DBA Maestro - Helpful DBA tips

I encountered an issue where standby fell out of sync with primary.  When trying to place the standby in auto recovery again, I received the following error in the alert log: ORA-00600: internal error code, arguments: [3020], [41], [41955], [172008419], [], [], [], [], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 41, block# 41955, file offset is 343695360 bytes) ORA-10564: tablespace SYSTEM ORA-01110: data file 41: '+DATA/spl1adg/datafile/system.317.766442357' ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 15 After researching this issue in metalink, the proposed solution was to rebuild the standby.  After pondering over this for a bit, I did the following which allowed me to remedy the issue: 1. Took the datafile offline on standby. SQL> alter database datafile 41 offline drop; 2. Took fresh backup of the datafile in question on primary. RMAN> backup as backupset datafile 41; 3. Copie...

A cascaded standby database is a standby database that receives primary database redo indirectly, from a cascading physical standby database, rather than directly from a primary database. Cascading can reduce network bandwidth consumption by eliminating duplicate redo transmission over network links that are shared by more than one standby database. I used this method after I successfully created a physical standby from a backup that was running against another physical standby; all RMAN backups are configured to run against the physical standby.  I needed to get some archivelogs to synch up primary with new standby; the archivelogs were no longer present on primary but were still located at the physical standby location. Therefore, to configure it so that I could successfully synchronize the new standby with primary, I did the following: Physical standby Database: db_unique_name = prmy_stb alter system set log_archive_config='DG_CONFIG=(prmy,prmy_stb,cscd_stb)'...