Autres classes et méthodes AMO

S’applique à : SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Cette section contient des classes communes qui ne sont pas spécifiques à OLAP ou à l’exploration de données, et qui sont utiles lors de l’administration ou de la gestion d’objets dans Analysis Services. Ces classes recouvrent des fonctionnalités telles que les procédures stockées, le traçage, les exceptions, ainsi que la sauvegarde et la restauration.

L'illustration suivante montre la relation qui existe entre les classes décrites dans cette rubrique.

Objets d’assembly

Un Assembly objet est créé en l’ajoutant à la collection d’assemblys du serveur, puis en le Assembly mettant à jour sur le serveur, à l’aide de la méthode Update.

Pour supprimer un Assembly objet, il doit être supprimé à l’aide de la méthode Drop de l’objet Assembly . La suppression d’un Assembly objet de la collection d’assemblys de la base de données ne supprime pas l’assembly, mais vous empêche de le voir dans votre application jusqu’à la prochaine exécution de votre application.

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

Méthodes de sauvegarde et de restauration

La sauvegarde et la restauration sont des méthodes qui peuvent être utilisées pour créer des copies d’une base de données et récupérer la base de données à l’aide de la copie. 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 de sauvegarde

Pour sauvegarder une base de données, utilisez la méthode Backup de l'objet de base de données en utilisant le nom du fichier de sauvegarde comme paramètre.

Valeurs par défaut

AllowOverwrite=false

BackupRemotePartitions=false

Security=CopyAll

ApplyCompression=true

Méthode de restauration

Pour restaurer une base de données sur un serveur, utilisez la méthode Restore du serveur en utilisant le nom du fichier de sauvegarde comme paramètre.

Valeurs par défaut

AllowOverwrite=false

DataSourceType=Remote

Security=CopyAll

Restrictions

1. Une partition locale ne peut pas être restaurée en tant que partition distante.

2. Une partition distante ne peut pas être restaurée en tant que partition locale, mais elle peut être restaurée sur un serveur différent de celui à partir duquel elle a été sauvegardée.

Paramètres et propriétés courants pour les méthodes de sauvegarde et de restauration

• File est le nom du fichier à sauvegarder (nom UNC) dans/à partir de.

• L’emplacement spécifie des informations de sauvegarde spécifiques au serveur, telles que BackupFile. Cela vous permet de spécifier un fichier de sauvegarde distinct pour une base de données distante.

• DatasourceID spécifie l’ID de la base de données subordonnée dans un serveur distant.

• ConnectionString vous permet d’ajuster la source de données distante au cas où le serveur distant a changé. DatasourceID doit toujours être spécifié quand ConnectionString est présent.

• Folder autorise le remapping des dossiers pour les partitions sur le disque dur local

• Original est le dossier d’origine pour les partitions locales.

• Nouveau est le nouvel emplacement pour les partitions locales qui résidaient dans l’ancien dossier « Original » correspondant.

• Le mot de passe, s’il n’est pas vide, spécifie que le serveur chiffrera le fichier de sauvegarde.

Objets trace

Trace est une infrastructure utilisée pour la surveillance, la relecture et la gestion d’un instance d’Analysis Services. Une application cliente, comme SQL 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 Profiler est l’outil utilisé pour analyser et relire les événements de trace. 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 Trace objet et remplissez ses données de base, notamment l’ID de trace, le nom, le nom du fichier journal, append|overwrite, 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. Passez en revue le fichier de trace avec SQL 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 le code XML, la propriété d’objet serveur CaptureXML doit avoir la valeur 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 requis sont transactionnels, de type booléen et parallèles, de type booléen. Si transactionnel a la valeur true, cela indique que le fichier de commandes XML sera créé en tant que transaction unique au lieu que chaque commande soit traitée comme une transaction séparée. Si parallel est défini sur true, cela indique que toutes les commandes dans le fichier de commandes seront enregistrées pour une exécution simultanée au lieu de l’exécuter de manière séquentielle au fur et à mesure qu’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 AmoException classe .