File di dati di SQL Server in Azure

I file di dati di SQL Server in Azure consentono il supporto nativo per i file di database di SQL Server archiviati come BLOB di Azure. Consente di creare un database in SQL Server in esecuzione in locale o in una macchina virtuale in Azure con un percorso di archiviazione dedicato per i dati in Archiviazione BLOB di Azure. Questo miglioramento semplifica in particolare lo spostamento di database tra computer tramite operazioni di scollegamento e collegamento. Offre inoltre un percorso di archiviazione alternativo per i file di backup del database consentendo di eseguire il ripristino da o in Archiviazione di Azure. Pertanto, consente diverse soluzioni ibride offrendo diversi vantaggi per la virtualizzazione dei dati, lo spostamento dei dati, la sicurezza e la disponibilità e qualsiasi semplice costo basso e manutenzione per la disponibilità elevata e la scalabilità elastica.

Questo argomento presenta concetti e considerazioni fondamentali per l'archiviazione di file di dati di SQL Server nel servizio di archiviazione di Azure.

Per un'esperienza pratica su come usare questa nuova funzionalità, vedere Esercitazione: File di dati di SQL Server nel servizio Archiviazione di Azure.

Il diagramma seguente illustra che questo miglioramento consente di archiviare i file di database di SQL Server come BLOB di Azure in Archiviazione di Azure indipendentemente dalla posizione in cui si trova il server.

Integrazione di SQL Server con Archiviazione di Azure

Vantaggi dell'uso di file di dati di SQL Server in Azure

Vantaggi della migrazione semplice e veloce: Questa funzionalità semplifica il processo di migrazione spostando un database alla volta tra computer in locale e tra ambienti locali e cloud senza modifiche all'applicazione. Pertanto, supporta una migrazione incrementale mantenendo l'infrastruttura locale esistente. Inoltre, avere accesso a un archivio dati centralizzato semplifica la logica dell'applicazione quando un'applicazione deve essere eseguita in più posizioni in un ambiente locale. In alcuni casi, potrebbe essere necessario configurare rapidamente i centri computer in posizioni geograficamente distribuite, che raccolgono dati da molte origini diverse. Usando questo nuovo miglioramento, invece di spostare i dati da una posizione a un'altra, è possibile archiviare molti database come BLOB di Azure e quindi eseguire script Transact-SQL per creare database nelle macchine locali o nelle macchine virtuali.
Vantaggi di archiviazione senza costi e limiti: Questa funzionalità consente di disporre di un'archiviazione fuori sede illimitata in Azure sfruttando le risorse di calcolo locali. Quando si usa Azure come posizione di archiviazione, è possibile concentrarsi facilmente sulla logica dell'applicazione senza il sovraccarico della gestione hardware. Se si perde un nodo di calcolo in locale, è possibile configurare un nuovo nodo senza alcun spostamento dei dati.
Vantaggi di disponibilità elevata e ripristino di emergenza: L'uso di file di dati di SQL Server in Azure potrebbe semplificare le soluzioni di disponibilità elevata e ripristino di emergenza. Ad esempio, se una macchina virtuale in Azure o un'istanza di SQL Server si arresta in modo anomalo, è possibile ricreare i database in un nuovo computer semplicemente stabilendo i collegamenti ai BLOB di Azure.
Vantaggi della sicurezza: Questo nuovo miglioramento consente di separare un'istanza di calcolo da un'istanza di archiviazione. È possibile avere un database completamente crittografato con decrittografia solo nell'istanza di calcolo, ma non in un'istanza di archiviazione. In altre parole, usando questo nuovo miglioramento, è possibile crittografare tutti i dati nel cloud pubblico usando certificati TDE (Transparent Data Encryption), separati fisicamente dai dati. Le chiavi TDE possono essere archiviate nel database master, archiviate localmente nel computer locale protetto fisicamente ed eseguito il backup in locale. È possibile usare queste chiavi locali per crittografare i dati che risiedono in Archiviazione di Azure. Se le credenziali dell'account di archiviazione cloud vengono rubate, i dati rimangono comunque protetti perché i certificati TDE risiedono sempre in locale.

