General Questions and Answers for 10g Standby

Database (Data Guard)

General Questions and Answers for 10g Standby Database (Data Guard)

o 1. What is Logical Standby Database and how is it different to Physical Standby

o 2. How to shutdown standby database

Physical Standby

Shutting Down a Physical Standby Database

Logical Standby

Shutting Down a Logical Standby Database

o 3. How to startup a standby database

Physical Standby

Startup a Physical Standby Database & Start Recovery

Startup a Physical Standby Database for Read-Only Access

Switch a Physical Standby Database from Managed Recovery to Read-Only

Access

Switch a Physical Standby Database from Read-Only Access to Managed

Recovery

Logical Standby

Start and Mount a Logical Standby Database

o 4. What synchronising issues - Managing Archive Gaps

4.1 What Is an Archive Gap?

4.2 When Is an Archive Gap Discovered?

4.3 Determining If an Archive Gap Exists on a Physical Standby Database

4.2 Determining If an Archive Gap Exists On a logical standby database:

4.4 How Is a Gap Resolved?

o 5.Monitoring

5.1 Monitoring Log Apply Services for Physical Standby Databases

5.2 Monitoring Log Apply Services for Logical Standby Databases

o 6.Adding space to the primary is the space added to the standby?

6.1 Adding a Datafile or Creating a Tablespace for Physical Standby

6.2 Adding a Datafile or Creating a Tablespace for Logical Standby

 o 7.How to tell there is a standby server attached

7.1 Locate Standby Database from Primary

7.2 Verify the Physical Standby Database

7.3 Verify the Logical Standby Database

o 8.Are there primary init.ora parameters we should be checking for ?

o 9.I assume system auto start scripts do not apply ?

o 10.I assume backups do not apply ?

o 11.How does auditing work on a standby ? If it is enabled on the primary what happens to
the standby ?

o 12.Oracle patches details

o 13.The Standby Site Does Not Receive Logs Archived by the Primary Database

o 14.What to Do If SQL Apply Operations to a Logical Standby Database Stop

o 15.ORA-16181 Error

1. What is Logical Standby Database and how is it different to

Physical Standby
Logical Standby Databases are updated using SQL statements. The advantage of a logical
standby database is that it can be used for recovery and reporting simultaneously.

Physical Standby Databases are updated on the basis of block-for-block. The physical standby
database cannot perform both managed recovery and read-only operations at the same time, but
can switch between them

2. How to shutdown standby database

Physical Standby

Shutting Down a Physical Standby Database

To shutdown a physical standby database, use the SQL*Plus SHUTDOWN command.

If the database is performing managed recovery, you must cancel managed recovery operations before
issuing the SHUTDOWN command.
If the primary database is up and running, defer the archive log destination on the primary database and
perform a log switch operation before shutting down the standby database. Otherwise, log transport
services will not be able to transmit redo data to this standby site.
The following steps show you how to shut down a standby database:
 Find out if the standby database is performing managed recovery.
If the MRP0 or MRP process exists, then the standby database is performing managed recovery.
SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;

Cancel managed recovery operations.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Shut down the physical standby database

SQL> SHUTDOWN IMMEDIATE;

Logical Standby

Shutting Down a Logical Standby Database

Stop logical standby apply

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

Shut down the standby database

SQL> SHUTDOWN IMMEDIATE;

3. How to startup a standby database

Physical Standby

Startup a Physical Standby Database & Start Recovery

To startup a physical standby database, use SQL*Plus to connect to the database with administrator
privileges, and then use the SQL*Plus STARTUP command with the NOMOUNT option.
If both the primary and standby databases are offline, then always start the standby database before
starting the primary database.
Once it is mounted, the database can receive archived redo data from the primary database.
The following example shows how to start a standby database:

Start the physical standby database without mounting

SQL> STARTUP NOMOUNT;

Mount the physical standby database

SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

Start managed recovery on the physical standby

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Startup a Physical Standby Database for Read-Only Access

Start the physical standby database without mounting

 SQL> STARTUP NOMOUNT;

Mount the physical standby database

SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

Open the database for read-only access

SQL> ALTER DATABASE OPEN READ ONLY;
Switch a Physical Standby Database from Managed Recovery to Read-Only Access

Cancel managed recovery

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Open the database for read-only access:

