Home > Prodotti > Lepide SQL Storage Manager

Lepide SQL Storage Manager

Introduzione

In questo articolo parleremo della soluzione SQL Storage Manager di Lepide Software (@LepideSW).

SQL Storage Manager è un tool in grado analizzare le performance e la struttura dello storage di una o più istanze SQL Server, aiuta il DBA a prevenire situazioni critiche dovute al degrado delle performance o a problemi nello storage. Di seguito verrà illustrata la procedura di installazione e il controllo dei pre-requisiti software necessari per il monitoraggio di un’istanza SQL Server; seguirà la descrizione di alcune delle funzionalità disponibili in SQL Storage Manager quali l’analisi del livello frammentazione degli indici, l’analisi dello spazio utilizzato dai DB e l’utilizzo della funzione di compattazione database.

Installazione

La procedura di installazione richiede solo sette click. La Welcome Form, illustrata in Figura 1, informa che sta per essere avviato il processo d’installazione di SQL Storage Manager; lo abbiamo provato in versione 12.06.01 su Windows Server 2012 Datacenter avente un’istanza SQL Server 2012 Enterprise Edition.

Figura 1 – Welcome Form

Cliccando sul tasto Next verrà chiesto di accettare le condizioni sancite nella licenza d’uso, la Figura 2 illustra la finestra License Agreement.

 Figura 2 – Finestra License Agreement Form

Dopo aver accettato i termini sanciti nella licenza d’uso, il setup chiede all’operatore di specificare la directory di installazione di SQL Storage Manager, viene proposto il percorso di default, illustrato in Figura 3, ovviamente modificabile.

Figura 3 – Selezione della directory di installazione

Confermata la directory che ospiterà l’installazione di SQL Storage Manager, si può decidere di creare o meno un collegamento all’applicazione; in caso affermativo, verrà creato, sul desktop, un link a SQL Storage Manager. La figura seguente illustra il quarto step del processo di installazione.

Figura 4 – Selezione per creazione collegamento a SQL Storage Manager sul Desktop

La finestra illustrata in Figura 4 rappresenta l’ultima finestra di raccolta delle informazioni necessarie all’installazione, premendo il tasto Next verrà visualizzata la finestra, illustrata in Figura 5, con il riepilogo delle opzioni specificate.

Figura 5 – Riepilogo delle informazioni necessarie all’installazione

Premendo il tasto Install, i file dell’applicazione verranno copiati nella directory specificata, il processo di copia è illustrato in Figura 6.

Figura 6 – Copia dei file dell’applicazione

Il settimo click completa l’installazione di SQL Storage Manager, nella finestra illustrata in Figura 7, si può decidere se avviare o meno la verifica dei pre-requisiti software, necessari al monitoraggio delle istanze SQL Server.

Figura 7 – Installazione di SQL Storage Manager completata correttamente

Controllo dei prerequisiti software

I pre-requisiti software richiesti per il monitoraggio delle istanze sono funzione delle versioni di SQL Server che di desidera monitorare; la distinzione viene fatta tra SQL Server 2000 e SQL Server 2005 o superiori. La verifica dei prerequisiti software può essere eseguita, opzionalmente, al termine dell’installazione oppure in un secondo momento accedendo al menù Tools all’interno dell’applicazione. Abbiamo deciso di intraprendere la verifica al termine dell’installazione, cliccando il tasto Finish, verrà eseguita la funzione Software Requirement Check la cui finestra è illustrata in Figura 8.

Figura 8 – Funzione Software Requirement Check

La funzione Software Requirement Check ha il compito di controllare la presenza dei componenti software necessari al monitoraggio delle diverse versioni di SQL Server. Volendo monitorare l’istanza SQL Server 2012 presente su questo server, abbiamo selezionato il check box SQL Server 2005 or Above, alla pressione del tasto Next verrà avviata la verifica. I componenti richiesti per il monitoraggio di istanze SQL Server 2005 o superiori sono elencati in Figura 9.

Figura 9 – Componenti richiesti per il monitoraggio di istanze SQL Server 2005 o superiori

La verifica dei prerequisiti ha evidenziato la mancanza del componente SQL Server 2005 Backward Compatibility, i componenti software richiesti vengono presentati all’operatore utilizzando la finestra illustrata in Figura 10. Notiamo, nella parte inferiore della finestra, la presenza del link da utilizzare per il download del componente richiesto.

