阿里巴巴数据库实用操作手册

(此文档为word格式，下载后您可任意编辑修改！)

阿里巴巴数据库标准操作手册 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值。

三、 风险评估

l Sequence命名与应用程序中不一致，导致应用无法正常访问sequence。

l 双向同步的库，多库创建同名sequence，起始值和步长值设置不合理，导致生成的值在表中对应主键值同步产生冲突。

l 删除、重建sequence的过程中，应用无法访问sequence，高并发的应用可能会产生故障。 l 删除、重建sequence之后没有对sequence的权限进行恢复，导致原本访问该sequence的其他schema无法正常访问。 l Sequence的cache设置不合理，设置过小会导致大量的系统相关等待，反之则导致sequence生成值断层过多浪费严重。

l Java程序的int16数据类型只能容纳最大21亿，所以sequence不能超过这个值，如果有可能超过，需要跟开发确认。

四、 操作流程

1. 准备工作

a) 默认使用变更系统生成的sequence名称，如果要修改，必须跟开发人员沟通一致。 b) 与开发人员、项目发布负责人沟通变更时间点。对于删除、重建的操作必须明确告诉他们其间会有短暂的无法访问，如果是高并发的应用则选择在系统访问量最低的时候执行，规避风险。

c) 根据并发数确定cache值，默认为100，如遇特殊需求，酌情调整。

d) 删除、重建的操作，事先检查是否有其他schema拥有对于该sequence的访问权限： SELECT grantee, owner, table_name, privilege FROM dba_tab_privs

WHERE table_name = upper(‘重建的对象名?);

e) 全面考虑同步的风险，确定同步环节中各个数据库的同名sequence起始值及步长，保证不会发生冲突，通常有如下两种做法：

i. 起始值相差不大，步长值等于数据库个数。以双库同步为例，起始值分别设为1和2，步长均设为2。

ii. 起始值相距较大，步长值相同。以双库同步为例，A库起始值设为1，B库起始值设为2亿，步长均设为1。相差的值可以根据增长预期进行调整。 2. 执行过程

a) 标准新建脚本：

CREATE SEQUENCE seq_tablename START WITH 1 CACHE 100; 命名规范： seq_tablename

默认不指定recycle和max value。 b) 标准重建脚本：

DROP SEQUENCE seq_tablename ;

CREATE SEQUENCE seq_tablename START WITH 1 CACHE 100;

为了尽量缩短sequence不可用时间，这两个语句一起放在SecureCRT的chartWindow中一起执行。

c) 标准修改cache脚本：

ALTER SEQUENCE seq_tablename CACHE 200;

译功能，字段加完后再禁用该trigger。 l 表的依赖对象是否要相应调整。

表上面的依赖对象如果有存储过程或触发器等，逻辑是否需要相应调整。 l 是否涉及到同步。

同步中的表需要两地都要变更。涉及到erosa的要更新一下数据字典。Erosa是否需要重启取决于erosa版本。

l 是否要通知其他关联的部门。如DW, ASC或CRM等等。

有些表很多部门都用，需要沟通约定时间一起变更。如果有同步方案，同步方案的变更也要考虑。

四、 操作流程

1. 准备工作

a) 该表的数据量以及大小，以及数据变更量（按日/时/分/秒等） b) 该表的并发访问数，以及频率最高的几种sql的访问方式 2. 执行过程

以表T1 加字段 col2为例。T1的数据量非常大，访问频率很高。 a) 在sysdba下开启trigger禁用客户端自动编译功能。（可选） Alter trigger SYS.ddl_trigger_for_database enable; b) 变更字段

以下加字段同编译失效对象连着执行。编译时先编译trigger再编译存储过程或package等 @conn zzzzzz/aaa

Alter table t1 modify col2 varchar2(50); Alter trigger trg_t1_search compile; @conn retl/rrr

Alter trigger trg_t1_sync compile; @conn bopsretl/bbb

Alter trigger trg_t1_sync compile; @conn zzzzzz/aaa

Alter procedure sp_test compile;

后面3个trigger的编译可以开三个窗口同时进行。 另开一个窗口，在admin用户下查看当前失效对象 @dbcheck

