I have an issue whereby our standby instance was down for a couple of days and when it came back online we found an archivelog file was missing, so recovery only happened up to a point. It appears that the archivelog was deleted therefore we are unable to continue with this standby. We are now planning to rebuild the standby database. As far as i know all of the steps originally performed need not be performed to complete this task.
1. Shutdown standby
2. Delete all datafiles & redo logs
3. Copy over datafiles to respective directories
4. Copy online logs and archivelogs to standby.
5. Create a control file for standby database
6. Startup mount standby database
7. start redo apply
I have dataguard configuration operating in maximum availability mode with a local standby db (A - lgwr sync not using real time apply) and a remote standby db (B - lgwr async). I then simualted a crash of my primary database with batch jobs running. Since the stby db A is in lgwr sync option ,all the commited data in the current online redo log has been transmitted to stby A and is present in its stby redo log (Group 2).How do I apply this stby redo log to the remote stby db.
Tried the following methods.
1.ftp the stby redo log to the remote db and tried to regiter it, got an error that it is not completely archived.
2.issued the recover standby database command and supplied the stby redo log when it asked for the sequence in the stby redo, got an error saying there is corruption in a block(tried this option multiple times ended up with the same result.)
1.create a primary database 2.duplicate a physical standby database; 3.turn on flashback on both databases. 4.record SCN xxx on physical standby database. 5.convert physical standby to logical standby (using keep identity statement) 6.flashback to logical standby to xxx 7.convert logical standby to physical standby 8.using real time apply I got errors: Fast Parallel Media Recovery enabledManaged Standby Recovery starting Real Time ApplyMRP0:
Background Media Recovery waiting for new incarnation during transient logical upgrade procedure
Errors in file /home ora/ app/ oracle/ diag/ rdbms/ ora11gr1dg/ora11gr1dg/trace/ora11gr1dg_mrp0_10120.trc:ORA-19906: recovery target incarnation changed during recoveryManaged Standby Recovery not using Real Time ApplyErrors in file /home/ ora/app/ oracle/diag/ rdbms/ ora11gr1dg/ ora11gr1dg/ trace/ora11gr 1dg_mrp0_ 10120.trc:ORA-19906: recovery target incarnation changed during recovery
Errors appears every 10 seconds. Seems MPR0 is waiting for new incarnation for a long time. So am I.Standby database incarnation:
List of Database IncarnationsDB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time-------1 1 ORA11GR1 3853851354 CURRENT 1 08/09/2013 01:02:182 2 ORA11GR1 3853851354 ORPHAN 2127877 08/28/2013 19:22:01 BGV
I have to implement Physical standby using same SID. parameters required to set on Primary and standby. Also what entries are required to do in TNS file. Recently we have faced hardware failure.
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=demodb' scope=both;
System altered.
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;
System altered.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Database altered.
SQL> recover managed standby database cancel; Media recovery complete. SQL> alter database open read only; alter database open read only * ERROR at line 1: ORA-16004: backup database requires recovery ORA-01152: file 1 was not restored from a sufficiently old backup ORA-01110: data file 1: '/u002/app/OraDB10g/stdemo/oradata/system01.dbf'
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH * ERROR at line 1:
Today, I am learning dataguard 11.2.0.1. The docs said:A. Monitoring Standby DB Application of redo logs may be monitored by issuing the SQL command:
SQL> select client_dbid, process, sequence#, status from v$managed_standby;
In the primary database, the sequence# with the status “WRITING” would refer to the current redo log sequence#In the standby database, if the status of the process MRPO is “APPLYING LOG” and the status of the process LGWR is “IDLE”, then application of redo logs is up to dateI see that that MRPO at standby is "WAIT_FOR_GAP". How do I resolve this gap.
DB1 <Primary> - Production DB2 <Physial Standby> - DR
I will need to startup my DB2 in DR segment for testing.If i perform the below, will it affect my Production DB? I need it to be up and running as well.
DR: recover managed standby database cancel; shutdown immediate; startup nomount; alter database mount standby database; recover standby database until cancel; alter database activate standby database;
I have set up a single instance standbys for rac databases. Now, I need to offload the backups from the primary on to the standbys.
1. cancel managed recovery
2. connect to target(standby) and catalog and backup the standby
3. put standby in managed recovery mode.
I think following these steps, I can restore primary(?). Now, My question is, how can I use these standby backups to clone/refresh databases? I tried it by connecting to target(primary), catalog and auxiliary but rman is using the primary backups instead of standby's to refresh the auxiliary database.
Suddenly I can't open any of my physical standby databases read only. Alert log snippet and trace files follow post. I'm running 9.2.0.1.0 on all hosts, which are running AIX 5.2. I've successfully opened all physical standby databases read only numerous times in the past. solve this? Is it possible that these standby databases cannot be switched over to primary should the need arise?
Here's how I typically open a physical standby database read only:
alter database recover managed standby database cancel; alter database open read only;
Errors in file /ora/product/9.2.0.1.0/rdbms/log/icps1_ora_27382.trc: ORA-00604: error occurred at recursive SQL level 1 ORA-16000: database open for read-only access
Is it possible to set a physical standby between 2 servers with same OS but different level ? I mean primary has windows 2003 SP1 and Standby has windows 2003 SP2. I want to know if it will work properly or not.
I have one primary database and one physical standby database on my data guard environment.
Now i want one more physical standby database in my data guard environment, meaning i want 2 physical standby. since this is a production environment, i need to take great care. However, downtime will be mandatory.
[u]init.ora for production:[/u]
pup2.__db_cache_size=6241124352 pup2.__java_pool_size=33554432 pup2.__large_pool_size=134217728 pup2.__oracle_base='/oracle/app/oracle'#ORACLE_BASE set from environment pup2.__pga_aggregate_target=5771362304 [code]......
init.ora for my first primary standby
pup2.__db_cache_size=6509559808 pup2.__java_pool_size=33554432 pup2.__large_pool_size=67108864 pup2.__oracle_base='/oracle/app/oracle'#ORACLE_BASE set from environment pup2.__pga_aggregate_target=5502926848 [code].......
I have Oracle database on Oracle 10g R2 with physical as well as logical standby database.
1) Is is necessary to take Physical standby database backup? 2) If 1) yes then Which RMAN backup is preferred?with catalog or default?How to take backup as different location? 3)how to Restore that backup?How to ensure backup is valid?
Can i setup physical standby without RMAN? I want to create a fresh single physical standby without RMAN .. If i copy all files in another system and take the controlfile from primary as alter database create controlfile for standby ... and fill all the gaps with archives.. Should it work ? i am on 10G Rhel 4 linux.. and both machines would have same config
Are there redo generate during truncate operation even my primary database is in FORCE LOGGGING mode? How this will effect on physical standby database.
which of the following views on the physical standby will us correct information on synchronization with Primary database?
For example, when I checked v$archived_gap it did not return any rows but the max(applied_seq#) on v$archive_dest_status was lagging far behind from the max(sequence#) on Primary database
select max(applied_seq#) from v$archive_dest_status where dest_id=2; select max(sequence#) from v$archived_log where applied='YES'; select * from v$archive_gap;
I am in need of a clarification regarding the file size growth in Physical Standby Database.Say we have 150 GB size of LIVE DB and we have created the same as in STDBY(150 GB).Will there be a growth in STDBY DB datafiles with respect to the LIVE DBOR only the logs are applied currently to the STDBY and the changes will only be reflecting when there is a switchover or failure scenario??
I would need to create a physical standby database for DR without using data guard. I like to know in more details like
1. What would be required to switch over to standby database in case of failure of primary database? Is it going to be a manual process each time, or can be automated using scripts? 2. How the archive logs will be applied to standby database in timely manner to sync with primary database? 3. How the Primary database will be synch with Standby database once the issue resolved on primary database. 4. Where do I get a complete script to create physical standby database on Windows platform?
i have a db's in maximum protection mode and i am trying to perform a switchover of physical standby database to primary role. but it failed., the steps followed is as follows. everything is fine with old primary site and the it is now in mounted state. When I went through the log file, I got the error message as "ORA-16072: a minimum of one standby database destination is required".the standby_archive_dest is as follows.
old primary database
SQL> alter system switch logfile; SQL> alter system archive log current;
old standby database...Disconnect the managed recovery mode in Standby database.
SQL> recover managed standby database cancel; Media recovery complete. SQL> recover standby database; AUTO SQL> exit [code]....
I have a setup where i have one physical and logical standby from a primary database. In case of switch over between primary and physical database my logical apply gets stopped. Can a logical database be applied from a physical standby ?
I am having a few issues trying to set up a physical standby database.
The primary database has a different naming structure than the standby and they are at different sites.
Physical is /var/hpsrp/ctrorp03/oradata/u0x/<DB_NAME>/<DB_UNIQUE_NAME> and standby is /var/hpsrp/drforp03/oradata/u0x/<DB_NAME>/<DB_UNIQUE_NAME>.
I have set db_file_name_convert to '<PRIMARY PATH>', '<STANDBY PATH>' times the number of paths as pairs. I have created a blank database for standby and having taken a full backup of primary with control file and standby control file.
Now I hit the issues:
The DB incarnation numbers are different. When I try and do a normal restore e.g. set dbid, restore controlfile; mount; it fails as it is trying to find files in the primary structure and not standby structure. When I try renaming via set newname or auxname it can't find files to restore I guess due to the incarnation id's. If I set the incarnation id and try to restore backup it fails as the incarnation id's don't match.
I have tried looking through various forums and the documentation but can't find a solution, probably can't see the wood for the trees though as there is so much.
We are planning to create physical standby database for 4-node RAC primary to a 4-node RAC standby using Active database duplicate with ASM and OMF
1. while using active database duplicate, do we need to set cluster_database=FALSE in spfile clause and create standby,next change it back to TRUE at standby. Or we don't need to touch it. And also do we need to include instance_number parameter 2. We are using OMF, can we use log_file_name_convert parameter in spfile clause of duplicate. Documentation says log_file_name_convert cannot be used if standby is going to have OMF. Because we have 5 groups for each thread, which are on 5 different disk groups. When standby is created all the logs are created in only one disk group pointed by db_create_online_file_dest_1. 3. To enable force logging at primary do we need to shutdown the database?
I am using Oracle RAC 11.2.0.3 as primary database, we are going to start using Oracle data guard. So I am designing my infrastructure and planing to use Oracle 11.2.0.3 Single instance as my physical stand by database.
My question is it feasible to have my standby database as single instance while the primary is RAC? is it feasible to build my Oracle single instance standby database from the RMAN backup of the RAC primary database? Is there any restrictions (or any points to be taken into consideration) since my primary database is RAC while the physical standby is Oracle single instance?
in the below link
[URL].......
it was mentioned that primary can be RAC or single and same for standby, but my question is it feasible to have primary as RAC while standby as single instance? or it should be like each others?
The primary database can be either a single-instance Oracle database or an Oracle Real Application Clusters (RAC) database. Similar to a primary database, a standby database can be either a single-instance Oracle database or an Oracle RAC database.
I have set the physical standby database to open read mode for a short while.
according to [URL] in order to set db in for from open read-only to applying redo data
Quote:
To change the standby database from being open for read-only access to performing Redo Apply:
Terminate all active user sessions on the standby database. Restart Redo Apply. To start Redo Apply, issue the following statement:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> DISCONNECT FROM SESSION;
To enable real-time apply, include the USING CURRENT LOGFILE clause:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> USING CURRENT LOGFILE;
this is what happen
SYS@ngdr> alter database recover managed standby database disconnect session; alter database recover managed standby database disconnect session * ERROR at line 1: ORA-00274: illegal recovery option SESSION SYS@ngdr> alter database recover managed standby database using current logfile;
okay since I encountered the illegal recovery options session, I decided to use alter database recover managed standby database using current logfile; now the session seems to be hanging forever.
