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.
Archives pour la catégorie SQL Server 2005
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 ?
Histoire d’index : Gestion des colonnes communes d’un index non cluster et d’un index cluster
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…
Connaître les classes d’événements et les colonnes gérées par une trace SQL Profiler côté serveur
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.
Nomination MVP SQL Server
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
Contraintes SQL et influence sur les performances
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.
Audit des autogrow de fichiers de bases de données avec SQL Server
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.
Histoire d’index : Parcours d’index sur SQL Server
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.
Organisation physique des lignes de données d’une table HEAP et d’une table avec index cluster
Si vous êtes administrateur de bases de données SQL Server vous connaissez certainement les tables HEAP (Tables ne possédant pas d’index cluster) et à contrario les tables possédant un index cluster. Savez vous seulement comment sont organisées les lignes d’une de ces tables dans les pages de données ? La plupart de la documentation que j’ai pu voir dit qu’une table possédant un index cluster voit ses lignes de données ordonnées physiquement selon la définition de ce même index cluster.. Est ce vraiment le cas ? Je vous propose dans ce billet une tentative de réponse .
Utiliser WMIC pour connaître le nombre physiques de processeurs avant l’installation de SQL Server
Avec les nouvelles architectures multicoeurs des processeurs actuels il est devenu difficile depuis le système d’exploitation de connaître l’architecture physique des processeurs d’un serveur. Le gestionnaire de périphérique de Windows nous offre une vue logique de l’architecture processeur qui peut être trompeuse. Par exemple lorsque celui-ci affiche 4 CPU rien ne dit à priori que nous avons à faire à 4 processeurs physiques ou 2 processeurs physiques dual-core. Quelques fois il arrive que la description donnée au processeur peut nous mettre sur la voie mais ce n’est pas toujours le cas. Il existe également des outils tiers qui permettent de donner précisément ces informations comme ceux fournis par sysinternals mais encore faut il les avoir sous la main ou qu’il soit permis de les utiliser sur les serveurs d’un client par exemple. Heureusement Windows, au moyen des WMI permettent de retrouver rapidement cette information. Je pars du principe que SQL Server n’est pas encore installé auquel cas nous aurions pu utiliser la DMV sys.dm_os_sys_info pour retrouver cette information.