ORA-1122 signalled during: alter database open 错误解决

本文详细描述了如何解决数据库因磁盘坏块导致无法启动的问题,特别是针对非归档模式下的数据库,通过备份和删除特定表空间的方式成功恢复数据库运行。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

帮忙解决一个数据库无法启动的问题,数据库处于非归档模式,没有物理备份和逻辑备份。由于磁盘坏块导致数据库无法正常启动。


得知这种情况,先做了最坏的打算,由于不知道磁盘的问题会影响哪些数据文件,很可能数据库根本无法启动。

登陆数据库服务器后,首先检查了一下alert文件,检查最后出现的错误信息:

Fri Feb 15 15:22:40 2008
ORACLE V9.2.0.1.0 - Production vsnsta=0
vsnsql=12 vsnxtr=3
Windows 2000 Version 5.0 Service Pack 4, CPU type 586
Fri Feb 15 15:22:40 2008
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
SCN scheme 2
Using log_archive_dest parameter default value
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 9.2.0.1.0.
System parameters with non-default values:
processes = 150
timed_statistics = TRUE
shared_pool_size = 134217728
sga_max_size = 420551900
large_pool_size = 8388608
java_pool_size = 33554432
control_files = D:oracleoradataserverCONTROL01.CTL, D:oracleoradataserverCONTROL02.CTL, D:oracleoradataserverCONTROL03.CTL
db_block_size = 8192
db_cache_size = 134217728
compatible = 9.2.0.0.0
db_file_multiblock_read_count= 32
fast_start_mttr_target = 300
undo_management = AUTO
undo_tablespace = UNDOTBS1
undo_retention = 10800
remote_login_passwordfile= EXCLUSIVE
db_domain = 
instance_name = server
dispatchers = (PROTOCOL=TCP) (SERVICE=serverXDB)
job_queue_processes = 10
hash_join_enabled = TRUE
hash_area_size = 1048576
background_dump_dest = D:oracleadminserverbdump
user_dump_dest = D:oracleadminserverudump
core_dump_dest = D:oracleadminservercdump
sort_area_size = 1048576
db_name = server
open_cursors = 300
star_transformation_enabled= TRUE
query_rewrite_enabled = TRUE
pga_aggregate_target = 33554432
aq_tm_processes = 1
PMON started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
SMON started with pid=6
RECO started with pid=7
CJQ0 started with pid=8
QMN0 started with pid=9
Fri Feb 15 15:22:54 2008
starting up 1 shared server(s) ...
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Fri Feb 15 15:23:04 2008
alter database mount exclusive 
Fri Feb 15 15:23:10 2008
Successful mount of redo thread 1, with mount id 4154651352.
Fri Feb 15 15:23:10 2008
Database mounted in Exclusive Mode.
Completed: alter database mount exclusive
Fri Feb 15 15:23:10 2008
alter database open
ORA-1110 signalled during: alter database open...
Dump file d:oracleadminserverbdumpalert_server.log

查询OracleERROR参考手册,发现ORA-1110错误描述为:

ORA-01110 data file string: 'string'
Cause: This message reports the file name involved with other messages.
Action: See the associated messages for a description of the problem.

这个错误只是整个错误信息中的一部分,仅凭这个错误无法确定具体的问题。

看来数据库已经处于MOUNT状态,尝试打开数据库:

SQL> alter database open;
alter database open
*
ERROR 
位于第 1 :
ORA-01122: 
数据库文件 3 验证失败

ORA-01110: 
数据文件 3: 'D:ORACLEORADATASERVERCWMLITE01.DBF'
ORA-01251: 
文件号3的未知文件标题版本读取

很不错,问题既不是出在SYSTEM系统表空间中,也不是出现在用户表空间中,而是出自相对“无害”的CWMLITE表空间。可以确定,当前系统是不需要使用这个表空间的。

不过,现在不能确定,是否其他数据文件还存在问题,在动手解决问题之前,首先对现有环境进行备份。

数据库处于MOUNT状态,可以查询V$DATAFILE视图和V$LOGFILE视图,手工备份所有的数据文件和日志文件,并根据SHOW PARAMETER CONTROL的结果备份当前的控制文件。

执行完备份操作,尝试删除数据文件的方式来打开数据库:

SQL> alter database datafile 'D:ORACLEORADATASERVERCWMLITE01.DBF' offline drop;

数据库已更改。

SQL> alter database open;

数据库已更改。

由于数据库处于非归档模式,只能采用OFFLINE DROP的方式,幸运的是,出现问题的只有一个数据文件CWMLITE01.DBF,删除后,数据库顺利打开。

数据库打开后删除OLAPSYS用户和CWMLITE表空间,然后确实要恢复到原来的情况,可以考虑使用dbca来添加OLAPSYS用户。

数据库打开后,对业务用户进行逻辑备份,避免磁盘的坏块造成进一步的损失。

整个恢复过程并没有什么技术含量,而且“运气”很好,不过并不是所有出现问题的数据库都会有如此好的运气,只有有效的备份才是最保险的。

