SOA Suite Datenbank „demystified“

SOA Suite Datenbank „demystified“
Markus Lohn
esentri AG
Ettlingen
Schlüsselworte
Fusion Middleware, SOA Suite
Einleitung
Die Datenbank als essentieller Bestandteil der Oracle SOA Suite wird in vielen Projekten unterschätzt
oder nicht ausreichend berücksichtigt. Wenn die Auswirkungen auf die Datenbank jedoch frühzeitig
beim Design von Composites beachtet werden, können viele Probleme vermieden werden.
In diesem Vortrag werden zunächst die grundsätzliche Mechanismen und das Zusammenspiel
Datenbank und SOA Suite erläutert. Ferner werden Best Practices aus verschiedenen Projekten
erläutert, die in jedem Projekt berücksichtigt werden sollten.
Oracle SOA Suite Architektur
Oracle SOA Suite bündelt verschiedene Komponenten zu einer Infrastruktur. Somit werden Daten
auch in unterschiedlichen Datenbanken verwaltet.
Abbildung 1 Oracle SOA Suite Infrastruktur
Zu jeder SOA Suite Installation gehören minimal die Datenbanken SOAINFRA und MDS. In
SOAINFRA werden alle Runtime-Daten zu Composite Instanzen verwaltet. Im MDS werden die
Konfigurationseinstellungen und SCA Composites selbst gespeichert.
Repository Creation Utility (RCU)
Generell werden alle notwendigen Datenbanken einer Fusion Middleware Installation mit dem RCU
erstellt. Somit wird auch die SOA-Datenbank (und alle Schemata) mit dem RCU erzeugt. Das RCU
wird ab Version 12c mit dem FMW-Package „Infrastructure“ ausgeliefert. Ferner ist erlaubt das RCU
ab Version 12c die Erstellung von SQL-Skripten zum Erstellen der Datenbanken. Das vereinfacht die
Zusammenarbeit mit den DBA’s in der Zukunft erheblich.
Abbildung 2 Repository Creation Utility für Oracle SOA Suite
Metadata Services Repository (MDS)
MDS stellt eine zentrale Infrastruktur für das Management von Konfigurationsdaten für Applikationen
zur Verfügung. MDS wird generell von allen Fusion Middleware Produkten, z. B. WebCenter, BPM
Suite, Web Services, ADF, etc. verwendet.
Oracle SOA Suite verwendet das MDS zum einen für die Speicherung von jeglichen
Konfigurationseinstellungen, z. B. Partitionen (siehe Datei folders.xml). Zum anderen für die zentrale
Ablage und Verteilung von SCA Composites. Zu beachten ist, dass alle Dateien eines Composites in
das MDS gespeichert werden. Prinzipiell erfolgt auch die Verteilung auf verschiedene Cluster-Knoten
über das MDS (in Verbindung mit Coherence).
Das MDS Repository kann in einem Dateisystem oder der Datenbank verwaltet werden. Das MDS
Repository in der Datenbank bietet mehr Funktionen, z. B. Versionierung, im Vergleich zur dateibasierten Variante.
In der Entwicklung hat sich die Strategie „Continuous Integration“ durchgesetzt und somit werden
sehr häufig Deployments durchgeführt. In Verbindung mit der SOA Suite und MDS kann das zu
einem Engpass im Tablespace für das MDS führen. Ursache ist die Versionierung von Artefakten
innerhalb des MDS. Oftmals ist es sinnvoll vorher ein Undeployment durchzuführen. In diesem Fall
werden auch alle Versionen eines Composites im MDS entfernt.
Mit dem folgenden SQL-Befehl kann die Anzahl von Versionen für gleiche SCA Composites
innerhalb des MDS festgestellt werden.
SELECT path_fullname, path_type
FROM mds_paths
WHERE path_fullname like '/deployedcomposites/default/RegisterUserProfileService_%/composite.xml'
SOAINFRA
Im Schema SOAINFRA werden die Runtime-Daten zu allen Komponenten, z. B. BPEL, Mediator,
Human Workflow, etc. gespeichert. Im Vergleich zu Version 11g hat sich das Schema in der Version
12c um fast 200 Tabellen vergrößert. Die Anzahl der neuen Tabellen verringert sich ein wenig, wenn
man die SOA Core Extension nicht installiert. Ferner wurde die Struktur der Infrastruktur-Tabellen
komplett erneuert. In der nachfolgenden Abbildung ist die Struktur und die Abhängigkeiten der
Tabellen dargestellt. In der zentralen Tabelle SCA_FLOW_INSTANCE wird für jede Composite
Instance ein neuer Datensatz angelegt. Primary Key für eine Instanz ist die sog. Flow Id (Spalte ID).
Neu ist auch die Verwaltung von SOA Partition’s innerhalb der Datenbank (SCA_PARTITION).
Bisher wurde das ausschließlich im MDS (folders.xml) gespeichert. SCA_ENTITY speichert die
Metadaten zu allen Komponenten eines Composites. Ferner ist in dieser Tabelle auch das sog. MDS
Label (Spalte LABEL) hinterlegt. Es dient zur Identifikation eines Composites im MDS.
SCA_ENTITY
SCA_META_DATA
SCA_ATTACHMENT_REF
SCA_PARTITION
SCA_FLOW_INSTANCE
SCA_COMMON_FAULT
SCA_FLOW_ASSOC
SCA_SENSOR_VALUE
SCA_REJECTED_MESSAGE
Abbildung 3 12c SOA Infrastructure Tabellen
Die Tabellen der Komponente BPEL sind auch in Version 12c weitestgehend stabil geblieben. Die
zentrale Tabelle ist CUBE_INSTANCE. Wichtige Tabellen sind ferner CUBE_SCOPE und
XML_DOCUMENT. In CUBE_SCOPE werden alle definierten Scope’s und alle Variablen-Inhalte
eines BPEL-Prozesses gespeichert.
AUDIT_TRAIL
AUDIT_DETAILS
NATIVE_CORRELATION
HEADERS_PROPERTIES
WORK_ITEM
DLV_SUBSCRIPTION
CUBE_INSTANCE
WI_FAULT
DOCUMENT_CI_REF
XML_DOCUMENT
CI_INDEXES
AG_INSTANCE
CUBE_SCOPE
DLV_MESSAGE
DOCUMENT_DLV
_MSG_REF
Abbildung 4 BPEL Tabellen
Ein BPEL-Prozess hat immer mind. einen Scope. Beim Design von BPEL-Prozessen muss deshalb auf
die Anzahl und Variablen in einem Scope geachtet werden. Überdies ist die Tabelle
XML_DOCUMENT in Bezug auf das Wachstum zu überwachen. In dieser Tabelle werden VariablenInhalte und Payloads gespeichert, die eine bestimmte Schwellwert-Größe überschritten haben. Dieser
Wert ist über den Enterprise Manager konfigurierbar (Large Document Treshhold).
Zu jeder Composite Instance werden Audit-Informationen in SOAINFRA gespeichert. Wann und wie
viele Audit-Informationen geschrieben werden, kann sehr detailliert konfiguriert werden. In
Abhängigkeit von den fachlichen Anforderungen, kann das Audit abgeschaltet oder in verschiedenen
Modi betrieben werden. Zusätzlich kann die Konfiguration auf alle oder ausgewählte SCA Composites
angewandt werden. Beispielsweise wird man bei einer prozess-orientierten Lösung voraussichtlich
mehr Audit-Informationen benötigen im Vergleich zu einem fachlich orientierten synchronen Business
Service.
In Untersuchungen konnte festgestellt werden, dass bis zu 40% Datenwachstum in SOAINFRA
gespart werden können, wenn der Audit-Level auf Production konfiguriert wurde.
Löschstrategie
Die Kontrolle des Datenwachstums ist eine wichtige Aufgabe in jedem SOA Suite Projekt. Eine
Archivierungs- und Löschstrategie ist deshalb unverzichtbar und muss frühzeitig im Projekt erarbeitet
werden. Bereits im SCA Composite Design können wichtige Aspekte berücksichtigt werden.
Beispielsweise sollten fachliche Anwendungsdaten, die in einem Prozess zur Verarbeitung
herangezogen werden, immer in der Fachdatenbank gespeichert werden. Somit ist sichergestellt, dass
die Runtime-Daten eines Prozesses jederzeit gelöscht werden können und keine Abhängigkeiten zur
Prozess-Engine entstehen.
Die technische Umsetzung einer Löschstrategie kann auf vielfältige Arten durchgeführt werden.
Folgende Varianten sind für die SOA Suite vorgesehen:
• Purge Scripts
• Database Partitioning (+ Purge Scripts)
• Enterprise Manager
• TRS Script (Table-Recreate-Script)
• Infrastructure Management API (Java)
• Truncate Script (Empfehlung: Nur in der Entwicklung oder beim Wechsel der Umgebung
nutzen!)
Oracle verwaltet Datendateien in Segmenten, Extents und Daten Blöcken. Bei vielen Löschaktivitäten
sind die Auswirkungen auf die Speicherstrukturen zu analysieren und ggf. regelmäßige Optimierungen
notwendig.
Fazit
Die Datenbank kann in einem SOA Suite Projekt nicht als „Black-Box“ betrachtet werden. Sie ist ein
wichtiger Bestandteil und benötigt deshalb auch entsprechende Beachtung! Unabhängig wie viele
Daten in der SOA Suite verarbeitet werden müssen, ein erfahrener DBA muss in jedem SOA Suite
Projekt als fester Bestandteil im Projektteam integriert sein. Bereits früh im Design von SCA
Composites können eine Menge Aspekte hinsichtlich Laufzeitverhalten und Einfluss auf das
Datenwachstum berücksichtigt werden. Frühzeitig ist die Erstellung und Überwachung einer
Löschstrategie erforderlich. Die Durchführung von Last- und Performancetest sind ein wichtiges
Instrument, um das Design und die Löschstrategie frühzeitig zu verifizieren und ggf. anzupassen.
Somit bleiben dem SOA Suite Betreiber in der Zukunft böse Überraschungen im Betrieb erspart.
Referenzen:
• Main Tables Used by the BPEL Engine (Doc ID 376002.1)
• SOA 11G Database Growth Management Strategy (Doc ID 1404605.1)
• Purge Scripts Master Note - Oracle SOA Suite 11g
• How to Reclaim Disk Space after Purging a SOA Infrastructure or BPEL Database (Doc ID
1387722.1)
• https://docs.oracle.com/middleware/1213/soasuite/administer/soa-database-manageplan.htm#SOAAG97777
Kontaktadresse:
Markus Lohn
esentri AG
Pforzheimer Str. 132
D-76275 Ettlingen
Telefon:
Fax:
E-Mail
Internet:
+49 (0) 7243 354900
+49 (0) 7243 3549099
[email protected]
www.esentri.com