Download as PDF, PPTX
![Controllo «Delayed Durability»
• Livello Database
• Livello «Atomic block» («Native Compilation»)
• Livello «Commit»
40
ALTER DATABASE … SET DELAYED_DURABILITY = { DISABLED | ALLOWED | FORCED }
CREATE PROCEDURE <procedureName> …
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER
AS BEGIN ATOMIC WITH
( DELAYED_DURABILITY = ON,
TRANSACTION ISOLATION LEVEL = SNAPSHOT,
LANGUAGE = N'English'
… )
END
COMMIT [ { TRAN | TRANSACTION } ] [ transaction_name | @tran_name_variable ] ]
[ WITH ( DELAYED_DURABILITY = { OFF | ON } ) ]](https://image.slidesharecdn.com/rdbms-pregiedifetti-181009215453/75/RDBMS-pregi-e-difetti-40-2048.jpg)
![«Row-Level Security»
63
Due
L’utente (es. l’infermiera) seleziona dalla tabella dei pazienti solo quelli che può vedere.
Tre
La «Security Policy» riscrive trasparentemente la query applicando il predicato.
Database Policy Manager
CREATE FUNCTION dbo.fn_securitypredicate(@wing int)
RETURNS TABLE WITH SCHEMABINDING AS
return SELECT 1 as [fn_securitypredicate_result] FROM
StaffDuties d INNER JOIN Employees e
ON (d.EmpId = e.EmpId)
WHERE e.UserSID = SUSER_SID() AND @wing = d.Wing;
CREATE SECURITY POLICY dbo.SecPol
ADD FILTER PREDICATE dbo.fn_securitypredicate(Wing) ON
Patients
WITH (STATE = ON)
Filter
Predicate:
INNER
JOIN…
Security
Policy
Application
Patients
Uno
Gestore delle policy crea un predicato in T-SQL per filtrare i dati in base all’identificativo utente e crea
«security policy» che vincola tale predicato alla tabella dei pazienti.
Nurse
SELECT * FROM Patients
SELECT * FROM Patients
SEMIJOIN APPLY dbo.fn_securitypredicate(patients.Wing);
SELECT Patients.* FROM Patients,
StaffDuties d INNER JOIN Employees e ON (d.EmpId = e.EmpId)
WHERE e.UserSID = SUSER_SID() AND Patients.wing = d.Wing;](https://image.slidesharecdn.com/rdbms-pregiedifetti-181009215453/75/RDBMS-pregi-e-difetti-63-2048.jpg)
Uploaded byGianluca Hotz
RDBMS: pregi e difetti
Il documento discute il modello relazionale per la gestione dei dati, enfatizzando le sue caratteristiche, come la struttura basata su relazioni e il linguaggio SQL. Si esplorano inoltre le differenze tra vari tipi di database, le transazioni e le proprietà ACID, nonché l'importanza della definizione di uno schema. Infine, si affrontano le problematiche legate alla flessibilità e all'integrità dei dati nei database relazionali.
![noSQL La nuova frontiera dei Database [DB05-S]](https://cdn.slidesharecdn.com/ss_thumbnails/db05-ssiracusa05-03-2016-160304154822-thumbnail.jpg?width=640&height=640&fit=bounds)
RDBMS: pregi e difetti
- 1. www.xedotnet.org RDBMS: pregi edifetti Gianluca Hotz @glhotz | Presidente UGISS.ORG | Data Platform MVP
- 2. Chi sono • GianlucaHotz | @glhotz | ghotz@ugiss.org • Fondatore e Mentor SolidQ • 20+ anni con SQL Server (dalla 4.21 nel 1996) • Modellazione basi di dati, dimensionamento e amministrazione, sviluppo, ottimizzazione • Interessi • Modello relazionale, architettura DBMS, alta disponibilità e Disaster Recovery • Community • 20 anni Microsoft MVP SQL Server (dal 1998) • Fondatore e presidente UGISS • User Group Italiano SQL Server (PASS Chapter) 2
- 3. Gestione delle Informazioni •Modello dati • Logico? Fisico? Entrambi? • Data Store specializzati • Document? Key-Value? Column-Oriented (Columnar)? Graph? • Interrogazione • Dichiarativa? Imperativa? Mix? • Funzioni accessorie • Gestione transazioni? Persistenza? Concorrenza? Consistenza? Replica? Sharding? • Terminologia poco chiara e in continuo mutamento… • Relational? SQL? NoSQL? NewSQL? • DBMS? RDBMS? ORDBMS? 3
- 4. Modello Relazionale • Modelloper la gestione dei dati dichiarativo • per specificare i dati (schema e valori) • per specificare interrogazioni (query) • struttura e linguaggio basati su logica dei predicati • puramente logico/concettuale • Nato per sopperire a limitazioni modelli • «Hierarchy» • «Network» • Letteratura storicamente molto formale • Prima descrizione di Edgar F. Codd (1969) • Molti libri anche recenti Christopher J. Date • Moltissimi «paper» accademici (50 anni) 4
- 5. Cos’è un databaserelazionale? • Collezione strutturata di fatti • sottoinsieme di fatti: del mondo reale, di interesse • Rappresenta proposizioni considerate vere • assiomi • Permette di derivare nuove proposizioni • tramite regole formali di inferenza 5 https://en.wikipedia.org/wiki/Fabian_Pascal
- 6. Proposizioni e predicato •Esempio: database per dati relativi a prenotazioni • Fatti (proposizioni) • La prenotazione identificata dal numero 990000, per la stanza 333, prevede la data di arrivo 29/10/2006 e la data di partenza 01/11/2006. • La prenotazione identificata dal numero 990001, per la stanza 275, prevede la data di arrivo 27/10/2006 e la data di partenza 01/11/2006. • Forma generalizzata (predicato) • La prenotazione identificata dal numero (IDPrenotazione), per la stanza (NumStanza), prevede la data di arrivo (DataArrivo) e la data di partenza (DataPartenza). 6
- 7. Basi del modellorelazionale • Concetto di relazione • non è la traduzione di relationship del modello E/R! • Relazione matematica • sottoinsieme del prodotto cartesiano di domini • insieme di n-uple • (v1, v2, ..., vn) con v1 D1, v2 D2, …, vn Dn • n-uple ordinate all’interno (stesso ordine dei domini) • Relazione nel modello relazionale • n-uple (tuple) non sono ordinate all’interno • riferimento per nome (attributi) 7
- 8. Dati nel modellorelazionale • Consideriamo i domini • D1 = costituito da numeri interi • D2 = costituito da numeri interi • D3 = costituito da date • D4 = costituito da date • Alcune possibili relazioni su D1, D2, D3, D4 • {(990000, 333, 29/10/2006, 01/11/2006)} • {(990000, 333, 29/10/2006, 01/11/2006), (990001, 275, 27/10/2006, 30/10/2006)} 8
- 9. Rappresentazione con tabelle •Una tabella per ogni variabile di tipo relazione • Nomi degli attributi sono intestazioni delle colonne • Colonne non sono ordinate • Righe sono n-uple (tuple) di valori non ordinate • Righe distinte una dall’altra • in un insieme non possono essere presenti due valori uguali • una tabella rappresenta una relazione se le righe sono l’una diversa dall’altra 9
- 10. Relazioni e predicato •Relazione rappresenta un predicato • interpretazione di una porzione del mondo reale di interesse • Istanza del predicato • sostituendo le variabili con i valori delle tuple otteniamo una proposizione sempre vera per convenzione 10
- 11. Rappresentazione logica • Predicato •La prenotazione identificata dal numero (IDPrenotazione), per la stanza (NumStanza), prevede la data di arrivo (DataArrivo) e la data di partenza (DataPartenza). • Relazione • {(990000, 333, 29/10/2006, 01/11/2006), (990001, 275, 27/10/2006, 30/10/2006)} 11 IDPrenotazione NumStanza DataArrivo DataPartenza 990000 333 2006-10-29 2006-11-01 990001 275 2006-10-27 2006-10-30
- 12. Implementazione reale RDBMS •12 regole di Codd • https://en.wikipedia.org/wiki/Codd%27s_12_rules • non tutti aderiscono a tutte… • indipendenza: fisica, logica, integrità, distribuzione • Linguaggio SQL • «approssimazione ingegneristica» • basato sul calcolo relazionale 12
- 13. Proprietà ACID • Nonstrettamente legate al modello relazionale • Proprietà gestione transazioni desiderabili • Atomicità • transazione eseguita in modo indivisibile (tutto o niente) • Consistenza (o coerenza) • database deve essere coerente con i vincoli e non contraddittorio prima e dopo l’esecuzione della transazioni • Isolamento • livello di interferenza tra transazioni in esecuzione contestuale • Durabilità (o persistenza) • le modifiche confermate devono essere persistite in modo permanente (nessun guasto successivo potrà determinare la perdita dei cambiamenti) 13 https://en.wikipedia.org/wiki/ACID
- 14. Implementazione fisica SQLServer • Tabelle • Heap • B+Tree • Columnstore • Hash (In-Memory Tables) • Indici • B+Tree • Full-text • XML • Spatial • Columnstore • BW-Tree 14
- 15. T-SQL: linguaggio dichiarativo •Specificando il «cosa» al posto del «come» • lascia spazio a continui miglioramenti del «come» • Ottimizzatore delle Query • Interpretazione richieste complesse • equivalenze logiche, individuazione contraddizioni, … • Ottimizzazione piano di esecuzione • algoritmi, parallelismo, utilizzo di indici, … • Riutilizzo dei piani di esecuzione • anche in modalità adattiva 15
- 16. Esempio: divisione Relazionale •Trovare sottoinsieme di… • competenze richieste dai candidati per un lavoro • aree geografiche dove diversi clienti/fornitori operano • componenti condivisi da diverse distinte base • prodotti venduti insieme in ordini distinti 16 Dividendo Divisore Risultato Resto Credits: https://www.slideshare.net/davidemauri/schema-less-table-dynamic-schema-44295422
- 17.
- 18. «Schema» • Definizione apriori di una struttura dati • Modifiche ai dati solo se conformi a schema • Esempi • Tabelle (e vincoli) di un RDBMS • XML Schema • Class, Struct 18
- 19. «Schema-less» • Nessuna definizione,caos completo ☺ • Solitamente «Schema» implicito • sparso nelle applicazioni e definito «al volo» • semplice da estendere ma… • …mantenimento vincoli problematico! • Integrità dei dati è un valore! • altrimenti abbiamo dati non informazioni ☺ • senza integrità estrarre informazioni dai dati diventa • difficile • dispendioso • inaffidabile 19
- 20. «Schema» e assenzainformazioni • A-Mark • valore applicabile ma assente • es. no carta identità durante inserimento anagrafica • I-Mark • valore inapplicabile • es. data ultima gravidanza paziente maschio • Gestione tramite il singolo marker NULL • problemi logica TRUE, FALSE, UNKNOWN 20
- 21. «Schema» in SQLServer • Ricchezza tipi dato complessi • XML, GEOMETRY, GEOGRAPHY, HIERARCHYID, FILESTREAM, FILETABLE, JSON • estensibile con integrazione CLR • Integrazione SQL (XPATH/XQUERY, funzioni JSON) • Vincoli dichiarativi • NULL/NOT NULL, DEFAULT, CHECK • PRIMARY KEY, FOREIGN KEY • «XML Schema Collection» • Vincoli procedurali • «After Trigger» • «Instead of Trigger» 21
- 22.
- 23. Valori inapplicabili • Rimuovibilicon modello semanticamente più ricco • Utilizzo di generalizzazioni/specializzazioni Product PK ProductID ProductType ProductName Camera PK,FK1 ProductID CameraFormat Resolution ZoomWide ZoomTele MemoryCard PK,FK1 ProductID MemoryCardType StorageSizeGB MobilePhone PK,FK1 ProductID ROMSizeMB RAMSizeMB 23
- 24. Rigidità «Schema» • Spessoproblema riguarda estensibilità • sottoinsieme noto e stabile di attributi • agilità nell’aggiungere ulteriori attributi • anche noto come «Open Schema» o «Dynamic Schema» • Diversi approcci • Aggiunta di colonne specifiche • Incapsulamento • Modello EAV 24
- 25. Aggiunta di colonne •Richiede una modifica allo schema • ALTER TABLE • possibile impatto su applicazioni (es. SELECT *) • possibile impatto disponibilità/prestazioni • consumo spazio senza «Sparse Columns» • «Sparse Columns» • disponibili a partire da SQL Server 2008 • non consumano spazio se non valorizzate ☺ • consumano più spazio se valorizzate • materializzazione colonna XML con attributi valorizzati 25
- 26. Incapsulamento • Colonne ditipo strutturato complesso • BLOB • stream binario o tipi implementati con CLR • utile principalmente per persistenza, nessun supporto • XML • supporto completo con XML Schema, indici, linguaggio • prestazioni buone ma non ottimali • utilizzano molto spazio • JSON • materializzazione colonne calcolate e indicizzazione • svariate ottimizzazioni con «memory optimized» 26
- 27. Modello EAV • «EntityAttribute Value» • tecnica molto vecchia, funziona con tutti gli RDBMS • massima flessibilità, minima ricchezza semantica • controllo tipi dato limitato • tutte stringhe, un campo per tipo, tipo «SQL Variant» • query complesse/poco performanti • «One True Lookup Table» • variante solo per tabelle di «Lookup» (ma cosa sono?) • Approccio ibrido 27 Product PK ProductID ProductType ProductName ProductEAV PK,FK1 ProductID PK ProductPropertyName ProductPropertyValue https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model
- 28.
- 29.
- 30. Graph Processing Concepts •Node Table • Represent an entity • Edge Table • Represent many-to-many relationship • May have properties • Is directed, connects two nodes • MATCH T-SQL Command • Search condition for graph objects • Pattern matching and traversal
- 31. Graph Processing Limitations •Local/global temporary tables not supported • Table types/variables not supported • System-versioned temporal tables not supported • Memory optimized tables not supported • Can’t update connected nodes of an edge using UPDATE • insert new edge pointing to different nodes • delete previous edge • Cross database queries on graph objects not supported
- 32.
- 33. Transazioni in SQLServer • Transazioni esplicite • comando BEGIN TRANSACTION • comando COMMIT/ROLLBACK TRANSACTION • Transazioni implicite • a livello di singolo comando • opzione SET IMPLICIT_TRANSACTIONS ON • Transazioni nidificate • Punti di salvataggio • Controllo immediato • rollback dipende dalla criticità dell’errore 33
- 34. Log delle transazioni •Garantisce le proprietà di • Atomicità • Durabilità (persistenza) • WAL («Write Ahead Logging») • Scrive le modifiche prima nel log e poi in memoria • Meccanismi asincroni consolidano modifiche nei file dati • «Checkpoint», «Lazy Writer», manutenzione della cache • Basato su ARIES • «Algorithms for Recovery and Isolation Exploiting Semantics» • Comprese ottimizzazioni • «No force on commit» (full recovery model) • «Force on commit» (bulk logged recovery model) • http://www.sai.msu.su/~megera/postgres/gist/papers/concurr ency/p94-mohan.pdf 34
- 35. Log transazioni e«Recovery» • «Crash Recovery» (ripresa a caldo) • alla ripartenza del servizio, per ogni database • ripristino transazioni confermate • annullamento transazioni non confermate • «Media Recovery» (ripristino a freddo) • al termine del «restore» • ripristino anche del log delle transazioni • Esecuzione della ripresa a caldo 35
- 36. Ripresa a caldoe «Checkpoint» 36 Ripristino transazioni Nulla da fare Checkpoint Guasto del sistema 1 2 3 4 5 Roll forward Roll back Roll forward Roll back
- 37. Ripresa a caldoottimizzata 37 VuotaHOT DisponibileNon disponibile Analisi Database Cache Redo Undo Database:
- 38. «Delayed Durability» • Transazionepuò essere • «Fully Durable» • protocollo WAL tradizionale, commit sincrono • «Delayed Durable» • AKA «lazy commit» o commit asincrono • «Eventual Durability» ☺ • record Transaction Log mantenuti nel buffer • buffer scritto quando pieno o evento di «Flush» • possibile perdita della transazione! • in modo consistente • Applicazione deve tollerare la perdita di dati! 38
- 39. «Delayed Durability Flush» •Buffer Transaction Log pieno • Commit transazione «fully durable» • stesso database • Esecuzione manuale procedura sp_flush_log • Attenzione! Shutdown SQL Server • potrebbe non scrivere il buffer • va trattato come un possibile evento di perdita dati 39
- 40. Controllo «Delayed Durability» •Livello Database • Livello «Atomic block» («Native Compilation») • Livello «Commit» 40 ALTER DATABASE … SET DELAYED_DURABILITY = { DISABLED | ALLOWED | FORCED } CREATE PROCEDURE <procedureName> … WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER AS BEGIN ATOMIC WITH ( DELAYED_DURABILITY = ON, TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'English' … ) END COMMIT [ { TRAN | TRANSACTION } ] [ transaction_name | @tran_name_variable ] ] [ WITH ( DELAYED_DURABILITY = { OFF | ON } ) ]
- 41. Isolamento delle transazioni •Idealmente: serializzazione delle transazioni • massima consistenza • minor concorrenza • Se le transazioni non sono coordinate • perdita di aggiornamenti (lost updates) • Se transazioni sono parzialmente isolate • letture inconsistenti («dirty reads») • letture non ripetibili («non-repeatable reads») • letture fantasma («phantoms») • conflitto in aggiornamento («update conflict») 41
- 42. Perdita di aggiornamenti •Aggiornamento non sincronizzato 42 T2 T1 Tempo X=10 Legge X (10) Legge X (10) Calcola X=X+10 (20) Calcola X=X+15 (25) Scrive X X=20 X=25X=25 Scrive X
- 43. Letture inconsistenti • T2vede le modifiche non confermate di T1 43 Calcola X=X+15 (25) T2 T1 Tempo X=10 Legge X (25) Legge X (10) X=25 Scrive X X=10 Rollback Utilizza il valore di X che non è mai stato confermato
- 44. Letture non ripetibili •Lettura successiva inconsistente 44 T2 T1 Tempo X=10 Legge X (10) Legge X (10) Calcola X=X+15 (25) X=25 Scrive X Commit Legge X (25)
- 45. Letture fantasma • Letturaintervallo successiva inconsistente 45 Part3, 50 Insert Select count (*) where cost > 30 (2) T2 T1 Tempo Part1,40 Part2, 70 Part3, 50 Part1,40 Part2, 70 Select count (*) where cost > 30 (3)
- 46. Livelli di isolamentoin SQL Server • 4 livelli supportati per standard ANSI • «Read Uncommitted», «Read Committed», «Repeatable Read», «Serializable» • Predefinito «Read Committed» in due modalità • pessimistico, usa protocollo di «Locking» • ottimistico, usa «Row Versioning» • Aggiunta di un ulteriore livello «Snapshot» • simile a «Serializable» ma ottimistico in scrittura • genera errore alla «Commit» in caso di conflitto 46
- 47. Gestione dei «Lock» •Tipologie di lock • Condivisi (S) • Esclusivi (X) • Aggiornamento (U) • Intenzione (I) • Granularità • Riga/chiave • Intervallo tra chiavi • Pagina • Tabella • «Extent» • Database 47 Tabella Pagina Pagina Pagina Riga Riga Riga
- 48. Compatibilità «Lock» • Sottoinsiemedella matrice di compatibilità 48 Lock richiesto IS S U IX X SchS SchM BU IS Si Si Si Si No Si No No S Si Si Si No No Si No No U Si Si No No No Si No No IX Si No No Si No Si No No X No No No No No Si No No SchS Si Si Si Si Si Si No Si SchM No No No No No No No No BU No No No No No Si No Si Lock già rilasciato
- 49. «Read Committed» (pessimistico) 49 CREATETABLE t1 ( c1 int unique, c2 int) INSERT INTO t1 VALUES (1, 5) Transazione 1 BEGIN TRAN UPDATE t1 SET c2 = 9 WHERE c1 = 1 COMMIT TRAN Tempo Transaction 2 (Read Committed) BEGIN TRAN SELECT c2 FROM t1 WHERE c1 = 1 -- SQL Server risponde 9 COMMIT TRAN Bloccato!
- 50. «Read Committed Snapshot»(ottimistico) 50 CREATE TABLE t1 ( c1 int unique, c2 int) INSERT INTO t1 VALUES (1, 5) Transazione 1 BEGIN TRAN UPDATE t1 SET c2 = 9 WHERE c1 = 1 COMMIT TRAN Tempo Transaction 2 (Read Committed Snapshot) BEGIN TRAN SELECT c2 FROM t1 WHERE c1 = 1 -- SQL Server risponde 5 SELECT c2 FROM t1 WHERE c1 = 1 -- SQL Server risponde 9 COMMIT TRAN
- 51. «Snapshot» (in lettura) 51 CREATETABLE t1 (c1 int unique, c2 int) INSERT INTO t1 VALUES (1, 5) Transazione 2 (Snapshot Isolation) SET TRANSACTION ISOLATION LEVEL SNAPSHOT BEGIN TRAN SELECT c2 FROM t1 WHERE c1 = 1 -- SQL Server risponde 5 SELECT c2 FROM t1 WHERE c1 = 1 -- SQL Server risponde 5 COMMIT TRAN SELECT c2 FROM t1 WHERE c1 = 1 -- SQL Server risponde 9 Transazione 1 BEGIN TRAN UPDATE t1 SET c2 = 9 WHERE c1 = 1 COMMIT TRAN Tempo
- 52. «Snapshot» (in aggiornamento) 52 Tempo CREATETABLE t1 ( c1 int unique, c2 int) INSERT INTO t1 VALUES (1,5) transazione 1 (Snapshot Isolation) SET TRANSACTION ISOLATION LEVEL SNAPSHOT BEGIN TRAN SELECT c2 FROM t1 WHERE c1 = 1 -- SQL Server risponde 5 UPDATE t1 SET c2 = 15 WHERE c1 = 1 Transazione 2 BEGIN TRAN UPDATE t1 SET c2 = 9 WHERE c1 = 1 COMMIT TRAN Bloccato! Rollback perché conflitto tra aggiornamenti
- 53. Livelli, fenomeni, concorrenza 53 Livellidi isolamento Dirty Read Non- Repeatable Read Phantoms Update Conflict Modello concorrenza Read Uncommitted Si Si Si No Read Committed 1 Locking 2 Snapshot No No Si Si Si Si No No Pessimistico Ottimistico Repeatable Read No No Si No Pessimistico Snapshot No No No Si Ottimistico Serializable No No No No Pessimistico Fenomeni permessi
- 54. Scelta livello diisolamento • Mediazione • livello alto: più consistenza, meno prestazioni • livello basso: meno consistenza, più prestazioni • Modello pessimistico o ottimistico? • dipende… quasi sempre va bene ottimistico • è bene censire gli altri casi • Scelta in base alle necessità applicative! • non alle prestazioni! 54
- 55. Altri problemi «ReadCommitted» • «Shared Lock» rilasciati durante «scan» • Righe possono muoversi fisicamente • Es. aggiornamento indice «Clustered» • Fenomeni problematici • Rilettura stessa riga • Mancata lettura di una riga 55
- 56. «Deadlock» (blocco critico) •Evento normale • tecniche per mitigarne la frequenza • non sempre si possono eliminare completamente • Risoluzione automatica • controllo cicli ad intervalli regolari • transazione meno costosa per annullamento viene scelta come vittima («rollback») • controllo più frequente quando si verificano «Deadlock» • Applicazioni • ricevono errore 1205 • devono gestire il problema, es. riprovando 56
- 57. Minimizzare i «Deadlock» •Usare livello di isolamento appropriato • Verificare possibilità di usare livelli «Snapshot» • Controllare gli indici • Controllare normalizzazione della base dati • Le transazioni dovrebbero • durare poco • non richiedere interazione con utente • accedere alle risorse nello stesso ordine 57
- 58. «Cycle Deadlock» • Coinvolgepiù risorse • Processi si bloccano a vicenda in modo ciclico 58 Resource Granted Lock Resource Granted Lock SPID 1 SPID 2 Waiting Lock Waiting Lock
- 59. «Conversion Deadlock» • Coinvolgeuna risorsa • Entrambi i processi hanno un «Lock» sulla risorsa • tipicamente «Shared» • con livello di isolamento più alto di «Read Committed» • Entrambi cercano di convertire il «Lock» • con uno incompatibile 59 Resource SPID 2SPID 1 Granted Lock Granted Lock Convert Convert
- 60. «Security Layering» 60 Data Encryption Data Access Access Control Proactive monitoring • TransportLayer Security (in transit) • Transparent Data Encryption (at rest) • Cell-Level Encryption (at rest) • Always Encrypted (at rest and in transit) Data Encryption • Dynamic Data Masking • Row-Level Security Data Access • Encrypted Authentication • SQL Firewall* Access Control • Auditing • Threat Detection* Proactive monitoring
- 61. Autenticazione • Due livelli:Server login e Database User • Nativa SQL Server • Integrata con Active Directory • Utilizza protocollo Kerberos • Supporto Azure Active Directory • Supporto Active Directory Universal Authentication • Multi-factor Authentication (es. via telefono) • Supportata solo con SSMS a partire dalla versione 17 61
- 62. Autorizzazioni • Permessi granulari •GRANT cosa può fare ON su che oggetto TO chi • Ereditarietà gerarchia di oggetti • Assegnazione (GRANT), negazione (DENY), revocare (REVOKE) • Row Level Security • Ruoli a livello di server e database • Es. sysadmin, dbcreator, db_datareader, db_datawriter • Specifici per alcune funzionalità (database msdb) • Principio guida: minor privilegio! • Possibile elevare temporaneamente • Impersonation • Stored Procedure (in generale moduli T-SQL firmati) 62
- 63. «Row-Level Security» 63 Due L’utente (es.l’infermiera) seleziona dalla tabella dei pazienti solo quelli che può vedere. Tre La «Security Policy» riscrive trasparentemente la query applicando il predicato. Database Policy Manager CREATE FUNCTION dbo.fn_securitypredicate(@wing int) RETURNS TABLE WITH SCHEMABINDING AS return SELECT 1 as [fn_securitypredicate_result] FROM StaffDuties d INNER JOIN Employees e ON (d.EmpId = e.EmpId) WHERE e.UserSID = SUSER_SID() AND @wing = d.Wing; CREATE SECURITY POLICY dbo.SecPol ADD FILTER PREDICATE dbo.fn_securitypredicate(Wing) ON Patients WITH (STATE = ON) Filter Predicate: INNER JOIN… Security Policy Application Patients Uno Gestore delle policy crea un predicato in T-SQL per filtrare i dati in base all’identificativo utente e crea «security policy» che vincola tale predicato alla tabella dei pazienti. Nurse SELECT * FROM Patients SELECT * FROM Patients SEMIJOIN APPLY dbo.fn_securitypredicate(patients.Wing); SELECT Patients.* FROM Patients, StaffDuties d INNER JOIN Employees e ON (d.EmpId = e.EmpId) WHERE e.UserSID = SUSER_SID() AND Patients.wing = d.Wing;
- 64. «SQL Server Audit» •Definizione gruppi di azioni da tracciare • Server • Database • Target • File • Windows Log • Disponibile con tutte le edizioni • a partire da SQL Server 2016 Service Pack 1 • Implementazione diversa per Azure SQL Database
- 65. «Policy Based Management» •Infrastruttura per • Definizione «policy» • Controllo conformità installazione con «policy» • Serie di «policy» conformi a Best Practice • Categoria di policy per sicurezza! • Enterprise Policy Management Framework • http://aka.ms/epmframework
- 66. Change Data Capture •Soluzione tradizionale Audit modifiche dati? • Trigger! Ma… • …complessità, prestazioni… • CDC cattura automaticamente modifiche • Pensato principalmente per caricare DWH • Genericamente va bene per tenere storico modifiche
- 67. Modifiche Database Temporali «Temporaltable» (dati correnti) Insert / Bulk Insert * Versioni vecchie Update */ Delete * «History table»
- 68. Interrogazioni Database Temporali «Temporaltable» (dati correnti) Query temporali * FOR SYSTEM_TIME ALL, AS OF, BETWEEN … AND …, FROM … TO, CONTAINED IN «History table» Query normali (dati correnti) * Include versioni storiche
- 69. Introduzione alta disponibilità •Alta disponibilità è una combinazione di • architettura (design) • persone • processi • tecnologia • Alta disponibilità non è • solamente una soluzione tecnologica • sinonimo di scalabilità 69
- 70. Significato di indisponibilità •Esempi di indisponibilità completa • manutenzione del server • problemi non programmati • attacchi DOS, malfunzionamenti hardware • tempo per implementare una tecnologia • «restore» di uno i più database • Esempi di indisponibilità percepita • lentezza degli applicativi • DBMS disponibile, mid-tier non disponibile • problemi di rete • rilascio nuove versioni degli applicativi 70
- 71. Valutazione requisiti HA •Rilevazione guasti automatica o manuale • Failover automatico o manuale • Tempo di «failover» e di «failback» • Numero guasti a cui può sopravvivere il sistema • Granularità • istanza, database, tabella, riga 71
- 72. Valutazione impatti HA •Perdita di dati • tutti dicono perdita zero, ma in caso di disastro reale solitamente ci sono dei margini • Consistenza dei dati • Complessità • implementazione • gestione • Costo di sistemi ridondati • hardware, gestione • Impatto sugli applicativi 72
- 73. Opzioni di «Standby» •«Hot standby» • nodo secondario mantiene una copia dei dati • dati consistenti (transazioni sincrone) • rilevazione guasti e «failover» automatici • «Warm standby» • nodo secondario mantiene una copia dei dati • dati non consistenti (transazioni asincrone) • rilevazione guasti e «failover» automatici o manuali • «Cold standby» • nodo secondario configurato ma nessuna copia • rilevazione guasti e «failover» manuali 73
- 74. «Backup & Restore» •Diverse tipologie di Backup • Completo • Differenziale • Del log delle transazioni (incrementale) • Granularità • Database • «Filegroup» • «Data File» • Ripristino • Completo • «Point in time» 74
- 75. «Full Backup» • Salvataggiocompleto di tutti i dati • tutte le pagine di tutti i file • catalogo di sistema (tabelle primary filegroup) • include il log delle transazioni • backup consistente con l’orario in cui termina • baseline di partenza per la ripresa a freddo (restore) 75
- 76. Strategia «Full Backup» 76 DomenicaLunedì Martedì Data Log Data Log Data Log Guasto! Full Database Backup Full Database Backup Full Database Backup Restore Transazioni non recuperabili Orario d’inizio Orario di fine
- 77. «Log Backup» • Salvataggiolog delle transazioni • contiene tutte le transazioni dall’ultimo backup del log • backup del log costituiscono una catena di backup • applicare in fase di ripristino per riportare a uno stato consistente • catena si estende da • backup completo • backup parziale • set completo backup di file • svuota il log fino alla porzione attiva • fino al virtual log che contiene la transazione attiva più vecchia • Supportato per i recovery model full o bulk-logged • in modalità bulk, backup può essere più voluminoso 77
- 78. Strategia «Log Backup» 78 DomenicaLunedì Full Database Backup Log Log Log Log Data Log Data Log Full Database Backup Guasto! Restore Restore Restore Backup coda del log Nessuna transazione persa
- 79. «Full Backup» e«Recovery Model» non Simple 79 Domenica Lunedì Martedì Data Log Data Log Data Log Guasto! Full Database Backup Full Database Backup Full Database Backup Restore Backup coda del log Orario d’inizio Orario di fine Log Restore Nessuna transazione persa 79
- 80. Strategia «Full +Differential + Log» 80 Lunedì Martedì Full Database Backup Differential Backup Differential Backup ...Log Data Log Log Log Log Log Log Guasto! Restore Restore Log Backup coda del log Restore Restore Nessuna transazione persa
- 81. «Restore to apoint» 81 Domenica Lunedì Full Database Backup Log Log Log Log Data Log Data Log Full Database Backup Errore utente! Restore Restore Restore Backup coda del log Restore stop at Transazioni perse
- 82. Tecnologie di protezione •AlwaysOn • FCI («Failover Cluster Instances») • AG («Availability Groups») • Log Shipping • Database Mirroring (deprecato -> AlwaysOn AG) • Database Snapshot • Database Replication 82
- 83. Controllo delle prestazioni •«Resource Governor» • «Query Store» • Telemetria • DMV • Extended Events • Performance Counters 83
- 84. «Shared Nothing Clustering» •Server Federati 84 Table B B ~ ~ ~ ~ ~ ~ ~ ~ Server 2 Clienti A ~ ~ ~ ~ ~ ~ ~ ~ B ~ ~ ~ ~ ~ ~ ~ ~ Server 1 CREATE VIEW Clienti SELECT Table A UNION ALL SELECT Table B Vista partizionata Table A A ~ ~ ~ ~ ~ ~ ~ ~ CREATE VIEW Clienti SELECT Table A UNION ALL SELECT Table B Clienti A ~ ~ ~ ~ ~ ~ ~ ~ B ~ ~ ~ ~ ~ ~ ~ ~
- 85. «Sharding» • Molteplici databasecondivisi da più «tenant»? • Tecnica «Scale out» distribuzione dati • Strutturati in maniera identica • In più database indipendenti • In base a «Sharding Key» • Mappature per intervallo di valori o lista 85
- 86. «Elastic Database clientlibrary» • «Shard Map Management» • Mappatura «Shard Keys» e database • «Shard Keys» liste o intervalli di valori • «Data Dependent Routing» • Supporto apertura connessione in base a «Shard Key» • «Multi-Shard Queries» • Supporto Query che coinvolge più «Shard» • Fusione unico «Result Set» con Semantica UNION ALL Image source: https://docs.microsoft.com/en-us/azure/sql-database/sql-database-elastic-scale-shard-map-management 86
- 87. «Elastic Database split-mergetool» • «Split Range» distribuisce una «Shard» su due «Shard» • «Merge Range» accorpa due «Shard» in una «Shard» • «Move Shardlet» Image source: https://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-scale-overview-split-and-merge 87
- 88. «Elastic Database Jobs» •Esecuzione Script T-SQL o applicazione DACPAC • Collezione database personalizzata • Tutti i database di «Elastic Database Pool» • «Shard Set» • Ritenta in caso di fallimento • Schedulazione 88
- 89. Scenari «Elastic DatabaseJobs» • Attività amministrative • es. «deploy» nuovo schema • Ricostruzione degli indici • Aggiornamento di dati in comune a più database • Raccolta dati di telemetria in tabella comune 89
- 90. «Elastic Database Queries» •Supporto T-SQL per query distribuite • CREATE EXTERNAL DATA SOURCE • CREATE EXTERNAL TABLE • Partizionamento verticale «cross-database queries» • TYPE = RDBMS • Partizionamento orizzontale «Sharding» • TYPE = SHARD_MAP_MANAGER Image source: https://docs.microsoft.com/en-us/azure/sql-database/sql-database-elastic-query-overview 90
- 91. «Eventual Consistency» • Caratteristichedei «Data Store» distribuiti • Teorema CAP • In caso di «Partitioning»… • Compromesso tra «Consistency» e «Availability» • Spesso sacrificata la prima • Estensione PACELC • Anche senza «Partitioning», «Availability» implica replica • Compromesso tra «Consistency» e «Latency» • Anche in questo caso spesso sacrificata la prima 91 https://en.wikipedia.org/wiki/PACELC_theorem
- 92. «In-Memory OLTP» • Tabelle«Memory Optimized» • Stored Procedure compilate • Strutture dati lock e latch free • Completamente integrate 92
- 93. «Memory Optimized Tables» •Struttura • Completamente in memoria • Indici di tipo hash e range (BW-tree) • Compilazione schema e metodi accesso • Persistenza (durability) • Solo Schema o Schema e dati • Storage • Data file e delta file usano tecnologia FILESTREAM • Transaction-log 93
- 94. Compiled SQL Modules •Compilazione codice nativo • «Stored Procedures» • «After Triggers» • «Inline TVFs» • «Scalar UDFs» • Massime prestazioni ma… • svariate limitazioni • rimosse in ogni nuova versione 94
- 95. Concorrenza «In-Memory OLTP» •Nuovo protocollo per transazioni MVCC • Conforme proprietà ACID • Molteplici versioni delle righe • Completamente lock-free (timestamp based) • Garbage Collector versioni non più utili • Metodi di accesso «latch/spinlock-free» • Operazioni CAS (Compare & Swap) • Logica di «Thread assist/abort» 95
- 96. Effetti collaterali MVCC •Protocollo ottimistico • Possibili conflitti tra scritture • Validazione prima della commit potrebbe fallire • Gestione e logica di «retry» necessaria