Évolutives bases de données partagées sont prises en charge par SQL Server 2005

Traductions disponibles Traductions disponibles
Numéro d'article: 910378 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Sommaire

INTRODUCTION

Bases de données évolutives partagées sont pris en charge par SQL Server 2005 Enterprise Edition. Cet article est un aperçu de la rubrique « évolutive base de partagée données » qui sera publié une mise à jour futur de la documentation en ligne de SQL Server.

Plus d'informations

Bases de données évolutives partagées

Bases de données évolutives partagées vous permettent de joindre une base de données Rapports en lecture seule à plusieurs instances de serveur sur un réseau de zone de stockage (SAN). Une base de données de rapport est une base de données en lecture seule qui est généré à partir d'une ou plusieurs bases de production données qui sont utilisés exclusivement pour à des fins de génération d'états. À effectuer dans une base de données partagée évolutive, une base de données de rapport doit résider sur un ou plusieurs volumes en lecture seule dédiés. Le principal objectif de ces volumes en lecture seule est d'ordinateur hôte la déclaration de base de données ou un ensemble coordonné de bases de données de rapports. Ces volumes sont appelés rapport volumes.

Avantages

Bases de données évolutives partagées offrent les avantages suivants :
  • Fournir évolution charge de travail de génération d'états des bases de données à l'aide serveurs marchandise. Une base de données partagée évolutive est un moyen efficace de rendre les magasins de données en lecture seule ou entrepôts de données disponibles pour plusieurs instances de serveur pour les déclarations, comme Exécution de requêtes ou l'utilisation de SQL Server 2005 Reporting Services.
  • Fournir d'isolation de charge de travail. Chaque serveur utilise sa propre base de données Mémoire, UC et tempdb .
  • Garantir la même vue de données de rapport de tous les serveurs si toutes les instances de serveur sont configurés de manière identique. Par exemple, tous les serveurs utilisez un assemblage unique.

    note Vous pouvez éventuellement mettre à jour la base de données rapports sur un deuxième volume génération d'états. Pour plus d'informations, reportez-vous à la section « Maximize la disponibilité d'une base de données partagée évolutive ».

Restrictions

Les restrictions suivantes existent pour une base de données partagée évolutive :
  • 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.
  • Bases de données évolutives partagées sont prises en charge uniquement sur Microsoft Windows Server 2003 Service Pack 1 (SP1) ou une version ultérieure de Windows Server 2003.

Mettre à jour de cycle d'une base de données de rapport

Lorsque vous utilisez une base de données partagée évolutive pour une base de données de rapport, elle implique un cycle de mise à jour trois phases :
  • phase de génération : le cycle de mise à jour d'une base de données de rapport commence par la phase de génération. Avant d'une base de données de rapport peut être créé, l'administrateur monte le volume de génération d'états sur le système de production et facilite en lecture/écriture. Lorsqu'un volume est dans un état en lecture/écriture, le volume peut uniquement être monté sur un système. Si le volume est monté sur plusieurs systèmes, une altération de système de fichiers peut se produire. L'administrateur crée puis la base de données à l'aide de l'une des méthodes de copie des données fournies par SQL Server 2005 pour copier des données ou des bases de données. Une fois la base de données est créé, l'administrateur définit le volume en lecture seule et puis le démonte.
  • phase de joindre : la phase d'attachement vient après la phase de génération. La phase d'attachement rend la base de données disponible comme base de données partagée évolutive. La phase d'attachement doit être effectuée sur chacun des rapports serveurs individuellement. Pour configurer la base de données de création de rapport en tant qu'une base de données partagée évolutive, l'administrateur monte les volumes de génération d'états en lecture seule sur un serveur de génération d'états sur le SAN. Une fois l'administrateur garantit que chaque volume est défini sur en lecture seule, l'administrateur associe la base de données de rapport sur une instance de SQL Server. La génération d'états base de données sur une instance de SQL Server est également connu sous le nom une instance de serveur de génération d'états. Parce que chaque rapport volume est en lecture seule, attacher la base de données lui en lecture seule. À ce stade, la base de données de création de rapport devient une base de données partagée évolutive sont accessibles par les clients à l'aide le serveur de génération d'états.

    note Si vous utilisez un deuxième volume rapport lorsque vous mettez à jour la base de données de création de rapport, vous devez choisir entre une mise à niveau de report et une mise à jour synchronisée. Pour plus d'informations, reportez-vous à la section « Maximize la disponibilité d'une base de données partagée évolutive ».
  • phase de détacher : la troisième phase est la phase detach. En règle générale, la base de données de création de rapport finalement devient obsolète. La base de données doit être actualisée pour maintenir à jour les données de rapport. La phase detach est le processus de supprimer une base de données rapports obsolète service comme une base de données partagée évolutive. Avant de pouvoir créer une base de données rapports mis à jour disponibles sur un serveur rapport particulier, la phase detach doit être terminée sur ce serveur. Lorsqu'une base de données de rapport doit être actualisée, elle doit être détachée de toutes les instances de serveur. Pour commencer la phase detach, l'administrateur de base de données arrête tout d'abord la charge de requête qui proviennent de à la base de données de toutes les instances de serveur. Sur chaque instance de serveur, l'administrateur de base de données obtient un accès exclusif à la base de données et libérer enfin. L'administrateur de base de données puis Démonte le volume de chaque système ordinateur hôte. Lorsque la phase detach est terminée, le volume de génération d'états est déconnecté le SAN.
