Tags:
create new tag
, view all tags

Historisierungs-Datenbank

Ausgangslage und Ziel

In der jetzigen Infra-Datenbank fallen teilweise enorme Datenmengen an, die jedoch sehr selten verwendet werden. Darüber hinaus wird der Wunsch nach einer Historisierung (online) und Archivierung (offline) gewisser Daten immer grösser. Um die Backup-Strategie hinsichtlich Menge und Häufigkeit optimieren zu können, ist eine Historisierungs-Datenbank sinnvoll, die einerseits online verfügbar ist, andererseits aber die Haupt-Datenbank entlastet.

Kandidaten für die DB

Schema Tabelle Grösse Charakteristik Historisationsdauer
nethz SCHEDULE > 1 Mio Der grösste Teil der Daten wird sehr selten verwendet 2 Jahre
nethz UNAME_HISTORY > 100'000 selten verwendet 5 Jahre
inventar OBJECT_HISTORY > 100'000 selten verwendet 5 Jahre
ides2 ORDERSHISTORIES > 1 Mio selten verwendet ? Jahre
radacct Radius-Tabellen > 1 Mio gelegentlich (Dialup800 Reporting) 1-2 Jahre

weitere "nice to have"-Kandidaten für Historisierung

Gründe für weitere Kandidaten:

  • namespacing - Probleme
  • Rekonstruktion von ehemaligen Verantwortlichkeiten

Schema Tabelle Grösse Beschreibung Historisationsdauer
nethz EMAIL > 50'000 Emailadressen sollten nicht sofort wiederverwendet werden - eine Historisierung könnte Abhilfe schaffen 1-2 Jahre
nethz UNAME > 100'000 Usernamen sollten nicht sofort wiederverwendet werden 5 Jahre
nethz MACHINE_RESPONSIBLE > 1000   5 Jahre

Technische Umsetzung Variante 1

Für jede zu historisierende Tabelle werden zwei identische Tabellen geschaffen: Mytable_01 und Mytable_02. Das ursprüngliche Synonym Mytable zeigt nicht mehr direkt auf die Tabelle Mytable, sondern auf eine View, welche Mytable_01 und Mytable_02 mit einem Union-Join vereint. Nach einem Jahr wird abwechselnd Mytable_xx geleert und der Inhalt in die Historisierungsdatenbank geschrieben. Dadurch sind immer die Daten von mindestens einem Jahr (bis maximal 2 Jahre) vorhanden.

Nachteil: Auf Applikationsseite müssen die INSERT-Statements auf andere Tabellen-Synonyme erfolgen als reine SELECT-Statements, z.B. "INSERT INTO Mytable_insert ...". Das Synonym "Mytable_insert" zeigt dann abwechselnd auf Mytable_01 oder Mytable_02.

Technische Umsetzung Variante 2

Jede zu historisierende Tabelle wird partitioniert. Aufgrund eines Kriteriums eines bestimmten Feldwertes entscheidet Oracle, in welche Partition ein bestimmter Datensatz geschrieben wird. Den Vorgang nennt man Range Partitioning. Von Zeit zu Zeit (z.B. 1x pro Jahr) wird die älteste Partition in die Historisierungsdatenbank geschrieben und im aktiven System gelöscht.

Vorteil: Auf Applikationsseite braucht nichts angepasst zu werden.

Nachteil: Falls kein bestimmter Wert (z.B. Sysdate) existiert, aufgrund dessen eine Range Partitioning vorgenommen werden kann, so muss ein zusätzliches Feld in der Tabelle eingeführt werden. Mit einem before-insert Trigger kann nun dieses Feld explizit gefüllt werden (z.B. mit sysdate).

-- Main.vermeul - 19 Jun 2006

Topic revision: r2 - 2006-07-03 - vermeul
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback