Oracle数据恢复、数据库恢复、灾难恢复

เครื่องมือการกู้คืนภัยพิบัติของออราเคิลเฉพาะ PRM-Dul

2014/05/19 by admin Leave a Comment

เครื่องมือการกู้คืนภัยพิบัติของออราเคิลเฉพาะ PRM-Dul
ParnassusData Recovery Manager (ต่อไปนี้จะเรียกว่า PRM) ORACLE ข้อมูลระดับองค์กรซอฟต์แวร์กู้คืนภัยพิบัติการกู้คืนข้อมูลสามารถสกัดโดยตรงจากตารางข้อมูลใน Oracle 9i, 10g, 11g, 12c แฟ้มข้อมูลฐานข้อมูล (แฟ้มข้อมูล) โดยไม่จำเป็นต้องฐานข้อมูล Oracle ดำเนินการเช่น SQL ในการบันทึกข้อมูล ParnassusData Recovery Manager คือการพัฒนา JAVA ที่ใช้ซอฟแวร์สีเขียวติดตั้งไม่สามารถนำมาใช้โดยตรงหลังจากดาวน์โหลดตัวแปลงสัญญาณ

อินเตอร์เฟซการใช้งาน PRM GUI แบบกราฟิก (รูปที่ 1) ที่ง่ายและสะดวก ผู้ใช้ไม่จำเป็นต้องเรียนรู้ชุดของคำสั่งเพิ่มเติมหรือเพื่อเข้าใจหลักการพื้นฐานโครงสร้างข้อมูลที่สามารถใช้ในการกู้คืนข้อมูล ORACLE ในฐานข้อมูลผ่านตัวช่วยสร้างการกู้ภัย (คืน Wizard)
รูปภาพแต่งตั้ง 1

ทำไมต้องใช้ PRM?
เป็นประเพณีนี้ ORACLE ใช้ RMAN คืนการสำรองข้อมูลและการกู้คืนผู้จัดการเพียงพอหรือไม่ ทำไมเลือกที่จะซื้อผู้ใช้ PRM ต้องหรือไม่ หัวใจของคุณอาจจะยังมีข้อสงสัยดังกล่าว!

ที่เพิ่มขึ้นในระบบไอทีขององค์กรความจุข้อมูลที่มีการขยายทางเรขาคณิต ของ Oracle DBA เพื่อความสมบูรณ์ของข้อมูลในเรื่องที่จะหันความจุระบบจัดเก็บข้อมูลบนดิสก์ที่มีอยู่ไม่เพียงพอที่จะเก็บสำรองข้อมูลเต็มรูปแบบเทปสำรองข้อมูลเพื่อเรียกคืนข้อมูลเมื่อมีปัญหาเกิดขึ้นจริงมักจะต้องไปไกลกว่าระยะเวลาการซ่อมแซมเฉลี่ยที่คาดว่าจะ

“สำหรับวัตถุประสงค์ของฐานข้อมูลการสำรองข้อมูลเป็นสิ่งที่สำคัญมากกว่าทุกอย่าง” เป็นคำขวัญของหัวใจ DBA ในใจ แต่ความเป็นจริงเป็นอย่างมากมายสภาพแวดล้อมที่แตกต่างกันการขาดของพื้นที่สำรองฐานข้อมูลขององค์กรอุปกรณ์การจัดเก็บข้อมูลสภาพแวดล้อมที่ไม่สามารถมาซื้อระยะสั้นแม้ดำเนินการ สำรอง แต่ก็พบว่าการสำรองข้อมูลการกู้คืนข้อมูลที่เกิดขึ้นจริงและปัญหาอื่น ๆ ที่มีสถานการณ์ทั่วไปสามารถใช้งานได้

ในการตอบสนองเหล่านี้จริงในโลกขึ้นเขียงการกู้คืนข้อมูลที่พบบทกวี PRM ตาลซอฟต์แวร์การจัดการการกู้คืนข้อมูลในการเล่นอย่างเต็มที่ข้อมูลภายในโครงสร้างของฐานข้อมูลของออราเคิลเริ่มต้นกระบวนการเช่นความเข้าใจแกนภายในของหลักการที่สามารถรับมือภายใต้ตารางสถานการณ์ระบบการสำรองข้อมูล การสูญเสียพื้นที่ในทางที่ผิด ORACLE ตารางข้อมูลพจนานุกรมเนื่องจากกระแสไฟฟ้าขัดข้องที่เกิดจากฐานข้อมูลพจนานุกรมไม่สอดคล้องไม่สามารถประสบความสำเร็จเปิดฉากที่คุณสามารถเรียกคืนตัดทอนผิดพลาด (ตัดทอน) / ลบ (ลบ) / ตารางข้อมูลทางธุรกิจและการใช้ผิดวัตถุประสงค์ของมนุษย์อื่น ๆ และ ข้อมูลการเรียกคืนความสงบ
แม้เพียงไม่กี่วันของการติดต่อกับไม่ ORACLE พนักงานฐานข้อมูล DBA ยังสามารถใช้ PRM ขอบคุณ PRM ติดตั้งง่ายและอินเตอร์เฟซแบบโต้ตอบเต็มกราฟิกบุคลากรในการดำเนินการกู้คืนไม่จำเป็นต้องมีฐานข้อมูลความรู้เฉพาะ ไม่จำเป็นต้องเรียนรู้คำสั่งใด ๆ แต่ไม่เข้าใจโครงสร้างการจัดเก็บฐานข้อมูลที่อยู่ภายใต้ เพียงแค่ต้องคลิกเมาส์เพียงไม่กี่คุณสบายสามารถกู้คืนข้อมูล

เมื่อเทียบกับเครื่องมือการกู้คืนแบบดั้งเดิม DUL, DUL เป็น ORACLE เดิมเครื่องมือการกู้คืนภายในการใช้งานของพวกเขาต้องการที่จะ ORACLE กระบวนการภายในโดยทั่วไปเพียงซื้อเดิม ORACLE ผู้ใช้บริการภาคสนามสามารถใช้เครื่องมือด้วยความช่วยเหลือของวิศวกรเดิม PRM ยากจนเพียงไม่กี่ผู้เชี่ยวชาญในการดำเนินการ จำกัด งานการกู้คืนฐานข้อมูลอย่างมากลดความล้มเหลวที่สมบูรณ์ในการกู้คืนข้อมูลจากความล้มเหลวเป็นครั้งที่ฐานข้อมูลการลดค่าใช้จ่ายทั้งหมดขององค์กรการกู้คืนข้อมูล
การกู้คืนข้อมูล PRM สามารถแบ่งออกเป็นสองชนิดวิธีการสกัดแบบดั้งเดิมคือแฟ้มข้อมูลที่สมบูรณ์จากข้อมูลที่สกัดและการเขียนไปยังแฟ้มข้อความแบนแล้วใช้เครื่องมือ sqlldr เช่นโหลดแล้วลงในฐานข้อมูล วิธีการดั้งเดิมที่จะเข้าใจง่าย แต่อุปสรรคที่ไม่จำเป็นต้องสองครั้งข้อมูลความจุของพื้นที่ที่มีอยู่: พื้นที่ครอบครองโดยข้อมูลข้อความแบนแล้วนำเข้าข้อมูลข้อความลงในพื้นที่ฐานข้อมูลครอบครองไม่จำเป็นในช่วงเวลาเดิม หลังจากที่ข้อมูลจะถูกสกัดจากแฟ้มข้อมูลก่อนที่จะถูกนำเข้ามาในฐานข้อมูลใหม่ที่พวกเขามักจะต้องมีครั้งที่สองอีกต่อไป
บทกวีตาลก็ขอแนะนำให้คุณใช้วิธีการเดิม PRM ข้อมูลข้ามคือโดย PRM จะถูกสกัดโดยตรงจากข้อมูลที่โหลดลงในฐานข้อมูลที่มีอยู่ใหม่หรืออื่น ๆ จึงหลีกเลี่ยงการจัดเก็บข้อมูลเชื่อมโยงไปถึงเมื่อเทียบกับวิธีการดั้งเดิมของการประหยัด พื้นที่การกู้คืนข้อมูลและเวลาที่ค่าใช้จ่ายที่จำเป็น

เทคโนโลยีการจัดการการจัดเก็บข้อมูล ASM อัตโนมัติของออราเคิลจะถูกมากขึ้นและผู้ประกอบการมากขึ้นนำมาใช้ฐานข้อมูลโดยใช้การจัดเก็บ ASM เมื่อเทียบกับระบบไฟล์แบบดั้งเดิมที่มีประสิทธิภาพสูงคลัสเตอร์การจัดการที่ง่ายและประโยชน์อื่น ๆ แต่ปัญหา ASM เป็นที่สำหรับโครงสร้างการจัดเก็บ ASM ผู้ใช้โดยเฉลี่ยเป็นกล่องสีดำเกินไปเมื่อ ASM ในโครงสร้างข้อมูลภายในกลุ่มดิสก์ได้รับความเสียหายที่เกิดดิสก์กลุ่มไม่สามารถที่จะประสบความสำเร็จใน MOUNT ก็หมายความว่าผู้ใช้เป็นสิ่งที่สำคัญ ข้อมูล ASM ถูกขังอยู่ในกล่องสีดำนี้ใน หลังจากฉากนี้มักจะต้องมี ORACLE ASM คุ้นเคยเดิมโครงสร้างข้อมูลภายในของวิศวกรอาวุโสเข้าถึงผู้ใช้ซ่อมแซมบนเว็บไซต์ของโครงสร้างภายในของ ASM ตนเองซื้อ ORACLE บริการเว็บไซต์เดิมสำหรับผู้ใช้สามัญดูเหมือนแพงและใช้เวลานาน
R & D บุคลากร PRM-based (อดีต ORACLE วิศวกรอาวุโส) ใน Oracle ASM เข้าใจเชิงลึกของโครงสร้างข้อมูลภายใน PRM เพิ่มคุณสมบัติการกู้คืนข้อมูลพิเศษสำหรับ ASM

PRM คุณสมบัติการกู้คืนข้อมูลที่ ASM รับการสนับสนุนในปัจจุบัน ได้แก่

1 แม้ดิสก์กลุ่มไม่สามารถเป็นปกติ MOUNT ยังคงสามารถอ่านข้อมูลที่มีอยู่ในข้อมูลดิสก์ ASM โดยตรงผ่าน PRM และอยู่บนพื้นฐานของข้อมูลนี้จะถูกคัดลอกออกมาจากกลุ่มดิสก์ในแฟ้ม ASM

2 แม้ดิสก์กลุ่มไม่สามารถเป็นปกติ MOUNT ยังคงสามารถอ่านได้โดยตรงโดยแฟ้มข้อมูล PRM ที่ ASM และดึงข้อมูลที่สนับสนุนวิธีการสกัดแบบดั้งเดิมและโหมดบายพาสข้อมูล
ซอฟท์แว PRM
ParnassusData Recovery Manager (PRM) การพัฒนา JAVA-based ซึ่งทำให้มั่นใจ PRM สามารถทำงานข้ามแพลตฟอร์มไม่ว่าจะเป็นบน AIX, Solaris, HPUX และแพลตฟอร์มอื่น ๆ Unix, Redhat ออราเคิล Linux, SUSE และแพลตฟอร์มอื่น ๆ ลินุกซ์หรือ Windows แพลตฟอร์มสามารถเรียกใช้ PRM โดยตรง

PRM-DUL ดาวน์โหลด ：http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip

PRM-DUL เอกสารภาษาอังกฤษ : http://www.parnassusdata.com/sites/default/files/ParnassusData%20Recovery%20Manager%20For%20Oracle%20Database%20User%20Guide%20V0.3.pdf

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

ORACLE専用データ復旧ソフトウェア　PRM DUL

2014/05/15 by admin Leave a Comment

ORACLE専用データ復旧ソフトウェア　PRM DUL

