Catégories: Architecture, PowerShell

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.

» Lire la suite!

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.

» Lire la suite!

Il y a peu de temps j'ai dû effectué un audit sur un ensemble de serveurs SQL. Autant vous dire que j'ai essayé d'optimiser certaines tâches comme la récupération de certaines données générales du serveur comme les processeurs, la mémoire, les disques et le système d'exploitation. Voici un script Powershell qui permet de récupérer ces informations rapidement !!

» Lire la suite!

Dans un précédent billet nous avons parlé des différentes phases d'une session de récupération avec SQL Server. Maintenant nous regardons plus en détail le fonctionnement interne des pages de données et du journal des transactions d'une base de données lorsqu'une mise à jour est effectuée sur les données d'une table.

» Lire la suite!

Je vois de temps en temps des processus de sauvegarde de bases de données en entreprise qui arrêtent le serveur SQL pour sauvegarder les fichiers de bases de données (fichiers de données et des journaux de transactions). Cependant cette méthode est à proscrire. Dans ce billet j'expliquerais quelles en sont les raisons.

» Lire la suite!

Vous vous levez, vous commencez le travail par une belle journée et tout va bien. Cependant une coupure électrique provoque l'extinction brusque d'un de vos serveurs de bases de données (et l'onduleur il ne fonctionne pas ??? !!). Votre serveur SQL redémarre et tout rentre dans l'ordre, les bases de données sont à nouveau en ligne et les pertes de données sont minimes . ouf !!! Cependant ne vous êtes vous jamais demandé comment SQL Server pouvait revenir à un état stable après une coupure aussi brusque ? C'est ce que nous allons voir dans ce billet.

» Lire la suite!

Le passage du mode de récupération de FULL à SIMPLE est une méthode souvent utilisée lorsqu'une mise à jour majeure d'une application est effectuée. Des scripts SQL sont lancés lors des ces mises à jour sur la base de données et le mode de récupération SIMPLE permet de réaliser deux choses : contrôler plus ou moins l'accroissement du journal des transactions et augmenter ou du moins ne pas détériorer le temps d'exécution des scripts SQL (le mode de récupération SIMPLE permet une journalisation moindre par rapport au mode de récupération FULL). Mais le fait de passer en mode SIMPLE rompt la chaîne de séquence des LSN ce qui signifie que les sauvegardes du journal ne pourront plus se faire correctement. Pour pouvoir reprendre cette séquence correctement le passage en mode de récupération FULL suivie d'une sauvegarde est obligatoire.  La sauvegarde la plus communément utilisée que j'ai pu voir est une sauvegarde complète. Mais doit on réellement effectuer ce type de sauvegarde pour reprendre cette chaîne de séquence ?

» Lire la suite!

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...

» Lire la suite!

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 .

» Lire la suite!