Figura 10 – Risultato del controllo dei pre-requisiti software

Dopo aver scaricato ed installato SQL Server 2005 Backward Compatibility il controllo pre-requisiti non segnala anomalie. Possiamo procedere con la registrazione delle istanze che si desidera monitorare.

Registrazione di un server SQL

La prima cosa da fare è la registrazione dei server SQL che si desidera monitorare. Il Manage Storage rappresenta lo strumento di amministrazione dei server SQL registrati ed eventualmente organizzati in gruppi logici per agevolarne la gestione. Per registrare un nuovo server SQL è sufficiente cliccare sul link Register New Server, nella scheda Manage SQL Servers o all’interno del menù File; verrà così visualizzata la finestra di connessione in cui si dovranno specificare le credenziali di accesso all’istanza ed eventualmente un alias ed una descrizione. La finestra di connessione è illustrata in figura 11.

Figura 11 – Finestra di connessione al server SQL

I server SQL registrati vengono visualizzati nel tree-view Manage Storage come illustrato in figura 12.

Figura 12 – Server registrati nel Manage Storage

Per esplorare i database installati è sufficiente espandere il ramo SQL Server Group (o l’eventuale gruppo specifico) e successivamente il ramo relativo al server SQL, rappresentato nel nostro esempio dall’istanza “WIN-8N4LI85IG18”. Per ogni database, le funzioni Overview, Filegroup e Partitioned Table permettono rispettivamente di ottenere informazioni circa lo spazio disco utilizzato dal database selezionato, le dimensioni dei file dati e del file di log con le relative percentuali di utilizzo; i filegroup e le caratteristiche di eventuali tabelle partizionate (schema e funzioni di partizionamento). La figura seguente rappresenta una overview del database AdventureWorks2012 (scaricabile gratuitamente da CodePlex).

Figura 13 – Overview database AdventureWorks2012

Osserviamo la dimensione totale del DB AdventureWorks2012, è pari a 189 MB. In seguito, eseguiremo su questo database, alcune attività che avranno effetto sulle dimensioni dei file dati e del file di log, vedremo come Lepide SQL Storage Manager ci aiuterà ad analizzare com’è avvenuta la crescita della dimensione del DB. La figura seguente illustra altre funzioni, amministrative e di gestione, disponibili per il database selezionato.

Figura 14 – Funzioni amministrative e di gestione per il DB selezionato

La frammentazione degli indici è uno dei temi che sta più a cuore ai DBA. La funzione Fragmentation fornisce informazioni sul livello di frammentazione degli indici nel DB; prima di apprezzare questa funzionalità, però, è necessario creare il Database Repository in cui verranno memorizzate le informazioni raccolte da SQL Storage Manager.

Senza il Database Repository, popolato con Snapshot periodici, la sezione Fragmentation appare come illustrato nella figura seguente (non disponibile).

Figura 15 – Frammentazione non disponibile per la mancanza del Database Repository

Database Repository

Lepide SQL Storage Manager è in grado di raccogliere automaticamente (e periodicamente) informazioni sullo spazio utilizzato dai file dati e dal file di log dettagliando la crescita (grow) che hanno avuto gli oggetti del DB, sia nei file dati che nel file di log. E’ inoltre possibile raccogliere informazioni circa la frammentazione degli indici. I dati raccolti vengono memorizzati in un database dedicato, che è possibile gestire con le funzioni disponibili nella scheda Manage Repository. Procediamo quindi con la creazione del database StorageManagerRepository dedicato alla memorizzazione degli Snapshot raccolti per noi da Lepide SQL Storage Manager. Per creare il nuovo Repository utilizziamo la funzione Create Repository Database specificando i dati richiesti dal wizard (osserviamo che le altre funzioni della scheda Manage Repository non sono abilitate, in questo momento, proprio perché non abbiamo un Repository su cui fare l’output degli Snapshot). La figura seguente illustra il Database Repository appena creato.

Figura 16 – Database Repository: StorageManagerRepository

Configurazione degli oggetti database da monitorare