SQL> ALTER DATABASE OPEN READ ONLY;
Switch a Physical Standby Database from Read-Only Access to Managed Recovery

Terminate all active user sessions on the standby database

Restart log managed recovery

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Logical Standby

Start and Mount a Logical Standby Database

After the standby database is converter to logical standby, you can open it as a normal database and the
start the SQL apply to apply changes from primary.

Start the logical standby database

SQL> STARTUP

Start the logical standby apply process

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

4. What synchronising issues - Managing Archive Gaps

Data Guard offers automatic archive redo log gap detection and resolution to handle
network connectivity problems that might temporarily disconnect one or more standby
databases from the primary database. Once properly configured, Data Guard requires
no manual intervention by the DBA to detect and resolve such gaps.
The following sections describe gap detection and resolution.

4.1 What Is an Archive Gap?

An archive gap is a range of archived redo logs created whenever the standby system
is unable to receive the next archived redo log generated by the primary database.
For example, an archive gap occurs when the network becomes unavailable and automatic
archiving from the primary database to the standby database stops. When the network is
available again, automatic transmission of the redo data from the primary database to
the failed standby database resumes.
The missing archived redo logs are the gap. The gap is automatically detected and resolved.

4.2 When Is an Archive Gap Discovered?

An archive gap can occur whenever the primary database archives a log, but the log is not
archived to the standby site. Every minute, the primary database polls its standby databases
to see if there is a gap in the sequence of archived redo logs. The polling between the primary
and standby databases is sometimes referred to as a heartbeat. The primary database polls
the standby databases serially.

4.3 Determining If an Archive Gap Exists on a Physical Standby Database

The following sections describe how to query the appropriate views to determine which logs
are missing on the standby database.
On a physical standby database
To determine if there is an archive gap on your physical standby database, query the V$ARCHIVE_GAP
view as shown in the following example:
SQL> SELECT * FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
----------- ------------- --------------
1 7 10

The output from the previous example indicates your physical standby database is currently
missing logs from sequence 7 to sequence 10 for thread 1. After you identify the gap, issue
the following SQL statement on the primary database to locate the archived redo logs on your
primary database (assuming the local archive destination on the primary database is
LOG_ARCHIVE_DEST_1):
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE#
BETWEEN 7 AND 10;

NAME
--------------------------------------------------------------------------------
/primary/thread1_dest/arcr_1_7.arc
/primary/thread1_dest/arcr_1_8.arc
/primary/thread1_dest/arcr_1_9.arc

Copy these logs to your physical standby database and register them using the ALTER DATABASE
REGISTER LOGFILE statement on your physical standby database. For example:
SQL> ALTER DATABASE REGISTER LOGFILE
'/physical_standby1/thread1_dest/arcr_1_7.arc';
SQL> ALTER DATABASE REGISTER LOGFILE
'/physical_standby1/thread1_dest/arcr_1_8.arc';
:
:
After you register these logs on the physical standby database, you can restart managed recovery
operations.

4.2 Determining If an Archive Gap Exists On a logical standby database:

