 TechNet Magazine March 2007
TechNet Magazine March 2007
MARCH 2007
SQL Server

OPTIMISATION DE SQL SERVER

C'est le mois SQL Server à Technet Magazine. Dans ce numéro, vous approfondirez vos connaissances de SQL Server pour une utilisation optimale. Vous apprendrez à maintenir des index propres et intègres pour permettre à SQL Server d'exécuter les requêtes en un tournemain et de mettre toutes les informations dont vous avez besoin à portée de main.

Vous verrez comment les clusters SQL Server peuvent fournir la redondance et améliorer la disponibilité. Vous découvrirez également ce que signifie haute disponibilité dans votre environnement, et les moyens d'y parvenir. Enfin, vous verrez comment mettre fin une fois pour toutes au dilemme du partitionnement de table.

Administration de Windows

Et n'oubliez pas ! Mark Russinovich est de retour ce mois-ci avec de nouveaux tuyaux sur le noyau de Windows Vista.
FONCTIONNALITÉS
SQL Server Nouveaux Outils pour diagnostiquer l’intégrité de l’index

Pour obtenir des performances optimales de SQL Server, vous devrez surveiller et maintenir l’intégrité des index. Les nouveaux affichages et fonctions de gestion dynamique ajoutent une fenêtre dans le SQL Server pour vous aider à mieux comprendre le fonctionnement de vos index et à déceler les problèmes de performance potentiels.

Randy Dyess Atteindre une haute disponibilité pour SQL Server

SQL Server 2005 offre un certain nombre d’options pour améliorer la disponibilité des bases de données, de la réplication à la mise en cluster en passant par l’envoi de journaux. Nous étudierons de plus près les diverses options pour la configuration de SQL Server et vous aiderons à trouver celles qui sont adaptées à votre environnement.

Zach Nichter Simplifiez la maintenance des bases de données à l'aide des partitions de tables

Par le passé, il était laborieux et fastidieux de travailler avec des partitions et des tables très volumineuses. Mais grâce à SQL Server 2005, le partitionnement de tables s'est beaucoup simplifié. À présent, vous pouvez aisément créer des partitions multiples, déplacer ces partitions, supprimer de vieilles partitions et même modifier la façon dont les données sont partitionnées. Nous allons vous expliquer comment.

Noé Gomez Astuces pour les clusters SQL Server

Un cluster de serveurs fournit des capacités de basculement qui vous assurent une plus grande disponibilité de fonctionnement pour vos opérations critiques. Toutefois, pour qu’un cluster soit efficace, il faut qu’il soit correctement mis en œuvre. Voici quelques astuces qui vous aideront à configurer rapidement votre cluster et à le faire fonctionner de façon rentable.

Tom Moreau, PhD Administration de Windows Dans le noyau de Windows Vista : 2ème partie

Ce mois-ci, nous poursuivons notre discussion approfondie sur les nouveautés du noyau de Windows Vista. Dans ce numéro, nous examinons quelques-unes des améliorations de la gestion de la mémoire dans Windows Vista et explorons le démarrage et l'arrêt du système, ainsi que la gestion de l'alimentation.

Mark Russinovich
COLONNES
Le mot du rédacteur en chef

Étagère des trophées

Joshua Trupin Boîte à outils

Nouveaux produits pour les professionnels de l'informatique

Greg Steen Coup de projecteur sur les utilitaires

SyncToy

Jay Munro Forum aux questions sur SQL

Heure d’été, mémoire de serveur et plus

Par Nancy Michell Le petit câbleur

Le protocole DHCPv6

Joseph Davies Windows PowerShell

La puissance des variables

Don Jones 		Hé, vous le scripteur !

Nous répondons à vos questions sur UO...pour 5 centimes seulement

Les scripteurs Microsoft Exchange Queue & A

Journaux des transactions, Cmdlets, gestion à distance et plus encore

KC Lemson et Nino Bilic Vigilance sécurité

Déploiement d'EFS : 2ème partie

John Morello Histoires de Bureau

Introduction à PsTools

Wes Miller Microsoft.com au jour le jour

Démarrage de la mise en miroir de base de données

Saleem Hakani Sur le terrain

Le médecin est là

Matt Hester La vie secrète de Windows

Paraître intelligent en étant stupide

Raymond Chen


 SQL&#160;Server: Nouveaux Outils pour diagnostiquer l’int&#233;grit&#233; de l’index
SQL Server Randy Dyess

Nouveaux Outils pour diagnostiquer l’intégrité de l’index
Vue d'ensemble:
  • Fragmentation de l’index
  • Usage de l’index
  • Activité opérationnelle de l’index
Télécharger le code de cet article: DyessSQLIndex2007_03.exe (151KB)

La mise au point des index de la base de données est l’un des éléments principaux de toute liste de vérification des réglages de la performance SQL Server. La capacité de l’optimiseur de requête SQL Server à utiliser correctement les index pendant l’exécution d’une requête dépend non seulement de la création efficace d’index mais
aussi de leur intégrité. Une série de vues et de fonctions de gestion dynamique (DMV, DMF), introduites dans le SQL Server™ 2005, peut aider les administrateurs de base de données à déterminer l’efficacité de leurs index et découvrir tout problème de performance.
Les DMV et DMF vous permettent d’examiner un serveur puis de renvoyer des informations à partir de l’état du serveur pour vous aider à surveiller l’intégrité et la performance de l’instance du serveur et de diagnostiquer des problèmes. Les administrateurs de base de données familiarisés avec les versions précédentes de SQL Server remarqueront que ces DMV et DMF les remplaceront grâce à l’utilisation de commandes DBCC, l’exécution de certaines procédures système stockées, l’interrogation de plusieurs tables système et la capture d’événements à l’aide du générateur de profils SQL.
Trois fonctions et vues clés à savoir : sys.dm_db_index_physical_stats, sys.dm_db_index_usage_stats et sys.dm_db_index_operational_stats sont disponibles pour vous aider à savoir si vos index fonctionnent comme prévu. Ils vous permettent de consulter les modèles de verrouillage et d’E/S de vos index, et de savoir s’ils sont utilisés par l’optimiseur de requête de façon à ne pas induire de contention inutile dans la base de données.

Fragmentation de l’index
Le DMF sys.dm_db_index_physical_stats a été créé pour remplacer DBCC SHOWCONTIG et pour afficher une fragmentation de l’index. Cependant, contrairement à DBCC SHOWCONTIG, qui place un verrou partagé (S) sur la table contenant l’index, sys.dm_db_index_physical_stats place seulement une intention de verrou partagé (IS), ce qui réduit largement le risque de blocage de la table pendant l’exécution de la fonction.
Pour définir la fragmentation d’un index en utilisant sys.dm_db_index_physical_stats, vous examinerez une combinaison de trois colonnes dans le résultat de la fonction. La fragmentation logique d’index (fragmentation d’étendue de tas) peut être déterminée en observant la valeur renvoyée dans la colonne avg_fragmentation_in_percent. La fragmentation logique correspond au pourcentage de pages non ordonnées au niveau feuille d’un index, tandis qu’une fragmentation de l’étendue est le pourcentage d’étendues non ordonnées au niveau feuille d’un index. La fragmentation logique et de l’étendue peut affecter la performance d’un index en nécessitant des E/S et un mouvement de la tête du disque supplémentaires, la tête de disque devant sauter pour pouvoir lire des pages dans l’ordre. Vous devez vous efforcer de garder la fragmentation logique et d’étendue aussi près de zéro que possible.
La fragmentation interne d’un index est le pourcentage de remplissage de pages. Il est certain que la page d’index doit être aussi pleine que possible, bien que vous deviez équilibrer remplissage et nombre d’insertions dans les pages d’index afin de garder le nombre de fractionnements de pages au minimum absolu.
L’argument avg_page_space_used_in_percent de sys.dm_db_index_physical_stats doit être examiné pour déterminer le remplissage des pages d’index. Pour s’assurer que le nombre est configuré proche de 100 pourcent, ajustez le taux de remplissage d’un index en observant le nombre de fractionnements de pages qui se produisent. À un moment donné, le nombre de fractionnements de pages augmentera de façon spectaculaire, indiquant que vous avez défini un taux de remplissage de l’index plus élevé que prévu. L’ajustement fillfactor (taux de remplissage) de l’index prend du temps et les tests ne doivent pas être conduits sans une bonne planification. (Pour les index n’ayant pas d’insertions aléatoires, il est possible de paramétrer les taux de remplissage à 100 sans se soucier de l’augmentation de fractionnements de page).
Pour déterminer les niveaux de fragmentation de tous les index dans la table AdventureWorks.HumanResources.Employee, vous pourriez utiliser l’instruction ci-après :
SELECT *
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,OBJECT_ID('HumanResources.Employee')
,NULL
-- NULL to view all indexes;
-- otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') -- We want all information
Utilisez ce DMF pour déterminer automatiquement les index qui doivent être reconstruits, ceux qui doivent être réorganisés et ceux qui n’ont pas besoin de maintenance. L’examen des valeurs des colonnes avg_page_space_used_in_percent et avg_fragmentation_in_percent de ce DMF pour la fragmentation d’index (se trouvant hors d’une logique et d’un seuil de densité admis) peut vous aider à déterminer les opérations à exécuter sur l’index.
Selon l’état de vos index, l’exemple affiché à la figure 1 peut ne pas retourner de données dans votre copie de la base de données AdventureWorks, mais il peut être facilement adapté à d’autres bases de données.
Figure 1 Examen de la fragmentation et du remplissage de page (Close Figure 1)
--Reorganize the following indexes in the AdventureWorks database
USE AdventureWorks
GO

SELECT OBJECT_NAME([object_id]) AS 'Table Name',
index_id AS 'Index ID'
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,NULL -- NULL to view all tables
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') --We want all information
WHERE ((avg_fragmentation_in_percent > 10
AND avg_fragmentation_in_percent < 15) -- Logical fragmentation
OR (avg_page_space_used_in_percent < 75
AND avg_page_space_used_in_percent > 60)) --Page density
AND page_count > 8 -- We do not want indexes less than 1 extent in size
AND index_id NOT IN (0) --Only clustered and nonclustered indexes

--Rebuild the following indexes in the AdventureWorks database
USE AdventureWorks
GO

SELECT OBJECT_NAME([object_id]) AS 'Table Name',
index_id AS 'Index ID'
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,NULL -- NULL to view all tables
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') --We want all information
WHERE ((avg_fragmentation_in_percent > 15) -- Logical fragmentation
OR (avg_page_space_used_in_percent < 60)) --Page density
AND page_count > 8 -- We do not want indexes less than 1 extent in size
AND index_id NOT IN (0) --Only clustered and nonclustered indexes
Vous pourrez aisément stocker les résultats des requêtes dans une variable de table puis effectuer une boucle de la variable de table pour générer une chaîne dynamique pour l’instruction ALTER INDEX correcte (voir la figure 2).
Figure 2 Création d’une chaîne ALTER INDEX dynamique (Close Figure 2)
--Rebuild the following indexes in the AdventureWorks database
USE AdventureWorks
GO

--Table to hold results
DECLARE @tablevar TABLE(lngid INT IDENTITY(1,1), objectid INT,
index_id INT)

INSERT INTO @tablevar (objectid, index_id)
SELECT [object_id],index_id
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks')
,NULL -- NULL to view all tables
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
,'DETAILED') --We want all information
WHERE ((avg_fragmentation_in_percent > 15) -- Logical fragmentation
OR (avg_page_space_used_in_percent < 60)) --Page density
AND page_count > 8 -- We do not want indexes less than 1 extent in size
AND index_id NOT IN (0) --Only clustered and nonclustered indexes

SELECT 'ALTER INDEX ' + ind.[name] + ' ON ' + sc.[name] + '.'
+ OBJECT_NAME(objectid) + ' REBUILD'
FROM @tablevar tv
INNER JOIN sys.indexes ind
ON tv.objectid = ind.[object_id]
AND tv.index_id = ind.index_id
INNER JOIN sys.objects ob
ON tv.objectid = ob.[object_id]
INNER JOIN sys.schemas sc
ON sc.schema_id = ob.schema_id

Usage de l’index
Tandis que sys.dm_db_index_physical_stats est un outil de remplacement puissant de DBCC SHOWCONTIG pouvant aider à révéler l’intégrité d’un index, vous serez souvent confrontés au problème plus complexe de la détermination des index utiles aux requêtes exécutées sur une table. Souvent les développeurs de base de données ou les administrateurs créent des index sur une table qui, selon eux, sera utilisée par l’optimiseur de requête pendant l’exécution d’une requête. Dans les versions précédentes de SQL Server, il était difficile de savoir si ces index étaient effectivement utilisés. Soit il fallait annuler l’index et voir si la performance des requêtes en était affectée soit capturer les projets d’exécution des requêtes et analyser l’usage de l’index.
sys.dm_db_index_usage_stats est une nouvelle vue de gestion dynamique qui facilite la compréhension de l’utilisation des index par l’optimiseur de requête et de l’exécution des requêtes sur une table. Cette vue peut être examinée pour déterminer l’utilité d’un index, vous permettant d’annuler tout index non utilisé par l’optimiseur de requête. Vous n’avez plus à vous soucier d’index qui gaspillent l’espace de stockage ou de la maintenance d’index inutilisés qui diminuent les performances de la base de données.
En examinant les résultats de cette vue de gestion dynamique (DMV) pour les index avec zéro recherche et analyse, vous pouvez déterminer si un index a été utilisé ou non depuis le dernier démarrage de SQL Server. Sachez toutefois qu’un grand nombre de DMV et DMF ne sont pas maintenues et se remettent à zéro une fois que SQL Server est relancé. Tenez en compte lorsque vous utilisez une DMV ou une DMF pour déterminer l’usage d’un index. L’index peut simplement ne pas être nécessaire depuis le dernier redémarrage du service mais vous en aurez besoin pour les requêtes de rapports de fin de semaine, de fin de mois ou trimestriels.
Pour afficher tous les index dans une instance qui n’a pas été utilisée depuis le dernier redémarrage du service SQL Server, vous pouvez utiliser l’instruction suivante :
SELECT DB_NAME(database_id),OBJECT_NAME([object_id])
FROM sys.dm_db_index_usage_stats
WHERE user_seeks = 0
AND user_scans = 0
AND user_lookups = 0
AND system_seeks = 0
AND system_scans = 0
AND system_lookups = 0

Activité opérationnelle de l’index
La DMF sys.dm_db_index_operational_stats sera très utile pour vous aider à comprendre l’activité opérationnelle de vos index. Vous pouvez l’utiliser pour afficher les activités d’E/S, de verrouillage, de blocage et de méthode d’accès sur chaque index d’une base de données ; vous pouvez ainsi comprendre comment vos index sont utilisés et diagnostiquer les problèmes de verrouillage d’index dus à une activité d’E/S étendue ou à l’existence d’un « point sensible » dans l’index.
Utilisez le temps d’attente de verrouillage de cette DMF pour vous aider à établir le temps qu’il faut aux opérations LECTURE et ÉCRITURE pour acquérir l’accès aux ressources de l’index. Vous pourriez ainsi déterminer si le sous-système disque utilisé pour stocker l’index est suffisant pour l’activité d’E/S de l’index. Il peut également indiquer si la conception et l’usage de l’index n’ont pas introduit un point sensible tandis qu’une activité étendue dans une ou plusieurs pages d’un index peut provoquer une contention pour les données contenues dans ces pages. Une telle contention conduit souvent au verrouillage excessif d’opérations tentant de LIRE ou ÉCRIRE dans cette zone.
La figure 3 affiche la méthode de détermination des modèles d’E/S et de verrouillage de tous les index de la table AdventureWorks.HumanResources.Employee.
Figure 3 Détermination de modèles d’E/S et de verrouillage (Close Figure 3)
SELECT page_latch_wait_count --page latch counts
,page_latch_wait_in_ms --page latch wait times
,row_lock_wait_in_ms --row lock wait times
,page_lock_wait_in_ms --page lock wait times
,row_lock_count --row lock counts
,page_lock_count --page lock counts
,page_io_latch_wait_count --I/O wait counts
,page_io_latch_wait_in_ms --I/O wait times
FROM sys.dm_db_index_operational_stats (DB_ID('AdventureWorks')
,OBJECT_ID('HumanResources.Employee')
,NULL -- NULL to view all indexes; otherwise, input index number
,NULL -- NULL to view all partitions of an index
)

Pour en savoir plus
Les DMV et DMF présentés dans cet article peuvent faire l’objet d’utilisations supplémentaires. Prenez le temps de consulter les articles de la documentation en ligne de SQL Server décrivant les fonctions et vues indiquées dans la barre latérale « Ressources Supplémentaires » afin de comprendre la grande variété d’informations que vous pourrez extraire et examiner grâce à elles.
Pour en savoir plus sur les DMF et DMV d’index n’ayant pas été abordés dans cet article, consultes le blog (en anglais) publié par l’équipe d’optimisation de requête SQL Server à blogs.msdn.com/queryoptteam/570176.aspx.
Ressources supplémentaires
  • sys.dm_db_index_physical_stats
  • sys.dm_db_index_usage_stats
  • sys.dm_db_index_operational_stats

Randy Dyess est le mentor de Solid Quality Learning, où il est spécialiste des systèmes OLTP SQL Server. Randy est l’auteur d’un grande nombre de livres et d’articles au sujet de SQL Server. Il est le fondateur et l’auteur principal de www.TransactSQL.Com et www.Database-Security.Info
© 2007 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.


 SQL&#160;Server: Atteindre une haute disponibilit&#233; pour SQL Server
SQL Server Zach Nichter

Atteindre une haute disponibilité pour SQL Server
Vue d'ensemble:
  • Mise en miroir
  • Instantanés de base de données
  • Envoi de journaux
  • Clusters
  • Réplication
Télécharger le code de cet article: NichterHA2007_03.exe (151KB)

La haute disponibilité est un concept que tout administrateur de base de données doit comprendre. Elle se rapporte à la réactivité et à l’accessibilité d’un système. Parfois, une haute disponibilité signifie un temps de réponse de quelques secondes tandis que dans d’autres cas les temps de réponse sont calculés en

fractions de seconde. J’ai eu l’occasion de travailler en tant que consultant dans une société où les serveurs Web avaient besoin que les requêtes SQL aient des temps de réponse aller-retour en millisecondes ; si la réponse dépassait cette limite, le système de base de données été considéré comme étant en panne et le serveur Web se reconnectait au serveur de base de données disponible suivant.
Comme les utilisateurs exigent des applications de plus en plus rapides, vous serez plus à même de planifier vos applications reposant sur des données si vous savez comment atteindre une haute disponibilité et des temps de réponse rapides.
Heureusement, SQL Server™ 2005 a un certain nombre d’options pour améliorer la disponibilité, notamment la réplication, la mise en cluster, la mise en miroir des bases de données, les instantanés de bases de données et l’envoi de journaux de bases de données. Je vais examiner ces fonctionnalités et fournir des informations sur les éléments qui vous permettront de découvrir celles qui sont adaptées à votre environnement. Commençons par la figure 1, qui décrit les options de disponibilité dans SQL Server 2005.
Figure 1 Options de haute disponibilité (Close Figure 1)

Attributs technologiques | Réplication | Mise en miroir de la base de données | Clusters | Instantanés de base de données | Envoi de journaux
Option de haute disponibilité |  |  |  |  |
Tolérance des exigences de transactions nombreuses |  |  |  |  |
Disponibilité en temps réel des données |  |  |  |  |
Image de données en lecture seule |  |  |  |  |
Configuration matérielle unique |  |  |  |  |
Faible coût |  |  |  |  |
Fournit une récupération des données |  |  |  |  |
Basculement automatisé |  |  |  |  |
Implémentation/gestion potentiellement complexe |  |  |  |  |
Considérations de performances possibles |  |  |  |  |

Définition de la haute disponibilité
L’un de vos premiers objectifs lors de la planification d’une application à haute disponibilité consiste à définir ce que cela signifie dans votre environnement particulier. Pour certaines organisations, la haute disponibilité signifie qu’il doit y avoir un matériel redondant égal au matériel de production, ce qui veut dire que les données et le matériel doivent avoir une durée de fonctionnement et une disponibilité de 99,995 pourcent ou plus. D’autres organisations auront peut-être besoin que les données aient uniquement une haute disponibilité, avec moins d’inquiétude en ce qui concerne les performances au niveau de la production si un basculement était nécessaire. La définition de la haute disponibilité est essentielle pour déterminer la solution adaptée à votre situation.
Vous devez également identifier les types de pannes rencontrées et indiquer comment elles affectent vos contrats de niveau de service (SLA, Service Level Agreements). Les pannes qui peuvent affecter votre disponibilité incluent les performances planifiées et non planifiées et les dégradations de performances.
Une panne planifiée est généralement une fenêtre de maintenance planifiée dont les utilisateurs des systèmes sont informés à l’avance. Une panne non planifiée est généralement le résultat d’une défaillance matérielle ou logicielle qui empêche l’accès à vos données. La dégradation des performances peut également provoquer des pannes et est souvent mesurée en temps de réponse utilisateur, ce qui est généralement négocié à l’avance par l’entreprise ainsi que le service informatique dans une forme de contrat de niveau de service (SLA, Service Level Agreement).
En plus d’identifier les sources potentielles de pannes, vous devez déterminer également le niveau d’activité de vos données et décider si elles doivent toujours être en ligne ou si elles peuvent être à proximité de la ligne ou hors ligne de temps en temps. Vous devez également décider si l’option de disponibilité va être dans le même emplacement géographique ou dans un emplacement distant. Les restrictions de budget joueront aussi probablement un rôle dans votre décision. À présent, examinons chaque option de disponibilité.

