I tool di gestione dei database, come SQL Server Management Studio (SSMS) sono prodotti maturi per l’uso quotidiano da parte dei professionisti dei database in tutto il mondo. Questo mi porta a domandarmi perché Microsoft si sia preoccupata di produrre il suo portale di gestione del database SQL di Azure basato su Silverlight. Presumo che verrà criticato perché non è disponibile per l’update V12 dei database SQL di Azure e per il fatto che il link “Manage” è stato omesso dalla pagina del dashboard del portale di Azure. Io non ho mai avuto motivo di usarlo, ma se voi lo faceste, è ancora possibile l’accesso diretto, usando l’indirizzo web del server SQL di Azure.
L’ultima versione del portale di gestione di Azure ora sta incoraggiando a usare Visual Studio 2013, e più precisamente SQL Server Data Tools (SSDT), per gestire i propri database. Io sono un grande appassionato di SSDT per ideare e sviluppare database, perché ci ha permesso di applicare i principi di Microsoft sulla gestione del ciclo di vita dell’applicazione allo sviluppo del database.
Detto tutto ciò, non vi è ancora possibile battere SQL Server Management Studio (SSMS) per la gestione e l’amministrazione del vostro database – o per scrivere e debuggare query, se è per quello. Io stesso mi ritrovo ancora a saltare da SSDT a SSMS per scrivere le mie query e per gli script T-SQL.
Il problema con SSMS sorge quando vi connettete a un database SQL di Azure. Risulta subito evidente che si tratta di un cittadino di serie B. Non sto parlando delle limitazioni intrinseche all’architettura dei database SQL di Azure, mi riferisco ai tools SSMS che sono stai disabilitati perché (probabilmente) non erano in sintonia o compatibili con Azure. So che Microsoft sta ovviando a questi inconvenienti e alla fine avremo una esperienza fluida nel passaggio da Azure SQL a SQL Server in SSMS. Prima che questo avvenga, gli sviluppatori sono lasciati in preda a un’impressione esagerata di differenza tra di loro. Recentemente sono stati introdotti due miglioramenti: l’update CU5 per SQL Server 2014 che ha reso disponibili molti più dialoghi e utility per i database SQL di Azure in SSMS (maggiori dettagli) e l’update V12 del database SQL di Azure (maggiori dettagli) che ha aggiunto più criteri dinamici di gestione (DMV) e più funzioni dinamiche di gestione (DMF).
Ho fatto un veloce paragone tra i set di DMV e DMF presenti in SQL e SQL V12 di Azure. Secondo i miei conti, il numero di DMV (e DMF) è aumentato da 34 a 151. Se escludete categorie che non sono applicabili (come Change Data Capture e AlwaysOn), ora è stata quasi stata raggiunta la parità tra SQL Server 2014 e Azure. SQL. Questo è di fondamentale importanza per il miglioramento della performance e la risoluzione dei problemi. Sono rimasto piacevolmente colpito dall’inclusione di DMV di uso comune, come ‘sys.dm_io_virtual_file_stats’, ‘sys.dm_os_wait_stats’, ‘sys.dm_os_waiting_tasks’.
Gli sviluppatori e gli amministratori di database SQL Server sono abituati a fare switch tra differenti versioni di SQL Server e a dover tenere a mente quali funzioni siano disponibili nelle due versioni. In una prospettiva di sviluppo, io tendo a considerare il database SQL di Azure semplicemente come una diversa versione di SQL Server e ci ho lavorato abbastanza a lungo per conoscere le differenze e sapere quando SSMS mi sta svilendo.
Recentemente un collega che voleva semplicemente controllare quali autorizzazioni al database erano state associate a un particolare login in SSMS, ha espresso la sua frustrazione. Con SQL Server potremmo solo mostrare le proprietà del login, che elencano mappature di utenti e poi mostrare le proprietà dell’utente mappato per avere una lista di autorizzazioni esplicite ed effettive. Con Azure SQL queste finestre di dialogo sulle proprietà dell’oggetto non sono disponibili. Così il piano era di creare un report personalizzato che mostrasse tutti gli utenti mappati e le autorizzazioni assegnate per un determinato login.
I report personalizzati in SSMS sono semplicemente dei file RDL (Report Definition Language), usati da SQL Server Reporting Services per catturare un determinato set di parametri in ingresso. Essi forniscono il context server, database, tipo di oggetto, nome dell’oggetto (più alcune altre cose). Questi report si connettono ai principali database ed eseguono delle query su di essi per ottenere i set di risultati. Purché siate in possesso delle debite autorizzazioni, non fa differenza se vi state connettendo a SQL Server o Azure SQL. Per dimostrarlo, ho preso alcuni dei file RDL di report standard SSMS, li ho archiviati nel mio folder di report personalizzati SSMS, ho selezionato un database Azure ed eseguito il report. In pratica ho dovuto selezionare il folder Tables anziché l’oggetto database, perché era il primo nodo in Object Explorer che avesse la voce del menu “Reports” abilitata. Ma funzionava bene, come potete vedere dalla schermata qui sotto.
La prima sfida del report pesonalizzato con login era il fatto che Azure SQL non supporta query attraverso vari database, così non ho potuto interrogare tutte le corrispondenti identità autenticate e entità protette negli altri database. La soluzione è stata quella di sfruttare espressioni nelle proprietà per consentire stringhe di connessione dinamiche che vengono risolte automaticamente. Questo mi ha permesso di interrogare la lista di database e di inviare il nome del database come un parametro (unitamente al SID di accesso) a un sub-report incorporato in una lista. Questo sub-report poi era in grado di connettersi dinamicamente al database e interrogare le autorizzazioni per gli utenti del database mappati per quel login. Un consiglio: quando avete a che fare con SID (o valori binari) che devono essere convertiti in e da stringhe, usate il 2 come valore dell’argomento con la funzione CONVERT per rimuovere lo “0x” iniziale.
La sfida successiva era che report personalizzati in SSMS non supportano sub-report, così ho dovuto trasformare il subreport integrato in un report collegato. Ciò significa che l’utente del report deve cercare in ogni database a turno. Questa soluzione, come è evidenziato nello screenshot qui sotto, non è perfetta ma ha fornito la funzionalità che serviva.
Un consiglio finale: una volta che avete un report personalizzato, potete effettuare rapidamente delle variazioni su di esso, modificando il file RDL e cambiando la query SQL, che sarà archiviata nella proprietà CommandText per il dataset.