Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
Oracle数据库数据恢复、性能优化»论坛 › Oracle › Oracle数据库管理 › “所以64KB就是该表空间的一个位”---这句话真的对吗？ ...
发新帖
武汉-SSH

316

积分

0

好友

0

主题

“所以64KB就是该表空间的一个位”---这句话真的对吗？

1#
发表于 2012-2-17 19:10:34 | 查看: 5473| 回复: 5
看老盖的《循序渐进Oracle：数据库管理、优化与备份恢复》第5章表空间和数据文件，
参考：
http://book.51cto.com/art/201108/288118.htm
简单提一下的是，在自动分配的本地管理的表空间中，区间大小可能由以下尺寸组成64KB、1MB、8MB、64MB甚至是256MB。但是不管多大，都有一个通用尺寸64KB，所以64KB就是该表空间的一个位标记的大小。

的确，在测试SMALL FILE TABLESPACE 的时候，8K环境，每个文件应该可以容纳63488*6个区，测算的话，一个位图bit也的确是64KB，但是如果一个位图bit是64KB，那么单个文件所容纳的容量不就是
63488*6*64KB=23.25GB，这远远小于32GB啊？



也可以参考：http://oaktable.net/articles/locally-managed-tablespaces，与老盖的无甚区别。
With an auto-allocate tablespace, the extent sizes consist of the units 64k, 1m, 8m, 64m and possibly 256m. The greatest common divisor of these values is 64k, so each bit in the bitmap will represent a 64k chunk of an extent.



谁能把这一块描述清楚呢？还有EXTENT MAP BLOCK 到底是怎么被ORACLE使用的呢？

[ 本帖最后由 武汉-SSH 于 2012-2-17 19:16 编辑 ]
2#
发表于 2012-2-17 19:55:24
我错了，实测32GB文件，KTFB Bitmapped File Space Bitmap 个数变成了14
63488*14*64KB= 54.25 GB

[ 本帖最后由 武汉-SSH 于 2012-2-17 20:03 编辑 ]

回复 只看该作者 道具 举报

3#
发表于 2012-2-17 20:07:27
db_block_size=8 KB，文件头会保留8个数据块；
http://book.51cto.com/art/201108/288113.htm

看来老盖的书需要勘误啊！

回复 只看该作者 道具 举报

4#
发表于 2012-2-17 23:25:34
ODM Testing

  1. SQL> select * from v$version;

  3. BANNER
  4. ----------------------------------------------------------------
  5. Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
  6. PL/SQL Release 10.2.0.1.0 - Production
  7. CORE    10.2.0.1.0      Production
  8. TNS for Linux: Version 10.2.0.1.0 - Production
  9. NLSRTL Version 10.2.0.1.0 - Production


  12. SQL> create tablespace small datafile '/s01/small.dbf' size 10M;

  14. Tablespace created.

  16. SQL> create table tb1 (t1 int) storage (initial 128k) tablespace small;

  18. Table created.

  20. SQL> alter system checkpoint;

  22. System altered.

  24. SQL> alter system dump datafile '/s01/small.dbf' block 3;

  26. System altered.

  28. SQL> oradebug setmypid;
  29. Statement processed.

  31. SQL> oradebug tracefile_name;
  32. /s01/admin/G10R21/udump/g10r21_ora_3692.trc


  35. File Space Bitmap Block:
  36. BitMap Control:
  37. RelFno: 29, BeginBlock: 9, Flag: 0, First: 2, Free: 63486
  38. 0300000000000000 0000000000000000 0000000000000000 0000000000000000
  39. 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  40. 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  41. 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  42. 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  43. 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  44. 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  45. 0000000000000000 0000000000000000 0000000000000000 0000000000000000
复制代码




030=> 0000 0011 0000   bit   =>  128K

Local Extent  Management 下最小一个Extent = 8 个 oracle block
当 db_block_size=8k 时 即一个bit 代表64k
一个位图bit 代表64k ， 在 8k标准块情况下是正确的。

RelFno: 29, BeginBlock: 9, Flag: 0, First: 2, Free: 63486

这里还可以看懂 Data Beginblock:9

即一个数据文件的 第1-2个块是 datafile header 是被保留的，  3-8 个块是KTFB Bitmapped File Space Bitmap， 从第九个块开始 是数据。即在此数据文件上文件头 datafile header  保留了8个块(耐心看完)。


