love wife & love life —Roger 的Oracle技术博客

Phone:18180207355 提供专业Oracle数据恢复、性能优化、迁移升级、紧急救援等服务

数据库重启之后无法open的恢复案例

这是某网友的维护的一套数据库,据说是正常重启之后就无法启动数据库了。那么我们先来看看日志是什么样的: Errors in file /u01/app/oracle/admin/orcl/bdump/orcl1_p012_18165.trc: ORA-27090: Message 27090 not found; product=RDBMS; facility=ORA Linux-x86_64 Error: 4: Interrupted system call Additional information: 3 Additional information: 128 Additional information: 65536 ….. Errors in file /u01/app/oracle/admin/orcl/bdump/orcl1_p007_18153.trc: ORA-27090: Message 27090 not found; product=RDBMS; facility=ORA Linux-x86_64 Error: 4: Interrupted system call Additional information: 3 Additional information: 128 Additional information: 65536 Starting [...]

耗时一周的某客户Oracle RAC(4 TB ASM) 数据库恢复记录

6月底我们接到某客户的紧急支持请求,其客户数据库在不久前由于机房停电,导致数据库重启后无法启动。 我们通过teamviewer远程初步分析了alert log以及kfed读取了几个disk 发现,数据库无法启动的根本原因在于ASM diskgroup无法mount。而ASM diskgroup 无法mount的根本原因在于,ASM元数据出现损坏,其中表现为ASM 启动时无法进行事务恢复。 这里我们先不去纠结为什么会坏。对于asm的元数据如果出现损坏,那么修复的难度可想而知。 这里我采取了非常简单的数据库恢复方案,计划用AMDU抽取数据库文件,然后将数据库open,最后再重建原数据库磁盘组,最后通过Oracle rman 的backup as copy 方式将数据库还原回去。 想象是比较美好的,经过与客户长达1天的沟通协调之后,发现客户根本协调不到存储资源,而数据库环境本地可以空间也就不足100G。我们知道,整个数据库的磁盘组是6TB,其中数据库文件大约在4T左右,显然这是比较麻烦的事情。 无奈之下,客户从京东买了一个6TB的移动硬盘,经过一番努力之后,挂上移动硬盘,通过AMDU抽取文件测试,发现速度大约为5m/s。这是一个500m的undo文件复制到移动硬盘的速度测试: root@jlzgdb1 # time dd if=/amdu/datafiles/undotbs2.dbf of=/data/undo_test.dbf bs=8192 64001+0 records in 64001+0 records out real 1:23.7 user 0.2 sys 2.2 大家可以计算一下,大约需要10天左右。这样是这样进行下去,那么整个恢复过程估计需要15天了,这是无法接受的。 后面跟客户了解了一下,客户的应用服务器是windows环境,我通过在windows共享文件,NFS共享到soalris,测试amdu抽取文件的速度大约可以达到15m/s。虽然这也是非常之慢的,但是相比之前已经好很多了,客户也可以接受了。 这里不得不说一下windows和Soalris之间配置NFS共享,也是一个比较麻烦的事情。折腾了几个小时才搞定这个问题。这里我简单记录一下配置的步骤,如下: –solaris 启动nfs服务 svcadm -v enable -r network/nfs/server –windows 安装nfs服务 设置文件夹共享,nfs共享 设置用户映射 nfsfile /v /ru=-2 /rg=-2 /s [...]

Insert into is very slowly,why ?

上周运营商客户的计费库反应其入库程序很慢,应用方通过监控程序发现主要慢在对于几个表的insert操作上。按照我们的通常理解,insert应该是极快的,为什么会很慢呢?而且反应之前挺好的。这有点让我百思不得其解。通过检查event也并没有发现什么奇怪的地方,于是我通过10046 跟踪了应用的入库程序,如下应用方反应比较慢的表的insert操作,确实非常慢,如下所示: INSERT INTO XXXX_EVENT_201605C (ROAMING_NBR,…..,OFFER_INSTANCE_ID4) VALUES (:ROAMING_NBR,…..:OFFER_INSTANCE_ID4) call count cpu elapsed disk query current rows ——- —— ——– ———- ———- ———- ———- ———- Parse 17 0.00 0.00 0 0 0 0 Execute 18 1.06 27.41 4534 518 33976 4579 Fetch 0 0.00 0.00 0 0 0 0 ——- —— ——– ———- ———- ———- ———- [...]

expdp 报错ORA-7445 的一个问题展开

