Partitionnement de tables SQL2005 Perf!!!

On 7 juin, 08:55, hch <h...@discussions.microsoft.com> wrote:

Je vous soumet un probleme etrange que j'ai eu chez mon client

nous avons fait une migration de SQL2000 vers 2005 Entreprise , et nous
avons profité pour mettre en place le partitionnement des tables volumin euses
sur 6 GROUPES DE Fichiers
Lorsque nous avons testé les performances sur un serveur de TEST avec un
disque data Local , nous avons été agreablement surpris par l'ameliora tion
des temps de reponse. (presque divisés par 6 !!)

Par contre lorsque nous avons decidé de mettre la solution en pre prod e t
nous avons refait la meme chose sur le serveur de pre prod nous avons etes
decus car les temps de reponses se sont rallongés ....

La seule difference entre le test et la pre prod c'est que la pred prod es t
en Cluster SQL Server Entreprise

et les datas sont sur un NAS , alors que le serveur de test n'etait pas en
cluster et avait un seul disque local.

Avez vous des idées? est ce que le fait d'avoir partitionné sur un NA S peut
avoir un effet negatif?
est ce que l'ecriture sur NAS est differente de l'ecriture sur disque loca l
bref avez vous une explication au probleme

Merci pour toute aide

HCH

Bonjour,
je dirais pour ma part que si les tables sont répartis en 6 groupe de
fichiers, ces groupes de fichiers doivent être distribués sur 6 unités
physiques différentes, chacune en raid 1 5 ou 10 suivant les moyens
déployés.
Stocker les données sur une unité de stockage en réseau (nas) n'est
pas du tout recommandé car dégradation des performances. En revanche
stocker sur un san (vu comme disque local pour le serveur) avec le
partitionnement en raid adéquat pour chaque lun permet d'optimiser au
mieux les performances.
Phil

Si votre NAS n'a pas 6 agrégat physiques différents les performances
seront les mêmes qu'avec un seul fichier.
Pire, si les unités logique (LUN) ne correspondant pas à des unité
physique (ZONING) alors vous choperez des temps encore plus long dû au
fait des opérations concurrentes d'autres services.

En tout état de cause avec SQL Server il vaut mieux un NAS dédié, et si
vous avez un NAS il est essentiel de définir autant d'unité logique
calqué sur des unités pgysiques que nécessaire.

De plus il vous faut impérativement tailler vos fichiers à des dimension
importantes correspondant par exemple au volume à terme de la abse de
données pour une exploitation de 3 à 5 ans

Autrement ditn il faut un NAS dédié hautement administrable. Sachez que
les grands constructeurs proposent du hardware spécifique pour les SGBDR
comme SQL Server ou Oracle (IBM, HP...).


hch a écrit :

Je vous soumet un probleme etrange que j'ai eu chez mon client

nous avons fait une migration de SQL2000 vers 2005 Entreprise , et nous
avons profité pour mettre en place le partitionnement des tables volumineuses
sur 6 GROUPES DE Fichiers
Lorsque nous avons testé les performances sur un serveur de TEST avec un
disque data Local , nous avons été agreablement surpris par l'amelioration
des temps de reponse. (presque divisés par 6 !!)

Par contre lorsque nous avons decidé de mettre la solution en pre prod et
nous avons refait la meme chose sur le serveur de pre prod nous avons etes
decus car les temps de reponses se sont rallongés ....

La seule difference entre le test et la pre prod c'est que la pred prod est
en Cluster SQL Server Entreprise

et les datas sont sur un NAS , alors que le serveur de test n'etait pas en
cluster et avait un seul disque local.

Avez vous des idées? est ce que le fait d'avoir partitionné sur un NAS peut
avoir un effet negatif?

Oh que OUI !!!

est ce que l'ecriture sur NAS est differente de l'ecriture sur disque local
bref avez vous une explication au probleme

Oui, voir ci dessus !

Merci pour toute aide

HCH

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************

Merci pour toutes ces precisions,

