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

附件为临时的ParnassusData Recovery Manager For Oracle白皮书(Version 0.1),这个白皮书还在完善中,你可以把它当做一个临时的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

【转】为什么互联网公司都在开曼群岛注册?

开曼群岛

 

本文来自《创业最前线》

开曼群岛(Cayman Islands)是英国在西印度群岛的一块海外属地,由大开曼、小开曼和开曼布拉克3个岛屿组成。开曼群岛是世界第四大离岸金融中心,并是著名的潜水胜地。(Wiki)

其它知名的离岸金融中心包括英属维尔京群岛、萨摩亚、香港、关岛等。离岸公司是指并不在注册地进行实质业务的公司。当地政府对这类公司没有任何税收,只收取少量的年度管理费,具有高度的保密性、减免税务负担、无外汇管制三大特点。

根据开曼群岛的税收规定,岛内税种只有进口税、工商登记税、旅游者税等几个简单的税种。几十年来没有开征过个人所得税、公司所得税、资本利得税、不动产税。这样,国内互联网公司选择设立立案公司的原因就呼之欲出了。

以下的内容来自张珂在知乎对这一问题的回答,详细解读了互联网公司在开曼群岛注册(设立离岸公司)的优势,给正在创业路上的你参考。

不仅仅是互联网公司,绝大多数知道开曼群岛这个地方的都会把公司注册在这儿。主要是它的政策太诱人了:

1.任何国籍年满18岁的人都可以注册;

2.注册股本只要50,000美元,且不需要验资(这可能是互联网公司注册开曼的原因,大家刚起步时都太小);

3.采用的是英式普法,公司形式是豁免公司;

4.豁免公司意味着不用在当地交税,避税效果巨强;

5.并且股东资料绝对保密;

6.还不用在开曼举行周年股东大会;

7.所有能想象到的金融服务业大佬全在开曼,有需要的时候不受其它繁琐政策限制(这意味着你在内地开公司你的公司账户也不用跨国,直接在这些大佬的分行运行);

8.开公司只需要一位股东、一位董事,且股东董事可同为一人(干,我都心动了);

9.可以选择任何词汇在你的公司名称里面(但信托、再保险等要申请),像大学、研究所还有国内受限制的环球、联邦等都可以用;

10.除了对银行、保险、军事等需申请外,公司用途无限制,你想干什么干什么;

11.在国内你享受的是外资待遇,且注册成功后直接可以投资(比如控股、合资、独资);

12.刚做起来没做好扛不住了需要暂停公司也巨方便,开曼允许随时暂停公司,只要交年报费和年审费。