周末晚上接到电话，公司有一台817的数据库出问题了。软件公司那边搞不定了。让去看下。。(哎。。下班了还得跑过去。。我的周末啊~~~~)
这台服务器我们这边一直都不知道它的存在。一直都是软件公司那边维护的。我们一直都不知道上面还有个ORACLE在跑。。晕。。。

到现场看下情况。服务器用的2000SRV,数据库817。非归档。不能mount。
问应用人员，他们说这几个月来他们系统总是出问题。每次一出问题都直接重启系统。
我倒。。。这也太。。。


看下alert日志：
****************************
starting up 1 shared server(s) ...
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Fri Aug 03 16:39:45 2007
alter database mount exclusive
Fri Aug 03 16:39:48 2007
ORA-214 signalled during: alter database mount exclusive...
Dump file d:\oracle\admin\oraclect\bdump\oraclectALRT.LOG
****************************

怀疑是控制文件出问题。。找到alert中关于控制文件的记录：
control_files = d:\oracle\oradata\oraclect\control01.ctl, d:\oracle\oradata\oraclect\control02.ctl, d:\oracle\oradata\oraclect\control03.ctl

三个控制文件。看下三个控制文件的修改时间发现
control01.ctl,control02.ctl这两个控制文件的最后修改时间是一致的。control03.ctl的最后修改时间比前两个控制文件要早。

决定使用control03.ctl复制得到control01.ctl，control02.ctl看能不能把数据库启动。

复制后数据库可以mount，但不能打开。错误信息是乱码。。。

本来这里看下alert日志就可以定位是控制文件出错了。。可我第一次碰到灾难恢复，经验不足。。而是做了数据库的关闭，再启动。。绕了一大圈。。。


看alert日志错误：
****************************
alter database mount exclusive
Fri Aug 03 17:35:27 2007
ORA-214 signalled during: alter database mount exclusive...
Fri Aug 03 17:47:54 2007
/* OracleOEM */ ALTER DATABASE MOUNT
Fri Aug 03 17:47:57 2007
ORA-214 signalled during: /* OracleOEM */ ALTER DATABASE MOUNT...
Fri Aug 03 17:52:22 2007
/* OracleOEM */ ALTER DATABASE MOUNT
Fri Aug 03 17:52:25 2007
ORA-214 signalled during: /* OracleOEM */ ALTER DATABASE MOUNT...
****************************
关闭库，重启动windows服务。。数据库随服务启动而启动。。。
sys用户不能登到数据库 。。。
****************************
以SYS登陆数据库：
conn / as sysdba

ora-01092 oracle instance termnated.disconnection forced.
****************************
这时的alert日志错误：

****************************
Corrupt block relative dba: 0x00000019 (file 0, block 25)
Fractured block found during controlfile block read
Data in bad block -
type: 21 format: 2 rdba: 0x00000019
last change scn: 0xffff.00006e15 seq: 0x1 flg: 0x04
consistency value in tail: 0x6d981501
check value in block header: 0x958a, computed block checksum: 0x38d
spare1: 0x0, spare2: 0x0, spare3: 0x0
***
DBW0: terminating instance due to error 227
Fri Aug 03 21:08:55 2007
ORA-449 signalled during: alter database open...
Fri Aug 03 21:08:55 2007
Instance terminated by DBW0, pid = 1168
Dump file d:\oracle\admin\oraclect\bdump\oraclectALRT.LOG
****************************

晕。没有维护过windows下的ORACLE，注册表项不太清楚。。维护现场还不能上网。。郁闷啊~~~
在外面总算找到一个能上网的网段。在网上查一下“windows 启动服务不启动数据库”找到如下方法，在此记录一下：
****************************
win2k环境下设置oracle，服务启动，但数据库不要打开。
1.修改注册表项，HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME\下设置。
    ORA_SID_AUTOSTART = true，服务启动，数据库随服务启动而打开；
    ORA_SID_AUTOSTART = false，服务启动时不打开数据库，仅仅启动windows服务。

