SOA Suite Datenbank „demystified“
Werbung
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
