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

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

Restore Database with ORA-01861

今天一个客户问我,有个异机恢复的问题,原库是生产,还在运行,需要将NBU中的备份恢复到另外一个主机上,数据文件均为raw。首先我们来看一下错误: RMAN> run{ 2> 3> allocate channel t1 type ‘sbt_tape’; 4> allocate channel t2 type ‘sbt_tape’; 5> send ‘NB_ORA_CLIENT=sth05v01′; 6> set until time “to_date(’2016-11-25 06:50:00′,’yyyy-mm-dd hh24:mi:ss’)”; 7> restore database; 8> release channel t1; 9> release channel t2;} allocated channel: t1 channel t1: sid=540 devtype=SBT_TAPE channel t1: Veritas NetBackup for Oracle – Release 7.5 (2012020801) allocated [...]

About consistent gets from cache (fastpath)

Oracle 11g相比10g版本而言,在优化器方面有很多改进,这里不一一列举。在分析某运营商客户的CRM系统时,发现每秒的逻辑读高达100w左右,其中Consistent Gets 就占据了90w之多。由此可见,这可能存在一个巨大的优化空间。然而,当我查询statistics信息时,发现了一个奇怪的事情,如下所示: SQL> l 1 select b.name, a.value 2 from v$sysstat a, v$statname b 3 where a.STATISTIC# = b.STATISTIC# 4* and b.NAME like ‘consistent gets%’ SQL> / NAME VALUE ————————————————– ———————————- consistent gets 2919902517406 consistent gets from cache 2918741933811 consistent gets from cache (fastpath) 0 consistent gets – examination 947312709390 consistent gets direct [...]

xtts expdp hung at inital stages

上周6某电信客户进行OSS数据库从aix到Linux的跨平台迁移升级,数据库版本并没有太大变化,即从11.2.0.3 到11.2.0.4。友商在进行3次测试,据说都没有太大问题。 然而,在正式割接时,进行元数据导出时,发现expdp操作hung住,几十分钟都没有任何反应,最后通过dblink的方式直接在目标库进行impdp操作来绕过了该问题。 经查确认是该Oracle Bug 16318046 : TTS EXPORT STUCK AT INITIAL STAGES,关于该bug的描述如下: Bug 16318046 : TTS EXPORT STUCK AT INITIAL STAGES Bug 属性 类型 B – Defect 已在产品版本中修复 严重性 2 – Severe Loss of Service 产品版本 11.2.0.3 状态 36 – Duplicate Bug. To Filer 平台 226 – Linux x86-64 创建时间 2013-2-13 平台版本 NO DATA [...]

Recover Case: 一个24TB的rac(asm)恢复案例

前几天某客户的一个核心数据库,大约24TB的rac,asm diskgroup无法mount。经过分析发现是某个disk的一个block坏掉了。其中通过kfed read读取发现确实有问题: $ kfed read /dev/rdisk/disk392 aun=0 blkn=2 | more kfbh.endian: 76 ; 0×000: 0x4c kfbh.hard: 86 ; 0×001: 0×56 kfbh.type: 77 ; 0×002: *** Unknown Enum *** kfbh.datfmt: 82 ; 0×003: 0×52 kfbh.block.blk: 1162031153 ; 0×004: blk=1162031153 kfbh.block.obj: 620095014 ; 0×008: file=386598 kfbh.check: 1426510413 ; 0x00c: 0x5506d24d kfbh.fcn.base: 0 ; 0×010: 0×00000000 kfbh.fcn.wrap: [...]

datafile auto offlile due to i/o error

刚到酒店,就接到客户电话说某数据库的一个数据文件报IO错误,通过vpn查看发现如下: Sun Oct 30 23:19:27 BEIST 2016 Trace dumping is performing id=[cdmp_20161030231927] Sun Oct 30 23:19:27 BEIST 2016 Errors in file /oracle/app/10.2/admin/xxxx/bdump/xxxx2_smon_11863216.trc: ORA-00376: file 595 cannot be read at this time ORA-01110: data file 595: ‘/dev/rdata05vg_8g_48′ Sun Oct 30 23:19:31 BEIST 2016 ORACLE Instance xxxx2 (pid = 22) – Error 376 encountered while recovering transaction [...]

2016第六届Oracle技术嘉年华与你相约

      这是一场探索数据价值和运维之道的技术盛宴 这是一次云技术的重磅聚集 这是运维者与开发者共同发出的声音 高手云集,群英荟萃 总结和升华,这个数据时代我们共同开启! 对,你没有听错,这就是2016 第六届 Oracle 技术嘉年华! 11月4日将在北京盛大开启!! Oracle 技术嘉年华作为OTN 亚太区的一部分,每年都会得到美国用户组总部的大力支持,同样,今年的嘉宾阵容也将是中西合璧,世界各地的技术大咖将在这里济济一堂,联袂为听众呈现一场饕餮盛宴。 往届嘉宾如下:     活动详情 主题:数据•技术•平台 - 新时代的技术前沿 大会网站:http://2016otn.31huiyi.com/ 会议时间:2016年11月4日(周五)- 5日(周六) 会议地点:北京·富力万丽酒店 说明: 为回馈广大消费者,我们设置了超值团队优惠票,只要5人起团购,每张票立减50元! 同时对于普通票,我们将会采取限时打折! 原价899的普通票,只要在11月4日前报名,就可以享受7折优惠 若在10月15日前报名,更可以享受5折惊喜优惠!!  

数据库重启之后无法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 [...]

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