Parmi les options de configuration  d’une base de données on trouve le mode de récupération qui peut être Complet (Full), Journalisé en bloc (Bulk-Logged) ou Simple (Simple).

Si le mode de récupération d’une base de données est différent du mode Simple, il faut impérativement mettre en place une stratégie de sauvegarde des fichiers journaux de cette base de données sinon les fichiers log n’arrêteront par de croitre et consommer de l’espace disque.

Au cas où vous avez oublié de mettre en place cette stratégie et que votre disque commence à souffrir il faut impérativement réduire la taille des fichiers journaux volumineux, cet article décrit l’ensemble des actions à entreprendre pour réaliser cette action.

Identifier le nom logique d’un fichier Log d’une base de données

Pour identifier le nom logique d’un fichier journal d’une base de données nommée Demo il suffit d’exécuter la requête suivante :

SELECT DB_NAME(database_id) AS [Base de données],name AS [Nom Logique] ,
physical_name AS [Nom Physique]  FROM sys.master_files  
WHERE DB_NAME(database_id) = 'Demo' AND type = 1

Noter le nom qui apparaît au niveau de la colonne Nom Logique

Sauvegarder la base de données et le fichier Log

Avant de procéder à la réduction de la taille du fichier log et afin de sécuriser l’opération il faut procéder à une sauvegarde de la base de données et du fichier journal pour pouvoir la récupérer en cas de problème.

Pour cela il suffit d’exécuter les scripts suivants :

BACKUP DATABASE [Demo]
TO  DISK = N'F:\Backup\Demo.BAK'
WITH NOFORMAT, NOINIT, 
NAME = N'Demo-Full Database Backup',
SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

BACKUP LOG [Demo]
TO  DISK = N'F:\Backup\Demo.bak'
WITH NOFORMAT, NOINIT, 
NAME = N'Demo-Transaction Log  Backup',
SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

Réduire la taille du fichier log de la base de données

On peut réduire la taille du fichier log en exécutant le script SQL Suivant

USE [Demo]
GO
DBCC SHRINKFILE (N'Demo_log' , 0, TRUNCATEONLY)
GO

Ou

En utilisant SQL Server Management Studio et en cliquant avec le bouton droit sur la base de données en question puis  sur Tasks ==> Shrink ==> Files

Au niveau de la fenêtre Shrink file – Demo.log :

1. Vérifier que le type de fichier est bien Log
2. Cocher la case Reduce unused space
3. Cliquer sur Ok

Si la taille du fichier Log n’est pas réduite suite à cette opération chose qui peut survenir si la fin du fichier log est considérée par SQL Server comme portion active non réductible, on peut forcer l’opération de réduction en changeant le mode de récupération de la base de données vers le mode simple, exécuter l’opération de troncature une autre fois et ensuite remettre le mode de récupération de la base de données au mode Complet (Full).

Pour changer le mode de récupération de la base vers le mode Simple exécuter le script suivant :

USE [master]
GO
ALTER DATABASE [Demo] SET RECOVERY SIMPLE WITH NO_WAIT
GO

Pour remettre le mode de récupération à Complet exécuter le script suivant :

USE [master]
GO
ALTER DATABASE [Demo] SET RECOVERY FULL WITH NO_WAIT
GO

Au niveau du script de la troncature on peut choisir la taille cible que doit prendre notre fichier log en utilisant la syntaxe suivante :

USE [Demo]
GO
DBCC SHRINKFILE (N'Demo_log' , <Taille Cible en MB>)
GO

Une vulnérabilité dans la sécurité d'Excel Services pour Microsoft Office SharePoint Server 2007 peut permettre à un code arbitraire de s'exécuter lors de l'ouverture sur le serveur d'un fichier qui a été modifié à des fins malintentionnées.

Une mise à jour de sécurité vient d’être publié le 05 mars 2010 afin de remédier à cette vulnérabilité.

La mise à jour est disponible en téléchargement en version 32 Bit et 64 Bit et elle concerne seulement les serveurs SharePoint 2007 sur les quels Excel Services est installé.

Pour de plus amples détail consulter le Bulletin de Sécurité MS10-017.

La nouvelle version de SharePoint “SharePoint 2010” qui sera disponible au cours de l’année 2010 ne sera supportée que sur une gamme de serveurs Windows bien déterminée.

Ainsi et afin de bien préparer vos déploiements il faudra prendre en considération les points suivants:

• SharePoint 2010 sera seulement disponible pour les architectures 64 Bit.
• SharePoint 2010 n’est pas supporté sur des installations Core de Windows Server 2008 ou Windows Server 2008 R2
• Pour le développement SharePoint 2010 sera supporté uniquement sur Windows Vista x64 avec SP2 et Windows 7 x64
• Les éditions de Windows supportées pour une installation de SharePoint 2010 sont :
  1. Windows Server 2008 R2 Standard, Enterprise et Datacenter
  2. Windows Server 2008 x64 Standard, Enterprise et Datacenter
  3. Windows Small Business Server 2008 x64
  4. Windows Essential Business Server 2008 x64        

