Data UnLoader: Release 8.0.5.3.0 - Internal Use Only - on Tue Jun 22 22:19:
Copyright (c) 1994/1999 Bernard van Duijnen All rights reserved. Parameter altered
Session altered.
Parameter altered
Session altered.
Parameter altered
Session altered.
Parameter altered
Session altered.
. unloading table OBJ$ 2271 rows unloaded
. unloading table TAB$ 245 rows unloaded
. unloading table COL$ 10489 rows unloaded
. unloading table USER$ 22 rows unloaded
. unloading table TABPART$ 0 rows unloaded
. unloading table IND$ 274 rows unloaded
. unloading table ICOL$ 514 rows unloaded
. unloading table LOB$ 13 rows unloaded Life is DUL without it This will unload the data of the USER$, OBJ$, TAB$ and COl$ data dictionary
tables into SQL*Loader files , this can not be manipulated into dump files
of the import format. The parameter export_mode = false is hardcoded into
the ddl scripts and can not be changed to the value "true" since this will
cause DUL to fail with the error: . unloading table OBJ$
DUL: Error: Column "DATAOBJ#" actual size(2) greater than length in column
definition(1)
.............etc...............
2.4 Invoke DUL
~~~~~~~~~~~~~~ Start DUL in interactive mode or you can prepare a scripts that contains all
the ddl commands to unload the necessary data from the database. I will
describe in this document the most used commands, this is not a complete list
of possible parameters that can be specified. A complete list can be found at
http://www.nl.oracle.com/support/DUL/ucg8.html section "DDL Description". DUL> unload database;
=> this will unload the entire database tables(includes sys'tables as well) DUL> unload user <username>;
=> this will unload all the tables owned by that particullarly user. DUL> unload table <username.table_name>;
=> this will unload the specified table owned by that username DUL> describe <owner_name.table_name>;
=> will represent the table columns with there relative pointers to the
datafile(s) owned by the specified user. DUL> scan database;
=> Scans all blocks of all data files.
Two files are generated:
1: seg.dat information of found segment headers (index/cluster/table)
(object id, file number, and block number).
2: ext.dat information of contiguous table/cluster data blocks.
(object id(V7), file and block number of segment header (V6),
file number and block number of first block,
number of blocks, number of tables) DUL> scan tables;
=> Uses seg.dat and ext.dat as input.
Scans all tables in all data segments (a header block and at least one
matching extent with at least 1 table).
2.5 Rebuild the database
~~~~~~~~~~~~~~~~~~~~~~~~ Create the new database and use import or SQL*Loader to restore the data
retrieved by DUL. Note that when you only unloaded the data that table
structures, indexation, grants, PL/SQL and triggers will no longer exist in
the new database. To obtain an exactly same copy of the database as before
you will need to rerun your creation scripts for the tables, indexes, PL/SQL,
etc. If you don't have these scripts then you will need to perform the steps
described in section 3 of this document.
3. How to rebuild object definitions that are stored in the data dictionary
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~You want to rebuild PL/SQL(packages, procedures, functions or triggers), grants,
indexes, constraints or storage clauses(old table structure) with DUL. This can
be done but is a little bit tricky. You need to unload the relevant data
Copyright (c) 1994/1999 Bernard van Duijnen All rights reserved. Parameter altered
Session altered.
Parameter altered
Session altered.
Parameter altered
Session altered.
Parameter altered
Session altered.
. unloading table OBJ$ 2271 rows unloaded
. unloading table TAB$ 245 rows unloaded
. unloading table COL$ 10489 rows unloaded
. unloading table USER$ 22 rows unloaded
. unloading table TABPART$ 0 rows unloaded
. unloading table IND$ 274 rows unloaded
. unloading table ICOL$ 514 rows unloaded
. unloading table LOB$ 13 rows unloaded Life is DUL without it This will unload the data of the USER$, OBJ$, TAB$ and COl$ data dictionary
tables into SQL*Loader files , this can not be manipulated into dump files
of the import format. The parameter export_mode = false is hardcoded into
the ddl scripts and can not be changed to the value "true" since this will
cause DUL to fail with the error: . unloading table OBJ$
DUL: Error: Column "DATAOBJ#" actual size(2) greater than length in column
definition(1)
.............etc...............
2.4 Invoke DUL
~~~~~~~~~~~~~~ Start DUL in interactive mode or you can prepare a scripts that contains all
the ddl commands to unload the necessary data from the database. I will
describe in this document the most used commands, this is not a complete list
of possible parameters that can be specified. A complete list can be found at
http://www.nl.oracle.com/support/DUL/ucg8.html section "DDL Description". DUL> unload database;
=> this will unload the entire database tables(includes sys'tables as well) DUL> unload user <username>;
=> this will unload all the tables owned by that particullarly user. DUL> unload table <username.table_name>;
=> this will unload the specified table owned by that username DUL> describe <owner_name.table_name>;
=> will represent the table columns with there relative pointers to the
datafile(s) owned by the specified user. DUL> scan database;
=> Scans all blocks of all data files.
Two files are generated:
1: seg.dat information of found segment headers (index/cluster/table)
(object id, file number, and block number).
2: ext.dat information of contiguous table/cluster data blocks.
(object id(V7), file and block number of segment header (V6),
file number and block number of first block,
number of blocks, number of tables) DUL> scan tables;
=> Uses seg.dat and ext.dat as input.
Scans all tables in all data segments (a header block and at least one
matching extent with at least 1 table).
2.5 Rebuild the database
~~~~~~~~~~~~~~~~~~~~~~~~ Create the new database and use import or SQL*Loader to restore the data
retrieved by DUL. Note that when you only unloaded the data that table
structures, indexation, grants, PL/SQL and triggers will no longer exist in
the new database. To obtain an exactly same copy of the database as before
you will need to rerun your creation scripts for the tables, indexes, PL/SQL,
etc. If you don't have these scripts then you will need to perform the steps
described in section 3 of this document.
3. How to rebuild object definitions that are stored in the data dictionary
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~You want to rebuild PL/SQL(packages, procedures, functions or triggers), grants,
indexes, constraints or storage clauses(old table structure) with DUL. This can
be done but is a little bit tricky. You need to unload the relevant data
解决方案 »
- 关于创建视图中，我想修改视图中其中一个字段的类型，如何做？
- orace 数据排序问题，急，急，急！！！！！
- oracle update 更新问题
- 触发器中实现生成流水编号功能
- ora-01092错误怎么解决？
- 数据库现在有id为1 2 6 8 26 999 等若干条数据，怎么才能让他们的ID往前面靠 不要有间隔
- 加分！！请教关于ORACLE表锁定的问题！谢谢 ！！！
- 哪儿有存储过程的教程啊.google了半天没找到:(
- 新手问题: 创建数据库!!
- 如何对oracle数据库进行数据备份?在线等待!!!
- 关于ORACLE 错误959的请教
- oracle Diagnostic pack top sql的问题
be sure to use a different user than sys or (system). Loading the data
dictionary tables of the crashed database into the healthy database dictionary
could corrupt the healthy database as well.
Detailed explanation to retrieve for example pl/sql packages / procedures /
functions from a corrupted database : 1) Follow the steps explained in the "Using DUL" section and unload the data
dictionary table "source$" 2) Create a new user into a healthy database and specify the desired default
and temporary tablespace. 3) Grant connect, resource, imp_full_database to the new user. 4) Import/load the table "source$" into the new created schema: e.g.: imp80 userid=newuser/passw file=d:\dul\scott_emp.dmp
log=d:\dul\impemp.txt full=y 5) You can now query from the table <newuser.source$> to rebuild the pl/sql
procedures/functions from the corrupted database. Scripts can be found on
WebIv to generate such PL/SQL creation scripts.The same steps can be followed to recreate indexes, constraints, and storage
parameters or to regrant privileges to the appropiate users. Please notice that
you always need to use a script of some kind that can recreate the objects and
include all the features of the crashed database version. For example : when
the crashed database is of version 7.3.4 and you have several bitmap indexes,
if you would use a script that supports version 7.3.2 or prior, then you won't
be able to recreate the bitmap indexes succesful !
4. How to unload data when the segment header block is corrupted
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~When DUL can't retrieve data block information on the normal way, it can scan
the database to create its own segment/extent map. The procedure of scanning
the database is necessary to unload the data from the datafiles.
(to illustrate this example I copied an empty block ontop of the segment header
block) 1) Create an appropiate "init.dul" (see 2.1) and "control.dul" (see 2.2) file. 2) Unload the table. This will fail and indicate that there is a corruption in
the segment header block: DUL> unload table scott.emp;
. unloading table EMP
DUL: Warning: Block is never used, block type is zero
DUL: Error: While checking tablespace 6 file 10 block 2
DUL: Error: While processing block ts#=6, file#=10, block#=2
DUL: Error: Could not read/parse segment header
0 rows unloaded 3) run the scan database command : DUL> scan database;
tablespace 0, data file 1: 10239 blocks scanned
tablespace 6, data file 10: 2559 blocks scanned 4) Indicate to DUL that it should use its own generated extent map rather than
the segment header information. DUL> alter session set use_scanned_extent_map = true;
Parameter altered
Session altered.
DUL> unload table scott.emp;
. unloading table EMP 14 rows unloaded
5. How to unload data when the datafile header block is corrupted
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~A corruption in the datafile header block is always listed at the moment you
open the database this is not like a header segment block corruption (see point
4) where the database can be succesfully openend and the corruption is listed
at the moment you do a query of a table. Dul has no problems with recovering
from such situations although there are other alternatives of recovering from
this situation like patching the datafile header block.The error you will receive looks something like :
ORACLE instance started.
Total System Global Area 11739136 bytes
Fixed Size 49152 bytes
Variable Size 7421952 bytes
Database Buffers 4194304 bytes
Redo Buffers 73728 bytes
Database mounted.
ORA-01122: database file 10 failed verification check
ORA-01110: data file 10: 'D:\DATA\TRGT\DATAFILES\JUR1TRGT.DBF'
ORA-01251: Unknown File Header Version read for file number 10
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~If datafiles are not available for the system tablespace the unload can still
continue but the object information can't be retrieved from the data dictionary
tables USER$, OBJ$, TAB$ and COL$. So ownername, tablename and columnnames will
not be loaded into the DUL dictionary. Identifying the tables can be an
overwhelming task and a good knowledge of the RDBMS internals are needed here.
First of all you need a good knowledge of your application and it's tables.
Column types can be guessed by DUL, but table and column names will be lost. Any old system tablespace from the same database (may be weeks old) can be a
great help !1) Create the "init.dul" file and the "control.dul" file as explained in above
steps 1 and 2. In this case the control file will contain all the datafiles
from which you want to restore but it doesn't require the system tablespace
information.2) Then You invoke dul and type the following command : DUL> scan database;
data file 6 1280 blocks scanned This will build the extent and segment map. Probably the dul command
interpreter will be terminated as well.3) reinvoke the dul command interpreter and do the following : Data UnLoader: Release 8.0.5.3.0 - Internal Use Only - on Tue Aug 03 13:33: Copyright (c) 1994/1999 Oracle Corporation, The Netherlands. All rights res
Loaded 4 segments
Loaded 2 extents
Extent map sorted
DUL> alter session set use_scanned_extent_map = true;
DUL> scan tables; (or scan extents;) Scanning tables with segment header Oid 1078 fno 6 bno 2 table number 0 UNLOAD TABLE T_O1078 ( C1 NUMBER, C2 UNKNOWN, C3 UNKNOWN )
STORAGE ( TABNO 0 EXTENTS( FILE 6 BLOCK 2));
Colno Seen MaxIntSz Null% C75% C100 Num% NiNu% Dat% Rid%
1 4 2 0% 0% 0% 100% 100% 0% 0%
2 4 10 0% 100% 100% 100% 0% 0% 0%
3 4 8 0% 100% 100% 100% 0% 0% 50%
"10" "ACCOUNTING" "NEW YORK"
"20" "RESEARCH" "DALLAS"
"30" "SALES" "CHICAGO"
"40" "OPERATIONS" "BOSTON" Oid 1080 fno 6 bno 12 table number 0 UNLOAD TABLE T_O1080 ( C1 NUMBER, C2 UNKNOWN, C3 UNKNOWN, C4 NUMBER,
C5 DATE, C6 NUMBER, C7 NUMBER, C8 NUMBER )
STORAGE ( TABNO 0 EXTENTS( FILE 6 BLOCK 12));
Colno Seen MaxIntSz Null% C75% C100 Num% NiNu% Dat% Rid%
1 14 3 0% 0% 0% 100% 100% 0% 0%
2 14 6 0% 100% 100% 100% 0% 0% 21%
3 14 9 0% 100% 100% 100% 0% 0% 0%
4 14 3 7% 0% 0% 100% 100% 0% 0%
5 14 7 0% 0% 0% 0% 0% 100% 0%
6 14 3 0% 0% 0% 100% 100% 0% 0%
7 14 2 71% 0% 0% 100% 100% 0% 0%
8 14 2 0% 0% 0% 100% 100% 0% 0%
"7369" "SMITH" "CLERK" "7902" "17-DEC-1980 AD 00:00:00" "800" "" "20"
"7499" "ALLEN" "SALESMAN" "7698" "20-FEB-1981 AD 00:00:00" "1600" "300" "30"
"7521" "WARD" "SALESMAN" "7698" "22-FEB-1981 AD 00:00:00" "1250" "500" "30"
"7566" "JONES" "MANAGER" "7839" "02-APR-1981 AD 00:00:00" "2975" "" "20"
"7654" "MARTIN" "SALESMAN" "7698" "28-SEP-1981 AD 00:00:00" "1250" "1400" "30" Note : it might be best that you redirect the output to a logfile since
commands like the "scan tables" can produce a lot of output.
On Windows NT you can do the following command :
C:\> dul8 > c:\temp\scan_tables.txt
scan tables;
exit;4) Identify the lost tables from the output of step 3; if you look carefully to
the output above then you will notice that the unload syntax is already given
but that the table name will be of the format t_0<objectno> and the column
names will be of the format C<no>; datatypes will not be an exact match of
the datatype as it was before. Look especially for strings like "Oid 1078 fno 6 bno 2 table number 0" where:
oid = object id, will be used to unload the object
fno = (data)file number
bno = block number
5) Unload the identified tables with the "unload table" command : DUL> unload table dept (deptno number(2), dname varchar2(14),
loc varchar2(13)) storage (OBJNO 1078)
Unloading extent(s) of table DEPT 4 rows.
cannot be retrieved otherwise. This is not an alternative for the export
utility or SQL*Loader. The database may be corrupted but an individual data
block used must be 100% correct. During all unloading checks are made to make
sure that blocks are not corrupted and belong to the correct segment. If a
corrupted block is detected by DUL, an error message is printed in the loader
file and to the standard output, but this will not terminate the unloading of
the next row or block.这段就似乎是功能概要了，说是别的方法都不行时可以从oracle里导出数据的。数据库可以损坏，但只要数据块都没问题就可以用。开始会判定数据块是不是全部完好，并归属于正确的分段。若出现错误的数据块，那么报错并导出下一行数据块。
这是哪来的？文章开头说是内部软件，不能随便分发哦
4. How to unload data when the segment header block is corrupted ?
5. How to unload data when the file header block is corrupted ?
6. How to unload data without the system tablespace ?
你是哪种情况，定了以后给你翻译翻译
REM A List of parameters for the most common platforms can be obtained from
REM http://www.nl.oracle.com/support/dul/index.html 常用平台的参数可以从这里获得
osd_big_endian_flag=false
osd_dba_file_bits=10
osd_c_struct_alignment=32
osd_file_leader_size=1
osd_word_size = 32 REM Sizes of dul dictionary caches. If one of these is too low startup will
REM fail. dul字典缓存的大小，如果其中一个过小，启动将失败
dc_columns=2000000
dc_tables=10000
dc_objects=1000000
dc_users=400
dc_segments=100000 REM Location and filename of the control file, default value is control.dul
REM in the current directory控制文件的位置，缺省为当前目录的control.dul
control_file = D:\Dul\control_orcl.dul REM Database blocksize, can be found in the init<SID>.ora file or can be
REM retrieved by doing "show parameter %db_block_size%" in server manager
REM (svrmgr23/30/l) changes this parameter to whatever the block size is of
REM the crashed database.数据库块大小，可在init<SID>.ora文件中找到，或在服务器管理svrmgr中使用show parameter %db_block_size%。
db_block_size=4096 REM Can/must be specified when data is needed into export/import format.
REM this will create a file suitable to use by the oracle import utility,
REM although the generated file is completely different from a table mode
REM export generated by the EXP utility. It is a single table dump file
REM with only a create table structure statement and the table data.
REM Grants, storage clauses, triggers are not included into this dump file !
确定数据是否需要存储为exp/imp格式，如果是，则可用于oracle的imp工具。这里数出的dump文件完全不同于exp输出文件，虽然包括了表结构语句和其中的数据，但是授权、存储子句和触发器丢失
export_mode=true REM Compatible parameter must be specified an can be either 6, 7 or 8
兼容参数，应为6,7或8
compatible=8 REM This parameter is optional and can be specified on platforms that do
REM not support long file names (e.g. 8.3 DOS) or when the file format that
REM DUL uses "owner_name.table_name.ext" is not acceptable. The dump files
REM will be something like dump001.ext, dump002.ext, etc in this case.
这个参数可选，并在不支持长文件名或不支持类似dul使用的"owner_name.table_name.ext"文件名的平台上可用。如下设定后dump文件将为dump001.ext,dump002.ext等等
file = dump
第一步中提到的dul需要的一个初始文件
A good knowledge about the logical tablespace and physical datafile
structure is needed or you can do the following queries when the database
is mounted :
需要你了解逻辑表空间、物理数据文件结构，或可在数据库加载时做一下查询
Oracle 6, 7
-----------
> connect internal
> spool control.DUL
> select * from v$dbfile;
> spool off Oracle 8
--------
> connect internal
> spool control.DUL
> select ts#, rfile#, name from v$datafile;
> spool off Edit the spool file and change, if needed, the datafile location and stripe
out unnecessary information like table headers, feedback line, etc...
A sample control file looks something like this :
若需要，编辑spool文件中的数据文件路径，去除不必要的信息，如表头等
一个样板控制文件如下
REM Oracle7 control file oracle 7的控制文件
1 D:\DUL\DATAFILE\SYS1ORCL.DBF
3 D:\DUL\DATAFILE\DAT1ORCL.DBF
7 D:\DUL\DATAFILE\USR1ORCL.DBF
REM Oracle8 control file oracle 8的控制文件
0 1 D:\DUL\DATAFILE\SYS1ORCL.DBF
1 2 D:\DUL\DATAFILE\USR1ORCL.DBF
1 3 D:\DUL\DATAFILE\USR2ORCL.DBF
2 4 D:\DUL\DATAFILE\DAT1ORCL.DBF
Note : Each entry can contain a part of a datafile, this can be useful when
you need to split datafiles that are too big for DUL, so that each
part is smaller than for example 2GB. For example :
注意：每个项目可以包含部分数据文件，当你需要分割数据文件或其相对dul过大时比较有用。所以这里每个部分都小于2GB，例如：
REM Oracle8 with a datafile split into multiple parts, each part is
REM smaller than 1GB ! Oracle8，数据文件分割为多个部分，每个都小于1G
0 1 D:\DUL\DATAFILE\SYS1ORCL.DBF
1 2 D:\DUL\DATAFILE\USR1ORCL.DBF startblock 1 endblock 1000000
1 2 D:\DUL\DATAFILE\USR1ORCL.DBF startblock 1000001 endblock 2000000
1 2 D:\DUL\DATAFILE\USR1ORCL.DBF startblock 2000001 endblock 2550000
导出/卸载对象信息 Start the DUL utility with the appropriate ddl (Dul Description Language)
script. There are 3 scripts available to unload the USER$, OBJ$, TAB$ and
COL$ tables according to the database version.
用正确的dul脚本来启动dul工具。这里根据不同数据库版本有三个脚本可以导出USER$, OBJ$, TAB$ and
COL$表
Oracle6 :> dul8.exe dictv6.ddl
Oracle7 :> dul8.exe dictv7.ddl
Oracle8 :> dul8.exe dictv8.ddl
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~If datafiles are not available for the system tablespace the unload can still
continue but the object information can't be retrieved from the data dictionary
tables USER$, OBJ$, TAB$ and COL$. So ownername, tablename and columnnames will
not be loaded into the DUL dictionary. Identifying the tables can be an
overwhelming task and a good knowledge of the RDBMS internals are needed here.
First of all you need a good knowledge of your application and it's tables.
Column types can be guessed by DUL, but table and column names will be lost.
若系统表空间的数据文件无法获得，unload仍然可以进行，但不能从USER$, OBJ$, TAB$ and COL$等数据字典表中得到对象信息。所以所有者名、表名和列名无法载入DUL字典中。识别表就成为当务之急，而这需要较好的掌握RDBMS底层知识。首先你需要了解你的应用和它的表。尽管DUL可以猜测列的类型，但表和列名将遗失。
Any old system tablespace from the same database (may be weeks old) can be a
great help !
任何同一个数据库中的旧的表空间（可以是几周之前的）都可能帮上大忙。
1) Create the "init.dul" file and the "control.dul" file as explained in above
steps 1 and 2. In this case the control file will contain all the datafiles
from which you want to restore but it doesn't require the system tablespace
information.
1)如步骤1和2所述，创建init.dul和control.dul文件。这种情况下，控制文件要包含所有你要恢复的数据文件，但不需要系统表空间信息。
2) Then You invoke dul and type the following command :
2)然后调用dul并敲入以下命令：
DUL> scan database;
data file 6 1280 blocks scanned This will build the extent and segment map. Probably the dul command
interpreter will be terminated as well.
这将建立扩展和分块图（extent and segment map）。dul命令解释器可能也会中止。
3) reinvoke the dul command interpreter and do the following :
3)重新调用dul命令解释器，并作如下工作：
Data UnLoader: Release 8.0.5.3.0 - Internal Use Only - on Tue Aug 03 13:33: Copyright (c) 1994/1999 Oracle Corporation, The Netherlands. All rights res
Loaded 4 segments
Loaded 2 extents
Extent map sorted
DUL> alter session set use_scanned_extent_map = true;
DUL> scan tables; (or scan extents;) Scanning tables with segment header用分块头来遍历表 Oid 1078 fno 6 bno 2 table number 0 UNLOAD TABLE T_O1078 ( C1 NUMBER, C2 UNKNOWN, C3 UNKNOWN )
STORAGE ( TABNO 0 EXTENTS( FILE 6 BLOCK 2));
Colno Seen MaxIntSz Null% C75% C100 Num% NiNu% Dat% Rid%
1 4 2 0% 0% 0% 100% 100% 0% 0%
2 4 10 0% 100% 100% 100% 0% 0% 0%
3 4 8 0% 100% 100% 100% 0% 0% 50%
"10" "ACCOUNTING" "NEW YORK"
"20" "RESEARCH" "DALLAS"
"30" "SALES" "CHICAGO"
"40" "OPERATIONS" "BOSTON" Oid 1080 fno 6 bno 12 table number 0 UNLOAD TABLE T_O1080 ( C1 NUMBER, C2 UNKNOWN, C3 UNKNOWN, C4 NUMBER,
C5 DATE, C6 NUMBER, C7 NUMBER, C8 NUMBER )
STORAGE ( TABNO 0 EXTENTS( FILE 6 BLOCK 12));
Colno Seen MaxIntSz Null% C75% C100 Num% NiNu% Dat% Rid%
1 14 3 0% 0% 0% 100% 100% 0% 0%
2 14 6 0% 100% 100% 100% 0% 0% 21%
3 14 9 0% 100% 100% 100% 0% 0% 0%
4 14 3 7% 0% 0% 100% 100% 0% 0%
5 14 7 0% 0% 0% 0% 0% 100% 0%
6 14 3 0% 0% 0% 100% 100% 0% 0%
7 14 2 71% 0% 0% 100% 100% 0% 0%
8 14 2 0% 0% 0% 100% 100% 0% 0%
"7369" "SMITH" "CLERK" "7902" "17-DEC-1980 AD 00:00:00" "800" "" "20"
"7499" "ALLEN" "SALESMAN" "7698" "20-FEB-1981 AD 00:00:00" "1600" "300" "30"
"7521" "WARD" "SALESMAN" "7698" "22-FEB-1981 AD 00:00:00" "1250" "500" "30"
"7566" "JONES" "MANAGER" "7839" "02-APR-1981 AD 00:00:00" "2975" "" "20"
"7654" "MARTIN" "SALESMAN" "7698" "28-SEP-1981 AD 00:00:00" "1250" "1400" "30" Note : it might be best that you redirect the output to a logfile since
commands like the "scan tables" can produce a lot of output.
On Windows NT you can do the following command :
注意：由于scan tables这类命令可能产生很多输出，最好将输出重定向到一个日志文件。在Windows NT上你可以如下操作：
C:\> dul8 > c:\temp\scan_tables.txt
scan tables;
exit;4) Identify the lost tables from the output of step 3; if you look carefully to
the output above then you will notice that the unload syntax is already given
but that the table name will be of the format t_0<objectno> and the column
names will be of the format C<no>; datatypes will not be an exact match of
the datatype as it was before.
4)从第三步的输出中分辨出丢失的表；若你仔细察看上面的输出，你会注意到unload语法已经给出，但表名格式类似t_0<objectno>，列名格式类似C<no>；数据类型与原来也未必一致。
Look especially for strings like "Oid 1078 fno 6 bno 2 table number 0" where:
oid = object id, will be used to unload the object
特别要观察类似"Oid 1078 fno 6 bno 2 table number 0"的字符串，其中oid 为对象id，可用于恢复对象。
fno = (data)file number
bno = block number
5) Unload the identified tables with the "unload table" command :
5) unload分辨出来的丢失的表
DUL> unload table dept (deptno number(2), dname varchar2(14),
loc varchar2(13)) storage (OBJNO 1078)
Unloading extent(s) of table DEPT 4 rows.
----------------------------------------------------------------------
我能做的都帮你做完了，怎么用还是要你自己琢磨，祝你好运，新年快乐！