Autres classes et méthodes AMO

Objets Assembly

Pour créer un objet Assembly, il convient de l'ajouter à la collection d'assemblys du serveur, puis de mettre à jour l'objet Assembly sur le serveur à l'aide de la méthode Update.

Pour supprimer un objet Assembly, il est nécessaire d'utiliser la méthode Drop de ce même Assembly objet. La suppression d'un objet Assembly de la collection d'assemblys de la base de données n'a pas pour effet de supprimer l'assembly en question : elle ne fait que le masquer dans votre application jusqu'à la prochaine exécution de cette dernière.

Pour plus d'informations sur les méthodes et les propriétés disponibles, consultez Microsoft.AnalysisServices..::..Assembly dans Microsoft.AnalysisServices.

Remarque relative à la sécurité
Les assemblys COM peuvent présenter un risque pour la sécurité. En raison de ce risque et d'autres considérations, les assemblys COM ont été déconseillés dans SQL Server 2008 Analysis Services (SSAS). Les assemblys COM peuvent ne pas être pris en charge dans les versions ultérieures.

Méthodes Backup et Restore

Backup et Restore sont des méthodes qui permettent de créer des copies d'une base de données Analysis Services et de récupérer cette dernière en utilisant ces copies. La méthode Backup appartient à l'objet Database, tandis que la méthode Restore appartient à l'objet Server.

Seuls les administrateurs de serveur et de base de données sont autorisés à procéder à la sauvegarde d'une base de données. Seuls les administrateurs de serveur peuvent restaurer une base de données sur un serveur différent de celui à partir duquel la sauvegarde a été effectuée. Les administrateurs de base de données ne peuvent restaurer une base de données en remplacement de la base de données existante que s'ils sont propriétaires de la base de données destinée à être remplacée. Après une restauration, l'administrateur de base de données peut perdre l'accès à la base de données restaurée si celle-ci est restaurée avec ses définitions de sécurité d'origine.

Les fichiers de sauvegarde de base de données doivent avoir une extension .abf.

Méthode Backup

Méthode Restore

Propriétés et paramètres communs aux méthodes Backup et Restore

Objets Trace

Trace est une infrastructure destinée à surveiller, relire et gérer une instance de Analysis Services. Une application cliente, comme SQL Server Profiler, s'abonne à une trace et le serveur renvoie les événements de trace comme spécifié dans la définition de trace.

Chaque événement est décrit par une classe d'événements. La classe d'événements décrit le type d'événement généré. Au sein d'une classe d'événements, les sous-classes d'événements décrivent un niveau de catégorisation plus fin. Chaque événement est décrit par plusieurs colonnes. Les colonnes qui décrivent un événement de trace sont les mêmes pour tous les événements et sont conformes à la structure de trace SQL. Les informations enregistrées dans chaque colonne peuvent varier en fonction de la classe d'événements ; autrement dit, un ensemble prédéfini de colonnes est défini pour chaque trace, mais la signification des colonnes peut être différente d'une classe d'événements à une autre. Par exemple, la colonne TextData sert à enregistrer les éléments ASSL d'origine pour tous les événements d'instruction.

Une définition de trace peut inclure une ou plusieurs classes d'événements à suivre simultanément. Pour chaque classe d'événements, une ou plusieurs colonnes de données peuvent être ajoutées à la définition de trace, mais il n'est pas obligatoire d'utiliser toutes les colonnes de trace. L'administrateur de base de données peut en effet choisir de n'inclure dans une trace qu'une partie des colonnes disponibles. En outre, les classes d'événements peuvent faire l'objet d'un suivi sélectif basé sur des critères de filtre appliqués à une colonne de trace.

Les traces peuvent être démarrées et supprimées. Plusieurs traces peuvent à tout moment être exécutées simultanément. Les événements de trace peuvent être capturés en temps réel ou dirigés vers un fichier pour une analyse ou une relecture ultérieure. SQL Server Profiler est l'outil utilisé pour analyser et relire les événements de trace Analysis Services. Plusieurs connexions peuvent recevoir les événements d'une même trace.

Les traces peuvent être réparties en deux groupes : les traces de serveur et les traces de session. Les traces de serveur renseignent sur tous les événements du serveur ; les traces de session ne renseignent quant à elles que sur les événements de la session active.

Les traces issues de la collection de traces du serveur se définissent de la façon suivante :

1. Créez un objet Trace et spécifiez ses données de base, notamment l'ID de trace, le nom, le nom du fichier journal, ajout|remplacement, etc.

2. Ajoutez les événements à surveiller à la collection d'événements de l'objet de trace. Pour chaque événement, des colonnes de données sont ajoutées.

3. Définissez des filtres pour exclure les lignes de données inutiles en les ajoutant à la collection de filtres.

4. Démarrez la trace ; la collecte de données ne démarre pas systématiquement une fois la trace créée.

5. Arrêtez la trace.

6. Examinez le fichier de trace avec SQL Server Profiler.

Les traces de l'objet de session sont obtenues de la façon suivante :

1. Définissez des fonctions pour gérer les événements de trace générés dans votre application par SessionTrace. Les événements possibles sont OnEvent et Stopped.

2. Ajoutez vos fonctions définies au gestionnaire d'événements.

3. Démarrez la trace de session.

4. Exécutez votre processus et laissez vos gestionnaires de fonction capturer les événements.

5. Arrêtez la trace de session.

6. Poursuivez avec votre application.

Classe CaptureLog et attribut CaptureXML

Toutes les actions à exécuter par AMO sont envoyées au serveur sous forme de messages XMLA. AMO permet de capturer tous ces messages sans les en-têtes SOAP. Pour plus d'informations, consultez Présentation des classes AMO. CaptureLog est le mécanisme d'AMO qui permet d'écrire sous forme de script les objets et les opérations ; les objets et les opérations sont écrits en XMLA.

Pour commencer à capturer les données XML, la propriété d'objet serveur CaptureXML doit être définie à true. Dès lors, toutes les actions qui doivent être envoyées au serveur commencent à être capturées dans la classe CaptureLog, sans que les actions soient envoyées au serveur. CaptureLog est considérée comme une classe, car elle possède une méthode, Clear, qui sert à effacer le journal de capture.

Pour lire le journal, vous devez obtenir la collection de chaînes et commencer à parcourir les chaînes. Vous pouvez également concaténer tous les journaux dans une chaîne en utilisant la méthode d'objet serveur ConcatenateCaptureLog. ConcatenateCaptureLog comprend trois paramètres dont deux sont obligatoires. Les paramètres obligatoires sont transactional et parallel, tous deux de type booléen. Si transactional est défini à true, cela indique que le fichier de commandes XML sera traité comme une transaction unique. Autrement dit, chaque commande ne sera pas traitée comme une transaction distincte. Si parallel est défini à true, cela indique que toutes les commandes contenues dans le fichier de commandes seront enregistrées pour être exécutées simultanément et non dans l'ordre où elles ont été enregistrées.

Classe d'exception AMOException

Vous pouvez utiliser la classe d'exception AMOException pour intercepter facilement les exceptions levées dans votre application par AMO.

AMO lève des exceptions lorsque certains problèmes sont rencontrés. Le tableau suivant répertorie les types d'exceptions gérés par AMO. Les exceptions sont dérivées de la classe AmoException.

Voir aussi

Référence

Concepts