note Pour optimiser la disponibilité des données de rapports, nous vous recommandons de que vous autre cycles de mise à jour entre deux volumes recommandé d'états financiers. Lorsque le volume de génération d'états premier est toujours monté sur les serveurs de génération d'états, vous pouvez monter le volume deuxième vers le serveur de production et ensuite créer une version mise à jour de la base de données Création de rapports. Pour plus d'informations, reportez-vous à la section « Maximize la disponibilité d'une base de données partagée évolutive ».

note Chaque phase se compose d'une série d'étapes doivent être effectuées par un utilisateur disposant des droits d'administrateur de base de données. Dans cet article, cet utilisateur va être appelé l'administrateur de base de données.

important Pour configurer une base de données partagée évolutive, l'environnement de réseau SAN doit déjà fonctionner correctement.

Exemples de bases de données évolutives partagées

Cycles de mise à jour suivante, la base de données peut être mis à jour ou reconstruit. La méthode préférée varie selon vos besoins professionnels. Vous pouvez utiliser évolutives bases de données partagées de l'une des deux manières suivantes :
  • base de données du magasin de données : l'utilisation plus simple d'une base de données partagée évolutive est une base de données du magasin de données. Une base de données du magasin de données est extraites périodiquement à partir du contenu d'un data warehouse et est utilisé pour la génération d'états. Pour mettre à jour la base de données du magasin de données, de supprimer la base de données et remplacez-le par une nouvelle version.
  • Création de rapports d'une base de données pouvant être mis à jour : lorsque la base de données qui est déclarée à partir de n'est à être transformées à partir de la base de données source, la base de données de peut mettre à régulièrement jour. Pour mettre à jour régulièrement la base de données, créer une sauvegarde complète de la base de données de production, puis restaurer la sauvegarde de base de données sur le rapport volume ou volumes.

Assurez-vous que l'environnement est correct pour une base de données partagée évolutive

Une base de données partagée évolutive doit être sur un volume en lecture seule qui sont accessibles via un réseau SAN. Les serveurs de génération d'états doivent exécuter suivantes :
  • Windows Server 2003 SP1 ou une version ultérieure de Windows Server 2003
  • SQL Server 2005 Enterprise Edition ou une version ultérieure de SQL Server 2005
Pour la prise en charge, nous vous recommandons de que vous limiter vos configurations de base de données partagée évolutives à huit instances de serveur. Toutefois, SQL Server 2005 ne limite pas le nombre d'instances simultanées pouvant accéder à une base de données partagée évolutive. En règle générale, chaque instance de serveur s'exécute sur un serveur rapports distinct. Toutefois, exécution plusieurs instances de serveur de génération d'états sur un serveur de génération d'états est prise en charge.

Configuration de votre environnement