Dopo aver creato il Database Repository, configuriamo gli oggetti da monitorare; utilizziamo la funzione Select Objects for Monitoring disponibile nella scheda Manage Repository, selezioniamo il server SQL ed il database AdventureWorks2012 con le opzioni di utilizzo dello storage, le informazioni riguardanti la frammentazione degli indici e le performance generali dell’istanza (di cui parleremo in seguito). Il tasto Add Monitored Objects permette di selezionare oggetti specifici di uno o più database per un monitoraggio puntuale sull’utilizzo dello storage e sulla frammentazione degli indici. Nel prossimo esempio verranno selezionate le tabelle Production.TransactionHistory e Production.TransactionHistoryArchive e alcuni indici che insistono su di esse, come illustrato nella figura seguente.

Figura 17 – Selezione di oggetti database specifici per monitoraggio puntuale

Premendo il tasto Next, il wizard procederà con la creazione automatica del job _csm_CollectDataJob proponendone anche l’esecuzione pianificata attraverso il servizio SQL Server Agent. Il job è stato pianificato per essere eseguito ogni ora. Non volendo però attendere la prossima esecuzione schedulata, ne abbiamo forziamo l’avvio accedendo alla scheda Manage Job illustrata nella figura seguente.

Figura 18 – Esecuzione forzata del job _csm_CollectDataJob

Database Reports e Frammentazione

Il job _csm_CollectDataJob ha raccolto i dati necessari al monitoraggio degli oggetti che abbiamo selezionato; le informazioni raccolte sono pronte per essere consumate nei report della sezione Database Reports relativa al DB AdventureWorks2012. Consultiamo i dati relativi alla frammentazione degli indici illustrati nella figura seguente; particolare importanza rivestono le colonne “Pages Count” e “Logical Fragmentation %”.

Figura 19 – Livello di frammentazione degli indici nel database AdventureWorks2012

Nel prossimo esempio aggiungeremo una colonna alla tabella Production.TransactionHistory del database AdventureWorks2012. La colonna aggiunta rappresenta la quantità movimentata con segno positivo o negativo in funzione del tipo di transazione (segno positivo per le transazioni che hanno aumentato la giacenza del prodotto, segno negativo per quelle che ne hanno diminuito la giacenza). Nell’esempio, l’aggiunta della colonna sQuantity ha come obiettivo quello di frammentare l’indice CLUSTER della tabella; l’aumento del livello di frammentazione verrà rilevato come una criticità nel prossimo Snapshot raccolto da Lepide SQL Storage Manager.

Il seguente frammento di codice T-SQL aggiunge e valorizza la nuova colonna sQuantity nella tabella Production.TransactionHistory del database AdventureWorks2012.

USE [AdventureWorks2012];
GO
-- Add column sQuantity
ALTER TABLE Production.TransactionHistory ADD sQuantity INTEGER NOT NULL DEFAULT(0);
GO
-- Update values in sQuantity
UPDATE Production.TransactionHistory
  SET sQuantity = CASE
                    WHEN (TransactionType IN ('W', 'P'))
                      THEN (Quantity)
                    ELSE (Quantity * -1)
                  END;

La figura seguente illustra il livello di frammentazione raccolto nello Snapshot successivo a quello illustrato in figura 19.

Figura 20 – Frammentazione nel DB AdventureWorks2012 dopo l’aggiunta della colonna sQuantity

In quest’ultimo report si osserva una frammentazione del 99% nella tabella Production.TransactionHistory, questo livello di frammentazione, associato ai valori soglia impostati, rappresenta una criticità che viene evidenziata come illustra la figura 20.

La funzione Reorganize Indexes permette di accedere al wizard di riorganizzazione indici che, in funzione dei parametri specificati, filtra gli indici da de-frammentare o ricostruire.

E’ inoltre possibile configurare la notifica, via mail, di messaggi di Alert, che verranno generati al superamento dei livelli soglia, considerati critici per un determinato database. La figura seguente illustra la finestra di impostazione dei valori soglia per la notifica di un Fragmentation Alert.

Figura 21 – Configurazione valori soglia per la notifica di un Alert

Analisi dello spazio utilizzato per database

L’aggiunta della colonna sQuantity nella tabella Production.TransactionHistory ha ovviamente prodotto anche un aumento dello spazio utilizzato dai file del database AdventureWorks2012, la cui dimensione totale è passata da 189 MB a 247 MB; lo possiamo osservare, con i dettagli della top 5 degli oggetti che hanno subito i maggiori aumenti di dimensione, nei report della sezione Database Reports, come illustra la figura seguente.