某客户说一套数据库由于非正常关机重启之后,进行数据导出发现报错,expdp无法正常工作,报错之后直接退出: 处理对象类型 SCHEMA_EXPORT/JOB . . 导出了 “STATS”.”T_REPORT_MONTH_TEMPS” 988.2 MB 1292221 行 ORA-39014: 一个或多个 worker 进程已过早地退出。 ORA-39029: worker 进程 1 (进程名为 “DW01″) 过早地终止 ORA-31672: Worker 进程 DW01 意外停止。 作业 “SYS”.”SYS_EXPORT_SCHEMA_04″ 因致命错误于 23:58:10 停止 而检查此时的alert log可以发现有如下类似的错误: Errors in file /u01/app/oracle/admin/orcl/bdump/orcl_dw01_28608.trc: ORA-07445: 出现异常错误: 核心转储 [klufprd()+321] [SIGSEGV] [Address not mapped to object] [0x000000000] [] [] 从上面的信息我们可以得到如下几个结论: 1、expdp的写进程报错,因为日志产生是dw进程。 2、dw进程报错的原因是遭遇了ora-07445 [klufprd()+321]错误。 [...]

清明节加班恢复的一个11gR2 rac恢复案例

这是昨天节假如接到的某客户的紧急救援数据恢复案例。大致的情况是由于掉电导致数据库无法open。经过初步排查,确认数据库版本为Oracle 11.2.0.3(linux RAC),数据量比较小, 大约200G左右。整个恢复过程开始看上去很顺利,仅30分钟就顺利打开了数据库,后续发现其中确实有少坑,这里跟大家简单分享一下这个清明节加班的恢复case。 首先我们来看下数据库无法open所报的错误是什么?   Sun Apr 03 20:55:36 2016 SMON: enabling cache recovery ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0×0000.5edc85a7): select ctime, mtime, stime from obj$ where obj# = :1 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_19990.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level [...]

一个55TB的Oracle RAC (ASM)恢复case

前几天某客户的一个数据库出现故障,需要我们紧急救援支持。了解了一下环境,着实也吓了一跳,数据量55TB左右。首先我们来看看故障的信息:   Fri Mar 25 22:57:10 2016 Errors in file /oracle/app/oracle/diag/rdbms/njsdb/njsdb1/trace/xxxx1_dia0_30474350.trc (incident=640081): ORA-32701: Possible hangs up to hang ID=80 detected Incident details in: /oracle/app/oracle/diag/rdbms/xxxx/xxxx1/incident/incdir_640081/xxxx1_dia0_30474350_i640081.trc DIA0 requesting termination of session sid:10347 with serial # 16419 (ospid:29884706) on instance 2 due to a LOCAL, HIGH confidence hang with ID=80. Hang Resolution Reason: Although the number of affected [...]

某客户一套15TB的数据库恢复小记

该客户数据库在春节之前就出现故障,后面经过多人尝试恢复后,均为打开数据库;数据库在open时报如下错误: Wed Jan 13 17:03:25 2016 ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, Query Duration=1452675805 sec, SCN: 0x0d6a.46c6524f): Wed Jan 13 17:03:25 2016 select ctime, mtime, stime from obj$ where obj# = :1 Wed Jan 13 17:03:25 2016 Errors in file /u01/app/oracle/admin/xxxx/udump/xxxx1_ora_18274.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00604: error occurred [...]

通过调整_lm_cache_res_cleanup解决shared Pool问题

前不久某客户的一套核心数据库(10.2.0.4.12),据说每间隔一段时间就必须重启,因为会报ORA-04031错误。查询发现shared pool差不多5G的样子,其实ges resource消耗了差不多3.5G shared pool 内存,也确实有些离谱了。 SQL> c/gcs/ges 1* select * from v$sgastat where name like ‘ges%’ SQL> / POOL NAME BYTES ———— ——————————- ———- shared pool ges big msg p 461440 shared pool ges resource hash seq tab 32768 shared pool ges shared global area 23928 shared pool ges regular msg buffers 1254008 shared [...]

从未遇见的错误ora-00600 [3712] 恢复案例

在Oracle数据库的日常维护中,我们可能经常会遇到一些从未见过的错误,甚至莫名其妙的错误。很多时候,甚至通过metalink、baidu、甚至google 都无法搜索到相关内容。这不,昨天公司南区同事让帮忙恢复的的一个客户数据库;据说是归档数据库,没有备份,重启实例后就无法打开数据库了。 我也是第一次听说这种事情,看了下居然是Oracle 11.2.0.3的数据库,还有这样起码的事情,确实有点匪夷所思。首先我们来看下是报错是什么样的。                           看到这个错误。我感觉有一定似曾相识的感觉,但是有又说不来具体是什么错误。不过从错误号来看,我可以大致判断跟什么内容有关系。这里我拓展一下,对于Oracle ora-00600 错误,metalink有一篇详细的文档描述,里面对600错误后面的错误编号进行了分类。对于该文档大家务必了解下。所以现在即使我从未见过的ora-00600错误,我仍然可以第一眼就能大致判断是哪方面的问题。这里列举下: Ora-600 Base Functionality Description 2000 server/rcv Cache Op 2100 server/rcv Control File mgmt 2200 server/rcv Misc (SCN etc.) 2400 server/rcv Buffer Instance Hash Table 2600 server/rcv Redo file component 2800 server/rcv Db file 3000 server/rcv [...]

