Oracle DRM 技术的变迁 (二)

原文链接: http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_season_2/

Oracle RAC从10g开始正式引入DRM,但是你是否知道实际上DRM在9i甚至更早以前, Oracle产品架构师就已经在构思这个功能。我们通过查询系统隐含参数发现,在9.2版本中,如下三个十分“可疑”的隐含参数:

_lm_dynamic_remastering (if TRUE enables dynamic remastering)
_lm_dynamic_lms (dynamic remastering bucket window size)
_lm_file_affinity (mapping between file id and master instance n umber)

可以看到这里核心参数为_lm_file_affinity,但是这个参数非常神秘,几乎鲜有人知道这些参数的用法。但是从Oracle TPCC测试的初始化参数中, 我们还是窥测到了_lm_file_affinity的真身:

_lm_file_affinity=”\
14-72,627-664,1304-1331,1641-1645,1701,1713-1717,1798,1826,1873=1:\
73-119,665-713,1332-1359,1646-1650,1702,1718-1722,1786,1825,1827,1874=2:\
120-166,714-762,1360-1387,1651-1655,1703,1723-1727,1787,1828,1839,1875=3:\
167-213,763-811,1388-1415,1656-1660,1704,1728-1732,1788,1829,1840,1876=4:\
214-260,812-860,1416-1443,1661-1665,1705,1733-1737,1789,1830,1841,1877=5:\
261-307,861-909,1444-1471,1666-1670,1706,1738-1742,1790,1831,1842,1878=6:\
308-354,910-958,1472-1499,1671-1675,1707,1743-1747,1791,1832,1843,1879=7:\
355-401,959-1007,1500-1527,1676-1680,1708,1748-1752,1792,1833,1844,1880=8:\
402-448,1008-1055,1528-1555,1681-1685,1709,1753-1757,1793,1835,1845,1881=9:\
449-494,1056-1103,1556-1583,1686-1690,1710,1758-1762,1794,1836,1849,1882=10:\
495-540,1104-1151,1584-1611,1691-1695,1711,1763-1767,1795,1837,1863,1883=11:\
541-586,1152-1199,1612-1639,1696-1700,1712,1768-1772,1796,1838,1872,1884=12″

可以猜测到以上参数出自一个12节点的rac数据库, 数据文件号从14开始到1872结束,连续的文件用连接符号隔开,每个节点上map了多个数据文件。

在9i中,上述情形更像是通过手工指定了文件的master节点,所以算不上DRM。而DRM功能的真正实现是始于10gR1这个版本,但是因为在10gR1中只实现了粗粒度的数据文件级的file affinity,但是dynamic remaster的条件过于苛刻,以至于很多人甚至根本就没有察觉到这个特性的存在。到了10gR2, file affinity进一步演化为更细粒度的object affinity,并且同时引入了undo affinity。

用一句最简单的话概括object affinity就是,哪个节点访问这个object的频率较高,就由哪个节点来充当master节点。具体的阈值可以由以下两个参数来决定:

_gc_affinity_time (Time in minutes at which statistics will be evaluated (default = 10 mins) )
_gc_affinity_limit  ( times a node accesses a file/object (default = 50))

从上述参数的默认值可以知道, DRM的临界条件为在10分钟以内,某node访问一个文件/对象的次数比另外一个节点多50次,那么这个节点就会成为此object的master节点的候选,从而能够尽量减少gc remote grants的产生。而原始master节点的分配是在启动的时候根据特定的hash算法来完成的,这一点在上一篇文章中已经有描述。

另外master节点是没有记忆和学习功能的,也就是说如果发生重启或者集群重组以后,以往的master节点的记录会被清零,然后重新分配。

undo affinity与object affinity类似,但是又不完全一样,这主要取决于undo本身的特殊性。对于undo segment而言,激活某个回滚段的实例会立即成为该回滚段段的master节点。这里的激活可以用另外一个词来替代:online。这种机制的依据是:在绝大多数情况下,undo段将会被online它的实例使用。更详细的undo段的master节点分配机制如下:

1. 对于自动管理的undo表空间而言,在实例启动的时候, undo_tablespace初始化参数指定的undo表空间下所有undo段都被会被这个实例online,所以这个实例就是这些undo段的master节点。。

2. 对于手动管理的undo表空间而言,在实例启动的时候, rollback_segments初始化参数指定的所有undo段都会被这个实例online,所以这个实例就是这些undo段的master节点。

3. 当手工创建(create)并且online新的undo表空间的时候,新的undo表空间/undo段的master节点由undo表空间所在的节点来充当。

只有当其中一个实例crash以后,幸存的实例才会暂时成为crash的实例上undo buffer的master节点, 进行恢复的工作,当恢复完成以后,就会把这些undo buffer 刷到磁盘上。当实例重新加入进来以后,这些undo buffer的master节点会再次重新回归到原来的节点。undo的remaster的触发条件比较苛刻,很难创建一个完整的test case对其进行模拟。我们可以将隐含参数_gc_undo_affinity隐含参数设置为false来关闭undo affinity这个特性。

 

未完待续

To Be Continued…

Comment

*

沪ICP备14014813号

沪公网安备 31010802001379号