Pour vous assurer que votre environnement prend en charge évolutives bases de données partagées, nous recommandons de suivre ces instructions :
  • Assurez-vous que les serveurs de génération d'états pour une base de données de rapport spécifique sont exécutent sur des systèmes d'exploitation identiques. Chaque fois que vous mettez à niveau un serveur de génération d'états, mettre à niveau les autres serveurs rapports qui correspondent à la même base de données partagée évolutive ou bases de données. Par exemple, si vous appliquez un logiciel mise à jour ou un service pack pour Windows ou SQL Server 2005 une des serveurs de génération d'états, appliquer la même logiciel mise à jour ou le service pack sur tous les serveurs génération d'états.

    note Souvent, vous pouvez effectuer report mises à niveau des serveurs de génération d'états tant que procéder à la mise à niveau Report dans un délai raisonnable.
  • Bases de données évolutives partagées sont testés sous une charge de travail accès simultané par jusqu'à huit instances de serveur de SQL Server 2005 Enterprise Edition. SQL Server 2005 n'impose pas une limite instance. Toutefois, nous vous recommandons que vous limiter vos configurations de base de données partagée évolutives à huit instances de serveur pour chaque base de données partagée.
  • Si les fichiers de données de la base de données de production s'étendent sur plusieurs volumes, vous devez utiliser le même nombre de rapports volumes. En revanche, parce que la base de données de création de rapport est défini sur en lecture seule, ses fichiers journaux peuvent coexister avec les fichiers de données sur un volume génération d'états.
  • Pour simplifier le processus de création ou mise à jour une base de données de rapport, nous recommandons de choisir le chemin de la génération d'états base de données identique à la base de données de production. Cela inclut l'utilisation à la fois la même lettre de lecteur pour le volume de génération d'états et le même chemin de répertoire pour la base de données. Par exemple, si la base de données de production se trouve sur E:\SQLdata, utiliser électronique sous forme de la lettre de lecteur du rapport volume, s'il est possible. En outre, utiliser \SQLdata que le répertoire de la base de données génération d'états, s'il est possible. Toutefois, un script qui a les chemins d'accès explicites peut gérer les différences. Si le volume de génération d'états utilise une lettre de lecteur autre que le volume de production, vous devrez peut-être apporter les modifications suivantes :
    • Si vous créez la base de données de création de rapport en restaurant une sauvegarde de base de données, l'instruction RESTORE la base de données doit contenir une clause WITH MOVE qui spécifie le chemin complet des fichiers de données restaurées.
    • Si votre base de données de rapport est une copie de la base de données de production, la clause de JOINDRE de l'instruction CREATE DATABASE doit indiquer chaque fichier. La clause de JOINDRE doit également spécifier son chemin d'accès complet lorsque vous attachez la base de données de création de rapport. Il est toujours recommandé.

      note Raisons, utiliser la même lettre de lecteur sur chaque serveur lorsque vous montez un volume de génération d'états sur vos serveurs de génération d'états. Cette session d'exercices pratiques vous aide à gérer le volume sur les serveurs différents.
  • La base de données rapports doit être sur un volume en lecture seule qui sont accessibles via le réseau SAN à partir des tous les serveurs de génération d'états :
    • Une fois que vous montez le volume de génération d'états sur un serveur de génération d'états, assurez-vous que le volume de génération d'états est monté correctement et que les fichiers de données est accessible. Pour cela, tapez DIR <drive-letter>: \ <database-directory>à partir d'une invite de commandes, où <drive-letter>La lettre affectée à la génération d'états volume et <database-directory>Spécifie l'emplacement des fichiers de données de la base de données sur le volume. Exécuter ce test à partir de chaque serveur de génération d'états pour vous assurer que vous recevez les mêmes résultats pour toutes les.
    • Pour vous assurer que la base de données de création de rapport est définie en lecture seule, essayez de créer un fichier sur le volume. La méthode plus simple est pour essayer de copier ou enregistrer un fichier au format texte brut sur le volume. La tentative doit échouer car le volume est en lecture seule.

      note Si vous effectuez ces étapes manuellement, nous vous recommandons de que vous répéter ces tests dans chaque cycle de mise à jour lorsque vous remontez le volume de génération d'états sur chaque serveur de génération d'états. Si vous script la procédure pour déplacer volumes rapports entre le serveur de production et les serveurs de génération d'états, de test n'est plus nécessaire une fois que vous avez assurer que vos scripts fonctionne correctement.

Phase 1: la phase de génération

