Questa sessione affronta come implementare, mantenere e far evolvere soluzioni sviluppate su Azure SQL Database, attraverso l’utilizzo degli strumenti SQL Sever Management Studio e Visual Studio. Attraverso esempi e casi reali, saranno illustrate la versatilità, potenza e affidabilità del database come servizio nel cloud.
2. Agenda
• Introduzione generale sull’infrastruttura
• La scelta responsabile
• Scenari di progetto
• Prima pubblicazione
• Pubblicazione delle revisioni
• Strategie di backup e restore
• Service Level Agreement (SLA)
4. SQLDatabase inside – Alta affidabilità
DatDabataasbea lsoegico
3° 1° db fisico
2° db fisico
3° db fisico
Copie multiple ridondate automatiche e failover automatico, disponibilità ottimizzata
5. SQLDatabase inside – Alta affidabilità
Database
Copie multiple ridondate automatiche e failover automatico, disponibilità ottimizzata
6. SQLDatabase inside – Alta affidabilità
1° db fisico
Database logico
2° db fisico
3° db fisico
Copie multiple ridondate automatiche e failover automatico, disponibilità ottimizzata
7. SQLDatabase inside – Alta affidabilità
1° db fisico
2° db fisico
3° db fisico
Database logico
Copie multiple ridondate automatiche e failover automatico, disponibilità ottimizzata
8. SQLDatabase inside – Alta affidabilità
3° db fisico
1° db fisico
2° db fisico
Database logico
Copie multiple ridondate automatiche e failover automatico, disponibilità ottimizzata
9. Partizionamento dei dati - Scalabilità
Scale-out
partizionamento Orizzontale
Partizionamento
Verticale
Scale-up
Database
Id val
Id val
Id val
db più grande più dbs Federation / Elastic scale (es. app multi-tenant)
10. Partizionamento dei dati - Scalabilità
Scale-out
partizionamento Orizzontale
Partizionamento
Verticale
Scale-up
Database
db più grande più dbs Federation / Elastic scale (es. app multi-tenant)
11. Partizionamento dei dati - Scalabilità
Scale-out
partizionamento Orizzontale
Partizionamento
Verticale
Scale-up
Id val
Id val
Id val
Database
db più grande più dbs Federation / Elastic scale (es. app multi-tenant)
12. Partizionamento dei dati - Scalabilità
Scale-out
partizionamento Orizzontale
Partizionamento
Verticale
Scale-up
Database
db più grande più dbs Federation / Elastic scale (es. app multi-tenant)
13. Considerazioni
Scale-up
– Tutto ok
Partizionamento Verticale
– Chiavi esterne tra databases diversi non ammesse
– Non è possibile avere transazioni tra databases
Nemmeno usando Microsoft Distributed Transaction Coordinator (MDTC lato
client)
Scale-out o partizionamento Orizzontale
– Nativo in Azure
– Modellazione schema
– Sviluppo e troubleshooting leggermente oneroso
– Elastic Scale (preview) … ciao ciao Federation …
15. Non ci credi?
RIP
Sep. ‘15
Proviamo a calcolare il prezzo
16. La scelta consapevole
Service Tier /
Performance
Level
DTU MAX DB Size
Max Worker
Threads
Max Sessions
Benchmark
Transaction
Rate
Predictability
Basic 5 2 GB 30 300 16.600/h
(4,6/s)
Good
Standard/S0 10 250 GB 60 600 521/min
(8,5/s)
Better
Standard/S1 20 250 GB 90 900 934/min
(15,6/s)
Better
Standard/S2 50 250 GB 120 1.200 2.570/min
(42,8/s)
Better
Premium/P1 100 500 GB 200 2.400 105/s Best
Premium/P2 200 500 GB 400 4.800 228/s Best
Premium/P3 800 500 GB 1.600 19.200 735/s Best
17. Evoluzione da Federation a Elastic Scale
(cenni)
• The Azure SQL Database Federations feature is being retired along with
the Web/Business editions in September 2015 (Cit.)
18. Shard Map
• Due tipi di Shard Map
– Range: intervalli elementi contigui
– List: lista di valori
• Quattro tipi di chiavi
– INT
– BIGINT
– GUID
– VARBINARY
24. Strumenti per la migrazione
• Schema e dati
SQL Server Migration Assistant (SSMA)
– da Oracle, Sybase, MySQL e Access
SQL Server Management Studio (SSMS)
– da SQL Server 2012 usando .bacpac package
SQL Database Migration Wizard (CodePlex)
– SQL Server 2008 R2 SP1 (v3x), SQL Server 2012 (v4x)
• Solo dati
– bcp, SSMS, SQL Data Sync, SSIS
• Solo schema
SQL Server Data Tools
– da Microsoft Visual Studio 2012
– da SQL Server 2012 usando .dacpac package
25. Caso reale di migrazione
• Strumento utilizzato: Migrate Data di SQL Server Migration
Assistant for MySQL
• Quantità: 6 tabelle, 9KK righe, 520MB dimensione totale
• Tempi: 26’ 30’’ upload parallelo, fibra 10Mbit/s
27. CONSIDERAZIONI
• Limitazioni sulle funzionalità
SQL Server Utility, SQL Server PowerShell Provider, Master Data Services, Change Data Capture, Data
Auditing, Data Compression, Extended Events, Extension of spatial types and methods through
Common Language Runtime (CLR), External Key Management / Extensible Key Management,
FILESTREAM Data, Integrated Full-Text Search, Large User-Defined Aggregates (UDAs), Large
User-Defined Types (UDTs), Performance Data Collection (Data Collector), Policy-Based Management,
Resource Governor, SQL Server Replication Transparent Data Encryption, Common Language
Runtime (CLR) and CLR User-Defined Types, Database Mirroring, Service Broker, Table Partitioning,
Typed XML and XML indexing (XML data type), Backup and Restore, Replication, Extended Stored
Procedures, SQL Server Agent/Jobs
• Limitazioni su T-SQL
Common Language Runtime (CLR), Database file placement, Database mirroring, Distributed
queries, Distributed transactions, Filegroup management, Global temporary tables, SQL Server
configuration options, SQL Server Service Broker, System tables, Trace Flags
• Documentazione disponibile online
• Pianifica prima di iniziare
29. GESTIRE SCHEMA E DATI
• Gestire ambienti di test e produzione
• Pianificare uno scenario di undo
• Cambiare lo schema e dati
SQL Server Management Studio (SSMS)
– da SQL Server 2012 usando .bacpac package
SQL Database Migration Wizard (CodePlex)
– SQL Server 2008 R2 SP1 (v3x), SQL Server 2012 (v4x)
• Cambiare solo dati
– bcp, SSMS, SQL Data Sync, SSIS
• Cambiare solo lo schema
– Microsoft Visual Studio 2012
30. Caso reale di upload federazione
• Strumento utilizzato:
Esporta dati di SQL Server
Management Studio
• Quantità:
3 tabelle, 8,6KK righe,
490MB dimensione totale
• Tempi:
10’ 15’’ download/upload
parallelo, fibra 10Mbit/s
32. Considerazioni
• DBA, Data Architect e sviluppatori, non litigate tra voi
• “Scalare” prima di raggiungere il limite
• Scegliere una pubblicazione passo-passo
• Pianificare prima di iniziare
34. Chi fa cosa?
• SQL Azure periodico mantenuto almeno 7 giorni
“as a safe guard against catastrophic software and system failures” !!!!
Backup Full settimanale, Differenziale giornaliero, Transaction Log ogni 5’
Storico 7gg (B), 14gg (S), 35gg (P)
Point in Time Restore, Restoring a Deleted Database, Geo-Restore
• Errori Utente (Business Continuity)
Usare SQL Data Sync (backup offline/remoto)
Copia di Database (CREATE DATABASE [destination] AS COPY OF [source])
Import/Export Service (Azure BLOB storage necessario, auto in preview)
Gruppo/Agente di sincronizzazione Azure (SQLDataSyncAgent solo x86 )
• Pianificare prima di iniziare