PostgreSQL數(shù)據(jù)庫(kù)的日常維護(hù)工作

PostgreSQL數(shù)據(jù)庫(kù)的日常維護(hù)工作日常數(shù)據(jù)庫(kù)維護(hù)工作作者：小p來(lái)自：LinuxSir.Org摘要：為了保持所安裝的PostgreSQL服務(wù)器平穩(wěn)運(yùn)行,我們必須做一些日常性的維護(hù)工作。我們?cè)谶@里討論的這些工作都是經(jīng)常重復(fù)的事情，可以很容易地使用標(biāo)準(zhǔn)的Unix工具，比如cron腳本來(lái)實(shí)現(xiàn)；目錄綜述；日常清理；2.1VACUUM;2.1.1語(yǔ)法結(jié)構(gòu)；2.1.2描述；2.1.3參數(shù)；2.1.4為什么要用VACUUM；2.2恢復(fù)磁盤(pán)空間；2.2.1概述；2.2.2VACUUMFULL;2.3更新規(guī)劃器統(tǒng)計(jì)；2.4避免事務(wù)ID重疊造成的問(wèn)題；2.5auto-vacuum守護(hù)進(jìn)程；經(jīng)常重建索引；日志文件維護(hù)；關(guān)于本文；更新日志；參考文檔；&相關(guān)文檔；+++++++++++++++++++++++++++++++++++++++++++正文+++++++++++++++++++++++++++++++++++++++++++1.綜述；為了保持所安裝的PostgreSQL服務(wù)器平穩(wěn)運(yùn)行,我們必須做一些日常性的維護(hù)工作。我們?cè)谶@里討論的這些工作都是經(jīng)常重復(fù)的事情，可以很容易地使用標(biāo)準(zhǔn)的Unix工具，比如cron腳本來(lái)實(shí)現(xiàn)。不過(guò)，設(shè)置合適的腳本以及檢查它們是否成功執(zhí)行則是數(shù)據(jù)庫(kù)管理員的責(zé)任，一件很明顯的維護(hù)工作就是經(jīng)常性地創(chuàng)建數(shù)據(jù)的備份拷貝。如果沒(méi)有最近的備份，那么您就沒(méi)有從災(zāi)難中恢復(fù)的機(jī)會(huì)（比如磁盤(pán)壞了，失火，誤刪了表等等）。其它主要的維護(hù)范疇的工作包括周期性的"vacuuming"（清理）數(shù)據(jù)庫(kù)。其它需要周期性注意的東西是日志文件的管理。PostgreSQL和其它數(shù)據(jù)庫(kù)產(chǎn)品比較起來(lái)是低維護(hù)量的。但是，適當(dāng)在這些任務(wù)上放一些注意將更加能夠確保我們的愉快工作和獲取對(duì)這個(gè)系統(tǒng)富有成效的經(jīng)驗(yàn)。操作環(huán)境：PostgreSQL8.2+Ubuntu7.042.日常清理；VACUUM;語(yǔ)法結(jié)構(gòu)；VACUUM[FULL|FREEZE][VERBOSE][table]VACUUM[FULL|FREEZE][VERBOSE]ANALYZE[table[（column[,...]）]]2.1.2描述；VACUUM回收已刪除元組占據(jù)的存儲(chǔ)空間。在一般的PostgreSQL操作里，那些已經(jīng)DELETE的元組或者被UPDATE過(guò)后過(guò)時(shí)的元組是沒(méi)有從它們所屬的表中物理刪除的；在完成VACUUM之前它們?nèi)匀淮嬖?。因此我們有必須周期地運(yùn)行VACUUM,特別是在常更新的表上，如果沒(méi)有參數(shù)，VACUUM處理當(dāng)前數(shù)據(jù)庫(kù)里每個(gè)表，如果有參數(shù)，VACUUM只處理那個(gè)表，簡(jiǎn)單的VACUUM（沒(méi)有FULL）只是簡(jiǎn)單地回收空間并且令其可以再次使用；參數(shù)；FULL 選擇"完全"清理，這樣可以恢復(fù)更多的空間，但是花的時(shí)間更多并且在表上施加了排它鎖。FREEZE 選擇激進(jìn)的元組"凍結(jié)"。VERBOSE 為每個(gè)表打印一份詳細(xì)的清理工作報(bào)告。ANALYZE 更新用于優(yōu)化器的統(tǒng)計(jì)信息，以決定執(zhí)行查詢(xún)的最有效方法。table 要清理的表的名稱(chēng)（可以有模式修飾）。缺省時(shí)是當(dāng)前數(shù)據(jù)庫(kù)中的所有表。column 要分析的具體的列/字段名稱(chēng)。缺省是所有列/字段。為什么要用VACUUM；VACUUM命令的含義為：垃圾收集以及可選地分析一個(gè)數(shù)據(jù)庫(kù)。VACUUM回收已刪除元組占據(jù)的存儲(chǔ)空間。在一般的PostgreSQL操作里，那些已經(jīng)DELETE的元組或者被UPDATE過(guò)后過(guò)時(shí)的元組是沒(méi)有從它們所屬的表中物理刪除的；在完成VACUUM之前它們?nèi)匀淮嬖?。由于以下幾個(gè)原因，我們必須周期性運(yùn)行PostgreSQL的VACUUM命令：1?恢復(fù)那些由已更新的或已刪除的行占據(jù)的磁盤(pán)空間。更新PostgreSQL查詢(xún)規(guī)劃器使用的數(shù)據(jù)統(tǒng)計(jì)信息。避免因?yàn)槭聞?wù)ID重疊造成的老舊數(shù)據(jù)的丟失。對(duì)上面每個(gè)條件進(jìn)行VACUUM操作的頻率和范圍因不同的節(jié)點(diǎn)而不同。因此，數(shù)據(jù)庫(kù)管理員必須理解這些問(wèn)題并且開(kāi)發(fā)出合適的維護(hù)策略。建議在經(jīng)常VACUUM（清理）（至少每晚一次）生產(chǎn)數(shù)據(jù)庫(kù)，以保證不斷地刪除失效的行。尤其是在增刪了大量記錄之后，對(duì)受影響的表執(zhí)行VACUUMANALYZE命令是一個(gè)很好的習(xí)慣。例如：sir=#VACUUMVERBOSEANALYZEaccess;信息：正在清理(vacuum)""public.access""信息：index""access_pkey"nowcontains0rowversionsin1pagesDETAIL:0indexrowversionswereremoved?0indexpageshavebeendeleted,0arecurrentlyreusable?CPU0?00s/0?00usecelapsed0?00sec.信息：""access":found0removable,0nonremovablerowversionsin0pagesDETAIL:0deadrowversionscannotberemovedyet?Therewere0unuseditempointers?0pagescontainusefulfreespace?0pagesareentirelyempty.CPU0?00s/0?00usecelapsed0?00sec.信息：正在清理(vacuum)""pg_toast?pg_toast_16464""信息：index""pg_toast_16464_index"nowcontains0rowversionsin1pagesDETAIL:0indexrowversionswereremoved?0indexpageshavebeendeleted,0arecurrentlyreusable?CPU0?00s/0?00usecelapsed0?00sec.信息： ""pg_toast_16464"":found0removable,0nonremovablerowversionsin0pagesDETAIL:0deadrowversionscannotberemovedyet?Therewere0unuseditempointers?0pagescontainusefulfreespace?0pagesareentirelyempty.CPU0?00s/0?00usecelapsed0?00sec.信息：正在分析""public.access""信息：""access":scanned0of0pages,containing0liverowsand0deadrows;0rowsinsample,0estimatedtotalrowsVACUUM這樣做將更新系統(tǒng)目錄為最近的更改，并且允許PostgreSQL查詢(xún)優(yōu)化器在規(guī)劃用戶(hù)查詢(xún)時(shí)有更好的選擇。不建議日常使用FULL選項(xiàng)，但是可以在特殊情況下使用。一個(gè)例子就是在您刪除了一個(gè)表的大部分行之后，希望從物理上縮小該表以減少磁盤(pán)空間占用。VACUUMFULL通常要比單純的VACUUM收縮更多表的尺寸;2.2恢復(fù)磁盤(pán)空間;概述;在正常的PostgreSQL操作里，對(duì)一行的UPDATE或DELETE并未立即刪除舊版本的數(shù)據(jù)行。這個(gè)方法對(duì)于獲取多版本并行控制的好處是必要的：如果一個(gè)行的版本仍有可能被其它事務(wù)看到，那么您就不能刪除它。但到了最后，不會(huì)有任何事務(wù)對(duì)過(guò)期的或者已經(jīng)刪除的元組感興趣。而它占據(jù)的空間必須為那些新的元組使用而回收，以避免對(duì)磁盤(pán)空間增長(zhǎng)的無(wú)休止的需求。這件事是通過(guò)運(yùn)行VACUUM實(shí)現(xiàn)的。很明顯，那些經(jīng)常更新或者刪除元組的表需要比那些較少更新的表清理的更頻繁一些。所以，設(shè)置一個(gè)周期性的cron任務(wù)VACUUM那些選定的表，而忽略那些已經(jīng)知道變化比較少的表．這個(gè)方法只是在您擁有大量更新頻繁的表和大量很少更新的表的時(shí)候有意義—清理一個(gè)小表的額外開(kāi)銷(xiāo)根本不值得擔(dān)心；VACUUM命令有兩個(gè)變種:第一種形式，叫做"懶漢vacuum"或者只是VACUUM,在表和索引中標(biāo)記過(guò)期的數(shù)據(jù)為將來(lái)使用；它并不試圖立即恢復(fù)這些過(guò)期數(shù)據(jù)使用的空間。因此，表文件不會(huì)縮小，并且任何文件中沒(méi)有使用的空間都不會(huì)返回給操作系統(tǒng)。這個(gè)變種的VACUUM可以和通常的數(shù)據(jù)庫(kù)操作并發(fā)執(zhí)行;第二種形式是VACUUMFULL命令。這個(gè)形式使用一種更加激進(jìn)的算法來(lái)恢復(fù)過(guò)期的的行版本占據(jù)的空間。任何VACUUMFULL釋放的空間都立即返回給操作系統(tǒng)。但是，這個(gè)形式的VACUUM命令在進(jìn)行VACUUMFULL;VACUUMFULL一個(gè)表的時(shí)候在其上要求一個(gè)排他鎖。因此，經(jīng)常使用VACUUMFULL會(huì)對(duì)并發(fā)數(shù)據(jù)庫(kù)查詢(xún)有著非常糟糕的影響;標(biāo)準(zhǔn)形式的VACUUM最適合用于維護(hù)相當(dāng)程度的磁盤(pán)用量的穩(wěn)定狀態(tài)。如果您需要把磁盤(pán)空間歸還給操作系統(tǒng)，那么您可以使用VACUUMFULL—不過(guò)如果釋放的磁盤(pán)空間又會(huì)很快再次被分配又怎樣？如果維護(hù)更新頻繁的表，那么中等頻率的多次標(biāo)準(zhǔn)VACUUM運(yùn)行方法比很低頻率的VACUUMFULL更好;對(duì)于大多數(shù)節(jié)點(diǎn)而言，我們推薦的習(xí)慣是在一天中的低使用的時(shí)段安排一次整個(gè)數(shù)據(jù)庫(kù)的VACUUM，必要時(shí)外加對(duì)更新頻繁的表的更經(jīng)常的清理。（有些環(huán)境下，對(duì)那些更新非常頻繁的表可能會(huì)每幾分鐘就VACUUM一次。）如果您的集群中有多個(gè)數(shù)據(jù)庫(kù)，別忘記對(duì)每個(gè)庫(kù)進(jìn)行清理；vacuumdb腳本可能會(huì)幫您的忙;如果您知道自己剛刪除掉一個(gè)表中大部分的行，那么我們建議使用VACUUMFULL，這樣該表的穩(wěn)定態(tài)尺寸可以因?yàn)閂ACUUMFULL更富侵略性的方法而顯著減小。日常的磁盤(pán)空間清理，請(qǐng)使用VACUUM，而不是VACUUMFULL;如果您有一個(gè)表，它的內(nèi)容經(jīng)常被完全刪除，那么可以考慮用TRUNCATE，而不是后面跟著VACUUM的DELETE。TRUNCATE立即冊(cè)U除整個(gè)表的內(nèi)容，而不要求隨后的VACUUM或者VACUUMFULL來(lái)恢復(fù)現(xiàn)在沒(méi)有用的磁盤(pán)空間;更新規(guī)劃器統(tǒng)計(jì);PostgreSQL的查詢(xún)規(guī)劃器依賴(lài)一些有關(guān)表內(nèi)容的統(tǒng)計(jì)信息用以為查詢(xún)生成好的規(guī)劃。這些統(tǒng)計(jì)是通過(guò)ANALYZE命令獲得的，您可以直接調(diào)用這條命令，也可以把它當(dāng)做VACUUM里的一個(gè)可選步驟來(lái)調(diào)用。擁有合理準(zhǔn)確的統(tǒng)計(jì)是非常重要的，否則，選擇了惡劣的規(guī)劃很可能會(huì)降低數(shù)據(jù)庫(kù)的性能；和為了回收空間做清理一樣，經(jīng)常更新統(tǒng)計(jì)信息也是對(duì)更新頻繁的表更有用。不過(guò)，即使是更新非常頻繁的表，如果它的數(shù)據(jù)的統(tǒng)計(jì)分布并不經(jīng)常改變，那么也不需要更新統(tǒng)計(jì)信息。一條簡(jiǎn)單的拇指定律就是想想表中字段的最大很最小值改變的幅度。比如，一個(gè)包含行更新時(shí)間的timestamp字段將是隨著行的追加和更新穩(wěn)定增長(zhǎng)最大值的；這樣的字段可能需要比那些包含訪問(wèn)網(wǎng)站的URL的字段更頻繁一些更新統(tǒng)計(jì)信息。那些URL字段可能改變得一樣頻繁，但是其數(shù)值的統(tǒng)計(jì)分布的改變相對(duì)要緩慢得多；我們可以在特定的表，甚至是表中特定的字段上運(yùn)行ANALYZE，所以如果您的應(yīng)用有需求的話，我們是可以對(duì)某些信息更新得比其它信息更頻繁的。不過(guò)，在實(shí)際中，這種做法的實(shí)用性是值得懷疑的。ANALYZE是一項(xiàng)相當(dāng)快的操作，即時(shí)在大表上也很快，因?yàn)樗褂昧私y(tǒng)計(jì)學(xué)上的隨機(jī)采樣的方法進(jìn)行行采樣，而不是把每一行都讀取進(jìn)來(lái)。因此，每隔一段時(shí)間對(duì)整個(gè)數(shù)據(jù)庫(kù)運(yùn)行一便這條命令可能更簡(jiǎn)單；注：盡管用ANALYZE按字段進(jìn)行挖掘的方式可能不是很實(shí)用，但您可能還是會(huì)發(fā)現(xiàn)值得按字段對(duì)ANALYZE收集的統(tǒng)計(jì)信息的詳細(xì)級(jí)別進(jìn)行調(diào)整。那些經(jīng)常在WHERE子句里使用的字段如果有非常不規(guī)則的數(shù)據(jù)分布，那么就可能需要比其它字段更細(xì)致的數(shù)據(jù)圖表．參閱ALTERTABLESETSTATISTICS．我們對(duì)大多數(shù)節(jié)點(diǎn)都建議在每天的低使用時(shí)段安排一次數(shù)據(jù)庫(kù)范圍的ANALYZE：這個(gè)任務(wù)可以有效地和每天的VACUUM組合在一起。不過(guò)，這對(duì)那些表統(tǒng)計(jì)信息改變相對(duì)緩慢的節(jié)點(diǎn)可能會(huì)過(guò)于夸張，而且少一些的ANALYZE也足夠了；避免事務(wù)ID重疊造成的問(wèn)題;PostgreSQL的MVCC事務(wù)語(yǔ)意依賴(lài)于比較事務(wù)ID（XID）的數(shù)值：一條帶有大于當(dāng)前事務(wù)的XID的插入XID的行版本是"屬于未來(lái)的"，并且不應(yīng)為當(dāng)前事務(wù)可見(jiàn)。但是因?yàn)槭聞?wù)ID的大小有限（在我們寫(xiě)這些的時(shí)候是32位），如果一次集群如果運(yùn)行的時(shí)間很長(zhǎng)（大于4十億次事務(wù)），那么它就要受到事務(wù)ID重疊的折磨：XID計(jì)數(shù)器回到零位，然后突然間所有以前的事務(wù)就變成看上去是在將來(lái)的—這意味著它們的輸出將變得可見(jiàn)。簡(jiǎn)而言之，可怕的數(shù)據(jù)丟失，（實(shí)際上數(shù)據(jù)仍然在那里，但是如果您無(wú)法獲取數(shù)據(jù)，這么說(shuō)也只是幸災(zāi)樂(lè)禍。）在PostgreSQL7.2之前，防御XID重疊的唯一辦法就是至少每40億事務(wù)就重新做一次initdb。這種做法對(duì)高流量的節(jié)點(diǎn)而言當(dāng)然不是令人滿(mǎn)意的做法，所以我們?cè)O(shè)計(jì)了更好的方法。新的方法允許某個(gè)服務(wù)器仍然保持運(yùn)行狀態(tài)，不需要initdb或者任何類(lèi)型的重啟。代價(jià)就是下面這樣的維護(hù)要求：數(shù)據(jù)庫(kù)中的每個(gè)表都必須在每十億次事務(wù)中至少清理一次．從實(shí)際角度出發(fā)，這個(gè)要求不算一個(gè)很繁重的要求，但是因?yàn)槿绻覀儧](méi)能滿(mǎn)足這個(gè)要求的后果是全部數(shù)據(jù)的丟失（而不僅僅是磁盤(pán)空間的浪費(fèi)或者性能的下降），我們制作了一些特殊的東西來(lái)幫助數(shù)據(jù)庫(kù)管理員避免災(zāi)難的發(fā)生。對(duì)于集群中的每個(gè)數(shù)據(jù)庫(kù)，PostgreSQL都跟蹤自上次全數(shù)據(jù)庫(kù)范圍VACUUM以來(lái)的時(shí)間。如果任何數(shù)據(jù)庫(kù)接近了十億次事務(wù)的危險(xiǎn)級(jí)別，系統(tǒng)就開(kāi)始發(fā)出警告信息。如果什么都不干，那么系統(tǒng)最終會(huì)停止正常的操作，直到進(jìn)行了合適的手工操作。本節(jié)剩下的部分給出這方面的細(xì)節(jié)。XID比較的新方法剝離出兩個(gè)特殊的XID，數(shù)字1和2（BootstrapXID和FrozenXID）。這兩個(gè)XID總是被認(rèn)為表任何普通的XID舊。普通的XID（那些大于2的）使用模-231運(yùn)算進(jìn)行比較。這就意味著對(duì)于每個(gè)普通的XID，總是有二十億個(gè)XID是"更舊"以及二十億個(gè)XID"更新"；表達(dá)這個(gè)意思的另外一個(gè)方法是普通的XID空間是沒(méi)有終點(diǎn)的環(huán)。因此，一旦一條元組帶著特定的普通XID創(chuàng)建出來(lái)，那么該元組將在以后的二十億次事務(wù)中表現(xiàn)得是"在過(guò)去"，而不管我們說(shuō)的是哪個(gè)普通XID。如果該元組在超過(guò)二十億次事務(wù)之后仍然存在，那么它就會(huì)突然變成在將來(lái)的元組。為了避免數(shù)據(jù)丟失，老的元組必須在到達(dá)二十億次事務(wù)的年齡之前的某個(gè)時(shí)候賦予XIDFrozenXID。一旦它被賦予了這個(gè)特殊的XID，那么它們?cè)谒衅胀ㄊ聞?wù)面前表現(xiàn)為"在過(guò)去"，而不管事務(wù)ID是否重疊，因此這樣的元組直到刪除之前都會(huì)完好，不管要保存多長(zhǎng)時(shí)間?這個(gè)XID的重新賦值是VACUUM控制的.VACUUM的正常策略是給任何其普通XID有超過(guò)十億次已過(guò)去事務(wù)行版本重新賦值為FrozenXID。這個(gè)策略保留了原來(lái)的插入XID直到該數(shù)值不再令人感興趣為止。（實(shí)際上，大多數(shù)行版本將可能在還沒(méi)有"凍結(jié)"之前就完成生存和消亡了）。在這個(gè)策略下，任何表在兩次VACUUM運(yùn)行之間的最大的安全間隔是十億次事務(wù)：如果您等的時(shí)間更長(zhǎng)，那么最后就可能就會(huì)有一條不夠老的行版本在重新賦值時(shí)變成比二十億次事務(wù)更老，并因此重疊到了未來(lái)—也就是說(shuō)，您失去它了。（當(dāng)然，它在另外二十億次事務(wù)之后會(huì)重新出現(xiàn)，不過(guò)那樣也無(wú)濟(jì)于事。）因?yàn)樯厦娴脑?，我們需要周期性地運(yùn)行VACUUM，所以很難有哪個(gè)表會(huì)到十億次事務(wù)還沒(méi)有清理過(guò)。但是，為了幫助管理員確保滿(mǎn)足了這個(gè)要求，VACUUM在系統(tǒng)表pg_database里存儲(chǔ)了事務(wù)ID統(tǒng)計(jì)。尤其是一個(gè)數(shù)據(jù)庫(kù)的pg_database行中的datfrozenxid字段在任何數(shù)據(jù)庫(kù)范圍的VACUUM操作（也就是沒(méi)有聲明任何表的VACUUM）之后將會(huì)被更新。這個(gè)字段里存儲(chǔ)的數(shù)值是該VACUUM命令使用的凍結(jié)終止的XID。系統(tǒng)保證在該數(shù)據(jù)庫(kù)中所有比這個(gè)終止XID老的普通XID都被FrozenXID代替。檢查這個(gè)信息的一個(gè)便利的方法是執(zhí)行下面的查詢(xún)SELECTdatname,age（datfrozenxid）FROMpg_database;age字段用于測(cè)量從中止XID到當(dāng)前事務(wù)的XID的數(shù)目。使用了這種標(biāo)準(zhǔn)的凍結(jié)策略，對(duì)一個(gè)剛清理過(guò)的數(shù)據(jù)庫(kù)而言，age字段將從十億處開(kāi)始。當(dāng)age到達(dá)二十億次的時(shí)候，數(shù)據(jù)庫(kù)必須再次清理以避免事務(wù)標(biāo)識(shí)重疊造成的問(wèn)題。我們建議的策略是至少每半個(gè)十億次（5億次）事務(wù)VACUUM一次數(shù)據(jù)庫(kù)，這樣就可以保證足夠的安全邊界范圍.為了幫助滿(mǎn)足這條規(guī)則，如果有任何pg_database記錄顯示出超過(guò)15億次事務(wù)的age，那么每次數(shù)據(jù)庫(kù)范圍的VACUUM都會(huì)自動(dòng)發(fā)出一條警告，比如：play=#VACUUM;WARNING:database"mydb"mustbevacuumedwithin177009986transactionsHINT:Toavoidadatabaseshutdown,executeafull-databaseVACUUMin"mydb".VACUUM如果忽略了上面這樣的VACUUM信息，如果距離事務(wù)ID重疊小于1千萬(wàn)次，那么PostgreSQL就會(huì)在每次事務(wù)開(kāi)始前發(fā)出類(lèi)似上面的警告。如果這些警告還是被忽略了，那么系統(tǒng)將在距離重疊小于1百萬(wàn)次的時(shí)候關(guān)閉，并且拒絕執(zhí)行任何新的事務(wù)：play=#select2+2;ERROR:databaseisshutdowntoavoidwraparounddatalossindatabase"mydb"HINT:StopthepostmasteranduseastandalonebackendtoVACUUMin"mydb".這個(gè)1百萬(wàn)的事務(wù)安全邊界留下來(lái)用于讓管理員在不丟失數(shù)據(jù)的情況下進(jìn)行恢復(fù)，方法是手工執(zhí)行所需要的VACUUM命令。不過(guò)，因?yàn)橐坏┻M(jìn)入了安全關(guān)閉模式，系統(tǒng)就不能再執(zhí)行命令，做這件事情的唯一的方法是停止postmaster，使用一個(gè)單獨(dú)運(yùn)行的后端來(lái)執(zhí)行VACUUM。關(guān)閉模式不會(huì)強(qiáng)制于獨(dú)立運(yùn)行的后端。帶著FREEZE選項(xiàng)的VACUUM使用了更大膽的凍結(jié)策略：如果行版本已經(jīng)老得被所有打開(kāi)的事務(wù)看做是良好的，那么就都凍結(jié).特別是如果在一個(gè)空閑的數(shù)據(jù)庫(kù)上運(yùn)行VACUUMFREEZE，那么就保證該數(shù)據(jù)庫(kù)中所有的行版本都被凍結(jié)。因此，只要該數(shù)據(jù)庫(kù)沒(méi)有其它的變化，那么它就不需要后續(xù)的清理以避免事務(wù)ID重疊問(wèn)題。這個(gè)技巧被initdb用于準(zhǔn)備template0數(shù)據(jù)庫(kù)。我們也應(yīng)該用這個(gè)方法對(duì)所有在pg_database表里標(biāo)記著datallowconn=false的數(shù)據(jù)庫(kù)進(jìn)行初始化，因?yàn)槲覀冞€沒(méi)有任何便利的方法VACUUM一個(gè)您無(wú)法聯(lián)接的數(shù)據(jù)庫(kù)。2.5auto-vacuum守護(hù)進(jìn)程;從PostgreSQL8.1開(kāi)始，系統(tǒng)帶有一個(gè)額外的可選服務(wù)進(jìn)程，叫做autovacuum守護(hù)進(jìn)程，它的目的是自動(dòng)執(zhí)行VACUUM和ANALYZE命令。在打開(kāi)這個(gè)選項(xiàng)之后，autovacuum守護(hù)進(jìn)程將周期性運(yùn)行并且檢查那些有大量插入，更新或者刪除元組操作的表。這些檢查使用行級(jí)別的統(tǒng)計(jì)收集設(shè)施；因此，除非把statsrowlevel和statsrowlevel設(shè)置為true，否則無(wú)法使用autovacuum守護(hù)。還有，在為superuserreservedconnections選擇數(shù)值的時(shí)候，不要忘記給autovacuum進(jìn)程保留一個(gè)槽位。如果打開(kāi)了autovacuum守護(hù)，那么它會(huì)每隔autovacummnatime秒鐘運(yùn)行一次，并且檢查應(yīng)該處理哪個(gè)數(shù)據(jù)庫(kù)。任何臨近事務(wù)ID重疊的數(shù)據(jù)庫(kù)都會(huì)被立即處理。這個(gè)時(shí)候，autovacuum發(fā)出一個(gè)數(shù)據(jù)庫(kù)范圍的VACUUM調(diào)用，如果是模板數(shù)據(jù)庫(kù)，則發(fā)出VACUUMFREEZE，然后終止。如果沒(méi)有數(shù)據(jù)庫(kù)復(fù)合這個(gè)標(biāo)準(zhǔn)，則選擇被上次autovacuum處理時(shí)間最遠(yuǎn)的那個(gè)數(shù)據(jù)庫(kù)。這種情況下，該數(shù)據(jù)庫(kù)里的表被檢查，然后根據(jù)需要發(fā)出獨(dú)立的VACUUM或者ANALYZE命令。對(duì)于每個(gè)表，用兩個(gè)條件來(lái)判斷應(yīng)該使用哪個(gè)操作。如果上次VACUUM之后的過(guò)期元組的數(shù)量超過(guò)了"清理閾值(vacuumthreshold)"，那么就清理改表。清理閾值是定義為：清理閾值=清理基本閾值+清理縮放系數(shù)*元組數(shù)(vacuumthreshold=vacuumbasethreshold+vacuumscalefactor*numberoftuples)這里的清理基本閾值是autovacuum_vacuum_threshold，清理的縮放系數(shù)是autovacuum_vacuum_scale_factor，元組的數(shù)目是失效的元組數(shù)目是從統(tǒng)計(jì)收集器里面獲取的；這事一個(gè)半精確的計(jì)數(shù)，由每次UPDATE和DELETE操作更新。(它只是半精確的是因?yàn)樵谥剌d下，有些信息可能會(huì)丟失。)為了分析，使用了一個(gè)類(lèi)似的條件：分析閾值，定義為分析閾值=分析基本閾值+分析縮放系數(shù)*元組數(shù)目(analyzethreshold=analyzebasethreshold+analyzescalefactor*numberoftuples)它會(huì)和上次ANALYZE插入，更新，或者刪除的元組總數(shù)進(jìn)行比較。缺省的閾值和伸縮系數(shù)是從postgresql.conf里面取得的，不過(guò)，我們可以以每個(gè)表獨(dú)立設(shè)置的方式覆蓋它，方法就是在系統(tǒng)表pg_autovacuum里輸入記錄。如果pg_autovacuum里面存在對(duì)某個(gè)特定表的行，那么就使用它聲明的設(shè)置；否則使用全局設(shè)置。除了基本閾值和縮放系數(shù)之外，在pg_autovacuum里還有三個(gè)參數(shù)可以為每個(gè)表進(jìn)行設(shè)置。首先，pg_autovacuum.enabled可以設(shè)置為false,讓autovacuum守護(hù)進(jìn)程完全忽略某個(gè)表。這種情況下，autovacuum只有在為了避免事務(wù)ID重疊清理整個(gè)數(shù)據(jù)庫(kù)的時(shí)候才會(huì)動(dòng)那個(gè)表。另外兩個(gè)參數(shù)，清理開(kāi)銷(xiāo)延遲（pg_autovacuum.vac_cost_delay）和清理開(kāi)銷(xiāo)限制（pg_autovacuum.vac_cost_limit），用于為基于開(kāi)銷(xiāo)的清理延遲特性設(shè)置表相關(guān)的數(shù)值。如果在pg_autovacuum里任何數(shù)值設(shè)置為負(fù)數(shù)，或者在pg_autovacuum里就根本沒(méi)有出現(xiàn)特定表的數(shù)據(jù)行，那么使用postgresql.conf里面對(duì)應(yīng)的數(shù)值。目前沒(méi)有任何制作pg_autovacuum記錄的支持，只能手工向該系統(tǒng)表中INSERT。這個(gè)特性將在以后的版本中改進(jìn)，并且這個(gè)系統(tǒng)表的定義也很有可能會(huì)改變。3.經(jīng)常重建索引;有時(shí)候我們值得用REINDEX命令周期的重建索引;在PostgreSQL版本7.4之前，我們經(jīng)常有必要避免"索引膨脹"，因?yàn)槿狈υ贐-tree索引內(nèi)部的空間恢復(fù)機(jī)制。一個(gè)情況是就是索引健字的范圍隨著時(shí)間而變化—比如，一個(gè)在某個(gè)表的時(shí)間戳上的索引，隨著時(shí)間的推移，舊的記錄會(huì)最終被刪除—就會(huì)導(dǎo)致膨脹，因?yàn)槟切┯糜诓辉偈褂玫逆I字范圍的索引頁(yè)面不回得到重復(fù)使用。隨著時(shí)間的推移，索引的尺寸可能會(huì)變得比里面的有用的數(shù)據(jù)大得多。從PostgreSQL7.4開(kāi)始，那些已經(jīng)完全清空的索引頁(yè)會(huì)得到重復(fù)使用。不過(guò)這樣仍然會(huì)有不充分使用空間的可能：如果一個(gè)頁(yè)面中大多數(shù)索引鍵字被刪除，只留下很少的部分呢，那么該頁(yè)仍然將被分配。所以，如果使用模式是這樣的：每個(gè)范圍里除了少數(shù)鍵字之外，其他大部分鍵字最終都被刪除；那么這樣也會(huì)導(dǎo)致空間的低效使用。膨脹的可能性不是無(wú)窮的—最差的情況是每個(gè)頁(yè)面至少還有一個(gè)鍵字—但是對(duì)這樣的使用模式，我們可能仍然值得安排周期性的重新索引;對(duì)于非B-tree索引的膨脹可能還沒(méi)有很好地定量分析。在使用非B-tree索引的時(shí)候保持對(duì)索引的物理尺寸的監(jiān)控是個(gè)很好的主意;還有，對(duì)于B-tree索引，一個(gè)新建立的索引從某種意義上比更新了多次的訪問(wèn)起來(lái)要快，因?yàn)樵谛陆⒌乃饕希壿嬌线B接的頁(yè)面通常物理上也連接在一起。（這樣的考慮目前并不適用于非B-tree索引。）僅僅從提高訪問(wèn)速度角度出發(fā)，可能我們也值得周期性的重建索引。4.日志文件維護(hù);把數(shù)據(jù)庫(kù)服務(wù)器的日志輸出保存在一個(gè)地方是個(gè)好主意。在碰到危險(xiǎn)的問(wèn)題的時(shí)候，日志輸出是非常寶貴的。不過(guò)，日志輸出可能很龐大（特別是在比較高的調(diào)試級(jí)別上），而且您不會(huì)無(wú)休止地保存它們．您需要"旋轉(zhuǎn)"日志文件，這樣生成新的日志文件并且經(jīng)常拋棄老的；如果您簡(jiǎn)單地把postmaster的stderr定向到一個(gè)文件中，您會(huì)有日志輸出，但是截?cái)嗳罩疚募奈ㄒ坏姆椒ㄊ峭Ｖ共⒅仄餻ostmaster。這樣做對(duì)于開(kāi)發(fā)環(huán)境中使用PostgreSQL可能是可以的，但是您肯定不想在生產(chǎn)環(huán)境上這么干；一個(gè)更好的辦法是把postmaster的stderr（錯(cuò)誤流■s