MANAGING A STANDBY DATABASE-CRITICAL

Question

Hi All,
I had a primary database version 10.2.0.3 which i upgraded to 10.2.0.4. While upgrading the database
i turned off archiving.
After i upgraded the database and brought it up and the listener i started getting errors of
missing archive logs at the standby site.
My standby database is 10.2.0.3.
My question is
1) As i had turned archiving off at the primary site there is a gap in the archive numbers at the primary itself.
arch_1_29345_623164377.dbf
arch_1_29346_623164377.dbf
-rw-r----- 1 oracle dba 5241344 Feb 7 08:43 arch_1_29347_623164377.dbf
-rw-r----- 1 oracle dba 5241344 Feb 7 09:03 arch_1_29348_623164377.dbf
-rw-r----- 1 oracle dba 5241344 Feb 7 09:35 arch_1_29349_623164377.dbf
-rw-r----- 1 oracle dba 2781184 Feb 7 11:57 arch_1_29350_623164377.dbf
--------------------GAP------------------------AS I HAD TURNED ARCHIVING OFF----------------
-rw-r----- 1 oracle dba 5241344 Feb 7 15:57 arch_1_29561_623164377.dbf
-rw-r----- 1 oracle dba 5241344 Feb 7 15:57 arch_1_29562_623164377.dbf
-rw-r----- 1 oracle dba 5241344 Feb 7 15:57 arch_1_29563_623164377.dbf
-rw-r----- 1 oracle dba 5241344 Feb 7 15:57 arch_1_29564_623164377.dbf
I am getting errors that the standby is not in snyc with primary
when i ran query
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS
2 FROM V$MANAGED_STANDBY;
on standby database
it says i am missing sequence # 29351 which is due to the fact that there is no sequence like that on
my primary itself.
How should i resolve this gap.
Also is it a good idea to upgrade the oracle home on my standbysite to 10.2.0.4 as i have upgraded
my primary

Answer 1

Hello,
Like I said no easy way out of this situation. First option sync both usign RMAN and section option setup from the scratch (that's might not be possbile).
You can also find similar steps under oracle documentation serach for resolving gaps manually/
Here are the steps for first option, study it and make changes to according to your needs
1. On the standby database, stop the managed recovery process
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
2. On the standby database, find the SCN which will be used for the incremental backup at the primary database:
SQL> SELECT CURRENT_SCN FROM V$DATABASE;
This will used in the rman backup command at step 2.
3. In RMAN, connect to the primary database and create an incremental backup from the
SCN derived in the previous step:
RMAN> BACKUP INCREMENTAL FROM SCN <SCN from previous step>
DATABASE FORMAT '/tmp/ForStandby_%U' tag 'FORSTANDBY';
You must create this incremental backup on disk for it to be useful. When you move
the incremental backup to the standby database, you must catalog it at the
standby as described in Oracle Database Backup and Recovery Advanced User's
Guide. Backups on tape cannot be cataloged.
4. Transfer all backup sets created on the primary system to the standby system (note that there may be
more than one backup file created). For example:
SCP /tmp/ForStandby_* standby:/tmp
5. Connect to the standby database as the RMAN target, and catalog all incremental backup pieces:
RMAN> CATALOG START WITH '/tmp/ForStandby';
6. Recover the standby database with the cataloged incremental backup:
RMAN> RECOVER DATABASE NOREDO;
7. In RMAN, connect to the primary database and create a standby control file backup:
RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/tmp/ForStandbyCTRL.bck';
8. Copy the standby control file backup to the standby system. For example:
SCP /tmp/ForStandbyCTRL.bck standby:/tmp
9. Shut down the standby database and startup nomount:
RMAN> SHUTDOWN;
RMAN> STARTUP NOMOUNT;
10. In RMAN, connect to standby database and restore the standby control file:
RMAN> RESTORE STANDBY CONTROLFILE FROM '/tmp/ForStandbyCTRL.bck';
11. Shut down the standby database and startup mount:
RMAN> SHUTDOWN;
RMAN> STARTUP MOUNT;
12. If the primary and standby database data file directories are identical, skip to step
13. If the primary and standby database data file directories are different,
then in RMAN, connect to the standby database, catalog the standby data files,
and switch the standby database to use the just-cataloged data files. For
example:
RMAN> CATALOG START WITH '+DATA_1/CHICAGO/DATAFILE/';
RMAN> SWITCH DATABASE TO COPY;
13. If the primary and standby database redo log directories are identical, skip to step 14. Otherwise, on the standby database, use an OS
utility or the asmcmd utility (if it is an ASM-managed database) to remove all
online and standby redo logs from the standby directories and ensure that the
LOG_FILE_NAME_CONVERT parameter is properly defined to translate log directory
paths. For example, LOG_FILE_NAME_CONVERT='/BOSTON/','/CHICAGO/'.
14. On the standby database, clear all standby redo log groups (there may be more than
3):
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 2;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 3;
15. If you have flashback enabled:
On the standby database, restart Flashback Database:
SQL> ALTER DATABASE FLASHBACK OFF;
SQL> ALTER DATABASE FLASHBACK ON;
16. If required restart managed recovery in the standby:
On the standby database, restart recovery:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;Regards
Edited by: OrionNet on Feb 7, 2009 6:43 PM