Y a t'il une doc qui explique comment configurer de pacon optimale un NAS
(agregats , LUN ZOONINGS etc....)

Merci encore

hch

"Fred BROUARD" wrote:

Si votre NAS n'a pas 6 agrégat physiques différents les performances
seront les mêmes qu'avec un seul fichier.
Pire, si les unités logique (LUN) ne correspondant pas à des unité
physique (ZONING) alors vous choperez des temps encore plus long dû au
fait des opérations concurrentes d'autres services.

En tout état de cause avec SQL Server il vaut mieux un NAS dédié, et si
vous avez un NAS il est essentiel de définir autant d'unité logique
calqué sur des unités pgysiques que nécessaire.

De plus il vous faut impérativement tailler vos fichiers à des dimension
importantes correspondant par exemple au volume à terme de la abse de
données pour une exploitation de 3 à 5 ans

Autrement ditn il faut un NAS dédié hautement administrable. Sachez que
les grands constructeurs proposent du hardware spécifique pour les SGBDR
comme SQL Server ou Oracle (IBM, HP...).


hch a écrit :
> Je vous soumet un probleme etrange que j'ai eu chez mon client
>
> nous avons fait une migration de SQL2000 vers 2005 Entreprise , et nous
> avons profité pour mettre en place le partitionnement des tables volumineuses
> sur 6 GROUPES DE Fichiers
> Lorsque nous avons testé les performances sur un serveur de TEST avec un
> disque data Local , nous avons été agreablement surpris par l'amelioration
> des temps de reponse. (presque divisés par 6 !!)
>
> Par contre lorsque nous avons decidé de mettre la solution en pre prod et
> nous avons refait la meme chose sur le serveur de pre prod nous avons etes
> decus car les temps de reponses se sont rallongés ....
>
> La seule difference entre le test et la pre prod c'est que la pred prod est
> en Cluster SQL Server Entreprise
>
> et les datas sont sur un NAS , alors que le serveur de test n'etait pas en
> cluster et avait un seul disque local.
>
> Avez vous des idées? est ce que le fait d'avoir partitionné sur un NAS peut
> avoir un effet negatif?

Oh que OUI !!!

> est ce que l'ecriture sur NAS est differente de l'ecriture sur disque local
> bref avez vous une explication au probleme

Oui, voir ci dessus !

>
> Merci pour toute aide
>
> HCH

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************

On 9 juin, 15:16, hch <h...@discussions.microsoft.com> wrote:

Merci pour toutes ces precisions,

Y a t'il une doc qui explique comment configurer de pacon optimale un NAS
(agregats , LUN ZOONINGS etc....)  

Merci encore

Voici 10 bonnes pratiques de l'éditeur pour le stockage avec sql
server, ce n'est qu'un bon début de documentation.
http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/storage-top-10 .mspx
Phil

Bonjour,

voilà mon avis sur le problème, l'équipement NAS étant un équipement réseau
les performances dépendront du trafic réseau et de l'accès à cet équipement.
Si vous en avez la possibilité vous pouvez vérifier cette hypothèse en
plaçant sur le serveur de pré-prod les fichiers en local.
Pour ce genre d'architecture, le SAN serait une solution plus adapté à ce
genre de besoin, reconnu pour le débit (selon protocole choisi) et
performance pour le mode transactionnel (NB : infrastructure plus onéreuse).

Cyril

"hch" <hch@discussions.microsoft.com> a écrit dans le message de groupe de
discussion : A4F83088-51C7-4A60-B332-9D65447B3042@microsoft.com...

Je vous soumet un probleme etrange que j'ai eu chez mon client

nous avons fait une migration de SQL2000 vers 2005 Entreprise , et nous
avons profité pour mettre en place le partitionnement des tables
volumineuses
sur 6 GROUPES DE Fichiers
Lorsque nous avons testé les performances sur un serveur de TEST avec un
disque data Local , nous avons été agreablement surpris par l'amelioration
des temps de reponse. (presque divisés par 6 !!)

