本文會檢閱加快 pg_dump 和 pg_restore 的選項和最佳做法。 其也說明執行 pg_restore 的最佳伺服器設定。
pg_dump 的最佳做法
您可以使用 pg_dump 公用程式，將適用於 PostgreSQL 的 Azure 資料庫彈性伺服器資料庫擷取至指令檔或封存盤案。 下列各節列出幾個您可以使用的命令列選項，透過使用 pg_dump 來縮短整體傾印時間。
目錄格式(-Fd)
此選項會輸出您可以輸入至 pg_restore 的目錄格式封存。 根據預設，輸出會經過壓縮。
平行作業(-j)
您可以透過 pg_dump，使用平行作業選項同時執行傾印作業。 此選項可縮短傾印總時間，但也會增加資料庫伺服器的負載。 建議您在密切監視來源伺服器計量之後到達平行作業值，例如 CPU、記憶體和 IOPS (每秒輸入/輸出作業) 使用量。
當您設定平行作業選項的值時，pg_dump 需要下列條件：
- 連線數目必須等於平行作業數目 +1，因此請務必據以設定
max_connections值。 - 平行作業數目應該小於或等於為資料庫伺服器配置的 vCPU 數目。
壓縮(-Z0)
此選項會指定要使用的壓縮層級。 零表示沒有壓縮。 在 pg_dump 程序期間，零壓縮有助於提升效能。
資料表膨脹和清理
開始 pg_dump 程序之前，請考慮是否需要清理資料表。 資料表上的膨脹會大幅提高 pg_dump 次數。 執行下列查詢來找出資料表膨脹：
select schemaname,relname,n_dead_tup,n_live_tup,round(n_dead_tup::float/n_live_tup::float*100) dead_pct,autovacuum_count,last_vacuum,last_autovacuum,last_autoanalyze,last_analyze from pg_stat_all_tables where n_live_tup >0;
相較於即時元組，此查詢中的 dead_pct 資料行是無效元組的百分比。 資料表的 dead_pct 值很高可能表示資料表未正確清理。 如需詳細資訊，請參閱適用於 PostgreSQL 的 Azure 資料庫彈性伺服器中的自動資料清理微調。
針對您找出的每個資料表，您可以執行下列動作來執行手動清理分析：
vacuum(analyze, verbose) <table_name>
使用 PITR 伺服器
您可以在線上或即時伺服器上執行 pg_dump。 即使資料庫正在使用中，其還是會進行一致的備份。 資料庫不會防止其他使用者使用資料庫。 開始 pg_dump 程序之前，請先考量資料庫大小和其他業務或客戶需求。 小型資料庫可能是在生產伺服器上執行 pg_dump 的良好候選項目。
對於大型資料庫，您可以從生產伺服器建立時間點復原 (PITR) 伺服器，並在 PITR 伺服器上執行 pg_dump 程序。 在 PITR 上執行 pg_dump 是極非經常性存取執行程序。 這種方法的取捨在於，您不需擔心在實際生產伺服器上執行之 pg_dump 程序所帶來的額外 CPU、記憶體和 IO 使用率。 您可以在 PITR 伺服器上執行 pg_dump，然後在完成 pg_dump 程序之後卸除 PITR 伺服器。
建議的伺服器大小
當您在網路頻寬較高時觀察到 pg_dump 效能變慢，請考慮使用較高的 vCore SKU。 較高的 vCore SKU 通常會提供額外的 CPU 和網路輸送量，這可以減少整體匯出時間。 監控 CPU、網路和 IOPS 指標，以確認頻寬或運算是否是瓶頸，再擴展。
參數調整
調整下列伺服器參數，以協助在還原作業期間加速建立索引。 pg_dump存檔通常包含索引建立命令（例如，CREATE INDEX 或 ALTER TABLE ...添加約束）;改善索引建置效能可以縮短移轉時間總計：
-
maintenance_work_mem= 2097151 （2 GB） — 增加此值，以配置更多記憶體用於索引建立和其他維護工作。 對於大型索引，請考慮提高此設定 （例如，數百 MB 到數 GB），並在非生產執行個體上驗證記憶體使用量，然後再將其套用到生產環境中。 -
max_parallel_maintenance_workers= 4 — 增加此值，以允許在多虛擬核心伺服器上建立平行索引。 將此設定相對於虛擬核心數目，並進行測試，以判斷工作負載的最佳層級。
在非生產或 PITR 伺服器上測試任何參數或 SKU 變更。 驗證效能和穩定性，然後將變更套用至生產環境。 移轉或大型還原完成後，將參數還原為符合一般工作負載需求的值。
pg_dump 語法
使用下列 pg_dump 語法：
pg_dump -h <hostname> -U <username> -d <databasename> -Fd -j <Num of parallel jobs> -Z0 -f sampledb_dir_format
您可以使用 pg_restore 公用程式，從 pg_dump 所建立的封存中還原適用於 PostgreSQL 的 Azure 資料庫彈性伺服器資料庫。 下列各節列出一些縮短整體還原時間的命令列選項。
平行還原
藉由使用多個並行作業，您可以縮短在多個虛擬核心目標伺服器上還原大型資料庫所需的時間。 作業數目可以等於或小於為目標伺服器配置的 vCPU 數目。
伺服器參數
如果您要將資料還原至新的伺服器或非生產伺服器，您可以在執行pg_restore之前最佳化下列伺服器參數：
work_mem = 32 MB
max_wal_size = 65536 （64 GB）
checkpoint_timeout = 3600 #60分鐘
maintenance_work_mem = 2097151 （2 GB）
autovacuum = 關閉
wal_compression = 開啟
還原完成後，請確定系統會根據工作負載需求適當地更新這些參數。
附註
只有在記憶體和磁碟空間充足的情況，才遵循上述建議。 如果您的小型伺服器具有 2、4 或 8 個虛擬核心，請據以設定參數。
其他考量
- 在執行pg_restore之前停用高可用性（HA）。
- 分析還原完成後所移轉的所有資料表。
pg_restore 語法
使用下列 pg_restore 語法：
pg_restore -h <hostname> -U <username> -d <db name> -Fd -j <NUM> -C <dump directory>
-
-Fd：目錄格式。 -
-j：作業數目。 -
-C：使用建立資料庫本身的命令開始輸出，然後重新連線至其中。
以下是此語法顯示方式的範例：
pg_restore -h <hostname> -U <username> -j <Num of parallel jobs> -Fd -C -d <databasename> sampledb_dir_format
虛擬機器考量
在相同的區域和可用性區域中建立虛擬機器，最好是目標和來源伺服器所在的位置。 或者，至少建立與來源伺服器或目標伺服器更接近的虛擬機器。 建議您搭配高效能本地 SSD 使用 Azure 虛擬機器。
如需 SKU 的詳細資訊，請參閱：
範例
以下是如何使用pg_dumppg_restore並遵循上述最佳實踐的一些示例。
搭配目錄格式與平行作業使用 pg_dump
pg_dump -h <server>.postgres.database.azure.com -U <username> -d <database> \
-Fd -j 4 -f /backups/mydb_dump_dir
解釋：
-
-Fd：以目錄格式匯出，此格式是進行平行還原所必需的。 -
-j 4：使用 4 個平行作業來加速傾印。 -
-f：指定輸出目錄。
使用pg_dump 不進行壓縮以提升效能
pg_dump -h <server>.postgres.database.azure.com -U <username> -d <database> \
-F c -Z 0 -f /backups/mydb_nocompress.dump
解釋：
-
-F c：自訂格式。 -
-Z 0：停用壓縮以提高效能。
搭配平行 obs 使用 pg_restore
pg_restore -h <server>.postgres.database.azure.com -U <username> -d <target_database> \
-Fd -j 4 /backups/mydb_dump_dir
解釋：
-
-Fd：符合匯出中使用的目錄格式。 -
-j 4：使用 4 個平行作業來加速還原。