Discussion :

[DOMINO53]

Bonjour,
Je cherche des infos sur la gestion de la ram sur SQL2005.

Faut il envisager plusieurs instances sur un serveur W2003 de 16 Go de RAM pour optimiser l'utilisation de la ram avec un sql 2005 voire 2008 ?
Faut il 1 instance avec x bdd ?

Y a t-il un choix à faire si SQL gére bien la ram ?

Merci de vos retours d'expert en la matière.

[iberserk]

SQL SERVER à son propre OS intégré (SQLOS), comme tout bon SGBDR qui se respect son fonctionnement tend à utiliser toute la RAM dont il dispose pour garder le plus de pages de données en mémoire afin de pouvoir répondre le plus efficacement possible aux requêtes...
C'est pourquoi il est conseillé d'installer SQL SERVER sur son propre serveur (ressources physiques dédiées).
Vous pouvez bien sûr paramétrer l'utilisation de la RAM (limitation de la taille max etc.).

Conclusion: il gère bien la RAM

Faut il envisager plusieurs instances sur un serveur W2003 de 16 Go de RAM pour optimiser l'utilisation de la ram avec un sql 2005 voire 2008 ?

NON

[elsuket]

Bonjour,

Pour compléter les propos de Iberserk :

Faut il envisager plusieurs instances sur un serveur W2003 de 16 Go de RAM pour optimiser l'utilisation de la ram avec un sql 2005 voire 2008 ?
Faut il 1 instance avec x bdd ?

Le mieux est d'avoir une seule instance SQL Server sur un seul serveur, avec une seule base de données, logiquement organisée en schémas.

SQL Server gère bien mieux que n'importe quel utilisateur la RAM, faites-lui confiance

@++

[mikedavem]

Le choix de plusieurs instances peut se faire sur plusieurs critères :

- Problème d'isolation de la sécurité
- Problème de collations
- Problème de collisations de nom de bases de données (2 applications qui ont le même nom de bases de donnnées par exemple)

++

[elsuket]

Mikedavem,

- Problème d'isolation de la sécurité : cela peut être géré au niveau du schéma
- Problème de collations : cela peut être géré au niveau table
- Problème de collisations de nom de bases de données (2 applications qui ont le même nom de bases de donnnées par exemple) : pas compris

@++

[SQLpro]

Le choix de plusieurs instances peut se faire sur plusieurs critères :
- Problème d'isolation de la sécurité
- Problème de collations
- Problème de collisations de nom de bases de données (2 applications qui ont le même nom de bases de donnnées par exemple)
++

Aucun de ces problèmes n'est incontournable et avoir plusieurs instances est toujours extrémement contre performant !

Problème d'isolation de la sécurité
Les solution qui existent aujourd'hui en matière de sécurité dans 2008 sont largement suffisantes pour ne pas devoir utiliser plusieurs isntances.

Problème de collations
Totalement réglé si les créations des tables temporaires explicites (et non en SELECT ... INTO) se font avec COLLATE database_default

Problème de collisations de nom de bases de données
Il suffit de jouer sur les schémas SQL et de prévoir le ou les SQL user qui vont bien avec le schéma par défaut associé.

Il n'y a donc aucune raison sérieuse pour placer plusieurs instances sur une même machine.

En revanche : le demandeur n'a pas dit s'il était en 32 ou 64 bits et cela change tout !!!!!

A +

[mikedavem]

Problème d'isolation de la sécurité
Les solution qui existent aujourd'hui en matière de sécurité dans 2008 sont largement suffisantes pour ne pas devoir utiliser plusieurs isntances.

Prenons un serveur qui héberge des applications de plusieurs sociétés. Chacune d'elle a sa propre équipe de DBA et doit pouvoir administrer son instance SQL Server ...

Problème de collisations de nom de bases de données
Il suffit de jouer sur les schémas SQL et de prévoir le ou les SQL user qui vont bien avec le schéma par défaut associé.

D'accord mais quand on pas le contrôle du schéma cela parait compliqué ... On rencontre ce genre de problème dans bon nombre de migrations.

Problème de collisation de nom de bases de données
Il suffit de jouer sur les schémas SQL et de prévoir le ou les SQL user qui vont bien avec le schéma par défaut associé.

Même chose quand on a pas la maitrise du schéma et du code .. cela me paraît compliqué.

- Problème de collisation de nom de bases de données (2 applications qui ont le même nom de bases de donnnées par exemple) : pas compris

Prenons une application A qui va installer une base Client sur l'instance SQL Server et une application B qui installe également une base qui porte le même nom soit Client. Dans ce cas soit il faudrait renommer une des bases mais pour la plupart des applications cette opération est impossible.

Il y a encore bon nombre de cas où l'installation de plusieurs instances s'impose mais comme vous, si je peux éviter d'avoir plusieurs instances je le fais systématiquement.

++

[elsuket]

Prenons un serveur qui héberge des applications de plusieurs sociétés. Chacune d'elle a sa propre équipe de DBA et doit pouvoir administrer son instance SQL Server ...

Je pense que tu cites cela pour l'avoir vécu, mais il aurait été plus sérieux de la part de ton employeur ou de ton client de prévoir deux serveurs ...
Ne me réponds pas que ça coûte cher !

Outre les exemples de contrôle sur le schéma que je comprend tout à fait (bon nombre de participants viennent sur ce forum avec cette contrainte), les autres exemples que tu donnes me semblent être des cas particuliers.

Je pense qu'il y a peu de chances pour que deux applications :

- éditées par deux entreprises différentes
- crées par la même entreprise

aient le même nom de bases de données.
Mais peu de chances signifie que c'est possible

Ici je crois que ce que met en avant SQLPro est l'ignorance terriblement répandue et très difficile à combattre des schémas de base de données.
Il m'est actuellement impossible de faire comprendre au DBA principal que si l'on organisait logiquement les tables à travers des schémas, ce serait un peu plus simple de gérer 4000 tables ...
Au lieu de cela, chacune est précédée par une abréviation qui aurait du en fait être le nom du schéma ...

Je ne vois aucun avantage à avoir plusieurs instances sur la même machine, si ce n'est satisfaire une certaine radinerie, dont les entreprises sont particulièrement friandes (quelle que soit leur taille).
Si elles regardaient le temps que leurs DBAs perdent à chercher la petite bête pour faire qu'un tout petit serveur tienne tout juste la charge de l'entreprise, elles changeraient peut-être d'avis.

En revanche, avoir plusieurs bases de données sur un seule instance SQL Server me semble avoir du sens si l'on souhaite avoir des fichiers de journaux de transaction séparés, en considération d'un plan de reprise d'activité et éventuellement de haute disponibilité.

@++