imp过程如何减少redo产生

显示全部楼层 · 2006-4-18 13:25:09

imp的过程在Oracle内部是一个大量insert/*+NESTED_TABLE_SET_REFS+*/into的过程(通过oradebug setospid &pid 跟踪imp对应操作系统进程得到),如果dmp文件中已经写死了insert/*+NESTED_TABLE_SET_REFS+*/
into table_name ... ... 这样的插入语句,也就意味着即使设置table nologging属性,imp不可避免的会产生大量redo.
我这里并行imp操作 insert会在2000条/秒*6并行进程数=12000条/秒,(操作系统命令topas可以查到每秒钟磁盘写入为12M左右)
也就是说每秒钟会产生12000条记录insert的redo。
我们系统单个redo member为512M 每个节点有6个redo group .redo file打在裸设备.
但是由于并发高,每三分钟就会切换一次redo log,造成imp过程中产生大量log file sync和redo相关的等待事件.
Sqltrace的结果显示: 两分钟的imp操作会有一半时间在等log file sync.
由于权限问题我不能拿到.trc文件.

如何能够减少imp过程中redo的产生，或者说imp由于内部原理上的限制就不可能做到这一点.
而我们只能从存储角度解决，比如把单个redo member重新打成1G到2G等.但这样又会使恢复存在问题.
机器配置: AIX P590 6C 12G
Oracle关键参数:
Sga_max
7G
db_cache_size 4G
shared_pool_size2G
sort_area_size8388608
Large_pool
256M
log_buffer
20480000
Processes
600
open_cursors
3000
dml_locks
10000
pga_aggregate_target3G
DB_WRITER_PROCESSES 参数值设置为 2
imp脚本形如
imp xxx/xxx tables=xxx file=xxx log=xxx buffer=204800000 commit=n ignore=y indexes=n
我测试commit=y redo产生会更多

千问 · 2006-4-18 13:25:09

导入时用noarchive log模式。。。

千问 · 2006-4-18 13:25:09

最初由 xzh2000 发布
[B]导入时用noarchive log模式。。。 [/B]
是的就是在noarchive log下做的测试.
目前启用6个session并行做倒入:
通过sqltrace

session 1下21.7 秒倒入CFG_ATTR_MODIFY_HISTORY条记录39956
CFG_ATTR_MODIFY_HISTORY
SQL> select 39956/21.7 from dual;
39956/21.7
----------
1841.29032

session 2
TB1560
SQL> select 84781/22.45 from dual;
84781/22.45
-----------
3776.43653

session 3
CFG_ATTR_MODIFY_HISTORY
SQL> select 85719/25.93 from dual;
85719/25.93
-----------
3305.78481
session 4
CFG_ATTR_MODIFY_HISTORY
SQL> select 51502/21.99 from dual;
51502/21.99
-----------
2342.06457
session 5
CFG_ATTR_MODIFY_HISTORY
SQL> select 61258/26.62 from dual;
61258/26.62
-----------
2301.2021
session 6
CFG_ATTR_MODIFY_HISTORY
SQL> select 105135/52.97 from dual;
105135/52.97
------------
1984.80272

SQL> select 1841.29032+3305.78481+2342.06457+2301.2021+1984.80272 from dual;
1841.29032+3305.78481+2342.06457+2301.2021+1984.8三0272
-----------------------------------------------------

11775.1445

SQL> select 1841.29032+3305.78481+2342.06457+2301.2021+1984.80272 from dual;
1841.29032+3305.78481+2342.06457+2301.2021+1984.80272
-----------------------------------------------------

11775.1445
SQL> select 11775.1445*60 from dual;
11775.1445*60
-------------
706508.67
SQL> select 350000000/706508.67 from dual;
350000000/706508.67
-------------------
495.393779
SQL> select 495.393779/60 from dual;
495.393779/60
-------------
8.25656298
这么一算这张3.5亿的表需要8.25656298个小时太长了

千问 · 2006-4-18 13:25:09

这张3.5亿的表150G左右

千问 · 2006-4-18 13:25:09

最初由 foreverlee 发布
[B]这张3.5亿的表150G左右 [/B]
呵呵，150g,导起来确实比较不爽，用mv+mvlog进行刷新也应该可以的。

千问 · 2006-4-18 13:25:09

Transport Tablespaces吧

千问 · 2006-4-18 13:25:09

老和尚我一开始想用mv来着但是人家甲方不让用
如果用mv
我能控制刷新的负载程度么？就是说能控制"应用mvlog刷新的work load"么？

千问 · 2006-4-18 13:25:09

最初由 foreverlee 发布
[B]
明白这招但现在牵扯到字符集转换 zhs16gb2310到zhs16gbk
这两个字符集不是严格子集关系
.
所以这次做这个库的数据迁移比较苦恼.
csscan的的结果也很不理想
[PHP]

[Data Dictionary Conversion Summary]
Datatype
ChangelessConvertibleExceptional
Total
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2
1,098,301
0
12001,098,301
CHAR
0
0
0
0
LONG
111,183
0
0
111,183
CLOB
0
134
0
134
--------------------- ---------------- ---------------- ---------------- ----------------
Total
1,209,484
134
1200 1,209,618

[Application Data Conversion Summary]
Datatype
ChangelessConvertibleExceptional
Total
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2
2,016,893,449
369 23,8942,016,917,712
CHAR
3,024,885,381
0
03,024,885,381
LONG
49
0
0
49
CLOB
0
0
0
0
--------------------- ---------------- ---------------- ---------------- ----------------
Total
5,041,778,879
369 23,8945,041,803,142
[/PHP] [/B]

千问 · 2006-4-18 13:25:09

最初由 foreverlee 发布
[B]
明白这招但现在牵扯到字符集转换 zhs16gb2310到zhs16gbk
这两个字符集不是严格子集关系
.
所以这次做这个库的数据迁移比较苦恼.
csscan的的结果也很不理想
[PHP]

[Data Dictionary Conversion Summary]
Datatype
ChangelessConvertibleExceptional
Total
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2
1,098,301
0
12001,098,301
CHAR
0
0
0
0
LONG
111,183
0
0
111,183
CLOB
0
134
0
134
--------------------- ---------------- ---------------- ---------------- ----------------
Total
1,209,484
134
1200
1,209,618

[Application Data Conversion Summary]
Datatype
ChangelessConvertibleExceptional
Total
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2
2,016,893,449
369 23,8942,016,917,712
CHAR
3,024,885,381
0
03,024,885,381
LONG
49
0
0
49
CLOB
0
0
0
0
--------------------- ---------------- ---------------- ---------------- ----------------
Total
5,041,778,879
369 23,8945,041,803,142
[/PHP] [/B]

千问 · 2006-4-18 13:25:09

由于csscan报告中存在大量 Data Dictionary Conversion 的Exception
所以就不能使用Oracle内部命令修改字符集.
所以目前只能采用exp/imp
exp出450G的dmp 现在要imp 就会产生redo的问题
而且现在时间很紧张只能停库12小时.