SQL: Domande&RisposteDimensione del database, mirroring, transazioni contrassegnate e altro

A cura di Nancy Michell

Trasferimento di un cluster

D Devo trasferire un cluster SQL Server 2000 su nuovi indirizzi IP sia per i server fisici sottostanti sia per i cluster Windows® e SQL Server™. È necessario ricreare l'intera soluzione?

R No, è sufficiente eseguire il programma di installazione di SQL Server e modificare gli indirizzi IP. Di seguito viene indicato l'indirizzo Internet dove poter trovare un articolo della Knowledge Base che spiega come eseguire l'operazione.

Dimensione del database

D SQL Server 2000 SP4 è in produzione con un database di rilevanza cruciale di quasi 10 GB, un modello di recupero con REGISTRAZIONE MINIMA, un file principale di 9.850 MB e un file di log delle transazioni di 88 MB. Anche il backup del database è di quasi 10 GB. Devo ridurre la dimensione del database per migliorare le prestazioni? In tal caso, dovrei utilizzare DBCC SHRINKDATABASE o DBCC SHRINKFILE? (Sfortunatamente, non ci sono orari in cui il traffico è ridotto per poter eseguire questa procedura di manutenzione).

R DBCC SHRINKDATABASE o DBCC SHRINKFILE sono utili solo se il database è sottoposto a molte operazioni di eliminazione e aggiornamento che riducono il volume dei dati. Ma la domanda reale è perché preoccuparsi? Uno spazio su disco di 10 GB oggigiorno può costare $20. Non avrebbe più senso aggiungere altri 100 GB di spazio su disco e farne uso? Le prestazioni peggiorano appena lo spazio diventa più frammentato, ma se non è possibile eseguire operazioni di manutenzione le scelte sono poche. A volte, in casi come questi, alcuni utilizzano una copia secondaria del database. Conservano inoltre una copia di backup aggiornata con la replica, di cui eseguono la manutenzione, quindi indirizzano le applicazioni al backup. Ciò richiede ovviamente la modifica del codice e il cambio del modello di recupero con REGISTRAZIONE MINIMA (in modello di recupero con REGISTRAZIONE COMPLETA o con REGISTRAZIONE MINIMA DELLE TRANSAZIONI DI MASSA) ma può essere una buona soluzione a lungo termine.

Aggiornamento e prestazioni

D Ho bisogno di trasferire due applicazioni da SQL Server 2000 a SQL Server 2005. Come posso evitare l'impatto sulle prestazioni durante l'aggiornamento?

R In genere, le seguenti insidie possono causare un peggioramento delle prestazioni durante l'aggiornamento, quindi è preferibile evitarle:

1. Le statistiche non sono state ricreate in seguito all'aggiornamento a SQL Server 2005.
2. Sono presenti clausole JOIN e WHERE che mettono a confronto due diversi tipi di dati, con conseguente peggioramento delle prestazioni, soprattutto se sul server era in esecuzione SQL Server 2000 SP3 o versione precedente (vedere support.microsoft.com/kb/271566/).
3. L'istanza di SQL Server 2005 non è configurata correttamente; mentre la memoria, la funzionalità AWE (Address Windowing Extensions), i driver e così via sono configurati in modo errato. Il computer che esegue SQL Server 2000 ha subito delle variazioni da parte di una persona che è andata via senza documentare le modifiche apportate, di conseguenza l'operazione non è stata mai eseguita sull'istanza SQL Server 2005.
4. Difetto dell'hardware. Spesso, si acquista un nuovo hardware perché sembra valido in teoria ma si rivela tutt'altro in pratica.

Prima di utilizzare un'istanza di SQL Server in produzione, occorre stabilire un valore di riferimento delle prestazioni per avere la conferma di poter ottenere le prestazioni previste. Si potrebbe quindi escludere l'infrastruttura come potenziale problema. È necessario esaminare i contatori Perfmon quali Disco, I/O e memoria e confrontarli tra le istanze.

Mirroring del database

D Utilizzo il mirroring del database e voglio attivare l'opzione di database READ_COMMITTED_SNAPSHOT. Quando tento di attivarla dopo aver impostato il mirroring, ricevo un'eccezione che dichiara che il db è in una sessione di mirroring e non è possibile eseguire il comando.

R Ciò accade perché l'impostazione dell'opzione READ_COMMITTED_SNAPSHOT richiede il riavvio del database per rendere operativa la modifica. Pertanto, occorre interrompere la sessione di mirroring, impostare l'opzione e riavviare il database. Completate queste operazioni, è possibile riprendere il mirroring. Una volta avviata la sessione, il database mirror selezionerà l'opzione e la utilizzerà in caso di failover.

