博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
ORA-01033: ORACLE initialization or shutdown in progress
阅读量:7026 次
发布时间:2019-06-28

本文共 2282 字,大约阅读时间需要 7 分钟。

这阵子折腾ORACLE数据库,今天还真给我“折腾”出问题来了,清理磁盘里面文件时,把D:\KERRY.MDF这个数据库文件删除了(呵呵,事后才想 起来的,当时以为是SQL SERVER 05 数据库实验时创建的),结果今天启动ORACLE服务后,PL/SQL连接过去时报错:ORA-01033: ORACLE initialization or shutdown in progress。查看D:\oracle\product\10.2.0\admin\orcl\bdump下告警日志,发现了下面一些错误,仅仅贴出 部分日志信息(太多了,不好贴)
OSD-04002: 无法打开文件O/S-Error: (OS 2) 系统找不到指定的文件。*** 2011-05-25 23:44:51.765ORA-01157: cannot identify/lock data file 6 - see DBWR trace fileORA-01110: data file 6: 'D:\KERRY.MDF'ORA-27041: unable to open fileOSD-04002: 无法打开文件O/S-Error: (OS 2) 系统找不到指定的文件。ORA-01157: cannot identify/lock data file 7 - see DBWR trace fileORA-01110: data file 7: 'D:\KERRY1.DBF'ORA-27041: unable to open file

百度了下,在这篇帖子里面有提供解决方法,有兴趣的可以看看。

首先用SYSDBA账号登陆数据库,当然你可以用SQL*PLUS,也可以用PL/SQL工具,我首先在命令窗口尝试输入如下命令:

SQL> SHUTDOWN NORMAL;SHUTDOWN NORMALORA-00900: 无效 SQL 语句SQL> STARTUP MOUNT;STARTUP MOUNTORA-00900: 无效 SQL 语句SQL> ALTER DATABASE OPEN;ALTER DATABASE OPENORA-01157: 无法标识/锁定数据文件 6 - 请参阅 DBWR 跟踪文件ORA-01110: 数据文件 6: 'D:\KERRY.MDF'
到这里我才模糊的记得好像是清理磁盘时,删除了这个数据文件。接下来只能修改数据库,把它离线处理
SQL> ALTER DATABASE DATAFILE 6 OFFLINE DROP;Database altered

关于OFFLINE 与 OFFLINE DROP的区别,我查了下资料,区别大体如下:

1、对一个datafile执行offline或offline drop本质上是一回事,但对一个datafile执行offline只能在归档模式下;而对一个datafile执行offline drop则既可以在归档模式也可以在非归档模式下;

 

2、对一个datafile无论是执行offline还是offline drop,都是只改写了control文件,不会更新file$和ts$,这就是为什么可以在mount状态下对某个datafile执行offline/offline drop的本质原因;

 

3、只有当对datafile所在的表空间执行offline normal的时候,才会既改写control文件,又更新ts$和seg$,oracle这里会把ts$的online$字段的值由1改为2,但依然不会去更新file$;

 

4、只有当对datafile所在的表空间执行drop操作的时候,oracle才会去更新ts$和file$,oracle这里会把ts$的online$字段的值由1改为3,会把file$的status$字段由2改为1;

注意,无论是file$file#还是ts$ts#,它们都是连续的!并且oracle会重用file$的file#,但是不会重用ts$里的ts#,这本质上是因为ts$里会记录tablespace的名字,而file$里并没有记录datafile的名字,所以file$里的记录可以重用而ts$则不能

 

5、只要你对一个datafile执行了offline或者offline drop操作,则oracle在open的时候就不会去存储上(无论是文件系统、裸设备还是ASM)校验这个文件了,所以即使这个文件已经在存储上被删掉了,此时库依然可以open。

 

6、无论你是在归档模式还是在非归档模式,且无论你对某 个datafile是执行了offline还是offline drop操作,只要归档日志还在(对应于归档模式)或者相关的online redo log没有被logfile switch覆盖(对应于非归档模式),则这个datafile始终是可以online的,里面的数据都还在。当然,即使归档日志不在了,online redo log被logfile switch覆盖了,这个datafile也是可以online的,只是里面的数据可能会不一致。

接下来打开数据库,结果还有一个数据文件被我干掉了(一点印象都没啊),依葫芦画瓢处理掉它,如下所示

2011052523322870.gif

SQL> ALTER DATABASE DATAFILE 7 OFFLINE DROP;Database alteredSQL> ALTER DATABASE OPEN;Database altered
OK,到此问题被解决了。 

转载地址:http://qcmxl.baihongyu.com/

你可能感兴趣的文章
安装pytorch成功但cuda不可用
查看>>
unity__DrawCall的理解
查看>>
springboot架构下运用shiro后在configuration,通过@Value获取不到值,总是为null
查看>>
SQLServer 数据库镜像+复制切换方案
查看>>
Postman初探
查看>>
仿淘宝头像上传功能(一)——前端篇。
查看>>
Eclipse通过集成svn实现版本控制
查看>>
OS开发过程中常用开源库
查看>>
关于在多个UItextield切换焦点
查看>>
STL: HDU1004Let the Balloon Rise
查看>>
hdu 2768
查看>>
git记住用户名密码
查看>>
ElasticSearch(2)-安装ElasticSearch
查看>>
从mysql数据表中随机取出一条记录
查看>>
ORACLE 锁表处理,解锁释放session
查看>>
二.hadoop环境搭建
查看>>
深海机器人问题
查看>>
ios开发之 -- invalid nib registered for identifier
查看>>
MySQL 通过semi join 优化子查询
查看>>
socket编程-服务器端
查看>>