Un seul et meme disque pour plusieurs Tempdb?

Tuxoon · 20/04/2011, 16h18

Bonjour,

Je dispose d'un nouveau serveur avec plusieurs instances, et selon les Best Practice Microsoft SQL, il est recommandé de placer la base de données "Tempdb" sur une disque rapide à part.

Ma question est :

-Est-il possible de dédier un seul est même disque pour tout les "Tempdb" des instances présentes sur mon seveur sans que cela n'affecte les performances (qui est le but recherché)?

Merci pour vos réponses

WOLO Laurent · 20/04/2011, 19h19

Il me semble que tu saches déjà que cela va forcement affecter les performances de ton applications.Si c'est pour une utilisation pro et si vos budgets, respecter les recommandations de l'éditeur.

iberserk · 21/04/2011, 08h43

Citation:

pour tout les "Tempdb" des instances présentes sur mon seveur

Vous avez plusieurs instances sur le même serveur?

WOLO Laurent · 21/04/2011, 09h04

Citation:

Envoyé par Tuxoon

-Est-il possible de dédier un seul est même disque pour tout les "Tempdb" des instances présentes sur mon seveur sans que cela n'affecte les performances (qui est le but recherché)?
Merci pour vos réponses

Combien de disque peux-tu disposer et combien d'instance veux tu installer ?

iberserk · 21/04/2011, 09h06

Citation:

Est-il possible de dédier un seul est même disque pour tout les "Tempdb" des instances présentes sur mon seveur sans que cela n'affecte les performances (qui est le but recherché)?

Clairement un disque physique dédié pour chaque tempDB vous apportera de meilleurs performances qu'un disque partagé pour vos multiples tempdb...

Tuxoon · 21/04/2011, 09h38

Bonjour,

Merci a tous pour vos reponses

.
Il va y avoir au moins 5 instances voir plus. Apres reflection, il se trouve que l'on va partager ces instances entre deux serveurs mises en cluster multi-site (voir trois dans un avenir prochain) .
Pour le basculement des services, je me suis rendu compte qu'il est preferable (obligatoire) qu'un disque dedie a "Tempdb" par instance soit cree.
Heureusement, nous avons enormement d'espace disques!

Merci encore pour vos eclairsissement qui me seront utiles prochainement

.

Bonne journee a tous

aieeeuuuuu · 21/04/2011, 10h31

Bonjour,

Citation:

Envoyé par Tuxoon

Heureusement, nous avons enormement d'espace disques!

Précision : on parle bien de disque physique...

Citation:

Il va y avoir au moins 5 instances voir plus

Si ce n'est pas indiscret, pourquoi avez vous autant d'instances ?

WOLO Laurent · 21/04/2011, 10h46

Citation:

Envoyé par Tuxoon

Bonjour,

Merci a tous pour vos reponses

.
partager ces instances entre deux serveurs mises en cluster multi-site (voir trois dans un avenir prochain) .
Pour le basculement des services
Bonne journee a tous ;

Pour le basculement multi-site, il vaux mieux utiliser le mirroring des bases de données. Je ne crois pas qu'il soit possible de faire du cluster multi-site sous windows !

Ptit_Dje · 21/04/2011, 11h49

Citation:

Envoyé par WOLO Laurent

Pour le basculement multi-site, il vaux mieux utiliser le mirroring des bases de données. Je ne crois pas qu'il soit possible de faire du cluster multi-site sous windows !

Detrompes toi l'ami

Un peu de lecture:
http://download.microsoft.com/downlo...erCluster.docx

Tu peux y trouver une section multi-site failover cluster (page 15).

@Tuxoon:
Si jamais tu as un retour d'experience a partager la dessus, il est tres bienvenu

Tuxoon · 21/04/2011, 14h18

Re-bonjour

,

Concernant l'espace disque, nous disposons de SAN HP.
Toutes les données se trouvant sur le SAN du site A sont automatiquement repliquées sur le SAN se trouvant sur le site B (le process de replication est effectué par la technologie HP).

L'installation d'un cluster Microsoft SQL multi-site est identique a celle d' un simple cluster, si ce n'est que pour le Quorum nous utilison un File Share Witness (Node and File Share Majority), soit une simple dossier partagé sur un troisième serveur, de préférence sur un troisième site.

