Supporto Tecnico Enterprise : SQL Team

SQL 2005 – Utilizzo del setup da riga di comando per upgrade/downgrade di versione

itentblg — Mon, 23 Nov 2009 00:00:00 GMT

L’esecuzione del setup di SQL Server da riga di comando permette di specificare diversi parametri e configurazioni e viene principalmente utilizzato per effettuare un upgrade di versione o per aggiornare versioni “Evaluation” a quelle definitive; in casi eccezionali può essere usato anche per l’operazione inversa (downgrade) preservando i dati e le configurazioni esistenti.

prendiamo ora in considerazione il caso più “semplice”, l’upgrade di versione ed i relativi passi. Si fa riferimento ad un istanza di SQL Server in configurazione cluster, con le opzioni non necessarie alle configurazioni standalone commentate singolarmente

E' necessario avere a disposizione il DVD della versione RTM o i file di installazione in una directory locale
Aprire un Command Prompt e posizionarsi nella directory Servers del DVD o della copia locale
eseguire il seguente comando:

start /wait setup.exe INSTANCENAME=SQL2005CU11 UPGRADE=SQL_Engine SKUUPGRADE=1 /qb VS=VSQL2005 ADMINPASSWORD=pwd GROUP="SQL 2005 ENG CU11" ADDNODE=W2K3NODE1_1,W2K3NODE2_2

Vediamo il significato dei vari parametri, applicati ad un cluster di laboratorio che ho usato per i test

INSTANCENAME è il nome dell’istanza da aggiornare, specificare MSSQLSERVER nel caso si tratti di quella di default
UPGRADE permette di specificare l’elenco delle componenti da aggiornare separati dalla virgola: in questo caso SQL_Engine informa il setup di aggiornare solo la parte di “Database Engine”
SKUUPGRADE=1 è il parametro che permette l’aggiornamento
VS è il nome del Virtual Server da aggiornare, ossia il nome della risorsa “Network Name” all’interno del gruppo del cluster che contiene SQL Server; questo parametro non serve per le configurazioni standalone
ADMINPASSWORD è la password dell’account (con diritti amministrativi) correntemente logato al nodo del cluster che sta eseguendo il setup; serve per potere gestire il nodo remoto (o i nodi) durante il setup. Non è richiesto per le configurazioni Standalone
GROUP è il gruppo del cluster all’interno del quale si trovano le risorse di SQL Server e nel caso in cui ci siano degli spazi il nome deve essere racchiuso tra doppi apici. Non è richiesto nelle installazioni Standalone
ADDNODE è utilizzato per specificare l’elenco dei nodi che possono essere “owwer” dell’istanza. Non richiesto per le Standalone
/qb abilita una modalità “semi silent” visualizzado solo richieste di input quando necessario

Vediamo ora le operazioni necessarie per potere fare il downgrade della versione mantenendo i database e le configurazioni esistenti; le operazioni sono un po’ più lunghe che nel precedente caso.
Per prima cosa occorre rimuovere l’istanza esistente usando il parametro SAVESYSDB, per cui lasciando inalterati i precedenti punti 1 e 2 la riga di comando diventa

start /wait setup.exe /qb INSTANCENAME=SQL2005CU11 VS=VSQL2005 REMOVE=All ADMINPASSWORD=pwd SAVESYSDB=1

Tutti parametri già visti tranne SAVESYSDB=1 che è quello che istruisce il setup di mantenere i database di sistema nella directory DATA originaria e REMOVE, che serve per indicare le componenti che devono essere rimosse, in questo caso tutte (All): è consigliabile comunque fare una copia dei file esistenti.
A questo punto si può procedere con l’installazione della nuova istanza seguendo i passi seguenti:

Riavviare i nodi dopo la rimozione di SQL effettuata in precedenza
Seguire i punti 1 e 2 gia visti per l’upgrade
eseguire la seguente riga di comando:
start /wait setup.exe /qb VS=VSQL2005 INSTANCENAME=SQL2005CU11 GROUP="SQL 2005 ENG CU11" ADDNODE=w2k3node1_1,w2k3node2_2 INSTALLVS=SQL_Engine ADDLOCAL=SQL_Engine,SQL_Replication,SQL_FullText,Client_Components,Connectivity,SQL_Tools90,SQL_Documentation,SQL_BooksOnline IP=10.10.10.80,ToHost INSTALLSQLDIR="C:\Program Files\Microsoft SQL Server" INSTALLSQLDATADIR="g:\Program Files\Microsoft SQL Server" ADMINPASSWORD=pwd SQLACCOUNT=CLUSTERDOM\sqlsvc SQLPASSWORD=pwd AGTACCOUNT=CLUSTERDOM\sqlsvc AGTPASSWORD=pwd SQLBROWSERACCOUNT="NT AUTHORITY\SYSTEM" SQLCLUSTERGROUP=CLUSTERDOM\CLUSTER AGTCLUSTERGROUP=CLUSTERDOM\CLUSTER FTSCLUSTERGROUP=CLUSTERDOM\CLUSTER USESYSDB="G:\Microsoft SQL Server\MSSQL.1\MSSQL"

Tra i vari parametri non ancora visti abbiamo:

INSTALLVS indica per quale componente si vuole creare un Virtual Server (in questo caso il Database Engine). Non è richiesto nel caso di installazione locale
ADDLOCAL permette di specificare quali componenti aggiungere alla parte locale dell’installazione: l’elenco riportato sopra corrisponde ad un’installazione tipica che comprende Database Enginge, Management Tools, Performance Tool e BooksOnline.
IP serve a specificare l’IP assegnato all’istanza ed il nome assegnato alla connesione di rete da usare, separati da una virgola; devono rimanere identici all’ IP e al nome della rete dell’istanza rimossa in precedenza. Non richiesto per un server Standalone.
INSTALLSQLDIR è la directory di installazione locale di SQL Server
INSTALLSQLDATADIR e la directory predefinita per il posizionamento dei file di dati e deve coincidere con quella precedente
SQLACCOUNT e SQLPASSWORD rappresentano l’account di servizio di SQL Server e relativa password
AGTACCOUNT e AGTPASSWORD rappresentano l’account di servizio del SQL Server Agent e relativa password
SQLBROWSERACCOUNT è l’account associato al servizio SQL Server Browser. Nel caso in cui si lascia l’account System (consigliato) non è necessario specificare la password
SQLCLUSTERGROUP, AGTCLUSTERGROUP e FTSCLUSTERGROUP rappresentano i gruppo di dominio necessari per l’installazione di un’istanza cluster e non sono richiesti nel caso di Standalone
USESYSDB permette di specificare il percorso base dal quale prendere i file di sistema e i database utente esistenti

Entrambe le modalità di "upgrade” riportano SQL Server alla versione RTM per cui al termine è necessario ri-applicare la stessa Service Pack e Cumulative Update esistenti prima dell’attività di manutenzione.

