Supporto Tecnico Enterprise : Raffaella Canobbio

SQL Server - Algoritmo Proportional fill, Autogrow e loro effetto sulle dimensioni dei file di un filegroup

itentblg — Sun, 18 Oct 2009 23:00:00 GMT

Algoritmo di Proportional fill

L'algoritmo di Proportional fill (Proportional fill and how to check whether it works, Using Files and Filegroups) è l'algoritmo utilizzato per allocare extent (Understanding Pages and Extents) all'interno dei datafile di un filegroup (Files and Filegroups Architecture) che contiene da due a più datafile.

Sql server alloca un quantità di extent , proporzionale allo spazio libero all'interno di ciascun datafile di un filegroup, mantenendo in questo modo la stessa percentuale di spazio utilizzato su ciascun file.

Il calcolo della proporzione da utilizzare per allocare lo spazio nei file viene effettuato con le seguenti modalità:

la percentuale di Proportional fill viene ricalcolata dopo aver allocato 8192 extent
il numero degli extent liberi del file con più spazio libero, viene diviso per il numero degli extent liberi degli altri file
il rapporto considera solo numeri interi

Tramite l'utilizzo dell'algoritmo del Proportional fill , i file all'interno di un filegroup si riempono contemporaneamente.

Nel caso di datafile con uguali dimensioni iniziali, dovremmo aspettarci un uguale utilizzo dello spazio su tali file man mano che il database cresce di dimensione.

L'algoritmo di Proportional fill considera solo interi, per cui si possono determinare uguali allocazioni anche con diverso spazio libero tra i file , ad esempio quando il rapporto tra lo spazio libero tra i file non è esattamente di 1 a 2 .
Avendo, all'interno di un filegroup, un datafile con 10 Gb di spazio libero e un datafile con 19,9 Gb di spazio libero , il rapporto tra lo spazio libero dei due datafile non è esattamente di 1 a 2, per cui il tasso di allocazione sui datafile sarà identico. In questa situazione, lo spazio verrà allocato nella stessa percentuale anche in file aventi una diversa quantità di spazio libero, con conseguente sbilanciamento dello spazio occupato tra di essi.

Siccome l'algoritmo è ricalcolato frequentemente, gli errori dovuti al considerare solo numeri interi, dovrebbero bilanciarsi, arrivando generalmente a situazioni in cui tutti i file hanno la stessa percentuale di spazio utilizzato e arrivano in contemporanea ad occupare tutto lo spazio libero.

Autogrow

Le impostazioni di autogrow dei file di un database controllano il comportamento di tali file nel momento in cui raggiungono la loro massima dimensione Database Properties (Files Page)

Ho spesso affrontato problemi di performance causati da una crescita per autogrow dei datafile o log file di un database. Il consiglio per evitare che l’autogrow venga scatenato durante l’attività sul database, causando problemi di performance, è di controllare periodicamente che ogni file abbia necessario spazio libero all'interno. In tal modo, lo spazio verrà allocato internamente al file e si eviterà la necessità di crescita automatica a causa del raggiungimento della massima dimensione.

L’autogrow dovrebbe essere utilizzato solo per evitare problemi causati da crescite inaspettate e non pianificate del database e non come sostituto di un’opportuna analisi sull’andamento delle dimensioni del database.

Attenzione è anche da riservare alla percentuale impostata di autogrow.

Consideriamo un database che ha raggiunto la dimensione massima e su cui l’applicazione tenta di inserite dati. All’inserimento di dati, siccome non è più presente spazio libero, l’autogrow viene attivato.

Se l’autogrow è impostato al 10% delle dimensioni del database e il database è di circa 30 GB, l’autogrow tenterà di aumentare le dimensioni del database di 3 GB. Tale espansione potrà richiedere molto tempo e terminare prima del timeout applicativo , determinando il fallimento dell’operazione di insert con un generico errore di timeout.

Di seguito alcuni articoli relativi alle considerazioni sulle impostazioni di autogrow

L'autogrow oltre a causare problemi di performance , può indirettamente causare uno sbilanciamento tra le dimensioni dei datafile di uno stesso filegroup, sebbene tali file siano stati impostati inizialmente alla stessa dimensione e con identiche configurazioni di autogrow.

