<< | IBExpert | >>

Die deutschsprachige Dokumentation wird seit dem 26. Juli 2016 nicht mehr gepflegt. Aktuelle und vollständige Dokumentation finden Sie auf der englischsprachigen Webseite: IBExpert Documentation

Systemobjekte RDB$, MON$, IBE$

Firebird/InterBase^® und IBExpert erzeugen Systemdatenbankobjekte und speichern ihre eigenen spezifischen Systeminformationen über Datenbankobjekte in Systemtabellen. Systemobjekte werden im DB Explorer rot dargestellt, wenn die Systemoptionen im Datenbank registrieren-Dialog (aufgerufen per Rechtsklick Zusatzeinstellungen/DB Explorer).

Firebird Systemobjekte enthalten den Präfix RDB$ und Firebird Überwachungstabellen enthalten den Präfix MON$; IBExpert Systemobjekte enthalten den Präfix IBE$.

Eine neu erzeugte Datenbank ist fast 0,5 MB groß. Dies ist wegen der, von Firebird/InterBase^® bei der Erzeugung einer Datenbank automatisch erzeugten Systemtabellen.

Diese Systemtabellen beinhalten einen Reichtum an Information, die von vielen der IBExpert Funktionalitäten benutzt wird. Sie können gern die Information in diesen Systemobjekten ansehen und studieren, aber bitte führen Sie keine Änderungen an die enthaltenen Daten, da es ohne Zweifel zu einer korrupten Datenbank führen wird!

zurück zum Seitenanfang

RDB$ Systemobjekte

RDB$-Objekte gehören zu Firebird und InterBase^®. Alle Feldnamen in diesen Tabellen fangen zur einfachen Identifikation auch mit RDB$ an. Sie beinhalten folgende Tabellen:

Datenbankbezogene Systemtabellen

• RDB$DATABASE: die meisten Systemtabellen sehen eine Beschreibungs-Spalte vor, als Unterstützung der Datenbankdokumentation. Die Datenbankbeschreibung kann im SQL Assistent auf der Beschreibung-Seite spezifiziert und angezeigt werden. Die Datenbankbeschreibung wird auch in der Generiere HTML Dokumentation einbezogen, sofern die Option, Beschreibungen aufnehmen ..., aktiviert ist. Diese Tabelle beinhaltet auch eine RDB$CHARACTER_SET_NAME-Spalte, die den Standardzeichensatz anzeigt.
• RDB$FILE: verwaltet alle Sekundärdateien und Datenbank Shadow Dateien, wenn sie vorhanden sind. Die RDB$FILE_SEQUENCE-Spalte beinhaltet eine SMALLINT-Nummer, die die Dateireihenfolge bestimmt. Maximal 65535 Sekundär- und Shadow-Datenbankdateien sind erlaubt.
• RDB$PAGES: verwaltet die Datenbankseiten. RDB$RELATION_ID zeigt auf die entsprechende Tabelle und RDB$PAGE_TYPE zeigt an, ob sie eine Daten- oder Index-Seite ist.

RDB$DEPENDENCIES: zeigt die Abhängigkeiten zwischen Tabellen, Ansichten und Constraints (Beschränkungen).

zurück zum Seitenanfang

Tabellen- und View-bezogene Systemtabellen