La partie qui pourrait être la "plus compliquée"

concerne la configuration réseau au niveau de la redondance.

Voici un lien interressant sur la mise en place d' un cluster SQL multi-site :

http://clusteringformeremortals.com/...%80%93-part-1/

Dans ce lien, l'application permettant la réplication s'appelle DataKeeper.

Concernant le nombre d'instance, elle correspond au nombre d'application.
Les applications ayant un grand nombre de bases de données (on en a plusieurs) ont leur propre instance (SharePoint par exemple).
Concernant "les différentes applications ayant peu de petites bases de données", elles sont toutes regroupés sur la même instance.

Bonne journée

iberserk · 21/04/2011, 15h45

Citation:

Concernant le nombre d'instance, elle correspond au nombre d'application.
Les applications ayant un grand nombre de bases de données (on en a plusieurs) ont leur propre instance (SharePoint par exemple).
Concernant "les différentes applications ayant peu de petites bases de données", elles sont toutes regroupés sur la même instance.

Il est déconseillé d'avoir plusieurs instances sur un même serveur physique...
Préférez 5 serveurs pour vos 5 instances ou reconsidérez le fait de répartir vos bases sur des instances différentes (en plaçant donc les différentes bases sur une même instance)

Tuxoon · 21/04/2011, 16h16

Merci Iberserk, j'attendais ce genre de reponse

.

Etant admin systeme et reseau a la base, depuis quelques temps l'on m'a donner la charge des server SQL, j'ai trouver ce genre d'installation a mon arrivee dans l'entreprise.
Apparement, le but aujourd'hui est de diminuer le nombre de serveur SQL physique, en migrant plusieurs instances sur un cluster a 2 ou 3 noeuds, chaque noeud ayant une tres bonne config (72 voir 140 GB de RAM ou + si besoin est, system a 6 coeurs, 12 processeurs logiques, avec SAN HP ayant de tres bonnes performances).
J'ai un peu moins d'une dizaine d'instances reparties sur plusieurs serveurs (en cluster et en standalone) et plus de 200 DB.
Ayant tres peu de connaissances SQL, j'essai de rechercher toutes les informations importantes concernant l'optimisation d'un serveur SQL (au niveau du system) et il est vrai que je n'ai jamais vue une documentation concernant la presences de plusieurs instances sur un seul et meme serveur.
Je vais tres prochainement solliciter vos precieux conseils dans d'autres topics

.

Malheureusement, je ne penses pas que mes responsables voudront augmenter le nombre de serveur SQL par instance. Je devrai prouver cette utilitee en prouvant que les performances sont moins bonnes. J'ai commencer a creer une baseline concernant tous les serveurs SQL qui pourra m'etre utile pour ca

.

Merci encore pour vos conseils

Ptit_Dje · 21/04/2011, 16h48

C'est inutile d'avoir une instance par serveur physique si le serveur a la capacite d'en contenir plusieures ! Gaspillage de ressources... A moins de contraintes legales ou techniques specifiques.

Apres il faut par contre bien delimites les ressources disponibles pour chaque instance (min-max de RAM, CPU par exemple en utilisant WSRM) et aussi leur laisser leurs propres disques histoire de savoir monitore l'usage des ressources par instance independemment.

Selon certaines contraintes on peut devoir separer plusieurs bases de donnees/applications car celles-ci demande des droits trop eleves sur une instance (imagine une application qui necessite sa sur une instance... Et bien il vaut mieux la foutre seule sur une instance au niveau securite car elle pourrait potentiellement foutre la grouille sur toute l'instance).

Apres, comme souvent, il n'y a pas une mais des solutions et une analyse plus en detail de ce que vous hostez comme bases/application devrait vous permettre de voir plus clair comment vous pourriez consolider vos serveurs.

SQLpro · 21/04/2011, 19h25

C'est toujours un absurdité à tous les niveaux d'avoir plusieurs instances sur un même serveur physique :
1) il y a concurrence de mémoire et le réglage possible étant statique, la RAM est très mal utilisée.
2) un certain nombre de ressources redondantes sont utilisées
3) il y aura concurrence des CPU à moins de l'interdire par un masque d'affinité différente et sans chevauchement pour chaque instance
4) les verrous mémoire seront important et les temps d'attente log...

Bref, totalement contre performant.

Si vous voulez de la performances, c'est 1 instance par serveur physique et pas de virtualisation. En sus vous devez maitriser la gestion des agrégat RAID dans votre SAN en évitant le RAID 5 / 6 et en alignant les LUN sur des disques physiques.
Enfin, croisez les fichiers data et log des bases pour répartir la synchro des IO

Lisez les articles que j'ai écri à ce sujet sur mon site et notamment :
http://blog.developpez.com/sqlpro/p8...t-le-stocakge/
http://blog.developpez.com/sqlpro/p9...u-plusieurs-1/

A +

iberserk · 21/04/2011, 19h45

Citation:

C'est inutile d'avoir une instance par serveur physique si le serveur a la capacite d'en contenir plusieures ! Gaspillage de ressources...

Pas du tout d'accord comme viens de l'expliquer SQLPRO c'est justement dans le cas ou vous allez tenter de partager ces ressources que vous allez au devant de problème...

Tuxoon · 22/04/2011, 08h47

Citation:

Envoyé par SQLpro

Lisez les articles que j'ai écri à ce sujet sur mon site et notamment :
http://blog.developpez.com/sqlpro/p8...t-le-stocakge/
http://blog.developpez.com/sqlpro/p9...u-plusieurs-1/

Bonjour a tous et merci pour ces liens.
a vous lire, je penses avoir pas mal de de lecture et de boulot pour que mon parc de serveur SQL soit correctement configurer.

Merci encore et bonne journee

SQLpro · 22/04/2011, 09h44

Citation:

Envoyé par iberserk

Pas du tout d'accord comme viens de l'expliquer SQLPRO c'est justement dans le cas ou vous allez tenter de partager ces ressources que vous allez au devant de problème...

Si vous avez 16 Go sur le serveur Physique (64 bits), vous allez par exemple donner 8 Go pour une instance et 8 Go pour l'autre via sp_configure.
Problème si l'une des instance à besoin de beaucoup plus alors que l'autre ne bosse pas, la première sera toujours limité à 8 Go. Tandi que l'autre à aussi 8 Go pour rien ! C'est une absurdité !

Si vous laissez les deux serveur se partager la RAM alors l'un va vampiriser la RAM de l'autre et vous pouvez arriver dans une situation instable au niveau RAM : l'un aura toute le RAM et l'autre rien (SQL Server étant préemptif au niveau RAM). Ce qui fait que l'autre instance devra signaler un stress mémoire à l'OS qui arbitrera et demandera à l'autre instance de rendre de la RAM, opération qui ne pourra pas être effectué immédiatement si une grosse transaction est en cours. Der plus la mémoire redonnées risque d'être reprise très rapidement si l'autre instance ne bosse plus trop.

De plus les méta données sont dédoublées, DMV, profileur interne, etc... donc deux fois plus d'encombrement mémoire

A +

mikedavem · 22/04/2011, 10h35

Citation:

Si vous avez 16 Go sur le serveur Physique (64 bits), vous allez par exemple donner 8 Go pour une instance et 8 Go pour l'autre via sp_configure.
Problème si l'une des instance à besoin de beaucoup plus alors que l'autre ne bosse pas, la première sera toujours limité à 8 Go. Tandi que l'autre à aussi 8 Go pour rien ! C'est une absurdité !

Est ce que l'on ne se retrouve pas dans la même situation avec une instance et plusieurs bases de données applicatives ? Une application qui sera plus gourmande en ressources pendant un intervalle de temps indéterminé va vampiriser également la mémoire au détriment des autres applications ...

On pourrait dire d'utiliser le gouverneur de ressources dans ce cas mais la réservation de la mémoire se fait de manière statique également .. ce qui est alloué le reste .. on se retrouve bien dans la même situation que pour 2 instances.

Bon le gros désavantage comme tu le dis c'est que chaque instance a besoin de son propre espace mémoire de travail ... et l'administration est plus complexe .. 2 instances à gérer au lieu d'une. Dans ce cas il faudrait pouvoir avoir des métriques d'utilisation des ressources pour chaque application qui sera hébergé sur chaque instance + une éventuelle marge afin de déterminer le dimensionnement et le paramétrage nécessaire aux différentes ressources comme l'a évoqué Ptit_Dje.

