Freigeben über

Andere AMO-Klassen und -Methoden

  • Artikel

Gilt für: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Dieser Abschnitt enthält allgemeine Klassen, die nicht spezifisch für OLAP oder Data Mining sind und beim Verwalten von Objekten in Analysis Services hilfreich sind. Diese Klassen decken Funktionen wie gespeicherte Prozeduren, Ablaufverfolgung, Ausnahmen sowie Sicherung und Wiederherstellung ab.

Die folgende Abbildung zeigt die Beziehung der in diesem Thema erläuterten Klassen.

Andere Klassen in AMO

Assemblyobjekte

Ein Assembly -Objekt wird erstellt, indem es der Assemblys-Auflistung des Servers hinzugefügt und das Assembly Objekt dann mithilfe der Update-Methode auf den Server aktualisiert wird.

Um ein Assembly Objekt zu entfernen, muss es mit der Drop-Methode des Assembly -Objekts gelöscht werden. Wenn Sie ein Assembly Objekt aus der Assemblys-Auflistung der Datenbank entfernen, wird die Assembly nicht gelöscht. Es verhindert nur, dass Sie es in Ihrer Anwendung sehen, bis Sie die Anwendung das nächste Mal ausführen.

Weitere Informationen zu verfügbaren Methoden und Eigenschaften finden Sie unter AssemblyMicrosoft.AnalysisServices .

Wichtig

COM-Assemblys können ein Sicherheitsrisiko darstellen. Aufgrund dieses Risikos und anderer Überlegungen werden COM-Assemblys nicht mehr unterstützt.

Sicherungs- und Wiederherstellungsmethoden

Sicherung und Wiederherstellung sind Methoden, die verwendet werden können, um Kopien einer Datenbank zu erstellen und die Datenbank mithilfe der Kopie wiederherzustellen. Die Backup-Methode gehört zum Database -Objekt und die Restore-Methode zum Server -Objekt.

Nur Server- und Datenbankadministratoren ist es gestattet, eine Datenbank zu sichern. Nur Serveradministratoren können eine Datenbank auf einem anderen Server als dem, auf dem die Sicherung ausgeführt wurde, wiederherstellen. Datenbankadministratoren können eine Datenbank durch Überschreiben der vorhandenen Datenbank wiederherstellen, jedoch nur, wenn sie die zu überschreibende Datenbank besitzen. Nach der Wiederherstellung verliert der Datenbankadministrator möglicherweise die Zugriffsberechtigung für die wiederhergestellte Datenbank, wenn diese mit den ursprünglichen Sicherheitsdefinitionen wiederhergestellt wurde.

Datenbanksicherungsdateien müssen eine .abf-Erweiterung aufweisen.

Sicherungsmethode

Verwenden Sie zum Sichern einer Datenbank die Backup-Methode des Datenbankobjekts zusammen mit dem Namen der Sicherungsdatei als Parameter.

Standardwerte

AllowOverwrite=false

BackupRemotePartitions=false

Security=CopyAll

ApplyCompression=true

Wiederherstellungsmethode

Verwenden Sie zum Wiederherstellen einer Datenbank auf einem Server die Restore-Methode des Servers zusammen mit dem Namen der Sicherungsdatei als Parameter.

Standardwerte

AllowOverwrite=false

DataSourceType=Remote

Security=CopyAll

Beschränkungen

  1. Eine lokale Partition kann nicht als Remotepartition wiederhergestellt werden.

  2. Eine Remotepartition kann nicht als lokale Partition wiederhergestellt werden, jedoch kann eine Remotepartition auf einem anderen Server wiederhergestellt werden als auf dem Server, auf dem die Sicherung vorgenommen wurde.

Allgemeine Parameter und Eigenschaften für Sicherungs- und Wiederherstellungsmethoden

  • Datei ist der Name der zu sichernden Datei (UNC-Name) in/aus.

  • Location gibt serverspezifische Sicherungsinformationen an, z. B . BackupFile. Dadurch können Sie eine separate Sicherungsdatei für eine Remotedatenbank angeben.

  • DatasourceID gibt die ID der untergeordneten Datenbank auf einem Remoteserver an.

  • Mit ConnectionString können Sie die Remotedatenquelle anpassen, falls sich der Remoteserver geändert hat. DatasourceID muss immer angegeben werden, wenn ConnectionString vorhanden ist.

  • Ordner ermöglicht das erneute Erstellen der Ordner für Partitionen auf der lokalen Festplatte.

  • Original ist der ursprüngliche Ordner für lokale Partitionen.

  • Neu ist der neue Speicherort für lokale Partitionen, die sich früher im entsprechenden alten Ordner "Original" befinden.

  • Wenn das Kennwort nicht leer ist, gibt es an, dass der Server die Sicherungsdatei verschlüsselt.

