加载中…
正文 字体大小:

Using Oracle 11g's Active Data Guard and Snapshot Standby Features

(2011-04-27 15:19:33)
标签:

杂谈

分类: RAC

Using Oracle 11g's Active Data Guard and Snapshot Standby Features

By Jim Czuprynski

 

Synopsis.Oracle Database 11g expands dramatically the ability to leverage a physical standby database for simultaneous support of both disaster recovery as well as intensive query activity. This article – the fifth in this ongoing series – also illustrates how Oracle 11g’s new snapshot standby features leverage a physical standby database for application quality assurance testing, including the new Real Application Testing suite.

The prior article in this series explored how to:

  • Use a recovery catalog to catalog backups made on the standby database
  • Create incrementally updateable image copy backups from a standby database
  • Implement block change tracking on a standby database

This article will discuss:

  • How to leverage Oracle 11g Data Guard Real Time Query features
  • How Oracle 11g Data Guard snapshot standby database features simultaneously provide disaster recovery and quality assurance testing environments

Active Data Guard: Real-Time Queries During Managed Recovery

Prior to Oracle Database 11g, the DBA could opt for one of two mutually-exclusive choices for a physical standby databases operating mode:

  • The database could operate in Managed Recovery mode, in which redo data would be applied as soon as it was received from the corresponding primary database. The physical standby would thus be available immediately for transition to the primary role during either a switchover or a failover operation.
  • Alternatively, the database could be opened in READ ONLY mode so that applications could execute queries against it. This offered the ability to leverage the physical standby database platform for the intensive read operations that data warehousing, DSS, and OLAP applications typically perform, thus offloading that workload from the production database.

While it was certainly possible to maintain two physical standby databases – one in managed recovery mode, and another in READ ONLY mode – to satisfy both requirements, it also potentially increased licensing costs and the complexity of the Data Guard environment. Thankfully, Oracle 11g now offers the capability to satisfy both modes within one physical standby database with Real Time Query, part of the separately licensable Active Data Guard option.

Enabling Active Data Guard. To activate this feature, I’ll first disable application of redo on the physical standby database. Since I’ve already enabled a Data Guard configuration, I’ll issue the appropriate commands via the DGMGRL command line utility against that database:


[oracle@11gPrimary ~]$ echo $ORACLE_SID
orcl_stdby1

$> dgmgrl
Copyright (c) 2000, 2005, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys/oracle
Connected.
DGMGRL> edit database orcl_stdby1 set state=apply-off;
Succeeded.
DGMGRL> show database orcl_stdby1

Database
  Name:            orcl_stdby1
  Role:            PHYSICAL STANDBY
  Enabled:         YES
  Intended State:  APPLY-OFF
  Instance(s):
    orcl_stdby1

Next, I’ll connect to the physical standby database and issue the ALTER DATABASE OPEN; command from within a SQL*Plus session to activate Active Data Guard. I’ve shown the results of issuing this command reflected in the alert log of the ORCL_STDBY1 database in Listing 5.1. Finally, I’ll reactivate redo application via DGMRGL commands:


DGMGRL> edit database orcl_stdby1 set state=apply-on;
Succeeded.
DGMGRL> show database orcl_stdby1;

Database
  Name:            orcl_stdby1
  Role:            PHYSICAL STANDBY
  Enabled:         YES
  Intended State:  APPLY-ON
  Instance(s):
    orcl_stdby1

At this point, the physical standby database is open in READ ONLY mode, but it’s simultaneously receiving and applying redo from its counterpart primary database.

Disabling Active Data Guard. Once activated, Active Data Guard’s Real-Time Query feature is equally simple to deactivate. All the DBA needs to do is:

  • Disable application of redo on the physical standby database using DGMGRL
  • Shut down the physical standby database
  • Restart the physical standby database instance in MOUNT mode
  • Re-enable application of redo on the physical standby database using DGMGRL

Since the physical standby database has been already configured for managed recovery via Data Guard Broker, the database’s DMON background process will automatically restart the Managed Recovery Process (MRP0) once redo application has been re-established.

Leveraging Snapshot Standby Database for Effective Application Testing

While I’ve got to admit that the new Active Data Guard features are impressive, Oracle 11g Data Guard also offers a new type of standby database - a snapshot standby - that simultaneously provides disaster recovery capabilities while also performing quality assurance testing against the same database because it’s also open in READ WRITE mode. A snapshot standby database therefore promises several advantages not available in prior releases:

Reduced database licensing costs. Since I can now easily transform a physical standby database from its disaster recovery mode into application testing mode, this translates into one less Oracle 11g database that needs to be licensed.

Reduced hardware costs. One less Oracle database also means one less database server. Now instead of having to justify the additional hardware costs of providing a QA environment, I’m able to provide it for essentially the same cost as the disaster recovery environment. And I can take advantage of those savings to justify duplicating the hardware environment for the primary database server because it will eliminate one additional variable – the system configuration itself - when I’m deep in the throes of system or integration testing of a new application software release.

Real Application Testing. A snapshot standby database is a perfect complement to Oracle 11g’s new Real Application Testing suite because it’s an excellent platform on which to replay a previously-recorded workload. The DBA can capture a representative workload from any Oracle 9iR2 (release 9.2.0.8) Oracle 10gR2 (release 10.2.0.4), or Oracle 11gR1 (release 11.1.0.6) database and then play it back on a snapshot standby database that’s configured in what I’ve termed “production plus one” (P+1) mode to determine if any performance, data, or error regression might occur when transitioning the application workload to Oracle 11g. (Please see my article series on Database Workload Capture and Replay for an in-depth discussion of this topic.)

Preconditions. It’s important to note some key prerequisites for creating a standby database:

  • Only a physical standby database can become a snapshot standby database. A logical standby database cannot be transformed into a snapshot standby for rather obvious reasons: Logical standby databases aren’t required to be an exact duplicate of the primary database, and they use a totally different method – SQL Apply – to apply redo information.
  • Flashback Logging must be enabled. Flashback Logging must have been enabled on both the primary database as well as the corresponding physical standby database that’s the target of the conversion. This means that a suitably-sized Flash Recovery Area is present, and it must be large enough to retain all recovery files necessary to return the original physical standby database to its prior state before being transformed to a snapshot standby database.