世界市場のトップシェアを占めるORACLE DB
だから本当に信頼できる復旧ツールを使いたい
PRM-DUL は、ParnassusDataが開発した法人サーバーORACLEデータベースの専用復旧ツールです。
ORACLEデータベースを正常にオープンできない場合やマウントできない場合、データベースが損傷した場合等にオラクルデータベースファイル(～.dbf)を直接読み込むことによって、ファイルから有効なデータを抽出するツールです。
PRM-DUL、無料お見積もり?お問い合わせ
ORACLE専用データ復旧ソフトウェア　PRM-DUL　製品紹介
ParnassusDataが独自開発したオラクルDB復旧専用ソフトウェアPRM-DULについて、本ページでは以下「Oracle DUlの特徴」「使用例作業手順」「動作環境」の3点をご案内致します。
ORACLE復旧サービスの特徴 ORACLEデータベース障害事例 ORACLEデータベースBackupと復旧方法
ORACLEデータベースの専用復旧ツール　PRM-DULの特徴
ハードディスクなどに有効なバックアップが無く、DBがオープンできない場合や、Hidden parameterを使用してDBをオープンしたにも関わらず、「internal code error」が発生してデータを抽出できない場合などにPRM-DULを使用すると、迅速、安全、確実にデータを抽出することが可能です。
このような障害時にPRM-DULの威力が発揮します。
障害事例1データセグメントヘッダーブロックが損傷して、データを抽出できない場合
索引やアドレスなど一般的なブロック（※ORACLEが定義する最小レベルデータの総称）が格納されるヘッダーのブロック領域が損傷してしまうと、データ抽出不具合などの障害が発生します。
PRM-DULでは独自技術で開発された8個のAPIレイヤーが損傷領域の代替DBを作成することで正常にデータ抽出させることが可能となります。詳しくは下の「8つのAPIレイヤー図」をご参照ください。
障害事例2システムテーブルスペースが損傷して、DBがオープンできない場合
何らかの理由によりシステム上のテーブルスペース（TABLESPACE＝表領域）が破損?損傷してしまうと、各種コマンドを入力してもデータベースがオープンできないという障害が発生します。
この場合もPRM-DULのAPIレイヤーが生成したカタログDB経由で復旧したいデータファイルからDBの読み込みをおこなうことで、データベースをオープンさせ、データを抽出することが可能となります。詳しくは下の「8つのAPIレイヤー図」をご参照ください。
障害事例3損傷したデータブロックを除外した正常なデータブロックのデータを抽出したい場合
通常はデータブロックが損傷してしまうと、エクステントやセグメントそのものがオープンできないため正常ブロックのみの抽出は叶いませんが、PRM-DULは独自技術により復旧したいデータファイルを読み込み、カタログDBという代替領域を生成することが可能なので、損傷データブロックを除いた、正常データブロックのみの抽出をおこなうことができます。
障害事例4その他、何らかの原因でデータを正常に抽出できない場合
上記の場合以外にも、様々な要因でデータベースからデータが正常に抽出できないケースがございますが、Parnassusdataが自社開発したPRM-DULは、そのような状態からもデータ抽出させることが可能です。
8つのAPIレイヤーで確実なデータ復旧
PRM-DULでは上記のような障害に対して8つのAPIレイヤーを用いて対応します。
8つのAPIレイヤーで確実なデータ復旧
PRM-DUL
1. 復旧したいデータファイルから、カタログ情報を抽出
PRM-DULの大きな特徴として、ヘッダー領域や表領域、行領域の一部などORACLEデータベースの中のブロックが損傷してもデータファイルそのものへ直接アクセスし、ファイル中のカタログ情報を自動で抽出する機能を搭載している点にあります。
2. 抽出したカタログ情報を利用して、カタログDBの作成
上記でデータファイルから抽出したカタログ情報を独自の技術によってカタログDBとして生成（再構成）します。このカタログDBを用いることによって障害発生時でもデータ抽出することが可能となります。
3. カタログDBの情報の読み込み
PRM-DULは生成したCatalog DBの情報を読み込むことで、復旧を希望するデータファイルのORACLE DB本体からのデータ抽出準備をおこないます。
4. 復旧したいデータファイルからDBを読み込み、データ抽出
PRM-DULが提供する８つのAPIレイヤーを用いて復旧したいデータファイルからオラクルデータベース読込を実行し、データを抽出します。
5. 抽出したデータをテキストファイルで保存
抽出したデータをテキストファイルで保存し外部メディアなどへ移動します。

PRM-DUL download: http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip

PRM-DUL User Guide(English):http://www.parnassusdata.com/sites/default/files/ParnassusData%20Recovery%20Manager%20For%20Oracle%20Database%20User%20Guide%20V0.3.pdf

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

DROP TABLE的Oracle数据恢复 PRM-DUL

2014/05/06 by admin Leave a Comment

D公司的应用开发人员在ASM存储环境下，在没有任何备份的情况下DROP了系统中一张核心应用表，此时第一时间采用PRM可以恢复该DROP掉数据表的绝大部分数据。10g以后提供了 recyclebin回收站特性，可以首先通过查询DBA_RECYCLEBINS视图来确定被DROP掉的表是否在回收站中，如果在则优先通过回收站flashback to before drop，如果回收站中也没有了，则第一时间使用PRM恢复。

恢复简要流程如下：

首先将被DROP掉的数据表所在的表空间OFFLINE
通过查询数据字典或者LOGMINER找到被DROP掉数据表的DATA_OBJECT_ID，如果此步骤中得不到这个DATA_OBJECT_ID，则需要在NON-DICT非字典模式下
启动PRM，进入NON-DICT非字典模式，并加入被DROP掉数据表所在的表空间的所有数据文件，之后SCAN DATABASE+SCAN TABLE from Extent MAP
通过DATA_OBJECT_ID定位到展开对象树形图中对应的数据表，采用DataBridge模式插回到源数据库中

SQL> select count(*) from "MACLEAN"."TORDERDETAIL_HIS"; 

  COUNT(*)
----------
    984359

SQL> 
SQL> create table maclean.TORDERDETAIL_HIS1 as select * from  maclean.TORDERDETAIL_HIS;

Table created.

SQL> drop table maclean.TORDERDETAIL_HIS;

Table dropped.

可以通过logminer或者《恢复场景9》中提供的方法得到大致的DATA_OBJECT_ID，使用LOGMINER则大致的脚本如下：

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME => '/oracle/logs/log1.f', OPTIONS => DBMS_LOGMNR.NEW);

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME => '/oracle/logs/log2.f', OPTIONS => DBMS_LOGMNR.ADDFILE);

Execute DBMS_LOGMNR.START_LOGMNR(DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG+DBMS_LOGMNR.COMMITTED_DATA_ONLY);

SELECT * FROM V$LOGMNR_CONTENTS ;

EXECUTE DBMS_LOGMNR.END_LOGMNR;

即便这里得不到DATA_OBJECT_ID，在数据表不多的情况下还是可以通过人工识别数据来定位我们需要恢复的数据表。

首先将被DROP掉的数据表所在的表空间OFFLINE

SQL> select tablespace_name from dba_segments where segment_name='TPAYMENT';

TABLESPACE_NAME
------------------------------
USERS

