SQL: Domande&RisposteClustering interno, blocchi misteriosi, account dell'amministratore di sistema e altro ancora

A cura di Nancy Michell

D: Ho bisogno di comprendere meglio il funzionamento del clustering. Il nostro ambiente sarà costituito da Windows Server® 2003 a 64 bit in cui viene eseguito SQL Server™ 2005, una Web farm SQL Server Reporting Services (SSRS) (distribuzione con scalabilità orizzontale del server di report), un server di catalogo TempDB SSRS e SQL Server che distribuisce i dati da un database di terze parti tramite un server collegato e in cui verranno memorizzati i dati per SSRS.

Desideriamo un cluster a 3 nodi attivo/attivo/passivo. Il nodo 1 dovrebbe essere attivo e servire per memorizzare i dati distribuiti dal database di terze parti. Il nodo 2 dovrebbe essere anch'esso attivo e servire per memorizzare il catalogo SSRS. Il nodo 3 dovrebbe essere passivo e servire come failover per il nodo 1 o 2. È possibile avere un aiuto?

A: Sfortunatamente, sono in troppi a essere fuorviati dai termini attivo/attivo e attivo/passivo quando si tratta di clustering di SQL Server. Si pensa, infatti, che il clustering di SQL possa supportare la "scalabilità orizzontale" di un'istanza di database o di SQL su più server. Ma non è così. In SQL Server, non è disponibile un'istanza o un database attivo/attivo. Per istanza "istanza" si intende un'installazione di SQL Server con i database corrispondenti. Il nostro clustering per l'istanza di SQL Server è sempre di tipo attivo (1) a passivo (n) (si noti che il valore di n varia da 1 a 7 a seconda della versione di SQL Server) ed è per questo motivo che viene chiamato clustering di failover.

Una volta compreso questo, è possibile iniziare a considerare l'installazione di più istanze di clustering di failover in un set di nodi. Ad esempio, tre server fisici che utilizzano dischi condivisi potrebbero avere un'istanza attiva per impostazione predefinita sul nodo 1 e una seconda istanza attiva per impostazione predefinita sul nodo 2, con il failover di entrambe eseguito sul nodo 3. Le istanze sono completamente separate, non condividono dati e non sono di tipo attivo/attivo. Sono invece entrambe di tipo attivo/passivo e condividono la stessa istanza di failover. Se il failover di entrambe viene eseguito sul nodo 3, la sfida consiste nel sapere se cederà sotto il carico. Strutturalmente, il failover è progettato per basarsi su una capacità di elaborazione uguale. Se, per l'elaborazione in condizioni di funzionamento normale, per un carico di picco sono necessari due nodi, difficilmente il nodo 3 sopravvivrà al carico di picco normalmente assegnato a due nodi.

Ciò detto, dato il costo dell'hardware in grado di eseguire un cluster, è comprensibile che le persone valutino la probabilità di un errore simultaneo di entrambi i nodi principali che costringe l'intero carico su un solo nodo. In virtù di tale considerazione, è possibile decidere di assumersi il rischio anziché acquistare hardware con una capacità di failover al 100 percento.

Per fortuna ci sono anche delle buone notizie: SQL Server 2005 è dotato di un numero maggiore di opzioni per l'alta disponibilità (HA, High Availability), con alternative in grado di eseguire il failover più rapidamente rispetto a un cluster e che possono prevedere persino copie duplicate di dati (il clustering si basa su una singola SAN). Tra queste sono incluse il mirroring, la replica peer-to-peer e altre opzioni. Grazie a queste nuove alternative, sono disponibili molte più opzioni in grado di soddisfare ogni sorta di esigenze, inclusa la possibilità di combinare diverse funzionalità per l'alta disponibilità.

Microsoft® Cluster Configuration Validation Wizard (ClusPrep), attualmente disponibile per il download, sostituisce quello che in precedenza era il test mediante Hardware Certification List (HCL), in base al quale potevano essere necessari mesi per convalidare una configurazione completa al fine di ritenerla in grado di supportare condizioni di clustering. Lo strumento di convalida dell'hardware viene ora posto nelle mani dell'amministratore di database, con un'ulteriore riduzione dei costi (in termini di denaro e di tempo) per la certificazione dell'hardware e la possibilità di convalidare e distribuire anche hardware eterogeneo all'interno di un singolo set di nodi del cluster.

D: Dopo 12 ore, una procedura di eliminazione in uno dei computer risulta sospesa, ma non bloccata. L'esame del piano delle query più lente rivela la presenza di un trigger in esecuzione per 87.327 secondi, facendo presupporre una sospensione della procedura in tale trigger. In che modo è possibile visualizzare l'istruzione in sospeso?

