Choix du serveur

Vaste question

1 - Recommendation sur le matériel
1-1 CPU : le plus gros delta est visible entre mono et bi proc (un 4 proc va
tout de même plus vite !)
1-2 CPU : les bench en 64 bits sont éloquents
1-3 RAM : suffisament !!! à voir selon l'exploitation des données
1-4 Disque : Un disque physique dédié pour le fichier de log. Regarder de
très près le temps d'accès moyen (et la tolérance de panne)
1-5 réseau : suffisament !!!

2- A budget donné comment choisir ?
Louer une belle bécane.
Installer une virtualisation de serveur.
Rejouer des traces.
Modifier les parametres (CPU, RAM, ...) et recommencer

3- Verifier que le code n'est pas le principal soucis de lenteur !!!
Ceci est à faire en dernier car tout le monde sais alors ce qu'on a
économisé à ne pas passer au matériel au dessus.

"Manur37" a écrit :

J'expose brievement mon pb :

J'ai développé un back office de gestion de stock avec VB6 et SQL Serveur
2000. Il est installé sur un réseau dont on n'a pas la maintenance. SQL
Server est installé sur le controleur principal de domaine qui est en Windows
NT alors que les postes clients sont en 2000 pro.

Il y a environ 50 postes qui travaillent simultanement sur l'application
avec beaucoup d'accés à la base de données (récupération des stocks, des
infos d'articles lors de la saisie de BL, commandes, etc....).

La base de données fait environ 10 Go.

J'aimerais savoir quelle est la configuration idéale du serveur pour obtenir
des performances correctes car actuellement il y a beaucoup de pb et
j'envisage de demander à mon client d'investir dans un serveur consacré
uniquement à SQL.

Merci d'avance.

La RAM c'est primordial, par exemple si tu avais plus de 10 Go de RAM, toute
ta base serais dans le cache ram, et si tout est bien configuré, tous tes
reads seraient dans le cache ram, et seuls les inserts et updates génèrent
des accès disques.

Donc si tu as beaucoup de "reads", beaucoup de RAM apporte un plus énorme.

Pour cette même raison il faut dédier une machine au SQL pour que la base
puisse disposer de toute la CPU et de la RAM nécessaire.

Pour les accès disque, une technologie performante comme SCSI ou RAID (ou
les deux) apporte aussi un énorme plus, les écritures disque (insert et
updates) se font beaucoup plus rapidement si tu as un accès disque de
qualité.

Donc une bonne machine classique, ca sera par exemple un Bi xéon ou dual
optéron, avec 4 Go de RAM ou plus et SCSI/RAID. Avec ce genre de serveur tu
ne sevrais pas avoir de soucis...

Salut,

Il est évident que la première chose à voir est la qualité des requêtes et
l'indexation associée, car cela peut avoir une influence faramineuse (x1000
ou d'avantage) sur les ressource consommées.
A coté, l'upgrade hardware te fera gagner du x2 ou x10, ça n'a pas grand
chose à voir !!!
Il y a aussi les problématiques de vérouillage qui ne se résoudront jamais
avec du matériel plus puissant.

Bref, tu peux te faire une petite idée en étant méthodique (ces
considérations sont TRES approximatives car on ne fait jamais du tuning en 5
minutes) :

1) Regarder la charge de ton serveur pour te faire une idée du l'influence
des problèmes de lock (si c'est du majoritairement du lock, il ne devrait pas
être trop chargé) :
- niveau CPU, quelle est ta moyenne de consommation : si c'est élevé, tu
dois avoir des problèmes de requêtes mal écrites / tables mal indexées, mais
a priori tu ne dois pas trop manquer de RAM (puisque CPU élevé = généralement
jointures lourdes en RAM) ...
- niveau Pagination, as-tu des pics ? Si oui, tu manques de RAM, tu peux
tenter de réduire la RAM allouée à certains programmes voire à SQLServer afin
de limiter le swap qui ruine les perfs (tu utilises + de RAM que tu en as).
- niveau Disque, ta file d'attente s'envole-t-elle ? Si oui, et que le CPU
n'est pas scotché, tu as soit des requêtes trop lourdes et tes tables ne
passent pas dans le buffer cache, soit des modifs (update/insert/delete) sont
lourdes/tro fréquentes et le sous-système disque sature. Voire les deux.
- niveau Réseau : ça me semble secondaire si tu ne brasse pas trop de
données entre tes clients et ton serveur.

2) Estimer le comportement de certaines de tes requêtes. Ton ami = le
Profiler (qui va tracer les requêtes envoyées au serveur). Tu le lances et tu
lui fais afficher tous les événements de requêtes "completed" (attention ça
peut être gros) : dans stored procedures, dans TSQL et dans Transactions. Tu
classes ça par READS, et tu laisses tourner un peu. Là si tu as des trucs
très moches, certaines requêtes, procs ou bouts de procs vont s'envoler en
nombre de reads, c'est là-dessus qu'il faudra que tu bosses (réécriture,
indexation) !!!
C'est assez basique comme première critère d'optim, mais ça permet en
général d'alléger les 10% de requêtes qui sont à l'origine de 90% de la
charge de ton serveur (problème classique) !

3) Pour le hardware, évidemment ça aide, mais vu que ça coute, mieux vaut
d'abord avoir au moins bien bossé sur les deux précédents points (surtout le
2).
Ensuite, un serveur dédié est toujours recommandé, cela facilite aussi le
troubleshooting.
Il est toujours préférable de mettre de l'argent dans le système disque et
dans la RAM, la différence de puissance processeur étant moins flagrante de
nos jours sur des "petites" applis (pas vrai évidemment pour des gros softs
!!!), les bipro actuels étant peu chers et assez performants (éviter le
monopro, car en cas de saturation CPU, c'est ingérable).
Pour le disque, il faut privilégier évidemment les systèmes RAID, si
possible avec une cache importante, et avoir plusieurs axes de disque
(séparation des I/O entre data, tolg, voire indexes, backups par exemple). Le
plus sensible pour les temps de réponse (si tu as assez de RAM) sera
forcément l'écriture dans les TLOG car elle est synchrone (prévoir du RAID 1
plutôt que du 5 pour ceux là si tu as les moyens).
Pour la RAM, si tu n'abuses pas des tris et des sous-requêtes (et autres
tables @), le tout est d'estimer la portion de ta base que tu manipules
souvent (données réellement vivantes). Cela te donnera une idée de ce qu'il
est utile d'acheter (une simple règle de trois). Pour 10 Go, je pense qu'à
partir de 4 Go de RAM tu dois être à l'aise sur une appli classique (entre la
moitié et les deux tiers de données très peu accédées).

Voilà, ces quelques conseils sont un peu caricaturaux, car le tuning c'est
du cas par cas et ça demande d'éviter d'avoir des a priori ...


Bon courage !

Guillaume.

"Manur37" a écrit :

J'expose brievement mon pb :

J'ai développé un back office de gestion de stock avec VB6 et SQL Serveur
2000. Il est installé sur un réseau dont on n'a pas la maintenance. SQL
Server est installé sur le controleur principal de domaine qui est en Windows
NT alors que les postes clients sont en 2000 pro.

Il y a environ 50 postes qui travaillent simultanement sur l'application
avec beaucoup d'accés à la base de données (récupération des stocks, des
infos d'articles lors de la saisie de BL, commandes, etc....).

La base de données fait environ 10 Go.

J'aimerais savoir quelle est la configuration idéale du serveur pour obtenir
des performances correctes car actuellement il y a beaucoup de pb et
j'envisage de demander à mon client d'investir dans un serveur consacré
uniquement à SQL.

Merci d'avance.

[Petit digression]

Contrairement au lieu commun (et aux benchmarks très marketing), le passage
32/64 bits en soi n'apporte pas grand chose en terme de perfs pures !!!!
Les différences de résultats de benchmarks sont principalement dûes à la
différence d'architecture processeur (P4 contre Itanium), les processeurs 32
bits étant une archi x86, et les 64 bits utilisés dans les benchs étant des
Itanium2 donc une architecture IA64 qui est foncièrement différente (ça n'est
pas une simple extension du 32 bits).

Ca m'avait fait bondir lors des démos Microsoft car la comparaison ne disait
rien en fait sur le passage 32 vers 64 bits en tant que tel (si ce n'est la
facilité d'allouer 64 Go de RAM sans passer par AWE) !!!
On sait qu'un Itanium 1,6 GHz équivaut à 2 Xéon 2.8 GHz en terme de
puissance brute, voir tous les benchmarks TPC-C, mais cela est du à son archi
EPIC qui est beaucoup plus évoluée que le CISC des processeurs x86 (d'où
d'ailleurs la fréquence beaucoup plus faible), cela indépendamment du débat
32/64 bits (manque de pot, l'Itanium n'est bon qu'en 64 bits [car émulation
en 32 bits] donc on n'a pas de possibilité de comparaison objective 32/64 sur
plate forme identique).

Mais le prix d'une plate forme Itanium n'est pas le même non plus, car cela
répond à des problématiques différentes (concentration ou partitionnement de
grosse machine) !

Bref, j'aimerais que l'on me montre un bench SQLServer 32 bits sur machine
Opteron sous W2K3 32 bits contre une version de la même machine sous W2K3 64
bits et SQLServer 64 bits.
Et là je vous parie que le gain (même s'il y en aura un car l'AMD64 est un
portage intelligent du x86 vers le 64 bits), sera de l'ordre de 10-20% au
mieux, contre les 100% des benchs irréalistes Xéon contre Itanium2.
Je n'ai pas de parti pris, je suis très favorable aussi bien aux Optérons
qu'aux Itanium, j'utilise les deux pour deux usages différents.

Le seul apport vraiment indiscutable du 64 bits est d'avantage la fin de la
limite des 3-4 Go adressables directement (hors PAE/AWE).

Comparons donc ce qui est comparable !!!

Guillaume.

cf. la douche froide concernant la "révolution" 64 bits que beaucoup trop de
gens espéraient un peu trop aveuglément (surtout avec un peu trop d'optimisme
!) :
http://www.x86-secret.com/index.php?option=newsd&nidƒ7

"Michel PRIORI" a écrit :

Vaste question

1 - Recommendation sur le matériel
1-1 CPU : le plus gros delta est visible entre mono et bi proc (un 4 proc va
tout de même plus vite !)
1-2 CPU : les bench en 64 bits sont éloquents
1-3 RAM : suffisament !!! à voir selon l'exploitation des données
1-4 Disque : Un disque physique dédié pour le fichier de log. Regarder de
très près le temps d'accès moyen (et la tolérance de panne)
1-5 réseau : suffisament !!!

2- A budget donné comment choisir ?
Louer une belle bécane.
Installer une virtualisation de serveur.
Rejouer des traces.
Modifier les parametres (CPU, RAM, ...) et recommencer

3- Verifier que le code n'est pas le principal soucis de lenteur !!!
Ceci est à faire en dernier car tout le monde sais alors ce qu'on a
économisé à ne pas passer au matériel au dessus.

"Manur37" a écrit :

> J'expose brievement mon pb :
>
> J'ai développé un back office de gestion de stock avec VB6 et SQL Serveur
> 2000. Il est installé sur un réseau dont on n'a pas la maintenance. SQL
> Server est installé sur le controleur principal de domaine qui est en Windows
> NT alors que les postes clients sont en 2000 pro.
>
> Il y a environ 50 postes qui travaillent simultanement sur l'application
> avec beaucoup d'accés à la base de données (récupération des stocks, des
> infos d'articles lors de la saisie de BL, commandes, etc....).
>
> La base de données fait environ 10 Go.
>
> J'aimerais savoir quelle est la configuration idéale du serveur pour obtenir
> des performances correctes car actuellement il y a beaucoup de pb et
> j'envisage de demander à mon client d'investir dans un serveur consacré
> uniquement à SQL.
>
> Merci d'avance.

En résumé :
1- Passer de 32 bits à 64 bits n'est pas un simple remplacement de proc
2- Les perfs sont meilleures en 64 bits (peu importe la raison)
3- infrastructure en 64 bit = cher

Je suis absolument d'accord avec toi Guillaume.


"GNocent" a écrit :

[Petit digression]

Contrairement au lieu commun (et aux benchmarks très marketing), le passage
32/64 bits en soi n'apporte pas grand chose en terme de perfs pures !!!!
Les différences de résultats de benchmarks sont principalement dûes à la
différence d'architecture processeur (P4 contre Itanium), les processeurs 32
bits étant une archi x86, et les 64 bits utilisés dans les benchs étant des
Itanium2 donc une architecture IA64 qui est foncièrement différente (ça n'est
pas une simple extension du 32 bits).

Ca m'avait fait bondir lors des démos Microsoft car la comparaison ne disait
rien en fait sur le passage 32 vers 64 bits en tant que tel (si ce n'est la
facilité d'allouer 64 Go de RAM sans passer par AWE) !!!
On sait qu'un Itanium 1,6 GHz équivaut à 2 Xéon 2.8 GHz en terme de
puissance brute, voir tous les benchmarks TPC-C, mais cela est du à son archi
EPIC qui est beaucoup plus évoluée que le CISC des processeurs x86 (d'où
d'ailleurs la fréquence beaucoup plus faible), cela indépendamment du débat
32/64 bits (manque de pot, l'Itanium n'est bon qu'en 64 bits [car émulation
en 32 bits] donc on n'a pas de possibilité de comparaison objective 32/64 sur
plate forme identique).

Mais le prix d'une plate forme Itanium n'est pas le même non plus, car cela
répond à des problématiques différentes (concentration ou partitionnement de
grosse machine) !

Bref, j'aimerais que l'on me montre un bench SQLServer 32 bits sur machine
Opteron sous W2K3 32 bits contre une version de la même machine sous W2K3 64
bits et SQLServer 64 bits.
Et là je vous parie que le gain (même s'il y en aura un car l'AMD64 est un
portage intelligent du x86 vers le 64 bits), sera de l'ordre de 10-20% au
mieux, contre les 100% des benchs irréalistes Xéon contre Itanium2.
Je n'ai pas de parti pris, je suis très favorable aussi bien aux Optérons
qu'aux Itanium, j'utilise les deux pour deux usages différents.

Le seul apport vraiment indiscutable du 64 bits est d'avantage la fin de la
limite des 3-4 Go adressables directement (hors PAE/AWE).

Comparons donc ce qui est comparable !!!

Guillaume.

cf. la douche froide concernant la "révolution" 64 bits que beaucoup trop de
gens espéraient un peu trop aveuglément (surtout avec un peu trop d'optimisme
!) :
http://www.x86-secret.com/index.php?option=newsd&nidƒ7

"Michel PRIORI" a écrit :

> Vaste question
>
> 1 - Recommendation sur le matériel
> 1-1 CPU : le plus gros delta est visible entre mono et bi proc (un 4 proc va
> tout de même plus vite !)
> 1-2 CPU : les bench en 64 bits sont éloquents
> 1-3 RAM : suffisament !!! à voir selon l'exploitation des données
> 1-4 Disque : Un disque physique dédié pour le fichier de log. Regarder de
> très près le temps d'accès moyen (et la tolérance de panne)
> 1-5 réseau : suffisament !!!
>
> 2- A budget donné comment choisir ?
> Louer une belle bécane.
> Installer une virtualisation de serveur.
> Rejouer des traces.
> Modifier les parametres (CPU, RAM, ...) et recommencer
>
> 3- Verifier que le code n'est pas le principal soucis de lenteur !!!
> Ceci est à faire en dernier car tout le monde sais alors ce qu'on a
> économisé à ne pas passer au matériel au dessus.
>
> "Manur37" a écrit :
>
> > J'expose brievement mon pb :
> >
> > J'ai développé un back office de gestion de stock avec VB6 et SQL Serveur
> > 2000. Il est installé sur un réseau dont on n'a pas la maintenance. SQL
> > Server est installé sur le controleur principal de domaine qui est en Windows
> > NT alors que les postes clients sont en 2000 pro.
> >
> > Il y a environ 50 postes qui travaillent simultanement sur l'application
> > avec beaucoup d'accés à la base de données (récupération des stocks, des
> > infos d'articles lors de la saisie de BL, commandes, etc....).
> >
> > La base de données fait environ 10 Go.
> >
> > J'aimerais savoir quelle est la configuration idéale du serveur pour obtenir
> > des performances correctes car actuellement il y a beaucoup de pb et
> > j'envisage de demander à mon client d'investir dans un serveur consacré
> > uniquement à SQL.
> >
> > Merci d'avance.

Enfin, je ne serais pas aussi catégorique malgré tout ! :-)
Avec de l'Opteron (AMD64) ou du Xéon récent (EMT64), tu peux avoir du 64
bits accessible !
Tu auras l'accès à plein de RAM, mais niveau perfs tu auras un gain faible,
si ce n'est une puissance unitaire de CPU intéressante, même face à de
l'Itanium (utile pour certaines bases à peu de clients et qui ne
parallélisent pas ou peu).
;-)

