Data Guard administrators need to know methods to resolve some specific issues. These issues may originate from configuration changes, misconfiguration, or user errors. Another important point is the use of diagnostic data to identify these issues. Now we'll cover handling the most common of these Data Guard issues and the methods to access and use diagnostic data.
In this chapter, we will discuss the following topics:
- Recreating the standby control file
- Dealing with redo transport authentication problems
- Dealing with
UNNAMEDdatafiles - Closing a gap with RMAN incremental backups
- Fixing
NOLOGGINGchanges in a standby database - Turning on Data Guard tracing
- Gathering diagnostic data
Let's start with renewing the standby control file of a standby database.
A standby control file essentially keeps the same information of the primary database with the control file, which is the physical structure of the database. It also contains some specific information about the Data Guard, such as whether an archive log sequence is applied or not. A standby control file is mandatory to mount a physical standby database, and we should consider keeping multiple copies of the standby control file, preferably on different disks, which is known as multiplexing.
In some cases, we may want to renew a standby control file by using a newly created one on the primary database. For example, before a switchover it's a good practice to renew the standby control file in order to guarantee that all of the redo, temp file structure, and historical archived log data are the same. In general, this is a three-step operation:
- Create a copy of the standby control file from the primary database.
- Transfer this standby control file from the primary database to the standby site.
- Restart the standby database using a new standby control file.
In order to create a standby control file from a primary database, we can choose one of the following methods:
- Using the
ALTER DATABASE CREATE STANDBY CONTROLFILESQL statement:SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/standby.ctl';We can directly copy the file to the standby server with FTP or SCP and use it as the new standby control file.
- Using the
BACKUP CURRENT CONTROLFILE FOR STANDBYRMAN statement:RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT 'standbyctl.bkp';The file will be an RMAN backup of the standby control file that we can transfer and use in order to restore the standby control file with the
RESTORE STANDBY CONTROLFILE FROMRMAN statement.
This standby control file recreation operation needs some extra steps if we use Oracle-managed files (OMF). OMF automatically generates datafile names, and the names will be different in the primary and standby databases. We'll not be able to mount the standby database with the newly created standby control file because it'll search for datafiles with their names in the primary database. So we need to introduce datafiles to the standby control file in some way.