Di seguito la spiegazione di come ciò possa avvenire

Autogrow e sbilanciamento dello spazio allocato tra i file di un filegroup nonostante il funzionamento del Proportional Fill

Sql server, allo startup, crea una lista dei datafile disponibili e calcola la percentuale di Proportional fill come sopra specificato.

Dopo il verificarsi di un autogrow, Sql server conserva in memoria l'informazione di quale file nella lista sopra indicata è aumentato di dimensione per autogrow.

In caso di mancanza di spazio su un database, il file successivo viene preso in considerazione per eventuali allocazioni.

Al restart di Sql server, l'informazione relativa al file che ha subito l'autogrow, non viene mantenuta, per cui il primo file della lista viene nuovamente preso in considerazione in casi di mancanza di spazio , anche se l'autogrow si è appena verificato su di esso.

A causa di questo meccanismo può capitare che nonostante il Proportional fill, uno dei file di un filegroup , possa raggiungere dimensioni maggiori rispetto agli altri sebbene le configurazioni iniziali siano state identiche.

Soluzione

Al fine di evitare lo sbilanciamento delle dimensioni di file configurati inizialmente con le stesse dimensioni all'interno di un filegroup si suggerisce di :

aumentare manualmente e contemporaneamente la dimensione dei file di un filegroup
verificare lo spazio libero all'interno dei file e aumentarli prima che si verifichi l'autogrow
Per Sql server 2005, la seguente select , mostra lo spazio libero e allocato all'interno dei file

select
dbfiles.file_id,
[FILE_SIZE_MB] =
convert(decimal(12,2),round(dbfiles.size/128.000,2)),
[SPACE_USED_MB] =
convert(decimal(12,2),round(fileproperty(dbfiles.name,'SpaceUsed')/128.000,2)),
[FREE_SPACE_MB] =
convert(decimal(12,2),round((dbfiles.size-fileproperty(dbfiles.name,'SpaceUsed'))/128.000,2)) ,
NAME = left(dbfiles.NAME,15),
FILENAME = left(dbfiles.physical_name,30)
from
sys.database_files dbfiles
In Sql server 2008, è possibile utilizzare il trace flag -T1117 per attivare l' autogrow di tutti i file di un filegroup contemporaneamente, garantendo in questo modo che tutti i file rimangano alla stessa dimensione

Raffaella Canobbio
Senior Support Escalation Engineer
Microsoft Enterprise SQL Support

SQL Server - Errore 701 e Memory Clerk Userstore_sxc

itentblg — Mon, 20 Jul 2009 02:00:00 GMT

In questo post descriverò una possibile causa dell'errore 701 ed individuazione della sua origine.

Problema

In maniera sporadica alcune query falliscono con il seguente errore
Error: 701, Severity: 17, State: 123.
There is insufficient system memory to run this query.
Server a 32 bit:
Microsoft SQL Server 2005 - 9.00.3200.00 (Intel X86)
Windows NT 5.2 (Build 3790: Service Pack 2)

Dati raccolti

Per questa particolare occorrenza dell’errore 701 sono stati raccolti ed analizzati solo i dati sotto riportati.

Informazioni relative a Dbcc Memorystatus (INF: Using DBCC MEMORYSTATUS to Monitor SQL Server Memory Usage) registrate nell’error log di Sql server al momento della generazione dell’errore 701
Memory Dump di Sql server prodotto in modo automatico al verificarsi dell’errore 701 tramite l’abilitazione dei seguenti trace flag:
- .8004 per generare un dump al verificarsi dell’errore 701
- .8026 per eliminare automaticamente il trace flag 8004 una volta che un primo dump è già stato prodotto per l’errore 701. Questo eviterà la successiva produzione di dump nel caso in cui l’errore 701 avvenisse numerose volte
- .2551 per generare un filtered dump
  I trace flag potranno essere abilitati utilizzando dbcc traceon o l’opzione di startup -T come indicato in Trace Flags
Informazioni sulla configurazione del server quali output di Sp_configure per Sql server e memoria fisica del server

Analisi dei Dati

Quando si verifica l’errore 701, la prima attività, necessaria a determinarne la causa, è controllare lo stato della memoria di Sql server scritto nell’Error log subito dopo il verificarsi dell’errore.
Di seguito un estratto dell’Error log e informazioni sullo stato della memoria di Sql server:

2008-12-21 14:22:33.61 spid54 Buffer Distribution: Stolen=5097 Free=680 Cached=162318
Database (clean)=831513 Database (dirty)=100
I/O=0, Latched=4
2008-12-21 14:22:33.61 spid54 Buffer Counts: Committed=999712 Target=1048576 Hashed=831617
Internal Reservation=33587 External Reservation=0
Stolen Potential=-7875
Min Free=256 Visible=167936
Available Paging File=34149490688
2008-12-21 14:22:33.61 spid54 Procedure Cache: TotalProcs=3 TotalPages=63 InUsePages=15

Come si può verificare lo Stolen Potential è negativo. Stolen Potential indica il numero massimo di pagine che possono essere sottratte alla Buffer Pool (How to use the DBCC MEMORYSTATUS command to monitor memory usage on SQL Server 2005)

In queste condizioni di Stolen Potential negativo, Sql server inizia ad impedire successive richieste di allocazione nell'ambito della Stolen Memory, per cui si possono generare errori 701 o di mancanza di memoria durante l'esecuzione di una query.
La Stolen Memory indica buffers di 8Kb utilizzati per diversi tipi di allocazioni di memoria escluso le allocazioni per le pagine dati. Esempi di Stolen Memory possono essere allocazioni della procedure cache, metadata cache, memoria dell'optimizer o memoria per esecuzione di query.

Esamindano l'output di dbcc memorystatus in corrispondenza della memoria utilizzata dai vari Memory Clerk, è stato possibile individuare un Memory Clerk utilizzante 1.3 Gb per single page allocator (Per una descrizione della Buffer Pool e Memory Clerk riferirsi al post di Slava Oks SQLOS's memory manager and SQL Server's Buffer Pool)

USERSTORE_SXC (Total)
VM Reserved = 0 KB
VM Committed = 0 KB
AWE Allocated = 0 KB
SM Reserved = 0 KB
SM Committed = 0 KB
SinglePage Allocator = 1309464 KB
MultiPage Allocator = 0 KB

Essendo il sistema a 32 bit, la dimensione della Stolen Memory è limitata dalla dimensione del Virtual Address space ( 2 GB di memoria per processo utente su windows-32 bit non utilizzanti il /3GB Virtual Address Space ), perciò, la quantità di memoria utilizzata dallo User Store USERSTORE_SXC (1,3GB ), ha determinato una diminuzione della parte di memoria utilizzabile per Stolen Memory e pagine dati, determinando l'errore 701.

Per verificare su quale esatta allocazione l’errore 701 venisse prodotto, abbiamo analizzato il dump ottenuto tramite i trace flag sopra menzionati

Il dump, contenente le chiamate generanti l’errore 701, mostrava, il tentativo di allocazioni per USERSTORE_SXC (sqlservr!SOS_UserStore::CreateMemoryObject à sqlservr!SQLSinglePageAllocator::AllocatePages ), scaturito da chiamate RPC (sqlservr!processRPC)e fallito per condizione di mancanza di memoria (sqlservr!BPool::RecordFailure).

66f7f5ac 0158fefb sqlservr!BPool::RecordFailure+0x168
66f7f63c 0101890a sqlservr!BPool::Steal+0x15a
66f7f65c 01018a4f sqlservr!SQLSinglePageAllocator::AllocatePages+0x24
66f7f8b0 01018b4b sqlservr!MemoryNode::AllocatePagesInternal+0xd3
66f7f8d4 01042534 sqlservr!MemoryClerkInternal::AllocatePages+0x50
66f7f93c 01301643 sqlservr!MemoryObjectFactory::CreateMemObject+0x319
66f7f974 013015b4 sqlservr!SOS_UserStore::CreateMemoryObject+0x136
66f7f998 01058e69 sqlservr!CCacheableSessionExecState::CreateMemoryObjectPxp+0x82
66f7f9c4 01058947 sqlservr!srv_rpcinfo::PxpAllocate+0x39
66f7fa00 01058784 sqlservr!processRPC<3>+0x31e
66f7fa1c 0103d94c sqlservr!CRPCExecEnv::GetCommandInput+0x70
66f7fb94 0103d690 sqlservr!process_request+0x267
66f7fd4c 01008d68 sqlservr!process_commands+0x2e0

Da notare che una volta prodotta una condizione di mancanza di memoria , l’errore 701 potrebbe prodursi anche su allocazioni diverse da quella che ha causato il problema, in questo caso il dump ha semplicemente rinforzato il concetto di un errore 701 avvenuto durante il tentativo di allocazioni per USERSTORE_SXC

Soluzione

Il Memory Clerk USERSTORE_SXC ha, tra i suoi utilizzi, la gestione della memoria per immagazzinare le richieste RPC e relativi parametri.
Numerose chiamate RPC possono essere inviate al server in un'unica richiesta.
Se il client invia al server numerosi batch RCP di grandi dimensioni in un'unica richiesta, Sql server 2005 accumula tale richiesta in memoria prima di iniziare l’esecuzione.

La memoria utilizzata per immagazzinare questa richiesta, può diventare molto grande a seconda dei tipo di dati utilizzati per i parametri RPC e dalla dimensione dei batch (numero di RPC per richiesta).

La soluzione a questo problema consiste nel

ridurre la dimensione dei batch (numero di RPC per richiesta) oppure
riconsiderare il tipo di dati dei parametri RPC , ad esempio evitando di utilizzare sql_variant.

Una soluzione temporanea potrebbe essere quella di liberare ad intervalli regolari la memoria associata a USERSTORE_SXC tramite esecuzione di

DBCC FREESYSTEMCACHE ('sxcCacheStore') WITH MARK_IN_USE_FOR_REMOVAL

Raffaella Canobbio
Senior Support Escalation Engineer
Microsoft Enterprise SQL Support

SQL Server - Query distribuite in esecuzione senza mai terminare

itentblg — Mon, 25 May 2009 02:00:00 GMT

Recentemente ho affrontato alcun problemi legati all'hang di query distribuite che utilizzano linked server, creati con provider di terze parti, per accedere a sorgenti dati diverse da Sql Server.

Di seguito sono descritte le attività eseguite per individuare la causa e come risolvere i problemi.

Problema

In modalità casuale query utilizzanti linked server creati con provider di terze parti, rimangono in esecuzione senza mai terminare
In alcuni casi, dopo il verificarsi della prima query in hang, tutte le successive query utilizzanti lo specifico Linked server, rimangono nello stesso stato di hang
L'unica soluzione al problema consiste nel riavviare Sql Server
L'esecuzione di una select sulla sysprocesses mostra lo SPID, avente in esecuzione la query, in stato di running con attesa su oledb

Dati da raccogliere

Al fine di verificare l'effettiva attività rimasta in esecuzione all'interno di Sql server, catturare un mini dump o filtered dump del processo di Sql server

Di seguito il link su come utilizzare sqldumper per ottenere un filtered o mini dump
How to use the Sqldumper.exe utility to generate a dump file in SQL Server 2005

Mini-dump file that includes indirectly referenced memory
Sqldumper.exe ProcessID 0 0x0120:40

Filtered dump file
Sqldumper.exe ProcessID 0 0x8100
ProcessID, in questo specifico caso, è l'ID del processo di Sql server

Salvare il risultato di una select * from master..sysprocesses, per individuare facilmente il Thread Id avente in esecuzione la query.

Analisi dei dati e Soluzione

Installare i Debugging Tools for Windows
Aprire windbg
start-->program files-->Debugging Tools for Windows—>windbg
Caricare i simboli pubblici
Con Windbg aperto, selezionare File -->Symbols file path
Inserire srv*c:\symbols*http://msdl.microsoft.com/download/symbols
Caricare il dump prodotto
Con Windbg aperto , selezionare File -->Open Crash Dump, selezionare il dump precedentemente prodotto
Individuare all'interno del dump il Thread ID avente in esecuzione la query
Da Windbg, eseguire il comando ~ per avere la lista dei numeri relativi ai Thread ID e Thread instance
0:000> ~
. 0 Id: 2304.1500 Suspend: 0 Teb: bffdf000 Unfrozen
1 Id: 2304.141c Suspend: 0 Teb: bffdb000 Unfrozen
2 Id: 2304.11f4 Suspend: 0 Teb: bffda000 Unfrozen

Convertire in esadecimale il valore presente nella colonna sysprocesses.kpid in corrispondenza dello SPID avente in esecuzione la query verso linked server, tale valore sarà il ThreadID.
Cercare il valore così ottenuto tra i Thread ID nella lista sopra visualizzata, tenendo conto che nella riga "
2 Id: 2304.11f4 Suspend: 0 Teb: bffda000 Unfrozen", 11f4
è il numero del Thread ID e 2 è numero del Thread Instance

Da notare che a causa del thread switching, il Thread ID potrebbe cambiare velocemente

Per capire la relazione tra Spid. kpid e Thread Instance consiglio il seguente documento
INFO: How to Correlate Spid, Kpid, and Thread Instance
Posizionarsi sul thread eseguente la query tramite il comando
~~[ ThreadID]

Nel caso del dump da me analizzato, il numero del ThreadID era 1890
41 Id: 2304.1890 Suspend: 0 Teb: bff93000 Unfrozen

Per cui ho eseguito il comando ~~[1890]
0:000> ~~[1890]
. 41 Id: 2304.1890 Suspend: 0 Teb: bff93000 Unfrozen
Start: msvcr80!_endthreadex+0x61 (781329e1)
Priority: 0 Priority class: 32 Affinity: ff
Visualizzare lo stack frame del thread tramite il comando k
0:041> k
# ChildEBP RetAddr
00 0f13d4b8 7739bf53 ntdll!KiFastSystemCallRet
01 0f13d4f0 7738965e user32!NtUserWaitMessage+0xc
02 0f13d518 7739f762 user32!InternalDialogBox+0xd0
03 0f13d7d8 7739f047 user32!SoftModalMessageBox+0x94b
04 0f13d928 7739eec9 user32!MessageBoxWorker+0x2ba
05 0f13d980 773d7d0d user32!MessageBoxTimeoutW+0x7a
06 0f13d9b4 773c42c8 user32!MessageBoxTimeoutA+0x9c
07 0f13d9d4 773c42a4 user32!MessageBoxExA+0x1b
08 0f13d9f0 0cb13f41 user32!MessageBoxA+0x45
09 0f13dad4 0cb180ac ThirdPartydriver!......
0a 0f13db68 0cb1b196 ThirdPartydriver!......
0b 0f13dbb4 0cb1b4e6 ThirdPartydriver!......

Dallo stack sopra riportato, possiamo capire come il driver di terze party, rinominato come ThirdPartydriver, ha eseguito internamente a Sql server una message box, motivo per cui, il thread non può proseguire l'attività.

Con buona probabilità, il driver di terze party ha eseguito una message box in seguito ad un problema interno o errore verificatosi, per cui per continuare l'analisi del problema sarà necessario contattare il produttore del driver.

Raffaella Canobbio
Support Escalation Engineer
Microsoft Enterprise SQL Support

SQL Server 2005 – Risolvere gli errori in fase d’installazione

itentblg — Mon, 26 Jan 2009 03:00:00 GMT

In questo post descriverò un esempio pratico di come è stato analizzato e risolto un errore durante il tentativo di aggiunta di un nodo ad un Sql Server in cluster.

Problema

Sql Server 2005 è stato disinstallato da uno dei nodi di un cluster tramite la procedura di rimozione di un nodo descritta in questo articolo
How to: Add or Remove Nodes in a SQL Server 2005 Failover Cluster (Setup)

Il tentativo di aggiungere nuovamente il nodo al cluster fallisce.

Dati da raccogliere

Tutte le informazioni per poter individuare un problema avvenuto durante il setup di Sql Server 2005 sono contenute nei file di log posizionati in %ProgramFiles%\microsoft sql server\90\setup bootstrap\log

In caso di installazioni di Sql Server in cluster, i log sono consolidati in un'unica cartella senza la necessità di doverli recuperare su ciascun nodo del cluster.

Analisi dei dati

Nei seguenti articoli del Books Online è contenuta una descrizione dei file di log di Sql Server 2005 e come analizzarli

Verificare il summary.txt

