分类目录归档:ORA-xxxxx

ORA-00600: internal error code, arguments: [2252], [3987]

客户数据库版本10.2.0.4,启动成功之后立马crash,让我们协助解决
version


Thu Jul  4 13:03:10 2019
Completed: ALTER DATABASE OPEN
Thu Jul  4 13:03:10 2019
db_recovery_file_dest_size of 2048 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Thu Jul  4 13:04:01 2019
Errors in file /oracle/app/oracle/admin/orcl/bdump/orcl_reco_22268.trc:
ORA-00600: internal error code, arguments: [2252], [3987], [3375047096], [], [], [], [], []
Thu Jul  4 13:04:01 2019
Errors in file /oracle/app/oracle/admin/orcl/bdump/orcl_reco_22268.trc:
ORA-00600: internal error code, arguments: [2252], [3987], [3375047096], [], [], [], [], []
Thu Jul  4 13:04:02 2019
Errors in file /oracle/app/oracle/admin/orcl/bdump/orcl_reco_22268.trc:
ORA-00600: internal error code, arguments: [2252], [3987], [3375047096], [], [], [], [], []
Thu Jul  4 13:04:02 2019
RECO: terminating instance due to error 476
Instance terminated by RECO, pid = 22268

根据以往经验记录一次ORA-00600[2252]故障解决,很可能是scn过大引起.通过Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)检查scn相关信息
scn


从ORA-600 2252错误信息看,由于scn可能超过该数据库的天花板理论上而导致该问题,而reco进程主要是由于分布式事务引起,通过和客户确认,该库有通过dblink去访问11204版本oracle,而从2019年6月23日之后scn的算法发生了一些改变(SCN Compatibility问题汇总-2019年6月23日),导致数据库可以支持更大的scn,从而当低版本需要进行分布式事务操作之时,可能导致数据库异常.

处理方案:通过临时屏蔽分布式事务,让数据库临时正常工作;长期解决方案需要把数据库版本升级,避免scn引起相关问题

发表在 ORA-xxxxx, Oracle备份恢复 | 标签为 , , | 评论关闭

ORA-07217: sltln: environment variable cannot be evaluated.

dg备库mount报ORA-07217
在一次搭建dg过程中,备库无法mount,报ORA-07217: sltln: environment variable cannot be evaluated.错误

[oracle@localhost orcl]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Wed Feb 13 22:27:31 2019

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-07217: sltln: environment variable cannot be evaluated.

alert日志报错

Set as converted control file due to db_unique_name mismatch
Changing di2dbun from ORCL to ORCLDG
ORA-7217 signalled during: alter database mount...
Wed Feb 13 20:33:41 2019
alter database mount
ORA-7217 signalled during: alter database mount...
Wed Feb 13 20:36:11 2019
alter database mount
ORA-7217 signalled during: alter database mount...

根据mos排查
根据mos ORA-07217: sltln: environment variable cannot be evaluated (Doc ID 2487898.1)描述排查,确认不是该问题

SQL> show parameter diag;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
diagnostic_dest                      string      /u01/app/oracle

[oracle@dg:/opt/app/oracle/arch]$env|grep ORA
ORACLE_SID=orcl
ORACLE_BASE=/opt/app/oracle
ORACLE_TERM=xterm
ORACLE_HOME=/opt/app/oracle/product/11.2.0/db_1

检查发现数据文件异常

SQL> select name from v$datafile where name like '%$%';

NAME
------------------------------------------------------
+DATA/orcl/datafile/ts_his$emr01
+DATA/orcl/datafile/ts_his$emr02

通过分析,注释掉db_file_name_convert=’+DATA/orcl/datafile/’,’/u01/app/oradata/orcl/’即可正常mount成功,数据文件命令一定要规范(不要有特殊符号),不然给后人和自己留下巨坑

发表在 ORA-xxxxx | 标签为 | 评论关闭

下调虚拟化资源导致ORA-00494

在虚拟化环境中的Oracle数据库近期报大量ORA-00494: 入队 [CF] 被持有的时间过长 (more than 900 seconds) 错误,每次客户重启一段时间之后又不行

Mon Nov 26 14:04:39 中国标准时间 2018
Thread 1 advanced to log sequence 97327 (LGWR switch)
  Current log# 1 seq# 97327 mem# 0: D:\ORADATA\xifenfei\REDO01.LOG
Mon Nov 26 14:20:02 中国标准时间 2018
Errors in file c:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_arc1_1860.trc:
ORA-00494: 入队 [CF] 被持有的时间过长 (more than 900 seconds) (由 'inst 1, osid 3264')

Mon Nov 26 14:20:03 中国标准时间 2018
Errors in file c:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_arc4_1872.trc:
ORA-00494: 入队 [CF] 被持有的时间过长 (more than 900 seconds) (由 'inst 1, osid 3264')

Mon Nov 26 14:20:03 中国标准时间 2018
Errors in file c:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_arc3_1868.trc:
ORA-00494: 入队 [CF] 被持有的时间过长 (more than 900 seconds) (由 'inst 1, osid 3264')

Mon Nov 26 14:20:03 中国标准时间 2018
Errors in file c:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_arc0_1856.trc:
ORA-00494: 入队 [CF] 被持有的时间过长 (more than 900 seconds) (由 'inst 1, osid 3264')

因为这个系统有一段历史,以前是客户的核心生产库,虚拟化资源给的比较多128G,后来核心生产迁移到其他系统,该系统跑一些边缘小业务,所以怀疑客户有可能下调了虚拟化的资源(cpu和内存),检查机器硬件资源

C:\Users\Administrator>systeminfo

主机名:           HIS-VM
OS 名称:          Microsoft Windows Server 2008 R2 Enterprise
OS 版本:          6.1.7601 Service Pack 1 Build 7601
OS 制造商:        Microsoft Corporation
OS 配置:          独立服务器
OS 构件类型:      Multiprocessor Free
注册的所有人:     Windows 用户
注册的组织:
产品 ID:          00486-OEM-8400691-20006
初始安装日期:     2013/4/19, 12:22:44
系统启动时间:     2018/11/27, 8:06:00
系统制造商:       VMware, Inc.
系统型号:         VMware Virtual Platform
系统类型:         x64-based PC
处理器:           安装了 2 个处理器。
                  [01]: Intel64 Family 6 Model 45 Stepping 2 GenuineIntel
Mhz
                  [02]: Intel64 Family 6 Model 45 Stepping 2 GenuineIntel
Mhz
BIOS 版本:        Phoenix Technologies LTD 6.00, 2014/4/14
Windows 目录:     C:\Windows
系统目录:         C:\Windows\system32
启动设备:         \Device\HarddiskVolume1
系统区域设置:     zh-cn;中文(中国)
输入法区域设置:   zh-cn;中文(中国)
时区:             (UTC+08:00) 北京,重庆,香港特别行政区,乌鲁木齐
物理内存总量:     32,767 MB
可用的物理内存:   22,740 MB
虚拟内存: 最大值: 95,047 MB
虚拟内存: 可用:   10,426 MB
虚拟内存: 使用中: 84,621 MB
页面文件位置:     C:\pagefile.sys
域:               WORKGROUP

果然系统内存从128G下调到了32G,但是数据库sga估计没有对应降低

SQL> show parameter sga;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 80G
sga_target                           big integer 80G

基本上就是由于虚拟机内存下调,但是数据库sga配置过大导致该问题.

发表在 ORA-xxxxx | 标签为 , | 评论关闭