Les index filtrés ont été introduit à partir de la version SQL Server 2008. Il existe déjà un certain nombre d’exemples qui illustrent leur intérêt et je vous invite à les regarder si cela n’est déjà fait (voir le billet d’Elsuket). Mais qu’en est il du stockage ? En effet la question peut sembler légitime car les index filtrés ne comportent que les lignes de données qui correspondant à sa définition. Nous verrons comment SQL Server gère ces index en interne.
Archives pour la catégorie SQL
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.
Etudier l’activité I/O des fichiers de bases de données
Durant mes audits, j’ai vu un certain nombre de fois où le(s) sous système(s) disque(s) étai(en)t une des causes principales de problèmes de performances. J’ai eu quelques fois à refaire le plan de répartition des fichiers de bases de données ainsi que l’architecture disque sous jacente qui n’était pas optimale. Pour pouvoir réaliser cette tâche, il est préférable de connaître les caractéristiques d’entrées / sorties appliquées aux fichiers de bases de données et implicitement au(x) sous système(s) disque(s) qui les hébergent. Le script suivant permet 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 ?