Un collègue m’a demandé il y a quelques temps, quelle était la différence entre un index non cluster classique et un index non cluster avec colonnes incluses ? Cette question est venue suite à la création de ce type d’index (avec colonnes incluses) pour couvrir certaines colonnes demandées par une requête et éviter ainsi une recherche par pointeur sur l’index cluster qui pouvait être contre performant dans ce cas car elle concernait une table très volumineuse. Dans ce billet, on verra quelle est la différence entre ces deux types d’index et comment SQL Server stocke en interne les index avec colonnes incluses.
Archives pour la catégorie Architecture
Histoire de stockage : Stockage interne d’une ligne de données avec SQL Server (part 1)
Le dump d’une page de données SQL Server est plutôt indigeste à lire lorsqu’il s’agit de lire les lignes de données présentes dans la page. Je me suis amusé à regarder s’il était possible de pouvoir déchiffrer cet agglomérat de valeurs hexadécimales. Avec de la documentation et un peu d’entrainement on y arrive et on apprend tout un tas de choses surprenantes.
SQL Server PowerShell : Récupérer la volumétrie globale des serveurs SQL
Un collègue qui est chargé de rationnaliser les processus d’entreprises autour des serveurs de bases de données m’a demandé s’il était possible de connaître la volumétrie de chaque serveur SQL Server en terme d’espace disque et la volumétrie globale de l’ensemble de ces serveurs. L’idée ici est d’avoir une idée de la volumétrie d’espace disque pour chaque technologie de bases de données (SQL Server et Oracle notamment). Je vous propose ici un script PowerShell permettant de réaliser cette tâche.
SQL Server PowerShell : Comment récupérer rapidement les informations générales d’une liste de serveurs
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 !!
SQL Server PowerShell : Activer désactiver certains protocoles SQL Server
Sur certaines éditions de SQL Server, l’activation du protocole TCPIP requiert une action manuelle. Voici un script powershell qui peut être intégré à une installation automatique et qui active le protocole TCPIP d’une part et désactive les canaux nommés d’autre part.
Histoire de sauvegarde : Le mode de récupération BULK LOGGED
Le mode de récupération BULK LOGGED n’est pas le mode le plus utilisé avec SQL Server. Ce mode est pratique lorsqu’il s’agit de journaliser au minimum certains traitements ou certaines opérations de maintenance comme les reconstructions d’index par exemple. Ces opérations ont tendance à augmenter de façon importante la taille du journal des transactions. Dans ce billet j’expliquerai les processus internes lorsque ce mode de récupération est utilisé.
Histoire de journal : Session de récupération et fonctionnement interne
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.
Histoire de journal : Pourquoi est il important d’arrêter une base proprement pour pouvoir attacher correctement une base de données
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.
Histoire de journal : Les différentes phases d’exécution d’une session de récupération avec SQL Server
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.
Histoire de journal : Doit on obligatoirement exécuter une sauvegarde complète après le passage du mode récupération SIMPLE à FULL ?
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 ?