[20160329]bbed修复offline的数据文件.txt

[20160329]bbed修复offline的数据文件.txt

--测试数据库，不小心将一个数据文件offline了，archivelog也删除了(主要磁盘空间紧张，做了一次整理)。
--自己测试修复看看，顺便做一个记录。

1.环境：
SCOTT@book> @ &r/ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

SYS@book> SELECT file#, CHECKPOINT_CHANGE#, CHECKPOINT_TIME,CREATION_CHANGE#  , RESETLOGS_CHANGE#,status, CHECKPOINT_COUNT,fuzzy,name,tablespace_name  FROM v$datafile_header;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME     CREATION_CHANGE# RESETLOGS_CHANGE# STATUS  CHECKPOINT_COUNT FUZ NAME                             TABLESPACE_NAME
----- ------------------ ------------------- ---------------- ----------------- ------- ---------------- --- -------------------------------- ----------------
    1        13227498080 2016-03-29 11:44:35                7       13227286650 ONLINE               999 NO  /mnt/ramdisk/book/system01.dbf   SYSTEM
    2        13227498080 2016-03-29 11:44:35             1834       13227286650 ONLINE               995 NO  /mnt/ramdisk/book/sysaux01.dbf   SYSAUX
    3        13227498080 2016-03-29 11:44:35           923328       13227286650 ONLINE               915 NO  /mnt/ramdisk/book/undotbs01.dbf  UNDOTBS1
    4        13227498080 2016-03-29 11:44:35            16143       13227286650 ONLINE               999 NO  /mnt/ramdisk/book/users01.dbf    USERS
    5        13227498080 2016-03-29 11:44:35           952916       13227286650 ONLINE               912 NO  /mnt/ramdisk/book/example01.dbf  EXAMPLE
    6        13227498080 2016-03-29 11:44:35          1314508       13227286650 ONLINE               928 NO  /mnt/ramdisk/book/sugar01.dbf    SUGAR
    7        13227287392 2016-03-25 17:13:07      13227207527       13227286650 OFFLINE               20 YES /mnt/ramdisk/book/tea01.dbf      TEA
7 rows selected.

--我估计CHECKPOINT_CHANGE# 修改为13227498080 就ok了。测试看看。安全起见做一个备份：
$ cp tea01.dbf_ORG tea01.dbf

SYS@book> @ &r/10to16 13227287392

10 to 16 HEX   REVERSE16
-------------- -----------------------------------
0000314686360 0x60636814-03000000

SYS@book> @ &r/10to16 13227498080

10 to 16 HEX   REVERSE16
-------------- -----------------------------------
00003146b9a60 0x609a6b14-03000000

SCOTT@book> @ &r/bbvi 7 1
BVI_COMMAND
--------------------------------------------------
bvi -b 8192 -s 8192 /mnt/ramdisk/book/tea01.dbf

$ cp tea01.dbf tea01.dbf_ORG

2.使用bvi打开，修改0x60636814=>0x609a6b14

BBED> set dba 7,1
        DBA             0x01c00001 (29360129 7,1)

BBED> p kcvfh.kcvfhckp.kcvcpscn.kscnbas
ub4 kscnbas                                 @484      0x14686360

BBED> set dba 1,1
        DBA             0x00400001 (4194305 1,1)

BBED> p kcvfh.kcvfhckp.kcvcpscn.kscnbas
ub4 kscnbas                                 @484      0x146b9a60

--换1种修改模式算是学习。使用bbed的assign命令。
BBED> assign file 7 block 1 offset 484= file 1 block 1 offset 484;
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
ub1 pad                                     @484      0x60

BBED> set dba 1,1
        DBA             0x00400001 (4194305 1,1)

BBED> p kcvfh.kcvfhckp.kcvcpscn.kscnbas
ub4 kscnbas                                 @484      0x146b9a60

BBED> set dba 7,1
        DBA             0x01c00001 (29360129 7,1)

BBED> p kcvfh.kcvfhckp.kcvcpscn.kscnbas
ub4 kscnbas                                 @484      0x14686360

