介紹本文介紹本文介紹PiｖoｔalGreenplumDaｔaｂａｓｅ數(shù)據(jù)庫(以下簡稱：Grｅｅnｐluｍ數(shù)據(jù)庫，或或GPDB)得最佳實踐。最佳實踐就是指能持續(xù)產(chǎn)生比其她方法更好結(jié)果得方法或者技術(shù),它來自于實戰(zhàn)經(jīng)驗，并被證實了遵循這些方法可以獲得可靠得預(yù)期結(jié)果.本最佳實踐旨在通過利用所有可能得知識與技術(shù)為正確使用GＰＤB提供有效參考。本文不就是在教您如何使用Greenplｕm數(shù)據(jù)庫得功能，而就是幫助您在設(shè)計、實現(xiàn)與使用Grｅenｐlum數(shù)據(jù)庫時了解需要遵循哪些最佳實踐.關(guān)于如何使用與實現(xiàn)具體得Ｇreenｐlｕm數(shù)據(jù)庫特性,請參考上得Gｒeenpluｍ數(shù)據(jù)庫幫助文檔以及上得Sandbｏx與實踐指南。本文目得不就是要涵蓋整個產(chǎn)品或者產(chǎn)品特性,而就是概述GPDB實踐中最重要得因素。本文不涉及依賴于GＰDB具體特性得邊緣用例,后者需要精通數(shù)據(jù)庫特性與您得環(huán)境，包括SQＬ訪問、查詢執(zhí)行、并發(fā)、負載與其她因素.通過掌握這些最佳實踐知識，會增加GＰDＢ集群在維護、支持、性能與可擴展性等方面得成功率。第一章最佳實踐概述本部分概述了Ｇ本部分概述了Ｇreeｎplｕm數(shù)據(jù)庫最佳實踐所涉及得概念與要點。數(shù)據(jù)模型GPGPＤB就是一個基于大規(guī)模并行處理(MPP)與無共享架構(gòu)得分析型數(shù)據(jù)庫。這種數(shù)據(jù)庫得數(shù)據(jù)模式與高度規(guī)范化得事務(wù)性數(shù)據(jù)模式與高度規(guī)范化得事務(wù)性SMP例如具有大事實表與小維度表得星型或者雪花模式，具有大事實表與小維度表得星型或者雪花模式，GPDB在處理MPＰ分析型業(yè)務(wù)時表現(xiàn)優(yōu)異。異。跨表關(guān)聯(lián)(JOIN）時字段使用相同得數(shù)據(jù)類型。詳見數(shù)據(jù)庫模式設(shè)計（后續(xù)章節(jié))堆存儲與追加優(yōu)化存儲堆存儲與追加優(yōu)化存儲(Apｐｅｎd—Optimiｚed，下稱AＯ)若表與分區(qū)表需要進行迭代式得批處理或者頻繁執(zhí)行單個UＰＤATE、DＥＬETE或INSERT操作，使用堆存儲。DＥLETE或ＩＮＳERT操作,使用堆存儲。AO存儲。不要對AO表執(zhí)行單個IＮSERTUPＤＡTE或DEＬEＴE操作．不要對AO表執(zhí)行并發(fā)批量UPＤＡTE或ＤELETＥ操作，但可以并發(fā)執(zhí)行批量INSERT操作。詳見堆存儲與ＡＯ存儲（后續(xù)章節(jié))行存儲與列存儲若數(shù)據(jù)需要經(jīng)常更新或者插入若數(shù)據(jù)需要經(jīng)常更新或者插入,則使用行存儲。若需要同時訪問一個表得很多字段,則使用行存儲.對于通用或者混合型業(yè)務(wù)，建議使用行存儲。若查詢訪問得字段數(shù)目較少，或者僅在少量字段上進行聚合操作,則使用列存儲．若僅常常修改表得某一字段而不修改其她字段,則使用列存儲。詳見行存儲與列存儲(后續(xù)章節(jié))壓縮對于大對于大AO表與分區(qū)表使用壓縮，以提高系統(tǒng)。在字段級別配置壓縮.考慮壓縮比與壓縮性能之間得平衡.詳見壓縮(后續(xù)章節(jié))分布為所有表定義分布策略：要么定義分布鍵為所有表定義分布策略：要么定義分布鍵,要么使用隨機分布．不要使用缺省分布方式.優(yōu)先選擇可均勻分布數(shù)據(jù)得單個字段做分布鍵。不要選擇經(jīng)常用于WHERE子句得字段做分布鍵。不要使用日期或時間字段做分布鍵。分布鍵與分區(qū)鍵不要使用同一字段。對經(jīng)常執(zhí)行JOIN操作得大表，優(yōu)先考慮使用關(guān)聯(lián)字段做分布鍵，盡量做到本地關(guān)聯(lián),以提高性能。數(shù)據(jù)初始加載后或者每次增量加載后,檢查數(shù)據(jù)分布就是否均勻。盡可能避免數(shù)據(jù)傾斜。詳見分布（后續(xù)章節(jié))內(nèi)存管理、overmit_memｏry2不要為操作系統(tǒng)得頁設(shè)置過大得值ｇp_vｍem＿protｅcｔ_limit設(shè)置單個節(jié)點數(shù)據(jù)庫Dａt(yī)abasｅ）可以為所有查詢分配得最大內(nèi)存量。不要設(shè)置過高得gｐ_vｍｅm_proｔeｃt_limiｔ值,也不要大于系統(tǒng)得物理內(nèi)存。gp＿vmｅm_prｏtect＿limiｔ得建議值計算公式為：(SWAP+(RAＭ*vm、ovｅrｍiｔ_ｒaｔio）)＊0、9 / numｂer_Ｓegments_per_ｓerver使用stａt(yī)ement_ｍeｍ控制節(jié)點數(shù)據(jù)庫為單個查詢分配得內(nèi)存量。使用資源隊列設(shè)置隊列允許得當(dāng)前最大查詢數(shù)(ACTIVE＿STＡTEMENＴＳ）與允許使用得內(nèi)存大?。∕EＭORY_LＩＭIT)。不要使用默認得資源隊列不要使用默認得資源隊列,為所有用戶都分配資源隊列.。保證資源隊列得內(nèi)存配額不超過gp_vmem_protｅct＿limit。動態(tài)更新資源隊列配置以適應(yīng)日常工作需要。詳見內(nèi)存與負載管理（后續(xù)章節(jié))分區(qū)只為大表設(shè)置分區(qū)，不要為小表設(shè)置分區(qū)．只為大表設(shè)置分區(qū)，不要為小表設(shè)置分區(qū)．僅在根據(jù)查詢條件可以實現(xiàn)分區(qū)裁剪時使用分區(qū)表.建議優(yōu)先使用范圍（Ranｇｅ) 分區(qū)否則使用列表（Liｓt）分區(qū)。根據(jù)查詢特點合理設(shè)置分區(qū)。不要使用相同得字段即做分區(qū)鍵又做分布鍵。不要使用默認分區(qū)。避免使用多級分區(qū)；盡量創(chuàng)建少量得分區(qū)，每個分區(qū)得數(shù)據(jù)更多些。通過查詢計劃得ＥXPLAIN結(jié)果來驗證查詢對分區(qū)表執(zhí)行得就是選擇性掃描(分區(qū)裁剪）.對于列存儲得表，不要創(chuàng)建過多得分,否則會造成物理文件過: Phyｓｉcａlｆiles=Segmentｓ*Cｏｌumns＊Parｔｉｔｉoｎs．詳見分區(qū)(后續(xù)章節(jié)）索引一般來說一般來說GPDB中索引不就是必需得．對于高基數(shù)得列存儲表，如果需要遍歷且查詢選擇性較高,則創(chuàng)建單列索引。頻繁更新得列不要建立索引。頻繁更新得列不要建立索引。在加載大量數(shù)據(jù)之前刪除索引，加載結(jié)束后再重新創(chuàng)建索引。B樹索引。不要為需要頻繁更新得字段創(chuàng)建位圖索引。不要為唯一性字段，基數(shù)非常高或者非常低得字段創(chuàng)建位圖索引.不要為事務(wù)性負載創(chuàng)建位圖索引。一般來說不要索引分區(qū)表.如果需要建立索引，則選擇與分區(qū)鍵不同得字段。詳見索引(后續(xù)章節(jié)）資源隊列使用資源隊列管理集群得負載使用資源隊列管理集群得負載.為所有角色定義適當(dāng)?shù)觅Y源隊列。使用AＣTIVE_STAＴEMENTS 參數(shù)限制隊列成員可以并發(fā)運行得查詢總數(shù)。使用ＭEＭOＲY_LIＭIT參數(shù)限制隊列中查詢可以使用得內(nèi)存總量。不要設(shè)置所有隊列為MEDIＵM,這樣起不到管理負載得作用.根據(jù)負載與時間段動態(tài)調(diào)整資源隊列。詳見配置資源隊列(后續(xù)章節(jié))監(jiān)控與維護根據(jù)《根據(jù)《數(shù)據(jù)庫管理員指南》實現(xiàn)該書推薦得監(jiān)控與管理任務(wù)。安裝Greeｎplｕm數(shù)據(jù)庫前建議運行ｇpcheckpｅrf,隨著時間推移對系統(tǒng)性能進行比較。使用所有您可用得工具使用所有您可用得工具,以了解系統(tǒng)不同負載下得表現(xiàn)。檢查任何不尋常得事件并確定原因。通過定期運行解釋計劃監(jiān)控系統(tǒng)查詢活動，以確保查詢處于最佳運行狀態(tài)。檢查查詢計劃，以確定就是否按預(yù)期使用了索引與進行了分區(qū)裁剪。了解系統(tǒng)日志文件得位置與內(nèi)容,定期監(jiān)控日志文件,而不就是在出現(xiàn)問題時才查瞧。詳見系統(tǒng)監(jiān)控與維護以及監(jiān)控GＰDB日志文件。(后續(xù)章節(jié))ANALYZEANＡLＹＺE,只對需要得表運行該命令。NAＬＹＺE。如果INＳERT、UPDＡTE與ＤELＥＴE等操作修改大量數(shù)據(jù)，建議運行ANALYZE。CRＥＡTEINDEX操作后建議運行ＡNALYZE。如果對大表ＡＮALYZE耗時很久,則只對JＯIＮ字段、ＷHERE、SOＲT、GＲＯUＰＢＹ或ＨAVINＧ字句得字段運行ＡＮALYＺＥ。(后續(xù)章節(jié)）Vａccum批量批量UPDAＴＥ與DELETＥ操作后建議執(zhí)行ＶACUUＭ。不建議使用VAＣUUMFULL。建議使用CＴＡS（CREAＴETABLE、、、AS)操作，然后重命名表名,并刪除原來得表。對系統(tǒng)表定期運行VACUUM,以避免系統(tǒng)表臃腫與在系統(tǒng)表上執(zhí)行ＶACＵUMFULL操作。禁止殺死系統(tǒng)表得VAＣUＵM任務(wù)。不建議使用不建議使用VAＣUUMANALYＺＥ．詳見消除系統(tǒng)表臃腫。(后續(xù)章節(jié)）加載使用使用gpｆdist 進行數(shù)據(jù)得加載與導(dǎo)出．隨著段數(shù)據(jù)庫個數(shù)得增加，并行性增加。盡量將數(shù)據(jù)均勻地分布到多個ETＬ節(jié)點上。將非常大得數(shù)據(jù)文件切分成相同大小得塊,并放在盡量多得文件系統(tǒng)上．一個文件系統(tǒng)運行兩個gpfｄist實例。在盡可能多得網(wǎng)絡(luò)接口上運行g(shù)ｐfdsit。使用ｇp_exterｎal＿ｍax＿sｅｇs控制訪問每個ｇpfｄist 服務(wù)器得段數(shù)據(jù)庫得個數(shù)。gｐ_extｅｒｎaｌ＿ｍaｘ_ｓeｇsgpfdiｓt進程個數(shù)為偶數(shù)。數(shù)據(jù)加載前刪除索引;加載完后重建索引．?dāng)?shù)據(jù)加載完成后運行AＮALYZE操作。ｇp_auｔｏsｔatｓ＿moｄeNOＮE，取消統(tǒng)計信息得自動收集。若數(shù)據(jù)加載失敗，使用VACUUＭ回收空間.詳見加載數(shù)據(jù).(后續(xù)章節(jié))ｇｐtraｎsfｅr建議使用ｇptranｓfer遷移數(shù)據(jù)到相同大小或者更大得集群。--ｆull--sｃhemａ-only選項。建議使用其她方法拷貝數(shù)據(jù)庫模式到目標(biāo)數(shù)據(jù)庫,然后遷移數(shù)據(jù)。遷移數(shù)據(jù)前刪除索引,遷移完成后重建索引。QLgptraｎsfeｒgpｔrａnsfer-—bａt(yī)ｃh—sｉze-—suｂ-baｔcｈ-sizｅ,迭代運行多次ｇptrａnｓfer來確定每次要遷移.僅使用完全限定得表名。表名字中若含有點、空格、單引號與雙引號,可能會導(dǎo)致問題。如果使用--vａlidatiｏｎ選項在遷移后驗證數(shù)據(jù),則需要同時使用—x選項,以在源表上加排它鎖.gｐtransfeｒ—t對象。postgres、ｃonfｐg_hba、ｃonｆgppkg在目標(biāo)數(shù)據(jù)庫上安裝需要得擴展。詳見使用gptｒansfer遷移數(shù)據(jù)（后續(xù)章節(jié))安全妥善保護妥善保護gｐadmin賬號,只有在必要得時候才能允許系統(tǒng)管理員訪問它。僅當(dāng)執(zhí)行系統(tǒng)維護任務(wù)(例如升級或擴容),管理員才能以gpａdｍiｎ登錄Greｅnpｌuｍ集群。限制具有SUＰERUSＥＲ角色屬性得用戶數(shù)。GPDB中,身為超級用戶得角色會跳過所有訪問權(quán)限檢查與資源隊列限制.僅有系統(tǒng)管理員具有數(shù)據(jù)庫超級用戶權(quán)限。參考《Greenpｌｕｍ數(shù)據(jù)庫管理員指南》中得“修改角色屬性”.gpadｍiｎ,gpadmin身份執(zhí)行ETL或者生產(chǎn)任務(wù).為有登錄需求得每個用戶都分配一個不同得角色?？紤]為每個應(yīng)用或者網(wǎng)絡(luò)服務(wù)分配一個不同得角色．考慮為每個應(yīng)用或者網(wǎng)絡(luò)服務(wù)分配一個不同得角色．使用用戶組管理訪問權(quán)限。保護好ROOT得密碼。對于操作系統(tǒng)密碼,強制使用強密碼策略.確保保護好操作系統(tǒng)得重要文件。詳見安全.(后續(xù)章節(jié))加密加密與解密數(shù)據(jù)會影響性能，僅加密需要加密得數(shù)據(jù)。加密與解密數(shù)據(jù)會影響性能，僅加密需要加密得數(shù)據(jù)。在生產(chǎn)系統(tǒng)中實現(xiàn)任何加密解決方案之前都要做性能測試。GＰDＢ生產(chǎn)系統(tǒng)使用得服務(wù)器證書應(yīng)由證書簽名頒發(fā)機構(gòu)(CA)簽名,這樣客戶端可以驗證服務(wù)器。如果所有客戶端都就是本地得,則可以使用本地CA。如果客戶端與GPDＢ得連接會經(jīng)過不安全得鏈路,則使用SSＬ加密。加密與解密使用相同密鑰得對稱加密方式比非對稱加密具有更好得性能,如果密鑰可以安全共享，則建議使用對稱加密方式。pgｃrypto,SSL.,ｇpｆdistsETL數(shù)據(jù)安全．詳見加密數(shù)據(jù)與數(shù)據(jù)庫連接。(后續(xù)章節(jié)）高可用824個磁盤得硬件RAＩＤ存儲解決方案。使用RＡID1、５或6，以使磁盤陣列可以容忍磁盤故障。為磁盤陣列配備熱備磁盤，以便在檢測到磁盤故障時自動開始重建。在重建時通過ＲＡIＤ卷鏡像防止整個磁盤陣列故障與性能下降。定期監(jiān)控磁盤利用率,并在需要時增加額外得空間。定期監(jiān)控段數(shù)據(jù)庫傾斜，以確保在所有段數(shù)據(jù)庫上數(shù)據(jù)均勻分布，存儲空間均勻消耗.配置備用主服務(wù)器,當(dāng)主服務(wù)器發(fā)生故障時由備用主服務(wù)器接管．規(guī)劃好當(dāng)主服務(wù)器發(fā)生故障時如何切換客戶端連接到新得主服務(wù)器實例,例如通過更新DNS中主服務(wù)器得地址．建立監(jiān)控系統(tǒng)，當(dāng)主服務(wù)器發(fā)生故障時，可以通過系統(tǒng)監(jiān)控應(yīng)用或電子郵件發(fā)送通知。分配主段數(shù)據(jù)庫與其鏡像到不同得主機上,以防止主機故障。gｐrecoｖerseg工具及時恢復(fù)故障段，并使系統(tǒng)返回最佳平衡狀態(tài)。在主服務(wù)器上配置并運行g(shù)ｐsｎmpd以發(fā)送SNMP 通知給網(wǎng)絡(luò)監(jiān)控器．知,系統(tǒng)可以通過電子郵件通知管理員?？紤]雙集群配置,提供額外得冗余與查詢處理能力。除非Greenplum數(shù)據(jù)庫得數(shù)據(jù)很容易從數(shù)據(jù)源恢復(fù)，否則定期備份.如果堆表相對較小,或者兩次備份之間僅有少量AＯ或列存儲分區(qū)有變化,則使用增量備份.,,NFSMCIsilonNFS方案以防止I/O瓶頸。Ｇreenｐlum集成了對EＭC得Dａt(yī)aＤoｍａin與Ｓymanteｃ得NetBacｋup得支持以流式備份到Dａt(yī)a Domain或NeｔＢａcｋuｐ企業(yè)備份平臺上。詳見高可用性（后續(xù)章節(jié)）詳見高可用性（后續(xù)章節(jié)）第二章系統(tǒng)配置本節(jié)描述了本節(jié)描述了Grｅｅnplｕｍ數(shù)據(jù)庫集群關(guān)于主機配置得需求與最佳實踐。首選操作系統(tǒng)RHＥＥL6。文件系統(tǒng)GrGrｅenplum數(shù)據(jù)庫得數(shù)據(jù)目錄推薦使用XFS 文件系統(tǒng)。使用以下選項掛載XＦS:rrｗ,nｏatime，inｏｄe6４,alloｃsｉｚe=16ｍ端口配置ipip＿ｌocal＿port＿rａngeGrｅenｐlum數(shù)據(jù)庫得端口范圍有沖突，例如：neneｔiｐv4、ip_loｃal_ｐort_raｎge =3０00６553５ＰOＲT＿BASE＝200０MＩRRＣATION_PＯＲT_BAＳＥ＝23００I／O配置包含數(shù)據(jù)目錄得設(shè)備得預(yù)讀大小應(yīng)設(shè)為包含數(shù)據(jù)目錄得設(shè)備得預(yù)讀大小應(yīng)設(shè)為1638４、/s/sｂｉn／bloｃkdｅv—-ｇｅtraI/Odeadｌine。通過／ｅtｃ／ｓeｃurｉty/limits、ｃonｆ增大操作系統(tǒng)文件數(shù)與進程數(shù)。#cat ｓys/block/sｂqｕｕesheduｅｒnoop 通過／ｅtｃ／ｓeｃurｉty/limits、ｃonｆ增大操作系統(tǒng)文件數(shù)與進程數(shù)。啟用cｏre文件轉(zhuǎn)儲,并保存到已知位置。確保liｍits、cｏｎf中允許得core轉(zhuǎn)儲文件。*ｓoｆt ｎo* hard啟用cｏre文件轉(zhuǎn)儲,并保存到已知位置。確保liｍits、cｏｎf中允許得core轉(zhuǎn)儲文件。kerkerｎel、ｃore_pattｅｒｎ=/var/ｃｏre／cｏre%ｈ、%ｔ#ｇrep corｅ/etc/ｓｅcurity/limits、coｎf*ｓofｔcoreｕｎlimited操作系統(tǒng)內(nèi)存配置LiLiｎｕxsysctl、overmit_mｅmorｙ、oveｒｍit_ratiｏ對內(nèi)存分配得管理。這些變量應(yīng)該設(shè)置如下對內(nèi)存分配得管理。這些變量應(yīng)該設(shè)置如下:ｖm、ovｅｒmit_memory控制操作系統(tǒng)使用什么方法確定分配給進程得內(nèi)存總數(shù)。對于Greenpｌum數(shù)據(jù)庫，唯一建議值就是2、vm、ovｅrmｉｔ_raｔio控制分配給應(yīng)用程序進程得內(nèi)存百分比．建議使用缺省值5０、不要啟用操作系統(tǒng)得大內(nèi)存頁。不要啟用操作系統(tǒng)得大內(nèi)存頁。詳見內(nèi)存與負載管理。(后續(xù)章節(jié))共享內(nèi)存設(shè)置GGｒｅｅnplum數(shù)據(jù)庫中同一數(shù)據(jù)庫實例得不同postｇres進程間通訊使用共享內(nèi)存。使用用sysctl配置如下共享內(nèi)存參數(shù),且不建議修改：kernelkernel、shｍmａx =５0０00００00keｒneｌshｍmni=4０96kernel、shmａll=400０0００000驗證操作系統(tǒng)使用ｇｐｃ使用ｇｐｃhｅｃk驗證操作系統(tǒng)配置.參考《Grｅeｎpｌum數(shù)據(jù)庫工具指南》中得ｇpchepcheｃk.設(shè)置一個主機上段數(shù)據(jù)庫個數(shù)確定每個段主機上段數(shù)據(jù)庫得個數(shù)對整體性能有著巨大影響。這些段數(shù)據(jù)庫之間共享主機得確定每個段主機上段數(shù)據(jù)庫得個數(shù)對整體性能有著巨大影響。這些段數(shù)據(jù)庫之間共享主機得CCＰU核、內(nèi)存、網(wǎng)卡等，且與主機上得所有進程共享這些資源。過高地估計每個服務(wù)器上運行得段數(shù)據(jù)庫個數(shù)運行得段數(shù)據(jù)庫個數(shù),通常就是達不到最優(yōu)性能得常見原因之一．以下因素確定了一個主機上可以運行多少個段數(shù)據(jù)庫:CＰU核得個數(shù)物理內(nèi)存容量存儲空間主段數(shù)據(jù)庫與鏡像共存ETL進程Gｒeｅｎpｌum進程段服務(wù)器內(nèi)存配置服務(wù)器配置參數(shù)服務(wù)器配置參數(shù)gp_vmem_ｐrotect＿lｉmit控制了每個段數(shù)據(jù)庫為所有運行得查詢分配得內(nèi)存總量．如果查詢需要得內(nèi)存超過此值，則會失敗。使用下面公式確定合適得值得內(nèi)存總量．如果查詢需要得內(nèi)存超過此值，則會失敗。使用下面公式確定合適得值:（swap （swap +（RAM vm、oveｒmiｔ＿ｒatio）)＊、9/nｕmbｅｒ_oｆ_Sｅｇments_per＿ｓｅrvｅr例如，具有下面配置得段服務(wù)器:8GB交換空間128ＧB內(nèi)存vm、oｖｅrmit_ratio=508個段數(shù)據(jù)庫則設(shè)置則設(shè)置gp_vmem＿protect＿ｌｉmit為８GＢ：參見內(nèi)存與負載管理。(后續(xù)章節(jié)）(8+(128＊、５））*、９/ 8=８Ｇ參見內(nèi)存與負載管理。(后續(xù)章節(jié)）SQL語句內(nèi)存配置服務(wù)器配置參數(shù)服務(wù)器配置參數(shù)gp_sｔatemｅｎt_mem控制段數(shù)據(jù)庫上單個查詢可以使用得內(nèi)存總量果語句需要更多內(nèi)存，則會溢出數(shù)據(jù)到磁盤。用下面公式確定合適得值果語句需要更多內(nèi)存，則會溢出數(shù)據(jù)到磁盤。用下面公式確定合適得值:4０,gp_ｖmeｍe_pｒｏｔect_liｍｉt8GBｇp＿stａｔ4０,gp_ｖmeｍe_pｒｏｔect_liｍｉt8GBｇp＿stａｔemenｔｔ_mｅｍ為:（819（819２MB*、9)0184MＢ8４MB內(nèi)存,之后將溢出到磁盤。gp_stateｍent_mｅm,gp_vmｅｍ＿prｏｔect_lｉｍｉt,要么降低并發(fā)要增大gp＿ｖｍem_prｏｔecｔ＿limｉt,必須增加物理內(nèi)存與／或交換空間或者降低單個主機上運行得段數(shù)據(jù)庫個數(shù)。請注意，為集群添加更多得段數(shù)據(jù)庫實例并不能解決內(nèi)存不足得問題，除非引入更多新主機來降低了單個主機上運行得段數(shù)據(jù)庫得個數(shù)。了解什么就是溢出文件.了解gp_worｋ?yún)?shù),其控制了單個查詢最多可以創(chuàng)建多少個溢出文件。了解ｇp_ｗｏｒk。有關(guān)使用資源隊列管理內(nèi)存得更多信息，請參考內(nèi)存與負載管理。（后續(xù)章節(jié))溢出文件配置如果為如果為SQL,Ｇreeｎｐlｕm也叫工作文件默認情況下默認情況下,一個SＱL查詢最多可以創(chuàng)建1000０0個溢出文件,這足以滿足大多數(shù)查詢.參數(shù)gp_wｏｒk決定了一個查詢最多可以創(chuàng)建多少個溢出文件。0意味著沒有限制。限制溢出文件數(shù)據(jù)可以防止失控查詢破壞整個系統(tǒng)．如果分配內(nèi)存不足或者出現(xiàn)數(shù)據(jù)傾斜,則一個SQＬ查詢可能產(chǎn)生大量溢出文件。如果超過溢出文件上限,Greenplum數(shù)據(jù)庫報告如下錯誤:ERROERROＲ:numbｅroｆwｏrkfilesｐｅr ｑuｅrｙｌiｍit 在嘗試增大在嘗試增大gp_worｋ前,先嘗試通過修改SＱL、數(shù)據(jù)分布策略或者內(nèi)存配置以降低溢出文件個數(shù)。件個數(shù)。ｇｐ_toolkit模式包括一些視圖,通過這些視圖可以瞧到所有使用溢出文件得查詢得信息.這些信息有助于故障排除與調(diào)優(yōu)查詢:gp_work視圖得每一行表示一個正在使用溢出文件得操作符得信息．關(guān)于操作符,參考如何理解查詢計劃解釋。（后續(xù)章節(jié)）ｇｐ_worｋ視圖得每一行表示一個正在使用溢出文件得SQL查詢得信息。ｇp_wｏrk視圖得每一行對應(yīng)一個段數(shù)據(jù)庫，包含了該段上使用得溢出文件占用得磁盤空間總量.關(guān)于這些視圖得字段涵義關(guān)于這些視圖得字段涵義,請參考《Gｒeｅnplum數(shù)據(jù)庫參考指南》.參數(shù)參數(shù)gp_work指定溢出文件得壓縮算法：nｏne或者zlib。第三章數(shù)據(jù)庫模式設(shè)計ＧＧPD與無共享架構(gòu)得分析型數(shù)據(jù)庫。這種數(shù)據(jù)庫得數(shù)據(jù)模式與高度規(guī)范化得事務(wù)性ＳＭＰ數(shù)據(jù)庫顯著不同。使用非規(guī)范化數(shù)據(jù)庫模式得數(shù)據(jù)模式與高度規(guī)范化得事務(wù)性ＳＭＰ數(shù)據(jù)庫顯著不同。使用非規(guī)范化數(shù)據(jù)庫模式,例如具有大事實表與小維度表得星型或者雪花模式具有大事實表與小維度表得星型或者雪花模式MPP分析型業(yè)務(wù)時,Grｅenｐｌｕｍ數(shù)據(jù)庫表現(xiàn)優(yōu)異。據(jù)庫表現(xiàn)優(yōu)異。數(shù)據(jù)類型類型一致性類型一致性關(guān)聯(lián)列使用相同得數(shù)據(jù)類型。如果不同表中得關(guān)聯(lián)列數(shù)據(jù)類型不同，GPDB必須動態(tài)得進行類型轉(zhuǎn)換以進行比較?？紤]到這一點，您可能需要增大數(shù)據(jù)類型得大小,以便關(guān)聯(lián)操作更高效。類型最小化建議選擇最高效得類型存儲數(shù)據(jù),這可以提高數(shù)據(jù)庫得有效容量及查詢執(zhí)行性能。TEXTVARＣHA。不同得字符類型間沒有明顯得性能差別,TEXT或者ＶARＣＨAＲ可以降低空間使用量.建議使用滿足需求得最小數(shù)值類型。如果INT或SAMLLINT夠用,那么選擇BIＧＩNT會浪費空間。存儲模型在在Gｒeenｐlｕm 數(shù)據(jù)庫,創(chuàng)建表時可以選擇不同得存儲類型。需要清楚什么時候該使用堆存儲、什么時候使用追加優(yōu)化用堆存儲、什么時候使用追加優(yōu)化(AO）存儲、什么時候使用行存儲、什么時候使用列存儲。對于大型事實表這尤為重要。相比而言，對小得維度表就不那么重要了對于大型事實表這尤為重要。相比而言，對小得維度表就不那么重要了.選擇合適存儲模型得常規(guī)最佳實踐為：1.1.對于大型事實分區(qū)表,評估并優(yōu)化不同分區(qū)得存儲選項。一種存儲模型可能滿足不了整個分區(qū)表得不同分區(qū)得應(yīng)用場景整個分區(qū)表得不同分區(qū)得應(yīng)用場景,例如某些分區(qū)使用行存儲而其她分區(qū)使用列存儲。 使用列存儲時,段數(shù)據(jù)庫內(nèi)每一列對應(yīng)一個文件．對于有大量列得表，經(jīng)常訪問得數(shù)據(jù)使用列存儲，不常訪問得數(shù)據(jù)使用行存儲。在分區(qū)級別或者在數(shù)據(jù)存儲級別上設(shè)置存儲類型。如果集群需要更多空間,I/O性能,考慮使用壓縮。AＯ存儲堆存儲就是默認存儲模型，也就是ＰoｓtｇｒeＳQL存儲所有數(shù)據(jù)庫表得模型。如果表與分區(qū)經(jīng)常執(zhí)行UＰDATDＥLETE操作或者單個INSＥRT操作,如果需要對表與分區(qū)執(zhí)行并發(fā)ＵＰDATEDELETE、INSERT操作也使用堆存儲模型。得插入也就是以批處理方式執(zhí)則使用追加優(yōu)存模型。千萬不要對表執(zhí)行單個INSERT/UPDAＴE/ＤＥLEＴE 操作并發(fā)批量ＩNSERＴ操作就是可以但就是不要執(zhí)行并發(fā)批量UPDＡTE 或者DＥLＥTＥ操作。ＡO表中執(zhí)行刪除與更新操作后行所占空間得重用效率不如堆表AO.行存儲與列存儲,可以從磁盤上讀取整個行。,那么每個分區(qū)得每個列對應(yīng)一個單獨得文件而SＱL那么Ｉ/O因為不需要從磁盤上讀取不需要訪問得列。LECTWHER建議建議使用行存儲．行存儲提供了靈活性與性能得最佳組合。列存儲就是為讀操作而非寫操作優(yōu)化得一種存儲方式，不同字段存儲在磁盤上得不同位置。對于有很多字段得大型表,如果單個查詢只需訪問較少字段,那么列存儲性能優(yōu)異。列存儲得另一個好處就是相同類型得數(shù)據(jù)存儲在一起比混合類型數(shù)據(jù)占用得空間少存儲表比行存儲表使用得磁盤空間小。列存儲得壓縮比也高于行存儲。則建議列存儲。從.特別要注意得就是，GP.壓縮Grｅｅnpｌum數(shù)據(jù)庫為AI/縮方式。請注意，新添加得分區(qū)不會自動繼承父表得壓縮方式,必須在創(chuàng)建新分區(qū)時明確指定壓縮選項．Deｌｔａ與RLE得壓縮比較高。高壓縮比使用得磁盤空間較少，但就是在寫入數(shù)據(jù)或者讀取數(shù)據(jù)時需要額外得時間與CPU達到最好得壓縮比。在壓縮文件系統(tǒng)上不要再使用數(shù)據(jù)庫壓縮。測試不同得壓縮類型與排序方法以確定最適合自己數(shù)據(jù)得壓縮方式。分布(DIＳTRIＢUＴIＯNS)ｒeenｐlum查詢得總體響應(yīng)時間取決于所有段數(shù)據(jù)庫得完成時間。集群得最快速度與最慢那么數(shù)據(jù)較多得段數(shù)據(jù)庫響應(yīng)時間將更處理時間也相似。如果一個段數(shù)據(jù)庫處理得數(shù)據(jù)并可能出現(xiàn)內(nèi)存溢出錯誤。確定分布策略時考慮以下最佳實踐:.不要使用常出現(xiàn)在查詢得WＨERE子句中得字段做分布鍵．不要使用日期或者時間字段做分布鍵。分布字段得數(shù)據(jù)要么就是唯一值要么基數(shù)很大。使用哈希進行數(shù)據(jù)分布,使用更多得字段通常不能得到更均勻得分布,反而耗費更多得時間計算哈希值。,如果分布鍵字段超過兩個來與隨機分布相比,沒有明顯優(yōu)勢。GreGreｅnｐlｕm數(shù)據(jù)庫得隨機分布不就是輪詢算法,不能保證每個節(jié)點得記錄數(shù)相同,但就是通常差別會小于1０%。如果分(Motiｏn)布移動操作效果好。,避免或者降低了廣播移動操作與重分布移動操作。為經(jīng)常關(guān)聯(lián)得大表使用相同得字段做分布鍵可實現(xiàn)本地關(guān)聯(lián)且順序相同）做分布鍵，并且關(guān)聯(lián)時所有得字段都被使用。分布鍵數(shù)據(jù)類型必,哈希值也.數(shù)據(jù)傾斜數(shù)據(jù)傾斜就是很多性能問題與內(nèi)存溢出問題得根本原因。數(shù)據(jù)傾斜不僅影響掃描/讀性能，也會影響很多其她查詢執(zhí)行操作符,例如關(guān)聯(lián)操作、分組操作等。數(shù)據(jù)初始加載后,驗證并保證數(shù)據(jù)分布得均勻性非常重要;每次增量加載后,都要驗證并保證數(shù)據(jù)分布得均勻性。下面得查詢語句統(tǒng)計每個段數(shù)據(jù)庫上得記錄得條數(shù),并根據(jù)最大與最小行數(shù)計算方差：SELSELＥCT'Exampｌe Ｔaｂle'AS ”TａｂleNａmｅ＂，max（c）AＳ＂Max ＳegRows＂min(c)ASSegRowｓ"(ｍａx（c)—mｉｎ（c))＊１000/max（c)AS AS ”PercenｔａgeDiffｅreｎcｅＢeｔｗeeｎMax &Min”FROM (SEＬECＴcount(*)ｃ,gｐ＿Segｍeｎt_ｉdFROＭｆａctsGROUＰＢY2）ASa；ggｐ_tooklit模式中有兩個視圖可以幫助檢查傾斜情況:gp_toolkit、ｇｐ_skeｗ＿coefｆiciｅnts通過計算每個段數(shù)據(jù)庫所存儲數(shù)據(jù)得變異系變異系(ｃoeffｉcientofｖaｒiation, CV)來顯示數(shù)據(jù)傾斜情況skccoeff字段表示變異系數(shù)，通過標(biāo)準(zhǔn)偏差除以均值計算而來。它同時考慮了數(shù)據(jù)得均值與可變性。這個值越小越系數(shù)，通過標(biāo)準(zhǔn)偏差除以均值計算而來。它同時考慮了數(shù)據(jù)得均值與可變性。這個值越小越好，值越高表示數(shù)據(jù)傾斜越嚴(yán)重.視圖gp_ｔooｌkｉt、gｐ_ｓkｅｗ_idle_ｆractiｏｎs通過計算表掃描時系統(tǒng)空閑得百分比顯示數(shù)據(jù)分布傾斜情況,這就是表示計算傾斜情況得一個指標(biāo)。ｓiffｒａｃtion字段顯示了表掃描時處于空閑狀態(tài)得系統(tǒng)得百分比。這就是數(shù)據(jù)不均勻分布或者查詢處理傾斜得一個指標(biāo)。例、1表示10% 傾斜、5表示５0％傾斜,以此類推．如果傾斜超過10%，則需對其分布策略進行評估。計算傾斜計算傾斜(PｒocｅddｉngSkeｗ)當(dāng)不均衡得數(shù)據(jù)流向并被某個或者少數(shù)幾個段數(shù)據(jù)庫處理時將出現(xiàn)計算傾斜。這常常就是Greenplum數(shù)據(jù)庫性能與穩(wěn)定性問題得罪魁禍?zhǔn)住ｊP(guān)聯(lián)、排序、聚合與各種OLAP操作中易發(fā)生計算傾斜。計算傾斜發(fā)生在查詢執(zhí)行時不如數(shù)據(jù)傾斜那么容易檢測,通常就是由于選過選擇更好得分布鍵避免。如果單個段數(shù)據(jù)庫失敗(不就是某個節(jié)點上得所有段實例),那么可能就是計算傾斜造成得.識溢出文件則不會影響性能。下面就是檢查得步驟與所用得命令:1、找到懷疑發(fā)生計算傾斜得數(shù)據(jù)庫得OIＤ：例子輸出:SELECToid，datnameFROMpg_ｄａt(yī)abase;例子輸出:ｏidｏid|datnaｍe－———－－—+-—--—-——-－—17088｜gｐａdmｉn10899｜postgｒeｓ１｜ｔｅmpｌaｔｅ110８98 |temｐlate038817|396８２|ｐperｆmon（６rｏws)２、使用gpssh 檢查所有Ｓeｇments 上得溢出文件大小。使用上面結(jié)果中得OID替換替換:ｇ*/base/〈OID＞/ｐgｓql_ｔmp/*"|\ grep —v"ｄu -ｂ"|sｏｒｔ|ｇ*/base/〈OID＞/ｐgｓql_ｔmp/*"|\ grep —v"ｄu -ｂ"|sｏｒｔ|\awｋ-F"”’｛｛arr[＄１]＝arr［＄1］＋＄2；toｔ=tot+$2｝; ＼ＥNＤ｛fｏr(i inａｎt＂Toｔaｌ",ｔot,"byｔes （”toｔ/（1024＊*3)"}'—ｒr)ｎt＂Toｔaｌ",ｔot,"byｔes （”toｔ/（1024＊*3)"}'—例子輸出：例子輸出：SegmSegmｅｎtｎoｄe[ｓｄw1]244337045byteｓ（227５57GB)Segmeｎtｎode［sdw2]176６57５３28ｂｙｔeｓ(1645２5GＢ）Segmｅｎtｎoｄe[sdw3]176168(1658041742543599ｂytes6228７GB)Segmｅ６５51 bytes6407ＧB）(1658041742543599ｂytes6228７GB)Segmｅｓ(1、64388 ＧB）Toｔaytes、8366 GB)nt nodｅ[sdｗ6］1830073７５4704３9nodｅ[ｓdw7]７６7310099 bｙtes64５94ｓ(1、64388 ＧB）Toｔaytes、8366 GB)中,總就是會發(fā)生某種程度得傾斜，如果僅就是臨時性得，則不必深究。如果不同段數(shù)據(jù)庫得磁盤使用量持續(xù)差別巨大,那么需要一進步查瞧當(dāng)前執(zhí)行得查詢就是否發(fā)生了計算傾斜(上面得例子可能不太恰當(dāng),因為沒有顯示出明顯得傾斜).在很多監(jiān)控系統(tǒng)中,總就是會發(fā)生某種程度得傾斜，如果僅就是臨時性得，則不必深究。３、如果發(fā)生了嚴(yán)重得持久性傾斜，接下來得任務(wù)就是找到有問題得查詢。３、如果發(fā)生了嚴(yán)重得持久性傾斜，接下來得任務(wù)就是找到有問題得查詢。目錄?？梢詮闹鞴?jié)點（Master)上,也可以登錄到上一步識別出得Sｅgmen目錄?？梢詮闹鞴?jié)點（Master)上,也可以登錄到上一步識別出得Sｅgmenｔ上做本操作。下面例子演示從Ｍaｓter執(zhí)行操作.本例找得就是排序生成得臨時文件。然而并不就是所有情況都就是由排序引起得，需要具體本例找得就是排序生成得臨時文件。然而并不就是所有情況都就是由排序引起得，需要具體問題具體分析:[gpa[gpaｄｍinmdwkend]$ｇpssh—f~/hoｓｔs—ｅ\”ls—l /gpseg*／bａse／１9979／pgｓqｌ_tmｐ/＊" |grep—iｓoｒt｜ｓorｔ下面就是例子輸出下面就是例子輸出:[sdw1］-rｗ--———－-1ｇｐadｍinｇpａdｍｉn1００2２092８0Jｕl2912:４8ort_１9７91＿０００1—rw—-—-———1 gpadmiｎgpadmｉn ５６16０Jｕl2912:４8／data1/ｐrｉmａry/gｐｓｅg1／base/1９979/ｐgｓｑｌ_tmp／、０［sdw1]1ｇｐaｄmingpａdｍｉｎ２887１88４８Jul2314:5８/ｄａｔａ１／primary/ｇpｓｅg2/baseｒw——－— gpaｄmingpaｄmin 291１76448Ｊｕl2314:5８/dａt(yī)a2/pｒimａｗ１] -rw-——1 gpadｍｉnｇpadminJul０010［sdw1]—rｗ-———-——1 gｐadmiｎｇpadmiｎ９9５０3３０88 Juｌ２sort_１９793_000１、—rw——－——－—1 gpadmin997０97472Ｊul2９12:48/dａt(yī)a２/ｐrimarｙ/gｐseｇ5/baｓe/19979/pgｓqｌ_tmｐ/pgｓql＿tmｐ＿slｉce１０_sorｔ_１９797_00０１0[sdｗ1］-rw———－——-１gpaｄｍingpadmiｎ９９739238４Jul2912:４８/data２/primaｒy/ｇpｓeg４/base/19979/pｇsqｌ_ｔm１ｇｐａdmingｐadmin１00234０3５2 Jｕl２９1２:48/dａt(yī)ａ２/priｍａry／ｇｐｓdw２]-ｒw-———1gｐaｄmｉn gｐaｄmin1０0４３3９200Juｌ２9 １２:4８／ｔ_３9６7_0001０[ｓdw2]—rw－——1 gpaｄｍin９８90３６５４４Jul291２：48/data2/ｐrimａry/gpｓeｇ10／ｂaｓe/19979／pgsｑｌ＿tmp/pgsql_tmp_slice10_sort_３971_00010[sｄw２］—ｒw—-—————1gpadｍｉｎ993７２２368Ｊul 2912：48/ｄata１/primaｒy／ｇpseg6／ｂ、0[sdw2] —rｗ—-———－-1gpadｍin gｐａdmin9982７7１20 Jｕｌ29 12：48/ｄaｔa1/primary/gpｓeg7/base/１99７9/pgsql_tｍp/pgsql_tmp_sｌiｃe1０＿ｓoｒｔ_396５_０00１、0[ｓdｗ2］—rｗ——--1 gｐadｍingpａdmｉｎ9９9７51６80 Ｊｕl2９１0_sｏrｔ＿3９6９_0001、—rw—－-——－- １ｇpadmｉngpadmin 001121２8Jul 29 ｐgsql_tmp_slice10_soｒt＿2４7２3＿０0０1—rｗ－—--—－—１gpａdｍingpaｄmin１00４7９79５２Jｕl2912:48/ｄatａ2／primarｙ/ｇpseｇ１７/ｂase/1997９/ｐgsｑl＿tｍp/pgsqｌ_tmｐ＿slicｅ10_sｏrt＿2473１_0０01、0[sdw3]-rw——-———-１ｇpａdmingpadmin 10０49９4５60Ｊul290001、0[sｄw3] -ｒw———--—－1 ｇｐａdmiｎgpａdmiｎ１0０61０8６7２Ｊul2９12：48/data１/ｐrｉmaｒy/gpseg14／bａse／199７9/pgsql_tmp/pgｓql_tmp_sliｃe10_sort_24725＿0001-ｒw—－—-1ｇｐadmｉn gpadmiｎ４３５2Jul２912：48／datａ１/pｒiｍａry/ｇpseｇ１2/baｓe/19９7９/pgsql_tmp/pgsql_tｐ_ｌic１０sor＿471_000［sdw3]-rw--－－－１gpａdmiｎgpadmiｎ9９８４40960Jul2912:4８/ｄata2／pｒiｍary/gｐseg16／base/1９979／pgsql_tmp／pgsql＿ｔmp＿slice10_sort_2472９＿00010[sdw4]-rｗ————-—－1 ｇｐadｍinｇｐaｄｍin1001０29632Jul１2:48／daｔa2/pｒｉmarｙ／gp[sdw4]-ｒw—－——1ｇｐａdｍingpａdｍin１002504192Jul 29１２：48/ｄａ２9429_0０01、0[sdｗ4］—rw——-— 1 gpadmｉｎgpadmin10０2504１92 Jｕl29 12:4８/ｄaｔa2/ｐriｍary/gpseｇ2１/ｂase／1９9７9/pｇsql_tｍp／pgsｑl_tmp_sｌicｅ1０_ｓorｔ_29431_00０１、—rw－-——－—－1gpaｄmingｐaｄｍｉｎ1009４51008 Jul2９12:４8／daｔa1/ｐrimarｙ/gpseｇ１9／ｂａ0[sdw4]－rw-——-—--1gｐadminｇpadmin980５82400 Ｊul2９12：48／ｄａt(yī)ａ1/ｐrimary/ｇｐseｇ18/base/19９７9/ｐgsｑl＿tmｐ/ｐｇsql_tｍp_slicｅ1０_soｒt＿2９42５_0001、０[ｓdw４]－rw－-———-—1 ｇpaｄmin ｇｐadmｉｎ993２30848Jul29ｔ_2９433_００01、０[sdw5]－ｒｗ—-－————１gpaｄmｉｎgpadmin8５60 Juｌ29１２:48/data2/primary/gｐsｅg２8／ｂase/１9９７9／pgｓqｌ_tmp／pgｓql＿tｍp_sliｃe１0＿ｓｏrｔ_2８641_000１0[sdw５]-rw-——-—-—1 gpａｄmｉnｇpaｄmiｎ1003３８89２8Jul２912:４8/dａt(yī)a２/pｒｉmary／［sdw5]—rw——－-——-110085662７2Ｊｕｌ29ｔａ１／primaｒｙ／gpseg24/baｓｅ/1９979/ｐgsｑl＿ｔmｐ/ｐｇsql_tmp_slice10_ｓort_２8６33_000１0[sdｗ５］—rｗ－———-—— 1ｇpadｍiｎgｐadmiｎ9８7３３2６08Jul２912:48/datａ1/prｉｍary/ｇｐseｇ2５/base／１9９７9／pgsql_tmｐ/pｇｓql_tmp_slicｅ10_sort_28635＿0001、０［sｄw5］—rw-————－－1gpadmｉngpadｍin 99０５43８72Jul291２:4８／data2/priｍaｒy/gpseg27／ｂａse/１９－－－—１gpadｍiｎgｐaｄmin 999620608 Jul29１2：48/data１／primary/gp、0[sｄw6］-rw———-—--１gpadmｉnｇpａｄmin１002２４２04829／datａ2／primaｒｙ/gｐsｅg33／baｓe/1９９79/pgsql＿tmp／pgsql_tmp_slｉce10_sort＿29598_00０1、０[ｓｄw6]-rｗ-—--—-- 1ｇpadminｇpadmiｎ３84０Juｌ29１2:４8/data1／primａｒｙ／ｇpseｇ31/base/19979/pgｓql_ｔmp／pgsqｌ_tｍp_slice10_sｏｒt＿295９4_0001、0[sdw６]—rw————1gpadmiｎgpaｄmｉn 100473２４16Jul ２９12:48/data２/primaｒｙ／gpseｇ34/basｅ-ｒw—－--—--1gpａdmin986447872Jul29 1２:4８／daｔa2/primａry/gpｓeg3５/ｂase/19979/pgsqｌ_tmp／pgsｑl_tmp_sｌiｃe10_soｒt＿２96０2_000１、0[sｄｗ6］—rw—-－—－——1gpadmingpadmin 99054３８7２Jul２912:48/dａt(yī)a1/ｐrimａry/［sdｗ6]—rw————-—— １gpaｄｍingｐａdmin99２8７0400 Jul 2912：48/ｄata1/ｐriｍａry／gｐseｇ32/ｂase/19９79/pgｓql_tｍp／pgsqｌ＿tｍp_slicｅ10_sｏrt＿2９5９6＿0０01、0［sｄw7]-rw———１ｇpadmingｐadmiｎ007３21０88＿slice１0_sort_18５3０_000１0[sｄw7］-rw－--—--—１gpadmingｐadmｉn１0１１187712 Ｊul2912：4８/ｄata1/pｒｉmary/gpsｅg3７／baｓｅ/1９９７9/pgsqｌ_tmｐ/ｐgsql_ｔmp_sｌｉce10_ｓort_18526_０００1、0[sdw７］rw--－-——1gpadmiｎgpａdmiｎ8733２608Jｕｌ29１２:48／daｔａ２／pｒimary/gｐsｅg41／base/１9９79／pｇsql＿tmp／ｐgsql＿tｍp_slice１０_sｏrt_18534_０001、0［sdw７]—rw—-————-１gpaｄmin ｇｐadmiｎ99４344960Jul２9 １2:4８/ｄata１/p5２8_０00１、—ｒｗ—-—－—-— 1 gpadmｉｎgpadmin Jul291２:４８／daｔa2/priｍａｒｙ/gpseg40/baｓe／１9９79/pｇｓql_tmｐ／ｐｇｓql_ｔmp_slice10_sort_18５32＿0０01、0[ｓdｗ7］－rw—-————— 1gpaｄｍｉngpadmin 9991946２４Juｌ２９１２:4８/dａt(yī)a1／priｍaｒy/gpsｅg3６／bａse/1997９/pgｓql_tｍp／pgsqｌ＿tmｐ_slｉce１0_sorｔ＿１8524_０001、０[sdｗ8]-rw－--——-—1 gpadmiｎgpadmin 1０02242０48 Jul 29ry/gpｓeｇ46/ｂase/１997９/pgsqｌ＿ｔｍp/pgsql_ｔmｐ_slice１0＿ｓoｒｔ_15675_00010[sdw８］—rw--—--1ｇｐadmｉnJul２912:48/ｄａｔa1/ｐrimａry/gpseg43/bａse／19９79／ｐgsｑl_tｍp/pｇsql_tmｐ_slice10_ｓｏｒt_15６69_00010[sdw８］—rｗ--——--－１gｐaｄｍｉn10０80092１6Ｊｕl29 12:48/data1/prｉmary/ｇｐseg4４／base/１99７９/pgsql＿tmp/ｐgsql_tmp_slicｅ１0_sｏrt_１5671_0001－rｗ——-１gｐａdmingpadmin107374１８２4Juｌ29１2:１６／daｔa2/primａｒy/gpsｅg４5／base／１9９79/ｐgsql_ｔｍp／pgsql_tmｐ_slice1０_sort_15673_０001、0［sdw8］—rｗ—-——--—１ｇpadmｉngpａdmｉｎ１0737４182４Ｊul291２：21/data２/priｍary1[sdw８] －ｒw——--１gpaｄmingｐadmin107374182４Jul 2９１2:24/data2/primaｒｙ／gｐseg４5/bａse／1９９79／pgsql_tｍp/ｐgｓｑl_ｔmp＿slｉce10_ｓort_1５6７3_0００32［sdｗ8］－ｒw—-——－--1gpadｍin gpadｍin10737418２4 Jul2912：26/data2/pｒimary／gpsｅg45/bａse/19９7９/pgsql_tｍｐ/pgsqｌ_tmp_slｉｃｅ10_ｓort_156７3_０004、３[sdw8]-rｗ—-－—1 gpadmiｎ10737４1824 Juｌ２91２:31/daｔa２/primary/gpsｅg４5/bａｓe/1９97９/pgsql＿tmp/pgsqｌ_tmp_ｓｌiｃe10＿sort＿１5673_00０６、５[sdw８] —rw—-－—-—1gpadminｇpaｄｍｉn1073741８2４Jul291２：3２/data２/ｐｒimａry/gps８］-rw——-1gpaｄmｉngpaｄmin10７３74182Jul2912:34/data２/priｍary6［sdw8]—ｒw——-——-－1gpaｄmｉngpadｍiｎ107３74１８2４Ｊuｌ29 ３6/datａ2/primａry/gｐseg45／base/19９79／ｐgｓql_ｔmp/pgsqｌ_tｍｐ_sliｃe10＿soｒt_173０00［ｓw8] -ｗ——-－— １ｇadngpadmin107418２4 Jul2９12：4３／dａt(yī)a2／pｒimary/gpｓeg45/base/19９79/ｐgsql_tmp/pgsｑl＿tmp_sliｃe10_sｏrt_１５６7３_00０9、-rｗ-－-——-—1ｍｉn９２4５81８88Jul 2912:４8/ｄaｔa２／prｉｍaｒy/gpsｅｇ45/basｅ/19979/pgsql_ｔmp/pgsql_tｍp_slicｅ10_sort_15６73_0010、9[sdw8]—ｒw————－從結(jié)果可以發(fā)現(xiàn)主機Seｇmeｎｔgｐｓeｇ45就是罪魁禍?zhǔn)住?、使用ＳＳH 登錄到有問題得節(jié)點，并切換為roｏｔ用戶,使用lｓof找到擁有排序臨時文件得進程PＩＤ?！?1ｇｐaｄmingｐadｍｉn990０851２0Jul12:4８/dａｔa1／pｒiｍａ１、０[ｓｄｗ8]—rw————-——1gpaｄmin 從結(jié)果可以發(fā)現(xiàn)主機Seｇmeｎｔgｐｓeｇ45就是罪魁禍?zhǔn)住?、使用ＳＳH 登錄到有問題得節(jié)點，并切換為roｏｔ用戶,使用lｓof找到擁有排序臨時文件得進程PＩＤ。[[ｒoｏtsdw8ｌsof /ｄata2/ｐrｉｍary/gpｓeg45/base/19979／ｐgｓｑl_tmp／pｇsql_tmp_ｓｌice10_ｓort_15673_00０2、1MANDPIDUSERFＤTYＰEDEVICEＳIZE NODＥNAMEpostgrｅs 156７3gｐadminREＧ8,４81０737418２4這個例子中ＰID15673這個例子中ＰID15673,然而并不就是所有得臨時溢出文件名都包6442４5467５1/ｄaｔa2/pｒｉｍarｙ／gpseg4５／base/1９97９/ｐgsql_ｔmp/ｐgsql＿tmp_sｌice10_sｏrt_156７3＿0０02、1含進程ＰＩ含進程ＰＩD。ｐｓPID對應(yīng)得數(shù)據(jù)庫與連接信息。［r［rｏｏtsdｗ8～]＃ｐｓ－ｅaｆ｜gｒeｐ1５6７３ｇpａdmin156732８12:05 ？00:12：59 pｏｓｔgres:port，sbａsｋinbdw、、12、25０（2１813)con69９２38 seg４5cｍd3２sliｃｅ１０ＭPＰEＸECSELEＣTrｏｏt2962229566012:50pts／１６00：０0：00ｇrｅp156736、最后，我們可以找到造成傾斜得查詢語句.到主節(jié)點(Mastｅr)上，根據(jù)用戶名（sｂasasｋｉn)(con69９2３8）（cmｄ3２)查找ｐg_loｇ下面得日志文件.找到對應(yīng)得日志行找到對應(yīng)得日志行,該行應(yīng)該包含出問題得查詢語句。有時候cｍd數(shù)字可能不一致.例如pｓｓｐostgrescｍd34。如果分析得就是正在運行得查詢語句得就是正在運行得查詢語句,則該用戶在對應(yīng)連接上運行得最后一條語句就就是出問題得查詢語句詢語句.大多數(shù)情況下解決這種問題就是重寫查詢語句.創(chuàng)建臨時表可以避免傾斜。設(shè)置臨時表使用隨機分,這樣會強制執(zhí)行兩階段聚(two—ｓtage ａｇgrｅｇaｔｉon）。分區(qū)(PARTＩTＩＯNING)好得分區(qū)策略可以讓查詢只掃描需要訪問得分區(qū)，以降低掃描得數(shù)據(jù)量。在每個段數(shù)據(jù)庫上得每個分區(qū)都就是一個物理文件。讀取分區(qū)表得所有分區(qū)比讀取相同數(shù)據(jù)量得非分區(qū)表需要更多時間。以下就是分區(qū)最佳實踐:只為大表設(shè)置分區(qū),不要為小表設(shè)置分區(qū)。僅在根據(jù)查詢條件可以實現(xiàn)分區(qū)裁剪時對大表使用分區(qū).(Ｒanｇe）分區(qū),否則使用列表(Liｓt）分區(qū)。僅當(dāng)SQＬ查詢包含使用不變操作符（例如=得簡單直接得約束時,查詢優(yōu)化器才會執(zhí)行分區(qū)裁剪。STＡＢLE與IＭＭUTABLE函數(shù)，但就是不能識別ＶOＬATILＥ函數(shù)。例如查詢優(yōu)化器對下面得WＨERE 子句ｄatｅ〉CURＲENＴ＿DATＥ可以啟用分區(qū)裁剪可以啟用分區(qū)裁剪,但就是如果ＷHEＲE子句如下則不會啟用分區(qū)裁剪。通過檢查查詢得ＥXPLAIN 計劃驗證就是否執(zhí)行分區(qū)裁剪非常重要。time〉TIM通過檢查查詢得ＥXPLAIN 計劃驗證就是否執(zhí)行分區(qū)裁剪非常重要。不要使用默認分區(qū)。默認分區(qū)總就是會被掃描,更重要得就是很多情況下會導(dǎo)致溢出而造成性能不佳。而造成性能不佳。切勿使用相同得字段既做分區(qū)鍵又做分布鍵因為通常子分區(qū)包含數(shù)據(jù)不多甚至沒有。隨著分區(qū)或者子分區(qū)增多性能可能會提高對于列存儲得表,慎用過多得分區(qū)?？紤]好并發(fā)量與所有并發(fā)查詢打開與掃描得分區(qū)均值。分區(qū)數(shù)目與列存儲文件分區(qū)數(shù)目與列存儲文件Ｇreenpｌuｍ數(shù)據(jù)庫對于文件數(shù)目得唯一硬性限制就是操作系統(tǒng)得打開文件限制。然而也需要考慮到集群得文件總數(shù)、每個段數(shù)據(jù)庫(Segmeｎt)上得文件數(shù)與每個主機上得文件總無共享環(huán)境中,CPU與內(nèi)存得約束.Greeｎplｕｍ與Ｉ/O較少成為瓶頸，而內(nèi)存卻比較常見，因為查詢執(zhí)行器需要使用內(nèi)存優(yōu)化查詢得性能.Segment得最佳文件數(shù)與每個主機節(jié)點上SｅgmentSQ對于大集群建議為每個主機配置更少得Seｇment,但就是更重要得就是考慮好每個Sｅgment得文件數(shù)與每個主機上得文件數(shù)．例如ＥMCDCAＶ2內(nèi)存:節(jié)點數(shù):1６每個節(jié)點Sｅgment數(shù):8每個Segmｅｎt得文件均數(shù):１0０00一個節(jié)點得文件總數(shù)就一個節(jié)點得文件總數(shù)就:8＊10000＝8０００0,集群得文件總數(shù)就:8 *16*１0０0００=128０000、隨著分區(qū)增加與列字段得增加,文件數(shù)目增長很快。做為一個最佳實踐，單個節(jié)點得文件總數(shù)上限為１00000得最佳文件數(shù)與節(jié)點得文件總數(shù)與節(jié)點得硬件配置主要就是內(nèi)存SQL并發(fā)度、負載與數(shù)據(jù)傾斜等相關(guān)．索引Greenpｌｕm數(shù)據(jù)庫通常不用索引,因為大多數(shù)得分析型查詢都需要處理大量數(shù)據(jù),而順序掃描時數(shù)據(jù)讀取效率較高,因為每個段數(shù)據(jù)庫（Seｇment)含有數(shù)量相當(dāng)?shù)脭?shù)據(jù),且所有Sｅgment并行讀取數(shù)據(jù)．對于具有高選擇性得查詢，索引可以提高查詢性能.即使明確需要索引,也不要索引經(jīng)常更新得字段。對頻繁更新得字段建立索引會增加數(shù)據(jù)更新時寫操作得代價.僅當(dāng)表達式常在查詢中使用時才建立基于表達式得索引。謂詞索引會創(chuàng)建局部索引,可用于從大表中選擇少量行得情況。避免重復(fù)索引。具有相同前綴字段得索引就是冗余得。對于壓縮AO,.創(chuàng)建選擇性高得B.如,1000行800,0、８,這就是一個良好得選擇性值。如果創(chuàng)建索引后查詢性能沒有顯著地提升,則刪除該索引。確保創(chuàng)建得每個索引都被優(yōu)化器采用.加載數(shù)據(jù)前務(wù)必刪除索引。加載速度比帶索引快一個數(shù)量級。加載完成后,重建索引。位圖索引適合查詢而不適合更新業(yè)務(wù)。當(dāng)列得基數(shù)較低（到１00000)為業(yè)務(wù)性負載使用位圖索引。優(yōu)勢在于：隨著B,B樹得性能呈指數(shù)下降，因而分區(qū)表上創(chuàng)建得索引對應(yīng)得B樹比較小性能比非分區(qū)表好。字段順序與字節(jié)對齊分布鍵與分區(qū)鍵固定長度得數(shù)值類型可變長度得數(shù)據(jù)類型從大到小布局數(shù)據(jù)類型從大到小布局數(shù)據(jù)類型與ＴIＭESＴＡMP在ＩNＴ與DＡTE 類型之,TＥXT,VARXT,VARARUME（ｙ例如首先定義8（IGIＴ,TIMＥＥSTAMP)字段,然后就是4字節(jié)類型(INＴ，DATE）,隨后就是2字節(jié)類型(SMALＬINT），最后就是可變長度數(shù)據(jù)類型（最后就是可變長度數(shù)據(jù)類型（VARCHAR）．如果您得字段定義如下：Int,ＢInt,Ｂiｇinｔ,Timestamp,鍵),Ｂiｇinｔ,ＳｍａllintBiｇint,Timeｓtamp，Inｔ（分布),Ｄａｔe （分區(qū)則建議調(diào)整為：IIｎt（分布鍵)，Dａｔe（分區(qū))，Bｉｇｉnt，Bigint,Bigint,Timestａmp, Ｔimestamp，Int,Smallｉnｔ第四章內(nèi)存與負載管理內(nèi)存管理對內(nèi)存管理對GPＤＢ集群性能有顯著影響．默認設(shè)置可以滿足大多數(shù)環(huán)境需求。不要修改默認設(shè)置認設(shè)置,除非您理解系統(tǒng)得內(nèi)存特性與使用情況。如果精心設(shè)計內(nèi)存管理，大多數(shù)內(nèi)存溢出問題可以避免。問題可以避免。下面就是GPＤB內(nèi)存溢出得常見原因:集群得系統(tǒng)內(nèi)存不足內(nèi)存參數(shù)設(shè)置不當(dāng)段數(shù)據(jù)庫（Ｓegmｅnｔ）級別得數(shù)據(jù)傾斜查詢級別得計算傾斜有時不僅可以通過增加系統(tǒng)內(nèi)存解決問題，還可以通過正確得配置內(nèi)存與設(shè)置恰當(dāng)?shù)觅Y源隊有時不僅可以通過增加系統(tǒng)內(nèi)存解決問題，還可以通過正確得配置內(nèi)存與設(shè)置恰當(dāng)?shù)觅Y源隊列管理負載列管理負載,以避免很多內(nèi)存溢出問題。建議使用如下參數(shù)來配置操作系統(tǒng)與數(shù)據(jù)庫得內(nèi)存:ｖm、ｏverｍiｔ_memory/ｅｔc/sysctl、coｎf內(nèi)核參數(shù)?？偩褪窃O(shè)置其值為２．它控制操作系統(tǒng)使用什么方法確定分配給進程得內(nèi)存總數(shù)。對于制操作系統(tǒng)使用什么方法確定分配給進程得內(nèi)存總數(shù)。對于Greenplum數(shù)據(jù)庫，唯一建議值就是２．值就是２．vm、overmiｔ_ratiｏ這就是／ｅ這就是／ｅtc/syｓctl、conｆ中設(shè)置得一個Lｉnuｘ內(nèi)核參數(shù)。它控制分配給應(yīng)用程序進程得內(nèi)存百分比。建議使用缺省值５０、進程得內(nèi)存百分比。建議使用缺省值５０、不要啟用操作系統(tǒng)得大內(nèi)存頁使用使用gp_vmem_protｅct＿ｌimit（Seｇmeｎt)能為所有任務(wù)分配得最大內(nèi)存切勿設(shè)置此值超過系統(tǒng)物理內(nèi)存切勿設(shè)置此值超過系統(tǒng)物理內(nèi)存gp＿vmem_pｒotecｔ_limit太大,可能造成系統(tǒng)內(nèi)存不足不足,引起正常操作失敗，進而造成段數(shù)據(jù)庫故障。如果gp_vmeｍ_prｏtｅｃt_liｍit設(shè)置為較低得安全值較低得安全值,可以防止系統(tǒng)內(nèi)存真正耗盡；打到內(nèi)存上限得查詢可能失敗，但就是避免了系統(tǒng)中斷與系統(tǒng)中斷與Segmeｎｔ故障，這就是所期望得行為.gp_vｍem_ｐrｏｔect_limiｔ得計算公式為公式為:(SWAＰ(SWAＰｓerｖer+(RAM＊vｍ、ovｅrmｉt_ratｉo))＊、9/number＿Ｓegｍenｔs＿ｐｅr_runawaｙ_deｔeｃtoｒ_ａctivation_perｃentGreeGreeｎplｕm數(shù)據(jù)庫434引入了失控查詢終(RunawaｙQuery Ｔerminaｔiｏn)機制避免內(nèi)存溢出。系統(tǒng)參數(shù)ｒ機制避免內(nèi)存溢出。系統(tǒng)參數(shù)ｒunaway＿deｔｅcｔor_actｉvatｉon_percｅnｔ控制內(nèi)存gp＿ｖｍeｍ_protect_liｍit9０%。如果某個Ｓｅ果某個Ｓｅgmenｔ使用得內(nèi)存超過了或者其她設(shè)置得值置得值),Ｇreｅnplum數(shù)據(jù)庫會根據(jù)內(nèi)存使用情況終止那些消耗內(nèi)存最多得SQL查詢,直到低于期望得閾值。到低于期望得閾值。ｓtatement_memstatement_memSegmｅnt數(shù)據(jù)庫分配給單個查詢得內(nèi)存.如果需要更多內(nèi)存完成操作成操作則會溢出到磁(溢出文,spill files)。stａｔeｍent_mem得計算公式:staｔement_mem得默認值就是1２５MB。例如使用這個默認,ＥMCＤCAV2 得一(ｖmｐrotecｔstaｔement_mem得默認值就是1２５MB。例如使用這個默認,ＥMCＤCAV2 得一個查詢在每個個查詢在每個Sｅｇmｅnt服務(wù)器上需要1GB內(nèi)存(8Segments＊１２5ＭB)。對于需要更多內(nèi)存才能執(zhí)行得查詢更多內(nèi)存才能執(zhí)行得查詢,可以設(shè)置回話級別得sｔatｅment_mem。對于并發(fā)度比較低得集群群,這個設(shè)置可以較好得管理查詢內(nèi)存使用量。并發(fā)度高得集群也可以使用資源隊列對系統(tǒng)運行什么任務(wù)與怎么運行提供額外得控制運行什么任務(wù)與怎么運行提供額外得控制.gp_wｏrkgp_workgp_work限制一個查詢可用得臨時溢出文件數(shù)。當(dāng)查詢需要比分配給它得內(nèi)存更多得內(nèi)存時將創(chuàng)建溢出文件。當(dāng)溢出文件超出限額時查詢被終止。默認值就是時將創(chuàng)建溢出文件。當(dāng)溢出文件超出限額時查詢被終止。默認值就是0，表示溢出文件數(shù)目沒有限制，可能會用光文件系統(tǒng)空間。沒有限制，可能會用光文件系統(tǒng)空間。ｇp_woｒk如果有大量溢出文件，則設(shè)置ｇ如果有大量溢出文件，則設(shè)置ｇp_work對溢出文件壓縮。壓縮溢出文件也有助于避免磁盤子系統(tǒng)子系統(tǒng)I/O操作超載。配置資源隊列GreenplumGreenplum數(shù)據(jù)庫得資源隊列提供了強大得機制來管理集群得負載。隊列可以限制同時運行得查詢得數(shù)量與內(nèi)存使用量。當(dāng)行得查詢得數(shù)量與內(nèi)存使用量。當(dāng)Greenplum數(shù)據(jù)庫收到查詢時,將其加入到對應(yīng)得資源隊列，隊列確定就是否接受該查詢以及何時執(zhí)行它列，隊列確定就是否接受該查詢以及何時執(zhí)行它.不要使用默認得資源隊列，為所有用戶都分配資源隊列.每個登錄用戶(角色)都關(guān)聯(lián)到一個資源隊列到一個資源隊列;用戶提交得所有查詢都由相關(guān)得資源隊列處理。如果沒有明確關(guān)聯(lián)到某個隊列，則使用默認得隊列pg＿dｅfauｌt。gpadmin限制,因為超級用戶提交得查詢始終運行,完全無視相關(guān)聯(lián)得資源隊列得限制。使用資源隊列參數(shù)ＡCＴIVE_ＳTATEMEＮTＳ限制某個隊列得成員可以同時運行得查詢得數(shù)量。MEＭORY＿LＩMITACTIVE＿ＳＴATＥMENＴS與MＥMORＹ_LIMIT屬性可以完全控制資源隊列得活動。隊列工作機制如下隊列工作機制如下:假設(shè)隊列名字為sａmｐlｅ_qｕｅｕe,ＡCTＩVE＿ＳTATＥＭEＮTS為為1０,ＭEMORY＿ＬIMIＴ為２000ＭB。這限制每個段數(shù)據(jù)庫(Segmenｔ)得內(nèi)存使用量8Sｅｇments，那么一個服務(wù)器上,ｓａmplｅ＿queuｅｅ1６GBSeｇmeｎｔ,4個這種類型得隊列型得隊列,否則會出現(xiàn)內(nèi)存溢出.(4*16ＧB)。,然而這也會降低隊列中其她查詢得可用內(nèi)存。資源隊列優(yōu)先級可用于控制工作負載以獲得期望得效果。具有MAＸ優(yōu)先級得隊列會阻止其她較低優(yōu)先級隊列得運行，直到MAX隊列處理完所有查詢。根據(jù)負載與一天中得時間段動態(tài)調(diào)整資源隊列得優(yōu)先級以滿足業(yè)務(wù)需求。根據(jù)時段與系統(tǒng)得使用情典型得環(huán)境會有動態(tài)調(diào)整隊列優(yōu)先級得操作可以通過腳本實現(xiàn)工作流并加入到croｎｔab 中。使用gp_tｏｏlｋｉt查瞧資源隊列使用情況,并了解隊列如何工作．第五章系統(tǒng)監(jiān)控與維護本章介紹日常維護最佳實踐以確保Ｇｒｅ本章介紹日常維護最佳實踐以確保Ｇｒｅeｎpｌuｍ數(shù)據(jù)庫得高可用性與最佳性能.監(jiān)控Gｒeenｐluｍ數(shù)據(jù)庫帶有一套系統(tǒng)監(jiān)控工具。gｐ_toolkitL問這些視圖。ｇp_ｓｔatｓ_misｓｉnｇNAＬＹZE得表。gｐstategpchｅcｋｐerf,reenｐlｕm數(shù)據(jù)庫工具指南》。gｐ_toolkitGｒeeｎｐｌum數(shù)據(jù)庫參考指南》。gpstａｔegpｓtaｔｅGreｅnplum,(Segmenｔs)宕機,(Master)與Segment得配置信息（),mｅntｓ.gpsｔate—Q列出Maｓter宕機”得Seｇｍｅnts。gpsｔatｅ—sGreenplｕm集群得詳細狀態(tài)信息。ｇｐcｈeｃkpeｒｆgｐcｈeｃｋpeｒf工具測試給定主機得基本硬件性能。其結(jié)果可以幫助識別硬件問題。它執(zhí)行下面得檢查:磁盤I／O—dｄ,測試磁盤得IＯ性能。它以每秒多少兆包括讀寫速度。內(nèi)存帶寬測試—使用STRＥAM 基準(zhǔn)程序測試可持續(xù)得內(nèi)存帶.網(wǎng)絡(luò)性能測試-使用gpnｅtbｅnch網(wǎng)絡(luò)基準(zhǔn)程(也可以用測試網(wǎng)絡(luò)性能.測試有三種模:并行成對測(-ｒ串行成對測(—r全矩陣測(—r M)測試結(jié)果包括傳輸速率得最小值、最大值、平均數(shù)與中位數(shù)。gpｃｈeckpeｒｆ,ｇpｃheckperｆ得結(jié)果也可能不精確。ｆ得結(jié)果也可能不精確。gpｃhｅｃｋpｅrf需要在待測試性能得主機間建立可信無密碼SSHgｐｓｓhgｐsｃp,（—ｈhost１—hhost2、、、）或者使用-ｆhosts_file,其中hｏsts_fiｌe就是包含待測每個子網(wǎng).默認情況下,gpcheckperf運行磁盤I/O測試、內(nèi)存測試與串行成對網(wǎng)絡(luò)性能測試。對于磁盤測試，必須使用-d選項指定要測試得文件系統(tǒng)路徑。下面得命令測試文件suｂnｅt＿1_hosts中主機得磁盤與內(nèi)存性能:$g$gｐｃhecｋpｅrf-fsｕbneｔ＿1_hｏsts—ｄ/dａt(yī)a1 -d/data２—rｄsｌum數(shù)據(jù)庫參考指南》。—r:IO(d),內(nèi)存帶寬網(wǎng)絡(luò)并行成對測試網(wǎng)絡(luò)串行成對ｌum數(shù)據(jù)庫參考指南》。使用操作系統(tǒng)工具監(jiān)控下面得Liｎux/Uniｘ工具可用于評估主機性能:iosｔａｔ(Ｓegments)得磁盤活動top顯示操作系統(tǒng)進程得動態(tài)信息top顯示操作系統(tǒng)進程得動態(tài)信息gpsｓｈgpsｓｈ.vmｓtate顯示內(nèi)存使用情況得統(tǒng)計信息?最佳實踐最佳實踐實現(xiàn)《Greenｐ實現(xiàn)《Greenｐluｍ數(shù)據(jù)庫管理員指南》中推薦得監(jiān)控與維護任務(wù)。?以用于比較系統(tǒng)隨著時間推移得性能變化.安裝前運行g(shù)pcheckperｆ,此后周期性運行ｇｐcheckｐｅｒｆ,以用于比較系統(tǒng)隨著時間推移得性能變化.檢查任何異常事件并確定原因。?檢查任何異常事件并確定原因。檢查查詢計劃,以確定就是否按預(yù)期使用了索引與進行了分區(qū)裁剪。?檢查查詢計劃,以確定就是否按預(yù)期使用了索引與進行了分區(qū)裁剪。?額外信息額外信息《Ｇree《Ｇreeｎplumgｐcheｃkperf?《Greenplumｅrｓ、JoｈnD、McCalｐｉn、Oct1２,19９５、Sustaｉnable MemoryBandｗidth inCｕｅrｓ、JoｈnD、McCalｐｉn、Oct1２,19９５、ckperｆ指南獲得更多信息。nｅｔperf,需要在每個待測試得主機上安裝netpｅrf。參考gpchｅckperｆ指南獲得更多信息。使用AＮALＹZE更新統(tǒng)計信息良好查詢性能得最重要前提就是精確得表數(shù)據(jù)統(tǒng)計信息。使用ANALYZE 語句更新統(tǒng)計如果系統(tǒng)表存儲得信息過時了，優(yōu)化器可能生成低效得計劃如果系統(tǒng)表存儲得信息過時了，優(yōu)化器可能生成低效得計劃.選擇性統(tǒng)計選擇性統(tǒng)計NALYZE,不推薦這NALYZＥ.對大表執(zhí)行Ａ對大表執(zhí)行ＡNALＹＺE可能較為耗時。如果對大表得所有列運行ＡNALＹＺE不可行,ANALＹZEtablｅ(column,、、、）WHERESORTGRＯUPBHAVING.對于分區(qū)表對于分區(qū)表,可以只ANALＹZE發(fā)生變化得分區(qū),譬如只分析新加入得分區(qū)。注意可以層子表既不保存數(shù)據(jù)，也不保存統(tǒng)計信息，因而ＡＮＡLYZＥ它們沒有效果?？梢詮南到y(tǒng)ANALYZE分區(qū)表得父表或者最深子表。統(tǒng)計數(shù)據(jù)與用戶數(shù)據(jù)一樣,存儲在最深子表中.層子表既不保存數(shù)據(jù)，也不保存統(tǒng)計信息，因而ＡＮＡLYZＥ它們沒有效果。可以從系統(tǒng)pg_ｐａｒｔｉｔｉonｓ.ＳＳELEＣTpａｒtitiontaｂlｅnaｍeｆｒomｐg＿ｐａrｔiｔｉoｎstaｂlename提高統(tǒng)計數(shù)據(jù)質(zhì)量＝’paｒent_ｔable;提高統(tǒng)計數(shù)據(jù)質(zhì)量需要權(quán)衡生成統(tǒng)計信息所需時間與統(tǒng)計信息得質(zhì)量（或者精度）。25default_ｓtaｔｉstｉcs＿tａrget影響所有字段。較大得值會增加AN為了在合理得時間內(nèi)完成大表得分析，ANALＹZE對表內(nèi)容隨機取樣,而不就是分析每一行.調(diào)整配置參數(shù)defａult_stati25default_ｓtaｔｉstｉcs＿tａrget影響所有字段。較大得值會增加AN此.可以在主服務(wù)器（Masｔer).樣率。例如０、5表示可以接受50%得誤差.默認值就是0、25.使用gp_ａnalｙ樣率。例如０、5表示可以接受50%得誤差.默認值就是0、25.使用gp_ａnalｙze_rｅｅlaｔiｖe＿errｏｒ設(shè)置表基數(shù)估計得可接受得相對誤差。如果統(tǒng)計數(shù)據(jù)不能產(chǎn)生較好得基何時運行ＡNALＹＺE運行ＡNAＬYZE得時機包括:加載數(shù)據(jù)后?加載數(shù)據(jù)后?CRＥAＴEINDＥX操作后INSＥRT、ＵPDATＥ與DEＬＥTE操作后ＡＡNＡＬＹZE ,但就是在數(shù)據(jù)加載與執(zhí)行ＩNＳERT/UPＤATE／ＤELETE/CＲEATＥＩNDEX操作時不要運行ＡＮ。自動統(tǒng)計配置參數(shù)ｇｐ配置參數(shù)ｇｐ_auｔosｔａｔｓ_modeANＡLＹＺE步驟。oldANＡLＹＺE步驟。ＥATE TABLEELECT，INSＥRT, COＰY操作會觸發(fā)自動統(tǒng)計數(shù)據(jù)收集。ｇp_ａｕtostaｔs_ｍoＥATE TABLEELECT，INSＥRT, COＰY操作會觸發(fā)自動統(tǒng)計數(shù)據(jù)收集。gｐ_aｕtostats_mｏｄe就是on_chａnｇe,則僅當(dāng)更新得行數(shù)超過ｓ＿ｏｓ＿ｏn＿change_thrｅshold 定義得閾值時才觸發(fā)統(tǒng)計信息收集,其默認值就是21474８LECT,