2 Using a Standby Database That Is Open for Read-Only Access

Using a Standby Database That Is Open for Read-Only Access



Figure 8–1 Standby Database Open for Read-Only Access



Primary

Database



Online Redo

Logs



Archived Redo

Logs



Local

Archiving

0001

0001



Read / Write

Transactions



0002

0002



Log

Transport

Services



0003



San Francisco

Boston



Application

Queries



Archived

Redo Logs



Log

Apply

Services



Standby

Database

in Read-Only

Mode



This section contains the following topics:

s



Assessing Whether or Not to Open a Standby Database for Read-Only Access



s



Opening a Physical Standby Database for Read-Only Access



s



Sorting Considerations for Standby Databases Open for Read-Only Access



8.2.1 Assessing Whether or Not to Open a Standby Database for Read-Only Access

As you decide whether or not to open a physical standby database for read-only

access, consider the following:

s



8-4



When a physical standby database is open for read-only access, redo data from

the primary database is received by the standby database, but the log files are

not applied. Therefore, a standby database that is open for read-only access is

not current with the primary database. At some point, you need to resume Redo

Apply on the standby database, and apply the archived redo log files to



Oracle Data Guard Concepts and Administration



Using a Standby Database That Is Open for Read-Only Access



resynchronize the standby database with the primary database. Because of the

additional time required to apply any accumulated archived redo log files,

having a standby database open for read-only access can increase the time

required to complete failovers or switchovers.

s



You can to use a standby system for reporting purposes and also maintain the

ability to complete a failover or switchover quickly if you configure more than

one standby database on the standby system. For example, based on your

business requirements and the system resources available on the standby

system, you might:

–



Configure two physical standby databases on the standby system with one

standby database always performing Redo Apply to be as current as

possible with the primary database and the other standby database open in

read-only mode during business hours for reporting purposes.



–



Configure a physical standby database on the standby system to maintain a

block-for-block copy of the primary database for disaster recovery purposes

and also configure a logical standby database to off-load reporting tasks

that require access to the latest data from the primary database.



When configuring more than one standby database on the same system,

consider using the DEPENDENCY attribute of the LOG_ARCHIVE_DEST_n

initialization parameter to define one archival destination to receive redo data

on behalf of all of the destinations, rather than transmitting redo data to each

individual destination. See Section 5.7.5 for more information.



8.2.2 Opening a Physical Standby Database for Read-Only Access

You can alternate between having a physical standby database open for read-only

access and performing Redo Apply using the following procedures.



To open a standby database for read-only access when it is currently

shut down:

Start, mount, and open the database for read-only access using the following

statement:

SQL> STARTUP;



To open a standby database for read-only access when it is currently

performing Redo Apply or real-time apply:

1.



Cancel Redo Apply or real-time apply:



Managing a Physical Standby Database



8-5



Using a Standby Database That Is Open for Read-Only Access



SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

2.



Open the database for read-only access:

SQL> ALTER DATABASE OPEN;



You do not need to shut down the instance to open it for read-only access.

Note: By default, the ALTER DATABASE OPEN statement opens



physical standby databases in read-only mode. The Oracle database

determines if this is a physical standby database based on

information in the control file.



To change the standby database from being open for read-only access

to performing Redo Apply:

1.



Terminate all active user sessions on the standby database.



2.



Restart Redo Apply or real-time apply. To start Redo Apply, issue the following

statement:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

2> DISCONNECT FROM SESSION;



To start real-time apply, issue the following statement:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

2> USING CURRENT LOGFILE;



You do not need to shut down the instance to start either of these apply modes.



8.2.3 Sorting Considerations for Standby Databases Open for Read-Only Access

Before you open your standby database for read-only access, consider the following

topics regarding sorting operations:

s



Sorting Operations While the Database Is Open for Read-Only Access



s



Sorting Operations Without Temporary Tablespaces



8.2.3.1 Sorting Operations While the Database Is Open for Read-Only Access

To perform queries that sort a large amount of data on a standby database that is

open for read-only access, the Oracle database must be able to perform on-disk



8-6



Oracle Data Guard Concepts and Administration



Using a Standby Database That Is Open for Read-Only Access



sorting. You cannot allocate space for sorting in tablespaces that cause Oracle

software to write to the data dictionary.

Temporary tablespaces allow you to add tempfile entries when the database is

open for read-only access for the purpose of making queries without affecting

dictionary files or generating redo entries. Therefore, you can use temporary

tablespaces as long as you follow these requirements for creating them:

s



s



s



The tablespaces must be temporary, locally managed, and contain only

temporary files.

User-level allocations and permissions to use the locally managed temporary

tablespaces must be in place on the primary database. You cannot change these

settings on the standby database.

You must create and associate a temporary file for the temporary tablespace on

the standby database.



To create a temporary tablespace for use on a read-only physical

standby database:

If you did not have a temporary tablespace on the primary database when you

created the physical standby database, perform the following steps on the primary

database:

1.



Enter the following SQL statement:

SQL> CREATE TEMPORARY TABLESPACE temp1

TEMPFILE '/disk1/oracle/oradata/payroll/temp1.dbf'

SIZE 20M REUSE

