Condividi tramite

Risolvere i problemi relativi ai database con mirroring di Fabric

Questo articolo descrive gli scenari, le risoluzioni e le soluzioni alternative comuni per i database con mirroring di Microsoft Fabric. Per ogni origine dati, esaminare anche la risoluzione dei problemi, le domande frequenti e le limitazioni specifiche.

Area Reference
Risoluzione dei problemi Mirroring per Azure Cosmos DB, Azure Database per PostgreSQL, database SQL di Azure, Istanza gestita di SQL di Azure, Snowflake, SQL Server, database SQL di Fabric
Limitazioni Mirroring per Azure Cosmos DB, Database di Azure per PostgreSQL, Azure Databricks, Database SQL di Azure, Istanza gestita di SQL di Azure, Snowflake, Google BigQuery, Oracle, SAP, SQL Server, database SQL fabric
Domande frequenti Mirroring per Azure Cosmos DB, Database di Azure per PostgreSQL, Azure Databricks, Database SQL di Azure, Istanza gestita di Azure SQL, Google BigQuery, SQL Server, database Fabric SQL

Modifiche alla capacità del fabric

Scenario Description
Capacità infrastruttura sospesa Il mirroring è stato interrotto e non è possibile elencare o accedere all'elemento del database in mirroring. Riprendi o riassegna la capacità all'area di lavoro.
Capacità del fabric ripristinata Quando la capacità viene ripresa da uno stato sospeso, lo stato del database con mirroring viene visualizzato come Sospeso. Di conseguenza, le modifiche apportate nell'origine non vengono replicate in OneLake.
Per riprendere il mirroring, accedere al database con mirroring attivo nel portale di Fabric, selezionare Riprendi replica. Il mirroring continua da dove è stato sospeso.
Si noti che se la capacità rimane sospesa per molto tempo, il mirroring potrebbe non riprendere dal punto di arresto e reinvierà i dati dall'inizio. Questo perché la sospensione prolungata del mirroring può causare l'aumento dell'utilizzo del log delle transazioni del database di origine e impedire il troncamento del log. Per ridurre al minimo l'impatto sul database, se lo spazio del log utilizzato è vicino a essere pieno, quando il mirroring viene ripreso, verrà avviato un nuovo ripristino del database per rilasciare lo spazio del log mantenuto.
Ridimensionamento della capacità dell'infrastruttura Il mirroring continua. Se si riduce la capacità, tenere presente che l'archiviazione OneLake per i dati con mirroring è gratuita fino a un limite basato sulla dimensione della capacità, quindi ridurre la capacità potrebbe comportare costi di archiviazione aggiuntivi. Per altre informazioni, vedere Costo del mirroring.
Capacità del tessuto limitata Attendere fino a quando lo stato di sovraccarico è terminato oppure aggiorna la tua capacità. Il mirroring continuerà una volta che la capacità sarà ripristinata. Per altre informazioni, vedere Azioni che è possibile eseguire per il ripristino da situazioni di overload.
Capacità di prova del tessuto scaduta Il mirroring è stato arrestato. Per conservare il database con mirroring, acquista una capacità di elaborazione Fabric. Per saperne di più, vai a La capacità di prova di Fabric scade.

I dati non sembrano essere replicati