SQL> select file_name from dba_data_files where tablespace_name='USERS';

FILE_NAME
----------------------------------------------------------------
+DATA1/parnassus/datafile/users.263.843694795

SQL> alter tablespace users offline;

Tablespace altered.

启动PRM到NON-DICT模式，并加入对应的数据文件选择SCAN DATABASE+SCAN TABLE From Extents:

prm-dul-drop-table1

由于是在非字典模式下所有需要输入必要的字符集信息：

选择被DROP掉的表所在的数据文件即可，多余的数据文件可不选择，并点击SCAN：

点中生成的数据库名，并右键选择scan tables from extents:

prm-dul-drop-table6

通过人工识别发现DATA_OBJECT_ID=82641的数据对应于被DROP掉的TORDERDETAIL_HIS表，通过DataBridge技术将其传输回源库别的表空间中。

prm-dul-drop-table10

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复 Tagged With: drop table, dul, PRM-DUL

ORA-01194 ORA-01547 ORA-01110 DATAFILE NEEDS MORE RECOVERY TO BE CONSISTENT错误解析

2014/04/25 by admin 3 Comments

ORA-1194 "file %s needs more recovery to be consistent"
ORA-1547 "warning: RECOVER succeeded but OPEN RESETLOGS would get error below"
ORA-1110 "data file %s: '%s'"

?

[oracle@mlab2 ~]$ oerr ora 1194
01194, 00000, "file %s needs more recovery to be consistent"
// *Cause: An incomplete recovery session was started, but an insufficient
// number of logs were applied to make the file consistent. The
// reported file was not closed cleanly when it was last opened by
// the database. It must be recovered to a time when it was not being
// updated. The most likely cause of this error is forgetting to
// restore the file from a backup before doing incomplete recovery.
// *Action: Either apply more logs until the file is consistent or restore
// the file from an older backup and repeat recovery.


[oracle@mlab2 ~]$ oerr ora 1547
01547, 00000, "warning: RECOVER succeeded but OPEN RESETLOGS would get error below"
// *Cause: Media recovery with one of the incomplete recovery options ended
//        without error.  However, if the ALTER DATABASE OPEN RESETLOGS command
//        were attempted now, it would fail with the specified error.
//        The most likely cause of this error is forgetting to restore one or
//        more datafiles from a sufficiently old backup before executing the
//        incomplete recovery.
// *Action: Rerun the incomplete media recovery using different datafile
//         backups, a different control file, or different stop criteria.



[oracle@mlab2 ~]$ oerr ora 1110
01110, 00000, "data file %s: '%s'"
// *Cause:  Reporting file name for details of another error. The reported
//          name can be of the old file if a data file move operation is
//          in progress.
// *Action: See associated error message.

假设所有的oracle数据文件均成功restore并recovery，但打开数据库时仍报错，那么

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: ‘/system01.dbf’

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

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

场景1：当前的控制文件可用

保证实例正常mount且所有的数据文件ONLINE，那么执行：

select name, controlfile_type from v$database ;

NAME CONTROL
——— ——-
ORCL?CURRENT

SQL> recover automatic database ;
..
Media recovery complete
SQL> alter database open

场景2 此次恢复中使用的是备份的控制文件

select name, controlfile_type from v$database ;

NAME CONTROL
--------- -------
ORCL BACKUP -- controlfile_type is "Backup" Controlfile

 

