Supporto Tecnico Enterprise : Mauro Munzi

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 - 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

Supporto Tecnico Enterprise : Mauro Munzi

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 - 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

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

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

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