Inutile de vous rappeler que les contraintes sont indispensables pour préserver l’intégrité des données. Mais celles-ci jouent un autre rôle indispensable pour l’optimiseur de requêtes. En effet pour pouvoir générer un plan d’exécution, celui-ci prend en compte ces contraintes. Le fait qu’une contrainte soit désactivée ou « non fiable » fait qu’elle n’est plus prise en compte par l’optimiseur et par conséquent peut influencer sur les performances. Nous verrons dans ce billet quelques cas concrets.
Archives mensuelles : mars 2010
Audit des autogrow de fichiers de bases de données avec SQL Server
Il y a quelques jours on m’a posé la question suivante : Est il possible d’être prévenu par mail lorsqu’une extension automatique de fichiers se produit sur une de nos bases de production avec SQL Server 2005 ? La réponse est oui et je monterais dans ce billet qu’il existe au moins deux approches pour réaliser cela. Ceci est également valable pour SQL Server 2008.
Histoire d’index : Parcours d’index sur SQL Server
Nous avons vu dans un précédent billet que les index gérés sous SQL Server étaient des arbres B-Tree. Nous verrons aujourd’hui comment SQL Server parcourt ces arbres en interne pour retrouver les informations recherchés lors des requêtes et ceci pour chaque type d’index.
Organisation physique des lignes de données d’une table HEAP et d’une table avec index cluster
Si vous êtes administrateur de bases de données SQL Server vous connaissez certainement les tables HEAP (Tables ne possédant pas d’index cluster) et à contrario les tables possédant un index cluster. Savez vous seulement comment sont organisées les lignes d’une de ces tables dans les pages de données ? La plupart de la documentation que j’ai pu voir dit qu’une table possédant un index cluster voit ses lignes de données ordonnées physiquement selon la définition de ce même index cluster.. Est ce vraiment le cas ? Je vous propose dans ce billet une tentative de réponse .
Utiliser WMIC pour connaître le nombre physiques de processeurs avant l’installation de SQL Server
Avec les nouvelles architectures multicoeurs des processeurs actuels il est devenu difficile depuis le système d’exploitation de connaître l’architecture physique des processeurs d’un serveur. Le gestionnaire de périphérique de Windows nous offre une vue logique de l’architecture processeur qui peut être trompeuse. Par exemple lorsque celui-ci affiche 4 CPU rien ne dit à priori que nous avons à faire à 4 processeurs physiques ou 2 processeurs physiques dual-core. Quelques fois il arrive que la description donnée au processeur peut nous mettre sur la voie mais ce n’est pas toujours le cas. Il existe également des outils tiers qui permettent de donner précisément ces informations comme ceux fournis par sysinternals mais encore faut il les avoir sous la main ou qu’il soit permis de les utiliser sur les serveurs d’un client par exemple. Heureusement Windows, au moyen des WMI permettent de retrouver rapidement cette information. Je pars du principe que SQL Server n’est pas encore installé auquel cas nous aurions pu utiliser la DMV sys.dm_os_sys_info pour retrouver cette information.
Histoire d’index : Importance du choix d’un index cluster avec SQL Server
Le choix d’un index cluster est important pour une table de données. Des bonnes pratiques existent et permettent d’orienter ce choix. Dans ce billet je tenterais d’en expliquer la raison tout en expliquant le fonctionnement interne de ces index et les conséquences d’une mauvaise stratégie de ce type d’indexation. Je ne prétends pas donner la liste exhaustive des bonnes pratiques sur ce point mais d’en donner une première analyse
Auditer l’espace physique et utile de l’ensemble des fichiers d’une base de données
Une des tâches d’un administrateur de bases de données consiste à surveiller la taille des données dans un fichier d’une ou plusieurs bases de données. Un fichier de données dimensionné pour une durée d’exploitation conséquente contient de l’espace inutilisé. Dans ce cas là comment surveiller l’évolution des données à l’intérieur de ce fichier ? Un script proposé par Elsuket permet de surveiller les fichiers d’une base de données en particulier. Le code qui suit est une évolution du précédent : vous pouvez auditer l’ensemble des fichiers d’une base de données.