Nell'agosto 2015, ho scritto un articolo che introduceva la nuova funzionalità Stretch Database in SQL Server 2016. In quell'articolo, ho discusso come iniziare con Stretch Database in SQL Server 2016 Community Technology Preview 2 (CTP2). SQL Server 2016 è stato rilasciato il 1 giugno 2016 e sono stati apportati numerosi aggiornamenti al prodotto. Il metodo di configurazione di Stretch Database è leggermente cambiato così come alcune funzionalità.
A partire da SQL Server 2016 abbiamo acquisito la possibilità di archiviare parti di un database in un database SQL di Azure. Nelle anteprime precedenti, quando abilitavi Stretch per un database, dovevi migrare l'intera tabella, con la versione RTM di SQL Server 2016 ora puoi scegliere una parte di una tabella. Dopo aver abilitato l'estensione per una tabella, i tuoi dati verranno migrati silenziosamente. Se non si ha familiarità con Stretch Database, sfrutta la potenza di elaborazione in Azure per eseguire query sui dati remoti riscrivendo la query. Non è necessario riscrivere alcuna query da parte tua. Lo vedrai come un operatore di "interrogazione remota" nel piano di query.
Un modo semplice per identificare i database e le tabelle che possono essere abilitati per l'estensione consiste nel scaricare ed eseguire l'Assistente di aggiornamento di SQL Server 2016 ed eseguire l'Assistente per l'estensione del database. Aaron Bertrand (@AaronBertrand) ne ha scritto qualche tempo fa. L'Upgrade Advisor è leggermente cambiato rispetto al post di Aaron, tuttavia il processo è praticamente lo stesso:
- Identifica le tabelle candidate per allungare i database di SQL Server 2016
Limiti per l'estensione del database
Non tutti i tavoli potranno essere abilitati per l'estensione. Determinate proprietà di tabella, tipi di dati e colonne, vincoli e indici non sono supportati, ad esempio:
- Tabelle ottimizzate per la memoria e replicate
- Tabelle che contengono dati FILESTREAM, utilizzano il rilevamento delle modifiche o l'acquisizione dei dati delle modifiche
- Tipi di dati come timestamp, sql_variant, XML o geografia
- Verifica o vincoli predefiniti
- Limiti di chiave straniera che fanno riferimento alla tabella
- Indici columnstore XML, full-text, spaziali o cluster
- Viste indicizzate che fanno riferimento alla tabella
- Non è possibile eseguire istruzioni UPDATE o DELETE o eseguire operazioni CREATE INDEX o ALTER INDEX su una tabella abilitata per Stretch
Per un elenco completo delle limitazioni, puoi visitare:Requisiti e limitazioni per Stretch Database.
Configurazione di Stretch Database
Iniziare con la versione RTM è leggermente diverso rispetto alle anteprime precedenti. Avrai bisogno di un account Azure, quindi dovrai abilitare Stretch Database nell'istanza locale.
Per abilitare Stretch Database su un'istanza, esegui:
EXEC sys.sp_configure N'remote data archive', '1'; RECONFIGURE; GO
Per questa demo userò un database di esempio che ho creato chiamato STRETCH. Ho iniziato facendo clic con il pulsante destro del mouse sul database, scegliendo Attività, Allunga e quindi Abilita. Questo stava usando SQL Server 2016 Management Studio.
La schermata successiva ti offre quali tabelle desideri abilitare per Stretch:
Ho scelto il tavolo SALES2. Per impostazione predefinita, la procedura guidata è "Intera tabella", ma puoi anche modificare tale opzione per migrare un sottoinsieme di righe.
Se scegli per righe, devi selezionare un nome per i tuoi criteri, quindi puoi scegliere quale colonna utilizzare nella tua istruzione where, nonché la condizione e il valore. In questa schermata ho scelto le righe prima del 2016. Essere in grado di scegliere una parte di una tabella è un enorme miglioramento rispetto alle anteprime precedenti, che ti permettevano solo di allungare l'intera tabella. Per semplicità, in questa demo migrerò l'intera tabella, quindi ho fatto clic su Annulla e poi su Avanti.
Dopo aver selezionato le tabelle e le condizioni, devi scegliere quale sottoscrizione di Azure utilizzerai, la tua area di Azure e le informazioni sul tuo server.
Dopo aver inserito le informazioni richieste, fare clic su Avanti.
Un nuovo miglioramento consiste nell'usare la chiave master del database per proteggere le credenziali di Azure per la connessione ad Azure. Se non possiedi già una chiave maestra ti verrà chiesto di crearne una, se ne hai già una dovrai fornire la password. Fare clic su Avanti.
Dovrai creare una regola del firewall per il tuo server oppure puoi inserire un intervallo IP di sottorete. Effettua la tua selezione e fai clic su Avanti.
È qui che le cose sono davvero cambiate e mi farà riconsiderare l'utilizzo di questa funzione. Microsoft ha creato un'unità di estensione del database (DSU) in modo da poter aumentare o ridurre il livello di prestazioni necessario per i dati di estensione. A partire da giugno 2016, il prezzo corrente viene fatturato sia per il calcolo che per l'archiviazione, che vedi rappresentato nell'immagine sopra. Per la mia tabella da 15 MB di cui è stata eseguita la migrazione, mi sarebbero stati addebitati $ 61 USD al mese per l'archiviazione, nonché il livello minimo di DSU (100) a $ 912,50 al mese. I livelli di DSU variano da:
| Livello DSU | Costo orario | Costo mensile massimo (mesi con 31 giorni) |
|---|---|---|
| 100 | $ 1,25 | $930 |
| 200 | $ 2,50 | $ 1.860 |
| 300 | $ 3,75 | $ 2.790 |
| 400 | $ 5,00 | $ 3.720 |
| 500 | $ 6,25 | $ 4.650 |
| 600 | $ 7,50 | $ 5.580 |
| 1000 | $ 12,50 | $ 9.300 |
| 1200 | $ 15,00 | $ 11.160 |
| 1500 | $ 18,75 | $ 13.950 |
| 2000 | $ 25,00 | $ 18.600 |
Perché la procedura guidata mi ha detto solo $ 912,50, quando il foglio dei prezzi indica che dovrebbe essere $ 900 per giugno (o ripartito proporzionalmente in base a quanti giorni rimangono a giugno)? La tua ipotesi è buona quanto la mia; Ho provato varie cose di matematica e sono rimasto vuoto. Puoi saperne di più sui modelli di prezzo qui:
- Prezzi del database di allungamento di SQL Server
Prima di conoscere questo nuovo metodo di fatturazione per DSU, potrei argomentare che l'utilizzo di Stretch Database sarebbe un metodo molto conveniente per l'archiviazione di dati a freddo (dati inutilizzati) nel cloud. Estendendo questi dati in Azure, è possibile migrare un'ampia porzione di dati meno recenti, riducendo le dimensioni (e quindi il costo) dei backup locali. Nel caso in cui dovessi ripristinare un database, dovresti semplicemente stabilire la connessione ad Azure per i dati estesi, eliminando così la necessità di ripristinarlo. Tuttavia, con il costo minimo di quasi $ 1.000 al mese per la scala DSU di fascia bassa, molte organizzazioni scopriranno che è molto più economico conservare i dati su un livello di archiviazione meno costoso all'interno del loro data center e trovare altri metodi per HA come mirroring, log shipping o gruppi di disponibilità.
Fai clic su Fine per iniziare la migrazione.
Congratulazioni, ora ho migrato la tabella SALES2 in un database SQL di Azure
Disabilita una tabella Stretch
Nelle prime anteprime di Stretch Database, se si desidera disabilitare una tabella Stretch, è necessario creare una nuova tabella e inserire i dati stretch in essa. Una volta che tutti i dati sono stati copiati, dovresti cambiare manualmente le tabelle rinominandole o unendo manualmente i dati estesi nella tabella di produzione. Con la versione RTM, puoi comunque gestire manualmente la migrazione, scegliere di lasciare i dati in Azure o scegliere un'opzione per ripristinare i dati da Azure.
Indipendentemente dal metodo utilizzato per recuperare i dati, vengono addebitati costi di trasferimento dei dati.
Backup e ripristino di un database esteso
Dopo aver migrato i dati in un database Stretch, Azure gestisce il backup dei dati Stretch. I backup vengono eseguiti con uno snapshot eseguito ogni 8 ore e gli snapshot vengono mantenuti per 7 giorni. Questo ti dà fino a 21 punti nel tempo rispetto ai 7 giorni precedenti per il ripristino.
Non è necessario apportare modifiche alle routine di backup locali correnti. Qualsiasi backup locale eseguito conterrà tutti i dati locali e i dati idonei che non sono stati ancora migrati. Viene definito backup superficiale e non contiene dati già migrati in Azure.
DBCC CHECKDB
Inoltre, non è possibile eseguire CHECKDB sui dati che sono stati migrati in Azure.
Quando ho eseguito DBCC CHECKDB sul mio database STRETCH prima della migrazione, ho ottenuto i seguenti risultati per la tabella SALES2:
Risultati DBCC per "SALES2".Ci sono 45860 righe in 1901 pagine per l'oggetto "SALES2".
Dopo la migrazione, ho ricevuto il seguente output per la tabella SALES2 (enfasi mia):
Risultati DBCC per 'SALES2'.Ci sono 0 righe in 1901 pagine per oggetto "SALES2".
È possibile eseguire DBCC CHECKDB sul database SQL di Azure, tuttavia, poiché non è possibile connettersi direttamente al database SQL di Azure esteso, attualmente non è possibile eseguire manualmente DBCC CHECKDB in modo specifico sui dati estesi. Non riesco a trovare alcuna documentazione che indichi che Azure sta eseguendo controlli di coerenza su questi database.
Questo comporta un rischio significativo secondo me.
Riepilogo
Stretch Database è un modo semplice per migrare i dati di archivio in Microsoft Azure, se il database lo supporta. Attualmente in SQL Server 2016 RTM esistono molte limitazioni con proprietà di tabelle, dati e colonne, tipi di dati e colonne, vincoli e indici. Se non sei limitato da tali limitazioni, Stretch Database è un modo semplice per migrare i dati cronologici al database SQL di Azure per liberare spazio di archiviazione locale e ridurre i tempi di ripristino di tali database se la spesa lo rende utile. Devi anche sentirti a tuo agio, almeno per ora, con l'impossibilità di eseguire DBCC CHECKDB sui dati migrati. Anche la gestione dei ripristini sarà un po' più complicata in quanto è necessario ripristinare la connessione tra il database di SQL Server e il database di Azure remoto.
