A database running in ARCHIVELOG mode is designated as the primary database for an application. One or more standby databases, accessible via Oracle Net, provide for failover capabilities. Data Guard automatically transmits redo information to the standby databases, where it is applied, keeping the standby database transactionally consistent.
Two types of standby databases
Physical = has the same physical structure as primary database. Block-for-block copy of the primary database. Can be used for database backups in place of the primary database. During disaster recovery, the physical standby looks exactly like the primary database it replaces.
Logical = may have different internal structures (such as additional indexes for reporting or a different tablespace layout). Can more easily be used to support specific reporting requirements that would otherwise burden the primary database.
Data Protection Modes
Maximum Protection = "no data loss". At least one standby location must be written to before a transaction commits in the primary database. The primary database shuts down if the standby database's log location is unavailable.
Maximum Availability = at least one standby location must be written to before a transaction commits in the primary database. If the standby location is not available, the primary database does not shut down.
Maximum Performance = (default) Transactions can commit before their redo information is sent to the standby locations. Commits in the primary database occur as soon as writes to the local online redo logs complete. Writes to the standby locations are handled by the ARCn processes by default (up to 30 archiver processes in Oracle Database 12c).
To Create a Physical Standby Database
Backup up the Primary Database's Datafiles
Create a Control File for the Standby Database (standby controlfile)
Create an Initialization Parameter File for the Standby Database
Copy the Database Files to the Standby Database Location
Configure the Standby Database Environment (password file, sqlnet.ora, tnsnames.ora, copy encryption wallet, spfile)
Start the Standby Database (startup mount; begin the redo application process - alter database recover managed standby database)
Verify the Configuration (alter system switch logfile)
Real-Time Apply
By default, redo data is not applied to a standby database until the standby redo log is archived. When using real-time apply feature, redo data is applied to the standby database as it is received, reducing the time lag between the databases and potentially shortening the time required to fail over the standby database.
Alter database recover managed standby database using current logfile disconnect from session;
For Logical standby database
Alter database start logical standby apply immediate;
Gaps in Archive Log Sequences
If the standby database has not received on or more archived logs generated by the primary database, it does not have a full record of the transactions in the primary database. Oracle Data Guard detects the gap in the archive log sequence automatically; it resolves the problem by copying the missing sequence of log files to the standby destination.
To determine if there is a gap in your physical standby database, query the V$ARCHIVE_GAP view. For each gap, that view will report the lowest and highest log sequence number of the set of logs missing from the standby database. If for some reason Oracle Data Guard does not copy the logs, copy the logs manually to the physical standby database and register them using ALTER DATABASE REGISTER LOGFILE filename command, then start the redo apply process. After logs have been applied, check the V$ARCHIVE_GAP view to see if there is another gap to resolve.
Comments