阿里巴巴数据库操作手册

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; d) 标准赋权脚本：

GRANT SELECT ON seq_tablename to username; 3. 验证方案

a) @dbcheck 检查是否有失效对象

b) 通知应用验证是否可以正常访问sequence

五、 核心对象风险

高并发对象重建时短暂不可访问；

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

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, distcnt => 1000000, 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‘, numrows => 1000000, 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; /

fromuser=zhangzj

touser=zzzzzz

tables=yz_ongimt_jingtzt file=exp0208.dmp log=imp0208.log

buffer=100000 –大小控制导入速度的，设置过大会导致日志产生很快

imp parfile=imp_ws0208.par –进行数据导入

注意上面的fromuser和touser。如果将表导入到两个schema:zzzzzz,yyyyy 需要按照这种格式配置参数：

fromuser和touser一一对应，即使导出时只有一个schema. fromuser=zhangzj,zhangzj touser=zzzzzz,yyyyy 1 2

b) exp导出数据时，检查exp的日志，如果报错，一般是参数配置错误，参考官方文档调整参数。

c) imp导入数据过程，需要监控下数据库事务和日志产生速度。 d) 对导入的表收集统计信息。

3. 验证方案

对比exp、imp的日志，确认导出导入数据量是否一致。并在数据库上检查数据量。 比如上面的数据迁移，检查数据量跟日志显示是否一致。

select count(*) from zzzzzz.yz_ongimt_jingtzt;

跨schema或者数据库迁移数据时，除检查日志外，还需要检查源和目标的对象数据量、 是否有失效对象。

select object_type,count(*) from dba_objects where owner=‘源schema‘; select object_type,count(*) from dba_objects where owner=‘目标schema‘; select * from dba_objects where status<>‘VALID‘ and owner=‘ 目标schema‘;

五、 核心对象风险

由于核心表访问、变更频繁，不宜直接使用imp对核心表大量导入数据。

六、 回退方案

exp对应用无影响，不需要回退。

imp后可能数据有误，需要进行回退操作。

如果目标表本来就是空表，跟应用确认后，直接清空即可。

如果目标表原有数据，跟应用确认是否使用原有备份数据进行恢复。若需要，先exp备份当前数据，然后清空再导入前面的备份数据。

19-数据迁移工具之sqlldr

一、 目的

说明使用sqlldr进行数据迁移的前置条件、操作步骤，降低对对应用造成的影响及避免故障

二、 适用范围

l 所有线上库：数据迁移，数据初始化，以及应用几乎只读的表

三、 风险评估

使用sqlldr迁移数据时，普通方式加载数据本质是insert，对表的结构影响不大。使用需要rows控制事务大小。风险主要在使用direct方式加载上：

l 默认情况下会同时维护索引，如果设置参数SKIP_INDEX_MAINTENANCE=true，则不会维护索引。导致索引处于处于unusable状态。

l direct方式加载数据时，表上unique约束始终有效，unique约束的校验是在表加载数据完毕后rebuild索引时完成的，如果索引build时发现有违反unique约束的数据，会导致该索引处于unusable状态。

l direct方式加载数据时，索引结构相当于rebuild，对临时空间需求比较大。如果空间不足，会导致索引处于unusable状态。

l 如果数据空间不足导致加载报错，也会导致索引处于unusable状态。

l 如果启用savepoint机制，sqlldr进程被中断失败时，会使索引处于unusable状态。

l direct方式加载数据时会自动disable表上的触发器和约束(check、外键)，在加载完成再次enable，由于enable时需要获得一个互斥的表锁，如果获得表锁失败，会导致无法成功enable。 l 表上的约束如果以enable novalidate方式启用时，direct方式加载数据时不会校验该约束，可能导致非法数据出现。

四、 操作流程

1. 准备工作

a) sqlldr不支持cluster表，及有global index的分区表。检查加载数据的目标表结构，尤其是触发器和约束，以及表上索引状态。如果有处于unusable的索引，需要评估是否rebuild生效，或者删除。

SELECT INDEX_NAME, STATUS FROM USER_INDEXES WHERE TABLE_NAME = ?tablename‘ and status<>?VALID‘;

SELECT INDEX_NAME, PARTITION_NAME, STATUS FROM USER_IND_PARTITIONS WHERE STATUS <> ?VALID‘;

b) 如果有enable novalidate方式启用的约束，需要提前评估是否再对该约束enable validate

一次。

select constraint_name, status, validated from user_constraints

where table_name = upper(?tablename‘);

enable validate约束:该操作会锁表，需要在业务低峰期处理

alter tablename enable validate constraint constraint_name;

c) 估算表数据需要的空间和加载过程索引需要的临时空间大小。索引需要的临时空间计算方法：

1.3*(number_of_rows)*( 10 + sum_of_column_sizes + number_of_columns ) 一般情况下是1.3倍，安全起见可以使用2倍系数【参考】

d) 根据加载的文本文件内容编写controlfile，sqlldr命令使用的各个参数。SKIP_INDEX_MAINTENANCE 这个参数默认值是false，不建议修改。 e) 检查表上是否有活动事务 select *

from v$locked_object a, dba_object b where a.object_id = b.object_id

and b.owner = ‘schema‘

and b.object_name = ‘tablename‘;

2. 执行过程

如果目标表是已存在数据，跟应用确认后，可以先进行exp导出备份，以防后面需 要回退。

