Referens till systemtabell för frågehistorik

Den här artikeln innehåller information om systemtabellen för frågehistorik, inklusive en disposition av tabellens schema.

Tabellsökväg: Den här systemtabellen finns på system.query.history.

Skivtillgänglighet

Register är vanligtvis tillgängliga inom en timme. Dataleverans för nya arbetsytor kan ta längre tid än så.

När frågehistoriktabellen använder kundhanterade nycklar gäller inte denna tillgänglighet. Se Läsa krypterade fält.

Använda frågehistoriktabellen

Frågehistoriktabellen innehåller poster för frågor som utförs med SQL-lager eller serverlös beräkning för notebooks och uppgifter. Tabellen innehåller kontoomfattande poster från alla arbetsytor i samma region som du kommer åt tabellen från.

Som standard har endast administratörer åtkomst till systemtabellen. Om du vill dela tabellens data med en användare eller grupp rekommenderar Databricks att du skapar en dynamisk vy för varje användare eller grupp. Se Skapa en dynamisk vy.

Systemtabellschema för frågehistorik

Tabellen för frågehistorik använder följande schema:

Åtkomst till maskerad satstext

SQL-uttalanden kan innehålla känslig information såsom kundnamn, e-postadresser eller annan personligt identifierbar information (PII). Fältet statement_text returnerar <REDACTED> som standard. Kontoadministratörer och medlemmar i databricks_pii_access gruppen kan läsa hela frågetexten.

För att skapa gruppen och hantera dess medlemskap och behörigheter, se Skapa och hantera databricks_pii_access gruppen.

Felsök överlappande kolumnmasker

Om du redan har applicerat en kolumnmask på statement_text, till exempel med en attributbaserad åtkomstkontrollpolicy (ABAC), kan frågor mot system.query.history misslyckas med COLUMN_MASKS_FEATURE_NOT_SUPPORTED.MULTIPLE_MASKS. Endast en kolumnmask kan tillämpas på en kolumn för en given användare.

För att lösa konflikten måste du vara metastore-administratör eller ha en MANAGE på bordet. Använd regler för flera filter och masker för att identifiera överlappande policyer, och begränsa eller ta sedan bort din mask på statement_text.

Läsa krypterade fält

När arbetsytor använder kundhanterade nycklar för hanterade tjänster krypteras fälten statement_text och error_message i systemtabellen som standard. Det beror på att systemtabeller lagrar data från och kan nås av alla arbetsytor i regionen. Kontoadministratörer måste lägga till en nyckelkonfiguration i system själva katalogen för att dekryptera och visa krypterade systemtabellfält. Du måste ha MANAGE behörighet i system katalogen för att utföra den här åtgärden.

När frågehistoriktabellen använder kundhanterade nycklar gäller inte den typiska posttillgängligheten i Record-tillgänglighet .

Du kan antingen skapa en ny nyckel eller återanvända en befintlig. Kör följande kommando med hjälp av det fullständiga nyckel-ID:t:

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"
        }
      }
}'

Tillåt upp till 24 timmar för system.query.history att börja visa de krypterade fälten.

Visa frågeprofilen för en post

Om du vill navigera till en frågas frågeprofil baserat på en post i frågehistoriktabellen gör du följande:

1. Identifiera intresseposten och kopiera sedan postens statement_id.
2. Hänvisa till dokumentets workspace_id för att försäkra dig om att du är inloggad på samma arbetsyta som dokumentet.
3. Klicka på Frågehistorik i arbetsytans sidofält.
4. I fältet Uttalande-ID klistrar du in statement_id i posten.
5. Klicka på namnet på en fråga. En översikt över frågemått visas.
6. Klicka på Se frågeprofil.

Förstå query_source kolumn

Kolumnen query_source innehåller en uppsättning unika identifierare för de Azure Databricks-entiteter som ingår i utförandet av instruktionen.

query_source Om kolumnen innehåller flera ID:er innebär det att instruktionskörningen utlöstes av flera entiteter. Ett jobbresultat kan till exempel utlösa en avisering som anropar en SQL-fråga. I det här exemplet fylls alla tre ID:na i i query_source. Värdena i den här kolumnen sorteras inte efter körningsordning.

Möjliga frågekällor är:

• alert_id: Instruktion som utlöses från en avisering
• sql_query_id: Instruktion som körs inifrån den här SQL-redigeringssessionen
• dashboard_id: Instruktionen körs från en instrumentpanel
• genie_space_id: Instruktion som körs från en Genie-agent
• notebook_id: Instruktion som körs från en notebook
• job_info.job_id: Uttalande körs inom ett jobb
• job_info.job_run_id: Instruktionen körs från en jobbkörning
• job_info.job_task_run_id: Instruktionen körs inom en jobbaktivitetskörning

Giltiga kombinationer av query_source

Följande exempel visar hur query_source kolumnen fylls i beroende på hur frågan körs:

• Frågor som utförs under en jobbprocess innehåller en ifylld job_info struct.

  {
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
}

• Förfrågningar från aviseringar inkluderar en sql_query_id och 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
}

• Förfrågningar från instrumentpaneler inkluderar en dashboard_id, men ingen 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
}