案例:Oracle dul数据挖掘 磁盘损坏dul提取数据文件中表的数据及l

通过使用Oracle DUL工具提取损坏磁盘里的数据库文件中的表及lob字段中内容

在有次8i的库恢复中,因为硬盘损坏导致几个表出现很多诡异性坏块,尝试使用dul对其进行挖掘数据,当时使用dul 9 遇到一个难题:当一张表中有lob类型,同时又有varchar2类型,而且varchar2类型数据中包含回车键,使得解决起来很麻烦(因为export_mode=false支持lob,但是不支持字符串含回车;export_mode=true支持字符串含回车,但是不支持lob),最后放弃了对部分数据的挖掘.这个问题让我一直不甘心,今天测试dul 10 发现是用export_mode=true可以完美解决该问题

1.创建模拟表和插入数据

SQL> desc t_xff
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 C_BLOB                                             BLOB
 C_VARCHAR                                          VARCHAR2(4000)

SQL> declare
  2  a_blob BLOB;
  3  bfile_name BFILE := BFILENAME(‘ULTLOBDIR‘,‘awr_ora11g_2012-06-01_174_175.html‘);
  4  begin
  5  insert into t_xff(C_BLOB,C_VARCHAR) values (
  6  empty_blob())
 12  returning C_BLOB into a_blob;
 13  dbms_lob.fileopen(bfile_name);
 14  dbms_lob.loadfromfile(a_blob, bfile_name, dbms_lob.getlength(bfile_name));
 15  dbms_lob.fileclose(bfile_name);
 16  commit;
 17  end;
 18  /

PL/SQL procedure successfully completed.

SQL> select length(c_varchar),dbms_lob.getlength(c_blob) from t_xff;

LENGTH(C_VARCHAR) DBMS_LOB.GETLENGTH(C_BLOB)
----------------- --------------------------
               61                    4282573

SQL>  select c_varchar from t_xff;

C_VARCHAR
---------------------------------------------------------------

数据库异常恢复

2.dul 挖数据

[[email protected] dul]$ ./dul

Data UnLoader: 10.2.0.5.13 - Internal Only - on Mon Jul  2 04:29:10 2012
with 64-bit io functions

Copyright (c) 1994 2012 Bernard van Duijnen All rights reserved.

 Strictly Oracle Internal Use Only

DUL> bootstrap;
DUL> desc chf.t_xff;
Table CHF.T_XFF
obj#= 51353, dataobj#= 51353, ts#= 4, file#= 4, block#=67
      tab#= 0, segcols= 2, clucols= 0
Column information:
icol# 01 segcol# 01       C_BLOB len 4000 type 113 BLOB
  LOB Segment: dataobj#= 51354, ts#= 4, file#= 4, block#=75 chunk=1
  LOB Index: dataobj#= 51355, ts#= 4, file#= 4, block#=83
icol# 02 segcol# 02    C_VARCHAR len 4000 type  1 VARCHAR2 cs 852(ZHS16GBK)

--export_mode=false
DUL> unload table chf.t_xff;
. unloading (index organized) table     LOB01000053      65 rows unloaded
Preparing lob metadata from lob index
Reading LOB01000053.dat 65 entries loaded and sorted 65 entries
. unloading table                     T_XFF       1 row  unloaded

--导出数据文件
-rw-r--r-- 1 oracle oinstall 6.1K Jul  2 04:15 LOB01000053.dat
-rw-r--r-- 1 oracle oinstall  335 Jul  2 04:15 LOB01000053.ctl
-rw-r--r-- 1 oracle oinstall 8.2M Jul  2 04:15 CHF_T_XFF.dat
-rw-r--r-- 1 oracle oinstall  263 Jul  2 04:15 CHF_T_XFF.ctl

----export_mode=true
DUL> unload table chf.t_xff;
. unloading (index organized) table     LOB01000053
DUL: Warning: Recreating file "LOB01000053.ctl"
      65 rows unloaded
Preparing lob metadata from lob index
Reading LOB01000053.dat 65 entries loaded and sorted 65 entries
. unloading table                     T_XFF       1 row  unloaded

--导出数据文件
-rw-r--r-- 1 oracle oinstall    6229 Jul  2 04:29 LOB01000053.dat
-rw-r--r-- 1 oracle oinstall     335 Jul  2 04:29 LOB01000053.ctl
-rw-r--r-- 1 oracle oinstall 4285027 Jul  2 04:29 CHF_T_XFF.dmp

3.导入数据测试

sqlldr导入

SQL> truncate table chf.t_xff;

Table truncated.

[[email protected] dul]$ sqlldr chf/xifenfei control=CHF_T_XFF.ctl

SQL*Loader: Release 10.2.0.1.0 - Production on Mon Jul 2 04:23:18 2012

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

SQL*Loader-510: Physical record in data file (CHF_T_XFF.dat) is longer than the maximum(1048576)
SQL*Loader-2026: the load was aborted because SQL Loader cannot continue.
[[email protected] dul]$ sqlldr chf/xifenfei control=CHF_T_XFF.ctl readsize=20971520

SQL*Loader: Release 10.2.0.1.0 - Production on Mon Jul 2 04:26:50 2012

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

SQL> select length(c_varchar),dbms_lob.getlength(c_blob) from chf.t_xff;

no rows selected

--试验结果证明在出现表中同时有lob和varchar2列(含回车)时,export_mode=false不能正常工作

imp导入

SQL> drop table chf.t_xff;

Table dropped.

[[email protected] dul]$ imp chf/xifenfei file=CHF_T_XFF.dmp full=y

Import: Release 10.2.0.1.0 - Production on Mon Jul 2 04:30:30 2012

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options

Export file created by EXPORT:V07.00.07 via conventional path

Warning: the objects were exported by Bernard‘s DUL, not by you

. importing Bernard‘s DUL‘s objects into CHF
. importing Bernard‘s DUL‘s objects into CHF
. . importing table                        "T_XFF"          1 rows imported

SQL> select length(c_varchar),dbms_lob.getlength(c_blob) from t_xff;

LENGTH(C_VARCHAR) DBMS_LOB.GETLENGTH(C_BLOB)
----------------- --------------------------
               61                    4282573

SQL>  select c_varchar from t_xff;

C_VARCHAR
---------------------------------------------------------------

数据库异常恢复

--试验结果证明在出现表中同时有lob和varchar2列(含回车)时,export_mode=true正常工作
-----------------温馨提示--------------------
操作有风险,动手需谨慎
Oracle研究中心
http://www.oracleplus.net
本文由大师惜分飞原创分享,转载请尽量保留本站网址

--------------------------------------ORACLE-DBA----------------------------------------

最权威、专业的Oracle案例资源汇总之案例:Oracle dul数据挖掘 磁盘损坏dul提取数据文件中表的数据及l

原文唯一网址:http://www.oracleplus.net/arch/oracle-20160522-213.html

Oracle研究中心

关键词:

Oracle dul数据挖掘

磁盘损坏dul提取数据文件中表中的数据及lob字段

时间: 2024-08-04 18:44:55

案例:Oracle dul数据挖掘 磁盘损坏dul提取数据文件中表的数据及l的相关文章

案例:Oracle dul数据挖掘 没有数据库备份非常规恢复truncate删除的数据表

Oracle数据库在没有备份情况下在对表中的某数据表进行truncate删除后,通过oracle dul进行非常规恢复 1.准备oracle dul测试环境 SQL> select count(*) from t_xifenfei; COUNT(*) ---------- 67854 SQL> desc t_xifenfei Name Null? Type ----------------------------------------- -------- ------------------

Oracle DBA的神器: PRM恢复工具,可脱离Oracle软件运行,直接读取Oracle数据文件中的数据

PRM 全称为ParnassusData Recovery Manager ,由 诗檀软件自主研发,拥有独立的软件著作权. PRM可以独立于Oracle软件运行,直接从Oracle数据文件中抽取表上的数据. 当以下几种场景中,都可以用上PRM: 无备份或者备份不可用情况下,数据表被意外truncate掉或者DROP掉 由于数据库损坏,导致的数据打不开 无法OPEN 数据块存在损坏,Oracle无法读取出数据 数据文件存在损坏,或者数据文件头信息不一致 等等 以上这些问题中,用户均可以考虑使用PR

案例:Oracle exp dmp文件损坏 通过CPFL工具抽取dmp中的数据表进行恢复

Oracle数据库逻辑导出exp的dmp文件损坏,通过非常规恢复抽取dmp文件中表的数据 在有些时候,exp的dmp文件因为某种原因损坏(比如磁盘异常,exp过程损坏等),导致imp导入无法继续,下面的处理方法(直接读取dmp文件)来对dmp文件进行抢救性恢复,最大程度减少数据丢失损失 1.创建exp dmp文件并使用dd破坏 SQL> create table t_xifenfei as select * from dba_objects; Table created. SQL> selec

oracle(数据文件)

--创建数据文件 create tablespace--创建表空间同时创建数据文件 create temporary tablespace --创建临时表空间的同时创建临时数据文件 alter tablespace...add datafile --向表空间添加数据文件 alter tablespace...add tempfile--向临时表空间添加数据文件 create database --创建数据库时创建数据文件 alter database...create datefile--数据氈

Oracle 表空间与数据文件

一.概念 表空间:是一个或多个数据文件的逻辑集合 表空间逻辑存储对象:永久段-->如表与索引 临时段-->如临时表数据与排序段                          回滚段-->用于事物回滚或闪回内存的撤销数据 表空间分类:系统表空间(system.sysaux),非系统表空间 一个表空间至少包含一个数据文件,一个数据文件只能属于一个表空间. 不可或缺的几个表空间: SYSTEM --->字典表空间,不能被损坏 UNDO --->dml,dql把数据快照到此,数据

Oracle 数据库 数据文件 表 表空间 用户的关系

这涉及到数据库的物理结构和逻辑结构. 首先,你需要明白的一点是:数据库的物理结构是由数据库的操作系统文件所决定,每一个Oracle数据库是由三种类型的文件组成:数据文件.日志文件和控制文件.数据库的文件为数据库信息提供真正的物理存储. 每一个Oracle数据库有一个或多个物理的数据文件(data file).一个数据库的数据文件包含全部数据库数据.逻辑数据库结构(如表.索引等)的数据物理地存储在数据库的数据文件中.数据文件通常为*.dbf格式,例如:userCIMS.dbf.数据文件有下列特征:

Oracle数据文件和临时文件的管理

一.数据文件概述在Oracle数据库中,SYSTEM和SYSAUX表空间至少需要包含一个数据文件,此外还将包含多个其他表空间及与其相关的数据文件和临时文件.Oracle的数据文件和临时文件是操作系统文件,属于数据库物理结构范畴,用于存储数据库中的逻辑结构的数据.在创建表空间时,必须明确的为每个表空间指定数据文件. Oracle通过两种方式为文件分配编号:绝对文件号,用于唯一标识数据库中的数据文件,绝对文件号可以通过v$datafile或v$tempfile视图的FILE#列查询,也可以通过DBA

Oracle的表空间、数据文件、用户

每一个Oracle数据库都是由三种类型的文件组成:数据文件(Data File).日志文件(Log File)和控制文件(Control File).数据库的文件为数据库信息提供真正的物理存储.      每个数据库有一个或多个物理的数据文件.逻辑数据库结构(如表.索引等)的数据物理地存储在数据库的数据文件中,数据文件通常为*.dbf格式. 数据文件有下列特征: 1.一个数据文件仅与一个数据库联系: 2.一旦建立,数据文件只增不减: 3.一个表空间(数据库存储的逻辑单位)由一个或多个数据文件组成

Oracle 表空间和数据文件之间的关系

首先,你需要明白的一点是:数据库的物理结构是由数据库的操作系统文件所决定,每一个Oracle数据库是由三种类型的文件组成:数据文件.日志文件和控制文件.数据库的文件为数据库信息提供真正的物理存储. 每一个Oracle数据库有一个或多个物理的数据文件(data file).一个数据库的数据文件包含全部数据库数据.逻辑数据库结构(如表.索引等)的数据物理地存储在数据库的数据文件中.数据文件通常为*.dbf格式,例如:userCIMS.dbf.数据文件有下列特征:①.一个数据文件仅与一个数据库联系:②