Physical Standby Database

Primary and standby databases (database roles) In a standby environment, one database is a primary database while all others are standby databases. Standby databases are either physical or logical standby databases. Query the database_role column in v$database in order to find out the role of a database A standby database environment is meant for disastrous failures. It protects the data even if a machine is wrecked beyond recognition. Therefore, it makes no sense to put a primary and a standby database on the same hardware. A logical standby turns redo into inserts, updates and deletes, while a physical standby directly applies redo to its datafiles.

Primary database In a standby environment, exactly one database is a primary database. All the other databases are standby databases.

Logical standby database The logical standby database is new with Oracle 9iR2. The key advantage for logical standby databases is that they're opened read/write, even while they're in applied mode. That is, they can be used to generate reports and the like. It is indeed a fully functional database. Also, additional indexes, materialized views and so on can be created. However (this being a disadvantage) not all datatypes are supported. Oracle (or more exactly the log apply services) uses the primary database's redo log, transforms them into SQL statements and replays them on the logical standby database.

Physical standby database A physical standby database is a byte for byte exact copy of the primary database. This also means that rowids stay the same in a physical standby database environment. Oracle (or more exactly the log apply services) uses the primary database's redo log to recover the physical database. A physical standby database might be opened read only; however, the received logs are in this case not applied. When the logs are applied, the database is not accessible (it is then in a managed recovery state).

1

A standby environment It is possible for some standby databases in a standby environment to be logical standby databases while the other standby databases are physical standby databases.

Creating a physical standby database A physical standby database is created from an existing other database. This other database will then be the primary database. In this text, it is assumed that the primary database uses a spfile. Getting the primary database ready The primary database must meet two conditions before a standby database can be created from it: • •

it must be in force logging mode and it must be in archive log mode (also automatic archiving must be enabled and a local archiving destination must be defined.

Use v$database.force_logging to determine if a database is in force logging mode. If not, enable it like so: SQL> select name, FORCE_LOGGING from v$database; NAME FOR --------- --MSB NO SQL> alter database force logging; SQL> select name, FORCE_LOGGING from v$database; NAME FOR --------- --MSB YES Use v$database.log_mode to determine if a database is in archive log mode. If not, enable it. The (local) archive destination should be specified like so: SQL> alter system set log_archive_dest_1='LOCATION=c:\oracle\oradb\arch MANDATORY' scope=both;

Creating the standby database Copying the datafiles The standby database is created from the existing datafiles of the primary database. These can be queried from the v$datafile view:

2

SQL> select name from v$datafile; These files must be copied to the standby database. However, the primary database must be shut down before they can be copied. SQL> shutdown immediate; After copying the datafiles, the primary database can be started up again. SQL> startup

Creating a standby database control file A control file needs to be created for the standby system. Execute the following on the primary system: SQL> alter database create standby controlfile as '/some/path/to/a/file' The created file must meet two conditions: • •

Its filename must be different from any other control file Must be created after the backup of the datafiles.

Creating an init file A pfile is created from the spfile. This pfile needs to be modified and then be used on the standby system to create a spfile from it. create pfile='/some/path/to/a/file' from spfile The following parameters must be modified or added: • • • • • • • • • •

control_files standby_archive_dest db_file_name_convert (only if directory structure is different on primary and standby server) log_file_name_convert (only if directory structure is different on primary and standby server) log_archive_format Log_archive_dest_1 This value is used if a standby becomes primary during a switchover or a failover. standby_file_management Set to auto(??) remote_archive_enable Set it to true(??) instance_name lock_name_space (Only if standby and primary are on the same server. This makes no sense anyway)

3

Creating an oracle service (if on windows) If the environment is running on windows, create a new oracle service on the standby system with oradim: oradim -new -sid stdby -startmode manual

Configuring the listener sqlnet.expire_time=2 In order to enable dead connection time, specify sqlnet.expire_time=2 (or any other appropriate value). Creating net service names net service names must be created on both the primary and standby database that will be used by log transport services. That is: something like to following lines must be added in the tnsnames.ora. TO_STANDBY = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = stdby_host)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = stdby) ) ) Creating the spfile on the standby database On the still idle standby database, the pfile is turned into an spfile. Then the instance is started up. set ORACLE_SID=stdby sqlplus "/ as sysdba" create spfile from pfile='/.../../modified-pfile'; Then, the standby database needs to be started as a physical standby database, however, without recovering: startup nomount alter database mount standby database; Creating standby redo logs On the standby database, standby redo logs can be created (if lgwr transmission is to be used).

4

alter database add standby logfile '/some/path/file_1.log' size 1M, '/some/path/file_2.log' size 1M, '/some/path/file_3.log' size 1M; Archiving to the standby from the primary alter system set log_archive_dest_2='service=to_standby lgwr' scope=both; alter system set log_archive_dest_state_2=enable scope=both;

Putting standby in recovery mode alter database recover managed standby database disconnect from session;

Verify environment After everything has been done, verify the physical standby database.

5