《阿里巴巴数据库操作手册.pdf》由会员分享，可在线阅读，更多相关《阿里巴巴数据库操作手册.pdf（88页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、精选文档 可编辑修改 阿里巴巴数据库标准操作手册 01-建表 一、目的 明确建表操作的风险及标准流程，最大限度避免建表操作带来的故障。二、适用范围 l 项目预发布新建表 l 项目正式发布新建表 l 不包含数据订正所建临时表 l 不包含导数据所建的中间表 三、风险评估 l 登录到错误的 schema 下，导致表建到错误的 schema 里，而应用无法访问。l 忽略了 TABLESPACE 参数，导致表建到了默认表空间，导致后续空间增长和维护困难。l 对于未来增量较快的表选择了一个空间规划不足的表空间，导致后续空间增长和维护困难。l 脚本末尾缺少分号，导致该表没有被创建上，而执行 DDL 的过程又
2、不会报错。l 其他原因漏建了表，导致应用访问错误。l 所建的表定义（表名、字段名、字段定义、字段个数、字段顺序）跟测试环境不一致，导致应用访问错误。l 同步库没有及时创建相应的表，或者没有更新同步配置，导致同步及应用出问题。四、操作流程 1.准备工作 a)在项目需求分析阶段，跟数据库设计人员一起明确新表所存放的数据库。具体设计原则本文不繁述。b)准备发布脚本时，检查 tablespace 定义，检查 tablespace 剩余空间，参考表空间自身负荷及新表的预期负荷，为每个新建的表选择合适的表空间，并在建表语句中添加tablespace 的配置。c)定发布计划时，跟开发接口人一起商定好建表操作
3、的时间点。如小需求没有发布计划评审，则必须在提交测试时（即表结构冻结时）即开始与开发接口人确定建表时间点。如果发生计划外的发布建表需求，则要追究项目跟进的应用 DBA 沟通不力的责任。d)以目前的认知，仅建表操作本身不会对数据库造成任何风险，故操作的时间点可以放宽：精选文档 可编辑修改 在变更时间窗口内，均可以执行建表操作。精选文档 可编辑修改 e)建表操作属于预授权变更，在做之前必须在 ITIL 中提交相应的变更申请。2.执行过程 a)用应用账户登录数据库，SHOW USER 检查是否连接到正确的 schema。严禁使用 sys、system等用户建表。b)执行建表脚本。若一次建表个数超过三
4、个以上，要求将脚本事先保存为文本文件，上传至数据库服务器，执行时使用 create_table_ddl.sql的方式直接执行。c)查看过程若无报错，退出当前登录。若有报错，找出报错的地方，修改确认再执行，直至全部执行通过，最后退出当前登录。3.验证方案 a)常规检查：dbcheck b)检查表定义是否与测试库一致：exec pkg_check.CompareObject(user,TABLE_NAME);c)立即联系开发接口人进行应用测试，【建表】变更是否成功以应用测试结果为准。d)同步库若建表，也需要执行 a)和 b)两个步骤。02-数据订正 一、目的 明确【数据订正】操作的种类、风险，并根
5、据各种类型的数据订正制定完善的步骤和回退方案，最大限度减少此类操作带来的故障。二、适用范围 l 新建表数据初始化 l 现有表新增数据 l 现有表删除数据 l 现有表上新增字段初始化 l 现有表上现有字段值修改 三、风险评估 l 业务风险：订正本身所包含的业务不正确，导致给客户给公司带来损失。l 程序风险：订正本身业务正确，但是应用程序无法兼容订正的数据，导致应用出错。l 数据库风险：订正本身业务正确，应用程序也可以兼容，但是订正速度过快、订正并发压力过大，导致数据库无法正常提供服务。通常会造成表空间耗尽、undo 消耗过快、archive增长过快、备库恢复压力大等问题。l 沟通风险：在业务方-
6、开发接口人-DBA 三方的沟通交流过程中，信息传递错误或者不及时，导致最终订正的数据没有达到预期的目的。精选文档 可编辑修改 l 回滚风险：主要是因为业务方的原因，订正完成一段时间后要求回退，若在订正前没有备份原始数据，则可能导致无法顺利回退或者回退难度极大，给客户给公司带来损失。l 同步风险：各类同步架构下，数据订正可能导致同步堆积和同步延时，影响正常同步业务，所以有些大规模订正必须要正确屏蔽同步，并在多个库分别执行相同的订正脚本。l 缓存：有些表在应用层面做了缓存，制定订正计划的时候要考虑到订正后是否需要更新缓存。四、操作流程 1.准备工作 a)需求分析阶段确认项目涉及的数据订正范围和数据
7、量。b)跟开发人员确定订正后是否涉及到对缓存的刷新和订正。c)根据数据量评估对数据同步的影响，决定是否屏蔽同步。（应用 DBA 必须熟悉同步采用的技术、正常情况下的同步量和延时、可以容忍的同步延时、屏蔽同步的具体方法。）d)注意规划订正速度，以防 undo 消耗殆尽。e)订正脚本：i.开发接口人直接提供可执行的 SQL 脚本，DBA 只负责拷贝执行。ii.开发接口人提供主键及更新字段新值列表，由 DBA 导入数据库，写 SQL 脚本关联原表批量订正。iii.开发接口人提供订正逻辑，由 DBA 翻译为批量提交 SQL 脚本。iv.订正脚本要求可断点续跑，可反复执行。v.严禁仅用一个事务来处理大规
8、模订正（影响的记录数超过1万笔）。超过一万笔的订正必须分段提交。vi.确认订正脚本的执行计划正确。vii.脚本中加入“进度报告”，即调用如下包（但是对于 trigger 中判断 client_info 的不允许这样处理。）：Dbms_Application_Info.set_client_info(n|rows commit.);n 为变量，累加，表示当前订正的总记录数。f)开发阶段跟开发接口人确认数据订正逻辑，完成订正脚本，并跟开发接口人确认脚本是否正确，同时按照需求准备备份脚本。g)测试阶段在测试库执行订正脚本，由开发接口人和测试人员验证订正的正确性，应用 DBA协助验证。h)发布前确定订
9、正速度和并发度，确定订正时间段，预估订正总时长，若涉及量较大，需要跨天做订正，则应规划好每日订正的数据量和时间段。i)备份要求：i.新建表初始化：无需备份，回退时直接 truncate 即可。ii.现有表新增数据：新建备份表记录下新增记录的主键，或者在新增记录中特定字段标识区分出订正所新增的数据，回退时定向 delete 这些记录。iii.现有表删除数据：新建备份表记录下删除数据的完整记录，回退时直接从备份表中取出数据 insert 到原表。iv.现有表上新增字段初始化：无需备份，回退时将该字段 update 为 NULL 或者开发接口人要求的值。不得将删除字段作为回退手段。v.现有表上现有字
10、段值修改：新建备份表记录下所改动记录的主键及所改动字段的原始值，回退时将改动过的字段按照主键更新到原表（若应用程序在回滚前已经修改了记录，则要根精选文档 可编辑修改 据具体业务具体分析回滚方案）。精选文档 可编辑修改 vi.备份表：备份表统一命名为 table_name_bak_mmdd_operator，最后的 operator 为操作DBA 的姓名每个字的首字母，如果超长了，则将原表名缩减。创建人有责任定期删除创建时间超过一个月以上的备份表。2.执行过程 a)如果需要，按照备份脚本备份数据。b)执行订正脚本。查看订正进度，使用如下脚本：select client_info from v$s
11、ession where client_info is not null;这个脚本必须配合前面描述的“进度报告”脚本执行。c)检查 undo 消耗:undo d)检查表空间消耗:tbs e)检查归档空间 f)检查同步延时是否异常。g)如果需要刷新应用缓存，在订正结束后通知应用刷新缓存。3.验证方案 a)以应用验证为主，数据库辅助做一些 count 等验证。以应用验证通过为操作成功标准。五、核心对象风险 l 考虑到对 erosa 和 otter 的影响，严禁数据订正更新主键值。六、回退方案 按照备份时所做的各种不同的回退方案进行回退，回退之后也要要求应用做验证。03-创建、删除、修改 seque
12、nce 一、目的 明确定义对于 sequence 对象的操作风险及步骤。二、适用范围 l 项目发布创建新 sequence。l 以删除、重建的方式修改 sequence 的起始值。l 在线修改 sequence 的 cache 值。精选文档 可编辑修改 三、风险评估 l Sequence 命名与应用程序中不一致，导致应用无法正常访问 sequence。l 双向同步的库，多库创建同名 sequence，起始值和步长值设置不合理，导致生成的值在表中对应主键值同步产生冲突。l 删除、重建 sequence 的过程中，应用无法访问 sequence，高并发的应用可能会产生故障。l 删除、重建 sequ
13、ence 之后没有对 sequence 的权限进行恢复，导致原本访问该 sequence的其他 schema 无法正常访问。l Sequence 的 cache 设置不合理，设置过小会导致大量的系统相关等待，反之则导致sequence 生成值断层过多浪费严重。l Java 程序的 int16数据类型只能容纳最大21亿，所以 sequence 不能超过这个值，如果有可能超过，需要跟开发确认。四、操作流程 1.准备工作 a)默认使用变更系统生成的 sequence 名称，如果要修改，必须跟开发人员沟通一致。b)与开发人员、项目发布负责人沟通变更时间点。对于删除、重建的操作必须明确告诉他们其间会有短
14、暂的无法访问，如果是高并发的应用则选择在系统访问量最低的时候执行，规避风险。c)根据并发数确定 cache 值，默认为100，如遇特殊需求，酌情调整。d)删除、重建的操作，事先检查是否有其他 schema 拥有对于该 sequence 的访问权限：SELECT grantee,owner,table_name,privilege FROM dba_tab_privs WHERE table_name=upper(重建的对象名);e)全面考虑同步的风险，确定同步环节中各个数据库的同名 sequence 起始值及步长，保证不会发生冲突，通常有如下两种做法：i.起始值相差不大，步长值等于数据库个数。
15、以双库同步为例，起始值分别设为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;
16、为了尽量缩短 sequence 不可用时间，这两个语句一起放在 SecureCRT 的 chartWindow 中一起执行。c)标准修改 cache 脚本：精选文档 可编辑修改 ALTER SEQUENCE seq_tablename CACHE 200;d)标准赋权脚本：GRANT SELECT ON seq_tablename to username;3.验证方案 a)dbcheck 检查是否有失效对象 b)通知应用验证是否可以正常访问 sequence 五、核心对象风险 高并发对象重建时短暂不可访问；04_增加、删除唯一约束 一、目的 明确增删唯一约束操作的风险及标准流程，最大限度避免增
17、删唯一约束操作带来的故障。二、适用范围 l 项目发布新建表的增删唯一约束 l 对于旧表的增删唯一约束 三、风险评估 l 对现有表新增唯一约束的操作，会堵塞包括查询在内的所有操作，风险很大，请谨慎使用，尽量在新建表时和开发讨论后增加。l 没有指定 index,系统自动创建了 index，删除约束时，自动创建的 index 同时删除了。l 在高峰期创建,导致大量的 library cache lock/pin 的等待 l 有同步的应用，先要在源端加，后在目标端加。l 表里有重复的数据，导致操作失败。四、操作流程 1.准备工作 a)检查唯一建字段上是否存在 index。没有的话,需首先创建 inde
18、x(步骤详见增加 index手册)。精选文档 可编辑修改 b)检查唯一键上是否有重复数据，如有，需和开发讨论如何处理。c)根据应用的需求和数据库的负载情况，确定操作的时间点。对于数据量和访问量较大的表，变更时间点要谨慎选择.d)检查字段上是否已经有了约束。e)增加和删除唯一约束属于标准变更，需要开发在 ITIL 中提交事件单，应用 dba 提交变更单，有技术经理审批后执行。f)对现有表新增约束，如果使用 validate 这个参数，会导致该表上连查询在内的所有操作都被锁住，风险非常大；如果使用 novalidate 参数，这个参数会导致数据字典不一致（及导致 sqlldr 的时候会导入重复数据
19、）。两者相比，故通常情况下用 validate 的风险更大，默认必须使用 novalidate 参数。g)约束名与所依赖索引名一致。2.执行过程 a)用应用账户登录数据库，SHOW USER 检查是否连接到正确的 schema。b)执行增加或删除的命令。命令模板如下：ALTER TABLE 表名 ADD CONSTRAINT 表名_uk unique(字段名)USING INDEX 索引名 NOVALIDATE;ALTER TABLE 表名 DROP CONSTRAINT 约束名 KEEP INDEX;如有 otter 同步，要注意执行顺序：先在源数据库端加后在目标端增加。c)查看过程若无报错
20、，退出当前登录。若有报错，找出报错的地方，修改确认再执行，直至全部执行通过，最后退出当前登录。3.验证方案 a)常规检查：dbcheck b)检查表定义是否与测试库一致：exec pkg_check.CompareObject(user,TABLE_NAME);c)检查约束是否加上或删除：select*fromdba_cons_colu mns wheretable_name=upper(table_name)五、核心对象风险 1.核心表访问量大，数据量大。增加唯一约束时会短暂出现 library cache pin/lock。执行时间要订在核心表访问的低峰期。六、回退方案 1.执行前需准备好
21、回退的脚本。2.回退时需得到开发的确认，并确认回退的时间点。精选文档 可编辑修改 05-加字段 一、目的 阐述表变更的风险及其步骤，降低对应用的影响和避免故障。二、适用范围 l 所有在使用的表的加字段 三、风险评估 l 新增字段的类型、长度（精度）是否合适 解决方法：跟应用明确加字段和改字段的风险，确认新增字段类型正确、长度（精度）合适。以及跟应用明确老数据是否要订正？如何订正？新增列是否非空？是否有默认值等等。l 新增字段的非空属性、默认值以及老数据问题。新增字段如果是 NOT NULL 的，则一定要有默认值，否则老应用的 insert 代码可能报错。表如果存在老数据，带上默认值的时候会导致
22、 oracle 去订正老的数据行的新增列。如果老数据非常多，表的并发访问高，很有可能导致大面积的阻塞等待以及产生大事务，甚至有可能导致 undo 耗尽。倘若回滚，还会因为回滚产生的并发会话导致 load 飙升。解决方法：先不带 not null 不带默认值加上列，再更改列默认值，再批量订正老数据，然后再加上 not null 属性。如果是大表，并且并发访问很高的表，则新增列不允许为 NOT NULL，以简化后面变更步骤，降低风险！l 新增字段导致依赖对象失效、sql 游标失效问题。表的 DML 并发很高的时候，如果表上面还有依赖对象，新增字段会导致依赖对象失效。默认其他 DML 会话会尝试去自
23、动编译这个依赖对象，此时很可能会出现大面积的 library cache pin。应用会话的连接时间会加长，进而导致出现后续应用报不能取得连接池错误。应用服务器 load 由此飙升。表新增字段也会导致跟该表有关的 SQL 的游标失效，如果 SQL 的并发很高（查询 SQL 或者DML SQL），失效后 SQL 会重新解析，此时也可能会出现大量的 library cache pin&library cache lock。解决方法：选择在业务低峰期发布，同时在数据库级别开启 trigger 禁用客户端程序自动编译功能，字段加完后再禁用该 trigger。l 表的依赖对象是否要相应调整。表上面的依赖
24、对象如果有存储过程或触发器等，逻辑是否需要相应调整。l 是否涉及到同步。同步中的表需要两地都要变更。涉及到 erosa 的要更新一下数据字典。Erosa 需要重启一下。l 是否要通知其他关联的部门。如 DW,ASC 或 CRM 等等。精选文档 可编辑修改 有些表很多部门都用，需要沟通约定时间一起变更。如果有同步方案，同步方案的变更也要考虑。四、操作流程 1.准备工作 a)该表的数据量以及大小，以及数据变更量（按日/时/分/秒等）b)该表的并发访问数，以及频率最高的几种 sql 的访问方式 2.执行过程 以表 T1 加字段 col2为例。T1的数据量非常大，访问频率很高。a)在 sysdba 下
25、开启 trigger 禁用客户端自动编译功能。（可选）Alter trigger SYS.ddl_trigger_for_database enable;b)变更字段 以下加字段同编译失效对象连着执行。编译时先编译 trigger 再编译存储过程或 package等 conn zzzzzz/aaa Alter table t1 add col2 varchar2(20);Alter trigger trg_t1_search compile;conn retl/rrr Alter trigger trg_t1_sync compile;conn bopsretl/bbb Alter trigg
26、er trg_t1_sync compile;conn zzzzzz/aaa Alter procedure sp_test compile;后面3个 trigger 的编译可以开三个窗口同时进行。另开一个窗口，在 admin 用户下查看当前失效对象 dbcheck c)老数据订正 如果需要默认值，加上默认值 Alter table t1 modify col2 default Y;数据订正存储过程 Create or replace procedure sp_dml0214 As Cursor c1 is select rowed rid,id,col2 from t1 where col2
27、 is null;V_cnt number:=0;Begin For rec_c1 in c1 loop V_cnt:=v_cnt+1;Update t1 set col2=Y where rowed=rec_c1.rid and id=rec_c1.id;If mod(v_cnt,500)=0 then Commit;Dbms_application_info.set_client_info(sp_dml0214|v_cnt|rows!);精选文档 可编辑修改 End if;End loop;Commit;Dbms_application_info.set_client_info(sp_dm
28、l0214|v_cnt|rows!);End;/Exec sp_dml0214;另开一个窗口，查看订正进度 col machine for a19 col status for a12 col client_Info for a50 select sid,serial#,status,machine,client_Info,sql_hash_value from v$session where client_Info is not null;d)订正完后加上 NOT NULL 属性 Alter table t1 add col2 not null;e)(国际站 可选)中美都变更，erosa 重
29、启 更新 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=ddl_trigger_for_database enable;b)验证结构正确 Desc zzzzzz.t1 c)验证无失效依赖对象 dbcheck 五、核心对象风险 核心对象风险指的是业务上重要的表，并且数据量很大或表大小很大或并发访
30、问数很高时，变更的潜在风险。前面已经阐述。精选文档 可编辑修改 六、回退方案 1.大表的新增字段不允许回滚。因为回滚即删掉字段，会导致锁表，持续时间很长进而导致一序列的严重问题。2.普通表的新增字段如果是发布失败，后续还会有二次发布，也不考虑回滚。或者只是将not null 属性拿掉，下次发布再加上。3.普通表如果应用有足够的理由要求回滚，则回滚。06-加 not null 字段 一、目的 阐述表变更的风险及其步骤，降低对应用的影响和避免故障。二、适用范围 l 所有在使用的表的加 not null 字段，但核心表（并发访问高的大表不允许加 not null）。三、风险评估 l 新增字段的类型、
31、长度（精度）是否合适 解决方法：跟应用明确加字段和改字段的风险，确认新增字段类型正确、长度（精度）合适。是否有默认值？以及跟应用明确老数据是否要订正？如何订正？l 新增字段的非空属性、默认值以及老数据问题。新增字段是 NOT NULL 的，则一定要有默认值，否则老应用的 insert 代码可能报错。表如果存在老数据，带上默认值的时候会导致 oracle 去订正老的数据行的新增列。如果老数据非常多，表的并发访问高，很有可能导致大面积的阻塞等待以及产生大事务，甚至有可能导致 undo 耗尽。倘若回滚，还会因为回滚产生的并发会话导致 load 飙升。解决方法：先不带 not null 不带默认值加上
32、列，再更改列默认值，再批量订正老数据，然后再加上 not null 属性。如果是大表，并且并发访问很高的表，则新增列不允许为 NOT NULL，以简化后面变更步骤，降低风险！l 新增字段导致依赖对象失效、sql 游标失效问题。表的 DML 并发很高的时候，如果表上面还有依赖对象，新增字段会导致依赖对象失效。默认访问这些依赖对象的会话（如 DML 会话，或者应用调存储过程等）会尝试去自动编译这个依赖对象（9i 所有会话都会尝试去编译，10g 以后只有一个会话去主动编译，其他等待），此时很可能会出现大面积的 library cache pin。应用会话的连接时间会加长，进而导致出现精选文档 可编辑
33、修改 后续应用报不能取得连接池错误。应用服务器 load 由此飙升。精选文档 可编辑修改 表新增字段也会导致跟该表有关的 SQL 的游标失效，如果 SQL 的并发很高（查询 SQL 或者DML SQL），失效后 SQL 会重新解析，此时也可能会出现大量的 library cache pin&library cache lock。解决方法：选择在业务低峰期发布，同时在数据库级别开启 trigger 禁用客户端程序自动编译功能，字段加完后再禁用该 trigger。l 表的依赖对象是否要相应调整。表上面的依赖对象如果有存储过程或触发器等，逻辑是否需要相应调整。l 是否涉及到同步。同步中的表需要两地都
34、要变更。涉及到 erosa 的要更新一下数据字典。Erosa 需要重启一下。l 是否要通知其他关联的部门。如 DW,ASC 或 CRM 等等。有些表很多部门都用，需要沟通约定时间一起变更。如果有同步方案，同步方案的变更也要考虑。l 表结构变更后应用需要重启。应用端缓存的表结构跟实际结构有冲突报错。四、操作流程 1.准备工作 a)该表的数据量以及大小，以及数据变更量（按日/时/分/秒等）b)该表的并发访问数，以及频率最高的几种 sql 的访问方式 2.执行过程 以表 T1 加字段 col2为例。T1的数据量非常大，访问频率很高。a)在 sysdba 下开启 trigger 禁用客户端自动编译功能
35、。（可选）Alter trigger SYS.ddl_trigger_for_database enable;b)变更字段 以下加字段同编译失效对象连着执行。编译时先编译 trigger 再编译存储过程或 package等 conn zzzzzz/aaa Alter table t1 add col2 varchar2(20);如果需要默认值，加上默认值 Alter table t1 modify col2 default Y;Alter trigger trg_t1_search compile;conn retl/rrr Alter trigger trg_t1_sync compile;
36、conn bopsretl/bbb Alter trigger trg_t1_sync compile;conn zzzzzz/aaa Alter procedure sp_test compile;另开一个窗口，在 admin 用户下查看当前失效对象 dbcheck 精选文档 可编辑修改 c)禁用 ddl trigger Alter trigger SYS.ddl_trigger_for_database disable;d)老数据订正 数据订正存储过程 Create or replace procedure sp_dml0214 As Cursor c1 is select rowed r
37、id,id,col2 from t1 where col2 is null;V_cnt number:=0;Begin For rec_c1 in c1 loop V_cnt:=v_cnt+1;Update t1 set col2=Y where rowid=rec_c1.rid and id=rec_c1.id;If mod(v_cnt,500)=0 then Commit;End if;End loop;Commit;End;/Exec sp_dml0214;另开一个窗口，用sqlinfo 脚本查看订正进度 e)订正完后加上 NOT NULL 属性(核心表不要做了)，风险和步骤详情参见文档
38、：4.增加、删除唯一约束 Alter table t1 modify col2 not null;f)表涉及到同步后，再多个节点变更，erosa 是否重启取决于 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)
39、;b)验证结构正确 Desc zzzzzz.t1 c)验证无失效依赖对象 dbcheck 精选文档 可编辑修改 d)跟测试库比对。五、核心对象风险 核心对象风险指的是业务上重要的表，并且数据量很大或表大小很大或并发访问数很高时，变更的潜在风险。前面已经阐述。六、回退方案 1.大表的新增字段不允许回滚。因为回滚即删掉字段，会导致锁表，持续时间很长进而导致一序列的严重问题。2.普通表的新增字段如果是发布失败，后续还会有二次发布，也不考虑回滚。或者只是将not null 属性拿掉，下次发布再加上。3.普通表如果应用有足够的理由要求回滚，则回滚 07-赋权 一、目的 明确常用赋权操作标准流程，以及赋权
40、过程中可能产生的风险，最大限度避免赋权操作带来的系统故障。二、适用范围 l 对数据库对象的授权操作，数据库对象包括表、存储过程、同义词、视图和序列等。授权类型包括查询、增删改、执行。l 对数据库用户的系统授权操作。三、风险评估 l 对数据库用户进行系统授权时，需要根据实际情况进行，避免因对用户授予过高的系统权限或角色，进而使该用户存在误操作引发数据库或应用故障的风险。l 对于存储机密数据的表的授权，需要慎重。以免泄露机密数据。l 对于涉及同步的数据库，需要分别在同步的两端数据库执行相同的授权操作。l 10G 之前版本，grant 操作需要获得 Exclusive 级别的 library cac
41、he lock/pin。其风险精选文档 可编辑修改 主要针对于 procedure、function 等，对 table 基本无影响。若 procedure 正在执行时，对其本身或者其依赖的 procedure、function 进行授权，将阻塞其他要执行此 procedure 或其依赖 procedure、function 的会话，直到授权前正在执行的 procedure 结束。精选文档 可编辑修改 l 对数据库对象授权时，不会引起依赖对象失效，但会导致 library cache 中与授权对象有依赖关系的游标失效，进而产生硬解析。如果对象的依赖游标过多，或执行频率较高，可能会对系统造成较大
42、的冲击，造成 CPU 繁忙，latch 争用严重，最常引起的latch 争用有 shared pool、library cache 还会有 library cache pin、cursor pin s:wait x 等争用出现。如果争用比较严重，甚至可能导致数据库 crash。为避免此类情况出现，对于新建对象，应尽可能的先把权限授予给可能会使用到的用户；对于在使用的对象，应充分评估对象依赖游标的个数和执行次数，选择执行低峰进行操作。l 对于 grant any table，或者 grant DBA/EXP_FULL_DATABASE 等涉及大量对象的系统授权操作，应该作为重大变更对待，此类操作
43、的风险极大，务必在业务低峰期进行操作。四、操作流程 1.准备工作 a)确认此次授权是否属于正常的业务需要。b)若赋予的为系统权限，禁止使用 with admin option 选项。c)若赋予的为对象权限，请确认此对象在数据库中缓存的游标个数，以及每个游标在不同时段的执行频率，根据具体的情况选择合适的变更时间窗口进行授权。d)准备授权脚本。e)新建对象的授权需要走事件流程。f)在用对象的授权或涉及大量对象的系统授权需要走一般变更或重大变更流程。2.执行过程 a)以赋权对象所在的用户登录数据库，SHOW USER 检查是否连接到正确的 schema。b)如果被依赖对象的执行频率很高，需要打开 D
44、DL TRIGGER.c)执行赋权脚本。d)查看过程若无报错，退出当前登录。3.验证方案,以下列举两种验证方式：使用被赋权用户登录：i.验证对象权限：select owner,grantee,table_name,privilege from user_tab_privs where grantee=&USER_NAME and table_name=&object_name;ii.验证系统权限：select username,privilege from user_sys_privs;五、核心对象风险 核心对象上的依赖 sql 往往较多，而且执行频率较高，授权操作会导致对象依赖的游标失效，进
45、而导致硬解析风暴。应该尽量选择业务低峰期来进行核心表的赋权操作。精选文档 可编辑修改 六、回退方案 我们遭遇的授权操作的最大风险第一是导致的硬解析风暴，第二是授权操作涉及数据字典的修改，甚至可能会导致 row cache lock 的出现。对于硬解析风暴的风险，回退的方案不是revoke 对象的权限，而是等待硬解析风暴过去。对于赋权操作引发的问题，要根据具体的情况而定。提前把方案一定要整理好，慎重选择变更的时间，避免出现问题。08-修改字段长度 一、目的 阐述表变更的风险及其步骤，降低对应用的影响和避免故障。二、适用范围 l 所有在使用的表修改字段长度，具体是 number 型和 varcha
46、r2型，只允许范围扩大。三、风险评估 l 相关表的长度是否一并修改 当该表某个字段长度加长后，可能有关联的表的数据来自于该表，那么那个关联的表的相应字段也应该加长。这点由应用去评估。该表上如果有物化视图，则物化视图的基表的对应的字段长度也要加长。该表上如果有存储过程、触发器、package，里面的代码中跟该字段有关的变量如果声明的是具体的长度，则也要加长。正确的声明方式是 col%type。l 修改字段导致依赖对象失效、sql 游标失效问题。表的 DML 并发很高的时候，如果表上面还有依赖对象，修改字段长度会导致依赖对象失效。默认其他 DML 会话会尝试去自动编译这个依赖对象，此时很可能会出现
47、大面积的 library cache pin。应用会话的连接时间会加长，进而导致出现后续应用报不能取得连接池错误。应用服务器 load 由此飙升。表修改字段长度也会导致跟该表有关的 SQL 的游标失效，如果 SQL 的并发很高（查询 SQL或者 DML SQL），失效后 SQL 会重新解析，此时也可能会出现大量的 library cache pin&library cache lock。解决方法：选择在业务低峰期发布，同时在数据库级别开启 trigger 禁用客户端程序自动编译功能，字段加完后再禁用该 trigger。精选文档 可编辑修改 l 表的依赖对象是否要相应调整。表上面的依赖对象如果有
48、存储过程或触发器等，逻辑是否需要相应调整。l 是否涉及到同步。同步中的表需要两地都要变更。涉及到 erosa 的要更新一下数据字典。Erosa 是否需要重启取决于 erosa 版本。l 是否要通知其他关联的部门。如 DW,ASC 或 CRM 等等。有些表很多部门都用，需要沟通约定时间一起变更。如果有同步方案，同步方案的变更也要考虑。四、操作流程 1.准备工作 a)该表的数据量以及大小，以及数据变更量（按日/时/分/秒等）b)该表的并发访问数，以及频率最高的几种 sql 的访问方式 2.执行过程 以表 T1 加字段 col2为例。T1的数据量非常大，访问频率很高。a)在 sysdba 下开启 t
49、rigger 禁用客户端自动编译功能。（可选）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 trigge
50、r 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.验证方案