To determine if there is an archive gap, query the DBA_LOGSTDBY_LOG view on the logical standby
database. For example, the following query indicates there is a gap in the sequence of archived
redo logs because it displays two files for THREAD 1 on the logical standby database. (If there
are no gaps, the query will show only one file for each thread.) The output shows that the highest
registered file is sequence number 10, but there is a gap at the file shown as sequence number 6:
SQL> SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L WHERE
NEXT_CHANGE# NOT IN
(SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#) ORDER BY
THREAD#,SEQUENCE#;

THREAD# SEQUENCE# FILE_NAME

---------- ---------- -----------------------------------------------
1 6 /disk1/oracle/dbs/log-1292880008_6.arc
1 10 /disk1/oracle/dbs/log-1292880008_10.arc

Copy the missing logs to the logical standby system and register them using the ALTER DATABASE
REGISTER LOGICAL LOGFILE statement on your logical standby database. For example:
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE /disk1/oracle/dbs/log-1292880008_10.arc;

After you register these logs on the logical standby database, you can restart log apply services.

4.4 How Is a Gap Resolved?

For both physical and logical standby databases, Data Guard performs gap detection and resolution
automatically. Normally no extra configuration settings are required.

5.Monitoring
5.1 Monitoring Log Apply Services for Physical Standby Databases

To monitor the status of archived redo logs and obtain information on log apply services on
a physical standby database, query the fixed views listed in this section.
V$MANAGED_STANDBY
V$ARCHIVE_DEST_STATUS
V$ARCHIVED_LOG
V$LOG_HISTORY
V$DATAGUARD_STATUS

5.2 Monitoring Log Apply Services for Logical Standby Databases

To monitor the status of archived redo logs and obtain information on log apply services on
a logical standby database, query the fixed views listed in this section.
DBA_LOGSTDBY_EVENTS
DBA_LOGSTDBY_LOG
DBA_LOGSTDBY_PROGRESS
V$LOGSTDBY
V$LOGSTDBY_STATS

6.Adding space to the primary is the space added to the

standby?
6.1 Adding a Datafile or Creating a Tablespace for Physical Standby

The initialization parameter, STANDBY_FILE_MANAGEMENT, allows you to control whether or not

adding a datafile to the primary database is automatically propagated to the standby database,
as follows:
If you set the STANDBY_FILE_MANAGEMENT initialization parameter in the standby database server
parameter file to AUTO, any new datafiles created on the primary database are automatically created
on the standby database as well.
If you do not specify the STANDBY_FILE_MANAGEMENT initialization parameter or if you set it to
MANUAL, then you must manually copy the new datafile to the standby database when you add a
datafile
to the primary database.

The following events are automatically administered by log transport services and log apply services,
and therefore require no intervention by the database administrator:
A SQL ALTER DATABASE statement is issued with the ENABLE THREAD or DISABLE THREAD clause.
The status of a tablespace changes (changes to read/write or read-only, placed online or taken offline).

A datafile is added or tablespace is created when the STANDBY_FILE_MANAGEMENT initialization

parameter is
set to AUTO.

6.2 Adding a Datafile or Creating a Tablespace for Logical Standby

DDL statements are executed the same way on the primary database and the logical standby database.
If the underlying file structure is the same on both databases, the DDL will execute on the standby
database as expected.

If an error was caused by a DDL transaction containing a file specification that did not match in
the logical standby database environment, perform the following steps to fix the problem:

Use the ALTER SESSION DISABLE GUARD statement to bypass the database guard so you can make
modifications
to the logical standby database:
SQL> ALTER SESSION DISABLE GUARD;
Execute the DDL statement, using the correct file specification, and then re-enable the database guard.
For example:
SQL> ALTER TABLESPACE t_table
ADD DATAFILE '/dbs/t_db.f' SIZE 100M REUSE;
SQL> ALTER SESSION ENABLE GUARD;
Start SQL Apply on the logical standby database and skip the failed transaction.
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
SKIP FAILED TRANSACTION;

Or manually copy the new file over if the standby control file has been updated. For example:
1. Take copy of newly created datafile from primary database and copy to standby server where
sufficient space is available.
2. Rename datafile manually using alter database rename datafile command on standby database to
take effect on controlfile if the file structure is different with primary.
3. Apply archive log files on standby to make standby on sync.

In some situations, the problem that caused the transaction to fail can be corrected and SQL Apply
restarted without skipping the transaction. An example of this might be when available space is
exhausted. Do not let the primary and logical standby databases diverge when skipping DDL
transactions. You should manually execute a compensating transaction in place of the skipped
transaction.

For details how to manage Logical Standby Database DDL, please refer to
A.9.1.1 DDL Transactions Containing File Specifications on
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/toc.htm

To prevent DDL failed in Logical Standby Database, some DDL should be defined within skip handler. For
details how to, please refer to
9.4.4 Setting up a Skip Handler for a DDL Statement
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/toc.htm

7.How to tell there is a standby server attached

7.1 Locate Standby Database from Primary

Logon SQLPLUS with SYS or System user

SQL> SHOW PARAMETER LOG_ARCHIVE_DEST;
It should list one of the LOG_ARCHIVE_DEST_2 like this LOG_ARCHIVE_DEST_2='SERVICE=<standby>'

The <standby> is Oracle Net Service Name. It contains net work protocol, host address, port, and SID
that the listeners for standby databases.

7.2 Verify the Physical Standby Database

Perform the following query from Standby Database.

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SEQUENCE# FIRST_TIME NEXT_TIME

---------- ------------------ ------------------
8 11-JUL-02 17:50:45 11-JUL-02 17:50:53
9 11-JUL-02 17:50:53 11-JUL-02 17:50:58
10 11-JUL-02 17:50:58 11-JUL-02 17:51:03
Or
SQL>select open_mode from v$database;
The mode should be either recovery or read only mode.
Or
SQL>select database_role from v$database;
The role should be 'PHYSICAL STANDBY'

7.3 Verify the Logical Standby Database

Perform the following query from Standby Database.

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, DICT_BEGIN, DICT_END FROM
DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
SEQUENCE# FIRST_TIME NEXT_TIME DIC DIC
---------- ------------------ ------------------ ---
24 23-JUL-02 18:19:05 23-JUL-02 18:19:48 YES YES
25 23-JUL-02 18:19:48 23-JUL-02 18:19:51 NO NO
26 23-JUL-02 18:19:51 23-JUL-02 18:19:54 NO NO
Or
SQL>select open_mode,database_role from v$database;
The open_mode should be normal 'read-write' mode and 'LOGICAL STANDBY'

8.Are there primary init.ora parameters we should be checking

for ?
LOG_ARCHIVE_DEST_n
Description: Defines an archive log destination and attributes for log transport services.
LOG_ARCHIVE_DEST_STATE_n
Description: Specifies the state of the destination specified by the LOG_ARCHIVE_DEST_n parameter.
LOG_ARCHIVE_FORMAT
Description: Specifies the format for archived redo log filenames.
STANDBY_ARCHIVE_DEST
Description: Used by a standby database to determine the archive location of online redo logs received
from the primary database.
STANDBY_FILE_MANAGEMENT
Description: Enables or disables automatic standby file management.
USER_DUMP_DEST
Description: Specifies the directory path name where the database server will write debugging trace
files on behalf of a user process.

9.I assume system auto start scripts do not apply ?

Does oratab entry have to be set to 'N'
Yes

10.I assume backups do not apply ?

Yes

11.How does auditing work on a standby ? If it is enabled on the

primary what happens to the standby ?
No Audit on the standby, because it is recovery or read only mode

12.Oracle patches details

The Oracle patch for Primary and Standby database must be on the same level.

13.The Standby Site Does Not Receive Logs Archived by the

Primary Database
If the standby site is not receiving the logs, the first thing you should do is obtain information
about the archiving status of the primary database by querying the V$ARCHIVE_DEST view. Check
especially
for error messages. For example, enter the following query:
SQL> SELECT DEST_ID "ID",
STATUS "DB_status",
DESTINATION "Archive_dest",
ERROR "Error"
FROM V$ARCHIVE_DEST;

ID DB_status Archive_dest Error

--------- ------------------------------ ------------------------------------
1 VALID /vobs/oracle/work/arc_dest/arc
2 ERROR standby1 ORA-16012: Archivelog standby database identifier mismatch
3 INACTIVE
4 INACTIVE
5 INACTIVE
5 rows selected.

If the output of the query does not help you, please refer to
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/toc.htm Or metlink
14.What to Do If SQL Apply Operations to a Logical Standby
Database Stop
Log apply services cannot apply unsupported DML statements, DDL statements, and Oracle supplied
packages to a logical standby database in SQL apply mode.
When an unsupported statement or package is encountered, SQL apply operations stop. For details of
troubleshooting, please refer to 'A Troubleshooting Data Guard' from
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/toc.htm

Further reference:
For 10g, http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/toc.htm
For 9i, http://download.oracle.com/docs/cd/B10501_01/server.920/a96653/toc.htm
For RAC,
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/rac_support.htm#SBYDB01700

15.ORA-16181 Error
When you start log apply and get error like ORA-16181, please set MAX_SGA < SHARED_POOL_SIZE *
75%
for example, we have 1GB shared pool size and get error when max_sga is on 1GB.
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
ALTER DATABASE START LOGICAL STANDBY APPLY
*
ERROR at line 1:
ORA-16181: SGA specified for Logical Standby is too large
ORA-06512: at "SYS.DBMS_INTERNAL_LOGSTDBY", line 540
ORA-06512: at line 1

SQL> select * from dba_logstdby_parameters where name like 'MAX%';

NAME
------------------------------
VALUE
--------------------------------------------------------------------------------
MAX_SGA
1024

after changed max_sga from 1GB to 256m:

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SGA', 256);

The problem fixed:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

Database altered.