疯狂

STANDING ON THE SHOULDERS OF GIANTS
posts - 481, comments - 486, trackbacks - 0, articles - 1
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

Oracle 数据块

Posted on 2011-08-16 15:13 疯狂 阅读(2371) 评论(0)  编辑  收藏 所属分类: database

Oracle数据块原理深入剖析-入门基础时间:

数据块(Oracle Data Blocks),本文简称为“块”,是Oracle最小的存储单位,Oracle数据存放在“块”中。一个块占用一定的磁盘空间。特别注意的是,这里的“块”是Oracle的“数据块”,不是操作系统的“块”。

  Oracle每次请求数据的时候,都是以块为单位。也就是说,Oracle每次请求的数据是块的整数倍。如果Oracle请求的数据量不到一块,Oracle也会读取整个块。所以说,“块”是Oracle读写数据的最小单位或者最基本的单位。

  块的标准大小由初始化参数DB_BLOCK_SIZE指定。具有标准大小的块称为标准块(Standard Block)。块的大小和标准块的大小不同的块叫非标准块(Nonstandard Block)。同一数据库中,Oracle9i及以上版本支持同一数据库中同时使用标准块和非标准块。Oracle允许指定5种非标准块(Nonstandard Block)

  操作系统每次执行I/O的时候,是以操作系统的块为单位;Oracle每次执行I/O的时候,都是以Oracle的块为单位。

  Oracle数据块大小一般是操作系统块的整数倍。

  数据块的格式(Data Block Format)

  块中存放表的数据和索引的数据,无论存放哪种类型的数据,块的格式都是相同的,块由块头(header/Common and Variable),表目录(Table Directory),行目录(Row Directory),空余空间(Free Space)和行数据(Row Data)五部分组成,

  如下图所示。

 

  块头(header/Common and Variable):存放块的基本信息,如:块的物理地址,块所属的段的类型(是数据段还是索引段) 表目录(Table Directory):存放表的信息,即:如果一些表的数据被存放在这个块中,那么,这些表的相关信息将被存放在“表目录”中。

  行目录(Row Directory):如果块中有行数据存在,则,这些行的信息将被记录在行目录中。这些信息包括行的地址等。

  行数据(Row Data):是真正存放表数据和索引数据的地方。这部分空间是已被数据行占用的空间。

  空余空间(Free Space):空余空间是一个块中未使用的区域,这片区域用于新行的插入和已经存在的行的更新。

  头部信息区(Overhead):我们把块头(header/Common and Variable),表目录(Table Directory),行目录(Row Directory)这三部分合称为头部信息区(Overhead)。头部信息区不存放数据,它存放的整个块的信息。头部信息区的大小是可变的。一般来说,头部信息区的大小介于84字节(bytes)107字节(bytes)之间。

  数据块中自由空间的使用

  当往数据库中插入(INSERT)数据的时候,块中的自由空间会减少;当对块中已经存在的行进行修改(UPDATE)的时候(使记录长度增加),块中的自由空间也会减少。

  DELETE语句和UPDATE语句会使块中的自由空间增加。当使用DELETE语句删除块中的记录或者使用UPDATE语句把列的值更改成一个更小值的时候,Oracle会释放出一部分自由空间。释放出的自由空间并不一定是连续的。通常情况下,Oracle不会对块中不连续的自由空间进行合并。因为合并数据块中不连续的自由空间会影响数据库的性能。只有当用户进行数据插入(INSERT)或者更新(UPDATE)操作,却找不到连续的自由空间的时候,Oracle才会合并数据块中不连续的自由空间。

  对于块中的自由空间,Oracle提供两种管理方式:自动管理,手动管理

  行链接和行迁移(Row Chaining and Migrating)

  行链接(Row Chaining):如果我们往数据库中插入(INSERT)一行数据,这行数据很大,以至于一个数据块存不下一整行,Oracle就会把一行数据分作几段存在几个数据块中,这个过程叫行链接(Row Chaining)。如下图所示:

 

  如果一行数据是普通行,这行数据能够存放在一个数据块中;如果一行数据是链接行,这行数据存放在多个数据块中。

  行迁移(Row Migrating):数据块中存在一条记录,用户执行UPDATE更新这条记录,这个UPDATE操作使这条记录变长,这时候,Oracle在这个数据块中进行查找,但是找不到能够容纳下这条记录的空间,无奈之下,Oracle只能把整行数据移到一个新的数据块。原来的数据块中保留一个“指针”,这个“指针”指向新的数据块。被移动的这条记录的ROWID保持不变。行迁移的原理如下图所示:

 

 

  无论是行链接还是行迁移,都会影响数据库的性能。Oracle在读取这样的记录的时候,Oracle会扫描多个数据块,执行更多的I/O

  块中自由空间的自动管理

  Oracle使用位图(bitmap)来管理和跟踪数据块,这种块的空间管理方式叫“自动管理”。自动管理有下面的好处:

  ◆易于使用

  ◆更好地利用空间

  ◆可以对空间进行实时调整

  块中自由空间的手动管理

  用户可以通过PCTFREE, PCTUSED来调整块中空间的使用,这种管理方式叫手动管理。相对于自动管理,手动管理方式比较麻烦,不容易掌握,容易造成块中空间的浪费。

  PCTFREE参数用于指定块中必须保留的最小空闲空间百分例。之所以要预留这样的空间,是因为UPDATE时,需要这些空间。如果UPDATE时,没有空余空间,Oracle就会分配一个新的块,这会产生行迁移(Row Migrating)

  PCTUSED也是用于设置一个百分比,当块中已使用的空间的比例小于这个百分比的时候,这个块才被标识为有效状态。只有有效的块才被允许插入数据。

 

