Home » Server Options » Data Guard » will data guard fail over causes a new incarnation (10.2.0.4.0, Microsoft Windows IA (32-bit))
will data guard fail over causes a new incarnation [message #520127] Thu, 18 August 2011 13:23
kytemanaic
Messages: 51
Registered: February 2009
Member
Hi all,

my rdbms:


BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for 32-bit Windows: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production



my os:

SYS@chicago>select platform_id, platform_name from v$database;

PLATFORM_ID
-----------
PLATFORM_NAME
---------------------------------------------------------------

          7
Microsoft Windows IA (32-bit)



my initial configuration

primary:chicago
physical standby:boston

after failover
primary:boston

later I recreate the chicago as a physical standby successfully since the database complain that there's not enough flashback logs to flashback.Sad

here's what thing look like over in the boston after failover (new primary)


SYS@boston>SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, applied FROM V$ARCHIVED_LOG
ORDER BY SEQUENCE#;

 SEQUENCE# FIRST_TIME         NEXT_TIME          APP
---------- ------------------ ------------------ ---
         1 18-AUG-11 05:57:49 18-AUG-11 06:18:46 NO
         1 18-AUG-11 05:57:49 18-AUG-11 06:18:46 NO
         1 18-AUG-11 05:57:49 18-AUG-11 06:18:46 NO
         2 18-AUG-11 06:18:46 18-AUG-11 06:29:52 NO
         2 18-AUG-11 06:18:46 18-AUG-11 06:29:52 NO
         2 18-AUG-11 06:18:46 18-AUG-11 06:29:52 NO
         3 18-AUG-11 06:29:52 18-AUG-11 06:30:44 NO
         3 18-AUG-11 06:29:52 18-AUG-11 06:30:44 NO
         3 18-AUG-11 06:29:52 18-AUG-11 06:30:44 NO
         4 18-AUG-11 06:30:44 18-AUG-11 06:34:42 NO
         4 18-AUG-11 06:30:44 18-AUG-11 06:34:42 NO

 SEQUENCE# FIRST_TIME         NEXT_TIME          APP
---------- ------------------ ------------------ ---
         4 18-AUG-11 06:30:44 18-AUG-11 06:34:42 NO
         5 18-AUG-11 06:34:42 18-AUG-11 06:35:22 NO
         5 18-AUG-11 06:34:42 18-AUG-11 06:35:22 NO
         5 18-AUG-11 06:34:42 18-AUG-11 06:35:22 NO
         6 18-AUG-11 06:35:22 18-AUG-11 06:37:20 NO
         6 18-AUG-11 06:35:22 18-AUG-11 06:37:20 NO
         6 18-AUG-11 06:35:22 18-AUG-11 06:37:20 NO
         7 18-AUG-11 06:37:20 18-AUG-11 06:38:50 NO
         7 18-AUG-11 06:37:20 18-AUG-11 06:38:50 NO
         7 18-AUG-11 06:37:20 18-AUG-11 06:38:50 NO
         8 18-AUG-11 06:38:50 18-AUG-11 07:41:28 NO

 SEQUENCE# FIRST_TIME         NEXT_TIME          APP
---------- ------------------ ------------------ ---
         8 18-AUG-11 06:38:50 18-AUG-11 07:41:28 NO
         9 18-AUG-11 07:41:28 18-AUG-11 07:44:42 NO
         9 18-AUG-11 07:41:28 18-AUG-11 07:44:42 NO
        10 18-AUG-11 07:44:42 18-AUG-11 07:54:11 NO
        10 18-AUG-11 07:44:42 18-AUG-11 07:54:11 NO
        11 18-AUG-11 07:54:11 18-AUG-11 08:21:20 NO
        11 18-AUG-11 07:54:11 18-AUG-11 08:21:20 NO
        12 18-AUG-11 08:21:20 18-AUG-11 09:58:21 NO
        12 18-AUG-11 08:21:20 18-AUG-11 09:58:21 NO
        13 18-AUG-11 09:58:21 18-AUG-11 09:59:13 NO
        13 18-AUG-11 09:58:21 18-AUG-11 09:59:13 NO

 SEQUENCE# FIRST_TIME         NEXT_TIME          APP
---------- ------------------ ------------------ ---
        14 18-AUG-11 09:59:13 18-AUG-11 10:25:51 NO
        14 18-AUG-11 09:59:13 18-AUG-11 10:25:51 NO
        15 18-AUG-11 10:25:51 18-AUG-11 11:02:38 NO
        15 18-AUG-11 10:25:51 18-AUG-11 11:02:38 NO
        16 18-AUG-11 11:02:38 18-AUG-11 11:03:30 NO
        16 18-AUG-11 11:02:38 18-AUG-11 11:03:30 NO
        17 18-AUG-11 11:03:30 18-AUG-11 11:09:24 NO
        17 18-AUG-11 11:03:30 18-AUG-11 11:09:24 YES
        17 18-AUG-11 11:03:30 18-AUG-11 11:09:24 NO
        18 18-AUG-11 11:09:24 18-AUG-11 11:24:33 NO
        18 18-AUG-11 11:09:24 18-AUG-11 11:24:33 YES

 SEQUENCE# FIRST_TIME         NEXT_TIME          APP
---------- ------------------ ------------------ ---
        18 18-AUG-11 11:09:24 18-AUG-11 11:24:33 NO
        19 18-AUG-11 11:24:33 18-AUG-11 11:25:43 NO
        19 18-AUG-11 11:24:33 18-AUG-11 11:25:43 NO
        19 18-AUG-11 11:24:33 18-AUG-11 11:25:43 YES
        20 18-AUG-11 11:25:43 18-AUG-11 11:27:09 NO
        20 18-AUG-11 11:25:43 18-AUG-11 11:27:09 NO
        20 18-AUG-11 11:25:43 18-AUG-11 11:27:09 YES
        85 17-AUG-11 07:06:49 17-AUG-11 10:52:31 YES
        86 17-AUG-11 10:52:31 17-AUG-11 10:52:49 YES
        87 17-AUG-11 10:52:49 17-AUG-11 11:11:11 YES
        88 17-AUG-11 11:11:11 17-AUG-11 11:17:59 YES

 SEQUENCE# FIRST_TIME         NEXT_TIME          APP
---------- ------------------ ------------------ ---
        89 17-AUG-11 11:17:59 17-AUG-11 11:18:32 YES
        90 17-AUG-11 11:18:32 17-AUG-11 11:27:44 YES
        91 17-AUG-11 11:27:44 17-AUG-11 11:30:15 YES
        92 17-AUG-11 11:30:15 17-AUG-11 11:30:33 YES
        93 17-AUG-11 11:30:33 18-AUG-11 12:07:11 YES
        94 18-AUG-11 12:07:11 18-AUG-11 12:18:27 YES
        95 18-AUG-11 12:18:27 18-AUG-11 12:20:06 YES
        96 18-AUG-11 12:20:06 18-AUG-11 04:23:31 YES
        97 18-AUG-11 04:23:31 18-AUG-11 04:38:30 YES
        98 18-AUG-11 04:38:30 18-AUG-11 04:43:47 YES
        99 18-AUG-11 04:43:47 18-AUG-11 04:53:19 YES

 SEQUENCE# FIRST_TIME         NEXT_TIME          APP
---------- ------------------ ------------------ ---
       100 18-AUG-11 04:53:19 18-AUG-11 04:54:28 YES
       101 18-AUG-11 04:54:28 18-AUG-11 05:04:19 YES
       102 18-AUG-11 05:04:19 18-AUG-11 05:05:41 YES
       103 18-AUG-11 05:05:41 18-AUG-11 05:53:41 YES
       104 18-AUG-11 05:53:41 18-AUG-11 05:57:34 YES
       104 18-AUG-11 05:53:41 18-AUG-11 05:57:34 YES

72 rows selected.



notice the last sequence is 104.

SYS@chicago>SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, applied FROM V$ARCHIVED_LOG
 ORDER BY SEQUENCE#;

 SEQUENCE# FIRST_TIME           NEXT_TIME            APP
---------- -------------------- -------------------- ---
         1 18-AUG-2011 17:57:49 18-AUG-2011 18:18:46 YES
         2 18-AUG-2011 18:18:46 18-AUG-2011 18:29:52 YES
         3 18-AUG-2011 18:29:52 18-AUG-2011 18:30:44 YES
         4 18-AUG-2011 18:30:44 18-AUG-2011 18:34:42 YES
         5 18-AUG-2011 18:34:42 18-AUG-2011 18:35:22 YES
         6 18-AUG-2011 18:35:22 18-AUG-2011 18:37:20 YES
         7 18-AUG-2011 18:37:20 18-AUG-2011 18:38:50 YES
         8 18-AUG-2011 18:38:50 18-AUG-2011 19:41:28 YES
         9 18-AUG-2011 19:41:28 18-AUG-2011 19:44:42 YES
        10 18-AUG-2011 19:44:42 18-AUG-2011 19:54:11 YES
        11 18-AUG-2011 19:54:11 18-AUG-2011 20:21:20 YES

 SEQUENCE# FIRST_TIME           NEXT_TIME            APP
---------- -------------------- -------------------- ---
        12 18-AUG-2011 20:21:20 18-AUG-2011 21:58:21 YES
        13 18-AUG-2011 21:58:21 18-AUG-2011 21:59:13 YES
        14 18-AUG-2011 21:59:13 18-AUG-2011 22:25:51 YES
        15 18-AUG-2011 22:25:51 18-AUG-2011 23:02:38 YES
        16 18-AUG-2011 23:02:38 18-AUG-2011 23:03:30 YES
        17 18-AUG-2011 23:03:30 18-AUG-2011 23:09:24 YES
        18 18-AUG-2011 23:09:24 18-AUG-2011 23:24:33 YES
        19 18-AUG-2011 23:24:33 18-AUG-2011 23:25:43 YES
        20 18-AUG-2011 23:25:43 18-AUG-2011 23:27:09 YES
        92 17-AUG-2011 23:30:15 17-AUG-2011 23:30:33 NO
        93 17-AUG-2011 23:30:33 18-AUG-2011 12:07:11 NO

 SEQUENCE# FIRST_TIME           NEXT_TIME            APP
---------- -------------------- -------------------- ---
        94 18-AUG-2011 12:07:11 18-AUG-2011 12:18:27 NO
        95 18-AUG-2011 12:18:27 18-AUG-2011 12:20:06 NO
        96 18-AUG-2011 12:20:06 18-AUG-2011 16:23:31 NO
        97 18-AUG-2011 16:23:31 18-AUG-2011 16:38:30 NO
        98 18-AUG-2011 16:38:30 18-AUG-2011 16:43:47 NO
        99 18-AUG-2011 16:43:47 18-AUG-2011 16:53:19 NO
       100 18-AUG-2011 16:53:19 18-AUG-2011 16:54:28 NO
       101 18-AUG-2011 16:54:28 18-AUG-2011 17:04:19 NO
       102 18-AUG-2011 17:04:19 18-AUG-2011 17:05:41 NO
       103 18-AUG-2011 17:05:41 18-AUG-2011 17:53:41 NO


notice the last sequence is 103

this looks weird if I'm failover from chicago to boston how come chicago has one sequence less than boston?

List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1521 1522 CHICAGO 1369129282 PARENT 1 17-AUG-11
1521 8481 CHICAGO 1369129282 CURRENT 361545 18-AUG-11

it confirms that the new db configuration now has two incarnation which is weird, becoz I've read the role transition, failover from

http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/role_management.htm#i1026491 many times, no where has it state the a new incarnation will take place.

that's whenever I perform a failover again

Quote:


Step 1 Identify and resolve any gaps in the archived redo log files.



  1* SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#)
 AS LAST from V$ARCHIVED_LOG;
SYS@chicago>SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY t
hread#) AS LAST from V$ARCHIVED_LOG;

    THREAD       LAST
---------- ----------
         1        103


I always have this error.

but if I take into account the RESETLOGS_CHANGE# =, i.e. doing a modified query as below,

  1* SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#)
 AS LAST from V$ARCHIVED_LOG where RESETLOGS_CHANGE# = 361545
SYS@chicago>/

    THREAD       LAST
---------- ----------
         1         20


it will report another thing.

May I know is it wrong to expect this type of behavior where by the former primary db has few sequences being archived than the new primary? do we need to consider the RESETLOGS_CHANGE#

thanks in advance!

thanks
Previous Topic: Why new physical standby database cannot received redo log after fail o ver
Next Topic: primary don't want be open after standby configuration
Goto Forum:
  


Current Time: Sat Dec 27 21:13:56 CST 2014

Total time taken to generate the page: 0.21214 seconds