Risolvere i problemi relativi al pool SQL serverless in Azure Synapse Analytics

  • Articolo

Questo articolo contiene informazioni su come risolvere i problemi più frequenti con il pool SQL serverless in Azure Synapse Analytics.

Per altre informazioni su Azure Synapse Analytics, vedere Panoramica e Novità di Azure Synapse Analytics.

Synapse Studio

Synapse Studio è uno strumento facile da usare per accedere ai dati usando un browser senza dover installare gli strumenti di accesso al database. Synapse Studio non è progettato per leggere un set di dati di grandi dimensioni o una gestione completa degli oggetti SQL.

L'opzione relativa al pool SQL serverless è disattivata in Synapse Studio

Se Synapse Studio non riesce a stabilire una connessione al pool SQL serverless, si noterà che il pool SQL serverless è disattivato o mostra lo stato Offline.

In genere, questo problema si verifica per uno dei due motivi seguenti:

  • La rete impedisce la comunicazione con il back-end di Azure Synapse Analytics. Il caso più frequente è che la porta TCP 1443 è bloccata. Per ottenere il funzionamento del pool SQL serverless, sbloccare questa porta. Altri problemi potrebbero impedire il funzionamento del pool SQL serverless. Per altre informazioni, vedere la guida alla risoluzione dei problemi.
  • Non si dispone dell'autorizzazione per accedere al pool SQL serverless. Per ottenere l'accesso, un amministratore dell'area di lavoro di Azure Synapse deve aggiungere l'utente al ruolo di amministratore dell'area di lavoro o al ruolo di amministratore SQL. Per altre informazioni, vedere Controllo di accesso di Azure Synapse.

Connessione Websocket chiusa in modo imprevisto

La query potrebbe non riuscire con il messaggio Websocket connection was closed unexpectedly. di errore Questo messaggio indica che la connessione del browser a Synapse Studio è stata interrotta, ad esempio a causa di un problema di rete.

  • Per risolvere questo problema, eseguire di nuovo la query.
  • Provare Azure Data Studio o SQL Server Management Studio per le stesse query anziché Synapse Studio per ulteriori indagini.
  • Se questo messaggio si verifica spesso nell'ambiente, ottenere assistenza dall'amministratore di rete. È anche possibile controllare le impostazioni del firewall e consultare la guida alla risoluzione dei problemi.
  • Se il problema persiste, creare un ticket di supporto tramite il portale di Azure.

I database serverless non vengono visualizzati in Synapse Studio

Se non vengono visualizzati i database creati nel pool SQL serverless, verificare se il pool SQL serverless è stato avviato. Se il pool SQL serverless è disattivato, i database non verranno visualizzati. Eseguire qualsiasi query, ad esempio , SELECT 1nel pool SQL serverless per attivarla e visualizzare i database.

Il pool SQL synapse Serverless non è disponibile

La configurazione di rete non corretta è spesso la causa di questo comportamento. Assicurarsi che le porte siano configurate correttamente. Se si usa un firewall o endpoint privati, controllare anche queste impostazioni.

Infine, assicurarsi che i ruoli appropriati vengano concessi e non siano stati revocati.

Impossibile creare un nuovo database perché la richiesta userà la chiave precedente/scaduta

Questo errore è causato dalla modifica della chiave gestita dal cliente dell'area di lavoro usata per la crittografia. È possibile scegliere di crittografare di nuovo tutti i dati nell'area di lavoro con la versione più recente della chiave attiva. Per crittografare di nuovo, modificare la chiave nel portale di Azure in una chiave temporanea e quindi tornare alla chiave che si vuole usare per la crittografia. Informazioni su come gestire le chiavi dell'area di lavoro.

Synapse serverless pool SQL non è disponibile dopo il trasferimento di una sottoscrizione a un tenant Microsoft Entra diverso

Se è stata spostata una sottoscrizione in un altro tenant di Microsoft Entra, potrebbero verificarsi alcuni problemi con il pool SQL serverless. Creare un ticket di supporto e supporto tecnico di Azure verrà contattato per risolvere il problema.

Archiviazione l'accesso

Se si verificano errori durante il tentativo di accesso ai file in Archiviazione di Azure, assicurarsi di disporre dell'autorizzazione per accedere ai dati. Dovrebbe essere possibile accedere ai file disponibili pubblicamente. Se si tenta di accedere ai dati senza credenziali, assicurarsi che l'identità di Microsoft Entra possa accedere direttamente ai file.

Se si dispone di una chiave di firma di accesso condiviso da usare per accedere ai file, assicurarsi di aver creato una credenziale a livello di server o con ambito database contenente tale credenziale. Le credenziali sono necessarie se è necessario accedere ai dati usando l'identità gestita dell'area di lavoro e il nome dell'entità servizio (SPN) personalizzati.

Non è possibile leggere, elencare o accedere ai file in Azure Data Lake Archiviazione

Se si usa un account di accesso di Microsoft Entra senza credenziali esplicite, assicurarsi che l'identità di Microsoft Entra possa accedere ai file nella risorsa di archiviazione. Per accedere ai file, l'identità di Microsoft Entra deve avere l'autorizzazione Lettore dati BLOB o le autorizzazioni per elencare e leggere gli elenchi di controllo di accesso (ACL) in ADLS. Per altre informazioni, vedere Query non riuscita perché non è possibile aprire il file.

Se si accede all'archiviazione usando le credenziali, assicurarsi che l'identità gestita o il nome SPN disponga del ruolo Lettore dati o Collaboratore o di autorizzazioni ACL specifiche. Se è stato usato un token di firma di accesso condiviso, assicurarsi che disponga rl dell'autorizzazione e che non sia scaduto.

Se si usa un account di accesso SQL e la OPENROWSET funzione senza un'origine dati, assicurarsi di disporre di credenziali a livello di server corrispondenti all'URI di archiviazione e di disporre dell'autorizzazione per accedere all'archiviazione.

La query non riesce perché non è possibile aprire il file

Se la query non riesce con l'errore File cannot be opened because it does not exist or it is used by another process e si è certi che entrambi i file esistano e non vengano usati da un altro processo, il pool SQL serverless non può accedere al file. Questo problema si verifica in genere perché l'identità di Microsoft Entra non dispone dei diritti di accesso al file o perché un firewall blocca l'accesso al file.

Per impostazione predefinita, il pool SQL serverless tenta di accedere al file usando l'identità Microsoft Entra. Per risolvere questo problema, è necessario disporre dei diritti appropriati per accedere al file. Il modo più semplice consiste nel concedere a se stessi un ruolo collaboratore ai dati BLOB Archiviazione nell'account di archiviazione su cui si sta tentando di eseguire una query.

Per altre informazioni, vedi:

Alternativa al ruolo Collaboratore dati di archiviazione BLOB

Invece di concedere a se stessi un ruolo di collaboratore ai dati BLOB Archiviazione, è anche possibile concedere autorizzazioni più granulari per un subset di file.

Tutti gli utenti che devono accedere ad alcuni dati in questo contenitore, devono disporre anche dell'autorizzazione EXECUTE per tutte le cartelle padre fino alla radice (il contenitore).

Altre informazioni su come impostare elenchi di controllo di accesso in Azure Data Lake Storage Gen2.

Nota

L'autorizzazione di esecuzione a livello di contenitore deve essere impostata all'interno di Azure Data Lake Archiviazione Gen2. Le autorizzazioni per la cartella possono essere impostate in Azure Synapse.

Se si desidera eseguire una query data2.csv, come in questo esempio, sono necessarie le autorizzazioni seguenti:

  • Autorizzazione di esecuzione per il contenitore
  • Autorizzazione di esecuzione per folder1
  • Autorizzazione di lettura per data2.csv

Diagramma che mostra la struttura delle autorizzazioni nel data lake.

  1. Accedere ad Azure Synapse con un utente amministratore che abbia le autorizzazioni complete per i dati ai quali si vuole accedere.

  2. Nel riquadro dei dati fare clic con il pulsante destro del mouse sul file e scegliere Gestisci accesso.

    Screenshot che mostra l'opzione gestisci l'accesso.

  3. Selezionare almeno l'autorizzazione Lettura. Immettere l'UPN o l'ID oggetto dell'utente, ad esempio, user@contoso.com. Selezionare Aggiungi.

  4. Concedere l'autorizzazione di lettura per questo utente.

    Screenshot che mostra la concessione di autorizzazioni di lettura.

Nota

Per gli utenti guest, questo passaggio deve essere eseguito direttamente con Azure Data Lake perché non può essere eseguito direttamente tramite Azure Synapse.

Il contenuto della directory nel percorso non può essere elencato