文章转载自网管网:http://www.bitscn.com/pdb/oracle/200904/160356.html

 

ORACLE块的分析
(一)
一直以来对“块”的概念总是含混不清,从字面意义理解,只知道这是ORACLE存放数据的最小单位,然而它的内部世界如何呢,本人打算从今天开始连载几篇文档,对它进行深度分析。
通过很多文档、资料,了解到了数据库基本结构鱼刺图:
基本上每个对象对应一个段( Segment),只有分区对应多个段,这里的对象包括tableindexpartition等等,段可以跨越多个数据文件。
每个段又有多个区(extent)来组成,这些区不能跨越多个数据文件,同时在系统使用过程中自动扩展。
最后是块(block),所有的数据都是存放在块中。为了适应操作系统,每个块在创建数据库的时候默认了一个大小,这个大小一般是8K,同时在9I及其以 后的版本中增加了不同大小的块参数,这将在以后的实验中体现。先说说这个8K大小的块,一般来说,为了使得oracle运行读写数据文件的时候有一个合理 的吞吐量,这里的块大小,都跟操作系统块大小设为整数倍,例如ntfs格式化的磁盘文件,每个物理块大小为4,这里oracle的块大小为8,即是代表每 读取一个oracle块,其实物理上也就是读取了两个操作系统块。 这里主要指的是数据文件存放在块设备上,在实际的生产环境中,大部分情况都是将数据库安装在裸设备(RAW)也叫做原始分区之上。关于RAW将在以后进行 讲解。
  
通过上面这段文字,我们可以了解到ORACLE基本的存储结构,下一篇将针对块的大小与存放数据大小来做实验。
(二)
上一节了解到了ORACLE的存储结构,这节讲一讲块的大小与数据存放之间的关系。
大家都知道了在ORACLE环境中,所有的对象都是存放在块中,这个块大小与存放的记录之间到底存在怎样的关系呢?
做一个实验看看:
创建一个表空间test
create tablespace test datafile '/oracle/oradata/test.dbf' size 100m;
创建一个用户
create user test identified by test default tablespace test;
创建一个表
create table test.t1 (a1 number,a2 varchar2(100));
检查段,可以发现在这个视图中出现了名称为T的段,段类型为TABLE,这个段里面分配了1个区,其中包含8个块,大小为64K字节。
select segment_name,blocks,extents,bytes,segment_type,tablespace_name from dba_segments where owner='TEST';
SEGMENT_NAME     BLOCKS    EXTENTS      BYTES SEGMENT_TYPE       TABLESPACE_NAME
---------- ---------- ---------- ---------- ------------------ ----------
T                   8          1      65536 TABLE              TEST
检查区,可以发现在这个视图中出现了一个区,区号为0,包含8个块,大小为64K字节。
select segment_name,segment_type,extent_id,blocks,bytes from dba_extents where owner='TEST';
SEGMENT_NAME SEGMENT_TYPE        EXTENT_ID     BLOCKS      BYTES
---------- ------------------ ---------- ---------- ----------
T          TABLE                       0          8      65536        
检查块,可以发现这里没有载入到内存的块,由此断定,在数据未写入的时候,内存中并没有存放数据的块。
select file#,block#,class#,status,xnc,objd from v$bh where ts#=12;
未选定行
插入10行数据,进行测试。
SQL> declare
  2  i number
  3  ;
  4  begin
  5  for i in 1..10 loop
  6  execute immediate 'insert into test.t values (:x,:y)' using i,i;
  7  end loop;
  8  end;
  9  /
PL/SQL
过程已成功完成。
再次查看v$bh视图,检查内存中是否使用到了块。
select file#,block#,class#,status,xnc,objd from v$bh where ts#=12;
     FILE#     BLOCK#     CLASS# STATU        XNC       OBJD
---------- ---------- ---------- ----- ---------- ----------
         1      28089          4 xcur           0      11038
         1      28090          1 xcur           0      11038
哈哈,果然出现了数据,说明在数据插入的表的时候在内存中已经载入了分配的块,同时在这些块中写入了数据,这里占用了两个块,块号分别为2808928090,其中我们可以根据CLASS#来判断出他们属于不同类型。
(三)
这一节紧接着上一节来说。
上一节通过实验,我们了解到,块的创建和读取流程,不过只是针对一个会话的,现在我们来看看在一个会话中插入数据之后,同时在另外一个会话查询数据,这样的情况会对块有什么影响。
打开一个新的会话, 然后执行如下命令:
查询表,由于插入数据的事务没有提交,这里在另外的会话中就看不到任何数据,深深体现了ORACLE的多版本一致性
select * from test_gao.t;
未选定行
查询视图v$bh,看是否有了变化
select file#,block#,class#,status,xnc,objd from v$bh where ts#=12;
      FILE#     BLOCK#     CLASS# STATU        XNC       OBJD
---------- ---------- ---------- ----- ---------- ----------
         1      28089          4 xcur           0      11038
         1      28090          1 cr             0      11038
         1      28090          1 cr             0      11038
         1      28090          1 xcur           0      11038
果然和上一节查询出来的结果不同,多了红色字体标识出来的两行,大家可以看到这两行的STATUS字段值为cr,什么是cr呢?它是Consistency Read(一致性读取)的缩写。从这里可以看出28090这个块被两个会话进行了操作。
在第一个会话中回滚事务会发生什么呢?看下面的操作:
会话1:执行rollback
SQL> rollback;
回退已完成。
再次查询v$bh视图,看看什么情况
  select file#,block#,class#,status,xnc,objd from v$bh where objd=11038;
     FILE#     BLOCK#     CLASS# STATU        XNC       OBJD
---------- ---------- ---------- ----- ---------- ----------
         1      28089          4 xcur           0      11038
         1      28090          1 cr             0      11038
         1      28090          1 cr             0      11038
         1      28090          1 xcur           0      11038
结果还是一样,说明在事务回滚之后,块还是处于一致读取的状态。
(四)
我们继续上一节的话题。
关闭数据库实例
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
重新打开数据库
SQL>startup
ORACLE
例程已经启动。

Total System Global Area  253214492 bytes
Fixed Size                   454428 bytes
Variable Size             117440512 bytes
Database Buffers          134217728 bytes
Redo Buffers                1101824 bytes
数据库装载完毕。
数据库已经打开。
检查v$bh视图
select file#,block#,class#,status,xnc,objd from v$bh where objd=11038;
未选定行
说明在没有进行块中数据的相关操作的时候,并没有从物理文件中提取块到内存。
执行查询或者插入、更新的SQL语句
SQL> insert into test.t values (200,200);
已创建 1 行。
再次检查v$bh视图
SQL> select file#,block#,class#,status,xnc,objd from v$bh where objd=11038;
     FILE#     BLOCK#     CLASS# STATU        XNC       OBJD
---------- ---------- ---------- ----- ---------- ----------
         1      28089          4 xcur           0      11038
         1      28090          1 xcur           0      11038
总结:在没有进行物理I/O的时候,v$bh视图中不会出现相关的块信息,同时证明此视图中存放的乃是数据文件块放到内存中的“块”信息。

实例讲解Oracle 9i数据坏块的处理

