Statistische Systemtabellen
Statistische Systemtabellen befinden sich im Schema EXA_STATISTICS und liefern
- aktuelle Informationen über den letzten Tag (*_LAST_DAY)
- oder aggregierte Daten auf Stunden-, Tages- und Monatsbasis (*_HOURLY, *_DAILY, *_MONTHLY)
Datenbankgröße: EXA_DB_SIZE_*
Die Tabellen EXA_DB_SIZE_* liefern verschiedene Kennzahlen, die das Volumen der Datenbank wiedergeben. Mit Hilfe dieser Tabellen können Sie Ihr Datenwachstum beobachten und ggf. vorhersagen. Die Tabellen enthalten folgende Spalten:
RAW_OBJECT_SIZE gibt die logische Datenbankgröße, bemessen an Datentypen und Inhalten an. Diese Größe ist vergleichbar mit der Größe einer CSV-Datei mit gleichem Inhalt. Der Wert wird berechnet als Summe über alle gespeicherten Werte. Dabei ergeben
- NULL –› 1 Byte
- Typ fester Größe: Typabhängig –› 1-80000 Bytes
- Varchar –› Anzahl Bytes die der Wert belegt.
Es werden alle Tabellen berücksichtigt.
MEM_OBJECT_SIZE gibt die tatsächliche Menge an (Haupt-) Speicher ab, die für die Datenbankobjekte verbraucht wird. Der Wert wird berechnet als
- Summe über alle gespeicherten Werte nach Kompression
- Overhead für Zugriffsstrukturen, z.B. Längeninformation für VARCHAR
- Overhead für Replikation
Replikation: Tabelleninhalte werden auf jedem Knoten im Speicher gehalten. Dies betrifft lediglich kleine Tabellen (< 100.000 Zeilen).
MEM_OBJECT_SIZE von sehr kleinen Tabellen kann größer als RAW_OBJECT_SIZE sein.
AUXILIARY_SIZE gibt die tatsächliche Speichergröße zusätzlicher Strukturen wie z.B. Indizes an.
RECOMMENDED_DB_RAM_SIZE gibt die vom System errechnete optimale Lizenzgöße an. Die Berechnung basiert auf der Menge der Festplattenzugriffe im Vergleich zur Datenmenge, die verarbeitet wird. Der Wert ist daher dann sinnvoll nutzbar, wenn die aktuelle Speichergröße (= Lizenzgröße) nicht ausreichend ist. Passen die Daten komplett in den Hauptspeicher, ist es nicht möglich festzustellen, wie viel Hauptspeicher tatsächlich benötigt wird. In diesem Fall wird die aktuelle Lizenzgröße angezeigt.
DB_FILE_SIZE gibt die Gesamtgröße der Datenbankdateien an.
MAX_USE zeigt den tatsächlich mit Daten belegten Anteil der Dateien in %.
Ausgeführte SQL-Befehle: EXA_SQL_*
Jede Zeile dieser Tabelle entspricht einem ausgeführten (beendetem) SQL-Befehl.
In der EXA_SQL Tabelle werden NICHT die vollständigen SQL-Texte gespeichert. Diese Tabelle kann nicht für Auditing-Zwecke verwendet werden. Stattdessen wird hier nur der Typ z.B. SELECT oder GRANT OBJECT gespeichert. Alle Kommandos werden in Gruppen aufgeteilt (
- DML: Data Modification Language
- DQL: Data Querying Language
- DCL: Data Control Language
- DDL: Data Definition Language
- Transaction: Commit und Rollback
- Other
Darüber hinaus werden für jeden SQL-Befehl folgende Informationen gespeichert:
- SESSION_ID
- STMT_ID: Eindeutige Statementnummer innerhalb der Session
- START_TIME: Startzeitpunkt des Kommandos
- STOP_TIME: Endzeitpunkt des Kommandos
- COMMAND_NAME
z.B. SELECT, INSERT oder COMMIT - SUCCESS (true oder false)
- MEM_PEAK (MiB): Maximale Heap-Speicherverbrauch. Dieser Wert ist ein wichtiger Parameter für das EXASolution Ressourcenmanagement und gibt Indikationen zur Queryoptimierung. Der Wert wird im Rahmen eines Knotens gemessen.
- TEMP_DB_RAM_PEAK (MiB): Maximaler Datenbankspeicherverbrauch im gesamten Cluster.
Aggregierte Tabellen enthalten neben maximalen und durchschnittlichen Werten für Speicherverbrauch auch Anzahl Queries im Messzeitraum, sowie eine durchschnittliche und maximale Dauer der Statementausführung. Aggregiert wird auf einen entsprechenden Interval und folgende Spalten:
- COMMAND_NAME,
- COMMAND_CLASS,
- SUCCESS
Beispiel 1: Datenvolumen vs. Anzahl Queries
-
- SELECT
- TO_CHAR(s.interval_start, 'IYYY-IW') AS "Week",
- AVG(RAW_OBJECT_SIZE_AVG) AS "Raw data",
- AVG(MEM_OBJECT_SIZE_AVG) AS "Compressed data",
- SUM(COUNT) AS "SQL Count"
- FROM EXA_SQL_DAILY s, EXA_DB_SIZE_DAILY d
- WHERE
- s.INTERVAL_START = d.INTERVAL_START
- GROUP BY TO_CHAR(s.interval_start, 'IYYY-IW')
- ORDER BY "Week";
Beispiel 2: Taglicher Hauptspeicherverbrauch
-
- SELECT RECOMMENDED_DB_RAM_SIZE_AVG, RECOMMENDED_DB_RAM_SIZE_MAX FROM EXA_DB_SIZE_DAILY;
Nutzerverhalten: EXA_USAGE_*
Die Tabellengruppe “EXA_USAGE_*” zeigt das konkurrierende Nutzerverhalten: die Anzahl der konkurrierenden Nutzer und Queries.
EXA_USAGE_LAST_DAY wird aktualisiert wenn ein Nutzer sich ein- oder ausloggt oder wenn eine Query gestartet oder beendet wird. Das System notiert zu jedem solchen Zeitpunkt (MEASURE_TIME) wie viele Nutzer im System eingeloggt sind (Spalte USERS) und wie viele Queries (Spalte QUERIES) gerade laufen.
Anschließend werden diese Daten nach Stunden, Tagen und Monaten aggregiert.
Beispiel 3: Konkurrierende Queries vs. Ausführungszeiten im Tagesverlauf
-
- SELECT
- TRUNC(s.INTERVAL_START, 'MM') "Month"
- , EXTRACT(HOUR FROM s.INTERVAL_START) "Time of day"
- , MAX(u.QUERIES_MAX) "MAX concurrent queries"
- , AVG(u.QUERIES_AVG) "AVG concurrent queries"
- , AVG(s.DURATION_AVG) "AVG execution time"
- FROM EXA_USAGE_HOURLY u, EXA_SQL_HOURLY s
- WHERE u.INTERVAL_START = s.INTERVAL_START
- GROUP BY TRUNC(s.INTERVAL_START, 'MM'), EXTRACT(HOUR FROM s.INTERVAL_START)
- ORDER BY 1,2;
Systemevents: EXA_SYSTEM_EVENTS
Jedes Mal wenn das System gestartet oder gestoppt wird, ensteht ein Eintrag in der Tabelle EXA_SYSTEM_EVENTS. Das System unterscheidet zwischen folgenden Eventtypen (Spalte EVENT_TYPE)
- STARTUP: DBMS wurde gestartet
- SHUTDOWN: DBMS wurde gestoppt.
Die Zeit bis zum nächsten Startup wird als "Wartung" betrachtet, da der Shutdown manuell durchgeführt werden muss. - RESTART: DBMS wurde restartet i.d.R. auf Grund eines Fehlers.
Die Zeit bis zum nächsten Startup wird als "Nicht Verfügbar" betrachtet. - FAILSAFETY: Nach einem Knotenausfall war es möglich, die Datenbank neu zu starten und die Daten wiederherzustellen.
Die Zeit bis zum nächsten Startup wird als "Nicht verfügbar" betrachtet, wenn sie länger als 3 bis 10 Minuten beträgt. Die Dauer hängt hauptsächlich von der Anzahl Objekte, die in der Datenbank gespeichert sind. - RECOVERY_START und RECOVERY_END markieren den Anfang und das Ende der Datenwiederherstellung in einem Failsafetyfall. Zum Endzeitpunkt ist die Redundanz im Cluster vollständig wiederhergestellt, so dass weitere Hardwareausfälle sicher behandelt werden können.
- BACKUP_START und BACKUP_STOP markieren den Anfang und das Ende eines Backupjobs. Bitte beachten Sie, dass es sich hierbei um einen Teil des Gesamtprozesses handelt, der in der Datenbank abläuft. Anschließend werden die erstellten Backupdateien von EXACluster OS redundant im Cluster verteilt, um auch Backups ausfallsicher zu halten.
- RESTORE_START und RESTORE_END markieren den Anfang und das Ende der Wiederherstellung einer Datenbank aus einem Backup.
In der Spalte MEASURE_TIME wird der jeweilige Zeitpunkt des Events gespeichert. Die Spalte DBMS_VERSION gibt an, mit welcher Version das System gestartet wurde. Die Spalte NODES speichert die Anzahl an Servern bei jedem Start der Datenbank.
