itspace
- 浏览: 978783 次
- 性别:
- 来自: 杭州
-
文章分类
最新评论
-
孤星119：
好熟悉的数据库字段啊， 上家公司做的项目每天都跟这些字段打招呼 ...
Oracle exp compress参数引起的空间浪费 -
itspace：
quxiaoyong 写道遇到个问题，网上一搜，全他妈这篇文章 ...
数据库连接错误ORA-28547 -
quxiaoyong：
遇到个问题，网上一搜，全他妈这篇文章。你转来转去的有意思吗？
数据库连接错误ORA-28547 -
hctech：
关于version count过高的问题，不知博主是否看过ey ...
某客户数据库性能诊断报告 -
itspace：
invalid 写道写的不错，我根据这个来安装，有点理解错误了 ...
AIX 配置vncserver
本实验纯模拟主库宕机情况下，激活备库的情况(强行激活)
[root@dbsvr tmp]# uname -a
Linux dbsvr 2.6.9-42.EL #1 Wed Jul 12 23:15:20 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
PL/SQL Release 9.2.0.4.0 - Production
CORE 9.2.0.3.0 Production
TNS for Linux: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production
一：不完全恢复激活备库
1.创建standby ctl
SQL> alter database create standby controlfile as '/oracle/app/oradata/test9i/c.ctl';
Database altered.
2。查询控制文件位置
SQL> select name from v$controlfile;
NAME
--------------------------------------------------------------------------------
/oracle/app/oradata/test9i/control01.ctl
/oracle/app/oradata/test9i/control02.ctl
/oracle/app/oradata/test9i/control03.ctl
3.将原来的ctl替换掉
[oracle@dbsvr test9i]$ mv c.ctl control01.ctl
[oracle@dbsvr test9i]$ cp control01.ctl control02.ctl
[oracle@dbsvr test9i]$ cp control01.ctl control03.ctl
4.启动备库
SQL> startup nomount
ORACLE instance started.
Total System Global Area 320308744 bytes
Fixed Size 742920 bytes
Variable Size 285212672 bytes
Database Buffers 33554432 bytes
Redo Buffers 798720 bytes
SQL> alter database mount standby database;
Database altered.
SQL> select resetlogs_change# from v$database;
RESETLOGS_CHANGE#
-----------------
227130
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
/oracle/app/oradata/test9i/system01.dbf
/oracle/app/oradata/test9i/undotbs01.dbf
/oracle/app/oradata/test9i/drsys01.dbf
/oracle/app/oradata/test9i/indx01.dbf
/oracle/app/oradata/test9i/tools01.dbf
/oracle/app/oradata/test9i/users01.dbf
/oracle/app/oradata/test9i/xdb01.dbf
/oracle/app/oradata/test9i/test01.dbf.bak
8 rows selected.
5。激活备库
SQL> alter database activate standby database;
Database altered.
其中alert日志显示
Sun Jun 14 01:56:18 2009
alter database activate standby database
Sun Jun 14 01:56:18 2009
ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE
RESETLOGS after incomplete recovery UNTIL CHANGE 304398[/b]
Resetting resetlogs activation ID 0 (0x0)
Sun Jun 14 01:56:30 2009
Online log 3 of thread 1 was previously cleared
Activation complete - Database shutdown not required
Completed: alter database activate standby database
可见数据库进行了不完全恢复，见粗体部分
6。ctl从standby ctl变成了normal ctl，用正常的mount命令，mount数据库
SQL> alter database mount;
Database altered.
7。查询resetlogs_change#，可以看到数据库其实是resetlogs了
SQL> select resetlogs_change# from v$database;
RESETLOGS_CHANGE#
-----------------
304399
8。打开数据库
SQL> alter database open;
Database altered.
二：完全恢复的情况下激活备份，即不进行resetlogs打开备库
1.查询备份库resetlogs_change，作为基准参考
SQL> select resetlogs_change# from v$database;
RESETLOGS_CHANGE#
-----------------
304399
2。创建standby ctl
SQL> alter database create standby controlfile as '/oracle/app/oradata/test9i/c.ctl';
Database altered.
3.替换控制文件，并重新启动
SQL> startup nomount
ORACLE instance started.
Total System Global Area 320308744 bytes
Fixed Size 742920 bytes
Variable Size 285212672 bytes
Database Buffers 33554432 bytes
Redo Buffers 798720 bytes
SQL> alter database mount standby database;
Database altered.
4。恢复库
SQL> recover standby database;
ORA-00279: change 304442 generated at 06/14/2009 01:57:33 needed for thread 1
ORA-00289: suggestion : /tmp/1_1.dbf
ORA-00280: change 304442 for thread 1 is in sequence #1
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/oracle/app/oradata/test9i/redo02.log
Log applied.
Media recovery complete.
alert日志显示
Sun Jun 14 02:11:31 2009
ALTER DATABASE RECOVER standby database
Sun Jun 14 02:11:31 2009
Media Recovery Start
Starting datafile 1 recovery in thread 1 sequence 1
Datafile 1: '/oracle/app/oradata/test9i/system01.dbf'
Starting datafile 2 recovery in thread 1 sequence 1
Datafile 2: '/oracle/app/oradata/test9i/undotbs01.dbf'
Starting datafile 3 recovery in thread 1 sequence 1
Datafile 3: '/oracle/app/oradata/test9i/drsys01.dbf'
Starting datafile 4 recovery in thread 1 sequence 1
Datafile 4: '/oracle/app/oradata/test9i/indx01.dbf'
Starting datafile 5 recovery in thread 1 sequence 1
Datafile 5: '/oracle/app/oradata/test9i/tools01.dbf'
Starting datafile 6 recovery in thread 1 sequence 1
Datafile 6: '/oracle/app/oradata/test9i/users01.dbf'
Starting datafile 7 recovery in thread 1 sequence 1
Datafile 7: '/oracle/app/oradata/test9i/xdb01.dbf'
Starting datafile 8 recovery in thread 1 sequence 1
Datafile 8: '/oracle/app/oradata/test9i/test01.dbf.bak'
Media Recovery Log
ORA-279 signalled during: ALTER DATABASE RECOVER standby database ...
Sun Jun 14 02:11:38 2009
ALTER DATABASE RECOVER LOGFILE '/oracle/app/oradata/test9i/redo02.log'
Media Recovery Log /oracle/app/oradata/test9i/redo02.log
Sun Jun 14 02:11:38 2009
Media recovery opens logfile:
Thread: 1 Sequence: 1 Logfile name: /oracle/app/oradata/test9i/redo02.log
Sun Jun 14 02:11:38 2009
Media recovery closes logfile:
Thread: 1 Sequence: 1 Logfile name: /oracle/app/oradata/test9i/redo02.log
Incomplete recovery applied all redo ever generated.
Recovery completed through change 304731
Media Recovery Complete
Completed: ALTER DATABASE RECOVER LOGFILE '/oracle/app/ora
5。尝试打开备库
SQL> alter database commit to switchover to primary;
alter database commit to switchover to primary
*
ERROR at line 1:
ORA-16139: media recovery required
alter日志显示
Sun Jun 14 02:12:54 2009
alter database commit to switchover to primary
Sun Jun 14 02:12:54 2009
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
Database not recovered through End-Of-REDO
Database not recovered through End-Of-REDO
Switchover: Media recovery required - standby not in limbo
ORA-16139 signalled during: alter database commit to switchover to primary...
Sun Jun 14 02:13:50 2009
alter database recover managed standby database finish skip standby logfile
Sun Jun 14 02:13:50 2009
Database not recovered through End-Of-REDO
显示恢复还需要syandby redolog，于是使用下列命令。注意此命令在10g不支持了
SQL> alter database recover managed standby database finish skip standby logfile;
Database altered.
查询v$log表可以看到ORACEL自动创建了standby redolog
SQL> select * from v$logfile;
GROUP# STATUS TYPE
---------- ------- -------
MEMBER
--------------------------------------------------------------------------------
2 ONLINE
/oracle/app/oradata/test9i/redo02.log
3 ONLINE
/oracle/app/oradata/test9i/redo03.log
1 ONLINE
/oracle/app/oradata/test9i/redo01.log
4 STANDBY
/tmp/1_0.dbf
alerlog日志显示次standby redolog再次应用了
Database not recovered through End-Of-REDO
Attempt to do a Terminal Incomplete Recovery
Media Recovery Start: Managed Standby Recovery
Starting datafile 1 recovery in thread 1 sequence 1
Datafile 1: '/oracle/app/oradata/test9i/system01.dbf'
Starting datafile 2 recovery in thread 1 sequence 1
Datafile 2: '/oracle/app/oradata/test9i/undotbs01.dbf'
Starting datafile 3 recovery in thread 1 sequence 1
Datafile 3: '/oracle/app/oradata/test9i/drsys01.dbf'
Starting datafile 4 recovery in thread 1 sequence 1
Datafile 4: '/oracle/app/oradata/test9i/indx01.dbf'
Starting datafile 5 recovery in thread 1 sequence 1
Datafile 5: '/oracle/app/oradata/test9i/tools01.dbf'
Starting datafile 6 recovery in thread 1 sequence 1
Datafile 6: '/oracle/app/oradata/test9i/users01.dbf'
Starting datafile 7 recovery in thread 1 sequence 1
Datafile 7: '/oracle/app/oradata/test9i/xdb01.dbf'
Starting datafile 8 recovery in thread 1 sequence 1
Datafile 8: '/oracle/app/oradata/test9i/test01.dbf.bak'
Media Recovery Log
Media Recovery Waiting for thread 1 seq# 1
Terminal Incomplete Recovery: UNTIL CHANGE 304731
Terminal Incomplete Recovery: End-Of-Redo log allocation
Terminal Incomplete Recovery: log 4 created '/tmp/1_0.dbf'
Terminal Incomplete Recovery: log 4 reserved for thread 1 seq# 1
TERMINAL RECOVERY changing datafile format version from 8.0.0.0.0 to 9.0.0.0.0
Switching logfile format version from 8.0.0.0.0 to 9.0.0.0.0
Terminal Incomplete Recovery: clearing standby redo logs.
Terminal Incomplete Recovery: thread 1 seq# 1 redo required
Terminal Incomplete Recovery: End-Of-Redo log /tmp/1_0.dbf
Identified end-of-REDO for thread 1 sequence 1
Sun Jun 14 02:14:05 2009
Media recovery opens logfile:
Thread: 1 Sequence: 1 Logfile name: /tmp/1_0.dbf
Sun Jun 14 02:14:05 2009
Media recovery closes logfile:
Thread: 1 Sequence: 1 Logfile name: /tmp/1_0.dbf
Terminal Incomplete Recovery: end checkpoint SCN 304060
Media Recovery Complete
Switching logfile format version from 9.0.0.0.0 to 8.0.0.0.0
Terminal Incomplete Recovery: successful completion
Begin: Wait for standby logfiles to be archived
Sun Jun 14 02:14:05 2009
ARC1: Evaluating archive log 4 thread 1 sequence 1
Sun Jun 14 02:14:05 2009
ARC0: Evaluating archive log 4 thread 1 sequence 1
ARC0: Unable to archive log 4 thread 1 sequence 1
Log actively being archived by another process
Sun Jun 14 02:14:05 2009
ARC1: Beginning to archive log 4 thread 1 sequence 1
Creating archive destination LOG_ARCHIVE_DEST_1: '/tmp/1_1.dbf'
ARC1: Completed archiving log 4 thread 1 sequence 1
Sun Jun 14 02:14:20 2009
End: All standby logfiles have been archived
Resetting standby activation ID 2426500015 (0x90a173af)
Completed: alter database recover managed standby database fi
6.再次尝试FALLOVER备份库
SQL> alter database commit to switchover to primary;
Database altered.
alert日志显示了此过程
Sun Jun 14 02:14:20 2009
End: All standby logfiles have been archived
Resetting standby activation ID 2426500015 (0x90a173af)
Completed: alter database recover managed standby database fi
Sun Jun 14 02:22:14 2009
alter database commit to switchover to primary
Sun Jun 14 02:22:14 2009
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
NORESETLOGS after complete recovery through change 304731
Resetting resetlogs activation ID 0 (0x0)
Online log 1 of thread 1 was previously cleared
Online log 3 of thread 1 was previously cleared
Changing control file format version from 8.0.0.0.0 to 9.0.0.0.0
RESETLOGS changing datafile format version from 9.0.0.0.0 to 8.0.0.0.0
Switchover: Complete - Database shutdown required
Completed: alter database commit to switchover to primary
alter database mount
Sun Jun 14 02:23:25 2009
Database in limbo -- Shutdown Required.
7。打开数据库并查询resetlogs_change
SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-01100: database already mounted
SQL> shutdown immediate
ORA-01507: database not mounted
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 320308744 bytes
Fixed Size 742920 bytes
Variable Size 285212672 bytes
Database Buffers 33554432 bytes
Redo Buffers 798720 bytes
Database mounted.
SQL> select resetlogs_change# from v$database;
RESETLOGS_CHANGE#
-----------------
304399
可以看到reselogs_change并没有改变
总结：
一般情况推荐使用第二种方法，第二种方法如果主库有多个备库，当激活其中一个备库之后可以作为其他备库的主库。
在9i环境中不推荐使用第一种方法，因为当备库reselog之后以为着需要重新做一次0级全备，当然了在10g环境中不需要做0级备份，因为ORACLE提供了闪回机制。呵呵
附：
切换后，不能将数据库read only打开，alert日志显示：
Errors in file /oracle/app/admin/test9i/udump/test9i_ora_30489.trc:
ORA-00376: file 1 cannot be read at this time
ORA-01110: data file 1: '/oracle/app/oradata/test9i/system01.dbf'
Sun Jun 14 03:03:46 2009
Error 376 happened during db open, shutting down database
USER: terminating instance due to error 376
Instance terminated by USER, pid = 30489
ORA-1092 signalled during: alter database open read only...
可以看到在read write打开过程中，数据虽然不重置resetlogs_change，但重置了activation ID：
LGWR: Primary database is in CLUSTER CONSISTENT mode
Assigning activation ID 2426541760 (0x90a216c0)
Thread 1 opened at log sequence 3
Current log# 2 seq# 3 mem# 0: /oracle/app/oradata/test9i/redo02.log
Successful open of redo thread 1.
[root@dbsvr tmp]# uname -a
Linux dbsvr 2.6.9-42.EL #1 Wed Jul 12 23:15:20 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
PL/SQL Release 9.2.0.4.0 - Production
CORE 9.2.0.3.0 Production
TNS for Linux: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production
一：不完全恢复激活备库
1.创建standby ctl
SQL> alter database create standby controlfile as '/oracle/app/oradata/test9i/c.ctl';
Database altered.
2。查询控制文件位置
SQL> select name from v$controlfile;
NAME
--------------------------------------------------------------------------------
/oracle/app/oradata/test9i/control01.ctl
/oracle/app/oradata/test9i/control02.ctl
/oracle/app/oradata/test9i/control03.ctl
3.将原来的ctl替换掉
[oracle@dbsvr test9i]$ mv c.ctl control01.ctl
[oracle@dbsvr test9i]$ cp control01.ctl control02.ctl
[oracle@dbsvr test9i]$ cp control01.ctl control03.ctl
4.启动备库
SQL> startup nomount
ORACLE instance started.
Total System Global Area 320308744 bytes
Fixed Size 742920 bytes
Variable Size 285212672 bytes
Database Buffers 33554432 bytes
Redo Buffers 798720 bytes
SQL> alter database mount standby database;
Database altered.
SQL> select resetlogs_change# from v$database;
RESETLOGS_CHANGE#
-----------------
227130
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
/oracle/app/oradata/test9i/system01.dbf
/oracle/app/oradata/test9i/undotbs01.dbf
/oracle/app/oradata/test9i/drsys01.dbf
/oracle/app/oradata/test9i/indx01.dbf
/oracle/app/oradata/test9i/tools01.dbf
/oracle/app/oradata/test9i/users01.dbf
/oracle/app/oradata/test9i/xdb01.dbf
/oracle/app/oradata/test9i/test01.dbf.bak
8 rows selected.
5。激活备库
SQL> alter database activate standby database;
Database altered.
其中alert日志显示
Sun Jun 14 01:56:18 2009
alter database activate standby database
Sun Jun 14 01:56:18 2009
ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE
RESETLOGS after incomplete recovery UNTIL CHANGE 304398[/b]
Resetting resetlogs activation ID 0 (0x0)
Sun Jun 14 01:56:30 2009
Online log 3 of thread 1 was previously cleared
Activation complete - Database shutdown not required
Completed: alter database activate standby database
可见数据库进行了不完全恢复，见粗体部分
6。ctl从standby ctl变成了normal ctl，用正常的mount命令，mount数据库
SQL> alter database mount;
Database altered.
7。查询resetlogs_change#，可以看到数据库其实是resetlogs了
SQL> select resetlogs_change# from v$database;
RESETLOGS_CHANGE#
-----------------
304399
8。打开数据库
SQL> alter database open;
Database altered.
二：完全恢复的情况下激活备份，即不进行resetlogs打开备库
1.查询备份库resetlogs_change，作为基准参考
SQL> select resetlogs_change# from v$database;
RESETLOGS_CHANGE#
-----------------
304399
2。创建standby ctl
SQL> alter database create standby controlfile as '/oracle/app/oradata/test9i/c.ctl';
Database altered.
3.替换控制文件，并重新启动
SQL> startup nomount
ORACLE instance started.
Total System Global Area 320308744 bytes
Fixed Size 742920 bytes
Variable Size 285212672 bytes
Database Buffers 33554432 bytes
Redo Buffers 798720 bytes
SQL> alter database mount standby database;
Database altered.
4。恢复库
SQL> recover standby database;
ORA-00279: change 304442 generated at 06/14/2009 01:57:33 needed for thread 1
ORA-00289: suggestion : /tmp/1_1.dbf
ORA-00280: change 304442 for thread 1 is in sequence #1
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/oracle/app/oradata/test9i/redo02.log
Log applied.
Media recovery complete.
alert日志显示
Sun Jun 14 02:11:31 2009
ALTER DATABASE RECOVER standby database
Sun Jun 14 02:11:31 2009
Media Recovery Start
Starting datafile 1 recovery in thread 1 sequence 1
Datafile 1: '/oracle/app/oradata/test9i/system01.dbf'
Starting datafile 2 recovery in thread 1 sequence 1
Datafile 2: '/oracle/app/oradata/test9i/undotbs01.dbf'
Starting datafile 3 recovery in thread 1 sequence 1
Datafile 3: '/oracle/app/oradata/test9i/drsys01.dbf'
Starting datafile 4 recovery in thread 1 sequence 1
Datafile 4: '/oracle/app/oradata/test9i/indx01.dbf'
Starting datafile 5 recovery in thread 1 sequence 1
Datafile 5: '/oracle/app/oradata/test9i/tools01.dbf'
Starting datafile 6 recovery in thread 1 sequence 1
Datafile 6: '/oracle/app/oradata/test9i/users01.dbf'
Starting datafile 7 recovery in thread 1 sequence 1
Datafile 7: '/oracle/app/oradata/test9i/xdb01.dbf'
Starting datafile 8 recovery in thread 1 sequence 1
Datafile 8: '/oracle/app/oradata/test9i/test01.dbf.bak'
Media Recovery Log
ORA-279 signalled during: ALTER DATABASE RECOVER standby database ...
Sun Jun 14 02:11:38 2009
ALTER DATABASE RECOVER LOGFILE '/oracle/app/oradata/test9i/redo02.log'
Media Recovery Log /oracle/app/oradata/test9i/redo02.log
Sun Jun 14 02:11:38 2009
Media recovery opens logfile:
Thread: 1 Sequence: 1 Logfile name: /oracle/app/oradata/test9i/redo02.log
Sun Jun 14 02:11:38 2009
Media recovery closes logfile:
Thread: 1 Sequence: 1 Logfile name: /oracle/app/oradata/test9i/redo02.log
Incomplete recovery applied all redo ever generated.
Recovery completed through change 304731
Media Recovery Complete
Completed: ALTER DATABASE RECOVER LOGFILE '/oracle/app/ora
5。尝试打开备库
SQL> alter database commit to switchover to primary;
alter database commit to switchover to primary
*
ERROR at line 1:
ORA-16139: media recovery required
alter日志显示
Sun Jun 14 02:12:54 2009
alter database commit to switchover to primary
Sun Jun 14 02:12:54 2009
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
Database not recovered through End-Of-REDO
Database not recovered through End-Of-REDO
Switchover: Media recovery required - standby not in limbo
ORA-16139 signalled during: alter database commit to switchover to primary...
Sun Jun 14 02:13:50 2009
alter database recover managed standby database finish skip standby logfile
Sun Jun 14 02:13:50 2009
Database not recovered through End-Of-REDO
显示恢复还需要syandby redolog，于是使用下列命令。注意此命令在10g不支持了
SQL> alter database recover managed standby database finish skip standby logfile;
Database altered.
查询v$log表可以看到ORACEL自动创建了standby redolog
SQL> select * from v$logfile;
GROUP# STATUS TYPE
---------- ------- -------
MEMBER
--------------------------------------------------------------------------------
2 ONLINE
/oracle/app/oradata/test9i/redo02.log
3 ONLINE
/oracle/app/oradata/test9i/redo03.log
1 ONLINE
/oracle/app/oradata/test9i/redo01.log
4 STANDBY
/tmp/1_0.dbf
alerlog日志显示次standby redolog再次应用了
Database not recovered through End-Of-REDO
Attempt to do a Terminal Incomplete Recovery
Media Recovery Start: Managed Standby Recovery
Starting datafile 1 recovery in thread 1 sequence 1
Datafile 1: '/oracle/app/oradata/test9i/system01.dbf'
Starting datafile 2 recovery in thread 1 sequence 1
Datafile 2: '/oracle/app/oradata/test9i/undotbs01.dbf'
Starting datafile 3 recovery in thread 1 sequence 1
Datafile 3: '/oracle/app/oradata/test9i/drsys01.dbf'
Starting datafile 4 recovery in thread 1 sequence 1
Datafile 4: '/oracle/app/oradata/test9i/indx01.dbf'
Starting datafile 5 recovery in thread 1 sequence 1
Datafile 5: '/oracle/app/oradata/test9i/tools01.dbf'
Starting datafile 6 recovery in thread 1 sequence 1
Datafile 6: '/oracle/app/oradata/test9i/users01.dbf'
Starting datafile 7 recovery in thread 1 sequence 1
Datafile 7: '/oracle/app/oradata/test9i/xdb01.dbf'
Starting datafile 8 recovery in thread 1 sequence 1
Datafile 8: '/oracle/app/oradata/test9i/test01.dbf.bak'
Media Recovery Log
Media Recovery Waiting for thread 1 seq# 1
Terminal Incomplete Recovery: UNTIL CHANGE 304731
Terminal Incomplete Recovery: End-Of-Redo log allocation
Terminal Incomplete Recovery: log 4 created '/tmp/1_0.dbf'
Terminal Incomplete Recovery: log 4 reserved for thread 1 seq# 1
TERMINAL RECOVERY changing datafile format version from 8.0.0.0.0 to 9.0.0.0.0
Switching logfile format version from 8.0.0.0.0 to 9.0.0.0.0
Terminal Incomplete Recovery: clearing standby redo logs.
Terminal Incomplete Recovery: thread 1 seq# 1 redo required
Terminal Incomplete Recovery: End-Of-Redo log /tmp/1_0.dbf
Identified end-of-REDO for thread 1 sequence 1
Sun Jun 14 02:14:05 2009
Media recovery opens logfile:
Thread: 1 Sequence: 1 Logfile name: /tmp/1_0.dbf
Sun Jun 14 02:14:05 2009
Media recovery closes logfile:
Thread: 1 Sequence: 1 Logfile name: /tmp/1_0.dbf
Terminal Incomplete Recovery: end checkpoint SCN 304060
Media Recovery Complete
Switching logfile format version from 9.0.0.0.0 to 8.0.0.0.0
Terminal Incomplete Recovery: successful completion
Begin: Wait for standby logfiles to be archived
Sun Jun 14 02:14:05 2009
ARC1: Evaluating archive log 4 thread 1 sequence 1
Sun Jun 14 02:14:05 2009
ARC0: Evaluating archive log 4 thread 1 sequence 1
ARC0: Unable to archive log 4 thread 1 sequence 1
Log actively being archived by another process
Sun Jun 14 02:14:05 2009
ARC1: Beginning to archive log 4 thread 1 sequence 1
Creating archive destination LOG_ARCHIVE_DEST_1: '/tmp/1_1.dbf'
ARC1: Completed archiving log 4 thread 1 sequence 1
Sun Jun 14 02:14:20 2009
End: All standby logfiles have been archived
Resetting standby activation ID 2426500015 (0x90a173af)
Completed: alter database recover managed standby database fi
6.再次尝试FALLOVER备份库
SQL> alter database commit to switchover to primary;
Database altered.
alert日志显示了此过程
Sun Jun 14 02:14:20 2009
End: All standby logfiles have been archived
Resetting standby activation ID 2426500015 (0x90a173af)
Completed: alter database recover managed standby database fi
Sun Jun 14 02:22:14 2009
alter database commit to switchover to primary
Sun Jun 14 02:22:14 2009
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
NORESETLOGS after complete recovery through change 304731
Resetting resetlogs activation ID 0 (0x0)
Online log 1 of thread 1 was previously cleared
Online log 3 of thread 1 was previously cleared
Changing control file format version from 8.0.0.0.0 to 9.0.0.0.0
RESETLOGS changing datafile format version from 9.0.0.0.0 to 8.0.0.0.0
Switchover: Complete - Database shutdown required
Completed: alter database commit to switchover to primary
alter database mount
Sun Jun 14 02:23:25 2009
Database in limbo -- Shutdown Required.
7。打开数据库并查询resetlogs_change
SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-01100: database already mounted
SQL> shutdown immediate
ORA-01507: database not mounted
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 320308744 bytes
Fixed Size 742920 bytes
Variable Size 285212672 bytes
Database Buffers 33554432 bytes
Redo Buffers 798720 bytes
Database mounted.
SQL> select resetlogs_change# from v$database;
RESETLOGS_CHANGE#
-----------------
304399
可以看到reselogs_change并没有改变
总结：
一般情况推荐使用第二种方法，第二种方法如果主库有多个备库，当激活其中一个备库之后可以作为其他备库的主库。
在9i环境中不推荐使用第一种方法，因为当备库reselog之后以为着需要重新做一次0级全备，当然了在10g环境中不需要做0级备份，因为ORACLE提供了闪回机制。呵呵
附：
切换后，不能将数据库read only打开，alert日志显示：
Errors in file /oracle/app/admin/test9i/udump/test9i_ora_30489.trc:
ORA-00376: file 1 cannot be read at this time
ORA-01110: data file 1: '/oracle/app/oradata/test9i/system01.dbf'
Sun Jun 14 03:03:46 2009
Error 376 happened during db open, shutting down database
USER: terminating instance due to error 376
Instance terminated by USER, pid = 30489
ORA-1092 signalled during: alter database open read only...
可以看到在read write打开过程中，数据虽然不重置resetlogs_change，但重置了activation ID：
LGWR: Primary database is in CLUSTER CONSISTENT mode
Assigning activation ID 2426541760 (0x90a216c0)
Thread 1 opened at log sequence 3
Current log# 2 seq# 3 mem# 0: /oracle/app/oradata/test9i/redo02.log
Successful open of redo thread 1.
1
顶
顶
0
踩
踩
分享到：
发表评论
-
buffer cache 的内部结构
2020-03-18 14:21 578BUFFER CACHE作为数据块的 ... -
Oracle OMC介绍
2020-03-18 13:19 486Oracle管理云服务（OMC）的大数据平台，自动收集的企业 ... -
参加Oracle勒索病毒防范专题培训会议
2019-09-27 17:15 5132019年7月22日，受邀参加Oracle勒索病毒防范专题培训 ... -
记一次内存换IO的Oracle优化
2019-09-27 16:50 827某客户数据库从P595物理 ... -
如何定位Oracle SQL执行计划变化的原因
2019-07-03 14:49 1460性能优化最难的是能够 ... -
如何定位Oracle SQL执行计划变化的原因
2018-10-30 09:24 1185性能优化最难的是能够 ... -
数据库性能优化目标
2018-10-08 10:59 518从数据库性能优化的场 ... -
数据库无法打开的原因及解决办法
2018-10-05 20:45 2120数据库的启动是一个相当复杂的过程。比如，Oracle在启动之前 ... -
怎么样彻底删除数据库？
2018-09-18 11:10 599Oracle提供了drop database命令用来删除数据库 ... -
Oracle减少日志量的方法
2018-09-10 10:17 867LGWR进程将LOG BUFFER中的 ... -
如何快速关闭数据库
2018-09-09 13:14 1233“一朝被蛇咬，十年怕井绳”。在没被“蛇”咬之前，很多DBA喜欢 ... -
关于《如何落地智能化运维》PPT
2018-05-17 10:19 1129在DTCC 2018发表《如何落地智能化运维》演讲，主要内容如 ... -
记录在redhat5.8平台安装oracle11.2容易忽视的几个问题
2018-05-11 19:58 578问题一：ping不通问题 在虚拟机上安装好linux系统后， ... -
《Oracle DBA实战攻略》第一章
2018-05-11 10:42 947即日起，不定期更新《OracleDBA实战攻略》一书电子版，请 ... -
Oracle 12c新特性
2018-05-11 10:33 900查询所有pdb [oracle@gj4 ~]$ sqlplu ... -
关于修改memory_target的值后数据库无法启动的问题
2017-02-28 12:24 3983操作系统：RHEL6.5 数据库版本：11.2.0.4 ... -
10g rac安装error while loading shared libraries libpthread.so.0 问题
2017-02-28 12:22 69311g rac安装在二节点跑脚本一般会报此错误： 解决这个问 ... -
记一次Oracle会话共享模式故障处理过程
2017-02-27 19:16 799故障简述 XXX第八人民医院HIS数据库7月13日11点左右从 ... -
RESMGR:cpu quantum等待事件处理过程
2017-02-27 18:23 2615由于数据库上线过程中出现大量的RESMGR:cpu quant ... -
谈谈log file sync
2014-03-19 14:18 1759数据库中的log file sync等待事件指的是，当user ...
相关推荐
Oracle 11g的数据保护功能得到加强，Data Guard提供了更多的高可用性和灾难恢复选项，如逻辑 standby、redo apply 和 fast-start failover，确保业务连续性。 6. **Partitioning Enhancements** 分区功能在Oracle...
当一个实例故障时，Failover技术会自动将连接转移到其他正常运行的实例，保证用户不会感知到中断。LoadBalance则负责将用户请求均匀地分散到各个节点，提高系统处理并发请求的能力。共享存储设备使得所有实例都能...
Oracle10g是Oracle数据库的一个重要版本，发布于2003年，它引入了...深入研究每个主题，将使你能够更全面地理解和管理Oracle数据库系统。无论是数据库管理员、开发人员还是IT专业人员，这份文档都将是宝贵的参考资料。
4. **高可用性策略**：讨论数据保护和故障恢复机制，如 Voting Disks、Redo Logs、Flashback Technology以及Fast Start Failover等。 5. **性能优化**：讲述如何利用RAC的特性来提高数据库性能，例如负载均衡、资源...
Oracle 12c增强了高可用性特性，例如快速故障切换（Fast-Start Failover）和数据守护（Data Guard）功能的改进。数据守护提供了更灵活的保护模式，允许在不影响主数据库性能的情况下提供实时的数据备份。 3. SQL...
7. **Fast Start Failover (FSFO)**：在客户端连接到数据库服务时，Oracle RAC会预先建立备用连接，当主实例出现故障时，客户端连接能迅速切换到备用实例，实现无缝故障转移。 8. **Grid Infrastructure**：Oracle...
为了进一步提升系统的灾难恢复能力，可以通过模拟故障进行Data Guard的Failover模式演练，人为破坏主库并进行主备库切换，以验证和优化恢复流程。这种技术对于依赖Oracle数据库的企业来说，是保障业务连续性和数据...
4. 透明应用切换（Transparent Application Failover） 透明应用切换是RAC的一项重要功能，当某节点或实例出现故障时，客户端应用程序无需进行任何修改，即可自动连接到其他正常运行的实例，实现服务的无缝切换，...
### Oracle 10g RAC核心技术研究与分析 #### 核心知识点概览 本文深入探讨了Oracle 10g RAC（Real Application Clusters）的核心技术及其在企业级IT解决方案中的应用价值。RAC作为Oracle 10g的重要组成部分，通过...
Oracle集群是一种高可用性和高性能的解决方案，用于运行关键业务应用程序。这种技术允许多个数据库服务器（节点）共享同一数据库，...通过深入研究这些内容，可以提升对Oracle集群环境的管理、故障排除和性能调优能力。
文章最后指出，Oracle RAC集群技术的应用研究，对提升高校图书馆关键业务的服务质量和稳定性有重要意义。RAC技术提供的高可用性、高扩展性和高容错性，使得图书馆能以高效、稳定的方式处理繁重的信息服务任务，为...
以上内容涵盖了Oracle 9i DBA的关键知识点，但实际的“Oracle 9i DBA 2 ppt”演示文稿可能会详细讨论这些主题中的某些部分，也可能包含具体的案例研究和最佳实践。通过学习和掌握这些知识，数据库管理员可以有效地...
6. **高可用性和灾难恢复**：讨论RAC的高可用性特性，如Fast Start Failover (FSFO)、Data Guard、Active Data Guard，以及如何制定有效的灾难恢复计划。 7. **安全管理**：阐述如何在RAC环境中实施用户权限管理、...
3. **保护模式**：研究不同保护模式的优缺点，如最大保护、最大可用和最大性能模式，以及何时选择合适的模式。 4. **Failover和Switchover**：学习如何在主备数据库之间安全地进行故障切换和角色切换，以确保业务...
根据给定的文件信息，我们可以深入探讨Oracle HA（High Availability）相关的专业知识点，尤其是Oracle ...对于任何希望构建高可用性数据库架构的企业来说，Oracle DataGuard都是一个值得深入研究和实践的重要技术。
证券公司网站及网上交易系统解决方案 知识点一：Oracle8i 的网络特性和管理能力 Oracle8i 提供了先进的网络特性和管理能力，引入了 Oracle...在节点和簇的实现中结合了加载平衡和 Failover，使机构能够支持几千用户。
TUXEDO，全称为“Transparent Application Failover”，是BEA（后被Oracle收购）开发的一款分布式事务处理中间件，它提供了高可用性和可伸缩性，广泛应用于金融、电信等对数据一致性要求极高的领域。 这份培训资料...
2. 操作系统层面：例如Windows Failover Clustering (WFC) for Windows Server。 3. 虚拟化层面：例如vSphere High Availability (HA) and vSphere Fault Tolerance (FT)。 4. 物理层面：例如多个网络接口卡、存储...
阿里巴巴还致力于构建一个完整的分布式数据库生态系统，旨在解决一系列核心问题，如故障转移（Failover）、前后端一致性保障等。 - **关键组件**： - **Erosa**：负责数据解析。 - **Eromanga**：负责数据消费。 ...