Benutzer-Werkzeuge

Webseiten-Werkzeuge


engine:databases

Die "anderen Datenbanken"

Die Installation der Engine betrifft nicht nur die (zentrale) „Customer-DB“, sondern es werden fünf weitere Datenbanken eingerichtet und außerdem in einer bzw. (indirekt) in zwei speziellen System-Datenbank(en) diverse Tabellen erstellt. Die Namen dieser Datenbanken sind :

  • dstore
  • dstorechecks
  • dstoreifin
  • dstoreifout
  • dstoretempdb
  • model bzw. tempdb (System-Datenbanken)

Näheres dazu in den nun folgenden Abschnitten.

dstore

In dieser Datenbank wird die Dokumentation der Engine gespeichert, also u.a. welche Tabellen und Prozeduren es gibt, was die jeweilige Aufgabe der Prozeduren ist, die Beschreibung von Prozedur-Parametern, -Rückgabemenge(n) und möglichen -Return-Codes (inkl. Klartext), etc.

Da nicht nur die hierzu benötigten Tabellen zur Engine gehören, sondern auch die Daten (also der Inhalt der Tabellen), wurde dieser Teil in eine eigene Datenbank ausgelagert. Prozeduren gibt es in dieser Datenbank nicht, lesender Zugriff erfolgt über die Prozeduren in der „Customer-DB“, die mit „do_“ beginnen, sowie der Prozedur mi_GetReturnCodeMessage (um sich den Klartext zu einem Prozedur-Return-Code holen zu können).

Die Tabellen und der Inhalt werden nach jedem Einspielen eines Updates entsprechend aktualisiert. Daher sind in dieser Datenbank keine „customized“ Objekte erlaubt !

dstorechecks

Gedacht ist diese Datenbank zur Speicherung von Daten anhand derer gewisse Überprüfungen (deswegen der Name „…checks“) gemacht werden (können), wobei die Daten aber separat „erworben“ werden müssen, also nicht Bestandteil der SmartEngine sind.

Bislang einziger Anwendungsfall ist der Frachtleitdaten-Check (oder besser Adressen-Check) der Deutschen Post. Es werden in der Engine-Installation lediglich die dafür benötigten Tabellen erstellt, sowie (in der „Customer-DB“) die Prozedur pm_AdressenCheck_Pu bereitgestellt. Anmerkung : Dies ist übrigens der einzige nicht in englisch verfaßte Prozedur-Name, um schon im Namen auf die Besonderheit hinzuweisen, daß nur Adressen aus Deutschland überprüft werden können.

Es gibt auch ein shell-script, um die Frachtleitdaten einzulesen, aber die Daten selbst müssen eben separat erworben werden.

model und tempdb

Die „model“-Datenbank ist eine System-Datenbank, in der ganz normal Objekte (Benutzer, Tabellen, Views, Prozeduren etc.) erstellt werden können. Das besondere ist jedoch, daß in jeder Datenbank, die neu angelegt wird, alle in der „model“-DB definierten Objekte erstellt werden. Hauptgrund für diese Funktionalität ist die Tatsache, daß es eine andere besondere System-Datenbank gibt, die bei jedem Start des ASE-Datenbank-Servers neu erstellt wird - die „tempdb“.

Die „tempdb“-Datenbank dient - wie der Name andeutet - ausschließlich dazu, temporär benötigte Objekte und/oder Daten zu erstellen bzw. zu speichern. Dies sind sowohl vom ASE selbst zur Laufzeit erstellte Objekte, wie z.B. „worktables“ (zur Sortierung von Daten), als auch u.a. von Nutzern angelegte temporäre Tabellen.

Anmerkung : Solche temporären Tabellen werden auch „Session“-Tabellen genannt, da keine anderen Prozesse auf eine solche Tabelle zugreifen können und diese Tabellen nicht erst nach einem Neu-Start des ASE zerstört werden, sondern nur an die „Lebensdauer einer Session“ gebunden sind - was u.a. den angenehmen Vorteil hat, daß man nicht explizit ein „drop table“ absetzen muß.

