Data Guard Scenarios

12 Data Guard Scenarios

This chapter describes scenarios you might encounter while administering your Data Guard configuration. Each scenario can be adapted to your specific environment. Table 12-1 lists the scenarios presented in this chapter.

Table 12-1 Data Guard Scenarios

Reference	Scenario
Section 12.1	Setting Up and Verifying Archival Destinations
Section 12.2	Choosing the Best Available Standby Database for a Role Transition
Section 12.3	Configuring a Logical Standby Database to Support a New Primary Database
Section 12.4	Using Flashback Database After a Failover
Section 12.5	Using Flashback Database After Issuing an Open Resetlogs Statement
Section 12.6	Using a Physical Standby Database for Read/Write Testing and Reporting
Section 12.7	Using RMAN Incremental Backups to Roll Forward a Physical Standby Database
Section 12.8	Using a Physical Standby Database with a Time Lag
Section 12.9	Recovering From a Network Failure
Section 12.10	Recovering After the NOLOGGING Clause Is Specified
Section 12.11	Resolving Archive Gaps Manually
Section 12.12	Creating a Standby Database That Uses OMFor ASM

12.1 Setting Up and Verifying Archival Destinations

How to Change Appspassword in R12

How to Change Applications R12 Passwords using Applications Schema Password Change Utility

Since changing passwords frequently helps ensure database security, Oracle Applications provides a command line utility, FNDCPASS, to change/reset Oracle Applications schema passwords. This utility changes the password registered in Oracle Applications tables, changes the schema password in the database and can also change user passwords.
Note: You cannot change a schema name, such as APPLSYS or GL, after a product is installed, with FNDCPASS.
Ensure that the entire Oracle Applications system has been shut down before changing any schema passwords.
All users should log out and the Applications system should be down before running this utility. 
If Oracle Applications user passwords are being changed then the relevant users should not be logged in. 
Before changing any passwords, you should make a backup of the tables FND_USER and FND_ORACLE_USERID.