Oracle断电报错ORA-00600数据库无法打开的恢复

以下为一个ORACLE数据库因为断掉而引起ORA-00600错误的例子。

造成ORA-00600 [4000]错误的主要原因是因为系统掉电,或者数据库恢复不完全,导致system表空间的一些位的状态异常,导致bootstrap无法正常情况.

以下是通过bbed方法,修改相关标志位,强制打开数据库的一种方法.

但是由于数据库实际上已经处于非一致状态,强烈建议用户打开数据库后,通过将生产环境的数据导出后,重建数据库.

--alert log相关的trace如下:

Tue Jun  4 15:41:34 2013

Errors in file /u02/oracle/app/oracle/admin/ORCL/udump/ORCL1_ora_770332.trc:

ORA-00600: internal error code, arguments: [4000], [41], [], [], [], [], [], []

trace文件 /u02/oracle/app/oracle/admin/ORCL/udump/ORCL1_ora_770332.trc,可以找到类似的相关内容

*** 2013-06-04 15:41:35.055

ksedmp: internal or fatal error

ORA-00600: internal error code, arguments: [4000], [41], [], [], [], [], [], []

Current SQL statement for this session:

select ctime, mtime, stime from obj$ where obj# = :1

----- Call Stack Trace -----

calling              call     entry                argument values in hex      

location             type     point                (? means dubious value)     

-------------------- -------- -------------------- ----------------------------

ksedst+001c          bl       ksedst1              0FFFFFFFF ? 000000020 ?

ksedmp+0290          bl       ksedst               1048EBB20 ?

ksfdmp+0018          bl       03F3BE0C             

kgeriv+0108          bl       _ptrgl               

kgeasi+0118          bl       kgeriv               1019AAD00 ? 000000000 ?

                                                   000000000 ?

                                                   26414080048E1630 ?

                                                   300000000 ?

...................................................                                                   

Block header dump:  0x0040007a

 Object id on Block? Y

 seg/obj: 0x12  csc: 0xc20.26114c0d  itc: 1  flg: -  typ: 1 - DATA

     fsl: 0  fnx: 0x0 ver: 0x01

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0029.026.0021d127  0x0091a949.3d91.01  --U-    1  fsc 0x0000.26114c0f

data_block_dump,data header at 0x700000b77a4e044

===============

tsiz: 0x1fb8

hsiz: 0xea

pbl: 0x700000b77a4e044

bdba: 0x0040007a

     76543210

flag=--------

ntab=1

nrow=108

frre=-1

fsbo=0xea

fseo=0x40c

avsp=0x368

tosp=0x368

这次一开始这个库报ORA-600[2662]错误:

Mon Aug 23 09:37:00 2010
Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_852096.trc:
ORA-00600: internal error code, arguments: [2662], [0], [130131504], [0], [130254136], [4264285], [], []
Mon Aug 23 09:37:02 2010
Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_852096.trc:
ORA-00600: internal error code, arguments: [2662], [0], [130131506], [0], [130254136], [4264285], [], []

Mon Aug 23 09:37:00 2010

Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_852096.trc:

ORA-00600: internal error code, arguments: [2662], [0], [130131504], [0], [130254136], [4264285], [], []

Mon Aug 23 09:37:02 2010

Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_852096.trc:

ORA-00600: internal error code, arguments: [2662], [0], [130131506], [0], [130254136], [4264285], [], []

以下为一些可能遇到的报错列表：

Error Description Corruption related to:

ORA-1578 ORA-1578一般为Oracle检测到存在物理坏块问题，包括其检测数据块中的checksum不正确，或者tail_chk信息不正确等。 ORA-1578 is reported when a block is thought to be corrupt on read.

Block