• RB$RELATIONS: alle Tabellen und Views werden hier gespeichert. Viewdefinitionen sind im RDB$VIEW_SOURCE gespeichert; die binäre Definition in RDB$VIEW_BLR. Systemtabellen sind mit einer 1 in der RDB$SYSTEM_FLAG-Spalte beflaggt, Nutzertabellen mit 0. Sollte die Tabelle eine externe Datei sein, befindet sich sein Name in der RDB$EXTERNAL_FILE-Spalte. Der Tabelleneigentumer ist im RDB$OWNER_NAME-Feld genannt.
• RDB$RELATION_FIELDS: speichert die Spaltendefinitionen der einzelnen Tabellen. Die Reihenfolge, wie die Spalten bei einer SELECT *-Anweisung erscheinen, wird durch den Wert der Spalte RDB$FIELD_POSITION spezifiziert, wobei die Spalte mit dem Wert null als Erste erscheint. Jede Tabellenspalte basiert auf einer Domäne, die in RDB$FIELD_SOURCE angezeigt wird. Ist eine Spalte als NOT NULL definiert, dann erhält RDB$NULL_FLAG den Wert eins. Eine abweichende Sortierreihenfolge findet man in der Spalte RDB$COLLATION_ID. Zwei neue Spalten wurden in Firebird 3.0 für die Unterstützung von Identity-Spalten hinzugefügt: RDB$GENERATOR_NAME und RDB$IDENTITY_TYPE. Weitere Information finden Sie unter IDENTITY data type.
• RDB$RELATION_CONSTRAINTS: Gültigkeitsprüfungen im weitesten Sinne finden sich in dieser Tabelle. Den Namen der Gültigkeitsprüfung finden Sie in RDB$CONSTRAINT_NAME, den der dazugehörenden Tabelle in RDB$RELATION_NAME. Für RDB$CONSTRAINT_TYPE sind die folgenden Werte vorgesehen:
  • PRIMARY für Primärschlüssel
  • UNIQUE für Sekundärschlüssel
  • FOREIGN KEY für Fremdschlüssel
  • PCHECK für selbst definierte Gültigkeitsprüfungen und
  • NOT NULL für zwingende Eingabe.

• RDB$INDICES: hier können Sie die Index-Namen (RDB$INDEX_NAME) und die Tabellen-Namen (RDB$RELATION_NAME) finden. Die zu einer Tabelle gehörenden Indizes werden in der Spalte RDB$INDEX_ID jeweils mit eins beginnend durchnummeriert. Handelt es sich um einen eindeutigen Index, dann hat RDB$UNIQUE_FLAG den Wert eins, RDB$INDEX_TYPE spezifiziert, ob es sich um einen aufsteigenden (0) oder absteigenden (1) Index handelt, und RDB$INDEX_INACTIVE zeigt inaktive Indizes mit dem Wert 1 an. Indexselektivität wird in der the RDB$STATISTICS-Spalte gespeichert.
• RDB$INDEX_SEGMENTS: diese Tabelle speichert die Spalten, welche den Index bilden. Die Reihenfolge der einzelnen Spalte ergibt sich aus RDB$FIELD_POSITION.
• RDB$REF_CONSTRAINTS: diese Tabelle speichert, wie Schlüsselverletzungen zu behandeln sind. Der Fremdschlüsselname findet man in RDB$CONSTRAINT_NAME, den des dazugehörenden Primär- oder Sekundärschlüssels in RDB$CONST_NAME_UQ. Die Spezifikation der Behandlung solcher Schlüsselverletzungen kann getrennt eingestellt werden für UPDATE und DELETE-Fälle, und können in RDB$UPDATE_RULE und RDB$DELETE_RULEeingesehen werden. Vorgesehen dafür sind der Vorgabewert RESTRICT sowie die Alternativen NO ACTION, CASCADE, SET NULL and SET DEFAULT.
• RDB$CHECK_CONSTRAINTS: Gültigkeitsprüfungen werden hier gespeichert. Gültigkeitsprüfungen werden über Trigger realisiert, der Triggername steht in RDB$TRIGGER_NAME, und der Name der Gültigkeitsprüfung in RDB$CONSTRAINT_NAME. Wenn in RDB$TRIGGER_NAME der Name einer Spalte statt eines Triggers steht, dann handelt es sich um eine NOT NULL-Prüfung, diese werden auch in dieser Tabelle gespeichert.
• RDB$VIEW_RELATIONS: diese Systemtabelle speichert alle einem View gehörenden Tabellen. Die einzelnen Tabellen werden mit RDB$VIEW_CONTEXT durchnummeriert. Wird ein Tabellen-Alias verwendet, dann steht dieser in RDB$CONTEXT_NAME.

