Attualità e Information Technology

Per eseguire un dato comando su ogni tabella di un database o per ogni database di una particolare istanza di SQL Server esistono due comodissime stored procedure, seppur non documentate ufficialmente:

• sp_msforeachtable
• sp_msforeachdb

Entrambe richiedono un parametro @command con, per l’appunto, l’istruzione da eseguire. Se l’istruzione stessa deve essere “parametrizzata” con il nome della tabella o del db il “carattere jolly” da utilizzare è ‘?’.

Per qualche dettaglio in più rimando ad un articolo di databasejournal.com:

SQL Server Undocumented Stored Procedures sp_MSforeachtable and sp_MSforeachdb

Per rimanere in tema di stored procedure non documentate cito anche sp_mshelpcolumns che vuole come parametro il nome della tabella da analizzare.

Queste SP funzionano sia su SQL Server 2000 che su SQL Server 2005.

SQL Server, stored procedure

Ancora un altro post sul tema degli indici, in particolare in SQL Server 2005. Si nota che ultimamente essendo in mutua sto cercando di approfondire il tema sql?

Come sempre creare indici su un db non è opera banale. Capire quali indici valga la pena creare e saper trovare il giusto equilibrio non è mai semplice. Come detto in precedente post si fa presto a creare un indice ma poi bisogna preoccuparsi anche di “mantenerlo”.

Un elevato numero di indici significa infatti maggiore lentezza nelle operazioni di insert e più difficile gestione degli stessi in termini di verifica dello stato di frammentazione, eventuale deframmentazione, etc.

Talvolta si pone però il problema di database dove il numero di indici creato è notevole, proprio perchè i ragionamenti appena descriti non vengono fatti, e molti di questi indici si “sovrappongono”. Come individuarli e portare tutto ad una situazione più umana? Per usare una frase trita e ritrita, con tanto olio di gomito L’approccio migliore sarebbe analizzare tutta la base di dati e tutte le query/stored procedure che vengono utilizzate e comportarsi come se si dovesse decidere una “strategia di indicizzazione” da zero. Non sempre però si ha il tempo, quindi si cercano delle scappatoie e qualsiasi aiuto è gradito.

In quest’ottica può risultare utile e interessante il seguente post:

Detecting Overlapping Indexes in SQL Server 2005

Ovviamente, come da titolo, è limitato al mondo SQL Server 2005, ma contiene una user function e una vista che in maniera un po’ grezza aiutano ad individuare eventuali sovrapposizioni di indici.

Ribadisco che lo script è interessante ma non va considerato un tool per la manutenzione dei database per i discorsi fatti sopra. Da notare inoltre come il tutto funzioni con tabelle con un numero di colonne inferiore al 16. C’è anche da dire che se vi sono tabelle con più di 16 colonne è probabile che si sia sbagliata la progettazione dello stesso a meno di poche eccezioni, ma questo è un altro discorso (e magari altro post ).

sql server 2005, performance, maintenance, index