Mauro Munzi
Senior Support Engineer
Microsoft Enterprise SQL Support

SQL 2000 - Spostamento della directory FTDATA su un altro disco per un istanza Cluster

itentblg — Mon, 16 Nov 2009 00:00:00 GMT

Mi è capitato alcune volte di incontrare clienti che hanno avuto problemi durante lo spostamento della directory FTDATA di SQL Server 2000 da un disco all’altro (così come da una directory all’altra all’interno dello stesso disco); praticamente tutti hanno fatto riferimento all’articolo tecnico http://support.microsoft.com/kb/240867/en-us e si sono scontrati con alcuni punti che sembrano essere un po’ difficili da applicare, in particolare quelli relativi alle modifiche sulle chiavi di registry.

A tal proposito già diverse volte mi sono trovato a suggerire una procedura alternativa, che non vuole rimpiazzare l’articolo tecnico, che i feedback ottenuti fino ad ora mi hanno confermato essere di più semplice implementazione; in questo caso ci stiamo riferendo ad una istanza di SQL Server 2000 in configurazione Cluster, ma le stesse informazioni possono essere applicate anche ad un server stand-alone.

Vediamo in dettaglio le azioni da fare: in questo caso si parte da una FTDATA posizionata in G:\Program Files\Microsoft SQL Server\MSSQL$SQL2000SP4\FTDATA, riferita a una Named Instance “SQL2000SP4”. Nel caso di un istanza di default non avremo MSSQL$SQL2000SP4 ma semplicemente MSSQL. La directory FTDATA alla fine della procedura si troverà su un nuovo disco Y: mantenendo lo stesso percorso, ma le stessa procedura può essere utilizzata per spostarla in qualsiasi directory senza però modificare la struttura delle cartelle al di sotto di FTDATA.

Ecco le azioni:

posizione originaria in G:\Program Files\Microsoft SQL Server\MSSQL$SQL2000SP4\FTDATA
La risorsa FullText all’interno del gruppo di SQL Server deve rimanere Online in questa fase (o semplicemente il servizio FullText in caso di installazione Standalone)
Sul nodo con in carico l’istanza occorre modificare tutte le ricorrenze del disco G: in Y: all’interno della chiave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Search\1.0. Come già anticipato si può modifare anche il percorso in qualsiasi modo, ma fino alla cartella FTDATA e non oltre.
Offline della risorsa Fulltext: in questa fase nei file CLUSTX.X che si trovano in FTDATA vengono salvate la chiavi di registry che abbiamo modificato al punto 3, evitando così di dovere caricare i vari file nel registry per fare le modifiche. i file CLUSTX.X sono specifici per SQL Server 2000 e contengono la configurazione del FullText quando è configurato su un Cluster, per cui non saranno mai presenti in un server Standalone, per il quale è sufficiente spegnere il servizio dopo il punto 3
spostare il contenuto della cartella FTDATA sull’altro disco (Y: ) e/o directory a patto che il cambio sia coerente con le modifiche fatte al punto 3.
Modificare ApplicationPath in HKEY_LOCAL_MACHINE\Cluster\Resources\xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx\Parameters, dove xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx coincide con il GUID delle risorsa FullText, per rispecchiare la nuova posizione di FTDATA per quell’istanza.
Modificare il valore FullTextDefaultPath nella chiave HKLM\Software\Microsoft\Microsoft SQL Server\<Istanza> per puntare alla nuova posizione (questo passo non è richiesto per un server standalone)
Offline e Online di SQL Server, Online del FullText. A questo punto nelle proprietà del FullText sotto “Support Services” (in Enterprise Manager) si dovrebbe vedere il puntamento al nuovo percorso.
Se i cataloghi non sono nella posizione predefinita occorre modificare il campo path della tabella sysfulltextcatalogs per ogni database
Da Query Analyzer
- sp_configure 'allow updates', 1
- go
- reconfigure with override
- go
- Update sysfultext catalogs set path =’nuova path’ where ftcatid=X, dove ‘nuova path’ è il nuovo percorso che si vuole impostare e X è l’id del catalogo che si vuole modificare. Questa operazione deve essere fatta per ognuno dei cataloghi in ogni database: se il campo ‘path’ contiene il valore NULL non c’è bisongo di apportare modifiche
Offline e Online di SQL Server
Offline e Online del FullText

NOTA: gli ultimi 3 passi sono necessari solo se i cataloghi non sono stati creati in origine nella posizione predefinita

Mauro Munzi
Senior Support Engineer
Microsoft Enterprise SQL Support

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 - Possibili cause del "General Network Error"

itentblg — Mon, 29 Jun 2009 02:00:00 GMT

In questo post vorrei parlare di alcuni scenari tipici in cui un’applicazione riceve l’errore “General Network Error”. Ciascuna delle cause rappresenta uno scenario piuttosto complesso, vorrei riassumere i punti chiave per ogni scenario:

Come?
Quando?
Come risolvere?

e fornirvi i link degli articoli dove potete trovare maggiori dettagli o spiegazioni.

Le cause descritte sotto sono solo una parte delle cause che potrebbero provocare "General Network Error", ho cercato di specificare le più comuni.

Sintomi

Consideriamo uno scenario come il seguente:

Un’applicazione si connette ad una database di SQL remota. L'applicazione potrebbe essere di diversi tipi: desktop, web.
Quando l'applicazione si connette a SQL Server, randomicamente si verifica uno dei seguenti messaggi d’errore:

System.Data.SqlClient.SqlException: A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
ERROR [08S01] [Microsoft][SQL Native Client]Communication link failure

[Microsoft][ODBC SQL Server Driver][DBNETLIB] General Network error. Check your network documentation

Primi controlli

Prima bisogna capire se l’errore è collegato all’applicazione, oppure è un problema generale di comunicazione tra i server. Per determinare questo si può provare ad aprire una connessione dal server dove gira l'applicazione allo stesso database di SQL Server nel momento in qui si verifica il problema usando un altro client, per esempio un file udl (http://support.microsoft.com/kb/244659). Per avere una buona prova bisogna fare un test della connessione immediatamente quando l'errore si presenta in applicazione. A volte è molte difficile prevedere quando succede l'errore, ma in alcuni casi potrebbe essere fattibile. Se, per esempio, tutte le connessioni dell'applicazione falliscono con "General Network Error" e allo stesso tempo tutti i test da un file udl si completano con successo bisogna cominciare le verifiche dalla review dell'applicazione.
Hardware di rete
- Se ci sono firewall, verificate se le impostazioni di timeout sono configurate correttamente. Il problema della connettività potrebbe succedere quando scatta un Timeout di firewall prima che il client e SQL hanno completato l’attività sulla connessione.
- Se usate teaming adapter fate una prova disattivandolo e verificate se il problema si presenta lo stesso. (Teaming significa che tutte le schede di rete sono tenute insieme e appaiono come un IP / indirizzo fisico)
- Sarebbe anche utile fare le seguente prove e verificare se il problema si presenta lo stesso o no:
  - Disattivare teaming adapters della rete.
  - Escludere routers o firewalls, se è possibile, semplificate il percorso tra il client e il server.
  - Spostare il server e il client sulla stessa subnet.
  - Verificare se i drivers della scheda di rete sono aggiornati.

