我認(rèn)識(shí)的很多Oracle DBA都在學(xué)習(xí)PG，不論是國(guó)內(nèi)還是國(guó)外。數(shù)據(jù)庫(kù)多元化發(fā)展，擁抱開源是一個(gè)趨勢(shì)性的東西。對(duì)于Oracle DBA來(lái)說(shuō)，PG這樣的學(xué)院派數(shù)據(jù)庫(kù)無(wú)論從架構(gòu)上還是從功能上都有一定的相似性，學(xué)習(xí)起來(lái)會(huì)感到比較親切。雖然如此，PG數(shù)據(jù)庫(kù)和Oracle是差異很大的，哪怕一些看似近似的概念，因?yàn)閮煞N數(shù)據(jù)庫(kù)的實(shí)現(xiàn)方式不同，在實(shí)際應(yīng)用中的差異很大。今天我就通過(guò)幾個(gè)容易引發(fā)誤解的問題，給大家提個(gè)醒。

曾經(jīng)有人和我討論P(yáng)G的WORK_MEM，他覺得PG的WORK_MEM就有點(diǎn)類似于Oracle的PGA手工管理。粗粗一看，好像還真的像，不過(guò)如果你完全按照使用Oracle PGA的*_area_size一樣來(lái)使用WORK_MEM，那是早晚會(huì)遇到坑的。我們知道，PG數(shù)據(jù)庫(kù)缺少HASH ANTI JION算子，因此在處理一些NOT IN類型的子查詢時(shí)往往使用Filter算子，這個(gè)算子通過(guò)對(duì)子查詢的結(jié)果集生成HASH表，然后由外表來(lái)循環(huán)探測(cè)，最終完成NOT IN過(guò)濾。

圖片

這種執(zhí)行計(jì)劃，雖然外表比較大的時(shí)候效率不高，不過(guò)總體執(zhí)行性能大多數(shù)情況下還是能接受的。如果我們繼續(xù)加大T2表符合條件的結(jié)果集的數(shù)據(jù)量，再來(lái)執(zhí)行一下這條SQL。

圖片

當(dāng)內(nèi)表的結(jié)果集需要生成的HASH表的大小大于WORK_MEM的時(shí)候，執(zhí)行計(jì)劃居然變了。在不使用HASH表的情況下，這條SQL的執(zhí)行時(shí)間惡化到75146毫秒。我的測(cè)試環(huán)境是PG 14,起碼在這個(gè)當(dāng)前使用量比較大的版本中，PG是不會(huì)使用多個(gè)WORK_MEM，或者采用類似Oracle的2-PASS HASH TABLE的機(jī)制來(lái)動(dòng)態(tài)處理的。在這種情況下，我們只能通過(guò)會(huì)話級(jí)臨時(shí)加大WORK_MEM來(lái)解決問題。

圖片

上面的例子可以看出，當(dāng)WORK_MEM加大到128MB的時(shí)候，又開始使用HASH表了，執(zhí)行效率也回來(lái)了。

對(duì)Oracle DBA的第一個(gè)認(rèn)知挑戰(zhàn)是，WORK_MEM設(shè)置的改變會(huì)影響SQL的執(zhí)行計(jì)劃?？赡墁F(xiàn)在的Oracle DBA已經(jīng)忘記PGA手工管理了，在當(dāng)年服務(wù)器內(nèi)存資源有限，磁盤IO性能極差的年代里，設(shè)置合理的PGA參數(shù)并非易事。目前面對(duì)PG，可能這個(gè)問題會(huì)更加嚴(yán)峻，在一些大型關(guān)鍵企業(yè)應(yīng)用系統(tǒng)中，設(shè)置適當(dāng)?shù)腤ORK_MEM的重要性比PGA手工管理時(shí)代更加重要。設(shè)置過(guò)大的WORK_MEM，有可能導(dǎo)致物理內(nèi)存不足，設(shè)置太小，會(huì)讓有些SQL跑不出來(lái)。對(duì)于特殊的SQL，設(shè)置會(huì)話級(jí)的WORK_MEM可能是更好的解決方案。