Se si osserva un ritardo nell'aspetto dei dati con mirroring, verificare quanto segue:

  • Stato del mirroring: Nella pagina di monitoraggio del portale Fabric del database con mirroring, controllare lo stato del database con mirroring e delle tabelle specifiche e la colonna "Ultimo completamento" che indica l'ultima volta che Fabric aggiorna la tabella con mirroring dall'origine. Vuoto significa che la tabella non è ancora replicata.

    Se abiliti il monitoraggio dell'area di lavoro, puoi anche verificare la latenza di esecuzione del mirroring eseguendo una query sul valore ReplicatorBatchLatency dai log delle operazioni del database a specchio.

    Per i tipi di origine come database SQL di Azure, Istanza gestita di SQL di Azure e Database di Azure per PostgreSQL, seguire le istruzioni specifiche per controllare anche la configurazione e lo stato del database di origine.

  • Dati in OneLake: Il mirroring replica continuamente i tuoi dati in OneLake nel formato di tabella Delta Lake. Per verificare se i dati vengono caricati correttamente in OneLake, è possibile creare un collegamento dalle tabelle replicate in un Lakehouse, quindi costruire notebook con Spark per interrogarli. Scopri di più su Esplora con i notebook.

  • Dati nell'endpoint di analisi SQL: È possibile eseguire query sui dati replicati tramite l'endpoint di analisi SQL del database replicato o di un Lakehouse con un collegamento ai dati replicati. Quando viene visualizzato un ritardo, convalidare prima lo stato e i dati del mirroring in OneLake, come indicato in precedenza. Se i dati vengono visualizzati in OneLake ma non nell'endpoint di analisi SQL, è possibile che si verifichi un ritardo nella sincronizzazione dei metadati nell'endpoint di analisi SQL.

    È possibile forzare manualmente un aggiornamento dell'analisi automatica dei metadati. Nella pagina per l'endpoint di analisi SQL selezionare il pulsante Aggiorna come illustrato nell'immagine seguente. Attendere un po' di tempo, quindi eseguire di nuovo una query sui dati da controllare.

    Screenshot del Portale Fabric di come forzare un aggiornamento per la scansione dei metadati degli endpoint di analisi SQL.

Arrestare la replica

Quando si seleziona Arresta replica, i file OneLake rimangono invariati, ma la replica incrementale viene arrestata. È possibile riavviare la replica in qualsiasi momento selezionando Avvia replica. È possibile arrestare o avviare la replica quando si reimposta lo stato della replica, dopo le modifiche al database di origine o come strumento di risoluzione dei problemi.

Replicare la gerarchia dello schema di origine

Quando si esegue il mirroring dei dati di vari tipi di database di origine, la gerarchia dello schema di origine viene mantenuta nel database con mirroring. Garantisce che i dati rimangano organizzati in modo coerente in diversi servizi, consentendo di usarli usando la stessa logica nell'endpoint di analisi SQL, nei notebook spark, nei modelli semantici e in altri riferimenti ai dati.

Per i database con mirroring creati prima dell'abilitazione di questa funzionalità, si noterà che lo schema di origine viene appiattito nel database con mirroring e il nome dello schema viene codificato nel nome della tabella. Se si desidera riorganizzare le tabelle con schemi, ricreare il database specchiato.

Se si usa l'API per creare/aggiornare il database con mirroring, impostare il valore per la proprietà defaultSchema, che indica se replicare la gerarchia dello schema dal database di origine. Consultare gli esempi di definizione nell'API pubblica REST per il mirroring di Microsoft Fabric.

Supporto per la mappatura delle colonne delta

Il mirroring supporta la replica di colonne contenenti spazi o caratteri speciali nei nomi (ad esempio ,;{}()\n\t=) dai database di origine ai database con mirroring. Dietro le quinte, il mirroring scrive i dati in OneLake con il mapping delle colonne Delta abilitato.

Per le tabelle già in fase di replica prima dell'abilitazione di questa funzionalità, per includere colonne con caratteri speciali nei nomi, è necessario aggiornare le impostazioni del database con mirroring rimuovendo e leggendo tali tabelle oppure arrestare e riavviare il database con mirroring.

Assumere il controllo di un database con mirroring

Attualmente, il database con mirroring non supporta la modifica della proprietà. Se un database con mirroring smette di funzionare perché il proprietario dell'elemento ha lasciato l'organizzazione o non è più valido, è necessario ricreare il database con mirroring.

Regioni supportate

Il mirroring del database e il mirroring aperto sono disponibili in tutte le aree di Microsoft Fabric. Per altre informazioni, si veda Disponibilità di Fabric a livello di area.

Troubleshoot