zurück zum Seitenanfang

Domänenbezogene Systemtabellen

• RDB$FIELDS: hier finden Sie die Definition aller Domänen, einschließlich Datentyp, size, Zeichensatz and Sortierung. Handelt es sich um eine berechnete Spalte, dann finden Sie die dazugehörende SQL-Anweisung in RDB$COMPUTED_SOURCE.
• RDB$TYPES: diese Tabelle speichert Daten- und Objekttypen (VIEW, TRIGGER, PROCEDURE), Zeichensätze und einige andere Informationen.
• RDB$FIELD_DIMENSIONS: diese Systemtabelle speichert Array-Definitionen.
• RDB$CHARACTER_SETS: hier finden Sie eine vollständige Liste aller Zeichensätze in Ihrer Firebird/InterBase^®-Version.
• RDB$COLLATIONS: diese Tabelle enthält eine Liste aller verfügbaren Sortierungen für die Zeichensatz-IDs, die in RDB$CHARACTER_SETS vorhanden sind.

Prozeduren- und triggerbezogene Systemtabellen

• RDB$PROCEDURES: Alle Stored Procedures in einer Datenbank werden in dieser Systemtabelle gespeichert. Den Prozedurnamen findet man in RDB$PROCEDURE_NAME mit einer durchlaufenden Identifikationsnummer in RDB$PROCEDURE_ID. Die Zahl der an die Prozedur übergebenen Parameter steht in RDB$PROCEDURE_INPUTS, die von den Prozedur zurückgegebenen Werte stehen in RDB$PROCEDURE_OUTPUTS. Der Quellcode wird in RDB$PROCEDURE_SOURCE gespeichert, und seine binäre Übersetzung in RDB$PROCEDURE_BLR. Nur der Besitzer einer Prozedur (in RDB$OWNER_NAME gespeichert) und der SYSDBA dürfen die Rechte an einer Prozedur vergeben. Das Feld, RDB$PACKAGE_NAME, wurde in Firebird 3.0 hinzugefügt, um Packages-Metadaten zu speichern.
• RDB$PROCEDURE_PARAMETERS: diese Tabelle speichert Information über die einzelnen Parameter, und in welchen Prozedur sie verwendet werden. Die einzelnen Parameter werden mit 0 beginnend durchnummeriert. Hat RDB$PARAMETER_TYPE den Wert 0, handelt es sich um einen Eingabeparameter, ein Ausgabeparameter ist durch den Wert eins gekennzeichnet. Dieses Feld referenziert auch die Tabelle RDB$FIELDS.
• RDB$TRIGGERS: diese Tabelle beinhaltet eine Liste aller in der Datenbank befindlichen Trigger. Neben dem Triggernamen finden Sie in RDB$RELATION_NAME den Namen der dazugehörenden Tabelle, den Triggertyp (RDB$TRIGGER_TYPE) und, wenn mehrere Trigger für eine einzelne Tabelle denselben Wert für RDB$TRIGGER_TYPE haben, dann entscheidet RDB$TRIGGER_SEQUENCE über die Reihenfolge der Ausführung, beginnend mit dem niedrigsten Wert. Bei Gleichheit auch in dieser Spalte entscheidet die alphabetische Reihenfolge des Triggernamens. Der Trigger Quelltext steht in RDB$TRIGGER_SOURCE und in RDB$TRIGGER_BLR seine binäre Übersetzung. Deactivierte Trigger werden mit 1 in der RDB$TRIGGER_INACTIVE-Spalte beflaggt.
• RDB$PACKAGES: Für die Speicherung der Package-Metadaten ist in Firebird 3.0 eine neue Systemtabelle RDB$PACKAGES hinzugekommen.

zurück zum Seitenanfang

Userrechtbezogene Systemtabellen

