Domande e risposte su SQLCome limitare i riavvii, installare più aggiornamenti e altro ancora

A cura di Nancy Michell

Come limitare i riavvii

D In che modo è possibile limitare il numero di riavvii durante l'applicazione di aggiornamenti rapidi a SQL Server e al sistema operativo del server in generale?

R Innanzitutto, è interessante sapere che la maggior parte dei riavvii eseguiti dopo l'installazione non è specificata a livello di codice nel programma di installazione. I riavvii sono in genere il risultato di file bloccati. Questo significa che il programma di installazione sta tentando di aggiornare i file già utilizzati (bloccati) da un'altra applicazione o dal sistema operativo. Per eliminare la necessità dei riavvii è possibile utilizzare un approccio molto semplice, ovvero garantire che i file in questione non vengano utilizzati da alcun processo. Come si deve procedere in casi del genere?

Il primo passaggio consiste nella determinazione dei file utilizzati e bloccati durante l'installazione. Il metodo più semplice prevede la ricerca dei file nella seguente chiave del Registro di sistema: HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations. Il controllo di questa chiave del Registro di sistema ha due finalità specifiche: verificare che la richiesta di riavvio sia stata effettivamente causata dai file bloccati e indicare all'utente i file che sono stati bloccati. Se si cercano questi file dopo l'installazione, ma prima del riavvio, sarà possibile determinare la causa della richiesta di riavvio e intraprendere le azioni appropriate per eliminare tale problema nel corso delle future installazioni.

È possibile rilevare due tipi di voci. Se un file è stato bloccato in lettura, verrà visualizzata una voce con una riga per file che indica che il file aggiornato è già presente sul disco ma è necessario rimuovere la copia temporanea ancora in uso. Se un file è stato bloccato in scrittura, verrà visualizzata una voce con due righe per file che indica che l'aggiornamento non è stato ancora eseguito e che l'applicazione è in uno stato sconosciuto e pertanto è consigliabile non utilizzarla. È letteralmente come arrestare il sistema nel mezzo del processo di installazione. In questo caso una riga indica il file effettivo, mentre l'altra fa riferimento a un file temporaneo (che diventerà il file effettivo al riavvio).

