数据库通用规范.docx

01-建表一、 目的明确建表操作的风险及标准流程，最大限度避免建表操作带来的故障。二、 适用范围l 项目预发布新建表l 项目正式发布新建表l 不包含数据订正所建临时表l 不包含导数据所建的中间表三、 风险评估l 登录到错误的 schema 下，导致表建到错误的 schema 里，而应用无法访问。l 忽略了 TABLESPACE 参数，导致表建到了默认表空间，导致后续空间增长和维护困难。l 对于未来增量较快的表选择了一个空间规划不足的表空间，导致后续空间增长和维护困难。l 脚本末尾缺少分号，导致该表没有被创建上，而执行 DDL 的过程又不会报错。l 其他原因漏建了表，导致应用访问错误。l 所建的表定义（表名、字段名、字段定义、字段个数、字段顺序）跟测试环境不一致，导致应用访问错误。l 同步库没有及时创建相应的表，或者没有更新同步配置，导致同步及应用出问题。四、 操作流程1. 准备工作a) 在项目需求分析阶段，跟数据库设计人员一起明确新表所存放的数据库。具体设计原则本文不繁述。b) 准备发布脚本时，检查 tablespace 定义，检查 tablespace 剩余空间，参考表空间自身负荷及新表的预期负荷，为每个新建的表选择合适的表空间，并在建表语句中添加 tablespace 的配置。c) 定发布计划时，跟开发接口人一起商定好建表操作的时间点。如小需求没有发布计划评审，则必须在提交测试时（即表结构冻结时）即开始与开发接口人确定建表时间点。如果发生计划外的发布建表需求，则要追究项目跟进的应用 DBA 沟通不力的责任。d) 以目前的认知，仅建表操作本身不会对数据库造成任何风险，故操作的时间点可以放宽：在变更时间窗口内，均可以执行建表操作。e) 建表操作属于预授权变更，在做之前必须在 ITIL 中提交相应的变更申请。2. 执行过程a) 用应用账户登录数据库， SHOW USER 检查是否连接到正确的 schema。严禁使用 sys、system 等用户建表。b) 执行建表脚本。若一次建表个数超过三个以上，要求将脚本事先保存为文本文件，上传至数据库服务器，执行时使用 @create_table_ddl.sql 的方式直接执行。c) 查看过程若无报错，退出当前登录。若有报错，找出报错的地方，修改确认再执行，直至全部执行通过，最后退出当前登录。3. 验证方案a) 常规检查： @dbcheckb) 检查表定义是否与测试库一致：exec pkg_check.CompareObject(‘user?,‘TABLE_NAME?);c) 立即联系开发接口人进行应用测试，【建表】变更是否成功以应用测试结果为准。d) 同步库若建表，也需要执行 a) 和 b) 两个步骤。02-数据订正一、 目的明确【数据订正】操作的种类、风险，并根据各种类型的数据订正制定完善的步骤和回退方案，最大限度减少此类操作带来的故障。二、 适用范围l 新建表数据初始化l 现有表新增数据l 现有表删除数据l 现有表上新增字段初始化l 现有表上现有字段值修改三、 风险评估l 业务风险：订正本身所包含的业务不正确，导致给客户给公司带来损失。l 程序风险：订正本身业务正确，但是应用程序无法兼容订正的数据，导致应用出错。l 数据库风险：订正本身业务正确，应用程序也可以兼容，但是订正速度过快、订正并发压力过大，导致数据库无法正常提供服务。通常会造成表空间耗尽、 undo 消耗过快、 archive增长过快、备库恢复压力大等问题。l 沟通风险：在业务方-开发接口人-DBA 三方的沟通交流过程中，信息传递错误或者不及时，导致最终订正的数据没有达到预期的目的。l 回滚风险：主要是因为业务方的原因，订正完成一段时间后要求回退，若在订正前没有备份原始数据，则可能导致无法顺利回退或者回退难度极大，给客户给公司带来损失。l 同步风险：各类同步架构下，数据订正可能导致同步堆积和同步延时，影响正常同步业务，所以有些大规模订正必须要正确屏蔽同步，并在多个库分别执行相同的订正脚本。l 缓存：有些表在应用层面做了缓存，制定订正计划的时候要考虑到订正后是否需要更新缓存。四、 操作流程1. 准备工作a) 需求分析阶段确认项目涉及的数据订正范围和数据量。b) 跟开发人员确定订正后是否涉及到对缓存的刷新和订正。c) 根据数据量评估对数据同步的影响，决定是否屏蔽同步。（应用 DBA 必须熟悉同步采用的技术、正常情况下的同步量和延时、可以容忍的同步延时、屏蔽同步的具体方法。）d) 注意规划订正速度，以防 undo 消耗殆尽。e) 订正脚本：i. 开发接口人直接提供可执行的 SQL 脚本， DBA 只负责拷贝执行。ii. 开发接口人提供主键及更新字段新值列表，由 DBA 导入数据库，写 SQL 脚本关联原表批量订正。iii. 开发接