Questo errore indica che l'utente che esegue query su Azure Data Lake non può elencare i file nell'archiviazione. Esistono diversi scenari in cui questo errore può verificarsi:

  • L'utente di Microsoft Entra che usa l'autenticazione pass-through di Microsoft Entra non dispone dell'autorizzazione per elencare i file in Data Lake Archiviazione.
  • L'ID o l'utente SQL di Microsoft Entra che legge i dati usando una chiave di firma di accesso condiviso o un'identità gestita dell'area di lavoro e tale chiave o identità non dispone dell'autorizzazione per elencare i file nella risorsa di archiviazione.
  • L'utente che accede ai dati di Dataverse che non dispone dell'autorizzazione per eseguire query sui dati in Dataverse. Questo scenario può verificarsi se si usano utenti SQL.
  • L'utente che accede a Delta Lake potrebbe non avere l'autorizzazione per leggere il log delle transazioni Delta Lake.

Il modo più semplice per risolvere questo problema consiste nel concedere a se stessi il ruolo collaboratore ai dati BLOB Archiviazione nell'account di archiviazione su cui si sta tentando di eseguire una query.

Per altre informazioni, vedi:

Il contenuto della tabella Dataverse non può essere elencato

Se si usa l'Collegamento a Synapse di Azure per Dataverse per leggere le tabelle DataVerse collegate, è necessario usare l'account Microsoft Entra per accedere ai dati collegati usando il pool SQL serverless. Per altre informazioni, vedere Azure Collegamento a Synapse per Dataverse con Azure Data Lake.

Se si tenta di usare un account di accesso SQL per leggere una tabella esterna che fa riferimento alla tabella DataVerse, verrà visualizzato l'errore seguente: External table '???' is not accessible because content of directory cannot be listed.

Le tabelle esterne di Dataverse usano sempre l'autenticazione pass-through di Microsoft Entra. Non è possibile configurarli in modo da usare una chiave di firma di accesso condiviso o un'identità gestita dell'area di lavoro.

Non è possibile elencare il contenuto del log delle transazioni Delta Lake

Quando il pool SQL serverless non riesce a leggere la cartella del log delle transazioni Delta Lake, viene restituito l'errore seguente:

Content of directory on path 'https://.....core.windows.net/.../_delta_log/*.json' cannot be listed.

Assicurarsi che la _delta_log cartella esista. È possibile eseguire query su file Parquet semplici che non vengono convertiti in formato Delta Lake. Se la _delta_log cartella esiste, assicurarsi di disporre dell'autorizzazione Lettura ed Elenco per le cartelle Delta Lake sottostanti. Provare a leggere i file JSON direttamente usando FORMAT='csv'. Inserire l'URI nel parametro BULK:

select top 10 *
from openrowset(BULK 'https://.....core.windows.net/.../_delta_log/*.json',FORMAT='csv', FIELDQUOTE = '0x0b', FIELDTERMINATOR ='0x0b',ROWTERMINATOR = '0x0b')  
with (line varchar(max)) as logs

Se la query non riesce, il chiamante non dispone dell'autorizzazione per leggere i file di archiviazione sottostanti.

Esecuzione della query

È possibile che si verifichino errori durante l'esecuzione della query nei casi seguenti:

La query non riesce perché non può essere eseguita a causa di vincoli di risorse correnti

La query potrebbe non riuscire con il messaggio This query cannot be executed due to current resource constraints. di errore Questo messaggio indica che il pool SQL serverless non può essere eseguito in questo momento. Ecco alcune opzioni di risoluzione dei problemi:

Timeout query scaduto

L'errore Query timeout expired viene restituito se la query è stata eseguita più di 30 minuti nel pool SQL serverless. Questo limite per il pool SQL serverless non può essere modificato.

  • Provare a ottimizzare la query applicando le procedure consigliate.
  • Provare a materializzare parti delle query usando la creazione di una tabella esterna come selezione (CETAS).
  • Controllare se è presente un carico di lavoro simultaneo in esecuzione nel pool SQL serverless perché le altre query potrebbero accettare le risorse. In tal caso, è possibile suddividere il carico di lavoro in più aree di lavoro.

Nome oggetto non valido

L'errore Invalid object name 'table name' indica che si sta usando un oggetto, ad esempio una tabella o una vista, che non esiste nel database del pool SQL serverless. Provare queste opzioni:

  • Elencare le tabelle o le viste e verificare se l'oggetto esiste. Usare SQL Server Management Studio o Azure Data Studio perché Synapse Studio potrebbe mostrare alcune tabelle non disponibili nel pool SQL serverless.

  • Se viene visualizzato l'oggetto , verificare di usare alcune regole di confronto del database con distinzione tra maiuscole e minuscole/binarie. È possibile che il nome dell'oggetto non corrisponda al nome usato nella query. Con le regole Employee di confronto di un database binario e employee sono due oggetti diversi.

  • Se l'oggetto non viene visualizzato, è possibile che si stia tentando di eseguire query su una tabella da un database Lake o Spark. La tabella potrebbe non essere disponibile nel pool SQL serverless perché:

    • La tabella include alcuni tipi di colonna che non possono essere rappresentati nel pool SQL serverless.
    • La tabella ha un formato non supportato nel pool SQL serverless. Gli esempi sono Avro o ORC.

I dati stringa o binari verrebbero troncati

Questo errore si verifica se la lunghezza del tipo di colonna stringa o binaria (ad esempio VARCHAR, VARBINARYo NVARCHAR) è più breve rispetto alle dimensioni effettive dei dati letti. È possibile correggere questo errore aumentando la lunghezza del tipo di colonna:

  • Se la colonna stringa è definita come VARCHAR(32) tipo e il testo è di 60 caratteri, usare il VARCHAR(60) tipo (o più lungo) nello schema della colonna.
  • Se si usa l'inferenza dello schema (senza lo WITH schema), tutte le colonne stringa vengono definite automaticamente come VARCHAR(8000) tipo. Se si riceve questo errore, definire in modo esplicito lo schema in una WITH clausola con il tipo di colonna più grande VARCHAR(MAX) per risolvere l'errore.
  • Se la tabella si trova nel database Lake, provare ad aumentare le dimensioni delle colonne di stringa nel pool di Spark.
  • Provare a SET ANSI_WARNINGS OFF abilitare il pool SQL serverless per troncare automaticamente i valori VARCHAR, se ciò non influirà sulle funzionalità.

Virgolette non chiuse dopo la stringa di caratteri

In rari casi, in cui si usa l'operatore LIKE in una colonna stringa o in un confronto con i valori letterali stringa, è possibile che venga visualizzato l'errore seguente:

Unclosed quotation mark after the character string

Questo errore può verificarsi se si usano le Latin1_General_100_BIN2_UTF8 regole di confronto nella colonna . Provare a impostare Latin1_General_100_CI_AS_SC_UTF8 le regole di confronto sulla colonna anziché sulle Latin1_General_100_BIN2_UTF8 regole di confronto per risolvere il problema. Se l'errore viene ancora restituito, generare una richiesta di supporto tramite il portale di Azure.

Impossibile allocare spazio tempdb durante il trasferimento dei dati da una distribuzione a un'altra

L'errore Could not allocate tempdb space while transferring data from one distribution to another viene restituito quando il motore di esecuzione delle query non può elaborare i dati e trasferirli tra i nodi che eseguono la query. Si tratta di un caso speciale della query generica non riuscita perché non può essere eseguita a causa di un errore di vincoli di risorse correnti. Questo errore viene restituito quando le risorse allocate al tempdb database non sono sufficienti per eseguire la query.

Applicare le procedure consigliate prima di inviare un ticket di supporto.

La query ha esito negativo con una gestione degli errori di un file esterno (numero massimo di errori raggiunto)

Se la query ha esito negativo con il messaggio error handling external file: Max errors count reacheddi errore , significa che esiste una mancata corrispondenza di un tipo di colonna specificato e i dati che devono essere caricati.

Per ottenere altre informazioni sull'errore e sulle righe e le colonne da esaminare, modificare la versione del parser da 2.0 a 1.0.

Esempio

Se si vuole eseguire una query sul file names.csv con questa query 1, il pool SQL serverless di Azure Synapse restituisce l'errore seguente: Ad esempio: Error handling external file: 'Max error count reached'. File/External table name: [filepath].

Il file names.csv contiene:

Id,first name,  
1, Adam
2,Bob
3,Charles
4,David
5,Eva

Query 1:

SELECT
    TOP 100 *
FROM
    OPENROWSET(
        BULK '[FILE-PATH OF CSV FILE]',
        FORMAT = 'CSV',
        PARSER_VERSION='2.0',
       FIELDTERMINATOR =';',
       FIRSTROW = 2
    )  
    WITH (
    [ID] SMALLINT,  
    [Text] VARCHAR (1) COLLATE Latin1_General_BIN2  
)

    AS [result]

Causa

Non appena la versione del parser viene modificata dalla versione 2.0 alla 1.0, i messaggi di errore consentono di identificare il problema. Il nuovo messaggio di errore è ora Bulk load data conversion error (truncation) for row 1, column 2 (Text) in data file [filepath].