ODM Test2:


  1. SQL> create tablespace large datafile '/s01/large.dbf' size 32767M;

  3. Tablespace created.


  6. SQL> create tablespace large datafile '/s01/large.dbf' size 32767M;

  8. Tablespace created.

  10. SQL> alter system dump datafile '/s01/large.dbf'  block 3;

  12. System altered.


  15. Start dump data block from file /s01/large.dbf minblk 3 maxblk 3
  16. V10 STYLE FILE HEADER:
  17.         Compatibility Vsn = 169869568=0xa200100
  18.         Db ID=2807279631=0xa753b00f, Db Name='G10R21'
  19.         Activation ID=0=0x0
  20.         Control Seq=31695=0x7bcf, File size=4194176=0x3fff80
  21.         File Number=30, Blksiz=8192, File Type=3 DATA
  22. Dump all the blocks in range:
  23. buffer tsn: 13 rdba: 0x07800003 (30/3)
  24. scn: 0x0000.00d3479d seq: 0x01 flg: 0x04 tail: 0x479d1e01
  25. frmt: 0x02 chkval: 0x4741 type: 0x1e=KTFB Bitmapped File Space Bitmap
  26. Hex dump of block: st=0, typ_found=1
  27. Dump of memory from 0x0000000006F8A200 to 0x0000000006F8C200
  28. 006F8A200 0000A21E 07800003 00D3479D 04010000  [.........G......]
  29. 006F8A210 00004741 0000001E 00000011 00000000  [AG..............]
  30. 006F8A220 00000000 0000F800 00000000 00000000  [................]
  31. 006F8A230 00000000 00000000 00000000 00000000  [................]
  32.         Repeat 507 times
  33. 006F8C1F0 00000000 00000000 00000000 479D1E01  [...............G]
  34. File Space Bitmap Block:
  35. BitMap Control:
  36. RelFno: 30, BeginBlock: 17, Flag: 0, First: 0, Free: 63488
  37. 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  38. 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  39. 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  40. 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  41. 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  42. 0000000000000000 0000000000000000 0000000000000000 0000000000000000

  44. alter system dump datafile '/s01/large.dbf'  block 16;

  46. Start dump data block from file /s01/large.dbf minblk 16 maxblk 16
  47. V10 STYLE FILE HEADER:
  48.         Compatibility Vsn = 169869568=0xa200100
  49.         Db ID=2807279631=0xa753b00f, Db Name='G10R21'
  50.         Activation ID=0=0x0
  51.         Control Seq=31695=0x7bcf, File size=4194176=0x3fff80
  52.         File Number=30, Blksiz=8192, File Type=3 DATA
  53. Dump all the blocks in range:
  54. buffer tsn: 13 rdba: 0x07800010 (30/16)
  55. scn: 0x0000.00d347b7 seq: 0x01 flg: 0x04 tail: 0x47b71e01
  56. frmt: 0x02 chkval: 0x8736 type: 0x1e=KTFB Bitmapped File Space Bitmap
  57. Hex dump of block: st=0, typ_found=1
  58. Dump of memory from 0x0000000006F8A200 to 0x0000000006F8C200
  59. 006F8A200 0000A21E 07800010 00D347B7 04010000  [.........G......]
  60. 006F8A210 00008736 0000001E 0064C011 00000000  [6.........d.....]
  61. 006F8A220 00000000 0000F800 00000000 00000000  [................]
  62. 006F8A230 00000000 00000000 00000000 00000000  [................]
  63.         Repeat 507 times
  64. 006F8C1F0 00000000 00000000 00000000 47B71E01  [...............G]
  65. File Space Bitmap Block:
  66. BitMap Control:  
  67. RelFno: 30, BeginBlock: 6602769, Flag: 0, First: 0, Free: 63488
  68. 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  69. 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  70. 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  71. 0000000000000000 0000000000000000 0000000000000000 0000000000000000
复制代码


RelFno: 30, BeginBlock: 17, Flag: 0, First: 0, Free: 63488

BeginBlock: 17=》KTFB Bitmapped File Space Bitmap 的范围从 3-8 扩展到了 3-16 = 14 个块

14 * 64KB * 63488= 54.25  超过了 8k block size的small datafile的最大大小32g

也就是说 File space Bitmap的区域会随着数据文件增长的需求 而扩展：
10g small datafile 下 (11g 范围更大)
最少且默认为  6个 File Space Bitmap 块      = 8k block size时 23.25g
最多为 14个File Space Bitmap 块                 = 8k  block size 时 54.25g

但是因为单个small datafile 数据文件的 block总数上限为4194303 个( 4194303 * 8k = 32g)  所以实际达不到54.25g，会有部分File Space Bitmap 被浪费。

回复 只看该作者 道具 举报

5#
发表于 2012-2-20 10:55:02
想到一个问题，若是一开始指定SIZE 10GB，KTFB Bitmapped File Space Bitmap 为 6 ，BeginBlock 为9，然后又RESIZE 到 32GB，如何找到新的KTFB Bitmapped File Space Bitmap？

回复 只看该作者 道具 举报

6#
发表于 2012-2-20 11:45:54
EXTENT MAP BLOCK:
http://www.itpub.net/thread-947547-1-1.html

回复 只看该作者 道具 举报

返回列表
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-11-15 01:41 , Processed in 0.061349 second(s), 22 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569