Deconstruct Streams LCR

At times while resolving streams replication issues, it might be faster to generate individual queries associated with an failed LCR instead of relying on routines provided by the DBMS_APPLY_ADM package.In addition the script attached to this blog can be used to clear LCR back log in parallel as long as the source commit order is maintained.

The driving query in the anonymous block is as follows and chose an appropriate filter to handle your issue
for currec in (
 select local_transaction_id, message_count
 from dba_apply_error
  where -- local_transaction_id = '70.18.2231436' --# Use this filter to handle one LCR at a time
    -- ERROR_MESSAGE LIKE '%DBOR_USERS%' --# Use this filter to handle LCR which have errors in the same table
    -- error_creation_time >= to_timestamp('18-MAR-2013 08:00:00','dd-MON-RRRR HH24:MI:SS')  --#  Use the following two to filter on a date range.
    --and error_creation_time <  to_timestamp('18-MAR-2013 10:00:00','dd-MON-RRRR HH24:MI:SS')
ORDER BY source_commit_scn)



Note: Prior to executing the SQL generated by the script, you will have to resolve the underlying issue that led to the Apply failure.

Usage

1. Copy the script to the target database
2. Make the necessary updates to the driving query filter to target specific errors
3. Log on to the database as sys or streams_admin user.
4. Start a spool file. e.g. spool somefilename.sql
5. run the script as a anonymous block
6. The generated output can be executed without any changes.

Notes

1. Should you wish to remove trailing spaces in the output file, then use the following series of commands
 cat [spooled_file_name] | sed -e "s/ \{1,\}$//" > new_file_name



Download the script from here.


Comments

Post a Comment

Popular posts from this blog

Recover Standby database from ORA-00332: archived log is too small

When a standby database crashes and upon instance recovery gets stuck with error ORA-00332: archived log is too small - may be incompletely archived, then following set of actions must be carried out to restore the service. 1. Check that the instance is in MOUNTED. (select status from v$instance) 2. If not mounted, then start the database in mounted mode SQL> startup mount; 3. Search the alert log to identify the archive log that is corrupt,  Sample lines from the alert log Errors in file /u01/app/oracle/diag/rdbms/fxfgsby/FXFGSBY1/trace/FXFGSBY1_ora_19463.trc: ORA-00332: archived log is too small - may be incompletely archived ORA-00334: archived log: '+FLASH/fxfgsby/archivelog/2013_08_19/thread_1_seq_173831.5998.823855747' Shutting down recovery slaves due to error 332 4. In the above example, the corrupt log file belongs to Thread#=1 and Sequence#=173831 5. Log on to the Primary database cluster and take a copy of the file from ASM onto the local file system. Not...
Read more

Check Active Dataguard Replication Status

In order to check if ADG is up-to-date, one has to tail the alert log on both the Primary and Physical Standby databases, followed by a manual check to look for the log status of (in-transit) against each of the threads. While this method is perfect it can be bit tedious to perform. You can now do the same using one of the attached SQL from the Primary database. Deployment and usage steps - Open a vi editor on the Primary database. - Copy of the below SQL into the editor - Complete the  database link creation command based on the database    you are checking. - Save the text file as check_adg_status.sql - execute the sql file as sys user. e.g. sqlplus -s  / as sysdba @check_adg_status.sql  Note : These commands cannot be run from the Physical standby as the query relies on using a temporary database link that cannot be created on a read-only database. Troubleshooting 1. Some database clusters may report the following error when invoked   ...
Read more

Top CPU consuming oracle sessions

Use the shell script from  here  to obtain the details of the Oracle sessions using high CPU.  Usage: Log in as oracle user and navigate to the folder where the script has been copied into. Do not forget to grant execute permissions to the script prior to invoking it. $ ./top_oracle_sessions.sh [cpu_threshold]  e.g.1  $ ./top_oracle_sessions.sh 90       This will gather information if overall CPU usage is above 90% e.g.1  $ ./top_oracle_sessions.sh        This will gather information if overall CPU usage is above 50%. This is the default setting. Notes: Use the attached script to obtain the details of the Oracle sessions using high CPU. The script works by follows Takes 2 snapshots using Linux "top" command with a interval of 2 seconds between snaps Uses the data from the second snapshot to determine if the overall CPU usage is above a set threshold. The threshold is a conf...
Read more