PRM – PARNASSUSDATA RECOVERY MANAGER For Oracle Database介绍手册

PRM – PARNASSUSDATA RECOVERY MANAGER For Oracle Database介绍手册下载:

 

PRM – ParnassusData Recovery Manager For Oracle Database, ParnassusData Software System提供,高效地恢复损坏ORACLE数据库中的数据。

 

PRM服务

 

PRM – ParnassusData Recovery Manager For Oracle Database,是由ParnassusData Software System(暨诗檀(上海)软件系统有限公司)独立研发的Oracle数据库灾难修复软件,拥有独立的软件著作权。用户可以购买PRM,通过其全程图形化交互的简单使用体验来自行恢复数据;用户也可以购买ParnassusData提供的Oracle数据库灾难恢复服务,由ParnassusData派遣专家级恢复工程师远程或现场协助用户应对数据库损坏难题。传统数据库损坏后的恢复总是需要资深数据库专家或者原厂专家的帮忙,但是PRM独创的高易用性恢复向导将恢复过程浓缩到简要的几个步骤,任何一个稍有基础的技术人员均可以独立完成恢复作业。由于PRM是直接从损坏数据库的数据文件中抽取数据,故其所做的读取是脏读。在没有充分备份条件下数据库灾难恢复的性质决定了任何软件工具不可能保证可以恢复100%一致的数据,但只要数据还没有被彻底覆盖,那么PRM可以保证恢复99.9%的数据。

 

 

PRM的优势

 

 

ParnassusData立志于提供更高效、简便的Oracle数据库灾难恢复产品:

 

  • 可以从无法打开的数据库中直接抽取Table和Cluster中的数据
  •   独创DataBridge模式将抽取出来的数据直接发送到目标数据库,无需用户费时费力再手动导入
  •   直接从数据文件中恢复数据,健壮度极强
  •   如果有SYSTEM表空间,适用于字典模式(Dict-Mode),提供图形化树形图预览数据
  •   如果丢失了SYSTEM表空间,通过PRM智能扫描同样可以轻松预览数据
  •   无需数据库完成介质恢复或崩溃恢复,即可绕过归档日志archivelog
  •   即便对于已经部分损坏的数据块,PRM仍能恢复其中的可用数据
  •   从ORACLE 9i到12c等多个版本均经过严格测试
  •    基于JAVA开发,最低软件要求为JDK 1.4,绿色无需安装,跨所有操作系统平台包括但不限于:常见Unix如AIX,HPUX ,Solaris, Linux(redhat、OEL、SUSE)以及Windows
  •   全面支持ASM

重整旗鼓

 

虽然我们可以通过PRM为用户克服数据库损坏难关,但数据库灾难恢复仍十分危险。ParnassusData拥有对ORACLE数据库备份恢复的丰富经验和解决方案,可以在用户有限的硬件资源条件下提供最实用的备份恢复方案,这些方案包括但不限于:DataGuard,物理或逻辑备份。ParnassusData将为用户在备份成本控制与备份有效性之间作出最佳平衡。

ParnassusData Recovery Manager For Oracle 白皮书(Version 0.2)

附件为临时的ParnassusData Recovery Manager For Oracle白皮书(Version 0.2),这个白皮书还在完善中,你可以把它当做一个临时的PRM使用手册。

 

prm-pic1_0

 下载ParnassusData Recovery Manager For Oracle社区版本,http://parnassusdata.com/d01/ParnassusData_PRMforOracle_2001.zip

 

 