Créer ou d'actualiser une base de données partagée évolutive

Une base de données de rapport doit être créé et actualisé manuellement. Ce processus est la première phase du cycle de mise à jour de base de données de rapport et est connue comme la phase de génération. La phase de génération peut impliquer la mise à jour une base de données obsolète ou créer une nouvelle version.

En règle générale, la version actuelle d'une base de données de rapport finalement devient obsolète. La base de données de création de rapport doit être actualisé périodiquement pour maintenir les données de rapport mise à jour.

Terminer la phase de génération

Vous pouvez actualiser une base de données rapports obsolète par la mise à jour des données obsolètes dans la base de données existante ou par la reconstruction de la base de données.

note Avant de pouvez actualiser une base de données Rapports, la base de données doit être détachée de chaque instance de serveur de génération d'états. En outre, le volume de génération d'états doit être démonté de chaque serveur génération d'états. Pour plus d'informations, reportez-vous à la section « détacher une base de données partagée évolutive ».

Pour actualiser une base de données rapports obsolète, procédez comme suit sur le serveur de production :
  1. Utilisez les utilitaires de votre fournisseur de matériel pour unmask les numéros d'unité logique (LUN) qui correspondent aux volumes de génération d'états. Cette action rend les volumes accessible sur le serveur de production.
  2. Monter le volume de génération d'états et le marque puis en lecture-écriture. Pour utiliser l'utilitaire de ligne de commande Diskpart pour monter le volume, entrer les commandes suivantes à partir d'une invite de commandes : DiskPart
    DISKPART > sélectionnez volume =<drive-number>
    DISKPART > affecter lettre =<drive-letter>
    DISKPART > attribut clair en lecture seule
    DISKPART > quitter

    Dans cette étape, <drive-number>est le numéro volume qui est affecté par Windows et <drive-letter>est la lettre est affectée à la génération d'états volume.
  3. Si vous sont actualiser une base de données Rapports, procédez comme suit :
    1. Attacher la base de données à une instance de serveur. En règle générale, ce serait l'instance de serveur de production. CREATE
      CREATE DATABASE <database_name> ON <filespec_list>
         FOR ATTACH
      
    2. Définir la base de données en lecture/écriture en utilisant l'instruction Transact-SQL suivante.
      ALTER DATABASE <database_name> SET READ_WRITE
      Pour plus d'informations, voir en ligne de SQL Server 2005.
  4. Créer la base de données.

    Pour actualiser une base de données de rapport, vous pouvez mettre à jour les données obsolètes, reconstruire la base de données ou faire tout ce qui reste vous pensez Qu'est nécessaire pour actualiser les données. L'administrateur crée la base de données à l'aide d'une des méthodes de copie de données qui sont fournis par SQL Server 2005 pour copier des données ou des bases de données. Pour plus d'informations, reportez-vous à la section "Méthodes de création ou la mise à jour une base de données".

    note Dans le rapport des bases de données, nous conseillons de cette page Vérifiez être définir à la somme de contrôle , la valeur par défaut. Pour modifier ce paramètre, utilisez ALTER DATABASE.
  5. Définis la base de données en lecture-seule par à l'aide de l'instruction Transact-SQL suivante.
    ALTER DATABASE <database_name> SET READ_ONLY
  6. Détachez la base de données à l'aide de la suivante Transact-SQL instruction.
    sp_detach_db @dbname='<database_name>'
    Dans cette étape, <database_name>est le nom de la base de données.
  7. Sélectionnez le volume en lecture seule et puis démonter le volume à partir du serveur de production. Pour utiliser l'utilitaire de ligne de commande Diskpart pour démonter le volume, entrer les commandes suivantes à partir d'une invite de commandes.
    DiskPart
    DISKPART> select volume=<drive-number>
    DISKPART> attribute set readonly
    DISKPART> remove
    
    Dans cette étape, <drive-number>est le numéro volume qui est affecté par Windows et <drive-letter>est la lettre est affectée à la génération d'états volume.
  8. Utilisez utilitaires votre fournisseur de matériel pour masquer les LUN qui correspondent aux volumes de génération d'états. Cette action rend les volumes inaccessible vers le serveur de production.