• RDB$ROLES: diese Tabelle beinhaltet die für die Datenbank definierten Role-Namen und die Benutzer, die diese Rollen definierten.
• RDB$PRIVILEGES: diese Tabelle speichert die Userrechte und wer sie vergeben hat. Das RDB$PRIVILEGE-Feld zeigt an, um welches Recht es sich handelt: S (Select), I (Insert), U (Update), D (Delete), R (Reference), X (Execute). Steht in RDB$GRANT_OPTION der Wert 1, dann darf dieses Recht weitergegeben werden. In RDB$RELATION_NAME ist angegeben, auf welche Tabelle oder welche Prozedur sich das Recht bezieht, ist es auf eine bestimmte Spalte beschränkt, dann wird diese in RDB$FIELD_NAME spezifiziert.

Andere Systemtabellen

• RDB$EXCEPTIONS: beinhaltet eine vollständige Liste aller exceptions.
• RDB$FILTERS: beinhaltet alle blob filters. Die Routine wird mit RDB$ENTRYPOINT spezifiziert, der DLL Dateiname mit RDB$MODULE_NAME.
• RDB$FUNCTIONS: beinhaltet alle eingebundenen UDFs in der Datenbank. Die Routine wird mit RDB$ENTRYPOINT spezifiziert, der DLL Dateiname mit RDB$MODULE_NAME. RDB$RETURN_ARGUMENT spezifizert, welcher der Parameter der Rückgabewert ist.
• RDB$FUNCTION_ARGUMENTS: Diese Tabelle listet die einzelnen UDF Parameter auf. Die Parameter sind mit RDB$ARGUMENT_POSITION durchnummeriert, die Parametertypen sind in RDB$FIELD_TYPE angezeigt, diese Spalte referenziert die Tabelle, RDB$TYPES. Steht in RDB$MECHANISM der Wert 0, dann wird der Parameter by value übergeben, bei einer 1, by reference. Insbesondere bei Strings interessant ist die Länge, die in RDB$FIELD_LENGTH angegeben ist. RDB$CHARACTER_SET_ID speichert den Zeichensatz.
• RDB$GENERATORS: diese Tabelle speichert den Generator-Namen und eine eindeutige Nummer. Der Generatorwert wird nicht in der Systemtabelle gespeichert.
• RDB$TRANSACTIONS: diese Systemtabelle speichert Transkationen, die über mehrere Datenbanken erstellt werden. Bei 0 in die Transaktion in limbo, also noch nicht abgeschlossen, bei 1 mit COMMIT und bei 2 mit ROLLBACK beendet.

Siehe auch:
englischsprachig:
The mystery of RDB$DB_KEY

zurück zum Seitenanfang

MON$ Systemtabellen

Firebird Überwachungstabellen wurden in Firebird 2.1. eingeführt und ermöglichen die Überwachung von Momentaufnahmen in einer laufenden Datenbank (von Transaktionen, Tabellen, etc.) via SQL über einige neue virtualisierte Systemtabellen.

Durch Abfrage dieser Systemtabellen bekommen Sie eine Momentaufnahme der laufenden Aktivitäten in Ihrer Datenbank. Beispielsweise bietet MON$DATABASE viele Datenbankkopfinformationen, die vorher nicht via SQL erhalten werden konnten: solche Details, wie die On-Disk-Struktur (ODS)-Version, SQL Dialekt, Sweep-Interval, OIT und OAT usw.

Sie können andere Aktivitäten, wie wer mit Ihrer Datenbank verbunden ist, welche Transaktionen und Anweisungen laufen gerade usw. ebenfalls einsehen. Sie können sogar eine laufende Abfrage durch die Ausführung einer DELETE-Anweisung in MON$STATEMENTS stornieren.

Wenn Sie die Überwachungstabellen abfragen, ist es wichtig, zu bedenken, dass es sich nur um eine Momentaufnahme handelt.

Firebird 2.1 beinhaltet folgende MON$ Systemtabellen:

• MON$DATABASE: verbundene Datenbank..
• MON$ATTACHMENTS: verbundene Clients.
• MON$TRANSACTIONS: angefangen Transaktionen.
• MON$STATEMENTS: vorbereitete Anweisungen.
• MON$CALL_STACK: Aufrufstapel aktiver PSQL Abfragen.
• MON$IO_STATS: I/O Statistik.
• MON$RECORD_STATS: Rekordebene Statistik.

Weitere Details finden Sie in den Firebird 2.1 Release Notes Kapitel Administrative features, und in den Firebird 2.5 Release Notes.

Folgende Verbesserungen wurde in Firebird 2.5 aufgenommen:

• MON$CONTEXT_VARIABLES: liefert Daten über Kontextvariablen (beinhaltet einen Überblick über alle mit RDB$SET_CONTEXT gesetzten benutzerdefinierten Kontextvariablen).
• MON$MEMORY_USAGE: enthält aktuelle Speichernutzung auf Datenbank-, Session-, Transaktions- bzw. Anweisungsebene in ODS 11.2 und höheren Datenbanken liefert. In diesen Datenbanken ist es auch möglich, eine Klientverbindung von einer anderen Verbindung über die MON$-Strukturen zu trennen.
• Die ursprüngliche Konfiguration in Firebird 2.1 erlaubte nicht-privilegierte Datenbankbenutzer nur Information über ihre CURRENT_CONNECTION zu sehen. In Firebird 2.5 können sie Information für alle Verbindungen, die mit demselben Usernamen authentifiziert sind, abfragen.
• Neue MON$ Metadaten für ODS 11.2 Datenbanken.
• Eine Klientverbindung beenden: die MON$-Strukturen sind schreibgeschützt. Also sind Benutzer DML-Operationen verboten. Jedoch ist ein Mechanismus eingebaut, der das Löschen von Datensätzen in den MON$STATEMENTS- und MON$ATTACHMENTS-Tabellen erlaubt. Dies hat die Auswirkung, laufende Anweisungen abzubrechen und – für ODS 11.2 Datenbanken – Clientsessions zu beenden.

zurück zum Seitenanfang

IBE$ Systemobjekte

IBExpert erzeugt eigene Systemobjekte für Features wie Logging und Versionshistorie:

Diese Objekte sollten in keiner Art und Weise geändert werden, sonst werden bestimmte IBExpert Funktionalitäten beeinträchtigt.

IBE$VERSION_HISTORY Systemtabelle

Für die Tabelle IBE$VERSION_HISTORY wurde ein spezieller Browser implementiert. Wenn IBE$VERSION_HISTORY im Tabelleneditor geöffnet wird, wird automatisch eine neue Version Browser-Seite geöffnet:

Wählen Sie das Datenbankobjekt und die Versionen, die Sie vergleichen möchten. Text und Code sind je nachdem, ob Sie hinzugefügt, modifiziert oder gelöscht wurden, farbig markiert.

Existiert die IBE$VERSION_HISTORY-Tabelle bereits in Ihrer Datenbank, fügen Sie folgende Änderungen manuell hinzu, wenn Sie die Clientadresse loggen möchten und die RDB$GET_CONTEXT-Funktion verfügbar ist:

Neues Feld in die IBE$VERSION_HISTORY-Tabelle einfügen:

     ALTER TABLE IBE$VERSION_HISTORY ADD IBE$VH_CLIENT_ADDRESS VARCHAR(32) CHARACTER 
     SET NONE;

Zusätzliche Code-Zeile in den IBE$VERSION_HISTORY_BI Trigger einfügen:

     NEW.IBE$VH_CLIENT_ADDRESS = RDB$GET_CONTEXT('SYSTEM', 'CLIENT_ADDRESS'); 

Siehe auch:
deutschsprachig:
Versionshistorie

IBE$DBINSIDE$ERRORS Systemtabelle

Diese Tabelle wird automatisch von IBExpert erzeugt, wenn Sie die Extract data/metadata Funktion auf einer korrupte Datenbank in Database Inside durchführen.

zurück zum Seitenanfang
<< | IBExpert | >>