Symptômes

Après avoir installer MOSS 2007 et créer des applications Web et des sites  vous n’arrivez pas à explorer vos sites avec leurs noms d’hôtes sur le serveur MOSS lui même, par contre ils sont bien accessibles depuis n’importe quel autre serveur ou poste client.

Lorsque vous tapez l’adresse de votre site on vous demande de s’authentifier 3 fois de suite et vous recevez une page vierge au niveau de l’explorateur.

Pas de messages d’erreur enregistrés à l’exception du journal de sécurité qui présente une série d’événements 4625: An Account Failed to Logon

Ce comportement se manifeste sur le serveur Web lui même et ne concerne que les sites ayant des noms d’hôte.

Cause

Depuis le service pack 1 de Windows Server 2003 une fonctionnalité de sécurité a été intégré au système d’exploitation (LoopBack Check) afin d’empêcher les attaques par réflexion sur les serveurs Web.

Cette fonctionnalité provoque un échec d’authentification pour toute demande portant un nom d’hôte qui ne ne correspond pas au nom de la machine.       

Résolution

Pour remédier à ce problème on dispose de deux méthodes:

Méthode 1 : Désactiver la fonctionnalité LoopBack Check

• Ajouter une valeur DWORD nommée DisableLoopBackCheck ayant une valeur 1 à la clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

•   Redémarrer le service d’administration d’IIS

Méthode 2 : Spécifier les noms d’hôtes en question

• Ajouter une valeur Multi-String nommée BackConnectionHostNames  à la clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 et y tapez les noms d’hôtes de tous les sites dont l’authentification est Windows et qui présentent le problème.       

• Redémarrer le service d’administration d’IIS

Réflexion

Avant de passer à l’action il faut se poser la question si on considère ce comportement problématique ou non puisque les sites sont bien accessibles de n’importe quel serveur ou poste client et seulement inaccessibles depuis le serveur Web lui même.

Il faut bien avoir cette réflexion puisque la résolution de ce “faux” problème consiste à désactiver la fonctionnalité LoopBack Check ce qui constitue en lui même l’exposition du serveur à un risque de sécurité.

Parmi les deux méthodes de résolution la deuxième semble comme même plus adaptée étant données qu’elle nous permet de spécifier les sites pour les quels la fonctionnalité sera désactivée et qui peuvent être les sites les plus sécurisés de point de vue fonctionnalités et utilisation, ce qui nous permettra de minimiser l’exposition du serveur à ce genre de risques de sécurité.

Avant de procéder à la mise à niveau de vos systèmes d’exploitation il faudra vérifier la compatibilité des applications serveur avec Windows 2008 R2.

1. SQL Server
   1. SQL Server 2005 Service Pack 3 et plus
   2. SQL Server 2008 Service Pack 1 et plus
   3. SQL Server 2005 Express Edition Service Pack 2
   4. SQL Server 2008 Express RTM
   5. SQL Server 2008 R2 sera supporté H1 2010

1. Exchange
   1. Exchange 2010 version est supporté depuis Q4 2009

1. Office Servers
   1. Forms Server 2007 Service Pack 2 et plus
   2. Groove Server 2007 Service Pack 2 et plus
   3. PerformancePoint Server 2007 Service Pack 2 et plus sera supporté Q1 2010
   4. Project Server 2007 Service Pack 2 et plus
   5. SharePoint Server 2007 Service Pack 2 et plus
   6. Search Server 2008 Service Pack 2 et plus
   7. Search Server 2008 Express Service Pack 2 et plus

Pour la liste complète des applications voir Microsoft Server Applications Supported on Windows Server 2008 R2

Introduction

Lors de la création d’une base de données SQL Server 2008 on peut choisir le mode de récupération à appliquer pour cette base de données. Ce choix ne doit pas être fait au hasard mais il doit répondre aux besoins de l’entreprise en termes de stratégie de sauvegarde et de récupération.

Types de sauvegardes

SQL Server 2008 offre une multitude de types de sauvegarde pour une base de données sauf que ces types de sauvegarde dépendent du mode de récupération choisi pour celle-ci.

Les types de sauvegarde qu’on peut réaliser sur une base de données sont :

1. Sauvegarde de données
2. Sauvegarde des journaux de transactions
3. Sauvegarde de type copie seule

L’étendu d’une sauvegarde peut être soit une base de données complète, une base de données partielle ou un ensemble de fichiers ou groupes de fichiers. Pour chacun de ces étendues on peut faire soit des sauvegardes complètes soit des sauvegardes différentielles.

Une sauvegarde différentielle dépend de la dernière sauvegarde complète réalisée avant celle-ci, la perte de la sauvegarde complète implique la perte de toutes les sauvegardes différentielles réalisées après.

Chaque sauvegarde de base de données contient la portion du journal de transaction qui permet de remettre la base de données à la fin de l’opération de sauvegarde.

