在DB2 9.5版本中，數(shù)據(jù)庫(kù)引擎由基于過程模式轉(zhuǎn)變?yōu)榫€程模式，這將意味著整個(gè)數(shù)據(jù)庫(kù)引擎都在一個(gè)地址空間下(任何代碼段都可以訪問任何全局變量)。這自然是有利也有弊。其中一個(gè)有利的方面是線程比過程更“輕”，這表示DB2的性能更好。有人做過測(cè)試顯示DB2 9.5的性能在負(fù)荷運(yùn)行情況下比相同狀態(tài)下的DB2 9.1提升了2%到5%。

而不利的方面是，在任何與緩沖池?zé)o關(guān)的任何db2代碼路徑中的任何db2錯(cuò)誤都有可能會(huì)破壞數(shù)據(jù)頁。此外，和db2共享相同地址空間的非保護(hù)模式下的用戶自定義函數(shù)(unfenced UDF)也有可能會(huì)破壞內(nèi)存頁。而后，這些不正確數(shù)據(jù)頁就會(huì)在毫不察覺的情況下被寫入磁盤里，而你很可能永遠(yuǎn)都不會(huì)知道這些數(shù)據(jù)已經(jīng)出現(xiàn)了不一致。線程模式還會(huì)產(chǎn)生與非保護(hù)模式下的用戶自定義函數(shù)相關(guān)的安全問題，因?yàn)榫€程模式在潛在情況下會(huì)允許惡意用戶代碼在沒有得到授權(quán)的情況下讀寫數(shù)據(jù)頁。如果在保護(hù)(fensed)模式下運(yùn)行用戶自定義函數(shù)，這些問題就都不成問題，用戶代碼會(huì)通過一個(gè)子過程執(zhí)行并且會(huì)通過IPC與DB2進(jìn)行交流，唯一的問題就是這樣做比在非保護(hù)模式下運(yùn)行要慢很多。

在IBM的Power6 CPU上市的時(shí)候，也帶來了一項(xiàng)用于內(nèi)存保護(hù)的新技術(shù)就是用戶級(jí)別存儲(chǔ)鍵技術(shù)。這里不是說的內(nèi)核級(jí)別存儲(chǔ)鍵，這個(gè)已經(jīng)存在了一段時(shí)間，而用戶級(jí)別的存儲(chǔ)鍵則是個(gè)新東西。存儲(chǔ)鍵能夠使應(yīng)用程序鎖定內(nèi)存頁，防止對(duì)其進(jìn)行任何形式的讀寫組合操作。

必須支持CPU上的存儲(chǔ)鍵是因?yàn)閮?nèi)存訪問的速度非常之快(達(dá)到納秒級(jí))，在軟件水平是無法做到的。存儲(chǔ)鍵使在用戶空間執(zhí)行的DB2引擎能夠防止代碼段對(duì)緩沖池?cái)?shù)據(jù)頁進(jìn)行無授權(quán)的讀寫操作。當(dāng)然，如果你是在AIX上運(yùn)行Power6處理器，那這只是其中一個(gè)可選的保護(hù)措施。啟動(dòng)該功能需要5%到6%的性能開銷。用下面的語句啟動(dòng)該功能：

以下是引用片段：

db2set DB2_MEMORY_PROTECT=yes RESTART YOUR INSTANCE

你需要運(yùn)行AIX 5.3 ML6(或更高版本)或AIX 6.1版操作系統(tǒng)。

假如你還在AIX上開發(fā)c或c++代碼，而且并不適用Java的話，你可以選擇使用ukey_protect( address, size, UKEY_PRIVATE)函數(shù)來協(xié)助保護(hù)數(shù)據(jù)內(nèi)存結(jié)構(gòu)。