Il troncamento indica che il tipo di colonna è troppo piccolo per adattare i dati. Il nome più lungo in questo names.csv file ha sette caratteri. Il tipo di dati da usare deve essere almeno VARCHAR(7). L'errore è causato da questa riga di codice:

    [Text] VARCHAR (1) COLLATE Latin1_General_BIN2

La modifica della query risolve di conseguenza l'errore. Dopo il debug, modificare nuovamente la versione del parser su 2.0 per ottenere prestazioni massime.

Per altre informazioni su quando usare la versione del parser, vedere Usare OPENROW edizione Standard T usando il pool SQL serverless in Synapse Analytics.

SELECT
    TOP 100 *
FROM
    OPENROWSET(
        BULK '[FILE-PATH OF CSV FILE]',
        FORMAT = 'CSV',
        PARSER_VERSION='2.0',
        FIELDTERMINATOR =';',
        FIRSTROW = 2
    )  
    WITH (
    [ID] SMALLINT,  
    [Text] VARCHAR (7) COLLATE Latin1_General_BIN2  
)

    AS [result]

Non è possibile eseguire il caricamento bulk perché non è stato possibile aprire il file

L'errore Cannot bulk load because the file could not be opened viene restituito se un file viene modificato durante l'esecuzione della query. In genere, è possibile che venga visualizzato un errore come Cannot bulk load because the file {file path} could not be opened. Operating system error code 12. (The access code is invalid.)

I pool SQL serverless non possono leggere i file che vengono modificati durante l'esecuzione della query. La query non può accettare un blocco sui file. Se si sa che l'operazione di modifica è aggiunta, è possibile provare a impostare l'opzione seguente: {"READ_OPTIONS":["ALLOW_INCONSISTENT_READS"]}.

Per altre informazioni, vedere come eseguire query su file di sola accodamento o creare tabelle in file di sola accodamento.

La query ha esito negativo e viene restituito un errore di conversione dei dati

La query potrebbe non riuscire con il messaggio Bulk load data conversion error (type mismatches or invalid character for the specified code page) for row n, column m [columnname] in the data file [filepath]. di errore Questo messaggio indica che i tipi di dati non corrispondono ai dati effettivi per il numero di riga n e la colonna m.

Ad esempio, se si prevedono solo numeri interi nei dati, ma nella riga n è presente una stringa, questo messaggio di errore è quello che si otterrà.

Per risolvere il problema, esaminare il file e i tipi di dati scelti. Controllare anche se le impostazioni del delimitatore di riga e del carattere di terminazione del campo sono corrette. Nell'esempio seguente viene illustrato come eseguire l'ispezione usando VARCHAR come tipo di colonna.

Per altre informazioni sui caratteri di terminazione dei campi, sui delimitatori di riga e sui caratteri di virgolette di escape, vedere Eseguire query su file CSV.

Esempio

Se si vuole eseguire una query sul file names.csv:

Id, first name,  
1,Adam
2,Bob
3,Charles
4,David
five,Eva

Con la query seguente:

Query 1:

SELECT
    TOP 100 *
FROM
    OPENROWSET(
        BULK '[FILE-PATH OF CSV FILE]',
        FORMAT = 'CSV',
        PARSER_VERSION='1.0',
       FIELDTERMINATOR =',',
       FIRSTROW = 2
    )  
    WITH (
    [ID] SMALLINT,  
    [Firstname] VARCHAR (25) COLLATE Latin1_General_BIN2  
)

    AS [result]

Il pool SQL serverless di Azure Synapse restituisce l'errore Bulk load data conversion error (type mismatch or invalid character for the specified code page) for row 6, column 1 (ID) in data file [filepath].

È necessario esplorare i dati e prendere una decisione informata per gestire questo problema. Per esaminare i dati che causano questo problema, è necessario prima modificare il tipo di dati. Anziché eseguire query sulla colonna ID con il tipo di dati SMALLINT, VARCHAR(100) viene ora usato per analizzare questo problema.

Con questa query leggermente modificata, i dati possono ora essere elaborati per restituire l'elenco dei nomi.

Query 2:

SELECT
    TOP 100 *
FROM
    OPENROWSET(
        BULK '[FILE-PATH OF CSV FILE]',
        FORMAT = 'CSV',
        PARSER_VERSION='1.0',
       FIELDTERMINATOR =',',
       FIRSTROW = 2
    )  
    WITH (
    [ID] VARCHAR(100),  
    [Firstname] VARCHAR (25) COLLATE Latin1_General_BIN2  
)

    AS [result]

È possibile osservare che i dati hanno valori imprevisti per ID nella quinta riga. In tali circostanze, è importante allinearsi al proprietario aziendale dei dati per accettare il modo in cui è possibile evitare dati danneggiati come questo esempio. Se la prevenzione non è possibile a livello di applicazione, VARCHAR di dimensioni ragionevoli potrebbe essere l'unica opzione disponibile qui.

Suggerimento

Provare a rendere VARCHAR() il più breve possibile. Evitare VARCHAR(MAX) se possibile perché può compromettere le prestazioni.

Il risultato della query non è simile al previsto

La query potrebbe non riuscire, ma si potrebbe notare che il set di risultati non è come previsto. È possibile che le colonne risultanti siano vuote o che vengano restituiti dati imprevisti. In questo scenario è probabile che sia stato scelto erroneamente un delimitatore di riga o un terminatore di campo.

Per risolvere questo problema, esaminare i dati e modificare tali impostazioni. Il debug di questa query è semplice, come illustrato nell'esempio seguente.

Esempio

Se si vuole eseguire una query sul file names.csv con la query in Query 1, il pool SQL serverless di Azure Synapse restituisce un risultato dispari:

In names.csv:

Id,first name,  
1, Adam
2, Bob
3, Charles
4, David
5, Eva

SELECT
    TOP 100 *
FROM
    OPENROWSET(
        BULK '[FILE-PATH OF CSV FILE]',
        FORMAT = 'CSV',
        PARSER_VERSION='1.0',
       FIELDTERMINATOR =';',
       FIRSTROW = 2
    )  
    WITH (
    [ID] VARCHAR(100),  
    [Firstname] VARCHAR (25) COLLATE Latin1_General_BIN2  
)

    AS [result]

| ID            |   Firstname   |  
| ------------- |-------------  |  
| 1,Adam        | NULL |  
| 2,Bob         | NULL |  
| 3,Charles     | NULL |  
| 4,David       | NULL |  
| 5,Eva         | NULL |

Non esiste alcun valore nella colonna Firstname. Tutti i valori si trovano invece nella ID colonna . Tali valori sono separati da una virgola. Il problema è stato causato da questa riga di codice perché è necessario scegliere la virgola anziché il simbolo di punto e virgola come carattere di terminazione del campo:

FIELDTERMINATOR =';',

La modifica di questo singolo carattere risolve il problema:

FIELDTERMINATOR =',',

Il set di risultati creato dalla query 2 è ora simile al previsto:

Query 2:

SELECT
    TOP 100 *
FROM
    OPENROWSET(
        BULK '[FILE-PATH OF CSV FILE]',
        FORMAT = 'CSV',
        PARSER_VERSION='1.0',
       FIELDTERMINATOR =',',
       FIRSTROW = 2
    )  
    WITH (
    [ID] VARCHAR(100),  
    [Firstname] VARCHAR (25) COLLATE Latin1_General_BIN2  
)

    AS [result]

Restituisce:

| ID            | Firstname   |  
| ------------- |-------------  |  
| 1             | Adam |  
| 2             | Bob |  
| 3             | Charles |  
| 4             | David |  
| 5             | Eva |

La colonna di tipo non è compatibile con il tipo di dati esterno

Se la query non riesce e viene visualizzato il messaggio Column [column-name] of type [type-name] is not compatible with external data type […], di errore, è probabile che sia stato eseguito il mapping di un tipo di dati PARQUET a un tipo di dati SQL non corretto.

Ad esempio, se il file Parquet ha un prezzo di colonna con numeri float (ad esempio 12,89) e si è tentato di eseguirne il mapping a INT, questo messaggio di errore è quello che si otterrà.

Per risolvere questo problema, esaminare il file e i tipi di dati scelti. Questa tabella di mapping consente di scegliere un tipo di dati SQL corretto. Come procedura consigliata, specificare il mapping solo per le colonne che altrimenti verrebbero risolte nel tipo di dati VARCHAR. Evitare VARCHAR quando possibile comporta prestazioni migliori nelle query.

Esempio

Se si vuole eseguire una query sul file taxi-data.parquet con questa query 1, il pool SQL serverless di Azure Synapse restituisce l'errore seguente:

Il file taxi-data.parquet contiene:

|PassengerCount |SumTripDistance|AvgTripDistance |
|---------------|---------------|----------------|
| 1 | 2635668.66000064 | 6.72731710678951 |
| 2 | 172174.330000005 | 2.97915543404919 |
| 3 | 296384.390000011 | 2.8991352022851  |
| 4 | 12544348.58999806| 6.30581582240281 |
| 5 | 13091570.2799993 | 111.065989028627 |

Query 1:

SELECT
    *
FROM
    OPENROWSET(
        BULK '<filepath>taxi-data.parquet',
        FORMAT='PARQUET'
    )  WITh
        (
        PassengerCount INT,  
        SumTripDistance INT,  
        AVGTripDistance FLOAT
        )

    AS [result]

Column 'SumTripDistance' of type 'INT' is not compatible with external data type 'Parquet physical type: DOUBLE', please try with 'FLOAT'. File/External table name: '<filepath>taxi-data.parquet'.

Questo messaggio di errore indica che i tipi di dati non sono compatibili e viene fornito con il suggerimento di usare FLOAT anziché INT. L'errore è causato da questa riga di codice:

SumTripDistance INT,

Con questa query leggermente modificata, è ora possibile elaborare i dati e visualizzare tutte e tre le colonne:

Query 2:

SELECT
    *
FROM
    OPENROWSET(
        BULK '<filepath>taxi-data.parquet',
        FORMAT='PARQUET'
    )  WITh
        (
        PassengerCount INT,  
        SumTripDistance FLOAT,  
        AVGTripDistance FLOAT
        )

    AS [result]

La query fa riferimento a un oggetto non supportato in modalità di elaborazione distribuita

L'errore The query references an object that is not supported in distributed processing mode indica che è stato usato un oggetto o una funzione che non può essere usata durante l'esecuzione di query sui dati in Archiviazione di Azure o nell'archiviazione analitica di Azure Cosmos DB.

Alcuni oggetti, ad esempio le viste di sistema e le funzioni, non possono essere usati mentre si eseguono query sui dati archiviati in Azure Data Lake o nell'archiviazione analitica di Azure Cosmos DB. Evitare di usare le query che aggiungono dati esterni con viste di sistema, caricare dati esterni in una tabella temporanea o usare alcune funzioni di sicurezza o metadati per filtrare i dati esterni.

Chiamata WaitIOCompletion non riuscita

Il messaggio WaitIOCompletion call failed di errore indica che la query non è riuscita durante l'attesa di completare l'operazione di I/O che legge i dati dall'archiviazione remota, Azure Data Lake.

Il messaggio di errore ha il modello seguente: Error handling external file: 'WaitIOCompletion call failed. HRESULT = ???'. File/External table name...

Assicurarsi che l'archiviazione sia posizionata nella stessa area del pool SQL serverless. Controllare le metriche di archiviazione e verificare che non siano presenti altri carichi di lavoro nel livello di archiviazione, ad esempio il caricamento di nuovi file, che potrebbero saturare le richieste di I/O.

Il campo HRESULT contiene il codice del risultato. I codici di errore seguenti sono i più comuni insieme alle possibili soluzioni.

Questo codice di errore indica che il file di origine non è in archiviazione.

Esistono motivi per cui questo codice di errore può verificarsi:

  • Il file è stato eliminato da un'altra applicazione.
    • In questo scenario comune, viene avviata l'esecuzione della query, vengono enumerati i file e vengono trovati i file. Successivamente, durante l'esecuzione della query, viene eliminato un file. Ad esempio, potrebbe essere eliminato da Databricks, Spark o Azure Data Factory. La query non riesce perché il file non viene trovato.
  • Questo problema può verificarsi anche con il formato Delta. La query potrebbe avere esito positivo dopo un nuovo tentativo perché è presente una nuova versione della tabella e il file eliminato non viene nuovamente sottoposto a query.
  • Un piano di esecuzione non valido viene memorizzato nella cache.
    • Come mitigazione temporanea, eseguire il comando DBCC FREEPROCCACHE. Se il problema persiste, creare un ticket di supporto.

Sintassi errata vicino a NOT

L'errore Incorrect syntax near 'NOT' indica che sono presenti alcune tabelle esterne con colonne che contengono il vincolo NOT NULL nella definizione di colonna.

  • Aggiornare la tabella per rimuovere NOT NULL dalla definizione di colonna.
  • Questo errore può talvolta verificarsi anche temporaneamente con le tabelle create da un'istruzione CETAS. Se il problema non viene risolto, è possibile provare a eliminare e creare nuovamente la tabella esterna.

La colonna di partizione restituisce valori NULL

Se la query restituisce valori NULL anziché colonne di partizionamento o non riesce a trovare le colonne di partizione, sono disponibili alcuni passaggi possibili per la risoluzione dei problemi:

  • Se si usano tabelle per eseguire query su un set di dati partizionato, tenere presente che le tabelle non supportano il partizionamento. Sostituire la tabella con le viste partizionate.
  • Se si usano le viste partizionate con OPENROW edizione Standard T che esegue query sui file partizionati usando la funzione FILEPATH(), assicurarsi di aver specificato correttamente il criterio con caratteri jolly nel percorso e di usare l'indice appropriato per fare riferimento al carattere jolly.
  • Se si eseguono query sui file direttamente nella cartella partizionata, tenere presente che le colonne di partizionamento non sono le parti delle colonne di file. I valori di partizionamento vengono inseriti nei percorsi delle cartelle e non nei file. Per questo motivo, i file non contengono i valori di partizionamento.

Valore di inserimento in batch per il tipo di colonna DATETIME2 non riuscito

L'errore Inserting value to batch for column type DATETIME2 failed indica che il pool serverless non è in grado di leggere i valori di data dai file sottostanti. Il valore datetime archiviato nel file Parquet o Delta Lake non può essere rappresentato come DATETIME2 colonna.

Esaminare il valore minimo nel file usando Spark e verificare che alcune date siano inferiori a 0001-01-03. Se i file sono stati archiviati usando la versione spark 2.4 (versione di runtime non supportata) o con la versione spark successiva che usa ancora il formato di archiviazione datetime legacy, i valori datetime prima vengono scritti usando il calendario julian non allineato al calendario gregoriano proleptico usato nei pool SQL serverless.

Potrebbe esserci una differenza di due giorni tra il calendario julian usato per scrivere i valori in Parquet (in alcune versioni di Spark) e il calendario gregoriano proleptico usato nel pool SQL serverless. Questa differenza può causare la conversione in un valore di data negativo, che non è valido.

Provare a usare Spark per aggiornare questi valori perché vengono considerati come valori di data non validi in SQL. L'esempio seguente illustra come aggiornare i valori non compresi negli intervalli di date SQL a NULL in Delta Lake:

from delta.tables import *
from pyspark.sql.functions import *

deltaTable = DeltaTable.forPath(spark,  
             "abfss://my-container@myaccount.dfs.core.windows.net/delta-lake-data-set")
deltaTable.update(col("MyDateTimeColumn") < '0001-02-02', { "MyDateTimeColumn": null } )

Questa modifica rimuove i valori che non possono essere rappresentati. Gli altri valori di data potrebbero essere caricati correttamente, ma non correttamente rappresentati perché esiste ancora una differenza tra i calendari gregoriani julian e proleptici. È possibile che vengano visualizzati turni di data imprevisti anche per le date precedenti 1900-01-01 se si usa Spark 3.0 o versioni precedenti.

Prendere in considerazione la migrazione a Spark 3.1 o versione successiva e passare al calendario gregoriano proleptico. Le versioni più recenti di Spark usano per impostazione predefinita un calendario gregoriano proleptico allineato al calendario nel pool SQL serverless. Ricaricare i dati legacy con la versione successiva di Spark e usare l'impostazione seguente per correggere le date:

spark.conf.set("spark.sql.legacy.parquet.int96RebaseModeInWrite", "CORRECTED")

Query non riuscita a causa di una modifica della topologia o di un errore del contenitore di calcolo

Questo errore potrebbe indicare che si è verificato un problema di processo interno nel pool SQL serverless. Inviare un ticket di supporto con tutti i dettagli necessari che potrebbero aiutare il team supporto tecnico di Azure a analizzare il problema.

Descrivere qualsiasi elemento insolito rispetto al carico di lavoro normale. Ad esempio, ad esempio, si è verificato un numero elevato di richieste simultanee o un carico di lavoro speciale o una query avviata prima che si sia verificato questo errore.

Timeout dell'espansione con caratteri jolly

Come descritto nella sezione Cartelle di query e più file , il pool SQL serverless supporta la lettura di più file/cartelle usando caratteri jolly. È previsto un limite massimo di 10 caratteri jolly per ogni query. È necessario tenere presente che questa funzionalità comporta un costo. Il pool serverless richiede tempo per elencare tutti i file che possono corrispondere al carattere jolly. Ciò introduce la latenza e questa latenza può aumentare se il numero di file che si sta tentando di eseguire query è elevato. In questo caso è possibile eseguire l'errore seguente:

"Wildcard expansion timed out after X seconds."

Per evitare questo problema, è possibile eseguire diversi passaggi di mitigazione:

  • Applicare le procedure consigliate descritte in Procedure consigliate per il pool SQL serverless.
  • Provare a ridurre il numero di file su cui si sta tentando di eseguire query, compattando i file in file di dimensioni maggiori. Provare a mantenere le dimensioni del file superiori a 100 MB.
  • Assicurarsi che i filtri sulle colonne di partizionamento vengano usati laddove possibile.
  • Se si usa il formato di file differenziale, usare la funzionalità di scrittura ottimizzata in Spark. Ciò può migliorare le prestazioni delle query riducendo la quantità di dati che devono essere letti ed elaborati. Come usare ottimizzare la scrittura è descritto in Uso di Ottimizzare la scrittura in Apache Spark.
  • Per evitare alcuni dei caratteri jolly di primo livello applicando in modo efficace l'hardcoding dei filtri impliciti sulle colonne di partizionamento, usare SQL dinamico.

Colonna mancante quando si usa l'inferenza automatica dello schema

È possibile eseguire facilmente query sui file senza conoscere o specificare lo schema omettendo la clausola WITH. In tal caso, i nomi delle colonne e i tipi di dati verranno dedotti dai file. Tenere presente che se si legge il numero di file contemporaneamente, lo schema verrà dedotto dal primo servizio file dalla risorsa di archiviazione. Ciò può significare che alcune delle colonne previste vengono omesse, tutte perché il file usato dal servizio per definire lo schema non contiene queste colonne. Per specificare in modo esplicito lo schema, usare la clausola OPENROW edizione Standard T WITH. Se si specifica lo schema (usando la tabella esterna o la clausola OPENROW edizione Standard T WITH) verrà utilizzata la modalità di percorso lax predefinita. Ciò significa che le colonne che non esistono in alcuni file verranno restituite come NULLs (per le righe di tali file). Per comprendere come viene usata la modalità percorso, consultare la documentazione e l'esempio seguenti.

Impostazione

I pool SQL serverless consentono di usare T-SQL per configurare gli oggetti di database. Esistono alcuni vincoli:

  • Non è possibile creare oggetti nei master database e o lakehouse Spark.
  • Per creare le credenziali, è necessario disporre di una chiave master.
  • È necessario disporre dell'autorizzazione per fare riferimento ai dati usati negli oggetti .

Non è possibile creare un database

Se viene visualizzato l'errore CREATE DATABASE failed. User database limit has been already reached., è stato creato il numero massimo di database supportati in un'area di lavoro. Per altre informazioni, vedere Vincoli.

  • Se è necessario separare gli oggetti, usare gli schemi all'interno dei database.
  • Se è necessario fare riferimento ad Azure Data Lake Storage, creare database lakehouse o database Spark che verranno sincronizzati nel pool SQL serverless.

Impossibile creare o modificare la tabella perché le dimensioni minime delle righe superano le dimensioni massime consentite della riga della tabella di 8060 byte

Qualsiasi tabella può avere dimensioni fino a 8 KB per riga (senza includere dati VARCHAR(MAX)/VARBINARY(MAX). Se si crea una tabella in cui la dimensione totale delle celle nella riga supera i 8060 byte, verrà visualizzato l'errore seguente:

Msg 1701, Level 16, State 1, Line 3
Creating or altering table '<table name>' failed because the minimum row size would be <???>,
including <???> bytes of internal overhead.
This exceeds the maximum allowable table row size of 8060 bytes.

Questo errore può verificarsi anche nel database Lake se si crea una tabella Spark con dimensioni di colonna superiori a 8060 byte e il pool SQL serverless non può creare una tabella che fa riferimento ai dati della tabella Spark.

Come mitigazione, evitare di usare i tipi a dimensione fissa come CHAR(N) e sostituirli con tipi di dimensioni VARCHAR(N) variabili o ridurre le dimensioni in CHAR(N). Vedere 8 KB rows group limitation in SQL Server( 8 KB rows group limitation in SQL Server).

Creare una chiave master nel database o aprire la chiave master nella sessione prima di eseguire questa operazione

Se la query non riesce con il messaggio Please create a master key in the database or open the master key in the session before performing this operation.di errore , significa che al momento il database utente non ha accesso a una chiave master.

Molto probabilmente è stato creato un nuovo database utente e non è stata ancora creata una chiave master.

Per risolvere questo problema, creare una chiave master con la query seguente:

CREATE MASTER KEY [ ENCRYPTION BY PASSWORD ='strongpasswordhere' ];

Nota

Sostituire 'strongpasswordhere' con un segreto diverso.

L'istruzione CREATE non è supportata nel database master

Se la query non riesce con il messaggio Failed to execute query. Error: CREATE EXTERNAL TABLE/DATA SOURCE/DATABASE SCOPED CREDENTIAL/FILE FORMAT is not supported in master database.di errore , significa che il master database nel pool SQL serverless non supporta la creazione di:

  • Tabelle esterne.
  • Origini dati esterne.
  • Credenziali con ambito database.
  • Formati di file esterni.

Ecco la soluzione:

  1. creare un database utente:

    CREATE DATABASE <DATABASE_NAME>

  2. Eseguire un'istruzione CREATE nel contesto di <DATABA edizione Standard_NAME>, operazione non riuscita in precedenza per il master database.

    Ecco un esempio della creazione di un formato di file esterno:

    USE <DATABASE_NAME>
CREATE EXTERNAL FILE FORMAT [SynapseParquetFormat]  
WITH ( FORMAT_TYPE = PARQUET)

Non è possibile creare l'account di accesso o l'utente di Microsoft Entra

Se viene visualizzato un errore durante il tentativo di creare un nuovo account di accesso o utente di Microsoft Entra in un database, controllare l'account di accesso usato per connettersi al database. L'account di accesso che sta tentando di creare un nuovo utente di Microsoft Entra deve avere l'autorizzazione per accedere al dominio Microsoft Entra e verificare se l'utente esiste. Tenere presente che:

  • Gli account di accesso SQL non dispongono di questa autorizzazione, quindi si otterrà sempre questo errore se si usa l'autenticazione SQL.
  • Se si usa un account di accesso di Microsoft Entra per creare nuovi account di accesso, verificare se si dispone dell'autorizzazione per accedere al dominio Microsoft Entra.

Azure Cosmos DB

I pool SQL serverless consentono di eseguire query sull'archiviazione analitica di Azure Cosmos DB usando la OPENROWSET funzione . Assicurarsi che il contenitore di Azure Cosmos DB disponga di archiviazione analitica. Assicurarsi di aver specificato correttamente l'account, il database e il nome del contenitore. Assicurarsi anche che la chiave dell'account Azure Cosmos DB sia valida. Per altre informazioni, consulta Prerequisiti.

Non è possibile eseguire query su Azure Cosmos DB usando la funzione OPENROW edizione Standard T

Se non è possibile connettersi all'account Azure Cosmos DB, esaminare i prerequisiti. Nella tabella seguente sono elencati i possibili errori e le azioni di risoluzione dei problemi.

Error Causa principale
Errori di sintassi:
- Sintassi non corretta vicino a OPENROWSET.
- ... non è un'opzione del provider riconosciuta BULK OPENROWSET .
- Sintassi non corretta vicino a ....		 Possibili cause radice:
- Non usare Azure Cosmos DB come primo parametro.
- Uso di un valore letterale stringa anziché di un identificatore nel terzo parametro.
- Non specificare il terzo parametro (nome del contenitore).
Si è verificato un errore nel stringa di connessione di Azure Cosmos DB. - L'account, il database o la chiave non è specificato.
- Un'opzione in un stringa di connessione non viene riconosciuta.
- Un punto e virgola (;) viene posizionato alla fine di un stringa di connessione.
La risoluzione del percorso di Azure Cosmos DB non è riuscita con l'errore "Nome account non corretto" o "Nome database non corretto". Impossibile trovare il nome dell'account, il nome del database o il contenitore specificato oppure l'archiviazione analitica non è stata abilitata per la raccolta specificata.
La risoluzione del percorso di Azure Cosmos DB non è riuscita con l'errore "Valore segreto non corretto" o "Secret is null or empty". La chiave dell'account non è valida o non è presente.

Durante la lettura dei tipi di stringa di Azure Cosmos DB viene restituito un avviso relativo alle regole di confronto UTF-8

Il pool SQL serverless restituisce un avviso in fase di compilazione se le regole di confronto della OPENROWSET colonna non hanno la codifica UTF-8. È possibile modificare facilmente le regole di confronto predefinite per tutte le OPENROWSET funzioni in esecuzione nel database corrente usando l'istruzione T-SQL:

ALTER DATABASE CURRENT COLLATE Latin1_General_100_CI_AS_SC_UTF8;

la regola di confronto Latin1_General_100_BIN2_UTF8 offre prestazioni ottimali quando si filtrano i dati usando predicati stringa.

Righe mancanti nell'archivio analitico di Azure Cosmos DB

Alcuni elementi di Azure Cosmos DB potrebbero non essere restituiti dalla OPENROWSET funzione. Tenere presente che:

  • Si verifica un ritardo di sincronizzazione tra l'archivio transazionale e quello analitico. Il documento immesso nell'archivio transazionale di Azure Cosmos DB potrebbe essere visualizzato nell'archivio analitico dopo due o tre minuti.
  • Il documento potrebbe violare alcuni vincoli di schema.

La query restituisce valori NULL in alcuni elementi di Azure Cosmos DB

Azure Synapse SQL restituisce NULL anziché i valori visualizzati nell'archivio transazioni nei casi seguenti:

  • Si verifica un ritardo di sincronizzazione tra l'archivio transazionale e quello analitico. Il valore immesso nell'archivio transazionale di Azure Cosmos DB può essere visualizzato nell'archivio analitico dopo due o tre minuti.
  • Potrebbe esserci un nome di colonna o un'espressione di percorso errata nella clausola WITH. Il nome della colonna (o l'espressione di percorso dopo il tipo di colonna) nella clausola WITH deve corrispondere ai nomi delle proprietà nella raccolta di Azure Cosmos DB. Il confronto fa distinzione tra maiuscole e minuscole. Ad esempio, productCode e ProductCode sono proprietà diverse. Assicurarsi che i nomi delle colonne corrispondano esattamente ai nomi delle proprietà di Azure Cosmos DB.
  • La proprietà potrebbe non essere spostata nell'archivio analitico perché viola alcuni vincoli dello schema, ad esempio più di 1.000 proprietà o più di 127 livelli di annidamento.
  • Se si usa una rappresentazione dello schema ben definita, il valore nell'archivio transazionale potrebbe avere un tipo errato. Lo schema ben definito blocca i tipi per ogni proprietà eseguendo il campionamento dei documenti. Qualsiasi valore aggiunto nell'archivio transazionale che non corrisponde al tipo viene considerato come un valore errato e non viene eseguita la migrazione all'archivio analitico.
  • Se si usa la rappresentazione dello schema con fedeltà completa, assicurarsi di aggiungere il suffisso di tipo dopo il nome della proprietà, ad esempio $.price.int64. Se non viene visualizzato un valore per il percorso a cui si fa riferimento, è possibile che sia archiviato in un percorso di tipo diverso, $.price.float64ad esempio . Per altre informazioni, vedere Eseguire query sulle raccolte di Azure Cosmos DB nello schema con fedeltà completa.

