Asynch CDC: Waiting For Dictionary Redo
I have come across (so far) four scenarios that show capture process “hanging” as WAITING FOR DICTIONARY REDO.
1. Wrong first_scn supplied for create_autolog_change_source: The first_scn when building the the data dictionary in the redo log via dbms_capture_adm.build does not match the first_scn when creating the change source on the downstream server. You need to supply the first_scn of the archived redo log that contains the data dictionary from the source.
Solution: (1) Drop the change source and all associated change sets and change tables. (2) Get the correct first_scn from the source by querying
|
1 2 3 |
SELECT * FROM V$ARCHIVED_LOG WHERE dictionary_begin = 'YES' ORDER BY completion_time DESC |
(3) Recreate the change source using the first_scn from the previous query
2. Source table has not been instantiated: You forgot to instantiate the source table with dbms_capture_adm.prepare_table_instantiation
Solution: execute procedure dbms_capture_adm.prepare_table_instantiation.
3. Second change source: You created a second change source that points to the same database source as your first one.
Solution: only ever use one change source per database source.
4. A second, third etc. change set was added at a later stage. You initially created a change source with just one change set. At a later stage you added an additional change set.
|
1 2 |
ALTER DATABASE REGISTER LOGICAL LOGFILE '/oracle/archdata/UDAT/usis_arch/1_12672_655855801.arc' FOR 'CDC$C_PERF_REG_SET3' |
You get the archived redo log that contains the data dictionary by querying:
|
1 2 3 |
SELECT consumer_name, name FROM DBA_REGISTERED_ARCHIVED_LOG WHERE dictionary_begin = 'YES' |