La fase successiva dipende da numerosi fattori, ma lo scopo principale consiste nell'identificare l'applicazione software che sta utilizzando i file bloccati. Utilizzare, se possibile, strumenti di verifica delle dipendenze o il database DLL HELP in MSDN® (visitare il sito Web all'indirizzo support.microsoft.com/kb/815065) (in inglese).

Se per il software identificato esiste un servizio, arrestare il servizio manualmente e eseguirne di nuovo il test. Se si tratta di una singola applicazione, chiuderla e riprovare. Se un singolo file viene utilizzato da più applicazioni, come talvolta accade, sarà necessario arrestarle tutte.

Il risultato di tali test (nell'ambiente di test) è un elenco di applicazioni e servizi che è necessario arrestare prima dell'installazione nell'ambiente di produzione. L'ambiente di produzione non richiederà alcun riavvio, poiché nessuna applicazione software esegue il blocco di file di cui è in corso l'installazione. Al termine del processo di installazione, occorre naturalmente riavviare tutte le applicazioni arrestate.

L'aspetto interessante di questa procedura è il fatto che i blocchi in genere non subiscono variazioni significative. Se quindi si applica una sola volta questo modello sui sistemi utilizzati, è probabile che si eviteranno numerosi riavvii durante l'intero arco di utilizzo del sistema.

Esiste un altro utile metodo che vale la pena menzionare. Si supponga di disporre di più versioni di SQL Server™ o di un altro prodotto installato in modalità parallela e che si siano installate persino versioni diverse. È consigliabile aggiornare sempre per prima la versione più recente. È probabile che l'aggiornamento sostituisca le versioni dei programmi installati con le versioni più recenti e che tutte le altre istanze ignorino completamente i blocchi. Se, ad esempio, si dispone di tre istanze di SQL Server 2000 SP3, l'aggiornamento a SP4 di una di queste istanze determinerà l'aggiornamento del file MSXML3.dll e richiederà un riavvio. Si supponga di eseguire il riavvio. In tal caso sarà possibile aggiornare le altre due istanze a SP4 senza dover eseguire il riavvio, poiché il file MSXML3.dll aggiornato è già presente nel sistema. Lo stesso concetto è applicabile in uno scenario in cui l'aggiornamento per le istanze di SQL Server 2005 venga eseguito prima che per le istanze di SQL Server 2000 e che queste vengano aggiornate prima delle istanze di SQL Server 7.0. Si tratta di una strategia molto efficace per la riduzione al minimo dei riavvii.

Considerando la situazione da un punto di vista generale, i team di sviluppo Microsoft hanno profuso un notevole impegno nel tentativo di eliminare o limitare il numero di riavvii in molti scenari. Poiché questo articolo è incentrato su domande e risposte relative a SQL, si prenda come esempio SQL Server.

In SQL Server 2005 il team per SQL Server ha suddiviso il codice Microsoft® Data Access Components (MDAC) necessario per SQL Server in SQLNCLI (nuovi file) anziché aggiornare il componente MDAC e ha riportato nuovamente MDAC in banda con il sistema operativo. Qual è l'utilità di questo approccio? Il sistema operativo Windows® utilizza MDAC e mantiene bloccati questi file. Per questo motivo la maggior parte dei service pack di SQL Server e altri pacchetti determinavano dei riavvii. Ora, poiché SQL Server è in grado di aggiornare la versione di MDAC senza utilizzare i file MDAC in uso del sistema operativo, non è più necessario eseguire il riavvio.

Nel programma di installazione di SQL Server 2005 SP1 inoltre è incorporato uno strumento di verifica delle dipendenze che consente di identificare i file bloccati, oltre alla causa del blocco, e di arrestare immediatamente tutte le operazioni che determinano il blocco e continuare il processo di installazione senza eseguire alcun riavvio. È quindi possibile utilizzare questo strumento in tempo reale, senza la necessità di eseguirlo in un ambiente di test. È sempre possibile ovviamente continuare il processo di installazione ed eseguire il riavvio se si desidera o se si opera in modalità automatica. La semplicità con cui questo metodo consente di determinare l'origine del blocco è davvero straordinaria.

La tecnologia del programma di installazione Microsoft consente inoltre di gestire in modo più efficiente le chiavi PendingFileRenameOperations (PFR) esistenti. Come si ricorderà, il programma di installazione di SQL Server 2000 si blocca se un file è presente nella chiave del Registro di sistema citata in precedenza. Il programma di installazione di SQL Server 2005 si blocca solo se i file appartengono a SQL Server (quando è possibile che si venga a creare un conflitto) e anche in tali casi è in grado di individuare la chiave PFR e aggiornarla direttamente senza la necessità di un riavvio. Questa tecnologia è inclusa in MSI e in update.exe, i programmi di installazione Microsoft standard utilizzati per l'esecuzione di tutti gli aggiornamenti.

Quali sono alcuni dei problemi noti che causano il riavvio? MSXML3.dll rappresenta uno dei maggiori problemi. Questo file è sempre bloccato dal servizio SVCHost di Windows. Pertanto, qualsiasi sistema operativo che includa questo servizio richiederà l'esecuzione di un riavvio. Il servizio è inoltre presente in molti stack MDAC (mdac_typ.exe). MDAC è per fortuna in modalità "in banda" in Windows Server® 2003 e Windows XP SP2 e versioni successive. Il team di sviluppo di SQL Server ha svolto un lavoro eccezionale nel suddividere il file msxmlsql.dll in modo da impedire che gli aggiornamenti a SQL Server determinino il riavvio del sistema, anche se si prevede che il problema possa presentarsi occasionalmente ancora per qualche tempo. In tal caso non esiste una soluzione efficace: non è possibile arrestare SVCHost e continuare a eseguire gli aggiornamenti.

Inoltre, i pacchetti update.exe si comportano in modo del tutto peculiare durante il processo di disinstallazione. Se si disinstalla un pacchetto, quest'ultimo esegue il blocco (naturalmente all'esterno delle chiavi PFR) dei file temporanei del programma di installazione in modo da impedire l'esecuzione degli altri pacchetti update.exe fino a quando non si esegue il riavvio per rimuovere il blocco. L'unica azione che è possibile intraprendere è pianificare, una volta individuato il blocco, un riavvio dopo tutte le disinstallazioni degli aggiornamenti rapidi eventualmente eseguite.

Un altro problema a cui occorre far fronte è costituito dall'intermittenza. Non tutti i programmi utilizzano un file per il 100% del tempo. Infatti, l'utilizzo delle DLL condivise è nella maggior parte dei casi temporizzato, il che indica che gli altri programmi vi accedono solo quando necessario, in base al relativo carico di lavoro e ai percorsi di codice. Ne consegue che è possibile eseguire 10 test e non individuare alcun file bloccato e che si rilevi un file bloccato durante la distribuzione della produzione. Purtroppo non esiste l'arma in grado di eliminare in modo rapido e definitivo tutti i problemi. È sufficiente creare un ambiente di test quanto più possibile simile all'ambiente di produzione, incluso il carico (comunque un valido obiettivo), ed eseguire un numero di test sufficiente per evidenziare le permutazioni.

I service pack e gli aggiornamenti del sistema operativo richiederanno il riavvio. È opportuno sottolineare che nelle versioni di livello inferiore (Windows 2000, Windows XP e versioni precedenti), l'installazione viene completata solo dopo il riavvio, anche se la chiave del Registro di sistema pendingfilerenameoperations è vuota. Durante il riavvio, è possibile che vengano eseguite operazioni di registrazione dei pacchetti di eccezione per l'installazione del codice. Si tratta di operazioni che non fanno parte dell'installazione dei service pack, ma sono comandi incorporati nel sistema operativo corrente che vengono attivati dagli scenari di aggiornamento per consentire che determinati segmenti di codice in uso non vadano persi con l'aggiornamento.

Infine, la chiave PFR non esegue il controllo delle versioni dei file né applica l'ordinamento tramite la serializzazione. Ne consegue che la chiave avvia le sostituzioni dei file nell'ordine in cui sono elencati. Tuttavia, è stato dimostrato che in base all'ordine in cui vengono applicate al disco rigido tali sostituzioni costituiscono l'ultima operazione completata (non la prima a essere avviata). Un comportamento logico, ma che implica la presenza di due copie dello stesso file nello stesso percorso, ciascuna delle quali fa riferimento a versioni differenti, con un risultato casuale dopo il riavvio. Quando si verifica una situazione di questo tipo, è necessario procedere a una rapida soluzione. Se non si è certi, rieseguire semplicemente entrambi i programmi di installazione dopo il riavvio. Se sono disponibili i file corretti, nessuno dei programmi di installazione eseguirà alcuna operazione. Se sono disponibili i file errati, questi verranno corretti da un qualsiasi pacchetto con i file giusti. Francamente, questo approccio è molto più rapido e sicuro che tentare di stabilire quale sia il risultato desiderato.

Installazioni multiple di service pack

D Se si utilizzano otto istanze in cluster di SQL Server 2000 in un cluster a 4 nodi e si desidera installare SP4 eseguendo un numero minimo di riavvii, è possibile installare SP4 su tutte le 8 istanze una per volta e al termine riavviare tutti i nodi?

R Al termine dell'installazione di una singola istanza di SQL Server SP4, operazione che potrebbe richiedere un riavvio, in uno specifico server Windows (in cluster o meno), non sarà necessario eseguire ulteriori riavvii durante l'installazione di SQL Server SP4 in qualsiasi altra istanza di SQL Server sul computer. Il motivo va ricercato nel fatto che tutti i file condivisi, strumenti, MDAC, MSXML e così via, corrispondono già alla versione corretta e, bloccati o meno, non necessitano di ulteriore aggiornamento. Tutti i file non condivisi vengono utilizzati solo dalla prima istanza, che verrà arrestata in fase di installazione. È chiaro che, se si dispone di istanze multiple di più versioni, è sempre consigliabile aggiornare prima l'istanza più recente di SQL Server.

Esecuzione come account Servizio di rete

D Cos'è con esattezza l'account NT AUTHORITY\NETWORK SERVICE e qual è la funzione principale dell'account? Quali sono inoltre le implicazioni dell'account in termini di protezione, soprattutto quando si concedono i diritti sysadmin (sa)?

R L'account Servizio di rete ha la stessa identità (identità del computer) dell'account di sistema sulla rete, ma dispone di privilegi limitati sul computer locale. Se quindi un servizio richiede l'accesso alle risorse di rete, ad esempio per risolvere i nomi degli account con il controller di dominio, sarà necessario eseguirlo come account di sistema, account di dominio o Servizio di rete. Quest'ultimo account rappresenta in genere la soluzione che garantisce il massimo livello di protezione, poiché viene definito solo in un computer locale e dispone di privilegi limitati.

Se si imposta l'account Servizio di rete come account sysadmin in SQL Server, qualsiasi altro servizio eseguito come Servizio di rete sul computer locale avrà un controllo completo sul server. Questa situazione si verifica, ad esempio, quando l'account di servizio di SQL Server è configurato per l'esecuzione come Servizio di rete. L'impostazione di un account di servizio di SQL Server come membro di sysadmin è necessaria per la funzionalità del server, ad esempio per consentire connessioni in loopback. Sebbene la configurazione dell'account Servizio di rete per l'esecuzione con l'account amministratore su SQL Server non rappresenti una procedura di protezione ottimale, si potrebbe tuttavia rivelare migliore rispetto all'utilizzo di un account di dominio per tale scopo e garantisce un livello di protezione molto più elevato rispetto alla configurazione di SQL Server per l'esecuzione come account LocalSystem.

Se non si intende concedere i privilegi sysadmin all'account Servizio di rete, è consigliabile utilizzare un account di dominio dedicato in modo specifico all'esecuzione di SQL Server in una o più installazioni di Windows NT®.

Per ulteriori informazioni, vedere i seguenti articoli: msdn.microsoft.com/library/en-us/dnpag2/html/paght000009.asp (in inglese) e microsoft.com/technet/security/topics/serversecurity/serviceaccount (in inglese).

Creazione di più database

D Quando è necessario eseguire il partizionamento dei dati in singoli database, magari fino a 250 database in linea contemporaneamente e si prevede che solo il 20% verrà utilizzato per le query attive in un determinato momento, la creazione di più database è preferibile alla creazione di un numero minore di database?

R Il numero di database all'interno di un'istanza del server del database deve essere commisurato alle esigenze aziendali e ai fattori di amministrazione. L'overhead associato alla creazione di più database all'interno di una singola istanza del server è minimo, ma la creazione di più database implica un maggiore overhead di amministrazione per le attività di manutenzione, come backup e ripristino, mirroring, account utente e ruoli utente. Le complessità di amministrazione possono superare di gran lunga i vantaggi che derivano dalla creazione di più database.

In generale è consigliabile che tutti i dati correlati a un'applicazione vengano conservati in un unico database, in modo da semplificare la procedura di ripristino in caso di errore. Se i dati di un'applicazione sono distribuiti su più database, durante un failover sarà necessario ripristinare tutti i database. Un'operazione che può ritardare il ripristino o persino impedire un ripristino quando non è possibile ripristinare uno dei database.

Considerate le premesse, esistono motivi specifici per segregare i dati in più database:

• un sottoinsieme di dati presenta requisiti di backup diversi rispetto ad altri tipi di dati.
• Per alcuni dati è necessario un contesto di protezione separato, ovvero un proprietario di database differente.
• I dati vengono talvolta creati a scopo cronologico e devono essere conservati in modalità di sola lettura.

Si ringraziano i seguenti professionisti IT di Microsoft per aver contribuito alla redazione di questo articolo con il loro bagaglio di competenze tecniche: Ramon Arjona, Frank De Waelle, Robert Djabarov, Herman Learmond-Criqui, Maxwell Myrick, Ruslan Ovechkin, Uttam Parui, Shashi Ramaka, Gary Roos, Gavin Sharpe, Vijay Sirohi, Jimmie Thompson e Madhusudhanan Vadlamaani.

A cura di Nancy Michell

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