Il primo file da verificare è il summary.txt il quale contiene un riassunto per ciascuna componente installata.

Per questo particolare problema il file summary.txt presentava un errore durante l’installazione del database engine e indicava il log SQLSetup000X_<sqlsrv>_SQL.log come il file contenente l’errore.

Machine : Sqlx
Product : Microsoft SQL Server 2005 (64-bit)
Product Version : 9.00.1399.06
Install : Failed
Log File : \\sql\C$\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup000X_<sqlsrv>_SQL.log
Last Action : SetInstanceProperty
Error String : The setup has encountered an unexpected error while Setting Internal Properties. The error is: 183
Error Number : 29528

Verificare il file di log contenente l’errore e indicato nel summary.txt

Per individuare l’errore corrispondente nel file di log SQLSetup000X_<srv>_SQL.log è necessario aprirlo in notepad ed effettuare una ricerca per “Return value 3”.

La prima azione che va in errore è quella indicata nelle linee del file di log che precedono la stringa “Return value 3”.

Come si può verificare da un estratto del file di log SQLSetup000X_<srv>_SQL.log sotto riportato, cercando per “Return value 3” , si individua l’azione generante l’errore.

In questa situazione specifica l’errore consisteva in un tentativo di creare un file già esistente

Doing Action: SetInstanceProperty
PerfTime Start: SetInstanceProperty : Mon Oct 27 15:06:05 2008
<Func Name='SetInstanceProperty'>
MSI (s) (08!30) [15:06:05:344]: PROPERTY CHANGE: Adding SqlOriginalMachineName property. Its value is 'SQLX'.
MSI (s) (08!30) [15:06:05:344]: PROPERTY CHANGE: Adding SqlLegacyRegPath property. Its value is 'Microsoft SQL Server\INSTANCE'.
Loaded DLL:
C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\xmlrw.dll
Version: 2.0.3609.0
Error Code: 0x800700b7 (183)
Windows Error Text: Cannot create a file when that file already exists.
Source File Name: sqlca\sqlcax.cpp
Compiler Timestamp: Wed Sep 21 01:10:12 2005
Function Name: SetInstanceProperty
Source Line Number: 969
Error Code: 183
MSI (s) (08!30) [15:08:48:663]: Product: Microsoft SQL Server 2005 (64-bit) -- Error 29528. The setup has encountered an unexpected error while Setting Internal Properties. The error is: 183
Error 29528. The setup has encountered an unexpected error while Setting Internal Properties. The error is: 183
<EndFunc Name='LaunchFunction' Return='183' GetLastError='0'>
Action ended 15:08:48: SetInstanceProperty.3EA9D9BF_D9D2_4023_B2A7_9E2137B2FB1B. Return value 3.
Action ended 15:08:48: INSTALL. Return value 3.

Sapendo che l’istanza era stata precedentemente rimossa dal nodo in cui si è verificato il problema e indicando il setup un errore relativo al tentativo di creare un file già esistente, abbiamo proceduto manualmente alla rimozione dell’istanza di Sql Server sul nodo avente il problema secondo la procedura sotto riportata.

Prima di indicare i punti della procedura utilizzata in questo specifico problema è bene tener presente che generalmente le procedure di rimozione manuale di un’istanza di Sql Server sono documentate pubblicamente nel seguente articolo: How to uninstall an instance of SQL Server 2005 manually

Di seguito le attività effettuate sul nodo affetto dal problema in questa specifica situazione:

Backup delle chiavi di registry al fine di garantire il server da danni causati da eventuali errori
How to back up and restore the registry in Windows
Localizzazione della seguente chiave di registry HKLM\Software\Microsoft\Microsoft SQL Server\Instance Name\Sql ed individuazione del valore MSSql.X relativo all’istanza avente il problema
All’interno di HKLM\Software\Microsoft\Microsoft SQL Server\Instance Name\Sql rimozione della chiave relativa all’istanza in questione
Rinomina della cartella relativa all’istanza c:\program files\microsoft SQL Server\MSSQL.X
Rimozione di HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL.X
Rimozione di
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQLServer$InstanceName
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SQLSERVERAGENT$InstanceName
Riavvio del nodo

Il successivo tentativo di aggiunta dell’istanza al nodo del cluster fallì con un nuovo errore.

