'LOCATION=/arch1/chicago/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2=
'SERVICE=boston LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 5
2> ('/oracle/dbs/log1c.rdo','/oracle/dbs/log2c.rdo') SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 10
2> ('/oracle/dbs/log1c.rdo','/oracle/dbs/log2c.rdo') SIZE 500M;
Verify the standby redo log file groups were created.
SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
GROUP# THREAD# SEQUENCE# ARC STATUS
---------- ---------- ---------- --- ----------
3 1 16 NO ACTIVE
4 0 0 YES UNASSIGNED
5 0 0 YES UNASSIGNED
To configure another archival destination to point to the flash recovery area
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST
ARCH MANDATORY REOPEN=5 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)'
Configure destinations in addition to LOG_ARCHIVE_DEST_10 destination for use
after a role transition
LOG_ARCHIVE_DEST_9='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH MANDATORY REOPEN=5
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)'
LOG_ARCHIVE_DEST_10='LOCATION=USE_DB_RECOVERY_FILE_DEST ARCH MANDATORY REOPEN=5
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)'
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'
STANDBY_ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST'
The transmission to the remote destination will either be synchronous or
asynchronous, based on whether the SYNC or the ASYNC attribute is set on the LOG_
ARCHIVE_DEST_n parameter. Synchronous LGWR processing is required for the
maximum protection and maximum availability modes of data protection in Data
Guard configurations
Specifying Synchronous or Asynchronous Network Transmission
The LGWR process synchronously writes to the local online redo log files at the same
time it transmits redo data to the remote destination:
--> The SYNC attribute performs all network I/O synchronously, in conjunction with
each write operation to the online redo log file, and waits for the network I/O to
complete. Section 5.3.2.2 shows an example of synchronous network transmission
in a Data Guard configuration. This is the default network transmission setting.
--> The ASYNC attribute performs all network I/O asynchronously and control is
returned to the executing application or user immediately, without waiting for the
network I/O to complete. Section 5.3.2.3 shows an example of asynchronous
network transmission in a Data Guard configuration.
If you do not specify the VALID_FOR attribute for a destination, by default, archiving
the online redo log and standby redo log is enabled to the destination, regardless of
the database role. This default behavior is equivalent to setting the (ALL_
LOGFILES,ALL_ROLES) keyword pair on the VALID_FOR attribute. For example:
LOG_ARCHIVE_DEST_1='LOCATION=/ARCH1/CHICAGO/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES)'
The LOG_ARCHIVE_CONFIG parameter also has SEND, NOSEND, RECEIVE, and
NORECEIVE attributes:
--> SEND enables a database to send redo data to remote destinations
--> RECEIVE enables the standby database to receive redo from another database
To disable these settings, use the NOSEND and NORECEIVE keywords.
For example, to ensure the primary database never accidentally receives any archived
redo data, set the LOG_ARCHIVE_CONFIG initialization parameter to NORECEIVE on
the primary database, as follows:
LOG_ARCHIVE_CONFIG='NORECEIVE,DG_CONFIG=(chicago,boston)'
Controlling the Number of Retry Attempts
LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=60 MAX_FAILURE=3'
====================================================================================================
Step 1 If you are upgrading the protection mode, perform this step.
Perform this step only if you are upgrading the protection mode (for example, from
maximum performance to maximum availability mode). Otherwise, go to Step 3.
Assume this example is upgrading the Data Guard configuration from the maximum
performance mode to the maximum availability mode. Shut down the primary
database and restart it in mounted mode:
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
For a Real Application Clusters database, shut down all of the primary instances but
start and mount only one primary instance.
Step 2 Set the data protection mode.
To specify a data protection mode, issue the SQL ALTER DATABASE SET STANDBY
DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE}
statement on the primary database. For example, the following statement specifies the
maximum availability mode:
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;
Step 3 Open the primary database.
If you performed Step 1 to upgrade the protection mode, open the database:
SQL> ALTER DATABASE OPEN;
If you are downgrading the protection mode, the database will already be open.
----------------------------------------------------------------------------------------------
Step 5 Confirm the configuration is operating in the new protection mode.
Query the V$DATABASE view to confirm the Data Guard configuration is operating in
the new protection mode. For example:
SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE;
PROTECTION_MODE PROTECTION_LEVEL
--------------------- ---------------------
MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY
Sharing a Log File Destination Among Multiple Standby Databases
LOG_ARCHIVE_DEST_1='LOCATION=DISK1 MANDATORY'
LOG_ARCHIVE_DEST_2='SERVICE=stdby1 OPTIONAL'
LOG_ARCHIVE_DEST_3='SERVICE=stdby2 OPTIONAL DEPENDENCY=LOG_ARCHIVE_DEST_2'
6.2.1 Using Real-Time Apply to Apply Redo Data Immediately
For physical standby databases, issue the ALTER DATABASE RECOVER MANAGED
STANDBY DATABASE USING CURRENT LOGFILE statement.
==================================================================================================================================================
8.1.2 Shutting Down a Physical Standby Database
1. Issue the following query to find out if the standby database is performing Redo
Apply or real-time apply. If the MRP0 or MRP process exists, then the standby
database is applying redo.
SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;
2. If Redo Apply is running, cancel it as shown in the following example:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
3. Shut down the standby database.
SQL> SHUTDOWN IMMEDIATE;
===============================================================================================================
Datafile maintananace,renaming datafile in production & changes according in 10g standby page no 132
Note:
------
If you did not set the STANDBY_FILE_MANAGEMENT initialization parameter to AUTO, you must copy the new
datafile to the standby database.
================================================================================================================
Dropping Tablespaces and Deleting Datafiles
-----------------------------------------------
1. Drop the tablespace from the primary database:
SQL> DROP TABLESPACE tbs_4;
SQL> ALTER SYSTEM SWITCH LOGFILE;
2. Delete the corresponding datafile on the standby system after the archived redo
log file was applied to the standby database. For example:
% rm /disk1/oracle/oradata/payroll/s2tbs_4.dbf
3. On the primary database, after ensuring the standby database applied the redo
information for the dropped tablespace, you can remove the datafile for the
tablespace. For example:
% rm /disk1/oracle/oradata/payroll/tbs_4.dbf
Renaming a Datafile in the Primary Database
-----------------------------------------------
1.make tablespace offline.
2.rename the tablespace
3.make it online.
4.wait for the standby to apply that archive log.
Standby side.
--------------
5.SQL> SHUTDOWN;
6.% mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf
7.SQL> STARTUP MOUNT;
8.SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf'
2> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf'
8.3.5 Adding or Dropping Online Redo Log Files
-----------------------------------------------
1. If Redo Apply is running, you must cancel Redo Apply before you can change the
log files.
2. If the STANDBY_FILE_MANAGEMENT initialization parameter is set to AUTO,
change the value to MANUAL.
3. Add or drop an online redo log file:
To add an online redo log file, use a SQL statement such as this:
SQL> ALTER DATABASE ADD LOGFILE '/disk1/oracle/oradata/payroll/prmy3.log'
SIZE 100M;
To drop an online redo log file, use a SQL statement such as this:
SQL> ALTER DATABASE DROP LOGFILE '/disk1/oracle/oradata/payroll/prmy3.log';
4. Repeat the statement you used in Step 3 on each standby database.
5. Restore the STANDBY_FILE_MANAGEMENT initialization parameter and the Redo
Apply options to their original states.
8.5 Monitoring the Primary and Standby Databases
----------------------------------------------------
8.5.3.3 Determining the Location and Creator of the Archived Redo Log Files
Query the V$ARCHIVED_LOG view on the standby database to find additional
information about the archived redo log.
SQL> SELECT NAME, CREATOR, SEQUENCE#, APPLIED, COMPLETION_TIME
2> FROM V$ARCHIVED_LOG;
NAME CREATOR SEQUENCE# APP COMPLETIO
---------------------------------------------- ------- --------- --- ---------
H:\ORACLE\ORADATA\PAYROLL\STANDBY\ARC00198.001 ARCH 198 YES 30-MAY-02
H:\ORACLE\ORADATA\PAYROLL\STANDBY\ARC00199.001 ARCH 199 YES 30-MAY-02
H:\ORACLE\ORADATA\PAYROLL\STANDBY\ARC00200.001 ARCH 200 YES 30-MAY-02
H:\ORACLE\ORADATA\PAYROLL\STANDBY\ARC00201.001 LGWR 201 YES 30-MAY-02
H:\ORACLE\ORADATA\PAYROLL\STANDBY\ARC00202.001 ARCH 202 YES 30-MAY-02
H:\ORACLE\ORADATA\PAYROLL\STANDBY\ARC00203.001 LGWR 203 YES 30-MAY-02
8.5.3.7 Determining Which Log Files Were Not Received by the Standby Site
--------------------------------------------------------------------------
Each archive destination has a destination ID assigned to it. You can query the DEST_
ID column in the V$ARCHIVE_DEST fixed view to find out your destination ID. You
can then use this destination ID in a query on the primary database to discover log
files that were not sent to a particular standby site.
For example, assume the current local archive destination ID on your primary
database is 1, and the destination ID of one of your remote standby databases is 2. To
find out which log files were not received by this standby destination, issue the
following query on the primary database:
SQL>
SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM
(SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) LOCAL
WHERE LOCAL.SEQUENCE# NOT IN
(SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND
THREAD# = LOCAL.THREAD#);
8.5.4.1 Accessing the V$DATABASE View
-----------------------------------------
Issue the following query to show information about the protection mode, the
protection level, the role of the database, and switchover status:
SQL> SELECT DATABASE_ROLE, DB_UNIQUE_NAME INSTANCE, OPEN_MODE, -
PROTECTION_MODE, PROTECTION_LEVEL, SWITCHOVER_STATUS -
FROM V$DATABASE;
Issue the following query to show information about fast-start failover:
SQL> SELECT FS_FAILOVER_STATUS FSFO_STATUS, FS_FAILOVER_CURRENT_TARGET -
TARGET_STANDBY, FS_FAILOVER_THRESHOLD THRESHOLD, -
FS_FAILOVER_OBSERVER_PRESENT OBS_PRES -
FROM V$DATABASE;
8.5.4.2 Accessing the V$MANAGED_STANDBY Fixed View
--------------------------------------------------------------------------
Query the physical standby database to monitor Redo Apply and redo transport
services activity at the standby site.
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
------- ------------ ---------- ---------- ---------- ----------
RFS ATTACHED 1 947 72 72
MRP0 APPLYING_LOG 1 946 10 72
8.5.4.2 Accessing the V$MANAGED_STANDBY Fixed View
--------------------------------------------------------------------------
Query the physical standby database to monitor Redo Apply and redo transport
services activity at the standby site.
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
------- ------------ ---------- ---------- ---------- ----------
RFS ATTACHED 1 947 72 72
MRP0 APPLYING_LOG 1 946 10 72
The previous query output shows that an RFS process completed archiving a redo log
file with sequence number 947. The output also shows that Redo Apply is actively
applying an archived redo log file with the sequence number 946. The recovery
operation is currently recovering block number 10 of the 72-block archived redo log
file.
8.5.4.3 Accessing the V$ARCHIVE_DEST_STATUS Fixed View
--------------------------------------------------------------------------
To determine if real-time apply is enabled, query the RECOVERY_MODE column of the
V$ARCHIVE_DEST_STATUS view. It will contain the value MANAGED REAL TIME
APPLY when real-time apply is enabled, as shown in the following example:
SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2 ;
RECOVERY_MODE
-----------------------
MANAGED REAL TIME APPLY
8.5.4.6 Accessing the V$DATAGUARD_STATUS Fixed View
--------------------------------------------------
SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;
MESSAGE
--------------------------------------------------------------------------------
ARC0: Archival started
ARC1: Archival started
Archivelog destination LOG_ARCHIVE_DEST_2 validated for no-data-loss
recovery
Creating archive destination LOG_ARCHIVE_DEST_2: 'dest2'
ARCH: Transmitting activation ID 0
LGWR: Completed archiving log 3 thread 1 sequence 11
Creating archive destination LOG_ARCHIVE_DEST_2: 'dest2'
LGWR: Transmitting activation ID 6877c1fe
LGWR: Beginning to archive log 4 thread 1 sequence 12
ARC0: Evaluating archive log 3 thread 1 sequence 11
ARC0: Archive destination LOG_ARCHIVE_DEST_2: Previously completed
ARC0: Beginning to archive log 3 thread 1 sequence 11
Creating archive destination LOG_ARCHIVE_DEST_1:
'/oracle/arch/arch_1_11.arc'
ARC0: Completed archiving log 3 thread 1 sequence 11
ARC1: Transmitting activation ID 6877c1fe
15 rows selected.
8.6 Tuning the Log Apply Rate for a Physical Standby Database
--------------------------------------------------------------------------------
1.Set Parallel Recovery to Twice the Number of CPUs on One Standby Host
2.Set DB_BLOCK_CHECKING=FALSE for Faster Redo Apply Rates
3.Set PARALLEL_EXECUTION_MESSAGE_SIZE = 4096
4.use native asynchronous I/O and set the database parameter DISK_ASYNCH_IO to TRUE
================================================================================================================================================
10.2.2 Recovery from Loss of Datafiles on the Standby Database
---------------------------------------------------------------
1. Stop Redo Apply.
2. Determine the value of the UNTIL_SCN column, by issuing the following query:
SQL> SELECT MAX(NEXT_CHANGE#)+1 UNTIL_SCN FROM V$LOG_HISTORY LH, V$DATABASE DB
WHERE LH.RESETLOGS_CHANGE#=DB.RESETLOGS_CHANGE# AND LH.RESETLOGS_TIME =
DB.RESETLOGS_TIME;
UNTIL_SCN
------- ----------------
967786
3. Issue the following RMAN commands to restore and recover datafiles on the
standby database. You must be connected to both the standby and recovery
catalog databases (use the TARGET keyword to connect to standby instance):
RESTORE DATAFILE
RECOVER DATABASE UNTIL SCN 967786;
To restore a tablespace, use the RMAN 'RESTORE TABLESPACE tbs_name1,
tbs_name2, ...' command.
4. Restart Redo Apply.
10.2.3 Recovery from the Loss of a Standby Control File
---------------------------------------------------------------
SQL> SHOW PARAMETER CONTROL_FILES
You can copy an intact copy of the control file over the lost copy, then restart the
standby instance using the following SQL statements:
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
If all standby control files are lost, then you must create a new control file from the
primary database, copy it to all multiplexed locations on the standby database, and
restart the standby instance and Redo Apply. The created control file loses all
information about archived redo log files generated before its creation. Because RMAN
looks into the control file for the list of archived redo log files to back up, all the
archived redo log files generated since the last backup must be manually cataloged.
10.2.4 Recovery from the Loss of the Primary Control File
---------------------------------------------------------------
Note:
-----
Oracle software allows multiplexing of the control file on the primary database. If one
of the control files cannot be updated on the primary database, the primary database
instance is shut down automatically.
If you lose all of your control files, you can choose among the following procedures,
depending on the amount of downtime that is acceptable.
10.2.5 Recovery from the Loss of an Online Redo Log File
---------------------------------------------------------------
Oracle recommends multiplexing the online redo log files. The loss of all members of
an online redo log group causes Oracle software to terminate the instance.
To add a new member to a redo log group, issue the following statement:
SQL> ALTER DATABASE ADD LOGFILE MEMBER 'log_file_name' REUSE TO GROUP n
You can issue this statement even when the database is open, without affecting
database availability.
If all members of an inactive group that has been archived are lost, the group can be
dropped and re-created.
10.3.3 Standby Database File Names Are Different than Primary Database
------------------------------------------------------------------------------
RUN
{
SET NEWNAME FOR DATAFILE 1 TO 'existing file location for file#1 from V$DATAFILE';
SET NEWNAME FOR DATAFILE 2 TO 'existing file location for file#2 from V$DATAFILE';
…
…
SET NEWNAME FOR DATAFILE n TO 'existing file location for file#n from V$DATAFILE';
RESTORE {DATAFILE
SWITCH DATAFILE ALL;
RECOVER DATABASE {NOREDO};
}
10.3.4 Deletion Policy for Archived Redo Log Files In Flash Recovery Areas
------------------------------------------------------------------------------
CONFIGURE ARCHIVELOG DELETION POLICY TO [CLEAR | NONE | APPLIED ON STANDBY];
10.3.4.1 Reconfiguring the Deletion Policy After a Role Transition
-------------------------------------------------------------------
After a switchover or failover, you may need to reissue the RMAN CONFIGURE
ARCHIVELOG DELETION POLICY command on each database.
10.3.4.2 Viewing the Current Deletion Policy
-----------------------------------------------
To see the current setting (APPLIED ON STANDBY, CLEAR, NONE) for a database, issue
the following query:
SELECT NAME, VALUE FROM V$RMAN_CONFIGURATION WHERE
NAME LIKE '%ARCHIVELOG DELETION POLICY%';
NAME VALUE
----------------------------- --------------
ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY
You can also find the existing configuration using the RMAN SHOW ARCHIVELOG
DELETION POLICY command:
RMAN> SHOW ARCHIVELOG DELETION POLICY
RMAN configuration parameters are:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
11.2 Requirements to Perform a Rolling Upgrade Using SQL Apply
-------------------------------------------------------------------
The rolling upgrade procedure requires the following:
--> A primary database that is running Oracle Database release x and a logical
standby database that is running Oracle Database release y.
--> The databases must not be part of a Data Guard Broker configuration. See Oracle
Data Guard Broker for information about removing databases from a broker
configuration.
-->The Data Guard protection mode must be set to either maximum availability or
maximum performance. Query the PROTECTION_LEVEL column in the
V$DATABASE view to find out the current protection mode setting.
--> The LOG_ARCHIVE_DEST_n initialization parameter for the logical standby
database destination must be set to OPTIONAL to ensure the primary database can
proceed while the logical standby database is being upgraded.
--> The COMPATIBLE initialization parameter must match the software release prior
to the upgrade. That is, a rolling upgrade from release x to release y requires that
the COMPATIBLE initialization parameter be set to release x on both the primary
and standby databases.
11.5 Upgrade the Databases
---------------------------
Step Description
1 Stop SQL Apply and upgrade the logical standby database
2 Restart SQL Apply
3 Monitor events on the upgraded standby database
4 Begin a switchover
5 Determine if unsupported objects were modified during the upgrade
6 Complete the switchover and activate user applications
7 Upgrade the former primary database
8 Start SQL Apply
9 Optionally, raise the compatibility level on both databases
10 Monitor events on the new logical standby database
11 Optionally, perform another switchover
12.1.4 Verifying the Current VALID_FOR Attribute Settings for Each Destination
--------------------------------------------------------------------------------
SQL> SELECT DEST_ID,VALID_TYPE,VALID_ROLE,VALID_NOW FROM V$ARCHIVE_DEST;
DEST_ID VALID_TYPE VALID_ROLE VALID_NOW
------- --------------- ------------ ----------------
1 ALL_LOGFILES ALL_ROLES YES
2 STANDBY_LOGFILE STANDBY_ROLE WRONG VALID_TYPE
3 ONLINE_LOGFILE STANDBY_ROLE WRONG VALID_ROLE
4 ALL_LOGFILES ALL_ROLES UNKNOWN
5 ALL_LOGFILES ALL_ROLES UNKNOWN
6 ALL_LOGFILES ALL_ROLES UNKNOWN
7 ALL_LOGFILES ALL_ROLES UNKNOWN
8 ALL_LOGFILES ALL_ROLES UNKNOWN
9 ALL_LOGFILES ALL_ROLES UNKNOWN
10 ALL_LOGFILES ALL_ROLES UNKNOWN
each line represents one of the ten destinations in the Data Guard
configuration. The first line indicates that the VALID_FOR attribute for LOG_
ARCHIVE_DEST_1 is set to (ALL_LOGFILES,ALL_ROLES), which is the only
keyword pair that is valid at all times.
More interesting are the second and third lines in the view, which are both currently
invalid, but for different reasons:
--> LOG_ARCHIVE_DEST_2 is set to (STANDBY_LOGFILES,STANDBY_ROLE), but
the WRONG VALID_TYPE is returned because this standby destination does not
have a standby redo log implemented.
--> LOG_ARCHIVE_DEST_3 is set to (ONLINE_LOGFILES,STANDBY_ROLE), but the
WRONG VALID_ROLE is returned because this destination is currently running in
the primary database role.
All of the other destinations are shown as UNKNOWN, which indicates the destinations
are either undefined or the database is started and mounted but archiving is not
currently taking place. See the V$ARCHIVE_DEST view in the Oracle Database Reference
for information about these and other columns.
12.2.1 Example: Best Physical Standby Database for a Failover
------------------------------------------------------------------
Bring the selected standby database to its most current state.
------------------------------------------------------------------
Step 6 Obtain a list of the archived redo log files that were applied or are
currently pending application to the NYC database.
Query the V$ARCHIVED_LOG view:
SQL> SELECT SUBSTR(NAME,1,25) FILE_NAME, SEQUENCE#, APPLIED
2> FROM V$ARCVHIVED_LOG ORDER BY SEQUENCE#;
FILE_NAME SEQUENCE# APP
------------------------- ---------- ---
/oracle/dbs/hq_nyc_2.log 2 YES
/oracle/dbs/hq_nyc_3.log 3 YES
/oracle/dbs/hq_nyc_4.log 4 YES
/oracle/dbs/hq_nyc_5.log 5 YES
/oracle/dbs/hq_nyc_6.log 6 YES
/oracle/dbs/hq_nyc_7.log 7 YES
/oracle/dbs/hq_nyc_8.log 8 NO
/oracle/dbs/hq_nyc_9.log 9 NO
/oracle/dbs/hq_nyc_10.log 10 NO
/oracle/dbs/hq_nyc_11.log 11 NO
/oracle/dbs/hq_nyc_12.log 12 NO
/oracle/dbs/hq_nyc_13.log 13 NO
% cp /net/nyc/oracle/dbs/hq_nyc_12.log /net/sat/oracle/dbs/hq_sat_12.log
% ls -l /net/sat/oracle/dbs/hq_sat_14.log
/net/sat/oracle/dbs/hq_sat_14.log: No such file or directory
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE '/oracle/dbs/hq_sat_12.log';
12.4 Using Flashback Database After a Failover
-------------------------------------------------
12.4.1 Flashing Back a Failed Primary Database into a Physical Standby Database
----------------------------------------------------------------------------------
Step 1 Determine the SCN at which the old standby database became the
primary database.
On the new primary database, issue the following query to determine the SCN at
which the old standby database became the new primary database:
SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;
Step 2 Flash back the failed primary database.
To create a new physical standby database, shut down the old primary database (if
necessary), mount it, and flash it back to the value for STANDBY_BECAME_PRIMARY_
SCN that was determined in Step 1:
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO SCN standby_became_primary_scn;
Step 3 Convert the database to a physical standby database.
Perform the following steps on the old primary database:
1. Issue the following statement on the old primary database:
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
This statement will dismount the database after successfully converting the control
file to a standby control file.
2. Shut down and restart the database:
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
12.5 Using Flashback Database After Issuing an Open Resetlogs Statement
----------------------------------------------------------------------------------
12.5.1 Flashing Back a Physical Standby Database to a Specific Point-in-Time
-------------------------------------------------------------------------------
The following steps describe how to avoid re-creating a physical standby database
after you issued the OPEN RESETLOGS statement on the primary database.
Step 1 Determine the SCN before the RESETLOGS operation occurred.
-----------------------------------------------------------------
On the primary database, use the following query to obtain the value of the system
change number (SCN) that is 2 SCNs before the RESETLOGS operation occurred on the
primary database:
SQL> SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) FROM V$DATABASE;
Step 2 Obtain the current SCN on the standby database.
-----------------------------------------------------------------
On the standby database, obtain the current SCN with the following query:
SQL> SELECT TO_CHAR(CURRENT_SCN) FROM V$DATABASE;
Step 3 Determine if it is necessary to flash back the database.
-----------------------------------------------------------------
If the value of CURRENT_SCN is larger than the value of resetlogs_change# - 2, issue
the following statement to flash back the standby database.
SQL> FLASHBACK STANDBY DATABASE TO SCN resetlogs_change# -2;
--> If the value of CURRENT_SCN is less than the value of the resetlogs_change# - 2,
skip to Step 4.
--> If the standby database’s SCN is far enough behind the primary database’s SCN,
log apply services will be able to continue through the OPEN RESETLOGS
statement without stopping. In this case, flashing back the database is unnecessary
because log apply services do not stop upon reaching the OPEN RESETLOGS
statement in the redo data.
Step 4 Restart Redo Apply.
----------------------------
To start Redo Apply on the physical standby database, issue the following statement:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
The standby database is now ready to receive and apply redo from the primary
database.
12.6 Using a Physical Standby Database for Read/Write Testing and Reporting
----------------------------------------------------------------------------------
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> CREATE RESTORE POINT before_application_patch GUARANTEE FLASHBACK
DATABASE;
Defer log archive destinations pointing to the standby that will be activated.
On the primary database
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;
Step 3 Activate the physical standby database.
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
Enter the following statement to shut down and restart the physical standby
database:
SQL> STARTUP MOUNT FORCE;
Set the protection mode to maximum performance and open the database for
read/write access:
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
SQL> ALTER DATABASE OPEN;
Step 4 Use the activated database for reporting or testing.
Once the standby database has been activated, you can run reporting
Step 5 Revert the activated database back to a physical standby database.
SQL> STARTUP MOUNT FORCE;
SQL> FLASHBACK DATABASE TO RESTORE POINT before_application_patch;
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL> STARTUP MOUNT FORCE;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
12.7 Using RMAN Incremental Backups to Roll Forward a Physical Standby Database
----------------------------------------------------------------------------------
12.7.1 Physical Standby Database Lags Far Behind the Primary Database
1. On the standby database, stop the managed recovery process (MRP):
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;
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
DATABASE FORMAT '/tmp/ForStandby_%U' tag 'FORSTANDBY';
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. On the standby database, restart Flashback Database:
SQL> ALTER DATABASE FLASHBACK OFF;
SQL> ALTER DATABASE FLASHBACK ON;
16. On the standby database, restart MRP:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
12.7.2 Physical Standby Database Has Nologging Changes On a Subset of Datafiles
----------------------------------------------------------------------------------
Follow this step-by-step procedure to roll forward a physical standby database for
which nologging changes have been applied to a small subset of the database:
1. List the files that have had nologging changes applied by querying the
V$DATAFILE view on the standby database. For example:
SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE
WHERE FIRST_NONLOGGED_SCN > 0;
FILE# FIRST_NONLOGGED_SCN
---------- -------------------
4 225979
5 230184
2. Stop Redo Apply on the standby database:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
3. On the standby database, offline the datafiles (recorded in step 1) that have had
nologging changes. Taking these datafiles offline ensures redo data is not skipped
for the corrupt blocks while the incremental backups are performed.
SQL> ALTER DATABASE DATAFILE 4 OFFLINE FOR DROP;
SQL> ALTER DATABASE DATAFILE 5 OFFLINE FOR DROP;
4. Start Redo Apply on the standby database:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
USING CURRENT LOGFILE DISCONNECT;
5. While connected to the primary database as the RMAN target, create an
incremental backup for each datafile listed in the FIRST_NONLOGGED_SCN
column (recorded in step 1). For example:
RMAN> BACKUP INCREMENTAL FROM SCN 225979 DATAFILE 4 FORMAT '/tmp/ForStandby_%U'
TAG 'FOR STANDBY';
RMAN> BACKUP INCREMENTAL FROM SCN 230184 DATAFILE 5 FORMAT '/tmp/ForStandby_%U'
TAG 'FOR STANDBY';
6. Transfer all backup sets created on the primary system to the standby system.
(Note that there may be more than one backup file created.)
SCP /tmp/ForStandby_* standby:/tmp
7. While connected to the physical standby database as the RMAN target, catalog all
incremental backup pieces. For example:
RMAN> CATALOG START WITH '/tmp/ForStandby_';
8. Stop Redo Apply on the standby database:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
9. Online the datafiles on the standby database
SQL> ALTER DATABASE DATAFILE 4 ONLINE;
SQL> ALTER DATABASE DATAFILE 5 ONLINE;
10. While connected to the physical standby database as the RMAN target, apply the
incremental backup sets:
RMAN> RECOVER DATAFILE 4, 5 NOREDO;
11. Query the V$DATAFILE view on the standby database to verify there are no
datafiles with nologged changes. The following query should return zero rows
SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE
WHERE FIRST_NONLOGGED_SCN > 0;
12. Remove the incremental backups from the standby system:
RMAN> DELETE BACKUP TAG 'FOR STANDBY';
13. Manually remove the incremental backups from the primary system. For example,
the following example uses the Linux rm command:
rm /tmp/ForStandby_*
14. Start Redo Apply on the standby database:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE
DISCONNECT;
12.7.3 Physical Standby Database Has Widespread Nologging Changes
-------------------------------------------------------------------
1. Query the V$DATAFILE view on the standby database to record the lowest
FIRST_NONLOGGED_SCN:
SQL> SELECT MIN(FIRST_NONLOGGED_SCN) FROM V$DATAFILE
WHERE FIRST_NONLOGGED_SCN>0;
MIN(FIRST_NONLOGGED_SCN)
------------------------
223948
2. Stop Redo Apply on the standby database:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
3. While connected to the primary database as the RMAN target, create an
incremental backup from the lowest FIRST_NONLOGGED_SCN (recorded in step 1)
RMAN> BACKUP INCREMENTAL FROM SCN 223948 DATABASE FORMAT '/tmp/ForStandby_%U'
tag 'FOR STANDBY';
4. Transfer all backup sets created on the primary system to the standby system.
(Note that more than one backup file may have been created.) The following
example uses the scp command to copy the files:
scp /tmp/ForStandby_* standby:/tmp
5. While connected to the standby database as the RMAN target, catalog all
incremental backup piece(s)
RMAN> CATALOG START WITH '/tmp/ForStandby_';
6. While connected to the standby database as the RMAN target, apply the
incremental backups:
RMAN> RECOVER DATABASE NOREDO;
7. Query the V$DATAFILE view to verify there are no datafiles with nologged
changes. The following query on the standby database should return zero rows:
SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE
WHERE FIRST_NONLOGGED_SCN > 0;
8. Remove the incremental backups from the standby system:
RMAN> DELETE BACKUP TAG 'FOR STANDBY';
9. Manually remove the incremental backups from the primary system. For example,
the following removes the backups using the Linux rm command:
rm /tmp/ForStandby_*
10. Start Redo Apply on the standby database:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
USING CURRENT LOGFILE DISCONNECT;
12.8.1 Establishing a Time Lag on a Physical Standby Database
-------------------------------------------------------------------
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=stdby DELAY=240';
12.8.2 Failing Over to a Physical Standby Database with a Time Lag
-------------------------------------------------------------------
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP
The ACTIVATE statement immediately transitions the standby database to the
primary role and makes no attempt to apply any additional redo data that might
exist at the standby location.
12.10.2 Recovery Steps for Physical Standby Databases(For unrecoverable tablespaces)
---------------------------------------------------------------------------------------
1. Query the primary database:
SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE;
NAME UNRECOVERABLE
----------------------------------------------------- -------------
/oracle/dbs/tbs_1.dbf 5216
/oracle/dbs/tbs_2.dbf 0
/oracle/dbs/tbs_3.dbf 0
/oracle/dbs/tbs_4.dbf 0
4 rows selected.
2. Query the standby database:
SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE;
NAME UNRECOVERABLE
----------------------------------------------------- -------------
/oracle/dbs/stdby/tbs_1.dbf 5186
/oracle/dbs/stdby/tbs_2.dbf 0
/oracle/dbs/stdby/tbs_3.dbf 0
/oracle/dbs/stdby/tbs_4.dbf 0
SQL> ALTER TABLESPACE system BEGIN BACKUP;
SQL> EXIT;
% cp tbs_1.dbf /backup
SQL> ALTER TABLESPACE system END BACKUP;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
LOG_ARCHIVE_DEST_n Parameter Attributes
-----------------------------------------------------
When you specify the ASYNC and AFFIRM attributes, performance is not
affected.
ALTERNATE
-----------
LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY ALTERNATE=LOG_ARCHIVE_DEST_2'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY'
LOG_ARCHIVE_DEST_STATE_2=ALTERNATE
DELAY
-----------
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
LOG_ARCHIVE_DEST_3='SERVICE=stbyC DELAY=120'
DEPENDENCY
-----------
LOG_ARCHIVE_DEST_3='SERVICE=dest3 DEPENDENCY=LOG_ARCHIVE_DEST_2 OPTIONAL'
LOG_ARCHIVE_DEST_STATE_3=ENABLE
LOCATION and SERVICE
----------------------
Example 1 Specifying the LOCATION Attribute
LOG_ARCHIVE_DEST_2='LOCATION=/disk1/oracle/oradata/payroll/arch/'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
Example 2 Specifying the SERVICE Attribute
LOG_ARCHIVE_DEST_3='SERVICE=stby1'
LOG_ARCHIVE_DEST_STATE_3=ENABLE
MANDATORY and OPTIONAL
----------------------
Specifies the policy for reusing online redo log files:
--> MANDATORY—specifies that filled online log files must be successfully archived to
the destination before they can be reused.
--> OPTIONAL—specifies that successful archival to the destination is not required
before the online redo log file can be made available for reuse.
MAX_CONNECTIONS
----------------
Specifies the maximum number of network connections that will be used to perform
remote archival to the destination. If the MAX_CONNECTIONS attribute is set to a value
greater than 1, redo transport services use multiple network connections to perform
remote archivals. Each of these connections use a separate archiver (ARCn) process.
LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=denver MAX_CONNECTIONS=3'
LOG_ARCHIVE_DEST_STATE_3=ENABLE
MAX_FAILURE
-------------
LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=5 MAX_FAILURE=3'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
NET_TIMEOUT
------------
LOG_ARCHIVE_DEST_2='SERVICE=stby1 LGWR NET_TIMEOUT=40 SYNC'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REOPEN
---------
LOG_ARCHIVE_DEST_3='SERVICE=stby1 MANDATORY REOPEN=60'
LOG_ARCHIVE_DEST_STATE_3=ENABLE
------------------------------------
Troubleshooting Data Guard
------------------------------------
When sessions are active, an attempt to switch over fails with the following error message:
------------------------------------------------------------------------------------------------------------
If you do not include the WITH SESSION SHUTDOWN clause as a part of the ALTER
DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY statement, active
SQL sessions might prevent a switchover from being processed. Active SQL sessions
can include other Oracle Database processes.
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY *
ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected
Action: Query the V$SESSION view to determine which processes are causing the
error. For example:
SQL> SELECT SID, PROCESS, PROGRAM FROM V$SESSION
2> WHERE TYPE = 'USER'
3> AND SID <> (SELECT DISTINCT SID FROM V$MYSTAT);
SID PROCESS PROGRAM
--------- -------- ------------------------------------------------
7 3537 oracle@nhclone2 (CJQ0)
10
14
16
19
21
6 rows selected.
In the previous example, the JOB_QUEUE_PROCESSES parameter corresponds to the
CJQ0 process entry. Because the job queue process is a user process, it is counted as a
SQL session that prevents switchover from taking place. The entries with no process or
program information are threads started by the job queue controller.
Verify the JOB_QUEUE_PROCESSES parameter is set using the following SQL
statement:
SQL> SHOW PARAMETER JOB_QUEUE_PROCESSES;
NAME TYPE VALUE
------------------------------ ------- --------------------
job_queue_processes integer 5
Then, set the parameter to 0. For example:
SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
Statement processed.
Because JOB_QUEUE_PROCESSES is a dynamic parameter, you can change the value
and have the change take effect immediately without having to restart the instance.
You can now retry the switchover procedure.
Do not modify the parameter in your initialization parameter file. After you shut
down the instance and restart it after the switchover completes, the parameter will be
reset to the original value. This applies to both primary and physical standby
databases.
A.6 Network Tuning for Redo Data Transmission
-----------------------------------------------
Oracle Net connect descriptor used by redo transport services.
The following example shows a database initialization parameter file segment that
defines a remote destination netserv:
LOG_ARCHIVE_DEST_3='SERVICE=netserv'
The following example shows the definition of that service name in the
tnsnames.ora file:
netserv=(DESCRIPTION=(SDU=32768)(ADDRESS=(PROTOCOL=tcp)(HOST=host) (PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=srvc)))
The following example shows the definition in the listener.ora file:
LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)
(HOST=host)(PORT=1521))))
SID_LIST_LISTENER=(SID_LIST=(SID_DESC=(SDU=32768)(SID_NAME=sid)
(GLOBALDBNAME=srvc)(ORACLE_HOME=/oracle)))
If you archive to a remote site using a high-latency or high-bandwidth network link,
you can improve performance by using the SQLNET.SEND_BUF_SIZE and
SQLNET.RECV_BUF_SIZE Oracle Net profile parameters to increase the size of the
network send and receive I/O buffers.
F.4 Creating a Standby Database with the Same Directory Structure
----------------------------------------------------------------------------------------------
F.4.1 Creating the Standby Database Without Performing Recovery
--------------------------------------------------------------------
Specify NOFILENAMECHECK in the DUPLICATE command. The
NOFILENAMECHECK option is required when the standby and primary
datafiles and log files have the same names. Otherwise, RMAN returns an
error.
DUPLICATE TARGET DATABASE FOR STANDBY
NOFILENAMECHECK;
F.4.2 Creating the Standby Database and Performing Recovery
-------------------------------------------------------------------
RUN
{
# If desired, issue a SET command to terminate recovery at a specified point.
# SET UNTIL SCN 143508;
DUPLICATE TARGET DATABASE FOR STANDBY
NOFILENAMECHECK
DORECOVER;
}
F.5.2 Naming Standby Database Files with SET NEWNAME
--------------------------------------------------------
RUN
{
# set new file names for the datafiles
SET NEWNAME FOR DATAFILE 1 TO '?/dbs/standby_data_01.f';
SET NEWNAME FOR DATAFILE 2 TO '?/dbs/standby_data_02.f';
.
.
.
# run the DUPLICATE command
DUPLICATE TARGET DATABASE FOR STANDBY;
}
F.5.3 Naming Standby Database Files with CONFIGURE AUXNAME
---------------------------------------------------------------
To use CONFIGURE AUXNAME to name standby database files without
performing recovery:
# set auxiliary names for the datafiles
CONFIGURE AUXNAME FOR DATAFILE 1 TO '/oracle/auxfiles/aux_1.f';
CONFIGURE AUXNAME FOR DATAFILE 2 TO '/oracle/auxfiles/aux_2.f';
.
.
.
CONFIGURE AUXNAME FOR DATAFILE n TO '/oracle/auxfiles/aux_n.f';
RUN
{
# allocate at least one auxiliary channel of type DISK or sbt
ALLOCATE AUXILIARY CHANNEL standby1 DEVICE TYPE sbt;
.
.
.
# issue the DUPLICATE command
DUPLICATE TARGET DATABASE FOR STANDBY;
}
4. Unspecify the auxiliary names for the datafiles so that they are not overwritten by
mistake. For example, enter the following at the RMAN prompt:
# un-specify auxiliary names for the datafiles
CONFIGURE AUXNAME FOR DATAFILE 1 CLEAR;
CONFIGURE AUXNAME FOR DATAFILE 2 CLEAR;
.
.
.
CONFIGURE AUXNAME FOR DATAFILE n CLEAR;
Setting Archive Tracing
------------------------------------
0 Disables archived redo log tracing (default setting)
1 Tracks archiving of log files
2 Tracks archive status by archive log file destination
4 Tracks archive operational phase
8 Tracks archive log destination activity
16 Tracks detailed archive log destination activity
32 Tracks archive log destination parameter modifications
64 Tracks ARCn process state activity
128 Tracks FAL server process activity
256 Track RFS Logical Client
512 Tracks LGWR redo shipping network activity
1024 Tracks RFS physical client
2048 Tracks RFS/ARCn ping heartbeat
4096 Tracks real-time apply activity
8192 Tracks Redo Apply activity (media recovery or physical standby)
No comments:
Post a Comment