数据块

  OERR: ORA-1578 “ORACLE data block corrupted (file # %s, block # %s)” Master Note  

  OERR: ORA-1578 “ORACLE data block corrupted (file # %s, block # %s)”  

Fractured Block explanation

  Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g  

  Diagnosing and Resolving 1578 reported on a Local Index of a Partitioned table  

ORA-1410

ORA-1410错误常见于从INDEX或其他途径获得的ROWID,到数据表中查询发现没有对应的记录。

该错误可能因为数据表与其索引存在不一致，也可能是分区的数据表本身存在问题。

This error is raised when an operation refers to a ROWID in a table for which there is no such row.

The reference to a ROWID may be implicit from a WHERE CURRENT OF clause or directly from a WHERE ROWID=… clause.

ORA 1410 indicates the ROWID is for a BLOCK that is not part of this table.

Row

数据行

  Understanding The ORA-1410  

  Summary Of Bugs Containing ORA 1410  

  OERR: ORA 1410 “invalid ROWID”  

ORA-8103

该ORA-8103可能由多个BUG引起，例如LOB在10.2.0.4之前可能会由于BUG覆盖了另一张表的segment header，导致出现ORA-8103错误。

诊断该问题可以从数据表的segment header和data_object_id入手。

The object has been deleted by another user since the operation began.

If the error is reproducible, following may be the reasons:-

a.) The header block has an invalid block type.

b.) The data_object_id (seg/obj) stored in the block is different than the data_object_id stored in the segment header. See dba_objects.data_object_id and compare it to the decimal value stored in the block (field seg/obj).

Block

数据块

  ORA-8103 Troubleshooting, Diagnostic and Solution  

  OERR: ORA-8103 “object no longer exists” / Troubleshooting, Diagnostic and Solution  

ORA-8102 ORA-8102常见于索引键值与表上存的值不一致。 An ORA-08102 indicates that there is a mismatch between the key(s) stored in the index and the values stored in the table. What typically happens is the index is built and at some future time, some type of corruption occurs, either in the table or index, to cause the mismatch.

Index

索引

  OERR ORA-8102 “index key not found, obj# %s, file %s, block %s (%s)  

ORA-1499 对表和索引做交叉验证时发现问题 An error occurred when validating an index or a table using the ANALYZE command.

One or more entries does not point to the appropriate cross-reference.

Index

索引

  ORA-1499. Table/Index row count mismatch  

  OERR: ORA-1499 table/Index Cross Reference Failure – see trace file  

ORA-1498 Generally this is a result of an ANALYZE … VALIDATE … command.

This error generally manifests itself when there is inconsistency in the data/Index block. Some of the block check errors that may be found:-

a.) Row locked by a non-existent transaction

b.) The amount of space used is not equal to block size

c.) Transaction header lock count mismatch.

While support are processing the tracefile it may be worth the re-running the ANALYZE after restarting the database to help show if the corruption is consistent or if it ‘moves’.

Send the tracefile to support for analysis.

If the ANALYZE was against an index you should check the whole object. Eg: Find the tablename and execute:

ANALYZE TABLE xxx VALIDATE STRUCTURE CASCADE; Block

  OERR: ORA 1498 “block check failure – see trace file”  

ORA-26040 由于采用过nologging/unrecoverable选项的redo生成机制，且做过对应的recover，导致数据块中被填满了0XFF，导致报错ORA-26040。 Trying to access data in block that was loaded without redo generation using the NOLOGGING/UNRECOVERABLE option.

This Error raises always together with ORA-1578

Block

数据块

  OERR ORA-26040 Data block was loaded using the NOLOGGING option  

  ORA-1578 / ORA-26040 Corrupt blocks by NOLOGGING – Error explanation and solution  

  ORA-1578 ORA-26040 in a LOB segment – Script to solve the errors  

  ORA-1578 ORA-26040 in 11g for DIRECT PATH with NOARCHIVELOG even if LOGGING is enabled  

  ORA-1578 ORA-26040 On Awr Table  

  Errors ORA-01578, ORA-26040 On Standby Database  

  Workflow Tables ORA-01578 ORACLE data block corrupted ORA-26040 Data block was loaded using the NOLOGGING option  

  ORA-1578, ORA-26040 Data block was loaded using the NOLOGGING option  

ORA-600[12700]

从索引获得的ROWID，对应到数据表时发现不存在数据行错误。

一把是一致性度consistent read问题

Oracle is trying to access a row using its ROWID, which has been obtained from an index.

A mismatch was found between the index rowid and the data block it is pointing to. The rowid points to a non-existent row in the data block. The corruption can be in data and/or index blocks.

ORA-600 [12700] can also be reported due to a consistent read (CR) problem.

Consistent Read

一致性读

  Resolving an ORA-600 [12700] error in Oracle 8 and above.  

  ORA-600 [12700] “Index entry Points to Missing ROWID”  

ORA-600[3020] 主要问题是redo和数据块中的信息不一致 This is called a ‘STUCK RECOVERY’.

There is an inconsistency between the information stored in the redo and the information stored in a database block being recovered. Redo

  ORA-600 [3020] “Stuck Recovery”  

  Information Required for Root Cause Analysis of ORA-600 [3020] (stuck recovery)  

