13 Replies Latest reply: Jul 16, 2014 5:11 AM by gvpeter RSS

    11g recover physical standby incomplete

    gvpeter

      Hello Experts,

       

      My setup:

      - OS: RHEL 6.4

      - Oracle DB: Oracle Standard Edition, v. 11.2.0.4

       

      I'm migrating the current RHEL 5, Oracle Standard Edition 10.2.0.4.0 setup to the new RHEL 6.4 11g setup.

      The 10g environment succesfully runs in physical standby mode (manual, not Data Guard):

      - Archived redo logs from the primary are copied to the standby server using rsync every 15 minutes

      - All transported archived redo logs are applied on the standby server using point in time recovery, every 3 hours.

      - The alert log shows the arc files being applied and concludes with "Incomplete Recovery applied until change 292650109"

      - DML/DDL changes made in the primary DB appear correctly in the standby DB.

       

      The same setup is not working on the new 11g environment: the shipped redo logs do not get applied during the point in time recovery.

       

       

       

      Creation of the standby database:

      The same SID has been created on both the physical server and the standby server, using DBCA.

      On the physical server:

      - create pfile from spfile

      - shutdown physical sid

      - scp pfile to standby server

      - scp password file to standby server

      - scp all data files to standby server

      - startup physical sid

      - create standby controlfile

      - scp standby controlfile to standby server

      On the standby server:

      - copy the standby controlfile to the data directory

      - copy the archived log files from the physical server to standby server

      - startup mount using pfile from physical

      - create spfile from pfile

      - shutdown

      - startup nomount (using spfile)

      - ALTER DATABASE MOUNT STANDBY DATABASE;

      - alter session set nls_date_format='yyyy-mm-dd:hh24:mi:ss';

      - alter database recover automatic standby database until time '2014-06-13:08:15:00';

      This point in time is about 10 minutes before making the backups on the physical server.

      This results in levert ORA-01547, ORA-01152 and ORA-01110.

      - recover standby database;

      pointing to the redo01.log file from the physical server (and the same for redo02.log and redo03.log)

      Only after this the standby database can be started in read only mode:

      - ALTER DATABASE OPEN READ ONLY;


      Applying the redo logs:

      Using cronjobs the archived redo logs are shipped from physical to standby without problems.

      The point in time recovery on the standby never goes beyond June 14th, 03:14:41, as reflected in the alert log:


      Fri Jul 04 09:30:53 2014

      alter database recover automatic standby database until time '2014-07-04:07:30:53'

      Media Recovery Start

      started logmerger process

      Fri Jul 04 09:30:53 2014

      Managed Standby Recovery not using Real Time Apply

      Parallel Media Recovery started with 4 slaves

      Media Recovery Log /oracle/arch/blldp/blldp_arch_1_73_849877970.arc

      Incomplete recovery applied all redo ever generated.

      Recovery completed through change 780221 time 06/14/2014 03:14:41

      Media Recovery Complete (blldp)

      Completed: alter database recover automatic standby database until time '2014-07-04:07:30:53'

      Fri Jul 04 09:30:55 2014

      ALTER DATABASE OPEN READ ONLY

       

       

      The mentioned archive file is present, as are the other archive files after 06/14/2014:

      SQL> show parameter LOG_ARCHIVE_DEST_1;

      LOCATION=/oracle/db/blldp/arch MANDATORY

      $ cd /oracle/db/blldp/arch

      $ ls -lrth

      -rw-r-----. 1 oracle oinstall  13M Jun 14 03:14 blldp_arch_1_73_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 14 03:14 blldp_arch_1_74_849877970.arc

      -rw-r-----. 1 oracle oinstall  23M Jun 14 22:08 blldp_arch_1_75_849877970.arc

      -rw-r-----. 1 oracle oinstall 2.8M Jun 15 04:10 blldp_arch_1_76_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 15 04:10 blldp_arch_1_77_849877970.arc

      -rw-r-----. 1 oracle oinstall  19M Jun 15 19:00 blldp_arch_1_78_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 16 03:07 blldp_arch_1_80_849877970.arc

      -rw-r-----. 1 oracle oinstall 7.0M Jun 16 03:07 blldp_arch_1_79_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 17 03:07 blldp_arch_1_82_849877970.arc

      -rw-r-----. 1 oracle oinstall  16M Jun 17 03:07 blldp_arch_1_81_849877970.arc

      -rw-r-----. 1 oracle oinstall  18M Jun 18 03:07 blldp_arch_1_83_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 18 03:07 blldp_arch_1_84_849877970.arc

      -rw-r-----. 1 oracle oinstall  21M Jun 19 00:13 blldp_arch_1_85_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 19 03:07 blldp_arch_1_87_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.5M Jun 19 03:07 blldp_arch_1_86_849877970.arc

      -rw-r-----. 1 oracle oinstall  30M Jun 20 00:14 blldp_arch_1_88_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.4M Jun 20 03:08 blldp_arch_1_89_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 20 03:08 blldp_arch_1_90_849877970.arc

      -rw-r-----. 1 oracle oinstall  29M Jun 21 00:15 blldp_arch_1_91_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 21 03:09 blldp_arch_1_93_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.4M Jun 21 03:09 blldp_arch_1_92_849877970.arc

      -rw-r-----. 1 oracle oinstall  20M Jun 21 18:09 blldp_arch_1_94_849877970.arc

      -rw-r-----. 1 oracle oinstall  22M Jun 22 00:17 blldp_arch_1_95_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 22 04:29 blldp_arch_1_97_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.9M Jun 22 04:29 blldp_arch_1_96_849877970.arc

      -rw-r-----. 1 oracle oinstall  19M Jun 22 19:00 blldp_arch_1_98_849877970.arc

      -rw-r-----. 1 oracle oinstall  21M Jun 23 00:18 blldp_arch_1_99_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 23 03:09 blldp_arch_1_101_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.4M Jun 23 03:09 blldp_arch_1_100_849877970.arc

      -rw-r-----. 1 oracle oinstall  30M Jun 24 00:19 blldp_arch_1_102_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 24 03:11 blldp_arch_1_104_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.5M Jun 24 03:11 blldp_arch_1_103_849877970.arc

      -rw-r-----. 1 oracle oinstall  30M Jun 25 00:21 blldp_arch_1_105_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 25 03:10 blldp_arch_1_107_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.5M Jun 25 03:10 blldp_arch_1_106_849877970.arc

      -rw-r-----. 1 oracle oinstall  30M Jun 26 00:22 blldp_arch_1_108_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 26 03:12 blldp_arch_1_110_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.5M Jun 26 03:12 blldp_arch_1_109_849877970.arc

      -rw-r-----. 1 oracle oinstall  26M Jun 27 00:23 blldp_arch_1_111_849877970.arc

      -rw-r-----. 1 oracle oinstall 5.0M Jun 27 03:09 blldp_arch_1_112_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 27 03:09 blldp_arch_1_113_849877970.arc

      -rw-r-----. 1 oracle oinstall  30M Jun 28 00:24 blldp_arch_1_114_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 28 03:15 blldp_arch_1_116_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.5M Jun 28 03:15 blldp_arch_1_115_849877970.arc

      -rw-r-----. 1 oracle oinstall  21M Jun 28 18:09 blldp_arch_1_117_849877970.arc

      -rw-r-----. 1 oracle oinstall  21M Jun 29 00:25 blldp_arch_1_118_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 29 04:10 blldp_arch_1_120_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.9M Jun 29 04:10 blldp_arch_1_119_849877970.arc

      -rw-r-----. 1 oracle oinstall  22M Jun 29 22:00 blldp_arch_1_121_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jun 30 03:06 blldp_arch_1_123_849877970.arc

      -rw-r-----. 1 oracle oinstall  18M Jun 30 03:06 blldp_arch_1_122_849877970.arc

      -rw-r-----. 1 oracle oinstall  29M Jul  1 00:27 blldp_arch_1_124_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jul  1 03:09 blldp_arch_1_126_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.5M Jul  1 03:09 blldp_arch_1_125_849877970.arc

      -rw-r-----. 1 oracle oinstall  25M Jul  2 00:28 blldp_arch_1_127_849877970.arc

      -rw-r-----. 1 oracle oinstall 7.2M Jul  2 03:09 blldp_arch_1_128_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jul  2 03:09 blldp_arch_1_129_849877970.arc

      -rw-r-----. 1 oracle oinstall  23M Jul  2 22:00 blldp_arch_1_130_849877970.arc

      -rw-r-----. 1 oracle oinstall  20M Jul  3 00:29 blldp_arch_1_131_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jul  3 03:08 blldp_arch_1_133_849877970.arc

      -rw-r-----. 1 oracle oinstall 3.2M Jul  3 03:08 blldp_arch_1_132_849877970.arc

      -rw-r-----. 1 oracle oinstall  31M Jul  4 00:30 blldp_arch_1_134_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.0K Jul  4 03:08 blldp_arch_1_136_849877970.arc

      -rw-r-----. 1 oracle oinstall 1.5M Jul  4 03:08 blldp_arch_1_135_849877970.arc

      -rw-r-----. 1 oracle oinstall 3.1M Jul  4 10:38 blldp_arch_1_137_849877970.arc

       

      Registering the other logfiles as below is not supported on a standby database:

      alter database register logfile '/oracle/arch/blldp/blldp_arch_1_74_849877970.arc';

       

      I tried setting the following parameters:

      *.standby_archive_dest='/oracle/db/blldp/arch'

      *.standby_file_management='AUTO'

      but the first one led to: ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance

      As indicated in other posts: on 11g it suffices to set LOG_ARCHIVE_DEST_1, which I did.

      But still the arc files after June 14th are not processed (according to the alert log and changes made in the primary DB after June 14th do not show up in the standby DB).

       

      Am I missing a setting which prevents the arc files after June 14th being processed?

      Did I make mistakes in setting up the standby DB, causing this problem?

       

      Please advise me.

       

      Best regards,

       

      Peter

        • 1. Re: 11g recover physical standby incomplete
          Nip-Oracle

          You can try cataloging the files via RMAN :

           

          RMAN> catalog start with '<full path where archived logs reside>' ;

          • 2. Re: 11g recover physical standby incomplete
            gvpeter

            NiP-Oracle,

             

            Thank you for your reply.

            I will try the RMAN catalog command and post the results here.

             

            Best regards,

             

            Peter

            • 3. Re: 11g recover physical standby incomplete
              Hemant K Chitale

              Once you OPEN the database (READ ONLY), Oracle will stop applying archivelogs.  You need to SHUTDOWN, STARTUP MOUNT and restart RECOVERy.

               

               

              Hemant K Chitale


              • 4. Re: 11g recover physical standby incomplete
                gvpeter

                Hello Hemant,

                 

                Thank you for your reply.

                I will test the recovery before opening the database as read only, after I have recreated the standby database from primary.

                 

                This would be a difference though, compaired to the current production environment (RHEL 5, Oracle SE 10.2.0.4). All standby databases in this environment have OPEN_MODE=READ ONLY, applying archive logs from primary using DBPITR happens without problems.

                 

                Beste regards,

                 

                Peter

                • 5. Re: 11g recover physical standby incomplete
                  Hemant K Chitale

                  A standby database wouldn't be in OPEN_MODE=READ ONLY by itself unless you have, manually or through a script, issued an ALTER DATABASE OPEN command.  10g does NOT apply archivelogs when the database is OPEN.

                  In fact, if you are running SE, you don't really have a standby database but a scripted standby using a backup controlfile.  Big difference between the two.

                   

                  (11g has the Active Standby feature which allows both OPEN and applying archivelogs to run concurrently -- this requires an additional licence option)

                   

                  Hemant K Chitale


                  • 6. Re: 11g recover physical standby incomplete
                    gvpeter

                    You are correct: the 10g SE setup is a manual standby (no data guard) using scripts to ship redo logs from the primary to standby and to apply the redo logs on the standby using DBPITR.

                    This script also executes "ALTER DATABASE OPEN READ ONLY" on the manual standby database.

                     

                    Steps in recovering the manual standby database each night are:

                    - shutdown

                    - STARTUP NOMOUNT

                    - ALTER DATABASE MOUNT STANDBY DATABASE;

                    - alter database recover automatic standby database until time '2014-07-16:01:30:33'

                    - ALTER DATABASE OPEN READ ONLY;

                     

                    On the 10g environment primary and manual standby are "in synch" (with the manual standby lagging by about 2 hours).

                     

                    The 11g SE environment is using the same scripted manual standby solution, but as stated above: on 11g the DBPITR doesn't apply any redo logs created after a certain date (alert log):

                    Incomplete recovery applied all redo ever generated.

                    Recovery completed through change 780221 time 06/14/2014 03:14:41


                    DBPITR never applies changes after checkpoint 780221, as recorded in the standby controlfile. Where as DBPITR on 10g does apply the most recent changes from the shipped redo logs. I just can't find the cause of this.


                    RMAN> LIST BACKUP OF CONTROLFILE;

                    Final 3 entries on 11g:

                    BS Key  Type LV Size       Device Type Elapsed Time Completion Time

                    ------- ---- -- ---------- ----------- ------------ ---------------

                    66      Full 9.36M      DISK        00:00:00     14-07-14

                            BP Key: 66   Status: AVAILABLE  Compressed: NO  Tag: TAG20140714T044138

                            Piece Name: /oracle/backup-internal/BLLDP/c-1164253650-20140714-00

                      Standby Control File Included: Ckp SCN: 780221       Ckp time: 14-06-14

                     

                    BS Key  Type LV Size       Device Type Elapsed Time Completion Time

                    ------- ---- -- ---------- ----------- ------------ ---------------

                    68      Full 9.36M      DISK        00:00:01     15-07-14

                            BP Key: 68   Status: AVAILABLE  Compressed: NO  Tag: TAG20140715T044232

                            Piece Name: /oracle/backup-internal/BLLDP/c-1164253650-20140715-00

                      Standby Control File Included: Ckp SCN: 780221       Ckp time: 14-06-14

                     

                    BS Key  Type LV Size       Device Type Elapsed Time Completion Time

                    ------- ---- -- ---------- ----------- ------------ ---------------

                    70      Full 9.36M      DISK        00:00:01     16-07-14

                            BP Key: 70   Status: AVAILABLE  Compressed: NO  Tag: TAG20140716T044241

                            Piece Name: /oracle/backup-internal/BLLDP/c-1164253650-20140716-00

                      Standby Control File Included: Ckp SCN: 780221       Ckp time: 14-06-14



                    Final 3 entries on 10g:

                     

                    BS Key  Type LV Size       Device Type Elapsed Time Completion Time

                    ------- ---- -- ---------- ----------- ------------ ---------------

                    2184    Full 34.64M     DISK        00:00:02     14-JUL-14

                            BP Key: 2184   Status: AVAILABLE  Compressed: NO  Tag: TAG20140714T064114

                            Piece Name: /oracle/backup-internal/BLLDP/c-1194074927-20140714-00

                      Standby Control File Included: Ckp SCN: 297924029    Ckp time: 14-JUL-14

                     

                    BS Key  Type LV Size       Device Type Elapsed Time Completion Time

                    ------- ---- -- ---------- ----------- ------------ ---------------

                    2186    Full 34.64M     DISK        00:00:02     15-JUL-14

                            BP Key: 2186   Status: AVAILABLE  Compressed: NO  Tag: TAG20140715T063717

                            Piece Name: /oracle/backup-internal/BLLDP/c-1194074927-20140715-00

                      Standby Control File Included: Ckp SCN: 298616835    Ckp time: 15-JUL-14

                     

                    BS Key  Type LV Size       Device Type Elapsed Time Completion Time

                    ------- ---- -- ---------- ----------- ------------ ---------------

                    2188    Full 34.64M     DISK        00:00:02     16-JUL-14

                            BP Key: 2188   Status: AVAILABLE  Compressed: NO  Tag: TAG20140716T063050

                            Piece Name: /oracle/backup-internal/BLLDP/c-1194074927-20140716-00

                      Standby Control File Included: Ckp SCN: 299238648    Ckp time: 16-JUL-14



                    • 7. Re: 11g recover physical standby incomplete
                      Hemant K Chitale

                      Try issuing a RECOVER DATABASE UNTIL .... manually from the command line

                      Possibly the 11g environment is missing an intermediate archivelog

                       

                      Hemant K Chitale


                      • 8. Re: 11g recover physical standby incomplete
                        gvpeter

                        I have issued the recover from the commandline, as below.

                        The alert log doesn't contain entries about a missing archive log. Or should I look elsewhere to see errors about missing archive logs?

                         

                        -bash-4.1$ sqlplus / as sysdba

                         

                        SQL*Plus: Release 11.2.0.4.0 Production on Wed Jul 16 10:34:24 2014

                         

                        Copyright (c) 1982, 2013, Oracle.  All rights reserved.

                         

                         

                        Connected to:

                        Oracle Database 11g Release 11.2.0.4.0 - 64bit Production

                         

                        SQL> shutdown

                        Database closed.

                        Database dismounted.

                        ORACLE instance shut down.

                        SQL> STARTUP NOMOUNT

                        ORACLE instance started.

                         

                        Total System Global Area 1,5132E+10 bytes

                        Fixed Size                  2267992 bytes

                        Variable Size            2080375976 bytes

                        Database Buffers         1,3019E+10 bytes

                        Redo Buffers               30527488 bytes

                        SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

                         

                        Database altered.

                         

                        SQL> alter database recover automatic standby database until time '2014-07-16:01:30:33';

                         

                        Database altered.

                         

                        SQL> ALTER DATABASE OPEN READ ONLY;

                         

                        Database altered.

                         

                         

                        Relevant entries in the alert log:

                        Completed: ALTER DATABASE MOUNT STANDBY DATABASE

                        ARC3: Archival started

                        ARC0: STARTING ARCH PROCESSES COMPLETE

                        Wed Jul 16 10:35:34 2014

                        alter database recover automatic standby database until time '2014-07-16:01:30:33'

                        Media Recovery Start

                        started logmerger process

                        Wed Jul 16 10:35:35 2014

                        Managed Standby Recovery not using Real Time Apply

                        Parallel Media Recovery started with 4 slaves

                        Media Recovery Log /oracle/arch/blldp/blldp_arch_1_73_849877970.arc

                        Incomplete recovery applied all redo ever generated.

                        Recovery completed through change 780221 time 06/14/2014 03:14:41

                        Media Recovery Complete (blldp)

                        Completed: alter database recover automatic standby database until time '2014-07-16:01:30:33'

                        ALTER DATABASE OPEN READ ONLY

                        AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access

                        Wed Jul 16 10:35:44 2014

                        SMON: enabling cache recovery

                        Dictionary check beginning

                        Dictionary check complete

                        Database Characterset is AL32UTF8

                        No Resource Manager plan active

                        replication_dependency_tracking turned off (no async multimaster replication found)

                        Physical standby database opened for read only access.

                        Wed Jul 16 10:35:44 2014

                        Completed: ALTER DATABASE OPEN READ ONLY

                        • 9. Re: 11g recover physical standby incomplete
                          Nip-Oracle

                          It will not complain as the minimum required archived logs (to make datafiles consistent) have been applied, and that's the reason, you could open it READ ONLY.

                           

                          To apply further archived logs,  shutdown, startup mount,  connect RMAN, catalog the archived logs from source (primary) like you did before, and recover them.

                           

                          This would be an ongoing activity to keep you standby close to your Primary.

                          • 10. Re: 11g recover physical standby incomplete
                            Hemant K Chitale

                            >until time '2014-07-16:01:30:33'

                            What is the NLS_DATE_FORMAT for the instance ?

                             

                             

                            Hemant K Chitale


                            • 11. Re: 11g recover physical standby incomplete
                              gvpeter

                              SQL> SELECT value FROM   nls_session_parameters WHERE  parameter = 'NLS_DATE_FORMAT';

                               

                              VALUE

                              --------------------------------------------------------------------------------

                              DD-MM-RR

                               

                              The recovery script actually deals with this by issueing:

                              alter session set nls_date_format='yyyy-mm-dd:hh24:mi:ss';

                              before the alter database recover automatic standby database until time '2014-07-16:01:30:33';

                               

                              I missed setting the nls_date_format when recovering from the command line.

                              Another try, this time including setting the nls_date_format yielded the same result.

                               

                              SQL> shutdown

                              SQL> STARTUP NOMOUNT

                              SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

                              SQL> alter session set nls_date_format='yyyy-mm-dd:hh24:mi:ss';

                              SQL> alter database recover automatic standby database until time '2014-07-16:01:30:33';

                              SQL> ALTER DATABASE OPEN READ ONLY;

                               

                               

                              SQL> shutdown

                              Database closed.

                              Database dismounted.

                              ORACLE instance shut down.

                              SQL> STARTUP NOMOUNT

                              ORACLE instance started.

                               

                              Total System Global Area 1,5132E+10 bytes

                              Fixed Size                  2267992 bytes

                              Variable Size            2080375976 bytes

                              Database Buffers         1,3019E+10 bytes

                              Redo Buffers               30527488 bytes

                              SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

                               

                              Database altered.

                               

                              SQL> alter session set nls_date_format='yyyy-mm-dd:hh24:mi:ss';

                               

                              Session altered.

                               

                              SQL> alter database recover automatic standby database until time '2014-07-16:01:30:33';

                               

                              Database altered.

                               

                              SQL> ALTER DATABASE OPEN READ ONLY;

                               

                              Database altered.

                               

                              Alert log:

                              Wed Jul 16 10:58:43 2014

                              Managed Standby Recovery not using Real Time Apply

                              Parallel Media Recovery started with 4 slaves

                              Media Recovery Log /oracle/arch/blldp/blldp_arch_1_73_849877970.arc

                              Incomplete recovery applied all redo ever generated.

                              Recovery completed through change 780221 time 06/14/2014 03:14:41

                              Media Recovery Complete (blldp)

                              Completed: alter database recover automatic standby database until time '2014-07-16:01:30:33'

                              • 12. Re: 11g recover physical standby incomplete
                                Hemant K Chitale

                                The database isn't "aware" of subsequent archivelogs.  They need to be registered or CATALOGed.

                                OR you need a fresh controlfile backup.

                                Also, as this is a Standard Edition install, I am surprised that it doesn't complain about the "standby database". Your controlfile isn't likely to be a standby controlfile.

                                 

                                 

                                Hemant K Chitale

                                • 13. Re: 11g recover physical standby incomplete
                                  gvpeter

                                  Hemant,

                                   

                                  Using a fresh controlfile solved the problem. I will add this action to the synch scripts.

                                  Thank you very, very much for your expert advice and time invested in solving my problem!

                                   

                                  Kind regards,

                                   

                                  Peter

                                   

                                   

                                  Details:

                                  After creating a fresh controlfile backup on the primary (as done during creation of the manual standby database):

                                  SQL> alter database create standby controlfile as '/home/oracle/std_control_blldp.ctl' reuse;

                                   

                                  and shipping it to the manual standby, another DBPITR was done, with a slightly changed recover command:

                                  SQL> alter database recover automatic standby database until time '2014-07-16:09:00:00' using backup controlfile;

                                  Database altered.

                                  SQL> ALTER DATABASE OPEN READ ONLY;

                                   

                                  Database altered.