Mise en miroir de la base de données
Avant de creuser dans le sujet de la mise en miroir des bases de données, je vais commencer par définir la terminologie.
Le principal est le serveur de production principal abritant la base de données qui envoie ses journaux de transactions en permanence au serveur miroir et à la base de données.
Le miroir est le serveur secondaire qui abrite la copie de sauvegarde de la base de données. La copie miroir est synchronisée régulièrement avec la base de données principale.
Le rôle indique l’objectif du serveur particulier (qu’il s’agisse d’un serveur principal ou miroir).
Le témoin est l’instance qui contrôle les serveurs principal et miroir lorsqu’ils font leur travail et peuvent initier un basculement automatique.
Un partenaire peut être le serveur principal ou le serveur miroir.
Dans un environnement typique, la base de données principale est sauvegardée sur l’instance principale et la sauvegarde est restaurée sur l’instance miroir (voir la figure 2). Une fois la base de données restaurée, la mise en miroir doit être configurée sur le serveur principal en utilisant soit la fenêtre des propriétés de la base de données principale dans SQL Server Management Studio (SMSS) soit des scripts T-SQL.
Figure 2 Architecture de mise en miroir des bases de données
Figure 2 Architecture de mise en miroir des bases de données (Cliquer sur l'image pour la réduire)
Figure 2 Architecture de mise en miroir des bases de données
Figure 2 Architecture de mise en miroir des bases de données (Cliquer sur l'image pour l'agrandir)
Une fois que la mise en miroir est configurée et que la session de mise en miroir a été établie, les bases de données principale et miroir se synchroniseront. La base de données principale enverra alors son journal des transactions des événements survenus depuis l’heure à laquelle la dernière sauvegarde a été appliquée à la base de données miroir. La base de données miroir recevra le journal et tentera de l’appliquer aussi vite que possible. Si vous utilisez SQL Server 2005 Enterprise Edition, ce processus est en mode multithread ; autrement, il s’agit d’une opération à un seul thread. Dès que ces journaux sont appliqués à la base de données miroir, les bases de données sont considérées comme synchronisées et elles resteront synchronisées jusqu’à ce que la session en miroir soit arrêtée.
Lorsque les clients exécutent de nouvelles transactions, le serveur principal exécute les transactions par rapport à la base de données principale et, ce faisant, il transfère les enregistrements du journal des transactions de la base de données principale vers le journal de restauration par progression, ou les files d’attente de journaux de la base de données en miroir, où il est repris et appliqué vers la base de données en miroir. Une fois la transaction appliquée et validée sur la base de données miroir, une réponse est envoyée au principal pour le prévenir que la transaction a été validée sur le miroir. Le principal ne confirmera pas les nouvelles transactions qui entreront dans le système jusqu’à ce que le miroir envoie un accusé de réception.
Dans le cas d’une défaillance, le miroir peut initier une défaillance automatique et le témoin prend en charge le processus en déterminant si la base de données principale est disponible. Lorsqu’une défaillance survient, il faut résoudre le problème de savoir qui est maintenant le partenaire miroir pour qu’il puisse redevenir le partenaire principal. Une fois les problèmes résolus sur le partenaire miroir, le retour vers le serveur du partenaire miroir est établi et les bases de données se synchronisent à nouveau. Une fois qu’elles sont synchronisées, la session de mise en miroir peut recommencer.
Ce mode de mise en miroir particulier est un mode haute sécurité qui fournit des opérations transactionnelles synchrones en activant la sécurité transactionnelle, mais il n’a pas besoin de témoin parce qu’il ne profite pas du basculement automatisé ; tous les basculements sont établis manuellement. Il y a un autre type de mode de mise en miroir qui fournit des opérations transactionnelles synchrones : le mode haute disponibilité. Il requiert non seulement l’activation de la sécurité transactionnelle, mais aussi l’utilisation d’un témoin pour le basculement automatisé dans le cas d’une défaillance.
Le troisième et dernier mode disponible dans la mise en miroir est hautes performances. Il requiert la désactivation de la sécurité transactionnelle pour permettre une prise en charge opérationnelle asynchrone qui, à son tour, permet la validation des transactions sur le partenaire principal sans qu’il soit nécessaire d’attendre l’écriture de l’enregistrement de la transaction sur le miroir. Le mode hautes performances n’a pas besoin de témoin dans la configuration.
Notez que la mise en miroir requiert la même édition de SQL Server sur le principal et le miroir mais pas sur le témoin, qui peut être SQL Server Express Edition. De plus, il est important que la base de données principale soit dans le mode de récupération complète.
ADO.NET 2.0 est intégré à SQL Server 2005 et inclut la capacité de prise en charge de la mise en miroir des bases de données et de basculement transparent pour l’application vers l’environnement en miroir. Ceci donne à votre application ADO.NET une façon de basculer automatiquement sans codage ou configuration supplémentaire si une connexion à la base de données principale ne peut pas être faite. La configuration est aussi facile que la spécification d’un utilisateur commun entre les deux environnements et le partenaire de basculement dans la chaîne de connexion. Voici un exemple d’une chaîne de connexion ADO.NET identifiant le partenaire de basculement pour l’environnement de la base de données en miroir :
"Provider=SQLNCLI.1;Data Source=MirrorDB;Failover Partner=SQL03;
 Initial Catalog=AdventureWorks;
Persist Security Info=True;User ID=TestUser; Password=TestPswd; Pooling=True;
Connect Timeout=5;Application Name=ADOMirrorTest"
La mise en miroir de la base de données peut être une option envisageable pour votre entreprise en fonction de vos exigences d’applications et de données, mais vous devez tenir compte d’un certain nombre de choses pour obtenir des performances optimales. Par exemple, à combien s’élève le taux de transaction du système ou le volume de changement des données ? Lorsque vous envisagez la mise en miroir de bases de données, il est essentiel de déterminer si la bande passante et la vitesse réseau suffisent pour gérer le volume de données et le taux de traitement des transactions. Prenez également en compte la saturation du lien. Ceci est particulièrement important si le miroir se trouve dans un emplacement géographique différent. Il est essentiel de surveiller votre système avant pour déterminer s’il existe des restrictions environnementales qui empêcheraient la mise en miroir de fonctionner efficacement.
La mise en miroir de bases de données peut être une excellente option si vous essayez de contrôler les coûts. En fait, l’architecture de mise en miroir des bases de données ne requiert pas de disques partagés, ni de compétences avancées ou spécialisées pour exécuter l’environnement. De plus, les partenaires n’ont pas besoin d’avoir le même matériel, à la différence de la mise en cluster. Par ailleurs, il est facile d’implémenter la mise en miroir à l’aide de l’assistant d’installation qui se trouve sous l’onglet de mise en miroir de la fenêtre des propriétés de la base de données (voir la figure 3). Je vous recommande aussi de lire le livre blanc (en anglais) « Database Mirroring Best Practices and Performance Considerations » (Méthodes recommandées et considérations de performances pour la mise en miroir de bases de données) à l’adresse go.microsoft.com/fwlink/?LinkId=80897 pour plus d’informations.
Figure 3 Assistant d’installation de la mise en miroir
Figure 3 Assistant d’installation de la mise en miroir (Cliquer sur l'image pour la réduire)
Figure 3 Assistant d’installation de la mise en miroir
Figure 3 Assistant d’installation de la mise en miroir (Cliquer sur l'image pour l'agrandir)

Instantanés de base de données
Les instantanés de base de données sont une nouvelle technologie offerte dans SQL Server 2005 Enterprise Edition, mais elles ne sont pas considérées comme une option de haute disponibilité. Les instantanés de base de données doivent être utilisés comme option de récupération ou de création de rapports viable lorsqu’ils sont utilisés avec d’autres technologies. Un instantané est simplement un affichage en lecture seule d’une base de données à un moment donné.
Un instantané est créé en utilisant une commande CREATE DATABASE de la façon suivante :
CREATE DATABASE SnapDB_20061028_2030 ON
(NAME = SnapDB_Data, FILENAME =
    'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SnapDB_20061028_2030.snp')
AS SNAPSHOT OF SnapDB;
GO
Lorsque l’instantané de base de données est créé, il utilise un ou plusieurs fichiers appelés fichiers fragmentés et non fichiers de données comme dans une base de données classique. Ces fichiers fragmentés sont essentiellement des espaces réservés virtuels qui ne consomment pas de données au début. Ils sont utilisés pour stocker des données uniquement si les données sont modifiées ou supprimées dans la base de données source. Les données sont inscrites dans les fichiers fragmentés une page de données à la fois et l’instantané de base de données affiche uniquement les données qui ont été modifiées depuis la prise de l’instantané. Le reste des données provient des pages de données de la base de données source.
Les fichiers de l’instantané de base de données sont alloués à la taille de la base de données au moment de la prise de l’instantané. La taille allouée ne vous donne aucune indication du volume réel des données contenues. Pour obtenir cette information, exécutez une instruction T-SQL comme celle-ci :
SELECT *
FROM fn_virtualfilestats(DB_ID(N'SnapDB_20061028_
    2030'), 1);
GO

En raison de la façon dont les données sont stockées dans des fichiers fragmentés et dans la base de données source, lors de l’accès à un instantané de base de données, les pages de données des fichiers de base de données et pages de données originaux des fichiers fragmentés de l’instantané sont récupérées. Les instantanés peuvent uniquement loger sur le serveur avec la base de données source dont est issu l’instantané car ils ont besoin de partager des pages de données. Comme cette architecture n’allège pas l’E/S sur la base de données source, les instantanés ne constituent pas une option de création de rapports valide car ils ne représenteront pas l’état réel de la base de données.
Envisagez un scénario où la mise en miroir de la base de données est utilisée avec des instantanés. Ceci permet la séparation physique des données de création de rapports, du miroir et des bases de données d’instantanés de la base de données principale. L’instantané de base de données est planifié à l’aide de l’agent SQL Server et d’un script personnalisé pour fournir des instantanés actualisés à des intervalles réguliers. L’exemple de script de la figure 4 montre la procédure stockée utilisée pour accomplir ceci. Elle est conçue pour être utilisée à l’intérieur d’une tâche pour gérer la création et la suppression d’instantanés pour une base de données particulière dans votre environnement. Ceci constituerait une solution de création de rapports acceptable parce que les données de rapports seraient isolées des données de production.
Figure 4 Procédure stockée pour la programmation des instantanés (Close Figure 4)
use msdb;
GO
set nocount on
GO

CREATE PROCEDURE usp_snaprefresh
     @database    sysname = NULL    --name of the database to snapshot
    ,@keepsnap    int        = 24   --# of hours to keep a snapshot
                                    --after it was created
                                    --use a value of '0' to keep all
                                    --existing snapshots
    ,@fileloc    sysname            --location for snapshot
        = 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\'
AS

DECLARE
     @dt            datetime        ,@cnt          int
    ,@databaseid    int             ,@snap         sysname
    ,@sql           nvarchar(1000)  ,@yy           varchar(4)
    ,@mm            varchar(2)      ,@dd           varchar(2)
    ,@h             varchar(2)      ,@m            varchar(2)
    ,@lname         sysname         ,@pname        sysname
    ,@file          sysname         ,@pos1         int
    ,@pos2          int

-- initialize variables
SELECT
     @dt = getdate()
    ,@cnt = 0, @pos1 = 0, @pos2 = 0
    ,@databaseid = db_id(@database)

-- check if valid database was provided
IF @databaseid IS NULL
BEGIN
    RAISERROR ('Missing database name. Rerun the procedure specifying a
       valid database name.',16,1)
    RETURN (0)
END

--determine if snapshots should be kept
IF @keepsnap <> 0
BEGIN
    -- determine if other snapshots exist for this server older than @
    -- keepsnap value hrs
    SELECT ROW_NUMBER() OVER(ORDER BY name DESC) AS [RowNum],
        name INTO #t1
    FROM master.sys.databases
    WHERE source_database_id = @databaseid
        AND create_date < dateadd(hh,-(@keepsnap),getdate())

    IF (SELECT max(RowNum) FROM #t1 where name is not null) > 0
    BEGIN
        WHILE @cnt <= (SELECT max(RowNum) FROM #t1)
        BEGIN
            SELECT @snap = name FROM #t1 WHERE RowNum = @cnt

            PRINT 'Dropping snapshot ''' + @snap + ''''

            SET @sql = 'DROP DATABASE ' + @snap

            EXEC(@sql)
            SELECT @cnt = @cnt + 1
        END
    END
END

-- break apart point in time date time information for file name
SELECT @yy = convert(varchar(4),year(@dt)),@mm = convert(varchar(2),
   month(@dt))
    ,@dd = convert(varchar(2), day(@dt)),@h = convert(varchar(2),
         datepart(hh,@dt))
    ,@m = convert(varchar(2), datepart(mi,@dt))

-- piece together the database snapshot name and the file name
SELECT @file = @database + '_' + @yy + @mm + @dd + '_' + @h + @m

-- identify logical file name of primary data file
SET @sql = 'SELECT name INTO tempdb..t1
FROM ' + @database + '.sys.database_files
WHERE file_id = 1'

EXEC(@sql)

--setting logical filename for the snap
SELECT @lname = name FROM tempdb..t1

-- making sure the file location ends with '\'
IF substring(@fileloc, len(@fileloc), 1) <> '\'
BEGIN
    SET @fileloc = @fileloc + '\'
END

-- build sql statement to be run
SET @sql = N'CREATE DATABASE ' + @file + ' ON
(NAME = ' + @lname + ', FILENAME = ''' + @fileloc + @file + '.snp'')
AS SNAPSHOT OF ' + @database

EXEC(@sql)

-- cleanup
DROP TABLE tempdb..t1;
GO
Souvenez-vous, cependant, que les instantanés de bases de données sont considérés comme temporaires parce que les instantanés ne peuvent pas être sauvegardés et ne peuvent pas exister sans leur base de données source. Si un fichier fragmenté manque d’espace, l’instantané sera considéré comme endommagé et devra être supprimé.
De plus, avec des instantanés de base de données, les performances système peuvent connaître une dégradation pendant les opérations de modification des données sur la base de données source, parce que les pages de données sont inscrites dans le fichier fragmenté pour chaque instantané depuis les fichiers de données de la base de données source. Ceci multiplie ensuite le nombre d’écritures par le nombre d’instantanés d’une base de données.
Les autorisations de lecture sont définies par la base de données source au moment de l’instantané et ne peuvent pas être modifiées. L’instantané doit résider dans la même instance que la base de données source parce qu’ils partagent des pages de données et la même mémoire cache de tampons.
Vous pouvez envisager d’utiliser des instantanés comme une solution de création de rapports uniquement si vous utilisez également la mise en miroir ; autrement, votre environnement n’y gagnera pas en performances. Les instantanés de base de données sont sans doute la façon la plus rapide de préserver des données avant l’exécution d’une opération discutable sur un système. Une base de données peut revenir à l’état de l’instantané ou les données peuvent être extraites de l’instantané pour remplacer des données dans la base de données source.
Il vous faudra déterminer une norme d’affectation de noms pour les bases de données d’instantanés. La norme que j’utilise est originaldatabasename_date_time.snp. Elle spécifie d’abord la base de données source, puis le jour et enfin l’heure (dans un format de 24 heures) de prise de l’instantané.

Envoi de journaux
L’envoi de journaux est une option de haute disponibilité limitée qui utilise la sauvegarde et la récupération pour établir une solution très bon marché. L’envoi de journaux tire parti des sauvegardes de journaux des transactions sur un intervalle planifié pour faire en sorte qu’une base de données secondaire reste à jour.
L’envoi de journaux dans SQL Server 2005 utilise des assistants pour guider les utilisateurs dans le processus d’installation, de planification, d’initialisation et de surveillance (voir la figure 5). Le processus est simple et peut être complété en quelques minutes seulement.
Figure 5 Assistant d’installation de l’envoi de journaux
Figure 5 Assistant d’installation de l’envoi de journaux (Cliquer sur l'image pour la réduire)
Figure 5 Assistant d’installation de l’envoi de journaux
Figure 5 Assistant d’installation de l’envoi de journaux (Cliquer sur l'image pour l'agrandir)

Une fois la base de données primaire identifiée, une planification est créée et l’âge du fichier déterminé pour les fichiers de sauvegarde. Ensuite, les partages de fichiers pour les fichiers de sauvegarde doivent être établis. Une fois les partages de fichiers configurés, l’emplacement des fichiers de la base de données secondaire doit être établi et la base de données doit être initialisée par le biais d’une restauration de la base de données primaire. Pour finir, les plannings doivent être déterminés pour les copies de fichier de sauvegarde et les restaurations des sauvegardes de journaux des transactions avec les éventuels retards ou alertes nécessaires pour chaque étape.
Une fois l’installation terminée, l’envoi de journaux sauvegarde le journal des transactions d’une base de données de façon programmée vers un emplacement réseau partagé. Lorsque les fichiers ont été envoyés en partage, la sauvegarde est appliquée à la base de données secondaire de manière programmée.
L’envoi de journaux fonctionne dans de nombreuses situations à cause de sa simplicité. Il s’agit d’une bonne option de haute disponibilité qui est bon marché et qui peut gérer un système ayant un nombre élevé de transactions. La base de données secondaire qui est employée dans l’envoi de journaux peut être utilisée dans le mode de lecture seule, ce qui est pratique pour une base de données de création de rapports. L’envoi de journaux requiert des surcharges minimales, mais il nécessite une stratégie d’alerte en cas de défaillances de gestion.
Il y a deux choses qu’il faut prendre en considération si vous envisagez d’utiliser l’envoi de journaux dans votre environnement : sa simplicité d’installation et de gestion et le fait qu’il requiert pas ou peu de compétences spécialisées. L’envoi de journaux n’est pas une solution de haute disponibilité en temps réel, cependant, bien qu’il puisse être associé à la mise en miroir de bases de données dans cette optique. Il est limité par des plannings, ainsi que des opérations telles que les sauvegardes, les copies de fichiers et les restaurations. Il nécessite également un basculement manuel. Pour ces raisons, l’envoi de journaux fournit une solution simple pour l’environnement qui n’est pas trop soumis à des exigences de temps.

Mise en cluster de SQL Server
La mise en cluster de serveurs fonctionne au niveau du système d’exploitation et implique une duplication du matériel, ainsi que des ressources disque partagées auxquelles le cluster accèdera. La mise en cluster est peut-être moins intrusive pour les utilisateurs finaux, mais elle coûte plus cher. Elle nécessite au moins deux fois plus de matériel que ce qui est nécessaire pour exécuter une instance non mise en cluster.
Le sujet de la mise en cluster est assez complexe, c’est pourquoi je vais vous en donner un aperçu général plutôt que d’en explorer tous les détails. La mise en cluster nécessite deux serveurs minimum, équipés de la même version de Windows® 2000 édition Advanced ou Datacenter ou de Windows Server ® 2003 Enterprise ou Datacenter. Il requiert également l’installation de Microsoft® Cluster Services (MSCS) qui gère la propriété des ressources partagées entre les serveurs et les adresses IP, les disques partagés et les noms de réseaux. La mise en cluster nécessite également une ressource disque partagée, généralement sous la forme d’un réseau de stockage (SAN - Storage area network) ou un stockage à connexion SCSI.
Une instance de SQL Server est également considérée comme une ressource et les éditions Standard et Enterprise de SQL Server 2005 peuvent être installées dans une configuration de cluster. Voir le « Feature Comparison Chart for SQL Server 2005 » (Tableau de comparaison des fonctionnalités pour SQL Server 2005) (microsoft.com/sql/prodinfo/features/compare-features.mspx) pour obtenir une liste des fonctionnalités prises en charge par les deux éditions de SQL Server 2005.
Une fois que les ressources sont établies sur le cluster, le nœud secondaire du cluster reste en communication régulière avec le nœud primaire du cluster via une pulsation établie sur un réseau privé entre les deux nœuds du cluster. La pulsation est un point de contrôle intermédiaire qui sert à déterminer si le nœud primaire a échoué.
Dans le cas d’une défaillance du primaire, les ressources sont transférées vers le nœud secondaire tandis que l’état du serveur logique reste en place. Ceci permet aux clients de continuer à travailler avec seulement une brève interruption de l’interaction. L’ensemble du processus de basculement peut prendre entre 5 secondes et un peu moins de 30 secondes, voire plus dans certains cas selon le matériel, le logiciel et les composants réseau impliqués dans le cluster.
La mise en cluster peut être une technologie coûteuse et complexe nécessitant des compétences spécialisées pour résoudre des défaillances sur le système ; cependant, elle fournit le basculement le plus fluide pour les utilisateurs finaux de toutes les options de basculement automatisé. Chaque application est différente et certaines peuvent ne pas être sensibles au cluster ou compatibles, ce qui, dans le pire des cas, nécessiterait une reconnexion de l’application.

Réplication
La réplication de SQL Server 2005 peut également être utilisée dans les architectures de haute disponibilité. Il existe quatre types de réplication : de capture instantanée, transactionnelle, égal à égal et de fusion. La réplication égal à égal est en fait juste une forme de réplication transactionnelle, je n’en parlerai donc pas ici.
Avec la réplication, vous avez l’option d’avoir un site et une base de données secondaires pour une haute disponibilité qui soient tout aussi fonctionnels que la base de données primaire. Vous pouvez y parvenir en utilisant la réplication de fusion, qui prend les transactions des bases de données primaire et secondaire et fusionne les modifications des deux dans une troisième base de données. Comme vous pouvez l’imaginer, une procédure de résolution de conflits est nécessaire dans cette configuration.
La réplication transactionnelle ressemble beaucoup, de par sa conception logique, à la mise en miroir de bases de données. Les transactions qui sont appliquées à la base de données primaire sont envoyées vers la base de données secondaire pour faire en sorte que l’environnement reste cohérent. Une fois arrivées, les transactions sont appliquées à la base de données secondaire, qui attend ensuite que la transaction suivante soit appliquée au système.
La réplication de capture instantanée ressemble beaucoup à l’envoi de journaux car ils s’exécutent tous les deux à des intervalles réguliers et ils mettent à jour la base de données secondaire en masse, plutôt que d’appliquer chaque transaction aux deux systèmes lorsqu’elles sont validées. Les deux technologies s’utilisent quasiment de la même façon.
La réplication nécessite des connaissances spécialisées, ce qui peut être un problème pour les environnements qui n’ont pas un administrateur de base de données dédié. Le dépannage de la réplication peut être un peu complexe et celle-ci nécessite une conception plus approfondie si elle doit être utilisée comme option de haute disponibilité.
La réplication peut très bien répondre aux besoins d’une solution de haute disponibilité. Cette technologie fait ce que la mise en miroir de bases de données peut faire au niveau des enregistrements en utilisant la réplication transactionnelle, mais sans l’option d’un basculement automatisé. Si l’on suppose que vous avez des ressources suffisantes et un peu d’imagination, l’écriture d’une solution pour un basculement automatisé ne doit pas être inconcevable.
À la différence de la mise en miroir de bases de données, les bases de données source et cible sont entièrement accessibles pour les applications client. La réplication fournit les mêmes fonctionnalités que l’envoi de journaux avec l’utilisation de la réplication de capture d’instantanés.
Il faut cependant tenir compte du fait que la technologie de réplication a fait ses preuves et qu’elle est bien documentée. L’utilisation de la réplication pour une solution de haute disponibilité a quelques inconvénients et les performances peuvent poser un problème, mais pas plus que la mise en miroir de bases de données. N’importe quelle solution de haute disponibilité conçue avec la réplication aura probablement une architecture plus compliquée à gérer ; pas forcément plus avancée, mais sans aucun doute plus complexe. De plus, l’un des plus grands obstacles rencontrés est le fait que si votre structure de tables de base de données change ou si vous souhaitez ajouter une table pour la réplication, vous devez arrêter et redéfinir la publication pour que les modifications soient présentes dans les deux bases de données.

Conclusion
Vous pouvez maintenant voir comment la création d’une solution de haute disponibilité pour votre environnement nécessite une pointe d’imagination. Chaque technologie de haute disponibilité de SQL Server 2005 a ses points forts et ses points faibles et chacune est adaptée à des situations différentes.
L’envoi de journaux, la réplication de capture d’instantanés et la mise en miroir de bases de données dans un mode hautes performances seraient adaptés dans le cas d’une séparation géographique d’une base de données Web primaire des environnements de la base de données secondaire (surtout si vous n’avez pas besoin que les données secondaires soient disponibles en temps réel).
Si, en revanche, vous avez besoin que les données de la base de données secondaire soient disponibles en temps réel, la réplication transactionnelle ou la mise en miroir de bases de données vous sera utile si les taux de transaction sur le serveur primaire sont bas et le lien entre les deux sites d’environnement est rapide et non saturé.
Voyez également si vous vous sentez à l’aise avec ces technologies. Si vous avez déjà travaillé avec certaines des technologies, tout ira probablement bien. Si vous êtes directeur sans administrateur de base de données dédié, essayez d’éviter les technologies les plus complexes (comme la réplication où il y a beaucoup de déplacements d’éléments) pour lesquelles le dépannage peut être complexe. Vous pourriez également envisager d’engager un consultant SQL Server expérimenté pour vous aider à concevoir, implémenter, voire même former votre personnel à gérer une nouvelle haute disponibilité adaptée à votre environnement.
Si la haute disponibilité dans votre organisation nécessite seulement que les données soient disponibles la plupart du temps, et que les pertes de données sont prises très au sérieux, la mise en cluster est peut-être faite pour vous.
On peut conclure de tout ça que SQL Server 2005 fournit un certain nombre de nouvelles options pour l’implémentation de la haute disponibilité qui sont adaptées à différents types d’environnements. Il se peut qu’une seule option de disponibilité réponde à vos besoins ou peut-être souhaiterez-vous combiner plusieurs technologies, mais, comme vous le savez maintenant, un tas de choix s’offrent à vous.

Zach Nichter est un spécialiste de SQL Server bénéficiant de plus de 10 années d’expérience. Il a occupé plusieurs postes de prise en charge SQL Server, notamment en tant qu’administrateur de base de données, chef d’équipe, responsable et consultant. Actuellement, Zach est employé par Levi Strauss & Co. comme architecte administrateur de base de données ; son travail porte principalement sur les performances, la surveillance, l’architecture et d’autres initiatives stratégiques de SQL Server.


 SQL&#160;Server: Simplifiez la maintenance des bases de donn&#233;es avec les partitions de tables
SQL Server Noah Gomez

Simplifiez la maintenance des bases de données avec les partitions de tables
Vue d'ensemble:
  • Création de tables partitionnées
  • Ajout et fusion de partitions
  • Création et gestion d'index partitionnés
Télécharger le code de cet article: GomezPartitioning2007_03.exe (156KB)

Par le passé, les administrateurs de bases de données gérant des tables contenant des millions de lignes de données étaient forcés de créer plusieurs tables. Une fois ces tables partitionnées, l'administrateur devait relier
ces tables pendant l'exécution d'un grand nombre de leurs requêtes. La liaison des partitions impliquait la création d'une vue partitionnée ou d'une procédure de wrapper stockée qui découvrait l'emplacement des données et exécutait une autre procédure stockée pour atteindre uniquement les partitions nécessaires pour récupérer l'ensemble de données.
Ces méthodes fonctionnaient, mais elles étaient laborieuses. L'administration de plusieurs tables et de leurs index, de même que les méthodes utilisées pour relier les tables, provoquait souvent des problèmes d'administration et de maintenance. Par ailleurs, la création de tables multiples pour partitionner les données entraînait un certain degré de rigidité, car les procédures stockées, les tâches de maintenance, les tâches DTS (Data Transformation Services), le code d'application et d'autres processus devaient comprendre la nature du partitionnement. Donc, pour vous permettre d'ajouter ou de supprimer ces quasi-partitions sans modifier votre code, ces éléments étaient généralement créés d'une manière non-dynamique et étaient par conséquent inefficaces.
Les éditions Enterprise et Developer de SQL Server™ 2005 vous permettent de partitionner de grandes quantités de données contenues dans une seule table en plusieurs petites partitions pouvant être gérées plus efficacement. La possibilité de créer des segments de données consultés à partir d'un point d'entrée unique réduit un grand nombre des problèmes d'administration rencontrés avec les vieilles méthodes. L'utilisation d'un point d'entrée unique (nom de la table ou nom de l'index) masque les segments de données multiples pour le code d'application et permet à l'administrateur ou au développeur de modifier les partitions autant que nécessaire sans avoir à ajuster la base de code.
En bref, vous pouvez créer des partitions multiples, déplacer ces partitions, supprimer de vieilles partitions et même changer la façon dont les données sont partitionnées sans jamais avoir à ajuster le code dans votre application. Votre code d'application continue simplement à appeler le même nom de table ou d'index de base. Pendant ce temps, vous pouvez réduire la quantité des données contenues dans les index individuels, réduisant ainsi les temps de maintenance pour ces index, et vous pouvez augmenter la vitesse de chargement des données en les chargeant dans des partitions vides.
Techniquement, chaque table SQL Server 2005 est partitionnée ; chaque table contient au moins une partition. SQL Server 2005 permet aux administrateurs de bases de données de créer des partitions supplémentaires sur chaque table. Les partitions de tables et d'index sont des partitions au niveau des lignes (le partitionnement par colonne n'est pas autorisé) qui autorisent un point d'entrée unique (nom de table ou nom d'index) sans que le code d'application ait besoin de connaître le nombre de partitions derrière le point d'entrée. Les partitions peuvent exister sur la table de base, de même que les index associés à la table.

Création de tables partitionnées
Vous utilisez des fonctions de partition et des modèles de partition pour créer une table capable de croître au delà de la partition unique par défaut. Ces objets vous permettent de diviser les données dans des segments spécifiques et de contrôler l'emplacement de ces segments de données dans votre conception de stockage. Vous pouvez, par exemple, répartir les données sur plusieurs baies de lecteurs en fonction de l'âge des données ou en utilisant d'autres facteurs de différenciation courants. Notez qu'une table peut être partitionnée à partir d'une colonne de la table et que chaque partition doit contenir des données qui ne peuvent pas être placées dans d'autres partitions.
Fonctions de partition Lors du partitionnement d'une table, la première décision concerne la façon dont vous souhaitez diviser les données dans des segments différents. Une fonction de partition est utilisée pour mettre en correspondance les lignes de données individuelles dans les différentes partitions. Ces lignes de données individuelles peuvent être mises en correspondance avec n'importe quel type de colonne, à l'exception des types suivants : texte, ntext, image, xml, timestamp, varchar(max), nvarchar(max), varbinary(max), types de données alias et types de données définis par l'utilisateur CLR (Common Language Runtime). Cependant, la fonction de partitionnement doit pouvoir placer une ligne de données dans une seule partition de table. Elle ne peut pas permettre à une ligne de données d'appartenir à plusieurs partitions en même temps.
Afin de partitionner une table, vous devez créer la colonne de partitionnement dans la table ciblée. Cette colonne de partitionnement peut exister dans le modèle de table lors de la création de la table, ou vous pouvez modifier la table et ajouter la colonne à une date ultérieure. La colonne peut accepter des valeurs NULL, mais toutes les lignes contenant des valeurs NULL seront placées par défaut dans la partition la plus à gauche de la table. Vous pouvez éviter ceci en spécifiant que les valeurs NULL doivent être placées dans la partition la plus à droite de la table lorsque vous créez la fonction de partitionnement. L'utilisation de la partition gauche ou droite sera une décision de conception importante lorsque vous modifierez votre modèle de partitionnement et que vous ajouterez de nouvelles partitions ou supprimerez des partitions existantes.
Lors de la création d'une fonction de partitionnement, vous pouvez choisir une fonction de partition GAUCHE ou DROITE. La différence entre les partitions GAUCHE et DROITE concerne l'endroit où seront placées les valeurs de limite dans le modèle de partitionnement. Les partitions GAUCHES (par défaut) incluent la valeur de limite dans la partition tandis que les partitions DROITES placent la valeur de limite dans la partition suivante.
Pour comprendre ce concept un peu mieux, examinons des partitions GAUCHES et DROITES simples :
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

CREATE PARTITION FUNCTION Right_Partition (int) AS RANGE RIGHT
FOR VALUES (1,10,100)
Dans la première fonction (Left_Partition), les valeurs 1, 10, et 100 sont placées dans les première, deuxième, et troisième partitions, respectivement. Dans la deuxième fonction (Right_Partition), les valeurs sont placées dans les deuxième, troisième et quatrième partitions.
Lorsque vous créez une table partitionnée, il est important de faire en sorte que les partitions soient aussi homogènes que possible. Ceci vous aidera à comprendre l'espace nécessaire pour une partition. L'usage des partitions GAUCHES et DROITES déterminera l'emplacement des données, avant de déterminer la taille de la partition et la taille des éventuels index créés sur cette partition.
Vous pouvez déterminer le nombre de partitions dans lesquelles une valeur de données sera placée en utilisant la fonction $PARTITION, comme illustré ici :
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Right_Partition (10)
Dans la première instruction SELECT, le résultat sera 2. Le résultat de la seconde instruction SELECT sera 3.
Modèles de partition Après avoir créé la fonction et décidé de quelle façon vos données seront divisées, vous devez décider où les partitions individuelles seront créées sur votre sous-système de disque. Vous utilisez des modèles de partition pour créer cette disposition de disque. Les modèles de partition gèrent le stockage sur disque des partitions individuelles en utilisant des groupes de fichiers pour placer chaque partition dans un emplacement sur le sous-système de disque. Vous pouvez configurer les modèles de partition pour que toutes les partitions soient placées dans un seul groupe de fichiers, que toutes les partitions soient placées dans des groupes de fichiers différents ou que plusieurs partitions partagent des groupes de fichiers. Cette dernière méthode offre à l'administrateur de bases de données une grande flexibilité dans la répartition des E/S de disque.
La figure 1 montre certaines des façons dont vous pouvez attribuer un groupe de fichiers ou plusieurs groupes de fichiers à un modèle de partition. Vous devez être conscient que les groupes de fichiers utilisés par votre modèle de partition doivent déjà exister dans la base de données avant que vous ne créiez votre modèle de partitionnement.
Figure 1 Attribution de groupes de fichiers à un modèle de partition (Close Figure 1)
--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

--Place all partitions into the different filegroups
CREATE PARTITION SCHEME Different_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      TO (Filegroup1, Filegroup2, Filegroup3, Filegroup4)
--Filegroups must currently exist in database

--Place multiple partitions into the different filegroups
CREATE PARTITION SCHEME Multiple_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      TO (Filegroup1, Filegroup2, Filegroup1, Filegroup2)
--Filegroups must currently exist in database
Si vous créez les exemples de fonctions de partition comme illustré à la figure 1 et que vous utilisez le modèle de partition pour créer une table, vous pouvez déterminer ensuite où les lignes de données individuelles sont placées dans les tables que vous venez de partitionner. Vous pouvez alors afficher la distribution de ces lignes de données après leur insertion dans votre table partitionnée. Le code qui vous permet de faire tout ceci ressemblera à celui de la figure 2.
Figure 2 Placement de lignes de données et affichage de la distribution (Close Figure 2)
--Prepare database
IF OBJECT_ID('Partitioned_Table') IS NOT NULL
DROP TABLE Partitioned_Table
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
      ALL TO ([PRIMARY])

CREATE TABLE Partitioned_Table
(
col1 INT
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

--Determine where values will be placed (this is not required)
--You should try to do this before executing the code
SELECT $PARTITION.Left_Partition (1)
SELECT $PARTITION.Left_Partition (2)
SELECT $PARTITION.Left_Partition (3)
SELECT $PARTITION.Left_Partition (4)
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Left_Partition (11)
SELECT $PARTITION.Left_Partition (12)
SELECT $PARTITION.Left_Partition (13)
SELECT $PARTITION.Left_Partition (14)
SELECT $PARTITION.Left_Partition (100)
SELECT $PARTITION.Left_Partition (101)
SELECT $PARTITION.Left_Partition (102)
SELECT $PARTITION.Left_Partition (103)
SELECT $PARTITION.Left_Partition (104)

--Insert data into partitioned table
INSERT INTO Partitioned_Table VALUES (1,'Description')
INSERT INTO Partitioned_Table VALUES (2,'Description')
INSERT INTO Partitioned_Table VALUES (3,'Description')
INSERT INTO Partitioned_Table VALUES (4,'Description')
INSERT INTO Partitioned_Table VALUES (10,'Description')
INSERT INTO Partitioned_Table VALUES (11,'Description')
INSERT INTO Partitioned_Table VALUES (12,'Description')
INSERT INTO Partitioned_Table VALUES (13,'Description')
INSERT INTO Partitioned_Table VALUES (14,'Description')
INSERT INTO Partitioned_Table VALUES (100,'Description')
INSERT INTO Partitioned_Table VALUES (101,'Description')
INSERT INTO Partitioned_Table VALUES (102,'Description')
INSERT INTO Partitioned_Table VALUES (103,'Description')
INSERT INTO Partitioned_Table VALUES (104,'Description')

--View the distribution of data in the partitions
SELECT ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('Partitioned_Table')

Modification de tables partitionnées
Même si vous planifiez minutieusement, vous devrez parfois ajuster vos tables partitionnées après leur création et leur remplissage. Votre modèle de partition peut fonctionner comme prévu, mais vous pouvez, par exemple, avoir besoin d'ajouter de nouvelles partitions lorsque de nouvelles données sont accumulées, à moins que vous n'ayez besoin de supprimer de grandes quantités de données partitionnées à un moment donné. Heureusement, les tables partitionnées et les structures de partitionnement sous-jacentes permettent d'effectuer des modifications après l'entrée en service de la table et l'insertion des données.
Ajout de partitions De nombreux projets de partitionnement incluent la possibilité d'ajouter une nouvelle partition à une date ultérieure. Ce point dans le temps peut être une date particulière ou peut dépendre d'une valeur dans une colonne d'identité incrémentielle. Cependant, si vous n'avez pas prévu cette éventualité, vous pouvez toujours intervenir à une date ultérieure et ajouter de nouvelles partitions à une table partitionnée. Examinez la table créée à la figure 2. Vous pouvez ajouter une nouvelle partition à cette table pour contenir des valeurs supérieures à 500, comme ceci :
--Determine where values live before new partition
SELECT $PARTITION.Left_Partition (501)  --should return a value of 4

--Create new partition
ALTER PARTITION FUNCTION Left_Partition ()
SPLIT RANGE(500)

--Determine where values live after new partition
SELECT $PARTITION.Left_Partition (501)  --should return a value of 5
La capacité d'ajouter des partitions offre une grande flexibilité. La figure 3 montre comment ajouter une partition du côté gauche de la fonction. Dans ce cas, vous devez indiquer au modèle de partitionnement à quel endroit mettre la nouvelle partition puisque vous avez épuisé tous les groupes de fichiers créés au moment de la création du modèle de partitionnement. Bien que vous utilisiez le groupe de fichier PRIMARY pour toutes vos partitions, vous devez quand même dire au modèle de partitionnement de réutiliser le groupe de fichiers PRIMARY pour la nouvelle partition.
Figure 3 Ajout d'une partition du côté gauche de la fonction (Close Figure 3)
--Determine where values live after new partition
SELECT $PARTITION.Left_Partition (5)   --should return a value of 2
SELECT $PARTITION.Left_Partition (1)   --should return a value of 1
SELECT $PARTITION.Left_Partition (10)  --should return a value of 2

--Add new filegroups to the partitioning scheme
ALTER PARTITION SCHEME Primary_Left_Scheme
NEXT USED [PRIMARY]

--Create new partition
ALTER PARTITION FUNCTION Left_Partition ()
SPLIT RANGE(5)

--Determine where values live after new partition
SELECT $PARTITION.Left_Partition (5)   --should return a value of 2
SELECT $PARTITION.Left_Partition (1)   --should return a value of 1
SELECT $PARTITION.Left_Partition (10)  --should return a value of 3
Fusionner deux partitions SQL Server vous permet de supprimer les partitions d'une table tout en conservant les données. Cette fonctionnalité peut servir pour fusionner des données actives plus anciennes dans des données archivées ou pour réduire le nombre de partitions que vous avez, ce qui facilitera l'administration de la table partitionnée. Vous pouvez également utiliser cette fonctionnalité pour fusionner des partitions, en déplaçant les données d'un groupe de fichiers à un autre pour libérer de l'espace disque sur certains groupes de lecteurs. Le code de la figure 4 montre comment déplacer des données d'une partition vers une autre partition sur le même groupe de fichiers.
Figure 4 Déplacement de données d'une partition vers une autre (Close Figure 4)
--Prepare database
IF OBJECT_ID('multiple_partition') IS NOT NULL
DROP TABLE multiple_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

INSERT INTO multiple_partition VALUES (1,'Description')
INSERT INTO multiple_partition VALUES (2,'Description')
INSERT INTO multiple_partition VALUES (3,'Description')
INSERT INTO multiple_partition VALUES (4,'Description')
INSERT INTO multiple_partition VALUES (10,'Description')
INSERT INTO multiple_partition VALUES (11,'Description')
INSERT INTO multiple_partition VALUES (12,'Description')
INSERT INTO multiple_partition VALUES (13,'Description')
INSERT INTO multiple_partition VALUES (14,'Description')
INSERT INTO multiple_partition VALUES (100,'Description')
INSERT INTO multiple_partition VALUES (101,'Description')
INSERT INTO multiple_partition VALUES (102,'Description')
INSERT INTO multiple_partition VALUES (103,'Description')
INSERT INTO multiple_partition VALUES (104,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')

--Check where data would be placed
SELECT $PARTITION.Left_Partition (1)
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Left_Partition (100)
SELECT $PARTITION.Left_Partition (101)

--Merge two partitions
ALTER PARTITION FUNCTION Left_Partition()
MERGE RANGE (10)

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')

--Check where data would be placed
SELECT $PARTITION.Left_Partition (1)
SELECT $PARTITION.Left_Partition (10)
SELECT $PARTITION.Left_Partition (100)
SELECT $PARTITION.Left_Partition (101)
Transférer une table à partition unique vers une table partitionnée Pendant les routines de chargement, de grandes quantités de données doivent souvent être chargées dans la base de données, puis modifiées ou agrégées avant leur déplacement vers la table de données. Le partitionnement SQL Server 2005 vous permet de transférer une table à partition unique vers une table à plusieurs partitions. Cela signifie que vous pouvez charger des données dans une seule table de chargement, modifier ces données, puis transférer la table entière vers une table existante sans avoir à déplacer chaque ligne de données individuelle. Cette couche de partitionnement n'implique pas la modification des structures de partitionnement sous-jacentes. Elle implique la modification de la table partitionnée. Le code de la figure 5 vous indique comment y parvenir.
Figure 5 Déplacement d'une table entière vers une table existante (Close Figure 5)
--Prepare database
IF OBJECT_ID(‘multiple_partition’) IS NOT NULL
DROP TABLE multiple_partition
GO

IF OBJECT_ID(‘single_partition’) IS NOT NULL
DROP TABLE single_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = ‘Primary_Left_Scheme’)
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = ‘Left_Partition’)
DROP PARTITION FUNCTION Left_Partition
GO

--Create single partition table
CREATE TABLE single_partition
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
)

--Table must have a CHECK Constraint
ALTER TABLE single_partition
WITH CHECK
ADD CONSTRAINT CK_single_partition
    CHECK (col1 > 100)

INSERT INTO single_partition VALUES (101,’Description’)
INSERT INTO single_partition VALUES (102,’Description’)
INSERT INTO single_partition VALUES (103,’Description’)
INSERT INTO single_partition VALUES (104,’Description’)

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

INSERT INTO multiple_partition VALUES (1,’Description’)
INSERT INTO multiple_partition VALUES (2,’Description’)
INSERT INTO multiple_partition VALUES (3,’Description’)
INSERT INTO multiple_partition VALUES (4,’Description’)
INSERT INTO multiple_partition VALUES (10,’Description’)
INSERT INTO multiple_partition VALUES (11,’Description’)
INSERT INTO multiple_partition VALUES (12,’Description’)
INSERT INTO multiple_partition VALUES (13,’Description’)
INSERT INTO multiple_partition VALUES (14,’Description’)
INSERT INTO multiple_partition VALUES (100,’Description’)

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID(‘multiple_partition’), OBJECT_
      ID(‘single_partition’))

--Move the single table into the partitioned table
ALTER TABLE single_partition SWITCH TO multiple_partition PARTITION 4

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID(‘multiple_partition’), OBJECT_ID(‘single_partition’))
Déplacer une partition d'une table à une autre Le déplacement de données plus anciennes vers des tables d'archives séparées est une tâche administrative courante. Le processus d'archivage implique généralement une série d'instructions qui peuvent créer une utilisation de ressources supplémentaires dans vos journaux de transactions. Le transfert de propriété d'une partition d'une table à une autre, cependant, est un moyen facile d'archiver de grandes quantités de données sans les surcharges de journaux de transactions. Cette fonctionnalité permet à l'administrateur de base de données de déplacer des segments de données plus anciennes de leurs tables actives vers des tables archivées. Mais puisque les données ne sont en fait pas déplacées, le temps nécessaire peut être bien inférieur à celui du déplacement de lignes de données individuelles. La figure 6 vous indique comment y parvenir.
Figure 6 Déplacement de données plus anciennes vers des tables archivées (Close Figure 6)
--Prepare database
IF OBJECT_ID('active_data') IS NOT NULL
DROP TABLE active_data
GO

IF OBJECT_ID('archive_data') IS NOT NULL
DROP TABLE archive_data
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Active_Scheme')
DROP PARTITION SCHEME Active_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Active_Partition')
DROP PARTITION FUNCTION Active_Partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Archive_Scheme')
DROP PARTITION SCHEME Archive_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Archive_Partition')
DROP PARTITION FUNCTION Archive_Partition
GO

--Create active function
CREATE PARTITION FUNCTION Active_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Create archive function
CREATE PARTITION FUNCTION Archive_Partition (int) AS RANGE LEFT
FOR VALUES (100,200,300)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Active_Scheme
AS PARTITION Active_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Archive_Scheme
AS PARTITION Archive_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE active_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Active_Scheme (col1)

CREATE TABLE archive_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Archive_Scheme (col1)

INSERT INTO active_data VALUES (1,'Description')
INSERT INTO active_data VALUES (2,'Description')
INSERT INTO active_data VALUES (3,'Description')
INSERT INTO active_data VALUES (4,'Description')
INSERT INTO active_data VALUES (10,'Description')
INSERT INTO active_data VALUES (11,'Description')
INSERT INTO active_data VALUES (12,'Description')
INSERT INTO active_data VALUES (13,'Description')
INSERT INTO active_data VALUES (14,'Description')
INSERT INTO active_data VALUES (100,'Description')

INSERT INTO archive_data VALUES (200,'Description')
INSERT INTO archive_data VALUES (300,'Description')
INSERT INTO archive_data VALUES (400,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

--Switch ownership of partition to another table
ALTER TABLE active_data SWITCH PARTITION 3 TO archive_data PARTITION 1

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))
Utiliser une seule partition pour créer une nouvelle table Vous pouvez déplacer une seule partition d'une table partitionnée existante vers une table non partitionnée vide. Ce faisant, un administrateur de base de données peut exécuter une maintenance d'index sur la partition unique ou supprimer aisément de grandes quantités de données sans que ce processus de suppression ne soit enregistré. L'exemple de la figure 7 montre comment déplacer une partition dans une table vide, puis utiliser cette nouvelle table pour supprimer les données.
Figure 7 Déplacement et suppression de données (Close Figure 7)
--Prepare database
IF OBJECT_ID('active_data') IS NOT NULL
DROP TABLE active_data
GO

IF OBJECT_ID('archive_data') IS NOT NULL
DROP TABLE archive_data
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Active_Scheme')
DROP PARTITION SCHEME Active_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Active_Partition')
DROP PARTITION FUNCTION Active_Partition
GO

--Create active function
CREATE PARTITION FUNCTION Active_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Active_Scheme
AS PARTITION Active_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE active_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
) ON Active_Scheme (col1)

CREATE TABLE archive_data
(
col1 INT PRIMARY KEY CLUSTERED
,col2 VARCHAR(15)
)

INSERT INTO active_data VALUES (1,'Description')
INSERT INTO active_data VALUES (2,'Description')
INSERT INTO active_data VALUES (3,'Description')
INSERT INTO active_data VALUES (4,'Description')
INSERT INTO active_data VALUES (10,'Description')
INSERT INTO active_data VALUES (11,'Description')
INSERT INTO active_data VALUES (12,'Description')
INSERT INTO active_data VALUES (13,'Description')
INSERT INTO active_data VALUES (14,'Description')
INSERT INTO active_data VALUES (100,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

--Switch ownership of partition to another table
ALTER TABLE active_data SWITCH PARTITION 3 TO archive_data

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

--Drop all archive data without logging
DROP TABLE archive_data
GO

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] IN (OBJECT_ID('active_data'),OBJECT_ID('archive_
      data'))

Index partitionnés
La possibilité de partitionner les données d'une table s'accompagne de la possibilité de créer des index partitionnés. Ceci permet à l'administrateur de base de données de concevoir la structure d'index en fonction des données divisées plutôt que des données de l'ensemble de la table. La création d'index partitionnés donne des arborescences B individuelles sur les index partitionnés. La division des index a pour effet de créer des index plus petits qui sont plus faciles à gérer pour le moteur de stockage pendant la modification, l'ajout et la suppression de données. Ces index plus petits peuvent également être gérés de façon individuelle par l'administrateur de la base de données, ce qui permet une meilleure gestion des index sur de grands ensembles de données.
Création d'index partitionnés. Lorsque vous créez des index partitionnés, vous pouvez créer soit des index alignés soit des index non alignés. Pour les index alignés, vous créez l'index avec une relation directe avec les données partitionnées. (Pour les index non alignés, vous choisissez un modèle de partitionnement différent).
La méthode des index alignés est préférable et sera adoptée automatiquement si vous créez la table de partition avant de créer les index sans spécifier un modèle de partitionnement différent. L'utilisation d'index alignés vous offre la flexibilité de créer des partitions supplémentaires sur la table et la possibilité de faire passer la propriété d'une partition vers une autre table. Ces fonctionnalités sont souvent la raison pour laquelle les administrateurs de bases de données créent des tables partitionnées et le simple fait d'utiliser le modèle de partitionnement de la table pour vos index vous permettra sans doute d'atteindre vos objectifs de partitionnement.
Vous pouvez créer des index par rapport à des tables avec données d'index non alignées sur les données de la table. Si les données se trouvent dans une table partitionnée, ceci vous permettra de joindre les données de différentes façons (les données partitionnées peuvent être efficacement jointes à d'autres données partitionnées par l'optimiseur de requête). Vous pouvez aussi faire cela avec une table non partitionnée, ce qui vous permettra de créer un index partitionné (par rapport à la table de partition unique) et facilitera la gestion de l'index.
Le code de la figure 8 créera un index partitionné, non mis en cluster sur une table partitionnée. L'index non mis en cluster sera aligné sur la table et utilisera la colonne de partitionnement de la table en tant que clé d'index non mis en cluster.
Figure 8 Index partitionné, non mis en cluster sur table partitionnée (Close Figure 8)
--Prepare database
IF OBJECT_ID('multiple_partition') IS NOT NULL
DROP TABLE multiple_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
    ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT
,col2 VARCHAR(15)
) ON Primary_Left_Scheme (col1)

--Create partitioned non-clustered index
CREATE NONCLUSTERED INDEX cl_multiple_partition ON multiple_
      partition(col1)

INSERT INTO multiple_partition VALUES (1,'Description')
INSERT INTO multiple_partition VALUES (2,'Description')
INSERT INTO multiple_partition VALUES (3,'Description')
INSERT INTO multiple_partition VALUES (4,'Description')
INSERT INTO multiple_partition VALUES (10,'Description')
INSERT INTO multiple_partition VALUES (11,'Description')
INSERT INTO multiple_partition VALUES (12,'Description')
INSERT INTO multiple_partition VALUES (13,'Description')
INSERT INTO multiple_partition VALUES (14,'Description')
INSERT INTO multiple_partition VALUES (100,'Description')
INSERT INTO multiple_partition VALUES (101,'Description')
INSERT INTO multiple_partition VALUES (102,'Description')
INSERT INTO multiple_partition VALUES (103,'Description')
INSERT INTO multiple_partition VALUES (104,'Description')

--Verify partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')

--Verify index partitions
SELECT partition_id, index_id FROM sys.partitions pt
WHERE pt.[object_id] = OBJECT_ID('multiple_partition')
Le code de la figure 9 créera un index non aligné, non mis en cluster sur une table partitionnée. Cet index non mis en cluster utilisera des colonnes différentes pour sa clé d'index, lesquelles peuvent être utilisées dans des jointures assemblées par rapport à d'autres tables partitionnées.
Figure 9 Index non aligné, non mis en cluster sur table partitionnée (Close Figure 9)
--Prepare database
IF OBJECT_ID('multiple_partition') IS NOT NULL
DROP TABLE multiple_partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Primary_Left_Scheme')
DROP PARTITION SCHEME Primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_schemes
WHERE [name] = 'Index_primary_Left_Scheme')
DROP PARTITION SCHEME Index_primary_Left_Scheme
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Left_Partition')
DROP PARTITION FUNCTION Left_Partition
GO

IF EXISTS(SELECT [name] FROM sys.partition_functions
WHERE [name] = 'Index_Left_Partition')
DROP PARTITION FUNCTION Index_Left_Partition
GO

--Create partitioned index function
CREATE PARTITION FUNCTION Index_Left_Partition (int) AS RANGE LEFT
FOR VALUES (10,50,100)

--Create partitioned table
CREATE PARTITION FUNCTION Left_Partition (int) AS RANGE LEFT
FOR VALUES (1,10,100)

--Place all index partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Index_primary_Left_Scheme
AS PARTITION Index_Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

--Place all partitions into the PRIMARY filegroup
CREATE PARTITION SCHEME Primary_Left_Scheme
AS PARTITION Left_Partition
--Partition must currently exist in database
      ALL TO ([PRIMARY])

CREATE TABLE multiple_partition
(
col1 INT
,col2 INT
) ON Primary_Left_Scheme (col1)

--Create non-aligned partitioned nonclustered index
CREATE NONCLUSTERED INDEX cl_multiple_partition ON multiple_
     partition(col2)
ON Index_primary_Left_Scheme (col2)

INSERT INTO multiple_partition VALUES (1,10)
INSERT INTO multiple_partition VALUES (2,10)
INSERT INTO multiple_partition VALUES (3,10)
INSERT INTO multiple_partition VALUES (4,10)
INSERT INTO multiple_partition VALUES (10,50)
INSERT INTO multiple_partition VALUES (11,50)
INSERT INTO multiple_partition VALUES (12,50)
INSERT INTO multiple_partition VALUES (13,50)
INSERT INTO multiple_partition VALUES (14,50)
INSERT INTO multiple_partition VALUES (100,100)
INSERT INTO multiple_partition VALUES (101,100)
INSERT INTO multiple_partition VALUES (102,100)
INSERT INTO multiple_partition VALUES (103,100)
INSERT INTO multiple_partition VALUES (104,100)

--Verify row count on partitioned data
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')
AND p.index_id = 0

--Verify row count on partitioned index
--Row counts will not match those found in the data partitions
SELECT OBJECT_NAME(ps.[object_id])
,ps.partition_number
,ps.row_count
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.partitions p
ON ps.partition_id = p.partition_id
AND p.[object_id] = OBJECT_ID('multiple_partition')
AND p.index_id <> 0
Gestion d'index partitionnés Par le passé, l'exécution de la maintenance des index par rapport à de grandes tables contenant des millions voire des milliards de lignes de données prenait souvent beaucoup trop de temps pour les administrateurs de bases de données. Cette maintenance était souvent omise en raison du verrouillage des données pendant la reconstruction de l'index. Avec SQL Server 2005, l'administrateur de base de données peut réaliser la maintenance des index en ligne sans verrouiller la table sous-jacente pendant une période prolongée. Mais même cette approche (qui vous oblige à réaliser la maintenance des index pendant que les utilisateurs accèdent aux données) peut ralentir votre système en raison de l'utilisation des ressources. Une meilleure approche consiste à partitionner les index en segments plus petits avant de réaliser la maintenance des index par rapport à ces partitions plus petites. Par exemple, pour réaliser une maintenance des index par rapport à une partition d'index, vous pourriez simplement ajouter l'extrait de code ci-dessous à la fin du code illustré à la figure 8.
ALTER INDEX cl_multiple_partition
ON multiple_partition
REBUILD Partition = 2
Notez que la maintenance des index par rapport à des partitions d'index uniques doit être réalisée hors ligne et peut entraîner le verrouillage de la table pendant la maintenance des index. Pour empêcher ceci, vous pouvez transférer la partition unique vers une partition séparée, réaliser la maintenance des index, puis ramener la partition dans la table principale. Ce processus causera des problèmes de performances aux moments où la partition sera replacée dans la table et l'index en cluster mis à jour, mais ceci est moins problématique que le verrouillage de l'ensemble de la table et nécessite moins de ressources système.

Résumé
Comme vous pouvez le constater, le partitionnement de tables SQL Server 2005 offre une flexibilité considérablement améliorée pour le stockage et la maintenance des données dans de grandes tables, sans avoir à retravailler le code d'application ou les processus SQL Server. Grâce à ces capacités, SQL Server s'affirme comme une plate-forme robuste pour les bases de données stratégiques d'entreprise.

Noah Gomez est administrateur de base de donnés de développement SQL Server senior pour Verizon, société spécialisée dans les bases de données VLDB et les applications à grande échelle. Il est membre de la Professional Association for SQL Server (PASS) et faisait partie de l'équipe d'administrateurs de bases de données Verizon qui s'est consacrée aux bases de données VLDB multi-téraoctets qui ont remporté le grand prix Winter Corp. Top Ten en 2003.


 SQL&#160;Server: Astuces pour les clusters SQL Server
SQL Server Tom Moreau, PhD

Astuces pour les clusters SQL Server
Vue d'ensemble:
  • Exécution de SQL Server sur un cluster
  • Exigences matérielles et logicielles
  • Clustering d’un nœud
  • Options rentables

Un cluster de serveurs vous permet de connecter un certain nombre de serveurs physiques (ou nœuds) jouant le rôle de partenaires de basculement les uns envers les autres. La redondance offerte par un cluster permet de bénéficier d’une plus grande disponibilité pour vos opérations
critiques. J’ai mis en œuvre beaucoup de clusters au cours de mes 13 années de travail avec SQL Server™, et chacun avait ses problèmes spécifiques. Cette expérience m’a permis de rassembler un certain nombre d’astuces qui pourront vous aider.
Les clusters de serveurs tirent parti des capacités de clustering intégrées à la famille des éditions d’entreprise de Windows Server®. En fait, concernant le clustering, Windows Server 2003 est bien plus pratique que Windows 2000 Advanced Server. Pour maximiser les avantages que vous tirerez du clustering, vous avez besoin du matériel adéquat, et cela implique quelques dépenses. Rassembler deux serveurs via un disque partagé ne suffit pas, et vous ne pouvez pas compter sur le fait que les composants matériels individuels se trouveront peut-être dans le Catalogue Windows® (anciennement connu sous le nom de Liste de certification matérielle). Il faut que le système dans son intégralité se trouve dans le Catalogue de Windows. Toutefois, pas d’inquiétude : il existe des solutions plus économiques et approuvées. La figure 1 affiche une configuration de cluster typique.
Figure 1 Cluster typique
Figure 1 Cluster typique (Cliquer sur l'image pour la réduire)
Figure 1 Cluster typique
Figure 1 Cluster typique (Cliquer sur l'image pour l'agrandir)
Bien sûr, le clustering ne se limite pas au matériel, il faut également que vous choisissiez la bonne édition de SQL Server 2005. L’édition d’entreprise permet le clustering et compte d’autres fonctionnalités utiles, telles que la capacité d’exploiter davantage d’unités centrales, des affichages partitionnés distribués qui peuvent être mis à jour, l’envoi de journaux intégrés et l’utilisation automatique d’affichages indexés. Si vous avez déjà une licence d’édition d’entreprise, je vous conseille de considérer le clustering, que vous disposiez ou non des deux à huit serveurs nécessaires pour former un cluster traditionnel (nous allons parler des clusters à un nœud dans quelques instants). Si vous disposez de SQL Server 2005 Standard Edition, vous pouvez installer un cluster à deux nœuds.
Les éditions Windows Server 2003 Enterprise et Datacenter sont fournies avec un clustering intégré. Il vous suffit d’exécuter l’Administrateur de cluster pour configurer votre cluster. Vous pouvez ajouter tous les nœuds en même temps, ou les ajouter un par un. De même, lorsque vous installez SQL Server, vous pouvez choisir une installation sur un serveur individuel sans cluster ou l’installation d’une instance virtuelle sur un cluster. Si vous choisissez d’installer une instance virtuelle, vous pouvez procéder à une installation sur tous les nœuds du cluster, certains nœuds uniquement ou même un seul nœud.
Enfin, pour atteindre le véritable objectif du clustering (la haute disponibilité), vous aurez besoin de personnel qualifié et de procédures éprouvées en cas de problème. Bien que le clustering constitue une bonne assurance contre les échecs matériels, il n’empêche pas les erreurs d’utilisateurs (comme la suppression d’une table critique par un administrateur de base de données épuisé, au beau milieu de la nuit).

Clusters à un nœud
Même si tout ce dont vous avez besoin est un serveur unique, considérez la création d’un cluster à un nœud. Ceci vous donne la possibilité de passer à un cluster ultérieurement et donc d’éviter une reconstruction. Assurez-vous juste que le matériel choisi se trouve sur la portion de cluster du Catalogue de Windows.
Ce n’est pas uniquement pour une question de disponibilité élevée que l’option d’ajouter un nœud ultérieurement peut s’avérer utile. Imaginez ce qui arrive si vous vous rendez compte que votre serveur n’a tout simplement pas la capacité nécessaire. Une migration est alors inévitable, avec le temps et les efforts associés. Si vous avez un cluster d’un nœud, la migration est plus facile et l’interruption bien moins longue. Vous ajoutez le nouveau nœud au groupe, les binaires SQL Server et les service packs au nouveau nœud, puis vous basculez vers le nouveau mode. Ensuite, vous ajoutez les mises à jour de service packs post-service, le cas échéant, et enfin, vous vous débarrassez de l’ancien nœud. Le temps d’interruption est limité au temps nécessaire au basculement et à l’ajout des mises à jour (le cas échéant).

Ajout de nœuds
Étant donné que tous les nœuds d’un cluster doivent être identiques, il est conseillé de récupérer ce nœud supplémentaire le plus vite possible. Si vous attendez trop longtemps, le nœud ne sera peut-être plus produit. Sur un projet, j’ai eu à reconstruire un nœud dans un cluster SQL Server 2000. J’ai demandé à l’administrateur système d’exploitation/réseau de gérer la construction de base, puis j’ai rajouté celle-ci au cluster et je l’ai préparée au fonctionnement en tant que nœud SQL Server. Tout s’est bien passé, jusqu’au basculement vers le nouveau nœud. À mon grand désarroi, il est repassé immédiatement à l’ancien. Pour résumer, j’avais préparé un document détaillé sur la construction d’un nouveau cluster, y compris l’addition du service de cluster et des comptes de service SQL Server aux deux nœuds, mais celui-ci n’avait pas été suivi explicitement. L’administrateur n’avait pas ajouté les comptes de service au nœud reconstruit, et les privilèges dont ils disposaient avant la reconstruction n’existaient donc plus.
J’ai mis du temps à comprendre ce qui s’était passé. Un jour, j’ai songé à examiner les appartenances de groupes locaux. Une fois les deux comptes ajoutés, le basculement s’est fait sans problème. Et puis j’ai réfléchi. La reconstruction d’un nœud, ce n’est pas quelque chose que l’on fait fréquemment ; c’est quelque chose que l’on fait dans l’urgence. J’avais un document, mais il n’avait pas été utilisé. Nous aurions pu automatiser la partie sécurité en écrivant un script bref pour ajouter ces deux comptes et apporter les autres personnalisations nécessaires. Heureusement, les choses se sont améliorées dans SQL Server 2005. Le programme d’installation vous demande de configurer des groupes niveau domaine pour les comptes de service SQL Server.
Bien sûr, ceci m’a fait réfléchir encore plus. Vous pouvez créer des scripts invoquant CLUSTER.EXE pour ajouter le nœud à votre cluster Microsoft® Cluster Server (MSCS). Tout ce que vous avez à faire, c’est de fournir au script le nom du nœud, il s’occupe du reste. En cas d’urgence, l’automatisation est votre meilleure amie.

Clusters N + 1
Parfois, ce n’est pas parce que vous remplacez un nœud que vous ajoutez un nœud à un cluster. Vous pourriez par exemple être en train d’ajouter des instances SQL Server à votre cluster, chaque instance ayant besoin de ressources de disque séparées. Bien que des instances multiples puissent s’exécuter sur un nœud unique, elles partageraient l’unité centrale et la RAM, ce qui pourrait engendrer des performances médiocres. L’idéal est qu’une seule instance s’exécute sur un seul nœud. Comment garantir ceci lorsque vous procédez au basculement ? La réponse est simple : il y a un nœud sur lequel ne s’exécutent aucun services, tandis que les autres exécutent chacun une instance de SQL Server. En fait, il s’agit là de la définition d’un cluster N + 1 : N instances s’exécutant sur N + 1 nœuds. Le nœud supplémentaire est la sauvegarde.

Mise à niveau de SQL Server
La mise à niveau d’une instance clusterisée de SQL Server n’est pas une mince affaire, car il est clusterisé pour une raison : vous avez besoin de disponibilité. Toutefois, SQL Server 2005 offre un certain nombre d’améliorations très intéressantes ; si vous décidez donc de procéder à la mise à niveau, le temps d’interruption ne sera pas important.
Quelles sont vos options ? Regardons tout d’abord la solution la plus chère : la création d’un nouveau cluster, ce qui signifie de nouveaux serveurs et peut-être un nouveau réseau de stockage SAN (storage area network). Vous pourrez probablement conserver les commutateurs de réseau existant, mais c’est à peu près tout. Évidemment, cette approche n’est pas très économique, mais elle présente des avantages. Le nouveau matériel fonctionne généralement beaucoup mieux que l’ancien, la capacité de disque et la vitesse augmentant en permanence. Ainsi, le matériel lui-même vous permet déjà d’obtenir de meilleures performances. Vous choisirez même peut-être de louer votre équipement afin d’être toujours à la pointe du progrès.
Une fois le matériel en place, vous pouvez créer votre nouveau SQL Server virtuel sur cette installation, y copier vos bases de données de production et lancer le nouveau système, ce qui vous laisse le temps nécessaire pour vous débarrasser des bogues avant le changement définitif. N’oubliez pas de scripter les connexions à partir de votre serveur existant. (Voir support.microsoft.com/kb/246133. Je vous conseille également de mettre à jour votre script de génération de connexion en cas de défaillance catastrophique).
Pour réduire au maximum le temps d’interruption, vous devrez probablement utiliser l’envoi de journaux, à moins que vos bases de données ne soient assez petites et que vous disposiez d’une période pendant laquelle aucun utilisateur n’est connecté. Vous pouvez procéder à l’envoi de journaux juste avant le changement définitif. Ensuite, chassez les utilisateurs, envoyez le journal final, puis pointez l’application vers la nouvelle instance. (Consultez la section sur la mise en miroir de la base de données, ci-dessous, pour obtenir une alternative intéressante à l’envoi de journaux). Si vous utilisez des alias DNS, vous n’aurez sans doute même pas besoin de pointer les applications vers la nouvelle instance. Contentez-vous de mettre à jour l’alias DNS. Cette approche présente un avantage : si vous vous lancez dans une migration et que vous devez revenir à l’original en cours de route, vous avez l’original.
Vous pouvez choisir une voie moins coûteuse, mais cela requiert une planification préalable plus approfondie. Un cluster peut prendre en charge plusieurs instances de SQL Server, mais chaque instance doit disposer de ses propres ressources disque. Lorsque vous configurez votre SAN, mettez un LUN de côté pour une mise à niveau future. Pour exécuter la mise à niveau, installez les binaires SQL Server sur cette ressource disque. Vous pouvez exercer le système et, lorsque vous êtes prêt, arrêter le SQL Server actuel, déplacer les ressources disque de l’ancien groupe SQL Server, mettre à jour les dépendances, et mettre en ligne la nouvelle instance de SQL Server. Attachez les bases de données à partir de l’ancienne instance, et vous y êtes. (Vous avez effectué des copies de sauvegarde auparavant, n’est-ce pas ?)
Il s’agit là de l’approche la moins coûteuse, mais elle comporte quelque risques. En cas de problème, vous ne pouvez pas détacher les bases de données de la nouvelle instance et les remettre. Vous serez alors réduit à restaurer des copies de sauvegarde, ce qui peut impliquer un temps d’interruption important.
Vous pouvez également placer deux instances de SQL Server sur votre SAN, si vous disposez de suffisamment d’espace. Vous restaurez les sauvegardes de production (et l’envoi de journaux) sur la nouvelle instance, et procédez comme indiqué plus tôt. Vous disposez cependant à présent de ressources de secours. Une fois la migration terminée, vous pouvez libérer les ressources SAN de l’ancienne instance. Cela vous coûtera uniquement le prix des disques supplémentaires.

Équilibrage de la charge
Commençons par éliminer une idée fausse très courante. Vous utilisez le clustering MSCS pour obtenir une disponibilité élevée, pas pour l’équilibrage de la charge. En outre, SQL Server ne dispose pas de capacité d’équilibrage de la charge intégrée. Vous devez équilibrer la charge via la conception physique de votre application. Qu’est-ce que cela signifie ?
À mesure qu’un tableau grandit, vous risquez de voir des dégradations des performances, particulièrement lorsque des analyses de tableaux sont impliquées. Lorsqu’il y a des millions, voire des milliards de lignes, la solution traditionnelle consiste généralement à utiliser des affichages partitionnés, constitués de tableaux aux schémas identiques rassemblés avec UNION ALL’s. En outre, des contraintes CHECK sont mises à sa place pour différencier les tableaux membres, et ceci empêche la duplication des données sur l’affichage partitionné. Si la colonne qui est utilisée dans la contrainte CHECK fait également partie de la clé principale, il est possible de mettre l’affichage à jour.
Si les tableaux membres se trouvent dans leurs propres groupes de fichiers, vous obtiendrez peut-être de meilleures performances de disque si les fichiers de ces groupes sont sur des lecteurs physiques séparés. Les tableaux peuvent même se trouver dans des bases de données séparées. Dans SQL Server 2005, cependant, tant que toutes les données se trouvent dans la même base de données, vous pouvez utiliser le partitionnement de tableau, bien plus facile à mettre en œuvre.
Mais imaginons que vous ayez essayé le partitionnement de tableau ou les affichages partitionnés (locaux), et que le fonctionnement soit toujours lent. Si vous avez SQL Server 2000 ou SQL Server 2005, vous pouvez utiliser des affichages partitionnés distribués. La différence majeure est que les tableaux membres peuvent résider sur différentes instances de SQL Server et que ces instances peuvent être installées sur un cluster N + 1. En quoi cela est-il une bonne idée ? Si un tableau membre se retrouve hors ligne dans un affichage partitionné, l’intégralité de l’affichage passe hors ligne. En intégrant ces membres à un cluster, vous disposez de la fiabilité dont vous avez besoin pour les performances et l’équilibrage de la charge.

Avez-vous vraiment besoin d’un cluster ?
Il est possible que vous disposiez de serveurs supplémentaires, mais qu’ils ne se trouvent pas dans le Catalogue Windows pour les clusters. Il serait dommage d’acheter de nouveaux serveurs pour prendre en charge un cluster lorsque ces serveurs sont disponibles.
Dans ce cas, la mise en miroir de la base de données peut constituer une alternative intéressante au clustering. La mise en miroir implique trois éléments : l’instance hébergeant la base de données miroir est l’instance principale ; le serveur de sauvegarde est le miroir, et si vous voulez un basculement automatique, un troisième serveur (témoin) est requis. Brièvement, une transaction dans une base de données sur l’instance principale est de nouveau exécutée sur le miroir. Si l’instance principale a un problème, la base de données peut basculer sur le miroir, de façon automatique si vous avez un témoin. Vous devrez configurer la mise en miroir pour chacune de vos bases de données d’applications, et vous ne pouvez pas mettre en miroir les bases de données système.
Le miroir est une instance séparée de SQL Server, ce qui n’est pas le cas dans un cluster, et peut être situé à des milliers de kilomètres de là. Ses mémoires cache sont remplies par l’activité de mise à jour résultant des transactions dupliquées à partir de l’instance principale. Nous partons bien sûr du principe qu’il n’y a pas d’activités sur le miroir autres que la réception des transactions reflétées à partir de l’instance principale. Le basculement est généralement plus rapide que dans un cluster, puisque SQL Server s’exécute déjà sur le miroir. Étant donné que les mémoires cache sont au moins partiellement amorcées, les performances initiales ne sont pas aussi lentes qu’elles pourraient l’être avec un cluster. En outre, lorsqu’une base de données miroir bascule, les rôles de l’instance principale et du miroir sont inversés.
L’inconvénient de la mise en miroir de base de données est qu’elle nécessite deux fois plus de capacité de disque que si vous choisissez le scénario avec le cluster. Vous aurez également besoin de davantage d’UC si vous choisissez un mode synchrone sans perte de données. Je le répète, la haute disponibilité n’est pas bon marché.

Une approche combinée
Puisqu’un miroir peut être situé assez loin de l’instance principale, il s’agit là d’un bon candidat pour les plans de récupération après incident. Votre cluster peut constituer votre première ligne de défense, mais que se passe-t-il si vous utilisez à la fois un cluster et une mise en miroir ? Dans un basculement sur cluster, si vous disposez d’un témoin dans votre configuration de mise en miroir, le miroir deviendra l’instance principale pendant que le SQL Server en cluster se met en ligne. Cependant, le basculement de la nouvelle instance principale vers le nouveau miroir (en cluster) n’est pas automatique. Par conséquent, il vaut mieux ne pas activer le basculement automatique pour vos bases de données en miroir lorsqu’elles sont utilisées conjointement à un cluster.
Les plans de récupération après incident ne sont pas la seule raison pour laquelle vous pourriez utiliser une mise en miroir ; celle-ci s’avère également utile si vous avez à appliquer un service pack ou un correctif à votre instance principale, auquel cas vous pouvez basculer manuellement vers votre miroir. Pendant que vous appliquez le service pack ou le correctif, l’ancien serveur principal se retrouve temporairement hors ligne et les transactions validées survenant sur la nouvelle instance principale sont mises en file d’attente, avant d’être renvoyées au nouveau miroir (ancienne instance principale). Une fois l’installation du service pack ou du correctif terminée, la synchronisation a lieu et les deux serveurs se trouvent alors complètement synchronisés. Maintenant, vous pouvez échanger les rôles d’instance principale et de miroir. Le temps d’interruption est limité aux quelques secondes nécessaires pour les deux basculements. Vous pouvez utiliser cette approche pour migrer votre SQL Server vers une autre boîte. Ne rebasculez pas ensuite, c’est tout.

Un serveur virtuel permet de bénéficier de davantage de flexibilité
La virtualisation vous permet d’exécuter un ou plusieurs systèmes d’exploitation simultanément sur un serveur physique unique. Le logiciel de virtualisation rajoute une couche de capacités au concept de cluster, car vous pouvez clusteriser le logiciel. Par conséquent, si le serveur sur lequel l’hôte exécute échoue, ce serveur (et ses systèmes d’exploitation invités) basculent vers un nœud de sauvegarde. Ceci peut permettre de migrer un serveur invité très facilement. En outre, le système d’exploitation invité n’a pas besoin d’être compatible avec un cluster. Vous pourriez ainsi exécuter SQL Server Workgroup Edition dans un Windows Server 2003 invité, s’exécutant sur Microsoft Virtual Server 2005 sur un cluster. Indirectement, vous avez clusterisé Workgroup Edition (voir la figure 2).
Figure 2 Utilisation d’un serveur virtuel
Figure 2 Utilisation d’un serveur virtuel (Cliquer sur l'image pour la réduire)
Figure 2 Utilisation d’un serveur virtuel
Figure 2 Utilisation d’un serveur virtuel (Cliquer sur l'image pour l'agrandir)

Responsable
Si vous êtes responsable d’une mise en œuvre SQL Server, il faut que votre serveur soit disponible en continu. Le clustering vous aide à vous en assurer. Cet article contient quelques bons conseils pour vous aider à démarrer, et vous trouverez d’autres informations utiles dans la barre latérale « Ressources de clustering ».
Ressources de clustering
Pour plus d’informations sur les méthodes utilisées ici et les divers produits dont vous avez besoin pour configurer votre cluster SQL Server, reportez-vous aux ressources suivantes :
  • SQL Server 2005 Failover Clustering (en anglais)
  • SQL Server 2000 Failover Clustering (en anglais)
  • Windows Server 2003 R2 Enterprise Edition–Cluster Server (en anglais)
  • Microsoft Cluster Server Administrator’s Guide (en anglais)
  • Microsoft Virtual Server 2005 R2

Tom Moreau, PhD, BSc, PhD, MCSE, MCDBA, est un consultant indépendant spécialisé dans l’administration, la conception et la mise en œuvre des bases de données SQL Server ; il est basé dans la région de Toronto. Tom utilise SQL Server depuis 1993 et est MVP depuis 2001. Il a rédigé plus de 100 articles et co-écrit un livre sur SQL Server. Merci à Geoff Hiten, MVP SQL Server, pour son aide.


 Administration de Windows: Dans le noyau de Windows&#160;Vista&#160;: 2&#232;me partie
Administration de Windows Mark Russinovich

Dans le noyau de Windows Vista : 2ème partie
Vue d'ensemble:
  • Gestion de la mémoire
  • Démarrage et arrêt
  • Gestion de l'alimentation

Le mois dernier, dans le premier article de cette série en trois épisodes, j'ai présenté les améliorations du noyau de Windows Vista au niveau des processus et d'E/S.
Cette fois, je vais aborder les avancées dans la façon dont Windows Vista gère la mémoire, ainsi que les améliorations majeures du démarrage et de l'arrêt du système, ainsi que de la gestion de l'alimentation (1e partie).
Chaque version de Windows® améliore l'évolutivité et les performances, et Windows Vista™ n'échappe pas à la règle. Le gestionnaire de mémoire de Windows Vista présente de nombreuses améliorations, telles qu'une utilisation plus étendue de techniques de synchronisation sans verrouillage, un verrouillage plus fin, une compression supérieure des structures de données, des E/S d'échange plus grandes, la prise en charge d'architectures de mémoire de cartes vidéo modernes et une utilisation plus efficace du tampon de traduction matériel. De plus, la gestion de la mémoire de Windows Vista offre maintenant une allocation de l'espace d'adressage dynamique pour les exigences de charges de travail différentes.
Quatre fonctionnalités d'amélioration des performances qui utilisent de nouvelles technologies sont utilisées pour la première fois dans un système d'exploitation sur Windows Vista : SuperFetch, ReadyBoost, ReadyBoot et ReadyDrive. Je les étudierai en détail plus loin dans cet article.

Espace d'adressage du noyau dynamique
Windows et les applications qui s'exécutent dessus ont dû faire face aux limites d'espace d'adressage des processeurs 32 bits. Le noyau Windows est limité par défaut à 2 Go, ou à la moitié de l'espace d'adressage virtuel 32 bits total, l'autre moitié étant réservée au processus dont le thread s'exécute actuellement sur le processeur. Dans sa moitié, le noyau doit se mapper, mapper les pilotes de périphérique, le cache du système de fichiers, les piles du noyau, les structures de données de code par session et les tampons à la fois non paginés (verrouillés dans la mémoire physique) et paginés alloués par les pilotes de périphérique. Avant Windows Vista, le gestionnaire de mémoire déterminait au moment du démarrage la quantité d'espace d'adressage à attribuer à ces objectifs différents, mais cette rigidité provoquait parfois des situations dans lesquelles l'une des zones devenait pleine alors que les autres possédaient encore plein d'espace disponible. L'épuisement d'une zone peut entraîner des échecs d'application et empêcher les pilotes de périphérique de terminer les opérations d'E/S.
Dans Windows Vista 32 bits, le gestionnaire de mémoire gère l'espace d'adressage du noyau de façon dynamique, en allouant et en libérant de l'espace pour diverses utilisations en fonction des exigences de la charge de travail. Ainsi, la quantité de mémoire virtuelle utilisée pour stocker des tampons paginés peut augmenter lorsque les pilotes de périphérique en ont besoin et rétrécir lorsque les pilotes la libèrent. Windows Vista pourra donc gérer une plus grande variété de charges de travail et, de la même manière, la version 32 bits du prochain Windows Server® au nom de code « Longhorn », sera en mesure de gérer davantage d'utilisateurs de Terminal Server.
Bien sûr, sur les systèmes Windows Vista 64 bits, les contraintes d'espace d'adressage ne constituent pas actuellement une limitation pratique et ne nécessitent donc pas de traitement spécial puisqu'elles sont configurées à leur maximum.

Priorités de mémoire
Tout comme il ajoute des priorités d'E/S (comme je l'ai expliqué dans le dernier article), Windows Vista implémente également des priorités de mémoire. Pour comprendre comment Windows utilise les priorités de mémoire, il faut comprendre comment le gestionnaire de mémoire implémente son cache de mémoire, appelé Liste En attente. Sur toutes les versions de Windows antérieures à Windows Vista, lorsqu'une page physique (dont la taille est généralement de 4 Ko) appartenant à un processus était récupérée par le système, le gestionnaire de mémoire la plaçait généralement à la fin de la liste En attente. Si le processus souhaitait accéder à nouveau à la page, le gestionnaire de mémoire prenait la page dans la liste En attente et la réaffectait au processus. Lorsqu'un processus souhaitait utiliser une nouvelle page de la mémoire physique et qu'il n'y avait pas de mémoire disponible, le gestionnaire de mémoire donnait au processus la page figurant au début de la liste En attente. Ce schéma traitait toutes les pages en attente de la même façon, en utilisant uniquement l'heure à laquelle elles avaient été placées dans la liste pour les trier.
Sur Windows Vista, chaque page de mémoire a une priorité comprise entre 0 et 7, et donc le gestionnaire de mémoire divise la liste En attente en huit listes qui contiennent chacune des pages d'une priorité particulière. Lorsque le gestionnaire de mémoire veut prendre une page dans la liste En attente, il commence par prendre les pages à priorité basse. La priorité d'une page reflète habituellement la priorité du thread qui entraîne son allocation à l'origine. (Si la page est partagée, elle reflète la priorité de mémoire la plus élevée des threads en partage). Un thread hérite sa valeur de priorité de page du processus auquel il appartient. Le gestionnaire de mémoire utilise des priorités basses pour les pages qu'il lit à partir du disque en spéculant lorsqu'il anticipe des accès à la mémoire d'un processus.
Par défaut, les processus ont une valeur de priorité de page de 5, mais des fonctions permettent aux applications et au système de modifier les valeurs de priorité de page des processus et des threads. Il n'est possible de réaliser la véritable puissance des priorités de mémoire que lorsqu'on comprend les priorités relatives des pages à un niveau macro, ce qui est le rôle de SuperFetch.

SuperFetch
La façon dont le gestionnaire de mémoire gère la mémoire physique représente un changement important. La gestion de la liste En attente utilisée par des versions antérieures de Windows a deux limites. Premièrement, la priorisation des pages repose uniquement sur le comportement antérieur récent des processus et elle ne prévoit pas leurs besoins de mémoire futurs. Deuxièmement, les données utilisées pour la priorisation sont limitées à la liste des pages appartenant à un processus à un moment donné. Ces lacunes peuvent entraîner des scénarios du type « syndrome post-déjeuner » (quand vous vous absentez de votre ordinateur pendant un moment et qu'une application de système sollicitant beaucoup de mémoire est exécutée (par exemple, une analyse antivirus ou une défragmentation du disque). Cette application remplace le code et les données que vos applications actives avaient mis en cache dans la mémoire par les activités sollicitant la mémoire. À votre retour, vous trouvez que les performances sont ralenties étant donné que les applications doivent récupérer leurs données et code sur le disque.
Windows XP a introduit une prise en charge de prérécupération qui améliorait les performances de démarrage et de lancement des applications en exécutant de grandes E/S de disque pour précharger la mémoire avec le code et les données de système de fichiers attendues, en fonction des redémarrages et lancements d'applications précédents. Windows Vista va encore plus loin avec SuperFetch, un mode de gestion de la mémoire qui améliore l'approche de l'accès le moins récent avec des informations historiques et une gestion proactive de la mémoire.
SuperFetch est implémenté dans %SystemRoot%\System32\Sysmain.dll en tant que service Windows qui s'exécute dans un processus Hôte de service (%SystemRoot%\System32\Svchost.exe). Ce mode s'appuie sur la prise en charge du gestionnaire de mémoire pour récupérer les historiques d'utilisation des pages, ainsi que pour demander au gestionnaire de mémoire de précharger des données et du code à partir de fichiers du disque ou d'un fichier de pagination de la liste En attente et attribuer des priorités aux pages. Le service SuperFetch étend en fait le suivi des pages aux données et au code qui étaient auparavant dans la mémoire, mais que le gestionnaire de mémoire a réutilisés pour faire de la place à de nouvelles données et du nouveau code. Il stocke ces informations dans des fichiers de scénario ayant une extension .db dans le répertoire %SystemRoot%\Prefetch, en compagnie des fichiers de prérécupération standard utilisés pour optimiser le lancement des applications. Grâce à cette connaissance approfondie de l'utilisation de la mémoire, SuperFetch peut précharger les données et le code lorsque la mémoire physique devient disponible.
Lorsque de la mémoire se libère (par exemple, lorsqu'une application se ferme ou qu'elle libère de la mémoire), Superfetch demande au gestionnaire de mémoire d'extraire les données et le code qui viennent d'être expulsés. Ceci se produit à un rythme de quelques pages par seconde avec des E/S de priorité très basse pour que le préchargement n'ait aucun impact sur l'utilisateur ou d'autres applications actives. Par conséquent, si vous quittez votre ordinateur le temps d'aller déjeuner et qu'une tâche d'arrière-plan sollicitant beaucoup de mémoire entraîne l'expulsion du code et des données de vos applications actives de la mémoire pendant votre absence, SuperFetch peut souvent les ramener, ou en ramener la majeure partie, dans la mémoire avant votre retour. SuperFetch inclut également une prise en charge des scénarios spécifique pour la veille prolongée, la veille, le changement rapide d'utilisateur et le lancement d'application. Lorsque le système passe en mode de veille prolongée, par exemple, SuperFetch stocke les données et le code dans le fichier de veille prolongée qui, selon ses estimations (en fonction des veilles prolongées précédentes), sera consulté au cours de la reprise à venir. Par comparaison, lorsque vous reprenez Windows XP, les données qui avaient été mises en cache doivent être relues à partir du disque lors du référencement.
Consultez l'encadré « Observation de SuperFetch » pour un aperçu de l'impact de SuperFetch sur la mémoire disponible.
Observation de SuperFetch
Après avoir utilisé un système Windows Vista pendant un moment, vous verrez un numéro peu élevé pour le compteur de mémoire physique libre sur la page des performances du gestionnaire des tâches. Cela est du au fait que SuperFetch et la mise en cache Windows standard utilisent toute la mémoire physique disponible pour mettre en cache les données du disque. Par exemple, lors du premier démarrage, si vous exécutez tout de suite le Gestionnaire des tâches, vous devriez remarquer que la valeur de la mémoire libre diminue à mesure que la valeur de la mémoire mise en cache augmente. Autre exemple : si vous exécutez un programme sollicitant beaucoup de mémoire et que vous le fermez ensuite (n'importe quel logiciel gratuit « optimisateur de RAM » allouant de grandes quantités de mémoire et libérant ensuite la mémoire fera l'affaire) ou que vous copiez simplement un très gros fichier, la valeur de la mémoire libre augmentera et le graphique d'utilisation de la mémoire physique chutera lorsque le système récupèrera la mémoire libérée. Toutefois, SuperFetch réalimente progressivement le cache avec les données qui ont été expulsées de la mémoire, de sorte que la valeur de mise en cache augmentera et celle de la mémoire disponible déclinera.
Observation de la mémoire
Observation de la mémoire (Cliquer sur l'image pour la réduire)
Observation de la mémoire
Observation de la mémoire (Cliquer sur l'image pour l'agrandir)

ReadyBoost
La vitesse des processeurs et de la mémoire sont en train de dépasser rapidement celles des disques durs, si bien que les disques constituent un goulot d'étranglement courant des performances du système. Les E/S de disque aléatoires sont particulièrement chères car les temps de recherche des têtes de disques sont de l'ordre de 10 millisecondes, une éternité pour les processeurs de 3 GHz d'aujourd'hui. La mémoire vive est idéale pour mettre en cache les données de disque, mais elle est relativement chère. La mémoire flash, en revanche, est généralement meilleur marché et propose les lectures aléatoires jusqu'à 10 fois plus vite qu'un disque dur classique. Windows Vista inclut donc une fonctionnalité appelée ReadyBoost qui tire parti des périphériques de stockage à mémoire flash en créant sur eux une couche de mise en cache intermédiaire qui repose logiquement entre la mémoire et les disques.
ReadyBoost consiste en un service implémenté dans %SystemRoot%\System32\Emdmgmt.dll qui s'exécute dans un processus Hôte de service et un pilote de filtre de volume, %SystemRoot%\System32\Drivers\Ecache.sys. (Emd est l'abréviation de External Memory Device, périphérique de mémoire externe, le nom de ReadyBoost pendant son développement). Lorsque vous insérez un périphérique flash tel qu'une clé USB dans un système, le service ReadyBoost étudie le périphérique pour déterminer ses caractéristiques de performances et stocke les résultats de son test dans HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt, illustré à la figure 1.
Figure 1 Résultats du test du périphérique réalisé par ReadyBoost dans le Registre
Figure 1 Résultats du test du périphérique réalisé par ReadyBoost dans le Registre (Cliquer sur l'image pour la réduire)
Figure 1 Résultats du test du périphérique réalisé par ReadyBoost dans le Registre
Figure 1 Résultats du test du périphérique réalisé par ReadyBoost dans le Registre (Cliquer sur l'image pour l'agrandir)
Si vous n'utilisez pas déjà un périphérique pour la mise en cache et que la taille du nouveau périphérique est comprise entre 256 Mo et 32 Go, qu'il a un taux de transfert de 2,5 Mo/s ou plus pour des lectures aléatoires de 4 Ko et que son taux de transfert est de 1,75 Mo/s ou plus pour des écritures aléatoires de 512 Ko, ReadyBoost vous demandera si vous souhaitez consacrer jusqu'à 4 Go du stockage pour la mise en cache du disque. (Bien que ReadyBoost puisse utiliser le système NTFS, il limite la taille maximale du cache à 4 Go pour tenir compte des restrictions FAT32). Si vous acceptez, le service crée un fichier de mise en cache appelé Readyboost.sfcache dans la racine du périphérique et demande à SuperFetch de préremplir le cache en arrière-plan.
Une fois que le service ReadyBoost a initialisé la mise en cache, le pilote de périphérique Ecache.sys intercepte toutes les lectures et écritures vers des volumes du disque dur local (C:\, par exemple) et copie toutes les données écrites dans le fichier de mise en cache que le service a créé. Ecache.sys compresse les données, généralement avec un taux de compression de 2:1. Un fichier de cache de 4 Go contiendra donc habituellement 8 Go de données. Le pilote chiffre chacun des blocs écrits à l'aide d'un chiffrement AES (Advanced Encryption Standard) en utilisant une clé de session générée de façon aléatoire par démarrage afin de garantir la confidentialité des données dans le cache si le périphérique est supprimé du système.
Lorsque ReadyBoost voit des lectures aléatoires qui peuvent être satisfaites à partir du cache, il les gère à partir de cet endroit, mais comme les disques durs ont un meilleur accès en lecture séquentiel que la mémoire flash, il laisse les lectures qui font partie de modèles d'accès séquentiel atteindre le disque directement, même si les données sont dans le cache.

ReadyBoot
Windows Vista utilise la même prérécupération de démarrage que celle que Windows XP utilisait si le système possédait moins de 512 Mo de mémoire, mais si le système possède 700 Mo de mémoire vive ou plus, il utilise un cache dans la mémoire vive afin d'optimiser le processus de démarrage. La taille du cache dépend du total de mémoire vive disponible, mais il est assez grand pour créer un cache raisonnable tout en laissant au système la mémoire dont il a besoin pour démarrer facilement.
Après chaque démarrage, le service ReadyBoost (même service que celui qui implémente la fonctionnalité ReadyBoost qui vient d'être décrite) utilise le temps d'inactivité du processeur pour calculer un plan de mise en cache pour le démarrage suivant. Il analyse les informations de suivi de fichier des cinq démarrages précédents et identifie les fichiers qui ont été consultés et leur emplacement sur le disque. Il stocke les suivis traités dans %SystemRoot%\Prefetch\Readyboot sous la forme de fichiers .fx et enregistre le plan de mise en cache sous HKLM\System\CurrentControlSet\Services\Ecache\Parameters dans des valeurs REG_BINARY nommées en fonction des volumes de disque internes auxquels elles se rapportent.
Le cache est implémenté par le pilote de périphérique qui implémente la mise en cache ReadyBoost (Ecache.sys), mais le remplissage du cache est guidé par le service ReadyBoost lors du démarrage du système. Tandis que le cache de démarrage est compressé de la même façon que le cache ReadyBoost, une autre différence entre ReadyBoost et la gestion de cache ReadyBoot réside dans le fait que, dans le mode ReadyBoot, le cache ne change pas pour refléter les données qui sont lues ou écrites pendant le démarrage (sauf pour les mises à jour du service ReadyBoost). Le service ReadyBoost supprime le cache 90 secondes après le début du démarrage ou si d'autres demandes de mémoire le justifient, et enregistre les statistiques du cache dans HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats, comme illustré à la figure 2. Les tests de performances de Microsoft montrent que ReadyBoot fournit des améliorations de performances d'environ 20 % de plus que la prélecture Windows XP héritée.
Figure 2 Statistiques de performances de ReadyBoot
Figure 2 Statistiques de performances de ReadyBoot (Cliquer sur l'image pour la réduire)
Figure 2 Statistiques de performances de ReadyBoot
Figure 2 Statistiques de performances de ReadyBoot (Cliquer sur l'image pour l'agrandir)

ReadyDrive
ReadyDrive est une fonctionnalité de Windows Vista qui tire parti des nouveaux disques durs hybrides appelés H-HDD. Un H-HDD est un disque avec une mémoire flash non volatile intégrée (également appelée NVRAM). En général, les H-HDD comprennent entre 50 Mo et 512 Mo de cache, mais la limite de cache de Windows Vista est de 2 To.
Windows Vista utilise des commandes ATA-8 pour définir les données de disque à conserver dans la mémoire flash. Par exemple, Windows Vista enregistre les données de démarrage dans le cache lorsque le système s'arrête, pour permettre un redémarrage plus rapide. Il stocke également des portions des données du fichier de veille prolongée dans le cache lorsque le système est mis en veille prolongée pour que la reprise ultérieure soit plus rapide. Comme le cache est activé même lorsque le disque est mis en veille, Windows peut utiliser la mémoire flash comme un cache d'écriture sur disque, ce qui évite de se servir du disque lorsque le système fonctionne sur batterie. De cette façon, vous pouvez économiser une grande partie de l'énergie consommée par le lecteur de disque en temps normal.

Base de données de configuration du démarrage
Windows Vista a amélioré plusieurs aspects du démarrage et de l'arrêt. Le démarrage s'est amélioré grâce à l'introduction de la Base de données de configuration du démarrage, qui permet de stocker la configuration du système et du démarrage du système d'exploitation, d'un nouveau flux et d'une nouvelle organisation des processus de démarrage du système, d'une nouvelle architecture d'ouverture de session et de la prise en charge de services de démarrage automatique retardé. Les modifications de l'arrêt dans Windows Vista incluent une notification de pré-arrêt pour les services Windows, le tri des arrêts de services Windows et une modification significative de la façon dont le système d'exploitation gère les transitions de l'état d'alimentation.
L'une des modifications du processus de démarrage les plus notables réside dans l'absence de Boot.ini dans la racine du volume système. Cette absence est due au fait que la configuration du démarrage, qui pour les versions antérieures de Windows était stockée dans le fichier texte Boot.ini, est maintenant stockée dans la base de données de configuration du démarrage. Windows Vista utilise la base de données de configuration du démarrage notamment parce qu'elle unifie les deux architectures de démarrage actuelles prises en charge par Windows : Master Boot Record (MBR) et Extensible Firmware Interface (EFI). L'architecture MBR est généralement utilisée par les systèmes de bureau x86 et x64, tandis que l'architecture EFI est utilisé par les systèmes Itanium (toutefois, les ordinateurs de bureau seront sans doute bientôt touts fournis avec une prise en charge EFI). La base de données de configuration du démarrage fait abstraction du microprogramme et présente d'autres avantages par rapport à Boot.ini, par exemple la prise en charge des chaînes Unicode et d'autres exécutables de pré-démarrage.
La base de données de configuration du démarrage est en fait stockée sur le disque dans une ruche de registre qui se charge dans le Registre Windows pour un accès via les API du Registre. Sur les PC, Windows la stocke dans \Boot\Bcd sur le volume système. Sur les systèmes EFI, elle se trouve sur la partition système EFI. Lorsque la ruche est chargée, elle apparaît sous HKLM\Bcd00000000, mais son format interne n'est pas documenté donc, pour la modifier, il convient d'utiliser un outil tel que %SystemRoot%\System32\Bcdedit.exe. Des interfaces de manipulation de la base de données de configuration du démarrage sont également disponibles pour les scripts et les éditeurs personnalisés par le biais de Windows Management Instrumentation (WMI), et vous pouvez utiliser l'utilitaire de configuration de système Windows (%SystemRoot%\System32\Msconfig.exe) pour modifier ou ajouter des paramètres de base, par exemple des options de débogage du noyau.
La base de données de configuration du démarrage distingue les paramètres de démarrage de la plate-forme, tels que la sélection du système d'exploitation par défaut et l'expiration du menu de démarrage, des paramètres spécifiques au système d'exploitation, tels que les options de démarrage du système d'exploitation et le chemin du chargeur de démarrage du système d'exploitation. Par exemple, la figure 3 montre que, lorsque vous exécutez Bcdedit sans aucune option de ligne de commande, il affiche les paramètres de plate-forme dans la section Gestionnaire de démarrage Windows en haut du résultat, suivis par les paramètres spécifiques au système d'exploitation dans la section Chargeur de démarrage Windows.
Figure 3 Paramètres affichés dans BCDEdit
Figure 3 Paramètres affichés dans BCDEdit (Cliquer sur l'image pour la réduire)
Figure 3 Paramètres affichés dans BCDEdit
Figure 3 Paramètres affichés dans BCDEdit (Cliquer sur l'image pour l'agrandir)
Lorsque vous démarrez une installation Windows Vista, ce nouveau mode divise les tâches qui étaient gérées par le chargeur du système d'exploitation (Ntldr) sur les versions antérieures de Windows en deux exécutables différents : BootMgr et %SystemRoot%\System32\Winload.exe. Bootmgr lit la base de données de configuration du démarrage et affiche le menu de démarrage du système d'exploitation, tandis que Winload.exe gère le chargement du système d'exploitation. Si vous exécutez un démarrage propre, Winload.exe charge les pilotes de périphérique du démarrage et les fichiers de base du système d'exploitation, notamment Ntoskrnl.exe, et transfère le contrôle au système d'exploitation. Si le système reprend après une veille prolongée, il exécute %SystemRoot%\System32\Winresume.exe pour charger les données de la veille prolongée dans la mémoire et reprendre le système d'exploitation.
Bootmgr inclut également une prise en charge d'exécutables de pré-démarrage supplémentaires. Windows Vista est fourni avec le diagnostic de mémoire Windows (\Boot\Memtest.exe) préconfiguré en tant qu'option pour vérifier l'état de la RAM, mais les fournisseurs tiers peuvent ajouter leurs propres exécutables de pré-démarrage en tant qu'options qui s'afficheront dans le menu de démarrage de Bootmgr.

Processus de démarrage
Dans les versions antérieures de Windows, la relation entre divers processus système n'était pas intuitive. Par exemple, lorsque le système démarre, le gestionnaire d'ouverture de session interactive (%SystemRoot%\System32\Winlogon.exe) lance le service LSASS (Local Security Authority Subsystme) (Lsass.exe) et le Gestionnaire de contrôle des services (Services.exe). Par ailleurs, Windows utilise un conteneur d'espace de noms appelé Session pour isoler les processus s'exécutant dans différentes sessions d'ouverture de session. Mais avant Windows Vista, l'utilisateur connecté à la console partageait la Session 0, la session utilisée par les processus système, ce qui créait des problèmes de sécurité potentiels. L'un de ces problèmes survenait, par exemple, lorsqu'un service Windows mal écrit exécuté dans la Session 0 affichait une interface utilisateur sur la console interactive, permettant ainsi aux logiciels malveillants d'attaquer la fenêtre avec des techniques comme les attaques destructrices (Shatter) et éventuellement de s'accaparer des privilèges administratifs.
Pour résoudre ces problèmes, plusieurs processus système ont été restructurés dans Windows Vista. Le gestionnaire de session (Smss.exe) est le premier processus de mode utilisateur créé pendant le démarrage comme dans les versions antérieures de Windows, mais, dans Windows Vista, le gestionnaire de session se lance une deuxième fois pour configurer la session 0, qui est uniquement consacrée aux processus système. Le processus du Gestionnaire de session pour la session 0 lance l'application de démarrage Windows (Wininit.exe), un processus de sous-système Windows pour la session 0 et il se ferme ensuite. L'application de démarrage Windows poursuit en démarrant le Gestionnaire de contrôle des services, le sous-système d'autorité de sécurité locale et un nouveau processus, le Gestionnaire de session locale (Lsm.exe), qui gère les connexions aux serveurs terminaux pour l'ordinateur.
Lorsqu'un utilisateur se connecte au système, le Gestionnaire de session initial crée une nouvelle instance de lui-même pour configurer la nouvelle session. Le nouveau processus Smss.exe démarre un processus de sous-système Windows et un processus Winlogon pour la nouvelle session. Le fait que le Gestionnaire de session primaire utilise des copies de lui-même pour initialiser de nouvelles sessions n'offre aucun avantage sur un système client, mais sur les systèmes « Longhorn » de Windows Server servant de serveurs terminaux, plusieurs copies peuvent s'exécuter simultanément pour permettre une connexion plus rapide de plusieurs utilisateurs.
Avec cette nouvelle architecture, les processus système, notamment les services Windows, sont isolés dans la session 0. Si un service Windows, qui s'exécute dans la session 0, affiche une interface utilisateur, le service de Détection de services interactifs (%SystemRoot%\System32\UI0Detect.exe) notifie les administrateurs connectés en lançant une instance de lui-même dans le contexte de sécurité de l'utilisateur et en affichant le message illustré à la figure 4. Si l'utilisateur sélectionne le bouton « Afficher le message », le service fait passer le Bureau en Bureau de service Windows, où l'utilisateur peut interagir avec l'interface utilisateur du service, avant de revenir à son propre Bureau. Pour en savoir plus sur le déroulement du démarrage, consultez l'encadré « Affichage des relations des processus de démarrage ».
Figure 4 Le service a affiché une fenêtre
Figure 4 Le service a affiché une fenêtre (Cliquer sur l'image pour la réduire)
Figure 4 Le service a affiché une fenêtre
Figure 4 Le service a affiché une fenêtre (Cliquer sur l'image pour l'agrandir)
Affichage des relations des processus de démarrage
Vous pouvez utiliser Process Explorer de Sysinternals (microsoft.com/technet/sysinternals) pour voir l'arborescence de démarrage des processus de Windows Vista.
La capture d'écran comprend la colonne Session, que vous pouvez ajouter par le biais de la boîte de dialogue de colonne de Process Explorer. Le processus mis en surbrillance est le Smss.exe initial. En dessous se trouvent le Csrss.exe et le Wininit.exe de la session 0, qui sont justifiés à gauche puisque leur processus parent, l'instance de Smss.exe ayant configuré la session 0, s'est refermé. Les trois enfants de Wininit sont Services.exe, Lsass.exe et Lsm.exe.
Process Explorer identifie une série de processus exécutés dans la Session 1, c'est-à-dire la session à laquelle je suis connectée via une connexion Bureau à distance. Process Explorer affiche les processus exécutés dans le compte que lui avec une surbrillance bleue. Pour finir, la Session 2 a été initialisée pour une préparation à la connexion d'un utilisateur sur la console et la création d'une nouvelle session de connexion. C'est dans cette session que Winlogon s'exécute et utilise LogonUI pour donner l'instruction suivante aux nouveaux utilisateurs de la console : « Appuyez sur CTRL+ALT+SUPPR pour ouvrir une session ». C'est aussi dans cette session que Logonui.exe demandera à l'utilisateur ses informations d'identification.
Processus de démarrage et informations sur la session
Processus de démarrage et informations sur la session (Cliquer sur l'image pour la réduire)
Processus de démarrage et informations sur la session
Processus de démarrage et informations sur la session (Cliquer sur l'image pour l'agrandir)

Fournisseurs d'informations d'identification
Même l'architecture d'ouverture de session a été modifiée dans Windows Vista. Dans les versions antérieures de Windows, le processus Winlogon chargeait la DLL GINA (Graphical Identification and Authentication) spécifiée dans le registre pour afficher une IU d'ouverture de session qui demandait aux utilisateurs leurs informations d'identification. Malheureusement, le modèle GINA est soumis à plusieurs limitations, notamment le fait que seul une GINA peut être configurée, l'écriture d'une GINA complète est difficile pour les tiers et les GINA personnalisées qui ont des interfaces utilisateur non standard modifient l'expérience de l'utilisateur Windows.
Au lieu d'une GINA, Windows Vista utilise la nouvelle architecture des fournisseurs d'informations d'identification. Winlogon lance un processus séparé, l'hôte de l'interface utilisateur d'ouverture de session (Logonui.exe), qui charge les fournisseurs d'informations d'identification configurés dans HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers. Logonui peut héberger plusieurs fournisseurs d'informations d'identification simultanément. En fait, Windows Vista est fourni avec des fournisseurs interactifs (Authui.dll) et de cartes à puce (Smart-cardcredentialprovider.dll). Pour garantir une expérience utilisateur uniforme, LogonUI gère l'interface utilisateur qui s'affiche aux utilisateurs finaux, mais il permet également aux fournisseurs d'informations d'identification de spécifier des éléments personnalisés tels que le texte et les icônes et de modifier des contrôles.

Services de démarrage automatique retardé
Si vous vous êtes déjà connecté à un système Windows tout de suite après son démarrage, vous avez sans doute été confronté à des retards avant que votre bureau ne soit entièrement configuré et que vous puissiez interagir avec le shell et toute application lancée. Pendant que vous ouvrez une session, le Gestionnaire de contrôle des services démarre les nombreux services Windows qui sont configurés en tant que services à démarrage automatique et qui s'activent donc au moment du démarrage. De nombreux services réalisent des initialisations sollicitant le processeur et le disque en même temps que vos activités d'ouverture de session. Pour tenir compte de ceci, Windows Vista introduit un nouveau type de démarrage de service appelé démarrage automatique retardé, que les services peuvent utiliser s'ils ne doivent pas forcément être actifs tout de suite après les démarrages de Windows.
Le Gestionnaire de contrôle des services démarre les services configurés pour le démarrage automatique retardé une fois que les services à démarrage automatique ont fini de démarrer et il définit la priorité de leur thread initial sur THREAD_PRIORITY_LOWEST. En raison de ce niveau de priorité, toutes les E/S de disque réalisées par le thread ont une priorité d'E/S très basse. Lorsqu'un service a fini de s'initialiser, le Gestionnaire de contrôle des services définit sa priorité sur normal. La combinaison du démarrage retardé, de la priorité basse du processeur et de la mémoire et la priorité du disque en arrière-plan réduit considérablement les interférences avec une ouverture de session d'utilisateur. De nombreux services Windows, notamment le service de transfert intelligent en arrière-plan, le client Windows Update et Windows Media® Center, utilisent le nouveau type de démarrage pour aider à améliorer les performances des ouvertures de session après un démarrage.

Arrêt
Un problème qui a tourmenté les auteurs des services Windows est le fait que, pendant un arrêt de Windows, ils ont, par défaut, vingt secondes maximum pour exécuter un nettoyage. Les versions de Windows antérieures à Windows Vista ne prenaient pas en charge un arrêt propre attendant la fermeture de tous les services parce qu'un service bogué peut empêcher l'arrêt indéfiniment. Certains services, comme ceux dont certaines opérations d'arrêt sont liées au réseau ou ceux qui doivent enregistrer de grandes quantités de données sur le disque, pourraient avoir besoin de plus de temps. C'est pour cette raison que Windows Vista permet aux services de demander une notification de pré-arrêt.
Lorsque Windows Vista s'arrête, le Gestionnaire de contrôle des services commence par notifier les services demandant une notification de pré-arrêt. Il attendra indéfiniment que ces services se ferment, mais s'ils ont un bogue et qu'ils ne répondent pas aux requêtes, le Gestionnaire de contrôle des services renonce et poursuit sur sa lancée au bout de trois minutes. Une fois que tous ces services sont fermés ou que le délai a expiré, le Gestionnaire de contrôle des services procède à l'arrêt des services de type hérité pour le reste des services. La stratégie de groupe et les services Windows Update inscrivent la notification de pré-arrêt dans une nouvelle installation de Windows Vista.
La stratégie de groupe et les services Windows Update utilisent également une autre fonctionnalité des services Windows Vista : le tri des arrêts. Les services ont toujours pu spécifier les dépendances de démarrage que le Gestionnaire de contrôle des services honore pour démarrer des services dans un ordre qui les satisfait, mais avant Windows Vista, ils étaient incapables de spécifier les dépendances d'arrêt. À présent, les services qui s'inscrivent pour recevoir une notification de pré-arrêt peuvent également s'insérer dans la liste stockée dans HKLM\System\CurrentControlSet\Control\PreshutdownOrder pour que le Gestionnaire de contrôle des services les ferme en fonction de leur ordre. Consultez l'encadré « Identification d'un démarrage automatique retardé et d'un service de pré-arrêt » pour en savoir plus sur ces services.

Gestion de l'alimentation
La veille et la veille prolongée sont d'autres formes d'arrêt et la mauvaise gestion de l'alimentation dans les pilotes et les applications gâchait la vie des personnes mobiles depuis l'introduction par Windows 2000 de la gestion de l'alimentation dans la gamme des systèmes d'exploitation Windows basés sur Windows NT®. De nombreux utilisateurs s'attendaient à ce que leur système portable s'interrompe ou se mette en veille prolongée lorsqu'ils le refermaient avant d'entreprendre un voyage, mais, à leur arrivée, ils étaient surpris de trouver leur étui chaud, leur batterie morte et certaines de leurs données disparues. C'est parce que Windows a toujours demandé l'accord des pilotes de périphérique et des applications pour changer d'état et il suffisait qu'un seul pilote ou une seule application ne réponde pas pour que la transition soit empêchée.
Dans Windows Vista, le gestionnaire de l'alimentation du noyau informe toujours les pilotes et applications des changements d'état de l'alimentation pour qu'ils puissent s'y préparer, mais leur autorisation n'est plus demandée. De plus, le gestionnaire de l'alimentation attend, pendant 20 secondes au maximum, une réponse des applications aux notifications de changements, plutôt que les deux minutes des versions antérieures de Windows. Par conséquent, les utilisateurs de Windows Vista peuvent être plus confiants que leurs systèmes respectent les veilles prolongées et s'interrompent.

À venir
Comme mentionné plus haut, il s'agit du second volet d'une série en trois épisodes. La première partie concernait les améliorations du noyau Windows Vista dans les domaines des E/S et des processus. Cette fois, j'ai parlé des améliorations de Windows Vista dans les domaines de la gestion de la mémoire, du démarrage et de l'arrêt. La prochaine fois, je conclurai la série en décrivant les modifications du noyau dans les domaines de la fiabilité et de la sécurité.
Identification d'un service de démarrage automatique retardé et de pré-arrêt
La commande SC intégrée est mise à jour dans Windows Vista pour montrer les services configurés en tant que services à démarrage automatique retardé :
Utilisation de SC pour afficher le type de démarrage
Utilisation de SC pour afficher le type de démarrage (Cliquer sur l'image pour la réduire)
Utilisation de SC pour afficher le type de démarrage
Utilisation de SC pour afficher le type de démarrage (Cliquer sur l'image pour l'agrandir)
Malheureusement, la commande SC ne signale pas les services qui ont demandé une notification de pré-arrêt, mais vous pouvez utiliser l'utilitaire PsService de Sysinternals pour voir si un service accepte la notification de pré-arrêt :
Affichage de l'état de pré-arrêt
Affichage de l'état de pré-arrêt (Cliquer sur l'image pour la réduire)
Affichage de l'état de pré-arrêt
Affichage de l'état de pré-arrêt (Cliquer sur l'image pour l'agrandir)

Mark Russinovich est technicien dans le service responsable des plates-formes et services chez Microsoft. Coauteur de l'ouvrage intitulé Microsoft Windows Internals (Microsoft Press, 2004), il participe fréquemment à des conférences pour informaticiens et développeurs. Il a rejoint récemment rejoint nos équipes lorsque Microsoft a racheté Winternals Software, la société dont il était le cofondateur. Il a également créé la société Sysinternals qui a publié les utilitaires Process Explorer, Filemon et Regmon.


 De la part de l’&#233;diteur: &#201;tag&#232;re des troph&#233;es
De la part de l’éditeur
Étagère des trophées
Joshua Trupin

PENDANT ENVIRON TRENTE ANS DE MA VIE, je n’ai jamais rien gagné. Mes billets de loterie ne contenaient jamais les bons numéros. Quand je gratte des tickets à gratter, je ne gagne jamais rien. Au tiercé je choisis toujours les mauvais chevaux.
Si l’on considère ce peu de chance, il n’est pas étonnant que je sois très enthousiaste à l’idée de gagner quelque chose, pour une fois. Technet Magazine vient de gagner quatre récompenses auprès de la Society for Technical Communication (STC). Nous mettons beaucoup de travail dans chaque numéro, et il est merveilleux que ce travail soit reconnu. Je voudrais prendre quelques instants pour remercier le personnel et les auteurs pour leur contribution.
Notre numéro de mars/avril 2006 vous proposait un guide clair et accessible d’Active Directory sous la forme d’un poster puzzle. Il a eu énormément de succès ; pour tout vous dire, on nous demande encore constamment des copies de ce numéro ! La STC a décerné la récompense « Excellence for Software Guides » à notre poster.
Deux de nos articles ont également reçu de très bonnes notes. L’article « Playing with Exchange in a Sandbox » de Greg Taylor et Simon Shepherd dans le numéro d’août 2006 et l’article « Deconstructing Common Security Myths » de Jesper Johansson et Steve Riley dans le numéro de mai/juin 2006 ont tous deux reçus des récompenses de la STC.
Technet Magazine lui-même a gagné la récompense « Award of Excellence for Scholarly & Professional Journals ». Je suis extrêmement fier de cette reconnaissance, comme tous ceux qui travaillent dans notre équipe.
Mais ne vous inquiétez pas, nous n’allons pas nous reposer sur nos lauriers pour autant. Dans ce numéro, Mark Russinovich explore les modifications de noyau des informations clés de Windows Vista, très utiles à tous les professionnels de l’informatique impliqué dans le déploiement d’ordinateurs de bureau ou les services de prise en charge. Nous vous proposons également une couverture approfondie de SQL Server ce mois-ci, de l’utilisation des métadonnées d’index à la partition des tableaux et aux options de haute disponibilité, en passant par des astuces de clustering.
À One TechNet Magazine Plaza, nous ne nous arrêtons jamais. (C’est ainsi quand on doit respecter des échéances.) Cependant, nous apprécions un changement de décor de temps à autre. Nous serons au Microsoft TechoEd à Orlando du 4 au 8 juin 2007 (voir microsoft.com/teched). Venez rencontrer quelques-uns des éditeurs et auteurs récompensés de Technet Magazine. Nous avons des cadeaux pour vous et pas mal de choses amusantes à vous proposer... peut-être que vous aussi, vous allez toucher le gros lot ! -JOSHUA TRUPIN
Remerciements aux experts techniques Microsoft suivants : Vijay Bharadwaj, Paul Bowden, Elden Christensen, Manish Karla, Michael Murgolo, Rajeev Nagar, John Peng, Mark Russinovich, Abraham Samuel, Mark Scurrell, Jim Truher, George Walterset et Buck Woody.

Joshua Trupin


 Bo&#238;te &#224; outils: Nouveaux produits pour les professionnels de l’informatique
Boîte à outils
Nouveaux produits pour les professionnels de l’informatique
Greg Steen

Gestion de la synchronisation du réseau
ViceVersa Pro
www.tgrmn.com

À moins que votre infrastructure consiste en un seul ordinateur, vous avez probablement à déplacer constamment des fichiers parmi vos environnements. Des fichiers journaux aux nouvelles versions d’applications, en passant pas les sauvegardes de base de données, les données se déplacent sans cesse sur le réseau. Il est alors important de savoir ce qui doit être copié pour garder des environnements différents synchronisés. Pour la plupart des professionnels de l’informatique, le déplacement manuel de ces fichiers entre les environnements ne constitue pas une option, sans oublier qu’il s’agit généralement d’une mauvaise idée car il peut mener à de mauvaises synchronisations.
ViceVersa Pro de TGRMN Software vous permet d’automatiser et de planifier facilement ces tâches. L’application fournit quatre modes de copie différents. La synchronisation de base (Basic Synchronization) permet une synchronisation de la source à la destination et le mode de synchronisation avancée (Advanced Synchronization) propose une synchronisation de fichiers et de répertoires bidirectionnelle avec suivi des fichiers. Le deux autres modes sont Backup (Sauvegarde, qui effectue une copie miroir de la source) et Consolidation.
Bien que le mode de sauvegarde assure une copie en miroir de la source sur la cible, en ajoutant et en supprimant des fichiers de la cible, il est également possible de choisir la réplication de fichiers, qui copiera uniquement des fichiers vers la cible. Ceci peut s’avérer très utile si des utilisateurs suppriment subitement des éléments. La synchronisation bidirectionnelle s’exécute comme son nom le suggère, le suivi de conflit et de suppression s’ajoutant à ses fonctionnalités. Si un fichier change sur la source comme sur la cible avant la synchronisation suivante, un conflit est noté et il est possible de résoudre le problème manuellement. La méthode de consolidation est similaire à la synchronisation bidirectionnelle, à ceci près qu’elle n’effectue pas de suivi des conflits et des suppressions.
Protection contre les erreurs de copie et la perte de données
Protection contre les erreurs de copie et la perte de données (Cliquer sur l'image pour la réduire)
Protection contre les erreurs de copie et la perte de données
Protection contre les erreurs de copie et la perte de données (Cliquer sur l'image pour l'agrandir)
Vice Versa Pro peut faciliter les tâches d’envoi de journaux grâce aux fonctions de compression et de chiffrement de fichiers intégrées au mode de sauvegarde. L’application compresse vos fichiers source au format standard gzip, qui peut être ensuite protégé par un mot de passe.
L’application est également dotée d’une bonne comparaison de fichiers intégrée mais, si vous le souhaitez, vous pouvez également configurer Vice Versa Pro pour utiliser un programme de comparaison de fichiers externe. Afin de prendre en charge un environnement global, Vice Versa accepte les caractères Unicode et les chemins de plus de 256 caractères. L’application possède également une prise en charge intégrée de la synchronisation de l’heure Internet et vous pouvez donc la configurer pour qu’elle pointe vers un ordinateur NTP local ou tout autre serveur NTP externe, si vous autorisez les requêtes sortantes depuis l’environnement dans lequel vous utilisez l’application.
Parfois, l’utilisation de la bande passante peut constituer un souci, si le trafic transite par un VPN ou un réseau global. Dans ce cas, Vice Versa vous permet de paramétrer la quantité de bande passante utilisée par l’application pour chaque tâche de synchronisation. Ceci peut également permettre d’assurer une réponse de niveau de production de la part des serveurs sur lesquels ou depuis lesquels la copie est effectuée. Si vous le voulez, vous pouvez également définir un seuil maximal d’utilisation d’UC pour vous assurer que votre serveur est disponible lorsque l’application s’exécute.
Vice Versa Pro vous protège contre les erreurs de copie et la perte de données en utilisant un algorithme de copie sécurisée. L’application exécute également des contrôles de vérification de redondance cyclique afin d’assurer l’intégrité des données. Vous pouvez planifier les tâches de synchronisation pour qu’elles s’exécutent à presque tout intervalle, y compris en mode temps réel (ceci synchronisera les fichiers dès qu’ils sont ajoutés ou supprimés des dossiers de synchronisation).
L’une des autres fonctionnalités pratiques de Vice Versa Pro est l’aperçu de toutes les opérations offert pas l’interface utilisateur, avant que celles-ci ne soient exécutées. Ceci permet de s’assurer que vous copiez ce que vous aviez prévu de copier ; rien n’est plus agaçant que de se retrouver avec plusieurs gigaoctets de fichiers journaux dans le répertoire système.
En résumé, si vous recherchez un outil de synchronisation à bas prix aux fonctionnalités complètes, Vice Versa Pro peut convenir à vos besoins.
Prix : 59,95 USD par utilisateur unique.

Administration des disques de votre système
Partition Manager 8.0 Professional Edition
www.partition-manager.com/corporate/professional
Si vous recherchez une application pour vous aider à administrer les disques de vos systèmes, Partition Manager 8.0 Professional Edition de Paragon Software Group est sans aucun doute une alternative à considérer.
La fonctionnalité fondamentale de cette application Windows® vous fournit une interface intuitive d’Assistant pour facilement créer, supprimer, modifier la visibilité et formater des partitions de disque dur, qu’elles soient au format FAT16/32, NTFS, Ext2/3 ou HPFS. Vous pouvez également redimensionner des partitions existantes ou déplacer des partitions d’un disque vers un autre.
Qui plus est, vous pouvez effectuer des conversions de types de système de fichiers tels que NTFS à partir de FAT16/32 ou Ext2 à Ext3, et inversement. La copie d’une partition d’un disque vers un autre redimensionnera automatiquement la partition à la taille du disque, ce qui peut être pratique pour étendre le disque de données de votre système sans avoir à copier tous les fichiers manuellement. La possibilité d’effectuer un redimensionnement à chaud est l’une des fonctionnalités pratiques de cette version 8.0. Elle vous permet d’augmenter la taille d’une partition NTFS active sans avoir à redémarrer Windows.
Augmentez la taille d’une partition NTFS active sans redémarrer
Augmentez la taille d’une partition NTFS active sans redémarrer (Cliquer sur l'image pour la réduire)
Augmentez la taille d’une partition NTFS active sans redémarrer
Augmentez la taille d’une partition NTFS active sans redémarrer (Cliquer sur l'image pour l'agrandir)
La conversion de disques dynamiques en disques de base sur les clients Windows 2000, Windows XP et Windows Server® 2003 est une autre fonctionnalité utile de la version Pro Edition. Partition Manager prend en charge les disques de taille allant jusqu’à 500 Go (ce qui constitue la limite des tests de Paragon et non une véritable limite physique), ainsi que les lecteurs connectés via FireWire et USB. Partition Manager prend en charge les disques dur PATA (IDE), SATA et SCSI.
Partition Manager vous permet de créer un CD de récupération (ou encore un DVD, ou même une disquette) pour vous aider à restaurer un système après une défaillance de disque catastrophique. Par ailleurs, si vous avez supprimé par inadvertance une partition mais que le système est toujours actif, vous pouvez annuler la suppression de la partition au travers de l’interface. Vous pouvez même modifier la taille de cluster de votre disque pour ajuster les performances. L’application vous procure également un affichage « de pré-exécution virtuelle » qui vous permet d’évaluer vos modifications de disque avant de les valider physiquement sur le disque.
Vous pouvez également mettre à niveau un disque dur sur votre système avec Partition Manager 8.0. L’application vous permet de copier une partition ou une image de disque dur complet vers un nouveau disque, en adaptant leur taille à la partition cible.
Enfin, Partition Manager comprend également un outil de défragmentation de disque intégré qui peut défragmenter les lecteurs qui sont jusqu’à 99 pourcent pleins, bien que nous espérons que vous pourrez y remédier avant que votre lecteur ait atteint un tel stade.
Prix : 99,95 USD pour la version Professional Edition.

Ajoutez la saisie semi-automatique à votre éditeur SQL
SQL Prompt : IntelliSense pour SQL
www.red-gate.com/products/SQL_Prompt/index.htm

Il est tentant de penser que toutes les bases de données sont créées et sont structurées avec des conventions de dénomination logiques de forme standardisée mais, tristement, nous savons que cela n’est pas le cas. Lorsque je suis en charge du rôle d’administrateur système ou de base de données, je dois souvent consulter la structure de la table lors de la création ou de l’exécution de requêtes, et encore plus souvent lorsque j’assume le rôle de développeur.
Bien que SQL Server™ Management Studio for SQL Server 2005 vous facilite la vie en intégrant un explorateur d’objets dans la section d’affichage par arborescence de l’interface, je suis toujours à la recherche de cette fonctionnalité que je me suis trop habitué à utiliser dans l’IDE de Visual Studio® : IntelliSense®. Heureusement, Red-Gate Software propose SQL Prompt, qui vous permet de profiter de la saisie semi-automatique dans les éditeurs Microsoft SQL Server.
L’application s’exécute dans votre barre des tâches et détecte que vous commencez à travailler dans un éditeur. Pour commencer, SQL Prompt vous demandera les informations de connexion à la base de données pour qu’il puisse atteindre et mettre en cache toutes les données d’objet. Ceci accélère les performances et réduit la charge, mais si vous modifiez constamment des objets sur l’instance de base de données, vous devrez vous souvenir de vider la mémoire cache (ce qui est une action simple effectuée en deux clics) pour voir vos modifications sur la liste d’invite.
Outre les IDE de Visual Studio, Enterprise Manager, Query Analyzer et SQL Server Management Studio, SQL Prompt s’intègre aussi directement à UltraEdit et EditPlus 2. Sur l’onglet Options de l’interface utilisateur de Paramètres, vous pouvez indiquer les mots-clés SQL devant déclencher la liste de candidats (tels que FROM, JOIN, EXEC, etc.). Le déclenchement de SQL Prompt avec l’instruction JOINS de SQL indiquera même votre instruction ON (en supposant que des références sont définies ou que les champs portent le même nom). Vous pourrez ici aussi définir des raccourcis de texte pour l’insertion d’extraits de code. Par exemple, l’application définit « ssf » suivi de la touche Tab pour écrire « SELECT * FROM ». Vous pouvez également faire en sorte que SQL Prompt mette automatiquement les mots-clés SQL en majuscules lorsque vous tapez. Cette fonctionnalité et celle qui concerne les extraits de code vous feront sans aucun doute gagner beaucoup de temps.
Sur l’onglet Candidates de l’interface utilisateur des paramètres, vous pouvez choisir si vous voulez que SQL Prompt utilise les noms de colonnes complets, le préfixe avec les informations de propriétaire/schéma, qu’il encadre les noms de crochets et vous pourrez même définir les types de fonctions SQL que vous voulez voir s’afficher dans la liste des candidats. Si vous utilisez SQL, il peut être judicieux d’ajouter cet outil à votre nécessaire de travail.
SQL Prompt est gratuit jusqu’à la sortie de la version 3.0 qui est, au moment de la rédaction de cet article, au stade de la version bêta finale. Le tarif de la version 3.0 n’a pour l’instant pas été publié.
Prix : Gratuit.

Calcul de la taille de page
Atomic Web Page Size Calculator
www.info-pack.com/pagesize
La bande passante de l’utilisateur final a peut-être augmenté alors que les nouvelles technologies facilitent la livraison toujours plus rapide du contenu Web ; néanmoins la taille des pages demeure toujours importante. Tous ces octets peuvent s’accumuler pour une répercussion importante sur le coût de la bande passante d’un site au trafic important.
L’utilitaire Atomic Page Size Calculator d’Info-pack.com fournit une méthode économique et simple pour la vérification de la taille des pages de votre site Web. Il vous suffit de taper l’URL de la page en question pour que le programme capture la page et calcule la taille de tous ses éléments, y compris toute référence à des images externes (ces éléments qui ne sont pas forcément visibles dans les journaux Web de votre domaine principal).
Surveillance du coût de bande passante
Surveillance du coût de bande passante (Cliquer sur l'image pour la réduire)
Surveillance du coût de bande passante
Surveillance du coût de bande passante (Cliquer sur l'image pour l'agrandir)
La calculatrice prend en charge les pages, les images et les fichiers Javascript et vous pourrez donc obtenir des données concernant la majorité des ressources de votre page. L’application vous notifiera également lorsqu’elle rencontre une erreur de ressources « indisponibles » 404. Une fois que vous avez obtenu les informations de taille de votre URL, cliquez sur le bouton de rapport pour voir un détail de la taille et une estimation du temps nécessaire au téléchargement de l’URL aux diverses vitesses de connexion.
Il serait pratique que l’application puisse contrôler simultanément plusieurs URL, mais cette fonction sera peut-être disponible dans une version future. Si vous cherchez une méthode rapide de vérification de la taille des pages de vos équipes de développement, cette application s’adresse peut-être à vous.
Prix : 19,95 USD (vente directe).

Écrire à Boîte à outils
Si vous souhaitez voir votre outil ou utilitaire préféré figurer dans l’un de nos articles, veuillez écrire à l’auteur à l’adresse tntools@microsoft.com.
Greg Steen est un professionnel de l’informatique, dynamique et enthousiaste. Il est constamment à la recherche de méthodes et d’outils innovants destinés à faciliter les opérations et le développement pour les professionnels de l’informatique.


 Coup de projecteur sur les utilitaires: SyncToy
Coup de projecteur sur les utilitaires
SyncToy
Jay Munro
Télécharger le code de cet article: SynctToy (971KB)

VOICI UN PROBLÈME RÉCURRENT pour les professionnels de l’informatique, les administrateurs réseau et le personnel d’assistance technique : un appel d’un utilisateur dont l’ordinateur est tombé en panne et qui ne dispose pas de sauvegarde. Il peut être très difficile de pousser les gens à enregistrer leur travail sur le réseau et non pas uniquement de façon locale. C’est là que SyncToy intervient.
Au départ conçu pour synchroniser des photographies numériques entre un appareil photo, un ordinateur et des lecteurs externes, SyncToy constitue une méthode flexible et fiable de sauvegarde de presque tous les types de fichiers. Fonctionnant sur Windows Vista™, ainsi que Windows® XP et Windows Server® 2003, SyncToy fonctionne aussi bien avec les lecteurs locaux, externes ou USB qu’avec les partages réseau ou de groupes de travail.
SyncToy utilise une architecture de dossiers en paire, dans laquelle vous spécifiez un répertoire de gauche et un répertoire de droite. Vous pouvez créer autant de paires de dossiers que vous le souhaitez et synchroniser une paire ou toutes les paires d’un clic. Pour créer une paire de dossiers, vous exécutez un assistant rapide contenant quatre étapes ; vous tapez ou collez un chemin d’accès ou naviguez vers un emplacement pour les dossiers de gauche et de droite. SyncToy comprend les dénominations de fichiers UNC (tels que \\MyServer\Joe_smith\backup\) ainsi que les mappages et les chemins de lecteurs locaux (E:\doc_backup). Une fois les chemins entrés, vous avez le choix entre cinq actions pour SyncToy au moment de la comparaison des dossiers.
Sync Copie les nouveaux fichiers et les fichiers mis à jour dans les deux directions. Si vous renommez ou supprimez un fichier dans un dossier, cette action est copiée dans l’autre.
Echo Copie les nouveaux fichiers et les fichiers mis à jour et supprime/renomme uniquement du dossier gauche au dossier droit.
Subscribe Copie les fichiers mis à jour de gauche à droite, et uniquement si ces fichiers existent déjà à gauche. Les modifications apportées à gauche ne seront pas copiées à droite.
Contribute Copie les nouveaux fichiers et les fichiers mis à jour à gauche sur le dossier de droite, en ignorant les suppressions.
Combine Verrouille plusieurs machines en copiant les fichiers existant d’un côté mais pas de l’autre. Les fichiers supprimés ou renommés, d’un côté ou de l’autre, ne sont ni affectés, ni répliqués.
Une fois que vous avez sélectionné l’action voulue, choisissez un nom pour la paire de dossiers, et c’est terminé. SyncToy ne vous permet pas pour l’instant de modifier les chemins d’accès ou le nom une fois la paire de dossiers créée ; si vous commettez une erreur, sélectionnez la paire de dossiers, supprimez-la et recréez-la. Vous pouvez configurer diverses options, y compris les fichiers et sous-répertoires à inclure, et si vous souhaitez ou non enregistrer les fichiers écrasés dans la Corbeille (option activée par défaut).
Synchronisation de fichiers avec SyncToy
Synchronisation de fichiers avec SyncToy (Cliquer sur l'image pour la réduire)
Synchronisation de fichiers avec SyncToy
Synchronisation de fichiers avec SyncToy (Cliquer sur l'image pour l'agrandir)

La boîte de dialogue principale de SyncToy affiche les paires de dossiers à gauche avec les chemins d’accès, options et actions correspondants. L’option All Folder Pairs liste toutes vos paires de dossiers, et vous pouvez réaliser un aperçu (Preview) ou une exécution complète (Run All) sur les paires cochées. Comme vous pouvez l’imaginer, Preview simule la synchronisation sans apporter aucune modification. Il s’agit là d’une option utile si vous avez prévu de réaliser des synchronisations sans surveillance. Preview affiche un rapport vous indiquant les opérations qu’il a réalisées. Si tout vous paraît bon, cliquez sur Run (Exécuter).
La planification n’est pas intégrée, mais le fichier d’aide est assez complet concernant les planifications Windows Vista et Windows XP. Les utilisateurs non-techniques pourraient avoir besoin d’aide pour cette configuration, mais vous n’avez à le faire qu’une fois, étant donné que toutes les modifications apportées aux paires de dossiers, aux actions et aux options sont réalisées dans SyncToy lui-même.
Comme tous les utilitaires de ce type, SyncToy n’est pas pris en charge par Microsoft, mais via des forums de communauté et de la documentation. Vous devrez donc vous débrouiller tous seuls. Le fichier d’aide est écrit pour tous les niveaux d’utilisation et couvre de façon assez exhaustive les fonctionnalités disponibles. L’interface utilisateur est suffisamment intuitive pour vous permettre une bonne compréhension immédiate.
Donc téléchargez SyncToy et montrez à vos utilisateurs comment sauvegarder leurs fichiers. Vous dormirez tous mieux.

Jay Munro est rédacteur dans l’équipe Windows User Assistance de Microsoft, et il est spécialisé dans Internet Explorer. Il a été par le passé chef de projet pour PC Magazine.


 Forum aux questions sur SQL: Heure d’&#233;t&#233;, m&#233;moire de serveur et plus
Forum aux questions sur SQL
Heure d’été, mémoire de serveur et plus
Par Nancy Michell

Heure d’été
Q Étant donnés les changements à venir en ce qui concerne l’heure d’été aux États-Unis pour se conformer à l’Energy Policy Act de 2005, dois-je mettre à jour SQL Server™ ?
R Non. Aucune mise à jour de SQL Server n’est à l’heure actuelle nécessaire pour la prise en charge de la modification de l’heure d’été. SQL Server repose sur le système d’exploitation sous-jacent en ce qui concerne les données liées à l’heure d’été, ce qui signifie que si le système d’exploitation fournit des dates et heures correctes, SQL Server fournira et utilisera des valeurs identiques. Pour vous conformer aux modifications à venir concernant l’heure d’été, vous devrez mettre à jour votre exemplaire de Windows® comme indiqué sur support.microsoft.com/kb/928388. Ceci sera nécessaire sur tous les systèmes d’exploitation Windows précédant Windows Vista™ (qui inclut déjà ces modifications) pour se conformer aux modifications de l’heure d’été, y compris ceux qui exécutent SQL Server. L’Australie fait également l’objet de quelques modifications. Voir support.microsoft.com/kb/912475.

Connexion avec Windows Vista
Q j’ai installé Windows Vista et maintenant je ne peux pas me connecter à SQL Server 2005 depuis mon système. Je suis administrateur local et je pouvais habituellement me connecter sans problème. Que s’est-il passé ?
R Il s’agit du comportement normal avec Windows Vista et SQL Server 2005 sans Service Pack 2 (SP2). Windows Vista possède un nouveau modèle de sécurité (Contrôle de compte d’utilisateur) qui a pour effet de limiter votre appartenance au groupe des administrateurs locaux et de vous demander de confirmer les opérations nécessitant des privilèges d’administrateur. Si vous cliquez sur le bouton Autoriser, vos informations d’authentification, qui incluent votre jeton d’administrateur, sont transférées à l’application. Avec SQL Server Management Studio (SSMS), aucune boîte de dialogue n’est affichée car l’exécution seule de l’outil ne nécessite pas d’autorisations administratives. Le problème est que par défaut le rôle d’administrateur SQL Server 2005 inclut le groupe d’administrateurs locaux du système d’exploitation et c’est ce que votre compte utilisait dans le passé pour accéder à SQL Server. Puisque Windows Vista ne transfère pas cette autorisation, l’accès ne vous est pas accordé.
Notez cependant que l’exécution de SQL Server 2005 sans SP2 n’est pas prise en charge sur Windows Vista et que SP2 dispose d’un outil qui ajoutera votre compte pour vous. Si vous attendez toujours pour installer SP2, la solution est assez simple. Votre compte d’utilisateur individuel de Windows doit être ajouté à SQL Server, dans votre cas au rôle d’administrateur système. Pour ce faire, cliquez simplement avec le bouton droit sur SQL Server Management Studio et sélectionnez Exécuter en tant qu’administrateur. Connectez-vous à votre serveur SQL Server et ajoutez votre compte Windows au rôle d’administrateur système. Reportez-vous à SQL Server Books Online pour plus d’informations sur cette manipulation.

Réplication transactionnelle avec les vues
Q Si je dispose d’une vue publiée et que je la mets à jour, je sais que cette transaction sera répliquée. Si je mets toutefois à jour la table de base de cette vue, cette transaction sera-t-elle répliquée ? Par ailleurs, si j’ai une table publiée, que je crée une vue pour celle-ci et que je mets à jour la vue au lieu de la table de base, cette transaction sera-t-elle répliquée ?
R En supposant que la table de base est configurée comme article d’une publication (c’est-à-dire que vous avez également configuré la table de base pour la réplication), toute mise à jour de la table de base est alors répliquée.
Lorsque vous répliquez une vue, par défaut, tout ce qui est répliqué dans la vue se compose de la partie schéma de cette vue, ou du code de la vue, et non des données sous-jacentes (sauf en cas de vue indexée). Ensuite, même sans réplication, toute mise à jour d’une vue (ce qui revient dans ce cas à exécuter une instruction du langage de manipulation de données [DML] avec la vue comme cible) est uniquement une mise à jour des données de la table sous-jacente et non de la vue. Une vue est uniquement un stockage logique d’une instruction de requête à laquelle aucun stockage physique n’est associé (sauf, ici encore, s’il s’agit d’une vue indexée).

Mémoire de serveur maximale
Q J’ai un ordinateur exécutant Windows Server® 2003 et SQL Server 2000, avec 5 Go de RAM. Disons que j’utilise le commutateur /3GB pour augmenter mon espace d’adressage virtuel en mode utilisateur, le commutateur /PAE pour charger la version d’extension d’adresse physique (Physical Address Extension, PAE) du noyau de Windows et que j’active Address Windowing Extensions (AWE) en le définissant sur 1 (et active le verrouillage des pages en mémoire). Avec AWE activé, est-ce que l’option de mémoire maximale de serveur configurera uniquement la taille de la mémoire cache des données ou la taille de toutes les mémoires cache de tampons (données, processus, sessions, etc.) ? Puisque seule la mémoire cache de données peut tirer parti de la mémoire mappée par AWE, si je configure la mémoire de serveur maximale sur 4 Go, est-ce que la mémoire cache de données utilisera seulement 1 Go (la portion mappée par AWE) ou pourra-t-elle utiliser ce gigaoctet supplémentaire et continuer à utiliser l’espace d’adressage standard ou à entrer en compétition avec les autres consommateurs de mémoire pour l’accès à celui-ci ?
R La mémoire maximale de serveur limitera toujours la taille complète du pool de tampons, même si seule la mémoire cache de données peut accéder à la mémoire mappée par AWE.
Donc pour répondre à votre première question, même avec AWE activé, la mémoire de serveur maximale limite toujours le pool complet de tampons, mais les consommateurs différents de la mémoire cache de données n’utiliseront jamais la mémoire mappée par AWE.
Pour répondre à la deuxième question, la mémoire cache de données utilisera la mémoire mappée par AWE, plus toute autre mémoire du pool de tampons que SQL Server qualifie comme appropriée. Il ne sera pas uniquement limité à la mémoire AWE mais sera le seul consommateur pouvant tirer parti de la mémoire AWE. Si vous n’êtes pas certain de l’effet du commutateur /3GB, consultez le blog de Raymond Chen (en anglais).

Profilage et performances
Q Je dispose de SQL Server 2005 mis en miroir dans un environnement de production. Lorsque je démarre SQL Server Profiler sur l’ordinateur de la base de données et que j’écris les données de suivi dans un fichier, j’observe une chute importante des performances. Pourquoi ?
R La raison de la chute des performances dépend de l’emplacement depuis lequel Profiler est exécuté. Si vous l’exécutez de manière interactive sur l’ordinateur serveur, l’interface utilisateur du Profiler consomme mémoire et processeur sur le serveur, ce qui a des répercussions sur les performances.
Si vous exécutez Profiler de manière interactive sur un poste de travail, vous déplacez alors les informations concernant les événements sur le réseau. Ceci a des répercussions sur le débit. S’il s’agit du réseau que vous utilisez également pour la mise en miroir, vous pourrez également constater l’impact sur ce dernier. En outre, si vous enregistrez le résultat de Profiler sur un partage réseau, vous déplacez des données sur le réseau et avez un impact négatif sur les performances.
La meilleure manière de concilier tout ceci est probablement d’exécuter Profiler de manière non interactive sur le serveur qui exécute l’instance dont le profilage doit être effectué et de rediriger la sortie vers un fichier local. Vous consommerez toujours des ressources du serveur, mais cette approche a généralement l’impact le plus réduit. Ceci fonctionne beaucoup mieux que le suivi de profilage en mémoire. Le suivi dans un fichier utilise la mémoire système plus efficacement. Il dispose de plus grands tampons et les vide sur disque plus efficacement. Il ne dépend pas non plus de processus externes (tels que SQL Server Profiler).
Enfin, les données de suivi sont écrites dans un fichier sur disque pendant que le Profileur continue à effectuer le profilage. Le fichier de suivi est partagé afin que d’autres personnes puissent voir à distance les données de profil en temps réel. Si vous appelez le fichier de suivi de manière interactive, cela signifie que vous avez invoqué Profiler manuellement et que vous affichez le résultat à l’écran. Les suivis peuvent être créés par programmation sans résultat visuel, ce qui explique pourquoi ces opérations doivent être effectuées sans aucune interaction.
Vous pouvez créer un partage avec un répertoire local et d’autres personnes peuvent accéder aux fichiers qui s’y trouvent, ce qui fonctionne en général bien. Comme indiqué auparavant, il n’est pas souhaitable d’envoyer le résultat du suivi vers un partage distant, en particulier si l’accès à celui-ci a lieu sur le même canal de réseau que celui utilisé pour la mise en miroir.
Vous devez également sélectionner uniquement l’ensemble d’événements nécessaire à votre investigation. Pour l’emplacement du fichier de suivi, vous devez choisir le lecteur le plus rapide sur votre système (de préférence différent des lecteurs de la base de données et du journal des transactions SQL Server). Si vous constatez toujours une dégradation significative des performances, fractionnez les événements en deux suivis ou plus, ciblant chacun un disque dur différent. Même si les suivis ciblent le même disque dur, cette division vous offrira toujours des avantages, car chaque suivi dispose de son propre ensemble de tampons. Pour plus d’informations, reportez-vous à sp_ trace_create et à tous ses éléments liés dans SQL Server Books Online (en anglais).

Problèmes de clusters
Q J’essaie d’installer SQL Server sur un cluster utilisant Windows Server 2003. Chaque fois que j’essaie ceci, j’obtiens une erreur indiquant « Le programme d’installation n’a pas réussi à effectuer les opérations requises sur les nœuds de clusters. ». Le journal sqlstp indique simplement :
Script file copied to '\\SERVER01\ADMIN$\SERVER01_MSSQLSERVER.iss' successfully.
Installing remote service (SERVER01)...
An error occured in the service create (SERVER01): 1069...
Que peut-il bien se passer ?
R Il y a plusieurs raisons possibles à cet échec. Le programme d’installation installe le service Windows NT® sur tous les nœuds sélectionnés pour la gestion à distance du processus d’installation sur les ordinateurs individuels. Donc, vous devez vous préparer à plusieurs embûches.
Tout d’abord, les utilisateurs de votre domaine peuvent avoir une stratégie de groupe qui refuse l’autorisation « d’ouverture de session en tant que service ». (Souvenez-vous que la stratégie de domaine a priorité sur votre stratégie d’ordinateur locale.) Assurez-vous que vous utilisez un compte sans ces restrictions.
Deuxièmement, le compte ayant ouvert la session sur l’ordinateur depuis lequel vous exécutez l’installation doit posséder l’accès en tant qu’administrateur à tous les nœuds pour les raisons suivantes : Le processus d’installation maître nécessite l’accès distant au registre de tous les ordinateurs ; le programme d’installation copie cnvsvc.exe vers le répertoire Windows de l’ordinateur distant ; ou le programme d’installation utilise les API Windows standard qui utilisent uniquement les autorisations du compte ayant ouvert la session pour accéder aux ordinateurs distants. Pour ces raisons, vous devriez ouvrir votre session en tant qu’administrateur pour tous les modes par défaut.

Plan de récupération après incident
Q Je me demande si je devrais utiliser la mise en miroir de base de données (en mode asynchrone) ou l’envoi de journaux pour mettre en place la stratégie de récupération après incident de mes bases de données SAP. Mes sites de production et de récupération après incident disposeront d’une connexion large bande 100 Mbits qui n’est pas dédiée à la session en miroir. La connexion sera partagée avec différentes sessions en miroir ou même d’autres serveurs de récupération après incident.
S’il y a un problème de réseau empêchant l’enregistrement de journal d’être envoyé à la base de données en miroir, y aura-t-il une nouvelle tentative ?
Lorsque la session mise en miroir est interrompue, y a-t-il une période de rétention ? Et, outre les vues du système, y a-t-il des informations de journalisation que je peux utiliser pour surveiller le trafic de mise en miroir et la transmission des enregistrements de journaux ?
R Commençons par répondre à la question suivante : Quelle est la logique de nouvelle tentative de la mise en miroir de base de données ? Vous pouvez considérer ceci de deux points de vue : Tout d’abord, s’il y a un problème de réseau passager, l’état de session en miroir est déconnecté. La valeur du délai d’expiration par défaut du réseau est 10 secondes, ce qui signifie qu’un enregistrement de journal ne peut pas être envoyé de la base de données principale à la base de données en miroir. Dans de tels cas, la base de données principale continuera à s’exécuter « exposée » et la transaction sera validée côté client. Une fois le problème de réseau résolu, la session en miroir effectuera automatiquement une nouvelle tentative, sans intervention de utilisateur. Elle tentera de rattraper le retard en utilisant les enregistrements de journaux ; les partenaires se synchroniseront d’abord et, une fois qu’ils auront rattrapé le retard, l’état sera synchronisé.
Deuxièmement, s’il y a un problème de nouvelle tentative, l’état de session en miroir est suspendu. Un problème de nouvelle tentative signifie que la base de données en miroir ne peut pas valider les enregistrements de journaux dans sa base de données. Les problèmes de nouvelle tentative sont principalement provoqués par des fichiers physiques introuvables ou un espace disque insuffisant. Dans de tels cas, la base de données principale continuera à s’exécuter exposée et la transaction sera validée côté client. Après avoir résolu manuellement le problème de nouvelle tentative sur le serveur en miroir, la session en miroir nécessite une intervention :
ALTER DATABASE <db> SET PARTNER RESUME;
En ce qui concerne les périodes de rétention, la réponse est qu’indépendamment du fait que la session de miroir est déconnectée ou interrompue, les enregistrements de journaux seront gardés jusqu’à ce que la session soit restaurée et tous les enregistrements depuis l’heure à laquelle la session a été interrompue jusqu’à l’heure à laquelle elle a été reprise sont validés sur le miroir. En gros, pendant que la session en miroir est déconnectée ou interrompue, le journal sur la base de données principale ne peut pas être tronqué, car cela briserait à nouveau la chaîne de nouvelle tentative. Ceci signifie que le journal de la base de données principale grandira sans limites jusqu’à ce que la session soit restaurée. Donc, il n’y a en fait aucune limite de rétention pour la session en miroir. La seule véritable contrainte est l’espace disque dont le serveur principal dispose pour enregistrer le journal, puisque celui-ci ne peut pas être tronqué.
Enfin, il n’existe aucun fichier journal spécifique pouvant être utilisé pour surveiller la mise en miroir. SQL Server 2005 dispose d’un outil à interface utilisateur graphique appelé Database Mirroring Monitor, qui permet aux administrateurs système d’afficher et de mettre à jour l’état et de configurer les seuils d’avertissement de plusieurs mesures de performances clés. Grâce à ceci, vous pouvez obtenir une alerte lorsque la mise en miroir ne fonctionne pas bien. Le souci de performances principal avec la mise en miroir de base de données est le traitement en temps voulu des enregistrements des journaux. Pour plus d’informations sur la surveillance des bases de données en miroir, consultez l’article (en anglais) concernant la surveillance de l’état de la mise en miroir sur msdn2.microsoft.com/fr-fr/library/ms365781.aspx.

Merci aux informaticiens Microsoft ci-dessous pour leur expertise technique : Chad Boyd, Sandu Chirica, Alan Doby, Kaloian Manassiev, Luciano Moreira, Ivan Penkov, Sivagaminathan Rajarethinam, Deborah To, Patrick Woodward, Buck Woody, Stanley Yau et Warren Young.


 Le petit c&#226;bleur: Le protocole DHCPv6
Le petit câbleur
Le protocole DHCPv6
Joseph Davies

Le protocole DHCP (Dynamic Host Configuration Protocol) a été conçu pour prendre en charge l’attribution d’adresses IP et d’autres informations de mise en réseau aux ordinateurs de façon à ce qu’ils puissent communiquer automatiquement sur le réseau. Avec un réseau IPv6, vous n’avez pas besoin de DHCP pour configurer des adresses, mais il peut y avoir de bonnes raisons de l’utiliser. DHCP for IPv6 (DHCPv6) peut
fournir une configuration d’adresses avec prise en compte des états ou des paramètres de configuration sans prise en compte des états aux hôtes IPv6. Les hôtes IPv6 peuvent utiliser plusieurs méthodes pour configurer des adresses :
La configuration automatique des adresses sans prise en compte des états est utilisée pour configurer des adresses propres à la liaison et des adresses supplémentaire non propres à la liaison, en échangeant les messages de sollicitation de routeur et d’annonce de routeur avec les routeurs avoisinants.
La configuration automatique des adresses avec prise en compte des états est utilisée pour configurer des adresses non propres à la liaison via l’utilisation d’un protocole de configuration tel que DHCP.
Un hôte IPv6 exécute une configuration automatique d’adresses sans prise en compte des états et utilise un protocole de configuration tel que DHCPv6 basé sur les indicateurs suivants dans le message d’annonce de routeur envoyé par un routeur voisin :
Managed Address Configuration Flag, également connu sous le nom de Indicateur M. Lorsqu’il est configuré sur 1, cet indicateur ordonne à l’hôte d’utiliser un protocole de configuration pour obtenir les adresses avec prise en compte des états.
Other Stateful Configuration Flag , également connu sous le nom de Indicateur O. Lorsqu’il est configuré sur 1, cet indicateur ordonne à l’hôte d’utiliser un protocole de configuration pour obtenir les paramètres de configuration.
La combinaison des valeurs des indicateurs M et O peut produire les résultats suivants :
Les indicateurs M et O sont configurés sur 0. Cette combinaison correspond à un réseau sans infrastructure DHCPv6. Les hôtes utilisent des annonces de routeur pour les méthodes non propres à la liaison et d’autres méthodes (configuration manuelle par exemple) pour configurer les autres paramètres.
Les indicateurs M et O sont configurés sur 1. DHCPv6 est utilisé pour les paramètres d’adresses et les autres paramètres de configuration. Cette combinaison est connue sous le nom de prise en compte des états DHCPv6 ; DHCPv6 attribue des adresses avec prise en compte des états aux hôtes IPv6.
L’indicateur M est configuré sur 0 et l’indicateur O est configuré sur 1. DHCPv6 n’est pas utilisé pour attribuer des adresses, uniquement pour attribuer les autres paramètres de configuration. Les routeurs voisins sont configurés pour annoncer des préfixes d’adresses non propres à la liaison, à partir desquels les hôtes IPv6 dérivent des adresses sans prise en compte des états. Cette combinaison est connue sous le nom de DHCPv6 sans prise en compte des états : DHCPv6 n’attribue pas d’adresses avec prise en compte des états aux hôtes IPv6, mais des paramètres de configuration sans prise en compte des états.
L’indicateur M est configuré sur 1 et l’indicateur O est configuré sur 0. Dans cette combinaison, DHCPv6 est utilisé pour la configuration des adresses mais pas pour les autres paramètres. Étant donné que les hôtes IPv6 ont généralement besoin d’être configurés avec d’autres paramètres, comme les adresses IPV6 de serveurs DNS (Domain Name System), cette combinaison est peu probable.
Comme DHCP pour IPv4, les composants d’une infrastructure DHCPv6 consistent en des clients DHCPv6 qui demandent une configuration, des serveurs DHCPv6 qui fournissent la configuration et des agents de relais DHCPv6 transmettant les messages entre les clients et les serveurs lorsque les clients se trouvent sur des sous-réseaux ne disposant pas d’un serveur DHCPv6.

Messages DHCPv6
Comme avec DHCP pour IPv4, DHCPv6 utilise des messages UDP (User Datagram Protocol). Les clients DHCPv6 écoutent les messages DHCP sur le port UDP 546. Les agents DHCPv6 et les agents de relais écoutent les messages DHCPv6 sur le port UDP 547. La structure des messages DHCPv6 est beaucoup plus simple que celle de DHCP pour IPv4, qui avait ses origines dans le protocole BOOTP afin de prendre en charge les postes de travail sans disque. La figure 1 affiche la structure des messages DHCPv6 envoyés entre le client et le serveur.
Figure 1 Messages DHCPv6 entre le client et le serveur
Figure 1 Messages DHCPv6 entre le client et le serveur (Cliquer sur l'image pour la réduire)
Figure 1 Messages DHCPv6 entre le client et le serveur
Figure 1 Messages DHCPv6 entre le client et le serveur (Cliquer sur l'image pour l'agrandir)
Le champ 1-byte Msg-Type (Type Msg 1 octet) indique le type de message DHCPv6. Le champ 3-byte Transaction-ID (ID-Transaction 3 octets) est déterminé par un client et utilisé pour regrouper les messages d’un échange de messages DHCPv6. Suivant le champ Transaction-ID, les options DHCPv6 sont utilisées pour indiquer l’identification du client et du serveur, les adresses et les autres paramètres de configuration. Pour obtenir une liste des options DHCPv6 définies, voir RFC 3315, comme référencé dans l’encadré « DHCPv6 RFC Ressources ».
Les options DHCPv6 sont au format type-durée-valeur (TLV). La figure 2 affiche la structure des options DHCPv6.
Le champ 2-byte Option-Code (Code-Option 2 octets) indique une option spécifique. Le champ 2-byte Option-Code indique la longueur du champ Option-Data (Données-Option) en octets. Le champ Option-Data contient les données de l’option.
Il existe une structure de messages séparée pour les messages échangés entre les agents de relais et les serveurs afin d’enregistrer des informations supplémentaires. La figure 3 affiche la structure de ce type de messages.
Figure 2 Structure des options DHCPv6
Figure 2 Structure des options DHCPv6 (Cliquer sur l'image pour la réduire)
Figure 2 Structure des options DHCPv6
Figure 2 Structure des options DHCPv6 (Cliquer sur l'image pour l'agrandir)
Le champ 1-byte Hop-Count (Nb-Sauts 1 octet) indique le nombre d’agents de relais qui ont reçu le message. Un agent de relais recevant un message peut le rejeter s’il dépasse le nombre de sauts maximal configuré. Le champ 16-byte Link-Address (Adresse-Lien 16 octets) contient une adresse non propre à la liaison attribuée à une interface connectée au sous-réseau sur lequel se situe le client. À partir du champ Link-Address, le serveur peut déterminer l’étendue d’adresses correcte à partir de laquelle attribuer une adresse. Le champ 16-byte Peer-Address (Adresse-Pair 16 octets) contient l’adresse IPV6 du client qui a envoyé le message ou de l’agent de relais qui a relayé le message. Au delà du champ Peer-Address se trouvent les options DHCPv6 qui incluent l’option de message de relais, qui contient le message relayé et d’autres options. L’option de message de relais fournit une encapsulation des messages échangés entre le client et le serveur.
Il n’y a pas d’adresses de diffusion définies pour IPv6. Ainsi, l’utilisation de l’adresse de diffusion limitée pour certains messages DHCPv4 a été remplacée par l’utilisation de l’adresse All_DHCP_Relay_Agents_and_Servers de FF02::1:2 pour DHCPv6. Par exemple, un client DHCPv6 tentant de découvrir l’emplacement du serveur DHCPv6 sur le réseau envoie un message de sollicitation à partir de son adresse propre à la liaison à FF02::1:2. S’il y a un serveur DHCPv6 sur le sous-réseau de l’hôte, il reçoit le message de sollicitation et envoie la réponse appropriée. Plus généralement, un agent de relais DHCPv6 sur le sous-réseau de l’hôte reçoit le message de sollicitation et le transmet à un serveur DHCPv6.
Figure 3 Structure de messages entre le relais et le serveur
Figure 3 Structure de messages entre le relais et le serveur (Cliquer sur l'image pour la réduire)
Figure 3 Structure de messages entre le relais et le serveur
Figure 3 Structure de messages entre le relais et le serveur (Cliquer sur l'image pour l'agrandir)

Échange de messages avec prise en compte des états
Un échange de messages DHCPv6 avec prise en compte des états pour obtenir des adresses IPV6 et des paramètres de configuration (lorsque les indicateurs M et O d’une annonce de routeur reçue sont configurés sur 1) contient généralement les messages suivants :
  • Un message de sollicitation envoyé par le client pour localiser les serveurs.
  • Un message d’annonce envoyé par un serveur pour indiquer qu’il peut fournir des adresses et des paramètres de configuration.
  • Un message de requête envoyé par le client pour demander des d’adresses et des paramètres de configuration à un serveur spécifique.
  • Un message de réponse envoyé par le serveur contacté contenant les adresses et les paramètres de configuration.
S’il y a un agent de relais entre le client et le serveur, il envoie les messages de relais-transfert contenant les messages de sollicitation et de requête encapsulés du client. Le serveur envoie à l’agent de relais les messages relais-réponse contenant les messages d’annonce et de réponse encapsulés du client. Pour une liste complète des messages DHCPv6, voir la figure 4.
Figure 4 Messages DHCPv6 (Close Figure 4)

Message DHCPv6 | Description | Message équivalent DHCP pour IPv4
Sollicitation | Envoyé par un client pour localiser des serveurs. | DHCPDiscover
Annonce | Envoyé par un serveur en réponse à un message de sollicitation pour indiquer la disponibilité. | DHCPOffer
Requête | Envoyé par un client pour demander des adresses ou des paramètres de configuration à un serveur spécifique. | DHCPRequest
Confirmation | Envoyé par un client à tous les serveurs pour déterminer si la configuration d’un client est valide pour le lien connecté. | DHCPRequest
Renouvellement | Envoyé par un client à un serveur spécifique pour étendre la durée de vie des adresses attribuées et obtenir des paramètres de configuration mis à jour. | DHCPRequest
Nouvelle liaison | Envoyé par un client à n’importe quel serveur lorsque aucune réponse au message de renouvellement n’est reçue. | DHCPRequest
Réponse | Envoyé par un serveur à un client spécifique en réponse à un message de sollicitation, de requête, de renouvellement, de nouvelle liaison, d’information-requête, de confirmation, de publication ou de refus. | DHCPAck
Publication | Envoyé par un client pour indiquer que le client n’utilise plus une adresse attribuée. | DHCPRelease
Refus | Envoyé par un client à un serveur spécifique pour indiquer que l’adresse attribuée est déjà utilisée. | DHCPDecline
Nouvelle configuration | Envoyé par un serveur à un client pour indiquer que le serveur dispose de nouveaux paramètres de configuration ou de paramètres mis à jour. Le client envoie ensuite un message de renouvellement ou d’information-requête. | N/A
Information-requête | Envoyé par un client pour demander des paramètres de configuration (mais pas d’adresses). | DHCPInform
Relais-transfert | Envoyé par un agent de relais pour transférer un message à un serveur. Relais-transfert contient un message client encapsulé en tant qu’option relais-message DHCPv6. | N/A
Relais-réponse | Envoyé par un serveur pour envoyer un message à un client via un agent de relais. Relais-réponse contient un message serveur encapsulé en tant qu’option relais-message DHCPv6. | N/A

Échange de messages sans prise en compte des états
Un échange de messages DHCPv6 sans prise en compte des états pour obtenir uniquement des paramètres de configuration (lorsque l’indicateur M est configuré sur 0 et l’indicateur O sur 1) contient généralement les messages suivants : Un message d’information-requête envoyé par le client DHCPv6 pour demander des paramètres de configuration à un serveur et un message de réponse envoyé par un serveur contenant les paramètres de configuration demandés.
Pour un réseau IPv6 disposant de routeurs configurés pour attribuer des préfixes d’adresse sans prise en compte des états aux hôtes IPv6, l’échange DHCPv6 de deux messages peut être utilisé pour attribuer des serveurs DNS, des noms de domaine DNS et d’autres paramètres de configuration non inclus dans le message d’annonce du routeur.

Prise en charge DHCPv6 dans Windows
Windows Vista™ et la nouvelle version de Windows Server® (nom de code « Longhorn ») incluent un client DHCPv6. Le client DHCPv6 tente une configuration DHCPv6 en fonction des valeurs des indicateurs M et O dans les messages d’annonce de routeur reçus. Ainsi, pour utiliser DHCPv6, vous devez configurer les serveurs DHCPv6 et les agents de relais pour servir chacun des sous-réseaux IPv6, puis configurer vos routeurs IPv6 pour définir les valeurs appropriées pour ces deux indicateurs. S’il existe plusieurs routeurs d’annonce pour un sous-réseau donné, ils doivent être configurés pour annoncer les mêmes préfixes d’adresse sans prise en compte des états et les mêmes valeurs pour les indicateurs M et O. Les hôtes IPv6 exécutant Windows® XP ou Windows Server 2003 n’incluent pas de client DHCPv6 et ignorent donc les valeurs des indicateurs M et O dans les annonces de routeur reçues.
Vous pouvez configurer un routeur IPv6 exécutant Windows Vista ou Windows Server « Longhorn » afin de définir l’indicateur M sur 1 dans les annonces de routeur à l’aide de la commande « netsh interface ipv6 set interface InterfaceName managedaddress=enabled ». De même, vous pouvez configurer l’indicateur O sur 1 dans les annonces de routeur à l’aide de la commande « netsh interface ipv6 set interface InterfaceName otherstateful=enabled ».
Le version Bêta 2 de Windows Server « Longhorn » prend en charge un agent de relais DHCPv6 et une configuration DHCPv6 sans prise en compte des états avec le service DHCP Server. Vous pouvez configurer le service DHCP Server pour que les options DHCPv6 soient distribuées à tous les clients DHCPv6 dans l’échange de messages DHCPv6 deux messages décrit précédemment. Microsoft a l’intention d’inclure la prise en charge de l’opération de prise en compte des états DHCPv6 , y compris la possibilité de créer des étendues d’adresses IPv6 dans le composant logiciel enfichable de DHCP, dans la version Bêta 3 de Windows Server « Longhorn ».
DHCPv6 RFC Resource
RFC sélectionnés liés à DHCPv6 :
  • RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
  • RFC 2462 IPv6 Stateless Address Autoconfiguration
  • RFC 3633 IPv6 Prefix Options for DHCP version 6
  • RFC 3646 DNS Configuration Options for DHCPv6
  • RFC 3736 Stateless DHCP Service for IPv6

Joseph Daviesest rédacteur technique chez Microsoft et il enseigne et écrit sur le réseau Windows depuis 1992. Il a écrit cinq livres pour Microsoft Press et on lui doit la chronique en ligne mensuelle Cable Guy de Technet.


 Windows PowerShell: La puissance des variables
Windows PowerShell
La puissance des variables
Don Jones

Si vous travaillez avec un langage de script Windows, tel que VBScript ou KiXtart, vous êtes habitué à ce que les variables ne soient rien de plus qu’une sorte de mécanisme de stockage des données. Windows PowerShell dispose également de variables, mais elles sont beaucoup plus puissantes que les variables des anciens langages de script. Les variables Windows
Les variables PowerShell sont en fait mappées aux classes sous-jacentes de l’infrastructure Microsoft® .NET Framework. Dans cette infrastructure, les variables sont des objets, ce qui signifie qu’elles peuvent contenir des données, mais également les manipuler de nombreuses manières. En fait, les capacités robustes des variables dans Windows PowerShell™ sont la raison pour laquelle le langage de script Windows PowerShell ne contient pas de fonctions de manipulation de données intrinsèques. Ces fonctions ne sont pas nécessaires car les variables fournissent déjà cette fonctionnalité.

Déclaration des variables
Bien que le cmdlet New-Variable de Windows PowerShell vous permette de déclarer une variable et de lui affecter une valeur initiale, vous n’avez pas à l’utiliser. Vous pouvez au lieu de cela créer immédiatement une nouvelle variable en lui attribuant une valeur :
$var = "Hello"

Dans Windows PowerShell, les noms de variables démarrent toujours avec un signe dollar ($) et peuvent contenir un mélange de lettres, chiffres, symboles ou même espaces (toutefois, si vous utilisez des espaces, vous devez encadrer la variable de crochets, comme dans ${Ma Variable} = "Hello"). Cet exemple a créé une nouvelle variable nommée $var et lui a attribué la valeur initiale "Hello". Puisque la valeur est dans ce cas une chaîne de caractères, Windows PowerShell utilisera le type de données String pour enregistrer la valeur. Dans .NET Framework, il s’agit de la classe System.String, qui a peut-être les fonctionnalités les plus intégrées de tous les types de variables. Si je souhaite par exemple obtenir une version en minuscules de la valeur stockée dans $var, je peux faire ceci :
PS C:\> $var.ToLower()
hello
PS C:\>
La méthode ToLower est intégrée à la classe System.String et produit une représentation en minuscules uniquement de la valeur de la chaîne. Elle ne modifie toutefois pas le contenu véritable de la variable $var. Pour voir une liste complète des capacités de la classe System.String, redirigez une variable chaîne vers cmdlet Get-Member, comme ceci :
$var | get-member
La figure 1 affiche le résultat, qui comprend plus d’une vingtaine de méthodes utilisées pour manipuler des chaînes. La quasi-totalité des fonctionnalités offertes par les fonctions de manipulation de chaînes VBScript est fournie à la place par les méthodes d’une variable de chaîne dans Windows PowerShell.
Figure 1 Aperçu du résultat de la classe System.String.
Figure 1 Aperçu du résultat de la classe System.String. (Cliquer sur l'image pour la réduire)
Figure 1 Aperçu du résultat de la classe System.String.
Figure 1 Aperçu du résultat de la classe System.String. (Cliquer sur l'image pour l'agrandir)

De nombreuses capacités des chaînes variables sont plus utiles dans un contexte administratif que dans les fonctions de chaînes d’un langage tel que VBScript. Imaginez que vous avez écrit un script qui lit les chemins d’accès UNC (Universal Naming Convention, convention de dénomination universelle) des fichiers et les utilise ensuite. Il est préférable de vérifier que chaque chemin est bien de type UNC avant de tenter de l’utiliser. La méthode StartsWith permet de confirmer que la valeur d’une chaîne démarre avec les caractères de barre oblique inverse nécessaires à UNC :
PS C:\> $path = "\\Server\Share"
PS C:\> $path.StartsWith("\\")
True
PS C:\>
Comme StartsWith renvoie une valeur booléenne True (Vrai) ou False (Faux), il est possible de l’utiliser dans les constructions logiques :
if ($path.StartsWith("\\")) {
 # code goes here
}
Windows PowerShell fournit même une forme de saisie automatique des méthodes des variables, ce qui réduit la quantité de frappe nécessaire. Si $var contient une chaîne, vous pouvez taper
$var.
et appuyer ensuite sur la touche Tabulation pour afficher le nom de la première méthode de la variable $var. Vous accéderez à la méthode suivante en appuyant de nouveau sur la touche Tabulation, et à la méthode précédente avec Maj+Tabulation. Vous pouvez ainsi parcourir toutes les méthodes disponibles jusqu’à ce que vous trouviez celle que vous voulez.

Confusion et variables
Jusqu’ici, mes exemples ont permis à Windows PowerShell de déterminer le type de données de mes variables. L’affectation d’une chaîne à une variable force principalement la variable à appartenir à la classe System.String. L’affectation d’un nombre à une variable, par contre, a habituellement pour résultat de transformer la variable en un entier (ou, plus précisément, un type Int32, qui peut contenir une plage spécifique de valeurs). Prenez par exemple ceci :
PS C:\> $int = 5
PS C:\> $int | get-member

  TypeName: System.Int32
Cette sortie tronquée montre que Windows PowerShell traite $int comme un Int32, qui dispose de son propre ensemble de méthodes et de propriétés. Son ensemble de méthodes et de propriétés est en fait beaucoup plus réduit que celui du type String.
$Int a été transformé en Int32 car sa valeur n’était pas encadrée de guillemets et qu’elle se composait exclusivement de chiffres. Si elle avait été encadrée de guillemets, il aurait été interprété comme System.String.
Autoriser Windows PowerShell à décider du type de données à utiliser ne produira pas toujours le résultat que vous voulez. Supposez que vous lisez des valeurs d’un fichier et souhaitez que les valeurs soient toujours traitées comme des chaînes. Certaines valeurs peuvent cependant contenir seulement des chiffres, ce qui accroît la possibilité que Windows PowerShell les traite comme des Int32 ou un autre type numérique. Cela peut provoquer des problèmes pour votre script. Si Windows PowerShell ne reconnaît pas la valeur comme étant une chaîne, toutes les méthodes de la classe System.String ne sont alors pas disponibles (et votre script pourrait compter sur l’une des méthodes indisponibles).
Pour remédier à ceci, vous pouvez forcer Windows PowerShell à traiter une variable comme un certain type en déclarant ce type lors de votre première utilisation de la variable. Voici un exemple :
[string]$var = 5
Normalement, $var aurait été un Int32, mais j’ai ici forcé Windows PowerShell à faire de $var une chaîne, pour m’assurer ainsi que je peux utiliser toutes les méthodes associées à la classe System.String. La déclaration du type de variable offre également un type pratique d’auto-documentation du code, car le type de données devant entrer dans $var est alors évident. En fait, j’ai pris l’habitude de toujours déclarer un type spécifique pour toutes mes variables et d’empêcher complètement Windows PowerShell de prendre cette décision. Mes scripts sont ainsi plus prévisibles et cela m’a permis dans plusieurs cas d’économiser une quantité importante de temps de débogage.
Comme on peut s’y attendre, la déclaration de force des variables a des répercussions, bien qu’elles ne soient pas nécessairement mauvaises. Prenez cet exemple, dans lequel le type de la variable n’est pas déclaré :
PS C:\> $me = 5
PS C:\> $me = "Don"
La variable $me était initialement un Int32, mais Windows PowerShell l’a changée en String lorsque la valeur « Don » a été ajoutée. Windows PowerShell peut modifier le type d’une variable selon la nécessité, pourvu que la variable n’ait pas déjà été explicitement affectée d’un type spécifique.
Dans cet exemple, j’ai forcé $me à être un Int32 en utilisant le nom de type [int] :
PS C:\> [int]$me = 5
PS C:\> $me = "Don"
Cannot convert value "Don" to type
"System.Int32". Error: "Input string
was not in a correct format."
At line:1 char:4
+ $me <<<< = "Don"
Ensuite, lorsque j’ai essayé de lui affecter une valeur de chaîne, un message d’erreur s’est affiché. Puisque j’avais forcé explicitement $me à être un Int32, Windows PowerShell s’attendait à convertir la chaîne « Don » en valeur entière. Il n’a pas pu le faire et n’a pas non plus pu changer le type de $me en String.

Tous ces types
De nombreux types sont disponibles dans Windows PowerShell. Vous pouvez en fait utiliser tout type .NET Framework (et ses types disponibles se comptent par centaines). Cependant, Windows PowerShell définit plusieurs raccourcis pour les types de données communs. La figure 2 est seulement une liste partielle qui contient 10 des raccourcis de types les plus habituellement utilisés. Pour la liste complète, reportez-vous à la documentation de Windows PowerShell.
Figure 2 Raccourcis de types communs (Close Figure 2)

Raccourci | Type de données
[datetime] | Date ou heure
[string] | Chaîne de caractères
[char] | Un seul caractère
[double] | Nombre flottant double précision
[single] | Nombre flottant simple précision
[int] | Entier 32 bits
[wmi] | Instance ou collection Windows Management Instrumentation (WMI)
[adsi] | Objet Active Directory Services
[wmiclass] | Classe WMI
[Boolean] | Valeur True ou False (Vrai ou Faux)
Vous pouvez également déclarer le type d’une variable à l’aide du nom de classe .NET Framework complet, comme ceci :
[System.Int32]$int = 5
Cette technique vous permet d’utiliser des types qui sont dans .NET Framework mais ne disposent pas d’un raccourci spécifique dans Windows PowerShell.

Extension des types
Le plus intéressant avec Windows PowerShell est peut-être sa possibilité d’étendre les capacités de ces types de variables. Dans le dossier d’installation de Windows PowerShell (généralement %systemroot\system32\windowspowershell\v1.0, même si le chemin est un peu différent sur les systèmes 64 bits), vous trouverez un fichier appelé types.ps1xml. Vous pouvez modifier ce fichier dans le Bloc-notes ou dans un éditeur XML tel que PrimalScript. Par défaut, la classe System.String n’est pas listée, bien que de nombreux autres types le soient. Cependant, je peux ajouter une nouvelle capacité au type System.String en ajoutant ceci au fichier types.ps1xml.
Après avoir effectué la modification, je dois fermer et rouvrir Windows PowerShell. Je dois également m’assurer que la stratégie d’exécution de scripts locale autorise les scripts non signés à s’exécuter, puisque je n’ai pas signé types.ps1xml :
Set-executionpolicy remotesigned
Maintenant, après avoir redémarré Windows PowerShell, je peux utiliser la nouvelle fonctionnalité, comme ceci :
PS C:\> [string]$comp = "localhost"
PS C:\> $comp.canping
True
PS C:\>
Comme vous pouvez le voir, j’ai ajouté une propriété CanPing à la classe System.String. Elle renvoie True (Vrai) ou False (Faux) pour indiquer si l’ordinateur local est capable d’exécuter une commande ping sur l’adresse contenue dans la chaîne. Dans la figure 3, vous remarquerez que la requête WMI utilise une variable spéciale, $this. La variable $this représente la valeur actuelle contenue dans la chaîne et constitue la manière dont le contenu de la variable de chaîne est passé dans la requête WMI.
Figure 3 Extension du type System.String (Close Figure 3)
<Type>
  <Name>System.String</Name>
  <Members>
    <ScriptProperty>
      <Name>CanPing</Name>
      <GetScriptBlock>
      $wmi = get-wmiobject -query "SELECT *
FROM Win32_PingStatus WHERE Address = '$this'"
      if ($wmi.StatusCode -eq 0) {
        $true
      } else {
        $false
      }
      </GetScriptBlock>
    </ScriptProperty>
  </Members>
</Type>

Laissez une variable faire le travail
Windows PowerShell fournit des types de variables souples et riches en fonctionnalités, ainsi qu’un système tout aussi souple pour l’extension de la fonctionnalité des types. Ces capacités permettent d’intégrer une puissance importante à vos scripts. En fait, les variables peuvent devenir un bloc de construction majeur dans les scripts complexes, en s’appropriant dans de nombreux cas des capacités avancées que vous trouveriez normalement dans une fonction plus complexe.
En apprendre plus en ligne
Rejoignez-moi pour cette série de Webcasts diffusés le second mardi de chaque mois pour continuer à plonger dans les fonctionnalités de création de scripts riches offertes par Windows PowerShell. Consultez microsoft.com/events/series/donjonesscripting.mspx pour vous inscrire dès aujourd’hui.

20 février 2007 Windows PowerShell : Cours intensif de création de scripts
Participez à ce Webcast pour en apprendre plus sur les variables, les constructions de langage, les scripts et les fonctions de Windows PowerShell. Avec ce cours intensif d’une heure, nous démontrons comment le langage de création de scripts simple mais efficace de Windows PowerShell accélère l’automatisation administrative de Windows®. Nous explorons également plusieurs outils de fournisseurs tiers qui facilitent l’écriture de scripts Windows PowerShell.

20 mars 2007 Windows PowerShell : Fonctions, filtres et efficacité
Apprenez à créer un code modularisé et efficace dans les fonctions et les filtres de Windows PowerShell. Nous explorons les règles robustes de portée de Windows PowerShell vous permettant d’encapsuler totalement des fonctions et des filtres et expliquons comment réemployer facilement ces fonctions et ces filtres avec des projets différents. Nous démontrons également comment vous pouvez ajouter vos propres fonctions personnalisées à la portée globale de Windows PowerShell, ce qui permet de créer facilement une bibliothèque de fonctions utilitaires.

17 avril 2007 Windows PowerShell et Windows Management Instrumentation
Windows PowerShell peut accéder à toute la puissance et à toutes les capacités de Windows Management Instrumentation, ou WMI. Nous décrivons non seulement comment utiliser Windows PowerShell pour accéder à WMI, mais également comment passer des objets et des collections WMI au travers du pipeline de Windows PowerShell. Nous explorons comment utiliser les propriétés de WMI et les méthodes des scripts Windows PowerShell et illustrons les fonctionnalités de sécurité et de configuration sous-jacentes de WMI.

22 mai 2007 Windows PowerShell : Conversion depuis VBScript
Vous souhaitez convertir vos scripts, ou peut-être seulement vos compétences, de VBScript vers Windows PowerShell ? Rejoignez ce Webcast pour découvrir comment y parvenir. Nous explorons comment Windows PowerShell inclut toutes les constructions et les fonctionnalités majeures de VBScript, et facilite ainsi la conversion de votre expérience de VBScript vers ce nouvel environnement administratif. Nous illustrons comment convertir des outils de VBScript vers le langage de création de scripts natif de Windows PowerShell. Nous examinons également la structure unique de Windows PowerShell et vous montrons comment commencer à utiliser le langage de création de scripts Windows PowerShell pour que votre travail soit plus efficace et plus performant.

19 juin 2007 Windows PowerShell : Extensions sous le capot
Au cours de ce Webcast, nous explorons comment Windows PowerShell utilise la puissance et la flexibilité de .NET Framework pour contrôler des données et vous procurer des centaines de fonctions intégrées pour la gestion des chaînes, des dates et d’autres types de données. Mais saviez-vous que vous pouvez étendre ces fonctions en utilisant des scripts Windows PowerShell ? Nous vous montrons comment créer des variables de chaîne qui contiennent non seulement un nom d’ordinateur mais peuvent également indiquer si cet ordinateur est en cours de fonctionnement. Apprenez à créer des variables de date et d’heure qui peuvent formater automatiquement leurs données sans avoir recours à des fonctions externes. Prenez part à cette session pour découvrir comment mettre en place toutes sortes de nouvelles fonctionnalités dans Windows PowerShell en quelques minutes seulement, pour une administration encore plus facile et rapide de Windows.

Don Jonesest directeur des projets et services de SAPIEN Technologies et co-auteur de Windows PowerShell : TFM (SAPIEN Press). Vous pouvez contacter Don sur le site www.ScriptingAnswers.com.


 H&#233;, vous le scripteur&#160;!: Nous r&#233;pondons &#224; vos questions sur UO...pour 5&#160;centimes seulement
Hé, vous le scripteur !
Nous répondons à vos questions sur UO...pour 5 centimes seulement
Les scripteurs Microsoft
Télécharger le code de cet article: HeyScriptingGuy2007_03.exe (151KB)

Q Comment faire pour afficher une boîte de dialogue me permettant de sélectionner une UO d’Active Directory ?

VOUS SAVEZ, si les scripteurs recevaient 5 centimes d’euro à chaque fois qu’on leur a posé cette question... euh, ils auraient environ trois euros cinquante. Mais s’ils recevaient 5 centimes pour chaque personne qui voulait poser cette question mais qui ne l’a jamais fait, ils auraient... bref, peu importe. Après tout, on n’est pas devenus scripteurs pour l’argent. Nous sommes devenus scripteurs pour la satisfaction ressentie lorsque nous aidons des gens à exécuter leurs tâches d’administration système plus rapidement et avec une plus grande facilité.
Remarque. Ok, techniquement, on est devenus scripteurs pour l’argent. Mais ensuite notre responsable nous a dit : « Vous savez, si vous voulez vous faire beaucoup d’argent, il va falloir que vous travailliez dur et que vous ne produisiez que de la qualité ». C’est là qu’on s’est dit que l’argent, c’était pas tout finalement.
Bref. En fait, beaucoup de gens aimeraient savoir comment faire pour afficher une boîte de dialogue leur permettant de sélectionner une UO et donc de se connecter à cette UO à l’aide d’un script. « Vous nous avez montré comment faire pour afficher une boîte de dialogue nous permettant de choisir des dossiers », nous a-t-on dit récemment, « et vous nous avez montré comment faire pour afficher une boîte de dialogue nous permettant de choisir des fichiers. Pourquoi ne nous avez-vous jamais montré comment faire pour afficher une boîte de dialogue nous permettant de choisir une UO dans Active Directory® ? »
Pour commencer, oui, c’est vrai, nous avons montré aux gens comment faire pour afficher une boîte de dialogue leur permettant de sélectionner un dossier ; vous en trouverez des exemples ici. Nous avons également montré à tout le monde comment afficher une boîte de dialogue permettant de sélectionner des fichiers ; aller voir microsoft.com/technet/scriptcenter/resources/qanda/jan05/hey0128.mspx si vous ne nous croyez pas. Ceux deux articles ont été bien reçus, et nous savons que les gens emploient ces techniques dans leurs scripts. Alors pourquoi donc n’avons-nous pas montré aux gens comment afficher une boîte de dialogue leur permettant de sélectionner des UO dans Active Directory ? C’est une conspiration de Microsoft ou quoi ?
Absolument pas. (Attendez un peu... c’est exactement ce que dirait quelqu’un impliqué dans une conspiration, non ?) En fait, nous avons une bonne raison : la boîte de dialogue en question n’existe pas. Comme on le dit parfois au base-ball, on ne peut pas tirer sur ce qu’on ne voit pas. Et comme on dit dans le métier, on ne peut pas afficher ce qui n’existe pas.
Donc voilà, c’est tout pour ce mois-ci, on dirait. À la prochaine fois.
Ah, ce serait bien. Selon les éditeurs de Technet Magazine, ce n’est pas tout pour ce mois-ci. « Cette boîte de dialogue n’existe pas, et alors ? » nous ont-il dit. « C’est vous qui écrivez les scripts, bon sang. Vous ne pouvez pas créer cette boîte de dialogue ? On pensait que vous pouviez faire n’importe quoi en matière de scripts. »
Inutile de préciser que les éditeurs de Technet Magazine se font vraiment des illusions. Faire n’importe quoi en matière de scripts ? Euh, pas vraiment. En fait, les scripteurs ne savent faire qu’une chose en matière de scripts.
Coup de chance, la seule chose qu’ils sachent faire, c’est créer une boîte de dialogue vous permettant de sélectionner une UO d’Active Directory. Jetez un coup d’œil à la figure 1.
Long script, hein ? Mais vous savez ce qu’on dit : on ne peut pas faire une omelette sans casser d’œufs. De la même manière, on ne peut pas construire une boîte de dialogue personnalisée sans casser quelques œufs (on a dû faire une pause en cours de rédaction de ce document, on avait faim). Maintenant qu’on est rassasiés, on va essayer de vous expliquer comment ça fonctionne.
En fait, nous utilisons le modèle d’objet Internet Explorer® pour construire une pseudo boîte de dialogue. Nous créons ainsi une instance d’Internet Explorer, récupérons quelques UO d’Active Directory, puis les affichons sous la forme d’une liste dans une fenêtre Internet Explorer. Nous attendons que l’utilisateur sélectionne une UO, puis récupérons l’ADsPath de l’élément sélectionné, éliminons la pseudo boîte de dialogue et continuons à partir de là.
Remarque. Est-ce que ça va être la boîte de dialogue la plus jolie jamais crée ? Oui, si par « la plus jolie » vous voulez dire une boîte ultra simpliste ne comportant même pas de bouton OK ou Annuler. Mais, pour notre défense, l’idée est simplement de vous donner la base. Si vous voulez rendre la boîte de dialogue plus jolie, débrouillez-vous tous seuls.
(Si on avait 5 centimes pour toutes les fois où on a dit « débrouillez-vous tous seuls », on serait vraiment riches. Envoyez vos dons aux Scripteurs c/o Technet Magazine.)
Afin que l’explication de notre technique tienne dans l’espace qui nous a été attribué, nous allons devoir faire quelques raccourcis. Par exemple, nous nous contenterons de dire que le bloc de code suivant crée une instance d’Internet Explorer de 350 pixels par 400, et masque ainsi la barre d’adresse et la barre d’état par exemple ;
Set objExplorer = CreateObject( _
    "InternetExplorer.Application")

objExplorer.Navigate "about:blank"
objExplorer.ToolBar = 0
objExplorer.StatusBar = 0
objExplorer.Width= 350
objExplorer.Height = 400
objExplorer.Left = 400
objExplorer.Top = 400
objExplorer.Visible = 1
en fait, ça nous donne une fenêtre Internet Explorer vierge. Afin d’obtenir la liste d’UO dans notre domaine, il faut réaliser une recherche dans Active Directory. Nous ne pouvons pas rentrer dans les détails concernant les recherches dans Active Directory aujourd’hui ; pour plus d’informations à ce sujet, jetez un coup d’œil à notre série en deux parties dans le Script Center (microsoft.com/technet/scriptcenter/resources/tales/sg0405). Ce que nous pouvons faire, c’est vous dire que le code que nous utilisons pour récupérer le Nom et l’ADsPath de chaque UO dans le domaine fabrikam.com est le suivant :
objCommand.CommandText = _
    "SELECT Name, ADsPath FROM 'LDAP://DC=fabrikam,DC=com' WHERE objectCategory=
    'organizationalUnit' ORDER BY Name"
Oh, et pour vous rendre les choses plus faciles, nous avons aussi trié les UO alphabétiquement par nom. C’est à ça que sert la clause ORDER BY Name (Trier par nom). (À votre service).
Lorsque nous appelons la méthode Exécuter, nous récupérons une liste de toutes les UO trouvées sur fabrikam.com. Cela signifie que la prochaine étape consiste à afficher chacune de ces UO dans une zone de liste.
Comment procédons-nous ? Il faut tout d’abord créer la zone de liste entière dans la mémoire. Pour commencer, cela signifie utiliser cette ligne de code pour enregistrer la balise <SELECT> dans une variable nommée strHTML :
strHTML = "<select size = '20' name='OUList' style='width:300px'>"
Que faisons-nous avec cette ligne de code ? Nous construisons tout simplement une zone de liste HTML standard (oui, c’est une chose que l’on fait à l’aide de la balise <SELECT>). En chemin, nous donnons à la zone de liste le nom ListeUO et nous la configurons pour afficher 20 éléments à la fois dans un cadre de 300 pixels (300px) de large. Si vous connaissez un peu l’HTML, le code précédent devrait vous paraître assez familier.
Ensuite, il faut ajouter des éléments (des UO) à la zone de liste. Par une coïncidence incroyable, notre liste est en fait constituée d’informations concernant chacune des UO de notre domaine. Grâce à cela, nous pouvons configurer une boucle Do Until passant en revue la liste entière, récupérant les informations et ajoutant chaque UO à la zone de liste. Dans cette boucle, nous utilisons le code suivant (une nouvelle fois, HTML standard pour ajouter des éléments à une zone de liste) pour ajouter chaque UO, en configurant les éléments de façon à ce que le nom de l’UO soit affiché dans la liste et que, si vous cliquez sur cette UO dans la zone de liste, l’ADsPath soit transmis au script :
strHTML = strHTML & "<option value= " & _
    Chr(34) & objRecordSet.Fields
    ("AdsPath").Value & Chr(34)
strHTML = strHTML & ">" & objRecordSet.
    Fields("Name").Value
Pourquoi transmettre l’ADsPath au script ? C’est simple : imaginons que nous transmettions le nom de l’UO à la place. Si le nom est par exemple Finance, il sera difficile d’établir une liaison vers cette UO, étant donné que « Finance » ne constitue pas une chaîne ADSI valide. Mais avec l’ADsPath (LDAP://ou=Finance,dc=fabrikam,dc=com), c’est du gâteau. Parce que l’ADsPath, c’est exactement ce dont nous avons besoin pour localiser un objet dans Active Directory et y établir une connexion.
Incidemment, nous affichons le nom dans la zone de liste parce que nous partons du principe que vos UO ont des noms uniques. Cela pourrait ne pas être le cas ; par exemple, les UO Amérique du nord\Recherche et Europe\Recherche ont le même nom (Recherche). Dans ce cas, il vaudrait sans doute mieux utiliser une propriété différente (ADsPath ou distinguishedName, par exemple) dans la zone de liste. À vous de décider. (Et tac ! Une autre pièce !)
Bon, n’oublions pas que nous sommes toujours en train de construire la zone de liste dans la mémoire : chaque élément ajouté à la zone est ajouté à la variable strHTML. Tout cela fait partie du plan : nous enregistrons le code entier de la zone de liste dans la variable strHTML, puis utilisons la valeur de cette variable pour ajouter la zone de liste à notre instance d’Internet Explorer.
Une fois toutes les UO ajoutées, nous utilisons cette ligne de code pour indiquer la fin de la zone de liste :
strHTML = strHTML & "</select>"
À ce stade, strHTML contient toutes les balises HTML nécessaires pour créer une zone de liste, et (encore mieux) une zone de liste dans laquelle chaque élément représente une UO d’Active Directory. Cela signifie que nous pouvons à présent attribuer la valeur de strHTML à la propriété InnerHTML de notre document Internet Explorer :
objExplorer.Document.Body.InnerHTML = strHTML
En retour, nous obtenons une zone de liste affichant toutes les UO d’un domaine.
Attendez une minute, ce n’est pas fini. Par exemple, nous avons encore besoin de code nous permettant de mettre notre script en pause jusqu’à ce que l’utilisateur ait sélectionné une UO dans la boîte de dialogue ; sans cela, la zone de liste serait affichée mais le script continuerait de s’exécuter, que l’utilisateur ait fait une sélection ou non. Aïe ! Pour éviter que cela ne se produise, nous utilisons ce bloc de code :
Do While objExplorer.Document.Body.All.OUList.Value = ""
    Wscript.Sleep 300
Loop
En fait, nous vérifions de façon répétée la Valeur de notre zone de liste (que nous avons nommée ListeUO, comme vous vous en souvenez peut-être). Si la Valeur est une chaîne vide (ce qui signifie qu’aucun élément n’a été sélectionné), le script est mis en pause pendant 300 millisecondes, puis la boucle est relancée et une nouvelle vérification a lieu. Ceci continue : a) éternellement ; b) jusqu’à ce que l’utilisateur ait sélectionné un élément dans la zone de liste ; ou c) jusqu’à ce que l’utilisateur ait fermé la fenêtre Internet Explorer.
Supposons que l’utilisateur sélectionne une UO dans la zone de liste. Dans ce cas, nous prenons la Valeur (qui est l’ADsPath de l’UO) et l’attribuons à une variable nommée strTargetOU :
strTargetOU = objExplorer.Document.Body.All.OUList.Value
Nous utilisons ensuite la méthode Quitter pour abandonner notre instance d’Internet Explorer comme illustré ci-dessous :
objExplorer.Quit
À ce stade, nous avons presque terminé. Nous regardons tout d’abord si strTargetOU est égal à une chaîne vide :
If strTargetOU = "" Then
    Wscript.Quit
End If
si c’est le cas, cela signifie que l’utilisateur a fermé Internet Explorer sans sélectionner d’UO ; nous utilisons alors la méthode Wscript.Quit pour arrêter le script. (Nous partons du principe que si l’utilisateur n’a pas sélectionné une UO, c’est qu’il ou elle n’a pas envie d’exécuter le script). Si toutefois strTargetOU n’est pas égal à une chaîne vide, nous renvoyons la valeur de la variable :
Wscript.Echo strTargetOU
Bien sûr, dans un script réel, vous choisiriez sans doute d’établir une liaison vers cette UO dans Active Directory au lieu de renvoyer simplement l’ADsPath. Mais vous savez ce qu’on va vous répondre : débrouillez-vous tous seuls dans ce cas.
Comme nous l’avons mentionné, et comme vous pouvez le voir à la figure 2, ce n’est pas la boîte de dialogue la plus jolie jamais créée, mais elle fonctionne, et c’est bien plus simple que d’avoir à saisir un ADsPath (en supposant que vous le connaissiez). En outre, vous disposez ainsi de l’opportunité de personnaliser le code et la boîte de dialogue comme vous le souhaitez.
Figure 2 Une boîte de dialogue de script simple
Figure 2 Une boîte de dialogue de script simple

Ah, si on recevait 5 centimes pour chaque document traitant de l’affichage d’une boîte de dialogue permettant de sélectionner une UO d’Active Directory... Après tout, ça ferait 5 centimes de plus que ce que nous paie Technet Magazine.
Non pas qu’on se plaigne, bien sûr !

Les scripteurs Microsofttravaillent pour (enfin, sont employés par) Microsoft. Lorsqu’ils ne sont pas en train de jouer au base-ball, d’entraîner une équipe ou de regarder un match (ou de se livrer à de multiples autres activités), ils dirigent le Script Center TechNet. Vous pouvez le vérifier vous-même sur www.scriptingguys.com.


 Exchange Queue &amp; A: Journaux des transactions, Cmdlets, gestion &#224; distance et plus encore
Exchange Queue & A
Journaux des transactions, Cmdlets, gestion à distance et plus encore
KC Lemson and Nino Bilic

Q Pourquoi avez-vous réduit la taille du journal des transactions à 1 Mo dans Microsoft® Exchange Server 2007 ?
R Hé bien, dans Exchange 2007 nous avions ce truc sympa appelé envoi de journaux, qui correspond à la technologie inhérente à quelques nouvelles fonctionnalités appelées réplication continue locale (Local Continuous Replication, LCR) et réplication continue en cluster (Clustered Continuous Replication, CCR). Une fois l’envoi activé au niveau groupe de stockage (SG), les journaux des transactions du SG sont copiés à partir du SG de production en cours au SG de copie. Les journaux du SG de copie sont rejoués dans la base de données pour qu’elle soit à jour. Certes, cette explication du processus est simplifiée, mais elle donne une vision d’ensemble.
Le fait est que les journaux des transactions ne peuvent pas être envoyés au SG de copie sauf si le journal est fermé sur le SG de production. En d’autres termes, le journal e00 ( le journal actuel dans le premier groupe de stockage) ne peut pas être envoyé tant qu’il n’est pas complet, fermé et renommé. En outre, il existe des paramètres de contrôle du nombre de journaux en retard dans ce processus, car un compromis doit exister entre disponibilité et performance. (Ces paramètres sont disponibles en exécutant la cmdlet Set-MailboxServer dans Exchange Management Shell. Le fichier d’aide fournit des détails sur les paramètres exacts nécessaires.)
En résumé, nous avons diminué la taille de journal des transactions pour réduire la quantité de données pouvant être désynchronisées entre deux copies du groupe de stockage. Par exemple, lors d’incidents de disque dur de la base de données de production, vous aurez besoin de prendre des mesures pour démarrer le SG de la copie. En diminuant la taille des journaux des transactions, les chances de perdre des donnés sont réduites.
Cela ne veut pas dire que nous pouvons garantir que vous ne perdrez qu’1 Mo de données. En considérant ces fichiers comme des journaux de transactions, il est possible que la perte d’un fichier journal d’1 Mo puisse contenir, par exemple, une transaction VALIDER de 5 Mo de données. Dans ce cas, ces 5 Mo de données manqueraient sur la copie (bien que vous puissiez avoir reçu cinq des journaux contenant les données elles-mêmes, le dernier journal contenant une petite partie des données et la transaction VALIDER nécessaire est essentiel).
En fin de compte, c’est à vous d’évaluer le risque au vu des besoins de votre entreprise. Une perte de données mineure avec un temps de récupération de seulement quelques minutes pourraient être parfaitement acceptable comparé à un travail de restauration des données pouvant nécessiter plusieurs heures. Nous approfondirons plus en détail ce sujet à l’avenir !

Q Les journaux de transactions étant plus courts maintenant, va-t-on « manquer » de journaux de transactions plus rapidement ?
R Dans le contexte d’Exchange, « manquer » fait référence aux noms de journaux de transactions. Dans Exchange Server 2003, les journaux des transactions sont nommés comme suit :
E nn fffff.log
Le nn est le préfixe qui change de SG à SG. Puisque nn reste identique pendant la durée de vie du SG, le nombre de journaux de transactions nommés de manière unique pouvant être créés pour le groupe de stockage est représenté essentiellement par la valeur « fffff », qui correspond à peu près à un million de journaux (note personnelle : mettre le petit doigt sur le coin de la bouche et ricaner). Certains de nos clients ont atteint cette limite sur des serveurs de messagerie occupés.
Depuis Exchange Server 2000, nous avons fourni un correctif pour afficher un événement dans le journal des applications à l’approche de cette limite. (Pour obtenir plus d’informations sur ce sujet, voir support.microsoft.com/kb/896001).
Ceci étant dit, qu’en est-il d’Exchange 2007 ? Nous venons de dire que les journaux des transactions sont passés de 5 Mo (taille dans les versions précédentes d’Exchange) à 1 Mo (taille dans Exchange 2007). Cela signifie-t-il qu’il faille juste un cinquième des données pour épuiser les noms de journaux des transactions uniques ?
La réponse est : non. Dans Exchange 2007, le nom du journal des transactions est sous le format suivant :
E nn ffffffff.log
Notez que nous pouvons travailler avec des journaux « ffffffff », plutôt que « fffff » comme dans les versions précédentes d’Exchange. Pour des raisons de calcul du moteur de stockage extensible (Extensible Storage Engine, ESE), Exchange 2007 ne peut pas créer tous les journaux « ffffffff ». Au lieu de cela, il crée des journaux « 7fffffec » ce qui représente encore un grand nombre (convertissez ceci de sextuple en décimal si vous ne nous croyez pas) !
Qu’est ce que tout cela signifie en pratique ? En pratique, cela signifie qu’avec Exchange 2007 vous pouvez créer environ 2048 fois plus de journaux que dans les versions précédentes d’Exchange. Factorisons maintenant les journaux d’un cinquième de taille :
2048 / 5 = 409.6
Comme vous pouvez le voir, le nouveau schéma d’appellation de journal peut gérer 409 fois plus de données que l’ancien ! Souvenez-vous, par SG et non par serveur, parce que chaque groupe de stockage aura un préfixe de fichier journal différent (tel que e00, e01 et ainsi de suite). Reste à mentionner que vous pouvez créer 50 SG par serveur sur la version Entreprise d’Exchange 2007 ? Nous estimons qu’il y a peu de chance que quelqu’un puisse manquer de journaux des transactions dans un avenir proche !

Q Comment puis-je gérer à distance mes serveurs Exchange 2007 ?
R Il existe quelques options pour gérer à distance les serveurs Exchange 2007. Premièrement, vous pouvez installer les outils d’administration Exchange 2007 sur une autre machine d’Exchange server, aussi longtemps que cette machine exécute la version 32 bits ou 64 bits de Windows Server® 2003 Service Pack 1 (SP1) ou plus récente, Windows Server 2003 R2, ou Windows XP SP2 ou plus récente. Notez que l’installation de rôles de serveur (accès client, boîte aux lettres, Edge etc.) sur un matériel 32 bits n’est pas prise en charge dans des environnements de production, mais seulement pour l’installation d’outils de gestion sur une machine 32 bits. Notez également que depuis la version initiale d’Exchange Server 2007, les outils de gestion ne sont pas pris en charge sur Windows Vista™.
Dans certaines organisations, le département informatique crée un seul serveur censé être le serveur de gestion, en installant tous les outils de gestion nécessaires aux divers produits sur ce serveur. Ensuite les administrateurs ayant besoin d’utiliser ces outils accèdent au serveur de gestion via le serveur Terminal Server afin de pouvoir exécuter l’administration à distance. Suivant d’autres paramètres, les utilisateurs installent les outils de gestion sur leurs propres poste de travail.
À partir de la console ou de l’interpréteur de commandes, vous pouvez effectuer des opérations sur les serveurs de votre organisation. Les serveurs sont visibles sur la console de sorte que vous pouvez exécuter des opérations à distance sur n’importe lequel. Sur l’interpréteur de commandes, plusieurs tâches prennent en charge un serveur de type indicateur de filtrage au cas où vous vouliez étendre une opération à un seul serveur. Il existe toutefois quelques exceptions, pour les commandes devant être exécutées localement, telles que la commande Get-NetworkConnectionInfo.

Q Dans votre dernière chronique, vous avez donné quelques précisions au sujet de la taille de mémoire vive (RAM) recommandée pour un serveur Exchange 2007. Qu’en est-il de la taille du fichier d’échange ?
R Afin d’empêcher des erreurs potentielles d’insuffisance de mémoire virtuelle sur les serveurs Exchange 2007, nous recommandons les indications suivantes pour déterminer la taille de votre fichier d’échange système.
Si le serveur a moins de 8 Go de mémoire vive (RAM), la taille minimale du fichier d’échange doit correspondre à la quantité de RAM plus 10 Mo. Pour un serveur avec 4 Go de mémoire vive (RAM), la taille minimale doit être de 4 Go plus 10 Mo. La taille recommandée du fichier d’échange, cependant, correspond à la quantité de mémoire vive (RAM) multipliée par 1,5. Donc pour un serveur de 4 Go, la taille est égale à 6 Go.
De plus, la taille minimale pour le fichier d’échange est calculée de la même manière pour un serveur ayant plus de 8 Go de mémoire vive (RAM) , c’est-à-dire, la quantité de RAM plus 10 Mo. Cependant, la taille recommandée est définie de manière différente. Fondamentalement, sur un serveur ayant plus de 8 Go de mémoire vive (RAM), vous ne pouvez utiliser qu’une fois et demie la quantité de mémoire vive (RAM) si vous recevez de messages d’erreur d’insuffisance de mémoire virtuelle avec des fichiers d’échange plus petits.
Notez que les erreurs mentionnées dans ce cas n’ont rien à voir avec la fragmentation de la mémoire virtuelle (ce problème existe avec les serveurs Exchange 2000 et Exchange 2003). Il s’agit d’erreurs contextuelles réelles enregistrées par le système indiquant que la taille du fichier d’échange est augmentée ou que le fichier d’échange est trop petit.

Q J’aimerais apprendre à utiliser Exchange Management Shell, mais je n’ai jamais utilisé de ligne de commande pour administrer mes systèmes auparavant. Par où dois-je commencer ?
Abordons en premier quelques principes fondamentaux. Dans Exchange Management Shell, chaque cmdlet comprend un seul verbe et un seul nom. Exchange Management Shell n’utilise qu’un petit nombre de verbes : « Get » est utilisé pour récupérer des propriétés d’objets, « Set » pour modifier les propriétés d’objet, « New » pour créer de nouveaux objets, et ainsi de suite. Les substantifs utilisés dans Exchange Management Shell incluent un grand nombre de concepts connus de tous les administrateurs d’Exchange (par exemple, Mailbox, Contact, Queue et OWAVirtualDirectory). Il existe également des concepts nouveaux dans Exchange Server 2007 (tels que TransportRule, StorageGroupCopy et UMAutoAttendant). Donc, dans la pratique, une cmdlet de base ressemblera à ceci New-Mailbox (pour créer une nouvelle boîte aux lettres) ou bien Get-Mailbox (pour récupérer une liste de boîtes aux lettres de l’organisation).
La plupart des cmdlets, cependant, exigera plus de détails sur ce que vous essayez d’accomplir. Si vous voulez modifier une propriété sur une boîte aux lettres, par exemple, vous devrez spécifier la boîte aux lettres et la propriété. Pour ce faire utilisez des paramètres. Si New-Sandwich était une cmdlet, alors les paramètres pourraient être -NumberOfTomatoSlices 4, -Bread Wheat et divers options similaires qui spécifient plus en détail la forme du sandwich (-FlufferNutter $true-ahhhh yum).
Une fois que vous avez compris la division verbe-nom, vous pouvez utiliser la ligne de commande dans l’assistant Exchange Management Console (EMC) pour vous familiariser avec les opérations que les cmdlets exécutent. Utilisez l’assistant Exchange Management Console (EMC) pour créer un nouvel utilisateur. À la fin de l’assistant, une fois l’opération complétée, vous verrez une copie de la commande que l’assistant a exécuté en coulisses (voir la figure 1). Appuyez sur Ctrl+C pour copier le contenu de la boîte de dialogue pour pouvoir coller la cmdlet dans le bloc-notes et assembler vos propres fichiers batch.
Figure 1 Exposition de la ligne de commande pour créer un nouvel utilisateur
Figure 1 Exposition de la ligne de commande pour créer un nouvel utilisateur (Cliquer sur l'image pour la réduire)
Figure 1 Exposition de la ligne de commande pour créer un nouvel utilisateur
Figure 1 Exposition de la ligne de commande pour créer un nouvel utilisateur (Cliquer sur l'image pour l'agrandir)
Si vous voulez vous entraîner à utilise des cmdlets (sans causer de dommages), une bonne astuce consiste à placer -WhatIf à la fin de la commande. Le système vous indiquera comment la commande sera exécutée sans faire aucune modification au système.
Une fois familiarisé avec les cmdlets de base telles que *-Mailbox, vous voudrez probablement en essayer d’autres. Pour trouver d’autres cmdlets, utilisez la cmdlet Get-ExCommand. Une liste de toutes les cmdlets de gestion Exchange s’affichera. (Vous devez le faire en exécutant Exchange Management Shell. Une simple ouverture d’Exchange Management Shell ou de Windows PowerShell™ ne vous permettra pas de le faire ni d’effectuer d’autres tâches de gestion d’Exchange). Le liste est énorme, servez-vous donc de la correspondance générique pour trouver ce que vous recherchez. Par exemple, Get-ExCommand *base de données* renvoie une liste de toutes les cmdlets d’Exchange ayant « base de données » dans le nom telles Dismount-Database, Move-DatabasePath et New-MailboxDatabase.
Si vous pensez connaître une partie du nom que vous cherchez, vous pouvez afficher tour à tour les options. Par exemple, vous pouvez taper Get-Mailbox puis appuyer sur la touche de tabulation pour parcourir toutes les cmdlets avec le nom mailbox dans le nom de la tâche. Vous pouvez même combiner correspondance générique et tabulation. Par exemple, vous pouvez taper Get-*Mailbox* et tabuler les options possibles.
Il est également possible d’utiliser une invite Chaque cmdlet est dotée d’une série de paramètres requis par défaut, les paramètres de base nécessaires pour exécuter l’opération. Les cmdlets « Get », telles que Get-Mailbox, ne nécessitent aucun paramètre. Par défaut, Get-Mailbox renvoie une liste de toutes les boîtes aux lettres de l’ensemble de l’organisation. (Par défaut la liste contient une nombre maximal de 1000. Pour modifier ce maximum, vous pouvez taper Get-Mailbox -ResultSize 2000, par exemple.) Des cmdlets qui créent ou modifient des objets (Set ou New) vous inviteront à entrer l’information nécessaire sur l’objet à créer ou à modifier. Si vous exécutez New-Mailbox, par exemple, l’interpréteur de commandes vous invitera tour à tour à entrer le mot de passe, la base de données, le nom et ainsi de suite.
Pour en savoir plus sur les paramètres possibles d’une cmdlet donnée, utilisez le système d’aide : Aide sur Move-DatabasePath. (Vous pouvez également taper Move-DatabasePath, Move-DatabasePath -? et ainsi de suite, nous essaierons de tous les passer en revue). L’aide vous donnera une description de la cmdlet et une liste des paramètres avec l’objet de chacun d’eux. L’aide est accessible également à partir de la cmdlet Get-Help. (Quel plaisir de simplement taper Get-Help ? Ne souhaitez-vous pas que votre entourage puisse simplement exécuter cette cmdlet dans la vie de tous les jours) ?
Une autre façon de découvrir les paramètres possibles sur une cmdlet consiste à utiliser la tabulation sur les noms de paramètre. Tapez Get-Mailbox -S puis appuyer sur la touche de tabulation ; vous parcourrez les paramètres possibles commençant par S.
Bien sûr, il y a aussi le système d’aide complet. Si vous ne trouvez pas ce que vous recherchez hors ligne, n’oubliez pas de consulter régulièrement le contenu d’aide mis à jour à go.microsoft.com/fwlink/?linkid=79421 et le guide de référence rapide à go.microsoft.com/fwlink/?linkid=64647.
Ceci vous permettra de mettre en route Exchange Management Console, bien que ces informations donnent juste un avant-goût de la flexibilité et de la puissance de la ligne de commande. Nous l’examinerons plus en détail dans les prochaines chroniques.

Q Dans Exchange Server 2003 ESM (Exchange System Manager), nous pouvions facilement observer la taille des boîtes aux lettres de tous les utilisateurs. Cette fonctionnalité semble avoir disparu dans Exchange 2007. Est-il possible d’obtenir cette information dans Exchange 2007 ?
R Dans la nouvelle console d’Exchange 2007, vous pouvez obtenir la taille d’une boîte aux lettres sur la page de propriétés générales de la boîte aux lettres elle-même. Pour afficher cette information pour plusieurs utilisateurs, vous devez utiliser Exchange Management Shell.
Si vous exécutez Get-MailboxStatistics, vous obtenez les données sur l’ensemble d’un serveur (pas juste une base de données spécifique). Par défaut, la taille n’est pas affichée, vous devez exécuter la cmdlet avec Format-List pour l’obtenir :
get-mailboxstatistics | format-list
Il est même préférable de choisir ce que vous voulez voir et le transférer dans une table. Dans cet exemple, nous obtenons le nom affiché de la boîte aux lettres, la taille totale de l’élément , la taille totale de l’élément supprimé et la base de données de la boîte aux lettres :
Get-MailboxStatistics | Select-Object
displayname,totalitemsize,
totaldeleteditemsize,databasename
| Format-Table
Selon les informations que vous recherchez, vous pouvez afficher les résultats sous différents formats. Dans cet exemple, Format-Table semble fonctionner mieux que Format-List

KC Lemson est responsable en chef de programme de l’équipe Exchange Server. Son numéro d’identification de distributeur automatique est 0000, mais ne dépensez pas tout en un seul endroit
Nino Bilicest responsable technique, il consacre le plus clair de son temps libre à collectionner les chèques de 1 000 $ de Bill en guise de remerciement pour le transfert de son message électronique


 Vigilance s&#233;curit&#233;: D&#233;ploiement d’EFS&#160;: 2&#232;me partie
Vigilance sécurité
Déploiement d’EFS : 2ème partie
John Morello

Le déploiement du système de fichiers EFS (Encrypting File System) peut essentiellement être considéré comme composé de deux parties : la portion conceptuelle dorsale, qui porte principalement sur la gestion des certificats et les agents de récupération, et la portion de déploiement d’EFS visible par l’utilisateur. J’ai décrit le mois dernier la portion dorsale et abordé les options de récupération de données et de clés,
ainsi que les options de création de certificats pour les clients. Je me concentrerai principalement ici sur les aspects du déploiement que vos utilisateurs finaux verront, comme les améliorations de l’Explorateur Windows®, le choix des emplacements du système de fichiers à chiffrer et la gestion des options de chiffrement avec la stratégie de groupe.

Déterminer si EFS est déjà utilisé
Une fois que vous avez décidé de déployer EFS, la première étape consiste à déterminer l’état actuel d’utilisation d’EFS dans votre organisation. Souvenez-vous qu’EFS peut être utilisé en mode autonome, dans lequel l’utilisateur final est entièrement responsable de la création et de la sauvegarde de ses clés de chiffrement. Des utilisateurs de votre organisation utilisent peut-être déjà EFS de cette manière et il est donc important de déterminer qui sont ces utilisateurs afin d’assurer une transition facile vers un déploiement plus géré.
La première fois qu’EFS est employé par un utilisateur donné sur son ordinateur, Windows crée l’entrée de registre suivante dans HKEY_CURRENT_USER :
HKCU\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys\CertificateHash
Microsoft® Systems Management Server (SMS), les scripts d’ouverture de session d’Active Directory et d’autres outils peuvent être utilisés pour vérifier la présence de cette entrée sur les ordinateurs dans toute l’entreprise. Si cette valeur de registre est présente pour un utilisateur, c’est qu’il a utilisé EFS à un certain moment. Cependant, cette valeur n’indique pas nécessairement que quelqu’un utilise actuellement EFS ou que certaines de ses données sont chiffrées. Ainsi, lorsqu’un ordinateur disposant de cette clé de registre est trouvé, il doit être examiné de plus près pour déterminer si des fichiers sont actuellement chiffrés.
Utilisez cipher.exe avec les commutateurs /U et /N pour lui ordonner d’indiquer l’état de chiffrage des fichiers et des répertoires d’un ordinateur. Par exemple, si vous souhaitez déterminer si certaines données d’un système ont été chiffrées, vous pourriez exécuter la commande suivante :
cipher /U /N
La vérification du Registre et le rapport de cipher peuvent être combinés dans un script commun pour vérifier la présence de la valeur du Registre et, si celle-ci est présente, générer un compte-rendu des fichiers actuellement chiffrés sur l’ordinateur. Une fois ces rapports générés, vous saurez quels sont les utilisateurs qui ont des fichiers chiffrés et quels sont ces fichiers, et serez prêt à les migrer vers une conception à gestion centralisée.
Pour contrôler l’application de la stratégie de groupe pendant le déploiement, il est utile de créer deux groupes de sécurité dans votre domaine pour séparer les ordinateurs sur lesquels EFS est utilisé de ceux pour lesquels ce n’est pas le cas. Par exemple, « SG-ComputersUsingEFS » peut contenir les comptes d’ordinateur des ordinateurs sur lesquels EFS est déjà utilisé, tandis que « SG-ComputersNotUsingEFS » contiendra tous les autres ordinateurs sur lesquels EFS n’est pas actuellement utilisé.

Contrôle de l’utilisation d’EFS avec la stratégie de groupe
Une fois que vous savez qui utilise ou n’utilise pas EFS, l’étape suivante de votre déploiement de client est la désactivation de l’utilisation autonome d’EFS pour tous ceux qui ne l’utilisent pas actuellement. C’est une étape importante du processus de déploiement car il est plus facile d’activer et de configurer convenablement EFS dès la première fois, que de migrer des utilisateurs qui utilisent des certificats auto-signés. Effectuez uniquement cette étape après avoir déterminé les utilisateurs qui utilisent déjà EFS car, en désactivant EFS au travers de la stratégie de groupe, les utilisateurs ne pourront pas accéder aux fichiers actuellement chiffrés. Vous trouverez cette stratégie dans l’Éditeur d’objet de stratégie de groupe sous Compu-ter Configuration\Windows Settings\Security Settings\Public Key Policies\Encrypting File System.
Comme mentionné précédemment, cette valeur devrait uniquement être activée sur les ordinateurs sur lesquels EFS n’est pas actuellement utilisé, pour ne pas interrompre le travail de tout utilisateur utilisant déjà EFS. Ainsi, dans mon exemple, la liste de contrôle d’accès (ACL) sur l’Objet de stratégie de groupe (Group Policy Object, GPO) qui désactive EFS autorise uniquement le groupe « SG-ComputersNotUsingEFS » à appliquer la stratégie de groupe.

Chiffrer ou ne pas chiffrer
Une fois que vous avez déterminé les systèmes utilisant actuellement EFS et désactivé EFS sur tous les autres jusqu’à votre déploiement géré, l’étape suivante consiste à déterminer ce qui sera chiffré dans ce déploiement géré. En fonction de la manière dont vos systèmes clients sont gérés, la difficulté de ce processus peut s’échelonner de simple à très compliquée.
Pour choisir les fichiers à chiffrer, il est tout d’abord important de savoir si vos utilisateurs possèdent les autorisations d’administrateurs sur leurs systèmes. Si vos utilisateurs sont administrateurs locaux, vous êtes seulement capable de les informer et de les encourager à chiffrer les données sensibles, mais vous n’êtes pas vraiment en mesure de prendre le contrôle de façon gérée. C’est pour une raison simple : un administrateur local peut créer des fichiers et des répertoires à tout emplacement du système de fichiers. Ainsi, bien que vous puissiez chiffrer les emplacements standard, tels que Mes Documents, si l’utilisateur crée un nouveau répertoire à un autre emplacement et y enregistre des informations sensibles, il est difficile de s’assurer que ces données sont également protégées. Outre tous les autres avantages de sécurité procurés par le fait que les utilisateurs finaux ne sont pas administrateurs locaux, ceci permet également à EFS d’être beaucoup plus gérable et sécurisé.
L’information essentielle suivante à garder à l’esprit est le fait qu’EFS assure un chiffrage dépendant de l’utilisateur. En d’autres termes, tout ce qui est chiffré par un utilisateur donné peut uniquement être déchiffré par ce même utilisateur et aucun autre, y compris le compte SYSTEM (à l’exception, bien sûr, de l’Agent de récupération de données ou DRA). Ceci signifie que si un exécutable ou une DLL sont chiffrés avec une clé de l’utilisateur et qu’un autre utilisateur principal du système essaie d’y accéder, un message de refus d’accès lui est affiché. Ainsi, ne chiffrez en général pas les fichiers ou répertoires qui incluent du code exécutable auquel plusieurs utilisateurs principaux d’un système peuvent avoir besoin d’accéder. Windows empêchera le chiffrement des fichiers de %SystemRoot% et des fichiers portant l’attribut SYSTEM, mais il n’est pas rare que les fournisseurs de logiciels installent des fichiers binaires dans %ProgramFiles% pour les services qui peuvent être exécutés par le compte SYSTEM. C’est une approche courante pour les fournisseurs de portables, qui l’utilisent pour installer les logiciels de gestion de périphériques et de l’énergie qui s’exécutent en tant que services.
Ces deux faits à l’esprit, quels sont les recommandations pour les cibles de chiffrement EFS ? La réponse se résume à la manière dont les systèmes de vos utilisateurs sont habituellement configurés. Dans un environnement bien géré avec une image de système d’exploitation standardisée, vous pouvez probablement automatiser le processus de chiffrement pour les utilisateurs en fonction des emplacements de stockage de données de l’image déterminés au préalable. Par exemple, si les utilisateurs peuvent uniquement enregistrer des données dans %userprofile%\Mes Documents, vous pouvez avoir uniquement besoin de chiffrer ce répertoire. Remarque : soyez prudent en cas de chiffrement de Mes Documents, si vous utilisez la redirection de dossiers. Si Mes Documents est redirigé vers un serveur, le serveur devra être approuvé pour la délégation et avoir accès au profil de l’utilisateur. Dans ce cas, il est généralement plus facile de chiffrer uniquement la mémoire cache des fichiers hors connexion, ce que nous aborderons plus tard dans cette rubrique.
Dans un environnement moins géré (où les utilisateurs peuvent écrire dans plusieurs emplacements du système de fichiers), il peut être souhaitable d’automatiser le chiffrement de quelques emplacements de stockage courants et d’apprendre ensuite aux utilisateurs à chiffrer par eux-mêmes d’autres emplacements. Quel que soit votre environnement, effectuez toujours le chiffrement au niveau du dossier et non du fichier. En procédant ainsi, vous êtes sûr que tous les fichiers créés dans cet annuaire, y compris les fichiers temporaires, sont toujours chiffrés.

Emplacements de chiffrement recommandés
En règle générale, les emplacements que vous devez chiffrer sont normalement : %userprofile%\Mes documents, %userprofile%\Application Data\Microsoft\Outlook (en supposant que vous utilisez Microsoft Office Outlook® comme client de messagerie) et %userprofile%\Desktop. Le chiffrage de Mes documents protège l’emplacement par défaut des fichiers enregistrés dans Windows XP. La protection du répertoire Outlook permet de s’assurer que les messages électroniques sensibles mis en cache localement sont également chiffrés. C’est particulièrement important pour les utilisateurs d’Outlook 2003 utilisant le mode de mise en cache par défaut. Enfin, le Bureau est souvent utilisé comme répertoire temporaire dans lequel les utilisateurs peuvent placer des documents sur lesquels ils sont en train de travailler ou des présentations qu’ils utilisent fréquemment. Vous pouvez bien sûr avoir modifié l’emplacement par défaut de certains de ces répertoires dans votre organisation, ainsi vos choix de chiffrement EFS doivent refléter les emplacements normalement utilisés dans votre organisation.
Outre ces recommandations générales, vous devez également déterminer si vous disposez d’applications qui enregistrent des informations sensibles à d’autres emplacements. Par exemple, certaines applications enregistrent des données utilisateur dans %ProgramFiles%\AppName au lieu du profil de l’utilisateur. Il est important de déterminer si vous disposez de telles applications sur vos systèmes clients afin que vous puissiez protéger convenablement toutes les données qu’elles utilisent. Dans le cas de figure idéal, l’application peut être configurée pour enregistrer les modifications dans un autre chemin spécifique au profil de l’utilisateur (tel que Mes documents), dans lequel aucune modification additionnelle d’EFS n’est nécessaire. Dans le cas de figure le moins désirable, si l’application nécessite que des données soient enregistrées dans son répertoire Program Files, EFS peut être utilisé pour chiffrer uniquement un sous-répertoire spécifique de Program Files.
Enfin, soyez prudent si vous avez l’intention de chiffrer le répertoire temporaire (%TMP% et %TEMP%). De nombreux programmes d’installation d’applications utilisent ce répertoire pour l’expansion du contenu des packs d’installation et exécutent ensuite des opérations de déplacement des fichiers développés pour les placer dans le chemin correct de %ProgramFiles%. Puisqu’un fichier déplacé sur un même volume conserve ses attributs originaux, le fichier continuera à être chiffré après avoir été placé dans %ProgramFiles%. Si un utilisateur différent de celui qui exécute le programme d’installation tente ensuite d’utiliser ce fichier, l’accès à ce dernier lui sera refusé. Souvent, de tels problèmes ne se manifestent pas sous forme de messages d’erreur d’application indiquant la cause initiale. Pour cette raison, je recommande généralement de chiffrer %TMP% uniquement dans les environnements bien gérés dans lesquels les utilisateurs finaux n’installent pas d’applications par eux-mêmes.

Protection des fichiers hors connexion
Les fichiers hors connexion sont une fonctionnalité de Windows 2000 et des versions ultérieures qui permet aux utilisateurs de faire une copie locale de données enregistrées sur un serveur de fichiers. Les fichiers hors connexion permettent alors à l’utilisateur de travailler sur ces données en étant déconnecté du serveur et de synchroniser par la suite les modifications sur le serveur lorsqu’ils sont connectés. Les fichiers hors connexion ne se composent cependant pas d’un répertoire simple contenant des copies de fichiers du serveur. Il s’agit plutôt d’une base de données partagée par l’ensemble du système et exécutée dans le contexte du compte SYSTEM. Dans Windows XP, cette base de données peut être protégée avec EFS. Réfléchissez à ce que ceci signifie, en tenant compte du fait qu’il a été dit précédemment qu’EFS est fonction de l’utilisateur. Comment EFS, qui est fonction de chaque utilisateur, peut-il chiffrer une base de données utilisée par plusieurs entités de sécurité ?
Lorsqu’un utilisateur exécutant Windows XP choisit l’option de chiffrer les fichiers hors connexion dans l’Explorateur Windows, la routine de chiffrement utilisée est différente de celle utilisée pour les autres opérations de chiffrement pouvant être établies par cet utilisateur. Au lieu d’utiliser la paire de clés personnelles EFS de l’utilisateur pour le processus (ce qui empêcherait SYSTEM d’accéder aux fichiers), le compte SYSTEM génère lui-même une paire de clés à utiliser par EFS et utilise cette paire de clés pour le chiffrement de la mémoire cache côté client. Ceci a une implication critique au niveau de la sécurité, car si quelqu’un peut par la suite faire en sorte que du code s’exécute avec le compte SYSTEM, il peut déchiffrer les données de la mémoire cache. Si un ordinateur portable est volé, il est incroyablement facile pour un attaquant de réinitialiser le mot de passe d’administrateur et d’ouvrir ensuite une session en tant qu’administrateur. Une fois administrateur, il est tout aussi simple de forcer le code à s’exécuter en tant que SYSTEM et d’accéder ensuite à la mémoire cache. Notez que ce comportement a été modifié dans Windows Vista™. Windows Vista utilise maintenant la clé individuelle de l’utilisateur pour chiffrer les fichiers hors connexion spécifiques à l’utilisateur.
Pour être protégé contre ce type d’attaque, l’ordinateur portable peut être configuré pour enregistrer la clé de chiffrement dans la base de données du Gestionnaire de comptes de sécurité (SAM) hors connexion, sous la forme d’une entrée de mot de passe au démarrage (mode 2) ou d’une disquette insérée pendant le processus de démarrage (mode 3). Les deux approches peuvent être peu pratiques puisqu’elles nécessitent une interaction non automatisable avec l’ordinateur pendant le processus de démarrage créant des problèmes potentiels avec la gestion automatisée des systèmes. Cependant, si EFS doit être utilisé sur un ordinateur avec fichiers hors connexion, il est essentiel que l’une de ces options soit utilisée pour la sécurité des données de la mémoire cache. Je recommande généralement d’utiliser le mot de passe au moment du démarrage (voir la figure 1). En effet, un utilisateur dont l’ordinateur portable et sa mallette ont été volés est plus susceptible d’avoir déjà sa disquette dans l’ordinateur portable ou, si ce n’est pas le cas, très certainement dans la mallette de son portable.
Figure 1 Automatisation des opérations EFS
Figure 1 Automatisation des opérations EFS

Activation d’EFS
Une fois que vous avez déterminé ce qui doit être chiffré sur le client, l’étape suivante consiste à exécuter l’opération de chiffrement. Ce processus peut être mené à bien à l’aide d’un script d’ouverture de session ou un autre processus qui exécutera un script sur le client pour appeler cipher.exe afin d’exécuter l’opération de chiffrement. Si votre environnement comporte déjà des utilisateurs autonomes d’EFS, comme indiqué dans l’exemple précédent, je recommande d’effectuer au préalable leur migration.
Pour la migration de ces utilisateurs autonomes, la première étape consiste à fournir aux systèmes clients des certificats gérés, comme indiqué dans la version de février 2007 de cette rubrique (microsoft.com/technet/technetmag/issues/2007/02/SecurityWatch). Une fois que tous les systèmes ont été inscrits pour obtenir ces certificats gérés, le chiffrement doit être exécuté avec le commutateur /U pour mettre à jour tout fichier existant avec le nouveau chiffrement et les clés de l’agent de récupération. À ce stade, tous les systèmes du groupe SG-ComputersUsingEFS utiliseraient EFS en mode géré, y compris avec des clés émises de façon centralisée (et potentiellement archivées) et des agents de récupération gérés de façon centralisée.
Pour déployer EFS pour les utilisateurs n’utilisant pas actuellement EFS, vous devez tout d’abord supprimer la stratégie de groupe empêchant l’utilisation d’EFS. Une fois ceci effectué et les utilisateurs inscrits pour obtenir des certificats gérés, un script d’ouverture de session peut être exécuté pour chiffrer les chemins de clés décrits précédemment. Voici un exemple simple de script :
cipher /e /s /a "%userprofile%\My Documents"

cipher /e /s /a "%userprofile%\Application Data\Microsoft\Outlook"

cipher /e /s /a "%userprofile%\Desktop"
Après avoir activé EFS sur les répertoires désirés, vous devrez peut-être définir deux options supplémentaires pour augmenter la sécurité de votre déploiement d’EFS, toutes deux liées aux données échangées depuis la mémoire vers le disque. Notez que pour chacun de ces scénarios, la quantité de données qui pourrait potentiellement être récupérée par une partie malveillante est limitée à ce qui a été chargé en mémoire ou placé sur disque pendant l’utilisation légitime. En d’autres termes, si un utilisateur dispose sur un ordinateur de données sensibles protégées par EFS et qui n’ont pas été affichées (et par conséquent pas chargées dans la mémoire), ces données ne sont pas mises en danger par ces sources d’attaques.
Le fichier d’échange est utilisé par Windows comme mémoire virtuelle (souvent appelée espace d’échange dans les autres systèmes d’exploitation) et contient des morceaux bruts de données en mémoire écrites en texte clair sur le disque dur. Ceci peut mettre des données sensibles en danger sur un système protégé par EFS car, si un attaquant peut récupérer le fichier d’échange, il peut potentiellement utiliser des outils d’investigation pour extraire des données utilisables de ce fichier. Puisque le fichier d’échange ne peut quant à lui pas être chiffré dans Windows XP (notez toutefois qu’il peut l’être dans Windows Vista), la meilleure option consiste à forcer Windows à le vider lors de l’arrêt du système. Ceci peut être accompli à l’aide de la stratégie de groupe, comme illustré dans la figure 2.
Figure 2 Définition de la stratégie de groupe
Figure 2 Définition de la stratégie de groupe (Cliquer sur l'image pour la réduire)
Figure 2 Définition de la stratégie de groupe
Figure 2 Définition de la stratégie de groupe (Cliquer sur l'image pour l'agrandir)
L’inconvénient de ce paramètre est l’augmentation significative du temps nécessaire à l’arrêt d’un ordinateur, en particulier ceux disposant d’une grande quantité de mémoire. Par défaut, la taille du fichier d’échange est directement liée à la quantité de mémoire physique de l’ordinateur. En effet, pour vider le fichier d’échange, Windows doit écrire physiquement dans chaque page du disque avant l’arrêt.
Le fichier de mise en veille prolongée de Windows contient une vidange de la mémoire physique de l’ordinateur lorsque le mode de gestion de l’alimentation est défini pour permettre la mise en veille. Lorsque la mise en veille survient, Windows écrit le contenu complet de la mémoire physique sur le disque dans le fichier de mise en veille, permettant ainsi à l’ordinateur d’être restauré dans un état identique lorsque l’utilisateur est prêt à continuer à travailler. Comme le fichier d’échange, le fichier de mise en veille prolongée ne peut pas être chiffré dans Windows XP. Cependant, contrairement au fichier d’échange, le fichier de mise en veille prolongée ne peut pas être directement désactivé avec un objet de stratégie de groupe. Utilisez au lieu de cela un script pour appeler powercfg.exe avec le commutateur /HIBERNATE pour désactiver (ou réactiver) la mise en veille prolongée.
Après avoir terminé les tâches de chiffrement et de configuration initiales, vous devriez envisager de nettoyer l’espace libre des disques pendant le déploiement. Ce processus peut être très long et perturbateur, mais a des avantages nets en terme de sécurité pour les environnements haute sécurité. L’espace libre est la zone d’un disque qui ne contient pas de données actuellement actives sur le système mais qui, en raison du fonctionnement des disques durs, peut contenir des morceaux d’informations sensibles des fichiers précédemment utilisés. En d’autres termes, puisque l’opération de suppression d’un fichier n’écrase en fait pas tous les secteurs qu’un fichier occupe sur un disque (elle supprime seulement le pointeur de la table des fichiers), les données qui ont été supprimées peuvent continuer à exister sur le disque. Dans ce cas, les données peuvent être récupérables par des outils d’investigation qui peuvent lire cet espace libre et reconstruire des fichiers à partir de celui-ci. Pour effacer en toute sécurité ces données résiduelles, exécutez cipher avec le commutateur /W. Ceci force cipher à écraser systématiquement tous les secteurs marqués comme disponibles sur le disque. Tant que toutes les opérations de fichiers futures sur les données sensibles surviennent dans des répertoires protégés par EFS, il ne sera pas nécessaire d’exécuter régulièrement cette commande.

Amélioration de l’Explorateur Windows pour EFS
Par défaut, les options de chiffrement et de déchiffrage des fichiers et des annuaires sont situées au plus profond des menus de propriétés avancées de l’Explorateur Windows. Vous pouvez choisir d’améliorer les activités de l’utilisateur final avec EFS en plaçant « Chiffrer » et « Déchiffrer » sur le menu contextuel de l’Explorateur Windows (que vous activez d’un clic avec le bouton droit). En outre, l’Explorateur Windows peut être configuré pour afficher les fichiers et les répertoires protégés avec EFS à l’aide d’une couleur différente (vert) de celle des autres fichiers. Ceci peut aider les utilisateurs à savoir si un fichier ou un répertoire est chiffré sans avoir à accéder au menu des propriétés avancées. Enfin, vous pouvez vouloir ajouter une option pour définir les utilisateurs ayant accès à un fichier ou à un répertoire. Pour activer ces options, faites les
following changes in the registry via a script calling reg.exe:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced]

"EncryptionContextMenu"=dword:00000001

"ShowCompColor"=dword:00000001

[HKEY_CLASSES_ROOT\*\Shell\Encrypt To User...\Command]
@="rundll32 efsadu.dll,AddUserToObject %1"

EFS dans Windows Vista
Le système de fichiers EFS a bénéficié de plusieurs améliorations importantes dans Windows Vista qui le rendent plus facile à déployer et à gérer et améliorent également sa sécurité. L’amélioration principale est la prise en charge complète du stockage des clés EFS sur les cartes à puce. C’est une fonctionnalité particulièrement utile pour les organisations qui utilisent déjà l’ouverture de session par carte à puce, car cette même carte peut être utilisée pour stocker les clés EFS des utilisateurs. Cette prise en charge des cartes à puce s’étend également aux certificats d’agent de récupération, de sorte que les certificats DRA sensibles peuvent également être enregistrés sur les cartes.
Windows Vista prend également en charge le chiffrement d’éléments auparavant impossible ou difficilement mis en œuvre dans Windows XP. Windows Vista peut chiffrer le fichier d’échange, éliminant le besoin de définir l’option d’effacement du fichier d’échange de mémoire virtuelle. La conception complète des fichiers hors connexion a été retravaillée dans Windows Vista. Outre une stabilité et des performances bien meilleures (ainsi qu’une interface généralement plus conviviale), la mise en cache côté client est maintenant fonction de l’utilisateur, ce qui signifie qu’il est possible de chiffrer en toute sécurité la mémoire cache sans recourir à SYSKEY mode 2 ou 3. Ces deux améliorations éliminent les obstacles de déploiement majeurs des environnements actuels basés sur Windows XP.
Enfin, Windows Vista permet aux administrateurs de configurer le chiffrement du dossier Documents directement au travers de la stratégie de groupe, sans avoir à utiliser un script séparé. La figure 3 illustre les nouvelles propriétés EFS disponibles au travers des objets de la stratégie de groupe dans Windows Vista.
Figure 3 Propriétés EFS dans Windows Vista
Figure 3 Propriétés EFS dans Windows Vista (Cliquer sur l'image pour la réduire)
Figure 3 Propriétés EFS dans Windows Vista
Figure 3 Propriétés EFS dans Windows Vista (Cliquer sur l'image pour l'agrandir)

Conclusion
EFS fournit aux administrateurs Windows une option hautement sécurisée pour la protection des données mobiles. EFS est évolutif, gérable et fournit des mécanismes de récupération de données souples. Dans Windows Vista, EFS dispose d’améliorations supplémentaires pour une gestion et un déploiement plus faciles, ainsi que la prise en charge du stockage des clés à base de carte à puce. Pour les organisations qui souhaitent protéger leurs données, même lorsqu’un ordinateur a été physiquement perdu, EFS fournit une solution puissante qui est déjà intégrée à la plate-forme Windows existante.
Où trouver davantage
Pour plus d’informations sur les sujets abordés dans cette rubrique, voir les ressources suivantes :
  • La rubrique de février 2007 de Vigilance sécurité
  • Encrypting File System in Windows XP and Windows Server 2003 (en anglais)
  • How to Use the SysKey Utility to Secure the Windows Security Accounts Manager Database (en anglais)

John Morello a obtenu une mention très bien à la Louisiana State University et a occupé plusieurs postes chez Microsoft, qu’il a rejoint il y a six ans. En tant que consultant senior, il a conçu des solutions de sécurité pour des entreprises classées dans Fortune 100 ainsi que des clients civils et militaires du Gouvernement. Il est actuellement responsable de programme dans le groupe Windows Server qui se consacre aux technologies de sécurité et d’accès distant.


 Histoires de Bureau: Introduction &#224; PsTools
Histoires de Bureau
Introduction à PsTools
Wes Miller
Télécharger le code de cet article: MillerTheDesktopFiles2007_03.exe (150KB)

Jusqu’à l’année dernière, j’ai travaillé chez Winternals Software, dont Microsoft a fait l’acquisition en juillet 2006. Winternals vendait des logiciel commerciaux, mais les fondateurs de la société, Mark Russinovich et Bryce Cogswell, possédaient également une société distincte nommée Sysinternals, qui distribuait de nombreux outils sous forme de graticiels. Certains de ces logiciels gratuits ont
évolué pour devenir des composants du Pack de l’administrateur Winternals. Mark et Bryce ont également conclu des accords de licence avec des sociétés cherchant à utiliser ces outils hors du cadre typique des termes de licence des logiciels gratuits.
L’un de mes outils préférés de la bibliothèque de Sysinternals est PsTools, une panoplie d’outils que vous trouverez désormais à l’adresse microsoft.com/technet/sysinternals/utilities/pstools.mspx. Mark a baptisé ces outils d’après l’utilitaire de listing de processus d’UNIX, ps. Comme indiqué sur le site de téléchargement des outils, il existe des outils de ligne de commande Windows® intégrés qui peuvent exécuter des fonctions identiques à celles de ces outils. Cependant, outre d’importantes fonctionnalités uniques, la différence majeure réside dans le fait que la suite PsTools peut être utilisée localement ou à distance (à la condition que les systèmes distants soient correctement configurés, bien sûr). Qui plus est, la procédure permettant de les exécuter à distance est presque aussi simple que pour leur exécution locale.
La suite PsTools inclut plusieurs applications individuelles, répertoriées à la figure 1. Comme avec le reste des utilitaires de Sysinternals, il n’y a pas de programme d’installation, seulement des applications. Copiez-les simplement dans un dossier de votre chemin et démarrez !
Figure 1 Utilitaires PsTools (Close Figure 1)

Outil | Description
PsExec | Permet d’exécuter des processus dans tout contexte utilisateur.
PsFile | Affiche les fichiers ouverts sur un système distant.
PsGetSid | Affiche l’Identificateur de sécurité Windows (SID) d’un ordinateur ou d’un utilisateur.
PsInfo | Fournit des informations sur un système Windows.
PsKill | Arrête des processus en fonction de leur nom ou de leur identificateur de processus.
PsList | Fournit des informations détaillées sur les processus en cours d’exécution.
PsLoggedOn | Affiche tous les utilisateurs ayant ouvert une session localement, de même que tous les utilisateurs partageant des ressources à distance.
PsLogList | Vidange les enregistrements du journal d’événements Windows.
PsPasswd | Modifie les mots de passe des comptes utilisateur.
PsService | Affichage et contrôle des services Windows.
PsShutdown | Arrête, redémarre, met en veille ou en veille prolongée un ordinateur.
PsSuspend | Interrompt des processus en cours d’exécution.
Vous remarquerez peut-être que certaines de ces fonctionnalités (en particulier PsLogList) pourraient être obtenues à l’aide de Windows Management Instrumentation (WMI) et de l’écriture de scripts complexes. L’intérêt de la suite PsTools est toutefois que chaque utilitaire a été conçu pour accomplir une tâche spécifique, simplement et facilement.
Je vais vous détailler chaque outil et vous donner un exemple simple des raisons et des méthodes de son utilisation. Toutefois, j’offrirai tout d’abord une courte présentation du fonctionnement des outils et du genre de conditions requises devant être vérifiées pour que ceux-ci fonctionnent.

Comment fonctionnent les outils ?
Les outils fonctionnent généralement de la même manière. Sur le système hôte, lancez l’outil PsTool de votre choix. Bien que beaucoup puissent être exécutés localement, vous vous apercevrez que ces outils sont particulièrement utiles lorsqu’ils sont exécutés pour un ou plusieurs systèmes distants à la fois. PsExec est une exception particulière qui me vient à l’esprit, comme vous verrez dans mon exemple ci-dessous. À l’aide du paramètre de ligne de commande que vous fournissez, l’utilitaire se copie sur le partage administratif du système distant, qui est l’équivalent de %SystemRoot% (répertoire de Windows) sur le système distant.
Une fois copié dans le répertoire distant, l’application se lance et installe un service Windows. Ce service Windows exécute la tâche que vous avez demandée, en utilisant les informations d’authentification que vous avez fournies au moment du lancement. Si une interface utilisateur d’utilisateur final est requise par un outil spécifique sur le système client, ce service lance alors un fichier binaire supplémentaire dans le contexte de l’utilisateur. Souvenez-vous que les services ne peuvent pas démarrer directement d’interfaces utilisateur interactives. Le service communique toutes les informations nécessaires en retour à la console qui l’a lancé. Pour terminer, le service se désinstalle.
Comme vous pouvez le voir, les outils sont puissants et autonomes. Bien qu’ils impliquent plusieurs processus et fichiers binaires, en tant qu’utilisateur vous n’aurez pas à vous soucier de cela : vous aurez simplement à exécuter l’outil de votre choix et il fonctionnera.
Afin d’utiliser les outils, la configuration suivante est requise : Windows NT®, Windows 2000, Windows XP ou Windows Server® 2003 (les versions x86 et x64 de Windows sont prises en charge, mais pas les versions Itanium) ; partage réseau administratif par défaut activé sur le système distant sur lequel vous exécutez les outils (admin$) ; ports du Partage de fichiers et d’imprimantes ouverts sur le système distant (que vous utilisiez le Pare-feu Windows, le Pare-feu de connexion Internet ou tout autre pare-feu).

PsExec
PsExec est mon préféré parmi ces outils, et probablement pas pour la raison à laquelle vous pensez. Depuis près de deux ans, j’ouvre mes sessions en tant que non-administrateur sur les systèmes que j’exécute comme utilisateur et non en tant qu’administrateur. Je dispose d’un script nommé run.vbs que j’utilise pour exécuter les applications en tant qu’administrateur local (elles pourraient aussi bien être exécutées en tant qu’utilisateur quelconque). La figure 2 détaille le contenu du script (qui est également disponible sur le site de TechNet Magazine à l’adresse technetmagazine.com/code07.aspx). Le script suppose que les outils PsTools sont situés dans le chemin de la variable système Path.
Figure 2 Run.vbs (Close Figure 2)
SET WshShell = WScript.CreateObject("WScript.Shell")
SET WshSysEnv = WshShell.Environment("SYSTEM")
SET FSO = CreateObject("Scripting.FileSystemObject")
IF WScript.Arguments.Count <> 0 Then
    FOR EACH arg IN WScript.Arguments
        iArgCount = iArgCount + 1
        strCmdArg = (arg)
        strCmdArray = Split(strCmdArg, " ", 2, 1)
        IF iArgCount = 1 THEN
        strExe = strCmdArray(0)
        ELSEIF iArgCount = 2 THEN
        strRun = strCmdArray(0)
        ELSE
        strParams = strParams&" "&strCmdArray(0)
        END IF
    NEXT
END IF
'/t:0A && title ***** Admin *****
        strExt = LCase(Right(strExe, 3))

IF strExt <> "exe" AND strExt <> "bat" AND strExt <> "cmd" THEN
WshShell.Run "psexec.exe -d -i -e -u COMPUTERNAME\USER -p PASSWORD  cmd /c start "&strExe&"
    "&strRun&" "&strParams, 0, FALSE
ELSE
WshShell.Run "psexec.exe -d -i -e -u COMPUTERNAME\USER -p PASSWORD "&strExe&" "&strRun&"
    "&strParams, 0, FALSE
END IF

    SET WshShell = NOTHING
    SET WshSysEnv = NOTHING
    SET FSO = NOTHING
Ce script simple est un exemple d’utilisation de PsExec avec la fonctionnalité que Mark a ajoutée lorsque nous travaillions sur notre produit Protection Manager chez Winternals : la possibilité pour un utilisateur restreint de fournir des informations d’authentification aux autorisations plus grandes pour lancer PsExec localement. L’utilisation la plus courante de PsExec, bien sûr, est son exécution à distance pour, par exemple, exécuter un utilitaire qui ne fournit pas sa propre infrastructure d’accès distant, d’écriture de script ou d’automatisation. Les fonctionnalités essentielles de PsExec comprennent la possibilité de copier un fichier binaire vers les systèmes distants sur lesquels il doit être exécuté, ainsi que la possibilité de choisir l’affinité avec certains processeurs. Une autre fonctionnalité pratique de PsExec consiste à pouvoir l’exécuter simultanément avec un script sur plusieurs ordinateurs en fournissant un fichier de script.
Voici l’utilisation simplifiée de PsExec :
PsExec \\computer -u username -p password command
Vous pouvez étendre cette utilisation à l’aide des commutateurs répertoriés à la figure 3.
Figure 3 Commutateurs de PsExec (Close Figure 3)

Commutateur | Description
-a | Spécifie l’affinité avec certains processeurs.
-c | Indique si l’application doit être copiée sur le système distant.
-d | Spécifie de ne pas attendre que le processus se termine avant de quitter (pas d’attente de message de réussite ou d’échec).
-e | Effectue le chargement à l’aide du profil de compte spécifié.
-f | Copie l’application, même si elle existe sur le système distant. Vérifie que vous exécutez la version la plus récente (ou une version spécifique).
-i | Exécute l’application de manière interactive sur le système distant (requis si vous voulez qu’un utilisateur final voie une interface utilisateur depuis l’application).
-l | Exécute l’application en tant qu’utilisateur restreint. Supprime le jeton du groupe Administrateurs et réduit les privilèges de processus au niveau auquel ils correspondraient pour un membre du groupe Utilisateurs. Pratique pour exécuter des applications à haut risque orientées Internet avec des privilèges minimaux.
-n | Spécifie le délai d’attente avant l’échec de la connexion aux ordinateurs distants.
-priority | Exécute le processus à la priorité spécifiée. Spécifie en fait comment Windows doit définir la priorité de processus pour une tâche donnée (-low, -belownormal, -abovenormal, -high ou -realtime).
-s | Exécute le processus en utilisant le compte System (pratique pour exécuter Regedit pour l’accès à des clés du Registre avec privilèges).
-v | Copie l’application, uniquement si celle qui est copiée est plus récente.
-x | Affiche l’interface utilisateur du bureau sécurisé Winlogon (fonctionne uniquement sur le système local).
@file | Exécute la commande pour tous les ordinateurs spécifiés dans le fichier texte.

PsFile
PsFile est un outil plus limité que PsExec. Il est utilisé pour identifier, sur le système distant, quels sont les fichiers qui sont ouverts et qui les a ouverts. Ceci peut être utile si vous voulez effectuer un suivi des fichiers qui sont ouverts avant de redémarrer un serveur. Si vous devez déterminer quel utilisateur a verrouillé le fichier et empêche ainsi peut-être sa modification ou sa suppression, vous pouvez l’avertir manuellement ou fermer ce fichier à l’aide de PsFile. Utilisez PsFile de la manière suivante :
PsFile \\computer -u username -p password
Ceci renvoie simplement une liste des handles des fichiers ouverts sur le système distant. Au delà de l’utilisation standard, vous pouvez également ajouter un paramètre Id à l’instruction pour spécifier le nom du fichier que vous voulez fermer ou à propos duquel vous recherchez des informations. Vous pouvez également inclure le commutateur -c, qui ferme le fichier que vous avez identifié avec le paramètre Id.

PsGetSid
PsGetSid est également un outil très spécifique. Il vous donnera l’Identificateur de Sécurité (SID) d’un ordinateur, d’un utilisateur ou d’un groupe. Ceci peut être utile si vous voulez vous assurer que les systèmes de votre domaine n’ont pas de doublons parmi leurs SID ou pour vérifier simplement les SID de tous les utilisateurs ou groupes d’un système. Utilisez PsGetSid comme ceci :
PsGetSid \\computer -u username -p password account
Notez que account peut faire référence à un utilisateur, un ordinateur ou un groupe. Bien que la syntaxe de PSGetSid soit simple, deux paramètres supplémentaires sont également disponibles. Le paramètre SID correspond au compte (groupe ou ordinateur) auquel un SID spécifique a été attribué et @file exécute la commande sur tous les ordinateurs répertoriés dans le fichier texte spécifié.

PsInfo
PsInfo est utilisé pour fournir des informations système détaillées. Cet utilitaire revêt bien entendu un intérêt primordial lorsqu’il est utilisé dans un script pour plusieurs systèmes distants, le résultat étant redirigé vers un fichier (tel qu’un fichier CSV pouvant être ouvert avec Excel® ou un programme de base de données). Notez que cet utilitaire fonctionne selon un concept important qui est différent de la plupart des autres outils : Si vous ne fournissez pas de nom d’ordinateur, PsInfo tentera par défaut d’interroger tous les ordinateurs du domaine. Utilisez PsInfo comme ceci :
PsInfo  \\computer -u username -p password
Bien que la syntaxe soit simple, des commutateurs et des paramètres supplémentaires sont également disponibles, comme indiqué à la figure 4.
Figure 4 Commutateurs de PsInfo (Close Figure 4)

Commutateur | Description
-h | Affiche toutes les mises à jour de Windows.
-s | Affiche toutes les applications installées sur le système.
-d | Affiche les informations concernant le disque/volume du système.
-c | Redirige les résultats dans un fichier au format CSV.
-t | Spécifie un séparateur de fichier CSV différent de la valeur par défaut (\t).
Filter | Affiche uniquement les données qui correspondent à un filtre donné.
@file | Exécute la commande pour tous les ordinateurs répertoriés dans le fichier texte spécifié.

PsKill
PsKill est un utilitaire incontournable pour mettre fin à des processus sur un système local ou distant. Son utilisation est très simple et il permet d’arrêter rapidement un processus ainsi que tous ses processus enfants. L’utilisation de PsKill est très similaire à celle des autres outils que j’ai abordés.
PsKill -t \\computer -u username -p password process id | process name
Notez que vous pouvez spécifier l’ID ou le nom de processus du processus que vous voulez arrêter.

PsList
Je n’utilise pas beaucoup PsList car je lui préfère Process Explorer (voir microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx pour plus d’informations). Mais puisqu’il n’existe pas de version utilisable à distance de Process Explorer, PsList offre une alternative raisonnable pour certaines fonctionnalités clés offertes par Process Explorer. PsList est en fait une liste utilisable à distance des processus s’exécutant sur un système distant.
L’utilisation de PsList est assez simple :
PsList \\computer -u username -p password account
Comme avec les autres outils, le paramètre de compte peut correspondre à un utilisateur, un ordinateur ou un groupe. Les paramètres supplémentaires sont indiqués à la figure 5.
Figure 5 Commutateurs de PsList (Close Figure 5)

Commutateur | Description
-t | Affiche les informations de niveau thread.
-m | Fournit des informations détaillées sur la mémoire pour chaque processus.
-x | Affiche les informations concernant le processus, la mémoire et le thread.
-t | Affiche les informations sous la forme d’une arborescence de processus (telle que l’arborescence de Process Explorer).
-s [n] | S’exécute en mode de Gestionnaire des tâches pendant le nombre de secondes spécifié. Ceci permet un affichage en quasi-temps réel des informations concernant les processus distants.
-r [n] | Spécifie la fréquence d’actualisation (en secondes) lors de l’exécution en mode Gestionnaire des tâches.
name | Affiche des informations sur les processus qui commencent par le nom spécifié.
-e | Recherche une correspondance exacte du nom de processus.
pid | Affiche des informations sur un processus spécifique.
PsList est puissant, tout en étant facile à utiliser et, sans recourir au Bureau à distance, vous permet de voir les processus distants avec un niveau de détail poussé. Grâce à ces informations, vous pouvez alors passer à PsKill ou à PsSuspend si, par exemple, un processus nécessite une intervention.

PsLoggedOn
Le principe sur lequel s’appuie PsLoggedOn est évident. L’utilitaire affiche qui a ouvert une session sur le système. Il peut s’agir d’ouvertures de session locales (interactives) ou sur des partages réseau. Comme avec PsFile, cette possibilité peut être utile pour déterminer qui utilise un serveur dont vous devez effectuer la maintenance. Son utilisation est très simple :
PsLoggedOn \\computer
PsLoggedOn a seulement deux paramètres facultatifs : -l affiche uniquement les ouvertures de session locales (pas les ouvertures de session réseau) et -x exclut l’heure de connexion.
Bien que simple, PsLoggedOn vous permet de facilement consulter des informations pour lesquelles vous devriez généralement fouiller à plusieurs emplacements de Windows.

PsLogList
PsLogList est généralement parmi les utilitaires les plus utiles. Il s’agit d’un outil de vidange des journaux d’événements Windows dans un format de fichier texte qui peut être ensuite utilisé par les analyseurs de journaux, les bases de données ou tout autre programme de votre choix. Son avantage principal est qu’il convertit les entrées de journaux d’événements de leur format binaire vers un autre format pouvant être facilement transformé ou peut être automatisé. (Bien entendu, dans Windows Vista™, les journaux d’événements sont disponibles en mode natif au format XML, mais il s’agit d’un autre sujet, que nous aborderons une autre fois.)
Utilisez PsLogList comme ceci :
PsLogList \\computer -u username -p password
Des commutateurs et des paramètres supplémentaires sont également disponibles, comme indiqué à la figure 6.
Figure 6 Commutateurs de PsLogList (Close Figure 6)

Commutateur | Description
-a | Vidange uniquement les événements survenus après la date spécifiée.
-b | Vidange uniquement les événements survenus avant la date spécifiée.
-c | Vide le journal des événements de manière permanente après la vidange de résultat voulu.
-d | Affiche uniquement les informations correspondant au nombre de jours spécifié.
-e | Exclut les événements avec l’ID d’événement spécifié (vous pouvez en spécifier jusqu’à 10).
-f | Filtre les types d’événements (avertissements, erreurs, etc.).
-g | Exporte le journal d’événements sous forme de fichier EVT (nécessite le commutateur -c).
-h | Affiche uniquement les informations correspondant au nombre d’heures spécifié.
-l | Effectue la vidange depuis le fichier EVT spécifié.
-m | Affiche uniquement les informations correspondant au nombre de minutes spécifié.
-n | Affiche uniquement le nombre spécifié d’événements les plus récents.
-o | Affiche uniquement les événements d’une source donnée (-o SRService pour le Service de restauration du système de Windows, par exemple).
-q | Exclut les événements d’une source donnée (le contraire de -o).
-r | Inverse l’ordre de vidange des événements du journal du plus ancien au plus récent.
-s | Répertorie les enregistrements de chaque ligne dans des champs délimités.
-t | Spécifie un séparateur différent de la virgule pour la sortie avec -s.
-w | Attend l’arrivée de nouveaux événements et effectue une vidange en temps réel. S’applique uniquement au système local.
-x | Vidange les données étendues des journaux d’événements.
eventlog | Spécifie le journal d’événements à vidanger. Par défaut, il s’agit de System.
@file | Exécute la commande pour tous les ordinateurs spécifiés dans le fichier texte.
Les journaux des événements de Windows peuvent constituer un outil de diagnostic puissant, mais il peut être compliqué de mettre les données sous une forme manipulable ou consolidable. PsLogList effectue ce tour de passe.

PsPasswd
PsPasswd est un utilitaire simple et cependant puissant, conçu avec des possibilités similaires à celles de Net.exe, mais avec l’utilisation à distance et l’automatisation à l’esprit.
PsPasswd  \\computer -u username -p password Username Newpassword
Vous pouvez spécifier un ordinateur, aucun ordinateur (le système local) ou, si vous spécifiez l’ordinateur sous la forme \\*, l’utilitaire s’exécutera pour tous les ordinateurs du domaine. PsPasswd dispose d’un seul paramètre supplémentaire : @file exécute la commande pour tous les ordinateurs spécifiés dans le fichier texte. Ici encore, vous disposez d’un utilitaire très simple, qui offre d’énormes capacités multi-systèmes.

PsService
PsService vous permet d’afficher et de modifier les informations fournies par le Gestionnaire de contrôle des services (SCM) sur un ou plusieurs systèmes de votre réseau. Vous pouvez même rechercher un nom de service particulier sur les systèmes de votre réseau.
PsService \\computer -u username -p password command options
Lorsque vous exécutez PsService, command correspond à l’une des commandes répertoriées à la figure 7 et options correspond à un attribut à appliquer à la commande donnée. Si aucun commutateur supplémentaire de commande n’est fourni, PsService fournira une vidange complète des informations de SCM.
Figure 7 Commandes de PsService (Close Figure 7)

Commande | Description
query | Interroge un service donné.
config | Interroge les informations de configuration d’un service donné.
setconfig | Définit les informations de configuration d’un service donné.
start | Démarre un service.
stop | Arrête un service.
restart | Redémarre (arrêt et démarre) un service.
pause | Interrompt un service.
cont | Reprend un service suspendu.
depend | Affiche les services dépendant d’un service donné.
find | Recherche une instance donnée du service sur votre réseau.
security | Fournit les informations de sécurité d’un service donné.
Vous pouvez donc considérer PsService comme une version puissante, en ligne de commande et pouvant être utilisée à distance de Services.msc, vous permettant toutefois d’examiner les services sur le réseau (comme par exemple ceux qui peuvent être dangereux) et de définir des informations de configuration.

PsShutdown
PsShutdown est aussi l’un de mes préférés. Même si certains diront que Microsoft fournit un outil effectuant cette tâche (shutdown.exe), ceux-ci ne sont vraiment pas identiques. La différence essentielle réside dans la puissance de PsShutdown : sa capacité de pouvoir arrêter et redémarrer un système distant. En outre, il a la possibilité de mettre un système en mode veille ou veille prolongée (et non uniquement de l’arrêter ou de le redémarrer), de verrouiller un système et de redémarrer un système après avoir affiché un message à l’utilisateur pendant une durée donnée.
PsShutdown \\computer -u username -p password
Des paramètres supplémentaires sont également disponibles pour l’utilisation de PsShutdown, comme indiqué à la figure 8.
Figure 8 Commutateurs de PsShutdown (Close Figure 8)

Commutateur | Description
-a | Abandonne un arrêt en cours initié par PsShutdown.
-c | Permet à un utilisateur interactif d’abandonner l’arrêt.
-d | Interrompt l’ordinateur (mode veille).
-e | Codes de raison de l’arrêt. Je vous recommande de consulter le site Web de Microsoft pour obtenir de l’aide sur ceux-ci, car ils peuvent s’avérer difficiles à utiliser avec PsShutdown comme avec l’outil intégré shutdown.exe. Voir msdn2.microsoft.com/en-us/library/aa376885.aspx pour plus d’informations.
-f | Force toutes les applications en cours d’exécution à se terminer.
-h | Place l’ordinateur en mode veille prolongée.
-k | Éteint l’ordinateur (redémarre si la mise hors tension n’est pas prise en charge).
-l | Verrouille l’ordinateur.
-m | Spécifie le message à afficher aux utilisateurs interactifs.
-n | Spécifie le délai d’attente avant l’échec de la connexion aux ordinateurs distants.
-o | Ferme la session de l’utilisateur de la console.
-r | Redémarre l’ordinateur.
-s | Arrête, mais n’éteint pas.
-t | Délai avant l’exécution de la commande d’arrêt ou de mise hors tension.
-v | Affiche le message aux utilisateurs jusqu’ à l’arrêt.
@file | Exécute la commande pour tous les ordinateurs spécifiés dans le fichier texte.
Vous pouvez constater que PsShutdown est un utilitaire puissant et extrêmement configurable de contrôle de l’alimentation d’un système, toujours relativement facile à utiliser.

PsSuspend
PsSuspend est un utilitaire pratique si vous voulez contrôler temporairement un processus rebelle ou simplement désactiver temporairement un processus utilisant intensivement le processeur sans perte de données ou de contexte d’application.
PsSuspend \\computer -u username -p password process ID
Vous pouvez obtenir l’identificateur du processus à l’aide de PsList. Une fois que vous avez interrompu un processus, vous pouvez utiliser le commutateur -r pour le reprendre. Notez que le concept d’interruption et de reprise d’un processus est également disponible avec Process Explorer, bien qu’il ne soit disponible que localement. PsSuspend peut évidemment interrompre et reprendre des processus à distance comme localement, ce qui lui confère un avantage par rapport à l’implémentation intégrée de Process Explorer.

Conclusion
Je trouve que la suite PsTools est un ensemble d’outils incontournable. Avec les autres utilitaires de Sysinternals (à savoir Regmon, Filemon, Process Explorer et maintenant Process Monitor), les PsTools sont les premiers programmes que je place sur mon disque après avoir réinstallé Windows sur mes systèmes. J’espère que cette rubrique vous a permis de vous familiariser avec les PsTools, si vous ne les connaissiez pas déjà et, si c’était le cas, j’espère que vous avez glané quelques connaissances supplémentaires sur ces outils. Un grand merci à Mark Russinovich, bien sûr, pour avoir fourni ces outils gratuitement pendant toutes ces années et pour m’avoir aidé à rédiger le contenu de cette rubrique.

Wes Miller est responsable du développement chez Pluck (www.pluck.com) à Austin, au Texas. Auparavant, Wes a travaillé chez Winternals Software à Austin et chez Microsoft en tant que responsable de programme et responsable de produit pour Windows. Vous pouvez contacter Wes à l’adresse suivante : technet@getwired.com.


 Microsoft.com au jour le jour: D&#233;marrage de la mise en miroir de base de donn&#233;es
Microsoft.com au jour le jour
Démarrage de la mise en miroir de base de données
Saleem Hakani

Si votre base de données se retrouve hors ligne, vous êtes probablement dans le pétrin, non ? Cependant, si vous utilisez SQL Server 2005 avec SP1, la fonctionnalité de mise en miroir de la base de données peut empêcher le désastre. Cette nouvelle technologie de haute disponibilité vous permet de maintenir une veille de votre base de données pour utilisation lorsque votre serveur de base de données de production devient
indisponible, quelle qu’en soit la raison. La fonctionnalité de mise en miroir de la base de données transfère les journaux de transactions d’une base de données du serveur primaire au serveur secondaire, qui sert de veille. Avec la mise en miroir de base de données, les modifications de données sont enregistrées dans le journal des transactions avant que les modifications ne soient apportées aux véritables pages de données, comme les mises à jour SQL Server™ fonctionnent toujours. Les journaux sont tout d’abord placés dans le tampon de journal de la base de données principale en mémoire, puis copiés sur disque. Ces journaux des transactions sont copiés sur la base de données du serveur miroir et rejoués dessus. Ceci provoque la duplication des modifications de la base de données principale sur la base de données miroir. Attention, seule la base de données principale est accessible aux connexions client. Lorsque la base de données principale reçoit des modifications demandées par les clients, le serveur principal envoie ces modifications actives au serveur miroir ; le miroir ne prend pas ces décisions. Lorsque la mise en mémoire de base de données est activée et que la base de données principale échoue, la base de données mise en miroir devient disponible.

Mécanique de la mise en mémoire de base de données
La mise en miroir de base de données fonctionne avec tout le matériel standard prenant en charge SQL Server 2005 et garantit qu’il n’y aura pas de perte de données en cas de défaillance de la base de données. La base de données miroir sera systématiquement mise à jour avec la transaction en cours de traitement sur le serveur de base de données primaire. La figure 1 illustre le flux de données.
Si votre serveur principal tombe en panne, vous pouvez être sûr que le serveur miroir dispose d’une copie exacte de la base de données principale au moment de la dernière transaction validée. Ainsi, le miroir est toujours prêt à prendre le rôle du serveur principal.
Figure 1 Réplication des données sur le miroir
Figure 1 Réplication des données sur le miroir (Cliquer sur l'image pour la réduire)
Figure 1 Réplication des données sur le miroir
Figure 1 Réplication des données sur le miroir (Cliquer sur l'image pour l'agrandir)
Dans la topologie de mise en mémoire de base de données, vous aurez besoin d’un troisième serveur appelé témoin si vous voulez activer le basculement automatique du serveur principal au serveur miroir et inversement. N’importe quel ordinateur prenant en charge SQL Server 2005 peut être serveur témoin.

Modes d’opération
La topologie de mise en miroir de base de données dépendra de la sécurité des transactions et des modes d’opération que vous avez choisis. Les modes d’opération pris en charge par la mise en miroir de base de données incluent la sécurité élevée (avec ou sans basculement automatique) et les performances élevées.
Sécurité élevée (avec basculement automatique) Ce mode prend en charge une disponibilité de base de données maximale avec transfert de données synchrone et basculement automatique vers la base de données miroir. Ce mode d’opération est idéal lorsque vous avez des communications rapides et très fiables entre le serveur principal et le serveur miroir, et que vous avez besoin d’un basculement automatique pour une seule base de données. Dans ce schéma, la base de données principale attend de valider une transaction jusqu’à ce qu’elle reçoive un message du serveur miroir indiquant que celui-ci a copié le journal des transactions sur le disque.
Sécurité élevée (sans basculement automatique) Ce mode prend en charge une disponibilité de base de données maximale avec transfert de données synchrone mais sans basculement automatique vers la base de données miroir. Dans ce mode, si l’instance de serveur miroir devient indisponible, l’instance de serveur principale continue à fonctionner mais ne pourra pas mettre en miroir les données. Si le serveur principal tombe en panne, la mise en miroir de base de données est interrompue, mais vous pouvez forcer manuellement le service à basculer.
Performances élevées Dans ce mode d’opération, le transfert de données est asynchrone. Le serveur principal n’attend pas d’indication du miroir comme dans les deux modes ci-dessus. Le serveur miroir fait de son mieux pour suivre le principal, mais il n’est pas garanti que toutes les transactions les plus récentes du serveur principal seront systématiquement copiées dans le journal des transactions du serveur miroir. Si le serveur principal tombe en panne, la mise en miroir de base de données est interrompue, mais vous pouvez forcer manuellement le service à basculer.

Poser les bases
La configuration d’une mise en miroir de base de données est un processus simple si vous établissez des bases solides en vous servant des meilleures pratiques :
Server Edition Revérifiez que les serveurs principal et miroir s’exécutent sur la même édition de SQL Server 2005 ; vous pouvez utiliser l’édition que vous souhaitez (Standard ou Enterprise).
Disponibilité du serveur témoin Si vous avez l’intention d’utiliser une sécurité élevée avec basculement automatique, assurez-vous que le serveur témoin est disponible et que SQL Server 2005 (n’importe quelle édition) est installé. Le serveur témoin peut s’exécuter sur n’importe quel système informatique fiable prenant en charge SQL Server 2005.
Image miroir Vérifiez que l’instance de serveur miroir et l’instance de serveur principale ont les mêmes tâches, logins, packages SQL Server Integration Service (SSIS), partitions de disque, emplacements de fichiers et configurations de serveur. Si vous configurez le serveur miroir exactement comme le serveur principal, le serveur miroir pourra fonctionner de la même façon que le principal.
Récupération complète Il est important que toutes les bases de données participant à la mise en miroir de base de données soient configurées sur le modèle de récupération FULL (complète).
Master et TempDB Vérifiez que toutes les instances de serveurs dans une topologie de mise en miroir utilisent le même classement Master et TempDB et la même page de code. Si ce n’est pas le cas, cela pourrait provoquer des problèmes lors de la configuration de mise en miroir de la base de données.
Sauvegarde Si la base de données à mettre en miroir a une taille importante, vous devez tout d’abord réaliser une sauvegarde complète de la base de données, puis la restaurer sur l’instance de serveur miroir à l’aide de l’option NORECOVERY.
Planification à l’avance Déterminez tous les noms de serveurs, numéros de ports, comptes de sécurité et emplacements où pourraient se trouver les bases de données et documentez-les. Voir la barre latérale Meilleures pratiques pour la mise en miroir de base de données qui contient une liste de vérification.
Une fois que vous vous êtes occupé des bases, vous êtes prêt à vous lancer dans la configuration de la mise en miroir de base de données dans votre environnement.
Meilleures pratiques pour la mise en miroir de base de données
  1. Utilisez des serveurs partenaires ayant une UC, une mémoire, une capacité de stockage et une capacité réseau identiques.
  2. Assurez-vous que les deux partenaires ont les mêmes éditions de SQL Server et du système d’exploitation, des service packs et des mises à jour.
  3. Installez SQL Server sur un répertoire et une structure de disque identiques sur les deux instances.
  4. Si les performances sont basses, vous pouvez envisager d’utiliser une carte d’interface dédiée pour diviser la charge.
  5. Comme pour les partenaires, vérifiez que les deux instances sont identiques en termes d’UC, de mémoire, de stockage et de capacité réseau. Si vous faites en sorte que les deux serveurs aient la même structure de répertoires, le même schéma de division des disques et la même configuration SQL Server, vous n’aurez pas à les modifier pendant ou après le basculement vers le partenaire miroir.
  6. Vérifiez que toutes vos applications peuvent se connecter et exécuter les actions nécessaires, et que tous les logins SQL Server actifs (et leurs autorisations) sur l’instance de serveur principale sont également présent sur l’instance de serveur miroir. Vous pouvez utiliser la tâche Transfer Logins de SQL Server 2005 Integration Services pour accomplir cela.
  7. Copiez les tâches d’agents SQL Server, les alertes, les packages SSIS, les bases de données d’assistance, les définitions de serveurs liés, les dispositifs de sauvegarde, les plans de maintenance, les profils de messagerie etc. du serveur principal au serveur miroir.
  8. Établissez une procédure de façon à ce que chaque fois que vous apportez des modifications au serveur principal (matériel, logiciel, paramètres SQL Server ou n’importe quel objet de base de données), ces modifications seront automatiquement répétées ou copiées et transférées sur l’instance de serveur miroir.
  9. Exécutez plusieurs basculements tests avant de commencer.

Configuration
Configurons la mise en miroir de base de données en utilisant le mode d’opération à sécurité élevée avec basculement automatique. (Comme indiqué, cela signifie qu’une instance de serveur témoin est nécessaire). Pour mon exemple j’utiliserai les noms de serveur et de base de données affichés à la figure 2, qui spécifie également le rôle de chaque serveur.
N’oubliez pas qu’étant donné que la configuration peut influer sur les performances lorsque le journal des transactions est copié du serveur principal au serveur miroir, il vaut sans doute mieux réaliser la configuration initiale en période creuse.
La configuration du miroir comporte trois étapes : la création de points finaux sur les serveurs qui participent, la sauvegarde et la restauration de votre base de données principale et l’activation de sessions miroir sur tous les serveurs participants.
Avant d’établir une session de mise en miroir de base de données, vous devez configurer le mécanisme de communication entre tous les serveurs participant à la mise en miroir de base de données. Pour ce faire, créez des points finaux sur tous les serveurs en exécutant cette instruction à la fois sur le serveur A et le serveur B :
Create Endpoint Mirroring_Endpoint
State= Started as TCP (Listener_Port=5001)
For Database_Mirroring (Role=Partner);
Pour le serveur C (qui servira de témoin), modifiez (Role=Partner) en (Role=Witness) et exécutez l’instruction. Ceci contrôle le port TCP sur lequel écoute chaque instance.
Pour l’étape suivante, exécutez une sauvegarde complète de la base de données, suivie d’une sauvegarde de la base de données DBM_Demo sur le serveur principal puis restaurez-la sur l’instance de serveur miroir à l’aide de l’option NORECOVERY. (Le fait d’utiliser NORECOVERY permet de garantir que la base de données miroir sera dans l’état de restauration afin que les journaux des transactions puissent être appliqués).
Voici l’instruction T-SQL permettant de réaliser une sauvegarde de base de données complète de DBM_Demo à partir du serveur A (instance de serveur principale) :
Backup Database DBM_Demo to DISK='E:\MSSQL\Bak\DBM_Demo_FULL.bak';
Si des modifications sont apportées à la base de données une fois que vous avez réalisé la sauvegarde complète, vous devrez peut-être exécuter une sauvegarde de journaux de la base de données ; sinon, cela ne sera peut-être pas nécessaire.
Si nécessaire, vous pouvez utiliser l’instruction T-SQL suivante pour exécuter une sauvegarde de journaux de la base de données DBM_Demo à partir du serveur A :
Backup Log DBM_Demo to Disk='E:\MSSQL\Bak\DBM_Demo_Log.bak';
Une fois toutes les sauvegardes exécutées, déplacez les fichiers de sauvegarde sur le serveur B ou un emplacement partagé de façon à ce que vous puissiez restaurer ces sauvegardes sur le serveur B. Une fois que c’est fait, restaurez les sauvegardes de journaux de transactions réalisées depuis la dernière sauvegarde de base de données complète à partir du serveur A, le cas échéant.
Vous pouvez utiliser l’instruction T-SQL suivante pour restaurer les sauvegardes complète et de journaux sur le serveur B à l’aide de l’option NORECOVERY :
--Restore full database backup on the mirror --server instance
Restore Database DBM_Demo from Disk='E:\MSSQL\Bak\DBM_Demo_FULL.bak' with NORECOVERY;
Enfin, utilisez l’instruction T-SQL suivante pour restaurer la sauvegarde de journaux sur le serveur miroir en utilisant l’option NORECOVERY :
Restore Log DBM_Demo from Disk='E:\MSSQL\Bak\DBM_Demo_Log.bak' with NORECOVERY;
Une fois que vous avez fini de restaurer toutes les sauvegardes, vous êtes prêt à exécuter la dernière étape, c’est-à-dire l’action de votre session de mise en miroir de base de données sur tous les serveurs participants.
La configuration d’une session de mise en miroir de base de données nécessite une adresse réseau de serveur pour chacune des instances de serveurs. Cette adresse doit identifier l’instance en fournissant une adresse système et le numéro de port sur lequel l’instance écoute. La syntaxe pour une adresse réseau de serveur ressemble à ce qui suit :
TCP://<System-address>:<port>
<Adresse système> : est un nom de domaine pleinement qualifié ou une adresse IP ; vous pouvez obtenir ces informations en exécutant IPCONFIG sur l’ordinateur local à partir d’une invite de commande.
Vous avez établi le <Port> lorsque vous avez créé les points finaux.
Vous pouvez démarrer la session de mise en miroir de base de données sur le serveur B :
Alter Database DBM_Demo
Set Partner= 'TCP://ServerA.com:5001';
Ensuite, exécutez l’instruction T-SQL suivante pour démarrer la session sur le serveur A :
Alter Database DBM_Demo
Set Partner='TCP://ServerB.com:5001';
Ensuite, activez la session de mise en miroir sur le serveur C (serveur témoin) :
Alter Database DBM_Demo
Set Witness='TCP://ServerC.com:5001';
La mise en miroir de base de données est à présent prête à fonctionner dans votre environnement. Tous les objets de base de données ayant été ajoutés ou modifiés sur la base de données DBM_Demo seront transférés sur la copie du serveur B. Cependant, si la base de données du serveur A devient indisponible, un basculement peut survenir, modifiant ainsi le rôle de la base de données mise en miroir qui devient la base de données principale.
Maintenant que vous avez un miroir de base de données en état de fonctionnement, vous disposerez toujours d’une veille si votre base de données de production tombe en panne.

Saleem Hakani est un ingénieur de base de données sénior chez Microsoft, ayant plus de 14 années d’expérience avec les systèmes de base de données. Il a fondé la communauté Microsoft SQL, qu’il dirige, et est responsable des normes et de l’automatisation de SQL Server dans toute l’organisation Windows Live. Saleem détient des certifications MCTS, MCDBA et MCSA. Vous pouvez le contacter à l’adresse Saleem@sqlcommunity.net.


 Sur le terrain: Le m&#233;decin est l&#224;
Sur le terrain
Le médecin est là
Matt Hester

IL Y A PEU DE TEMPS ENCORE Être un professionnel de l’informatique ressemblait au métier de médecin. Cette révélation m’est apparue lorsque j’utilisais pour la première fois Windows Vista™. À l’époque j’avais des problèmes de connectivité réseau. Après des heures d’exécution de commandes ping, ipconfig et même quelques redémarrages, j’ai découvert un nouveau mot qui a naturellement suscité la curiosité de tous les professionnels de l’informatique : « Diagnostiquer ». Typiquement, en travaillant sur un système d’exploitation, je vois des mots et des phrases comme « réparation, » « statut, » « gestionnaire des tâches, » et « envoyer le rapport d’erreur » cela m’aide à naviguer les chemins détournés du système d’exploitation. Mais le mot « diagnostiquer » me fait penser aux similarités entre les deux professions.
En premier lieu, les médecins comme les professionnels de l’informatique doivent passer des examens de qualification et obtenir des certifications qui les autorisent à ajouter des sigles après leurs noms. Ces sigles identifient des spécialisations qui, on l’espère, font bonne impression sur le mur ou sur les cartes de visite.
Tout comme les médecins, les professionnels de l’informatique disposent de grandes ressources pour résoudre des problèmes. Les médecins consultent leurs pairs et cherchent l’information dans les journaux professionnels et sur Internet. Nous, professionnels de l’informatique, conférons également avec nos pairs et effectuons des recherches sur Internet et dans les publications techniques (particulièrement TechNet Magazine bien sûr !) pour nous aider à résoudre les problèmes.
De plus, le médecin et le professionnel de l’informatique se fient tous deux à des outils sûrs. Les médecins utilisent des instruments fiables comme le stéthoscope ; nous avons la commande ping. Ils nous permettent tous deux d’écouter ce qui se passe.
L’autre point commun est de nature sociale. Lorsque des médecins et des professionnels de l’informatique participent à des événements sociaux, ils éprouvent souvent le besoin de masquer leurs identités professionnelles. Hélas, récemment, lors d’une soirée, les gens ont découvert ce que je faisais comme métier et je suis devenu soudain extrêmement populaire. Mais cette popularité a un prix : J’ai perdu également ma réputation de personne charmante. Je suis devenu simplement le « technicien informatique » et, par extension, malgré moi le support technique sur site de tous les invités de la partie : « Hé, le technicien, pourquoi mon PC s’est-il planté ce matin ? » « Hé, le technicien, où se trouve la touche n’importe quelle touche ? », « Hé, le technicien, vous pouvez réparer mon Mac ? ». Le pire c’était de voir ce médecin à travers la pièce me regarder avec son large sourire tandis qu’il continuait à danser.
Mais revenons à notre problème de connectivité : Après trois heures d’efforts infructueux pour me connecter, j’ai cliqué sur le bouton Diagnostiquer et réparer que j’ai découvert récemment. Imaginez ma stupeur et mon embarras lorsque j’ai vu l’écran de réponse affiché ci-dessous :

(Cliquer sur l'image pour la réduire)
La bouche bée et mon visage grave, j’ai regardé autour de la pièce pour m’assurer que personne ne regardait. J’ai ensuite saisi mon PC et branché le câble. Depuis ce jour heureux, j’ai travaillé davantage avec Windows Vista et j’ai beaucoup utilisé la fonctionnalité de diagnostic. Cela m’a fait gagner énormément de temps à rechercher la cause initiale d’un grand nombre de problèmes. Grâce à une intégration parfaite avec le panneau de configuration Rapports et solutions aux problèmes, il vous permet de rechercher des informations supplémentaires en ligne. Jetez-y un coup d’œil, avant de vous arracher les cheveux.
Plus tard dans la nuit, avant de m’endormir, heureux d’avoir réussi à identifier et résoudre mon problème de connectivité réseau, je me suis demandé : puis-je à présent jouer plus souvent au golf et conduire une nouvelle voiture de sport toute neuve ?

Matt Hester est présentateur TechNet au sein de l’équipe Microsoft Across America. Pour en savoir plus (en anglais) sur ses présentations allez à technetevents.com/mhester. Vous trouverez son blog à blogs.technet.com/matthewms.


 La vie secr&#232;te de Windows: Para&#238;tre intelligent en &#233;tant stupide
La vie secrète de Windows
Paraître intelligent en étant stupide
Le site Web de Raymond Chen

LORSQUE VOUS insérez un CD dans votre ordinateur, Windows® vous demandera peut-être ce qu’il doit faire, même si vous lui avez déjà dit quoi faire la fois précédente. Pourquoi Windows oublie-t-il vos paramètres d’exécution automatique ? En fait, Windows n’a pas oublié, mais se contente de vérifier.
La façon dont Windows XP gérait l’exécution automatique de CD présentait deux problèmes. Tout d’abord, beaucoup d’utilisateurs, après avoir installé un programme prenant en charge l’exécution automatique de CD, ne savaient pas comment faire de ce programme leur nouveau programme d’exécution automatique de CD par défaut. S’ils avaient sélectionné précédemment un programme et coché « Always perform this action » (Toujours exécuter cette action) il n’y avait apparemment aucune façon d’annuler cela afin de faire réapparaître la boîte de dialogue d’exécution automatique de CD et de donner à l’utilisateur l’opportunité de sélectionner le nouveau programme comme programme par défaut.
Deuxièmement, certains programmes mal éduqués, au moment de l’installation, pirataient secrètement les paramètres d’exécution automatique de CD non documentés afin de se configurer comme programme d’exécution automatique de CD par défaut, remplaçant ainsi le choix de l’utilisateur.
Pour résumer, voici les deux problèmes qui existaient pour les utilisateurs : « Je viens d’installer un programme et je veux que ce soit mon programme d’exécution automatique de CD » et son contraire « Je viens d’installer un programme et je ne veux pas que ce soit mon programme d’exécution automatique de CD ».
Windows Vista traite les paramètres d’exécution automatique de façon globale
Windows Vista traite les paramètres d’exécution automatique de façon globale (Cliquer sur l'image pour la réduire)
Windows Vista traite les paramètres d’exécution automatique de façon globale
Windows Vista traite les paramètres d’exécution automatique de façon globale (Cliquer sur l'image pour l'agrandir)
Windows XP Service Pack 2 (SP2) a introduit un nouveau comportement d’exécution automatique de CD afin de tenter de résoudre ces problèmes. Lorsqu’il voit qu’un nouveau gestionnaire d’exécution automatique de CD est disponible, Windows affiche à présent la boîte de dialogue d’exécution automatique de CD une nouvelle fois. Cela vous permet de choisir le nouveau programme installé ou d’annuler le programme que vous avez installé s’il a eu le culot de se configurer comme nouveau lecteur par défaut.
La boîte de dialogue d’exécution automatique de CD s’affiche également la première fois que vous insérez un CD après la mise à niveau vers Windows XP SP2. Il s’agit là d’une boîte de dialogue de type « mieux vaut tard que jamais », visant à traiter les gestionnaires installés avant la mise à niveau vers Windows XP SP2.
Dans le temps, le système d’exploitation avait uniquement à se préoccuper d’aider les développeurs à utiliser une fonctionnalité. Toutefois, dans le paysage logiciel actuel, il doit également empêcher les programmeurs d’abuser de cette interface.
Il existe une autre situation dans laquelle vous aurez peut-être l’impression que Windows a oublié vos paramètres d’exécution automatique. Lorsque vous insérez un périphérique de stockage amovible, tel qu’un lecteur USB, il est possible que vous obteniez une invite même si vous avez déjà choisi une option et coché la case « Always perform this action » (Toujours exécuter cette action). Ce n’est pas parce que Windows a oublié vos paramètres, mais plutôt parce qu’il se les rappelle trop bien.
Lorsque vous sélectionnez une option pour un périphérique de stockage amovible, Windows se souvient des paramètre pour ce périphérique. Si vous branchez un périphérique différent, vous obtenez une nouvelle invite puisque vous n’avez pas spécifié comment vous vouliez que ce périphérique se comporte. Ceci vous permet par exemple d’établir votre appareil photo numérique sur « View pictures » (Afficher les images) par défaut et votre lecteur de musique sur « Play music » (Lire la musique). (Si le périphérique n’a pas un numéro de série, si vous le branchez sur un port USB différent, il sera traité comme un périphérique différent).
En réponse à la confusion créée par la conception de Windows XP, ce comportement a été modifié dans Windows Vista™. Les paramètres d’exécution automatique sont maintenant traités de façon globale, et non périphérique par périphérique. Si vous spécifiez « Take no action » (Ne rien faire), Windows Vista ne prendra aucune action, quel que soit le périphérique inséré ou l’endroit où vous l’avez branché. Parfois, pour qu’un système d’exploitation paraisse plus intelligent, il suffit de le rendre plus stupide.

Le site Web de Raymond Chen, The Old New Thing (blogs.msdn.com/oldnewthing), et son livre portant le même titre (Addison-Wesley, 2007) traitent de l’historique de Windows et de la programmation Win32. Dans ses loisirs, il corrige des devoirs de collégiens.