Vue d'ensemble des bases de données partagées évolutives
La fonctionnalité de base de données partagée évolutive vous permet de développer une base de données en lecture seule créée exclusivement pour générer des rapports (base de données de rapports). La base de données de rapports doit résider sur un ensemble de volumes dédiés en lecture seule dont l'objectif principal est d'héberger la base de données. L'utilisation de produits matériels pour les serveurs et les volumes vous permet de développer une base de données de rapports qui fournit un affichage identique des données de rapport sur plusieurs serveurs de rapports. Cette fonctionnalité permet également l'utilisation d'un chemin de mise à jour régulier pour la base de données de rapports.
Une fois que la base de données de rapports a été créée sur un ensemble de volumes de rapports, les volumes sont marqués en lecture seule et sont montés sur plusieurs serveurs de rapports. Sur chaque serveur de création de rapports, la base de données de rapports est attachée à une instance de MicrosoftSQL Server 2005 et versions ultérieures et devient disponible en tant que base de données partagée évolutive. Une fois établie comme base de données partagée évolutive, une base de données de rapports peut être partagée par des clients qui utilisent des serveurs de rapports différents. Pour interroger la base de données, un utilisateur ou une application peuvent se connecter à toute instance de serveur à laquelle la base de données est attachée. Pour une version donnée d'une base de données de rapports, des clients sur des serveurs différents obtiennent une vue identique des données de rapports, ce qui fournit des résultats de requête cohérents entre les serveurs.
Avantages
Les bases de données partagées évolutives offrent les avantages suivants :
Évolutivité horizontale de la charge de travail sur vos bases de données de rapports en utilisant des produits matériels et serveur.
Une base de données partagée évolutive représente une manière économique de rendre un mini-Data Warehouse ou des Data Warehouses en lecture seule accessibles à plusieurs instances de serveur pour générer des rapports, en exécutant des requêtes ou en utilisant Reporting Services.
Isolation de la charge de travail.
Chaque serveur utilise ses propres éléments : mémoire, UC et base de données tempdb, ce qui empêche une requête au paramétrage incorrect de monopoliser toutes vos ressources de serveur.
Vue identique des données de rapports à partir de tous les serveurs.
Cela suppose que toutes les instances de serveur sont configurées de manière identique, par exemple, qu'elles utilisent un classement unique.
[!REMARQUE]
Vous pouvez mettre à jour la base de données de rapports sur un second volume de rapports. Pour plus d'informations, consultez Optimisation de la disponibilité d'une base de données partagée évolutive.
Limitations
Les bases de données partagées évolutives présentent les limitations suivantes :
La base de données doit être sur un volume en lecture seule.
Les fichiers de données sont accessibles via un réseau SAN.
Les bases de données sont prises en charge par Windows Storage qui s'exécute uniquement sous Windows Server 2003 SP1 ou version ultérieure.
Nous vous conseillons de limiter la configuration de vos bases de données partagées évolutives à huit instances de serveur par base de données partagée.
Les bases de données partagées évolutives ne prennent pas en charge les captures instantanées de base de données.
Important
La configuration d'une base de données partagée évolutive requiert que l'environnement SAN (Storage Area Network) fonctionne déjà correctement. Pour obtenir des instructions et des conseils sur l'utilisation d'une base de données partagée évolutive, consultez Vérification d'un environnement correct pour une base de données partagée évolutive.
Création et développement d'une base de données de rapports
Pour configurer une nouvelle base de données partagée évolutive, un administrateur de base de données commence par construire une nouvelle base de données de rapports sur un ensemble de volumes de rapports ou en actualisant une version obsolète de la base de données de rapports sur ces volumes (phase de construction ou d'actualisation). L'administrateur développe ensuite la base de données en la configurant en tant que base de données partagée évolutive sur plusieurs instances de serveur (phase d'attachement).
La figure ci-dessous illustre la construction d'une nouvelle base de données de rapports à l'aide d'un volume de rapports unique et l'attachement de cette base de données pour la rendre disponible en tant que base de données partagée évolutive.
.gif "Base de données partagée évolutive utilisant 1 volume de création de rapports")
La phase de construction représentée sur la figure illustre le processus visant à monter le volume de rapports sur le serveur de production et à construire la base de données de rapports. Après avoir été monté sur le système de production, le volume est marqué comme accessible en lecture-écriture. Ensuite, une base de données de création de rapports est construite sur le volume à l'aide d'une des méthodes de copie de données fournies par SQL Server 2005 et versions ultérieures pour la copie des données et des bases de données. La base de données de rapports représentée sur cette figure est une copie d'une base de données de production complète. Après avoir construit la base de données, l'administrateur définit en lecture seule chaque volume de rapports et le démonte.
La phase d'attachement représentée sur la figure illustre la mise à disposition de la base de données de rapports en tant que base de données partagée évolutive. En premier lieu, l'administrateur monte le volume de rapports en lecture seule sur plusieurs serveurs de rapports via le réseau SAN. Ensuite, sur chaque serveur de rapports, l'administrateur attache la base de données de rapports à une instance de SQL Server. La base de données est attachée en tant que base de données en lecture seule car les volumes sont en lecture seule. Une fois ce processus achevé sur un serveur de rapports donné, la base de données de rapports devient une base de données partagée évolutive sur ce serveur. Toutefois, la phase d'attachement dans son ensemble continue tant que la base de données n'est pas attachée sur tous les serveurs de rapports.
Une version donnée d'une base de données de rapports reste disponible en tant que base de données partagée évolutive tant qu'elle est attachée à un des serveurs de rapports.
Mise à jour d'un ensemble de volumes de rapports
Comme une base de données de rapports est en lecture seule, en général, elle devient éventuellement obsolète et doit être actualisée pour que les données de rapports soient mis à jour. Dans le cas d'une configuration de base de données partagée évolutive, le processus complet visant à remplacer une base de données de rapports sur un ensemble donné de volumes de rapports à l'aide d'une version actuelle de la même base de données porte le nom de cycle de mise à jour.
Cycle de mise à jour
Le cycle de mise à jour commence avec la phase de détachement, qui se termine par le démontage de tous les volumes de rapports de tous les serveurs de rapports. Ensuite, la phase d'actualisation a lieu (équivalente à la phase de construction d'une nouvelle base de données de rapports). La phase d'actualisation se termine avec une version actualisée relativement mise à jour de la base de données sur des volumes en lecture seule qui ne sont actuellement montés sur aucun serveur. Enfin, la base de données est établie en tant que base de données partagée évolutive au cours d'une phase d'attachement qui implique les mêmes étapes que celles utilisées pour attacher une nouvelle base de données de rapports.
Phase de détachement
La première phase d'un cycle de mise à jour supprime la base de données obsolète de la configuration de base de données partagée évolutive sur chaque serveur de rapports. Le processus de suppression d'une base de données de rapports obsolète d'un service en tant que base de données partagée évolutive porte le nom de phase de détachement du cycle de mise à jour. Avant de pouvoir proposer une version actualisée d'une base de données de rapports sur un serveur de rapports donné, cette phase doit être terminée sur ce serveur.
Pour commencer la suppression de la base de données, l'administrateur de base données arrête la charge de travail de requête entrant dans la base de données à partir de chaque instance de serveur. Ensuite, sur chaque serveur de rapports, l'administrateur détache la base de données. Une fois détachée de la dernière instance de serveur, la base de données de rapports cesse d'être une base de données partagée évolutive. Pour terminer cette phase, l'administrateur démonte l'ensemble de volumes de rapports contenant la base de données obsolète.
Phase d'actualisation
La phase suivante du cycle de mise à jour implique l'actualisation de la base de données sur le même ensemble de volumes de rapports. L'actualisation de la base de données implique soit sa mise à jour, par exemple en important les données de production en cours, soit sa reconstruction, par exemple en restaurant une sauvegarde récente de la base de données de production. La méthode préférable d'actualisation d'une base de données dépend des besoins de votre entreprise.
Phase d'attachement
Pour terminer le cycle de mise à jour pour un ensemble de volumes de rapports, l'administrateur doit développer la base de données actualisée. Si un seul ensemble de volumes de rapports est utilisé pour une configuration de base de données partagée évolutive, le processus d'attachement au cours d'une mise à jour est équivalent au processus d'attachement d'origine.
Alternance des versions de la base de données entre deux ensembles de volumes de rapports
Pour garantir une disponibilité maximale d'une configuration de base de données partagée évolutive, vous pouvez utiliser deux ensembles alternés de volumes de rapports. Cela permet de superposer les cycles de mise à jour d'une base de données obsolète et d'une base de données actualisée. La base de données de rapports actualisée réside sur un ensemble différent de volumes. Avant de détacher la version obsolète de la base de données et de démonter ses volumes, vous pouvez actualiser la base de données sur l'autre ensemble de volumes et monter ces volumes sur les serveurs de rapports. Ensuite, lorsque vous détachez la version obsolète de la base de données d'une instance de serveur donnée, vous pouvez attacher immédiatement la version actualisée.
Pour plus d'informations, consultez Optimisation de la disponibilité d'une base de données partagée évolutive.
Voir aussi