Si on revient au problème de Tuxxon effectivement avoir plusieurs instances dans son cas n'est peut être pas nécessaire. Mais dans le cas où ceci serait obligatoire, dois t'on forcément garder 2 serveurs physiques avec une instance dédiée même si les ressources utilisés ne dépassent pas le 1/3 des ressources totales ou consolide t'on sur un seul serveur physique avec 2 instances avec paramétrage correct ?

++

20/04/2011, 16h18	#1
Tuxoon Invité de passage Inscription : février 2008 Messages : 8 Détails du profil Informations forums : Inscription : février 2008 Messages : 8 Points : 0 Points : 0	Un seul et meme disque pour plusieurs Tempdb? Bonjour, Je dispose d'un nouveau serveur avec plusieurs instances, et selon les Best Practice Microsoft SQL, il est recommandé de placer la base de données "Tempdb" sur une disque rapide à part. Ma question est : -Est-il possible de dédier un seul est même disque pour tout les "Tempdb" des instances présentes sur mon seveur sans que cela n'affecte les performances (qui est le but recherché)? Merci pour vos réponses
	00

20/04/2011, 19h19	#2
WOLO Laurent Rédacteur/Modérateur Laurent WOLO Architecte de base de données Inscription : mars 2003 Messages : 2 696 Détails du profil Informations personnelles : Nom : Laurent WOLO Âge : 35 Localisation : Congo-Brazzaville Informations professionnelles : Activité : Architecte de base de données Secteur : Finance Informations forums : Inscription : mars 2003 Messages : 2 696 Points : 3 917 Points : 3 917	Il me semble que tu saches déjà que cela va forcement affecter les performances de ton applications.Si c'est pour une utilisation pro et si vos budgets, respecter les recommandations de l'éditeur. __________________ Découvrez la FAQ de MS SQL Server. La chance accorde ses faveurs aux esprits avertis !
	00

21/04/2011, 16h16	#12
Tuxoon Invité de passage Inscription : février 2008 Messages : 8 Détails du profil Informations forums : Inscription : février 2008 Messages : 8 Points : 0 Points : 0	Merci Iberserk, j'attendais ce genre de reponse. Etant admin systeme et reseau a la base, depuis quelques temps l'on m'a donner la charge des server SQL, j'ai trouver ce genre d'installation a mon arrivee dans l'entreprise. Apparement, le but aujourd'hui est de diminuer le nombre de serveur SQL physique, en migrant plusieurs instances sur un cluster a 2 ou 3 noeuds, chaque noeud ayant une tres bonne config (72 voir 140 GB de RAM ou + si besoin est, system a 6 coeurs, 12 processeurs logiques, avec SAN HP ayant de tres bonnes performances). J'ai un peu moins d'une dizaine d'instances reparties sur plusieurs serveurs (en cluster et en standalone) et plus de 200 DB. Ayant tres peu de connaissances SQL, j'essai de rechercher toutes les informations importantes concernant l'optimisation d'un serveur SQL (au niveau du system) et il est vrai que je n'ai jamais vue une documentation concernant la presences de plusieurs instances sur un seul et meme serveur. Je vais tres prochainement solliciter vos precieux conseils dans d'autres topics . Malheureusement, je ne penses pas que mes responsables voudront augmenter le nombre de serveur SQL par instance. Je devrai prouver cette utilitee en prouvant que les performances sont moins bonnes. J'ai commencer a creer une baseline concernant tous les serveurs SQL qui pourra m'etre utile pour ca . Merci encore pour vos conseils
	00

