追蹤活動

  • 11 分鐘

大多數的維護資料庫是效能微調。 您在內部部署資料庫上用來檢閱的相同記錄檔，仍可透過適用於 MySQL/PostgreSQL 的 Azure 資料庫取得。

當您的資料庫遷移至 Azure 時，您需要繼續檢閱記錄檔，以確保維護資料庫的效能。

在此單元中，您會看到 PostgreSQL 和 MySQL 的記錄檔儲存在 Azure 中的位置，及其所包含的詳細資料層級。

使用伺服器記錄來追蹤資料庫活動

適用於 MySQL/PostgreSQL 的 Azure 資料庫也會在伺服器記錄中記錄診斷資訊。 伺服器記錄是 MySQL 和 PostgreSQL 的原生訊息記錄檔 (不是交易記錄檔，適用於 MySQL/PostgreSQL 的 Azure 資料庫無法存取這些檔案)。 這些檔案包含訊息、伺服器狀態，以及您用來偵測資料庫問題的其他錯誤資訊。 伺服器記錄最多保留七天 (如果伺服器記錄檔的大小總計超過 7 GB，則會保留少於七天)。

適用於 MySQL 的 Azure 資料庫和適用於 PostgreSQL 的 Azure 資料庫會在伺服器記錄檔中記錄不同的詳細資料。 下列各節分別描述每個服務的伺服器記錄。

適用於 MySQL 的 Azure 資料庫中的伺服器記錄

在適用於 MySQL 的 Azure 資料庫中，伺服器記錄提供在 MySQL 伺服器上的 慢速查詢記錄 和 稽核記錄 中通常可用的資訊。

您可以使用慢速查詢記錄中的資訊來協助識別執行緩慢的查詢。 依預設，會停用慢速查詢記錄。 您可以藉由將 slow_query_log 伺服器參數設為 ON，以啟用該記錄。 您可以使用下列伺服器參數來設定慢速查詢記錄，以判斷 慢速查詢 所代表的意義：

  • log_queries_not_using_indexes。 此參數是 ON 或 OFF。 將其設為 ON，以記錄可能執行完整資料表掃描的所有查詢，而非索引查詢。
  • log_throttle_queries_not_using_indexes。 指定每分鐘可記錄之不使用索引的慢速查詢數量上限。
  • log_slow_admin_queries。 將此參數設為 ON，以在記錄中包含慢速執行的管理查詢。
  • long_query_time。 查詢視為 慢速執行 的閾值 (以秒為單位)。

當您啟用慢速查詢記錄和稽核記錄之後，記錄檔會開始出現在伺服器的 [伺服器記錄] 頁面中。 每天都會建立新的慢速查詢記錄。 按一下記錄檔以進行下載：

Image of the Server logs page for Azure Database for MySQL.

若要啟用稽核記錄，請將 audit_log_enabled 伺服器參數設為 ON。 您可以使用下列參數來設定稽核記錄：

  • audit_log_events。 指定要稽核的事件。 在 Azure 入口網站中，此參數會提供事件的下拉式清單，例如 CONNECTION、DDL、DML、ADMIN 和其他事件。
  • audit_log_exclude_users。 此參數是以逗號分隔的使用者清單，這些使用者的活動不會包含在稽核記錄中。

如果您需要將慢速查詢記錄和稽核記錄保留超過七天，可安排它們傳輸至 Azure 儲存體。 為您的伺服器使用 [診斷設定] 頁面，然後選取 [+ 新增診斷設定]。 在 [診斷設定] 頁面中，選取 [封存至儲存體帳戶]，選取要儲存記錄檔的儲存體帳戶 (此儲存體帳戶必須已存在)，選取 MySqlSlowLogs 和 MySqlAuditLogs，並指定最多 365 天的保留期間。 您可以在這段期間的任何時候從 Azure 儲存體下載記錄檔。 選取 [儲存]：

Image of the Diagnostic settings page for Azure Database for MySQL.

慢速查詢記錄資料會以 JSON 格式寫入至名為 insights-logs-mysqlslowlogs 之容器中的 Blob。 最多可能需要 10 分鐘的時間，記錄檔才會出現在 Azure 儲存體中。 稽核記錄會以 JSON 格式儲存在 insights-logs-mysqlslowlogs Blob 容器中。

適用於 PostgreSQL 的 Azure 資料庫中的伺服器記錄

在適用於 PostgreSQL 的 Azure 資料庫中，伺服器記錄包含錯誤記錄檔和查詢記錄檔。 使用這些檔案中的資訊可協助找出任何錯誤的來源，以及無效查詢。

您可以藉由將各種 log_ 伺服器設定參數設為 ON，以啟用記錄。 這些參數包括：

  • log_checkpoints。 每當各資料檔案皆使用交易記錄中的最新資訊更新時，就會發生檢查點。 如果伺服器失敗，此檢查點會標示從交易記錄向前復原需要開始的時間。
  • log_connection 和 log_disconnections。 這些設定會記錄每個成功的連線，以及每個工作階段的結束。
  • log_duration。 此設定會導致記錄每個已完成 SQL 陳述式的持續時間。
  • log_lock_waits。 此設定會導致記錄鎖定等候事件。 鎖定等候可能是因為應用程式程式碼中的交易執行不力所造成。
  • log_statement_stats。 此設定會將伺服器效能的累計資訊寫入記錄。

適用於 PostgreSQL 的 Azure 資料庫也會提供進一步的參數，以微調記錄的資訊：

  • log_error_verbosity。 此設定會指定每個已記錄訊息所記錄的詳細資料層級。
  • log_retention_days 這是伺服器將每個記錄檔移除之前保留的天數。 預設值為三天，最多可以設定為七天。
  • log_min_messages 和 log_min_error_statement。 使用這些參數來指定錄製陳述式的警告和錯誤層級。

如同適用於 MySQL 的 Azure 資料庫，適用於 PostgreSQL 的 Azure 資料庫所產生的記錄檔可在 [伺服器記錄檔] 的頁面上取得。 您也可以使用 [診斷設定] 頁面，將記錄複製到 Azure 儲存體。

追蹤查詢效能

查詢存放區是 Azure 所提供的另一項功能，可協助您找出並追蹤效能不佳的查詢。 您可以搭配適用於 PostgreSQL 的 Azure 資料庫和適用於 MySQL 的 Azure 資料庫一起使用。

啟用查詢效能追蹤

查詢存放區會在適用於 MySQL 的 Azure 資料庫的 MySQL 架構中，以及適用於 PostgreSQL 的 Azure 資料庫中名為 azure_sys 的資料庫中記錄資訊。 查詢存放區可以擷取兩種類型的資訊：查詢執行的相關資料，以及等待統計資料的相關資訊。 預設會停用查詢存放區。 若要啟用該功能：

  • 如果您是使用適用於 MySQL 的 Azure 資料庫，請將伺服器參數 query_store_capture_mode 和 query_store_wait_sampling_capture_mode 設定為 [全部]
  • 如果您使用適用於 PostgreSQL 的 Azure 資料庫，請將伺服器參數 pg_qs. query_capture_mode 設定為 [全部] 或 [頂端] ，然後將 pgms_wait_sampling. query_capture_mode 參數設定為 [全部] 。

分析查詢效能資料

查詢存放區所使用的資料表可以直接查詢。 如果您正在執行適用於 MySQL 的 Azure 資料庫，請連線到您的伺服器，然後執行下列查詢：

SELECT * FROM mysql.query_store;

SELECT * FROM mysql.query_store_wait_stats;

如果您是使用適用於 PostgreSQL 的 Azure 資料庫，請改為執行下列查詢：

SELECT * FROM query_store.qs_view;

SELECT * FROM query_store.pgms_wait_sampling_view;

在這兩種情況下，第一個查詢會顯示每個最近執行之查詢的文字，以及許多關於查詢花費多少時間編譯和執行的統計資料。 第二個查詢會顯示等候事件的相關資訊。 當某個查詢無法執行時，就會產生等候事件，因為它需要其他查詢使用的資源。

如果直接查看查詢存放區，您可以產生自己的自訂報表，並深入瞭解系統的運作方式。 不過，可用的資料量可能會讓您難以掌握狀況。 適用於 MySQL/PostgreSQL 的 Azure 資料庫提供兩個額外的工具，可協助您瀏覽此資料-查詢效能深入解析和 查詢建議。

查詢效能深入解析 是圖形化公用程式，可從您伺服器的 [查詢效能深入解析] 頁面取得。 [長時間執行查詢] 索引標籤會顯示最長時間執行之查詢的統計資料。 您可以指定時間週期，並且將週期放大至幾分鐘以內。 圖例會顯示每個查詢的文字，以及查詢所執行的持續時間和次數。 圖形會提供每個查詢持續時間的比較。 您可以依照每個查詢的平均時間來查看資料，但它也會顯示每個查詢的總時間 (持續時間 * 執行計數)。 下圖為範例：

Image of the Query Performance Insight page for Azure Database for PostgreSQL, showing the Long running queries tab.

[等候統計資料] 索引標籤會顯示每個查詢的等候事件資訊。 您將會看到查詢等候各種資源所花費的時間量。

Image of the Query Performance Insight page for Azure Database for PostgreSQL, showing the Wait statistics tab.

等候事件通常分為三個類別：

  • 鎖定等候。 如果查詢嘗試讀取或修改其他查詢所鎖定的資料，就會產生這些事件。 如果您遇到大量鎖定等候，請檢查長時間執行的交易，或使用極為嚴格交易隔離等級的作業。
  • I/O 等候。 如果查詢正在執行大量 I/O，就會產生這種等候類型。 這可能是因為設計不佳的查詢 (檢查 WHERE 子句)、無效率的聯結作業，或是因為遺漏索引而產生的完整資料表掃描。
  • 記憶體等候。 如果記憶體不足，無法處理查詢，就會產生記憶體等候。 您的查詢可能嘗試讀取大量資料，或其他查詢佔用了記憶體而導致封鎖查詢。 同樣地，這可能表示索引遺失，而導致查詢將整個資料表讀取到記憶體中。

不同形式的等候很可能會相互影響，因此您無法以隔離方式檢查這些問題。 例如，在不同資料表中讀取和更新資料的交易可能會受限於記憶體等候。 因此，此交易可能會有鎖定的資料，而導致另一個交易產生鎖定等候。

伺服器的 [效能建議] 頁面會取得保留在查詢存放區中的資訊，並使用該資訊來提出建議，以針對所遇到的工作負載微調您的資料庫。