Developpez.com
Accueil
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.
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.
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.
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 ?
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…
Il peut être utile de connaître en détail les événements et les colonnes gérées par une trace profiler. La vue système sys.traces permet de lister l’ensemble des traces existantes sur un serveur de bases de données sans en donner le détail. Cependant Il existe une fonction très pratique et quelques vues systèmes qui permettent de récupérer les informations nécessaires à notre besoin.
Les nominations MVP sont tombés ce 1er avril 2010. Je suis à l’occasion devenu MVP SQL Server !!
Je profite donc de ce petit moment pour remercier l’ensemble des personnes qui ont contribué à l’obtention de ce titre de près ou de loin. Je remercie tout particulièrement l’équipe Developpez.com, Elsuket, Fadace, Dje, Waldar, SQLPro avec lesquels j’ai pu échanger autour de SQLServer et SQL et je tiens également à remercier SQLPro et Rudib pour le parrainage 
David BARBARIN (Mikedavem)
Elève ingénieur CNAM Lyon
Inutile de vous rappeler que les contraintes sont indispensables pour préserver l’intégrité des données. Mais celles-ci jouent un autre rôle indispensable pour l’optimiseur de requêtes. En effet pour pouvoir générer un plan d’exécution, celui-ci prend en compte ces contraintes. Le fait qu’une contrainte soit désactivée ou « non fiable » fait qu’elle n’est plus prise en compte par l’optimiseur et par conséquent peut influencer sur les performances. Nous verrons dans ce billet quelques cas concrets.
Il y a quelques jours on m’a posé la question suivante : Est il possible d’être prévenu par mail lorsqu’une extension automatique de fichiers se produit sur une de nos bases de production avec SQL Server 2005 ? La réponse est oui et je monterais dans ce billet qu’il existe au moins deux approches pour réaliser cela. Ceci est également valable pour SQL Server 2008.
Nous avons vu dans un précédent billet que les index gérés sous SQL Server étaient des arbres B-Tree. Nous verrons aujourd’hui comment SQL Server parcourt ces arbres en interne pour retrouver les informations recherchés lors des requêtes et ceci pour chaque type d’index.
© 2000-2020 - www.developpez.com
Partenaire : Hébergement Web