笔者在一台生产用测试库上SELECT一个表时出现ORA-01578,一个块损坏,以前学习过块损坏怎么处理,到还真没遇到过,今天总算让我遇到了,还是一台生产用测试库,就不用很紧张了。

数据库版本是9.2.0.4Oracle9iRMAN有一个blockrecover命令,可以在线修复坏块,以下就是使用RMAN修复坏块的过程。

SQL> conn owi/owi
Connected.
SQL> select * from dpa_history;
select * from dpa_history
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 15, block # 18)
ORA-01110: data file 15: '/d01/app/oracle/oradata/dpa/dpa01.dbf'

ORA-01578数据块损坏,以下使用RMAN命令查询是否可以使用blockrecover命令恢复以及怎样恢复

使用rman登录catalog数据库

[ora9@rmanserver ~]$ rman target sys/oracle@dpa catalog rman/rman

 

Recovery Manager: Release 9.2.0.8.0 - Production

 

Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

 

connected to target database: DPA (DBID=843495022)
connected to recovery catalog database

 

查找最近datafile 15的全备份,今天下午刚做了一次RMAN的全备份

RMAN> list backup of datafile 15;

 


List of Backup Sets
===================

 

BS Key Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
643    Full    64K        DISK        00:00:27     16-MAR-09     
BP Key: 650   Status: AVAILABLE   Tag: TAG20090316T154352
Piece Name: /d02/fullbackup/20090316_data_24_1
List of Datafiles in backup set 643
File LV Type Ckp SCN    Ckp Time Name
---- -- ---- ---------- --------- ----
15      Full 11856250905 16-MAR-09 /d01/app/oracle/oradata/dpa/dpa01.dbf

 

查找SCN 11856250905 以后的archivelog是否有备份

RMAN> list backup of archivelog scn from 11856250905
List of Backup Sets
===================
BS Key Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
680     265K       DISK        00:00:00     16-MAR-09     
BP Key: 681   Status: AVAILABLE   Tag: TAG20090316T154731
Piece Name: /d02/fullbackup/20090316_arch_28
List of Archived Logs in backup set 680
Thrd Seq     Low SCN    Low Time Next SCN   Next Time
---- ------- ---------- --------- ---------- ---------
1    109     11856250805 16-MAR-09 11856251483 16-MAR-09
1    110     11856251483 16-MAR-09 11856251487 16-MAR-09

查找sequence 110 以后的archivelog是否有备份

RMAN> list copy of archivelog from sequence 110;

 

List of Archived Log Copies
Key     Thrd Seq     S Low Time Name
------- ---- ------- - --------- ----
694     1    111     A 16-MAR-09 /d02/arch/1_111.dbf
695     1    112     A 16-MAR-09 /d02/arch/1_112.dbf

 

查询online archive log

 

SQL> select sequence#,members,archived,status from v$log;

 

SEQUENCE#    MEMBERS ARC STATUS
---------- ---------- --- ----------------
113          1 NO CURRENT
111          1 YES INACTIVE
112          1 YES INACTIVE

从以上查询中可以看出datafile 15有一次最近的全备份,有全备份以来的所有archivelogonline redo log
下面开始blockreocver,其实命令很简单

RMAN> blockrecover datafile 15 block 18;

 

Starting blockrecover at 16-MAR-09
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=16 devtype=DISK

 


channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of datafile 00015
channel ORA_DISK_1: restored block(s) from backup piece 1
piece handle=/d02/fullbackup/20090316_data_24_1 tag=TAG20090316T154352 params=NULL
channel ORA_DISK_1: block restore complete

 

starting media recovery

 

archive log thread 1 sequence 111 is already on disk as file /d02/arch/1_111.dbf
archive log thread 1 sequence 112 is already on disk as file /d02/arch/1_112.dbf
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=109
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=110
channel ORA_DISK_1: restored backup piece 1
piece handle=/d02/fullbackup/20090316_arch_28 tag=TAG20090316T154731 params=NULL
channel ORA_DISK_1: restore complete
media recovery complete
Finished blockrecover at 16-MAR-09

SELECT一下表DPA_HISTORY

SQL> select * from dpa_history;

 

PRODLINEID BARCODE                        PA
---------- ------------------------------ --
7          S*33040-D8311050149512B        03
7          S*33040-D8311050143512B        03
7          S*33040-D8311050140512B        03

 

 


只有注册用户登录后才能发表评论。


网站导航: