Developpez.com
Accueil
SQL Server 2008 propose une nouvelle fonctionnalité apportée à la fonction CONVERT() qui va faciliter la vie des développeurs concernant la conversion des nombres hexadécimaux en entier.
Une de mes tâches du moment est de pouvoir justifier ou non d’une éventuelle extension de disques sur le SAN en fonction de l’évolution du volume des données des bases. Cela peut se faire de plusieurs façons mais une méthode simple est de se baser sur l’historique des sauvegardes complètes des bases qui sont vraiment représentatives des données réelles qu’elles hébergent.
Lors d’un audit de serveur, il est parfois utile de visualiser rapidement le planning d’exécution des jobs SQL Server. Si les jobs sont peu nombreux, il est simple d’aller voir directement dans les propriétés des jobs depuis la console SSMS mais lorsque le nombre de jobs augmente et devient important cette manipulation devient très facilement fastidieuse.
Récemment un internaute s’est étonné de voir que lorsqu’il réalisait une opération de réduction de fichier à l’aide de la commande DBCC SHRINFILE après une sauvegarde du journal des transactions, celui-ci ne se réduisait pas à la 1ère tentative. Une seconde opération de journal était nécessaire avant de pouvoir réduire le fichier à la taille désirée. Quelle en est la cause ? Nous allons pouvoir y répondre en utilisation la commande DBCC LOGINFO.
Il m’est arrivé de réaliser en urgence une réduction de fichiers suite à un manque de place sur le sous système de disque qui hébergeait la base de données. L’opération était anormalement longue et je me suis posé 2 questions : Y’a t’il un problème avec la réduction de fichiers et comment le vérifier ?. La vue dynamique sys.dm_exec_requests permet de réaliser cette tâche.
Une des problématiques que rencontre mon client lors de releases de son application principale est de s’assurer qu’aucun utilisateur ne soit connecté pendant la fenêtre de mise à jour de ces bases de données ceci afin de garantir qu’aucune perturbation ne soit créée pendant l’application de ces mises à jour. L’utilisation des points de terminaison ou ENDPOINT de SQL Server peut s’avérer bien utile dans ce cas.
Il n’y pas longtemps sur le forum msdn, un internaute rencontrait un problème de performance concernant une vue partitionnée qu’il avait mis en place. Lorsqu’il interrogeait sa vue selon un critère bien précis, l’ensemble des tables de la vue étaient concernées au lieu d’une seule comme il le prévoyait. Nous allons voir pourquoi.
Ce billet est purement informatif. Je vous propose de vous expliquer brièvement la la façon dont le moteur SQL alloue les pages de données lors d’une insertion d’enregistrements dans une table. Comme vous le savez sans doute une base de données est une collection de pages de 8 Ko réparties sur un ou plusieurs fichiers physiques. Une page peut donc contenir plusieurs lignes d’une table selon le cas . Les commandes DBCC EXTENTINFO et sp_spacused nous aideront à comprendre ce mécanisme d’allocation.
Il peut être intéressant de vérifier si les sauvegardes les plus récentes sont bien présentes sur le système de fichier. Des fichiers de sauvegarde peuvent être déplacés ou supprimés en raison d’un manque de place disque par exemple. Cela permet donc d’anticiper et d’éviter de se retrouver piéger si vous devez effectuer une restauration en urgence en se posant la question : Mais où sont mes sauvegardes ?
Un des avantages des triggers DDL est de permettre la prévention contre tout changement non désiré. Après avoir eu une discussion avec Elsuket, nous nous sommes demandé comment empêcher la désactivation d’un trigger DML par la commande DISABLE TRIGGER.
© 2000-2020 - www.developpez.com
Partenaire : Hébergement Web
