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.
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