Par contre lorsque nous avons decidé de mettre la solution en pre prod et
nous avons refait la meme chose sur le serveur de pre prod nous avons etes
decus car les temps de reponses se sont rallongés ....

La seule difference entre le test et la pre prod c'est que la pred prod
est
en Cluster SQL Server Entreprise

et les datas sont sur un NAS , alors que le serveur de test n'etait pas en
cluster et avait un seul disque local.

Avez vous des idées? est ce que le fait d'avoir partitionné sur un NAS
peut
avoir un effet negatif?
est ce que l'ecriture sur NAS est differente de l'ecriture sur disque
local
bref avez vous une explication au probleme

Merci pour toute aide

HCH

MERCI pour toutes ces infos

hch

"Cyril Blanloeil - LANDPARK" wrote:

Bonjour,

voilà mon avis sur le problème, l'équipement NAS étant un équipement réseau
les performances dépendront du trafic réseau et de l'accès à cet équipement.
Si vous en avez la possibilité vous pouvez vérifier cette hypothèse en
plaçant sur le serveur de pré-prod les fichiers en local.
Pour ce genre d'architecture, le SAN serait une solution plus adapté à ce
genre de besoin, reconnu pour le débit (selon protocole choisi) et
performance pour le mode transactionnel (NB : infrastructure plus onéreuse).

Cyril

"hch" <hch@discussions.microsoft.com> a écrit dans le message de groupe de
discussion : A4F83088-51C7-4A60-B332-9D65447B3042@microsoft.com...
> Je vous soumet un probleme etrange que j'ai eu chez mon client
>
> nous avons fait une migration de SQL2000 vers 2005 Entreprise , et nous
> avons profité pour mettre en place le partitionnement des tables
> volumineuses
> sur 6 GROUPES DE Fichiers
> Lorsque nous avons testé les performances sur un serveur de TEST avec un
> disque data Local , nous avons été agreablement surpris par l'amelioration
> des temps de reponse. (presque divisés par 6 !!)
>
> Par contre lorsque nous avons decidé de mettre la solution en pre prod et
> nous avons refait la meme chose sur le serveur de pre prod nous avons etes
> decus car les temps de reponses se sont rallongés ....
>
> La seule difference entre le test et la pre prod c'est que la pred prod
> est
> en Cluster SQL Server Entreprise
>
> et les datas sont sur un NAS , alors que le serveur de test n'etait pas en
> cluster et avait un seul disque local.
>
> Avez vous des idées? est ce que le fait d'avoir partitionné sur un NAS
> peut
> avoir un effet negatif?
> est ce que l'ecriture sur NAS est differente de l'ecriture sur disque
> local
> bref avez vous une explication au probleme
>
> Merci pour toute aide
>
> HCH

Oh pardon.... !
Je n'avais pas vu qu'il s'agissait d'un NAS et non d'un SAN !
C'est une hérésie que d'utiliser un NAS. Vous courrez à la
catastrophe. C'est fortement déconseillé et impossible par défaut.
Pour faire cela il faut déplomber le serveur avec un FLAG de TRACE.
Voir mon blog ou j'en parle...
http://blog.developpez.com/sqlpro?title=fragmentation_physique_des_fichier s_et_t
Dernier paragraphe...

A +



On 11 juin, 11:31, hch <h...@discussions.microsoft.com> wrote:

MERCI pour toutes ces infos

hch

"Cyril Blanloeil - LANDPARK" wrote:

> Bonjour,

> voilà mon avis sur le problème, l'équipement NAS étant un équi pement réseau
> les performances dépendront du trafic réseau et de l'accès à cet équipement.
> Si vous en avez la possibilité vous pouvez vérifier cette hypothès e en
> plaçant sur le serveur de pré-prod les fichiers en local.
> Pour ce genre d'architecture, le SAN serait une solution plus adapté à ce
> genre de besoin, reconnu pour le débit (selon protocole choisi) et
> performance pour le mode transactionnel (NB : infrastructure plus onér euse).