Questa sezione contiene i passaggi generali per la risoluzione dei problemi relativi al mirroring.

Non è possibile connettersi a un database di origine

  1. Verificare che i dettagli della connessione siano corretti, nome del server, nome del database, nome utente e password.
  2. Verificare che il server non si trovi dietro un firewall o una rete virtuale privata. Aprire le porte del firewall appropriate.
    • Alcune origini dati con mirroring supportano gateway di dati per rete virtuale o gateway di dati locali; consultare la documentazione dell'origine per il supporto di questa funzionalità.

Nessuna visualizzazione viene replicata.

Attualmente, le visualizzazioni non sono supportate. Sono supportate solo le tabelle regolari replicabili.

Non vengono replicate tabelle

  1. Controllare lo stato del monitoraggio per controllare lo stato delle tabelle. Per altre informazioni, vedere Monitorare la replica del database con mirroring di Fabric.
  2. Selezionare il pulsante Configura replica . Verificare se le tabelle sono presenti nell'elenco delle tabelle o se sono presenti avvisi in ogni dettaglio di tabella.

Colonne mancanti nella tabella di destinazione

  1. Selezionare il pulsante Configura replica .
  2. Selezionare l'icona Avviso accanto al dettaglio della tabella se le colonne non vengono replicate.

Alcuni dei dati nella colonna sembrano essere troncati

L'endpoint di analisi SQL supporta varchar(max) fino a 16 MB.

  • Il limite di 16 MB si applica alle tabelle create dopo il 18 novembre 2025 nei database con mirroring, ma ogni tipo di elemento con mirroring può avere un limite diverso e inferiore. Ad esempio, SQL Server con mirroring supporta fino a 1 MB e Cosmos DB supporta fino a 2 MB. Vedere la tabella seguente.
  • Le tabelle esistenti create prima del 18 novembre 2025 supportano solo varchar(8000) e devono essere ricreate per adottare un nuovo tipo di dati e supportare dati maggiori di 8 KB.
Oggetto della piattaforma specchiato limite varchar(max)
SQL Server con mirroring, database SQL di Azure, Istanza gestita di Azure SQL 1 MB
Database SQL su Fabric 1 MB
Azure Cosmos DB rispecchiato 2 MB
Cosmos DB in Fabric 2 MB

La tabella/schema con mirroring non viene eliminata quando viene rimossa dal database di origine.

Livello della tabella:

  • Quando si sceglie di eseguire il mirroring di un elenco di tabelle selettive e la tabella di origine viene eliminata, la tabella con mirroring rimane e viene visualizzato l'errore "La tabella di origine non esiste" nel monitoraggio. Se non si vuole più replicare questa tabella, aggiornare la configurazione del database con mirroring e rimuoverla, la tabella con mirroring verrà eliminata.
  • Quando si sceglie di eseguire il mirroring di tutti i dati e la tabella di origine viene eliminata, viene eliminata anche la tabella con mirroring.

Livello dello schema: quando lo schema viene eliminato nel database di origine, lo schema viene comunque visualizzato nell'endpoint di Analisi SQL come schema vuoto.

Non è possibile modificare il database di origine

La modifica del database di origine non è supportata. Creare un nuovo database specchio.

Limita i messaggi di errore

Questi messaggi di errore comuni contengono spiegazioni e mitigazioni:

Messaggio di errore Ragione Mitigazione
"Il numero di tabelle può superare il limite, potrebbero mancare alcune tabelle". È previsto un massimo di 1000 tabelle. Nel database di origine eliminare o filtrare le tabelle. Se la nuova tabella è la 1000a tabella, non è necessaria alcuna mitigazione.
Il processo di replicazione viene rallentato con l'intenzione di continuare a YYYY-MM-DDTHH:MM:ss. È previsto un massimo di 1 TB di dati delle modifiche acquisiti per ogni database con mirroring al giorno. Attendere il termine della limitazione.

Contenuti correlati

  • Last updated on