Comment déterminer le taux de données ayant changées

Posted by Yukon on 22. August 2011 15:29

La commande DBCC PAGE (non documentée) peut être utilisée si vous désirez avoir une idée de la quantité de données qui change dans votre base de données. Sa syntaxe est la suivante: DBCC PAGE ({‘dbname’|dbid}, filenum, pagenum [, printopt={0|1|2|3} ]) Avant de commencer, vous avez besoin d’identifier les valeurs des paramètres filenum et pagenum ; c'est-à-dire identifier les pages contenant la page bitmap différentielle. Pour ce faire exécutez la commande suivante (exemple sur la base exemple AdventureWorks): DBCC PAGE (AdventureWorks,1,0,3) Vous obtenez ce le resultat ci-dessous : Comme vous pouvez le constater sur la figure ci-dessus, la première page de bitmap différentielle (differential bitmap page) est la page 6 du premier fichier dans la base de données, donc son ID est (1 :6). La valeur dans la colonne VALUE indique qu’il y a eu un changement depuis la dernière sauvegarde différentielle. Vous pouvez donc exécuter la commande DBCC PAGE avec valeurs 1, 6 et 3 respectivement pour filenum, pagenum et printopt. DBCC PAGE (AdventureWorks,1,6,3) WITH TABLERESULTS, NO_INFOMSGS Vous obtenez ainsi le resultat suivant:La colonne ParentObjects affiche DIFF_MAP pour toutes les extensions couvertes par ce GAM. La colonne Field affiche les pages groupées dans les extensions, et la colonne VALUE indique si les extensions ont changées ou pas. Partant de là, vous pouvez calculer le taux de données ayant changées et ainsi estimer la taille de votre sauvegarde différentielle.L’utilisation de la commande DBCC PAGE vous permettra de calculer le pourcentage de modification effectuée sur votre base de données et ainsi décider de la politique de sauvegarde à mettre en œuvre : « Backup FULL ou Backup DIFF ». Paul Randal dans son blog « New script: How much of the database has changed since the last full backup » fournit le script d’une procédure stockée permettant d’éffectuer cette opération.

Convertir une configuration Log Shipping vers le Database Mirroring

Posted by Yukon on 2. August 2011 16:09

Il peut être parfois intéressant, voire avantageux de convertir une installation log shipping vers du database mirroring, car ce dernier fournit les avantages suivants par rapport au log shipping : Pas de perte de données (mode synchrone) Basculement automatique possible (mode synchrone avec témoin) Par contre, il ne faut pas perdre de vue certaines contraintes imposées par le database mirroring : Le Database Mirroring nécessite une base de donnée en mode de récupération FULL, alors que le log shipping fonctionne avec des bases en mode BULK_LOGGED ou FULL Log Shipping a peu ou pas d’impact sur la performance des applications sur le serveur principal. En effet, le database mirroring peu éventuellement impacter la performance des applications si ce dernier gère un volume important de « log » générée. Ainsi, il est possible de convertir une installation log shipping vers du database mirroring sans effectuer une sauvegarde complète suivie d’une restauration sur la base mirroir.La procédure ci-dessous décrit les grandes étapes de mise œuvre de la conversion d’une configuration log shipping vers le database mirroring ; Cette approche peut être utilisée dans le cas où vous disposez d’une configuration Log Shipping entre deux serveurs SRV1 (primaire) et SRV2 (secondaire). Votre objectif étant de minimiser la durée d’indisponibilité de la plateforme pendant une phase de maintenance planifiée sur le serveur primaire ; Une première solution est de basculer la base de donnée du serveur SRV1 vers le secondaire, mais l’application ne basculera pas automatiquement et la durée d’indisponibilité peut s’étaler sur plusieurs minutes. Une approche alternative serait : De convertir la configuration log shipping en database mirroring (mode synchrone) en suivant les étapes décrites dans la section « mise en œuvre ». Effectuer un basculement manuel de la base de données du principal vers le miroir. Ainsi l’ancien miroir devient le serveur principal et l’application peut se reconnecter automatiquement au nouveau principal et continuer à fonctionner. Une fois l’opération de maintenance terminée, vous pouvez rebasculer vers le serveur principal original. Supprimez ensuite la configuration du database mirroring Réinitialisez le log shipping. Mise en œuvre S’assurer du bon fonctionnement du log shipping entre les serveurs SRV1 et SRV2 (SRV1 en principal et SRV2 en secondaire) : vérifiez l’état des jobs backup, copy et restore dans l’historique des jobs SQL Agent. Vérifiez aussi que la base secondaire est dans l’état NORECOVERY, et non en STANDBY. Configurez les différentes étapes du database mirroring : securité, endpoints, privilèges, etc… Sur SRV1, désactivez le job de backup log. Attendez que tous les backups de log soient copiés et restaurés sur le serveur secondaire. (Vous pouvez également exécuter manuellement le job de copie et ensuite le job de restauration sur le serveur secondaire ; ce qui permettra de gagner près de 15 minutes). Une fois la copie et la restauration effectuées sur le serveur secondaire, désactivez les jobs correspondants sur ce dernier. Activez maintenant le database mirroring entre les deux serveurs, avec SRV2 comme miroir et SRV1 comme le principal. Modifiez manuellement l’option safety level si vous souhaitez passer en mode asynchrone (car synchrone par défaut). Supprimez la configuration log shipping entre SRV1 et SRV2 Enjoy !  

SQL Server Buffer Pool et Buffer Cache Hit Ratio

Posted by Yukon on 1. August 2011 12:59

On a souvent tendance à confondre SQL Server Buffer Cache et Buffer Cache Hit Ratio. Cet article a pour objectif de présenter brièvement la différence entre les deux éléments.SQL Server Buffer Cache ?Le buffer cache est un espace du buffer pool (ou cache de données) qui maintient en mémoire vive autant qu’il est possible de page de données et d’index. La lecture à partir de la RAM étant environ mille fois plus rapide que sur le disque dur, on en comprend l’intérêt. En effet, ce cache est géré par un composant de SQLOS nommé buffer manager, dont le travail est la lecture des pages du disque vers le buffer, et l’écriture des pages modifiées du buffer vers le disque.Buffer Cache Hit Ratio ?Le buffer cache hit ratio (ou taux d’accès au cache des tampons) est le rapport du nombre de pages lues en RAM par rapport au nombre de pages lues à partir des disques. Il s’exprime en pourcentage et plus la valeur de ce pourcentage est élevé, meilleures sont les performances. Dans les meilleures conditions de performance, le buffer cache hit ration doit être supérieur au égal à 90%. Dans la pratique, il est possible d’utiliser le moniteur de performance Windows (PerfMon) pour déterminer la valeur du buffer cache hit ratio ou. Start > Programs > Administrative Tools > Reliability and Performance Monitor Clique-droit sur le graphe de Performance Monitor puis choisir Add Counters Sélectionner l’objet SQL Server :Buffer Manager Ajouter, Buffer Cache Hit Ratio   La valeur de Buffer Cache Hit Ratio peut être obtenue à partir de la requête suivante: SELECT CAST( ( SELECT CAST (cntr_value AS BIGINT) FROM sys.dm_os_performance_counters WHERE counter_name = 'Buffer cache hit ratio' )* 100.00 / ( SELECT CAST (cntr_value AS BIGINT) FROM sys.dm_os_performance_counters WHERE counter_name = 'Buffer cache hit ratio base' ) AS NUMERIC(6,3) )  Pour connaitre les détails sur l’utilisation mémoire (RAM) des serveurs SQL Server, vous pouvez exécuter la commande DBCC suivante : DBCC MEMORYSTATUS;