2.使用oradim修改windows服务
   
    -EDIT -SID sid [ -STARTMODE auto|manual ] 这里指定的是windows服务的启动是自动，还是手动。
    设置成a，则注册表ORA_SID_AUTOSTART = true，
    设置成m时，注册表的ORA_SID_AUTOSTART = false。
    这里设置的startmode与注册表中设置true与false是一样的效果。
****************************
完成后启动oracle服务。以SYS用户登陆数据库，启动。

sqlplus "/as sysdba"
startup nomount

alter database mount;

alter database open;
这时报错。错误乱码

alter session set nls_lang=american;
再做alter database open;

报错信息提示控制文件出错。。我这里是维护完成后总结。那个错误信息没有记录。。

做controlfile 的backup
SQL> alter database backup controlfile to trace;

Database altered.

查看trace文件：
这里这个trace文件没有copy过来。。现在又连不上那台机器。没办法显示出来了。
trace文件里报的都是错。。关于数据文件，日志文件的记录全都没有了。。



到此，彻底定位是控制文件出错了。准备重建控制文件。停掉数据库后备份一下现有的所有数据文件，日志文件。

这个库以前是买软件的时候软件公司给建的。看了下oradata\ 目录下的文件情况，晕。。。发现日志文件只有1M。。奶奶的。。虽然这个系统用的人不是很多，也就几十个，但日志文件只这么一点也太。。。。

sqlplus "/ as sysdba"
statrtup nomout;

create controlfile reuse database oraclect noresetlogs noarchivelog
maxlogfiles 32
maxlogmembers 3
maxdatafiles 100
maxinstances 8
maxloghistory 800
logfile
group 1 'd:\oracle\oradata\oraclect\redo01.log' size 1m,
group 2 'd:\oracle\oradata\oraclect\redo02.log' size 1m,
group 3 'd:\oracle\oradata\oraclect\redo03.log' size 1m
datafile
'd:\oracle\oradata\oraclect\system01.dbf',
'd:\oracle\oradata\oraclect\tools01.dbf',
'd:\oracle\oradata\oraclect\dr01.dbf',
'd:\oracle\oradata\oraclect\indx01.dbf',
'd:\oracle\oradata\oraclect\rbs01.dbf',
'd:\oracle\oradata\oraclect\tbs_att.ora',
'd:\oracle\oradata\oraclect\users01.dbf'
character set ZHS16GBK;

NORESETLOGS创建控制文件报错：
*
ERROR 位于第 1 行:
ORA-01503: CREATE CONTROLFILE failed
ORA-01192: must have at least one enabled thread

倒。~~~网上查也没什么建设性意见。。
决定备份三个日志文件后以resetlogs方式重建控制文件：




====================================================================
ORACLE 例程已经关闭。
SQL> startup nomount
ORACLE 例程已经启动。

Total System Global Area 160401436 bytes
Fixed Size                    75804 bytes
Variable Size              60256256 bytes
Database Buffers           99991552 bytes
Redo Buffers                  77824 bytes
SQL> create controlfile reuse database oraclect resetlogs noarchivelog
2 maxlogfiles 32
3 maxlogmembers 3
4 maxdatafiles 100
5 maxinstances 8
6 maxloghistory 800
7 logfile
8 group 1 'd:\oracle\oradata\oraclect\redo03.log' size 1m,
9 group 2 'd:\oracle\oradata\oraclect\redo02.log' size 1m,
10 group 3 'd:\oracle\oradata\oraclect\redo01.log' size 1m
11 datafile
12 'd:\oracle\oradata\oraclect\system01.dbf',
13 'd:\oracle\oradata\oraclect\tools01.dbf',
14 'd:\oracle\oradata\oraclect\dr01.dbf',
15 'd:\oracle\oradata\oraclect\indx01.dbf',
16 'd:\oracle\oradata\oraclect\rbs01.dbf',
17 'd:\oracle\oradata\oraclect\tbs_att.ora',
18 'd:\oracle\oradata\oraclect\users01.dbf'
19 character set ZHS16GBK
20 /

