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…