Concetti e requisiti

Concetti di Archiviazione Azure

Quando si usa la funzionalità File di dati di SQL Server in Azure, è necessario creare un account di archiviazione e un contenitore in Azure. È quindi necessario creare una credenziale di SQL Server, che include informazioni sui criteri del contenitore e una firma di accesso condiviso necessaria per accedere al contenitore.

In Azure, un account di archiviazione rappresenta il livello più elevato nello spazio dei nomi per l'accesso ai Blob. Un account di archiviazione può contenere un numero illimitato di contenitori, purché la dimensione totale sia inferiore a 500 TB. Per informazioni più recenti sui limiti di archiviazione, vedere Sottoscrizione di Azure e limiti dei servizi, quote e vincoli. Un contenitore fornisce un raggruppamento di un set di BLOB. Tutti i BLOB devono trovarsi in un contenitore. Un account può contenere un numero illimitato di contenitori. Analogamente, un contenitore può archiviare anche un numero illimitato di BLOB. Esistono due tipi di BLOB che possono essere archiviati in Archiviazione di Azure: BLOB in blocchi e pagine. Questa nuova funzionalità usa BLOB di pagine, che possono avere dimensioni fino a 1 TB e sono più efficienti quando gli intervalli di byte in un file vengono modificati di frequente. È possibile accedere ai BLOB usando il formato url seguente: http://storageaccount.blob.core.windows.net/<container>/<blob>.

Considerazioni sulla fatturazione di Azure

La stima del costo dell'uso dei servizi di Azure è una questione importante nel processo decisionale e nella pianificazione. Quando si archiviano i file di dati di SQL Server in Archiviazione di Azure, è necessario pagare i costi associati all'archiviazione e alle transazioni. Inoltre, l'implementazione di file di dati di SQL Server in Archiviazione di Azure richiede un rinnovo del lease BLOB ogni 45-60 secondi in modo implicito. Ciò comporta anche i costi delle transazioni per ogni file di database, ad esempio .mdf o ldf. In base alle stime, il costo del rinnovo dei lease per due file di database (.mdf e ldf) sarebbe di circa 2 centesimi al mese in base al modello di prezzi corrente. È consigliabile usare le informazioni nella pagina Prezzi di Azure per stimare i costi mensili associati all'uso di Archiviazione di Azure e macchine virtuali di Azure.

Concetti relativi a SQL Server

Quando si usa questo nuovo miglioramento, è necessario eseguire le operazioni seguenti:

È necessario creare un criterio in un contenitore e generare anche una chiave di firma di accesso condiviso.You must create a policy on a container and also generate a shared access signature (SAS).
Per ogni contenitore usato da un file di dati o di log, è necessario creare una credenziale di SQL Server il cui nome corrisponde al percorso del contenitore.
È necessario archiviare le informazioni relative al contenitore di Archiviazione di Azure, al nome della politica associata e alla chiave SAS nell'archivio credenziali di SQL Server.

L'esempio seguente presuppone che sia stato creato un contenitore di Archiviazione di Azure e che sia stato creato un criterio con diritti di lettura, scrittura ed elenco. La creazione di un criterio su un contenitore genera una chiave SAS che è sicura da conservare non crittografata in memoria e necessaria a SQL Server per accedere ai file BLOB nel contenitore. Nel frammento di codice seguente sostituire 'your SAS key' con una voce simile alla seguente: 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>'. Per altre informazioni, vedere Creare e usare una firma di accesso condiviso

