1 2 Previous Next 17 Replies Latest reply: Apr 17, 2012 6:31 AM by user569151 RSS

    Warning: the given resetlogs_id is not on the valid incarnation path

    user569151
      I have a primary database (while standby is removed for now, since I got some issues), the drc log file shows below information, how to fix those issue?


      Warning: the given resetlogs_id 780690997 is not on the valid incarnation path.
      04/16/2012 12:35:26

      "drcrwxcty1.log" 289909L, 19778849C 289828,1 99%
        • 1. Re: Warning: the given resetlogs_id is not on the valid incarnation path
          mseberg
          Hello;

          OK the Broker log and Broker are still active, but you don't have a Standby.


          I would remove the Broker setup since it will probably trip you when you decided to put the Standby back.


          I would use this note :


          How to Safely Remove a Data Guard Broker Configuration [ID 261336.1]

          Best Regards

          mseberg
          • 2. Re: Warning: the given resetlogs_id is not on the valid incarnation path
            user569151
            Thank you very much for your quick response. My problem comes up because during the weeknd, I tried to test reinstate, so I failed over the primary to standby, and somehow I could not reinstate it back per instruction.

            however the primary right now seems messed up:

            SQL> select primary_db_unique_name from v$database;

            PRIMARY_DB_UNIQUE_NAME
            ------------------------------
            wxctysqa

            SQL> select * from v$instance;

            INSTANCE_NUMBER INSTANCE_NAME HOST_NAME VERSION STARTUP_T STATUS PAR THREAD# ARCHIVE LOG_SWITCH_WAIT LOGINS SHU DATABASE_STATUS INSTANCE_ROLE ACTIVE_ST BLO
            --------------- ---------------- ---------------------------------------------------------------- ----------------- --------- ------------ --- ---------- ------- --------------- ---------- --- ----------------- ------------------ --------- ---
            1 wxctyqa1 pd-oracle 11.2.0.3.0 15-APR-12 OPEN YES 1 STARTED ALLOWED NO ACTIVE PRIMARY_INSTANCE NORMAL NO

            See here this primary instance should be wxctyqa1, however v$database shows it is wxctysqa.

            Can somebody help me to straight things up?

            Thanks
            • 3. Re: Warning: the given resetlogs_id is not on the valid incarnation path
              mseberg
              There's a note which is about 6 weeks old which may help :

              Step by Step Guide on How To Reinstate Failed Primary Database into Physical Standby [ID 738642.1]


              Might be worth a look too :

              Reinstating a Standby Database after Failover fails with ORA-16623 / ORA-16541 [ID 1131833.1]


              Best Reagards

              mseberg

              Edited by: mseberg on Apr 16, 2012 9:24 AM
              • 4. Re: Warning: the given resetlogs_id is not on the valid incarnation path
                CKPT
                however the primary right now seems messed up:
                How you can say its messed up?

                See here this primary instance should be wxctyqa1, however v$database shows it is wxctysqa.
                Its confusing post.
                SQL> select name,database_role,db_unique_name,instance_name from gv$database,gv$instance;
                SQL> show parameter cluster

                To reinstate you can use below links

                http://uhesse.com/2012/01/16/after-test-failover-make-new-primary-standby-again/
                http://uhesse.com/tag/snapshot-standby/

                Edited by: CKPT on Apr 16, 2012 7:56 PM
                • 5. Re: Warning: the given resetlogs_id is not on the valid incarnation path
                  user569151
                  SQL> select name,database_role,db_unique_name,instance_name from gv$database,gv$instance;

                  NAME DATABASE_ROLE DB_UNIQUE_NAME INSTANCE_NAME
                  --------- ---------------- ------------------------------ ----------------
                  WXCTY PRIMARY wxcty wxcty1
                  WXCTY PRIMARY wxcty wxcty1
                  WXCTY PRIMARY wxcty wxcty2
                  WXCTY PRIMARY wxcty wxcty2

                  SQL> show parameter cluster

                  NAME TYPE VALUE
                  ------------------------------------ ----------- ------------------------------
                  cluster_database boolean TRUE
                  cluster_database_instances integer 2
                  cluster_interconnects string
                  SQL>


                  Why the dr log keep giving me that resetlog is not right?
                  • 6. Re: Warning: the given resetlogs_id is not on the valid incarnation path
                    user569151
                    Also , I ftp the primary rman backup to standby and created a standby controlfile from primary, when I do a rman restore, it won't point to the wxctysqa location.
                    • 7. Re: Warning: the given resetlogs_id is not on the valid incarnation path
                      user569151
                      I used Uwe's reinstate instruction, however it did not work when I convert back to primary.

                      Then somehow it seems both databases are physical standby. So I activated standby on primary which reset logs and then the problem occurred.
                      • 8. Re: Warning: the given resetlogs_id is not on the valid incarnation path
                        user569151
                        Now I want just use primary backup to restore to standby.

                        Why the restore did not set the db file convert path? Anybody help here?
                        • 9. Re: Warning: the given resetlogs_id is not on the valid incarnation path
                          CKPT
                          user569151 wrote:
                          Now I want just use primary backup to restore to standby.

                          Why the restore did not set the db file convert path? Anybody help here?
                          Before that can you check what is the resetlogs change of primary & standby?
                          is Broker still active?
                          What are the errors duing standby reinstate?
                          How many days standby is not in sync with primary? because once you convert it back again you have to sync, so look either you can build new standby instead of that.
                          • 10. Re: Warning: the given resetlogs_id is not on the valid incarnation path
                            user569151
                            I managed restored the database files into standby database and opened mounted and started recovered.

                            However I did not see in the alert log any media recovers.

                            Mon Apr 16 17:57:23 2012
                            Archived Log entry 34077 added for thread 1 sequence 6 ID 0x4a8aeff1 dest 1:
                            Mon Apr 16 18:03:38 2012
                            Thread 1 advanced to log sequence 8 (LGWR switch)
                            Current log# 2 seq# 8 mem# 0: +ORA_DAT/wxcty/onlinelog/group_2.279.777058471
                            Mon Apr 16 18:03:39 2012
                            Archived Log entry 34079 added for thread 1 sequence 7 ID 0x4a8aeff1 dest 1:

                            Standby server:

                            Waiting for all non-current ORLs to be archived...
                            All non-current ORLs have been archived.
                            Mon Apr 16 18:24:17 2012
                            Media Recovery Waiting for thread 1 sequence 3 (in transit)
                            Completed: ALTER DATABASE RECOVER managed standby database disconnect using current logfile


                            The standby server is not doing any media recovery at all. Any help Please?
                            • 11. Re: Warning: the given resetlogs_id is not on the valid incarnation path
                              user569151
                              hi, CKTP:

                              Need help here.

                              I managed to check through all parameter files, and reconfigured dataguard.

                              However I think still have issues here.

                              I still not quite able to get it work.
                              • 12. Re: Warning: the given resetlogs_id is not on the valid incarnation path
                                user569151
                                some how on primary ,I got this error:

                                Redo transport problem detected: redo transport for database remesqa has the following error:
                                ORA-00272: error writing archive log
                                • 13. Re: Warning: the given resetlogs_id is not on the valid incarnation path
                                  CKPT
                                  user569151 wrote:
                                  some how on primary ,I got this error:

                                  Redo transport problem detected: redo transport for database remesqa has the following error:
                                  ORA-00272: error writing archive log
                                  Dear,

                                  Sorry for the delay response.
                                  Is this error related to remote destination?
                                  After configuring datagaurd, have you seen redo transport from primary to standby?
                                  Can you check any errors from primary alert log file? Or check v$dataguard_stauts to review errors.

                                  Or use this below script and post in coded format, so that it will give overall idea.
                                  http://www.oracle-ckpt.com/dataguard_troubleshoot_snapper/
                                  • 14. Re: Warning: the given resetlogs_id is not on the valid incarnation path
                                    user569151
                                    on Primary , alert log last entries are:

                                    FAL[server, ARC3]: FAL archive failed, see trace file.
                                    ARCH: FAL archive failed. Archiver continuing
                                    ORACLE Instance remeqa1 - Archival Error. Archiver continuing.
                                    Tue Apr 17 07:45:35 2012
                                    FAL[server, ARC5]: FAL archive failed, see trace file.
                                    ARCH: FAL archive failed. Archiver continuing
                                    ORACLE Instance wxcty1 - Archival Error. Archiver continuing


                                    DGMGRL shows following error on primary:

                                    Error: ORA-16737: the redo transport service for standby database "wxctys" has an error

                                    DGMGRL> show database wxcty LogXptStatus
                                    LOG TRANSPORT STATUS
                                    PRIMARY_INSTANCE_NAME STANDBY_DATABASE_NAME STATUS
                                    wxcty1 wxctys ORA-03135: connection lost contact
                                    wxcty2 wxctys ORA-03140: I/O operation in progress




                                    on Standby alert logs shows:

                                    RFS[106]: Possible network disconnect with primary database
                                    Tue Apr 17 07:47:15 2012
                                    FAL[client]: Failed to request gap sequence
                                    GAP - thread 1 sequence 4-4
                                    DBID 1245181813 branch 780690997
                                    FAL[client]: All defined FAL servers have been attempted.
                                    ------------------------------------------------------------
                                    Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
                                    parameter is defined to a value that's sufficiently large
                                    enough to maintain adequate log switch information to resolve
                                    archivelog gaps.
                                    ------------------------------------------------------------
                                    1 2 Previous Next