这里给出一个示例，从算法提供的文本文件加载数据。

先根据需求编辑的control文件：‘-?后面是参数说明，实际使用时去掉 more ld_ws.ctl load data

infile ?totaldata_ae.txt‘

append into table X_table_name (

id sequence(200000000,1), –这里产生表id列的数据，自增长。2亿是起始值，1代表步长 GMT_CREATE ―sysdate‖, –对gmt_create使用sysdate填充，下同 GMT_MODIFIED ―sysdate‖,

PRODUCT_ID POSITION(1) CHAR TERMINATED BY ?\\^‘ ―TO_NUMBER(:PRODUCT_ID)‖, –这里开始读取正式数据，注意position(1)，指定从文本各行的第一个字符开始。如果不指定product_id数据的起始位置，上面的gmt_create,gmt_modified列数据初始化会报错 group_ID TERMINATED BY ?\\^‘, FINGER_PRINT TERMINATED BY ?\\^‘, IMG_VERSION TERMINATED BY ?\\^‘, IMG_URL TERMINATED BY ?\\^‘, COMPANY_ID TERMINATED BY ?\\^‘, OFFLINE_DATE TERMINATED BY ?\\^‘

―to_number(:OFFLINE_DATE)/3600/24+to_date(‘1970-01-01 00:00:00′, ?yyyy-mm-dd hh24:mi:ss‘)‖,–这里时间数字转成日期格式 grade TERMINATED BY ?\\t‘ ―TO_NUMBER(:grade)‖

)

–加载数据

sqlldr userid=username/password@dbname direct=true control=ld_ws.ctl log=ld_ws.log bad=ld_ws.err 1

2

ld_ws.err保存不符合上面control文件格式的数据

3. 验证方案

a) 检查sqlldr的日志，确认是否报错，以及非法的数据。并在数据库上检查数据量和导入的数据量是否一致。

比如上面的数据迁移，检查数据量跟日志显示是否一致。 select count(*) from zzzzzz.x_table_name;

b) 检查是否有处于unusable状态的索引及索引分区，如果有，rebuild该索引。 SELECT INDEX_NAME, STATUS FROM USER_INDEXES WHERE TABLE_NAME = ?tablename‘ and status<>?VALID‘;

SELECT INDEX_NAME, PARTITION_NAME, STATUS FROM USER_IND_PARTITIONS

WHERE STATUS <> ?VALID‘;

c) 检查是否存在disable状态约束和触发器，如果存在手工enable select trigger_name, status from user_triggers where table_name = ?tablename‘ and status <> ?ENABLED‘;

select constraint_name, status from user_constraints where table_name = ?tablename‘ and status <> ?ENABLED‘;

五、 核心对象风险

由于核心表访问、变更频繁，不宜直接使用sqlldr对核心表大量导入数据。需要先导入一个同构的中间表，再把数据分批insert到正式表。

六、 回退方案

sqlldr加载后可能数据有误，需要进行回退操作。

如果目标表本来就是空表，跟应用确认后，直接清空即可。

如果目标表原有数据，跟应用确认是否使用原有备份数据进行恢复。

20-固定执行计划-baseline

一、 目的

在遭遇执行计划不稳定或者执行计划错误的情况下，通过baseline来固定SQL执行计划以确保执行计划稳定性、提高性能。baseline是oracle 11G提供的稳固sql执行计划的功能，是spm功能的一部分。本人更建议通过10G的sql profile来实现baseline的这些功能，因为baseline用起来稍微繁琐点，sql profile的使用规范请参照我写的其他文档。

二、 适用范围

l 执行计划走错，导致查询性能降低，数据库压力飙升 l 执行计划不稳定，有走错的风险。

l 执行计划错误，需要增加hint，应用来不及修正发布，临时用baseline固定。

l 数据库升级，可以在源库生成baseline，然后把baseline迁移至新库，这样能确保升级前后执行计划性能不变。详情参阅ORACLE 11G SPM部分。

三、 风险评估

l outline、sql profile、baseline这三种固定执行计划的方式都依赖于SQL的文本，如果SQL文本变了，就失去了固定的作用。因此对于并发量非常大、应用修改代码容易的SQL，应该确保通过添加hint的方式来矫正执行计划，以免通过baseline方式修正执行计划的SQL文本变化，导致baseline失效，查询计划走错，导致数据库压力飙升。

l 在做数据迁移过程中，如果原系统中存在已经建立过的baseline，请不要在数据迁移过程中忘记在新系统中安装他们。

l 需要注意，表对象被删除时，baseline并不会被删除，当然这个应该也不是很严重的问题。如果想要删除baseline，必须采取显式的用命令删除。

l baseline是依赖sql文本来进行匹配的，这意味着一份SQL计划基线可能同时被用于两张有相同名称但分属于不同schema下的表。

四、 操作流程

1）FUNCTION LOAD_PLANS_FROM_CURSOR_CACHE RETURNS BINARY_INTEGER Argument Name Type In/Out Default? —————————— ———————– —— ——–

SQL_ID VARCHAR2 IN

PLAN_HASH_VALUE NUMBER IN DEFAULT FIXED VARCHAR2 IN DEFAULT ENABLED VARCHAR2 IN DEFAULT 2）FUNCTION LOAD_PLANS_FROM_CURSOR_CACHE RETURNS BINARY_INTEGER Argument Name Type In/Out Default?

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