Preparing the Primary Database for Standby Database Creation: Before we create a standby database you must first ensure the primary database is properly configured. Enable Force logging 2. Create a password File 3. Create standby Redo log file groups 4. Set Primary Database Initialization Parameters 5.
Hi, I will continue to tell you Oracle dataguard configuration and installation in this article. Read first article before this. Leave a Reply Cancel reply. October 24, October 9, Popular Category. November 23, Privacy Policy Terms of Use Disclaimer. You need to submit your details to download the file. Linux Admin Details. Linux - Shell Scripting Training Details. Switchover will not begin until the standby database applies all of the archived redo log files. By lifting the delay using the NODELAY keyword, you allow the standby database to proceed without waiting for the specified time interval to pass before applying the archived redo log files.
Step 2 Stop read or update activity on the primary and standby databases. You must have exclusive database access before beginning a switchover. See Oracle Database Administrator's Guide for more information about managing users. Step 3 Switch the primary database to the physical standby role. Step 4 Shut down and start up the former primary instance, and mount the database. Step 5 Switch the original standby database to the primary role.
Step 6 Shut down and restart the new primary database instance. On the primary database, execute the following SQL statement for the destination that experienced the network failure. The query results show there are errors archiving to the standby database, and the cause of the error is TNS:no listener. You should check whether or not the listener on the standby site is started.
If the listener is stopped, then start it. Step 2 Prevent the primary database from stalling. If you can not solve the network problem quickly, and if the standby database is specified as a mandatory destination, try to prevent the database from stalling by doing one of the following:.
When the network problem is resolved, you can change the archive destination from optional back to mandatory:.
Step 3 Archive the current online redo log file. On the primary database, archive the current online redo log file:.
When the network is back up again, log apply services can detect and resolve the archive gaps automatically when the physical standby database resumes Redo Apply. Even though the user specifies the clause, a redo record is still written to the online redo log file. However, there is no data associated with this record.
This can result in log application or data access errors at the standby site and manual recovery might be required to resume applying log files. When the archived redo log file is copied to the standby site and applied to the physical standby database, a portion of the datafile is unusable and is marked as being unrecoverable. To recover after the NOLOGGING clause is specified, you need to copy the datafile that contains the missing redo data from the primary site to the physical standby site.
Perform the following steps:. Step 1 Determine which datafiles should be copied. Step 2 On the primary site, back up the datafile you need to copy to the standby site.
Step 3 Copy the datafile to the standby database. Copy the datafile that contains the missing redo data from the primary site to location on the physical standby site where files related to recovery are stored. Step 4 On the standby database, restart Redo Apply. You might get the following error messages possibly in the alert log when you try to restart Redo Apply:. If you get the ORA error and Redo Apply does not terminate automatically, you can cancel recovery by issuing the following statement from another terminal window:.
These error messages are returned when one or more log files in the archive gap have not been successfully applied. If you receive these errors, manually resolve the gaps, and repeat Step 4. See Section 5. If you performed unrecoverable operations on your primary database, determine if a new backup operation is required by following these steps:.
Issue the following SQL statement on the primary database to determine if you need to perform another backup:. If the query in the previous step reports an unrecoverable time for a datafile that is more recent than the time when the datafile was last backed up, then make another backup of the datafile in question. An archive gap is a range of archived redo log files created whenever you are unable to apply the next archived redo log file generated by the primary database to the standby database.
This section contains the following topics:. An archive gap can occur whenever the primary database archives the current online redo log file locally, but the redo data is not archived at the standby site. Because the standby database requires the sequential application of log files, media recovery stops at the first missing log file encountered. One example of an archive gap occurs when you create the standby database from an old backup. For example, if the standby database is made from a backup that contains changes through log file , and the primary database currently contains changes through log file , then the standby database requires that you apply log files to Another typical example of an archive gap occurs when you generate the standby database from a hot backup of an open database.
At time t , while you are busy configuring the network files, primary archives log files, sequences 4 and 5. Archived redo log file sequences 4 and 5 are now part of an archive gap, and these log files must be applied to the standby database.
You might be required to shut down the standby database to resolve maintenance issues. Start the standby databases and listeners before starting the primary database. Shut down the primary database before shutting down the standby database. If you violate either of these two rules, then the standby database is down while the primary database is open and archiving. Consequently, the Oracle database can create an archive gap.
If you maintain a Data Guard environment, and the network goes down, the primary database might continue to write to disk but be unable to send redo to the standby site. In this situation, archived redo log files accumulate as usual on the primary site, but the standby database is unaware of them. Section 5. If an archive gap exists, the output of the query specifies the thread number and log sequence number of all log files in the archive gap.
If there is no archive gap for a given thread, the query returns no rows. Use the following query to determine the names of the archived redo log files on the local system that must be copied to the standby system that has the gap:.
If the standby database is on the same site as the primary database, or the standby database is on a remote site with a different directory structure than the primary database, the path names for the log files on the standby site cannot be the same as the path names of the log files archived by the primary database.
Before transmitting the redo data to the standby site, determine the correct path names for the archived redo log files at the standby site. To copy log files in an archive gap to the standby site. Review the list of archive gap log files that you obtained earlier.
For example, assume you have the following archive gap:. If a thread appears in the view, then it contains an archive gap. You need to copy log files from threads 1, 2, and 3. Determine the path names of the log files in the archive gap that were transmitted by the primary database. After connecting to the primary database, issue a SQL query to obtain the name of a log file in each thread. For example, use the following SQL statement to obtain filenames of log files for thread For example, you discover the following:.
These parameter settings determine the filenames of the archived redo log files at the standby site. For example, enter the following copy commands to copy the archive gap log files required by thread If these parameter values are the same, then you do not need to perform this step. See also Section 8.
After recovering the available log files, the Oracle database prompts for the name of a log file that does not exist. For example, you might see:. The following error messages are acceptable after recovery cancellation and do not indicate a problem:.
After you finish manually applying the missing log file, you can restart log apply services on the standby database, as follows:. Chapter 3 and Chapter 4 described how to create physical and logical standby databases. Chapter 3 , Chapter 4 , and Appendix F for information about creating physical and logical standby databases. Maintenance and future role transitions are simplified if the same disk group names are used for both the primary and standby databases. Create a remote login password file for the standby database.
Use the same password for the SYS account as on the primary database. If the standby database is going to use ASM, create an ASM instance if one does not already exist on the standby database system. If the backup set is on tape, the media manager must be configured so that the standby instance can read the backup set.
After you successfully complete these steps, continue with the steps in Section 3. To create a logical standby database, continue with the standby database creation process described in Chapter 4 , but with the following modifications:. However, if this parameter was set on the primary database, it must also be set on the standby database. After creating a logical standby control file on the primary system, do not use an operating system command to copy this file to the standby system.
To perform this operation, connect only to the standby database, as shown in the following example:. After you successfully complete these steps, continue with the steps in Section 4.
Is ignored; valid only when boston is running in the primary role. Directs transmission of redo data to the remote physical standby destination chicago. Is ignored; valid only when boston is running in the standby role.
You must configure a standby redo log on this site to perform switchovers. Is ignored; valid only when denver is running in the primary role. Is ignored; valid only when denver is running in the standby role. Directs transmission of redo data to the remote logical standby destination chicago.
Is not defined for this database. Directs transmission of redo data to the remote logical standby destination denver. Is ignored; valid only for standby role. Note: The New York city database is operating in maximum performance mode because sending redo data synchronously from HQ to NYC might impact the primary database performance during peak workload periods.
However, the New York City standby database is still considered a viable candidate for failovers because it uses a standby redo log. Note: Depending on how long the primary database has been unavailable, the previous query might not return any selected rows because the RFS process might detect the network disconnection and terminate itself. If this occurs, it is always best to select a standby database that is configured to receive the redo data in a synchronous manner.
0コメント