控制文件已创建
SQL> alter database open;
alter database open
*
ERROR 位于第 1 行:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open


SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR 位于第 1 行:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'D:\ORACLE\ORADATA\ORACLECT\SYSTEM01.DBF'


SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done

SQL> recover database using backup controlfile until cancel;
ORA-00279: change 17948482 generated at 08/03/2007 16:08:45 needed for thread 1
ORA-00289: suggestion : D:\ORACLE\ORA81\RDBMS\ARC07749.001
ORA-00280: change 17948482 for thread 1 is in sequence #7749


Specify log: {=suggested | filename | AUTO | CANCEL}
'd:\oracle\oradata\redo02.log'
ORA-00310: archived log contains sequence 7748; sequence 7749 required
ORA-00334: archived log: 'D:\ORACLE\ORADATA\REDO02.LOG'


ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'D:\ORACLE\ORADATA\ORACLECT\SYSTEM01.DBF'


SQL> recover database using backup controlfile until cancel;
ORA-00279: change 17948482 generated at 08/03/2007 16:08:45 needed for thread 1
ORA-00289: suggestion : D:\ORACLE\ORA81\RDBMS\ARC07749.001
ORA-00280: change 17948482 for thread 1 is in sequence #7749


Specify log: {=suggested | filename | AUTO | CANCEL}
'd:\oracle\oradata\redo03.log'
ORA-00310: archived log contains sequence 7747; sequence 7749 required
ORA-00334: archived log: 'D:\ORACLE\ORADATA\REDO03.LOG'


ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'D:\ORACLE\ORADATA\ORACLECT\SYSTEM01.DBF'


SQL> recover database using backup controlfile until cancel;
ORA-00279: change 17948482 generated at 08/03/2007 16:08:45 needed for thread 1
ORA-00289: suggestion : D:\ORACLE\ORA81\RDBMS\ARC07749.001
ORA-00280: change 17948482 for thread 1 is in sequence #7749


Specify log: {=suggested | filename | AUTO | CANCEL}
'd:\oracle\oradata\redo01.log'
ORA-00310: archived log contains sequence 7746; sequence 7749 required
ORA-00334: archived log: 'D:\ORACLE\ORADATA\REDO01.LOG'


ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'D:\ORACLE\ORADATA\ORACLECT\SYSTEM01.DBF'


SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'D:\ORACLE\ORADATA\ORACLECT\SYSTEM01.DBF'


郁闷了。~~~使用备份出来的日志文件恢复不成功。。

总是提示sequence 7749，我这只有这三个日志文件，最大sequence#就是7748,没有7749这个sequence#，而且不是归档模式。
晕。。到哪去找去。。。

没有办法，最后决定强制打开数据库。把数据导出来先。
停掉数据库。在参数文件中加入
_allow_resetlogs_corruption= TRUE

启动数据库。。这次能打开数据库了。。
抓紧时间导出数据数据。。还好，exp过程中没有出现错误。
在网上看到一位兄弟，比我的还厉害。。按owner导出不成功。。。只能一个一个表的导。。。

数据导出来就成功一大半了。。

最后再创建一个库。把用户数据导进去完工。



总结一下：
这次问题还不是很严重。只是控制文件和日志文件损坏。。数据文件都没有问题。重建控制文件。加上隐含参数强制打开数据库后把用户数据导出来。再导入新库。

在碰到问题时关键不能急。多关注一下alert日志。有很多问题都可以在alert里面找到。。比如数据库字符集，日志文件组对应的日志文件等等。。有什 么问题多google一下。。刚开始的时候我就犯了急进主义。。。一定要稳住。。错误已经发生。现在最主要的是如何挽救数据。


第一次碰到灾难恢复。。没有经验。。上面的操作是和网上朋友一块讨论中完成的。
在此多谢给予我支持的“小熊”。
谢谢~~