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

武汉-SSH

看老盖的《循序渐进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 编辑 ]

武汉-SSH

我错了，实测32GB文件，KTFB Bitmapped File Space Bitmap 个数变成了14
63488*14*64KB= 54.25 GB

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

武汉-SSH

db_block_size=8 KB，文件头会保留8个数据块；
http://book.51cto.com/art/201108/288113.htm

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

Maclean Liu(刘相兵

ODM Testing

1. SQL> select * from v$version;
   
2. 
   
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
   
10. 
    
11. 
    
12. SQL> create tablespace small datafile '/s01/small.dbf' size 10M;
    
13. 
    
14. Tablespace created.
    
15. 
    
16. SQL> create table tb1 (t1 int) storage (initial 128k) tablespace small;
    
17. 
    
18. Table created.
    
19. 
    
20. SQL> alter system checkpoint;
    
21. 
    
22. System altered.
    
23. 
    
24. SQL> alter system dump datafile '/s01/small.dbf' block 3;
    
25. 
    
26. System altered.
    
27. 
    
28. SQL> oradebug setmypid;
    
29. Statement processed.
    
30. 
    
31. SQL> oradebug tracefile_name;
    
32. /s01/admin/G10R21/udump/g10r21_ora_3692.trc
    
33. 
    
34. 
    
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;
   
2. 
   
3. Tablespace created.
   
4. 
   
5. 
   
6. SQL> create tablespace large datafile '/s01/large.dbf' size 32767M;
   
7. 
   
8. Tablespace created.
   
9. 
   
10. SQL> alter system dump datafile '/s01/large.dbf'  block 3;
    
11. 
    
12. System altered.
    
13. 
    
14. 
    
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
    
43. 
    
44. alter system dump datafile '/s01/large.dbf'  block 16;
    
45. 
    
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 被浪费。

武汉-SSH

想到一个问题，若是一开始指定SIZE 10GB，KTFB Bitmapped File Space Bitmap 为 6 ，BeginBlock 为9，然后又RESIZE 到 32GB，如何找到新的KTFB Bitmapped File Space Bitmap？

武汉-SSH

EXTENT MAP BLOCK:
http://www.itpub.net/thread-947547-1-1.html