Il documento discute l'implementazione e la gestione di Azure SQL Database, coprendo argomenti quali l'architettura dell'infrastruttura, le strategie di backup e restore, e le varie opzioni di scalabilità. Viene evidenziato il passaggio da federazioni a elastic scale e le considerazioni per una migrazione efficace, oltre a dettagli sulle limitazioni e le funzionalità da tenere a mente. Infine, sono forniti dettagli sui service level agreement e strumenti per migrazione e gestione dei dati.

1. Implementare e mantenere un progetto
Azure SQL Database
Emanuele Zanchettin - thinkIT

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)

3. Alcune caratteristiche di SQL Database
le basi non sono cambiate … +/-

4. SQLDatabase inside – Alta affidabilità
Database
Copie multiple ridondate automatiche e failover automatico, disponibilità ottimizzata

5. SQLDatabase inside – Alta affidabilità
1° db fisico
Database logico
2° db fisico
3° db fisico
Copie multiple ridondate automatiche e failover automatico, disponibilità ottimizzata

6. SQLDatabase inside – Alta affidabilità
1° db fisico
2° db fisico
3° db fisico
Database logico
Copie multiple ridondate automatiche e failover automatico, disponibilità ottimizzata

7. SQLDatabase inside – Alta affidabilità
3° db fisico
1° db fisico
2° db fisico
Database logico
Copie multiple ridondate automatiche e failover automatico, disponibilità ottimizzata

8. 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)

9. 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)

10. 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)

11. 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)

12. 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 …

13. Altre considerazioni
• L’evoluzione del Servizio
t
f(x)
start
ieri
oggi
domani?

14. Non ci credi?
RIP
Sep. ‘15
Proviamo a calcolare il prezzo

15. 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

16. 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.)

17. Shard Map
• Due tipi di Shard Map
– Range: intervalli elementi contigui
– List: lista di valori
• Quattro tipi di chiavi
– INT
– BIGINT
– GUID
– VARBINARY

18. Split/Merge scenario
Key Shard Location
1 Database_A
3 Database_B
4 Database_C
6 Database_B
... ...
Key Range Shard Location
[1, 50) Database_A
[50, 100) Database_B
[100, 200) Database_C
[400, 600) Database_C
... ...
• Alcuni comandi
– CreateShard 
– DeleteShard
– CreateRangeMapping
– CreatePointMapping
– DeleteMapping
– UpdateMapping
– MarkMappingOffline
– MarkMappingOnline

19. Si parte …
Qual’è il tuo caso?

20. Migrazione progetto esistente
Azure SQL Database
tutto su cloud on premise + cloud (Ibrido)

21. Nuovo progetto
Azure SQL Database
tutto su cloud

22. Prima pubblicazione
Sono pronto per farlo?

23. 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

24. 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

25. demo

26. 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 

27. Pubblicazione delle revisioni
E ora?

28. 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

29. 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

30. demo

31. 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 

32. Strategie di backup e restore
Non dimenticartelo!

33. 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 

34. Service Level Agreement (SLA)
Garanzie sul servizio fornito?

35. SLA
• 99,90% (W, BU) e 99,99% (B, S, P)
– Mensile, calcolo al minuto su inattività >= 1 minuto
• Limiti di sottoscrizione
• Carta di credito senza soldi
• Sforamenti di quota
• DTU (Database Throughput Units )
• Upgrade / Downgrade del Service tier
– SLO (Service Level Objective) e “la formula del male”
3 x (5 minutes + database size / 150 MB/minute)
Es. 3 x (5 minutes + 50 GB x 1024 MB/GB / 150 MB/minute) ≈17 hours
SLO < SLA  SLO == SLA  SLO > SLA  (MNU)

36. Links
• Migration from federation to elastic scale
azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-
scale-federation-migration/
• Azure SQL Database Elastic Scale Ch9
channel9.msdn.com/Shows/Data-Exposed/Azure-SQL-Database-Elastic-
Scale
• SQL Database Service Level Agreement (SLA)
www.windowsazure.com/it-it/support/legal/sla/
• SQL Database pricing
www.windowsazure.com/it-it/pricing/details/sql-database/

37. Links
• SQL Server Migration Assistant (SSMA)
blogs.msdn.com/b/ssma/
• Guidelines and Limitations (Windows Azure SQL
Database)
msdn.microsoft.com/en-us/library/windowsazure/ff394102.aspx
• Known SQL Data Sync (Preview) Limits
msdn.microsoft.com/en-us/library/jj590380.aspx
• Azure SQL Database Backup and Restore
msdn.microsoft.com/en-us/library/azure/jj650016.aspx

38. feedback
10
o Feedback su:
• http://xedotnet.org/feedback
Grazie!
Emanuele Zanchettin – thinkIT
Email: ezanchettin@thinkit.it
Site: http://www.thinkit.it/
Twitter: @_thinkIT_
LinkedIn: http://it.linkedin.com/pub/emanuele-zanchettin/18/921/34