[20121115]关于oracle数据文件的第1块.txt

[20121115]关于oracle数据文件的第1块.txt

每个数据文件的第一个块(block 0)是OS block header，在数据库中查询不到信息，记录的是OS信息，以及文件大小的等信息.
今天做一些简单的研究。

SQL> select * from v$version where rownum

BANNER

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

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

CREATE TABLESPACE TEST DATAFILE 

  '/u01/app/oracle11g/oradata/test/test01.dbf' SIZE 64M AUTOEXTEND ON NEXT 16M MAXSIZE UNLIMITED

LOGGING

ONLINE

PERMANENT

EXTENT MANAGEMENT LOCAL AUTOALLOCATE

BLOCKSIZE 8K

SEGMENT SPACE MANAGEMENT AUTO

FLASHBACK ON;

SQL> show parameter db_block_size

NAME           TYPE        VALUE

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

db_block_size  integer     8192

SQL>  SELECT file_name, file_id, tablespace_name, BYTES, blocks, status, relative_fno, maxbytes, maxblocks, online_status FROM dba_data_files where tablespace_name='TEST';

FILE_NAME                                                   FILE_ID TABLESPACE_NAME           BYTES     BLOCKS STATUS    RELATIVE_FNO               MAXBYTES  MAXBLOCKS ONLINE_

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

/u01/app/oracle11g/oradata/test/test01.dbf                        8 TEST                   67108864       8192 AVAILABLE            8            34359721984    4194302 ONLINE

SQL> host ls -l /u01/app/oracle11g/oradata/test/test01.dbf

-rw-r-----  1 oracle11g oinstall 67117056 Nov 15 08:08 /u01/app/oracle11g/oradata/test/test01.dbf

--可以发现从OS看文件大小是67117056,而从dba_data_files视图看大小67108864。
--67117056-67108864=8192.正好相差1块。而数据文件的第1块(block 0 )实际上保存OS相关信息，数据库是查询不到。
--如果使用bbed查询发现：
BBED> set dba 8,0
BBED-00205: illegal or out of range DBA (File 8, Block 0)

--如果仅仅这个块的信息破坏（个人感觉破坏一块的概率很低），理论讲对于数据文件并没有任何影响，不影响任何操作.
--在做这些操作前，做一个备份。
RMAN> backup as copy datafile 8 format '/data/testtest/test01.dbf';

Starting backup at 2012-11-15 10:00:44
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=537 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00008 name=/u01/app/oracle11g/oradata/test/test01.dbf
output file name=/data/testtest/test01.dbf tag=TAG20121115T100056 RECID=2 STAMP=799408868
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:15
Finished backup at 2012-11-15 10:01:11


--使用dd导出，注意if，of参数不要写反了!!

$ dd if=/u01/app/oracle11g/oradata/test/test01.dbf f=l0.bin count=1 bs=8192

$ od -A x -t x l0.bin

000000 0000a200 ffc00000 00000000 00000000

000010 0000da66 00002000 00002000 7a7b7c7d

000020 000081a0 00000000 00000000 00000000

000030 00000000 00000000 00000000 00000000

*

002000

--可以发现大部分信息是0x00. 而且非0x00信息都存在前面的48个字节。

测试1：

--写一些垃圾数据看看。关闭数据库来操作，我使用bvi -s 8192来操作。注意我并没有覆盖前面48个字节。

$ dd if=/u01/app/oracle11g/oradata/test/test01.dbf  count=1 bs=8192 2>/dev/null | od -A x -t x

000000 0000a200 ffc00000 00000000 00000000

000010 0000da66 00002000 00002000 7a7b7c7d

000020 000081a0 00000000 00000000 00000000

000030 00000000 00000000 00000000 00000000

*

000780 aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa

*

0007a0 0000aaaa 00000000 00000000 00000000

0007b0 00000000 00000000 00000000 00000000

*

002000

$ dbv file=/u01/app/oracle11g/oradata/test/test01.dbf
DBVERIFY: Release 11.2.0.1.0 - Production on Thu Nov 15 10:12:45 2012
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
DBVERIFY - Verification starting : FILE = /u01/app/oracle11g/oradata/test/test01.dbf
DBVERIFY - Verification complete
Total Pages Examined         : 8192
Total Pages Processed (Data) : 1553
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 3
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 171
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 6465
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 3011243229 (0.3011243229)

--可以发现并没有报错。另外oracle还提供一个dbfsize命令检查块的大小。
$ dbfsize /u01/app/oracle11g/oradata/test/test01.dbf

Database file: /u01/app/oracle11g/oradata/test/test01.dbf
Database file type: file system
Database file size: 8192 8192 byte blocks
--可以发现也是正常的，主要是我的操作并没有覆盖前面的48个有信息的字节。
--如果这时启动数据库一切OK。