EXTENT MANAGEMENT LOCAL UNIFORM SIZE 16M;



2.



Switch the log file to send the redo data to the standby database:

SQL> ALTER SYSTEM SWITCH LOGFILE;



To create and associate a temporary file with a temporary tablespace on

a read-only physical standby database:

The redo data that is generated on the primary database automatically creates the

temporary tablespace in the standby control file after the archived redo log file is

applied to the physical standby database. However, even if the temporary

tablespace existed on the primary database before you created the physical standby

database, you must use the ADD TEMPFILE clause to actually create the disk file on

the standby database.

On the physical standby database, perform the following steps:



Managing a Physical Standby Database



8-7



Using a Standby Database That Is Open for Read-Only Access



1.



Start Redo Apply or real-time apply, if necessary, and apply the archived redo

log files. To start Redo Apply, issue the following SQL*Plus statement:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

2> DISCONNECT FROM SESSION;



To start real-time apply, issue the following statement:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

2> USING CURRENT LOGFILE;

2.



Connect to the standby database and query the V$ARCHIVED_LOG view to

verify all of the archived redo log files have been applied:

SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG

2> ORDER BY SEQUENCE#;

SEQUENCE# APP

--------- --8 YES

9 YES

10 YES

11 YES

4 rows selected.



3.



Cancel log apply services and open the physical standby database for read-only

access using the following SQL statements:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL> ALTER DATABASE OPEN;



Opening the physical standby database for read-only access enables you to add

a temporary file. Because adding a temporary file does not generate redo data,

it is allowed for a database that is open for read-only access.

4.



Create a temporary file for the temporary tablespace. The size and names for

the files can differ from the primary database. For example:

SQL> ALTER TABLESPACE temp1

ADD TEMPFILE '/disk1/oracle/oradata/payroll/s_temp1.dbf'

SIZE 10M REUSE;



8.2.3.2 Sorting Operations Without Temporary Tablespaces

If a temporary file does not exist on the standby database, or if the standby database

is not open and you attempt to sort a large amount of data, an error is returned, as

shown in the following example.



8-8



Oracle Data Guard Concepts and Administration



Managing Primary Database Events That Affect the Standby Database



SQL> SELECT * FROM V$PARAMETER;

select * from v$parameter

*

ERROR at line 1:

ORA-01220: file based sort illegal before database is open



Note that you can, however, sort small amounts of data if the SORT_AREA_SIZE

parameter is set to a sufficient value in your server parameter file. (The SORT_

AREA_SIZE parameter is a static parameter. See Oracle Database Reference for

information about setting this initialization parameter.)



8.3 Managing Primary Database Events That Affect the Standby

Database

To prevent possible problems, you must be aware of events in the primary database

that affect a standby database and learn how to respond to them. This section

describes these events and the recommended responses to these events.

In some cases, the events or changes that occur on a primary database are

automatically propagated through archived redo log files to the standby database

and thus require no extra action on the standby database. In other cases, you might

need to perform maintenance tasks on the standby database.

Table 8–1 indicates whether or not a change made on the primary database requires

additional intervention by the database administrator (DBA) to be propagated to

the standby database. It also briefly describes how to respond to these events.

Detailed descriptions of the responses are described in the section references

provided.

The following events are automatically administered by log transport services and

log apply services, and therefore require no intervention by the database

administrator:

s



s



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).



Managing a Physical Standby Database



8-9



Managing Primary Database Events That Affect the Standby Database



s



A datafile is added or tablespace is created when the STANDBY_FILE_

MANAGEMENT initialization parameter is set to AUTO.



Table 8–1



Actions Required on a Standby Database After Changes to a Primary Database



Reference



Change Made on Primary Database Action Required on Standby Database



Section 8.3.1



Add a datafile or create a tablespace



Section 8.3.2



Drop or delete a tablespace or datafile Delete datafiles from primary and standby databases

after the archived redo log file containing the DROP or

DELETE command was applied.



Section 8.3.3



Use transportable tablespaces



Move tablespaces between the primary and standby

databases.



Section 8.3.4



Rename a datafile



Rename the datafile on the standby database.



Section 8.3.5



Add or drop redo log files



Synchronize changes on the standby database.



Section 8.3.6



Alter the primary database control

file (using the SQL ALTER

DATABASE CREATE CONTROLFILE

statement)



Re-create the standby control file or re-create the standby

database, depending on the alteration made.



Section 8.3.7



Perform a DML or DDL operation

using the NOLOGGING or

UNRECOVERABLE clause



Send the datafile containing the unlogged changes to the

standby database.



Chapter 11



Change initialization parameters



Dynamically change the standby parameters or shut

down the standby database and update the initialization

parameter file.



If you did not set the STANDBY_FILE_MANAGEMENT

initialization parameter to AUTO, you must copy the new

datafile to the standby database.



8.3.1 Adding a Datafile or Creating a Tablespace

The initialization parameter, STANDBY_FILE_MANAGEMENT, enables you to control

whether or not adding a datafile to the primary database is automatically

propagated to the standby database, as follows:

s



s



8-10



If you set the STANDBY_FILE_MANAGEMENT initialization parameter in the

standby database server parameter file (SPFILE) 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.



Oracle Data Guard Concepts and Administration