Emanuele Zanchettin - thinkIT

Implementare e mantenere un progetto Azure SQL Database

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)

Alcune caratteristiche di SQL Database

le basi non sono cambiate … +/-

SQLDatabase inside – Alta affidabilità

Database logicoDatabase

2° db fisico

3° db fisico

3° db fisico

1° db fisico

Copie multiple ridondate automatiche e failover automatico, disponibilità ottimizzata

Scale-outpartizionamento Orizzontale

PartizionamentoVerticale

Scale-up

Partizionamento dei dati - Scalabilità

Id val

Id val

Id val

Database

db più grande più dbs Federation / Elastic scale (es. app multi-tenant)

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 …

Altre considerazioni

• L’evoluzione del Servizio

t

f(x)

startieri

oggi

domani?

Non ci credi?

RIPSep. ‘15

Proviamo a calcolare il prezzo

La scelta consapevole

Service Tier / Performance

LevelDTU MAX DB Size Max Worker

Threads Max SessionsBenchmark Transaction

RatePredictability

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

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

Shard Map

• Due tipi di Shard Map– Range: intervalli elementi contigui– List: lista di valori

• Quattro tipi di chiavi– INT– BIGINT– GUID– VARBINARY

Split/Merge scenario

KeyShard Location

1 Database_A3 Database_B4 Database_C6 Database_B... ...

Key RangeShard 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

Si parte …

Qual’è il tuo caso?

Migrazione progetto esistente

tutto su cloud on premise + cloud (Ibrido)

Azure SQL Database

Nuovo progetto

tutto su cloud

Azure SQL Database

Prima pubblicazione

Sono pronto per farlo?

Strumenti per la migrazione

• Schema e datiSQL 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 schemaSQL Server Data Tools– da Microsoft Visual Studio 2012– da SQL Server 2012 usando .dacpac package

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

demo

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-SQLCommon 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

Pubblicazione delle revisioni

E ora?

GESTIRE SCHEMA E DATI

• Gestire ambienti di test e produzione

• Pianificare uno scenario di undo

• Cambiare lo schema e datiSQL 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

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

demo

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

Strategie di backup e restore

Non dimenticartelo!

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

Service Level Agreement (SLA)

Garanzie sul servizio fornito?

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 (MNU)SLO == SLA SLO < SLA

Links

• Migration from federation to elastic scaleazure.microsoft.com/en-us/documentation/articles/sql-database-elastic-scale-federation-migration/

• Azure SQL Database Elastic Scale Ch9channel9.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 pricingwww.windowsazure.com/it-it/pricing/details/sql-database/

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) Limitsmsdn.microsoft.com/en-us/library/jj590380.aspx

• Azure SQL Database Backup and Restoremsdn.microsoft.com/en-us/library/azure/jj650016.aspx

feedback

10

o Feedback su:

• http://xedotnet.org/feedback

Grazie!

Emanuele Zanchettin – thinkITEmail: ezanchettin@thinkit.itSite: http://www.thinkit.it/Twitter: @_thinkIT_LinkedIn: http

://it.linkedin.com/pub/emanuele-zanchettin/18/921/34