【故障处理】告警日志报“ORA-01565 Unable To open Spfile”

【故障处理】告警日志报“ORA-01565 Unable To open Spfile”

1.1  BLOG文档结构图

 

1.2  故障分析及解决过程

1.2.1  故障环境介绍

 


项目


source db


db 类型


RAC


db version


12.1.0.2.0


db 存储


ASM


OS版本及kernel版本


SuSE Linux Enterprise Server(SLES 11) 64位

1.2.2  故障发生现象及报错信息

客户的12.1.0.2的RAC库告警日志报ORA-01565: Unable To open Spfile的错误,其中一个节点在每天凌晨3点多,另外一个节点在凌晨1点多。

 

1.2.3  故障分析及解决过程

根据MOS How to troubleshoot ORA-01565 being reported in alert log (文档 ID 1950208.1)查询出来是由于$ORACLE_HOME/dbs/init$ORACLE_SID和OCR 中的配置(srvctl config db -d racdb1)查询出来的结果不一致导致的。

解决:将两者配置修改为一致即可。

可以设置trace事件来追踪该问题,生成trace后再关闭该跟踪事件:

alter system set events '1565 trace name errorstack level 10';

alter system set events '1565 trace name context off';

 

另外,在12.1.0.2的RAC中,文件“<DB_HOME>/dbs/init<ORACLE_SID>.ora”不再使用:

The only reference to the incorrect spfile name is in <DB_HOME>/dbs/init<ORACLE_SID>.ora which isn't being used in 12.1.0.2:

$ cat initeaipprd1.ora
SPFILE='+DATA/eaipprd/spfileeaipprd.ora'

 

1.3  MOS

1.3.1  Grid Infrastructure 12.1.0.2 ORA-01565 Unable To open Spfile (文档 ID 1970979.1)

In this Document

Symptoms
Cause
Solution
References

APPLIES TO:

Oracle Database - Enterprise Edition - Version 12.1.0.2 and later
Information in this document applies to any platform.

SYMPTOMS

Newly created database using dbca, seeing the following in database alert.log frequently:

Wed Nov 19 10:00:40 2014 
ORA-01565: Unable to open Spfile +DATA/eaipprd/spfileeaipprd.ora. 
Wed Nov 19 10:00:40 2014 
ORA-01565: Unable to open Spfile +DATA/eaipprd/spfileeaipprd.ora. 
Wed Nov 19 10:00:41 2014

The spfile doesn't exist, the spfile in the OCR for the database is correct:

$ srvctl config database -d eaipprd 
Database unique name: eaipprd 
Database name: eaipprd 
Oracle home: /oracle/oracle/product/12.1.0.2_eaip 
Oracle user: oracle 
Spfile: +DATA/EAIPPRD/PARAMETERFILE/spfile.279.861715841

SQL> show parameter spfile;

NAME TYPE VALUE 
------------------------------------ ----------- ------------------------------ 
spfile string +DATA/EAIPPRD/PARAMETERFILE/spfile.279.861715841

ASMCMD [+DATA/EAIPPRD/PARAMETERFILE] > ls -l 
Type Redund Striped Time Sys Name 
PARAMETERFILE UNPROT COARSE NOV 20 07:00:00 Y spfile.279.861715841

The only reference to the incorrect spfile name is in <DB_HOME>/dbs/init<ORACLE_SID>.ora which isn't being used in 12.1.0.2:

$ cat initeaipprd1.ora 
SPFILE='+DATA/eaipprd/spfileeaipprd.ora'

  

CAUSE

The issue was investigated in multiple bugs: 

BUG 20133332 - FREQUENT ALERT.LOG MSG: ORA-01565: UNABLE TO OPEN SPFILE +DATA/EAIPPRD/SPFILEEAI
BUG 19064439 - ORA-01565: UNABLE TO OPEN SPFILE ON AN IDLE SYSTEM - FOR 1 SECOND 
BUG 20025790 - EM CAUSES ORA-1565 TO BE GENERATED DUE TO DBCA ISSUE

The exact cause wasn't determined.

 

 

SOLUTION

After applied 12.1.0.2 GI PSU2, the issue stopped.

 

