Developpez.com
Accueil
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
© 2000-2020 - www.developpez.com
Partenaire : Hébergement Web
