SQL SERVER 101 : Concepts essentiels pour administrateurs Windows

Pour mettre en place un système SQL Server, il faut commencer par bien dimensionner la mémoire. En effet, les systèmes base de données se nourrissent de RAM, et SQL Server ne fait pas exception. Le minimum doit être de 512 Mo pour un système départemental. Pour de plus grands systèmes, il en faudra beaucoup plus. Compte tenu du prix actuel de la RAM, il est facile d’ajouter de 1 à 2 Go de RAM à votre système SQL Server sans assécher le budget. L’investissement d’aujourd’hui en RAM supplémentaire peut éviter de futurs problèmes de performances qui coûteront très cher en temps d’immobilisation et donc en perte de productivité.

Microsoft a voulu que SQL Server 2000 soit facile à installer et à exécuter. On pourrait même dire que l’installation est un peu trop facile. Ainsi, en acceptant les paramètres par défaut proposés au moment de l’installation, vous aurez un système médiocrement performant. Par défaut, l’installation de SQL Server crée les fichiers log et les fichiers de données de la base de données sur le même lecteur. Or, votre système SQL Server sera bien plus à l’aise si ces fichiers se trouvent sur des lecteurs différents. Par conséquent, la première chose à faire après avoir installé SQL Server, est de mettre vos fichiers de données et vos fichiers log sur des lecteurs différents. Bien entendu, pour cela, il faut que le système SQL Server ait suffisamment de lecteurs. Vous aurez vérifié ce point au préalable. Au minimum, il faut trois lecteurs : un pour l’OS, un pour les fichiers de données et un pour les fichiers log (fichiers de journalisation). La figure 1 montre une configuration de lecteurs classique pour une installation de SQL Server en PME. Dans cet exemple de système à huit lecteurs, l’OS, les fichiers de données et les fichiers log sont tous sur des lecteurs séparés et les fichiers OS et log utilisent le mode miroir pour assurer la redondance des données. Les fichiers de données utilisent RAID 5 (data striping ou segmentation des données) pour obtenir un stockage plus efficace. Pour obtenir une protection des données maximale, vous pourriez utiliser à la place RAID 1 (mirroring) pour vos lecteurs de données. Mais cette solution est beaucoup plus chère que RAID 5 parce que le mirroring demande deux fois plus d’espace disque que vous n’en utilisez actuellement, pour permettre la duplication des lecteurs en miroir. Les lecteurs SCSI surclassent les lecteurs IDE et, en bonne logique, les lecteurs plus rapides sont aussi plus performants.

Pour une meilleure récupération, songez à appliquer le mode miroir aux fichiers log. Une configuration classique d’installation de SQL Server consiste à utiliser RAID 1 pour les volumes disque qui contiennent des fichiers, et RAID 5 pour ceux qui contiennent des fichiers de données. Vous pouvez y ajouter un autre lecteur consacré aux traces ou autres opérations de diagnostic. Enfin, pour soigner la performance et la sécurité, il vaut mieux installer SQL Server sur un serveur membre, pas sur un DC (domain controller).

Le type d’authentification souhaité est la prochaine considération importante dans la mise en place d’un système SQL Server. SQL Server accepte deux types d’authentification : l’authentification Windows et l’authentification SQL Server (dite aussi mode mixte). Sous l’authentification Windows, SQL Server vérifie les références de login entrante par rapport aux comptes utilisateur Windows. Sous l’authentification SQL Server, vous devez créer et maintenir un jeu séparé de logins dans SQL Server. Bien que chacun de ces deux types ait ses avantages et ses inconvénients, l’authentification Windows sera généralement préférable, si on peut l’appliquer. Elle vous permet de ne maintenir qu’un jeu de mots de passe, et les applications qui se connectent au système SQL Server n’ont pas besoin de transmettre l’information de login dans la chaîne de connexion. Windows maintient toutes les références de login. Enfin, quoique vous fassiez, il faut absolument donner un mot de passe puissant au compte sa. Beaucoup d’attaques dirigées contre SQL Server sont expressément conçues pour profiter d’un compte sa sans mot de passe. Ne laissez pas le mot de passe sa vierge et n’utilisez pas non plus des valeurs faciles à deviner comme sa ou motdepasse.