标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (103)
- 数据库 (1,756)
- DB2 (22)
- MySQL (76)
- Oracle (1,598)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (163)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (588)
- Oracle安装升级 (96)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (84)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
- 11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错
- [MY-013183] [InnoDB] Assertion failure故障处理
- Oracle 19c 202504补丁(RUs+OJVM)-19.27
- Oracle Recovery Tools修复ORA-600 6101/kdxlin:psno out of range故障
- pdu完美支持金仓数据库恢复(KingbaseES)
- 虚拟机故障引起ORA-00310 ORA-00334故障处理
- pg创建gbk字符集库
- PostgreSQL运行日志管理
- ora-600 kdsgrp1 错误描述
- GAM、SGAM 或 PFS 页上存在页错误处理
- ORA-600 krhpfh_03-1208
- VMware勒索加密恢复(vmdk勒索恢复)
- ORA-39773: parse of metadata stream failed故障处理
分类目录归档:ORA-xxxxx
ORA-00600: internal error code, arguments: [2252], [3987]
客户数据库版本10.2.0.4,启动成功之后立马crash,让我们协助解决
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相关信息
从ORA-600 2252错误信息看,由于scn可能超过该数据库的天花板理论上而导致该问题,而reco进程主要是由于分布式事务引起,通过和客户确认,该库有通过dblink去访问11204版本oracle,而从2019年6月23日之后scn的算法发生了一些改变(SCN Compatibility问题汇总-2019年6月23日),导致数据库可以支持更大的scn,从而当低版本需要进行分布式事务操作之时,可能导致数据库异常.
处理方案:通过临时屏蔽分布式事务,让数据库临时正常工作;长期解决方案需要把数据库版本升级,避免scn引起相关问题
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-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配置过大导致该问题.