Pasquale Ceglie

Come già annunciato allo scorso Ignite, una delle nuove (tra le tante) feature di SQL Server 2019 accolta con ovazione dei presenti è la possibilità di ottenere informazioni più complete rispetto al tanto odiato messaggio

La buona notizia è che è possibile abilitare la stessa funzionalità anche su SQL Server 2017 (e con la SP2 su SQL Server 2016) installando la CU12 e abilitando trace flag 460.

Qui trovate tutti i dettagli.

Se avete abilitato Sql Server Auditing su un database di SQL Azure, dopo averlo esportato in .bacpac, se provate ad importarlo sulla vostra istanza in locale vi troverete di fronte al seguente messaggio: Error SQL72014: .Net SqlClient Data Provider: Msg 33161, Level 15, State 1, Line 1 Database master keys without password are not supported in this version of SQL Server. Error SQL72045: Script execution error. The executed script: CREATE MASTER KEY;

C’è ancora chi si meraviglia davanti all’opzione WITH TIES.

Molti non sanno che esiste o ne sottovalutano l’utilità.

Consideriamo la query

SELECT TOP 3 Name, ListPrice 
FROM SalesLT.Product 
ORDER BY ListPrice ASC;

Questa query ritornerà i primi 3 articoli ordinati per ListPrice crescente.

L’opzione WITH TIES indica che, invece di restituire solo il numero richiesto di righe, la query restituirà anche tutte le righe aventi lo stesso valore dell’ultima riga in base ai criteri di ordinamento (ListPrice, nel nostro caso). Questo significa che si potrebbero ottenere più righe rispetto a quelle richieste, ma la selezione delle righe diventa di tipo deterministico (al contrario del caso precedente).

Immaginate di avere il vostro bel Azure SQL Database e con una serie di indici Azure Search collegati ad altrettanti Datasource che fanno riferimento a tabelle fisiche (o viste) del db (a chi non sapesse cosa sono i servizi Azure Search consiglio vivamente questa lettura).

Il tutto in produzione con ottimi risultati in termini di performance ed usabilità.

Ad un certo punto il CTO decide che il database debba essere spostato sotto altro account Azure con conseguente cambiamento della ConnectionString. Poco male, penso tra me e me, basta cambiare la connectionstring nei relativi datasource et voilà … il gioco è fatto.

Si applica a: Azure SQL Database, SQL Server 2016 Preview

---

Converte un inputdate al valore datetimeoffset corrispondente nel fuso orario di destinazione. Se inputdate viene fornito senza le informazioni di offset, la funzione applica l’offset del fuso orario partendo dal presupposto che il valore inputdate viene fornito nel fuso orario di destinazione. Se inputdate viene fornito come valore datetimeoffset, allora la clausola AT TIME ZONE converte nel fuso orario di destinazione utilizzando regole di conversione del fuso orario.

Tenere sotto controllo le prestazioni e lo “stato di salute” di un database non è semplice e talvolta richiede parecchio tempo.

Query Performance Insight offre la possibilità di verificare il consumo in DTU del database, individuare le query più costose in termini di DTU che potrebbero quindi influire negativamente sulle prestazioni e infine eseguire “drill down” sulle query per visualizzarne tutti i dettagli.

[highlight color=“yellow”]N.B.: Query Performance Insight è in modalità anteprima ed è attivabile solo tramite Azure Preview Portal[/highlight]

Mi è capitato spesso di confrontarmi con colleghi a proposito della scelta più adatta tra le versioni di SQL Server.

La prima scelta riguarda quella tra PaaS (Platform as a Service) e IaaS (Infrastructure as a Service).

Nel caso si scelga IaaS si procederà alla creazione di una VM Azure oppure alla scelta tra quelle offerte nella gallery da Microsoft facendosi carico dell’amministrazione della VM stessa (aggiornamenti, applicazione di patch, ecc.). In questo link trovate le informazioni sul licensing delle VM.

Immaginate di dover ripristinare un database dall’ambienti di produzione a quello di sviluppo per permettere agli sviluppatori di effettuare dei test su dati reali. Si pone il problema di offuscare informazioni riservate che possono essere il nome utente, il numero di carta di credito, ecc. ecc.

Il metodo tradizionale impone al dba di lanciare immediatamente una query sulle tabelle interessate per offuscare le informazioni riservate. Pur avendo tutti gli script a disposizione occorrerebbe eseguirli sul database e attendere il termine dell’esecuzione generando traffico “inutile” (specie su database molto grandi).