[20121115]關於oracle資料檔案的第1塊.txt

lfree發表於2012-11-20
Oracle
[20121115]關於oracle資料檔案的第1塊.txt

每個資料檔案的第一個塊(block 0)是OS block header，在資料庫中查詢不到資訊，記錄的是OS資訊，以及檔案大小的等資訊.
今天做一些簡單的研究。

SQL> select * from v$version where rownum<=1;

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找到一篇文章：
%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



來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/267265/viewspace-749525/，如需轉載，請註明出處，否則將追究法律責任。

相關文章