Ablaufverfolgungsobjekte

Die Ablaufverfolgung ist ein Framework, das zum Überwachen, Wiedergeben und Verwalten einer instance von Analysis Services verwendet wird. Eine Clientanwendung wie SQL Profiler abonniert eine Ablaufverfolgung, und der Server sendet Ablaufverfolgungsereignisse zurück, wie in der Ablaufverfolgungsdefinition angegeben.

Jedes Ereignis wird von einer Ereignisklasse beschrieben. Die Ereignisklasse beschreibt den Typ des generierten Ereignisses. Innerhalb einer Ereignisklasse beschreiben Ereignisunterklassen eine stärker differenzierte Kategorisierung. Jedes Ereignis wird von einer Anzahl an Spalten beschrieben. Die Spalten, die ein Ablaufverfolgungsereignis beschreiben, sind für alle Ereignisse konsistent und entsprechen der SQL-Ablaufverfolgungsstruktur. Die in den einzelnen Spalten enthaltenen Informationen können je nach Ereignisklasse variieren. Ein vordefinierter Satz Spalten ist also für jede Ablaufverfolgung definiert, die Bedeutung der Spalten kann sich jedoch abhängig von der Ereignisklasse ändern. Beispielsweise wird die TextData-Spalte dazu verwendet, die ursprüngliche ASSL für alle Anweisungsereignisse aufzuzeichnen.

Eine Ablaufverfolgungsdefinition kann eine oder mehrere Ereignisklassen enthalten, die gleichzeitig verfolgt werden sollen. Für jede Ereignisklasse kann mindestens eine Datenspalte zur Ablaufverfolgungsdefinition hinzugefügt werden. Jedoch müssen nicht alle Ablaufverfolgungsspalten verwendet werden. Der Datenbankadministrator kann entscheiden, welche der verfügbaren Spalten in eine Ablaufverfolgung einbezogen werden soll. Weiterhin können Ereignisklassen auf Grundlage von Filterkriterien in einer beliebigen Spalte in der Ablaufverfolgung selektiv verfolgt werden.

Ablaufverfolgungen können gestartet und gelöscht werden. Mehrere Ablaufverfolgungen können gleichzeitig ausgeführt werden. Ablaufverfolgungsereignisse können live aufgezeichnet oder an eine Datei weitergeleitet und später analysiert und wiedergegeben werden. SQL Profiler ist das Tool zum Analysieren und Wiedergeben von Ablaufverfolgungsereignissen. Mehrere Verbindungen dürfen Ereignisse von derselben Ablaufverfolgung empfangen.

Ablaufverfolgungen können in zwei Gruppen unterteilt werden: Serverablaufverfolgungen und Sitzungsablaufverfolgungen. Serverablaufverfolgungen bieten Informationen zu allen Ereignissen auf dem Server; Sitzungsablaufverfolgungen bieten nur Informationen zu Ereignissen in der aktuellen Sitzung.

Ablaufverfolgungen über die Auflistung der Ablaufverfolgungen auf dem Server werden folgendermaßen definiert:

  1. Erstellen Sie ein Trace Objekt, und füllen Sie die grundlegenden Daten auf, einschließlich Ablaufverfolgungs-ID, Name, Protokolldateiname, append|overwrite und andere.

  2. Fügen Sie der Events-Auflistung des Ablaufverfolgungsobjekts Ereignisse hinzu, die überwacht werden sollen. Für jedes Ereignis werden Datenspalten hinzugefügt.

  3. Legen Sie Filter fest, um unnötige Zeilen mit Daten auszuschließen, indem Sie diese zur Filterauflistung hinzufügen.

  4. Starten Sie die Ablaufverfolgung; durch das Erstellen der Ablaufverfolgung wird die Datensammlung nicht gestartet.

  5. Beenden Sie die Ablaufverfolgung.

  6. Überprüfen Sie die Ablaufverfolgungsdatei mit SQL Profiler.

Ablaufverfolgungen über das Sitzungsobjekt werden folgendermaßen abgerufen:

  1. Definieren Sie Funktionen, um die in der Anwendung mithilfe von SessionTrace generierten Ablaufverfolgungsereignisse zu handhaben. Mögliche Ereignisse sind OnEvent und Stopped.

  2. Fügen Sie dem Ereignishandler Ihre definierten Funktionen hinzu.

  3. Starten Sie die Ablaufverfolgung der Sitzung.

  4. Führen Sie Ihren Prozess aus, und lassen Sie die Funktionshandler die Ereignisse aufzeichnen.

  5. Beenden Sie die Ablaufverfolgung der Sitzung.

  6. Fahren Sie mit der Anwendung fort.

CaptureLog-Klasse und CaptureXML-Attribut

Alle Aktionen, die von AMO ausgeführt werden sollen, werden als XMLA-Nachrichten an den Server gesendet. AMO stellt die Mittel bereit, alle diese Nachrichten ohne die SOAP-Header aufzuzeichnen. Weitere Informationen finden Sie unter Einführung in AMO-Klassen. CaptureLog ist der Mechanismus in AMO, der für das Ausgeben von Objekten und Vorgängen verwendet wird. Für die Objekte und Vorgänge werden in XMLA Skripts erstellt.

Um mit der Erfassung des XML-Codes zu beginnen, muss die CaptureXML-Serverobjekteigenschaft auf true festgelegt werden. Anschließend werden alle Aktionen, die an den Server gesendet werden sollen, in der CaptureLog-Klasse aufgezeichnet, ohne dass die Aktionen an den Server gesendet werden. CaptureLog kann als Klasse betrachtet werden, da es eine Methode (Clear) aufweist, die zum Löschen des Aufzeichnungsprotokolls dient.

Um das Protokoll zu lesen, rufen Sie die Zeichenfolgenauflistung ab, und beginnen Sie mit dem Durchlaufen der Zeichenfolgen. Sie können auch alle Protokolle in einer Zeichenfolge verketten, indem Sie die Serverobjektmethode ConcatenateCaptureLog verwenden. ConcatenateCaptureLog weist drei Parameter auf, von denen zwei erforderlich sind. Die erforderlichen Parameter sind transaktional vom booleschen Typ und parallel vom booleschen Typ. Wenn transaktional auf true festgelegt ist, gibt dies an, dass die XML-Batchdatei als einzelne Transaktion erstellt wird, anstatt dass jeder Befehl als separate Transaktion behandelt wird. Wenn parallel auf TRUE festgelegt ist, gibt dies an, dass alle Befehle in der Batchdatei für die gleichzeitige Ausführung aufgezeichnet werden, anstatt sequenziell aufgezeichnet zu werden.

AMOException-Ausnahmeklasse

Sie können die AMOException-Ausnahmeklasse verwenden, um Ausnahmen in Ihrer Anwendung, die von AMO ausgegeben werden, einfach abzufangen.

AMO löst bei verschiedenen Problemen Ausnahmen aus. In der folgenden Tabelle wird die Art von Ausnahmen, die von AMO behandelt werden, aufgelistet. Ausnahmen werden von der AmoException -Klasse abgeleitet.

Ausnahme Origin BESCHREIBUNG
AmoException Basisklasse Die Anwendung empfängt diese Ausnahme, wenn ein erforderliches übergeordnetes Objekt fehlt oder wenn ein erforderliches Element nicht in einer Auflistung auffindbar ist.
OutOfSyncException Abgeleitet von AMOException Die Anwendung empfängt diese Ausnahme, wenn AMO nicht mit der Engine synchronisiert ist und die Engine einen Objektverweis zurückgibt, der AMO unbekannt ist.
OperationException Abgeleitet von AMOException Dies ist eine wichtige Ausnahme, die häufig von Anwendungen empfangen wird. Diese Ausnahme enthält die Details eines Fehlers, der vom Server stammt. Die Ursache ist wahrscheinlich ein fehlerhafter AMO-Vorgang wie Update oder Process oder Drop.
ResponseFormatException Abgeleitet von AMOException Diese Ausnahme tritt auf, wenn die Engine eine Meldung in einem Format zurückgibt, das AMO nicht versteht.
ConnectionException Abgeleitet von AMOException Diese Ausnahme tritt auf, wenn eine Verbindung nicht hergestellt werden kann (mit Server Connect) oder wenn die Verbindung getrennt wird, während AMO Daten mit der Engine austauscht (beispielsweise während eines Update-, Process- oder Drop-Vorgangs).