1.3.2  How to troubleshoot ORA-01565 being reported in alert log (文档 ID 1950208.1)

 

In this Document

Goal
Solution
References

APPLIES TO:

Oracle Database - Enterprise Edition - Version 12.1.0.2 and later
Information in this document applies to any platform.

GOAL

 Troubleshooting "ORA-01565: Unable to open Spfile"

SOLUTION

When "ORA-01565: Unable to open Spfile" is being reported in the instance alert log, then some process is trying to access the spfile but referring to the incorrect location

 

Database Instance alert log reports the following errors

Wed Nov 19 19:26:44 2014
ORA-01565: Unable to open Spfile +DATA/racdb1/spfileracdb1.ora.
Wed Nov 19 19:26:44 2014
ORA-01565: Unable to open Spfile +DATA/racdb1/spfileracdb1.ora.
Wed Nov 19 19:26:44 2014
ORA-01565: Unable to open Spfile +DATA/racdb1/spfileracdb1.ora.
Wed Nov 19 19:26:44 2014
ORA-01565: Unable to open Spfile +DATA/racdb1/spfileracdb1.ora.
Wed Nov 19 19:26:44 2014
ORA-01565: Unable to open Spfile +DATA/racdb1/spfileracdb1.ora.

 

 

In a situation where the error is not generating any trace files we need to set the following event at the database level

 

alter system set events '1565 trace name errorstack level 10';

 

Once the above event is set we can see messages as follows in the alert log when the issue occurs again

 

From alert log

Mon Dec 01 19:26:44 2014
ORA-01565: Unable to open Spfile +DATA/racdb1/spfileracdb1.ora.
Mon Dec 01 19:26:44 2014
Errors in file /u01/app/oracle/diag/rdbms/racdb1/racdb1/trace/racdb1_ora_3106.trc: <<<<<<<<<<<<<<<Trace files for the event are getting generated
ORA-01565: error in identifying file '+DATA/racdb1/spfileracdb1.ora'
ORA-17503: ksfdopn:2 Failed to open file +DATA/racdb1/spfileracdb1.ora
ORA-15173: entry 'spfileracdb1.ora' does not exist in directory 'racdb1'
Mon Dec 01 19:26:48 2014
Dumping diagnostic data in directory=[cdmp_20141201192648], requested by (instance=1, osid=3106), summary=[abnormal process termination].
Mon Dec 01 19:26:49 2014
ORA-01565: Unable to open Spfile +DATA/racdb1/spfileracdb1.ora.
Mon Dec 01 19:26:49 2014
Errors in file /u01/app/oracle/diag/rdbms/racdb1/racdb1/trace/racdb1_ora_3233.trc:
ORA-01565: error in identifying file '+DATA/racdb1/spfileracdb1.ora'
ORA-17503: ksfdopn:2 Failed to open file +DATA/racdb1/spfileracdb1.ora
ORA-15173: entry 'spfileracdb1.ora' does not exist in directory 'racdb1'

 

After the event has occurred, the tracing can be disabled as follows

 

alter system set events '1565 trace name context off';

 

In the current example the trace file has the following information

 

Trace file output

 

*** 2014-12-01 19:26:44.771
*** SESSION ID:(15.63147) 2014-12-01 19:26:44.771
*** CLIENT ID:() 2014-12-01 19:26:44.771
*** SERVICE NAME:(SYS$USERS) 2014-12-01 19:26:44.771
*** MODULE NAME:(sqlplus@nracdb1 (TNS V1-V3)) 2014-12-01 19:26:44.771
*** CLIENT DRIVER:(SQL*PLUS) 2014-12-01 19:26:44.771
*** ACTION NAME:() 2014-12-01 19:26:44.771
*** CONTAINER ID:(1) 2014-12-01 19:26:44.771

dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=10, mask=0x0)
----- Error Stack Dump -----
ORA-01565: error in identifying file '+DATA/racdb1/spfileracdb1.ora'
ORA-17503: ksfdopn:2 Failed to open file +DATA/racdb1/spfileracdb1.ora
ORA-15173: entry 'spfileracdb1.ora' does not exist in directory 'racdb1'
----- Current SQL Statement for this session (sql_id=37hr89tuy952y) -----
CREATE PFILE='/tmp/RUwOs966FJ' FROM SPFILE='+DATA/racdb1/spfileracdb1.ora'

 