-- Create a credential  
CREATE CREDENTIAL [https://testdb.blob.core.windows.net/data]  
WITH IDENTITY='SHARED ACCESS SIGNATURE',  
SECRET = 'your SAS key'  
  
-- Create database with data and log files in Azure container.  
CREATE DATABASE testdb   
ON  
( NAME = testdb_dat,  
    FILENAME = 'https://testdb.blob.core.windows.net/data/TestData.mdf' )  
 LOG ON  
( NAME = testdb_log,  
    FILENAME =  'https://testdb.blob.core.windows.net/data/TestLog.ldf')

Importante

Se sono presenti riferimenti attivi ai file di dati in un contenitore, i tentativi di eliminare le credenziali di SQL Server corrispondenti hanno esito negativo.

Sicurezza

Di seguito sono riportate considerazioni sulla sicurezza e requisiti per l'archiviazione di file di dati di SQL Server in Archiviazione di Azure.

Quando si crea un contenitore per il servizio di archiviazione BLOB di Azure, è consigliabile impostare l'accesso su privato. Quando si imposta l'accesso a dati privati, i contenitori e i dati BLOB possono essere letti solo dal proprietario dell'account Azure.
Quando archivi i file di database di SQL Server in Azure Storage, è necessario utilizzare una firma di accesso condiviso, un URI che concede diritti di accesso limitati a contenitori, BLOB, code e tabelle. Usando una firma di accesso condiviso, è possibile abilitare SQL Server per accedere alle risorse nell'account di archiviazione senza condividere la chiave dell'account di archiviazione di Azure.
È inoltre consigliabile continuare a implementare le tradizionali procedure di sicurezza locali per i database.

Prerequisiti per l'installazione

Di seguito sono riportati i prerequisiti di installazione per l'archiviazione di file di dati di SQL Server in Azuree.

SQL Server locale: La versione di SQL Server 2014 include questa funzionalità. Per informazioni su come scaricare SQL Server 2014, vedere SQL Server 2014.
SQL Server in esecuzione in una macchina virtuale di Azure: se si installa SQL Server in una macchina virtuale di Azure, installare SQL Server 2014 o aggiornare l'istanza esistente. Analogamente, è anche possibile creare una nuova macchina virtuale in Azure usando l'immagine della piattaforma SQL Server 2014. Per informazioni su come scaricare SQL Server 2014, vedere SQL Server 2014.

Limitazioni

Nella versione corrente di questa funzionalità l'archiviazione dei FileStream dati in Archiviazione di Azure non è supportata. È possibile archiviare Filestream i dati in un database locale integrato di Archiviazione di Azure, ma non è possibile spostare i dati Filestream tra computer usando Archiviazione di Azure. Per FileStream i dati, è consigliabile continuare a usare le tecniche tradizionali per spostare i file (.mdf, ldf) associati a Filestream tra computer diversi.
Attualmente, questo nuovo miglioramento non supporta più istanze di SQL Server che accedono contemporaneamente agli stessi file di database in Archiviazione di Azure. Se ServerA è online con un file di database attivo e se ServerB viene avviato accidentalmente e dispone anche di un database che punta allo stesso file di dati, il secondo server non avvia il database con un codice di errore 5120 Impossibile aprire il file fisico "%.*ls". Errore del sistema operativo %d: "%ls".
Solo file con estensione .mdf, .ldf e .ndf possono essere archiviati in Archiviazione di Azure usando la funzionalità File di dati SQL Server in Azure.
Quando si usa la funzionalità File di dati di SQL Server in Azure, la replica geografica per l'account di archiviazione non è supportata. Se un account di archiviazione è con replica geografica e si è verificato un failover geografico, potrebbe verificarsi un danneggiamento del database.
Ogni BLOB può avere dimensioni massime di 1 TB. In questo modo viene creato un limite massimo per i singoli file di dati e di log del database che possono essere archiviati in Archiviazione di Azure.
Non è possibile archiviare In-Memory dati OLTP nel BLOB di Azure usando la funzionalità File di dati di SQL Server in Archiviazione di Azure. Ciò è dovuto al fatto che In-Memory OLTP ha una dipendenza da FileStream e, nella versione corrente di questa funzionalità, l'archiviazione dei dati FileStream in Azure Storage non è supportata.
Quando si usa la funzionalità File di dati di SQL Server in Azure, SQL Server esegue tutti i confronti tra URL o percorsi di file usando le regole di confronto impostate nel master database.
AlwaysOn Availability Groups sono supportati finché non si aggiungono nuovi file di database al database primario. Se un'operazione di database richiede la creazione di un nuovo file nel database primario, disabilitare prima di tutto i gruppi di disponibilità AlwaysOn nel nodo secondario. Eseguire quindi l'operazione di database nel database primario e eseguire il backup del database nel nodo primario. Ripristinare quindi il database nel nodo secondario e abilitare i gruppi di disponibilità AlwaysOn nel nodo secondario. Si noti che le AlwaysOn Failover Cluster Instances non sono supportate quando si utilizza la funzionalità File di dati di SQL Server in Azure.
Durante il normale funzionamento, SQL Server utilizza leasing temporanei per riservare i BLOB per l'archiviazione, con un rinnovo di ogni leasing di BLOB ogni 45 o 60 secondi. Se un server si arresta in modo anomalo e viene avviata un'altra istanza di SQL Server configurata per l'uso degli stessi BLOB, la nuova istanza attenderà fino a 60 secondi per la scadenza del lease esistente nel BLOB. Se si vuole collegare il database a un'altra istanza e non è possibile attendere che il lease scada entro 60 secondi, è possibile interrompere in modo esplicito il lease nel BLOB per evitare errori nelle operazioni di collegamento.

Supporto per strumenti e riferimenti alla programmazione

Questa sezione descrive gli strumenti e le librerie di riferimento di programmazione che è possibile usare per l'archiviazione di file di dati di SQL Server in Archiviazione di Azure.

Supporto di PowerShell

In SQL Server 2014 è possibile usare i cmdlet di PowerShell per archiviare i file di dati di SQL Server nel servizio Archiviazione BLOB di Azure facendo riferimento a un percorso URL di archiviazione BLOB anziché a un percorso di file. È possibile accedere ai BLOB usando il formato: http://storageaccount.blob.core.windows.net/<container>/<blob> url seguente.

Supporto degli oggetti e dei contatori delle prestazioni di SQL Server

A partire da SQL Server 2014, è stato aggiunto un nuovo oggetto SQL Server da usare con la funzionalità File di dati di SQL Server in Archiviazione di Azure. Il nuovo oggetto SQL Server viene chiamato SQL Server, HTTP_STORAGE_OBJECT e può essere usato da System Monitor per monitorare l'attività durante l'esecuzione di SQL Server con Archiviazione di Azure.

Supporto di SQL Server Management Studio

SQL Server Management Studio consente di usare questa funzionalità tramite diverse finestre di dialogo. Ad esempio, è possibile digitare il percorso URL del contenitore di archiviazione, ad esempio https://teststorageaccnt.blob.core.windows.net/testcontainer/ un percorso in diverse finestre di dialogo, ad esempio Nuovo database, Collega database e Ripristina database. Per altre informazioni, vedere Esercitazione: File di dati di SQL Server nel servizio Archiviazione di Azure.

Supporto di SQL Server Management Objects

Quando si usa la funzionalità File di dati di SQL Server in Azure, sono supportati tutti gli oggetti SMO (SQL Server Management Objects). Se un oggetto SMO richiede un percorso di file, usare il formato URL BLOB anziché un percorso di file locale, ad esempio https://teststorageaccnt.blob.core.windows.net/testcontainer/. Per altre informazioni su SQL Server Management Objects (SMO), vedere Guida alla programmazione di SQL Server Management Objects (SMO) nella documentazione online di SQL Server.

supporto Transact-SQL

Questa nuova funzionalità ha introdotto la modifica seguente nell'area superficiale Transact-SQL.

Nuova colonna int , credential_id, nella vista di sistema sys.master_files . La colonna credential_id viene utilizzata per consentire ai file di dati abilitati in Azure Storage di essere referenziati di nuovo a sys.credentials per le credenziali create per essi. È possibile usarlo per la risoluzione dei problemi, ad esempio una credenziale non può essere eliminato quando è presente un file di database che lo usa.

Risoluzione dei problemi relativi ai file di dati di SQL Server in Azure

Per evitare errori dovuti a funzionalità o limitazioni non supportate, vedere Limitazioni.

Di seguito è riportato l'elenco degli errori che possono verificarsi quando si usa la funzionalità File di dati di SQL Server in Archiviazione di Azure.

Errori di autenticazione

Impossibile eliminare la credenziale '%.*ls' perché viene usata da un file di database attivo.
Soluzione: è possibile che questo errore venga visualizzato quando si tenta di eliminare una credenziale ancora usata da un file di database attivo in Archiviazione di Azure. Per eliminare le credenziali, è prima necessario eliminare il BLOB associato con questo file di database. Per eliminare un BLOB con un lease attivo, è necessario prima interrompere il lease.
La firma di accesso condiviso non è stata creata correttamente nel contenitore.
Soluzione: assicurarsi di aver creato correttamente una firma di accesso condiviso nel contenitore. Esaminare le istruzioni fornite nella lezione 2 in Esercitazione: File di dati di SQL Server nel servizio Archiviazione di Azure.
Le credenziali di SQL Server non sono state create correttamente.
Soluzione: assicurarsi di aver usato "Firma di accesso condiviso" per il campo Identità e di aver creato correttamente un segreto. Esaminare le istruzioni fornite nella lezione 3 in Esercitazione: File di dati di SQL Server nel servizio Archiviazione di Azure.

Errori del BLOB di lease:

Errore durante il tentativo di avvio di SQL Server dopo l'arresto anomalo di un'altra istanza che usa gli stessi file BLOB. Risoluzione: Durante il normale funzionamento, SQL Server utilizza contratti di locazione temporanei per riservare i Blob per l'archiviazione, con il rinnovo di ciascun contratto di locazione ogni 45-60 secondi. Se un server si arresta in modo anomalo e viene avviata un'altra istanza di SQL Server configurata per l'uso degli stessi BLOB, la nuova istanza attenderà fino a 60 secondi per la scadenza del lease esistente nel BLOB. Se si vuole collegare il database a un'altra istanza e non è possibile attendere che il lease scada entro 60 secondi, è possibile interrompere in modo esplicito il lease nel BLOB per evitare errori nelle operazioni di collegamento.

Errori di database

Errori durante la creazione di un database
Soluzione: esaminare le istruzioni fornite nella lezione 4 in Esercitazione: File di dati di SQL Server nel servizio archiviazione di Azure.
Errori durante l'esecuzione dell'istruzione Alter
Soluzione: assicurarsi di eseguire l'istruzione Alter Database quando il database è online. Quando si copiano i file di dati in Archiviazione di Azure, creare sempre un BLOB di pagine, e non un BLOB di blocchi. In caso contrario, ALTER Database avrà esito negativo. Esaminare le istruzioni fornite nella lezione 7 in Esercitazione: File di dati di SQL Server nel servizio archiviazione di Azure.
Codice errore 5120 Impossibile aprire il file fisico "%.*ls". Errore del sistema operativo %d: "%ls"
Soluzione: attualmente questo nuovo miglioramento non supporta più istanze di SQL Server che accedono contemporaneamente agli stessi file di database in Archiviazione di Azure. Se ServerA è online con un file di database attivo e se ServerB viene avviato accidentalmente e ha anche un database che punta allo stesso file di dati, il secondo server non avvia il database con un codice di errore 5120 Impossibile aprire il file fisico "%.*ls". Errore del sistema operativo %d: "%ls".

Per risolvere questo problema, prima determina se hai bisogno che ServerA acceda al file di database in Azure Storage. In caso contrario, rimuovere semplicemente qualsiasi connessione tra ServerA e i file di database in Archiviazione di Azure. Per fare questo, segui questi passaggi:
1. Impostare il percorso del file del server A su una cartella locale usando l'istruzione ALTER Database.
2. Impostare il database offline nel server A.
3. Copiare quindi i file di database da Archiviazione di Azure alla cartella locale nel server A. In questo modo, ServerA ha ancora una copia del database in locale.
4. Mettere il database online.

Vedere anche

Esercitazione: File di dati di SQL Server nel servizio Archiviazione di Azure

Last updated on 2017-06-13

Condividi tramite