--仔细检查发现没改，仅仅修改最后1个字节，实际上这里正好一样(看不出来)。
BBED> help assign
ASSIGN[/x|d|u|o] <target spec>=<source spec>
<target spec> : [ DBA | FILE | FILENAME | BLOCK | OFFSET | symbol | *symbol ]
<source spec> : [ value | <target spec options> ]

BBED> assign dba 7,1 kcvfh.kcvfhckp.kcvcpscn.kscnbas = dba 1,1 kcvfh.kcvfhckp.kcvcpscn.kscnbas;
ub4 kscnbas                                 @484      0x146b9a60

BBED> p kcvfh.kcvfhckp.kcvcpscn.kscnbas dba 1,1
ub4 kscnbas                                 @484      0x146b9a60

BBED> p kcvfh.kcvfhckp.kcvcpscn.kscnbas dba 7,1
ub4 kscnbas                                 @484      0x146b9a60

--ok现在一样了。
BBED> sum apply dba 7,1
Check value for File 7, Block 1:
current = 0xdedb, required = 0xdedb

BBED> verify  dba 7,1
DBVERIFY - Verification starting
FILE = /mnt/ramdisk/book/tea01.dbf
BLOCK = 1

DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 0
Total Blocks Failing   (Data) : 0
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0
Message 531 not found;  product=RDBMS; facility=BBED

3.重启到mount状态：
SYS@book> SELECT file#, CHECKPOINT_CHANGE#, CHECKPOINT_TIME,CREATION_CHANGE#  , RESETLOGS_CHANGE#,status, CHECKPOINT_COUNT,fuzzy,name,tablespace_name  FROM v$datafile_header;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME     CREATION_CHANGE# RESETLOGS_CHANGE# STATUS  CHECKPOINT_COUNT FUZ NAME                            TABLESPACE_NAME
----- ------------------ ------------------- ---------------- ----------------- ------- ---------------- --- ------------------------------- ----------------
    1        13227498080 2016-03-29 11:44:35                7       13227286650 ONLINE               999 NO  /mnt/ramdisk/book/system01.dbf  SYSTEM
    2        13227498080 2016-03-29 11:44:35             1834       13227286650 ONLINE               995 NO  /mnt/ramdisk/book/sysaux01.dbf  SYSAUX
    3        13227498080 2016-03-29 11:44:35           923328       13227286650 ONLINE               915 NO  /mnt/ramdisk/book/undotbs01.dbf UNDOTBS1
    4        13227498080 2016-03-29 11:44:35            16143       13227286650 ONLINE               999 NO  /mnt/ramdisk/book/users01.dbf   USERS
    5        13227498080 2016-03-29 11:44:35           952916       13227286650 ONLINE               912 NO  /mnt/ramdisk/book/example01.dbf EXAMPLE
    6        13227498080 2016-03-29 11:44:35          1314508       13227286650 ONLINE               928 NO  /mnt/ramdisk/book/sugar01.dbf   SUGAR
    7        13227498080 2016-03-25 17:13:07      13227207527       13227286650 OFFLINE               20 YES /mnt/ramdisk/book/tea01.dbf     TEA
7 rows selected.
--现在一致了，recover看看。

SYS@book> recover datafile 7;
Media recovery complete.

alter database open read only ;

SYS@book> select owner,segment_name from dba_segments where tablespace_name='TEA';
OWNER  SEGMENT_NAME
------ --------------------
SCOTT  EMPX

SYS@book> select * from scott.empx ;
select * from scott.empx
                    *
ERROR at line 1:
ORA-00376: file 7 cannot be read at this time
ORA-01110: data file 7: '/mnt/ramdisk/book/tea01.dbf'

SYS@book> alter database datafile 7 online ;
Database altered.

SYS@book> select * from scott.empx where rownum<=1;
       EMPNO ENAME      JOB                MGR HIREDATE                     SAL         COMM       DEPTNO
------------ ---------- --------- ------------ ------------------- ------------ ------------ ------------
        7369 YYYY       CLERK             7902 1980-12-17 00:00:00          800                        20

时间： 2024-08-10 16:53:29

[20160329]bbed修复offline的数据文件.txt的相关文章

[20160329]表空间与数据文件.txt

