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 SQL
Connaître les classes d’événements et les colonnes gérées par une trace SQL Profiler côté serveur
Il peut être utile de connaître en détail les événements et les colonnes gérées par une trace profiler. La vue système sys.traces permet de lister l’ensemble des traces existantes sur un serveur de bases de données sans en donner le détail. Cependant Il existe une fonction très pratique et quelques vues systèmes qui permettent de récupérer les informations nécessaires à notre besoin.
Contraintes SQL et influence sur les performances
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.
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.
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.
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 .