À présent, la base de données de création de rapport peut servir une base de données partagée évolutive. Pour plus d'informations, reportez-vous à la section « attacher une base de données partagée évolutive ».

Méthodes pour créer ou de l'actualisation d'une base de données

note Lorsque vous créez une base de données de rapport, nous vous recommandons d'utiliser toujours le même chemin d'accès pour les les bases de données rapports et de la base de données de production. En outre, nous vous recommandons d'utiliser la même lettre de lecteur pour la production et rapport volume lorsque le volume est monté sur les serveurs génération d'états, s'il est possible.

SQL Server 2005 prend actuellement en charge les méthodes suivantes pour porter des données dans une base de données ou porter une base de données entière :
  • SQL Server Integration Services : vous pouvez créer ou copier une base de données en exécutant des packages Integration Services et en utilisant la tâche Exécuter SQL ou le transfert de base de données Office :
    • La tâche Exécuter SQL exécute les instructions SQL ou procédures stockées à partir d'un package. Lorsque vous utilisez la tâche Exécuter SQL, vous pouvez créer une base de données en exécutant une instruction CREATE DATABASE. Vous pouvez ensuite renseigner la base de données en copiant dans un ou plusieurs tables ou vues.
    • La tâche de transfert de base de données pouvez copier une base de données dans la même instance de serveur ou entre les instances.

      note Vous pouvez également créer une base de données grâce aux SQL Server Importation et l'Assistant Exportation, mais vous devez copier au moins une table ou vue.
  • sauvegarde et de restauration : vous pouvez restaurer une sauvegarde d'une base de données de production sur le volume de génération d'états. Pour ce faire, restaurer et récupérer une sauvegarde de base de données complète sur le volume de génération d'états :
    • Si vous utilisez la même lettre de lecteur, montez le volume sur un autre ordinateur hôte génération d'états et puis connectez-vous à une instance de serveur il pour restaurer la base de données.
    • Si le volume de génération d'états utilise une lettre de lecteur autre que le volume de production, l'instruction RESTORE la base de données doit contenir une clause WITH MOVE qui spécifie la lettre de lecteur du volume génération d'états dans le chemin de la base de données restaurée.
  • copie de la base de données de production sur le volume de génération d'états : avant de vous pouvez manuellement copier une base de données ou utiliser le détacher et attacher la méthode de l'Assistant Copie de base de données, vous devez prendre la base de données en mode hors connexion. Après avoir copié la base de données, mettez la base de données en ligne. Toutefois, la copie de la base de données Assistant propose une méthode alternative. La méthode SMO transfert copie la base de données même si la base de données reste en ligne. Bien que la SMO transfert méthode est plus lent que du Détacher et Attacher méthode, la méthode de transfert SMO conserve les connexions actives dans la base de données.
Pour plus d'informations sur ces méthodes de copie de données, voir en ligne de SQL Server 2005.

Lorsque la base de données de création de rapport est prêt, vous devez effectuer la phase de génération. Pour plus d'informations, voir la « phase 1: la phase de génération « section.

Phase 2: la phase d'attachement

Attacher une base de données partagée évolutive

Une fois que vous créer ou mettre à jour une base de données de rapport et vous démontez le volume génération d'états à partir du serveur de production, un administrateur devez rendre la base de données disponible comme base de données partagée évolutive. Ce processus est appelé la phase d'attachement.

Terminer la phase d'attachement

De cette phase, un administrateur doit procédez comme suit :
  1. Utiliser utilitaires votre fournisseur de matériel pour unmask les LUN qui correspondent aux volumes de génération d'états. Cette action permet les volumes accessible aux clients à partir de chaque serveur de génération d'états.
  2. Sur chaque serveur de génération d'états, montez le volume qui correspond au LUN.

    note Pour simplifier le processus de création ou mise à jour une base de données de rapport, nous vous recommandons de que vous montez toujours son volume de génération d'états en utilisant la même lettre de lecteur comme le volume de production. Par exemple, si la base de données de production est sur le lecteur E sur le serveur de production, le volume de génération d'états doit également être monté comme lecteur E sur chaque serveur de génération d'états, s'il est possible.

    Pour utiliser l'utilitaire de ligne de commande Diskpart pour monter le volume, entrez les commandes suivantes à partir d'une invite de commandes.
    DiskPart
    DISKPART> select volume=<drive-number>
    DISKPART> assign letter=<drive-letter>
    DISKPART> exit
    
    Dans cette étape, <drive-number>est le numéro volume qui est affecté par Windows et <drive-letter>est la lettre que vous souhaitez utiliser pour le rapport volume sur le serveur de génération d'états.

    note Le volume de génération d'états doit être en lecture seule. Nous vous recommandons que qu'il soit marquée en lecture seule avant que le volume est démonté à partir du serveur de production. Si le volume n'a pas marqué comme en lecture seule, définir le volume en lecture seule une fois que vous montez le volume sur le premier serveur de génération d'états. Pour plus d'informations, voir la « phase 1: la phase de génération « section.

    Raisons, assurez-vous que que le volume est accessible comme un volume en lecture seule sur le SAN une fois que vous monter un volume de génération d'états à chaque serveur de génération d'états. Pour plus d'informations, reportez-vous à la section « Assurez-vous que l'environnement est correct pour une base de données partagée évolutive ».
  3. Attacher la base de données à l'instance du serveur de rapports ou instances sur chaque serveur de génération d'états. Pour plus d'informations, voir en ligne de SQL Server 2005.
La base de données de création de rapport est désormais disponible en une base de données partagée évolutive, et requêtes peuvent continuer.

Phase 3: la phase detach

Détacher une base de données partagée évolutive

En règle générale, la version actuelle d'une base de données de rapport finalement devient obsolète et doit être actualisée les données de rapport à jour. Le processus de supprimer une base de données rapports obsolète service comme une base de données partagée évolutive est appelé la phase detach. Cette phase est passe de la phase de troisième et dernière de la mise à jour pour une base de données de rapport. Avant de pouvoir créer une base de données rapports mis à jour disponibles sur un serveur rapport particulier, la phase detach doit être terminée sur ce serveur.

Terminer la phase de detach

De cette phase, un administrateur doit procédez comme suit sur chaque serveur de génération d'états :
  1. Désactiver les nouvelles requêtes sur la base de données et laisser ensuite requêtes en cours se termine normalement, si il est possible.
  2. Détachez la base de données de chaque instance de serveur de génération d'états en utilisant le @dbname sp_detach_db = '<nom_base_données>'la commande.

    Dans cette étape, <database_name>est le nom de la base de données. Pour plus d'informations sur la commande sp_detach_db , consultez en ligne de SQL Server 2005.
  3. Sur chaque serveur de génération d'états, démonter le volume de génération d'états. Pour démonter le volume à l'aide de l'utilitaire de ligne de commande Diskpart, entrez les commandes suivantes à partir d'une invite de commandes.
    DiskPart
    DISKPART> select volume <drive-number>
    DISKPART> remove
    
    Dans cette étape, <drive-letter>est la lettre affectée à la génération d'états volume.
  4. Utilisez utilitaires votre fournisseur de matériel pour masquer les LUN qui correspondent aux volumes de génération d'états. Cette action rend les volumes inaccessibles aux clients à partir de chaque serveur de génération d'états.

Stratégies de remplacement pour détachement d'une base de données rapports obsolète

Lorsque vous remplacez la version obsolète d'une base de données, vous devez considérer les besoins pour votre environnement de génération d'états. Vous devez évaluer les exigences métier suivantes sont prioritaires dans votre environnement :
  • Conserver les transactions en cours d'exécution jusqu'à ce que leur fini.
  • Fin de la mise à jour dans une période limitée.
Selon les besoins est prioritaire, vous pouvez décider comment faire pour gérer la phase detach sur chaque serveur de génération d'états. Vous pouvez gérer la phase detach de l'une des manières suivantes :
  • Permettent les transactions se terminer avant que vous détacher le serveur de génération d'états : pour conserver toutes les transactions en cours, vous devez démarrer la phase detach en arrêtant l'activité d'E / S entrante pour le volume de génération d'états. Puis, sur chaque instance de serveur génération d'états, attendez pour détacher la base de données jusqu'à ce que toutes les transactions en cours sont terminées. Lorsque la base de données a été détachée de toutes les instances de serveur, vous pouvez démonter le volume génération d'états.
  • Mettre à jour de la base de données pendant une période limitée : dans ce cas, vous devez obtenir l'accès exclusif à la base de données sur chaque instance de serveur avec une heure de fin qui permet de votre période. Si toutes les requêtes ne finit pas dans ce délai Arrêt, il sont arrêtés. Ces requêtes devra attendre jusqu'à ce qu'après la mise à jour d'être redémarré. Une fois les requêtes sont arrêtés, vous pouvez Détachez la base de données de chaque instance de serveur et puis démonter le volume génération d'états de chaque serveur génération d'états.
À ce stade, vous êtes prêt pour la phase de génération suivante. Sinon, si vous avez déjà actualisé la base de données sur un autre volume génération d'états que nous vous recommandons, vous pouvez maintenant effectuer la phase d'attachement pour le volume de remplacement. Pour plus d'informations, reportez-vous à la section « Maximize la disponibilité d'une base de données partagée évolutive ».

Optimiser la disponibilité d'une base de données partagée évolutive

Pour optimiser la disponibilité des données de rapports, nous vous recommandons de que vous autre cycles de mise à jour entre deux volumes de génération d'états. Lorsque le volume de génération d'états premier est toujours monté sur les serveurs de génération d'états, vous pouvez monter le volume deuxième vers le serveur de production et créer une version mise à jour de la base de données Création de rapports.

Si vous mettez à jour la base de données rapports sur un deuxième volume génération d'états, envisagez les options suivantes :
  • Si vous souhaitez que toutes vos bases de création de rapports données pour renvoyer des résultats identiques aux clients, vous devez détacher l'ancienne copie de toutes les instances de serveur avant de joindre la nouvelle copie à l'une d'elles.
  • Si vous pouvez tolérer des clients de recevoir des résultats différents sur instances de serveur différent lorsque vous mettez à jour la base de données de création de rapport, vous pouvez effectuer une mise à niveau report de la base de données de création de rapport. Vous devez terminer le cycle de mise à jour sur un serveur génération d'états à la fois.

Synchronisation, fois-sensibles met à jour de tous les serveurs génération d'états

Cette section décrit plusieurs stratégies pour la mise à jour le contenu de la base de évolutive données partagée, selon vos besoins métier :
  • Vous devez conserver tous les rapports serveurs de.
  • Vous devez effectuer la mise à jour dans une période limitée. Cette période est plus important que la conservation des transactions en cours d'exécution.
Lorsque vous synchronisez la base de données sur tous les serveurs de génération d'états, la base de données rapports est indisponible entre la phase detach pour la version obsolète de la base de données et de la phase d'attachement de la nouvelle version.

Pour synchroniser le cycle de mise à jour toutes les instances de serveur génération d'états et fin de cycle de la mise à jour dans une période limitée, procédez comme suit :
  1. Pour synchroniser le contenu, que vous devez terminer la detach phase sur tous les serveurs rapports avant de l'un des serveurs de génération d'états peut être mis à jour. Si les requêtes de longue sont actives sur n'importe quel serveur, vous devez arrêter les.
  2. Une fois que vous démontez le volume rapport première de toutes les instances de serveur, vous pouvez commencer à mettre à jour les serveurs de génération d'états. Sur chaque serveur de génération d'états, Monter un autre volume qui contient une version plus récente de la base de données de création de rapport. Associer cette version à l'instance de serveur de génération d'états locale. Dès que la base de données est attaché sur une instance particulière, transactions arrêtées peuvent être redémarrées sur cette instance.

Restauration des mises à niveau de reporting de serveurs

Une mise à niveau Report vous permet d'actualiser la base de données génération d'états sur un serveur de génération d'états lorsqu'un obsolètes rapports de base de données reste temporairement disponible sur un autre serveur de génération d'états. Pour un certain temps, à la fois la version obsolète et la version actualisée de la base de données sont disponibles en même temps. Selon vos besoins professionnels, une mise à niveau de report peut se produire dans une période limitée ou la mise à niveau report peut être relativement ouverte pour permettre des transactions en cours de fin.

Vous permettent de transactions se termine avant la mise à niveau report

