下列案例概述 Oracle 至 Azure Postgres 移轉期間遇到的一些潛在挑戰。 在規劃和執行您自己的移轉時，建議的解決方案有助於克服這些挑戰。
案例： 在相同的資料庫上獨立探索到兩個不同的低延遲、高輸送量、用戶端應用程式。 每個應用程式無意中將另一個快取的查詢從緩衝區中凸起。 共用負載及合併資源爭用造成資料庫共用緩衝區排清過於頻繁的情況，導致兩個系統的效能降低。
建議的解決方案： 請確定您的初始評估會擷取資料庫平台環境的所有層面，包括系統全域區域 （SGA） 和程式全域區域 （PGA） 記憶體結構的記憶體耗用量和使用率模式。 選取符合資源需求的適當計算系列，並確定您的Postgres計畫容量會視需要進行調整。
提示
pg_buffercache 延伸模組提供檢查使用率的方法，並可讓您即時觀察共用緩衝區快取中發生的情況。
緩衝區快取命中率
檢查命中率可讓您評估快取有效性，並判斷共用緩衝區大小是否合適。 良好的快取命中率是表示大部分的數據要求都是從記憶體而非磁碟提供，以提供最佳效能：
SELECT COUNT(*) AS total
, SUM(CASE WHEN isdirty THEN 1 ELSE 0 END) AS dirty -- # of buffers out of sync with disk
, SUM(CASE WHEN isdirty THEN 0 ELSE 1 END) AS clean -- # of buffers in sync with data on disk
FROM pg_buffercache;
最常存取的數據表和索引
檢查最常存取的數據表和索引，以及/或佔用緩衝區快取中最多空間有助於識別記憶體中快取的熱點：
SELECT b.relfilenode, relname, relblocknumber
, relkind
--r = ordinary table, i = index, S = sequence, t = TOAST table
--, v = view, m = materialized view, c = composite type
--, f = foreign table, p = partitioned table, I = partitioned index
, COUNT(*) AS buffers
FROM pg_buffercache b
JOIN pg_class c ON c.oid = b.relfilenode
GROUP BY b.relfilenode, relname, relblocknumber, relkind
ORDER BY buffers DESC
LIMIT 10;
緩衝區快取爭用
緩衝區快取中的重大爭用表示多個查詢可能會針對相同的緩衝區空間而戰，而導致效能瓶頸。 檢查緩衝區存取的位置和頻率有助於診斷這類問題：
SELECT c.relname, b.relblocknumber, COUNT(*) AS access_count
FROM pg_buffercache b
JOIN pg_class c ON c.relfilenode = b.relfilenode
GROUP BY c.relname, b.relblocknumber
ORDER BY access_count DESC
LIMIT 10;
案例： 移轉工作是在Postgres平台發行週期的和跨版本之間起始的。 儘管最新版本提供新功能和改進功能，但在移轉開始時選取的版本仍保持不變。 後續新增的工作、時間和費用，是在初始移轉之後升級Postgres資料庫版本，以達到最佳效能和新功能。
建議的解決方案： 盡可能優先在移轉時採用最新版本的 Postgres。 Postgres 社群開發小組非常努力地將每一點效能和穩定性擠到每個新版本中，而阻礙基本上意味著將效能留在邊線。 此外，請充分利用新的 Azure 功能。 新的 Azure Postgres 功能包括：SSDv2 記憶體、最新的伺服器系列基礎結構，以及自動化索引微調和自發伺服器參數微調功能。
劇本： 第一次遷移到 Postgres 的組織在識別執行緩慢的查詢時可能不熟悉最佳實務和方法。 在適當實作新的索引類型時，應特別小心和注意。 值得注意的是，Postgres 資料庫引擎的設計目的是要優化查詢效能，而不需要或能夠指定查詢提示。
建議的解決方案： 延伸模組是Postgres如此強大不可或缺的一部分。 有數個延伸模組可提供重要功能，讓您確保資料庫在尖峰效能上運作。 要考慮的一些主要延伸模組包括：
auto_explain： 自動記錄執行超過設定臨界值之查詢的執行計劃。 可讓資料庫管理員診斷效能問題並優化查詢效能，而不需在每個查詢上手動執行 EXPLAIN。
pg_trgm： 提供函式和運算符，以便透過三格比對來判斷文字型數據的相似度。 此延伸模組適用於涉及文字搜尋、模糊比對和相似性查詢的工作。 結合文字數據行上的 GIN 或 GIST 索引，可改善 LIKE 查詢和相似性搜尋的效能。
pg_cron： 允許直接在資料庫內排程和管理定期工作。 將類似 cron 的工作排程整合到 Postgres 中，讓例行維護工作、數據處理和類似的重複作業自動化。
提示
如果您的資料庫操作涉及大量重複建立和刪除資料庫對象，則較舊的pg_catalog系統表元組將會增加，從而導致表「膨脹」。 由於pg_catalog是涉及許多資料庫作業的系統數據表，因此此數據表上的未明確維護可能會導致整個資料庫的效能降低。 藉由設定週期性pg_cron排程，確保pg_catalog能充分維護並適當地進行清理。
- pg_hint_plan： Postgres 旨在提供一致且可靠的效能，而不需要手動介入，導致刻意的設計決策不包含查詢提示。 對於某些需要特定且精確控制查詢計劃設計的情況，pg_hint_plan 提供一種方法，使用內嵌在 SQL 註解中的提示來影響查詢規劃器的決策。 這些提示可讓資料庫管理員引導查詢規劃器選擇特定計劃，以最佳化複雜的查詢或解決規劃器可能無法自行處理的效能問題。
注意
這些範例只是劃破了Postgres資料庫可用的一組令人難以置信的龐大延伸模組表面。 我們鼓勵您完整探索這些延伸模組，以增加 Postgres 資料庫的功能。 此外，您也可以考慮撰寫自己的延伸模組的可能性，您可以在其中看到將Postgres擴充至其目前功能的可能性。 強大的彈性擴充架構可確保Postgres一律能夠隨著您的平臺需求進行調整和演進。
案例： 在某些情況下，舊版數據表分割策略導致建立數千個數據分割。 雖然這在先前使用時可能很有效，但在某些情況下，這些策略可能會降低 Postgres 中的查詢效能。 在非常特定的實例中，查詢規劃器在剖析查詢時可能無法判斷適當的分割區索引鍵。 產生的行為會產生延伸的規劃時間，並導致查詢規劃花費的時間超過實際的查詢執行時間。
建議的解決方案： 重新評估產生過多數據分割之數據分割策略的需求。 Postgres 資料庫引擎可能不再需要相同的資料分割，減少分割區數目可能會改善效能。 如果評估了舊版數據分割配置並判斷為必要，請考慮將您的查詢重組為離散作業，先識別並擷取動態分割區索引鍵，然後接著在查詢作業中使用分割區索引鍵。
劇本： 有時候，外部相依性和環境情況可能需要混合式資料庫案例，其中 Oracle 和 Azure Postgres 資料庫需要共存。 例如，在某些情況下，可能需要分階段移轉，才能直接從 Azure Postgres 存取和查詢 Oracle 資料，而不需要匯入資料或修改複雜 ETL 程式的額外負荷。 在其他情況下，藉由同時比較 Oracle 和 Azure Postgres 環境中的對等數據集來執行平行數據驗證，有助於在移轉期間和/或期間確保數據一致性和完整性。
建議的解決方案： PostgreSQL 外部數據包裝函式 （FDW） 延伸模組是一項重要的 Postgres 功能，可讓您存取和操作儲存在外部系統中的數據，就像該數據原生位於 Azure Postgres 資料庫中一樣。 FDW 可讓 Azure Postgres 成為同盟資料庫，允許與任意數目的外部數據源整合，包括 Oracle 資料庫。 FDW 會在 Postgres 資料庫中建立外部資料表定義，而這些外部數據表會作為您定義的外部數據源的 Proxy，讓使用者使用一般 SQL 查詢來查詢這些外部數據表。 在內部，Postgres 引擎會使用外部 FDW 定義來與遠端數據源隨選通訊及協調數據。
oracle_fdw： （Oracle 的外國數據包裝函式）是 Postgres 延伸模組，可讓您從 Azure Postgres 中存取 Oracle 資料庫。 從 Oracle 移轉至 Azure Postgres 時，oracle_fdw可提供數據存取、數據驗證、累加移轉和實時數據同步處理，以發揮關鍵作用。 請務必記住使用 FDW 時的下列重要考慮：
- 透過 oracle_fdw執行查詢，會在處理數據並從遠端 Oracle 伺服器擷取數據時，以網路通訊和驗證交涉的形式產生額外負荷
- 某些資料類型可能需要特殊處理或轉換，以確保資料類型在系統之間正確對應。
有效地使用oracle_fdw有助於簡化資料庫轉換，並藉由讓應用程式和數據在整個整體移轉過程中保持可存取性，以確保數據可存取性。