Possibili cause

Scalable Networking Pack (SNP) è abilitato e incompatibile con l’hardware di rete

Scalable Networking Pack include il supporto per le seguente funzionalità:

TCP Chimney Offload,
Receive-Side Scaling
NetDMA

Scalable Networking Pack(SNP) è incluso nel Service Pack 2 di Windows Server 2003 e come un pacchetto stand-alone.

Come verificare il problema:
- SQL Server è installato sul Windows Server 2003 dove SNP è abilitato
- Applicazione si connette a questo SQL Server remoto tramite protocollo TCP/IP
- In modo randomico nell’applicazione si verifica un problema descritto nella sezione Sintomi sopra riportata
- Il problema si verifica solo quando la connessione è aperta tramite il protocollo TCP/IP
Come confermare il problema:
- Se l’applicazione esplicitamente si connette a SQL Server usando il protocollo Named Pipes il problema non si verifica. Per esempio, nella stringa della connessione il nome del server viene specificato come np:ServerName forzando il protocollo Named Pipes.
- Potete prendere le trace di rete simultanee dal server dell'applicazione e dal server di database. Dovete vedere un pacchetto con RESET nell'entrambe trace. Ma nella trace di database si vede che RESET è inviato dal client invece nel trace di client si vede che RESET è inviato dal server di database. Lo scenario è molto simile allo scenario descritto nel punto 2 “Firewall or router interrompe le connessioni”, dove potete vedere anche un esempio dei pacchetti
Come risolvere il problema:
- Disabilitate manualmente le funzionalità di SNP come è descritto nell’articolo http://support.microsoft.com/kb/948496 (Metodo 3). Se dopo la disattivazione delle funzionalità di SNP il problema si verifica ancora, la causa del problema è diverso; cancellate le modifiche, fatte per disabilitare SNP.

Firewall o Router interrompe le connessioni