Creating a Snapshot Standby Database: An Example

Oracle Database 11g leverages the powerful Flashback Database features introduced in Oracle 10g to implement the transition between physical standby and snapshot standby modes, and the Data Guard Broker accomplishes the transition with a single command: CONVERT DATABASE. Transitioning from physical standby mode to snapshot standby mode involves three phases:

1.) Managed recovery is terminated. First, the physical standby database’s Managed Recovery Process (MRP0) is shut down, and then the physical standby database is shut down. Note that redo logs will still be received at the standby site – they just aren’t going to be applied until after physical standby mode is restored at a later time.

2.) A guaranteed restore point is created. Next, the physical standby database is opened in MOUNT mode and a guaranteed restore point is created. Once a guaranteed restore point is created, Oracle literally guarantees that all files necessary to perform a point-in-time recovery of the database to that specified point in time will be retained until the guaranteed restore point is destroyed. (Without a guaranteed restore point, Oracle might start deleting Flashback Logs in FIFO order when the database’s Flash Recovery Area approached overflow capacity, and that would make it impossible to “rewind” the physical standby database to the state it was in prior to becoming a snapshot standby database.)

3) A newly-incarnated snapshot standby database is opened. Finally, the physical standby database is opened in READ WRITE mode as a snapshot standby by incrementing its current incarnation. At this point, any user can now access the snapshot standby database if it were an exact copy of the production database – which, of course, it is! – and perform any desired application testing until either the testing phase is completed, or disaster recovery is required.

To illustrate how to transmogrify a physical standby into a snapshot standby database via Data Guard Broker, I’ll first create a few new database objects in my production database so I can modify them after the snapshot database has been activated:


-----
-- Create new sequence
-----
DROP SEQUENCE hr.seq_empl_id;
CREATE SEQUENCE hr.seq_empl_id
    MINVALUE 0
    MAXVALUE 999999999999
    START WITH 100
    CACHE 1000
    NOCYCLE;

-----
-- Create new table
-----
DROP TABLE hr.new_employees PURGE;
CREATE TABLE hr.new_employees
   TABLESPACE example
    AS
        SELECT employee_id, last_name, first_name, salary 
          FROM hr.employees
         WHERE 1 = 0;

-----
-- Now populate additional data into the table
-----
INSERT INTO hr.new_employees 
SELECT hr.seq_empl_id.NEXTVAL, last_name, first_name, salary FROM hr.employees;
INSERT INTO hr.new_employees 
SELECT hr.seq_empl_id.NEXTVAL, last_name, first_name, salary FROM hr.new_employees;
INSERT INTO hr.new_employees 
SELECT hr.seq_empl_id.NEXTVAL, last_name, first_name, salary FROM hr.new_employees;
INSERT INTO hr.new_employees 
SELECT hr.seq_empl_id.NEXTVAL, last_name, first_name, salary FROM hr.new_employees;
INSERT INTO hr.new_employees 
SELECT hr.seq_empl_id.NEXTVAL, last_name, first_name, salary FROM hr.new_employees;
INSERT INTO hr.new_employees 
SELECT hr.seq_empl_id.NEXTVAL, last_name, first_name, salary FROM hr.new_employees;
INSERT INTO hr.new_employees 
SELECT hr.seq_empl_id.NEXTVAL, last_name, first_name, salary FROM hr.new_employees;

COMMIT;

-----
-- Create primary key (PK) index and constraint
-----
ALTER TABLE hr.new_employees
    ADD CONSTRAINT new_employees_pk 
    PRIMARY KEY (employee_id)
    USING INDEX (
        CREATE INDEX hr.new_employees_pk_idx
            ON hr.new_employees (employee_id)
            TABLESPACE example
    );

Here’s the results of some queries run against the production database’s data dictionary and the new table I created there:


SELECT
     owner
    ,index_name
  FROM dba_indexes
 WHERE table_owner = 'HR'
   AND table_name = 'NEW_EMPLOYEES';

OWNER                          INDEX_NAME
------------------------------ ------------------------------
HR                             NEW_EMPLOYEES_PK_IDX

-----
-- Capture some statistics from the newly-created table
-----
SELECT
     COUNT(*) tot_emps
    ,MIN(employee_id)
    ,MAX(employee_id)
    ,AVG(salary)
    ,MIN(salary)
    ,MAX(salary)
  FROM hr.new_employees;

  TOT_EMPS MIN(EMPLOYEE_ID) MAX(EMPLOYEE_ID) AVG(SALARY) MIN(SALARY) MAX(SALARY)
---------- ---------------- ---------------- ----------- ----------- -----------
      6848              100             6947  6517.75701        2100       30000

Next, I’ll open a DGMGRL session, connect to my primary database, and issue the appropriate flavor of the CONVERT DATABASE command to complete the transformation of the current physical standby database (ORCL_STDBY1) to a snapshot standby database:


[oracle@11gPrimary ~]$ dgmgrl
DGMGRL for Linux: Version 11.1.0.6.0 - Production

Copyright (c) 2000, 2005, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys/oracle
Connected.
DGMGRL> show configuration

Configuration
  Name:                MAA_orcl
  Enabled:             YES
  Protection Mode:     MaxPerformance
  Databases:
    orcl_primary - Primary database
    orcl_stdby1  - Physical standby database

Fast-Start Failover: DISABLED

Current status for "MAA_orcl":
SUCCESS

DGMGRL> CONVERT DATABASE orcl_stdby1 TO SNAPSHOT STANDBY;
Converting database "orcl_stdby1" to a Snapshot Standby database, please wait...

Database "orcl_stdby1" converted successfully
DGMGRL> show configuration

Configuration
  Name:                MAA_orcl
  Enabled:             YES
  Protection Mode:     MaxPerformance
  Databases:
    orcl_primary - Primary database
    orcl_stdby1  - Snapshot standby database

Fast-Start Failover: DISABLED

Current status for "MAA_orcl":
SUCCESS

As shown in Listing 5.2, the successful conversion of the original physical standby database to a snapshot standby database is also reflected in the database’s alert log. I can also confirm that the snapshot standby database is indeed a separate incarnation of its “parent” physical standby database by querying the V$DATABASE_INCARNATION and V$DATABASE dynamic views:


TTITLE 'Database Incarnations|(from V$DATABASE_INCARNATION)'
COL incarnation#        FORMAT 9999999      HEADING 'Incar-|nation'
COL resetlogs_id        FORMAT 99999999999  HEADING 'ResetLogs|ID'
COL prior_incarnation#  FORMAT 9999999      HEADING 'Prior|Incar-|nation'
COL status              FORMAT A16          HEADING 'Status'
COL rsl_dtm             FORMAT A11          HEADING 'Reset|Logs|Timestamp' WRAP
COL prior_rsl_dtm       FORMAT A11          HEADING 'Prior|Reset|Logs|Timestamp' WRAP
COL fba_flag            FORMAT A05          HEADING 'Flash|Back|DB|Alwd?'
SELECT 
     incarnation#
    ,resetlogs_id
    ,resetlogs_change# rsl_chg#
    ,TO_CHAR(resetlogs_time, 'yyyy-mm-dd hh24:mi:ss') rsl_dtm
    ,prior_incarnation#
    ,TO_CHAR(prior_resetlogs_time, 'yyyy-mm-dd hh24:mi:ss') prior_rsl_dtm
    ,status
    ,flashback_database_allowed fba_flag
  FROM v$database_incarnation
;
TTITLE OFF
                                  Database Incarnations
                             (from V$DATABASE_INCARNATION)

                                                      Prior                        Flash
                                 Reset          Prior Reset                        Back
  Incar-    ResetLogs            Logs          Incar- Logs                         DB
  nation           ID   RSL_CHG# Timestamp     nation Timestamp   Status           Alwd?
-------- ------------ ---------- ----------- -------- ----------- ---------------- -----
       1    629600782          1 2007-08-03         0             PARENT           NO
                                 01:06:22

       2    682541003     522753 2009-03-26         1 2007-08-03  PARENT           NO
                                 18:43:23             01:06:22

       3    692737822    4458754 2009-07-20         2 2009-03-26  ORPHAN           NO
                                 19:10:22             18:43:23

       4    692911765    4957899 2009-07-22         2 2009-03-26  ORPHAN           YES
                                 19:29:25             18:43:23

       5    693763762    4970489 2009-08-01         2 2009-03-26  PARENT          NO
                                 16:09:22             18:43:23

       6    694880645    5045967 2009-08-14         5 2009-08-01  CURRENT         NO
                                 14:24:05             16:09:22


6 rows selected.

                                                   Prior Prior
SQL> SQL> TTITLE 'Database Status|(From V$DATABASE)'
COL name                FORMAT A12      HEADING 'Database|Name'
COL current_scn         FORMAT 99999999 HEADING 'Current SCN'
COL rlc_nbr             FORMAT 9999999  HEADING 'ResetLogs|Change #'
COL rlc_dtm             FORMAT A11      HEADING 'ResetLogs|Timestamp' WRAP
COL prlc_nbr            FORMAT 9999999  HEADING 'Prior|ResetLogs|Change #'
COL prlc_dtm            FORMAT A11      HEADING 'Prior|ResetLogs|Timestamp' WRAP
SELECT
     name
    ,current_scn
    ,resetlogs_change# rlc_nbr
    ,TO_CHAR(resetlogs_time, 'yyyy-mm-dd hh24:mi:ss')  rlc_dtm
    ,prior_resetlogs_change# prlc_nbr
    ,TO_CHAR(prior_resetlogs_time, 'yyyy-mm-dd hh24:mi:ss')  prlc_dtm
  FROM v$database
;
TTITLE OFF

                           Database Status
                          (From V$DATABASE)

                                                    Prior Prior
Database                 ResetLogs  ResetLogs   ResetLogs ResetLogs
Name         Current SCN  Change #  Timestamp    Change # Timestamp
------------ ----------- ---------  ----------- --------- -----------
ORCL             5046338   5045967 2009-08-14    4970489 2009-08-01
                                    14:24:05              16:09:22

Now that my snapshot standby database is available for READ WRITE access, I’ll simulate the deployment of required application changes. I’ll add two new indexes against the HR.NEW_EMPLOYEES table and insert a few more rows into the table, then query the data dictionary and the table to prove these changes are in place as expected:


-----
-- Add new indexes on Last Name and Salary columns
-----
CREATE INDEX hr.new_employees_salary
   ON hr.new_employees (salary)
   TABLESPACE example;

CREATE INDEX hr.new_employees_ln
   ON hr.new_employees (last_name)
   TABLESPACE example;

-----
-- Add some more data using the table as its own source
-----
INSERT INTO hr.new_employees 
SELECT hr.seq_empl_id.NEXTVAL, last_name, first_name, salary FROM hr.new_employees;
INSERT INTO hr.new_employees 
SELECT hr.seq_empl_id.NEXTVAL, last_name, first_name, salary FROM hr.new_employees;

COMMIT;

-----
-- Show the results of the reconfiguration
-----
SELECT
     COUNT(*) tot_emps
    ,MIN(employee_id)
    ,MAX(employee_id)
    ,AVG(salary)
    ,MIN(salary)
    ,MAX(salary)
  FROM hr.new_employees;

  TOT_EMPS MIN(EMPLOYEE_ID) MAX(EMPLOYEE_ID) AVG(SALARY) MIN(SALARY) MAX(SALARY)
---------- ---------------- ---------------- ----------- ----------- -----------
     27392             100            27643  6517.75701        2100       30000

SELECT
     owner
    ,index_name
  FROM dba_indexes
 WHERE table_owner = 'HR'
   AND table_name = 'NEW_EMPLOYEES';

OWNER                          INDEX_NAME
------------------------------ ------------------------------
HR                             NEW_EMPLOYEES_PK_IDX
HR                             NEW_EMPLOYEES_SALARY
HR                             NEW_EMPLOYEES_LN

At this point, I could continue testing my application with the changes in place, but roll them back at any time to the original guaranteed restore point and start my testing all over again. I could also replay a pre-recorded application workload using Oracle 11g’s Real Application Testing suite via calls to the DBMS_WORKLOAD_REPLAY package or via Enterprise Manager.

Switching a Snapshot Standby Database Back To Physical Standby Mode

