这些天太忙了，做的事情好琐碎，不过磨练毅力啊。

由于在windows下启动数据库要先启动数据库服务的历程，然后启动数据库

cmd>net start oracleserivetest

启动数据库服务test历程

Cmd>sqlplus sys/oracle as sysdba

Startup

一直以为linux也和windows下启动数据库一样，需要启动服务和数据库，今天看eygle在循序渐进书中说到linux下不存在数据库服务这一说话，直接用spfile启动数据库就可以了。也难怪以前在手工创建数据库中提到了oradim，而且此工具只在windows下能使用，是一个注册服务的工具，在linux等平台下无法使用。

Oradim –new –sid test

实例已经创建

其实windows下的提示帮助有点迷惑性，以为数据库实例已经创建了，其实此时只是oracle数据库在os上所对应的服务已经创建，实例的创建和启动只是nomount状态，由sga和后台进程组成，所以好书值得精读细读，有时候前辈们提到的一两点都值得好好推敲。

数据库在nomount状态时，此时丢失控制文件。在rman中如果开启控制文件的自动备份功能，可以直接restore控制文件。

Rman>restore controlfile to ‘d:control01.ctl’ from autobackup

同样的可以从控制文件的自动备份集中提取spfile的信息

Rman>restore spfile to ‘d:spfiletest.ora’ from autobackup

如果此时缺少控制文件自动备份集，可以尝试手工创建控制文件的脚本

Create controlfile reuse databae “TEST” resetlogs archivelog

Maxlogfiles 10

Maxlogmembers 3

Maxdatafiles 100

Maxinstances 1

Logfile

‘d:oracleproduct10.2.0oradatatestredo01.log’,

‘d:oracleproduct10.2.0oradatatestredo02.log’,

‘d:oracleproduct10.2.0oradatatestredo03.log’

Datafile

‘d:oracleproduct10.2.0oradatatestsystem01.dbf’,

‘d:oracleproduct10.2.0oradatatestsysaux01.dbf’,

‘d:oracleproduct10.2.0oradatatestuntobs01.dbf’

character set ZHS16GBK

;

基本就是上面的脚本规范，其实和创建数据库的脚本有相同的地方，不过确实也记不住。

如果数据库控制文件丢失，而且也没有备份集，此时可以尝试试着创建控制文件然后利用归档日志和在线重做日志恢复数据库。

Startup nomount

执行创建控制文件的脚本

如果是用resetlogs创建数据库，oracle会认为当前日志文件全部损坏，此次数据库恢复将是一次不完整恢复，介质恢复数据库时必须指定using controlfile backup，一旦resetlogs打开数据库，oracle就会认为当前日志文件已经删除。

Recover database using controlfile backup unitl cancel

通过控制文件执行介质恢复

此时我们是recover database using controlfile backup，

Recover database恢复数据库时：数据文件的scn会以current controlfile为准，利用在线日志的redo entry和archive log来恢复数据文件的block信息到当前控制文件的scn。

Recover database using controlfile backup主要是为了把数据文件block恢复到当前控制文件所记录的scn更靠后的位置，例如用backup controlfile或者createcontrolfile恢复数据文件时可以把数据文件的scn比当前控制文件的scn的更后面一点，此时数据文件就不会受控制文件scn的限制，就局限于你后面的until cancel或者until scn等和archive log ，redo log。

以下情况需使用using controlfile backup

1 使用resetlogs重建控制文件后，noresetlogs不需要此时oracle认为当前日志都已经损坏，恢复数据文件要让其到当前控制文件scn靠后一点

2 使用备份的控制文件恢复数据库

Alter database open restlogs

以resetlogs重建ctl，打开数据库也要resetlogs，此时重做日志开始重新计数。

如果数据库无法nomount了，那么可以去altersid.log下查找数据库启动的具体参数，警告日志会记录具体的参数，然后手工创建一个pfile来启动数据库到nomount

以前nomount状态细节解析提到了spfile需要的最少参数就是db_name。只要指定db_name就可以利用spfile启动数据库。

pfile内容 inittest.ora最少参数：

db_name=test

ramn>startup pfile=’d:oracleproduct10.2.0databaseinittest.ora’ nomount

如果有控制文件自动备份集可以restore然后重新启动数据库

rman>restore spfile to ‘d:oracleproduct10.2..0databasespfiletest.ora’ from autobackup

rman>shutdown immediate

rman>startup;

也可以尝试rman启动默认实例

cmd>Rman target /

rman>startup nomount;

rman>restore spfile to ‘’ from autobackup;

不过这里还是有点疑惑，首先不完全恢复是丢失当前日志文件，resetlogs打开数据库是因为：resetlogs重建控制文件，利用备份的控制文件，不完全恢复三种情况，既然resetlogs方式创建控制文件oracle会认为当前控制日志失效，那也就意味着丢失当前日志文件，恢复将是一次不完整恢复，但是此时当前日志文件确实存在且后面用于同步数据文件，控制文件等，此时就只是指定了一次resetlogs创建控制文件，不应该是不完全恢复。

是否应该是resetlogs创建的控制文件，转储新建的ctl发现ctl中记载的redo log全部都认为未使用，recover database using controlfile backup until cancel，此时控制文件会按照archive log和当前redo log来同步，如果此时redo log缺少才是一次不完整的恢复，如果选择auto，oracle会同步到最后一个archive log，redo log，也可以制定scn或者time来满足此时控制文件和数据文件的scn同步，然后open resetlogs后oracle才会真正丢弃当前的redo log然后redo log开始重新计数，此时恢复由于有当前的redo log，是一次完整的数据库恢复。

eygle提到的了，由于外界服务器等因素导致数据库意外关闭，而且又丢失当前redo log的恢复只能是一次不完整的恢复，意外关闭此时buffer cache并没有写进磁盘，记载事物的当前redo log丢失，只能是不完全恢复，不完全恢复要以resetlog打开数据库，但是resetlogs打开数据库并不是不完全恢复，很有可能只是resetlogs创建ctl或者利用备份的ctl，resetlogs创建ctl，open resetlogs时redo log重新计数，利用备份ctl，此时oracle在恢复阶段也是利用log来恢复，最后同样redo log开始重新计数。