SQL Server : Problème « restart failed » lors de l’installation du Serveur SQL

Petite astuce pour contourner le bug qui peut apparaitre lors de l’installation d’un serveur SQL Server 2005 – 2008, au niveau du « restart failed » alors que nous avons déja redémarré le serveur.

=> Il faut modifier la registry windows de cette façon :

– Ouvrir REGEDIT
– Reperer la clé : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
– Renommer « PendingFileRenameOperations » en « PendingFileRenameOperations2 »
– Effectuer un « Rerun » sur l’installation de SQL Server pour vérifier que l’étape « restart computer » soit désormais valide.

Enjoy 😉

Mise en place de Performance Dashboard sur MS SQL 2005 & 2008

Performance Dashboard pour MS SQL Server est un outil permettant de générer un rapport personnalisé pour afficher des statistiques de performances précises (I/O , CPU, Wait , Recommandations d’index ..)

-> Il est gratuit d’utilisation et peut donc être installé sur une version Express.

Pour les versions 2005 & 2008 / 2008R2.

Attention : il faut savoir que performance Dashbaord est prévu d’origine pour les versions 2005. Pour les versions 2008 et 2008R2, une modification est nécessaire dans le script d’installation.

L’installation et utilisation :

–> Télécharger le programme depuis MS Technet :
http://www.microsoft.com/en-us/download/details.aspx?DisplayLang=en&id=22602

L’installer sur le serveur Windows concerné.

Pour les versions 2005 : Installation Standard.

=> Pour les versions supérieures : Choisir comme répertoire d’installation : « Program Files\Microsoft SQL Server\100\Tools\PerformanceDashboard » au lieu de « Program Files\Microsoft SQL Server\90\Tools\PerformanceDashboard »

Une fois l’installation terminée, Il faut créer les éléments en bases de données qui seront utilisés pour la génération du rapport (procédures, fonctions …)

Pour les versions 2005 :

-> Ouvrir SQL Management Studio, puis se connecter au moteur MSSQL.
-> Ouvrir l’éditeur de requête via le bouton « Nouvelle Requête » en haut à gauche.
-> Ouvrir le fichier « setup.sql » qui se trouve dans l’arborescence « Program Files\Microsoft SQL Server\90\Tools\PerformanceDashboard » (cliquer sur « Fichier » du menu standard puis sur – Ouvrir – Fichier)
-> Exécuter la requête.

Les objets sont maintenant crées, il est donc possible d’utiliser le rapport personnalisé.

Pour ce faire, sélectionner sur une base de données dans l’arborescence de l’explorateur d’objets, puis clique droit. Sélectionner alors l’option « Rapport » puis « Rapport Personnalisé ».

-> Aller dans le répertoire « Program Files\Microsoft SQL Server\90\Tools\PerformanceDashboard » puis sélectionner le fichier « performance_dashboard_main.rdl »

La génération du rapport est en cours, vous avez ainsi accès aux différentes informations de performances.

Pour les versions 2008 et 2008 R2 :

Les étapes sont quasiment les mêmes, sauf qu’il est nécessaire de modifier auparavant le fichier « setup.sql ». En effet, pour la table « sys.dm_os_sys_info« , une colonne a été retirée depuis la version 2008 : « cpu_ticks_in_ms »

-> il convient de retirer cette colonne et de la remplacer par la colonne « ms_ticks« .

Donc avant modifications :

create procedure MS_PerfDashboard.usp_Main_GetCPUHistory
as
begin
declare @ts_now bigint
select @ts_now = cpu_ticks / convert(float, cpu_ticks_in_ms) from sys.dm_os_sys_info


Après modifications :

create procedure MS_PerfDashboard.usp_Main_GetCPUHistory
as
begin
declare @ts_now bigint
select @ts_now = cpu_ticks / convert(float, ms_ticks) from sys.dm_os_sys_info


Par la suite, il suffit de lancer le setup.sql corrigé, puis de générer un rapport de la même façon que pour les versions 2005.

Recherche des index potentiels pour des tables

Requète permettant d’identifier les indexes qui seraient à mettre en place sur une ou plusieurs tables