c) 禁用ddl trigger

Alter trigger SYS.ddl_trigger_for_database disable;

d) 涉及到同步的表，各个节点都变更，erosa重启取决于版本 –更新erosa数据字典 ./getDict.sh –erosa重启 ./erctl stop ./erctl start 3. 验证方案

a) 验证sys下的trigger已经禁用

Select owner,trigger_name,status from dba_triggers where owner in (?SYS‘) and

trigger_name=upper(? ddl_trigger_for_database ‘); b) 验证结构正确 Desc alibaba1949.t1 c) 验证无失效依赖对象 @dbcheck

d) 跟测试库比对结构

五、 核心对象风险

核心对象风险指的是业务上重要的表，并且数据量很大或表大小很大或并发访问数很高时，变更的潜在风险。前面已经阐述。

09-改动统计信息

一、 目的

ORACLE优化器依据对象、系统的统计 信息来产生执行计划。因此如何收集对象、系统的统计信息尤其重要，本文档主要介绍收集对象统计信息的操作方法。某些情况下，如执行计划走错、表缺少关键字 段统计信息，需要我们手工的设置统计信息，因此也会涉及修改对象统计信息的内容。对于执行计划走错，通过修改统计信息来修正的情况，要对CBO算法有简单的了解，知道哪些统计信息涉及到cost计算的过程。可以参考lewis的CBO优化法则来了解cost的计算.本手册不会涉及这些内容。

二、 适用范围

l 新建表，表里初始化了大量的数据。

l 对于已经存在的表，表里数据量变化比较大。比如表删除了大量数据。需要重新收集统计信息。

l 由于表上统计信息不准确或缺失导致执行计划走错。 l 表统计信息过于陈旧，可能导致执行计划错误

三、 风险评估

l 统计信息的改变会涉及到表上所有SQL在下一次硬解析的时候用到，因此影响面广。在操作的时候，需要确认影响的范围，不要单纯为了某一个SQL的执行计划正确，而导致更多的SQL执行计划走错。

l 请仔细评估好，no_invalidate的设置问题，这个参数设置为true，表上依赖的SQL不会立马失效，即不会立刻采用表上新的统计信息。只有下一次硬解析的时候才会用新的统计信息来生成执行计划。绝大多数时候，我们这边采用的参数值是false.代表让表上依赖的游标立刻失效，在下一次解析的时候，能够立刻用上表上新的统计信息。

l no_invalidate在设置为false会导致在收集统计信息完成后，表上所有的sql重新解析，对于核心表以及一些依赖sql很多的表，要尽量放到业务低峰期去操作，否则可能遭遇硬解析的风暴，导致系统CPU繁忙，latch争用（shared pool latch ,library cache latch，library cache pin,cursor pin s:wait x）.如果遭遇这种情况，大多数时候，这种争用会随着硬解析完成而很快结束，但是也有可能会导致ORACLE CRASH。

l ORACLE优化器依赖准确健全的统计信息来产生优秀的执行计划，虽然收集统计信息理论上是为了让更精准的、更能反映目前数据的分布的统计信息产生出更优秀的执行计划，但是无论如何ORACLE无法保证这一点，有可能执行计划更优秀或者不变，有可能更糟糕了，相信随着ORACLE版本的不断提升，优化器的BUG会越来越少。

l ORACLE的dbms_stats不能单独收集列的统计信息，要了解到，如果收集了某一列的统计信息，表的统计信息会随着更新。

l 把estimate_percent设置的比较小，可以加快收集统计信息的时间，在不收集直方图的情况下，设置较小的值一般也不会有任何问题。可是如果表存在直方图，那么还是建议你根据情况把这个参数设置的大点。

l 目前生产环境都关闭了绑定变量窥探的功能，因此对于收集了直方图的列，需要确认传入的是文本变量。

四、 操作流程

几个重要收集参数的介绍以及使用规范：

1. no_invalidate 是否让表上的游标立即失效：自动定期执行（crontab）设置true，手动收集设置false。

2. force 是否对锁定统计信息的表收集统计信息 ：不指定，统一规范使用默认值false 不收集锁定表的统计信息，如果需要收集请提单给出原因。

3. degree 收集统计信息的并行度 ： 不指定，使用默认值1；如果为了加快收集时间，可以设置高的并行度，需要提单给出理由。

4. estimate_percent 采样百分比：一般设置成 0.5 ，可以让收集统计信息的时间缩短。这个值是个最小值，如果ORACLE觉得这个值小，会自动调大。采样的大小不要超过100M，采样的时间控制在1分钟以内。

5. method_opt 收集直方图的方法 ：分以下几种情况： a) 执行计划走错：

1. 收集指定列的基本统计信息：for columns A size repeat,B size repeat 2. 收集指定列的直方图：for columns A size auto,B size auto

b) 统计信息全为空：收集所有列的基本信息，同时收集个别列的直方图： for columns size repeat, A size auto,B size auto

c) 定时收集统计信息：for all columns size repeat

6. cascade 设置成true，收集索引的统计信息。9I默认值是false,10G默认值是true. 7. 如果是分区表，需要指定partname参数。

更多参数的说明请参照我写的dbms_stats包参数介绍。文档位于：数据库管理—–à知识总结—-àdbms_stats包使用规范 1. 准备工作

a) 准备脚本，确认好收集对象的schema,table name，以及收集统计信息的参数设置等。参数的设置要依据规范。不同与规范的参数要提单给出理由。

b) 9I统计信息收集、修改前，请做好统计信息的备份。stattab为备份统计信息表。

begin

dbms_stats.export_table_stats(ownname=>‘xx‘,tabname=>‘xx‘,stattab=>‘stattab‘); end; /

备份表的创建方式如下： begin

dbms_stats.CREATE_STAT_TABLE(OWNNAME=>‘xx‘,STATTAB=>‘stattab‘,TBLSPACE=>‘xx‘); end; /

2. 执行过程

以收集统计信息对象所在的用户登录数据库，以下为参考。 a) 分析表的统计信息 begin

dbms_stats.gather_table_stats(ownname => ?xx‘, tabname => ?xx‘, no_invalidate => FALSE, estimate_percent => 0.5,

method_opt => ?for all columns size repeat‘, cascade => true); end; /

以上仅为举例，特别是直方图的设置要依据情况，直方图的收集方法请依据规范来。 b) 设置列的统计信息 begin

dbms_stats.set_column_stats( ownname => user, tabname => ?table_name?, colname => ?column_name?, no_invalidate => false, density =>1/100000); end; /

说明：针对特定表的特定字段，如何获取准确的distinct 值： SELECT COUNT(DISTINCT column_name) FROM table_name; density统一设置为1/distinct值. c) 设置表的统计信息 begin

dbms_stats.set_table_stats( ownname => user, tabname => ?table_name‘, numblks => 6654, no_invalidate => false, force => false); end; /

说明：针对特定表，如何获取准确的 numrows: SELECT COUNT(*) FROM table_name; d) 修改索引的统计信息 begin

dbms_stats.set_index_stats(ownname => user, indname => ?index_name‘, numrows => 1000, numlblks => 300, numdist => 600, clstfct => 400, no_invalidate => false); end; /

clstfct的含义为聚簇因子。将群集因子改大，会增大该索引访问的cost；反之，则减小cost。 e) 删除表、索引、列的统计信息 begin

dbms_stats.delete_column_stats(ownname => user, tabname => ?table_name‘, colname => ?column_name‘, no_invalidate => false, force => false); end; /

begin

dbms_stats.delete_table_stats(ownname => user, tabname => ?table_name‘, no_invalidate => false, force => false); end; /

需要注意删除表的统计信息默认会把列、索引、表的都删除。 begin

dbms_stats.delete_index_stats(ownname => user, indname => ?index_name‘, no_invalidate => false, force => false); end; /

3. 验证方案

@tabstat脚本查看统计信息是否为最新，如果修改统计信息是为了验证执行计划，那么还需要explain出问题的sql的执行计划，确认统计信息修改后，走了期望的执行计划。

本文来源：https://www.bwwdw.com/article/n16v.html