Andere AMO-Klassen und Methoden

Dieser Abschnitt enthält gängige Klassen, die nicht OLAP- oder Data Mining-spezifisch sind und die bei der Verwaltung von Objekten in Microsoft SQL Server Analysis Services hilfreich sein können. Diese Klassen decken Funktionen wie gespeicherte Prozeduren, Ablaufverfolgung, Ausnahmen sowie Sicherung und Wiederherstellung ab.

Dieses Thema enthält folgende Abschnitte:

• Assemblyobjekte

• Backup- und Restore-Methoden

• Ablaufverfolgung von Objekten

• CaptureLog-Klasse und CaptureXML-Attribut

• AMOException-Ausnahmeklasse

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

Assemblyobjekte

Ein Assembly-Objekt wird erstellt, indem es der Auflistung der Assemblys auf dem Server hinzugefügt und anschließend das Assembly-Objekt auf dem Server mithilfe der Update-Methode aktualisiert wird.

Um ein Assembly-Objekt zu entfernen, muss es mithilfe der Drop-Methode des Assembly-Objekts gelöscht werden. Durch das Entfernen eines Assembly-Objekts aus der Auflistung der Assemblys der Datenbank wird die Assembly nicht gelöscht. Allerdings können Sie die Assembly erst wieder in Ihrer Anwendung anzeigen, wenn Sie diese das nächste Mal ausführen.

Weitere Informationen zu den verfügbaren Methoden und Eigenschaften finden Sie unter Microsoft.AnalysisServices..::..Assembly in Microsoft.AnalysisServices.

Sicherheitshinweis
COM-Assemblys können ein Sicherheitsrisiko darstellen. Aufgrund dieses Risikos und anderer Überlegungen wurden COM-Assemblys in SQL Server 2008 Analysis Services (SSAS) als veraltet markiert. COM-Assemblys werden in zukünftigen Versionen möglicherweise nicht mehr unterstützt.

Backup- und Restore-Methoden

Die Methoden Backup und Restore sind Methoden, mit denen Sie Kopien einer Analysis Services-Datenbank erstellen können, mit deren Hilfe diese Datenbank wiederhergestellt werden kann. Die Backup-Methode gehört zum Database-Objekt, und die Restore-Methode gehört 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.

Backup-Methode

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

Restore-Methode

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

Einschrä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 die Backup- und Restore-Methoden

• File ist der Name der Datei (UNC-Name), in die/aus der die Sicherung vorgenommen werden soll.

• Location gibt serverspezifische Sicherungsinformationen wie BackupFile an. Das gestattet Ihnen, eine separate Sicherungsdatei für eine Remotedatenbank anzugeben.

• 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.

• Folder ermöglicht die Neuzuordnung der Ordner für Partitionen auf der lokalen Festplatte.

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

• New ist der neue Speicherort für lokale Partitionen, die sich zuvor im entsprechenden Ordner Original befanden.

• Password gibt an, dass der Server die Sicherungsdatei verschlüsselt (sofern ein bestimmter Wert festgelegt ist).

Ablaufverfolgung von Objekten

Die Ablaufverfolgung ist ein für die Überwachung, Wiedergabe und Verwaltung einer Instanz von Analysis Services verwendetes Framework. Eine Clientanwendung wie SQL Server Profiler abonniert eine Ablaufverfolgung, und der Server sendet Ablaufverfolgungsereignisse gemäß Ablaufverfolgungsdefinition zurück.

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 erfasst oder an eine andere Datei zur späteren Analyse oder Wiedergabe weitergeleitet werden. SQL Server Profiler ist das Tool, das für die Analyse und Wiedergabe von Analysis Services-Ablaufverfolgungsereignissen verwendet wird. Mehrere Verbindungen können Ereignisse aus derselben Ablaufverfolgung erhalten.

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 seine grundlegenden Daten aus, einschließlich Ablaufverfolgungs-ID, Name, Name der Protokolldatei, Anfügen/Überschreiben 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 Server 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.

Damit Sie mit dem Aufzeichnen der XML-Elemente beginnen können, 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 transactional des booleschen Typs und parallel des booleschen Typs. Wenn transactional auf den Wert true festgelegt ist, zeigt dies an, dass die XML-Batchdatei als einzelne Transaktion erstellt wird und nicht jeder Befehl als separate Transaktion behandelt wird. Wenn parallel auf den Wert true festgelegt ist, zeigt dies an, dass alle Befehle in der Batchdatei für die gleichzeitige Ausführung und nicht sequenziell aufgezeichnet 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 AmoException abgeleitet.

Ausnahme	Ursprung	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 dem Modul synchronisiert ist und das Modul 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 das Modul 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 dem Modul austauscht (beispielsweise während eines Update-, Process- oder Drop-Vorgangs).

Siehe auch

Verweis

Microsoft.AnalysisServices

Konzepte

Einführung in AMO-Klassen

Logische Architektur (Analysis Services - Mehrdimensionale Daten)

Datenbankobjekte (Analysis Services - Mehrdimensionale Daten)