Come verificare il problema:
- Intermittente
- Può essere causato da malfunzionamenti hardware o impostazioni che possono interrompere i pacchetti.
Come confermare il problema:
- Create una trace di rete simultanea sul computer client e sul server del database quando si verifica il problema ( si può utilizzare Microsoft Network Monitor 3.2 per catturare le trace) contrassegnando esattamente il momento in cui si verifica l’errore.
- Poi analizzate le conversazioni nelle trace del client e del server nel momento dell’errore. Le conversazioni dovrebbero essere simili alle seguenti (SQL Server ascolta sulla porta TCP 1433, l'applicazione – sulla porta 1556):
Come risolvere il problema:
- Procedete con la verifica dello stato di rete con la revisione delle impostazioni hardware di rete tra il client e il server di database.

Applicazione non usa connection pooling e apre le connessioni tramite protocollo TCP/IP

Le tre cause seguenti sono molto simili e per questo suggerisco di rivederle insieme.

1 - Le porte anonime si esauriscono sul client

Le porte anonime sono utilizzate dal lato client al livello di protocollo dell’applicazione. Queste porte sono assegnate dinamicamente. In Windows 2003 le porte sono assegnate nell’intervallo 1024 – 5000.

Come verificare il problema:
- L'applicazione apre la connessione al database di SQL Server utilizzando il provider che permette di disattivare il connection pooling, per esempio, SQL Server OLEDB provider or System.Data.SqlClient provider.
- Se l'applicazione si connette al database di SQL Server utilizzando il protocollo TCP / IP, connection pooling è disattivato e l'applicazione apre e chiude le connessioni molto spesso, lo stress sulla sottostante libreria di rete SQL Server può essere aumentato e come risultato la connessione potrebbe essere interrotta con l’errore "General Network Error".
- Ogni volta quando si apre e si chiude un socket tramite una libreria di rete di SQL sul lato client, il socket entra in stato TIME_WAIT per quattro minuti. Se si aprono e si chiudono rapidamente i 4000 sockets in meno di quattro minuti, si raggiunge la massima impostazione di default per le porte anonime, e i nuovi tentativi di aprire una nuova connessione falliranno fino a quando il set esistente delle socket in TIME_WAIT non va in timeout.

Come confermare il problema:

Appena si verifica l’errore “General network error” dovete aprire la riga del comando ed eseguire il commando sotto riportato.
netstat -ano

Analizzate il risultato. Dovete vedere circa 4000 connessioni nello stato TIME_WAIT verso l’indirizzo IP del computer, dove gira SQL Server.

Protocol	Local Address	Foreign Address	State	PID
TCP	web:3098	sql:ms-sql-s	TIME_WAIT	1520
TCP	web:3100	sql:ms-sql-s	TIME_WAIT	2256
TCP	web:3110	sql:ms-sql-s	TIME_WAIT	1140
TCP	web:3111	sql:ms-sql-s	TIME_WAIT	1096
TCP	web:3115	sql:ms-sql-s	TIME_WAIT	2292
TCP	web:3118	sql:ms-sql-s	TIME_WAIT	2456

Potete confrontare il risultato dello strumento TCPView (http://technet.microsoft.com/it-it/sysinternals/bb897437(en-us).aspx) al risultato ottenuto dalla query sulla tabella sysprocesses in SQL Server.
- Nel momento, in cui si presenta il problema, eseguite il comando in SQL Server.
  SELECT * FROM sysprocesses
- Lanciate lo strumento TCPView e confrontate il risultato con il risultato ottenuto nel passo precedente.
- Per esempio, se vedete che ci sono 1000 porte aperte per connettersi al SQL server, ma SQL Server dimostra solo 100 connessioni in sysprocesses, questo potrebbe indicare che molte porte TCP sono nello stato inattivo (per impostazione predefinita si aspetta 4 minuti prima di essere chiuso) e questo può impedire ai nuovi clienti di ottenere una porta dal sistema operativo.

Come risolvere il problema:
- Se pooling è abilitato, non dovete aggiustare l’impostazione dei parametri MaxUserPort and TcpTimedWaitDelay.
- Altrimenti regolate le impostazioni di MaxUserPort e TcpTimedWaitDelay sul computer client dove gira l'applicazione. Per esempio, su un Internet Information Services (IIS) in cui un server web si connette a un computer remoto di SQL Server database utilizzando il protocollo TCP / IP con pooling disabilitato.
  - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters:
    Value Name: MaxUserPort
    Data Type: REG_DWORD
    Valid Range: 5000 – 65534(decimal)
    Default: 0x1388 (5000 decimal)
  - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters:
    Value Name: TcpTimedWaitDelay
    Data Type: REG_DWORD
    Valid Range: 30 – 300(decimal)
    Default: 0xF0 (240 decimal)
Ulteriori informazioni e articoli:

2 – L’Applicazione apre connessioni multiple non in pool

Come verificare il problema:
- L’applicazione non usa pooling. Il problema è molto simile al problema descritto nel punto 4 “Esaurimento delle porte anonime sul client”.
- Potete determinare se questa è la causa del problema usando gli approcci descritti nel punto 4.
- La differenza è che il codice dell’applicazione è scritto in maniera tale che può produrre gli scenari quando si creano le connessioni aggiuntive.
Come risolvere il problema:
- Bisogna revisionare il codice dell’applicazione e risolvere il problema cambiando l’implementazione in modo tale che non si generano le connessioni aggiuntive non in pool
- Usate il pooling e ricuperate il risultato della query iniziale prima di eseguire una seconda query.
- Una connessione aggiuntiva verrà generata quando:
  - Viene utilizzata una connessione che è in attesa di un risultato da un cursore ‘firehose’
  - Viene utilizzata una connessione che ha una operazione asincrona in corso.
Ulteriori informazioni e articoli:

3 - Si supera l’impostazione predefinita di WINSOCKLISTENBACKLOG nel computer con SQL Server

Come verificare il problema:
- L’impostazione backlog è la massima lunghezza della coda di connessioni in attesa per listener. I sintomi sono molto simili allo scenario con le porte anonime e il codice dove si aprono multiple connessioni non in pool.
- Bisogna tener conto che solo in rarissimi casi, potrebbe essere necessario modificare questa impostazione, anche se pooling è attivato sul computer client. Per esempio, se molti computer client comunicano con un computer singolo dove gira SQL server, un gran numero di tentativi di connessioni simultanee in entrata possono verificarsi in qualsiasi momento anche se pooling è abilitato.
Come confermare il problema:
- Per determinare se si presenta questo problema potete catturare una trace di rete sul computer del client oppure sul computer dove gira SQL Server e verificare le richieste di connessione che sono immediatamente respinte con ACK+RESET
- Esaminando i pacchetti TCP/IP nella trace di rete è possibile vedere un pacchetto come il seguente quando il problema si è verificato.
- Nell’esempio sotto riportato SQL Server ascolta sulla porta 1433.
  - Frame:
    + Ethernet: Etype = Internet IP (IPv4)
    + Ipv4: Next Protocol = TCP, Packet ID = 17897, Total IP Length = 40
    + Tcp: Flags=....A..R., SrcPort=1433, DstPort=4046, Len=0, Seq=0-0, Ack=2305526653, Win=0
Come risolvere il problema:
- Revisionate il codice e usate il pool delle connessioni.
- Se questo non risolve il problema e avete verificato che le connessioni vanno in pool, in questo caso potete provare ad aumentare la dimensione della coda backlog. In questo caso sarà aumentato il numero delle richieste delle connessioni socket in attesa che il livello socket di TCP/IP mette in coda.
Ulteriori informazioni e articoli:
- Description of TCP/IP settings that you may have to adjust when SQL Server connection pooling is disabled

Uso improprio delle connessioni SqlConnection in codice gestito.

Come verificare il problema:
- Quando gli oggetti SqlConnection non sono gestiti correttamente nel codice dell’applicazione, questo potrebbe portare alla situazione in cui i 2 thread possono tentare di utilizzare contemporaneamente lo stesso oggetto SqlConnection, In questo caso l’invio dei TDS invalidi a SQL Server fa scattare l’errore 17805 provocando SQL Server di chiudere la connessione bruscamente.
Come risolvere il problema:

Bisogna assicurarsi che le connessioni SqlClient siano chiuse correttamente. Se ci sono i DataReaders restituiti, dovrebbe essere usata la modalità CommandBehavior.CloseConnection alla creazione di DataReader
Non bisogna mai chiamare Close() or Dispose() dell’oggetto di SqlClient nel metodo Finalize di una classe.
Non usate un oggetto SqlConnection statico e sempre utilizzate gli oggetti di SqlConnection con scopo locale al metodo dove vengono usati. In questo modo potete garantire che non ci sono i 2 thread che utilizzano una connessione di SqlConnetion allo stesso tempo.
"Invalid Buffer Received from Client” error message in SQL Server log when you use SQL Server .NET provider classes

Questo articolo parla di una specifica causa dell’errore 17805. In generale, l'errore può verificarsi in qualsiasi scenario che potrebbe consentire il simultaneo accesso multi - threaded ad un oggetto SqlConnection. In quasi tutti i casi in cui si verifica l’errore 17805 in modo casuale, si consiglia un cambiamento nel codice e l’utilizzo degli oggetti SqlConnection che sono locali a un metodo, in modo tale da garantire che gli oggetti SqlConnection non possono essere accessibile da più di un thread.

Ulteriori informazioni e articoli:

Applicazione client usa SqlClient con crittografia SSL (.NET Framework 1.0 / 1.1)

Descrizione dettagliata di questo problema, si può trovare nell’articolo sotto riportato:

KB 821289
FIX: "General Network Error" when you use SqlClient with SSL encryption
http://support.microsoft.com/kb/821289

Come verificare il problema:

Applicazione è basata su .Net Framework 1.0 o .Net Framework 1.1
Secure Socket Layer (SSL) si usa con Microsoft SQL Server 2000. Se SQL Server trova sul computer locale un certificato valido che è stato rilasciato sul FQDN ( Fully- Qualified-Domain-Name) e l’applicazione usa SqlClient, si può verificare l’errore “General Network Error”.
Quando il problema si verifica viene visualizzato il seguente call stack:

exception in TraceLogProcess:General network error. Check your network documentation.:
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, TdsParserState state) at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, TdsParserState state)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()
at System.Data.SqlClient.TdsParser.ReadNetlib(Int32 bytesExpected)
at System.Data.SqlClient.TdsParser.ReadBuffer()
at System.Data.SqlClient.TdsParser.ReadByteArray(Byte[] buff, Int32 offset, Int32 len)
at System.Data.SqlClient.TdsParser.ReadSqlValue(_SqlMetaData md, Int32 length)
at System.Data.SqlClient.TdsParser.ProcessRow(_SqlMetaData[] columns, Object[] buffer, Int32[] map, Boolean useSQLTypes)
at System.Data.SqlClient.SqlDataReader.PrepareSQLRecord(Int32 i)
at System.Data.SqlClient.SqlDataReader.GetSqlInt32(Int32 i)
at System.Data.SqlClient.SqlDataReader.GetInt32(Int32 i

Come risolvere il problema:

Applicare l’hotfix dall’articolo

SqlCommand.CommandTimeout è impostato a 0 (.NET Framework 1.0/ 1.1)

Come verificare il problema:

Se la proprietà di SqlCommand.CommandTimeout è impostata a 0 (cioè infinito) e una risposta da parte di SQL è divisa in più di un pacchetto di rete, la connessione può essere chiusa incorrettamente e come conseguenza si verifica l’errore “General Network Error”
Questo problema può apparire come un problema intermittente, a seconda di come spesso l’applicazione riceve le risposte che sono più grandi di un pacchetto.

Come confermare il problema:

Questo problema può essere individuato in una trace di rete. Se risulta presente una query, seguita da un completo pacchetto di dati trasmessi (per default la dimensione di un pacchetto SqlClient è di 8K, anche se nella trace di rete può apparire come pacchetti multipli con la dimensione totale di 8K ), quindi dopo il primo pacchetto, la connessione sembra essere chiusa correttamente con il pacchetto ACK+FIN. Dopodiché SQL Server continua l’invio dei dati che risultano in un reset TCP/IP con l’errore.
Comunque non dovrebbe essere necessario di catturare una trace di rete se avete già individuato che CommandTimeout è impostato a zero e potenzialmente potrebbe essere ricevuto più di un pacchetto di dati per volta.

Come risolvere il problema:

Potete evitare questo problema impostando un valore alto per CommandTimeout, per esempio, 7200 oppure installando una hotfix dall’articolo sotto riportato.

KB 823679
Fix: Multiple Fixes for SQL Server .NET Data Provider
http://support.microsoft.com/kb/823679

Olga Guzheva
Senior Support Engineer
Microsoft Enterprise SQL Support

Supporto Tecnico agli Sviluppatori

itentblg — Mon, 22 Jun 2009 02:00:00 GMT

Incident di Supporto Tecnico

Sviluppatori italiani, unitevi! Avete un problema o una domanda su come usare i prodotti di sviluppo Microsoft e i newsgroup o i forum non sono stati d'aiuto? Allora, non perdete altro tempo lasciando che il problema diventi troppo urgente, ed aprite una richiesta di supporto! Parlerete con lo specialista della tecnologia di vostro interesse e potrete constatare se davvero il Supporto Tecnico Microsoft sia in grado di fornire quel valore aggiunto che vi serve. Tra l'altro, particolare non trascurabile... ne avete probabilmente già diritto gratuitamente! Forse non tutti sanno che acquistando Visual Studio insieme alla sottoscrizione MSDN, avete già acquistato il diritto di aprire un certo numero di "incident" senza costi aggiuntivi:

MSDN Subscription Level	Visual Studio 2008 Professional with MSDN Professional	Visual Studio 2008 Professional with MSDN Premium	Visual Studio Team System 2008 Edition with MSDN Premium	Visual Studio Team System 2008 Team Suite with MSDN Premium
Incident	2	4	4	4

Come aprire una richiesta

Se avete acquistato il singolo prodotto, è possibile aprire la richiesta:

telefonicamente, allo 02/70.398.398 (la prima volta sarà necessario attivare il prodotto chiamando il numero verde 800 531042)
1. opzione 1 "Privato"
2. sotto-opzione 2 "Supporto Tecnico": qui parlerete con un tecnico di primo livello che raccoglierà alcune informazioni, dopo aver verificato la possibilità di supporto gratuito
3. a questo punto la richiesta sarà aperta e a seconda dell'urgenza l'ingegnere di Supporto Tecnico vi contatterà al telefono o via mail
via web, come indicato di seguito (la prima volta sarà necessario attivare il prodotto):
1. Dalla Home page del Supporto Tecnico in italiano, nella categoria "Supporto Assistito" cliccate su "Seleziona il tuo prodotto Microsoft per ricevere assistenza tecnica via web o telefono"
2. Selezionate il tuo prodotto nella categoria "Strumenti per sviluppatori", eventualmente dopo averli visualizzati tutti
3. Selezionate l'edizione del prodotto che avete acquistato. Ad esempio, per Visual Studio 2008 Professional Italiano, arriverete a questa pagina: cliccate sul pulsante "Invia Richiesta Online"
4. Leggete attentamente e accettate le condizioni
5. A questo punto la procedura chiede se il problema si presenta sul PC che si sta utilizzando, poichè in questo modo vengono raccolte informazioni sull'attuale stato del computer attraverso il controllo ActiveX 'Microsoft Support Diagnostics Platform'
6. Poi, per determinare se è disponibile il servizio di supporto GRATUITO, digitate il numero di serie del prodotto: in questo modo sfrutterete i cosiddetti "incident inclusi"
7. infine, descrivete il problema e specificatene l'urgenza: la richiesta sarà aperta e a seconda dell'urgenza l'ingegnere di Supporto Tecnico vi contatterà al telefono o via mail

N.B. E' possibile attivare il prodotto anche dal menu Help\About - "Register Product" di Visual Studio: è necessario avere un account Windows Live ID (che corrisponde ad un indirizzo MSN Hotmail, oppure MSN Messenger, o Passport account).

Per chi abbia sottoscritto un abbonamento MSDN, le modalità sono analoghe, dopo aver eseguito la registrazione del proprio account: come indicato qui, è necessario effettuare l'accesso e fare clic sul collegamento Interventi di supporto per ulteriori informazioni.

Cosa aspettarsi

Bene, ed una volta aperta la chiamata cosa succede? Nel giro di un paio ore un tecnico esperto della tecnologia in questione prenderà in carico la richiesta di supporto e vi contatterà per parlarne più approfonditamente; questa fase è importante per farsi un’idea del problema vero e proprio, di quali componenti coinvolge, dell’ambiente nel quale si verifica (macchine coinvolte, tipo di rete ecc…) ed indirizzare i passi successivi. Potrebbe essere necessario raccogliere log del sistema operativo, o trace applicative, magari dump di memoria da analizzare, o altre volte potrebbe essere necessario creare una piccola applicazione di test per riprodurre il problema nel nostro laboratorio dove lo possiamo analizzare al meglio… il tutto ovviamente con l’obiettivo di trovare la soluzione migliore per le vostre esigenze, possibilmente condita con informazioni tecniche che vi potranno essere utili anche in futuro.

Insomma, cosa aspettate?

Il Team di Supporto Tecnico agli Sviluppatori

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

Emergenza Abruzzo – la risposta di Microsoft

itentblg — Thu, 09 Apr 2009 14:00:00 GMT

Le notizie che si susseguono sulla tragedia che ha colpito l’Abruzzo lunedì scorso sono veramente sconvolgenti. Tutti i dipendenti ed i partner della nostra azienda sono vicini alle persone coinvolte. Microsoft Italia si è attivata in questi giorni con una serie di azioni di supporto materiale e tecnico che speriamo possano alleviare per quanto possibile i disagi e le difficoltà in cui versano le popolazioni toccate da questo drammatico evento.
Molte di queste iniziative sono e saranno oggetto di comunicazione direttamente alle Istituzioni coinvolte o destinatarie di questi contributi. Tra le azioni intraprese, segnaliamo a tutte le scuole, enti pubblici, piccole aziende e organizzazioni non profit del territorio che avessero necessità di supporto tecnico informatico sui nostri prodotti a più ampia diffusione, di rivolgersi al numero 02 70398398 e, indicando la provenienza dalle province colpite, le chiamate saranno dirottate ad un servizio gratuito appositamente attivato per loro.

Se vuoi partecipare attivamente per aiutare le popolazioni terremotate dell'Abruzzo, fai clic qui.

Grazie a tutti per il vostro aiuto.

Supporto Tecnico Enterprise

SQL Server - Facciamo quattro conti con i dischi

itentblg — Mon, 09 Feb 2009 03:00:00 GMT

Mi capita spesso di incontrare evidenti problemi di performance sui vari volumi utilizzati da SQL Server, sia per un’errata scelta del livello di RAID sia per un errato dimensionamento del numero di dischi necessari a soddisfare la quantità di operazioni al secondo richieste dai vari database.

Le moderne Storage Area Network dispongono di sistemi di gestione dei volumi che praticamente in tempo reale possono riallocare su meccaniche completamente differenti,anche come numero, quello che dal sistema operativo viene visto come disco (la lettera dell’unità): inoltre la grande quantità di memoria cache installata garantisce prestazioni teoriche tali da non far sorgere preoccupazioni, tant’è che per volumi dedicati alla “semplice” di repository normalmente si può risparmiare su qualche disco.

La tendenza attuale inoltre è quella che porta a vedere la SAN più come una riserva di GigaByte e TeraByte di spazio, piuttosto che come un sistema dal quale si possono estrarre notevoli performance, perché normalmente si chiede “Ho bisogno di XXX Gb di spazio” e non “Ho bisogno di XXX Gb di spazio che sia in grado di garantirmi YYY operazioni di I/O al secondo”.

E qui si inserisce un aspetto molto importante da considerare: SQL Server ( e anche Exchange ) all’avvio richiede l’apertura dei suoi file di database in modalità WriteThrouh, tramite il flag FILE_FLAG_WRITE_THROUGH e FILE_FLAG_NO_BUFFER della funzione Windows CreateFile, ignorando quindi qualsiasi tipo di cache, da quella del sistema operativo a quella che può essere presente sul disco. Solo alcuni sistemi molto avanzati possono essere configurati per ignorare questi due flag e fare in modo che SQL Server “veda” la cache come “stable media” (praticamente un disco) garantendo così elevate performance, ma la maggior parte delle installazioni oggi presenti non è in grado: e qui iniziano i problemi perché dobbiamo fare i conti, nel vero senso del termine, con le pure caratteristiche fisiche dei dischi che compongono gli array (spesso uno solo) dove risiedono i file di dati di SQL Server.

Vediamo quindi un generico disco SCSI di ultima generazione cosa può garantirci come numero di operazioni di I/O prima di iniziare ad accodare le richieste e allungare i tempi di risposta: il riferimento dei nostri calcoli è un Seagate Cheetah 15.5K, disponibile nei tagli 74Gb, 146Gb e 300Gb, i più comuni (purtroppo … come dimensione del singolo) usati oggi all’interno delle SAN.

Il disco in questione presenta per i tre formati le seguenti caratteristiche:

latenza media di 2ms (considerata come la metà del tempo necessario per compiere un intera rotazione dei piatti)
Scrittura Random 4.0ms
Lettura Random 3.5ms
Scrittura Sequenziale 0.4ms
Lettura Sequenziale 0.2ms

Tenendo presente che un disco inizia a dare evidenti segni di accodamento quando viene usato in modo continuativo oltre l’ 85% delle sue capacità (Cap. 8 di “Microsoft SQL Server 2000 Performance Tuning Technical Reference”), possiamo passare a valutare quanto rende il nostro Cheetah in termini di operazioni al secondo.

Relazione tra tempi di risposta e percentuale di utilizzo del disco

Abbiamo che in modalità sequenziale una lettura richiede una latenza totale di 2.2ms mentre per una scrittura servono 2.4ms, per un totale rispettivamente di 455 e 417 operazioni/sec (= 1000m / latenza ). In modalità random i valori salgono 5.5ms e 6.0ms ottenendo così 182 e 167 operazioni/sec.

A questi risultati dobbiamo sottrarre l’overhead della catena driver+controller+logica di gestione del disco, in sostanza tutto quello che si trova tra la richiesta di scrittura da parte del sistema operativo e la testina del disco, valutato intorno al 20% per le operazioni random e 10% per quelle sequenziali. I valori calcolati prima diventano così 364 e 333 per l’accesso sequenziale mentre per l’accesso random si scende a 164 e 150: abbiamo così il massimo ammissibile per ogni disco nel caso di uso non continuativo. I valori medi diventano quindi 348 nel caso di accesso sequenziale e 157 per l’accesso random.

Prendendo ora come riferimento l’85% dell’utilizzo onde evitare evidenti accodamenti, i nostri valori diventano 309 e 283 nel primo caso e 139 e 128 nel secondo, con una media rispettivamente di 296 per l’accesso sequenziale e 133 per l’accesso random.

Di seguito la tabella riassuntiva dei dati appena trovati:

Latenza di rotazione (1/2 giro) = 2ms		Latenza totale	Operazioni/Sec	Overhead:20% random, 10% sequenziale	Media per uso non continuativo	85% per evitare code	Media
Lettura Sequenziale	0.2ms	2.2ms	455	364	348	309	296
Scrittura Sequenziale	0.4ms	2.4ms	417	333		283
Lettura Random	3.5ms	5.5ms	182	164	157	139	133
Scrittura Random	4.0ms	6.0ms	167	150		128

Vediamo ora i vari livelli di RAID come si comportano dal punto di vista delle operazioni di I/O richieste ad ogni disco che compone un Array.

RAID0

Alla base di tutti i livelli abbiamo il RAID0, un semplice striping che non offre caratteristiche di fault tolerance e naturalmente non è raccomandato per fornire storage a SQL Server, anche se rappresenta il massimo livello di performance. Il numero di operazioni gestite da ogni disco componente l’array è dato da:

I/O per Disco = (Letture + Scritture) / Numero di dischi

RAID1

Rappresenta il “classico” mirroring in cui i il meccanismo di “fault tolerance” viene implementato replicando i dati un secondo disco. dal punto di vista del calcolo abbiamo:

I/O per Disco = [Letture + (2 * Scritture)] / 2

Si nota quindi come in questo caso le operazioni di scrittura siano più onerose, mentre nel caso delle letture grazie al supporto “Split seeks”, che permette di distribuire equamente il carico sui due dischi, si comporta come un RAID0

RAID5

E’ probabilmente il livello più utilizzato perché fornisce un buon livello “fault tolerance” unitamente ad un elevato rapporto numero di dischi/spazio disponibile, e in determinate condizione anche buone performance. Il RAID5 introduce il concetto di “parità” per potere ricostruire il dato nel caso in cui uno dei dischi componenti un array dovesse rompersi: il calcolo della parità risulta essere anche il “tallone d’Achille” per le performance di questa implementazione. Al momento della creazione di un volume di questo tipo la parte riservata ai dati viene inizializzata a 0 ed il bit di parità resettato: per questo motivo sono necessarie quattro operazioni, la prima per leggere il dato esistente, la seconda lo stato della parità, la terza per riscrivere il nuovo dato e la quarta per la nuova parità dopo che il processore del controller ne ha calcolato il valore. Abbiamo quindi:

I/O per Disco = [Letture + (4 * Scritture)] / Numero di dischi

dal momento che come abbiamo visto sopra per ogni operazione di scrittura ne occorrono 4

RAID10

E' l'unica vera alternativa al RAID5 nel momento in cui si vuole il massimo delle performance unitamente al migliore livello di “fault tolerance” ed è in sostanza un mirroring al quale viene aggiunta la funzionalità di stripe.

Il calcolo presenta la stessa formula del RAID0 ma con il denominatore che diventa uguale al numero di dischi (sempre multiplo di 2)

I/O per Disco = [Letture + (2 * Scritture)] / Numero di dischi

Sono previsti anche altri livelli di RAID: 3,4, 6 (un 5 con doppia parità) e 7 ( 3 o 4 con caching), ma il loro impiego è limitato a casi sporadici.

LA DOMANDA FATIDICA: RAID5 o RAID10?

Purtroppo molto spesso le esigenze di spazio dominano nei confronti delle performance ed il RAID5, a parità di dischi fornisce sempre una capacità di memorizzazione superiore, ma una volta che questo problema passa in secondo piano sarebbe opportuno scegliere praticamente sempre il RAID10 dal punto di vista delle performance. Il RAID5 nel momento in cui la percentuale delle scritture supera il 10% del totale inizia a imporre un maggior carico ai singoli dischi dell’array.

Prendiamo ad esempio il nostro disco visto sopra, da 188 operazioni random al secondo prima di iniziare ad accodare, e vediamo cosa succede una volta inserito in un array composto da 6 unità (configurazione molto diffusa), che si trova a gestire 500 operazioni al secondo.

Confronto sul carico dei dischi

Rapporto Lettura/Scrittura	RAID 5 I/Os ^[a]	RAID 10 I/Os ^[b]
100% letture; 0% scritture	(500 + 0) / 6 83 I/Os per disco	(500 + 0) / 6 83 I/Os per disco
90% letture; 10% scritture	(450 + 200) / 6 108 I/Os per disco	(450 + 100) / 6 91 I/Os per disco
75% letture; 25% scritture	(375 + 500) / 6 145 I/Os per disco	(375 + 250) / 6 104 I/Os per disco
50% letture; 50% scritture	(250 + 1000) / 10 208 I/Os per disco	(250 + 500) / 6 125 I/Os per disco
0% letture; 100% scritture	(0 + 2000) / 6 333 I/Os per disco	(0 + 1000) / 6 166 I/Os per disco
^[^a^] [Letture+ (4 * Scritture)] / N°Dischi ^[^b^] [Letture+ (2 * Scritture)] /N°Dischi

Come si vede già con il 10% di scritture il RAID5 impone più del 15% in più di carico su ogni disco, al 25% il confronto inizia a diventare molto sconveniente, e già prima del 50% supera il limite oltre il quale inizia l’accodamento. infine al 100% di scritture il RAID5 risulta evidentemente in difficoltà mentre il RAID10 si mantiene ancora entro le capacità del singolo disco.

Mauro Munzi
Senior Support 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

SQL Server 2005 Service Pack 3 + Cumulative Update 1 SP3

itentblg — Wed, 24 Dec 2008 16:41:00 GMT

A metà dicembre sono stati rilasciati la tanto attesa SQL Server 2005 Service Pack 3 ed anche la Cumulative Update 1 Post-SP3.

Questo rilascio merita un breve commento per evitare possibili fraintendimenti.

La SP3 contiene solo HOTFIX e nessun miglioramento.

Le HOTFIX sono tutte quelle rilasciate nel periodo tra la SP2 e la Cumulative Update 9.

Quindi si consiglia l’installazione della SP3 a tutti i clienti che hanno installato la SP2 ed una post-CU fino alla 9.

Invece per i clienti che hanno già installato la CU10 o CU11 si consiglia di installare la SP3 ed anche il nuovo Cumulative Update 1 che è stato rilasciato qualche giorno dopo la SP3.

Questo Cumulative Update 1 contiene tutte le hotfix incluse nella CU10 e nella CU11.

Quindi l’ultima build di sql che contiene tutti gli ultimi aggiornamento è la 9.00.4207.

Altro gradito rilascio è il Feature Pack SQL Server 2005 Service Pack 3 che contiene tutti i componenti distribuibili di SQL Server 2005. Si consiglia di aggiornare tutti i client che devono dialogare con i componenti SP3 con questi nuovi Feature Pack.

Ultimo ma non meno importante: BUONE FESTE!

Andrea Uggetti
Senior Support Escalation Engineer
Microsoft Enterprise SQL Support

Rilasciata la Cumulative Update 10 di SQL Server 2005

itentblg — Tue, 21 Oct 2008 13:37:08 GMT

Fresca di “stampa” vi segnalo il rilascio dall’ultimo aggiornamento di SQL Server 2005 che è la Cumulative Update 10.

Potete trovare tutte le informazioni in questo articolo:

956854 Cumulative update package 10 for SQL Server 2005 Service Pack 2
http://support.microsoft.com/default.aspx?scid=kb;EN-US;956854

Questa CU contiene 31 hotfix di cui ben 7 relative ad Analysis Service 2005. Per quanto riguarda AS ci sono almeno un paio di scenari interessanti in cui questo aggiornamento può dare dei benefici e sono quelli di un uso estremo di Cell Security oppure di query MDX che usano la funzione EXCEPT() nella clausula di Where.

Vi ricordo che come ogni update è sempre consigliato testare l’aggiornamento in ambiente di test prima di “passarlo in produzione”. E’ possibile rimuovere la CU tramite “Add/Remove Program” presente nel Control Panel.

Buona patch a tutti

Andrea Uggetti
Support Escalation Engineer
Microsoft Enterprise SQL Support

Blog dedicati agli Sviluppatori

itentblg — Thu, 02 Oct 2008 12:19:00 GMT

Ciao,
Come avete modo di leggere dalla mia introduzione sono responsabile del team di supporto a SQL Server ma mi occupo anche del team di supporto agli Sviluppatori. Essendo questo blog orientato al mondo Enterprise speriamo che venga letto dagli amministratori di sistema e da quelli di database. Abbiamo quindi deciso di lasciare fuori da questa avventura temi relativi allo sviluppo software, ai compilatori ed al debug di codice. Lo sviluppo è però parte integrante della mia anima e quindi mi permetto di segnalare a tutti gli sviluppatori le altre persone del team:

Carlo Cardella - Sviluppo Asp.Net e IIS

Raffaele Limosani - Sviluppo Mobile

Andrea Liberatore - Sviluppo WCF, WSE e .NET Remoting

Dategli un’occhiata... magari avete qualche collega a cui i temi in oggetto possono interessare. I post sono in inglese per una ragione di diffusione!

Alla prossima!

Marco Crippa
Escalation Manager
Microsoft Developer Support

Benvenuti nel mondo dei Cubi

itentblg — Wed, 24 Sep 2008 17:29:00 GMT

Quando mio figlio di 7 anni mi ha chiesto di spiegargli in poche parole che lavoro faccio gli ho risposto: “gioco con i cubi”, e lui tranquillo e serafico “mi raccomando stai attento agli spigoli”.

Infatti è ormai da più di 4 anni che mi preoccupo di “smussare” gli “spigoli” dei cubi di Microsoft Analysis Services e da oggi tenterò di spiegarvi come smussarli e/o evitare di prendere troppi spigoli in faccia.

Prima di addentrarci in qualcosa di tecnico vorrei darvi una serie di links e libri fondamentali per utilizzare Analysis Services (purtroppo sono tutti in inglese):

Il primo link è quello di uno dei papà di Analysis Services Microsoft OLAP by Mosha Pasumansky

Il blog di Mosha è fondamentale per capire in dettaglio il linguaggio MDX che è alla base dell’interrogazione dei database multidimensionali. Inoltre sta scrivendo un tool MDXStudio che è fondamentale per ottimizzare le query ed evitare errori ingenui. Tornerò più avanti con una serie di esempi sull’uso di questo tool.

Ci sono poi un paio di “ragazzi italiani” (spero che non si offendano) che stanno scrivendo una serie di blog sulla Metodologia alla base dell’architettura ed implementazioni di soluzioni BI che vi può essere utile per capire le basi della BI. Vi consiglio anche i loro blogs SQLBI – Marco Russo e Alberto Ferrari.

Un altro sito fondamentale per trovare documentazione e whitepaper autorevoli di Analysis Service è SQLCat. Il Customer Advisor Team è fatto da persone Microsoft con un passato di Program Manager del prodotto oppure con una vasta esperienza nell’uso dei medesimi. Il loro scopo è quello di portare al successo i progetti più arditi in ambito di BI (ma non solo) e dall’esperienza maturata pubblicano una serie di post di blog e di whitepaper.

Alla fine vi consiglio i due libri fondamentali a riguardo di Analysis Service 2005 ed il linguaggio MDX.

Microsoft SQL Server 2005 Analysis Services

Authors: Edward Melomed, Irina Gorbach, Alexander Berger, Py Bateman
Paperback: 864 pages
Publisher: Sams; 1 edition (December 25, 2006)
Language: English
ISBN-10: 0672327821
ISBN-13: 978-0672327827

MDX Solutions: With Microsoft SQL Server Analysis Services 2005 and Hyperion Essbase

Authors: George Spofford, Sivakumar Harinath, Christopher Webb, Dylan Hai Huang, Francesco Civardi
Paperback: 744 pages
Publisher: Wiley; 2 edition (March 6, 2006)
Language: English
ISBN-10: 0471748080
ISBN-13: 978-0471748083

Andrea Uggetti
Support Escalation Engineer
Microsoft Enterprise SQL Support

Supporto Tecnico Enterprise : SQL Team

SQL 2005 – Utilizzo del setup da riga di comando per upgrade/downgrade di versione

SQL 2000 - Spostamento della directory FTDATA su un altro disco per un istanza Cluster

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

Algoritmo di Proportional fill

Autogrow

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

Soluzione

SQL Server - Errore 701 e Memory Clerk Userstore_sxc

Problema

Dati raccolti

Analisi dei Dati

Soluzione

SQL Server - Possibili cause del "General Network Error"

Sintomi

Primi controlli

Possibili cause

Scalable Networking Pack (SNP) è abilitato e incompatibile con l’hardware di rete

Firewall o Router interrompe le connessioni

Applicazione non usa connection pooling e apre le connessioni tramite protocollo TCP/IP

1 - Le porte anonime si esauriscono sul client

2 – L’Applicazione apre connessioni multiple non in pool

3 - Si supera l’impostazione predefinita di WINSOCKLISTENBACKLOG nel computer con SQL Server

Uso improprio delle connessioni SqlConnection in codice gestito.

Applicazione client usa SqlClient con crittografia SSL (.NET Framework 1.0 / 1.1)

SqlCommand.CommandTimeout è impostato a 0 (.NET Framework 1.0/ 1.1)

Supporto Tecnico agli Sviluppatori

Incident di Supporto Tecnico

Come aprire una richiesta

Cosa aspettarsi

SQL Server - Query distribuite in esecuzione senza mai terminare

Problema

Dati da raccogliere

Analisi dei dati e Soluzione

Emergenza Abruzzo – la risposta di Microsoft

SQL Server - Facciamo quattro conti con i dischi

Latenza di rotazione (1/2 giro) = 2ms

Latenza totale

Lettura Sequenziale

0.2ms

2.2ms

Scrittura Sequenziale

0.4ms

2.4ms

Lettura Random

3.5ms

5.5ms

Scrittura Random

4.0ms

6.0ms

RAID0

RAID1

RAID5

RAID10

LA DOMANDA FATIDICA: RAID5 o RAID10?

100% letture; 0% scritture

90% letture; 10% scritture

75% letture; 25% scritture

50% letture; 50% scritture

0% letture; 100% scritture

[a] [Letture+ (4 * Scritture)] / N°Dischi

[b] [Letture+ (2 * Scritture)] /N°Dischi

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

Problema

Dati da raccogliere

Analisi dei dati

Verificare il summary.txt

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

SQL Server - Analizzare un problema di timeout utilizzando Sqlnexus

Problema

Dati da raccogliere

Analisi dei dati

Installazione di Sqlnexus

Caricamento dati in Sqlnexus

Visualizzazione dei dati di performance

Individuazione dei timeout

SQL Server 2005 Service Pack 3 + Cumulative Update 1 SP3

Rilasciata la Cumulative Update 10 di SQL Server 2005

Blog dedicati agli Sviluppatori

Benvenuti nel mondo dei Cubi

Latenza di rotazione
(1/2 giro) = 2ms

^[^a^] [Letture+ (4 * Scritture)] / N°Dischi

^[^b^] [Letture+ (2 * Scritture)] /N°Dischi