D Tento di impostare il mirroring asincrono e ricevo un errore 1418. L'esecuzione di Netstat -ano mostra che SQL Server è in ascolto sulla porta corretta su tutti i server. L'errore viene visualizzato quando tento di avviare il mirroring. Che succede?

R Forse il firewall potrebbe bloccare la comunicazione; si tratta di un problema abbastanza comune che dovrebbe essere esaminato. Per ulteriori informazioni, consultare i seguenti whitepaper: Risoluzione dei problemi relativi all'impostazione del mirroring del database all'indirizzo e MSSQLSERVER_1418.

Da notare che questo problema non è specifico del mirroring asincrono. In realtà, può verificarsi anche con il mirroring sincrono.

L'errore ricevuto ("L'indirizzo di rete del server "%.*ls" non è raggiungibile o non esiste. Controllare il nome dell'indirizzo di rete e ripetere il comando") è corretto. Spesso accade che il partner remoto esiste ma non è raggiungibile.

Questo può accadere se il partner remoto non è attivo, non è in ascolto sulla porta o anche se l'endpoint non è attivo (il che potrebbe verificarsi se i partner non possono negoziare lo stesso meccanismo di crittografia o riscontrano altri problemi di autenticazione). Può verificarsi anche se il partner è bloccato, a causa del firewall del partner che ha avviato il comando.

Altri problemi che probabilmente si vorranno escludere sono quelli inerenti il nome origine dati (DSN, Data Source Name) e la risoluzione nomi. Generalmente, è preferibile utilizzare i nomi dominio completi. Quindi, nonostante spesso il problema potrebbe essere il firewall stesso, non dimenticare che le cause potenziali sono molte.

D Desidero utilizzare il mirroring di SQL Server 2005; tuttavia, ho sentito che è sconsigliato in caso di più applicazioni che si collegano a più database sulla stessa istanza di SQL Server. È vero?

R La risposta in realtà dipende da diversi fattori, ad esempio se ogni applicazione dispone del proprio database, se le applicazioni utilizzano transazioni tra database o Distributed Transaction Coordinator (DTC). Se vengono utilizzate transazioni tra database, il mirroring potrebbe presentare incongruenze logiche in cui le transazioni non vengono sottoposte a commit come previsto. Una spiegazione esauriente relativamente a quanto accade in queste circostanze è disponibile alla pagina

In caso di più database utilizzati da più applicazioni, con ciascuna applicazione che dispone del proprio database, il mirroring non causa questi problemi.

Transazioni contrassegnate

D Cosa sono esattamente le transazioni contrassegnate? Possono essere utilizzate con un database SQL Server e un database Oracle insieme?

R Una transazione contrassegnata è un'operazione eseguita periodicamente dal DBA per applicare un contrassegno nello stesso punto in tutti i log. Questa azione, insieme alla capacità di ripristinare una tabella in corrispondenza di un contrassegno di transazione, consente di ripristinare tutti i database allo stesso punto. Questa operazione può essere estremamente sgradevole in quanto si devono ripristinare tutti i database interessati, perdendo tutti i dati in essi contenuti, pertanto sarebbe meglio evitarla assicurandosi di non perdere i file di log. Le transazioni contrassegnate sono specifiche di SQL Server, quindi se le transazioni distribuite contengono dei database diversi da SQL Server, non possono prendere parte al contrassegno della transazione. In generale, pochissimi sistemi di database distribuiti utilizzano i contrassegni di transazione. La perdita di uno dei log delle transazioni sarebbe un evento catastrofico che richiederebbe molto lavoro manuale per il ripristino.

Strumento di conversione da Access a T SQL

D È disponibile uno strumento automatico per convertire Access™-SQL in T-SQL per le stored procedure?

R Provare SQL Server Migration Assistant (SSMA) for Access, che può essere scaricato dal sito Allo stesso indirizzo, sono disponibili anche SQL Server Migration Assistant for Oracle, SQL Server Migration Assistant for Sybase e Migrating Informix Databases to Microsoft® SQL Server 2000.

Per l'upsize da Access a SQL Server, è possibile utilizzare Office Upsizing Wizard, ma SSMA for Access, mostrato nella Figura 1, dispone di più funzionalità, tra cui report di valutazione conversione e scansione della rete. SSMA for Access corregge anche molti problemi che al momento non sono gestiti correttamente da Office Upsizing Wizard.

