Multi instances SQL2000

Bonjour,

Je dirais que le multi Instance est intéressant pour des raisons de
sécurité.
En revanche pénalisant pour les performances de la machines qui doit alors
gérer plusieurs moteurs en mémoire.

--
Cordialement.

Romelard Fabrice [MVP]

"hch" <hch@discussions.microsoft.com> a écrit dans le message de news:
B12E6CDF-69F9-4FD5-8C4A-C2446B576542@microsoft.com...

bonjour ,

Lorsqu'on a un super serveur 4 processeurs et 6 GO de RAM par exemple ,
quelles sont a votre avis les arguments et les considerations a prendre en
compte lorsqu'on veut mettre en place SQL Server sur un tel serveur pour
heberger 3 ou 4 appli avec des bases de taille importante .?
(Multiinstance
ou pas???)

Qu'est ce qui pourrait justifier ou pas les choix du type une seule
instance
et 3 ou 4 bases ou bien une instance SQL pour chaque application ou base ?
comment faire le bon choix? et surtout y a t'il de la doc dessus

Merci d'avance

Bonjour,
Je vous recommande plusieurs instances si vos applications necessitent
chaqu'une un grand nombre
de base de donnees (stats, donnees, gestion utilisateur, reporting, ...),
ou pour une separation d'environement utilisateur (compte utilisateur/groupe
dans different domaine/foret)
Par contre la gestion de plusieurs instances simultanees est un facteur
important en consomation des ressources systemes.

--
Anonyme - is SpeGase
Anonyme
.

"hch" <hch@discussions.microsoft.com> wrote in message
news:B12E6CDF-69F9-4FD5-8C4A-C2446B576542@microsoft.com...

bonjour ,

Lorsqu'on a un super serveur 4 processeurs et 6 GO de RAM par exemple ,
quelles sont a votre avis les arguments et les considerations a prendre en
compte lorsqu'on veut mettre en place SQL Server sur un tel serveur pour
heberger 3 ou 4 appli avec des bases de taille importante .?
(Multiinstance
ou pas???)

Qu'est ce qui pourrait justifier ou pas les choix du type une seule
instance
et 3 ou 4 bases ou bien une instance SQL pour chaque application ou base ?
comment faire le bon choix? et surtout y a t'il de la doc dessus

Merci d'avance

hch a écrit :

bonjour ,

Lorsqu'on a un super serveur 4 processeurs et 6 GO de RAM par exemple ,
quelles sont a votre avis les arguments et les considerations a prendre en
compte lorsqu'on veut mettre en place SQL Server sur un tel serveur pour
heberger 3 ou 4 appli avec des bases de taille importante .? (Multiinstance
ou pas???)

Qu'est ce qui pourrait justifier ou pas les choix du type une seule instance
et 3 ou 4 bases ou bien une instance SQL pour chaque application ou base ?
comment faire le bon choix? et surtout y a t'il de la doc dessus

Merci d'avance

Le multi instance est totalement à déconseillé si vous voulez le maximum
de performances et que vous n'avez pas pris en compte des problématiques
de collation différentes sur vos différentes bases.

En effet, SQL Server se comporte comme s'il se trouvait seul comme
application sur la machine et tend à préempter le maximum de RAM au
détriment de toute autre application. Seul l'os windows est autorisé à
demander à SQL Server de restituer de la RAM, et ce uniquement en cas de
stress mémoire dudit OS.
En l'occurrence la cohabitation de différentes instance sans limiter la
RAM de chaque instance peut donc conduire à une famine de RAM pour une
instance qui aurait démarrée son exploitation tardivement (restart par
exemple).
Une fois la RAM limitée pour chaque instance, l'adéquation RAM
nécessaire / RAM utilisée peut s'avérer particulièrement contre
performante. En effet vos différentes isntances n'ont peut être pas
besoin d'une grande quantité de RAM toutes simultanément.

De plus chaque instance occupe une place plus importante en mémoire
(duplication des caches, moteurs...) non négligeable...

Enfin, il est plus difficile d'administrer plusieurs instances qu'une seule.

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.datasapiens.com ***********************

Bonjour,
Le multi instances permet tout de même de cloisonner au mieux les bases,
donc d'éviter facilement qu'une application plus gourmande que les autres
s'accapare l'intégralité des ressources de la machine.
Il est intéressant dans ce cas de spécifier une mémoire fixe par instance
(afin de ne pas basculer dans le cas évoqué par Fred Brouard), et il est
possible, en assignant judicieusement certains processeurs aux différentes
instances, d'éviter qu'une requête ne vienne saturer l'intégralité des CPUs...