第二個(gè)容易讓學(xué)習(xí)PG的Oracle DBA困惑的是CURSOR SHARING機(jī)制。在Oracle數(shù)據(jù)庫(kù)中，CURSOR SHARING的性能十分關(guān)鍵，對(duì)于高并發(fā)的應(yīng)用來(lái)說(shuō)，這一點(diǎn)尤為重要。如果硬解析過(guò)多，會(huì)消耗不必要的CPU資源，嚴(yán)重時(shí)會(huì)引發(fā)性能危機(jī)。與Oracle不同的是，PG雖然學(xué)習(xí)了Oracle的CURSOR共享機(jī)制，采用了一種類似的方法來(lái)解決共享CURSOR和避免多種最優(yōu)執(zhí)行計(jì)劃導(dǎo)致的SQL性能問題。PG沒有類似Oracle的共享池機(jī)制，因此不可能有全局CURSOR的概念。PG的CURSOR共享是會(huì)話級(jí)的，不是實(shí)例級(jí)的。在PG的一個(gè)會(huì)話中，一條SQL的前五次執(zhí)行，每次都會(huì)重新生成執(zhí)行計(jì)劃，如果前五次編譯發(fā)現(xiàn)存在通用執(zhí)行計(jì)劃，那么這個(gè)通用執(zhí)行計(jì)劃就會(huì)被共享。

與Oracle的CURSOR SHARING相比，這種機(jī)制要難管理多了，對(duì)于類似的SQL,很可能因?yàn)榻壎ㄗ兞康牟煌?，?dǎo)致不同的會(huì)話中某條SQL 的執(zhí)行計(jì)劃是不同的，執(zhí)行效率存在很大的差異。在Oracle數(shù)據(jù)庫(kù)中如果我們發(fā)現(xiàn)某個(gè)SQL的執(zhí)行計(jì)劃因?yàn)锽IND PEEKING 等方面的原因發(fā)生了錯(cuò)誤，那么我們?cè)诠蚕沓刂袑⑦@個(gè)CURSOR PURGE掉，下一次SQL被執(zhí)行時(shí)就會(huì)重新生成執(zhí)行計(jì)劃，大概率會(huì)糾正以前的錯(cuò)誤了。不過(guò)在PG里，因?yàn)闆]有全局共享CURSOR而變得十分困難了。當(dāng)然通過(guò)對(duì)相關(guān)表做DDL會(huì)讓所有會(huì)話的執(zhí)行計(jì)劃失效，或者殺掉某個(gè)存在問題的會(huì)話可以解決這個(gè)問題。

實(shí)際上在一個(gè)并發(fā)相當(dāng)高的PG數(shù)據(jù)庫(kù)中要對(duì)執(zhí)行頻繁的表做DDL，其副作用也遠(yuǎn)遠(yuǎn)大于Oracle數(shù)據(jù)庫(kù)，突如其來(lái)的SQL解析風(fēng)暴很可能打爆服務(wù)器的CPU，從而引發(fā)性能故障。

基于上面的一些問題，作為DBA，應(yīng)該盡可能為自己的PG數(shù)據(jù)庫(kù)申請(qǐng)更多的CPU和物理內(nèi)存資源。在服務(wù)器資源相對(duì)充足的系統(tǒng)中，上述兩個(gè)問題帶來(lái)的影響都可以得到一定程度的控制。

今天的時(shí)間關(guān)系，我們先討論這兩個(gè)問題，如果PG數(shù)據(jù)庫(kù)承擔(dān)了高負(fù)載的關(guān)鍵業(yè)務(wù)系統(tǒng)，那么DBA也許真的會(huì)在生產(chǎn)環(huán)境中遇到這些問題，希望今天的文章對(duì)于正在學(xué)習(xí)或者轉(zhuǎn)型到PG數(shù)據(jù)庫(kù)的Oracle DBA有所幫助。也給這些DBA提個(gè)醒，有些表面上的概念，實(shí)際上PG和Oracle是有本質(zhì)差異的。比如流復(fù)制VS DATAGUARD ，WAL VS REDO，分區(qū)表，CHECKPOINT，等等等等。