Sarà successo anche a voi di dover modificare il tipo di dato di una colonna presente da tempo in una tabella di un database SQL Server e probabilmente vi sarete scontrati con l’errore 5074 che segnala l’impossibilità di modificare la colonna a causa della presenza di oggetti collegati come Primary Key, Foreign Key, Indici, Vincoli (di univocità e non), Statistiche, ecc..
Le performance di una soluzione database sono spesso oggetto di diatriba tra chi fornisce la soluzione e chi la personalizza. Scrivere codice T-SQL ottimizzato, in grado di scalare all’aumentare dei dati e degli utenti, non è affatto semplice e quando la complessità aumenta, le attività di manutenzione del codice diventano difficili da attuare anche per l’autore stesso.
SQL Server offre da sempre gli strumenti per gestire i dati gerarchici e le relazioni tra le entità. A volte, però, le relazioni tra le entità possono diventare complesse. Pensiamo ad una relazione molti-a-molti, i database relazionali non dispongono di soluzioni native per questo tipo di legame, che viene comunemente implementato con una tabella di associazione.
Nell’articolo Conversioni implicite: cosa sono e che impatto hanno sulle nostre query, Luca Bruni (@mrg3d) ci ha parlato delle conversioni implicite che avvengono, a nostra insaputa, all’interno dell’Engine di SQL Server. Tali conversioni, possono costringere il Query Optimizer ad accedere alle tabelle con operazioni di scansione (Table Scan, Index Scan) in alternativa alle più efficienti operazioni di Seek (Index Seek), e quando una parte significativa del carico di lavoro è interessata da conversioni implicite, le performance degradano visibilmente!
Avete presente le procedure di manutenzione degli indici di Hola Hallengren?
Se no, vi consiglio di guardarle perché sono molto utili. Ecco il link: https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html
Se le conoscete, magari vi è capitato di notare che, nelle versioni più recenti di SQL Server, la manutenzione degli indici colonnari richiede uno sforzo ulteriore.
“SQL Server Management Studio ha smesso di funzionare”, a volte succede di ottenere a video questo messaggio poco simpatico.
Nulla di grave, “basta solo” riavviare il programma.
Ed ecco che una volta riavviato SSMS alcun file è stato recuperato … GRRRRRR!!!!
La cosa meno divertente, quindi, è scoprire che la query/procedura che si stava scrivendo e provando, magari da qualche ora, è andata persa. Ovvero perse le ultime modifiche non salvate .. come dici!? non hai salvato lo script SQL prima di eseguirlo!? Ahhh, non hai proprio salvato nemmeno una volta!?
Una delle domande più comuni quando si inizia ad utilizzare SQL Azure è legata alla scelta del livello di servizio necessario per la proprie necessità. Dato che sul Cloud, ogni risorsa sprecata è un tangibile costo aggiuntivo, è bene scelgliere il livello di servizio migliore. Il “problema” è che il livello è misurato in DTU - Database Transaction Units - ossia un valore che rappresenta un mix di CPU, Memoria ed I/O. Il problema è che è molto difficile, se non impossibile, calcolare questo valore per un server on-premises già esistente, in modo da poter aver un paragone con dei dati conosciuti.
