7 x 24 在线支持!
用DUL Data UnLoader拯救Oracle数据
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com
DUL FOR LINUX平台(已更新为PRM-DUL)
DUL FOR Windows平台 (已更新为PRM-DUL)
-
Chapter 1: 概况
-
Chapter 2: 基础知识
-
Chapter 3: 参数和命令
-
Chapter 4: 简单数据恢复场景
-
Chapter 5: 复杂数据恢复场景
-
Chapter 6: 加载数据
-
Chapter 7: 内部文件
-
Chapter 8: 实验
- 前提:
-
初步了解Oracle 数据库架构
- 高级别文件结构
- 实例进程
-
初步了解Oracle 数据库操作
- 数据库状态: started, mounted, open, shutdown
- 导出/导入工具
- SQL*Loader
- 概念
- 何时使用Data UnLoader?
- “正常的” 数据恢复
- 特性
- 限制
- 主要的适用范围
- 预期结果
Overview: 概念: 何为Data UnLoader?
- 由Bernard van Duijnen开发的一个C程序
- 仅直接从数据库文件(*.dbf)的表和簇中提取数据
- 建立标准的Dump导出 files (*.dmp) 或 SQL*Loader 控制/数据文件的组合 (.ctl/.dat) 以将数据导入一个新的或功能数据库中
- 一个不依赖于正被安装或打开的数据库实例的独立的实用程序
DUL 仅严格用于支持和内部使用.
Overview: 概念: 如何使用它
-
通过直接扫描数据文件(.dbf)恢复格式化的数据
- 如可用,数据/段/范围信息和元数据从SYSTEM.dbf文件提取
- 如 SYSTEM.dbf 文件不可用,使用启发式和用户知识提取数据/段/范围信息
- 脏读 (仅写入磁盘的数据被提取; 内存中的数据丢失; 归档日志不被使用)
- 作为替代方案,后来改进了从标准export (.exp)或数据pump 文件 (.edp) 中提取数据 (虽然仍是一个正在进行中的任务)
Overview: 概念:安全
-
数据安全
-
因为DUL直接读取.dbf 文件
- 数据库可彻底瘫痪
- 没有审核访问的数据库userid
- 提取的数据很容易读取
-
因为DUL直接读取.dbf 文件
-
程序安全
- DUL 可执行文件的可用性和分布必须严格限制和控制
概念: 历史
-
过去
- 工程师只能现场操作
- 工程师负责从客户机安装和移除DUL可执行文件
-
现在
- 远程是首选, 更快的交付方法
- 一些低级别的、基于时间的“复制”保护已实现使 DUL 45天后失效
注意: 大部分政府合同不允许远程访问,现场是唯一选择。
概念: “远程” 访问选项
-
客户可直接访问主机(VPN/putty)
- 这通常涉及到客户的安全部门,要么被拒绝要么花费很长的时间得到全部批准
-
开展 Webex 或 Beehive 共享会话来查看和控制与DBA的活动
- DUL.exe 需要通过电子邮件或ftp发送到DBA
-
通过这个过程在电话里讨论DBA
- DUL.exe需要通过电子邮件或ftp发送到DBA
- 预配置控制文件, 电子邮件到DBA, 接收日志
- ASE 应该相当了解DUL
何时使用Data UnLoader?
- 一般而言,由全球产品支持 (GPS) 根据服务请求做出决定。
- 仅当所有记录和非法数据恢复方法被评估和拒绝后
- 当“正常的”数据库/数据恢复方法不适用或不可行时
Ø注意: 虽然该过程最显著的使用是用于一个瘫痪的数据库,不过当数据库启动, 只有部分数据丢失或损坏时也可以使用。
-
例子
- 客户没有可用的备份
- 备份/档案不足导致数据丢失
- 内部错误或损坏导致数据库无法打开
- 使用正常的恢复方法, MTTR(平均修复时间)是不可接受的 (i.e. 归档日志太多无法应用)
- 系统数据文件丢失
- 损坏的数据文件采取了表空间脱机
- DUL旨在检索通过其他手段无法检索到的数据
- 它不是数据库恢复的一个替代方案
- 它是最后手段, 不是为正常的生产使用
- 注意: 可能与检索到的数据逻辑不一致。
Ø不保证一定会成功!
- 这主要是因为损坏的不可预测性,且不是所有的数据库特性和数据类型都已实现。
何时使用Data UnLoader?
- DUL旨在检索通过其他手段无法检索到的数据
- 它不是数据库恢复的一个替代方案
- 它是最后手段, 不是为正常的生产使用
- 注意: 可能与检索到的数据逻辑不一致。
Ø不保证一定会成功!
- 这主要是因为损坏的不可预测性,且不是所有的数据库特性和数据类型都已实现。
“正常的” 数据库恢复
-
当前数据库恢复选项(手动)
- 恢复上次备份,并用归档日志前滚
- 从上次完全备份导出导入
- 使用 SQL*Loader 从源数据重新加载数据
- 使用并行创建表选择(PCTS)
- 使用传输表空间
- 建立一个克隆数据库, 导出数据, 然后导入
-
RMAN (更自动化)
- 用适当的指令启动一个RMAN 会话
-
无证 init.ora 数据库参数
- _corrupted_rollback_segments
- _allow_resetlogs_corruption
-
诊断/编辑工具
- opatch (非常老的工具, 参见Notes 28864.1, 33182.1)
-
块浏览器/编辑器(BBED)
- 注意: BBED 不再是以 11g开始的分布式
“正常的” 数据库恢复: 限制
- 在系统表空间或数据文件丢失的情况下没有替代品
- 数据库必须处于相当良好的状态,否则即使有无证参数,也不可能恢复
-
编辑数据文件是繁琐的、危险的,且不保证起作用。
- 大量的内部结构知识是必需的
- 某些损坏无法编辑
支持的特性
- 可支持Oracle v6 到 v11 (12?)
-
可用于多个(并非全部) 平台
- Linux, AIX, Solaris, Windows
- 自8/13/12起,DUL for HP-UX 不可用
- 跨平台提取成为可能
- 不是标准恢复方法的一个替代方案
- 不是一个官方支持的工具
- 仅作为最后手段使用!
- 如系统数据文件可用,读取数据字典
-
不过,没有系统数据文件也可提取数据
- 如果没有系统数据文件, 用户/对象/列的名称都会丢失
- 可卸载单个表, 按模式(用户)的表 ,按对象数量的表, 或整个数据库
- 可从不完备表卸载区段
-
可跨平台卸载
- i.e. 从Windows上卸载, 在UNIX上加载
- 支持标准的Oracle数据库结构
支持的特性:结构
- 链接行, 迁移行
- hash/index 集群
- longs, raws, blobs
- rowids, dates, numbers
- 多个空闲列表组
- 段高水位segment high water mark
- 无限盘区unlimited extents
- 分区表
支持的 “新” 特性
- 可配置为自动存储管理(ASM)
- 简化配置(表空间和相对的文件号现在直接从.dbf 文件读取)
- Unexp (从一个导出文件中提取)
- Unpump (从一个数据pump文件中提取)
- SQL*Loader 现在可用于long raws和blobs
-
注意: DUL 当前版本为 10.2.0.5.31
- 基础版本从6/9/2011开始
Limitations / Restrictions
- 数据库可以损坏,但单个模块必须是好的。一个错误将去到每个坏块的日志。
- DUL仅卸载表和集群数据
- 不支持MLSLABELS
- 不支持多字节字符集
- 不支持一些11 g 特性(i.e. 加密)
- DUL v10 可用于v11 datafiles
11g 特性的限制 (11/2012)
- 11g 安全文件lobs 正处于beta测试阶段
- 标签安全还不支持
- 加密还不支持
- 还不支持 exadata cells上的ASM磁盘
- 区大小可变的11g ASM 和 ASM 条带化是最近可用的支持
- export_mode中不支持复杂类型
- export_mode中生成的dump文件=true 不包含元数据
主要的适用范围
-
在继续进行engegement之前, 弄清楚:
- 什么平台? OS version? DB version? Blocksize?
- Is the DB up or down? 能否安装? 打开?
- SYSTEM.dbf 数据文件是否可用? 是否可读?
- 远程访问是否可行? 必须现场操作吗?
- 需要提取的数据库或表有多大?
- 首选哪个数据格式? Export? SQL*Loader?
- 是否有足够的可用磁盘空间输出?
- 提醒客户不保证一定会成功。
预期结果
-
从 ASE
- 评估客户的环境和条件
- 确定需要或者要求什么数据
- 配置 DUL 以提取数据
- “尽最大努力” 运行DUL 把用数据导出的 dump 文件 或SQL Loader 文件提供给客户
-
帮助客户
- 解读DUL日志
- 规划加载和验证数据
-
从客户那里
- 访问所有必需的 .dbf 文件 (telnet, owc, ftp?)
- 建立新数据库(如当前数据库打不开时需要)
- 加载和验证数据
- 若SYSTEM.dbf 丢失, 在应用程序开发人员或功能工作人员的帮助下重命名应用程序对象和列
- 重建所有所需的丢失的对象(索引, triggers..)
- 验证应用程序功能
-
客户一般会问的问题
-
一个DUL engagement 需要多久?
-
安装时间取决于The setup time depends on
- 什么 .dbf 文件可用, 地点和时间
- 遇到的是哪种损坏?
- 抽取时间取决于数据库的大小
-
解读结果的时间取决于
- SYSTEM.dbf 的可用性
-
重新加载新数据库的时间
- 几次加载完成后,那时客户也许不需要ASE
-
安装时间取决于The setup time depends on
-
一个DUL engagement 需要多久?
DUL的未来
- Bernard 继续改进DUL, 即使要支持11g 和12c的新特性如加密和压缩会更加困难。
Ø随着更多的客户接受不被支持的新特性, DUL 应用将受到更多限制。
- 新版本的Oracle 数据库具有附加数据保护/恢复功能(i.e. 回收站, flash 恢复/闪回项)
Ø随着更多的客户接受最新的恢复特性,对DUL的呼声应该越来越少。
- 总是会有硬件/软件故障和人为错误造成数据库崩溃,导致数据丢失。
- 总是会有客户使用旧版本的数据库。
- 虽然有限制,DUL仍将是拯救数据有价值的工具。
1) 配置和运行DUL后, dul.log中出现了一个未知错误。下列哪一项操作能够迅速得到帮助?
发送电子邮件到service@parnassusdata.com 或呼叫手机 + 86 13764045638
3) DUL运行的输出是什么?
a)Export .dmp files
b)SQL*Loader .dat files
c)SQL*Loader .ctl files
d)A dul.log
e)全部都是
f)没有输出, DUL 当场恢复数据
4) 只要客户有一个好的SYSTEM.dbf 数据文件, DUL 就能提取所有必需的用户数据,格式化一个 dump 导出文件或 SQL*Loader .dat 数据文件。
a)True
b)False
5) 只要客户有一个好的SYSTEM.dbf datafile, 对客户来说唯一的额外工作就是导入export 文件或运行SQL*Loader。
a)True
b)False
6) 当客户丢失SYSTEM.dbf datafile, DUL仍旧能提取可用数据。 ASE将重命名其相应应用程序可用身份的表和列名称。
a)True
b)False
第2章: 基础知识
-
前提:
-
对Oracle数据库服务器有深入了解
- imp 工具的使用, 交互式和批处理模式
- SQL*Loader的使用
-
对UNIX/Windows 命令行级有初步了解
- vi 或UNIX上的其他文本编辑器
- Windows上的记事本
- 下载 DataUnLoader_Toolkit.zip
-
- 下载 DataUnLoader_Labs.zip
-
对Oracle数据库服务器有深入了解
- Data UnLoader 架构
- 需要什么?
- 配置 DUL
- 安装和运行DUL
- 检查输出日志
Data UnLoader 架构
-
INPUT
- .dbf datafiles (可为脱机副本, 在备用位置)
- 2 .dul “控制” 文件 (不是DB 控制文件)
- DUL> 提示符下的用户命令
- dul.exe 或 dul (单个文件大约500k)
-
OUTPUT
- .dmp files (用于稍后导入) 或
-
.ctl 和 .dat files (for SQL*Loader)
- 命名为 schema_tablename.filetype
- 日志文件(dul.log)
需要什么?
- 丢失数据? 得到 .dbf? 需要 dul.exe? 去
- 为你想要的平台下载可执行文件
- 最佳实践: 如果去现场,提前下载所有的平台,以防后来内部Oracle访问被禁止。
- 建立和配置init.dul
- OS 和 DB 相关的参数, 指令
- 建立和配置control.dul
- 映射数据文件到磁盘上的位置
- 现在支持ASM (新特性)
配置init.dul
- 包含帮助DUL了解datafiles (.dbf)的格式和平台,以及使用什么输出格式的参数
-
这个纯文本文件中的信息指定了
- DUL 缓存大小
- header布局的细节
- Oracle 块大小
- 输出文件格式
- Sql*Loader 格式和记录大小
- 其他可选指令
- 配置DUL 缓存大小
-
这些必须足够大才能容纳来自DBA_TAB_COLUMNS, _TABLES, _OBJECTS, and _USERS 表的所有条目
- DC_COLUMNS =
- DC_TABLES =
- DC_OBJECTS =
- DC_USERS =
- 注意: DUL现在使用这些作为最小值,且运行时可根据需要动态地增加。
- 配置平台相关的参数
- OSD_BIG_ENDIAN_FLAG = true/false
-“字节序” 处理一个结构中位的排序
-在高位优先平台上, 一个词的四个字节按倒序分配,从高到低
-Little endian ordering 是指将低位字节存储在最低有效地址上
–注意: 对于 DB >= 10g, 这是所需的唯一osd parm
- OSD_DBA_FILE_BITS =
-数据基地址中用于文件号低阶部分的位数。
- OSD_C_STRUCT_ALIGNMENT =
-数据文件头中的结构布局。
- OSD_FILE_LEADER_SIZE =
-Oracle 文件头之前的块/字节数。 Unix datafiles 有一个额外的头块 (文件大小, 块大小幻数)
平台特定参数值
PORT PLATFORM ENDIAN FBITS67 FBITS8 CSTR LEAD WORD
1 Digital VAX OpenVMS FALSE 8 – 0 0 32
2 HP Series 9000 HP-UX TRUE 6 10 32 1 32
21 Novell Netware (Oracle7) FALSE 8 – 0 1 32
21 Novell Netware (Oracle8) FALSE – 8 32 1 32
22 MS DOS FALSE 8 – 16 512 16
46 Intel based server LINUX FALSE – 10 32 1 32
87 Digital Unix FALSE 6 10 32 1 32
89 Alpha Vms FALSE 8 10 32 0 32
168 Silicon Graphics UNIX TRUE 6 ? 32 1 32
172 Intel Solaris FALSE 5 ? 32 1 32
198 Sequent Dynix/PTX FALSE 6 ? 32 1 32
319 IBM RS 600 AIX TRUE 8 10 32 1 32
358 NCR Intel FALSE 8 ? 32 1 32
453 Sun Sparc Solaris TRUE 6 10 32 1 32
601 MS Windows NT Alpha FALSE 8 8 32 512 32
615 MS Windows 95 FALSE 8 ? 32 512 32
912 MS Windows NT Intel FALSE 8 10 32 1 32
Explanation of the values:
ENDIAN OSD_BIG_ENDIAN_FLAG
FBITS67 OSD_DBA_FILE_BITS (Oracle version6/Oracle7)
FBITS8 OSD_DBA_FILE_BITS (Oracle8 and greater)
CSTR OSD_C_STRUCT_ALIGNMENT
LEAD OSD_FILE_LEADER_SIZE
WORD OSD_WORD_SIZE
配置init.dul
-
数据库特定参数
- db_block_size = 8192 /* db default block size */
- compatible = 9 /* db version */
-
Sql*Loader 或导出格式参数
- export mode = false /* for sql*loader, true=exp */
- ldr_enclose_char = ” /* delimiter for sql*loader */
- ldr_phys_rec_size = 81 /* output length */
- 注意: 其他参数和值会在第3章详细介绍。
dc_columns = 200000
dc_tables = 40000
dc_objects = 40000
dc_users = 2048
osd_big_endian_flag = true # Only osd parm needed on >=10g
osd_dba_file_bits = 10
osd_c_struct_alignment = 32
osd_file_leader_size = 1
osd_word_size = 32
db_block_size = 8192
compatible=9
export_mode=false
ldr_enclose_char = ”
ldr_phys_rec_size = 81
最小 init.dul
ØDUL 现在试图从dbf头中找出所有的配置参数
ØInit.dul 只需要:
ØCOMPATIBLE=n
ØOSD_BIG_ENDIAN_FLAG=true/false
–仅对于跨平台
Ø当指定时, DUL 将使用你贴在init.dul中的参数值
ØGENERIC_init.dul 包含在DUL ToolKit中
配置一个 control.dul
-
指定要提取的数据目前位于哪儿
- Datafile 位置可在操作系统级别获取
- 如数据库可安装, 使用 v$datafile上的SQL
-
现在支持3种格式的行条目
- file_piece_spec (传统的)
- asm_disk_spec
- block_index_spec
control.dul: file_piece_spec
- [[tablespace_no] relative_file_number] data_file_name
[ extra_leader_offset ]
[ startblock block_no ]
[ endblock block_no ]
[ block_size nk ]
注意: 新版本>= 10, the tablespace_no 和 relative_file_number 是 可选的! 他们现在可直接从.dbf file header 中读取(如果没损坏)。
建立 control.dul: file_piece_spec
如数据文件头被损坏或因其它原因无法访问dul,你可以运行以下SQL,如果数据库可安装,或来自一个备用数据库。
sqlplus /nolog
connect / as sysdba
startup mount
set trimspool on pagesize 0 linesize 256 feedback off
column name format a200
spool control.dul
select ts#, rfile#, name from v$datafile;
exit
- 前面的 SQL 假设数据库被安装
- 不过,也可能从一个数据库控制文件中生成 control.dul
- >strings <controlfile> >control.dul
- 你可以通过从另一个数据库转储获得ts# and rfile# 号(如版本< 10)
Øalter system dump datafile ‘c:\app\jdydek\oradata\orcl\users01.dbf’
block min 1 block max 2;
Ø在追踪文件中寻找以下字段:
文件号=4
RelFno: 4
样例输出: 更改系统dump数据文件
Start dump data block from file D:\MY_DATA\DULCLASS\USERS.DBF minblk 1 maxblk 2
V10 STYLE FILE HEADER:
Compatibility Vsn = 169869568=0xa200100
Db ID=2596130611=0x9abdcf33, Db Name=’XE’
Activation ID=0=0x0
Control Seq=323=0x143, File size=12800=0x3200
File Number=4, Blksiz=8192, File Type=3 DATA
…
File Space Header Block:
Header Control:
RelFno: 4, Unit: 8, Size: 12800, Flag: 9
AutoExtend: YES, Increment: 1280, MaxSize: 655360
Initial Area: 7, Tail: 12800, First: 42, Free: 1557
Deallocation scn: 0.0
Header Opcode:
Save: No Pending Op
End dump data block from file D:\MY_DATA\DULCLASS\USERS.DBF minblk 2 maxblk 2
control.dul: 可选的ts# 和 file#
0 1 /p012/oracle/GTU5ASP/system.dbf
1 2 /p014/oracle/GTU5ASP/undotbs01.dbf
2 3 /p015/oracle/GTU5ASP/sysaux01.dbf
4 4 /p028/oracle/GTU5ASP/pinn_data01.dbf
0 5 /p030/oracle/GTU5ASP/system02.dbf
4 6 /p020/oracle/GTU5ASP/pinn_data02.dbf
1 7 /p018/oracle/GTU5ASP/undotbs02.dbf
4 8 /p033/oracle/GTU5ASP/pinn_data03.dbf
通过以‘安装’模式在数据库上运行下列SQL可得到以上。
Øselect ts#, rfile#, name from v$datafile;
注意: 即便没有ts# and rfile#, 这对于获取所有数据文件名称也是有用的
# AIX version 7 example with one file on raw device
1 /usr/oracle/dbs/system.dbf
8 /dev/rdsk/data.dbf 4096
注意:可选的第三字段是一个将被添加到该数据文件所有fseek()操作的额外的正或负字节偏移。
# Oracle8 example with a datafile split in multiple parts,
# each part smaller than 2GB
0 1 /fs1/oradata/PMS/system.dbf
12 /tmp/huge_file_part1 startblock 1 endblock 1000000
21 /tmp/huge_file_part2 startblock 1000001 endblock 2000000
32 /mnt3/huge_file_part3 startblock 2000001 endblock 2550000
/p012/oracle/GTU5ASP/system.dbf
/p014/oracle/GTU5ASP/undotbs01.dbf
/p015/oracle/GTU5ASP/sysaux01.dbf
/p028/oracle/GTU5ASP/pinn_data01.dbf
/p030/oracle/GTU5ASP/system02.dbf
/p020/oracle/GTU5ASP/pinn_data02.dbf
/p018/oracle/GTU5ASP/undotbs02.dbf
/p033/oracle/GTU5ASP/pinn_data03.dbf
注意: dul v10 如果没损坏,现可直接从dbf headers 读取表数和相关的文件号。
control.dul: asm_disk_spec
- DISK device name [ disk group options ]
- disk group option ::=
GROUP disk group name |
DISK_NO disk number in group |
F1B1 File1 Block1 location
- 注意:设备名称通常是足够的。其他属性从文件头检索
样例 control.dul: asm_disk_spec
# ASM disks for disk groups
disk /media/maxtor/asm/dgn1
disk /media/maxtor/asm/dgn2
disk /media/maxtor/asm/dgn3
disk /media/maxtor/asm/dgodd
# 第一个asm磁盘组中的系统数据文件
+DGN/db102/datafile/system.257.621616979
# 不同磁盘组中的用户数据文件
+DGODD/db102/datafile/users.257.621616683
- 11/27/12: 最新的DUL 可执行文件有一个新的asm层支持细粒度分段和可变区段大小。
control.dul: block_index_spec
- BLOCK INDEX block_index_name
- 块索引是访问损坏文件系统上Oracle块的一种方式
- 在使用 in control.dul之前, 使用DUL 命令:
- CREATE BLOCK INDEX index_name ON device ;
- 这对于合并多个磁盘映像或从损坏的文件系统卸载是有用的。仅仅在极端的文件系统损坏场景中有用。
安装和运行DUL
- dul.exe 是命令和参数驱动, 使用一个类似于SQL*Plus (约18个命令)的结构
- 有关命令详细信息参阅第3章和在线手册
- 没有“安装”程序。 仅复制.exe 程序到所需的目录。用文本编辑器建立init.dul 和 control.dul。
- 从一个 UNIX shell 或Windows DOS 提示符运行DUL。
- >./dul.exe /* for UNIX */
- >dul /* for Windows */
- 最佳实践: DUL 输出去到可执行文件所在的目录。 为dul.exe 和输出建立一个单独的目录,同时让control.dul 控制输入。
运行 DUL: 常用命令
-
一些常用的标准命令(交互式或批处理)
- SHOW PARAMETERS; /* display all parm settings */
- BOOTSTRAP; /* read dictionary metadata */
- SCAN DATABASE; /* scans all known datafiles */
- SCAN TABLES; or SCAN EXTENTS;
- UNLOAD DATABASE; /* extracts all users/tables */
- UNLOAD TABLE schema.table (…..) ;
- UNLOAD USER user_name;
- UNLOAD OBJECT number;
- EXIT; or BYE; /* end dul session */
- 第3 章将回顾所有命令的详细内容。
“新” 命令 / 特性
- 更新在线用户指南 (越来越完善)
- ASM 支持 (control.dul 格式是不同的)
- SCAN LOB SEGMENT FOR …
- UNEXP TABLE schema.table_name
- UNPUMP … (wip, check with Bernard)
-
dul.exe 有一些内置的“复制” 保护
- 总是下载当前版本
-
Date sensitive inactivation 可能会阻止程序执行
- 目前无法启动
- 你需要一个该操作系统的最新DUL版本
检查dul.log
- dul.exe 每次连续执行都会创建一个日志
- 默认该日志被命名为“dul.log”
-
当DUL多次运行时,
- 默认每次运行将覆盖the dul.log
- 设置RESET_LOGFILE=false,每次运行添加 dul.logs 或在两次运行之间重命名dul.log
- 注意: 虽然你在init.dul中可能只设置了约10个参数,实际上约有50个可能的参数。那些没设置的都有默认值。 日志将显示某次特定运行的所有参数值。
样例 dul.log
DUL version 10.2.0.5.17 with 64-bits i/o
Init.dul parameter settings:
_SLPE_DEBUG = FALSE
ALLOW_CHECKSUM_MISMATCH = FALSE
ALLOW_DBA_MISMATCH = FALSE
ALLOW_OTHER_OBJNO = FALSE
ALLOW_TRAILER_MISMATCH = FALSE
ASM_DO_HARD_CHECKS = TRUE
AUTO_UPDATE_CHECKSUM = TRUE
AUTO_UPDATE_TRAILER = TRUE
BUFFER = 1048576
CF_FILES = 1022
CF_TABLESPACES = 64
COMPATIBLE = 10
CONTROL_FILE = control.dul
DB_BLOCK_SIZE = 8192
DB_NAME =
…
UNEXP_VERBOSE = FALSE
USE_LOB_FILES = FALSE
USE_SCANNED_EXTENT_MAP = false
VERIFY_NUMBER_PRECISION = TRUE
WARN_RECREATE_FILES = TRUE
WRITABLE_DATAFILES = FALSE
Reading USER.dat 42 entries loaded
Reading OBJ.dat 16246 entries loaded and sorted 16246 entries
Reading TAB.dat 1512 entries loaded
Reading COL.dat 58768 entries loaded and sorted 58768 entries
Reading TABPART.dat
DUL: Error: File TABPART.dat, line 1: token missing
DUL: Warning: Ignoring file TABPART.dat cache
Database national character set is AL16UTF16
Entries from control file control.dul:
DUL: Error: open( ‘C:\ORACLEXE\ORADATA\XE\SYSTEM.DBF’, Read Only)
OS error 2: No such file or directory
DUL: Error: open( ‘C:\ORACLEXE\ORADATA\XE\DULDAT01.DBF’, Read Only)
OS error 2: No such file or directory
DUL: Error: open( ‘D:\DULDAT02-corrupt.DBF’, Read Only)
OS error 2: No such file or directory
DUL> show parameters
…
DUL> bye
Goodbye
简单 vs. 复杂的数据抽取
- 简单: 有 SYSTEM datafile
- 模式名、表名、列名和属性都可访问
- BOOTSTRAP; 从数据字典读取信息
- 复杂: 无 SYSTEM 表空间
- 模式名、表名、属性名必须由客户进行映射
- 扫描数据库;扫描表;
或扫描区段;
- 设置 use_scanned_extents_map=true 以卸载
其他复杂数据抽取
-
复杂: 有或者无SYSTEM.dbf
- 从一个截断表中抽取数据
- 从一个dropped 表中抽取数据
- 从一个deleted 表中抽取数据
- 从一个部分被插入的截断表中抽取原始数据
- 注意: 从10g开始, 新数据库特性(i.e. 回收站, 闪回) 可避免许多上述场景, 但前提是他们被适当配置。
Preparing to engage
-
DUL 预检问题列表
- 通过e-mail 或 scoping call获得预检答案
- 设定客户预期值
-
为平台下载当前的exe zip/gz 文件
- DUL 工具 (注意: 日期有效的复制保护)
- DUL 手册
-
如去现场, 复制到一个CD 或 USB 驱动上
- 注意应使所有的平台都可以容纳在一个CD上。
- 跨平台DUL 是可能的
- 如不去现场, 通过e-mail 或 ftp 给客户
1) 如配置错误且DUL生成错误信息,需要采取哪些步骤来重新运行?
a)修改参数并重启
b)重装 DUL 并移动.dbf 文件到一个新目录
c)备份日志和数据文件
d)DUL 无法重新运行
2) 解释这些文件的功能:
a)init.dul
b)control.dul
c)dul.exe
d)dul.log
e)system.dbf
3) 解释发生下列情况后数据字典状态的不同之处以及使用哪种方法抽取数据:
a) 数据库打不开
b) 数据库不能加载
c) 一个表被截断
d) 表行被deleted
e) 一个表被dropped
参数和命令
-
前提:
-
对Oracle 数据库服务器有深入了解
- imp 工具的使用, 交互式和批处理模式
- SQL*Loader的使用
-
对UNIX/Windows 命令行级有初步了解
- vi 或UNIX上的其他文本编辑器
- Windows上的记事本
-
对Oracle 数据库服务器有深入了解
- 启动序列
- 最有用的参数
- 很少使用的参数
- 无证参数
- 最有用的命令
- 很少使用的命令
启动序列
>dul [可选的命令文件名]
1.参数文件(默认“init.dul“) 被处理。
2.控制文件 (默认 “control.dul”) 被处理。
3.尝试将USER$, OBJ$, TAB$ 和 COL$的dumps,如可用,加载进 DUL的数据字典缓存中。
4.尝试加载seg.dat 和 col.dat。
5.显示 “DUL>” 提示符并接受命令(或运行指定作为命令行中第一个参数的文件名中的命令)
-
CONTROL_FILE = control.dul
- .dbf 位置输入来源的文件名
- “control.dul” 是默认的
-
LOGFILE = dul.log
- 运行输出写入的文件名
- “dul.log” 是默认的
- RESET_LOGFILE = [TRUE/false]
- 如为 true, DUL 每次运行都会覆盖前面的dul.log
- DB_NAME=text
-
DB_ID=number
- 这些可选参数可用于确切地告知 DUL 处理哪个数据库实例(通过名称或 id)。
- 如客户无意中从多个数据库提供.dbf文件时有用。
- DUL 将报告dul.log中不匹配的.dbf 文件
- 最好从control.dul中移除这些 .dbf 文件,并重新运行dul 会话。
-
EXPORT_MODE=[true/false]
- 如为 true, DUL 输出导出(.dmp) 文件
- 如为 false, DUL 输出 SQL*Loader 文件 (.dat and .ctl)
-
当使用SQL*Loader 输出时
- LDR_ENCLOSE_CHAR = “ /* delimiter char */
- LDR_OUTPUT_IN_UTF8 =[true/false]
-
LDR_PHYS_REC_SIZE = 81
- If 0, 无固定大小; 每行以新行字符结尾
- If >2, 每行为一个固定大小
-
BUFFER=1048576
- 指定大量字节缓冲一个行
- 行输出缓冲区大小以export和SQL*Loader两种模式使用
- 每行首先被存储在该缓冲区
- 只有完整无错误的行被写入输出文件
- 如超过该值,DUL将失败,必须重启
- 大多数情况下,默认的1M 足够。 不过如因缓冲区太小错误导致dul失败,也不要惊慌
-
FILE_SIZE_IN_MB=number
- 一个数字指定最大dump (.dmp) 文件大小,以MB为单元。默认的0意味着无限制 。
- 当客户磁盘空间有限时,它是有用的
- 当 DUL运行时,大于它的Dump文件被分到多个块
- 这给了客户一个机会复制文件到另一个文件系统,并通过删除回收空间
- 每个部分dump 文件可独立导入
最有用的参数
-
COMPATIBLE=[6,7,8,9,10,11]
- 指定数据库版本
-
DB_BLOCK_SIZE=8192
- 指定默认数据库块大小
-
USE_SCANNED_EXTENT_MAP = [FALSE/true]
- 当为 false (默认值), 使用来自seg header的区段映射
- 当为 true, 使用通过SCAN命令建立的external ext.dat文件中的区段映射卸载表
- 当多个复杂情况要求时,ext.dat 可能分别在不同的运行中生成。
很少使用的参数
-
ALLOW_CHECKSUM_MISMATCH = FALSE
- 如为 true, 跳过检查块校验和
-
ALLOW_DBA_MISMATCH = FALSE
- 如为 true, 跳过检查块地址
-
ALLOW_OTHER_OBJNO = FALSE
- 如为true, 跳过检查有效对象数
-
ALLOW_TRAILER_MISMATCH = FALSE
- 如为true,跳过检查block trailer
- 将以上这些设置为TRUE之前请谨慎操作!
-
FILE = text
- text 用作一个生成8.3 DOS 文件名的基础
-
MAX_OPEN_FILES = 8
- 最大#dbfs 同时在操作系统级别开着
-
PARSE_HEX_ESCAPES = FALSE
- 解析时使用\\xhh 十六进制转义序列? No
- 如设置为TRUE, 则可指定 \\ 字符串以使用转义序列
- 这也用于指定多字节字符
-
WARN_RECREATE_FILES = TRUE
- 如为 true, 当文件被覆盖时,日志警告消息
- 如为 false, 抑制警告消息
-
WRITABLE_DATAFILES = FALSE
- 如为 false (默认), DUL 确保为只读
- 如为 true, DUL 可在命令模式下做一些有限的数据文件编辑
无证参数
- _SLPE_DEBUG=FALSE
- ASM_DO_HARD_CHECKS = TRUE
- AUTO_UPDATE_CHECKSUM = TRUE
- AUTO_UPDATE_TRAILER = TRUE
- CF_FILES = 1022
- CF_TABLESPACES = 64
- DEFAULT_CHARACTER_SET =
- DEFAULT_NATIONAL_CHARACTER_SET =
- DB_ID =
- DB_NAME =
- FEEDBACK = 0
- OSD_MAX_THREADS = 1055
- SCAN_DATABASE_SCANS_LOB_SEGMENTS = TRUE
- SCAN_STEP_SIZE = 512
- TRACE_FLAGS = 0
- UNEXP_MAX_ERRORS = 1000
- UNEXP_VERBOSE = FALSE
- USE_LOB_FILES = FALSE
- VERIFY_NUMBER_PRECISION = TRUE
最有用的命令
-
[ALTER SESSION] SET init.dul parameter = value ;
- 大多数参数可动态改变
-
BOOTSTRAP;
- 这扫描数据字典并构建外部文件,用于在稍后的卸载命令中映射用户、表、区段和列
- 如 SYSTEM.dbf 可用
- DESCRIBE owner_name.table_name ;
- REM any_text_till_end_of_line
- REM 不允许在ddl 语句内
-
SCAN DATABASE;
- 扫描所有配置数据文件的所有块。
- 生成两个或三个文件
- SEG.dat
–发现段标题
- EXT.dat
–连续的表/集群数据块
- SCANNEDLOBPAGE.dat
–每个lob datablock的信息
–If SCAN_DATABASE_SCANS_LOB_SEGMENTS=TRUE
-
SCAN TABLES;
- 使用 SEG.dat 和 EXT.dat 作为输入。
- 扫描所有数据段中的所有表(一个头信息块和至少一个表一个匹配区段).
-
SCAN EXTENTS;
- 使用 SEG.dat 和 EXT.dat 作为输入。
- 其所有区段,没找到相应的段头。只有当一个表空间不完整,或一个段头损坏才有用。
-
SHOW DBA dba ;
- dba to file_no block_no calculator
-
SHOW DBA rfile_no block_no ;
- file_no block_no to dba calculator
-
SHOW SIZES ;
- 显示了重要结构的大小
-
SHOW PARAMETER;
- 显示了所有参数的当前值
-
SHOW LOBINFO;
- 显示了扫描数据库找到的lob 索引
-
SHOW DATAFILES;
- 配置数据文件汇总
-
SHOW ASM DISKS;
- 配置asm磁盘汇总
-
SHOW ASM FILES;
- asm上 配置数据文件汇总
-
SHOW ASM FILE cid
- asm 文件的范围信息
- UNLOAD DATABASE; /* everything except SYS */
- UNLOAD USER user_name;
- UNLOAD [TABLE] [ schema_name.] table_name [ PARTITION ( partition_name ) ]
[ SUBPARTITION ( sub_partition_name ) ]
[ ( column_definitions) ]
[ cluster_clause ]
[ storage_clause ] ;
- UNLOAD EXTENT table_name
[ ( column_definitions ) ]
[ TABLESPACE tablespace_no ]
FILE extent_start_file_number
BLOCK extent_start_block_number BLOCKS extent_size_in oracle_blocks ;
- UNLOAD LOB SEGMENT FOR
[schema_name.]table_name [(column name)] ;
- UNLOAD LOB SEGMENT STORAGE
( SEGOBJNO data obj#) ;
- EXIT, QUIT, EOF, BYE all cause DUL to terminate.
-
COMMIT;
- 将改变块写入数据文件
- 很多时候, DUL 用作READ-ONLY!
-
CREATE BLOCK INDEX index_name ON device ;
- 一个块索引包含在一个损坏文件系统中找到的有效oracle块的地址。对于合并多个磁盘映像或从损坏文件系统卸载有用。
- 这只有在极端文件系统损坏场景中有用。
- DUMP [ TABLESPACE tablespace_no ]
[ FILE file_no ]
[ BLOCK block_no ]
[ LEVEL level_no ] ;
- 不是一个完整的blockdump, 主要用于调试。 数据块地址被记住。
- EXTRACT asm file name to output file name ;
- 从一个磁盘组复制任意ASM 文件到文件系统。 (有一个在线redologs的问题, 需要更多的测试)
-
MERGE block_index INTO [ segment ];
- 合并命令使用索引文件中的信息来定位可能的数据块。查找文件数量和对象id的组合。
-
每个候选区块与数据文件中的当前块作比较。
- 如当前块是坏的或有一个更老的scn, 候选块将被写入数据文件。
- 这只有在极端文件系统损坏场景中才有用。
- ROLLBACK;
- 取消UPDATE语句
- SCAN DUMP FILE dump file name
[ FROM begin offset ]
[ UNTIL end offset ];
- 扫描一个dump导出文件以提供 create/insert 语句和dump文件中的偏移量。
- SCAN LOB SEGMENT storage clause ;
- SCAN LOB SEGMENT FOR
table name [. column name] ;
- 扫描lob 段以生成LOBPAGE.dat 信息, 但只是该段的。
- 可能会更快和更小。
- 对于分区对象,使用SCAN DATABASE;
- UPDATE [ block_address ]
SET UB1|UB2|UB4 @ offset_in_block = new_value ;
- UPDATE [ block_address ]
SET block element name = new_value ;
- 偶尔我们可以修补一些东西。
- 当前块补丁和转储 。
- 你可以发出多个UPDATE 命令。
- 至今还未写的块, 使用 COMMIT 编写。
- UNEXP [TABLE] [ owner. ] table name
( column list ) [ DIRECT ]
DUMP FILE dump file name
FROM begin offset [ UNTIL end offset ]
[ MINIMUM min number of cols COLUMNS ] ;
- 从一个损坏exp dump 文件中卸载数据。
- 不需要特殊设置,只需兼容参数。
- begin offset 应位于一行实际开始的位置。
-
UNPUMP
- 从一个损坏expdp (datapump) dump 文件中卸载数据。
- 这仍是一个进展中的任务。当基本命令起作用时,使用起来相当复杂。
1) DUL在命令提示符下运行,不能在批处理模式下运行。
a)True
b)False
2) 当用于批处理模式时,DUL可并行运行。
a)True
b)False
Chapter 4: 简单场景
- 前提:
-
对Oracle 数据库服务器有深入了解
- imp 工具, 交互式和批处理模式的使用
- SQL*Loader 的使用
-
对UNIX/Windows 命令行级有初步了解
- vi 或UNIX上的其他文本编辑器
-
- Windows上的记事本
-
简单数据恢复
- 完整数据库数据抽取
- 部分数据库数据抽取
- 模式数据抽取
- 表数据抽取
- 区段数据抽取
- 数据字典抽取
- SYSTEM.dbf 数据文件可用,且没被损坏
- 工程师无需知道任何有关应用程序表结构、列类型等的信息…
-
元数据 (用户名,表名,列名,列类型) 通过BOOTSTRAP从SYSTEM.dbf 读取; 命令。
- BOOTSTRAP 命令过程中生成的信息存储在 OS 文本文件中,且可被后续的DUL会话读取。
- 用所有可用的.dbf 文件卸载整个数据库将生成所有模式 (除了 SYS)的输出,甚至是你可能不感兴趣的模式 (i.e. SYSTEM, XDB, MDSYS, OUTLN, etc)
- 配置 init.dul 和 control.dul
- Run /dul
DUL>bootstrap;
DUL>unload database;
DUL>exit
完整数据库抽取
虽然一个完整数据库抽取可能是得到某种结果最快的方法(特别是在客户着急的情况下),但它还将创造比所需的更多的文件。
- 如果磁盘空间对客户来说是一个问题 (数据库非常大的情况下), 创建太多文件可能是个问题
- 一个完整数据库抽取花费的时间最长,因为要连续抽取每个表
最佳实践: 知道对客户来说最关键的是什么数据,限制DUL 抽取运行。
- 仅对那些包含客户所需数据的,限制control.dul中的配置 dbfs。
- DUL 可通过不扫描不必要的dbfs节省时间。
最佳实践: DUL不会自动并行运行,然而如正确配置,多个局部数据库抽取会话可并行运行以节省时间。
部分数据库抽取
- 最佳实践: 为节省时间, 从不包含关键数据的control.dul中消除dbfs。 这些是典型的UNDOTBS, SYSAUX, IDX, INDEX, TEMP, etc
- 客户可以识别其他不必要的dbfs
- 配置 init.dul 和 control.dul
- Run /dul
DUL>bootstrap;
DUL>unload database;
DUL>exit
虽然部分数据库抽取的命令可能与完整的一样,DUL 只能识别control.dul中的.dbf 文件,因此将限制输出
- DUL 将输出一个数据字典中所引用表空间对象的错误消息,但在 control.dul中没有对应的.dbf。
- 这些错误可忽略, 不过你可能需要向你的客户解释它们。
-
最佳实践: 如果客户对其应用程序.dbf 文件的内容不确定,将其保存在control.dul中,否则数据可能会丢失
- 为节省时间, 可考虑并行运行DUL 会话,并将每个配置为一个不同的模式或表的不同子集(如数据库较大)
- 如果运行多个DUL 会话,可考虑从不同的目录运行以避免覆盖dul.log
- 需要部分抽取的另一个场景是:客户有一个表空间已离线。可能其数据文件中只有一个被损坏。
- 这种情况下,只包括该表空间(和系统)的dbfs并从control.dul排除所有其他的
- 配置 init.dul 和 control.dul
- Run /dul
DUL>bootstrap;
DUL>unload database;
DUL>exit
- 最佳实践: 为消除许多错误消息同时节省时间,如果客户能够具体的话,可考虑在模式或表级别抽取。
- 注意: 在许多真实场景中,数据库可能没有崩溃。要被抽取的数据可能是整个数据库很小的一部分。
- 一个截断表
- 一个被删除的用户
- 一个损坏的表空间
模式数据抽取
- 只卸载客户需要的模式。
- 配置 init.dul 和 control.dul
- Run /dul
DUL>bootstrap;
DUL>unload USER scott;
DUL>unload USER apps;
…
DUL>exit
表数据抽取
- 只卸载客户需要的那些表
- 配置 init.dul 和 control.dul
- Run /dul
DUL>bootstrap;
DUL>unload TABLE scott.dept;
DUL>unload TABLE apps.po_orders;
…
DUL>exit
表数据抽取
- UNLOAD TABLE 命令有可选参数,其可进一步限制抽取什么数据。
- UNLOAD [TABLE] [ schema_name . ] table_name
[ PARTITION( partition_name ) ]
[ SUBPARTITION( sub_partition_name ) ]
[ ( column_definitions ) ]
[ cluster_clause ]
[ storage_clause ] ;
- storage_clause ::=
STORAGE ( storage_specification )
- storage_specification ::=
OBJNO object_id_number
| TABNO cluster_table_number
| SEGOBJNO cluster/data_obj_number /*v7/v8 */
| BLOCK data_segment_header_block_number )
简单场景区段(Extent)数据抽取
- 进一步限制的话,数据可按区段抽取 (只有一个局部表,及有限的行)
- 这当客户只有部分表损坏,且已经标记特定的行或块不可用时有用。
- 配置 init.dul 和 control.dul
- Run /dul
DUL>bootstrap;
DUL>unload EXTENT scott.customer …;
DUL>exit
- UNLOAD EXTENT table_name
[ ( column_definitions ) ]
[ TABLESPACE tablespace_no ]
FILE extent_start_file_number
BLOCK extent_start_block_number
BLOCKS extent_size_in oracle_blocks ;
- 由于 DUL 只抽取数据,由客户DBA 从以前保存的创建脚本中重建索引、触发器等。
- 如果客户没有保存这些其他对象的创建脚本,可通过从数据字典中抽取源代码来创建。
UNLOAD table sys.source$;
注意: 如果该数据被抽取, 不能加载到其他数据库的SYS 里。将该数据导入到一个单独的模式中,编写SQL逆向工程脚本。
简单场景审阅输出
-
dul.log
- 列出了该运行的所有参数设置
- 列出找到的db_id 和/或 db_name
- 列出所有识别的数据文件,连同file#, relative file#, startblock, #blocks, blocksize和 offset
- 每个schema.table 的行数
- 可能的警告和错误消息
- 最佳实践:本次运行DUL的确切版本显示在标题中。
- 抽取的文件
- schema_tablename.dmp or .dat or .ctl
- dul.log 示例
Found db_id = 1321768231
0 1 c:\app\jdydek\oradata\orcl\SYSTEM01.DBF startblock 0 blocks 93441 block size 8192 (off=0)
4 4 c:\app\jdydek\oradata\orcl\USERS01.DBF startblock 0 blocks 641 block size 8192 (off=0)
…
DUL> unload table locationd (col001 number, col002 varchar2(11)) storage (extents (file 4 block 530));
. unloading table LOCATIOND 6 rows unloaded
DUL> exit
- 一般而言,没有DUL会话期间可能发生的警告或错误的完整列表。
-
警告
- 这些通常被忽略,但试着去理解他们为什么发生。
-
错误
- 这些可能造成DUL终止,或者它可能继续下去却没有结果。使用来自审查输出dul.log的最佳判断。
- 你需要一个该操作系统最新的DUL 版本
- 原因: DUL是大约每45天重新编译,且具有不同的截止日期。
-
版本 GLIBC_2.11 没有找到(required by dul)
- 原因: Linux有两个版本的DUL
- 下载并尝试Linux的另一个DUL版本 (使用动态链接库的那个)
- 每个抽取的表应显示一个行数,但:
. unloading table LOGSTDBY$FLASHBACK_SCN
DUL: Error: No entry in control file for block: ts# = 1 rfile# = 2 block# = 2050
DUL: Error: While processing ts# 1 file# 2 block# 2050
DUL: Error: Could not read/parse segment header
0 rows unloaded
- 原因: 排除了不包含任何客户应用程序数据的数据文件如SYSAUX,DUL 将找不到在数据字典中确实存在的匹配的表空间和块。 这是可预见的。
- 启动期间,你也许会看到:
DUL: Error: open( ‘C:\ORACLEXE\ORADATA\XE\SYSTEM.DBF’, Read Only)
OS error 2: No such file or directory
- 原因: control.dul中指定的数据文件不在指定的位置。
- 要么改正在control.dul中的位置
- 要么如果文件不是真的需要且一定会被排除的话就忽略。DUL 将继续且不会终止。
- 不支持的特性 / 数据类型
DUL: Error: Type REF, typcode 110 is not supported(yet)
0000000000 00220208 6d6aa16a cad6403a b6c27d8e .”.. mj.j ..@: ..}.
- 原因: DUL 可能会发现它无法识别的数据类型
- OS 相关的错误
- If osd_dba_file_bits size is wrong:
DUL: Warning: Block[1][2] DBA in block mismatch [4][2]
DUL: Warning: Bad cache layer header file#=1, block#=2
- If osd_c_struct_alignment is wrong:
DUL: Warning: file# 0 is out of range
DUL: Warning: Cannot read data block file#=0, block# = 262145 OS error 2: No such file or directory
- If db_block_size is wrong:
DUL: Warning: Block[1][2] DBA in block mismatch [513][1159680]
DUL: Warning: File=1, block 2: illegal block version 2
DUL: Warning: Block[1][2] Illegal block type[0]
DUL: Warning: Bad cache layer header file#=1, block#=2
1) 你必须使数据库的所有.dbf 文件对 DUL可用才能检索客户要求的数据
a)True
b)False
Chapter 5: 复杂场景
-
前提:
-
对Oracle 数据库服务器有深入了解
- imp 工具、交互式和批处理模式的使用
- SQL*Loader 的使用
-
对Oracle 数据库服务器有深入了解
-
对UNIX/Windows 命令行级有初步了解
- vi 或UNIX上的其他文本编辑器
- Windows上的记事本
- 假设/过程
- 分析整个数据库
- 从截断表中抽取数据
- 从dropped表中抽取数据
- 从deleted表中抽取数据
-
SYSTEM.dbf 文件不可用或被损坏
- 最佳实践: 在继续进行之前,检查客户是否有一个更老的、备份的SYSTEM.dbf 版本。除非数据库有重大变化,否则即便老的SYSTEM.dbf版本,其内部对象信息也可能是相同和可用的。
-
随着尝试抽取,列数据类型可能会被 DUL猜到, 但表名和列名丢失
- 猜到的列数据类型/精度可能是错误的
- dul.log 将包含统计数据(计数,置信级)
- 一个深入了解应用程序和表的功能人是必需的
- 卸载数据没有任何价值,如果你不知道它来自哪个表的话。
- DUL 只能通过对象编号识别表
- DUL 只能通过列编号识别列
- 最佳实践: DUL 生成每个表的行数。如客户有任何具有类似信息的最近报告,DUL行数可能与表相匹配。
- 该过程需要至少运行DUL两次
1.运行 DUL 以分析所有对象、数据类型,并为各个对象创建通用的 UNLOAD命令
2.和客户一起审阅 dul.log 统计数据、表映射对象和列数据类型。
3.修改UNLOAD 命令,如有必要。
注意: 来自客户的实际列名可能被生成的 “Col1, Col2, Col3…”代替; 此时表名可能被对象号代替。
4.运行DUL来按对象号处理每个修改的UNLOAD 命令,可能是在一个批处理文件中。
-
注意: 如果它们只包含NULLs, DUL不会找到结束列
- Trailing NULL 列没有存储在数据库中
- 列的数量可能与源表不匹配
-
那些已被删除的表将会找回并生成一个带有效对象号的UNLOAD
- 当一个表被删除时,描述仅从数据字典中删除,但带对象号的行仍存在于数据文件中。
- 没有行的表将不被报告
复杂场景 DUL运行 1: 分析数据文件
- 配置 init.dul 和 control.dul
- 确保USE_SCANNED_EXTENT_MAP=false
- Run /dul
DUL>scan database;
DUL>set USE_SCANNED_EXTENT_MAP=true
DUL>scan tables; /* or scan extents */
DUL>exit
审阅第1次运行中的dul.log
- 审阅统计数据和生成的UNLOAD 命令
-
对每一个发现的对象号, DUL 将:
- 显示它的列分析置信级统计数据
- 以纯文本格式发表5行数据
-
用“最佳猜测”列属性格式化一个通用UNLOAD命令
- 表名将为‘OBJNOnnn’
- 列将为‘COL001, COL002, etc’
- 使用纯文本验证表的标识和DUL猜测到的数据类型。
Analyzing segment: data object id 12088 segment header at ( file 4 block 11) heap organized table
Col Seen Max PCT PRINT NUMBERS DATES TIMESTAMP WITH TZ INTRVAL ROWIDS LOB
no count Size NUL 75%100% AnyNice AnyNice AnyNice AnyNice Y2M D2S AnyNice
1 4 2 0 0 0 100 100 0 0 0 0 0 0 0 0 0 0 0
2 4 22 0 100 100 0 0 0 0 0 0 0 0 0 0 50 0 0
DUL: Warning: No character set id for CHAR Column
“1” “Europe”
“2” “Americas”
“3” “Asia”
“4” “Middle East and Africa”
UNLOAD TABLE OBJNO12088 ( COL001 NUMBER, COL002 VARCHAR2(22) )
STORAGE( DATAOBJNO 12088 );
复杂场景 修改 UNLOAD 命令
此时,生成的UNLOAD命令可被编辑以满足客户要求:
UNLOAD TABLE OBJNO12088 ( COL001 NUMBER, COL002 VARCHAR2(22))
STORAGE( DATAOBJNO 12088 );
也许会变成:
UNLOAD TABLE location ( loc_id NUMBER (10), description VARCHAR2(25))
STORAGE( DATAOBJNO 12088 );
DUL 运行 2: 执行 UNLOADs
- 剪切和复制每个相关的UNLOAD 命令:
- 到批处理运行的另一个文本文件或
- 到另一个在线DUL 会话,如UNLOADS的数量较小且行量小
/dul
DUL>UNLOAD TABLE location ( loc_id NUMBER (10), description VARCHAR2(25)) STORAGE( DATAOBJNO 12088 );
. unloading table LOCATION 4 rows unloaded
复杂场景 从截断表中抽取数据
-
因为 Oracle 8, 每个对象有2 个对象id。
- 标准对象id用于追踪数据字典中的依赖关系。
- 数据对象id 用于标记一个数据段中的数据块。
- 当一个对象被创建,两个是平等的。
- 每次一个表被截断,数据对象id 递增。
- 要得到截断前的数据,你需要以前的数据对象 id (可能是当前的对象id – 1)
- SQL以识别已被截断的表
SELECT name, obj#, dataobj# from sys.obj$
where obj# <> dataobj#;
- SQL以识别用户名和内部id
SELECT user_id, username from sys.dba_users
order by username; /* or user_id */
REM Find truncated objects for a specific userid
set pages 60
col username format a12 trunc
select d.username,
o.owner#, o.name, o.obj#, o.dataobj#
from sys.obj$ o,
sys.dba_users d
where o.obj#<>o.dataobj# /* Truncated? */
and o.owner# = d.user_id
and d.username = upper(‘&1’) /* For 1st parm */
order by owner#, name;
从drop掉的表中抽取数据
- 从10g开始, Oracle 已实现了回收站,且为默认启用。
- 如果数据库已启动,客户可正常恢复删除表:
Ø闪回表 schema.tablename 到删除前;
- 如果数据库崩溃且没有配置闪回, 那么抽取数据的关键在于识别正确的数据对象id。
Ø从dul.log中, 你可能会看到行数类似的多个对象。客户需要识别。
从删除表中抽取数据
用以下场景测试你对数据 UnLoader的理解 :
- 闪回恢复区未配置或数据库版本不支持闪回。
- 当尝试删除一个雇员时, 客户忘记雇员id的一个 WHERE 子句并且:
ØDELETE from hr.emp;
ØCOMMIT; /* all rows are deleted… now what? */
- DUL应如何配置才能抽取从hr.emp表删除的数据 ?
- 在无SYSTEM.dbf数据文件可用情况下,运行完DUL后什么步骤是必需的?
a)和客户一起审阅 dul.log
b)基于行数识别表
c)修改 UNLOAD 命令以使用适当的表和列名
d)剪切/复制 修改的UNLOAD 命令
e)重新运行 DUL 并输入每个UNLOAD 命令
f)以上全都是
Chapter 6: 加载数据
-
取决于客户需求, DUL 会话中的输出可能是
- 数百个导出的 dump 文件 (*.dmp)
-
数百个SQL*Loader 文件 (*.dat, *.ctl)
- 其中一些是临时工作文件,可忽略
- 或者每个中只有几个
-
数百个LOB*.dat 或 *.ctl
- 这些是临时DUL 工作文件,可忽略
- 客户可用的输出将以以下格式命名:schema_tablename.dmp, .dat or .ctl
加载数据 下一步
- 一旦生成输出文件,ASE通常脱离和客户DBA接管。
-
不过一些客户可能需要加载数据。
- 如果许多文件已经生成,下一页上的脚本可能有助于将它们一起批处理。
DUL 导入 Unix Shell 脚本
#!/usr/bin/sh
#batch file import for dul
for i in `cat /dul/filelist`
do
imp scott/tiger rows=y full=y grants=y indexes=y
ignore=y buffer=1048576 commit=y
file=/dul/$i
log=/dul/log/$i.log charset=american
done
DUL SQL*Loader Unix Shell 脚本
#!/usr/bin/sh
#batch file import for dul
for i in `cat /dul/filelist`
do
sqlldr system/manager
control=<path>/$i
log=<path>/$i.log
done
加载数据 DUL 导入 Windows 批处理文件
REM batch file import for dul
for %%f in ( *.dmp )
do imp system/manager FULL=y
FROMUSER=dul TOUSER=scott ROWS=y GRANTS=y
INDEXES=y IGNORE=y BUFFER=1048576 COMMIT=y
FILE=C:\DUL\%%F
LOG=C:\DUL\LOG\%%F.LOG
Chapter 7: DUL 内部文件
-
前提:
-
对Oracle 数据库服务器有深入了解
- imp 工具, 交互式和批处理模式的使用
- SQL*Loader 的使用
-
对UNIX/Windows 命令行级有初步了解
- vi 或UNIX上的其他文本编辑器
- Windows上的记事本
-
对Oracle 数据库服务器有深入了解
- 访问Excel 获取导入和解析文件
- DUL 生成2种类型的临时内部文件
- .dat
- .ctl
-
所使用的关键内部文件
- EXT.dat Extent map
- SEG.dat Segment map
- SEEN_TAB.dat Found table names
- SEEN_COL.dat Found column names
- EXT.dat 和 SEG.dat 是在数据库的最初扫描过程中生成的
- DUL 使用这些文件扫描数据文件来获取内容
- SEEN_COL.dat 和 SEEN_TAB.dat 用于生成扫描表/区段操作中产生的对象统计信息
- 所有文件都可用于通过DUL执行高级卸载恢复操作
-
EXT.dat (在SCAN DATABASE过程中创建;)
- 包含有关连续表/集群数据块的信息
-
由9个列组成
- Object ID
- File# of 段头
- Block# of 段头(segment header)
- File#
- Block# of 段头后的第一个块
- 块数 = 与指向HWM的段相偏移的块
- 表数, 如常规表,为1
-
SEG.dat (在SCAN DATABASE过程中创建;)
- 包含有关段头的信息
-
由4 列组成
- Object ID
- File#
- Rfile#
- Block#
- SEEN_TAB.dat (SCAN TABLE过程中创建;)
- 包含关于找到的表对象的信息
-
由6 列组成
- Object ID
- Table #
- Block #
- ??
- # of columns
- Row count
-
SEEN_COL.dat (在SCAN TABLE过程中创建;)
-
由16 列组成
- Object ID
- Table #
- Column #
- Field Type
- Max Internal Size
- Null found
- Number of rows
- 75% Character
- 100% Character
- Number
- % Nice Number
- % Date
- % Row ID
-
由16 列组成
- SEG.dat
“77876” “4” “4” “522 ”
- EXT.dat
“4” “16777227” “6” “5” “77876” “1” “1” “1” “0“
- SEEN_TAB.dat
77876 4 522 0 2 5
- SEEN_COL.dat
77876 0 1 2 2 F 5 0 0 0 5 5 0 0 0 0
77876 0 2 1 11 F 5 0 5 5 0 0 0 0 3 0
- 为更好地理解发现的对象号、列和行数,可将这些文件导入Excel进行分析。
Chapter 8: 练习/实验
- 前提: Chapter 1
- 无
- 前提: Chapter 2
- 访问内部Oracle DUL 网站
- 前提: Chapters 3-7
- 安装在笔记本电脑上的Oracle Database 11g 或
- 访问Oracle 11g 数据库的测试/开发
- 完整的DBA管理权限(为验证)
- Chapters 3-7: 实验安装步骤
- 注意: 在真实场景中, 数据库可能会关闭, 但为了简化实验安装和结果验证, 你需要保持数据库处于开启状态。
- DUL 可以运行.dbf 文件,不论数据库是开启还是关闭。
-
作为SYSDBA 登录到你的数据库并运行以下脚本创建一个labuser, labuser下的一些表, 和用于导入数据的一个 newuser。
- @create
-
运行的一般步骤并完成
- 下载DUL 工具
- 在客户机上安装它
- 配置 init.dul 和 config.dul 文件
-
确定适当的命令序列
- 执行‘引导’ 或
- 扫描数据库或扫描表或区段
- 卸载数据库/用户/表/区段/对象
- 重新创建所需的数据库或表空间
- 导入或 SQL*Load DUL 输出文件。
- Chapter 3: 参数和命令
- 从通用_init.dul的副本创建一个init.dul
- 修改你平台的 OSD 参数
- 审阅并根据需要修改其他参数
- 从数据库生成一个 control.dul
- 如数据库已安装,在 v$datafiles上运行SQL 。
Ø@control_dul.sql
- 从OS生成一个control.dul, 根据需要编辑
- 从oradata目录获取一个.dbf 文件的文件列表
Ø/strings CONTROL01.dbf > control.dul
- Chapter 4: 简单数据挽救场景
1) 使用第3章练习中的init.dul 和control.dul,执行一次完整数据库抽取
- dul < Chap4_Ex1.txt
- 审阅日志
- 审阅输出目录
- 注意创建了多少文件
- 这些文件中有多少是临时工作文件?
- 这些文件中有多少可用于加载?
- 查看错误消息
- 它完成了吗?
- Chapter 4: 简单数据挽救场景
3) 执行一个目标模式抽取
- 卸载用户labuser;
- 查看日志获取表名和行数
4) 执行一个表抽取
- 卸载表sys.source$;
- 注意: 该表中的数据可能用于重建索引、触发器等的源脚本。
- 查看日志获取行数和任何错误
- 导入并验证Chapter 4的所有数据
- Chapter 5: 复杂数据挽救场景
- @actions /* truncate, drop, delete tables */
- 编辑 control.dul, 移除 SYSTEM01.dbf
- dul < Chap5_Ex1.txt
- 查看 dul.log
- 从日志抽取一些UNLOAD 命令
- 修改一些UNLOAD 命令
- 运行 UNLOAD 命令
- 导入并验证Chapter 5的数据
- Chapter 6: 加载数据Data
- 将抽取的.dmp 或 .dat/.ctl 文件导入到你的测试数据库的一个新模式中
- 运行提供的 import.bat 以从Windows导入
- 查看导入到newuser的数据
- Chapter 7: 内部文件
- 解析ext.dat, seg.dat, seen_tab.dat 和 seen_col.dat 文本文件到一个 Excel 电子表格中
- 查看行数、表列统计数据、对象号