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

@++

[mikedavem]

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 !

Dans ce ca là il faut forcément raisonner budget l... Avoir 2 serveurs, c'est 2 fois le coût d'achat + maintenance des serveurs, deux licences Microsoft, deux licences SQL Server, deux licences d'agents de surveillance etc .. etc .... bref rien qui convaincra un client d'acheter 2 serveurs au lieu d'un seul surtout si ceux-ci ne sont pas utilisés à plein régime ..

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

Justement c'est parce qu'il existe ce genre de cas qu'il faut y penser mais je suis d'accord ce n'est pas tous les jours que l'on voit cela

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.

Je suis 100% d'accord avec SQLPro sur le sujet. Avoir plusieurs instances sur le même serveur n'est pas une bonne pratique en soi mais il faut malheureusement faire avec la réalité. Pourquoi les entreprises vont dans ce sens ? La réponse est simple ... Demander aux développeurs de modifier le schéma d'une base est certainement plus long et plus coûteux que d'acheter de la ressource et de demander à un DBA de faire en sorte que tout va bien. Cette méthode a bien sûr ces limites que tout le monde connaît ..

++

[SQLpro]

Dans ce ca là il faut forcément raisonner budget l... Avoir 2 serveurs, c'est 2 fois le coût d'achat + maintenance des serveurs, deux licences Microsoft, deux licences SQL Server, deux licences d'agents de surveillance etc .. etc .... bref rien qui convaincra un client d'acheter 2 serveurs au lieu d'un seul surtout si ceux-ci ne sont pas utilisés à plein régime ..

Dans ce cas la virtualisation est intéressante :
1) base qui bosse pas à plein régime
2) économie de licence : 1 seule licence pour les 2 instances puis que le pris est fonction des CPU physiques....

A +

[mikedavem]

Effectivement sur le coût on y gagne tu as raison mais alors après il faudra aussi prendre en compte les problématiques de performances qu'amène la virtualisation ... surtout si le paramétrage en amont est mal fait.

On peut se demander alors quel est le mieux : Avoir un serveur physique et 2 instances ou 2 serveurs virtuels avec une instance propre ?

++

[DOMINO53]

Merci à tous pour ces réponses.

Je vois que la solution est à trouver en fonction de son cas et des principes de la gestion des BDD

En l'occurence, nous souhaitons utiliser MS Query qui requiert que l'utilisateur précisé soit SYSADMIN. Et donc admin de toute l'instance.
Cet utilisateur est un utilisateur Editeur auquel nous ne souhaitons pas donner ce droit.
Il y a peut être un moyen de gérer ce cas ??

Comment faire autrement que de créer 1 instance dédié pour notre base Editeur ?

Concernant mon serveur C'est un 64 Bits

Merci

[Ptit_Dje]

J'ai une question concernant la logique 1 DB avec plusieurs schemas pour differents clients et la securite au niveau des schemas.

Lorsqu'un client demande un restore, comment fait on pour restaurer un seul schema ?

Si vous avez des references la dessus je suis prenneur a 100% !


Je suis d'accord aussi avec Mikedavem concernant plusieures instances sur un serveur comme je l'ai deja explique brievement dans d'autres posts.
D'autant plus si on considere 3 voir 4 environnements (DEV/INT/QA/PROD), il va vite falloir investir dans un datacenter complet.


Pour ce qui est du DBA et de l'organisation des tables - Il n'est pas toujours demande au DBA de savoir ce que contienne les DBs. Juste de gerer des boites, des sous boites et des sous-sous-boites (serveurs, instances et dbs + disques et tout le tralala qui va avec...). Le cote applicatif et le reste etant gerer par d'autres equipes.


Cote securite des donnees, je en veux absolument pas qu'une application qui necessite un SA puisse acceder aux donnees d'autres bases sur la meme instance.
Comment je fais ? Est ce que le deny fonctionne sur un SA (jamais teste...) ?