The actual SPFILE location of the database can be checked from the alert log or database configuration

 

From alert log

Thu Oct 30 10:55:26 2014
Starting ORACLE instance (normal) (OS id: 10576)
Thu Oct 30 10:55:26 2014
RECOMMENDATION:
Thu Oct 30 10:55:26 2014
1. For optimal performance, configure system with expected number 
of pages for every supported system pagesize prior to the next 
instance restart operation.
Thu Oct 30 10:55:26 2014
**********************************************************************
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Initial number of CPU is 4
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =101
LICENSE_MAX_USERS = 0
SYS auditing is enabled
NOTE: remote asm mode is local (mode 0x1; from cluster type)
NOTE: Using default ASM root directory ASM
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options.
ORACLE_HOME = /u01/app/oracle/product/12.1.0/db_1
System name: Linux
Node name: lo03dox3
Release: 2.6.32-431.29.2.el6.x86_64
Version: #1 SMP Sun Jul 27 15:55:46 EDT 2014
Machine: x86_64
Using parameter settings in server-side spfile +DATA/spfileracdb1.ora

From the config output

srvctl config database -d racdb1
Database unique name: racdb1
Database name: racdb1
Oracle home: /u01/app/oracle/product/12.1.0/db_1
Oracle user: oracle
Spfile: +DATA/spfileracdb1.ora
Password file: 
Domain: 
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Disk Groups: FRA,DATA
Services: test1, test2
OSDBA group: 
OSOPER group: 
Database instance: racdb1

 

 

From the above it is clear that the actual location of the spfile is "+DATA/spfileracdb1.ora" however the process is trying to access the spfile from "+DATA/racdb1/spfileracdb1.ora"

In such a situation the reference of the spfile needs to be corrected by the process.

REFERENCES

BUG:18334406 - ORA-01565 ERROR ON THE TWO RAC NODES
BUG:9906253 - ORA-01565: UNABLE TO OPEN SPFILE EACH SIX HOURS

 

About Me


...............................................................................................................................

● 本文作者:小麦苗,只专注于数据库的技术,更注重技术的运用