ORA-600[4194] 主要是redo记录与回滚rollback/undo的记录不一致 A mismatch has been detected between Redo records and rollback (Undo) records.

We are validating the Undo record number relating to the change being applied against the maximum undo record number recorded in the undo block.

This error is reported when the validation fails. Undo

  ORA-600 [4194] “Undo Record Number Mismatch While Adding Undo Record”  

  Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter  

ORA-600[4193] 主要是redo记录与回滚rollback/undo的记录不一致 A mismatch has been detected between Redo records and Rollback (Undo) records.

We are validating the Undo block sequence number in the undo block against the Redo block sequence number relating to the change being applied.

This error is reported when this validation fails. Undo

  ORA-600 [4193] “seq# mismatch while adding undo record”  

  Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter  

  Ora-600 [4193] When Opening Or Shutting Down A Database  

  ORA-600 [4193] When Trying To Open The Database  

ORA-600[4137] transaction id不匹配，问题可能存在与回滚段中或者对象本身存在讹误 While backing out an undo record (i.e. at the time of rollback) we found a transaction id mis-match indicating either a corruption in the rollback segment or corruption in an object which the rollback segment is trying to apply undo records on.

This would indicate a corrupted rollback segment. Undo/Redo

  ORA-600 [4137] “XID in Undo and Redo Does Not Match”  

ORA-600[6101] Not enough free space was found when inserting a row into an index leaf block during the application of undo. Index

  ORA-600 [6101] “insert into leaf block (undo)”  

ORA-600[2103] Oracle is attempting to read or update a generic entry in the control file.

If the entry number is invalid, ORA-600 [2130] is logged. Control File

  ORA-600 [2130] “Attempt to access non-existant controlfile entry”  

ORA-600[4512] Oracle is checking the status of transaction locks within a block.

If the lock number is greater than the number of lock entries, ORA-600 [4512] is reported followed by a stack trace, process state and block dump.

This error possibly indicates a block corruption. Block

  ORA-600 [4512] “Lock count mismatch”  

ORA-600[2662] 主要是发现一个数据块的SCN甚至超过了当前SCN，常规解决途径有调整SCN等，但11.2以后Oracle公司使较多调整SCN的方法失效了 A data block SCN is ahead of the current SCN.

The ORA-600 [2662] occurs when an SCN is compared to the dependent SCN stored in a UGA variable.

If the SCN is less than the dependent SCN then we signal the ORA-600 [2662] internal error. Block

  ORA-600 [2662] “Block SCN is ahead of Current SCN”  

  ORA 600 [2662] DURING STARTUP  

ORA-600[4097] 访问一个回滚段头以便确认事务是否已提交时，发现XID有问题 We are accessing a rollback segment header to see if a transaction has been committed.

However, the xid given is in the future of the transaction table.

This could be due to a rollback segment corruption issue OR you might be hitting the following known problem. Undo

  ORA-600 [4097] “Corruption”  

ORA-600[4000] It means that Oracle has tried to find an undo segment number in the dictionary cache and failed. Undo

  ORA-600 [4000] “trying to get dba of undo segment header block from usn”  

ORA-600[6006] Oracle is undoing an index leaf key operation. If the key is not found, ORA-00600 [6006] is logged.

ORA-600[6006] is usually caused by a media corruption problem related to either a lost write to disk or a corruption on disk. Index

  ORA-600 [6006]  

ORA-600[4552] This assertion is raised because we are trying to unlock the rows in a block, but receive an incorrect block type.

The second argument is the block type received. Block

  ORA-600 [4555]  

ORA-600[6856] Oracle is checking that the row slot we are about to free is not already on the free list.

This internal error is raised when this check fails. Row

  ORA-600 [6856] “Corrupt Block When Freeing a Row Slot  

ORA-600[13011] During a delete operation we are deleting from a view via an instead-of trigger or an Index organized table and have exceeded a 5000 pass count when we raise this exception. Row

  ORA-600 [13011] “Problem occurred when trying to delete a row”  

ORA-600[13013] During the execution of an UPDATE statement, after several attempts (Arg [a] passcount) we are unable to get a stable set of rows that conform to the WHERE clause. Row

  ORA-600 [13013] “Unable to get a Stable set of Records”  

  How to resolve ORA-00600 [13013], [5001]  

ORA-600[13030]  

  ORA-600 [13030]  