【Oracle数据库恢复】ORA-00600[25026】错误解析

该ORA-00600[25026]错误一般是当ORACLE查看检测tablespace表空间时发现一个无效的tablespace ID或者RDBA所引起,其2个变量的含义为:

Arg [a] — tablespace ID
Arg [b] — rdba

 

ORA-00600[25026]错误属于Kernel File management Tablespace component模块,其可能的影响包括 实例失败,可能的物理块损坏等。

其相关的BUG列表如下:

如果自己搞不定可以找ASKMACLEAN专业ORACLE数据库修复团队成员帮您恢复!

 

NB Bug Fixed Description
13503554 11.2.0.4, 12.2.0.0 Various ORA-600 errors crashing the apply process in a downstreams environment
17604137 12.1.0.2, 12.2.0.0 ORA-600 [25026] when running query on table being dropped
12912297 11.2.0.3.BP07, 11.2.0.4, 12.1.0.1 CREATE GLOBAL TEMPORARY TABLE incorrectly allows a tablespace group causing ORA-600 [25026] on insert
+ 9399991 11.1.0.7.5, 11.2.0.1.3, 11.2.0.1.BP04, 11.2.0.2, 12.1.0.1 Assorted Internal Errors and Dumps (mostly under kkpa*/kcb*) from SQL against partitioned tables
8630146 10.2.0.5, 11.2.0.1 OERI [25026] / OERI [25012] by SMON while recovering a transaction against a dropped tablespace
6249879 10.2.0.5, 11.2.0.1 OERI [kcbgcur_1] / [25026] / ORA-1502 from DML on table with CONSTRAINTS
4545196 10.2.0.4, 11.1.0.6 Corrupt index leaf by RMAN CONVERT from cross platform transport of compress-key indexes

【Oracle数据库恢复】ORA-00600[25027]错误解析

ORA-00600[25027]错误的触发原因是ORACLE检测到一个无效的表空间号TSN Tablespace Number或者相对文件号Relative File Number。

该ORA-00600[25027]的2个变量各代表:

arg[a] Tablespace Number表空间号

arg[b] 十进制的相对数据块号Relative Data Block Address (RDBA)

 

该ORA-00600[25027]错误相关的模块为Kernel File management Tablespace component,其影响为可能的物理块损坏。

当该错误触发后 如果 arg[b] 即RDBA为0,则该错误可能由于索引问题引起。

可以使用如下查询来获得有问题的索引:

 

 select do.owner,do.object_name, do.object_type,sysind.flags
     from dba_objects do, sys.ind$ sysind
     where do.object_id = sysind.obj#
     and bitand(sysind.flags,4096)=4096;

如果上面的查询返回了数据行,则建议用户进一步检查查询所获得的对象,并考虑drop这些对象来绕过错误。

 

进一步可以对trace文件中指向的表做一个analyze table validate structure cascade,来进一步确认该问题。

与ORA-00600[25027]相关的一些BUG列表如下:

 

 如果自己搞不定可以找ASKMACLEAN专业ORACLE数据库修复团队成员帮您恢复!

 

NB Bug Fixed Description
14010183 11.2.0.3.BP22, 11.2.0.4.BP03, 12.1.0.2, 12.2.0.0 ORA-600 [ktspfundo:objdchk_kcbgcur_3] in SMON after failed temp segment merge load
13503554 11.2.0.4, 12.2.0.0 Various ORA-600 errors crashing the apply process in a downstreams environment
13785716 11.2.0.4, 12.1.0.1 Intermittent ORA-600 [25027] during upgrade from 10.2 to 11.2
11661824 11.2.0.1.BP09 Assorted Dumps by SQL*LOADER using DIRECT and PARALLEL after exadata bp8 is applied
10067246 12.2.0.0 ORA-600 [25027] ORA-7445 [kauxs_do_dml_cooperation] by CREATE INDEX ONLINE
14138130 11.2.0.3.5, 11.2.0.3.BP13, 11.2.0.4, 12.1.0.1 SGA memory corruption / ORA-7445 when modifying uncompressed blocks of an HCC-compressed segment
13330018 11.2.0.4, 12.1.0.1 ora-600 [ktspfmb_add1], [4294959240] occurred, then cannot recover with ora-600[25027]
13103913 11.2.0.2.BP15, 11.2.0.3.3, 11.2.0.3.BP03, 11.2.0.4, 12.1.0.1 ORA-600 [25027] [ts#] [1] or false ORA-1 during dml while index is being rebuilt online
10394825 11.2.0.3, 12.1.0.1 ORA-600[25027] [..] [0] inserting to ASSM segment
10329146 11.2.0.1.BP10, 11.2.0.2.2, 11.2.0.2.BP03, 11.2.0.2.GIBUNDLE02, 11.2.0.2.GIPSU02, 11.2.0.3, 12.1.0.1 Lost write in ASM with multiple DBWs and a disk is offlined and then onlined
+ 10209232 11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2.1, 11.2.0.2.BP02, 11.2.0.2.GIBUNDLE01, 11.2.0.3, 12.1.0.1 ORA-1578 / ORA-600 [3020] Corruption. Misplaced Blocks and Lost Write in ASM
+ 9399991 11.1.0.7.5, 11.2.0.1.3, 11.2.0.1.BP04, 11.2.0.2, 12.1.0.1 Assorted Internal Errors and Dumps (mostly under kkpa*/kcb*) from SQL against partitioned tables
* 9145541 11.1.0.7.4, 11.2.0.1.2, 11.2.0.2, 12.1.0.1 OERI[25027]/OERI[4097]/OERI[4000]/ORA-1555 in plugged datafile after CREATE CONTROLFILE in 11g
8837919 11.2.0.2, 12.1.0.1 DBV / RMAN enhanced to detect ASSM blocks with ktbfbseg but not ktbfexthd flag set as in Bug 8803762
8803762 11.1.0.7.6, 11.2.0.1.2, 11.2.0.1.BP06, 11.2.0.2, 12.1.0.1 ORA-600[kdsgrp1], ORA-600[25027] or wrong results on 11g database upgrade from 9i
8716064 11.2.0.2, 12.1.0.1 Analyze Table Validate Structure fails on ADG standby with several errors
+ 8597106 11.2.0.1.BP06, 11.2.0.2, 12.1.0.1 Lost Write in ASM when normal redundancy is used
7251049 11.2.0.1.BP08, 11.2.0.2, 12.1.0.1 Corruption in bitmap index introduced when using transportable tablespaces
8437213 10.2.0.4.3, 10.2.0.5, 11.1.0.7.7, 11.2.0.1 ASSM first level bitmap block corruption
8356966 11.2.0.1 ORA-7445 [kdr9ir2rst] by DBMS_ADVISOR or false ORA-1498 by ANALYZE on COMPRESS table
* 8198906 10.2.0.5, 11.2.0.1 OERI [kddummy_blkchk] / OERI [5467] for an aborted transaction of allocating extents
* 7263842 10.2.0.4.2, 10.2.0.5, 11.1.0.7.1, 11.2.0.1 ORA-955 during CTAS / OERI [ktsircinfo_num1] / dictionary inconsistency for PARTITIONED Tables
6666915 10.2.0.5, 11.1.0.7, 11.2.0.1 OERI[25027] / dictionary corruption from concurrent partition DDL
6025993 10.2.0.5, 11.1.0.6 ORA-600 [25027] in flashback archiving queries
4925342 9.2.0.8, 10.2.0.3, 11.1.0.6 OERI [25027] / OERI [25012] on IOT analyze estimate statistics
* 7190270 10.2.0.4.1, 10.2.0.5 Various ORA-600 errors / dictionary inconsistency from CTAS / DROP
4310371 9.2.0.8, 10.2.0.2 OERI [25027] from concurrent startup / shutdown in RAC
4177651 10.2.0.1 Row migration within a MERGE may OERI[25027]
4020195 10.1.0.5, 10.2.0.1 OERI 25027 can occur in RAC accessing transported tablespace
4000840 9.2.0.7, 10.1.0.4, 10.2.0.1 Update of a row with more than 255 columns can cause block corruption
3963135 10.1.0.5, 10.2.0.1 OERI[kcbgcur_3] / OERI:25027 during bitmap index updates
3829900 10.1.0.4, 10.2.0.1 OERI[25027] possible accessing index in 10g
2942185 9.2.0.6, 10.1.0.4, 10.2.0.1 Corruption occurs on direct path load into IOT with ADDED columns
3085057 10.1.0.2 ORA-600: [25027] from ALTER TABLE .. SHRINK SPACE CASCADE
2926182 9.2.0.5, 10.1.0.2 OERI[25027] / ORA-22922 accessing LOB columns in IOT in AFTER UPDATE trigger

 

【ORACLE数据库恢复】ORA-00600[KCLCHKBLK]

ORA-600: internal error code, arguments: [kclchkblk_3/4]错误的相关症状可能如下:

 

  • 当从备份中restore过数据库并做了一个incomplete recovery不完全恢复时
  • 以resetlogs 选项打开数据库
  • 在打开数据库之后可能遇到以下的错误:
      • ORA-00600 [kclchkblk_4]
        ORA-00600 [2662]
  • 其错误堆栈stack trace 为kclchkblk kcbzib kcbgcur ktfbhget ktftfcload

 

触发该错误的原因是:

 

ORA-600[KCLCHKBLK_4]是由临时文件中的块上的SCN过高引起,  ORA-600[2662]错误也是类似的原因。

该问题可能是由于在OPEN RESETLOGS之后临时文件temporary file没有正确初始化所引起

这个ORA-00600[KCLCHKBLK]中的KCLCHKBLK 代表 check block scn after a disk read

ORA-600 [kclchkblk_3] [a] [b] [c]

The error is reported when the block SCN is less than the last block SCN.
Called by the cache layer after reading a block from disk.

The block SCN is checked to make sure it is not greater than the recent
SCN and not less than the last block SCN seen.

ARGUMENTS:
Arg [a]  Current SCN WRAP
Arg [b]  Current SCN BASE
Arg [c]  Block type

FUNCTIONALITY:
Check Block scn

IMPACT:
MEMORY CORRUPTION
POSSIBLE PHYSICAL CORRUPTION

 

 

 

如果自己搞不定可以找ASKMACLEAN专业ORACLE数据库修复团队成员帮您恢复!

 

已知的一些ORA-00600[KCLCHKBLK3/4]的相关BUG如下:

 

NB Bug Fixed Description
17273253 12.1.0.1.1 Various ORA-600 corruption errors with ASM
14034244 11.2.0.3.BP09, 11.2.0.4, 12.1.0.1 Lost write type corruption using ASM in 11.2.0.3
12718090 11.2.0.3.1, 11.2.0.3.BP02, 11.2.0.4, 12.1.0.1 ORA-600 [kclchkblk_3] can occur in RAC
+ 10425010 11.2.0.3, 12.1.0.1 Stale data blocks may be returned by Exadata FlashCache
* 10205230 11.2.0.1.6, 11.2.0.1.BP09, 11.2.0.2.2, 11.2.0.2.BP04, 11.2.0.3, 12.1.0.1 ORA-600 / corruption possible during shutdown in RAC
10071193 11.2.0.2.BP02, 11.2.0.3, 12.1.0.1 Lost write / ORA-600 [kclchkblk_3] / ORA-600 [3020] in RAC – superceded
+ 8597106 11.2.0.1.BP06, 11.2.0.2, 12.1.0.1 Lost Write in ASM when normal redundancy is used
12905058 11.2.0.3.1, 11.2.0.3.BP02, 11.2.0.4.1, 11.2.0.4.BP02 Rare ASM corruption after disk resync
4767885 10.2.0.1 OERI [kclchkblk_3] possible in RAC
3601253 9.2.0.6, 10.1.0.2 OERI[kclchkblk_3] possible accessing transported tablespace in RAC
2000029 9.0.1.3, 9.2.0.1 OERI:KCLCHKBLK_3 possible in RAC after reconfiguration

 

 

NB Bug Fixed Description
14351566 11.2.0.3.8, 11.2.0.3.BP21, 11.2.0.4, 12.1.0.1 ORA-600 [kclchkblk_4] when doing flash back

 

NB Bug Fixed Description
10112810 11.2.0.3, 12.1.0.1 ORA-600[kjbcrc:g] / ORA-600[kclchkblk_2] / [kjbconvert:modes] With Flash Cache Enabled on RAC
2873045 9.2.0.4, 10.1.0.2 OERI:[KCLCHKBLK_2] possible in RAC

2014年3月21日晚SHOUG上海ORACLE用户组首次线下活动

2014年3月21日晚SHOUG上海ORACLE用户组首次线下活动,本次活动限制名额50人,如欲参建议尽早报名。

具体时间为:2014年3月21日(周五)晚上18~21时

具体地点为: 中国上海市黄浦区天津路155号名人商业大厦12楼Oracle公司内

 

本次SHOUG议题如下:

  1. 刘相兵 – 《介绍SHOUG的组织宗旨》 40分钟左右
  2. 唐涛 – 《介绍ORACLE的大数据解决方案》 40分钟左右
  3. 一号店 柳阳 – 《Exadata在电商的实践》   40分钟左右
  4. 程飞 – 《oracle常见异常恢复处理思路 》 40分钟左右

 

按照国际惯例会后将提供presentation的PDF版本,但不提供会议的视频。

 

下载并填写《SHOUG2014年3月21日活动报名表格》后,请将本报名表格发送到 joinevent@shoug.info,并抄送maclean.liu@shoug.info 和 liu.maclean@gmail.com(避免漏看您的邮件)。

【文档】Maclean介绍Oracle ASM基础概念和原理

【文档】Maclean介绍Oracle ASM基础概念和原理  原帖在这里:http://www.askmaclean.com/archives/know-oracle-asm-basic-html.html

 

asm arch

这里放出PDF版本下载:http://www.askmaclean.com/wp-content/uploads/2014/02/Maclean介绍Oracle-ASM基础概念和原理1.pdf

看图说话:Maclean在Oracle的这一年多所留下的足迹

2012年8月入职,当天领到笔记本,O记发的笔记本都预装了 OBI:

2012-08-13 13.27.39
2012-08-13 13.25.04
2012-08-13 14.02.00

2012-08-13 13.23.19

上海ORACLE的窗外景

 

2012-08-13 13.37.59

Maclean Liu在Oracle的工牌和名片:

2013-09-30 13.09.26

2012-08-17 16.55.13 (1)

在原厂第一次乘高铁出差

2012-08-19 21.55.51

第一次出差南京 下榻在金陵饭店

2012-08-20 18.02.29 (1)

 

第一次签原厂的工单 timesheet:

2012-08-21 14.33.32

ORACLE在上海的OFFICE位于 南京东路,楼下是Apple苹果零售店,公司楼下:

2012-08-24 13.09.24

在原厂第一次加班夜宵:

2012-08-28 20.17.16

在原厂第一次飞机出差,去武汉

2012-09-01 20.33.13

在武汉的现场:

2012-09-03 17.27.44 (1)

武汉出差,住在万达威斯丁:

2012-09-03 19.52.46

2012-09-05 08.09.32

在武汉吃热干面:

2012-09-05 12.04.05

在客户现场忙碌一天,终于回到酒店,累得不想出去吃饭,就在酒店内解决:

2012-11-01 18.52.35

第一次报销贴发票,长期跑现场,导致每次都堆积大量发票,需要一个下午甚至一天来贴发票:

2012-09-10 14.57.16

报销单:

2012-09-10 14.56.46

公司福利下午茶点心:

2012-09-10 15.51.36

开始在ORACLE官方博客blogs.oracle.com 上发大量技术文章:

2012-10-13 21.29.45

工行的数据中心位于外高桥保税区内,哪里还有一个18M的Base:

2012-10-17 12.52.25

这是从公司朝外看 ,南京东路这边在大兴土木

2012-10-26 13.35.35

已经装了一堆的 旅行类IOS APPS:

2012-12-03 09.57.06

在上海电信的楼下发现老电信的基石:

2012-12-05 12.50.48

O记年会:

2013-01-04 17.41.50

2013-01-04 17.50.18

2013-01-04 18.04.17

2013-01-04 18.08.10

2013-01-04 18.08.34

2013-01-04 18.25.27

2013-01-04 18.35.24

叫了一部荣威950送我上班:

2013-01-10 21.02.46

在某银行的指挥中心:这个图还是不放了。。

去南京给客户培训,不爱出差的我是早上6点赶高铁去南京的:

2013-01-19 08.45.35

一等座,在车头的位置:

2013-01-19 08.49.42

住在南京威斯丁:

2013-01-20 07.43.03

2013-01-20 07.47.10

俯瞰玄武湖:

2013-01-20 07.50.57

杭州出差住在 西溪喜来登

2013-01-22 17.53.22

2013-01-22 18.05.05

2013-01-22 18.05.17

赶路时的午餐:

2013-02-01 08.58.11

OFFICE里我的箱子:

2013-02-26 16.46.48

某客户的园区不错,有个水塘 还有天鹅:

2013-03-05 12.08.34

2013-03-05 12.08.46

2013-03-05 12.08.59

旅途中有空就动笔写写,发到blogs.oracle.com , 慢慢积累:

2013-03-20 10.00.55

2013-03-20 10.01.02

有些客户那里不能带进电脑和U盘,只能带手机,记不住的命令就拍照存档:

2013-03-27 14.30.40

杭州的洲际酒店,是个大球:

2013-03-31 18.26.57

2013-03-31 18.32.48

住在洲际,洲际的好处是离开 杭州城站较近:

2013-03-31 19.26.15

杭州那几天太热了,不想吃东西,中午随便解决:

2013-04-01 13.30.19

家里开始大兴园艺:

2013-04-10 14.09.39

2013-04-10 14.09.49

2013-04-21 13.10.26-2

2013-05-05 17.06.52

工行数据中心的绿化还是不错的:

2013-05-23 08.07.58

在工行吃个午饭不容易:

2013-04-19 12.29.48

2013-09-29 12.10.15

家里看看Exadata的文档:

2013-05-05 19.39.53

2013年之后太忙了,偶尔才回一次公司:

2013-05-22 13.37.31

2013-05-22 17.39.18

某用户的Exadata IO高到了7.5GB/s

2013-06-01 09.56.40

2013-06-01 15.03.04

参加在大连的ACS高级服务研讨会,我讲了下ADDM DBA:

2013-06-21 08.57.24

大连的凯宾斯基饭店:

2013-06-21 13.16.39

在南京讲课, 中午顺道去软件大道上华为的基地蹭饭:

2013-06-26 11.55.59

饭菜还是不错的哦!

2013-06-26 12.01.31

正处理一个故障呢!日志拷不了,只能拍照看

2013-06-30 00.17.20

湖光鱼影:

2013-07-04 16.05.30

池中鱼蛙:

2013-09-03 11.51.52

家里的台式机升级到 4* 8GB 内存:

2013-08-07 19.51.06

家里的实验用机:

2013-08-07 20.36.02

在杭州吃蟹火锅:

2013-08-13 18.17.45

客户那里发现的自学光盘:

2013-10-24 13.54.13

这个是去普吉岛旅游,我在一个小岛的码头上,我的普吉岛游记 见http://www.askmaclean.com/archives/%E6%99%AE%E5%90%89%E5%B2%9B%E5%8F%8Ako-yao-yai%E6%B8%B8%E8%AE%B0.html:

2013-06-14 10.47.38