● 本文在itpub(http://blog.itpub.net/26736162)、博客园(http://www.cnblogs.com/lhrbest)和个人微信公众号(xiaomaimiaolhr)上有同步更新

● 本文itpub地址:http://blog.itpub.net/26736162/viewspace-2131070/

● 本文博客园地址:http://www.cnblogs.com/lhrbest/p/6204654.html

● 本文pdf版及小麦苗云盘地址:http://blog.itpub.net/26736162/viewspace-1624453/

● QQ群:230161599     微信群:私聊

● 联系我请加QQ好友(642808185),注明添加缘由

● 于 2016-11-28 10:00 ~ 2016-11-30 22:00 在农行完成

● 文章内容来源于小麦苗的学习笔记,部分整理自网络,若有侵权或不当之处还请谅解

● 版权所有,欢迎分享本文,转载请保留出处

...............................................................................................................................

手机长按下图识别二维码或微信客户端扫描下边的二维码来关注小麦苗的微信公众号:xiaomaimiaolhr,免费学习最实用的数据库技术。

 

时间: 2024-10-22 15:52:18

【故障处理】告警日志报“ORA-01565 Unable To open Spfile”的相关文章

oracle 11.2.0.1告警日志报错ORA-03137与绑定变量窥探BUG9703463

2017年12月份第二次oracle数据库巡检中,发现某一地市oracle数据库发现SQL语句触发特定版本BUG,详细信息如下: 操作系统版本:windows server 2008R2数据库版本:oracle 11.2.0.1问题描述:2017年12月份第二次巡检中,发现告警日志报错,报错信息如下:19/12/2017 08:27:35 Tue Dec 19 08:27:35 2017 ORA-03137: TTC 协议内部错误: [12333] [6] [50] [48] [] [] []

归档—监控ORACLE数据库告警日志

ORACLE的告警日志里面包含许多有用的信息,尤其是一些ORACLE的ORA错误信息,所以有必要及时归档.监控数据库告警日志的ORA错误,及时提醒数据库管理员DBA处理这些错误信息,那么我们首先来看看告警日志的内容片断: Thread 1 advanced to log sequence 37749 (LGWR switch) Current log# 6 seq# 37749 mem# 0: /u01/oradata/SCM2/redo06.log Thu Jun 27 15:02:30 20

使用外部表管理Oracle 告警日志(ALAERT_$SID.LOG)

--================================================ -- 使用外部表管理Oracle 告警日志(ALAERT_$SID.LOG) --================================================       Oracle 告警日志时DBA维护数据库经常需要关注的一部分内容.然而告警日志以文本文件,按时间的先后顺序不断累积的形式来存储,久而 久之,势必造成告警日志的过大,难于维护和查找相关的信息.使用外表表方式来

Oracle的告警日志之v$diag_alert_ext视图

Oracle的告警日志之v$diag_alert_ext视图   最近由于自己写的一个job老是报错,找不出来原因,数据库linux的terminal由于安全原因不让连接,因此告警日志就没有办法阅读,没有办法就想想其它的办法吧,比如采用外部表的形式来阅读告警日志就是一个不错的办法. 告警日志的重要性就不多说了.... 实验环境 本次所有的实验环境是Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Productio

alert日志报checkpoint not complete错误如何解决

高峰期alert日志报checkpoint not complete 比较频繁,需要根据什么进行调整redo? 当oracle想重用你的一个redo log时,发现这个redo log中检查点还在,oracle就会在alter log中报这个警告 与这个告警相关的的调整项有以下几个方面: 1.系统的IO性能有问题,dbwr进程写的太慢 2.LOG_CHECKPOINT_TIMEOUT,FAST_START_MTTR_TARGET, LOG_CHECKPOINT_INTERVAL 设置的不合理,致

ORACLE告警日志文件

告警日志介绍   告警日志文件是一类特殊的跟踪文件(trace file).告警日志文件命名一般为alert_<SID>.log,其中SID为ORACLE数据库实例名称.数据库告警日志是按时间顺序记录message和错误信息.   告警日志位置 在ORACLE 10g中,BACKGROUND_DUMP_DEST参数确定了告警日志的位置,但是告警日志的文件名无法修改,告警日志的名称 为:alert_<SID>.log ,其中<SID>是实例的名称.BACKGROUND_D

Linux 日志报错 xxx blocked for more than 120 seconds

        监控作业发现一台服务器(Red Hat Enterprise Linux Server release 5.7)从凌晨1:32开始,有一小段时间无法响应,数据库也连接不上,后面又正常了.早上检查了监听日志,并没有发现错误信息.但是检查告警日志,发现有下面错误信息: Thread 1 advanced to log sequence 19749 (LGWR switch)   Current log# 2 seq# 19749 mem# 0: /u01/oradata/epps/r

Linux/Unix shell 监控Oracle告警日志(monitor alter log file)

    使用shell脚本实现对Oracle数据库的监控与管理将大大简化DBA的工作负担,如常见的对实例的监控,监听的监控,告警日志的监控,以及数据库的备份,AWR report的自动邮件等.本文给出Linux 下使用 shell 脚本来监控 Oracle 告警日志(monitor alter log file).     Linux Shell的相关参考:        Linux/Unix shell 脚本中调用SQL,RMAN脚本        Linux/Unix shell sql 之

ORACLE 告警日志alert过大的处理

  现在,对于我来说,处理ORACLE告警日志alert多大不再是什么难题:但是,由于数据库是公司最重要的设备,不容有失,处理数据库相关的进程或文件还是要特别小心.  目前,ORACLE数据库主要分widows和LINUX/UNIX版本,对于LINUX/UNIX平台,我们可以使用tail -n /path/alert*.log|more来查看,很方便:但是,windows操作平台,我们遇到如下图所示那么大个的告警日志,该怎么查看.你要说直接TXT文本打开,估计是不会成功的:有人说可以上传到lin