系统崩溃造成数据库无法启动的恢复

本本突然蓝屏，当时数据库是打开使用中的，重启后，启动实例，准备连接数据库继续使用，发现无法连接，一直报：
SQL> conn system/test@test
ERROR:
ORA-12514: TNS: 监听程序当前无法识别连接描述符中请求的服务

一开始以为数据库还没启动完毕，于是重启了数据库服务，多次未果，没有怀疑数据库有问题，因为之前也遇到过多次在打开oracle的情况下系统崩溃的情况，重启系统后还是能正常使用的。
多次连接不上之后，才想起来去看下alter文件，一看果然出现问题了：
Sun Jul 17 13:26:15 2011
Recovery of Online Redo Log: Thread 1 Group 2 Seq 3 Reading mem 0
Mem# 0 errs 0: D:\ORACLE\PRODUCT\10.2.0\DB_1\ORADATA\TEST\REDO02.LOG
Sun Jul 17 13:26:15 2011
Errors in file d:\oracle\product\10.2.0\db_1\admin\test\bdump\test_dbw0_2904.trc:
ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [_kcbzdh+583] [PC:0x4A41AF] [ADDR:0xECDC0214] [UNABLE_TO_READ] []
在这个地方看到重做日志文件Group 2的REDO02.LOG需要恢复。
暴力一点吧，反正是新库，没啥数据，只要能给我起来就好了。
删掉这个文件，重启打开数据库：
SQL> startup mount
ORACLE 例程已经启动。

Total System Global Area 167772160 bytes
Fixed Size 1247876 bytes
Variable Size 71304572 bytes
Database Buffers 88080384 bytes
Redo Buffers 7139328 bytes
数据库装载完毕。
SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-00313: 无法打开日志组 2 (用于线程 1) 的成员
ORA-00312: 联机日志 2 线程 1:
‘D:\ORACLE\PRODUCT\10.2.0\DB_1\ORADATA\TEST\REDO02.LOG’
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。

SQL> select group#,sequence#,status from v$log;

GROUP# SEQUENCE# STATUS
———- ———- —————-
1 2 INACTIVE
3 1 INACTIVE
2 3 CURRENT
乖乖，是current的log，难怪无法自动恢复打开了。

SQL> alter database drop logfile member ‘D:\ORACLE\PRODUCT\10.2.0\DB_1\ORADATA\T
EST\REDO02.LOG’;
alter database drop logfile member ‘D:\ORACLE\PRODUCT\10.2.0\DB_1\ORADATA\TEST\R
EDO02.LOG’
*
第 1 行出现错误:
ORA-00361: 无法删除最后一个日志成员
D:\ORACLE\PRODUCT\10.2.0\DB_1\ORADATA\TEST\REDO02.LOG (组 2)

靠，无法删除，不想rename log，把刚刚删除的REDO02.LOG恢复回去。

SQL> alter database recover;

数据库已更改。

SQL> alter database open;

数据库已更改。

SQL> shutdown immediate;
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup
ORACLE 例程已经启动。

Total System Global Area 167772160 bytes
Fixed Size 1247876 bytes
Variable Size 71304572 bytes
Database Buffers 88080384 bytes
Redo Buffers 7139328 bytes
数据库装载完毕。
数据库已经打开。
SQL>
ok，可以启动打开就达到我的目的了。
上述方法只能适用于本机的测试环境或者不重要的测试环境，在对丢失数据没有任何担忧的情况，千万不要对生产库这么操作。
-The End-