Scripts et guides SQL Server®, prêts à l'emploi.

Les requêtes ad hoc, envoyées en texte par les applications ou les outils, sont souvent à l'origine d'un pic de processeur. Ce script les classe par coût et les regroupe par empreinte (query_hash) pour retrouver la requête réelle derrière des dizaines de variantes.

Quand le code applicatif passe par des procédures stockées, la vue des statistiques de procédures donne le coût réel de chaque objet, instance entière ou base par base. C'est souvent le premier endroit où chercher l'origine d'une lenteur.

Un index jamais lu ne sert à rien, mais il coûte : espace disque, temps de sauvegarde, et surtout mise à jour à chaque écriture dans la table. Ce script les repère, avec leur taille et le nombre de mises à jour qu'ils subissent.

Entre l'index jamais lu et l'index indispensable, il y a ceux qui coûtent plus qu'ils ne rapportent : très mis à jour, rarement lus. Ce script les isole grâce à deux seuils que vous réglez selon l'activité de votre base.

Un index qui n'est jamais utilisé en recherche (seek) mais seulement parcouru en entier (scan) n'apporte pas le bénéfice attendu d'un index. Il sert peut-être de simple réservoir de colonnes, ou ses colonnes clés ne correspondent pas aux filtres des requêtes.

SQL Server ne crée pas automatiquement d'index sur les colonnes d'une clé étrangère. Sans index, les suppressions ou modifications dans la table parente provoquent des parcours complets de la table enfant, et des verrous prolongés. Ce script recense les clés étrangères et indique si chacune est indexée.

SQL Server mémorise, à chaque compilation de plan, les index qui auraient réduit le coût d'une requête. Ces suggestions sont précieuses, mais brutes : elles se chevauchent et ne tiennent pas compte des index existants. Les regrouper par table permet de les arbitrer.

Des statistiques périmées conduisent l'optimiseur à de mauvaises estimations, donc à de mauvais plans. Ce script indique, pour chaque statistique, quand elle a été calculée, sur quel échantillon, et combien de lignes ont été modifiées depuis.

Dans un groupe de disponibilité, les sauvegardes peuvent être faites sur le réplica principal ou sur un secondaire : l'historique de chaque réplica ne contient que ses propres sauvegardes. Pour savoir si une base est protégée, il faut regarder tous les réplicas.

Un fichier qui grossit souvent par petits incréments ralentit la base et fragmente le disque. Ces scripts donnent la taille et l'espace libre de chaque fichier, puis listent les extensions automatiques récentes, avec leur durée et la session qui les a déclenchées.

Le journal d'erreurs de SQL Server (ERRORLOG) est découpé en plusieurs fichiers, recyclés à chaque redémarrage du service. L'incident que vous cherchez est peut-être dans une archive. Ce script parcourt tous les fichiers disponibles et regroupe le résultat.

Erreur 823, base SUSPECT, DBCC CHECKDB qui signale des erreurs : la panique pousse à lancer la première commande de réparation venue. C'est souvent ainsi que des données récupérables sont perdues. Voici la marche à suivre.

Une requête qui allait bien hier est lente aujourd'hui. Avant de toucher à quoi que ce soit, il faut savoir où le temps est perdu : à calculer, à lire ou à attendre. Voici la démarche et les causes les plus courantes.

Un fichier journal (.ldf) qui occupe tout le disque est l'un des incidents SQL Server les plus fréquents. La cause relève presque toujours de la même famille : quelque chose empêche la réutilisation du journal. Il faut trouver quoi, avant de réduire le fichier.

tempdb est partagée par toutes les bases et toutes les sessions. Quand elle sature, tout le monde en pâtit : erreurs d'espace, requêtes qui échouent, lenteurs généralisées. Il faut comprendre ce qui la consomme.

Les événements étendus (XEvents) ont remplacé SQL Profiler : plus légers, plus précis, et exploitables en production. Voici comment construire une session, puis des exemples de filtres sur une table, une base, une opération ou une application.

Deux serveurs, une base répliquée en continu et un basculement automatique : c'est la configuration de haute disponibilité la plus courante. Voici les étapes, du cluster Windows au test de basculement, avec les pièges qui reviennent en intervention.

Comptes applicatifs, comptes de maintenance, compte sa : un mot de passe faible ou réutilisé sur une instance SQL Server est une porte ouverte. Voici comment les générer, les poser sans casser les applications et auditer l'existant.

Une connexion refusée alors que tout est correct vient souvent d'une règle de pare-feu qui ne connaît pas votre adresse IP. Voici comment la trouver, l'autoriser proprement et la retirer ensuite.

« L'application est figée » : dans la moitié des cas, une session attend un verrou détenu par une autre. Voici comment identifier la session fautive, comprendre ce qu'elle tient, et agir sans aggraver la situation.

« Transaction was deadlocked on lock resources and has been chosen as the deadlock victim » : l'erreur 1205 interrompt une requête sans prévenir. Voici comment retrouver chaque interblocage, le lire et le supprimer.

Par défaut, SQL Server fait attendre les lecteurs derrière les écrivains. Le versionnement de lignes supprime l'essentiel de ces blocages : les lecteurs lisent une version validée au lieu d'attendre. Voici comment activer RCSI sur une base, passer une transaction en SNAPSHOT, et ce que cela coûte.

Des mots de passe complexes, longueur et jeux de caractères au choix, génération locale. Gratuit, sans publicité.

Votre adresse IP publique en un clic, utile pour autoriser un accès dans un pare-feu. Gratuit, sans publicité.