Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 12.0.0 (Deutsch) » SQL Anywhere Server - Datenbankadministration » Pflege der Datenbank » Aufgaben mit Zeitplänen und Ereignissen automatisieren

 

Systemereignisse verstehen

SQL Anywhere registriert mehrere Systemereignisse. Jedes Systemereignis stellt einen Startpunkt dar, der mit einer Serie von Maßnahmen verknüpft werden kann. Der Datenbankserver registriert die Ereignisse und führt die Maßnahmen aus (die für den Event-Handler vorher definiert wurden), wenn das Systemereignis eine gegebene Triggerbedingung erfüllt.

Weitere Hinweise zu Triggerbedingungen finden Sie unter Triggerbedingungen für Ereignisse definieren.

Sie legen fest, dass Event-Handler ausgeführt werden, wenn ein bestimmtes Systemereignis eintritt und einer vorher definierten Auslösebedingung entspricht. Damit können Sie die Sicherheit und den Schutz Ihrer Daten verbessern und die Verwaltung des Datenbanksystems vereinfachen. Die Aktionen eines Event-Handlers werden festgeschrieben, wenn während der Ausführung kein Fehler festgestellt wurde, und zurückgesetzt, falls Fehler ermittelt wurden.

Folgende Systemereignisse kommen dafür in Frage:

  • BackupEnd   Sie können den Ereignistyp BackupEnd benutzen, um Maßnahmen am Ende einer Sicherung zu ergreifen.

  • Verbindungsereignisse   Wenn eine Verbindung eingerichtet wird (Connect) oder fehlschlägt (ConnectFailed). Sie können diese Ereignisse für die Sicherheitsverwaltung benutzen. Als Alternative zu einem Connect-Event-Handler können Sie eine Login-Prozedur in Betracht ziehen. Weitere Hinweise finden Sie unter login_procedure-Option.

  • DatabaseStart   Sie können den Ereignistyp DatabaseStart benutzen, um Aktionen für den Datenbankstart festzulegen.

  • Deadlock   Sie können das Deadlock-Ereignis verwenden, um Aktionen durchzuführen, wenn ein Deadlock eintritt. Der Event-Handler kann mit der Prozedur sa_report_deadlock Informationen über die Bedingungen erhalten, die zum Deadlock geführt haben. Wenn Sie das Deadlock-Ereignis verwenden, sollten Sie den Datenbankserver dahingehend konfigurieren, dass er die Deadlock-Daten aufzeichnet, indem Sie die Option "log_deadlocks" auf ON setzen und die Funktion RememberLastStatement mit sa_server_option oder der Serveroption -zl aktivieren.

    Deadlock-Ereignisse werden bei Verbindungs-Deadlocks und Thread-Deadlocks ausgelöst. Ein Deadlock-Ereignis liefert nur die Informationen, die über die Systemprozedur sa_report_deadlocks verfügbar gemacht werden. Die Verwendung dieses Ereignisses ermöglicht es Ihnen allerdings, auf einen Deadlock rechtzeitig zu reagieren. Eine schnelle Reaktion kann wichtig sein, da die Menge an Deadlocks betreffender Informationen, die der Datenbankserver aufrecht erhält, beschränkt ist. Weitere Hinweise finden Sie unter:

  • Disconnect   Sie können das Ereignis Disconnect benutzen, um eine Aktion einzuleiten, wenn ein Benutzer oder eine Anwendung eine Verbindung trennt.

  • Freier Festplattenspeicher   Damit wird der freie Speicherplatz auf dem Speichermedium registriert, auf dem sich die Datenbankdatei (DBDiskSpace), die Logdatei (LogDiskSpace) oder die Temporärdatei (TempDiskSpace) befinden. Dieses Systemereignis steht unter Windows Mobile nicht zur Verfügung.

    Sie können Festplattenereignisse benutzen, um den Systemadministrator zu verständigen, wenn der Speicherplatz knapp wird.

    Sie können die Option -fc beim Starten des Datenbankservers angeben, um eine Callback-Funktion zu implementieren, wenn der Datenbankserver Speichermangel im Dateisystem feststellt. Weitere Hinweise finden Sie unter --fc - dbeng12/dbsrv12-Serveroption.

  • Dateigröße   Die Datei erreicht eine vorher festgelegte Größe. Dies kann für die Datenbankdatei (GrowDB), das Transaktionslog (GrowLog) oder die Temporärdatei (GrowTemp) benutzt werden.

    Sie können Dateigrößenereignisse benutzen, um ungewöhnliche Aktionen in der Datenbank zu registrieren oder Massenvorgänge zu überwachen.

  • GlobalAutoincrement   Wenn die Anzahl der verbleibenden Werte für eine mit GLOBAL AUTOINCREMENT definierte Spalte niedriger ist als ein Prozent des festgelegten Bereiches, wird das Ereignis GlobalAutoIncrement ausgelöst. Eine typische Aktion für den Handler könnte darin bestehen, einen neuen Wert für die Option global_database_id auf der Grundlage der Tabelle und der Anzahl der restlichen Werte anzufordern, die als Parameter für dieses Ereignis übergeben wurden. Um die restlichen Werte für die Tabelle im Ereignis zu beziehen, verwenden Sie die Funktion EVENT_PARAMETER mit den Parametern RemainingValues und TableName. RemainingValues gibt die Anzahl der restlichen Werte zurück, die bei der Spalte generiert werden können, und TableName gibt die Tabelle zurück, die die Spalte GLOBAL AUTOINCREMENT enthält, bei der der Bereich beinahe ausgeschöpft ist. Weitere Hinweise finden Sie unter EVENT_PARAMETER-Funktion [System].

  • RAISERROR-Fehler   Wenn eine RAISERROR-Anweisung ausgeführt wird, können Sie den Ereignistyp RAISERROR benutzen, um Maßnahmen einzuleiten. Die in der RAISERROR-Anweisung verwendete Fehlernummer kann innerhalb des Event-Handlers ermittelt werden, indem Sie die Funktion EVENT_CONDITION verwenden (z.B. EVENT_CONDITION( 'ErrorNumber' )).

  • Leerlaufzeit   Der Datenbankserver wurde eine Zeit lang nicht benutzt (ServerIdle). Sie können diesen Ereignistyp verwenden, um Routine-Wartungsvorgänge in Ruhezeiten auszuführen.

  • Datenbankspiegelung   Wenn die Verbindung vom Primärserver zu einem Spiegel- oder Arbiterserver getrennt wird, wird das Ereignis MirrorServerDisconnect ausgelöst. Um den Namen des Servers zu erhalten, dessen Verbindung getrennt wurde, verwenden Sie die Funktion EVENT_PARAMETER mit dem Parameter MirrorServerName. Weitere Hinweise finden Sie unter EVENT_PARAMETER-Funktion [System].

    Das Ereignis MirrorFailover wird ausgelöst, wenn ein Server Eigentümer der Datenbank wird. Es wird z.B. ausgelöst, wenn ein Server erstmals startet und bestimmt, dass er der Eigentümer der Datenbank sein soll. Es wird auch ausgelöst, wenn ein Server, der bisher als Spiegelserver gedient hat, feststellt, dass der Primärserver ausgefallen ist, und nach Beratungen mit dem Arbiterserver bestimmt, dass er Eigentümer werden soll.

    Ereignisse werden nicht auf einem Server ausgelöst, der derzeit als Spiegelserver agiert, da seine Kopie der Datenbank weiterhin gestartet wird. Überdies können Spiegelungsereignisse nicht für die Ausführung auf einem Arbiterserver definiert werden, da Ereignisse nur im Kontext der Datenbank ablaufen, in der sie definiert wurden, und der Arbiterserver keine Kopie der gespiegelten Datenbank verwendet. Weitere Hinweise finden Sie unter Systemereignisse bei der Datenbankspiegelung.


Triggerbedingungen für Ereignisse definieren