查詢記錄系統數據表參考

本文包含查詢記錄系統數據表的相關信息，包括數據表架構的大綱。

資料表路徑：此系統資料表位於 system.query.history。

紀錄可用性

紀錄通常一小時內可取得。 新工作空間的資料傳輸可能比這更久。

當查詢歷史表使用客戶管理的金鑰時，此可用性不適用。 參見 「讀取加密欄位」。

使用查詢記錄數據表

查詢歷史表包含使用 SQL 倉庫執行的查詢紀錄、筆記本與作業的無伺服器計算，以及使用 serverless 或經典運算的 Lakeflow 管線。 這個表格包含了你帳戶中所有與你用來存取該工作區相同區域的工作區記錄。

根據預設，只有系統管理員可以存取系統數據表。 如果您想要與使用者或群組共用數據表的數據，Databricks 建議為每個使用者或群組建立動態檢視。 請參閱建立動態檢視。

查詢記錄系統數據表架構

查詢歷程記錄資料表會使用下列架構：

存取遮罩語句文字

SQL 語句可能包含敏感資訊，如客戶姓名、電子郵件地址或其他個人識別資訊（PII）。 statement_text該欄位預設會回傳<REDACTED>。 帳號管理員及群組成員 databricks_pii_access 可閱讀完整的查詢文字。

要建立群組並管理其成員資格與權限，請參閱 「建立與管理 databricks_pii_access 群組」。

排解重疊欄位遮罩問題

例如，如果你已經對 套用欄位遮罩statement_text，例如使用屬性基礎存取控制（ABAC）政策，對 system.query.history 的查詢可能會失敗。COLUMN_MASKS_FEATURE_NOT_SUPPORTED.MULTIPLE_MASKS 同一使用者只能套用一個欄位遮罩。

要解決衝突，你必須是元商店管理員或有 MANAGE 相關討論。 使用衝突過濾器和遮罩來辨識重疊的政策，然後縮小範圍或移除遮罩。statement_text

讀取加密欄位

當工作空間使用 客戶管理的金鑰來管理服務時， statement_text 系統資料表中的 and error_message 欄位預設是加密的。 這是因為系統資料表會儲存區域內所有工作區的資料，且可存取。 要解密並顯示加密的系統表格欄位，帳號管理員必須在 system 目錄本身新增金鑰設定。 你必須擁有 MANAGE 在 system 目錄上的許可才能執行此操作。

當查詢歷史資料表使用客戶管理的金鑰時，典型的紀錄可用性不適用於紀錄 可用性 。

你可以建立 一個新的金鑰 ，或是重複使用現有的金鑰。 使用完整金鑰 ID，執行以下指令：

curl -v -X PATCH https://my-workspace-url/api/2.1/unity-catalog/catalogs/system -H 'Authorization: Bearer <pat token>' --data '{
"managed_encryption_settings": {
        "azure_key_vault_key_id": "https://my-key-vault.vault.azure.net/keys/my-key-name/my-key-version",
        "azure_encryption_settings": {
          "azure_tenant_id": "my-tenant-id"
        }
      }
}'

允許啟用時間最多可達24小時。 啟用完成後， system.query.history 開始顯示所有新紀錄的加密欄位。 啟用前建立的紀錄無法解密。

檢視記錄的查詢概要

若要根據查詢歷史表中的某個記錄導航至查詢設定檔，請執行下列動作：

1. 辨識感興趣的記錄，然後複製記錄的 statement_id。
2. 參考記錄的 workspace_id ，以確保您已登入與記錄相同的工作區。
3. 按一下圖示。在工作區側邊欄中查詢歷程記錄。
4. 在［陳述式 ID］欄位中，將記錄中的 貼上。
5. 按一下查詢的名稱。 查詢計量的概觀隨即出現。
6. 按一下查看查詢設定檔。

了解掃描指標

查詢歷史表包含掃描過程中收集的多項指標。 你可以從表格的欄位計算以下額外指標：

• table_bytes：掃描資料表中檔案的總壓縮大小（以位元組計）。 計算為 pruned_files_bytes + read_files_bytes。
• table_files：掃描資料表中檔案總數。 計算為 read_files + pruned_files。

瞭解 query_source 欄

query_source列包含一組在語句執行中涉及的Azure Databricks實體的唯一識別碼。

如果數據 query_source 行包含多個標識碼，表示語句執行是由多個實體觸發。 例如，作業結果可能會觸發呼叫 SQL 查詢的警示。 在此範例中，這三個識別碼都會填入query_source內。 此數據行的值不會依執行順序排序。

可能的查詢來源如下：

• alert_id：從警示觸發的語句
• sql_query_id：從這個 SQL 編輯器 會話內執行的語句
• dashboard_id：從儀錶板執行的語句
• genie_space_id：精靈特工執行的陳述
• notebook_id：從筆記本執行的語句
• job_info.job_id：在作業內執行的語句
• job_info.job_run_id：從作業執行執行的語句
• job_info.job_task_run_id：在作業工作執行內執行的語句

有效的查詢來源組合

下列範例示範如何 query_source 根據查詢的執行方式填入數據行：

• 作業執行期間執行的查詢包括填入 job_info 的結構體：

  {
alert_id: null,
sql_query_id: null,
dashboard_id: null,
notebook_id: null,
job_info: {
job_id: 64361233243479,
job_run_id: null,
job_task_run_id: 110378410199121
},
legacy_dashboard_id: null,
genie_space_id: null
}

• 警示查詢包括 sql_query_id 與 ： alert_id

  {
alert_id: e906c0c6-2bcc-473a-a5d7-f18b2aee6e34,
sql_query_id: 7336ab80-1a3d-46d4-9c79-e27c45ce9a15,
dashboard_id: null,
notebook_id: null,
job_info: null,
legacy_dashboard_id: null,
genie_space_id: null
}

• 來自儀錶板的查詢包括 dashboard_id，但沒有 job_info：

  {
alert_id: null,
sql_query_id: null,
dashboard_id: 887406461287882,
notebook_id: null,
job_info: null,
legacy_dashboard_id: null,
genie_space_id: null
}