数套ASM RAC的恢复案例

前不久帮助某客户恢复了6套Oracle RAC,均为ASM,而且版本均为10.2.0.4。熬夜好几天,差点吐血了。 这里以其中一套库的恢复进行简单说明,跟大家分享。 其中几套基本上都遇到了如下的ORA-00600 错误: Thu Dec 31 11:55:46 2015 SUCCESS: diskgroup DG1 was mounted Thu Dec 31 11:55:50 2015 Errors in file /oracle/admin/xxx/udump/xxx1_ora_28803.trc: ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [13715626], [13715623], [0x000000000], [], [], [], [] SUCCESS: diskgroup DG1 was dismounted Thu Dec 31 11:55:51 2015 对于该错误,其实很简单,主要是因为控制文件损坏,通过重建控制文件或者利用备份的控制文件进行restore即可进行mount;甚至于我们利用控制文件快照都可以进行数据库mount;然后接着进行恢复操作。在恢复的过程中还遇到了如下的错误: Errors in file /oracle/admin/xxx/udump/xxx1_ora_6990.trc: ORA-00600: internal error [...]

how to recreate acfs filesystem ?

今天西北某电信客户的一个系统有点小问题,无法切换归档日志。通过临时将归档路径都放到本地后,切换ok。检查发现之前的arch目录有点问题,如下: [root@dtdb1 arch]# ls -ltr ls: cannot access 1_3883_855680193.dbf: Invalid argument ls: cannot access 2_2408_855680193.dbf: No such file or directory ls: cannot access 2_2408_855680193.dbf: No such file or directory ls: cannot access 1_4776_855680193.dbf: Invalid argument total 7521476 -????????? ? ? ? ? ? 2_2408_855680193.dbf -????????? ? ? ? ? ? 2_2408_855680193.dbf -????????? ? ? ? [...]

某网友的数据库TB 数据库恢复

这是一个网友的数据库,据说是非归档,不知道为啥主机强制重启后就无法打开数据库。首先我们来看下他这里在open的时候所报的错误: SQL> alter database open ; alter database open * 第 1 行出现错误: ORA-00603: ORACLE server session terminated by fatal error ORA-00600: internal error code, arguments: [2662], [3429], [661240178], [3429], [661259589], [12583040], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [2662], [3429], [661240177], [3429], [661259589], [12583040], [], [], [], [], [], [] [...]

3TB 非归档Oracle数据库恢复小case(windows)

这是友情支持一个朋友的数据库恢复case,昨天圣诞节的时候来个求助,只能速度帮忙解决了好过节去了。首先我们来看下的alert log都有哪些信息: Wed Dec 23 15:19:21 2015 SMON: enabling tx recovery Wed Dec 23 15:19:21 2015 Database Characterset is ZHS16GBK Opening with internal Resource Manager plan where NUMA PG = 2, CPUs = 8 Wed Dec 23 15:19:22 2015 Errors in file d:\oracle\product\10.2.0\admin\ajzq\udump\ajzq_ora_1712.trc: ORA-00600: internal error code, arguments: [4194], [45], [45], [], [], [], [], [...]

ogg学习系列–ORA-00353: log corruption due to GoldenGate extract process

某客户今天告诉我,一套核心库的备库的日志涨的很快,通过检查发现alert log不断的报错,如下所示: Fri Dec 11 20:48:37 2015 Incomplete read from log member ‘/arch2/2_82548_864474703.dbf’. Trying next member. Incomplete read from log member ‘/arch2/2_82548_864474703.dbf’. Trying next member.Archived Log entry 101817 added for thread 2 sequence 82548 ID 0xedd14d2a dest 1: Incomplete read from log member ‘/arch2/2_82548_864474703.dbf’. Trying next member. Errors in file /oracle/app/oracle/diag/rdbms/crmadg/crmdb2/trace/crmdb2_ora_15304.trc (incident=711224): ORA-00353: log corruption [...]

linux 强制free cache 导致数据库实例crash