Dans ce cas la virtualisation est intéressante :
1) base qui bosse pas à plein régime
2) économie de licence : 1 seule licence pour les 2 instances puis que le pris est fonction des CPU physiques....

A +

Dans ce cas pourquoi pas mettre directement 2 instances sur un serveur physique plutot que sur un host de VM ? On a une couche a gerer en moins et qui plus est, on charge pas en memoire 2 OS complets (windows...) avec bien entedu segregations des ressources...

[mikedavem]

Lorsqu'un client demande un restore, comment fait on pour restaurer un seul schema ?

On pourrait utiliser les groupes de fichiers distincts par schéma et les sauvegardes partielles mais celles-ci ne supportent pas le mode de récupération complet et ne peut donc pas être restaurés dans le temps. De plus elles ne sont pas adaptées pour ce genre d'usage. Donc la seule manipulation que je connaisse c'est restauration complète d'une base à côté et réinsertion des données dans le schéma concerné.

Cote securite des donnees, je en veux absolument pas qu'une application qui necessite un SA puisse acceder aux donnees d'autres bases sur la meme instance.
Comment je fais ? Est ce que le deny fonctionne sur un SA (jamais teste...) ?

Non et en plus je pense que ce serait une très mauvaise idée. SA reste le super utilisateur du serveur avec les pleins pouvoirs. Dans ce cas un login pour chaque application et un accès à sa propre base de données. Si l'application doit avoir un full accès au serveur, dans ce cas pas le choix, il faut passer par une instance dédiée.

++

[SQLpro]

Vous ne pouvez pas restaurez un seul schéma. Mais si vous mettez toutes les tables d'un même schéma dans un seule et même filegroup alors vous pouvez faire des sauvegardes partielles.
En revanche vous ne pouvez pas faire des restaurations partielles car cela n'a pas de sens.
Mais rien de vous empêche de restaurer sous une autre base et importer les données de l'autre base dans la base de production....

A +

[zinzineti]

J'ai une question concernant la logique 1 DB avec plusieurs schemas pour differents clients et la securite au niveau des schemas.
Lorsqu'un client demande un restore, comment fait on pour restaurer un seul schema ?

Bonne question

J'avais évoqué cette problématique dans mon commentaire à cet article de sqlpro

Il me semble que sous ORACLE le backup/restore de schema d'une instance est possible

[Ptit_Dje]

Vous ne pouvez pas restaurez un seul schéma. Mais si vous mettez toutes les tables d'un même schéma dans un seule et même filegroup alors vous pouvez faire des sauvegardes partielles.
En revanche vous ne pouvez pas faire des restaurations partielles car cela n'a pas de sens.
Mais rien de vous empêche de restaurer sous une autre base et importer les données de l'autre base dans la base de production....

A +

Donc si on suit l'idee de consolider toutes les bases de donnees dans une seule sous different schemas, on s'expose a avoir une base de donnee d'une volumetrie enorme avec un temps de restauration monstre pour un schema qui fait peut etre au total 200MO (mesure totalement arbitraire).
Niveau recovery time, je ne pense pas que les clients soient tres heureux.
De plus, cela necessite d'avoir un espace de storage disponible en tout temps.

De plus si l'on part dans cette direction, on egare dans la notion de schema qui permet d'organiser les tables (ie dans un datawarehouse en fonction des differents datamarts) qui deviendrait plus une notion de "base de donnees" au sens SQL server du terme. Comment alors organiser ces tables ? Utiliser des naming conventions au niveau des schemas genre <schema>_<sous-schema> ?
Je pense personellement que ca devient complique a gerer.

[WOLO Laurent]

Restaurer un fichier de 200 Mo ne prend que quelques secondes sur un serveur dédié. Le seul problème reste l'organisation du stockage des données des differents shémas.

Cordialement;

[SQLpro]

Donc si on suit l'idee de consolider toutes les bases de donnees dans une seule sous different schemas, on s'expose a avoir une base de donnee d'une volumetrie enorme avec un temps de restauration monstre pour un schema qui fait peut etre au total 200MO (mesure totalement arbitraire).
Niveau recovery time, je ne pense pas que les clients soient tres heureux.
De plus, cela necessite d'avoir un espace de storage disponible en tout temps.

Pour vous donner un ordre d'idée la restauration d'une base de 10 Go sur un bon serveur, ne prend que quelques secondes. Tout dépend de l'organisation des disques et de l'activité au moment du remontage de la base (activité qui devrait être nulle si vous avez perdu la base).

D'autre part vous confondez deux notions : haute disponibilité et besoin de sauvegardes... Je vais en reparler...

De plus si l'on part dans cette direction, on egare dans la notion de schema qui permet d'organiser les tables (ie dans un datawarehouse en fonction des differents datamarts) qui deviendrait plus une notion de "base de donnees" au sens SQL server du terme. Comment alors organiser ces tables ? Utiliser des naming conventions au niveau des schemas genre <schema>_<sous-schema> ?
Je pense personellement que ca devient complique a gerer.

Parce que vous n'en avez pas l'habitude... Malgré que la notion de schéma SQL existe depuis la version 1 de la norme (1986...).
De toute façon la nécessité d'une norme de nommage est plus qu'importante. Elle est à mon sens impérative...

Pour ce qui est de la sauvegarde : celle-ci ne doit être utilisée qu'en dernier recours et ce dans deux cas de figure bien distinct :
1) la récupération de données ancienne
2) le sinistre majeur (incendie, dégâts des eaux....)
Dans les deux cas, vous consommerez beaucoup plus de temps dans l'organisation du scénario de reprise qu'au temps réel de la restauration !

Prenons le premier cas : restauration de données anciennes, avec un exemple.... Suppression malencontreuse d'un client et ses factures suite à une fausse manœuvre.
Il vous faudra beaucoup de temps pour reprendre les données de la sauvegarde et les remettre dans la base de prod. En effet, vous ne devez pas arrêter la base de prod pour ce faire, mais restaurer à côté et faire quelques requêtes de réinsertion. Pour peu que les clefs primaires aient été réutilisées, alors vous allez passer quelques heures, voir quelques jours à retrouver vos petits.

Prenons le second cas : sinistre majeur, là il vous faudra retrouver un local, racheter des machines....

Vous confondez reprise des données et haute dispo.... Si vos exigences sont de n'avoir pas d'interruption de service lors d'un sinistre mineur (perte d'une disque, d'une alim, d'une mémoire, d'un CPU... ) alors la solution est la haute dispo qui ne se fait pas avec des sauvegardes mais avec du clustering, du mirroring, voir du log shipping, tout dépend de la perte des données envisageable entre une synchro absolue (0 perte) et quelques minutes.

A +

[Ptit_Dje]

Restaurer un fichier de 200 Mo ne prend que quelques secondes sur un serveur dédié. Le seul problème reste l'organisation du stockage des données des differents shémas.

Cordialement;

Hello Laurent,

Il n'est pas possible de restaurer une base de donnees partiellement.
Donc pour restaure un schema de 200MO il faut restaurer l'entierete de la base de donnees (qui pourrait au total faire plusieurs GO/TO) sous un autre nom.

Une amelioration a apporter a SQL Server (pour rebondir sur ce sujet) serait donc de pouvoir effectuer une restauration d'un "contained schema" d'une base de donnee individuellement.
La notion de "contained schema" se rapproche de l'idee des contained databases de Denali, dans le sens ou le schema a lui seul est independant de la base de donnee dans laquelle il se trouve et peut etre restaurer en standalone. (Pas de FK referencee vers un autre schema, pas de stored procedures utilisant un autre schema, pas de vue referencant un autre schema, ...).
On pourrait aller plus loin avec des "Partial contained schema" qui pourrait avoir une relation avec un ou plusieurs schemas et pour restaurer l'un de ces schema, les autres schemas necessite d'etre restaure aussi.

C'est juste une idee ainsi...