But what if I need to perform disaster recovery via a failover at this point in my application testing? Or, in a more likely scenario, what if I need to deploy critical patch updates or perform a rolling upgrade by performing a role transition? Here’s the beauty of the snapshot standby technology: Transforming a database that’s currently operating in snapshot standby mode back to physical standby mode essentially uses the same principles in reverse:

1.) Snapshot standby mode is terminated. First, Oracle 11g discards any changes that have been made to the snapshot standby database. It does this by applying flashback logs to rewind the standby database back to the previously-created guaranteed restore point.

2.) The original physical standby database is reincarnated. The physical standby database is restored to its previous incarnation. All changes that were made during snapshot standby operations are reflected in an orphaned incarnation.

3.) Managed recovery is reinstated. Since the reincarnated physical standby database is now in MOUNT mode, Oracle 11g simply applies the change vectors from the previously received (but as yet unapplied!) redo logs to roll forward all changes that pertain to the original incarnation, and then the Managed Recovery Process (MRP0) is reactivated.

To illustrate the reversion of a snapshot standby database back to physical standby mode, I’ll once again use DGMGRL to connect to my primary database and issue the CONVERT DATABASE command to transform database ORCL_STDBY1 into its original physical standby role:


DGMGRL> CONVERT DATABASE orcl_stdby1 TO PHYSICAL STANDBY
Converting database "orcl_stdby1" to a Physical Standby database, please wait...
Operation requires shutdown of instance "orcl_stdby1" on database "orcl_stdby1"
Shutting down instance "orcl_stdby1"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "orcl_stdby1" on database "orcl_stdby1"
Starting instance "orcl_stdby1"...
ORACLE instance started.
Database mounted.
Continuing to convert database "orcl_stdby1" ...
Operation requires shutdown of instance "orcl_stdby1" on database "orcl_stdby1"
Shutting down instance "orcl_stdby1"...
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "orcl_stdby1" on database "orcl_stdby1"
Starting instance "orcl_stdby1"...
ORACLE instance started.
Database mounted.
Database "orcl_stdby1" converted successfully

The results of converting the snapshot standby database back to its original physical standby state are also reflected in the database’s alert log as shown in Listing 5.3. The following query results prove that the physical standby database has been restored to its prior state:


                                  Database Incarnations
                             (from V$DATABASE_INCARNATION)

                                                      Prior                        Flash
                                 Reset          Prior Reset                        Back
  Incar-    ResetLogs            Logs          Incar- Logs                         DB
  nation           ID   RSL_CHG# Timestamp     nation Timestamp   Status           Alwd?
-------- ------------ ---------- ----------- -------- ----------- ---------------- -----
       1    629600782          1 2007-08-03         0             PARENT           NO
                                 01:06:22

       2    682541003     522753 2009-03-26         1 2007-08-03  PARENT           NO
                                 18:43:23             01:06:22

       3    692737822    4458754 2009-07-20         2 2009-03-26  ORPHAN           NO
                                 19:10:22             18:43:23

       4    692911765    4957899 2009-07-22         2 2009-03-26  ORPHAN           YES
                                 19:29:25             18:43:23

       5    693763762    4970489 2009-08-01         2 2009-03-26  CURRENT         NO
                                 16:09:22             18:43:23

       6    694880645    5045967 2009-08-14         5 2009-08-01  ORPHAN          NO
                                 14:24:05             16:09:22


6 rows selected.

                           Database Status
                          (From V$DATABASE)

                                                    Prior Prior
Database                 ResetLogs  ResetLogs   ResetLogs ResetLogs
Name         Current SCN  Change #  Timestamp    Change # Timestamp
------------ ----------- ---------  ----------- --------- -----------
ORCL             5046662   4970489 2009-08-01     522753 2009-03-26
                                    16:09:22              18:43:23

SELECT
     COUNT(*) tot_emps
    ,MIN(employee_id)
    ,MAX(employee_id)
    ,AVG(salary)
    ,MIN(salary)
    ,MAX(salary)
  FROM hr.new_employees;

  TOT_EMPS MIN(EMPLOYEE_ID) MAX(EMPLOYEE_ID) AVG(SALARY) MIN(SALARY) MAX(SALARY)
---------- ---------------- ---------------- ----------- ----------- -----------
      6848             100             6947  6517.75701        2100       30000

SELECT
     owner
    ,index_name
  FROM dba_indexes
 WHERE table_owner = 'HR'
   AND table_name = 'NEW_EMPLOYEES';

OWNER                          INDEX_NAME
------------------------------ ------------------------------
HR                             NEW_EMPLOYEES_PK_IDX

Snapshot Standby Databases: Some Caveats

Even though snapshot standby databases offer some obvious advantages for application testing, it’s important to be aware of at least two possible situations that could delay a speedy reincarnation of the physical standby database environment:

  • Reincarnation may take a long time. Depending on how much READ WRITE activity has taken place on the snapshot standby incarnation of the database, it could take an extremely long time to rewind those changes via Flashback Database to the original guaranteed restore point … and an equally long time to roll forward all the pending change data from the archived redo logs that have been received since the standby database was incarnated.
  • Delayed discovery of corrupted archived redo logs. Remember that even though archived redo logs are still being received at the snapshot standby database’s site, those logs will not be applied until after the snapshot standby is reincarnated as a physical standby database. If the primary database is unavailable when reincarnation is attempted, and one or more of the as-yet unapplied archived redo logs are corrupted or missing on the standby site, reincarnation isn’t possible until those logs have been recovered from some other source – perhaps even from tape backups.

Next Steps

In the next article in this series, I'll delve into how Oracle 11g handles the ultimate worst-case scenario -- the loss of the primary database -- by showing how an Oracle DBA can initiate a failover operation to a physical standby database, as well as resurrect a failed primary database back to physical standby with Data Guard's REINSTATE command.

References and Additional Reading

While I’m hopeful that I’ve given you a thorough grounding in the technical aspects of the features I’ve discussed in this article, I’m also sure that there may be better documentation available since it’s been published. I therefore strongly suggest that you take a close look at the corresponding Oracle documentation on these features to obtain crystal-clear understanding before attempting to implement them in a production environment. Please note that I’ve drawn upon the following Oracle Database 11g documentation for the deeper technical details of this article:

B28279-02 Oracle Database 11g New Features Guide

B28294-03 Oracle Database 11g Data Guard Concepts and Administration

B28295-03 Oracle Database 11g Data Guard Broker

B28320-01 Oracle Database 11g Reference Guide

B28419-02 Oracle Database 11g PL/SQL Packages and Types Reference

» See All Articles by Columnist Jim Czuprynski






>>> Alert log entries:

Media Recovery Waiting for thread 1 sequence 266 (in transit)
Recovery of Online Redo Log: Thread 1 Group 5 Seq 266 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/stdby/srl02.log
Sun Jul 19 21:20:37 2009
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
Sun Jul 19 21:20:37 2009
MRP0: Background Media Recovery cancelled with status 16037
Errors in file /u01/app/oracle/diag/rdbms/orcl_stdby1/orcl_stdby1/trace/orcl_stdby1_mrp0_6595.trc:
ORA-16037: user requested cancel of managed recovery operation
Managed Standby Recovery not using Real Time Apply
Shutting down recovery slaves due to error 16037
Recovery interrupted!
Recovered data files to a consistent state at change 4455257
Waiting for MRP0 pid 6595 to terminate
Errors in file /u01/app/oracle/diag/rdbms/orcl_stdby1/orcl_stdby1/trace/orcl_stdby1_mrp0_6595.trc:
ORA-16037: user requested cancel of managed recovery operation
MRP0: Background Media Recovery process shutdown (orcl_stdby1)
Managed Standby Recovery Canceled (orcl_stdby1)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
Sun Jul 19 21:20:41 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[8]: Assigned to RFS process 6701
RFS[8]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[8]: Successfully opened standby log 5: '/u01/app/oracle/oradata/stdby/srl02.log'
Sun Jul 19 21:20:59 2009
alter database open
Data Guard Broker initializing...
Data Guard Broker initialization complete
AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access
Sun Jul 19 21:20:59 2009
SMON: enabling cache recovery
Dictionary check beginning
Sun Jul 19 21:21:00 2009
Errors in file /u01/app/oracle/diag/rdbms/orcl_stdby1/orcl_stdby1/trace/orcl_stdby1_dbw0_6554.trc:
ORA-01157: cannot identify/lock data file 201 - see DBWR trace file
ORA-01110: data file 201: '/u01/app/oracle/oradata/orcl/temp01.dbf'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
Errors in file /u01/app/oracle/diag/rdbms/orcl_stdby1/orcl_stdby1/trace/orcl_stdby1_dbw0_6554.trc:
ORA-01186: file 201 failed verification tests
ORA-01157: cannot identify/lock data file 201 - see DBWR trace file
ORA-01110: data file 201: '/u01/app/oracle/oradata/orcl/temp01.dbf'
File 201 not verified due to error ORA-01157
Dictionary check complete
Re-creating tempfile /u01/app/oracle/oradata/orcl/temp01.dbf
Database Characterset is AL32UTF8
Opening with internal Resource Manager plan
**********************************************************
WARNING: Files may exists in db_recovery_file_dest
that are not known to the database. Use the RMAN command
CATALOG RECOVERY AREA to re-catalog any such files.
If files cannot be cataloged, then manually delete them
using OS command.
One of the following events caused this:
1. A backup controlfile was restored.
2. A standby controlfile was restored.
3. The controlfile was re-created.
4. db_recovery_file_dest had previously been enabled and
   then disabled.
**********************************************************
replication_dependency_tracking turned off (no async multimaster replication found)
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Physical standby database opened for read only access.
Sun Jul 19 21:21:31 2009
Completed: alter database open
Sun Jul 19 21:21:46 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[9]: Assigned to RFS process 6716
RFS[9]: Identified database type as 'physical standby'
Sun Jul 19 21:21:49 2009
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE THROUGH ALL SWITCHOVER DISCONNECT  USING CURRENT LOGFILE
Attempt to start background Managed Standby Recovery process (orcl_stdby1)
Sun Jul 19 21:21:49 2009
MRP0 started with pid=26, OS id=6718
MRP0: Background Managed Standby Recovery process started (orcl_stdby1)
Fast Parallel Media Recovery enabled
Managed Standby Recovery starting Real Time Apply
 parallel recovery started with 2 processes
Waiting for all non-current ORLs to be archived...
Media Recovery Log /u01/app/oracle/flash_recovery_area/STDBY/log_266_1_682541003.arc
Media Recovery Waiting for thread 1 sequence 267 (in transit)
Recovery of Online Redo Log: Thread 1 Group 5 Seq 267 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/stdby/srl02.log
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE THROUGH ALL SWITCHOVER DISCONNECT USING CURRENT LOGFILE
Media Recovery Waiting for thread 1 sequence 268
Sun Jul 19 21:21:58 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[10]: Assigned to RFS process 6728
RFS[10]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[10]: Successfully opened standby log 5: '/u01/app/oracle/oradata/stdby/srl02.log'
Sun Jul 19 21:22:02 2009
Recovery of Online Redo Log: Thread 1 Group 5 Seq 268 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/stdby/srl02.log



>>> Alert log entries:

Fri Aug 14 14:23:38 2009
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
Fri Aug 14 14:23:38 2009
MRP0: Background Media Recovery cancelled with status 16037
Errors in file /u01/app/oracle/diag/rdbms/orcl_stdby1/orcl_stdby1/trace/orcl_stdby1_mrp0_5547.trc:
ORA-16037: user requested cancel of managed recovery operation
Managed Standby Recovery not using Real Time Apply
Shutting down recovery slaves due to error 16037
Recovery interrupted!
Recovered data files to a consistent state at change 5045966
Errors in file /u01/app/oracle/diag/rdbms/orcl_stdby1/orcl_stdby1/trace/orcl_stdby1_mrp0_5547.trc:
ORA-16037: user requested cancel of managed recovery operation
MRP0: Background Media Recovery process shutdown (orcl_stdby1)
Managed Standby Recovery Canceled (orcl_stdby1)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
alter database convert to snapshot standby
Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_08/14/2009 14:23:38
tkcrrxms: Killing 3 processes (all RFS)
Waiting for dispatcher 'D000' to shutdown
All dispatchers and shared servers shutdown
Active process 5509 user 'oracle' program 'oracle@11gStdby (TNS V1-V3)'
CLOSE: all sessions shutdown successfully.
Fri Aug 14 14:24:05 2009
SMON: disabling cache recovery
RESETLOGS after incomplete recovery UNTIL CHANGE 5045966
Resetting resetlogs activation ID 1221597403 (0x48d018db)
Online log /u01/app/oracle/oradata/stdby/redo01.log: Thread 1 Group 1 was previously cleared
Online log /u01/app/oracle/oradata/stdby/redo02.log: Thread 1 Group 2 was previously cleared
Online log /u01/app/oracle/oradata/stdby/redo03.log: Thread 1 Group 3 was previously cleared
Standby became primary SCN: 5045964
Fri Aug 14 14:24:05 2009
Setting recovery target incarnation to 6
Converting standby mount to primary mount.
ACTIVATE STANDBY: Complete - Database mounted as primary (orcl_stdby1)
ALTER DATABASE CONVERT TO SNAPSHOT STANDBY: Complete (orcl_stdby1)
Completed: alter database convert to snapshot standby
ALTER DATABASE OPEN
Data Guard Broker initializing...
Data Guard Broker initialization complete
Fri Aug 14 14:24:06 2009
Assigning activation ID 1222645452 (0x48e016cc)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /u01/app/oracle/oradata/stdby/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Fri Aug 14 14:24:07 2009
ARC2: Becoming the 'no SRL' ARCH
SMON: enabling cache recovery
Fri Aug 14 14:24:07 2009
idle dispatcher 'D000' terminated, pid = (18, 1)
Successfully onlined Undo Tablespace 2.
Dictionary check beginning
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
Opening with internal Resource Manager plan
Fri Aug 14 14:24:09 2009
Starting background process FBDA
Starting background process SMCO
Fri Aug 14 14:24:09 2009
FBDA started with pid=19, OS id=5601
Fri Aug 14 14:24:09 2009
SMCO started with pid=21, OS id=5603
Starting background process QMNC
Fri Aug 14 14:24:13 2009
QMNC started with pid=30, OS id=5605
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Fri Aug 14 14:24:31 2009
Completed: ALTER DATABASE OPEN
Fri Aug 14 14:24:38 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[7]: Assigned to RFS process 5629
RFS[7]: Identified database type as 'snapshot standby'
RFS[7]: Successfully opened standby log 4: '/u01/app/oracle/oradata/stdby/srl01.log'
Fri Aug 14 14:24:42 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[8]: Assigned to RFS process 5635
RFS[8]: Identified database type as 'snapshot standby'



>>> Alert log entries:

Fri Aug 14 14:44:35 2009
Stopping background process SMCO
Stopping background process FBDA
Shutting down instance: further logons disabled
Stopping background process QMNC
Fri Aug 14 14:44:37 2009
Stopping background process CJQ0
Stopping background process MMNL
Stopping background process MMON
Shutting down instance (immediate)
Fri Aug 14 14:44:40 2009
ORA-1089 : opidrv aborting process J000 ospid (10945_3083204288)
License high water mark = 8
All dispatchers and shared servers shutdown
alter database CLOSE NORMAL
Fri Aug 14 14:44:41 2009
SMON: disabling tx recovery
SMON: disabling cache recovery
Fri Aug 14 14:44:41 2009
Shutting down archive processes
Archiving is disabled
Fri Aug 14 14:44:41 2009
ARCH shutting down
ARC3: Archival stopped
Fri Aug 14 14:44:41 2009
ARCH shutting down
ARC2: Archival stopped
Fri Aug 14 14:44:41 2009
ARCH shutting down
ARC1: Archival stopped
Fri Aug 14 14:44:41 2009
ARCH shutting down
ARC0: Archival stopped
Thread 1 closed at log sequence 1
Successful close of redo thread 1
Completed: alter database CLOSE NORMAL
alter database DISMOUNT
Completed: alter database DISMOUNT
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Shutting down Data Guard Broker processes
Fri Aug 14 14:44:46 2009
Completed: Data Guard Broker shutdown
Fri Aug 14 14:44:48 2009
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Fri Aug 14 14:44:48 2009
Stopping background process VKTM:
Fri Aug 14 14:44:50 2009
Instance shutdown complete
Fri Aug 14 14:44:51 2009
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Autotune of undo retention is turned on.
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 11.1.0.6.0.
Using parameter settings in server-side spfile /u01/app/oracle/product/11.1.0/db_1/dbs/spfileorcl_stdby1.ora
System parameters with non-default values:
  processes                = 150
  sga_target               = 400M
  control_files            = "/u01/app/oracle/oradata/orcl/control01.ctl"
  log_file_name_convert    = "/u01/app/oracle/oradata/orcl/"
  log_file_name_convert    = "/u01/app/oracle/oradata/stdby/"
  db_block_size            = 8192
  compatible               = "11.1.0.0.0"
  log_archive_config       = "dg_config=(orcl_primary,orcl_stdby1)"
  log_archive_dest_1       = "location="/u01/app/oracle/flash_recovery_area/STDBY/""
  log_archive_dest_1       = "valid_for=(ALL_LOGFILES,ALL_ROLES)"
  log_archive_dest_2       = ""
  log_archive_dest_state_1 = "ENABLE"
  log_archive_dest_state_2 = "ENABLE"
  log_archive_max_processes= 4
  log_archive_min_succeed_dest= 1
  log_archive_trace        = 0
  log_archive_format       = "log_%s_%t_%r.arc"
  fal_client               = "orcl_stdby1"
  fal_server               = "orcl_primary"
  archive_lag_target       = 0
  db_recovery_file_dest    = "/u01/app/oracle/flash_recovery_area"
  db_recovery_file_dest_size= 8G
  standby_file_management  = "AUTO"
  undo_tablespace          = "UNDOTBS1"
  sec_case_sensitive_logon = FALSE
  remote_login_passwordfile= "EXCLUSIVE"
  db_domain                = ""
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=orclXDB)"
  audit_file_dest          = "/u01/app/oracle/admin/orcl/adump"
  audit_trail              = "DB"
  db_name                  = "orcl"
  db_unique_name           = "orcl_stdby1"
  open_cursors             = 300
  pga_aggregate_target     = 150M
  dg_broker_start          = TRUE
  dg_broker_config_file1   = "/u01/app/oracle/product/11.1.0/db_1/dbs/dr1orcl_stdby1.dat"
  dg_broker_config_file2   = "/u01/app/oracle/product/11.1.0/db_1/dbs/dr2orcl_stdby1.dat"
  diagnostic_dest          = "/u01/app/oracle"
