关于OAM page

　　 
可能是一个多月前看到小无赖提出的两个问题，最近抽空试了一下。
原问题如下：
一个对象是否只有一个对象分配页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的限制，只要设备足够大，表就可以足够大。
通过dbclearcase/" target="_blank" >cc 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 占用的空间

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

原文转自：http://www.ltesting.net