15 SQL Statements Relevant to Data Guard

This chapter summarizes the SQL and SQL*Plus statements that are useful for performing operations on standby databases in a Data Guard environment. This chapter includes the following topics:

ALTER DATABASE Statements
ALTER SESSION Statements

This chapter contains only the syntax and a brief summary of particular SQL statements. You must refer to the.Oracle Database SQL Reference for complete syntax and descriptions about these and other SQL statements

See Chapter 13 for a list of initialization parameters that you can set and dynamically update using the ALTER SYSTEM SET statement.

15.1 ALTER DATABASE Statements

Table 15-1 describes ALTER DATABASE statements that are relevant to Data Guard.

Table 15-1 ALTER DATABASE Statements Used in Data Guard Environments

ALTER DATABASE Statement	Description
`ADD` `[STANDBY`] `LOGFILE [THREAD` integer`] [GROUP` integer`]` `filespec`	Adds one or more online redo log file groups or standby redo log file groups to the specified thread, making the log files available to the instance to which the thread is assigned. See Section 8.3.5 for an example of this statement.
`ADD [STANDBY`] `LOGFILE` `MEMBER` 'filename' `[REUSE]` `TO` logfile-descriptor	Adds new members to existing online redo log file groups or standby redo log file groups. See Section 5.7.3.2 for an example of this statement.
`[ADD`\|`DROP`] `SUPPLEMENTAL` `LOG` `DATA {PRIMARY KEY\|UNIQUE INDEX}` `COLUMNS`	This statement is for logical standby databases only. Use it to enable full supplemental logging before you create a logical standby database. This is necessary because supplemental logging is the source of change to a logical standby database. To implement full supplemental logging, you must specify either the `PRIMARY KEY COLUMNS` or the `UNIQUE INDEX COLUMNS` keyword on this statement. See Oracle Database SQL Reference for more information.
`COMMIT TO SWITCHOVER TO [[PRIMARY] \| [[PHYSICAL\|LOGICAL] [STANDBY]][WITH \| WITHOUT] SESSION SHUTDOWN] [WAIT \| NOWAIT]`	Performs a switchover to: Change the current primary database to the standby database role Change one standby database to the primary database role. Note: On logical standby databases, you issue the `ALTER DATABASE PREPARE TO SWITCHOVER` statement to prepare the database for the switchover before you issue the `ALTER DATABASE COMMIT TO SWITCHOVER` statement. See Section 7.2.1 and Section 7.3.1 for examples of this statement.
`CREATE [PHYSICAL\|LOGICAL] STANDBY CONTROLFILE AS '`filename`' [REUSE]`	Creates a control file to be used to maintain a physical or a logical standby database. Issue this statement on the primary database. See Section 3.2.2 for an example of this statement.
`DROP [STANDBY] LOGFILE` logfile_descriptor	Drops all members of an online redo log file group or standby redo log file group. See Section 8.3.5 for an example of this statement.
`DROP [STANDBY] LOGFILE MEMBER` 'filename'	Drops one or more online redo log file members or standby redo log file members.
`[NO]FORCE LOGGING`	Controls whether or not the Oracle database logs all changes in the database except for changes to temporary tablespaces and temporary segments. The `[NO]FORCE LOGGING` clause is required to prevent inconsistent standby databases.: The primary database must be mounted but not open when you issue this statement. See Section 3.1.1 for an example of this statement.
`MOUNT` [`STANDBY DATABASE`]	Mounts a standby database, allowing the standby instance to receive redo data from the primary instance.
`OPEN`	Opens a previously started and mounted database: Physical standby databases are opened in read-only mode, restricting users to read-only transactions and preventing the generating of redo data. Logical standby database are opened in read/write mode. See Section x.x for an example of this statement.
`PREPARE` `TO` `SWITCHOVER TO[PRIMARY] \| [[PHYSICAL\|LOGICAL] [STANDBY]][WITH \| WITHOUT] SESSION SHUTDOWN] [WAIT \| NOWAIT]`	This statement is for logical standby databases only. It prepares the primary database and the logical standby database for a switchover by building the LogMiner dictionary before the switchover takes place. After the dictionary build has completed, issue the `ALTER DATABASE COMMIT TO SWITCHOVER` statement to switch the roles of the primary and logical standby databases. See Section 7.3.1 for examples of this statements.
`RECOVER` `MANAGED` `STANDBY` `DATABASE [[NO TIMEOUT\|TIMEOUT [`integer`] ] [NODELAY]\|DELAY [`integer`] ] [DEFAULT DELAY] [DISCONNECT [FROM SESSION]][NO EXPIRE\|EXPIRE [`integer`] ][NEXT [`integer`]][NOPARALLEL\|PARALLEL [`integer`]][NOTIMEOUT\|TIMEOUT [integer]][THROUGH {ALL\|NEXT\|LAST SWITCHOVER][THROUGH [THREAD` n`] SEQUENCE` n`][ALL ARCHIVELOG][UNTIL CHANGE` scn`][USING CURRENT LOGFILE] ]`	This statement starts and controls Redo Apply on physical standby databases . You can use the `RECOVER MANAGED STANDBY DATABASE` clause on a physical standby database that is mounted, open, or closed. See Step 2 in Section 3.2.6 and Section 6.3 for examples. Note: Several clauses and keywords were deprecated and are supported for backward compatibility only. See Appendix F, "Changed and Deprecated Features" for more information.
`RECOVER` `MANAGED` `STANDBY` `DATABASE` `CANCEL` `[[NOWAIT]\|[WAIT][IMMEDIATE] ]`	The `CANCEL` clause cancels Redo Apply on a physical standby database after applying the current archived redo log file.
`RECOVER` `MANAGED` `STANDBY` `DATABASE` `FINISH` [`FORCE`][`NOWAIT`\|`WAIT`] ]	The `FINISH` clause initiates failover on the target physical standby database and recovers the current standby redo log files. Use the `FINISH` clause only in the event of the failure of the primary database. This clause overrides any delay intervals specified. Include `FORCE` to terminate the RFS processes and allow the failover to occur immediately, without waiting for the RFS process to exit. Specify `NOWAIT` to have control returned immediately, rather than after the recovery process is complete. See Step 4 in Section 7.2.2 for examples.
`REGISTER [OR REPLACE] [PHYSICAL\|LOGICAL] LOGFILE` `filespec`	Allows the registration of manually archived redo log files. See Section 5.8.4 for an example of this statement.
`RECOVER TO LOGICAL STANDBY` new_database_name	Instructs log apply services to continue applying changes to the physical standby database until you issue the command to convert the database to a logical standby database. See Section 4.2.4.1 for more information.
`RESET DATABASE TO INCARNATION` integer	Resets the target recovery incarnation for the database from the current incarnation to a different incarnation.
`SET` `STANDBY` `DATABASE` `TO` `MAXIMIZE` {`PROTECTION`\|`AVAILABILITY`\|`PERFORMANCE`}	Use this clause to specify the level of protection for the data in your Data Guard configuration. You specify this clause from the primary database, which must be mounted but not open.
`START LOGICAL STANDBY APPLY INITIAL` [scn-value] ] [`NEW PRIMARY` dblink]	This statement is for logical standby databases only.It starts SQL Apply on a logical standby database. See Section 6.4.1 for examples of this statement.
`{STOP\|ABORT} LOGICAL STANDBY APPLY`	This statement is for logical standby databases only.Use the `STOP` clause to stop SQL Apply on a logical standby database in an orderly fashion. Use the `ABORT` clause to stop SQL Apply abruptly. See Section 7.3.2 for an example of this statement.
`ACTIVATE [PHYSICAL\|LOGICAL] STANDBY DATABASE FINISH APPLY]`	Performs a failover. The standby database must be mounted before it can be activated with this statement. Note: Do not use the `ALTER DATABASE ACTIVATE STANDBY DATABASE` statement to failover because it causes data loss. Instead, use the following best practices: For physical standby databases, use the `ALTER DATABASE RECOVER MANAGED STANDBY DATABASE` statement with the `FINISH` keyword to perform the role transition as quickly as possible with little or no data loss and without rendering other standby databases unusable. Note: The failover operation adds an end-of-redo marker to the header of the last log file being archived and sends the redo to all enabled destinations that are valid for the primary role (specified with the `VALID_FOR=(PRIMARY_ROLE, _LOGFILES)` or the `VALID_FOR=(ALL_ROLES, _LOGFILES)` attributes). For logical standby databases, use the `ALTER DATABASE PREPARE TO SWITCHOVER` and `ALTER DATABASE COMMIT TO SWITCHOVER` statements.

15.2 ALTER SESSION Statements

Table 15-2 describes an ALTER SESSION statement that is relevant to Data Guard.

Table 15-2 ALTER SESSION Statement Used in Data Guard Environments

ALTER SESSION Statement Description

ALTER SESSION Statement	Description
`ALTER` `SESSION` [`ENABLE`\|`DISABLE`] `GUARD`	This statement is for logical standby databases only. This statement allows privileged users to turn the database guard on and off for the current session. See Section 7.3.2 for an example of this statement.

ALTER SESSION [ENABLE|DISABLE] GUARD

This statement is for logical standby databases only.

This statement allows privileged users to turn the database guard on and off for the current session.

See Section 7.3.2 for an example of this statement.