BVesan a écrit :

Bonjour,
Le multi instances permet tout de même de cloisonner au mieux les bases,

??? je ne voit pas la différence avec du multibase !

donc d'éviter facilement qu'une application plus gourmande que les autres
s'accapare l'intégralité des ressources de la machine.

FAUX !!!

Une instance peut créer la famine RAM des autres...

Il est intéressant dans ce cas de spécifier une mémoire fixe par instance
(afin de ne pas basculer dans le cas évoqué par Fred Brouard), et il est
possible, en assignant judicieusement certains processeurs aux différentes
instances, d'éviter qu'une requête ne vienne saturer l'intégralité des CPUs...

autre problématique... même en mono instance cela est possible.
Il vaut mieux pour les grosses requêtes préciser un tag MAXDOP en clause
OPTION.

C'est franchement déséquilibré le multi instance et cela ne tire JAMAIS
partie des meilleures performances possible de la machine !

Donc a éviter...

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.datasapiens.com ***********************

Même si dans la majorité des cas, une solution en multi-instances est plus
couteuse qu'une solution en multi-bases, cette solution reste valable dans
pas mal de cas
En voici quelques uns qui me viennent à l'esprit et j'en oublie...
a)Le multi-instance offre une meilleure isolation concernant la sécurité
Chaque instance possède son propre jeu de logins.
C'est même la seule solution si l'on veut pas que le voisin connaisse le nom
de votre base de données

b) Tempdb
En attendant que Microsoft nous donne la possiblité d'avoir un tempdb par
base, le multi-instance reste la seule solution
C'est la solution si lon veut pas partager tempdb avec son voisin et eviter
qu'il voit vos objets temporaires
Des fois la contention est telle sur tempdb que la solution multi-instance
se doit d'être considérée

c)Le multi-instance offre la possibilité d'avoir une configuration
différente pour chaque base.
Le sp_configure peut être totalement différent
Le multi-instance est intéressant lorsque l'on souhaite tourner avec des
services packs différents
Une base en SP4 et une autre en SP3 ou même en une toute autre release de
SQL Server

d) Mémoire
Le multi-instance est même la seule solution si l'on veut pas gaspiller de
la mémoire!!!
Contrairement à ce que dit Fred et en accord avec ce que dit BVesan, il est
tout a fait possible de limiter la consommation RAM d'une instance
Elle n'ira pas empiéter sur la RAM d'une autre instance.
En dehors de ce fait, Il est des cas où l'utilisateur possède une édition
Standard de SQL Server qui ne peut utiliser toute la RAM disponible sur un
serveur
En 2000, l'edition standard est limitée à 2Go, en 2005, l'édition Workgroup
est limitée à 3Go
La seule solution reste alors la mise en place de deux instances
Dans le cas présent, tu dis avoir un serveur avec 6Go de RAM. Si ton SQL
Server 2000 est en édition Standard, tu dois sérieusement considérer cette
solution

Le multi-instance a cependant un cout.
Il te faut payer le prix d'une licence par instance
La gestion admnistrative est multipliée par le nombre d'instance
Sauvegarder plusieurs master, installer plusieurs fois le même patch, etc
Si les instances sont configurées en RAM fixe, ce qui très souvent le cas
dans ce genre d'architecture, cela a l'inconvénient de mobiliser inutilement
de la RAM dans le cas où une des instances ne travaille pas

--
Bien cordialement
Med Bouchenafa


"hch" <hch@discussions.microsoft.com> a écrit dans le message de news:
B12E6CDF-69F9-4FD5-8C4A-C2446B576542@microsoft.com...

bonjour ,

Lorsqu'on a un super serveur 4 processeurs et 6 GO de RAM par exemple ,
quelles sont a votre avis les arguments et les considerations a prendre en
compte lorsqu'on veut mettre en place SQL Server sur un tel serveur pour
heberger 3 ou 4 appli avec des bases de taille importante .?
(Multiinstance
ou pas???)

Qu'est ce qui pourrait justifier ou pas les choix du type une seule
instance
et 3 ou 4 bases ou bien une instance SQL pour chaque application ou base ?
comment faire le bon choix? et surtout y a t'il de la doc dessus

Merci d'avance

Med Bouchenafa a écrit :

Même si dans la majorité des cas, une solution en multi-instances est plus
couteuse qu'une solution en multi-bases, cette solution reste valable dans
pas mal de cas
En voici quelques uns qui me viennent à l'esprit et j'en oublie...

a)Le multi-instance offre une meilleure isolation concernant la sécurité
Chaque instance possède son propre jeu de logins.
C'est même la seule solution si l'on veut pas que le voisin connaisse le nom
de votre base de données