SQL> select status,
2 resetlogs_change#,
3 resetlogs_time,
4 checkpoint_change#,
5 to_char(checkpoint_time, 'DD-MON-YYYY HH24:MI:SS') as checkpoint_time,
6 count(*)
7 from v$datafile_header
8 group by status, resetlogs_change#, resetlogs_time, checkpoint_change#, checkpoint_time
9 order by status, checkpoint_change#, checkpoint_time ;
STATUS RESETLOGS_CHANGE# RESETLOGS_TIME CHECKPOINT_CHANGE# CHECKPOINT_TIME COUNT(*)
------- ----------------- -------------------- ------------------ -------------------- ----------
ONLINE 995548 15-FEB-2012:17:17:20 2446300 13-FEB-2013 15:09:44 1 -- Datafile(s) are at different checkpoint_change#
(scn), so not consistent
ONLINE 995548 15-FEB-2012:17:17:20 2472049 13-FEB-2013 16:02:22 6
SQL>
SQL>
SQL> -- Check for datafile status, and fuzziness
SQL> select STATUS, ERROR, FUZZY, count(*) from v$datafile_header group by STATUS, ERROR, FUZZY ;
STATUS ERROR FUZ COUNT(*)
------- ----------------------------------------------------------------- --- ----------
ONLINE YES 7
SQL>
SQL>
SQL> -- Check for MIN, and MAX SCN in Datafiles
SQL> select min(CHECKPOINT_CHANGE#), max(CHECKPOINT_CHANGE#) from v$datafile_header ;
MIN(CHECKPOINT_CHANGE#) MAX(CHECKPOINT_CHANGE#)
----------------------- -----------------------
2446300 2472049
SQL>
SQL> select substr(L.GROUP#,1,6) GROUP#
2 ,substr(L.THREAD#,1,7) THREAD#
3 ,substr(L.SEQUENCE#,1,10) SEQUENCE#
4 ,substr(L.MEMBERS,1,7) MEMBERS
5 ,substr(L.ARCHIVED,1,8) ARCHIVED
6 ,substr(L.STATUS,1,10) STATUS
7 ,substr(L.FIRST_CHANGE#,1,16) FIRST_CHANGE#
8 ,substr(LF.member,1,60) REDO_LOGFILE
9 from GV$LOG L, GV$LOGFILE LF
10 where L.GROUP# = LF.GROUP# ;
GROUP# THREAD# SEQUENCE# MEMBERS ARC STATUS FIRST_CHANGE# REDO_LOGFILE
------ ------- ---------- ------- --- ---------- ---------------- ------------------------------------------------------------
1 1 454 1 NO CURRENT 2471963 /u01/app/oracle/oradata/ORCL/redo01.log <-- This is CURRENT log containing most
recent redo, and is available
3 1 453 1 YES INACTIVE 2471714 /u01/app/oracle/oradata/ORCL/redo03.log
2 1 452 1 YES INACTIVE 2451698 /u01/app/oracle/oradata/ORCL/redo02.log
SQL>
-- Use MIN(CHECKPOINT_CHANGE#) 2446300 as found before, then use it with this query to find the
-- first SEQ# 'number' and archivelog file needed for recover to start with.
-- All SEQ# up to the online Current Redolog SEQ# must be available without any gap for successful recovery
-- MIN(CHECKPOINT_CHANGE#) 2446300
SQL> select thread#, sequence#, substr(name,1,80) from v$Archived_log
where 2446300 between first_change# and next_change#;
THREAD# SEQUENCE# SUBSTR(NAME,1,80)
---------- ---------- --------------------------------------------------------------------------------
1 449 /u01/app/oracle/oradata/ORCL/arch1/arch_1_449_775329440.arc
1 449 /u01/app/oracle/fra/ORCL/archivelog/2013_02_13/o1_mf_1_449_8kq7oc6y_.arc
1 450 /u01/app/oracle/oradata/ORCL/arch1/arch_1_450_775329440.arc
1 450 /u01/app/oracle/fra/ORCL/archivelog/2013_02_13/o1_mf_1_450_8kqbn929_.arc
SQL>
SQL> select * from v$recover_file ; -- Checking for Datafile(s) which needs recovery
FILE# ONLINE ONLINE_ ERROR CHANGE# TIME
---------- ------- ------- ----------------------------------------------------------------- ---------- --------------------
6 ONLINE ONLINE 2446300 13-FEB-2013:15:09:44

 

 

 

SQL> select name, controlfile_type from v$database ;
NAME CONTROL
--------- -------
ORCL BACKUP
SQL>

 

#451
ORA-00278: log file '/u01/app/oracle/fra/ORCL/archivelog/2013_02_13/o1_mf_1_450_8kqbn929_.arc' no longer needed for this recovery
...
< all required logs applied >
...
ORA-00279: change 2471963 generated at 02/13/2013 16:02:19 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fra/ORCL/archivelog/2013_02_13/o1_mf_1_454_%u_.arc
ORA-00280: change 2471963 for thread 1 is in sequence #454
ORA-00278: log file '/u01/app/oracle/fra/ORCL/archivelog/2013_02_13/o1_mf_1_453_8kqbqvrk_.arc' no longer needed for this recovery <-- All
Redo, up to and including SEQ# 453 is applied
ORA-00308: cannot open archived log '/u01/app/oracle/fra/ORCL/archivelog/2013_02_13/o1_mf_1_454_%u_.arc' <<<-- "SEQ# 454" requested,
which is in ONLINE REDOLOG as seen before
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/u01/app/oracle/oradata/ORCL/system01.dbf'
SQL>
SQL> select * from v$recover_file ;
FILE# ONLINE ONLINE_ ERROR CHANGE# TIME
---------- ------- ------- ----------------------------------------------------------------- ---------- --------------------
6 ONLINE ONLINE 2471963 13-FEB-2013:16:02:19
SQL>
SQL> alter database open resetlogs ;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/u01/app/oracle/oradata/ORCL/system01.dbf'
SQL>

 

 

SQL> select min(FHSCN) "LOW FILEHDR SCN"
, max(FHSCN) "MAX FILEHDR SCN"
, max(FHAFS) "Min PITR ABSSCN"
from X$KCVFH ;
LOW FILEHDR SCN MAX FILEHDR SCN Min PITR ABSSCN
---------------- ---------------- ----------------
2446300 2472049 0
-- Example output explained:
--
-- "LOW FILEHDR SCN" - this is the SCN at which recovery process starts
-- "MAX FILEHDR SCN" - this is the SCN we must recover to to get all datafiles consistent
--
-- IF "Min PITR ABSSCN" != 0 AND > "MAX FILEHDR SCN"
-- THEN "Min PITR ABSSCN" is the SCN we must recover to to get all datafiles consistent
ABSSCN = Absolute SCN

 

SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL ;
.
ORA-00279: change 2471963 generated at 02/13/2013 16:02:19 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fra/ORCL/archivelog/2013_02_13/o1_mf_1_454_%u_.arc
ORA-00280: change 2471963 for thread 1 is in sequence #454
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
'/u01/app/oracle/oradata/ORCL/redo01.log' <-- specify the online redologfile having SEQ# 454 to be manually applied
Log applied.
Media recovery complete.
SQL> alter database open resetlogs ;
Database altered.
SQL>
Note:

 

If after applying all archive logs and online redo logs the database does not open
please provide the following script output to Oracle support to assist with the recovery.
( Please upload spooled file: recovery_info.txt )
SQL> set pagesize 20000
set linesize 180
set pause off
set serveroutput on
set feedback on
set echo on
set numformat 999999999999999
Spool recovery_info.txt
select substr(name, 1, 50), status from v$datafile;
select substr(name,1,40), recover, fuzzy, checkpoint_change# from v$datafile_header;
select GROUP#,substr(member,1,60) from v$logfile;
select * from v$recover_file;
select distinct status from v$backup;
select hxfil FILENUMBER, fhsta STATUS, fhscn SCN, FHAFS ABSSCN , fhrba_Seq SEQUENCE from x$kcvfh;
select distinct (fuzzy) from v$datafile_header;
spool off
exit;

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Oracle闪回功能flashback详解

2014/04/25 by admin 1 Comment

特性	应用场景	基于	数据使用	对象	摘要	功能类别	参数
FlashbackDatabase闪回数据库	使整个数据库实际回退到某个时间点	快速恢复区	闪回日志和归档日志	数据库	脱机操作，需要预配置和资源	恢复	Flashback database；还原点、SCN、Timestamp
FlashbackTable闪回表	以表为单位，回到某个时间点	UNDO	UNDO数据	Table	数据库在线操作，业务可能需要暂停。	恢复	还原点、SCN、Timestamp
Flashback Drop闪回drop	挽救回已经被DROP但还在RECYCLEBIN中的表	RECYCLEBIN	RECYCLEBIN	Table	对无误drop表的恢复	恢复	指定表名
FlashbackVersion Query闪回版本查询	可参考的过去改变的历史	UNDO	UNDO数据	行	变更历史的参考	参照	SCN TIMESTAMP
FlashbackTransactionQuery闪回事务查询	获得某次交易对应的撤销SQL语句	UNDO	UNDO数据和supplemental log补充日志	行	FLASHBACK_TRANSACTION_QUERY	参照	XID
FlashbackTransaction闪回事务	用于回退特定事务处理及其所有相关事务处理的逻辑恢复选项；反转事务和所有后续的冲突事务	UNDO	UNDO_SQLUNDO数据和supplemental log补充日志	行	比费力的手动方法更快、更容易	恢复	XIDUNDO_SQL
FlashbackQuery 闪回查询	观察到表上不久的过去的数据	UNDO	UNDO数据	Table	过去数据的参考	参照	SCNTIMESTAMP
FlashbackData Archive闪回数据归档	观察到表上很久（月-年）过去的数据访问任何时间点的数据而不会更改当前数据	FDA表空间	历史数据表，但其本质仍来源于UNDO数据	Table	联机操作，启用跟踪，使用最少的资源	参照	SCN TIMESTAMP

Flashback Data Archive的内部行为

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

【Oracle数据恢复】ORA-00283错误一例

2014/04/25 by admin Leave a Comment

存储无法访问导致数据库异常宕机,重起数据库无法启动

数据库可以mount,但是无法启动,发现文件3(sysaux01.dbf)损坏,需要介质恢复,因为设置为noarhivelog模式,没有数据库的备份,无法正常恢复。

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

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

SQL> alter database open;

alter database open

ERROR at line 1:

ORA-01172: recovery of thread 1 stuck at block 131977 of file 3

ORA-01151: use media recovery to recover block, restore backup if needed

SQL> recover datafile 3 ;

ORA-00283: recovery session canceled due to errors

ORA-12801: error signaled in parallel query server P003

ORA-10562: Error occurred while applying redo to data block (file# 3, block#

37292)

ORA-10564: tablespace SYSAUX

ORA-01110: data file 3: ‘/opt/ora

[oracle@mlab2 ~]$ oerr ora 283
00283, 00000, “recovery session canceled due to errors”
// *Cause: An error during recovery was determined to be fatal enough to end
// the current recovery session.
// *Action: More specific messages will accompany this message. Refer to
// the other messages for the appropriate action.

尝试通过allow 1 corruption忽略坏块，但是部分块无法跳过。

SQL> recover database allow 1 corruption;

ORA-00283: recovery session canceled due to errors

ORA-10562: Error occurred while applying redo to data block (file# 3, block#

37292)

ORA-10564: tablespace SYSAUX

ORA-01110: data file 3: ‘/opt/oracle/oradata/monitor/sysaux01.dbf’

ORA-10560: block type ‘0’

ORA-00600: internal error code, arguments: [4553], [2], [0], [], [], [], [], []

通过DBV工具进行检查，只发现sysaux表空间有损坏，system及其它表空间正常。

和客户沟通，将sysaux01.dbf数据文件offline，先将数据库open，然后将数据进行逻辑备份，重建数据库，通过逻辑备份将数据恢复。

和客户沟通，将sysaux01.dbf数据文件offline，先将数据库open，然后将数据进行逻辑备份，重建数据库，将数据恢复。

SQL> alter database open;

alter database open

ERROR at line 1:

ORA-01172: recovery of thread 1 stuck at block 131977 of file 3

ORA-01151: use media recovery to recover block, restore backup if needed

SQL> alter database datafile 3 offline drop;

Database altered.

SQL> alter database open;

Database altered.

数据库已启动。

因为没有SYSAUX表空间,发现通过EXP导出数据时不能全库导出,也不能按用户导出，因此对SYSAUX表空间进行重建，重建后可以通过EXP正常导出数据。

新建Monitor1数据库，将备份数据导入，然后修改Service_names参数为monitor,对外提供服务，原数据库monitor关闭。

1：实例名称ORACLE_SID=monitor1

2：创建相应的目录 /data2/monitor,adump,bdump,cdump,udump

3：建立密码文件：

$ORACLE_HOME/bin/orapwd file=$ORACLE_HOME/dbs/orapwmonitor1 password=monitor1

4: 修改参数文件

5．设置当前工作实例：

export ORACLE_SID=monitor1

6．登陆oracle：

sqlplus ‘/ as sysdba’

7．启动实例：

SQL>startup nomount

8．通过脚本创建数据库及相应的表空间、用户等。

9.IMP导入数据。

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

JDUL技术原理介绍文档

2014/04/13 by admin Leave a Comment

JDUL技术原理介绍文档

[gview file=”https://www.askmac.cn/wp-content/uploads/2014/11/Harris_Wheres-My-Data.pdf”]

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

PRM-DUL For Oracle Database Installation Instruction

2014/04/11 by admin Leave a Comment

[gview file=”https://www.askmac.cn/wp-content/uploads/2014/04/PRM-Installation-Instruction.pdf”]

PRM is a java developed tool, unzipped and clicked to run

PRM is designed for Enterprise Database Recovery, which includes all Oracle DUL data recovery functionalities, and also easy-to-use GUI.

1 Unzip package

Unix：

unzip ParnassusData_PRMForOracle_3004.zip

Windows：

Right click to unzip

2 Make sure JDK is available and JDK 1.6 is recommended

Unix：

java –version

Windows: type “cmd” in start

java –version

If there is no JDK 1.6 or above, please download and click to install

Open JDK For Linux download Link:

Open jdk x86_64 for Linux 5	http://pan.baidu.com/s/1qWO740O
Tzdata-java x86_64 for Linux 5	http://pan.baidu.com/s/1gdeiF6r
Open jdk x86_64 for Linux 6	http://pan.baidu.com/s/1mg0thXm
Open jdk x86_64 for Linux 6	http://pan.baidu.com/s/1sjQ7vjf
Open jdk x86 for Linux 5	http://pan.baidu.com/s/1kT1Hey7
Tzdata-java x86 for Linux 5	http://pan.baidu.com/s/1kT9iBAn
Open jdk x86 for Linux 6	http://pan.baidu.com/s/1sjQ7vjf
Tzdata-java x86 for Linux 6	http://pan.baidu.com/s/1kTE8u8n

JDK on Other platform downloads:

AIX JAVA SDK 7	http://pan.baidu.com/s/1i3JvAlv
JDK Windows x86	http://pan.baidu.com/s/1qW38LhM
JDK Windows x86-64	http://pan.baidu.com/s/1qWDcoOk
Solaris JDK 7 x86-64bit	http://pan.baidu.com/s/1gdzgSvh
Solaris JDK 7 x86-32bit	http://pan.baidu.com/s/1mgjxFlQ
Solaris JDK 7 Sparc	http://pan.baidu.com/s/1pJjX3Ft

Other download address：http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html

3 start PRM

Make sure X GUI is available in UNIX, and switch to PRM folder

cd to PRM path

./prm.sh

If there is an error, please try:

java –jar prm.jar

./prm_startup.sh

Windows

cmd, and go to PRM folder

./prm.bat

or click PRM.bat

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

诗檀软件成功为某北方国企恢复被DELETE删除的数据

2014/04/04 by admin Leave a Comment

某北方国企的核心ERP系统Oracle数据库由于乙方维护人员操作不慎，DELETE数据时忘记加上必要的WHERE条件，导致一张十几万记录的表被DELETE只剩几千条记录，该数据库为非归档模式，且无其他有效的物理备份。且该表在后续的时间里还插入了部分数据，可能导致原有DELETE记录被部分覆盖，恢复难度较大。这个Case用户之前已经找了好几拨数据库工程师来查看，并尝试使用DUL等工具，都没有成功恢复哪怕一条数据。

诗檀软件员工 @Biot_wang通过快速编写SHELL脚本配合BBED修改row flag 再配合PRM-DUL的方式，从该表中恢复出数万条记录，其中70%为可用数据，30%数据已经不完整。对于此类DELETE删除情况，若一旦发现且无有效备份，可以立即将DELETE表的所在表空间数据文件全部拷贝出来，以便恢复工程师后续在做恢复努力时可以最大程度挽回损失。

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

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

ORACLE PRM是诗檀软件独立研发的ORACLE数据库灾难恢复软件，其具有全程图形化界面、简单高效等特点。

欢迎下载使用ORACLE PRM。下载地址：http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip

PRM用户使用手册。http://www.parnassusdata.com/sites/default/files/ParnassusData%20Recovery%20Manager%20For%20Oracle%20Database%E7%94%A8%E6%88%B7%E6%89%8B%E5%86%8C%20v0.3.pdf

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

system01.dbf损坏的oracle数据库恢复

2014/03/21 by admin Leave a Comment

system01.dbf损坏的oracle数据库恢复

诗檀软件工程师于2014 年11 月26 日通过修正文件中的坏块。成功从原数据库中救出数据文件，并操作诗檀公司救援工具PRM-DUL 从数据文件中抽取出客户业务数据。所得数据已经倒入到临时数据库ORCL1 中，以方便用户查询验证。

由于数据文件内部的坏块量较少，因此保证了90%以上的业务数据可成功抽取，完成任务。

现场ORCL 数据库采用11.2.0.1.0 版本单节点，数据存储使用普通文件存储模式，其操作平台为Windows Server。

当时数据库情况
1. Alert Log 历史追溯
通过追溯日志发现，于2014 年1 月5 日已出现坏块读取错误。

Sun Jan 05 06:00:48 2014
GATHER_STATS_JOB encountered errors. Check the trace file.
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_j003_192.trc:
ORA-01115: IO error reading block from file (block # )
ORA-01110: data file 2:
'G:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSAUX01.DBF'
ORA-27070: async read/write failed
OSD-04006: ReadFile() 失败, 无法读取文件
O/S-Error: (OS 23) 数据错误(循环冗余检查)。

然后这种坏块现象也蔓延到System 表空间文件 SYSTEM01.DBF

Mon Feb 17 02:00:00 2014
Clearing Resource Manager plan via parameter Errors in file
d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_dbrm_3016.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-01115: IO error reading block from file (block # )
ORA-01110: data file 1:'G:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSTEM01.DBF'
ORA-27070: async read/write failed
OSD-04006: ReadFile() 失败, 无法读取文件
O/S-Error: (OS 23) 数据错误(循环冗余检查)。
Unable to restore resource manager plan to '':
ORA-02097: parameter cannot be modified because specified
value is invalid
ORA-00604: error occurred at recursive SQL level 1
ORA-01115: IO error reading block from file (block # )
ORA-01110: data file 1:
'G:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSTEM0
1.DBF'
ORA-27070: async read/write failed
OSD-04006: ReadFile() 失败,

并开始出现内部错误：

Mon Feb 24 11:37:36 2014
Exception [type: ACCESS_VIOLATION,
UNABLE_TO_READ] [ADDR:0xD4A0000] [PC:0x6D17E20,
_kgghash()+686]
Errors in file
d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora
_5432.trc (incident=9762):
ORA-07445: 出现异常错误: 核心转储 [kgghash()+686]
[ACCESS_VIOLATION] [ADDR:0xD4A0000] [PC:0x6D17E20]
[UNABLE_TO_READ] []
Incident details in:
d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdi
r_9762\orcl_ora_5432_i9762.trc

之后此类错误陆续出现在REDO log 以及TEMP 文件，甚至在用户业务文件.ORA 中也出现了坏块。

Sat May 24 08:27:46 2014
Errors in file
d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_m0
00_5072.trc (incident=9763):
ORA-00603: ORACLE server session terminated by fatal error

ORA-01115: IO error reading block from file (block # )
ORA-01110: data file 3:
'G:\APP\ADMINISTRATOR\ORADATA\ORCL\UNDOTB
S01.DBF'
ORA-27070: async read/write failed
OSD-04006: ReadFile() 失败, 无法读取文件
O/S-Error: (OS 23) 数据错误(循环冗余检查)。
ORA-01115: IO error reading block from file (block # )
ORA-01110: data file 3:
'G:\APP\ADMINISTRATOR\ORADATA\ORCL\UNDOTB
S01.DBF'
ORA-27070: async read/write failed
OSD-04006: ReadFile() 失败, 无法读取文件
O/S-Error: (OS 23) 数据错误(循环冗余检查)。
ORA-01115: IO error reading block from file (block # )
ORA-01110: data file 3:
'G:\APP\ADMINISTRATOR\ORADATA\ORCL\UNDOTB
S01.DBF'
ORA-27070: async read/write failed
OSD-04006: ReadFile() 失败, 无法读取文件
O/S-Error: (OS 23) 数据错误(循环冗余检查)。
ORA-01115: IO error reading block from file (block # )
ORA-01110: data file 2:
'G:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSAUX0
1.DBF'
ORA-27070: async read/write failed
OSD-04006: ReadFile() 失败, 无法读取文件
O/S-Erro
Incident details in:
d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdi
r_9763\orcl_m000_5072_i9763.trc
opidrv aborting process M000 ospid (5072) as a result of
ORA-603
Thu Sep 11 22:02:02 2014
Errors in file

d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_j00
0_4392.trc:
ORA-12012: error on auto execute of job 128120
ORA-01115: IO error reading block from file (block # )
ORA-01110: data file 6:
'G:\APP\ADMINISTRATOR\ORADATA\ORCL\BJ_ZCGL.
ORA'
ORA-27070: async read/write failed
OSD-04006: ReadFile() 失败, 无法读取文件
O/S-Error: (OS 23) 数据错误(循环冗余检查)。
ORA-06512: at "SYS.DBMS_ADVISOR", line 201
ORA-06512: at "SYS.DBMS_SPACE", line 1798
ORA-06512: at "SYS.DBMS_SPACE", line 1871

由于最终坏块蔓延到控制文件，最终导致宕机。

Thu Oct 09 21:49:52 2014
Errors in file
d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_m0
00_4676.trc:
ORA-00202: control file:
'G:\APP\ADMINISTRATOR\ORADATA\ORCL\CONTRO
L01.CTL'
ORA-27070: async read/write failed
OSD-04006: ReadFile() 失败, 无法读取文件
O/S-Error: (OS 23) 数据错误(循环冗余检查)。
Errors in file
d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_m0
00_4676.trc:
ORA-00204: error in reading (block 22, # blocks 1) of control
file
ORA-00202: control file:
'G:\APP\ADMINISTRATOR\ORADATA\ORCL\CONTRO
L01.CTL'
ORA-27070: async read/write failed
OSD-04006: ReadFile() 失败, 无法读取文件
O/S-Error: (OS 23) 数据错误(循环冗余检查)。
Thu Oct 09 21:54:01 2014
Errors in file
d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_lgw
r_3036.trc:
ORA-00202: control file:
'G:\APP\ADMINISTRATOR\ORADATA\ORCL\CONTRO
L01.CTL'
ORA-27070: async read/write failed
OSD-04006: ReadFile() 失败, 无法读取文件
O/S-Error: (OS 23) 数据错误(循环冗余检查)。
Errors in file
d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_lgw
r_3036.trc:
ORA-00204: error in reading (block 22, # blocks 1) of control
file
ORA-00202: control file:
'G:\APP\ADMINISTRATOR\ORADATA\ORCL\CONTRO
L01.CTL'
ORA-27070: async read/write failed
OSD-04006: ReadFile() 失败, 无法读取文件
O/S-Error: (OS 23) 数据错误(循环冗余检查)。
LGWR (ospid: 3036): terminating the instance due to error 204

之后客户及第三方服务机构曾多次尝试打开数据库失败。由于数据库文件坏块已基本蔓延至所有数据文件。一旦数据库奔
溃后，即便修复了控制文件（据日志观察，10 月31 日对控制文件进行过修复），由于系统文件无法通过自检，数据库打开失败
也就成了必然事件。

Wed Nov 19 11:37:05 2014
SMON: Restarting fast_start parallel rollback
Errors in file
d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora
_3568.trc:
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01115: 从文件 读取块时出现 IO 错误 (块 # )
ORA-01110: 数据文件 1:
'G:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSTEM0
1.DBF'
ORA-27070: 异步读取/写入失败
OSD-04006: ReadFile() 失败, 无法读取文件
O/S-Error: (OS 23) 数据错误(循环冗余检查)。
Errors in file
d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora
_3568.trc:
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01115: 从文件 读取块时出现 IO 错误 (块 # )
ORA-01110: 数据文件 1:
'G:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSTEM0
1.DBF'
ORA-27070: 异步读取/写入失败
OSD-04006: ReadFile() 失败, 无法读取文件
O/S-Error: (OS 23) 数据错误(循环冗余检查)。
Error 604 happened during db open, shutting down database
USER (ospid: 3568): terminating the instance due to error 604

用户曾试图将相关数据文件copy 到其他无坏块盘，但由于无法完成坏块读取，导致操作失败。

数据库配置

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 -
Production
With the Partitioning, OLAP, Data Mining and Real
Application Testing options.
Using parameter settings in server-side spfile
D:\APP\ADMINISTRATOR\PRODUCT.2.0\DBHOME_
1\DATABASE\SPFILEORCL.ORA
System parameters with non-default values:
processes = 150
memory_target = 1232M
control_files =
"G:\APP\ADMINISTRATOR\ORADATA\ORCL\CONTRO
L01.CTL"
control_files =
"D:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\
ORCL\CONTROL02.CTL"
db_block_size = 8192
compatible = "11.2.0.0.0"
db_recovery_file_dest =
"D:\app\Administrator\flash_recovery_area"
db_recovery_file_dest_size= 3852M
undo_tablespace = "UNDOTBS1"
remote_login_passwordfile= "EXCLUSIVE"
db_domain = ""
dispatchers = "(PROTOCOL=TCP)
(SERVICE=orclXDB)"
audit_file_dest =
"D:\APP\ADMINISTRATOR\ADMIN\ORCL\ADUMP"
audit_trail = "DB"
db_name = "orcl"
open_cursors = 300
diagnostic_dest = "D:\APP\ADMINISTRATOR".

下图为数据库Mount 后，数据文件情况：

数据库救援处理

诗檀工程师在分析其数据库情况后，按以下步骤进行数据库数据救援操作：

1. 首先使用文件修复拷贝工具将所有数据库文件copy 至I 盘（磁盘为用户提供的无问题盘）。

System01.dbf

工程师使用PRM-DUL 工具打开了对应数据库文件：

1）打开prm.bat
2）使用字典模式并倒入数据文件:
SYSTEM01.DBF
SYSAUX01.DBF
BJ_ZCGL.ORA
EXAMPLE01.DBF
USERS01.DBF
3）通过观察发现需要导出Schema 下的数据

4. 使用PRM-DUL DataBridge 方式将用户业务数据抽取并成功倒入到临时数据库ORCL1 中。

1. 由于坏块使得重新将客户系统恢复已无意义。建议第三方重新部署软件相应数据库应用设置并将救援出的客户数据重新导入

2. 用户的数据库无备份，无归档。并缺少相应数据库专业人员进行维护及日志检查。数据库出现问题在初期未能及时解决，使得坏块扩散，最终造成客户损失。

建议：开启备份和日志归档，派遣数据库相关人员做定期健康检查。

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

ORACLE専用データ復旧ソフトウェア PRM DUL

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

场景1： 当前的控制文件可用

场景2 此次恢复中使用的是备份的控制文件

存储无法访问导致数据库异常宕机,重起数据库无法启动

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

ORACLE専用データ復旧ソフトウェア　PRM DUL

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

场景1：当前的控制文件可用

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com