R: È molto probabile che un ciclo all'interno del trigger non abbia termine per vari motivi. Se la sospensione dura da molto tempo e si desidera visualizzare l'istruzione in esecuzione, eseguire il codice illustrato nella Figura 1. In questo modo verrà restituita l'istruzione attualmente in esecuzione, che dovrebbe essere quella che sta causando la sospensione del computer.

Figure 1 Individuazione dell'istruzione attualmente in esecuzione

-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20), 
        @start int, 
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle, 
        @start = stmt_start, 
        @end = stmt_end 
FROM Master..sysProcesses(NOLOCK) 
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT ‘Handle not found in cache’
ELSE
   SELECT ‘Current Statement’= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

D: Ho necessità di supportare la replica transazionale attraverso un firewall. Il server di pubblicazione e quello di distribuzione si trovano all'esterno del firewall, il sottoscrittore all'interno. L'ascolto del sottoscrittore è impostato su 1433 e i nomi dei computer utilizzati sono i seguenti: server di pubblicazione: PUBMACHINE, server di distribuzione: DISTMACHINE, sottoscrittore: SUBMACHINE. Quali porte è necessario aprire per consentire la riuscita della snapshot iniziale e del push di pubblicazione?

R: Se si utilizza una sottoscrizione push, l'apertura della porta SQL Server (1433 nel caso specifico) dovrebbe essere sufficiente, dato che l'agente di distribuzione verrà eseguito nel computer di distribuzione (all'esterno del firewall) e probabilmente disporrà di accesso locale ai file di snapshot generati dall'agente snapshot. Se invece si utilizza una sottoscrizione pull, l'agente di distribuzione in esecuzione nel computer del sottoscrittore dovrà in qualche modo accedere ai file di snapshot attraverso il firewall. Ecco le opzioni da prendere in considerazione.

Partendo dal presupposto che i file di snapshot siano già accessibili da una condivisione file all'esterno del firewall, è possibile aprire le porte di condivisione file di Windows® attraverso il firewall, in modo che l'agente di distribuzione in esecuzione all'interno del firewall possa accedere ai file di snapshot situati all'esterno (fare attenzione alle implicazioni di protezione che questa operazione può comportare per altre parti dell'infrastruttura). Si noti che, se è stato configurato un percorso locale come posizione predefinita della snapshot (impostazione predefinita di SSMS), potrebbe essere necessario utilizzare l'opzione /AltSnapshotFolder dell'agente di distribuzione per sostituire la posizione di prelievo del file di snapshot.

È inoltre possibile configurare la replica in modo da utilizzare l'FTP per il trasferimento dei file di snapshot (in questo caso è necessario aprire la porta 21).

D: Vorrei sapere se la disattivazione dell'account dell'amministratore di sistema in SQL Server 2005 presenta degli inconvenienti e se costituisce un reale valore aggiunto per la protezione. Esiste un white paper sull'argomento?

R: In una nuova installazione di SQL Server 2005 senza attivazione della modalità mista, l'account dell'amministratore di sistema è disattivato per impostazione predefinita e per esso viene generata automaticamente una password. È comunque possibile eseguirne la disattivazione manuale. Non esiste un white paper a proposito, ma la disattivazione e la ridenominazione degli account di accesso sono trattate in un articolo sulle procedure consigliate.

Se si desidera proteggersi da tentativi di violazione dell'account dell'amministratore di sistema, è possibile anche ridenominarlo. Non dimenticare che, se si attiva un account disattivato, è necessario impostare per esso una nuova password.

Per rispondere alla domanda se questa operazione offra un'effettiva protezione, ricordare che la maggiore protezione fornita dalla disattivazione dell'account deriva dal fatto che è inutile indovinare la password quando l'account è disattivato. Indipendentemente dal tempo a disposizione del pirata informatico o del virus, un attacco di forza bruta a un account bloccato non avrà mai esito positivo. Con la ridenominazione o la disattivazione dell'amministratore di sistema, le applicazioni che per la connettività dipendono dall'utilizzo di questo account verranno interrotte. L'individuazione e la modifica o l'eliminazione di queste applicazioni vanno quindi considerate in ogni caso come priorità. Come già accennato, l'account non può essere utilizzato per la connessione al database fino a quando non viene riattivato. Inoltre, poiché il processo di autenticazione non riesce in precedenza, un tentativo fallito richiederà un carico minore sul sistema attaccato.

D: In uno dei database di elaborazione delle transazioni in linea (OLP) di dimensioni maggiori è presente un file di registro la cui dimensione è il doppio di quella del file di dati. Ho tentato di utilizzare i comandi seguenti per ridurre il file di registro a una dimensione ragionevole, ma è necessario ridurlo ulteriormente:

backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

R: È consigliabile modificare il database di backup in un'istruzione del registro di backup. In alternativa, è possibile impostare il database in modalità di ripristino semplice ed eseguire l'istruzione shrinkfile. Al termine della compattazione del registro, impostare il database sul modello di recupero precedente ed eseguire il backup del database. Se ancora non si ottiene una compattazione, verificare che non siano presenti transazioni aperte (utilizzare dbcc opentran). Ulteriori informazioni sono disponibili nell'articolo seguente della Knowledge Base: support.microsoft.com/kb/907511.

D: Se si verifica un failover durante un processo pianificato di SQL Server Agent, cosa succede al processo dopo il failover? Devo riavviarlo manualmente?

R: Sì, è necessario avviarlo manualmente se non è in atto qualche altro processo. Se non si vuole riavviare manualmente i processi, è possibile scrivere uno script che consente di aggiornare una tabella una volta terminato un processo. Se il valore è uguale a 1, il processo è stato eseguito. Ogni altro valore indica che il processo non è stato completato e verrà eseguito successivamente un secondo processo con l'emissione del comando di avvio. Pertanto, anche se il processo deve essere eseguito nuovamente se si verifica un failover durante il suo passaggio, mediante uno script è possibile ridurre in parte le preoccupazioni legate a questi processi notturni fondamentali che devono essere assolutamente completati prima della giornata lavorativa seguente.

Suggerimento: aggiornamento e DBCC UPDATEUSAGE

Si sta eseguendo l'aggiornamento da SQL Server 2000 a SQL Server 2005?

In tal caso, accertarsi di eseguire DBCC UPDATEUSAGE immediatamente dopo l'aggiornamento dei database.

Il comando DBCC UPDATEUSAGE segnala e corregge le pagine e le inesattezze di conteggio delle righe nelle viste del catalogo, un'operazione necessaria perché queste inesattezze potrebbero causare la restituzione di report sull'utilizzo dello spazio non corretti da parte della stored procedure di sistema sp_spaceused. In SQL Server 2005, questi valori sono sempre mantenuti in modo corretto e pertanto nei relativi database non saranno mai presenti conteggi inesatti. Poiché è invece possibile che i database aggiornati a SQL Server 2005 contengano conteggi non validi, è consigliabile eseguire DBCC UPDATEUSAGE dopo l'aggiornamento.

Funzionamento di DBCC UPDATEUSAGE Questo comando corregge le righe, le pagine utilizzate, le pagine riservate, le pagine foglia e i conteggi delle pagine di dati per ogni partizione di una tabella o di un indice. Se nelle tabelle di sistema non ci sono inesattezze, non viene restituito alcun dato. Se invece vengono rilevate e corrette inesattezze e non è stato utilizzato WITH NO_INFOMSGS, vengono restituite le righe e le colonne aggiornate nelle tabelle di sistema.

DBCC UPDATEUSAGE può inoltre essere utilizzato per sincronizzare i contatori di utilizzo dello spazio. Poiché la sua esecuzione può richiedere del tempo in caso di tabelle o di database di grandi dimensioni, è in genere consigliabile utilizzare tale comando solo quando si sospetta la restituzione di valori non corretti da parte di sp_spaceused. Si noti che sp_spaceused accetta un parametro facoltativo per l'esecuzione di DBCC UPDATEUSAGE prima di restituire le informazioni sullo spazio relative alla tabella o all'indice.

In SQL Server 2005, DBCC CHECKDB è stato migliorato per rilevare quando i conteggi delle pagine o delle righe diventano negativi. In questo caso, verrà visualizzato un avviso in cui viene consigliato di eseguire DBCC UPDATEUSAGE per risolvere il problema. Sebbene il problema sembri causato dall'aggiornamento del database a SQL Server 2005, i conteggi inesatti esistevano già prima della procedura di aggiornamento.

Come esempio, ecco come aggiornare i conteggi delle pagine, delle righe o di entrambe per tutti gli oggetti presenti nel database corrente. Con il comando seguente viene specificato 0 come nome del database e vengono restituite le informazioni aggiornate relative al database corrente:

DBCC UPDATEUSAGE (0);
GO

Per aggiornare i conteggi delle pagine, delle righe o di entrambe per, ad esempio, AdventureWorks, e inoltre sopprimere i messaggi informativi, eseguire un comando simile al seguente, mediante cui viene specificato AdventureWorks come nome del database e quindi vengono soppressi tutti i messaggi informativi:

USE AdventureWorks;
GO
DBCC UPDATEUSAGE (‘AdventureWorks’) WITH NO_INFOMSGS; GO

Per ulteriori informazioni, ricercare DBCC UpdateUsage nella documentazione in linea di SQL Server.

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.

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