SQL Server Worst Practices
Download as PPTX, PDF2 likes805 views
Il documento presenta una serie di pratiche errate nell'uso e gestione di SQL Server, evidenziando come tali pratiche possano derivare da una progettazione inadeguata, sviluppo scorretto e amministrazione poco attenta. Si discute sui pericoli di non seguire le best practices e sull'importanza di imparare dagli errori altrui per evitare problematiche comuni. Inoltre, il documento fornisce diverse aree di attenzione e suggerimenti per migliorare l'efficacia nella gestione dei database.
![OTLT: One True Lookup Table
• Impossibile usare Foreign Key
• Tipi di dati generici nvarchar(?)
– Implicit Conversions
• Difficile definire vincoli CHECK
• Locking
CHECK(
CASE
WHEN lookup_code = 'states' AND lookup_code LIKE '[A-Z][A-Z]' THEN 1
WHEN lookup_code = 'priorities' AND lookup_code LIKE '[0-9]' THEN 1
WHEN lookup_code = 'countries' AND lookup_code LIKE '[0-9][0-9][0-9]' THEN 1
WHEN lookup_code = 'status' AND lookup_code LIKE '[A-Z][A-Z]' THEN 1
ELSE 0
END = 1
)](https://image.slidesharecdn.com/dba103-sqlserverworstpractices-150313130322-conversion-gate01/85/SQL-Server-Worst-Practices-16-320.jpg)
SQL Server Worst Practices
- 1. SQL START! ANCONA, 28 SETTEMBRE 2012
- 2. SQL START! ANCONA, 28 SETTEMBRE 2012 SQL Server Worst Practices Gianluca Sartori gianluca.sartori@sqlconsulting.it
- 3. Tecnosistemi Marche Un GRAZIE agli sponsors
- 4. #sqlstart
- 5. Gianluca Sartori • Independent SQL Server consultant • Works with SQL Server since version 7 • MCTS, MCITP, MCT • DBA @ Scuderia Ferrari
- 6. Agenda • Best practices o Worst practices? • Dove posso sbagliare? – Progettazione – Sviluppo – Installazione – Amministrazione
- 7. Disclaimer: • Non tutto è bianco o nero • «Dipende» è la risposta migliore Possono esistere casi limite in cui qualcuna di queste worst practice è l’unica soluzione possibile
- 8. Best Practices vs. Worst Practices • Perché le Best Practices non bastano – Sono troppe – Non c’è tempo – Manca l’esperienza – Non è chiaro cosa succede se non le seguiamo • Perché le Worst Practices servono – Ci mostrano gli errori da non fare – Possiamo imparare dagli errori degli altri
- 9. Worst Practices Areas Design Development Installation Administration Schema design Naming Data Types Environment HW validation OS configuration SQL installation Recovery Security Capacity Performance Monitoring Code Test
- 10. Schema Design • Non normalizzare lo schema – 1NF: Una chiave, solo attributi atomici – 2NF: Ogni attributo dipende da tutta la chiave – 3NF: Ogni attributo dipende solo dalla chiave «La chiave, solo la chiave, nient’altro che la chiave, così Codd mi aiuti»
- 11. Indizi di denormalizzazione • Dati che si ripetono ridondanze • Dati inconsistenti tra tabelle anomalie • Dati separati da «,» • ES: john@gmail.com, john@business.com • Dati strutturati in colonne «nota» • Colonne con un suffisso numerico – ES: Zona1, Zona2, Zona3 …
- 12. Schema Design Worst Practices • Nessuna Primary Key o solo chiavi surrogate – «Id» non è la sola chiave primaria al mondo! • Nessuna Foreign Key – Sono «scomode» • Nessun vincolo CHECK – L’applicazione garantirà la consistenza… • Utilizzo di tipi di dato errati – CAP, Telefono – Date salvate come stringhe • Utilizzo di NULL dove non necessario • Utilizzo di valori «dummy» (es: ‘.’ , 0)
- 13. Schema Design Worst Practices • Naming conventions inconsistenti – Plurale o singolare? – Italiano / Inglese – Hungarian Notation • tbl… • vw... • Nomi di oggetto o di colonna riservati • Usare il prefisso sp_ – … meno peggio di quanto sembri!
- 14. Lookup Tables Orders PK order_id int order_date datetime FK2 customer_id int FK1 status_id char(2) FK3 priority_id tinyint Order_Status PK status_id char(2) status_description nvarchar(50) Customers PK customer_id int name varchar(100) address varchar(50) ZIP char(5) city nvarchar(50) FK2 state_id char(2) FK1 country_id char(3) Countries PK country_id char(3) description nvarchar(50) States PK state_id char(2) description nvarchar(50) Order_Priorities PK priority_id tinyint priority_description nvarchar(50) Una tabella di lookup per ogni attributo
- 15. OTLT: One True Lookup Table Orders PK order_id int order_date datetime FK1 customer_id int status_id char(2) priority_id tinyint Customers PK customer_id int name nvarchar(100) address nvarchar(50) ZIP char(5) city nvarchar(50) state_id char(2) country_id char(3) LookupTable PK table_name sysname PK lookup_code nvarchar(500) lookup_description nvarchar(4000) CREATE TABLE LookupTable ( table_name sysname, lookup_code nvarchar(500), lookup_description nvarchar(4000) ) Una tabella di lookup per tutti gli attributi
- 16. OTLT: One True Lookup Table • Impossibile usare Foreign Key • Tipi di dati generici nvarchar(?) – Implicit Conversions • Difficile definire vincoli CHECK • Locking CHECK( CASE WHEN lookup_code = 'states' AND lookup_code LIKE '[A-Z][A-Z]' THEN 1 WHEN lookup_code = 'priorities' AND lookup_code LIKE '[0-9]' THEN 1 WHEN lookup_code = 'countries' AND lookup_code LIKE '[0-9][0-9][0-9]' THEN 1 WHEN lookup_code = 'status' AND lookup_code LIKE '[A-Z][A-Z]' THEN 1 ELSE 0 END = 1 )
- 17. EAV: Entity, Attribute, Value Customers PK customer_id int name nvarchar(100) address nvarchar(50) ZIP char(5) city nvarchar(50) state_id char(2) country_id char(3) AttributeNames PK attribute_id int PK,FK1 entity_id int attribute_name nvarchar(128) AttributeValues PK,FK1 attribute_id int PK,FK1 entity_id int PK,FK2,FK3 id int value nvarchar(4000) Entities PK entity_id int entity_name nvarchar(128) Orders PK order_id int order_date datetime customer_id int status_id char(2) priority_id tinyint
- 18. EAV: Entity, Attribute, Value • Svantaggi: – Tipi di dato generici ES: varchar(4000) – No Foreign Key – No CHECK constraints – Accessi multipli alla stessa tabella • Una lettura per ogni attributo • Vantaggi – Schema dinamico: non richiede modifiche al DB • Replica, ambienti distribuiti
- 19. EAV: Entity, Attribute, Value • Workaround: – PIVOT / Crosstab – Viste + INSTEAD OF triggers • Alternative: – SPARSE columns – XML – Key-value store databases • Azure Table storage, Redis – Document-oriented databases • MongoDB, RavenDB
- 20. DEMO: EAV Design
- 21. Development Worst Practices Development Environment • Non versionare lo schema del DB • Non fornire un livello di astrazione – Viste, Functions, Stored Procedures • Sviluppare con privilegi di sysadmin – In produzione non ci saranno!
- 22. Development Worst Practices Code • Nessuna transazione • Nessuna gestione degli errori – @@ERROR appartiene al passato! • Utilizzo di livelli di isolamento errati – NOLOCK = nessuna consistenza! • SELECT * • SQL dinamico con valori hardcoded • Codice suscettibile alla SQL injection
- 23. Development Worst Practices Test • Non testare tutto il codice – Volumi rappresentativi • Testare in ambiente di produzione – Può alterare i dati – Perturba l’attività degli utenti • Testare in ambiente di sviluppo – Va bene al più per test di unità
- 24. Installation Worst Practices • Utilizzare HW inadeguato o sbilanciato • Installare utilizzando tutti i default – File di dati sui dischi di sistema! • Installare componenti non necessarie • Installare più servizi sulla stessa macchina
- 25. I/O Worst Practices • Scegliere un livello di RAID errato – RAID 0 non offre protezione! • Pianificare lo storage pensando allo spazio • Non allineare le partizioni • Utilizzare l’unità di allocazione di default (4Kb)
- 26. Cosa serve a un database? Brent Ozar
- 27. Administration Worst Practices Backup and Recovery • Nessun backup – In FULL recovery è una bomba in attesa di esplodere – Ignorare RPO e RTO • Nessun test di restore • Nessun controllo di consistenza – DBCC REPAIR_ALLOW_DATA_LOSS Il nostro compito è fare il restore, non il backup!
- 28. Administration Worst Practices Security • Troppi sysadmin • Utilizzo di SQL Authentication – Password deboli • Nessun auditing
- 29. Administration Worst Practices Capacity • Non controllare lo spazio disco – Spazio esaurito = database fermo! – Sto facendo il backup? • Affidarsi ad autogrow • Non predimensionare tempdb – Dimensioni diverse = striping penalty
- 30. Administration Worst Practices Manutenzione • Non manutenere gli indici e le statistiche • Creare piani di manutenzione «tuttofare» • Aggiornare le statistiche dopo aver ricostruito gli indici
- 32. Performance Worst Practices Query Optimization RBAR: Row By Agonizing Row – Cursori – Cicli WHILE – Cursori lato applicativo – Funzioni scalari e multi-statement Jeff Moden Utilizziamo codice set-based L’ottimizzatore la sa molto più lunga di noi
- 33. Performance Worst Practices Query Optimization • Una query per domarli tutti – L’ottimizzatore è buono, non perfetto – Molto meglio «divide et impera» • DISTINCT in tutte le query • Query HINT
- 34. Performance Worst Practices Indexing • Accettare tutti i suggerimenti del Tuning Advisor • Indici duplicati • Un indice per ogni colonna – Gli indici non sono gratis! • Clustered Index non ottimale – Univoco – Piccolo – Immutabile – Monotòno Preferire NEWSEQUENTIALID() A NEWID()
- 35. Performance Worst Practices Server Tuning • «Lanciare HW» al problema – Una macchina più veloce non risolve problemi strutturali • Usare opzioni «avanzate» senza testare – NT Fibers (lightweight pooling) – Priority Boost
- 36. Administration Worst Practices Monitoring • Gestione reattiva (no monitoring) • Mancanza di alerting – Severity > 16 • Troppo rumore negli alert – Non li guarda più nessuno!
- 37. Risorse Free Tool: Best Practices Analyzer • Evidenzia i parametri di configurazione che non rispettano le best practices • Evidenzia potenziali problemi • Offre raccomandazioni http://www.microsoft.com/en-us/download/details.aspx?id=15289
- 38. Risorse Free e-book: Troubleshooting SQL Server • Jonathan Kehayias • Ted Krueger – Gail Shaw – Paul Randal http://www.simple-talk.com/books/sql-books/troubleshooting- sql-server-a-guide-for-the-accidental-dba/
- 39. Grazie! Non dimenticate di compilare i moduli di feedback. Commenta la sessione che hai appena seguito su Twitter #sqlstart