[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
				


				
时间： 2024-07-30 10:46:50

		
		


		


	

	
	

		


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


								

		

			

                [20161110]数据文件的第0块.txt
			

		

		

									

				[20161110]数据文件的第0块.txt --如果数据文件的第0块是OS块信息,以前的测试如果rman做备份集都不会备份. --如果这块损坏,里面讲问题不大,你甚至可以不修复,当然重建控制文件就出现问题. --而且解决也很简单,就是建立一样大小的数据文件,然后copy回去.做一个测试例子: 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER -------------------			

		

	

				

		

			

                EXT4文件系统上ORACLE数据文件误删除的对应恢复方法
			

		

		

									

				如果EXT4文件系统上的ORACLE数据文件被误删除了,那么一般可以考虑下面2种恢复方式: 使用testdisk工具从文件系统角度恢复数据文件 使用prmscan工具从oracle 数据块角度恢复数据文件 这里我们介绍使用testdisk的恢复ext4上数据文件的步骤: 删除users数据文件   [oracle@dbdao01 ~]$ df -h Filesystem            Size  Used Avail Use% Mounted on /dev/mapper/VolGrou			

		

	

				

		

			

                收缩Oracle数据文件
			

		

		

									

				      最近有网友提到收缩Oracle数据文件的问题,这是DBA经常碰到的一个常见问题.通常我们需要收缩相应的数据文件以减少来自磁盘空间的压力以及提高数据库的整体性能.但这并非对于所有情形都是适用的,尤其是生产环境.因为生产环境数据清洗相当较少,因此空间浪费也比较小,而且一旦收缩之后又要重新自动扩展数据文件,浪费系统资源.对于UAT,DEV环境,多DB,磁盘空间压力大的情形,收缩一下非常有必要.勒紧裤带过日子也是常有的事情,哈哈.总之收缩数据文件会使得磁盘空间得以释放以及加快数据迁移,RMA			

		

	

				

		

			

                oracle数据文件，恢复数据库问题
			

		

		

									

				问题描述 oracle数据文件,恢复数据库问题 一直用的mysql,今天老板突然给我一个oracle的文件,说让我恢复oracle数据库,表示搞不定请教诸位.			

		

	

				

		

			

                [20161111]数据文件的第0块2.txt
			

		

		

									

				[20161111]数据文件的第0块2.txt --如果数据文件的第0块是OS块信息,以前的测试如果rman做备份集都不会备份. --如果这块损坏,里面讲问题不大,你甚至可以不修复,如果在线resize就ok了,当然重建控制文件就出现问题. --而且解决也很简单,就是建立一样大小的数据文件,然后copy回去.做一个测试例子: 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ---			

		

	

				

		

			

                Oralce OMF功能详解(一） Oracle数据文件的OMF管理
			

		

		

									

				OMF,全称是Oracle_Managed Files,即Oracle文件管理,使用OMF可以简化管理员的管理工作,不用指定文件的名字.大小.路径,其名字,大小,路径由oracle 自动分配.在删除不再使用的日志.数据.控制文件时,OMF也可以自动删除其对应的OS文件. OMF支持下列文件的自动管理: (1)表空间 (2)日志文件(联机) (3)控制文件 前提条件:需要为这些类型文件设定相关参数. 一.数据文件的OMF管理 数据文件管理参数:db_create_file_dest db_crea			

		

	

				

		

			

                windows系统 Oracle数据文件大小为0的恢复例子
			

		

		

									

				一个网友的数据库部署在windows环境,可能是由于存储问题或者windows本身文件系统的问题,出现IO问题之后,最后数据库重启之后,竟然无法启动了,报错无法读取其中的几个文件,alert log如下: Nov 14 12:33:12 2014 Errors in file d:\oracle\diag\rdbms\orcl\orcl\trace\orcl_m001_1704.trc  (incident=60577): ORA-00700: soft internal error, argu			

		

	

				

		

			

                批量迁移Oracle数据文件，日志文件及控制文件
			

		

		

									

				   有些时候需要将Oracle的多个数据文件以及日志文件重定位或者迁移到新的分区或新的位置,比如磁盘空间不足,或因为特殊需求.对于这种情形可以采取批量迁移的方式将多个数据文件或者日志文件实现一次性迁移.当然备份恢复也是其中的方式之一.本文主要描述如何使用批量方式来迁移数据文件,日志文件.如需要也可以将整个数据库迁移到新的位置以及重命名数据库. 1.环境及需求 robin@SZDB:~> cat /etc/issue Welcome to SUSE Linux Enterprise Server			

		

	

				

		

			

                Oracle 数据文件 reuse 属性 说明
			

		

		

									

				原文转自:http://blog.csdn.net/tianlesoftware/article/details/6462259 有关表空间创建的相关参数,参考:        Oracle 表空间 创建参数 说明          http://blog.csdn.net/changyanmanman/article/details/7388558          当我们对表空间添加数据文件的时候,有一个reuse 属性. 10g的官网对这个参数的说明如下:   REUSE Specify