Une sauvegarde de type copie seule (Copy Only) nous permet de réaliser des sauvegardes sans affecter la stratégie de sauvegarde mise en place, ce qui veut dire qu’une sauvegarde en copie seule même si c’est une sauvegarde complète n’affecte pas le chainage entre les sauvegardes différentielles réalisées après celle-ci et la sauvegarde complète normale réalisée avant elle.

Mode de récupération

Si le mode de récupération d’une base de données est Simple, la sauvegarde des journaux de transaction est désactivée pour celle-ci, en effet SQL Server prendra en charge la gestion des fichiers journaux et à chaque point de contrôle les parties inactives du journal seront tronquées.

Le mode de récupération Journalisé en bloc est un mode complémentaire au mode complet qui permet d’optimiser les opérations en bloc mais n’offre pas le même niveau de protection que le mode complet, en effet ce mode ne prend pas en charge la récupération de la base de données à une date et heure précise.

Meilleures pratiques

• Choisir le mode de récupération Simple pour les bases de données de développement et de test
• Si votre base de données est configurée avec un mode de récupération complet ou journalisé en bloc il ne faut pas oublier de réaliser des sauvegardes des journaux de transaction.
• Une sauvegarde différentielle d’une base de données contient toutes les pages de données modifiées depuis la dernière sauvegarde complète, sans la sauvegarde complète de référence une sauvegarde différentielle ne peut pas être restaurée ; dans le cas où on met en place une stratégie de sauvegarde à base de sauvegarde complète et différentielles il faut bien faire attention à ne pas perdre la sauvegarde complète.
• L’application d’une mise à jour ou d’un patch de sécurité qui change le numéro de version de votre serveur SQL doit être suivi immédiatement d’une sauvegarde des bases de données système, en fait les anciennes sauvegardes seront obsolètes dans ce cas.

L’optimisation des performances des serveurs SQL Server passe obligatoirement par la mise en place d’une infrastructure de stockage adéquate. Les consignes suivantes permettent d’améliorer les performances de vos serveurs de bases de données SQL Server.

1. Placer les fichiers de données, les fichiers journaux et la base de données TempDB sur des disques dédiés
2. Aligner les partitions de vos disques (Windows Server 2003 et antérieurs)
3. Aligner le nombre de fichiers de données de vos bases de données et principalement la base de données TempDB au nombre de processeurs du serveur.
4. Formater les disques qui hébergent les fichiers de données avec une taille de cluster adéquate (8, 16, 32 ou 64 Ko), le choix de la taille doit se faire suite à une analyse et des tests qui prendront en compte le contexte d’exploitation de votre base de données et les caractéristiques techniques de votre équipement de stockage.
5. Favoriser les systèmes RAID 1+0 pour les disques qui hébergeront les journaux de transaction et la base de données TempDB
6. Planifier convenablement la taille des fichiers de données, des fichiers journaux ainsi que la taille des fichiers de la base de données TempDB.

Si une base de données est configurée en mode de récupération complet, son journal de transaction ne sera tronqué que suite à la sauvegarde de celui-ci. La réalisation d’un grand nombre de transactions volumineuse peut augmenter indéfiniment la taille du journal des transactions ce qui impliquera un suivi permanent et une charge administratif en plus.

Avec les alertes et les travaux SQL Server on peut automatiser les tâches de sauvegarde du journal de transactions afin d’éviter que le disque hébergeant le journal ne soit rempli.

Pour cela il faudra procéder comme suit :

Créer une unité de sauvegarde

Depuis l’explorateur des objets, développer Server Objects puis cliquer avec le bouton droit de la souris sur Backup Devices et cliquer sur New Backup Device.

Donnez un nom et préciser le chemin du fichier à utiliser pour votre unité de sauvegarde

Cliquer sur Ok

Créer un opérateur pour recevoir les notifications

Créez un opérateur en cliquant sur New Operator

Précisez le nom de l’opérateur, son adresse email si vous voulez utiliser la notification par messagerie électronique et le nom de sa machine en cas de notification par message console.

Cliquer sur Ok

Créer un travail de sauvegarde du journal de transaction

Créer un nouveau Travail en cliquant sur New Job…

Au niveau de l’onglet Général tapez le nom du travail et ensuite passez à l’onglet Etapes.

Créer une étape de Type Script Transact-SQL (T-SQL) avec le script BACKUP LOG NomBase TO BackupDevice avec BackupDevice le nom de l’unité de sauvegarde crée auparavant.

Au niveau de l’onglet Notification choisissez l’opérateur qui doit recevoir une notification et quand.

Créer une alerte relative au compteur de performance (Pourcentage du journal utilisé)

Créez une alerte en cliquant sur New Alerte

Au niveau de l’onglet Général donner un nom à votre alerte de type Alerte de condition de performance SQL Server et configurez la comme illustré au niveau de l’image

Au niveau de l’onglet Réponse choisissez l’exécution du Job de sauvegarde comme réponse et cochez le mode de notification à utiliser.

La configuration de cette alerte qui déclenche le travail de sauvegarde permettra d’éviter que les disques soient remplis et que les journaux de transactions ne grandissent indéfiniment.