Windowsタスクスケジューラを使用して、毎日午後11時にOracle11gデータベースのバックアップを取るようにスケジュールしました。現時点では、データベースを停止させていません。また、私のデータベースはnoarchivelogモードです。ダンプサイズは7 GBのみですが、このエクスポートの完了には11時間以上かかります。 15から16のスキーマで構成されます。これらのスキーマのみをエクスポートしても、時間がかかりすぎます。私はDB管理の初心者なので、この問題を深く掘り下げることはできません。
その時のトレースログは次のとおりです。
*** 2017-02-10 06:40:31.392
kcrfw_update_adaptive_sync_mode: poll->post current_sched_delay=275 switch_sched_delay=5635 current_sync_count_delta=14 switch_sync_count_delta=10
*** 2017-02-10 06:40:31.392
Log file sync switching to post/wait
Current approximate redo synch write rate is 4 per sec
*** 2017-02-10 06:42:02.923
kcrfw_update_adaptive_sync_mode: post->poll long#=2 sync#=6 sync=428 poll=33464 rw=4838 ack=0 min_sleep=33464
*** 2017-02-10 06:42:02.923
Log file sync switching to polling
Current scheduling delay is 111 usec
Current approximate redo synch write rate is 2 per sec
kcrfw_update_adaptive_sync_mode: poll->post current_sched_delay=0 switch_sched_delay=111 current_sync_count_delta=12 switch_sync_count_delta=6
どうしましたか?データポンプのエクスポートが遅くなる原因と、expdpを迅速に処理する方法を特定するには、何をチェックすればよいですか?
Traceコマンドを追加した後の関連するエクスポートファイルログ:
With the Partitioning, OLAP, Data Mining and Real Application Testing options
;;; Legacy Mode Active due to the following parameters:
;;; Legacy Mode Parameter: "consistent=TRUE" Location: Command Line, Replaced with: "flashback_time=TO_TIMESTAMP('2017-02-10 23:45:00', 'YYYY-MM-DD HH24:MI:SS')"
;;; Legacy Mode Parameter: "direct=TRUE" Location: Command Line, ignored.
;;; Legacy Mode has set reuse_dumpfiles=true parameter.
Starting "SYS"."SYS_EXPORT_SCHEMA_01": "sys/********@PROD AS SYSDBA" DUMPFILE=Backup_02102017.dmp LOGFILE=BakupLog_02102017.log SCHEMAS=O1,O2,O3,O4,O5,O6,O7 flashback_time=TO_TIMESTAMP('2017-02-10 23:45:00', 'YYYY-MM-DD HH24:MI:SS') ESTIMATE=STATISTICS trace=1FF0300 reuse_dumpfiles=true
Estimate in progress using STATISTICS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
. estimated "O1"."T1" 471.6 MB
. estimated "O2"."T2" 360.5 MB
. estimated "O3"."T3" 295.5 MB
. estimated "O4"."T4" 223.9 MB
. estimated "O5"."T5" 137.0 MB
. estimated "O6"."T6" 78.11 MB
Total estimation using STATISTICS method: 2.408 GB
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/SYNONYM/SYNONYM
Processing object type SCHEMA_EXPORT/TYPE/TYPE_SPEC
Processing object type SCHEMA_EXPORT/DB_LINK
Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE
Processing object type SCHEMA_EXPORT/SEQUENCE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/TABLE/RLS_POLICY/RLS_POLICY
Processing object type SCHEMA_EXPORT/TABLE/TRIGGER
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/USER_PREF_STATISTICS
. . exported "O1"."T1" 571.7 MB 16000532 rows
. . exported "O2"."T1" 369.9 MB 1512560 rows
. . exported "O3"."T1" 360.6 MB 9739091 rows
. . exported "O1"."T2" 239.0 MB 1834364 rows
. . exported "O1"."T3" 152.0 MB 967417 rows
. . exported "O1"."T4" 79.42 MB 208401 rows
. . exported "O3"."T4" 15.15 MB 119298 rows
;;; Ext Tbl Shadow: worker id 1.
. . exported "O5"."T6" 6.860 MB 35959 rows
;;; Ext Tbl Shadow: worker id 1.
.
. . exported "O6"."T1" 4.159 MB 52923 rows
. . exported "O7"."T2" 3.735 MB 69269 rows
;;; Ext Tbl Shadow: worker id 1.
ORA-31693: Table data object "O8"."PS_TXN" failed to load/unload and is being skipped due to error:
ORA-02354: error in exporting/importing data
ORA-01555: snapshot too old: rollback segment number with name "" too small
ORA-22924: snapshot too old
. . exported "O4"."T6" 750.1 KB 4911 rows
;;; Ext Tbl Shadow: worker id 1.
.
データベースがアーカイブログモードではなく、毎日ウォームバックアップを行うことで、1日分のデータを失うことは許容できると言っています。その場合は問題ありませんが、アーカイブログモードは必要ありません。データポンプのエクスポートを実行すると、ある時点でのデータベースの論理バックアップが得られます。次の質問は、データをエクスポートするのに11時間かかる場合、インポートにどのくらい時間がかかるかということです。リカバリシナリオでデータをインポートする必要がある場合は、プロセスに時間がかかることがあります。 RMANウォームバックアップを実行するだけの方が良いでしょう。
とは言っても、あなたの現在の問題について私は2つの考えを持っています。エクスポート中にデータが変更され、場合によってはロックされているプロセスはありますか?その場合、エクスポートは一貫性がなく、その日に変更されたすべてのデータが含まれません。たとえば、エクスポート中にETLプロセスを実行している場合、一部のデータはETLから取得できますが、すべてのデータは取得できません。 2番目の考えは、エンタープライズ版を使用している場合、複数のチャネルを使用していますか?複数のチャネルと圧縮を使用する必要があります。しかし、私はあなたの問題のほとんどを引き起こしているロックの問題があると思います。