ORA-600[25012] We are trying to generate the absolute file number given a tablespace number and relative file number and cannot find a matching file number or the file number is zero. afn/rdba/tsn

  ORA-600 [25012] “Relative to Absolute File Number Conversion Error”  

ORA-600[25026] Looking up/checking a tablespace

invalid tablespace ID and/or rdba found afn/rdba/tsn

  ORA-600 [25026]  

ORA-600[25027] Invalid tsn and/or rfn found afn/rdba/tsn

  ORA-600 [25027]  

ORA-600[kcbz_check_objd_typ] 内存中的block buffer检测发现存在错误的object id An object block buffer in memory is checked and is found to have the wrong object id. This is most likely due to corruption. Buffer Cache

  ORA-600 [kcbz_check_objd_typ_3]  

  ORA-600 [kcbz_check_objd_typ]  

ORA-600[kddummy_blkchk] ORA-600[kdblkcheckerror] 一种逻辑检测发现问题的情况 ORA-600[kddummy_blkchk] is for 10.1/10.2 and ORA-600[kdblkcheckerror] for 11 onwards. Block

  ORA-600 [kddummy_blkchk]  

  How to Resolve ORA-00600[kddummy_blkchk]  

  ORA-600 [kdblkcheckerror]  

QREF – kddummy_blkchk / kdBlkCheckError – Check Codes Listing (Full) [This section is not visible to customers.]

QREF – kddummy_blkchk / kdBlkCheckError – Check Codes Definition && Return Values[This section is not visible to customers.]

ORA-600[ktadrprc-1]

Dictionary

字典

  ORA-600 [ktadrprc-1]  

ORA-600[ktsircinfo_num1] SYS.SEG$字典表导致row cache字典缓存中存在意外 This exception occurs when there are problems obtaining the row cache information correctly from sys.seg$. In most cases there is no information in sys.seg$.

Dictionary

字典

  ORA-600 [ktsircinfo_num1]  

ORA-600[qertbfetchbyrowid] Row

  ORA-600 [qertbfetchbyrowid]  

ORA-600[ktbdchk1-bad dscn] This exception is raised when we are performing a sanity check on the dependent SCN and fail.

The dependent scn is greater than the current scn. Dictionary

  ORA-600 [ktbdchk1: bad dscn]  

一些可供参考的文档：

77587.1: BLOCK CORRUPTIONS ON ORACLE AND UNIX

32969.1: TECH: Database Block Checking Features

68013.1: DBMS_REPAIR example

33405.1: Extracting Data from a Corrupt Table using SKIP_CORRUPT_BLOCKS or Event 10231

360032.1: How to detect and fix a corruption in the datafile OS header - ORA-27047

293515.1: ORA-1578 ORA-26040 in a LOB segment - Script to solve the errors

1011557.6: ORA-1122, ORA-1110, ORA-120X

107821.1: ORA-01545 while Dropping Corrupted Rollback Segment

215929.1: ORA-07445 and Bad header found during buffer read

238931.1: Fractured Block Found During User Buffer Read Message in Alert.log

96118.1: ORA-08102: Rebuilding Index does not correct ORA-8102

227671.1: Hardware Assisted Resilient Data H.A.R.D

239388.1: DBWR Terminates Instance With ORA-600 [kcbzpb_1] during Startup

125607.1: Compute stats gives ORA-01410 & ORA-06512

76375.1: Prevention, Detection and Repair of Database Corruption

77589.1: CAUSES OF BLOCK CORRUPTIONS

34371.1: Extracting Data from a Corrupt Table using ROWID or Index Scans in Oracle7

97357.1: SALVAGE8i.PC - Oracle8i,Oracle9i Pro*C Code to Extract Data from a Corrupt Table.

96709.1: Starting Database Fails With ORA-00205 and ORA-09782

180416.1: DBVerify Reports the Message 'kdbchk: the amount of space used is not equal to block size'

360218.1: ORA-8102 reported when attempting to delete row in Index Organized Table (IOT)

239865.1: ORA-00600 [25012], while performing select or insert on a table

159973.1: Corrupt File(s) Reported In The Alertlog

168831.1: Delete From Table With Compressed Indexes Fails with ORA-08102

76746.1: SCRIPT: For Bug:970640 to check if Target Database has been corrupted

301124.1: Alert file reports controlfile fractured block

341456.1: ORA-00600 [Kcrf_pvt_strand_bind1] in 10gR1