21/04/2011, 19h25	#14
SQLpro Rédacteur/Modérateur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 10 953 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 10 953 Points : 17 773 Points : 17 773	C'est toujours un absurdité à tous les niveaux d'avoir plusieurs instances sur un même serveur physique : 1) il y a concurrence de mémoire et le réglage possible étant statique, la RAM est très mal utilisée. 2) un certain nombre de ressources redondantes sont utilisées 3) il y aura concurrence des CPU à moins de l'interdire par un masque d'affinité différente et sans chevauchement pour chaque instance 4) les verrous mémoire seront important et les temps d'attente log... Bref, totalement contre performant. Si vous voulez de la performances, c'est 1 instance par serveur physique et pas de virtualisation. En sus vous devez maitriser la gestion des agrégat RAID dans votre SAN en évitant le RAID 5 / 6 et en alignant les LUN sur des disques physiques. Enfin, croisez les fichiers data et log des bases pour répartir la synchro des IO Lisez les articles que j'ai écri à ce sujet sur mon site et notamment : http://blog.developpez.com/sqlpro/p8...t-le-stocakge/ http://blog.developpez.com/sqlpro/p9...u-plusieurs-1/ A + __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	00

21/04/2011, 09h38	#6
Tuxoon Invité de passage Inscription : février 2008 Messages : 8 Détails du profil Informations forums : Inscription : février 2008 Messages : 8 Points : 0 Points : 0	Bonjour, Merci a tous pour vos reponses . Il va y avoir au moins 5 instances voir plus. Apres reflection, il se trouve que l'on va partager ces instances entre deux serveurs mises en cluster multi-site (voir trois dans un avenir prochain) . Pour le basculement des services, je me suis rendu compte qu'il est preferable (obligatoire) qu'un disque dedie a "Tempdb" par instance soit cree. Heureusement, nous avons enormement d'espace disques! Merci encore pour vos eclairsissement qui me seront utiles prochainement . Bonne journee a tous
	00

21/04/2011, 14h18	#10
Tuxoon Invité de passage Inscription : février 2008 Messages : 8 Détails du profil Informations forums : Inscription : février 2008 Messages : 8 Points : 0 Points : 0	Re-bonjour , Concernant l'espace disque, nous disposons de SAN HP. Toutes les données se trouvant sur le SAN du site A sont automatiquement repliquées sur le SAN se trouvant sur le site B (le process de replication est effectué par la technologie HP). L'installation d'un cluster Microsoft SQL multi-site est identique a celle d' un simple cluster, si ce n'est que pour le Quorum nous utilison un File Share Witness (Node and File Share Majority), soit une simple dossier partagé sur un troisième serveur, de préférence sur un troisième site. La partie qui pourrait être la "plus compliquée" concerne la configuration réseau au niveau de la redondance. Voici un lien interressant sur la mise en place d' un cluster SQL multi-site : http://clusteringformeremortals.com/...%80%93-part-1/ Dans ce lien, l'application permettant la réplication s'appelle DataKeeper. Concernant le nombre d'instance, elle correspond au nombre d'application. Les applications ayant un grand nombre de bases de données (on en a plusieurs) ont leur propre instance (SharePoint par exemple). Concernant "les différentes applications ayant peu de petites bases de données", elles sont toutes regroupés sur la même instance. Bonne journée
	00

21/04/2011, 16h48	#13
Ptit_Dje Modérateur Administrateur de base de données Inscription : août 2007 Messages : 1 158 Détails du profil Informations personnelles : Sexe : Âge : 28 Localisation : Belgique Informations professionnelles : Activité : Administrateur de base de données Secteur : Industrie Pharmaceutique Informations forums : Inscription : août 2007 Messages : 1 158 Points : 1 617 Points : 1 617	C'est inutile d'avoir une instance par serveur physique si le serveur a la capacite d'en contenir plusieures ! Gaspillage de ressources... A moins de contraintes legales ou techniques specifiques. Apres il faut par contre bien delimites les ressources disponibles pour chaque instance (min-max de RAM, CPU par exemple en utilisant WSRM) et aussi leur laisser leurs propres disques histoire de savoir monitore l'usage des ressources par instance independemment. Selon certaines contraintes on peut devoir separer plusieurs bases de donnees/applications car celles-ci demande des droits trop eleves sur une instance (imagine une application qui necessite sa sur une instance... Et bien il vaut mieux la foutre seule sur une instance au niveau securite car elle pourrait potentiellement foutre la grouille sur toute l'instance). Apres, comme souvent, il n'y a pas une mais des solutions et une analyse plus en detail de ce que vous hostez comme bases/application devrait vous permettre de voir plus clair comment vous pourriez consolider vos serveurs.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email