SQL: Domante&RisposteOra legale, memoria del server e altro ancora

A cura di Nancy Michell

Ora legale

D Date le modifiche imminenti all'ora legale negli Stati Uniti per conformarsi all'Energy Policy Act 2005 (Atto sulla politica energetica), devo aggiornare SQL Server™?

R La risposta è no. Al momento non sono richiesti aggiornamenti specifici a SQL Server per supportare le modifiche all'ora legale. Per le informazioni relative a data e ora, SQL Server si basa sul sistema operativo sottostante, vale a dire che se il sistema operativo riporta data e ora corrette, SQL Server riporterà e utilizzerà gli stessi valori. Per conformarsi alle modifiche imminenti all'ora legale, sarà richiesto di aggiornare le copie di Windows® come descritto in support.microsoft.com/kb/928388. Ciò è richiesto per tutti i sistemi operativi Windows precedenti a Windows Vista™ (che già contiene le modifiche) per conformità alle modifiche all'ora legale, compresi i sistemi operativi in cui è in esecuzione SQL Server. Anche in Australia sono previste modifiche. Vedere support.microsoft.com/kb/ il 912475.

Collegamento a Windows Vista

D Ho installato Windows Vista e adesso non riesco più a collegarmi a SQL Server 2005 sul mio sistema. Sono un amministratore locale e sono sempre riuscito a effettuare questa connessione senza problemi. Che cosa è successo?

R Questo tipo di comportamento è prevedibile in Windows Vista e SQL Server 2005 senza Service Pack 2 (SP2). Windows Vista contiene un nuovo modello di protezione (il controllo dell'account utente) che in effetti racchiude l'appartenenza dell'utente nel gruppo di amministratori locali e richiede di verificare le operazioni che richiedono privilegi amministrativi. Se si fa clic sul pulsante Consenti, le credenziali, che contengono il token amministratore, sono inviate all'applicazione. Nel caso di SQL Server Management Studio (SSMS) non viene visualizzata una finestra di dialogo perché non sono richieste autorizzazioni amministrative per eseguire solo lo strumento. Il problema è che, per impostazione predefinita, il ruolo amministratore di sistema SQL Server 2005 comprende il gruppo di amministratori locali dal sistema operativo, ed è questo che l'account utilizzava in precedenza per accedere a SQL Server. Poiché Windows Vista non invia tale autorizzazione, l'utente non riesce ad ottenere l'accesso.

Bisogna notare l'esecuzione di SQL Server 2005 senza SP2 non è supportata in Windows Vista e che SP2 contiene uno strumento che aggiungerà automaticamente l'account utente. Se si aspetta ancora SP2, la correzione è semplice. L'account utente Windows individuale deve essere aggiunto a SQL Server, in questo caso al ruolo amministratore di sistema. A tale scopo, fare clic con il pulsante destro del mouse su SQL Server Management Studio e scegliere Esegui come amministratore. Collegarsi a SQL Server e aggiungere il proprio account Windows al ruolo amministratore di sistema. Per ulteriori informazioni, vedere la Documentazione in linea di SQL Server.

Replica per componenti transazionali con viste

D Se ho una vista pubblicata e l'aggiorno, so che quella transazione sarà replicata. Se, invece, aggiorno la tabella di base di questa vista, tale transazione sarà replicata? E ancora, se ho una tabella pubblicata, ne creo una vista e aggiorno la vista invece della tabella di base, tale transazione sarà replicata?

R Supponendo che la tabella di base sia configurata come articolo in una pubblicazione (vale a dire, la tabella di base è stata configurata anche per la replica), ogni aggiornamento alla tabella di base sarà replicato.

Quando si replica una vista, per impostazione predefinita tutto ciò che è replicato come parte di una vista è la porzione di schema della vista o il codice dietro la vista, non i dati sottostanti (a meno che non si tratti di una vista indicizzata). Quindi, anche senza replica, ogni volta che si aggiorna una vista (in questo caso ciò vuol dire eseguire un'istruzione DML (Data Manipulation Language) con la vista come destinazione) si aggiornano effettivamente i dati nella tabella sottostante e non nella vista. Una vista è semplicemente un'archiviazione logica di un'istruzione di query senza alcuna archiviazione fisica associata (di nuovo, a meno che non si utilizzino viste indicizzate).

Memoria massima del server

D Ho un computer in cui sono in esecuzione Windows Server® 2003 e SQL Server 2000, con 5 GB di RAM. Utilizzo lo switch /3GB per aumentare lo spazio virtuale di indirizzi in modalità utente, lo switch /PAE per caricare la versione di estensione indirizzo fisico (PAE) del kernel Windows e impostare Address Windowing Extensions (AWE) Enabled su 1 (attivando le pagine di blocco in memoria). Con le estensioni AWE attivate, l'opzione di memoria massima del server configurerà solo la dimensione della cache dati o la dimensione di tutte le cache buffer (dati, processi, sessioni e così via)? Poiché soltanto la cache dati può utilizzare la memoria mappata AWE, se configuro la memoria massima del server su 4 GB, la cache dati utilizzerà soltanto 1 GB (la porzione mappata da AWE) o potrà utilizzare anche questo 1 GB aggiuntivo? Continuerà, inoltre, a utilizzare tutti gli altri consumatori di memoria nello spazio di indirizzi standard o competerà con essi?

R La memoria massima del server limiterà sempre l'intera dimensione pool di buffer; tuttavia, l'unico consumer di memoria che potrebbe fare uso della memoria mappata AWE è la cache dati.

Per quanto riguarda la prima domanda, anche con AWE attivato, la memoria massima del server limita l'intero pool di buffer, ma chi non utilizza cache dati non utilizzerà mai alcuna porzione della memoria mappata AWE.

Per quanto riguarda la seconda domanda, la cache dati utilizzerà la memoria mappata AWE e, inoltre, ogni altra memoria nel pool di buffer che sarà ritenuta appropriata da SQL Server; l'utilizzo non sarà limitato soltanto alla memoria AWE, semplicemente è il solo consumer che può utilizzare la memoria AWE. Se si hanno dubbi sulle funzioni dello switch /3GB, vedere il blog di Raymond Chen.

Profiling e prestazioni

D Ho SQL Server 2005 con mirroring in produzione. Quando avvio SQL Server Profiler sul computer del database e scrivo i dati di traccia su file, noto una notevole riduzione delle prestazioni. Perché?

R La ragione della riduzione delle prestazioni dipende da dove è in esecuzione Profiler. Se Profiler è in esecuzione in modalità interattiva sul server, l'interfaccia utente di Profiler utilizza sia la memoria sia la CPU del server e ciò ha un impatto sulle prestazioni.

Se Profiler è in esecuzione in modalità interattiva su una workstation, le informazioni degli eventi si spostano attraverso la rete. Questo ha un impatto sulla produttività. Se è la stessa rete utilizzata per effettuare il mirroring, si noterà un impatto anche qui. Inoltre, se si archivia l'output di Profiler su una condivisione di rete, i dati vengono spostati attraverso la rete, con effetti negativi sulle prestazioni.

Probabilmente, il modo migliore per attenuare questi problemi è eseguire Profiler in modo non interattivo sul server in cui è in esecuzione l'istanza da analizzare e quindi trasportare l'output in un file locale. In tal modo si utilizzano risorse del server, tuttavia questo approccio ha generalmente il minimo impatto. Questo funziona molto meglio del file traccia Profiler (in memoria). Il file traccia utilizza la memoria di sistema in maniera più efficiente; dispone di buffer più ampi e li inserisce nel disco più efficacemente. Inoltre non dipende da processi esterni (come SQL Server Profiler).

Infine, i dati di traccia sono scritti su un file su disco mentre Profiler continua a realizzare il profiling. Il file di traccia è condiviso in modo che altri utenti possano vedere i dati di profilo in tempo reale in modalità remota. Se si chiama il file di traccia in modo interattivo, significa che Profiler è stato richiamato manualmente e si sta osservando l'output sulla schermata. I file di traccia possono essere creati a livello di programmazione senza alcun output visivo, motivo per cui si dovrebbero eseguire attività in modo non interattivo.

È possibile creare una condivisione su una directory locale e altri utenti possono accedere ai file presenti, e questo di solito funziona bene. Come indicato in precedenza, è preferibile non inviare output di traccia a un file su una condivisione remota, soprattutto a una condivisione cui si accede attraverso la stessa pipe di rete utilizzata per effettuare il mirroring.

Inoltre bisognerebbe scegliere soltanto la minima serie di eventi necessaria per la ricerca. Per la posizione del file di traccia è necessario scegliere l'unità più veloce del sistema (che sia preferibilmente diversa dal database e dalle unità di log delle transazioni SQL Server). Se si verifica ancora una riduzione significativa delle prestazioni, bisogna dividere gli eventi in due o più tracce, ognuna con un disco rigido di destinazione diverso. Anche se le tracce vengono destinate allo stesso disco rigido, la divisione apporterà dei benefici in quanto ogni traccia possiede una serie di buffer individuale. Per ulteriori informazioni vedere sp_trace_create e gli argomenti relativi nella Documentazione in linea di SQL Server.

Problemi relativi al clustering

D Sto cercando di installare SQL Server su un cluster in cui è in esecuzione Windows Server 2003. Ogni volta che provo, ricevo il messaggio di errore "Impossibile eseguire le operazioni necessarie in almeno un nodo del cluster." In sqlstp.log è contenuta la dichiarazione:

Script file copied to '\\SERVER01\ADMIN$\SERVER01_MSSQLSERVER.iss' successfully.
Installing remote service (SERVER01)...
An error occured in the service create (SERVER01): 1069...

Qual è la causa del problema?

R Questo errore può essere causato da motivi diversi. La procedura di installazione installa Windows NT® Service su tutti i nodi selezionati per gestire in modalità remota il processo di installazione sui computer individuali. Pertanto è necessario essere consapevoli di alcuni problemi che possono accadere.

In primo luogo, gli utenti dell'account di dominio potrebbero utilizzare dei criteri di gruppo che negano l'autorizzazione "log on as service (accedi come servizio)". Ricordare che i criteri di dominio hanno la precedenza sui criteri del computer locale. Assicurarsi di utilizzare un account libero da queste restrizioni.

In secondo luogo, l'account connesso del computer in cui si sta eseguendo l'installazione dovrebbe avere accesso amministrativo su tutti i nodi per i motivi seguenti: il processo di installazione master richiede l'accesso al registro di sistema remoto per tutti i computer; l'installazione copia cnvsvc.exe sulla directory Windows del computer remoto; oppure l'installazione utilizza Windows API standard che utilizzano soltanto l'autorizzazione dell'account per accedere ai computer remoti. Per queste ragioni è necessario collegarsi con accesso amministrativo in tutte le modalità, per impostazione predefinita.

Piano di ripristino di emergenza

D Sto considerando se utilizzare il mirroring del database (modalità asincrona) o la distribuzione dei log per implementare la strategia Ripristino di emergenza nei miei database SAP. La mia produzione di siti DR avrà una connessione a banda larga da 100 MB non dedicata alla sessione di mirroring. La connessione sarà condivisa fra diverse sessioni di mirroring o anche con altri server DR.

Se sussiste un problema di rete che impedisce al record del log di essere inviato al database di mirroring, il computer tenterà un retry?

Quando la sessione di mirroring è sospesa, esiste un periodo di conservazione? E infine, oltre alle viste del sistema, esistono informazioni log di cui mi posso servire per monitorare il traffico di mirroring e la trasmissione dei record di log?

R Iniziamo rispondendo alla domanda: qual è la logica delle operazioni di retry del mirroring del database? È possibile analizzare questo argomento in due modi: Per prima cosa, se esiste un problema di rete temporaneo, lo stato della sessione di mirroring è disconnesso. Esiste un valore di timeout di rete predefinito pari a 10 secondi; ciò significa che un record di log non può essere inviato dal database principale al database di mirroring. In tali casi, il database principale continuerà a essere in esecuzione in modalità "esposta" e la transazione eseguirà il commit dal lato client. Una volta risolto il problema di rete, la sessione di mirroring verrà ritentata automaticamente, senza intervento da parte dell'utente. La sessione tenterà il recupero utilizzando i record di log; i partner si sincronizzeranno per primi e una volta recuperata la posizione, lo stato sarà sincronizzato.

In secondo luogo, se si verifica un problema di ripristino, lo stato della sessione di mirroring viene sospeso. Un problema di ripristino significa che il database di mirroring non è in grado di eseguire il commit dei record del log sul proprio database. I problemi di ripristino sono principalmente causati dal mancato ritrovamento di un file fisico o da spazio su disco insufficiente. In tali casi, il database principale continuerà ad essere eseguito in modalità esposta e la transazione eseguirà il commit dal lato client. Dopo che sono stati risolti manualmente i problemi di ripristino sul server di mirroring, occorre intervenire sulla sessione di mirroring:

ALTER DATABASE <db> SET PARTNER RESUME; 

Per quanto riguarda i periodi di conservazione, la risposta è che, a prescindere se la sessione di mirroring è disconnessa o sospesa, i record di log saranno mantenuti finché la sessione non sarà ripristinata e tutti record, dal momento in cui la sessione è stata sospesa fino al momento del suo ripristino, verranno protetti sul mirror. In sostanza, mentre la sessione di mirroring è disconnessa o sospesa, il log nel computer principale non può essere troncato, in quanto ciò bloccherebbe la catena di ripristino del log. Questo significa che il log del computer principale aumenterà senza limiti finché la sessione non verrà ripristinata. Pertanto, non esiste effettivamente alcun limite di conservazione nella sessione di mirroring; l'unico vincolo reale è lo spazio sul disco del server principale per la memorizzazione del log, in quanto questo non può essere troncato.

Infine, non esiste un file di log specifico da utilizzare per monitorare il mirroring. SQL Server 2005 fornisce a questo scopo uno strumento GUI chiamato Database Mirroring Monitor, che permette agli amministratori di sistema di osservare e aggiornare lo stato e configurare soglie di avviso su diversi criteri di misurazione di prestazioni chiave. Ciò consente di ricevere un avviso quando il mirroring non viene eseguito correttamente. La questione essenziale per le prestazioni nel mirroring del database è se i record del log siano elaborati in maniera tempestiva. Per ulteriori informazioni sul monitoraggio del mirroring del database, consultare l'articolo Monitoring Mirroring Status (in inglese) all'indirizzo msdn2.microsoft.com/fr-fr/library/ms365781.aspx.

Si ringraziano i seguenti professionisti IT di Microsoft per la propria esperienza tecnica: Chad Boyd, Sandu Chirica, Alan Doby, Kaloian Manassiev, Luciano Moreira, Ivan Penkov, Sivagaminathan Rajarethinam, Deborah To, Patrick Woodward, Buck Woody, Stanley Yau e Warren Young.

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