227214.1: ORA-600 [25012] Possible From Index Prefetch

1029883.6: Extracting Data from a Corrupt Table using SALVAGE Scripts / Programs

1038857.6: DBVERIFY RETURNS CORRUPTED BLOCKS WITH 16 OR 32K BLOCKSIZE DATAFILES

153642.1: Corrupt Block Bad Headers are Found During Buffer Read in Alert.log

114471.1: CORRUPT BLOCK DBA MESSAGES WITH DB_BLOCK_CHECKSUM=TRUE

1016661.102: ORA-08103: ON "DELETE FROM" STATEMENT WITH A "WHERE" CLAUSE

337338.1: ORA-600 [2663] During Import

1068001.6: ORA-01578: AGAINST A NEW DATAFILE

147492.1: Data Corruption in Oracle on Sun Solaris 2.7, 2.8 and Network Attached Storage

280754.1: ORA-1499 when analyzing cluster indexes using online option

237544.1: ORA-01578 ORA-01110 when data file extends on 4GB boundary on AIX 5L with 32bit Kernel

126094.1: ORA-600 [25012] using DBMS_SPACE.UNUSED on TEMPORARY Tables

131422.1: C_MLOG# CLUSTER CORRUPTION

1068627.6: CORRUPTION IN FILE 0 ON A UNIX SYSTEM

1036642.6: ORA-600 [2845] SELECTING WITH ROWID

122648.1: ORA-600 [15163] Working With Partitioned Table

245761.1: ORA-600[kftts2bz_many_files] Error From An INSERT Statement

98789.1: ORA-07445[KSQCMI()+5420] AND ORA-0600[1100]

102615.1: ORA-600 [KCCSBCK_FIRST] When Starting Database

1064436.6: ORA-00600 [12850], AND ORA-00600 [15265]: WHEN SELECT OR DESCRIBE ON TABLE

157533.1: DBVERIFY Fails With DBV-00100 on Datafile Larger Than 2GB

1070801.6: ORA-00604, ORA-01406: EXECUTING SELECT OR DESCRIBE FROM DBA_ROLLBACK_SEGS

109836.1: COMPRESSED IOT BLOCK IS GETTING CORRUPTED

307597.1: Bug:3785200: Platform Vulnerability

1039248.6: REDIRECTING OUTPUT FOR SQL_TRACE

118941.1: ORA-07445 exception encountered: core dump [8] When Select a table

1031125.6: ORA-04031: WHEN TRYING TO COMPILE TRIGGER

1070878.6: ORA-00604, ORA-00001: WHILE CHANGING PASSWORD FOR USER 'SYSTEM'

166632.1: Running DBVERIFY Reports Corruption Errors on Locally Managed Temporary Tablespaces

114285.1: EBU REPORTS LOGICALLY CORRUPT BLOCKS

114218.1: ORA-600 [2847] or [kcfnew_1] WHEN RESIZING A DATAFILE

158417.1: Corrupted Blocks Are Reported in ALERT file with no Corruption

114357.1: CORRUPT BLOCK INFO NOT REPORTED TO ALERT.LOG

100933.1: ORA-600 [1906] ORA-600 [12235] ORA-7445 [11] Followed by Database Crash

1059851.6: HP-UX: RECREATING A TABLE

167743.1: DBV Reports Corruption for All Pages on Tru64

140649.1: Mass Retirement Ends In Error

此场景中由于数据字典已经损坏，所以想要正常打开数据库是十分困难的。

此时则可以使用PRM来抽取数据库中的数据。具体步骤与场景1中的相似，用户仅仅需要输入该数据库的所有数据文件即可，其简要步骤如下:

Recovery Wizard

启动PRM-DUL ，并选择 Tools =>  Recovery Wizard

点击Next

虽然遇到了ORA-00600或其他一系列的报错，但这只意味着ORACLE认为数据库特别是数据字典可能存在讹误，仍可以通过PRM-DUL的数据字典模式来恢复数据，而不需要使用非数据字典模式。

下一步骤 我们要选择几个参数 ： 包括Endian 字节序和DB NAME

由于ORACLE数据文件在不同的操作系统平台上采用了不同的Endian字节序格式，字节序和平台对应列表如下：

Solaris[tm] OE (32-bit)Big

Solaris[tm] OE (64-bit)Big

Microsoft Windows IA (32-bit)Little

Linux IA (32-bit)Little

