初步分析是表的统计信息不对,造成了insert这个表的时候的执行计划加上了/*+ RESTRICT_ALL_REF_CONS */
的hint,所以需要先收集下这个表的统计信息,让执行计划走正确。
2.也先不要着急收集统计信息,可以先看下实际状况再说。
(1)操作系统的iostat,关注下面一些:
iostat -d -k 1 10 #查看TPS和吞吐量信息(磁盘读写速度单位为KB)
iostat -d -m 2 #查看TPS和吞吐量信息(磁盘读写速度单位为MB)
iostat -d -x -k 1 10 #查看设备使用率(%util)、响应时间(await) iostat -c 1 10 #查看cpu状态
util是否达到100、await<5
(2)数据库这张表的统计信息情况
select num_rows, blocks, last_analyzed from dba_tables where owner_name='xxx' and table_name = 'xxx';
3.收集统计信息步骤
(1)关复制进程
(2)使用sql收集,收集的时候注意采样率。大表采30%左右合适。以及并行度。
BEGIN
DBMS_STATS.GATHER_TABLE_STATS(ownname => 'xxx',
tabname => 'xxx',
estimate_percent => 30,
method_opt => 'for all columns size repeat',
no_invalidate => FALSE,
degree => 8,);
END;
//注意直观图选项。
(3)开启复制进程,可以查看ogg的err.log中的信息。看下rba等追上来没有。
4.中途发生个datapump导数据的问题,发现在导出时卡在导统计信息那一块了。
select s.EVENT,s.MODULE,s.PROGRAM from vsession s where s.MODULE='Data Pump Worker';
select program,sid, event,blocking_session from vsession where program like '%DW%';
SELECT
bs.username "Blocking User",
bs.username "DB User",
bs.SID "SID",
bs.serial# "Serial#",
bs.sql_address "address",
bs.sql_hash_value "Sql hash",
bs.program "Blocking App",
bs.machine "Blocking Machine",
bs.osuser "Blocking OS User",
bs.serial# "Serial#",
ws.username "Waiting User",
ws.SID "WSID",
ws.program "Waiting App",
ws.machine "Waiting Machine",
ws.osuser "Waiting OS User",
ws.serial# "WSerial#",
wk.TYPE lock_type,
hk.lmode mode_held,
wk.request mode_requested,
TO_CHAR(hk.id1) lock_id1,
TO_CHAR(hk.id2) lock_id2,
hk.BLOCK blocking_others
FROM vlock hk, vsession bs, vlock wk, vsession ws
WHERE hk.BLOCK = 1
AND hk.lmode != 0
AND hk.lmode != 1
AND wk.request != 0
AND wk.TYPE(+) = hk.TYPE
AND wk.id1(+) = hk.id1
AND wk.id2(+) = hk.id2
AND hk.SID = bs.SID(+)
AND wk.SID = ws.SID(+)
AND (bs.username IS NOT NULL)
AND (bs.username <> 'SYSTEM')
AND (bs.username <> 'SYS')
ORDER BY 1;
5.清理分区表时使用truncate,要带上update index,否则全局索引失效。
drop分区也会造成全局索引失效。