SETOBJACC/CLRPOOL命令使用

li6612773

實(shí)驗(yàn)了一下，把pf加入內(nèi)存后再處理，一個(gè)6400萬(wàn)的表12分鐘處理完。 但是，可悲的是沒(méi)加到內(nèi)存里處理的時(shí)候也是12分鐘，對(duì)于有讀寫(xiě)，順序訪問(wèn)的表沒(méi)必要用setobjacc

http://blog.chinaunix.net/uid-2271579-id-3487396.html

passthru

"把pf加入內(nèi)存后再處理，一個(gè)6400萬(wàn)的表12分鐘處理完..."

‘處理’是什么？

在270環(huán)境下，讀6400萬(wàn)條記錄大約512秒。如果需12分鐘，肯定每一條記錄要經(jīng)過(guò)‘處理’。用setobjacc把pf表裝載或沒(méi)有裝載，這個(gè)pf表6400萬(wàn)條記錄‘處理’，時(shí)間上都是一樣。所以，肯定是每一條記錄處理的時(shí)間與裝載時(shí)間差別可以到用setobjacc的時(shí)間效果可以忽略不計(jì)。

li6612773

為了做測(cè)試，虛擬了一個(gè)場(chǎng)景，從表T1中讀出，然后寫(xiě)入另一張表，再update T1的某個(gè)字段。

uxyzp

270是啥……

li6612773

機(jī)器回復(fù) 4# uxyzp


   

qiao_zq

樓主能否將在2種不同情況下具體的i/o次數(shù)列出來(lái)？

li6612773

回復(fù) 6# qiao_zq
由于是順序訪問(wèn)，具體的IO應(yīng)該和之前是相同的。
這個(gè)實(shí)驗(yàn)也驗(yàn)證了setobjacc在實(shí)際應(yīng)用中只適合帶key pf的隨機(jī)訪問(wèn)場(chǎng)景，而對(duì)于順序訪問(wèn)的應(yīng)用作用微乎其微。

以下是IBM的專家在討論中給出的建議，這里同時(shí)也感謝一下：

key和LF提升訪問(wèn)數(shù)據(jù)的效率的前提是訪問(wèn)的數(shù)據(jù)量占全表的15%以下，訪問(wèn)的數(shù)據(jù)越小，效率提升越高。有些業(yè)務(wù)應(yīng)用，不得不按照某個(gè)key來(lái)遍歷全表，即按照某個(gè)列的順序來(lái)訪問(wèn)全表數(shù)據(jù)，這種情況下，由于對(duì)于每個(gè)key的值，我們無(wú)法預(yù)計(jì)下一個(gè)要讀取的記錄在哪里，所以，無(wú)法使用預(yù)讀取技術(shù)，大量的隨機(jī)讀取，會(huì)導(dǎo)致訪問(wèn)效率的急劇下降。此時(shí)，將PF和LF通過(guò)setobjacc置入private pool才有明顯的性能提升。也就是您說(shuō)的頻繁隨機(jī)讀取數(shù)據(jù)，這種情況，才需要setobjacc。setobjacc大多在日終批處理或聯(lián)機(jī)業(yè)務(wù)的靜態(tài)參數(shù)表使用。

沒(méi)有辦法，讓pf加載到內(nèi)存中后，更新和寫(xiě)數(shù)據(jù)的時(shí)候和物理磁盤(pán)脫鉤，實(shí)現(xiàn)近似于完全內(nèi)存操作的效果，以提高效率。
答：pf加載到內(nèi)存中后，更新和寫(xiě)數(shù)據(jù)就是在內(nèi)存中完成的。對(duì)于單純的寫(xiě)操作來(lái)說(shuō)，內(nèi)存操作和磁盤(pán)操作，效率差別不大，因?yàn)閷?xiě)入cache就算寫(xiě)操作完成。除非有特殊的設(shè)置，要求一定數(shù)據(jù)落硬盤(pán)。


   

passthru

呵呵，節(jié)后，我測(cè)試一把再續(xù)這個(gè)話題。之前樓主所說(shuō)的，我表示懷疑。