<think>好的,我现在需要处理用户关于在Oracle数据库中执行ALTER DATABASE MOUNT时遇到ORA-00659错误的问题。首先,我需要回忆一下ORA-00659错误的常见原因。这个错误通常与控制文件相关,比如控制文件无法访问、损坏或者配置不正确。 用户之前已经询问过在创建SPFILE后无法挂载数据库的问题,现在又遇到了具体的错误代码,所以我应该结合之前的回答,进一步细化解决方案。首先,我需要确认用户是否按照之前的步骤检查过警报日志,因为警报日志中的详细信息是诊断问题的关键。 接下来,用户提到错误发生在执行ALTER DATABASE MOUNT时,这可能意味着实例已经启动到NOMOUNT状态,但挂载数据库时失败。这时候控制文件的问题可能性最大。我需要考虑控制文件的路径是否正确,权限是否足够,文件是否存在,或者是否损坏。 另外,用户之前执行了CREATE SPFILE FROM MEMORY,可能导致参数文件中的控制文件路径不正确,或者内存中的参数与控制文件的实际位置不匹配。因此,可能需要检查SPFILE中的control_files参数是否正确,是否指向了有效的控制文件。 还可能存在的情况是控制文件本身损坏,或者存储控制文件的磁盘空间不足,或者权限问题导致Oracle进程无法访问这些文件。此外,如果控制文件是镜像的,可能部分副本损坏,而Oracle尝试访问这些损坏的副本。 我需要建议用户检查警报日志,确认具体的错误信息,然后根据日志中的提示进行相应的处理。比如,如果日志显示无法找到控制文件,则需要验证control_files参数的值,并确保文件存在。如果文件存在但权限不对,需要调整权限。如果是控制文件损坏,可能需要从备份恢复,或者重建控制文件。 此外,用户可能需要使用PFILE启动实例,绕过SPFILE,以排除参数文件的问题。如果通过PFILE能够成功挂载数据库,那么问题可能出在SPFILE的参数配置上,需要重新生成SPFILE。 如果控制文件全部丢失且没有备份,用户可能需要通过CREATE CONTROLFILE命令重建控制文件,这需要用户了解数据库的结构,如数据文件、日志文件的位置等信息,因此在操作前需要确保这些信息是可用的。 最后,需要提醒用户在进行任何修复操作前备份现有文件,避免数据丢失,并建议在操作困难时联系Oracle支持。</think>以下是针对 **ORA-00659** 错误(在执行 `ALTER DATABASE MOUNT` 时触发)的逐步解决方案: --- ### **1. 错误背景分析** - **ORA-00659** 表示数据库无法找到或访问控制文件(Control File)。常见原因包括: - 控制文件路径配置错误(`control_files` 参数不正确)。 - 控制文件被删除、损坏或权限不足。 - 存储控制文件的磁盘空间不足或I/O故障。 --- ### **2. 检查警报日志 (Alert Log)** - **步骤**: 1. 定位警报日志路径: ```sql SELECT value FROM v$diag_info WHERE name = 'Diag Trace'; ``` 文件名为 `alert_<SID>.log`。 2. 搜索 `ORA-00659` 相关条目,确认具体错误描述(例如找不到文件、权限拒绝等)。 --- ### **3. 验证控制文件路径** - **关键操作**: 1. 检查当前参数 `control_files` 配置: ```sql SHOW PARAMETER control_files; ``` 2. 确认操作系统路径是否存在且权限正确: ```bash # 示例:检查控制文件是否存在及权限 ls -l /u01/app/oracle/oradata/ORCL/control01.ctl ``` 3. **权限修复**(如有必要): ```bash chown oracle:dba /path/to/controlfile.ctl chmod 660 /path/to/controlfile.ctl ``` --- ### **4. 尝试通过PFILE启动** - **适用场景**:SPFILE参数错误导致路径配置异常。 - **步骤**: 1. 创建PFILE(若已有SPFILE): ```sql CREATE PFILE='/tmp/init_temp.ora' FROM SPFILE; ``` 2. 手动编辑PFILE,修正 `control_files` 路径为实际有效路径。 3. 使用PFILE启动到 `NOMOUNT` 状态: ```sql STARTUP NOMOUNT PFILE='/tmp/init_temp.ora'; ``` 4. 尝试挂载数据库: ```sql ALTER DATABASE MOUNT; ``` --- ### **5. 恢复控制文件** - **场景**:控制文件丢失或损坏。 - **情况1:存在有效备份** 从RMAN备份恢复控制文件: ```sql RMAN> RESTORE CONTROLFILE FROM '/backup/controlfile.bkp'; RMAN> ALTER DATABASE MOUNT; ``` - **情况2:无备份但数据库未崩溃** 通过其他副本恢复(若配置了多路复用): ```bash cp /path/to/controlfile_copy.ctl /path/to/missing_controlfile.ctl ``` - **情况3:无备份且所有控制文件丢失** 必须重建控制文件(需提前记录数据库结构): ```sql CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 8 MAXLOGHISTORY 292 LOGFILE GROUP 1 '/u01/app/oracle/oradata/ORCL/redo01.log' SIZE 50M, GROUP 2 '/u01/app/oracle/oradata/ORCL/redo02.log' SIZE 50M DATAFILE '/u01/app/oracle/oradata/ORCL/system01.dbf', '/u01/app/oracle/oradata/ORCL/sysaux01.dbf' CHARACTER SET AL32UTF8; ``` --- ### **6. 检查存储状态** - **可能问题**:磁盘空间不足或硬件故障。 - 检查控制文件所在磁盘空间: ```bash df -h /path/to/controlfile_directory ``` - 检查I/O错误日志(操作系统级): ```bash dmesg | grep -i error ``` --- ### **7. 重建SPFILE(若参数修正有效)** - **步骤**: 1. 若通过PFILE成功挂载数据库,重新生成SPFILE: ```sql CREATE SPFILE FROM PFILE='/tmp/init_temp.ora'; ``` 2. 重启数据库验证: ```sql SHUTDOWN IMMEDIATE; STARTUP; ``` --- ### **注意事项** - **备份优先**:操作前备份所有控制文件及参数文件。 - **多路复用控制文件**:建议至少配置2个控制文件副本,避免单点故障。 - **日志分析**:警报日志中的时间戳和错误链是诊断关键。 若仍无法解决,请提供警报日志中的完整错误上下文或联系Oracle支持。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值