La colonna non è compatibile con il tipo di dati esterno

L'errore Column 'column name' of the type 'type name' is not compatible with the external data type 'type name'. viene restituito se il tipo di colonna specificato nella clausola WITH non corrisponde al tipo nel contenitore Azure Cosmos DB. Provare a modificare il tipo di colonna come descritto nella sezione Azure Cosmos DB in mapping dei tipi SQL o usare il tipo VARCHAR.

Risolvere: il percorso di Azure Cosmos DB non è riuscito con errore

Se viene visualizzato il controllo degli errori Resolving Azure Cosmos DB path has failed with error 'This request is not authorized to perform this operation'. per verificare se sono stati usati endpoint privati in Azure Cosmos DB. Per consentire al pool SQL serverless di accedere a un archivio analitico con endpoint privati, è necessario configurare gli endpoint privati per l'archivio analitico di Azure Cosmos DB.

Problemi di prestazioni di Azure Cosmos DB

Se si verificano alcuni problemi di prestazioni imprevisti, assicurarsi di applicare le procedure consigliate, ad esempio:

Delta Lake

Esistono alcune limitazioni che potrebbero essere visualizzate nel supporto delta Lake nei pool SQL serverless:

  • Assicurarsi di fare riferimento alla cartella Radice Delta Lake nella funzione OPENROW edizione Standard T o nel percorso della tabella esterna.
    • La cartella radice deve avere una sottocartella denominata _delta_log. La query ha esito negativo se non è presente alcuna _delta_log cartella. Se tale cartella non viene visualizzata, si fa riferimento a file Parquet semplici che devono essere convertiti in Delta Lake usando pool di Apache Spark.
    • Non specificare caratteri jolly per descrivere lo schema di partizione. La query Delta Lake identifica automaticamente le partizioni Delta Lake.
  • Le tabelle Delta Lake create nei pool di Apache Spark sono automaticamente disponibili nel pool SQL serverless, ma lo schema non viene aggiornato (limitazione dell'anteprima pubblica). Se si aggiungono colonne nella tabella Delta usando un pool di Spark, le modifiche non verranno visualizzate nel database del pool SQL serverless.
  • Le tabelle esterne non supportano il partizionamento. Usare le viste partizionate nella cartella Delta Lake per usare l'eliminazione della partizione. Vedere problemi noti e soluzioni alternative più avanti nell'articolo.
  • I pool SQL serverless non supportano le query di spostamento del tempo. Usare i pool di Apache Spark in Synapse Analytics per leggere i dati cronologici.
  • I pool SQL serverless non supportano l'aggiornamento dei file Delta Lake. È possibile usare il pool SQL serverless per eseguire query sulla versione più recente di Delta Lake. Usare i pool di Apache Spark in Synapse Analytics per aggiornare Delta Lake.
  • I pool SQL serverless in Synapse Analytics sono compatibili con il lettore Delta versione 1. Le funzionalità Delta che richiedono lettori Delta con versione 2 o successiva (ad esempio il mapping delle colonne) non sono supportate nei pool SQL serverless.
  • I pool SQL serverless in Synapse Analytics non supportano i set di dati con il filtro BLOOM. Il pool SQL serverless ignora i filtri BLOOM.
  • Il supporto di Delta Lake non è disponibile nei pool SQL dedicati. Assicurarsi di usare pool SQL serverless per eseguire query sui file Delta Lake.
  • Per altre informazioni sui problemi noti relativi ai pool SQL serverless, vedere Problemi noti di Azure Synapse Analytics.

La ridenominazione delle colonne nella tabella Delta non è supportata

Il pool SQL serverless non supporta l'esecuzione di query sulle tabelle Delta Lake con le colonne rinominate. Il pool SQL serverless non può leggere i dati dalla colonna rinominata.

Il valore di una colonna nella tabella Delta è NULL

Se si usa un set di dati Delta che richiede un lettore Delta versione 2 o successiva e usa le funzionalità non supportate nella versione 1 ,ad esempio la ridenominazione di colonne, l'eliminazione di colonne o il mapping delle colonne, i valori nelle colonne a cui si fa riferimento potrebbero non essere visualizzati.

Il testo JSON non è formattato correttamente

Questo errore indica che il pool SQL serverless non è in grado di leggere il log delle transazioni Delta Lake. Probabilmente verrà visualizzato l'errore seguente:

Msg 13609, Level 16, State 4, Line 1
JSON text is not properly formatted. Unexpected character '' is found at position 263934.
Msg 16513, Level 16, State 0, Line 1
Error reading external metadata.

Assicurarsi che il set di dati Delta Lake non sia danneggiato. Verificare di poter leggere il contenuto della cartella Delta Lake usando il pool di Apache Spark in Azure Synapse. In questo modo si garantisce che il _delta_log file non sia danneggiato.

Soluzione alternativa

Provare a creare un checkpoint nel set di dati Delta Lake usando il pool di Apache Spark ed eseguire di nuovo la query. Il checkpoint aggrega i file di log JSON transazionali e potrebbe risolvere il problema.

Se il set di dati è valido, creare un ticket di supporto e fornire altre informazioni:

  • Non apportare modifiche come l'aggiunta o la rimozione delle colonne o l'ottimizzazione della tabella perché questa operazione potrebbe modificare lo stato dei file di log delle transazioni Delta Lake.
  • Copiare il contenuto della _delta_log cartella in una nuova cartella vuota. Non copiare i .parquet data file.
  • Provare a leggere il contenuto copiato nella nuova cartella e verificare di ricevere lo stesso errore.
  • Inviare il contenuto del file copiato _delta_log a supporto tecnico di Azure.

È ora possibile continuare a usare la cartella Delta Lake con il pool di Spark. I dati copiati verranno forniti al supporto tecnico Microsoft se si è autorizzati a condividere queste informazioni. Il team di Azure esaminerà il contenuto del delta_log file e fornirà altre informazioni sui possibili errori e soluzioni alternative.

Risolvere i log delta non riusciti

L'errore seguente indica che il pool SQL serverless non è in grado di risolvere i log Delta: Resolving Delta logs on path '%ls' failed with error: Cannot parse json object from log folder. la causa più comune è che last_checkpoint_file nella _delta_log cartella è maggiore di 200 byte a causa del checkpointSchema campo aggiunto in Spark 3.3.

Sono disponibili due opzioni per aggirare questo errore:

  • Modificare la configurazione appropriata nel notebook spark e generare un nuovo checkpoint, in modo che last_checkpoint_file venga ricreato. Se si usa Azure Databricks, la modifica della configurazione è la seguente: spark.conf.set("spark.databricks.delta.checkpointSchema.writeThresholdLength", 0);
  • Effettuare il downgrade a Spark 3.2.1.

Il team di progettazione sta attualmente lavorando a un supporto completo per Spark 3.3.

La tabella Delta creata in Spark non viene visualizzata nel pool serverless

Nota

La replica delle tabelle Delta create in Spark è ancora in anteprima pubblica.

Se è stata creata una tabella Delta in Spark e non viene visualizzata nel pool SQL serverless, verificare quanto segue:

  • Attendere un po' di tempo (in genere 30 secondi) perché le tabelle Spark vengono sincronizzate con ritardo.
  • Se la tabella non è stata visualizzata nel pool SQL serverless dopo qualche tempo, controllare lo schema della tabella Spark Delta. Le tabelle Spark con tipi complessi o i tipi non supportati in serverless non sono disponibili. Provare a creare una tabella Parquet Spark con lo stesso schema in un database Lake e verificare che tale tabella venga visualizzata nel pool SQL serverless.
  • Controllare la cartella Delta Lake per l'accesso all'identità gestita dell'area di lavoro a cui fa riferimento la tabella. Il pool SQL serverless usa l'identità gestita dell'area di lavoro per ottenere le informazioni sulla colonna della tabella dalla risorsa di archiviazione per creare la tabella.

Database Lake

Le tabelle di database Lake create tramite Spark o Progettazione Synapse sono automaticamente disponibili nel pool SQL serverless per l'esecuzione di query. È possibile usare il pool SQL serverless per eseguire query sulle tabelle Parquet, CSV e Delta Lake create usando il pool di Spark e aggiungere altri schemi, viste, procedure, funzioni con valori di tabella e utenti di Microsoft Entra nel db_datareader ruolo del database Lake. I possibili problemi sono elencati in questa sezione.

Una tabella creata in Spark non è disponibile nel pool serverless

Le tabelle create potrebbero non essere immediatamente disponibili nel pool SQL serverless.

  • Le tabelle saranno disponibili nei pool serverless con un certo ritardo. Potrebbe essere necessario attendere 5-10 minuti dopo la creazione di una tabella in Spark per visualizzarla nel pool SQL serverless.
  • Nel pool SQL serverless sono disponibili solo le tabelle che fanno riferimento a formati Parquet, CSV e Delta. Altri tipi di tabella non sono disponibili.
  • Una tabella che contiene alcuni tipi di colonna non supportati non sarà disponibile nel pool SQL serverless.
  • L'accesso alle tabelle Delta Lake nei database Lake è disponibile in anteprima pubblica. Controllare altri problemi elencati in questa sezione o nella sezione Delta Lake.

Una tabella esterna creata in Spark mostra risultati imprevisti nel pool serverless

Può verificarsi una mancata corrispondenza tra la tabella esterna spark di origine e la tabella esterna replicata nel pool serverless. Ciò può verificarsi se i file usati per la creazione di tabelle esterne Spark non sono con estensioni. Per ottenere i risultati appropriati, assicurarsi che tutti i file siano con estensioni come parquet.

L'operazione non è consentita per un database replicato

Questo errore viene restituito se si sta tentando di modificare un database Lake, creare tabelle esterne, origini dati esterne, credenziali con ambito database o altri oggetti nel database Lake. Questi oggetti possono essere creati solo nei database SQL.

I database Lake vengono replicati dal pool di Apache Spark e gestiti da Apache Spark. Pertanto, non è possibile creare oggetti come in database SQL usando il linguaggio T-SQL.

Nei database Lake sono consentite solo le operazioni seguenti:

  • Creazione, eliminazione o modifica di viste, routine e funzioni inline con valori di tabella (iTVF) negli schemi diversi da dbo.
  • Creazione ed eliminazione degli utenti del database dall'ID Microsoft Entra.
  • Aggiunta o rimozione di utenti di database dallo db_datareader schema.

Altre operazioni non sono consentite nei database Lake.

Nota

Se si sta creando una vista, una routine o una funzione nello dbo schema (o omettendo lo schema e usando quello predefinito che è in genere dbo), verrà visualizzato il messaggio di errore.

Le tabelle delta nei database Lake non sono disponibili nel pool SQL serverless

Assicurarsi che l'identità gestita dell'area di lavoro abbia accesso in lettura nell'archiviazione ADLS che contiene la cartella Delta. Il pool SQL serverless legge lo schema della tabella Delta Lake dai log Delta inseriti in ADLS e usa l'identità gestita dell'area di lavoro per accedere ai log delle transazioni Delta.

Provare a configurare un'origine dati in alcuni database SQL che fanno riferimento ad Azure Data Lake Storage usando le credenziali di identità gestite e provare a creare una tabella esterna sopra l'origine dati con Identità gestita per verificare che una tabella con l'identità gestita possa accedere all'archiviazione.

Le tabelle delta nei database Lake non hanno uno schema identico nei pool Spark e serverless

I pool SQL serverless consentono di accedere alle tabelle Parquet, CSV e Delta create nel database Lake tramite Spark o Synapse Designer. L'accesso alle tabelle Delta è ancora in anteprima pubblica e attualmente senza server sincronizza una tabella Delta con Spark al momento della creazione, ma non aggiornerà lo schema se le colonne vengono aggiunte in un secondo momento usando l'istruzione ALTER TABLE in Spark.

Si tratta di una limitazione dell'anteprima pubblica. Eliminare e ricreare la tabella Delta in Spark (se possibile) anziché modificare le tabelle per risolvere il problema.

Prestazioni

Il pool SQL serverless assegna le risorse alle query in base alle dimensioni del set di dati e alla complessità delle query. Non è possibile modificare o limitare le risorse fornite alle query. In alcuni casi potrebbero verificarsi riduzioni impreviste delle prestazioni delle query e potrebbe essere necessario identificare le cause radice.

La durata della query è molto lunga

Se si dispone di query con una durata della query superiore a 30 minuti, la query che restituisce lentamente i risultati al client è lenta. Il pool SQL serverless prevede un limite di 30 minuti per l'esecuzione. Viene impiegato più tempo per lo streaming dei risultati. Attenersi alle soluzioni alternative seguenti:

  • Se si usa Synapse Studio, provare a riprodurre i problemi con un'altra applicazione, ad esempio SQL Server Management Studio o Azure Data Studio.
  • Se la query è lenta quando viene eseguita usando SQL Server Management Studio, Azure Data Studio, Power BI o un'altra applicazione, verificare i problemi di rete e le procedure consigliate.
  • Inserire la query nel comando CETAS e misurare la durata della query. Il comando CETAS archivia i risultati in Azure Data Lake Archiviazione e non dipende dalla connessione client. Se il comando CETAS termina più velocemente della query originale, controllare la larghezza di banda di rete tra il client e il pool SQL serverless.

La query è lenta quando viene eseguita tramite Synapse Studio

Se si usa Synapse Studio, provare a usare un client desktop, ad esempio SQL Server Management Studio o Azure Data Studio. Synapse Studio è un client Web che si connette al pool SQL serverless usando il protocollo HTTP, che in genere è più lento rispetto alle connessioni SQL native usate in SQL Server Management Studio o Azure Data Studio.

La query è lenta quando viene eseguita usando un'applicazione

Controllare i problemi seguenti se si verifica un rallentamento dell'esecuzione delle query:

  • Assicurarsi che le applicazioni client siano collocate con l'endpoint del pool SQL serverless. L'esecuzione di una query nell'area può causare una latenza aggiuntiva e un flusso lento del set di risultati.
  • Assicurarsi di non avere problemi di rete che possono causare il flusso lento del set di risultati
  • Assicurarsi che l'applicazione client disponga di risorse sufficienti( ad esempio, non usando la CPU al 100%).
  • Assicurarsi che l'account di archiviazione o l'archiviazione analitica di Azure Cosmos DB si trovano nella stessa area dell'endpoint SQL serverless.

Vedere le procedure consigliate per la collocazione delle risorse.

Variazioni elevate nelle durate delle query

Se si esegue la stessa query e si osservano variazioni nelle durate della query, potrebbero verificarsi diversi motivi:

  • Controllare se si tratta della prima esecuzione di una query. La prima esecuzione di una query raccoglie le statistiche necessarie per creare un piano. Le statistiche vengono raccolte analizzando i file sottostanti e aumentando la durata della query. In Synapse Studio verranno visualizzate le query di creazione di statistiche globali nell'elenco di richieste SQL eseguite prima della query.
  • Le statistiche potrebbero scadere dopo un certo periodo di tempo. Periodicamente, è possibile osservare un impatto sulle prestazioni perché il pool serverless deve analizzare e ricompilare le statistiche. È possibile notare un'altra query di creazione di statistiche globali nell'elenco di richieste SQL eseguite prima della query.
  • Controllare se è presente un carico di lavoro in esecuzione nello stesso endpoint quando è stata eseguita la query con la durata più lunga. L'endpoint SQL serverless alloca equamente le risorse a tutte le query eseguite in parallelo e la query potrebbe essere ritardata.

Connessioni

Il pool SQL serverless consente di connettersi usando il protocollo TDS e il linguaggio T-SQL per eseguire query sui dati. La maggior parte degli strumenti che possono connettersi a SQL Server o database SQL di Azure può connettersi anche al pool SQL serverless.

Il pool SQL si sta riscaldando

Dopo un periodo di inattività più lungo, il pool SQL serverless verrà disattivato. L'attivazione viene eseguita automaticamente nella prima attività successiva, ad esempio il primo tentativo di connessione. Il messaggio di errore viene visualizzato perché il processo di attivazione potrebbe richiedere più tempo rispetto a un singolo tentativo di connessione. Il tentativo di ripetizione del tentativo di connessione dovrebbe essere sufficiente.

Come procedura consigliata, per i client che lo supportano, usare Connessione ionRetryCount e Connessione RetryInterval stringa di connessione parole chiave per controllare il comportamento di riconnessione.

Se il messaggio di errore persiste, inviare un ticket di supporto tramite il portale di Azure.

Non è possibile connettersi da Synapse Studio

Vedere la sezione Synapse Studio.

Non è possibile connettersi al pool di Azure Synapse da uno strumento

Alcuni strumenti potrebbero non avere un'opzione esplicita che è possibile usare per connettersi al pool SQL serverless di Azure Synapse. Usare un'opzione da usare per connettersi a SQL Server o database SQL. Non è necessario che la finestra di dialogo di connessione sia "Synapse" perché il pool SQL serverless usa lo stesso protocollo di SQL Server o database SQL.

Anche se uno strumento consente di immettere solo un nome server logico e predefinito il database.windows.net dominio, inserire il nome dell'area di lavoro di Azure Synapse seguito dal -ondemand suffisso e dal database.windows.net dominio.

Sicurezza

Assicurarsi che un utente disponga delle autorizzazioni per accedere a database, autorizzazioni per eseguire comandi e autorizzazioni per accedere all'archiviazione di Azure Data Lake o Azure Cosmos DB.

Non è possibile accedere all'account Azure Cosmos DB

È necessario usare una chiave di Azure Cosmos DB di sola lettura per accedere all'archiviazione analitica, quindi assicurarsi che non scada o che non venga rigenerata.

Se viene visualizzato l'errore "Risoluzione del percorso di Azure Cosmos DB non riuscito con errore", assicurarsi di aver configurato un firewall.

Non è possibile accedere a lakehouse o al database Spark

Se un utente non riesce ad accedere a un lakehouse o a un database Spark, l'utente potrebbe non avere l'autorizzazione per accedere e leggere il database. Un utente con autorizzazione CONTROL edizione Standard RVER deve avere accesso completo a tutti i database. Come autorizzazione con restrizioni, è possibile provare a usare CONNECT ANY DATABA edizione Standard e edizione Standard LECT ALL U edizione Standard R edizione Standard CURABLES.

L'utente SQL non può accedere alle tabelle di Dataverse

Le tabelle di Dataverse accedono all'archiviazione usando l'identità Microsoft Entra del chiamante. Un utente SQL con autorizzazioni elevate potrebbe provare a selezionare i dati da una tabella, ma la tabella non sarebbe in grado di accedere ai dati di Dataverse. Questo scenario non è supportato.

Errori di accesso dell'entità servizio Microsoft Entra quando SPI crea un'assegnazione di ruolo

Se si vuole creare un'assegnazione di ruolo per un identificatore dell'entità servizio (SPI) o un'app Microsoft Entra usando un altro SPI oppure se ne è già stato creato uno e non è possibile eseguire l'accesso, probabilmente si riceverà l'errore seguente: Login error: Login failed for user '<token-identified principal>'.

Per le entità servizio, l'account di accesso deve essere creato con un ID applicazione come ID di sicurezza (SID) non con un ID oggetto. Esiste una limitazione nota per le entità servizio, che impedisce ad Azure Synapse di recuperare l'ID applicazione da Microsoft Graph quando crea un'assegnazione di ruolo per un altro SPI o un'altra app.

Soluzione 1

Passare alla portale di Azure> Synapse Studio>Gestire>il controllo di accesso e aggiungere manualmente Synapse Amministrazione istrator o Synapse SQL Amministrazione istrator per l'entità servizio desiderata.

Soluzione 2

È necessario creare manualmente un account di accesso appropriato con codice SQL:

use master
go
CREATE LOGIN [<service_principal_name>] FROM EXTERNAL PROVIDER;
go
ALTER SERVER ROLE sysadmin ADD MEMBER [<service_principal_name>];
go

Soluzione 3

È anche possibile configurare un'entità servizio amministratore di Azure Synapse usando PowerShell. È necessario che sia installato il modulo Az.Synapse.

La soluzione consiste nell'usare il cmdlet New-AzSynapseRoleAssignment con -ObjectId "parameter". Nel campo del parametro specificare l'ID applicazione anziché l'ID oggetto usando le credenziali dell'entità servizio di Azure amministratore dell'area di lavoro.

Script di PowerShell:

$spAppId = "<app_id_which_is_already_an_admin_on_the_workspace>"
$SPPassword = "<application_secret>"
$tenantId = "<tenant_id>"
$secpasswd = ConvertTo-SecureString -String $SPPassword -AsPlainText -Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $spAppId, $secpasswd

Connect-AzAccount -ServicePrincipal -Credential $cred -Tenant $tenantId

New-AzSynapseRoleAssignment -WorkspaceName "<workspaceName>" -RoleDefinitionName "Synapse Administrator" -ObjectId "<app_id_to_add_as_admin>" [-Debug]

Convalida

Connessione all'endpoint SQL serverless e verificare che venga creato l'account di accesso esterno con SID (app_id_to_add_as_admin nell'esempio precedente):

SELECT name, convert(uniqueidentifier, sid) AS sid, create_date
FROM sys.server_principals 
WHERE type in ('E', 'X');

In alternativa, provare ad accedere all'endpoint SQL serverless usando l'app di amministrazione impostata.

Vincoli

Alcuni vincoli di sistema generali possono influire sul carico di lavoro:

Proprietà Limitazione
Numero massimo di aree di lavoro di Azure Synapse per sottoscrizione Vedere limiti.
Numero massimo di database per pool serverless 100 (non inclusi i database sincronizzati dal pool di Apache Spark).
Numero massimo di database sincronizzati dal pool di Apache Spark Non limitate.
Numero massimo di oggetti database per database La somma del numero di tutti gli oggetti in un database non può essere maggiore di 2.147.483.647. Vedere Limitazioni nel motore di database di SQL Server.
Lunghezza massima dell'identificatore in caratteri 128. Vedere Limitazioni nel motore di database di SQL Server.
Durata massima query 30 minuti.
Dimensioni massime del set di risultati Fino a 400 GB condivisi tra query simultanee.
Concorrenza massima Non limitato e dipende dalla complessità delle query e dalla quantità di dati analizzati. Un pool SQL serverless può gestire contemporaneamente 1.000 sessioni attive che eseguono query leggere. I numeri verranno diminuiti se le query sono più complesse o analizzano una quantità maggiore di dati, quindi in tal caso prendere in considerazione la riduzione della concorrenza ed eseguire query in un periodo di tempo più lungo, se possibile.
Dimensioni massime del nome tabella esterna 100 caratteri.

Impossibile creare un database nel pool SQL serverless

I pool SQL serverless presentano limitazioni e non è possibile creare più di 100 database per area di lavoro. Se è necessario separare gli oggetti e isolarli, usare gli schemi.

Se viene visualizzato l'errore CREATE DATABASE failed. User database limit has been already reached creato il numero massimo di database supportati in un'area di lavoro.

Non è necessario usare database separati per isolare i dati per tenant diversi. Tutti i dati vengono archiviati esternamente in un data lake e in Azure Cosmos DB. I metadati, ad esempio tabelle, viste e definizioni di funzione, possono essere isolati correttamente usando gli schemi. L'isolamento basato su schema viene usato anche in Spark in cui i database e gli schemi sono gli stessi concetti.

Passaggi successivi