Ein wesentlicher Nachteil von temporären („Session“-)Tabellen ist, daß sie nicht innerhalb einer Transaktion erstellt werden können. Es gibt zwar eine ASE-Server- Option, dies zu erlauben, aber das ist aus folgendem Grund auf keinen Fall eine gute Möglichkeit, das Problem zu lösen : Da die „tempdb“ im Prinzip eine ganz normale Datenbank wie alle anderen auch ist, führt die Erstellung von Tabellen dazu, daß die Definition in ihren System-Tabellen („sysobjects“, „syscolumns“ etc.) abgebildet wird. Während dieses Speicher- Vorgangs greifen - wie bei allen anderen Tabellen auch - die normalen „locking“- Mechanismen. Wäre man also in der Lage, in einer Transaktion temporäre Tabellen zu erstellen, wären ab Erstellungs-Zeitpunkt der ersten temporären Tabelle bis zum Ende der Transaktion die System-Tabellen der „tempdb“ ge“lock“t ! Einen schlimmeren „Flaschenhals“ kann man kaum erzeugen…

Nun ist es aber in bestimmten Prozeduren unabdingbar, sowohl temporär Daten zu speichern als auch in einer Transaktion abzulaufen. Glücklicherweise kann man in der „tempdb“ eben auch „permanente“ (im Sinne von : über eine „Session“ hinausgehende) Tabellen speichern, die dann von solchen Prozeduren verwendet werden können.

Genau diese Tabellen werden in der „model“-DB erstellt, damit diese auch nach einem Neustart des ASE garantiert in der „tempdb“ zur Verfügung stehen. Logischerweise (im Gegensatz zu „Session“-Tabellen) müssen sich aber alle Prozeduren eine solche Tabelle „teilen“. Wie das funktioniert, wird im Abschnitt „‚Input‘-Tabellen“ in Hintergrundinformationen zu Engine-Prozeduren erklärt.

Anmerkung : Als Nebeneffekt können diese Tabellen auch zur Übergabe von Daten an und/oder zwischen Prozeduren dienen, wie in Hintergrundinformationen zu Engine-Prozeduren ausführlicher geschildert.

dstoreifin, dstoreifout und dstoretempdb

Wie im vorigen Abschnitt „model und tempdb“ und auch in Hintergrundinformationen zu Engine-Prozeduren erwähnt, werden die Tabellen in der „tempdb“ sowohl zur Übergabe von Daten an und/oder zwischen Prozeduren als auch zur Speicherung temporärer Daten in Transaktionen verwendet.

Dies hat aber als Konsequenz, daß neben „normalen“ temporären Tabellen sowie den vom ASE erstellten „worktables“ nun noch zusätzlich sehr viele Schreib- Operationen in der „tempdb“ hinzukommen. Außerdem gibt es einige wenige Tabellen („OneID“, „TwoIDs“, „ThreeIDs“ u.a.), die von einer Vielzahl von Prozeduren verwendet werden, was nicht nur etwas „unschön“ ist, sondern auch einen zusätzlichen Engpaß darstellt und es bei Auftreten von solchen Engpässen sehr schwierig bis unmöglich ist, die verursachende Prozedur herauszufinden. Man kann ja noch nicht einmal z.B. den Werten in „OneID“ ansehen, um welche IDs es sich handelt – „NodeID“s oder „TreeNodeID“s oder „PersonID“s oder … ?

Um also zum einen die Schreib-Operationen besser zu verteilen, und um zum anderen leichter Problem-verursachende Prozeduren herauszufinden, wurde das Konzept der Datenbanken „dstoreifin“, „dstoreifout“ und „dstoretempdb“ in der Engine-Version 5.0.1 eingeführt :

  • dstoreifin : Dient der Übergabe von Daten an Prozeduren, stellt also sozusagen eine Input-Schnittstelle dar (daher der Name : „Interface, input“)
  • dstoreifout : Tabellen dieser Datenbank enthalten die jeweilige Rückgabemenge von Prozeduren, weshalb die Datenbank grob als Output-Schnittstelle beschrieben werden kann (daher der Name : „Interface, output“)
  • dstoretempdb : Hier können Prozeduren Daten (temporär, daher der Name) zwischenspeichern

Mehr Details gibt es im Kapitel Hintergrundinformationen zu Engine-Prozeduren, und zwar in den Abschnitten „‚Input‘-Tabellen“ und „‚Output‘-Tabellen“. Dort werden zwar nicht die Tabellen der „dstoretempdb“-Datenbank behandelt, aber der Aufbau und die Konzepte sind identisch.

engine/databases.txt · Zuletzt geändert: 13.11.2014 (Externe Bearbeitung)