Au travers de mes derniers audits, j’ai remarqué qu’il y avait visiblement un manque d’informations auprès des clients quant à l’utilisation du verrouillage des pages en mémoire pour les architectures SQL Server en 64 bits. En effet à la base seule les éditions Entreprises prenaient en charge ce type paramétrage. Depuis SQL Server 2005 SP3 CU4 et SQL Server 2008 SP1 CU2 les éditions Standard prennent maintenant en charge le verrouillage de pages en mémoires. C’est également le cas de SQL Server 2008 R2.
Archives pour la catégorie Architecture
SQL Cluster 2008 / 2008 R2 : Pré installation des objets de cluster dans l’active directory
L’installation de base d’un cluster SQL Server 2008 avec Windows 2008 R2 se passe relativement bien dans des environnements dit « classiques ». Cependant il arrive quelques fois où l’on se trouve dans des contextes bien plus spécifiques qui ne permettent pas, par exemple, les mises à jour dynamiques des enregistrements DNS ou encore pour lesquels il existe des GPO qui peuvent interférer au bon déroulement de l’installation du cluster Windows ou SQL Server. On peut même se retrouver dans une situation où la politique d’entreprise fait que l’on interdise la création dynamique des objets dans l’AD. Dans ce cas il n’est pas rare de se retrouver avec l’événement portant l’ID 1194 pendant l’installation du cluster SQL dû principalement à un problème de droit sur la création ou le paramétrage des objets de cluster. La solution est donc de pré installer ces objets et de configurer la sécurité associée.
Histoire de stockage : Suppression complète des données d’une table et comportement interne du stockage
La suppression des données d’une table peut se réaliser de 2 manières : à l’aide de l’instruction DELETE ou encore TRUNCATE. Ces dernières n’ont pas la même incidence en interne sur le stockage. Il faut également compter avec la structure de la table concernée. En effet une table peut posséder un index ou non. Nous couvrirons dans ce blog les différents comportements qu’il est possible de rencontrer.
Visualiser les pages physiques lues par le moteur de stockage avec les évènements étendues
Voici une façon rigolote (ou non) de visualiser les pages lues par le moteur de stockage lors de l’exécution d’une requête par l’intermédiaire des X Events ou évènements étendues. Ceci m’a permis de comprendre et de vérifier le comportement du moteur de stockage lors d’un index scan (avec lecture anticipée).
Mise à jour des statistiques avec échantillonnage (WITH SAMPLE) sur les tables à faible volumétrie
Comme vous le savez certainement la mise à jour des statistiques peut s’effectuer de différentes manières. Une d’entre elle est d’utiliser la commande UPDATE STATISTICS avec l’option WITH SAMPLE qui permet de mettre à jour les statistiques selon une méthode d’échantillonnage en prenant en compte un certain nombre de lignes ou en se basant sur un certain pourcentage. Cette méthode est très utilisée dans les VLDB avec des tables volumineuses. Cependant quelle est le comportement de cette option sur les tables à faible volumétrie ?
Index Scan et Allocation Order Scans : Quesaco ?
Les opérations d’analyses d’un index (opérations logiques) peuvent engendrer 2 types d’opérations physiques appelés : Index Scans ou les Allocation Order Scans pour reprendre les termes anglophones. Chaque type d’opération est exécuté dans un contexte bien précis. C’est le moteur de stockage SQL Server qui décide de la stratégie à employer. Nous verrons cela dans un exemple très simple.
Histoire de stockage : colonnes sparses avec SQL Server 2008
Les colonnes fragmentées ou SPARSE sont apparues avec la version 2008 de SQL Server. Celles-ci permettent d’optimiser le stockage pour les tables ayant une majorité de colonnes avec une absence de valeurs (NULL). Cependant ce type de colonne n’est réellement efficace que si une table possède une majorité de valeurs NULL pour les colonnes concernées. Pourquoi une telle condition ? C’est ce que nous verrons dans ce billet.
SQLProfiler : Analyse avancée de traces
La création d’une trace profiler est un passage quasi obligatoire lorsqu’il s’agit d’auditer les performances et les ressources monopolisées des requêtes, lots de requêtes ou des procédures stockées qui s’exécutent sur le serveur de bases de données lors d’un audit. Bien qu’il existe les DMV depuis la version 2005, celles-ci ne peuvent être réellement utilisées qu’après une période significative de fonctionnement du serveur. Par conséquent il est plus intéressant de les utiliser dans un contexte de production que dans celui d’un audit ponctuel.
De plus, il peut exister plusieurs exécutions d’une même requête ou procédure dans une trace profiler mais avec des paramètres différents. Une question peut alors se poser : comment connaître les durées et consommations globales des différents modèles de requêtes (indépendamment de la valeur des paramètres utilisés) et pouvoir ainsi mettre l’accent sur l’optimisation de certains modèles de requêtes ?
Lors de mon dernier audit, j’ai également dû répondre à la problématique suivante : le serveur de bases de données comportait plusieurs instances SQL Server. Dans un tel cas, comment connaitre le ratio entre la consommation d’une requête exécutée sur une instance et celle de l’ensemble des instances présentes sur ce même serveur ? Cela peut être utile pour cibler les requêtes ou procédures les plus consommatrices à l’échelle du serveur et pour lesquelles il est utile de revoir la conception.
Le script suivant permet de répondre aux deux problématiques décrites ci-dessus.
Histoire de journal : Fichiers multiples et journal des transactions
Dans la plupart des cas, une base de données comporte un seul fichier journal. Il peut arriver qu’il soit nécessaire de rajouter un ou plusieurs fichiers au journal des transactions à cause d’un manque d’espace libre sur une partition par exemple. Comment se remplit le journal dans ce cas ? Comment s’effectue l’allocation de nouveaux VLF dans plusieurs fichiers ? C’est ce que nous verrons dans ce billet.
Log shipping : Comment déplacer les fichiers journaux d’une base de données ?
Il est parfois nécessaire de déplacer certains fichiers journaux d’une base de données. Les causes peuvent être multiples : changement dans l’architecture du sous-système disque, espace disque insuffisant . Cette opération est, dans un cas classique, relativement simple mais lorsqu’il s’agit d’une topologie log-shipping cela peut compliquer un peu les choses. Nous verrons dans ce billet comment déplacer les fichiers journaux d’une base de données selon si l’on se trouve sur le primaire ou le secondaire.