Fri Aug 14 14:44:54 2009
PMON started with pid=2, OS id=12700
Fri Aug 14 14:44:54 2009
VKTM started with pid=3, OS id=12702 at elevated priority
VKTM running at (20)ms precision

<< ... removed for sake of brevity ... >>

DMON started with pid=18, OS id=12747
Fri Aug 14 14:44:55 2009
alter database  mount
Setting recovery target incarnation to 6
Successful mount of redo thread 1, with mount id 1222676713
Allocated 3981204 bytes in shared pool for flashback generation buffer
Starting background process RVWR
Fri Aug 14 14:45:02 2009
RVWR started with pid=21, OS id=13610
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: alter database  mount
Starting Data Guard Broker (DMON)
Fri Aug 14 14:45:03 2009
NSV0 started with pid=22, OS id=13650
Fri Aug 14 14:45:07 2009
INSV started with pid=23, OS id=14160
Fri Aug 14 14:45:12 2009
RSM0 started with pid=24, OS id=14656
Using STANDBY_ARCHIVE_DEST parameter default value as /u01/app/oracle/flash_recovery_area/STDBY/
ALTER SYSTEM SET log_archive_dest_1='location="/u01/app/oracle/flash_recovery_area/STDBY/"','valid_for=(ALL_LOGFILES,ALL_ROLES)' SCOPE=BOTH SID='orcl_stdby1';
ALTER SYSTEM SET log_archive_dest_state_1='ENABLE' SCOPE=BOTH SID='orcl_stdby1';
ALTER SYSTEM SET log_archive_trace=0 SCOPE=BOTH SID='orcl_stdby1';
ALTER SYSTEM SET log_archive_format='log_%s_%t_%r.arc' SCOPE=SPFILE SID='orcl_stdby1';
ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH SID='*';
ALTER SYSTEM SET archive_lag_target=0 SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_archive_max_processes=4 SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_archive_min_succeed_dest=1 SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_file_name_convert='/u01/app/oracle/oradata/orcl/','/u01/app/oracle/oradata/stdby/' SCOPE=SPFILE;
ALTER SYSTEM SET fal_server='orcl_primary' SCOPE=BOTH;
ALTER SYSTEM SET fal_client='orcl_stdby1' SCOPE=BOTH;
Fri Aug 14 14:45:22 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 15910
RFS[1]: Identified database type as 'snapshot standby'
RFS LogMiner: Client disabled from further notification
RFS[1]: Successfully opened standby log 5: '/u01/app/oracle/oradata/stdby/srl02.log'
Fri Aug 14 14:45:22 2009
alter database convert to physical standby
ALTER DATABASE CONVERT TO PHYSICAL STANDBY (orcl_stdby1)
Flashback Restore Start
Flashback Restore Complete
Guaranteed restore point  dropped
tkcrrxms: Killing 1 processes (all RFS)
The primary database controlfile was created using the
'MAXLOGFILES 16' clause.
There is space for up to 13 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
Setting recovery target incarnation to 5
Completed: alter database convert to physical standby
Fri Aug 14 14:45:27 2009
Shutting down instance: further logons disabled
Stopping background process MMNL
Stopping background process MMON
Shutting down instance (immediate)
License high water mark = 3
All dispatchers and shared servers shutdown
alter database CLOSE NORMAL
ORA-1109 signalled during: alter database CLOSE NORMAL...
alter database DISMOUNT
Completed: alter database DISMOUNT
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Shutting down Data Guard Broker processes
Fri Aug 14 14:45:31 2009
Completed: Data Guard Broker shutdown
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Fri Aug 14 14:45:33 2009
Stopping background process VKTM:
Fri Aug 14 14:45:35 2009
Instance shutdown complete
Fri Aug 14 14:45:35 2009
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Autotune of undo retention is turned on.
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 11.1.0.6.0.
Using parameter settings in server-side spfile /u01/app/oracle/product/11.1.0/db_1/dbs/spfileorcl_stdby1.ora
System parameters with non-default values:
  processes                = 150
  sga_target               = 400M
  control_files            = "/u01/app/oracle/oradata/orcl/control01.ctl"
  log_file_name_convert    = "/u01/app/oracle/oradata/orcl/"
  log_file_name_convert    = "/u01/app/oracle/oradata/stdby/"
  db_block_size            = 8192
  compatible               = "11.1.0.0.0"
  log_archive_config       = "dg_config=(orcl_primary,orcl_stdby1)"
  log_archive_dest_1       = "location="/u01/app/oracle/flash_recovery_area/STDBY/""
  log_archive_dest_1       = "valid_for=(ALL_LOGFILES,ALL_ROLES)"
  log_archive_dest_2       = ""
  log_archive_dest_state_1 = "ENABLE"
  log_archive_dest_state_2 = "ENABLE"
  log_archive_max_processes= 4
  log_archive_min_succeed_dest= 1
  log_archive_trace        = 0
  log_archive_format       = "log_%s_%t_%r.arc"
  fal_client               = "orcl_stdby1"
  fal_server               = "orcl_primary"
  archive_lag_target       = 0
  db_recovery_file_dest    = "/u01/app/oracle/flash_recovery_area"
  db_recovery_file_dest_size= 8G
  standby_file_management  = "AUTO"
  undo_tablespace          = "UNDOTBS1"
  sec_case_sensitive_logon = FALSE
  remote_login_passwordfile= "EXCLUSIVE"
  db_domain                = ""
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=orclXDB)"
  audit_file_dest          = "/u01/app/oracle/admin/orcl/adump"
  audit_trail              = "DB"
  db_name                  = "orcl"
  db_unique_name           = "orcl_stdby1"
  open_cursors             = 300
  pga_aggregate_target     = 150M
  dg_broker_start          = TRUE
  dg_broker_config_file1   = "/u01/app/oracle/product/11.1.0/db_1/dbs/dr1orcl_stdby1.dat"
  dg_broker_config_file2   = "/u01/app/oracle/product/11.1.0/db_1/dbs/dr2orcl_stdby1.dat"
  diagnostic_dest          = "/u01/app/oracle"
