SQL Server

Atteindre une haute disponibilité pour SQL Server

Zach Nichter

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é

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 **(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 **(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

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 **(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.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.