关于OAM page

核心提示：可能是一个多月前看到小无赖提出的两个问题，最近抽空试了一下，关于OAM page，原问题如下：一个对象是否只有一个对象分配页OAM? http://chinaunix.net/forum/viewtopic.php?t=65106&highlight=OAM一个OAM能存储多少个分配单元的信息? http://chin

可能是一个多月前看到小无赖提出的两个问题，最近抽空试了一下。
原问题如下：
一个对象是否只有一个对象分配页OAM? 
http://chinaunix.net/forum/viewtopic.php?t=65106&highlight=OAM


一个OAM能存储多少个分配单元的信息? 
http://chinaunix.net/forum/viewtopic.php?t=82826&highlight=OAM

我在solaris上建立了一个数据库test，4G data, 1G log, 并建立了一个表test,
经过一整夜的疯狂插入，最终的结果如下：
sp_spaceused test
 name　　　　　　　　 rowtotal　　reserved　　　　data
　　　　 index_size　　　unused
 -------------------- ----------- --------------- ---------------
　　　　--------------- ---------------
 test　　　　　　　　 300719376　 4176724 KB　　　4176658 KB
　　　　 0 KB　　　　　　66 KB
首先可以回答第一个问题，表并没有2G的限制，只要设备足够大，表就可以足够大。
通过dbcc listoam("test", 32000114, 0)
得到以下的输出：
-----------------------------------------------------------------------------
Objid:　 32000114　　 indid:　 0
[color=red:49a6d2b4e5]OAM pg cnt:　　 33 [/color:49a6d2b4e5]　　 Entry cnt:　　　 8190
Rows:　　　300719376　　Rows Per pg:　　　144
Used pgs:　2088362　　　Unused pgs:　　　　 0
Attribute entries:　　　 10
OAM status bits set:　(0x8000 (PG_OAMPG), 0x0008 (PG_OAMATTRIB))
LAST SCANNED OAM PAGE:　　　　　0
ALLOCATION HINTS　　 :
　　　 513　　　56833　　 120833　　 184833
　　248833　　 312833　　 376833　　 440833
　　504833　　 568833　　 632833　　 696833
　　760833　　 824833　　 888833
IDENTITY Max burned value from disk:　　NULL From the DES:　　　NULL
OAM pg #　　　　513 has the following　　 240 entries (allocpg:used/unused

　　　 512:167/　0　　　 768:255/　0　　　1024:255/　0　　　1280:255/　0
　　　1536:255/　0　　　1792:255/　0　　　2048:255/　0　　　2304:255/　0
　　　2560:255/　0　　　2816:255/　0　　　3072:255/　0　　　3328:255/　0
　　　3584:255/　0　　　3840:255/　0　　　4096:255/　0　　　4352:255/　0
　　　4608:255/　0　　　4864:255/　0　　　5120:255/　0　　　5376:255/　0
　　　5632:255/　0　　　5888:255/　0　　　6144:255/　0　　　6400:255/　0
　　　6656:255/　0　　　6912:255/　0　　　7168:255/　0　　　7424:255/　0
　　　7680:255/　0　　　7936:255/　0　　　8192:255/　0　　　8448:255/　0
　　　8704:255/　0　　　8960:255/　0　　　9216:255/　0　　　9472:255/　0
　　　9728:255/　0　　　9984:255/　0　　 10240:255/　0　　 10496:255/　0
。。。。。。
显然，他有33个OAM page。
所以，一个对象可以有多个OAM page。
那么，一个OAM能存储多少个分配单元的信息（小无赖的提法）?或者说，一个OAM page可以管理多大的数据空间呢？
其实，小无赖的这个提法是对的，一个OAM页中存放的纪录称为OAM entry。一个entry为8个字节，包括AU(Allocation unit)的地址，AU中分配的页面数/未分配的页面数.
我的表的大小为4176658 k(由以上的sp_spaceused输出得到)，又有33个OAM page。
因此，一个OAM page可以管理的数据空间大约为：
CapacityManagedByOneOAMPage = 
　　4176658 k / 33 = 123.6 M
也就是说，当表的空间大于123.6M时，就需要新的OAM page了

实际上，这个估算是比较准确的，OAM page 是以双向循环链表的方式连接在一起的，第一个OAM page可以存放240个 OAM entry, 余下的OAM page可以存放250个 OAM entry. 就以250为准。
CapacityManagedByOneOAMPage = 
　　250 * 
　　NumberOfDataPagesInAllocationUnit *
　　LogicalPageSize / 1024(M)
这里NumberOfDataPagesInAllocationUnit为255而非256,是因为AU中的第一页为allocation page。不计在内
LogicalPageSize就以2K代入吧,我的@@pagesize = 2k
结果等于
CapacityManagedByOneOAMPage = 
　　250 * 
　　255 *
　　2 / 1024 = 124.5M
与前面估算的差不多吧
还有一个有趣的现象，在sp_spaceused中
unused = 66kb，正好是33个OAM page 占用的空间

不知道讲明白了没，希望对大家又帮助