测试2：
--写一些垃圾数据看看。关闭数据库来操作，我使用bvi -s 8192来操作。注意这次覆盖前面48个字节！千万不要在生产系统做这样操作！

$ dd if=/u01/app/oracle11g/oradata/test/test01.dbf  count=1 bs=8192 2>/dev/null  | od -A x -t x

000000 bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb

*

000060 00bbbbbb 00000000 00000000 00000000

000070 00000000 00000000 00000000 00000000

*

000780 aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa

*

0007a0 0000aaaa 00000000 00000000 00000000

0007b0 00000000 00000000 00000000 00000000

*

002000

$ dbv file=/u01/app/oracle11g/oradata/test/test01.dbf
DBVERIFY: Release 11.2.0.1.0 - Production on Thu Nov 15 10:22:07 2012
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
DBV-00107: Unknown header format (187) (-1145324613)

$ dbfsize /u01/app/oracle11g/oradata/test/test01.dbf
/u01/app/oracle11g/oradata/test/test01.dbf: Header block magic number is bad

--可以发现dbv以及dbfsize都报错，启动数据库看看，可以发现一些OK。包括访问信息以及DML操作。

SQL> select tablespace_name from dba_tables where wner='SCOTT' and table_name='DEPT1';

TABLESPACE_NAME

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

TEST

SQL> select * from scott.dept1;

    DEPTNO DNAME          LOC

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

        50 TEST           BBBBB

        10 ACCOUNTING     NEW YORK

        20 RESEARCH       DALLAS

        30 SALES          CHICAGO

        40 OPERATIONS     BOSTON

SQL> insert into dept1 values (60,'AAAAAA','BBBBB');

1 row created.

SQL> commit ;

Commit complete.

SQL> select * from scott.dept1;

    DEPTNO DNAME          LOC

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

        50 TEST           BBBBB

        10 ACCOUNTING     NEW YORK

        20 RESEARCH       DALLAS

        30 SALES          CHICAGO

        40 OPERATIONS     BOSTON

        60 AAAAAA         BBBBB

6 rows selected.

3.修复数据文件的第1块的错误呢？
如何修复呢？虽然没有任何影响，但是如果重建控制文件会报错。
SQL> @cr
ORACLE instance started.

Total System Global Area 2137886720 bytes
Fixed Size                  2215064 bytes
Variable Size            1778385768 bytes
Database Buffers          352321536 bytes
Redo Buffers                4964352 bytes
CREATE CONTROLFILE REUSE DATABASE "TEST" NORESETLOGS  ARCHIVELOG
*
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-01565: error in identifying file '/u01/app/oracle11g/oradata/test/test01.dbf'
ORA-27048: skgfifi: file header information is invalid

实际上只要数据文件大小发生变化，就可以修改数据文件的第1块信息。

SQL> alter database datafile '/u01/app/oracle11g/oradata/test/test01.dbf' resize 64m;

Database altered.

$ dd if=/u01/app/oracle11g/oradata/test/test01.dbf  count=1 bs=8192 2>/dev/null  | od -A x -t x

000000 bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb

*

000060 00bbbbbb 00000000 00000000 00000000

000070 00000000 00000000 00000000 00000000

*

000780 aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa

*

0007a0 0000aaaa 00000000 00000000 00000000

0007b0 00000000 00000000 00000000 00000000

*

002000

--文件大小没有变化，并不改写第1块。

SQL> alter database datafile '/u01/app/oracle11g/oradata/test/test01.dbf' resize 65m;

Database altered.

$ dd if=/u01/app/oracle11g/oradata/test/test01.dbf  count=1 bs=8192 2>/dev/null  | od -A x -t x

000000 0000a200 ffc00000 00000000 00000000

000010 0000dae6 00002000 00002080 7a7b7c7d

000020 000081a0 00000000 00000000 00000000

000030 00000000 00000000 00000000 00000000

*

002000

$ od -A x -t x l0.bin

000000 0000a200 ffc00000 00000000 00000000

000010 0000da66 00002000 00002000 7a7b7c7d

000020 000081a0 00000000 00000000 00000000

000030 00000000 00000000 00000000 00000000

*

002000

--可以发现现在已经改写第1块，对比前面的备份看看。0x12-0x13处发现变化,从0xda66=> 0xdae6
--0x1c-0x1d处发现变化，从0x2000=>0x2080.

--猜测有点困难，google找到一篇文章：
http://www.killdb.com/2011/09/05/%E4%B8%8D%E5%AE%8C%E5%85%A8%E8%AF%A6%E8%A7%A3os-block-header.html

顺便导出一个windows oracle 9.2.0.8（32位) 数据文件大小也是64M的第1块看看。
D:\>od -A x -t x -N 64 TOOLS01.DBF
000000 00000000 00002000 00002000 6a6b6c6d
000010 00000606 00000000 00000000 00000000
000020 00000000 00000000 00000000 00000000
*
000040