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:
This chapter contains only the syntax and a brief summary of particular SQL statements. You must refer to the Oracle Database SQL Language Reference for complete syntax and descriptions about these and other SQL statements.
See Chapter 14 for a list of initialization parameters that you can set and dynamically update using the ALTER SYSTEM SET
statement.
Table 16-1 describes ALTER DATABASE
statements that are relevant to Data Guard.
Table 16-1 ALTER DATABASE Statements Used in Data Guard Environments
ALTER DATABASE Statement | Description |
---|---|
|
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 9.3.5 for an example of this statement. |
|
Adds new members to existing online redo log file groups or standby redo log file groups. |
|
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 See Oracle Database SQL Language Reference for more information. |
|
Note: On logical standby databases, you issue the See Section 8.2.1 and Section 8.3.1 for examples of this statement. Also see Oracle Database SQL Language Reference for information about the complete syntax for this statement. |
Converts a physical standby database into a snapshot standby database and vice versa. |
|
|
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. |
|
Drops all members of an online redo log file group or standby redo log file group. See Section 9.3.5 for an example of this statement. |
|
Drops one or more online redo log file members or standby redo log file members. |
|
The primary database must at least be mounted (and it can also be open) when you issue this statement. See Section 3.1.1 for an example of this statement. |
|
Controls user access to tables in a logical standby database. Possible values are |
|
Mounts a standby database, allowing the standby instance to receive redo data from the primary instance. |
|
Opens a previously started and mounted database:
|
|
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 See Section 8.3.1 for examples of this statement. Also see Oracle Database SQL Language Reference for information about the complete syntax for this statement. |
|
This statement starts and controls Redo Apply on physical standby databases. You can use the Note: Several clauses and keywords were deprecated and are supported for backward compatibility only. See Oracle Database SQL Language Reference for more information about these clauses. |
|
The Note: Several clauses and keywords were deprecated and are supported for backward compatibility only. See Oracle Database SQL Language Reference for more information about these clauses. |
|
The See Step 4 in Section 8.2.2 for examples. Note: Several clauses and keywords were deprecated and are supported for backward compatibility only. See Oracle Database SQL Language Reference for more information about these clauses. |
|
Note: This command should be issued only after manually copying the corresponding archived redo log file to the standby database. Issuing this command while the log file is in the process of being copied or when the log file does not exist may result in errors on the standby database at a later time. |
|
Instructs 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. |
|
Resets the target recovery incarnation for the database from the current incarnation to a different incarnation. |
|
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. |
|
This statement is for logical standby databases only.It starts SQL Apply on a logical standby database. See Section 7.4.1 for examples of this statement. |
This statement is for logical standby databases only.Use the |
|
Performs a failover. The standby database must be mounted before it can be activated with this statement. Note: Do not use the
|
Table 16-2 describes the ALTER SESSION
statements that are relevant to Data Guard.
Table 16-2 ALTER SESSION Statements Used in Data Guard Environments
ALTER SESSION Statement | Description |
---|---|
|
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 10.5.4 for more information. |
|
This statement is for physical standby databases only. This statement synchronizes a physical standby database with the primary database, by blocking until all redo data received by the physical standby at the time of statement invocation has been applied. See Section 9.2.1.3 for more information. |
Table 16-3 describes the ALTER SYSTEM
statements that are relevant to Data Guard.
Table 16-3 ALTER SYSTEM Statements Used in Data Guard Environments
ALTER SYSTEM Statement | Description |
---|---|
|
This statement flushes redo data from a primary database to a standby database and optionally waits for the flushed redo data to be applied to a physical or logical standby database. This statement must be issued on a mounted, but not open, primary database. |