> Cyril

> "hch" <h...@discussions.microsoft.com> a écrit dans le message de grou pe de
> discussion : A4F83088-51C7-4A60-B332-9D65447B3...@microsoft.com...
> > Je vous soumet un probleme etrange que j'ai eu chez mon client

> > nous avons fait une migration de SQL2000 vers 2005 Entreprise , et nou s
> > avons profité pour mettre en place le partitionnement des tables
> > volumineuses
> > sur 6 GROUPES DE Fichiers
> > Lorsque nous avons testé les performances sur un serveur de TEST ave c un
> > disque data Local , nous avons été agreablement surpris par l'amel ioration
> > des temps de reponse. (presque divisés par 6 !!)

> > Par contre lorsque nous avons decidé de mettre la solution en pre pr od et
> > nous avons refait la meme chose sur le serveur de pre prod nous avons etes
> > decus car les temps de reponses se sont rallongés ....

> > La seule difference entre le test et la pre prod c'est que la pred pro d
> > est
> > en Cluster SQL Server Entreprise

> > et les datas sont sur un NAS , alors que le serveur de test n'etait pa s en
> > cluster et avait un seul disque local.

> > Avez vous des idées? est ce que le fait d'avoir partitionné sur u n NAS
> > peut
> > avoir un effet negatif?
> > est ce que l'ecriture sur NAS est differente de l'ecriture sur disque
> > local
> > bref avez vous une explication au probleme

> > Merci pour toute aide

> > HCH

SQLpro a écrit :

Oh pardon.... !
Je n'avais pas vu qu'il s'agissait d'un NAS et non d'un SAN !
C'est une hérésie que d'utiliser un NAS. Vous courrez à la
catastrophe. C'est fortement déconseillé et impossible par défaut.
Pour faire cela il faut déplomber le serveur avec un FLAG de TRACE.
Voir mon blog ou j'en parle...
http://blog.developpez.com/sqlpro?title=fragmentation_physique_des_fichiers_et_t
Dernier paragraphe...

A +

c'est aussi une hérésie de suivre les conseils de quelqu'un qui prétend
coder plus de 65536 valeurs sur 2 octets ?

http://groups.google.com/group/fr.comp.applications.sgbd/msg/621527f995585842?dmode=source


--
Dr Thierry HOLZ
HELIOS SERVICES
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net

Merci pour tout je vais compiler toutes ces reponses et faire un test complet
avec les specilistes hardware

Merci encore pour ce partage d'infos et d'experiences
hch

"SQLpro" wrote:

Oh pardon.... !
Je n'avais pas vu qu'il s'agissait d'un NAS et non d'un SAN !
C'est une hérésie que d'utiliser un NAS. Vous courrez à la
catastrophe. C'est fortement déconseillé et impossible par défaut.
Pour faire cela il faut déplomber le serveur avec un FLAG de TRACE.
Voir mon blog ou j'en parle...
http://blog.developpez.com/sqlpro?title=fragmentation_physique_des_fichiers_et_t
Dernier paragraphe...

A +