[20160329]表空间与数据文件.txt --昨天跟别人聊天,提到招聘DBA,一些dba这些基本的概念不清楚. --表空间可以是一个逻辑的概念,包含多个数据文件.而一个数据文件仅仅属于一个表空间. --表空间offline,一般不需要recover 恢复.除非加入immediate 参数. --而数据文件offline,一定需要恢复,才能online.如果是非归档模式必须在后面加入drop参数(自己曾经对于这存在混乱). --不要误解后面这个drop不是删除的意思,我以前理解就存在错误. -

[20130104]快速移动数据文件.txt

[20130104]快速移动数据文件.txt 如果要快速移动数据文件,对业务的影响最小,可以使用rman的backup as copy功能,先拷贝文件到需要移动的目录,然后再追加增量变化,再利用增量备份来恢复copy文件,再切换数据文件. 做一个例子来说明整个过程: SQL> select * from v$version where rownum BANNER -------------------------------------------------------------------

[20171206]最小数据文件.txt

[20171206]最小数据文件.txt --//曾经写过一篇关于[20150113]关于oracle的存储结构.txt的文章,链接http://blog.itpub.net/267265/viewspace-1400603/ --//里面提到如果建立的数据文件如果SEGMENT SPACE MANAGEMENT AUTO (8K数据块),最小文件是88k.实际占用大小96K. --//是否可以建立更小的数据文件呢? 1.环境: SCOTT@book> @ &r/ver1 PORT_STRI

[20130116]ASM未正常启动,使用dd找回数据文件.txt

[20130116]ASM未正常启动,使用dd找回数据文件.txt 参考链接:http://www.xifenfei.com/3025.html,自己为了加强理解,重做一次. SQL> column name format a50 SQL> select file#,ts#,status,enabled,checkpoint_change#,name,bytes  from v$datafile;      FILE#        TS# STATUS  ENABLED    CHECKPO

[20130115]测试从asm中取出spfile文件以及一个数据文件.txt

[20130115]测试从asm中取出spfile文件以及一个数据文件.txt 参考: http://www.xifenfei.com/3019.html 使用dd复制asm中文件 SQL> column name format a50 SQL> select file#,ts#,status,enabled,checkpoint_change#,name,bytes  from v$datafile;      FILE#        TS# STATUS  ENABLED    CHEC

数据文件、表空间offline用法及区别

对数据库的脱机包括数据文件的脱机和对表空间的脱机,表空间脱机实际就是表空间对应的所有数据文件脱机. 1.         数据文件OFFLINE 数据文件添加到表空间之后不能够被删除的,没有语法支持这么做,如果想不使用该数据文件,唯一是将数据文件设置为OFFLINE状态.执行以下步骤将数据文件设置为OFFLINE状态: 1)         如果是归档模式可以执行如下SQL设置数据文件的状态为OFFLINE: ALTER DATABASE DATAFILE 'XXXX.DBF' OFFLINE;

[20141106]建立控制文件与丢失数据文件问题

[20141106]建立控制文件与丢失数据文件问题.txt --前一阵子,帮别人恢复系统,主数据库硬盘损坏,dataguard能够只读打开,查询没有问题,安全起见在另外的机器 --建立新系统,把dataguard的数据文件拷贝到新机器,建立新的控制文件,但是open resetlogs后发现,丢失一些数 --据文件,感觉很奇怪,询问以后才明白,有一些表空间是read only的,当然解决也很简单, --参考链接: http://blog.itpub.net/267265/viewspace-74

数据文件坏删除数据文件

数据 没有简单的方法来删除表空间的数据文件,唯一的方法是删除整个定义的表空间,步骤有下面(前提是这个数据文件上的数据是不需要了): 如果数据库运行在非归档模式: 1. MOUNT数据库 - startup mount2. 删除数据文件 - alter database datafile xxx offline drop3. 打开(OPEN)数据库 - alter database open 4. 查看属于该表空间的所有对象:        select owner, segment_name,

[20151028]理解数据文件offline+drop.txt

[20151028]理解数据文件offline+drop.txt --前几天做删除数据文件的恢复测试,自己在理解offline drop的方式存在错误,做一个记录: The ALTER DATABASE DATAFILE <datafile name> OFFLINE DROP command, is not meant to allow you to remove a datafile. What the command really means is that you are offlin