阿里巴巴数据库操作手册.pdf

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) 常规检查： @dbcheck b) 检查表定义是否与测试库一致： exec pkg_check.CompareObject( user ’‘TABLE_NAME, ’ ‘); c) 立即联系开发接口人进行应用测试， 【建表】变更是否成功以应用测试结果为准。 d) 同步库若建表，也需要执行 a) 和 b) 两个步骤。 02-数据订正 一、 目的 明确【数据订正】操作的种类、 风险，并根据各种类型的数据订正制定完善的步骤和回退方 案，最大限度减少此类操作带来的故障。 二、 适用范围 l 新建表数据初始化 l 现有表新增数据 l 现有表删除数据 l 现有表上新增字段初始化 l 现有表上现有字段值修改 三、 风险评估 l 业务风险：订正本身所包含的业务不正确，导致给客户给公司带来损失。 l 程序风险： 订正本身业务正确， 但是应用程序无法兼容订正的数据， 导致应用出错。 l 数据库风险：订正本身业务正确，应用程序也可以兼容，但是订正速度过快、订正并发压 力过大，导致数据库无法正常提供服务。通常会造成表空间耗尽、 undo 消耗过快、 archive 增长过快、备库恢复压力大等问题。 l 沟通风险： 在业务方 -开发接口人 -DBA 三方的沟通交流过程中， 信息传递错误或者不及时， 导致最终订正