Fri Aug 14 14:45:36 2009
PMON started with pid=2, OS id=16881
Fri Aug 14 14:45:36 2009
VKTM started with pid=3, OS id=16883 at elevated priority
VKTM running at (20)ms precision
Fri Aug 14 14:45:36 2009

<< ... removed for sake of brevity ... >>

Fri Aug 14 14:45:37 2009
alter database  mount
Fri Aug 14 14:45:37 2009
DMON started with pid=18, OS id=16922
Setting recovery target incarnation to 5
ARCH: STARTING ARCH PROCESSES
Fri Aug 14 14:45:44 2009
ARC0 started with pid=20, OS id=17837
Fri Aug 14 14:45:44 2009
ARC1 started with pid=21, OS id=17839
ARC0: Archival started
ARC1: Archival started
ARC2: Archival started
ARC3: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC1: Thread not mounted
ARC0: Becoming the heartbeat ARCH
Fri Aug 14 14:45:44 2009
ARC3 started with pid=23, OS id=17843
ARC3: Thread not mounted
Fri Aug 14 14:45:44 2009
ARC2 started with pid=22, OS id=17841
ARC2: Thread not mounted
ARC0: Thread not mounted
Successful mount of redo thread 1, with mount id 1222710548
Allocated 3981204 bytes in shared pool for flashback generation buffer
Starting background process RVWR
Fri Aug 14 14:45:44 2009
RVWR started with pid=24, OS id=17847
Physical Standby Database mounted.
Lost write protection disabled
Completed: alter database  mount
Starting Data Guard Broker (DMON)
Fri Aug 14 14:45:45 2009
NSV0 started with pid=25, OS id=17899
Fri Aug 14 14:45:48 2009
INSV started with pid=27, OS id=18288
Fri Aug 14 14:45:52 2009
RSM0 started with pid=28, OS id=18803
Using STANDBY_ARCHIVE_DEST parameter default value as /u01/app/oracle/flash_recovery_area/STDBY/
ALTER SYSTEM SET log_archive_dest_1='location="/u01/app/oracle/flash_recovery_area/STDBY/"','valid_for=(ALL_LOGFILES,ALL_ROLES)' SCOPE=BOTH SID='orcl_stdby1';
ALTER SYSTEM SET log_archive_dest_state_1='ENABLE' SCOPE=BOTH SID='orcl_stdby1';
ALTER SYSTEM SET log_archive_trace=0 SCOPE=BOTH SID='orcl_stdby1';
ALTER SYSTEM SET log_archive_format='log_%s_%t_%r.arc' SCOPE=SPFILE SID='orcl_stdby1';
ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH SID='*';
ALTER SYSTEM SET archive_lag_target=0 SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_archive_max_processes=4 SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_archive_min_succeed_dest=1 SCOPE=BOTH SID='*';
ALTER SYSTEM SET log_file_name_convert='/u01/app/oracle/oradata/orcl/','/u01/app/oracle/oradata/stdby/' SCOPE=SPFILE;
ALTER SYSTEM SET fal_server='orcl_primary' SCOPE=BOTH;
ALTER SYSTEM SET fal_client='orcl_stdby1' SCOPE=BOTH;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  THROUGH ALL SWITCHOVER DISCONNECT  USING CURRENT LOGFILE
Attempt to start background Managed Standby Recovery process (orcl_stdby1)
Fri Aug 14 14:45:58 2009
MRP0 started with pid=29, OS id=19477
MRP0: Background Managed Standby Recovery process started (orcl_stdby1)
Fast Parallel Media Recovery enabled
Managed Standby Recovery starting Real Time Apply
 parallel recovery started with 2 processes
Waiting for all non-current ORLs to be archived...
Clearing online redo logfile 1 /u01/app/oracle/oradata/stdby/redo01.log
Clearing online log 1 of thread 1 sequence number 1
Fri Aug 14 14:46:04 2009
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  THROUGH ALL SWITCHOVER DISCONNECT  USING CURRENT LOGFILE
Fri Aug 14 14:46:05 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 20251
RFS[1]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
RFS LogMiner: Client disabled from further notification
Primary database is in MAXIMUM PERFORMANCE mode
kcrrvslf: inactive RFS archival for log 5 thread 1 sequence 16
RFS[1]: Successfully opened standby log 4: '/u01/app/oracle/oradata/stdby/srl01.log'
Clearing online redo logfile 1 complete
Media Recovery Log /u01/app/oracle/flash_recovery_area/STDBY/log_14_1_693763762.arc
Media Recovery Waiting for thread 1 sequence 15
Fetching gap sequence in thread 1, gap sequence 15-15
Fri Aug 14 14:46:09 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 20373
RFS[2]: Identified database type as 'physical standby'
RFS[2]: Archived Log: '/u01/app/oracle/flash_recovery_area/STDBY/log_15_1_693763762.arc'
Fri Aug 14 14:46:39 2009
Media Recovery Log /u01/app/oracle/flash_recovery_area/STDBY/log_15_1_693763762.arc
Recovery of Online Redo Log: Thread 1 Group 5 Seq 16 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/stdby/srl02.log
Fri Aug 14 14:46:45 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[3]: Assigned to RFS process 25409
RFS[3]: Identified database type as 'physical standby'
RFS[3]: Archived Log: '/u01/app/oracle/flash_recovery_area/STDBY/log_16_1_693763762.arc'
Media Recovery Log /u01/app/oracle/flash_recovery_area/STDBY/log_16_1_693763762.arc
Media Recovery Waiting for thread 1 sequence 17 (in transit)
Recovery of Online Redo Log: Thread 1 Group 4 Seq 17 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/stdby/srl01.log

0

阅读 评论 收藏 转载 喜欢 打印举报
已投稿到:
  • 评论加载中,请稍候...
发评论

       

    验证码: 请点击后输入验证码 收听验证码

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 不良信息反馈 电话:4006900000 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有