SELECT sys.objects.name
, (avg_total_user_cost * avg_user_impact) * (user_seeks + user_scans) AS Impact
, 'CREATE NONCLUSTERED INDEX ix_IndexName ON ' + sys.objects.name COLLATE DATABASE_DEFAULT + ' ( ' + IsNull(mid.equality_columns, '') + CASE WHEN mid.inequality_columns IS NULL
THEN ''
ELSE CASE WHEN mid.equality_columns IS NULL
THEN ''
ELSE ',' END + mid.inequality_columns END + ' ) ' + CASE WHEN mid.included_columns IS NULL
THEN ''
ELSE 'INCLUDE (' + mid.included_columns + ')' END + ';' AS CreateIndexStatement
, mid.equality_columns
, mid.inequality_columns
, mid.included_columns
FROM sys.dm_db_missing_index_group_stats AS migs
INNER JOIN sys.dm_db_missing_index_groups AS mig ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details AS mid ON mig.index_handle = mid.index_handle AND mid.database_id = DB_ID()
INNER JOIN sys.objects WITH (nolock) ON mid.OBJECT_ID = sys.objects.OBJECT_ID
WHERE (migs.group_handle IN
(
SELECT TOP (500) group_handle
FROM sys.dm_db_missing_index_group_stats WITH (nolock)
ORDER BY (avg_total_user_cost * avg_user_impact) * (user_seeks + user_scans) DESC))
AND OBJECTPROPERTY(sys.objects.OBJECT_ID, 'isusertable')=1
ORDER BY 2 DESC , 3 DESC


Requète pour identifier les index fragmentés

Requète pour connaitre les index fragmentés d’une base SQL Server.

Fonctionne à partir de MS SQL server 2005.


USE [MYBASE]
FO
select object_name(Stat.object_id) AS NomObjet,
Ix.Name as NomIndex,
Stat.partition_number AS NoPartition,
Stat.avg_fragmentation_in_percent AS CoeffFragmentation
from
sys.dm_db_index_physical_stats (DB_ID(), null, null , null, 'LIMITED') Stat
inner join sys.indexes Ix
on Stat.object_id = Ix.object_id AND
Stat.index_id = Ix.index_id
where
Stat.avg_fragmentation_in_percent > 10.0 AND
Stat.index_id > 0;
GO


Définition Journal Log et maintenance

La limitation de la taille du fichier de transaction peut s’avérer un remède pire que le mal : il peut entraîner le blocage du serveur.
De même un fichier de transaction ridiculement petit entrainera des performances notablement dégradées. Inversement, une grande taille n’affecte pas les performances du fait qu’il est écrit en séquentiel.
En principe un journal des transactions doit être capable de recevoir les écritures de transaction d’au moins une période de temps donné (heure, journée, semaine…) avant sauvegarde. Pour obtenir des performances, sa taille minimale doit donc être basée sur la moyenne de remplissage de ce laps de temps.

Le journal de transactions est l’espace dans lequel SQL Server consigne toutes les transactions, c’est-à-dire toutes les modifications effectuées dans la base de données. Le journal de transactions est constitué, à la création de la base de données, d’un fichier portant l’extension par défaut LDF.

Or il est possible d’avoir un nombre de fichiers supérieur pour le journal de transactions (la limite théorique étant de 32 767 fichiers par base de données, quel que soit le type de fichier). Mais cela en vaut-il la peine ?

Tout est dans le fonctionnement du journal de transactions. Le journal de transactions est rempli de manière séquentielle, parce que tout simplement il faut garantir l’ordre des transactions.

Que se passerait-il si on vous débitait une somme avant de vous en créditer une autre et que l’on vous réclamait les intérêts associés ? Si l’on supprimait une ligne avant de la modifier ? L’ordre des transactions est un facteur déterminant dans les bases de données relationnelles, c’est pour cela que les écritures se font de manière séquentielle. Le fait d’avoir un remplissage séquentiel permet aussi de maximiser les performances en écriture.

Ajouter un nouveau fichier LDF au journal de transactions, ne change rien à la donne. En effet, SQL Server va continuer à remplir le premier fichier LDF et ne considérera le second que lorsque le premier est à court d’espace. Soit, parce qu’il est limité en taille, et que la taille maximale est atteinte soit, parce que le disque qui supporte le fichier est à court d’espace disque.

Au final, c’est là que réside le seul et unique intérêt d’ajouter un fichier (ou plus) au journal de transactions de SQL Server. En effet, en cas de manque d’espace sur le disque supportant le journal de transactions, ajouter un fichier LDF sur un second disque (le temps de résoudre le problème de manière plus pérenne) permet de gagner un peu de temps, et d’éviter que la base de données ne refuse toute écriture parce qu’il n’y a plus d’espace dans le journal de transactions.

L’ajout d’un fichier supplémentaire ne permet pas d’améliorer les performances, car SQL Server ne l’utilisera qu’une fois le premier rempli. Par contre en cas de problème de remplissage du premier fichier l’ajout d’un second permet de sursoir au problème d’espace disque.

Attention, du côté des fichiers des données (MDF / NDF), le problème est totalement différent… Mais ceci est une autre histoire