阿里巴巴数据库操作手册
阿里巴巴数据库标准操作手册
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三方的沟通交流过程中,信息传递错误或者不及时,导致最终订正的数据没有达到预期的目的。
l 回滚风险:主要是因为业务方的原因,订正完成一段时间后要求回退,若在订正前没有备份原始数据,则可能导致无法顺利回退或者回退难度极大,给客户给公司带来损失。
l 同步风险:各类同步架构下,数据订正可能导致同步堆积和同步延时,影响正常同步业务,所以有些大规模订正必须要正确屏蔽同步,并在多个库分别执行相同的订正脚本。
l 缓存:有些表在应用层面做了缓存,制定订正计划的时候要考虑到订正后是否需要更新缓存。
四、 操作流程
1. 准备工作
a) 需求分析阶段确认项目涉及的数据订正范围和数据量。
b) 跟开发人员确定订正后是否涉及到对缓存的刷新和订正。
c) 根据数据量评估对数据同步的影响,决定是否屏蔽同步。(应用DBA必须熟悉同步采用的技术、正常情况下的同步量和延时、可以容忍的同步延时、屏蔽同步的具体方法。)
d) 注意规划订正速度,以防undo消耗殆尽。
e) 订正脚本:
i. 开发接口人直接提供可执行的SQL脚本,DBA只负责拷贝执行。
ii. 开发接口人提供主键及更新字段新值列表,由DBA导入数据库,写SQL脚本关联原表批量订正。
iii. 开发接口人提供订正逻辑,由DBA翻译为批量提交SQL脚本。
iv. 订正脚本要求可断点续跑,可反复执行。
v. 严禁仅用一个事务来处理大规模订正(影响的记录数超过1万笔)。超过一万笔的订正必须分段提交。
vi. 确认订正脚本的执行计划正确。
vii. 脚本中加入“进度报告”,即调用如下包(但是对于trigger中判断client_info的不允许这样处理。):
Dbms_Application_Info.set_client_info(n || ‘ rows commit.’);
–n为变量,累加,表示当前订正的总记录数。
f) 开发阶段跟开发接口人确认数据订正逻辑,完成订正脚本,并跟开发接口人确认脚本是否正确,同时按照需求准备备份脚本。
g) 测试阶段在测试库执行订正脚本,由开发接口人和测试人员验证订正的正确性,应用DBA协助验证。
h) 发布前确定订正速度和并发度,确定订正时间段,预估订正总时长,若涉及量较大,需要跨天做订正,则应规划好每日订正的数据量和时间段。
i) 备份要求:
i. 新建表初始化:无需备份,回退时直接truncate即可。
ii. 现有表新增数据:新建备份表记录下新增记录的主键,或者在新增记录中特定字段标识区分出订正所新增的数据,回退时定向delete这些记录。
iii. 现有表删除数据:新建备份表记录下删除数据的完整记录,回退时直接从备份表中取出数据insert到原表。
iv. 现有表上新增字段初始化:无需备份,回退时将该字段update为NULL或者开发接口人要求的值。不得将删除字段作为回退手段。
v. 现有表上现有字段值修改:新建备份表记录下所改动记录的主键及所改动字段的原始值,回退时将改动过的字段按照主键更新到原表(若应用程序在回滚前已经修改了记录,则要根据具体业务具体分析回滚方案)。
vi. 备份表:备份表统一命名为 table_name_bak_mmdd_operator,最后的operator为操作DBA的姓名每个字的首字母,如果超长了,则将原表名缩减。
创建人有责任定期删除创建时间超过一个月以上的备份表。
2. 执行过程
a) 如果需要,按照备份脚本备份数据。
b) 执行订正脚本。查看订正进度,使用如下脚本:
select client_info from v$session where client_info is not null;
–这个脚本必须配合前面描述的“进度报告”脚本执行。
c) 检查undo消耗: @undo
d) 检查表空间消耗: @tbs
e) 检查归档空间
f) 检查同步延时是否异常。
g) 如果需要刷新应用缓存,在订正结束后通知应用刷新缓存。
3. 验证方案
a) 以应用验证为主,数据库辅助做一些count等验证。以应用验证通过为操作成功标准。
五、 核心对象风险
l 考虑到对erosa和otter的影响,严禁数据订正更新主键值。
六、 回退方案
按照备份时所做的各种不同的回退方案进行回退,回退之后也要要求应用做验证。
03-创建、删除、修改sequence
一、 目的
明确定义对于sequence对象的操作风险及步骤。
二、 适用范围
l 项目发布创建新sequence。
l 以删除、重建的方式修改sequence的起始值。
l 在线修改sequence的cache值。

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。