AIX-Based Systems (64-bit)Big

HP-UX (64-bit)Big

HP Tru64 UNIXLittle

HP-UX IA (64-bit)Big

Linux IA (64-bit)Little

HP Open VMSLittle

Microsoft Windows IA (64-bit)Little

IBM zSeries Based LinuxBig

Linux x86 64-bitLittle

Apple Mac OSBig

Microsoft Windows x86 64-bitLittle

Solaris Operating System (x86)Little

IBM Power Based LinuxBig

HP IA Open VMSLittle

Solaris Operating System (x86-64)Little

Apple Mac OS (x86-64)Little

例如在传统Unix  AIX-Based Systems (64-bit) 、HP-UX (64-bit) 上使用的是Big Endian大端字节序，则这里要选为Big Endian:

否则例如常见的Linux x86-64 、Windows都保持为默认的Little Endian:

注意事项： 如果你的数据文件是在AIX(即Big Endian的)上生成的，你为了方便而将这些数据文件拷贝到Windows服务器上并使用PRM-DUL来恢复数据，那么你仍应当选择其原生的Big Endian格式。

这里由于我们的数据文件是在Linux x86上所以我们选择Endian为Little，并输入Database name数据库名字(注意这里输入的数据库名仅仅是一个别名，它不代表这个数据库真实的DBNAME，PRM-DUL的LICENSE检测机制使用的是真实的DBNAME，而非此处输入的Database Name)：

点击Next

点击Choose Files， 一般我们推荐 如果数据库不大，那么将该库所有的数据文件都选择进来； 如果你的数据库很大，且你了解你的数据表位于哪些数据文件上，则你可以仅仅选择SYSTEM表空间的数据文件(必须！)以及数据所在的数据文件。

注意Choose界面支持Ctrl + A 和Shift等键盘操作：

后需要为指定的数据文件指定其Block Size即ORACLE数据块的大小，这里根据实际情况修改即可， 例如你的DB_BLOCK_SIZE是8K，但是部分表空间指定16K作为数据块大小的，仅仅需要为那些不是8k的数据文件修改BLOCK_SIZE即可。

这里的OFFSET 参数主要是为了那些采用裸设备存放数据文件的场景，例如在AIX上基于普通VG的LV作为数据文件，则存在4k的OFFSET，需要在此处指定。

如果你恰巧正在使用裸设备数据文件，而又不知道OFFSET到底是多少？ 则可以使用$ORACLE_HOME/bin下自带的dbfsize工具查看，如下面的例子高亮部分显示该裸设备具有4K的OFFSET

$dbfsize /dev/lv_control_01Database file: /dev/lv_control_01

Database file type: raw device without 4K starting offset

Database file size: 334 16384 byte blocks

由于此场景中所有数据文件均为8K的BLOCK SIZE，且基于文件系统所以均没有OFFSET，点击Load

Load阶段PRM-DUL会从SYSTEM表空间中读取ORACLE数据字典信息，并在自带的Derby中自建一个数据字典，这让PRM-DUL有能力操作ORACLE数据库中的各种数据。

Load完成后会在后台输出数据库 字符集和国家字符集等信息：

注意PRM-DUL是支持 多语言和ORACLE数据库的多字符集的， 但是前提是实施PRM-DUL数据恢复的操作系统要求已经安装了对应的语言包； 例如在Windows操作系统上没有安装中文语言包，但是由于ORACLE数据库字符集是独立于操作系统语言的，即ORACLE数据库的字符集可以为ZHS16GBK字符集，但是操作系统并不支持中文，此场景中不在本服务器上部署的ORACLE客户端并不受影响，可以正确显示数据库中的中文数据。

但是使用PRM-DUL则要求实施PRM-DUL数据恢复的操作系统已经安装了对应的语言包，例如用户要恢复ZHS16GBK的中文字符集数据库，则需要操作系统上已经安装了中文语言包才可以。

类似的 在Linux上需要安装fonts-chinese 中文字体包。

Load完成后 PRM-DUL界面左侧出现按照数据库用户分组的树形图

点开USERS，可以看到多个用户名，例如用户需要恢复PARNASSUSDATA SCHEMA下的一张表，则点开PARNASSUSDATA，并双击表名：

之后根据实际需求恢复各表中的数据，也可以点击用户名使用Schema-用户级别的数据搭桥模式来批量传输数据到目标数据库中；当数据库中表特别多的时候可以考虑使用该功能。