intérêt très limité si sécurité maitrisée, car le nom de la BD ne veut
pas dire grande chose, surtout si l'architecte de données à pensé à
l'injection de SQL.

b) Tempdb
En attendant que Microsoft nous donne la possiblité d'avoir un tempdb par
base, le multi-instance reste la seule solution
C'est la solution si lon veut pas partager tempdb avec son voisin et eviter
qu'il voit vos objets temporaires
Des fois la contention est telle sur tempdb que la solution multi-instance
se doit d'être considérée

Les seuls objets temporaires visibles sont les objets temporaires
globaux qui ont un intérêt limité.

par contre pour la contention de la tempDB, là oui. Mais dans ce cas, le
multiserveur (une base par machine) sera plus intéressant.

c)Le multi-instance offre la possibilité d'avoir une configuration
différente pour chaque base.
Le sp_configure peut être totalement différent
Le multi-instance est intéressant lorsque l'on souhaite tourner avec des
services packs différents
Une base en SP4 et une autre en SP3 ou même en une toute autre release de
SQL Server

Le seul intérêt à mon sens c'est pas en prod (car la encore 1 base sur 1
serveur) sera toujours mieux !
En revanche en développement et notamment pour les tests, c'est intéressant.

d) Mémoire
Le multi-instance est même la seule solution si l'on veut pas gaspiller de
la mémoire!!!
Contrairement à ce que dit Fred et en accord avec ce que dit BVesan, il est
tout a fait possible de limiter la consommation RAM d'une instance
Elle n'ira pas empiéter sur la RAM d'une autre instance.

Tout à fait, mais ce n'est pas ce que je disait : je disais que lorsque
l'on limite la RAM d'un serveur alors il n'y a plus de gestion dynamique
de la mémoire ce qui est contre performant :

Exemple : j'ai 2 serveur et 1 Go
je limite chaque serveur à 512 Mo
A l'instant T serveur 1 aurait besoin de 800 Mo pour traiter une requête
en cache. Il ne peut pas. Les temps de réponse vont être
particulièrement mauvais : lecture disque
Pendant ce temps serveur 2 à 512 Mo et n'en utilise vraiement que 150...
Quel gachis !

Les limitations statiques déséquilibrent les deux serveurs...

En dehors de ce fait, Il est des cas où l'utilisateur possède une édition
Standard de SQL Server qui ne peut utiliser toute la RAM disponible sur un
serveur
En 2000, l'edition standard est limitée à 2Go, en 2005, l'édition Workgroup
est limitée à 3Go
La seule solution reste alors la mise en place de deux instances
Dans le cas présent, tu dis avoir un serveur avec 6Go de RAM. Si ton SQL
Server 2000 est en édition Standard, tu dois sérieusement considérer cette
solution

Le multi-instance a cependant un cout.
Il te faut payer le prix d'une licence par instance
La gestion admnistrative est multipliée par le nombre d'instance
Sauvegarder plusieurs master, installer plusieurs fois le même patch, etc
Si les instances sont configurées en RAM fixe, ce qui très souvent le cas
dans ce genre d'architecture, cela a l'inconvénient de mobiliser inutilement
de la RAM dans le cas où une des instances ne travaille pas

--
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.datasapiens.com ***********************

Bonjour,

donc d'éviter facilement qu'une application plus gourmande que les autres
s'accapare l'intégralité des ressources de la machine.

FAUX !!!

Quoi qui est faux ? d'éviter facilement qu'une application prenne de la
ram de manière inconsidérée, sur SBS oui je sais un peu spécial :-) j'ai 4
instance de SQL qui fonctionne sans broncher.
Et celle qui consomme on la force a moins se gaver et cela fonctionne
parfaitement avec ce script :

USE master
EXEC sp_configure 'show advanced options', 1
RECONFIGURE WITH OVERRIDE
USE master
EXEC sp_configure 'max server memory (MB)', 100
RECONFIGURE WITH OVERRIDE
USE master
EXEC sp_configure 'show advanced options', 0
RECONFIGURE WITH OVERRIDE

Limiter a 100 Mo par exemple ISA 2004 serveur ne bronche pas ni
d'ailleurs monitoring, ni WSS en WMSDE illimité.
Le plus gros intérêt au multi-instance que je conseille en exploitation
c'est que si on a affaire a un porcin de développeur qui fout la grouille
dans son instance, il ne la fout pas ailleurs et avec le moniteur de
perf on peut parfaitement lui mettre le nez dans sa bouse.

--
Cordialement.
GG.