Figura 1.** SQL Server Migration Assistant (SSMA) for Access **(Fare clic sull'immagine per ingrandirla)

Indici non raggruppati

D Ho una tabella la cui chiave primaria è composta da due GUID (GUID1 e GUID2). Già dispongo di un indice raggruppato univoco su GUID1 e GUID2. Ora, per motivi di prestazioni, vorrei creare un secondo indice non raggruppato su GUID2 e GUID1. Le prestazioni potrebbero rallentarsi se dichiaro l'indice come univoco?

R Le prestazioni non verranno penalizzate se si dichiara l'indice non raggruppato come univoco. In realtà, in questo modo si riducono i livelli della struttura dell'indice.

Quando un indice non raggruppato viene dichiarato non univoco, l'indicatore di posizione delle righe viene aggiunto alla porzione principale delle voci di indice nelle pagine principali e non foglia. Lo scopo è di semplificare l'eliminazione e l'aggiornamento delle voci di indice, evitando la scansione di una catena di sinonimi in presenza di duplicati per una chiave. La voce specifica da modificare può essere individuata da un'operazione di ricerca nel sistema sul localizzatore chiavi avanzato. Ne consegue che quelle voci sono più lunghe (considerevolmente, con la chiave del cluster scelta). Di conseguenza, le pagine principali e non foglia verranno naturalmente compilate con più rapidità. Se l'indice è univoco, dovrebbe essere dichiarato come tale.

Il punto è questo: a prescindere che la tabella abbia un indice raggruppato o meno, per qualsiasi indice non raggruppato sulla tabella che non viene dichiarato univoco, verrà aggiunto un indicatore alle voci di indice nelle pagine principali e non foglia.

Per di più, se si utilizza una colonna identificatore int come chiave surrogata e si aggiungono due indici univoci (GUID1, GUID2) e (GUID2, GUID1), in questo modo, probabilmente, le prestazioni miglioreranno poiché gli indici avranno una chiave di clustering di 4 byte anziché di 32 byte.

Blocchi di aggiornamenti

D Ho una stored procedure con la seguente struttura:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION

-- Get The lock if available
UPDATE    ProcessingInstances 
SET       LockHolder = @MessageId
WHERE     ( InstanceId = @InstanceId ) 
AND       ( LockHolder IS NULL )

COMMIT TRANSACTION

Questa stored procedure consente a un solo chiamante di assumere il blocco, lasciando tutti gli altri in attesa. Posso ottenere lo stesso funzionamento riducendo il livello di isolamento?

Sembra che READ COMMITTED sia il livello di isolamento corretto perché questa transazione presenta solo una query e se altre transazioni si trovano nel processo di aggiornamento dello stesso record, questa transazione attende l'altra. È vero?

R Non è l'impostazione serializzabile di questo esempio che fa attendere gli altri chiamanti: è l'aggiornamento stesso. Sì, è possibile impostare il livello di isolamento su READ COMMITTED e l'aggiornamento utilizzerà naturalmente un blocco aggiornamento su qualsiasi indice che utilizza. Questo comporta dei problemi per gli altri processi che eseguono la stessa istruzione, i quali verranno bloccati fino al completamento dell'aggiornamento. (Inoltre, se l'aggiornamento rappresenta l'unica istruzione, la transazione esplicita non è necessaria; ciascuna istruzione si trova implicitamente nella propria transazione se non si trova in una esplicita).

Tuttavia, in assenza di righe corrispondenti alla clausola WHERE nell'istruzione UPDATE, l'uso del livello di isolamento serializzabile impedisce l'inserimento o la modifica di questo tipo di righe in altre transazioni. Se l'istruzione UPDATE fosse stata eseguita nel livello di isolamento READ COMMITTED, questo non sarebbe accaduto e le altre transazioni avrebbero potuto inserire righe qualificate per l'aggiornamento. Se il codice di stored procedure è identico al codice mostrato, non ha senso eseguire queste azioni (serializzabile o transazione); è sufficiente eseguire l'aggiornamento.

Si ringraziano i seguenti professionisti IT di Microsoft per la propria esperienza tecnica: Gaurav Aggarwal, Anthony Bloesch, Todd Briley, Shaun Cox, Roberto Di Pietro, Michael Epprecht, Kevin Farlee, Umachandar Jayachandran, Chuck Ladd, Kaloian Manassiev, Luciano Moreira, Ward Pond, Mark Prazak, Arunachalam Thirupathi, Roger Wolter, Clement Yip e Frankie Yuen.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.