一、 前言
当业务系统上线一段时间，期间数据库运行稳定，性能良好。然而开发人员在运作过程中会有代码功能新增或调整等重要操作，如没有按照严格的规范进行，会导致系统资源不足甚至系统崩溃，给客户带来重大损失！为了提高DBA或开发人员的操作规范和风险意识，避免数据的误操作，降低公司的运营风险，现制定数据库操作规范手册，以进一步完善数据库管理维护制度。

二、 操作规范
2.1 建表
(一) 目的
明确建表操作的风险及标准流程，最大限度避免建表操作带来的故障。

(二) 适用范围

1. 项目预发布新建表
2. 项目正式发布新建表
3. 生产环境临时备份表
4. 不包含数据订正所建临时表
5. 不包含导数据所建的中间表

(三) 风险评估

1. 登录到错误的schema下，导致表建到错误的schema里，而应用无法访问。
2. 指定了错误的TABLESPACE参数，导致表建到了其他表空间，导致后续空间增长和维护困难。
3. 对于未来增量较快的表选择了一个空间规划不足的表空间，导致后续空间增长和维护困难。
4. 脚本末尾缺少分号，导致该表没有被创建上，而执行DDL的过程又不会报错。
5. 其他原因漏建了表，导致应用访问错误。
6. 所建的表定义（表名、字段名、字段定义、字段个数、字段顺序）跟测试环境不一致，导致应用访问错误。
7. CTAS（create table as select * from tab;）形式创建备份表，如果表很大，可能会造成IO高负荷，影响数据库的正常使用。

(四) 操作流程

1. 准备工作
   a) 在项目需求分析阶段，跟数据库设计人员一起明确新表所存放的数据库。
   b) 准备发布脚本时，检查tablespace定义，检查tablespace剩余空间，参考表空间自身负荷及新表的预期负荷，为每个新建的表选择合适的表空间，并在建表语句中添加tablespace的选项。
   c) 仅建表操作本身不会对数据库造成任何风险，故操作的时间点可以放宽：在变更时间窗口内，均可以执行建表操作。
2. 执行过程
   a) 用DBA或应用账户登录数据库，SHOW USER检查是否连接到正确的schema，如果用DBA账号执行，注意前缀一定要正确指定。
   b) 执行建表脚本。若一次建表个数较多，注意用分号区分好，避免出错。
   c) 查看过程若无报错，退出当前登录。若有报错，找出报错的地方，修改确认再执行，直至全部执行通过，最后退出当前登录。
   d) 对于临时备份表，如表很大，仅备份需要的数据，加限制条件CTAS
3. 验证方案
   a) 检查应用有无异常；
   b) 检查DG对端的表定义是否一致。

2.2 数据订正
(一) 目的
明确【数据订正】操作的种类、风险，并根据各种类型的数据订正制定完善的步骤和回退方案，最大限度减少此类操作带来的故障。

(二) 适用范围

1. 新建表数据初始化
2. 现有表新增数据
3. 现有表删除数据
4. 现有表上新增字段初始化
5. 现有表上现有字段值修改

(三) 风险评估

1. 业务风险：订正本身所包含的业务不正确，导致给客户给公司带来损失。
2. 程序风险：订正本身业务正确，但是应用程序无法兼容订正的数据，导致应用出错。
3. 数据库风险：订正本身业务正确，应用程序也可以兼容，但是订正速度过快、订正并发压力过大，导致数据库无法正常提供服务。通常会造成表空间耗尽、undo消耗过快、archive增长过快、备库恢复压力大等问题。
4. 沟通风险：在业务方-开发接口人-DBA三方的沟通交流过程中，信息传递错误或者不及时，导致最终订正的数据没有达到预期的目的。
5. 回滚风险：主要是因为业务方的原因，订正完成一段时间后要求回退，若在订正前没有备份原始数据，则可能导致无法顺利回退或者回退难度极大，给客户给公司带来损失。
6. 同步风险：各类同步架构下，数据订正可能导致同步堆积和同步延时，影响对端正常同步业务，这里主要指OGG或DG对端的同步影响。

更多详细内容请点击下载完整版文档查看！