Cet article a fait l'objet d'une traduction manuelle. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte. Informations supplémentaires.

Traduction

Source

Ce sujet n'a pas encore été évalué - Évaluez ce sujet

Administrer une base de données de serveur de rapports

SQL Server 2012

Autres versions

Un déploiement de Reporting Services utilise deux bases de données relationnelles SQL Server pour le stockage interne. Par défaut, les bases de données sont nommées ReportServer et ReportServerTempdb. La base de données ReportServerTempdb est créée à l'aide de la base de données du serveur de rapports primaire et sert à stocker les données temporaires, les informations de session et les rapports mis en mémoire cache.

Dans Reporting Services, les tâches d'administration de base de données consistent à sauvegarder et à restaurer les bases de données du serveur de rapports et à gérer les clés de chiffrement qui permettent de chiffrer et de déchiffrer les données sensibles.

Pour administrer les bases de données du serveur de rapports, SQL Server met une série d'outils à votre disposition.

Pour sauvegarder ou restaurer la base de données du serveur de rapports, déplacer une base de données du serveur de rapports ou récupérer une base de données du serveur de rapports, vous pouvez utiliser SQL Server Management Studio, les commandes Transact-SQL ou les utilitaires d'invite de commandes de base de données. Pour obtenir des instructions, consultez Déplacement des bases de données du serveur de rapports vers un autre ordinateur dans la documentation en ligne de SQL Server.
Pour copier le contenu d'une base de données dans une autre base de données du serveur de rapports, vous pouvez attacher une copie d'une base de données du serveur de rapports et l'utiliser avec une autre instance du serveur de rapports. Ou encore, vous pouvez créer et exécuter un script qui utilise des appels SOAP pour recréer le contenu du serveur de rapports dans une nouvelle base de données. Vous pouvez utiliser l'utilitaire rs pour exécuter le script.
Pour gérer les connexions entre le serveur de rapports et la base de données connexe et pour déterminer quelle base de données utilise une instance de serveur de rapports particulière, utilisez la page Installation de la base de données dans l'outil de configuration de Reporting Services. Pour plus d'informations sur la connexion du serveur de rapports à la base de données du serveur de rapports, consultez Configurer une connexion à la base de données du serveur de rapports (en mode natif).

Autorisations de compte de connexion et de base de données SQL Server

Les bases de données du serveur de rapports sont utilisées en interne par le serveur de rapports. Les connexions à une base de données sont opérées par le service Report Server. Vous devez utiliser l'outil de configuration de Reporting Services pour configurer la connexion du serveur de rapports à la base de données du serveur de rapports.

Les informations d'identification de la connexion du serveur de rapports à la base de données peuvent être représentées par le compte de service, un compte d'utilisateur local ou de domaine Windows, ou un utilisateur de base de données SQL Server. Vous devez choisir un compte existant pour la connexion ; Reporting Services ne crée pas de comptes à votre place.

Une connexion SQL Server à la base de données du serveur de rapports est créée automatiquement pour le compte de votre choix.

Les autorisations d'accès à la base de données sont également configurées automatiquement. L'outil de configuration de Reporting Services attribue les rôles Public et RSExecRole à l'utilisateur du compte ou à l'utilisateur de base de données pour les bases de données du serveur de rapports. Le rôle RSExecRole fournit les autorisations permettant d'accéder aux tables de base de données et d'exécuter des procédures stockées. Le rôle RSExecRole est créé dans les bases de données master et msdb au moment de créer la base de données du serveur de rapports. RSExecRole est un membre du rôle db_owner pour les bases de données du serveur de rapports, ce qui permet au serveur de rapports de mettre à jour son propre schéma pour la prise en charge d'un processus de mise à niveau automatique.

Conventions d'affectation des noms pour les bases de données du serveur de rapports

Lors de la création de la base de données primaire, le nom de la base de données doit respecter les règles spécifiées pour les Identificateur de la base de données.. La base de données temporaire utilise toujours le même nom que la base de données primaire du serveur de rapports, mais avec le suffixe Tempdb. Vous ne pouvez pas choisir un autre nom pour la base de données temporaire.

Le changement de nom des bases de données de serveur de rapports n'est pas pris en charge car ces bases de données sont considérées comme des composants internes. Renommer des bases de données de serveur de rapports entraîne des erreurs. Si vous renommez la base de données primaire, un message d'erreur explique que les noms des bases de données ne sont plus synchronisés. Si vous renommez la base de données ReportServerTempdb, l'erreur interne suivante se produit ultérieurement lorsque vous exécutez les rapports :

« Une erreur interne s'est produite sur le serveur de rapports. Consultez le journal des erreurs pour plus d'informations. (rsInternalError)

Nom d'objet 'ReportServerTempDB.dbo.PersistedStream' non valide. »

Cette erreur se produit car le nom ReportServerTempdb est stocké en interne et utilisé par des procédures stockées pour effectuer des opérations internes. Renommer la base de données temporaire empêche le bon fonctionnement des procédures stockées.

Activation de l'isolement d'instantané sur la base de données du serveur de rapports

Vous ne pouvez pas activer l'isolement d'instantané sur la base de données du serveur de rapports. Si l'isolement d'instantané est activé, l'erreur suivante s'affiche : « Le rapport sélectionné n'est pas prêt pour être affiché. Le rendu du rapport n'est pas terminé ou son instantané n'est pas disponible ».

Si vous n'avez pas volontairement activé l'isolement d'instantané, il est possible que l'attribut ait été défini par une autre application ou que l'isolement d'instantané soit activé sur la base de données model ; dans ce dernier cas, toutes les nouvelles bases de données héritent du paramètre.

Pour désactiver l'isolement d'instantané sur la base de données du serveur de rapports, démarrez Management Studio, ouvrez une nouvelle fenêtre de requête, collez puis exécutez le script suivant :

ALTER DATABASE ReportServer
SET ALLOW_SNAPSHOT_ISOLATION OFF
ALTER DATABASE ReportServerTempdb
SET ALLOW_SNAPSHOT_ISOLATION OFF
ALTER DATABASE ReportServer
SET READ_COMMITTED_SNAPSHOT OFF
ALTER DATABASE ReportServerTempDb
SET READ_COMMITTED_SNAPSHOT OFF

À propos des versions de base de données

Dans Reporting Services, aucune information explicite n'est disponible sur la version des bases de données. Toutefois, comme les versions des bases de données sont toujours synchronisées avec les versions des produits, vous pouvez utiliser les informations de version d'un produit pour savoir quand la version de base de données a changé. Les informations de version d'un produit pour Reporting Services sont indiquées par le biais des informations de version de fichier qui apparaissent dans les fichiers journaux, dans les en-têtes de tous les appels SOAP et lorsque vous vous connectez à l'URL du serveur de rapports (par exemple, lorsque vous ouvrez un navigateur à l'adresse http://localhost/reportserver).

Voir aussi