L’autre jour en regardant les index non cluster existants d’une table de l’ERP Microsoft bien connu NAVISION, je me suis aperçu que tous étaient composés de leurs colonnes de clé respectives plus la colonne de table qui composait la clé primaire. Je me suis donc posé la question de savoir si les données de cette colonne étaient dupliquées dans ces index, ce qui pourrait avoir en plus un impact sur la quantité de stockage supplémentaire et nécessaire pour héberger cette duplication d’informations . Nous verrons dans ce billet à travers un exemple très simple qu’il n’en est rien…
Archives pour la catégorie Architecture
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
Connaître les types de pages gérées par SQL Server
Pour bien commencer cette nouvelle 2010, j’ai envie de commencer par un billet concernant les types de pages que l’on peut rencontrer sur SQL Server. Depuis quelques temps, je m’intéresse beaucoup au fonctionnement interne de SQL Server. Etant amateur de voiture, je ferais une brève analogie. Il n’est pas indispensable de connaître en détail le fonctionnement d’une voiture pour pouvoir la conduire. Cependant si vous êtes passionné ou tout simplement curieux, vous aurez envie un jour ou l’autre de soulever le capot… Il en va de même pour SQL Server. Administrer SQL Server ne demande pas de connaître précisément le comportement interne du moteur. Cependant « maîtriser » le fonctionnement des processus internes du moteur ne peut qu’aider dans la maîtrise et le perfectionnement dans l’administration et la conception des bases de données avec SQL Server. J’en suis intimement convaincu. Dans ce billet je commencerais par aborder le thème suivant : Les types de pages que gèrent SQL Server. Nous verrons par la même occasion les différentes commandes permettant d’en visualiser le détail des pages comme DBCC PAGE, DBCC IND ou DBCC EXTENTINFO .
Comprendre le fonctionnement des snapshots avec SQL Server
Il est possible depuis SQL Server 2005 de créer des captures instantanées de base de données. Cependant je me suis aperçu que cette fonctionnalité était plutôt méconnue. Dans ce billet, j’essaierais d’expliquer au mieux le fonctionnent des captures instantanées et d’exposer les avantages et les inconvénients quant à leur utilisation.
Fonctionnement et utilisation des options de boot /3GB et /PAE avec SQL Server
Après avoir effectué des audits sur 2 serveurs de bases de données chez mon client, j’ai constaté qu’il y avait quelques confusions concernant les options bien connus /3GB et /PAE qui permettent d’étendre la mémoire vue et utilisée par le système d’exploitation et les applications. Les questions qui reviennent souvent sont les suivantes : Quand utiliser l’option /3GB ? Quand utiliser l’option /PAE ? Peux t’on utiliser les 2 options en même temps ? Nous allons y répondre .
Recréer un mappage rompu entre un compte de connexion SQL Server avec l’authentifcation Windows et un utilisateur de bases de données
Vous avez déjà sans doute eu le cas où un administrateur système par mégarde, a supprimé un compte Windows utilisé par votre serveur SQL et qui est mappé à un ou plusieurs utilisateurs de vos bases de données . Vous avez sans doute maudit ce pauvre et malchanceux administrateur système car le problème dans ce cas est que le nouveau compte Windows recréé avec les mêmes paramètres ne possèdent pas le même SID et que le mappage avec les différents utilisateurs de bases de données existants est rompu. La question évidente ici est comment allons nous faire pour pouvoir revenir à une situation normale ?
Comprendre les enregistrements fantômes (Ghost records) avec SQL Server
En utilisant la vue dynamique système sys.dm_db_index_physical_stats, vous avez sans doute remarqué la présence d’une colonne ghost_record_count que je traduirais par nombre d’enregistrement fantômes. Cette colonne est incrémentée à chaque fois qu’un enregistrement est supprimé d’une table comportant au moins un index.