Mirroring di Database SQL di Azure
Il mirroring in Fabric offre un'esperienza semplice per evitare complessi ETL (Extract Transform Load) e integrare il database SQL di Azure esistente con il resto dei dati in Microsoft Fabric. È possibile replicare continuamente i database SQL di Azure esistenti direttamente in OneLake di Fabric. All'interno di Fabric è possibile sbloccare potenti scenari di business intelligence, intelligenza artificiale, ingegneria dei dati, data science e condivisione dei dati.
Per un'esercitazione sulla configurazione delle database SQL di Azure per il mirroring in Fabric, vedere Esercitazione: Configurare i database con mirroring di Microsoft Fabric da database SQL di Azure.
Per altre informazioni e per guardare le demo dei mirroring dei database SQL di Azure in Fabric, guardare l'episodio dati exposti seguente.
Perché usare il mirroring in Fabric?
Con il mirroring in Fabric, non è necessario unire servizi diversi da più fornitori. Invece, è possibile usufruire di un prodotto end-to-end altamente integrato e facile da usare, progettato per semplificare le esigenze di analisi e creato per l'apertura e la collaborazione tra Microsoft, Azure SQL Database e le migliaia di soluzioni tecnologiche in grado di leggere il formato di tabella Delta Lake open source.
Quali esperienze di analisi sono integrate?
I database con mirroring sono un elemento di Fabric Archiviazione dati distinto dall'endpoint di analisi warehouse e SQL.
Il mirroring crea tre elementi nell'area di lavoro Fabric:
- Elemento del database con mirroring. Il mirroring gestisce la replica dei dati in OneLake e la conversione in Parquet, in un formato pronto per l'analisi. Questo consente scenari downstream quali ingegneria dei dati, data science e altri.
- Un endpoint di Analisi SQL
- Un modello semantico predefinito
Ogni database SQL di Azure con mirroring ha un endpoint di analisi SQL generato automaticamente che offre un'esperienza analitica avanzata oltre alle tabelle Delta create dal processo di mirroring. Gli utenti hanno accesso a comandi T-SQL familiari che possono definire ed eseguire query su oggetti dati, ma non modificare i dati dall'endpoint di analisi SQL, perché si tratta di una copia di sola lettura. È possibile eseguire le azioni seguenti nell'endpoint di analisi SQL:
- Esplorare le tabelle che fanno riferimento ai dati nelle tabelle Delta Lake da database SQL di Azure.
- Creare query e visualizzazioni senza codice ed esplorare visivamente i dati senza scrivere nemmeno una riga di codice.
- Sviluppare viste SQL, TVF (funzioni con valore di tabella) inline e procedure archivate per incapsulare la semantica e la logica di business in T-SQL.
- Gestire le autorizzazioni per gli oggetti.
- Eseguire query sui dati in altre Warehouse e Lakehouse nella stessa area di lavoro.
Oltre all'editor di query SQL, è disponibile un ampio ecosistema di strumenti in grado di eseguire query sull'endpoint di analisi SQL, tra cui SQL Server Management Studio (SSMS), l'estensione mssql con Visual Studio Code e anche GitHubCopilot.
Requisiti di rete
Attualmente, il mirroring non supporta database SQL di Azure server logici dietro una rete virtuale di Azure o una rete privata. Se l'istanza di database di Azure si trova dietro una rete privata, non è possibile abilitare mirroring di database SQL di Azure.
- Attualmente, è necessario aggiornare le regole del firewall del server logico SQL di Azure in Consenti l'accesso alla rete pubblica.
- È necessario abilitare l'opzione Consenti ai servizi di Azure di connettersi al server logico database SQL di Azure.
Transazioni attive, carichi di lavoro e comportamenti del motore di replica
- Le transazioni attive continuano a contenere il troncamento del log delle transazioni fino a quando non viene eseguito il commit delle transazioni e il database SQL di Azure con mirroring recupera o interrompe le transazioni. Le transazioni di esecuzione prolungata potrebbero comportare un riempimento del log delle transazioni superiore al normale. Il log delle transazioni del database di origine deve essere monitorato in modo che il log delle transazioni non venga compilato. Per altre informazioni, vedere Aumento del log delle transazioni a causa di transazioni a esecuzione prolungata e CDC.
- Ogni carico di lavoro utente varia. Durante lo snapshot iniziale, nel database di origine potrebbero essere presenti più utilizzi delle risorse, sia per le operazioni di CPU che di I/O al secondo (operazioni di input/output al secondo, per leggere le pagine). Le operazioni di aggiornamento/eliminazione delle tabelle possono comportare un aumento della generazione di log. Altre informazioni su come monitorare le risorse per il database SQL di Azure.
- Il motore di replica monitora ogni tabella per le modifiche in modo indipendente. Se non sono presenti aggiornamenti in una tabella di origine, il motore di replicatore inizia a eseguire il back off con una durata esponenziale crescente per tale tabella, fino a un'ora. Lo stesso può verificarsi in presenza di un errore temporaneo, impedendo l'aggiornamento dei dati. Il motore di replicator riprenderà automaticamente il polling regolare dopo il rilevamento dei dati aggiornati.
Supporto di livelli e modelli di acquisto
Il database sorgente Azure SQL può essere sia un database singolo o un database in un pool elastico.
- Sono supportati tutti i livelli di servizio nel modello di acquisto vCore.
- Per il modello di acquisto DTU (Database Transaction Unit), i database creati nei modelli di servizio Free, Basic, o Standard con meno di 100 DTU non sono supportati.
Passaggio successivo
Contenuto correlato
- Procedura: Proteggere i database con mirroring di Microsoft Fabric da database SQL di Azure
- Limitazioni nei database con mirroring di Microsoft Fabric da Azure SQL
- Monitorare la replica del database con mirroring di Fabric
- Risolvere i problemi relativi ai database con mirroring dell'infrastruttura da database SQL di Azure