这是1个月之前处理的某个客户的案例,现象大致是某天凌晨某RAC节点实例被重启了,通过如下是alert log我们可以发现RAC集群的节点2实例被强行终止掉了,如下是详细的告警日志信息: Mon Sep 28 02:00:00 2015 Errors in file /oracle/admin/xxx/bdxxx/xxx2_j000_7604.trc: ORA-12012: error on auto execute of job 171538 ORA-06550: line ORA-06550: line 4, column 3: PLS-00905: object XSQD.E_SP_DL_CRM_TERMINAL_MANAGER is invalid ORA-06550: line 4, column 3: PL/SQL: Statement ignored , column : Mon Sep 28 02:03:18 2015 Errors in file /oracle/admin/xxx/udxxx/xxx2_ora_6810.trc: ORA-00600: internal error code, [...]

记一次TB级别的Exadata数据库恢复

某客户的exadata环境,由于大量硬件故障,导致数据库宕机。经过分析确认是由于某个cell节点的某个disk出现异常,导致部分 cell节点的disk 离线后无法进行asm reblance;最终导致diskgroup 被强制dismount了。如下是alert log: Fri Oct 09 15:44:26 2015 NOTE: process _user4655_+asm1 (4655) initiating offline of disk 46.3915916191 (DATA_KLYX_CD_10_KLYXCEL02) with mask 0x7e in group 1 NOTE: checking PST: grp = 1 ERROR: Disk 18 cannot be offlined, since all the disks [18, 49] with mirrored data would be offline. ERROR: too many offline [...]

How to recreate Bootstrap Index(I_OBJ1,I_USER1,I_FILE#_BLOCK#) to fix ORA-00701 ?

在上一篇数据恢复文章中,我提到了bootstrap 核心数据数据字典表的对象index出现异常后,难以修复。实际上,仅仅是数据不一致(或类似的情况)导致的index异常,其实有其他的方式进行重建。实际上Oracle 11gR2版本中的如下脚本提供了相关的解决方案:$ORACLE_HOME/rdbms/admin/utlmmig.sql. 虽然该脚本的的解决方法是针对从10g升级到11gR2出现异常后的处理方式,然而该脚本中的内容,却值得我们深入研究。 几年前之前也写过一篇通过bbed来修复bootstrap 核心对象的例子:bootstrap$核心对象数据不一致导致ORA-08102 这里以上篇文章中提到的2个index 为例进行说明: SQL> alter index sys.i_obj1 rebuild; alter index sys.i_obj1 rebuild * ERROR at line 1: ORA-00701: object necessary for warmstarting database cannot be altered SQL> alter index sys.i_obj2 rebuild; alter index sys.i_obj2 rebuild * ERROR at line 1: ORA-00701: object necessary for warmstarting database cannot be altered SQL> [...]

某客户RAC由于掉电导致系统崩溃的恢复过程

这里简单记录一下,此次国庆加班恢复的某客户的2套Oracle RAC数据库,整个恢复过程中,2套rac差不多,因此这里以其中一套数据库的恢复过程为例进行简单分析说明。数据库由于为非归档,由于掉电导致重启之后系统无法正常open。 在正常open的过程中,报错如下错误: SQL> alter database open; alter database open * ERROR at line 1: ORA-00600: internal error code, arguments: [kcratr1_lastbwr], [], [], [], [], [], [], [] SQL> shutdown immediate ORA-01109: database not open Database dismounted. ORACLE instance shut down. SQL> startup ORACLE instance started. Total System Global Area 4294967296 bytes Fixed Size 2089576 [...]

某大学的数据库恢复过程

某客户的数据库出现崩溃,无法正常启动,经过我的远程紧急救援恢复之后,恢复正常,如下是简单的处理过程,供参考! 在open数据库时,发现无法打开,报错如下: SMON: enabling cache recovery ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0×0000.1d2be1e6): select ctime, mtime, stime from obj$ where obj# = :1 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_20559.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level 1 ORA-01555: snapshot too old: rollback segment number 7 [...]

mapid溢出导致Oracle RAC 节点重启

某客户的CRM数据库在2015年9月17号11:38分左出现其中一个节点宕机的情况。其中节点1报错信息如下: Thu Sep 17 11:38:10 2015 Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. NOTE: ASMB terminating Errors in file /oracle/app/oracle/diag/rdbms/crm2db/crm2db1/trace/crm2db1_asmb_11141424.trc: ORA-15064: communication failure with ASM instance ORA-00600: internal error code, arguments: [ORA_NPI_ERROR], [600], [ORA-00600: internal error code, arguments: [kffilCreate01], [crm2db1:crm2db], [], [...]

第 1 页,共 15 页12345...1015...15
18180207355
加Q咨询