【Oracle】解决ORA-01034: ORACLE not available问题

这个…不知道是镜像问题还是配置上有问题,Docker版的Oracle 11g在上次部署完之后已经出现了多次无法访问的情况(就是 registry.cn-hangzhou.aliyuncs.com/helowin/oracle_11g这个镜像),最后一次修复已经将连接数从150(默认)提升到8000,这次无法访问肯定不是连接数已满的问题。

遇事不要慌,先通过docker exec进入容器内部连接一下oracle数据库,看到的是

ORA-01034: ORACLE not available

这…难道是之前为了修改连接数直接关机导致日志无法归档么?

上网查了些资料,最终通过如下步骤解决的:

  1. 先用sqlplus使用sysdba权限访问连接数据库
[oracle@e156e1b777f5 -]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Sun Nov 14 13:36:28 2021
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to an idle instance.
  1. 查询v$log看看能否正常查询到日志信息
SQL> select * from v$log;
select × from v$log
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0
  1. 在发现报ORA-01034: ORACLE not available错误后,我们再试试操作resetlogs
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: O
Session ID: 0 Serial number: 0

要注意,这里使用resetlogs方式打开数据库对oracle进行恢复是存在风险的,如果日志文件没有损坏的情况下可以直接恢复就可以了,这次的情况比较麻烦,所以才想用这种方式进行。

  1. 既然所有操作都报错了,就先关闭实例
SQL> shutdown immediate;
ORA-01034: ORACLE not available ORA-27101: shared memory realm does not exist
Linux-x86 64 Error: 2: No such file or directory
  1. 重新挂载启动
SQL> startup mount;
ORACLE instance started.
Total System Global Area 1603411968 bytes
Fixed Size                  2213776 bytes
Variable Size            1342179440 bytes
Database Buffers          251658240 bytes
Redo Buffers                7360512 bytes
Database mounted.
  1. 重启之后再尝试使用resetlogs打开数据库
SQL> alter database open resetlogs;
alter database open resetlogs
ERROR at line 1:
ORA-01139: RESETLOGS option only valid after an incomplete database recovery

这里又是一个ERROR,先不要管它继续下一步操作

  1. 这时我们又再查一次v$log

image.png
如上图所示,通过v$log得知日志只记录到昨天(11月13日),还好不是生产环境的一天的时间还能够接受。

  1. 通过recover database命令进行数据恢复
SQL> recover database until time '2021-11-13 00:00:00'
ORA-10879: error signaled in parallel recovery slave
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: '/home/oracle/app/oracle/oradata/helowin/systeml.dbf'

嗯…没有头绪还是先“重启”吧

SOL> shutdown;
ORA-01109: database not open


Database dismounted.
ORACLE instance shut down.
SOL> startup
ORACLE instance started.

Total System Global Area 1603411968 bytes
Fixed Size                  2213776 bytes
Variable Size            1342179440 bytes
Database Buffers          251658240 bytes
Redo Buffers                7360512 bytes
Database mounted.
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

这次连启动也报错,真是“一波未平一波又起”。

  1. sqlplus再查询一次l日志

image.png
既然这样就手动redo一次吧。

  1. 执行recover database

image.png
执行完了之后再open resetlogs就可以了

SQL> alter database open resetlogs;

Database altered.

为了使操作完全生效决定重启了一下oracle

SQL> shutdown immedate;
SP2-0717: illegal SHUTDOWN option
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SOL> startup;
ORACLE instance started.

Total System Global Area 1603411968 bytes
Fixed Size                  2213776 bytes
Variable Size            1342179440 bytes
Database Buffers          251658240 bytes
Redo Buffers                7360512 bytes
Database mounted.
Database opened.

这样就搞定了。

### ORA-01034 错误分析与解决方案 ORA-01034Oracle 数据库中的常见错误之一,表示数据库实例不可用。以下是该问题的具体原因以及修复方法。 #### 一、错误原因 ORA-01034 的主要原因是 Oracle 实例未启动或未能正常运行。具体可能由以下几个方面引起: 1. **Oracle 服务未启动** 如果 Oracle 数据库服务未被正确初始化,则会触发此错误[^2]。 2. **环境变量配置不正确** 当 `ORACLE_HOME` 或 `TNS_ADMIN` 环境变量设置有误时,可能导致 SQL*Plus 无法找到正确的数据库路径[^1]。 3. **监听器状态异常** 即使数据库已启动,如果监听器未正确注册到数据库实例上,也可能引发此类错误。 4. **硬件资源不足** 若服务器内存或其他系统资源耗尽,可能会阻止 Oracle 正常启动并抛出 ORA-01034 错误[^3]。 --- #### 二、解决步骤 ##### 1. 验证 Oracle 服务的状态 检查目标主机上的 Oracle 服务是否正在运行。可以通过以下命令验证: ```bash ps -ef | grep ora_ ``` 如果没有发现任何进程,则说明 Oracle 服务尚未启动。此时可以尝试手动启动数据库实例: ```sql startup nomount; alter database mount; alter database open; ``` ##### 2. 检查监听器状态 确认监听器是否处于活动状态,并成功注册到了对应的数据库实例上。执行如下操作来查看监听器详情: ```bash lsnrctl status ``` 如果显示 “UNKNOWN INSTANCE”,则表明监听器未完成正常的注册过程。重新加载监听器配置文件后再次测试: ```bash lsnrctl reload ``` ##### 3. 审核环境变量设定 确保操作系统层面设置了恰当的环境参数,特别是 `ORACLE_SID`, `ORACLE_HOME` 和其他必要的变量。例如,在 Linux 平台下可编辑 `.bash_profile` 文件加入这些定义: ```bash export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1 export PATH=$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib export TNS_ADMIN=$ORACLE_HOME/network/admin ``` 随后刷新 shell session 让更改生效: ```bash source ~/.bash_profile ``` ##### 4. 排除硬件瓶颈因素 利用工具监控 CPU 使用率、磁盘 I/O 性能指标等,判断是否存在物理层面上阻碍 Oracle 启动的情况。必要情况下增加更多 RAM 或优化存储子系统的布局结构以缓解压力。 --- #### 三、预防措施 为了避免未来发生类似的状况,建议采取以下策略: - 定期备份重要数据以防丢失; - 设置自动化的健康检测脚本定期扫描潜在风险点; - 对于生产环境中使用的机器保持良好的维护习惯,及时更新补丁版本; --- ### 示例代码片段 下面提供一段用于诊断和恢复的 PL/SQL 脚本作为参考: ```plsql BEGIN IF (dbms_utility.get_parameter_value('instance_status') != 'OPEN') THEN EXECUTE IMMEDIATE 'ALTER DATABASE OPEN'; END IF; EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(SQLERRM); END; / ``` 上述代码逻辑简单明了:先查询当前实例状态,如果不是开放模式就强制打开它。同时捕获可能出现的各种例外情况以便进一步处理。 ---
评论 11
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Kida 的技术小屋

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值