Figura 22 – Aumento dello spazio utilizzato dal DB AdventureWorks2012

Compattazione Database (Shrink)

La funzione Shrink Database nella scheda Manage Storage, permette di accedere al wizard di compattazione database la cui finestra principale è illustrata nella figura seguente. L’attività di compattazione riduce lo spazio utilizzato dai file dati e dal file di log di un database SQL Server.

Figura 23 – Selezione dei database da compattare

E’ comunque importante, prima di effettuare un’operazione di compattazione, considerare che se un database cresce, in termini di spazio occupato, è perché ne ha bisogno, e che l’attività di crescita consuma risorse e tempo per cui, in generale, non conviene fare compattazioni, ma anzi, spesso si pre-alloca spazio (magari suddiviso su più file) per fare in modo che il database abbia sempre tutto lo spazio di cui ha bisogno; in modo che non avvengano richieste di autogrow che dovrebbero accadere solo in situazioni estreme. In ambiente di produzione, la compattazione di un DB dovrebbe avvenire solo in particolarissime soluzioni. In aggiunta, lo Shrink ha come effetto collaterale quello di frammentare gli indici.

Settings

La scheda Settings permette di accedere alla finestra di impostazione dei valori soglia e dei parametri utilizzati da Lepide SQL Storage Manager per considerare le criticità, per parametrizzare i report delle diverse sezioni, ecc La finestra Settings è illustrata nella figura seguente.

Figura 24 – Finestra di impostazione valori soglia, parametri, ecc…

Performance e Statistiche generali dell’istanza

Ora che il job _csm_CollectDataJob ha raccolto un numero sufficiente di Snapshot, possiamo analizzare anche le performance generali dell’istanza. Accediamo alla scheda Manage Storage, un click con il tasto sinistro del mouse farà comparire la sezione Reports and Database File Management da cui possiamo accedere alla funzione Performance Statistics, che fornisce informazioni circa l’utilizzo medio della CPU, la memoria RAM mediamente utilizzata, il tempo medio di inattività del sistema ed il tempo medio nel quale il sottosistema dischi è stato completamente impegnato in operazioni di IO. Si osservi, in figura 25, la linea di colore arancione-rosa, essa rappresenta la previsione futura di utilizzo della risorsa misurata nel grafico.

Figura 25 – Performance e Statistiche generali dell’istanza

Conclusioni

Termina qui questa breve review del prodotto Lepide SQL Storage Manager, non abbiamo analizzato tutte le funzioni del prodotto, ci siamo solo limitati a far intravedere le potenzialità di questo strumento che fornisce ad un DBA tutte le informazioni necessarie per monitorare e gestire al meglio le proprie istanze SQL Server.

La versione di prova di SQL Storage Manager può essere scaricata dalla pagina download del sito ufficiale del prodotto, ecco il link:

http://www.lepide.com/sql-storage-manager/download.html

Chi è Sergio Govoni

Sergio Govoni è laureato in Scienze e Tecnologie Informatiche. Da oltre 16 anni lavora presso una software house che produce un noto sistema ERP, distribuito a livello nazionale ed internazionale, multi azienda client/server su piattaforma Win32. Attualmente si occupa di progettazione e analisi funzionale, coordina un team di sviluppo ed è responsabile tecnico di prodotto. Lavora con SQL Server dalla versione 7.0 e si è occupato d'implementazione e manutenzione di database relazionali in ambito gestionale, ottimizzazione delle prestazioni e problem solving. Nello staff di UGISS si dedica alla formazione e alla divulgazione in ambito SQL Server e tecnologie a esso collegate, scrivendo articoli e partecipando come speaker ai workshop e alle iniziative del primo e più importante User Group Italiano sulla tecnologia SQL Server. Ha conseguito la certificazione MCP, MCTS SQL Server. Per il suo contributo nelle comunità tecniche e per la condivisione della propria esperienza con altri, dal 2010 riceve il riconoscimento SQL Server MVP (Microsoft Most Valuable Professional). Nel corso dell'anno 2011 ha contribuito alla scrittura del libro SQL Server MVP Deep Dives Volume 2 (http://www.manning.com/delaney/).

Leggi Anche

Governo delle istanze\database SQL Server!

Introduzione L’obiettivo del presente articolo è quello di esporre una nuova metodologia di monitoraggio che …