Dans cette stratégie, une mise à niveau de report permet à l'administrateur de base de données à attendre transactions durables se termine à un serveur de génération d'états lorsque la base de données sur un autre serveur de génération d'états est actualisé. Cette stratégie traite les exigences métier suivantes :
  • Les serveurs de génération d'états ne pas devoir rester synchronisés. Cela permet une mise à niveau report entre la obsolète base de données rapports et la base de données rapports mis à jour.
  • Vous avez une période illimité pour effectuer la mise à jour, ou l'échéance est moins critique à conserver les transactions en cours d'exécution.
Pour effectuer cette forme de report de mise à niveau, procédez comme suit sur une instance de serveur à la fois :
  1. Pour conserver toutes les transactions en cours, vous devez démarrer la phase detach en arrêtant l'activité d'E / S entrante pour le volume de génération d'états. Si une longue requête retarde la mise à niveau sur une instance de serveur, attendez que la requête pour se terminer avant déconnecter l'instance du serveur.
  2. Une fois que toutes les transactions sont terminées sur cette instance de serveur, détachez la base de données Création de rapports.
  3. Une fois que vous détachez une base de données particulière génération d'états de toutes les instances de serveur, associer une version plus récente de la génération d'états base de données à cette instance de serveur.
  4. Pour rendre l'instance de serveur disponible pour les requêtes Création de rapports, attachez une copie à jour de la base de données.

Terminer la mise à niveau report en un temps limité

Dans cette stratégie, une mise à niveau report permet l'administrateur de base de données pour maintenir la continuité des services Création de rapports en laissant brièvement la version obsolète de la base de données reste disponible pour les nouvelles requêtes sur certains serveurs de génération d'états. Le service reste sans interruption lorsque vous mettez à jour la base de données sur un autre serveur de génération d'états. Cette stratégie traite les exigences métier suivantes :
  • Les serveurs de génération d'états ne pas devoir rester synchronisés. Cela permet une mise à niveau report entre la obsolète base de données rapports et la base de données rapports mis à jour.
  • Vous devez effectuer la mise à jour dans une période limitée. Ce délai est plus important de conservation des transactions en cours d'exécution.
Pour effectuer cette forme de report de mise à niveau, procédez comme suit sur un serveur génération d'états à la fois :
  1. Arrêter l'activité d'E / S entrante pour le volume de génération d'états et, éventuellement, attendez pour les transactions courte à se terminer à une instance de serveur avant de vous détacher la base de données de rapport.
  2. Terminer la phase detach sur ce serveur. Pour plus d'informations, reportez-vous à la section « détacher une base de données partagée évolutive ».
  3. Mettre la version mise à jour de la base de données rapports disposition à nouveau pour les requêtes Création de rapports. Pour plus d'informations, reportez-vous à la section « attacher une base de données partagée évolutive ».
Cette mise à niveau de report garantit que la fonctionnalité de génération d'états globale est jamais interrompue. Cette stratégie vous permet de pour tolérer des transactions relativement longue sur des instances de serveur pendant un certain temps. Toutefois, offerte la période limitée pour la mise à jour toutes les bases de création de rapports données, si une longue requête diffère considérablement la mise à niveau sur une instance de serveur, vous devrez arrêter cette requête. La requête peut attendre pour être réexécuté sur la même instance du serveur après sa base de données de rapport a été actualisé, ou la requête peut être redémarrée plus tôt sur un serveur mis à jour.

Références

Pour télécharger en ligne de SQL Server 2005, reportez-vous au site Web du Centre de téléchargement Microsoft suivant :
http://www.microsoft.com/downloads/details.aspx?FamilyID=be6a2c5d-00df-4220-b133-29c1e0b6585f&DisplayLang=en
SQL Server nécessite systèmes afin de prendre en charge ? garantie remise aux médias stable ? comme indiqué dans le programme Microsoft SQL Server Always-On stockage solution analyse. FO Pour plus d'informations sur les exigences entrées et de sortie pour le moteur de base de données SQL Server, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
967576 Microsoft SQL Server Database Engine entrée/sortie configuration

Propriétés

Numéro d'article: 910378 - Dernière mise à jour: mardi 20 novembre 2007 - Version: 2.4
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Enterprise Edition for Itanium Based Systems
  • Microsoft SQL Server 2005 Enterprise X64 Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Standard
Mots-clés : 
kbmt kbsql2005engine kbtshoot kbinfo KB910378 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 910378
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com