Partendo sempre dalla verifica del file summary.txt è stato possibile individuare il secondo errore:

Machine : SQLX
Product : Microsoft SQL Server 2005 (64-bit)
Product Version : 9.00.1399.06
Install : Failed
Log File : \\Sqlx\C$\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup000X_<sqlsrv>_SQL.log
Last Action : InstallFinalize
Error String : The setup has encountered an unexpected error while Completing Commit. The error is: The cluster resource could not be found.
Error Number : 29528

Il file di log SQLSetup000X_<sqlsrv>_SQL.log indicato nel summary.txt non conteneva il nome della risorsa cluster non trovata.

Pertanto, non avendo ulteriori informazioni se non l’indicazione nel file di log di una risorsa cluster non trovata, sono state verificate le chiavi di registry associate alle risorse cluster relative ad un’installazione di Sql Server in cluster.

Durante la verifica delle chiavi di registry relative a Sql Server, Sql Server Agent e Full Text Search è emerso che la chiave relativa a Sql Server Agent non presentava i valori di VirtualServerName e InstanceName che devono essere presenti per tale risorsa in un’installazione di Sql Server in cluster

Di seguito le chiavi verificate:

HKEY_LOCAL_MACHINE\Cluster\Resources\ 710f2e43-4387-4066-848f-c1e189f82349
Name REG_SZ SQL Server Agent (SQLINSTANCE)

HKEY_LOCAL_MACHINE\Cluster\Resources\ 710f2e43-4387-4066-848f-c1e189f82349\Parameters
    ServiceName    REG_SZ    SQLAgent$QLINSTANCE
    StartupParameters    REG_SZ
    UseNetworkName    REG_DWORD    0x0

Di seguito , come dovrebbero apparire i valori di VirtualServerName e InstanceName per la risorsa Sql Server Agent

Per ricreare correttamente la chiave di registry relative alla risorsa Sql server Agent è stato seguito il seguente articolo
How to manually re-create the resource-specific registry keys for SQL Server cluster resources

Una volta ricreata correttamente la chiave di registry per la risorsa Sql Server Agent è stato possibile risolvere questo ultimo errore “The cluster resource could not be found” e aggiungere l’istanza di Sql Server al nodo del cluster.

Raffaella Canobbio
Support Escalation Engineer
Microsoft Enterprise SQL Support

SQL Server - Analizzare un problema di timeout utilizzando Sqlnexus

itentblg — Mon, 05 Jan 2009 03:00:00 GMT

Una delle richieste più frequenti che riceviamo nel team di supporto di Sql Server è quella di capire la causa determinante timeout applicativi durante l’esecuzione di query.

In questo post spiegherò come utilizzare Sqlnexus per effettuare velocemente l'analisi di un problema relativo alla lentezza di una query e determinante un timeout applicativo.

Problema

Errori di timeout, che si verificano in modalità casuale, durante una complessa attività applicativa.

Dati da raccogliere

Per capire la causa di problemi di timeout è necessario individuare l'attività su cui il timeout si verifica e se tale attività è stata affetta da blocchi o da problemi di performance sul server.

Dal punto di vista di Sql server, l’analisi di un timeout verificatosi durante l’esecuzione di una query, può essere inizialmente affrontata come un generico problema di performance volto ad identificare la causa per cui una determinata query viene eseguita in un tempo superiore a quello impostato dal timeout applicativo.

A tale scopo, durante il riprodursi del problema, si chiede generalmente di raccogliere dati di performance quali trace di Sql server profiler, System monitor counters e trace di Blocker script.

Il tool in grado di raccogliere contemporaneamente tali informazioni è Pssdiag:

Sql server 2000 è disponibile pubblicamente con interfaccia grafica al seguente indirizzo http://support.microsoft.com/kb/830232
Sql server 2005 è possibile utilizzare il tool Sqldiag compreso nell'installazione e non avente interfaccia grafica

Per avere un esempio degli eventi e counters da catturare è possibile far riferimento al seguente articolo HOW TO: Troubleshoot Application Performance with SQL Server.

In questa situazione specifica sono stati raccolti i seguenti eventi:

Database: tutti gli eventi
Errors and warning: tutti gli eventi
Locks: Lock:Deadlock, Lock:Escalation, Lock:Timeout
Objects: Auto Update Stats
Performance: Show Plan Statistics
Security Audit: Login, Login Failed, Logout
Sessions: ExistingConnestion
StoredProcedure: RPC:Completed, RPC:Starting, SP:CacheInsert, SP:CacheRemove, SP:Recompile, SP:StmtCompleted, SP:StmtStarting
Tsql:SQL:BatchCompleted, SQL:BatchStarting, SQL:StmtCompleted, SQL:StmtStarting

Analisi dei dati

In questa sezione vedremo come Sqlnexus possa essere utilizzato per analizzare i dati raccolti tramite le trace di Sql server profiler.

Installazione di Sqlnexus

Scaricare il tool Sqlnexus e verificare le informazioni sul suo utilizzo

Installare RML utilities

Caricamento dati in Sqlnexus

Avviare Sqlnexus.exe e connettersi a un Sql server in ambiente di test per effettuare l’analisi dei dati.
Una volta aperta l’interfaccia di Sqlnexus, cliccando su import, verrà visualizzata la finestra in cui impostare la cartella contenente i file di Sql server profiler raccolti con Pssdiag:

Visualizzazione dei dati di performance

Terminato l'import dei dati , potremo selezionare Readtrace_main, nella sezione Reports, per visualizzare l'analisi:

Selezionando i link presenti nella schermata di Performance Overview, potremo visualizzare i report indicanti le query eseguite durante l’intervallo di tempo di cattura dei dati e il rispettivo consumo di risorse. Tali report costituiscono un aiuto essenziale nell’individuare le query aventi maggiore impatto in termini di tempo di esecuzione , letture , scritture o consumo di CPU.

Individuazione dei timeout

Siccome l’obiettivo di questo blog e quello di analizzare le query su cui è avvenuto un timeout applicativo, dovremo individuare gli eventi di Attention avvenuti durante la cattura dei dati.
Per visualizzare tali eventi, selezioniamo Interesting events e sarà visualizzato un grafico simile a quello sotto riportato:

Come è possibile verificare dalla schermata sopra riportata, supponendo di aver impostato gli eventi necessari in Sql server profiler, potremo visualizzare tramite un grafico facilmente leggibile, altri tipi di eventi quali la crescita dei datafile o i sort warning e associare o meno tali eventi al verificarsi del problema.
Selezionando il link Attention, potremo visualizzare la query su cui è avvenuto il timeout e lo spid che stava eseguendo in quel momento la query.

Selezionando la query, potremo visualizzare tutti i dettagli sul tempo di esecuzione, le letture eseguite, il consumo di CPU e il nome del file di Sql server profiler contenente l’esecuzione della query durante l’avvenuto timeout.

Dalla schermata sopra riportata è evidente che il tempo di esecuzione della query ha superato i 30 sec di timeout impostato dall’applicazione.

Una volta individuata la query su cui si manifesta il problema, lo spid avente in esecuzione la query e l’intervallo di tempo in cui è avvenuto il timeout, potremo aprire la trace di Sql server profiler, filtrare per lo spid indicato da Sqlnexus, cercare la query affetta dal problema e analizzare in dettaglio i vari passi di esecuzione.

Nell’esempio qui riportato, analizzando la trace di Sql server profiler in corrispondenza della query e dell’intervallo di tempo in cui si è verificato il problema è stato possibile verificare che il timeout applicativo era dovuto ad un tempo di esecuzione superiori ai 30 sec e che la maggior parte del tempo di esecuzione, circa 25 sec, era utilizzato nella ricompilazione e inserimento in cache.

Se la trace di Sql server profiler non dovesse bastare ad individuare la causa del problema, sarà necessario effettuare altre verifiche quali l’analisi del Blocker script e dei Performance counters in corrispondenza dell’intervallo di tempo in cui si è verificato il problema oppure la verifica dettagliata del piano di esecuzione della query per effettuare un adeguato tuning.

Anche per analisi più approfondite Sqlnexus potrà aiutare, dandoci velocemente una panoramica delle attività presenti sul server durante il verificarsi del problema.

Raffaella Canobbio
Support Escalation Engineer
Microsoft Enterprise SQL Support