对于数据库的巡检，应使用SQL Monitor, Zabbix监控工具实现自动化运维，超过警告阈值及时通过邮件，短信通知相关运维人员进行处理。
2. 检查数据库服务和后台进程
检查服务和后台进程是否正常，如果服务或进程停止，应及时恢复，并对系统日志进行分析，确定异常原因。
2.1. 检查数据库网络连通性
通过监控平台检查数据库网络是否能正常通信，如果存在网络异常，立即联系网络专员进行排查处理。
2.2. 检查数据磁盘空间
通过监控平台保证磁盘空间有20%以上的可用空间，如果空间不足，可删除无用文件增加可用空间或对历史数据进行归档并做数据库收缩，必要时可以考虑扩容硬盘容量。
2.3. 查看警告文件有无异常
通过自动化邮件告警接收数据库警告文件，如出现异常时，及时联系业务部门进行处理。
2.4. 检查备份作业是否正常完成
备份文件是数据库安全的重要环节，出现数据故障或灾难都需要备份进行数据还原恢复，如果备份作业失败，需立即手工启动数据库备份。
2.5. 内存压力监控
操作系统可用内存需要在30%以上（可通过任务管理器查看），且缓存命中率最好在90%以上，如果不是需要考虑优化查询或者增加内存。
缓存命中率可通过脚本查看，参见《附录二：获取数据库缓存命中率》
2.6. CPU压力监控
如果CPU的平均利用率持续长时间超过80%（24小时的监控周期里大约超过10分钟），这个时候要需要减少服务器的负载，优化查询或者更换更高频率的CPU。
2.7. 对数据库IO监控
读取数据所需平均时间小于20ms，写入数据所需平均时间小于40ms，如果持续超过设定的阈值（在你24小时的监控周期里大约超过10分钟，一个小时出现好几次），说明SQLServer有I/O瓶颈，这个时候要需要减少服务器的负载，优化查询，更换更快的磁盘控制器或者给控制器卡增加缓存。
2.8. 获取高峰时段运行TOP10脚本
进行SQL分析，看是否有异常查询，有无优化空间。脚本参见《02-数据库监控手册》
3. 数据库维护
3.1. 数据库完整性检查
数据完整性检查一般在做数据库迁移后执行，发现损坏要及时修复，防止对业务系统产生不利影响。非特殊情况禁止在生产环境中使用。
DBCC CHECKDB
3.2. 数据库性能统计
检查高速缓存区命中率，资源争用情况，若有异常，加以分析并改善
脚本参见《02-数据库监控手册》
3.3. 重组数据库表
随着系统运行，数据库会慢慢形成索引与数据页碎片，这样会降低扫描索引和数据页的速度，降低检索数据速度，因此需要对数据库运行状况做出统计，并分析资源消耗趋势，提前做好规划。
1.每月对数据库索引和数据页进行重组，因重组耗时较长，需要安排在业务闲时进行处理。【ALTER INDEX 索引名称 ON 表名 REORGANIZE】
2.对重要的业务大表定期（根据业务情况设定，可以一天一次）更新数据库统计信息。【UPDATE STATISTICS 表名】
4. 网络环境安全
1、数据库服务器置于单独的服务器区域，任何对这些数据库服务器的物理访问均应受到监管和控制。
2、数据库服务器所在的服务器区域边界部署防火墙或其它逻辑隔离设施。
5. 服务器安全
1、重要的数据库服务器除提供数据访问服务外，不提供任何其它的服务。如WEB，FTP等。
2、数据库专用帐户，赋予账户除运行数据库服务之外的最小权限，sa或是sysadmin等权限不能对外开放。sa默认帐号应该禁止在任何地方使用。
3、目录及相应文件访问权限进行控制，非数据库管理员不能访问数据库服务器上任何目录如：禁止用户访脚本存放目录。
4、数据库服务器置于单独的服务器区域，任何对这些数据库服务器的物理访问均应受到控制
5、数据库服务器所在的服务器区域边界部署防火墙或其它逻辑隔离设施。
5、去掉不必要的协议。禁用不必要的端口
确认用户和应用程序不使用管道通讯，删除管道，只保留TCP/IP协议。
①定期对数据库账户进行梳理，删除多余无用账号，对于离职人员的账号需要人资部门通知后要进行及时禁用和删除，禁止有高权限的应用程序账号存在。
②加强管理扩展存储过程
扩展存储过程（例如xp_cmdshell等），容易被利用来提升权限或进行破坏，需要进行删除，删除之前必须要确认应用程序没有调用。
6. 数据库安全
1、正式生产数据库系统与开发测试数据库系统物理分离，确保没有安装未使用的数据库系统组件或模块。
2、数据库用户的创建、删除和更改工作，并做好记录，按照最小原则进行授权。数据库管理员拥有对数据库管理的最高权限。
3、数据库对象存储空间的创建、删除和更改工作，并做好记录。
4、对系统的安装更新、系统设置的更改等要作好维护记录。
5、确保没有开启未使用的数据库系统服务。
6、数据库系统安装必要的升级程序或是补丁，升级前作好数据库备份。
7、编写建立权限脚本，为后续实施权限准备编写导出脚本权限，出现重组服务器或服务器宕机，可以直接运用脚本
8、禁止员工和运维人员在生产数据库建立以管理用途为目的数据库管理帐号，一经发现，永久禁用。须由DBA统一建立和权限管理。
数据库服务器通用安装指引
详细参见《01-数据库安装手册》
7. 数据保密制度
1、严禁任何人泄漏美宜佳数据库业务关键数据，需要访问业务数据时，必须提出申请批准后才能对数据进行相关的操作，并做好记录与日志。具体申请流程参见企业微信—零方科技信息权限申请流程
2、数据库安全性设计与管理需要依照《美宜佳数据保护技术规范》、《美宜佳数据资产管理条例》等制度实施。
8. 数据库账户管理
8.1. 数据库对象管理（表，索引，存储过程）
1、数据库对象的建立要遵循标准执行，所有的表，必须有主键，相关约束，建立索引按照相应的字段， 示例：IDX_TABLENAME_XXX_01的标准执行。
2、使用存储过程时应严格控制禁止在过程中使用多个链接服务器进行数据查询，在进行查询时应查看SQL执行计划，通过系统的建议，再相应的执行，任何时候禁止使用select * from table名的方法执行SQL查询语句。
8.2. 数据库建立标准
原则上由数据库管理员负责每个业务数据库的生命周期，即从到建立数据库，备份数据库，维护数据库，删除数据库，都由数据库管理员获取相应权限的情况下进行，其他人员一律无权新建数据库。已经建立的须向技术委员会报备，并为新数据库建档留存并审核。
8.3. 数据库，数据库帐号和计算机名命名规范
- 数据库命名规则按照相应业务名称进行
示例：MPS数据库，命名为 ‘MPSDB’
MPS备份数据库，命名为 ‘MPSDB_BA’
MPS 归档数据库 命名为 ‘MPSDB_ARC’
- 程序专用账号：app_<功能标识>_<账号性质>
功能标识：标识用于什么功能
账号性质：只读（r）、只写（w）、读写（wr）
示例：app_mpsReport_r（MPS报表只读账号）、app_mpsWeb_wr（MPSWeb读写账号）
- 链接服务器专用账号（建立在链接目标服务器上）：link_<功能标识>_<账号性质>
功能标识：标识用于什么功能
账号性质：只读（r）、只写（w）、读写（wr）
示例：link_synchMpsData_r（同步MPS数据）
- 代理作业帐户：agent_<功能标识>_<账号性质>
功能标识：标识用于什么功能
账号性质：只读（r）、只写（w）、读写（wr）
示例：agent_GenerReport_wr（生成报表读写账号）
- 计算机名：数据库的计算机名，应按照统一命名规范
示例：按照区域拼音简写划分，东莞：DG 湖南：HN
如计算机名：DGSDB538, DG代表东莞，S代表服务器，DB代表数据库
538代表IP地址192.168.5.38
8.4. 密码复杂度安全管理规范
- 数据库账户口令应为无意义的字符组，长度至少八位，并且至少包括数字、英文字母两类字符。可设置相应的策略强制复杂的口令。
- 必须根据安全要求对数据库管理系统的密码策略进行设置和调整，以确保口令符合要求。
- 定期或不定期修改数据库管理员口令，并与第一条相符合。
- 帐户、密码统一管理，由DBA进行管理，记录帐户变及审核。
- 程序使用账户密码以加密文件进行存储，程序使用时需要进行解密，禁止明文存储在配置文件或程序中。
8.5. 账户最小权限原则
- 数据库管理员帐号具有最高数据库管理权限（如：MSSQL的SA或是ORACLE的SYSDBA等），开发人员和业务人员需要直连访问数据库或需要具有一定数据库操作权限，必须通过企业微信向技术委员会申请，审批通过后，由数据库管理员开通权限后通过数据库统一管理平台进行操作数据库，其他人员通过业务系统访问数据库。
- 根据业务需要的权限建立专门的账号，以区分责任，提高系统的安全性，业务人员必须使用自己的账号登录数据库,如JOB，存储过程等执行权限。
- 对账号权限的设置遵从最小化原则，不需求的权限就不能开通。如查询数据的人员，只能有对某些表的SELECT权限，而不能用UPDATE，DELETE等权限。
- 普通数据库用户账户与数据库管理员帐户分离。
- 开通帐户必须先填写“企业微信-审批-零方科技信息权限申请流程”，经如下流程人员审批通过后，由数据库管理员建立帐号。
8.6. 管理固定服务器角色及权限
在生产环境中，必须严格管理固定服务器角色及权限。
角色 | 权限说明 | 适用人员或场景 |
bulkadmin | 这个角色可以运行BULK INSERT语句，该语句允许从文本文件中将数据导入SQLSERVER数据库中 | 需要执行大容量插入到数据库的域帐号 |
dbcreator | 这个角色可以创建、修改、删除和还原任何数据库。 | DBA |
diskadmin | 这个角色用于管理磁盘文件，比如镜像数据库和添加备份设备 | 助理DBA |
processadmin | 终止在SQLSERVER实例中运行的进程 | DBA |
public | 初始状态时没有权限；第二,所有数据库用户都是他的成员。 | 所有数据库用户 |
securityadmin | 这个角色将管理登录名及其属性，可以授权，拒绝和撤销服务器级/数据库级权限，可以重置登录名和密码。 | DBA |
serveradmin | 这个角色可以更改服务器范围的配置选项和关闭服务器 | DBA |
setupadmin | 为需要管理联接服务器和控制启动的存储过程的用户设计。 | DBA |
sysadmin | 这个角色有权在SQLSERVER中执行任何操作。建议将Administrators组从该角色中删除。 | DBA |
8.7. 管理数据库级别角色及权限
角色 | 权限说明 | 适用人员或场景 |
db_accessadmin | 可以在数据库中添加和删除数据库用户，组及角色，并设置访问权限 | DBA |
db_backupoperator | 可以备份和还原数据库 | DBA |
db_datareader | 可以读取任何表中的数据。 | 一般用户 |
db_datawriter | 可以添加、更改或删除所有表中的数据 | 一般用户 |
db_ddladmin | 可以添加、更改或删除数据库对象（即可以执行任何DDL语句） | DBA |
db_denydatareader | 不能读取任何表中的数据，但仍可以通过存储过程来查看 | 特别管控用户 |
db_denydatawriter | 不能更改任何表中的数据，但仍然可以通过存储过程来修改 | 特别管控用户 |
db_owner | 执行任何操作 | DBA |
db_securityadmin | 可以更改数据中的权限和角色 | DBA |
public | 每个数据库角色用户都属于public角色，未对用户授权之前，该用户将被授予public角色的权限，该角色不能被删除。 | 所有数据库用户 |
8.8. 管理用户自定义数据库角色及权限
确定每个角色对数据库表的操作权限，如创建、检索、更新、删除等。每个角色拥有刚好能够完成任务的权限，在应用时再为用户分配角色，则每个用户的权限等于他所兼角色的权限之和。
8.9. 管理应用程序角色及权限
如果需要限制用户通过特定应用程序（例如销售APP）来访问数据或防止用户直接访问数据。限制用户的这种访问方式将禁止用户使用应用程序（如 SQL 查询分析器）连接到 SQL Server 实例并执行编写质量差的查询，以免对整个服务器的性能造成负面影响。用户只能用帐号登录到应用软件，通过应用软件访问数据库，而没有其它途径操作数据库。
8.10. 数据库级用户权限设计
必须按照应用需求，设计不同的用户访问权限。包括应用系统管理用户，普通用户等，按照业务需求建立不同的应用角色。
8.11. 账户申请注销原则，无使用的账户注销。
数据库管理员收到人员离职通知后，应即时审查该人员是否拥有数据库访问账户；并禁用和删除相应人员的权限。
8.12. 数据库对象安全
- 数据文件安全，对数据文件访问权限进行控制，如：禁止除专用账户外的其它账户访问、修改、删除数据文件。
- 删除不需要的示例数据库，在允许存在的示例数据库中严格控制数据库账户的权限。
- 删除或禁用不需要的数据库对象，如表，视图，过程，函数，触发器等。
- 敏感数据安全，对于数据库中的敏感字段，如：口令等，要加密保存。
- 对应用系统进行升级时，需要列明需要处理的表、视图、存储过程等相关的数据库对象信息，并提交数据管理员进行风险评估。
- 所有DDL语句必须要经过DBA审核，大数据新表要特别说明，避免没优化索引的大数据表出现在业务中
- 数据库账号权限需进行备份，出现宕机或升级更换服务器时进行恢复
8.13. 访问控制
- 在外围防火墙或其它隔离设施上控制从互联网到数据库系统的直接访问。
- 修改数据库系统默认监听端口。
- 应用程序的数据库连接字符串中不能出现数据库账户口令明文。
- 禁止未授权的数据库系统远程管理访问，对于已经批准的远程管理访问，应采取安全措施增强远程管理访问安全。
- 原则上禁止所有数据库服务器连接互联网。
8.14. DBA 权限
- DBA按企业微信-零方科技信息权限申请流程完成数据库运维账号的申请。
- DBA 数据库运维账号绑定使用人员设备和手机号码，通过短信或双因子认证。所有的运维操作通过堡垒机完成，堡垒机记录并审计 DBA 所有的操作指令。
- 禁止远程DDL：核心业务系统限制DDL操作仅能在数据库服务器本地进行，禁止远程连接执行DDL操作
- 禁止在任何数据库应用中使用sa账号。数据库管理员也不能使用sa账号，需要建立一个与sa账号一样权限的超级用户来管理数据库。
- 禁止任何形式的DBA权限借用和滥用。
9. 备份与恢复
制定数据库系统的备份策略，定期对数据库系统进行备份。如备份周期，方式等。遵循32 1 0备份原则进行数据库数据备份。
3：存储 3 份完整文件，一份原件加上两份拷贝。
2：将文件起码保持在两种不同的介质上。（NAS,或是磁带）
1：将一份拷贝保存在异地。
0：零数据丢失
数据库备份策略要以高效备份与恢复为目标，与操作系统的备份最好地结合，物理备份与逻辑备份相结合。
必须对备份帐户的权限严格控制，由数据库管理员或指定专人负责。
妥善存放和保管备份介质（从数据库导出的磁盘柜等），防止非法访问与丢失。
根据重要性对数据库进行周期或不定期进行恢复测试与应及处理。
数据库升级、表结构变更、数据库分库分表分区、业务核心表变更前必须进行数据备份。对数据层面重大调整的，应启动完整日志或数据备份等数据容灾策略。
9.1. 备份方式及策略
完全备份：对备份的内容进行整体备份。
增量备份：仅备份相对于上一次备份后新增加和修改过的数据。
差异备份：仅备份相对于上一次完全备份之后新增加和修改过的数据。
按需备份：仅备份应用系统需要的部分数据，或临时需要解决的问题。
- 建立各个应用能接受的恢复时间和数据备份方式，采取相应的备份策略。
- 结合使用在线备份、逻辑备份和物理备份等多种方式，并且自动方式和手动方式相结合。
- 数据备份应根据系统情况和备份内容，采用不同的备份方式及策略，并做好记录。
9.2. 备份要求
- 数据库的数据要求定时自动备份。
- 建立备份记录，详细记录备份数据信息。备份应有明确的文件名，时间点、备份人,备份文件名统一标准。
- 备份文件保存时间可根据数据重要程度和有效利用周期确定。
- 备份介质安全问题，既要保证存放的物理环境，也要避免对备份数据的非授权访问。
- 系统管理员和数据库管理员确定备份策略。
- 备份文件名采用标准格式： 数据库名称 + 下划线 + ISO时间格式（YYYYMMDDHHNNSS,即四位年2位月2位日2位小时2位分钟 + 备份的扩展名bak或是trn（日志文件））示例：trn或是myj_202004011131.bak
- 数据表的备份命名为原表命名_bak_yyyyMMdd形式命名，若为同一天可以追加批次版本_v1，备份数据宜采用bcp形式进行数据导出与导入。备份表生产环境留存期至少7天。7天后应将该表转移至历史数据库留存至少90天。
- 备份文件与数据文件分离，不允许存放在相同磁盘。如使用SMB网络盘符进行备份的，要确保备份完成后网络盘符进行断开连接，以防止勒索病毒进行恶意破坏。
9.3. 恢复管理
- 恢复的操作直接影响到实际的应用。恢复操作应严格按一定的操作程序进行，而绝不能由备份系统管理员或某一个应用者进行恢复操作了事。
- 故障确认。在进行恢复之前首先应该确认造成故障的原因。故障的原因非常多，应该分清是操作系统的故障还是数据库的故障。如果是数据库的故障，不同的数据库应采用不同的故障分析方法，在完成故障分析后确认需要进行恢复操作时，由相应的管理人员提交书面的故障分析报告。
- 恢复计划。系统管理员在确认故障分析报告后应与相应管理者一起制定详细的恢复计划，包括应恢复的内容、恢复的时间、恢复的操作步骤、恢复对应用造成的影响等，主管领导应确认恢复对生产造成的影响，在批准执行恢复前应以相应方式与有关部门进行沟通和通知有关部门进行恢复前的准备工作。
- 定期备份校验。对长期保存的备份进行校验，防止在需要时备份不可用的情况发生，使用数据库自带工具校验。
10. 数据存放、归档管理
- 结合各业务系统确定数据有效期
- 对历史的数据转移到历史库或存储介质中，释放空间，减轻生产库压力。
- 及时清理无用数据，清理前务必和业务部门书面进行确认。
- 生产数据库要有副本，并进行异地备份
- 对于需要归档的历史数据，要按照归档的标准流程进行归档
11. 监控审计
- 数据库监控审计，应配置数据库系统记录所有用户的各种操作事件。
- 数据库管理员应定期对数据库进行安全审计，内容包括：用户权限、访问限制等。