On 11 juin, 11:31, hch <h...@discussions.microsoft.com> wrote:
> MERCI pour toutes ces infos
>
> hch
>
> "Cyril Blanloeil - LANDPARK" wrote:
>
> > Bonjour,
>
> > voilà mon avis sur le problème, l'équipement NAS étant un équipement réseau
> > les performances dépendront du trafic réseau et de l'accès à cet équipement.
> > Si vous en avez la possibilité vous pouvez vérifier cette hypothèse en
> > plaçant sur le serveur de pré-prod les fichiers en local.
> > Pour ce genre d'architecture, le SAN serait une solution plus adapté à ce
> > genre de besoin, reconnu pour le débit (selon protocole choisi) et
> > performance pour le mode transactionnel (NB : infrastructure plus onéreuse).
>
> > Cyril
>
> > "hch" <h...@discussions.microsoft.com> a écrit dans le message de groupe de
> > discussion : A4F83088-51C7-4A60-B332-9D65447B3...@microsoft.com...
> > > Je vous soumet un probleme etrange que j'ai eu chez mon client
>
> > > nous avons fait une migration de SQL2000 vers 2005 Entreprise , et nous
> > > avons profité pour mettre en place le partitionnement des tables
> > > volumineuses
> > > sur 6 GROUPES DE Fichiers
> > > Lorsque nous avons testé les performances sur un serveur de TEST avec un
> > > disque data Local , nous avons été agreablement surpris par l'amelioration
> > > des temps de reponse. (presque divisés par 6 !!)
>
> > > Par contre lorsque nous avons decidé de mettre la solution en pre prod et
> > > nous avons refait la meme chose sur le serveur de pre prod nous avons etes
> > > decus car les temps de reponses se sont rallongés ....
>
> > > La seule difference entre le test et la pre prod c'est que la pred prod
> > > est
> > > en Cluster SQL Server Entreprise
>
> > > et les datas sont sur un NAS , alors que le serveur de test n'etait pas en
> > > cluster et avait un seul disque local.
>
> > > Avez vous des idées? est ce que le fait d'avoir partitionné sur un NAS
> > > peut
> > > avoir un effet negatif?
> > > est ce que l'ecriture sur NAS est differente de l'ecriture sur disque
> > > local
> > > bref avez vous une explication au probleme
>
> > > Merci pour toute aide
>
> > > HCH

rebonjour

apres verification , il y a eu confusion , mon client a rattaché un SAN et
non un NAS au serveur de preprod sur lequel nous avons les problemes de perf

auriez vous alors des recommandations particulieres pour la config du SAN

Merci pour tout et desolé de cette erreur
hch

"Fred BROUARD" wrote:

Si votre NAS n'a pas 6 agrégat physiques différents les performances
seront les mêmes qu'avec un seul fichier.
Pire, si les unités logique (LUN) ne correspondant pas à des unité
physique (ZONING) alors vous choperez des temps encore plus long dû au
fait des opérations concurrentes d'autres services.

En tout état de cause avec SQL Server il vaut mieux un NAS dédié, et si
vous avez un NAS il est essentiel de définir autant d'unité logique
calqué sur des unités pgysiques que nécessaire.

De plus il vous faut impérativement tailler vos fichiers à des dimension
importantes correspondant par exemple au volume à terme de la abse de
données pour une exploitation de 3 à 5 ans

Autrement ditn il faut un NAS dédié hautement administrable. Sachez que
les grands constructeurs proposent du hardware spécifique pour les SGBDR
comme SQL Server ou Oracle (IBM, HP...).


hch a écrit :
> Je vous soumet un probleme etrange que j'ai eu chez mon client
>
> nous avons fait une migration de SQL2000 vers 2005 Entreprise , et nous
> avons profité pour mettre en place le partitionnement des tables volumineuses
> sur 6 GROUPES DE Fichiers
> Lorsque nous avons testé les performances sur un serveur de TEST avec un
> disque data Local , nous avons été agreablement surpris par l'amelioration
> des temps de reponse. (presque divisés par 6 !!)
>
> Par contre lorsque nous avons decidé de mettre la solution en pre prod et
> nous avons refait la meme chose sur le serveur de pre prod nous avons etes
> decus car les temps de reponses se sont rallongés ....
>
> La seule difference entre le test et la pre prod c'est que la pred prod est
> en Cluster SQL Server Entreprise
>
> et les datas sont sur un NAS , alors que le serveur de test n'etait pas en
> cluster et avait un seul disque local.
>
> Avez vous des idées? est ce que le fait d'avoir partitionné sur un NAS peut
> avoir un effet negatif?

Oh que OUI !!!

> est ce que l'ecriture sur NAS est differente de l'ecriture sur disque local
> bref avez vous une explication au probleme

Oui, voir ci dessus !

>
> Merci pour toute aide
>
> HCH

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************