Just my 2 cents ...

Guillaume.

====================
"Michel PRIORI" a écrit :

En résumé :
1- Passer de 32 bits à 64 bits n'est pas un simple remplacement de proc
2- Les perfs sont meilleures en 64 bits (peu importe la raison)
3- infrastructure en 64 bit = cher

Je suis absolument d'accord avec toi Guillaume.


"GNocent" a écrit :

> [Petit digression]
>
> Contrairement au lieu commun (et aux benchmarks très marketing), le passage
> 32/64 bits en soi n'apporte pas grand chose en terme de perfs pures !!!!
> Les différences de résultats de benchmarks sont principalement dûes à la
> différence d'architecture processeur (P4 contre Itanium), les processeurs 32
> bits étant une archi x86, et les 64 bits utilisés dans les benchs étant des
> Itanium2 donc une architecture IA64 qui est foncièrement différente (ça n'est
> pas une simple extension du 32 bits).
>
> Ca m'avait fait bondir lors des démos Microsoft car la comparaison ne disait
> rien en fait sur le passage 32 vers 64 bits en tant que tel (si ce n'est la
> facilité d'allouer 64 Go de RAM sans passer par AWE) !!!
> On sait qu'un Itanium 1,6 GHz équivaut à 2 Xéon 2.8 GHz en terme de
> puissance brute, voir tous les benchmarks TPC-C, mais cela est du à son archi
> EPIC qui est beaucoup plus évoluée que le CISC des processeurs x86 (d'où
> d'ailleurs la fréquence beaucoup plus faible), cela indépendamment du débat
> 32/64 bits (manque de pot, l'Itanium n'est bon qu'en 64 bits [car émulation
> en 32 bits] donc on n'a pas de possibilité de comparaison objective 32/64 sur
> plate forme identique).
>
> Mais le prix d'une plate forme Itanium n'est pas le même non plus, car cela
> répond à des problématiques différentes (concentration ou partitionnement de
> grosse machine) !
>
> Bref, j'aimerais que l'on me montre un bench SQLServer 32 bits sur machine
> Opteron sous W2K3 32 bits contre une version de la même machine sous W2K3 64
> bits et SQLServer 64 bits.
> Et là je vous parie que le gain (même s'il y en aura un car l'AMD64 est un
> portage intelligent du x86 vers le 64 bits), sera de l'ordre de 10-20% au
> mieux, contre les 100% des benchs irréalistes Xéon contre Itanium2.
> Je n'ai pas de parti pris, je suis très favorable aussi bien aux Optérons
> qu'aux Itanium, j'utilise les deux pour deux usages différents.
>
> Le seul apport vraiment indiscutable du 64 bits est d'avantage la fin de la
> limite des 3-4 Go adressables directement (hors PAE/AWE).
>
> Comparons donc ce qui est comparable !!!
>
> Guillaume.
>
> cf. la douche froide concernant la "révolution" 64 bits que beaucoup trop de
> gens espéraient un peu trop aveuglément (surtout avec un peu trop d'optimisme
> !) :
> http://www.x86-secret.com/index.php?option=newsd&nidƒ7
>
> "Michel PRIORI" a écrit :
>
> > Vaste question
> >
> > 1 - Recommendation sur le matériel
> > 1-1 CPU : le plus gros delta est visible entre mono et bi proc (un 4 proc va
> > tout de même plus vite !)
> > 1-2 CPU : les bench en 64 bits sont éloquents
> > 1-3 RAM : suffisament !!! à voir selon l'exploitation des données
> > 1-4 Disque : Un disque physique dédié pour le fichier de log. Regarder de
> > très près le temps d'accès moyen (et la tolérance de panne)
> > 1-5 réseau : suffisament !!!
> >
> > 2- A budget donné comment choisir ?
> > Louer une belle bécane.
> > Installer une virtualisation de serveur.
> > Rejouer des traces.
> > Modifier les parametres (CPU, RAM, ...) et recommencer
> >
> > 3- Verifier que le code n'est pas le principal soucis de lenteur !!!
> > Ceci est à faire en dernier car tout le monde sais alors ce qu'on a
> > économisé à ne pas passer au matériel au dessus.
> >
> > "Manur37" a écrit :
> >
> > > J'expose brievement mon pb :
> > >
> > > J'ai développé un back office de gestion de stock avec VB6 et SQL Serveur
> > > 2000. Il est installé sur un réseau dont on n'a pas la maintenance. SQL
> > > Server est installé sur le controleur principal de domaine qui est en Windows
> > > NT alors que les postes clients sont en 2000 pro.
> > >
> > > Il y a environ 50 postes qui travaillent simultanement sur l'application
> > > avec beaucoup d'accés à la base de données (récupération des stocks, des
> > > infos d'articles lors de la saisie de BL, commandes, etc....).
> > >
> > > La base de données fait environ 10 Go.
> > >
> > > J'aimerais savoir quelle est la configuration idéale du serveur pour obtenir
> > > des performances correctes car actuellement il y a beaucoup de pb et
> > > j'envisage de demander à mon client d'investir dans un serveur consacré
> > > uniquement à SQL.
> > >
> > > Merci d'avance.

Bonjour,

Manur37 a écrit:

J'expose brievement mon pb :

J'ai développé un back office de gestion de stock avec VB6 et SQL Serveur
2000. Il est installé sur un réseau dont on n'a pas la maintenance. SQL
Server est installé sur le controleur principal de domaine qui est en Windows
NT alors que les postes clients sont en 2000 pro.

Il y a environ 50 postes qui travaillent simultanement sur l'application
avec beaucoup d'accés à la base de données (récupération des stocks, des
infos d'articles lors de la saisie de BL, commandes, etc....).

La base de données fait environ 10 Go.

J'aimerais savoir quelle est la configuration idéale du serveur pour obtenir
des performances correctes car actuellement il y a beaucoup de pb et
j'envisage de demander à mon client d'investir dans un serveur consacré
uniquement à SQL.

Il est certains que SQL Server gagnera à être placé sur un serveur dédié.

J'ai lu les divers commentaires faits sur ce forum.
Mais avant de parler serveur il est intéressant de noter que ce n'est pas, loin
s'en faut, le serveur qui est la cause essentielle et donc le remède à tous les
problèmes.

Après quelques années passées à réaliser des prestations d'audits de bases de
données SQL Server, mon constat est simple :
60 % des mauvaises performances viennent du modèle de données : types SQL et
collation inapropriée, non respect des formes normales, redondances, clefs mals
conçues, modèle peu fouillé...
20 % écriture des requêtes et indexation (requêtes peu performantes, manque
d'index, fragmentation des index...)
10 % code Serveur peu optimisé (pas de gestion efficace des transactions,
utilisation abusive de curseurs...)
Le reste se partage entre la configuration SQL Server, l'OS et le hardware.

Cependant et je tiens à attirer votre attention sur le fait qu'en ce qui
concerne le dimensionnement d'un serveur ce sont 2 points cruciaux qu'il faut
avoir à l'esprit :
1) la quantité de RAM => elle doit correspondre à la fenêtre de données au
minimum + celle pour SQL Server, les connexions et l'OS.
2) le type de disque et la façon dont sont créés les fichies de données.

Pour ce qui concerne le point 1, prenez conscience que si vous visez à terme
plus de 4 Go de RAM pour SQL Server, il faut d'ores et déjà prévoir une version
Entreprise de SQL Server et une version Entreprise de l'OS Windows 2003 Server.
Sinon vous serez condamné à terme à une migration. Or on ne change pas de
serveur aussi facilement. C'est pourquoi prendre les devants sur un bon
dimensionnement est esentiel.
En effet les versions standard de ces deux produits ne puvent aller au dela de 2
Go de RAM pour MS SQL Server.

Pour ce qui concerne le disque, sachez qu'en créant des fichiers de tailles fixe
et en les répartissant bien sur différentes grappes RAID bien configurées, vous
diminuerez par deux, trois ou plus les temps d'accès et d'écriture.
Mais pour cela il faut privilégier des disques de haute capacité
(surdimensionnement) et surtout la plus grande vitesse de rotation possible (18
rpm actuellement).

Je suis à votre disposition si vous voulez des informations complémentaires...

Merci d'avance.

--
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, formation, modélisation, optimisation : 06 11 86 40 66
********************* http://www.datasapiens.com ***********************