Leitfaden für die Oracle Datenbankserver-Architektur

Germany, Jan. 30, 2017

Das Thema Oracle Datenbankserver-Architektur ist sehr umfangreich – und für moderne Unternehmen ein sehr wichtiges dazu. Wir werden im Folgenden die einzelnen Komponenten dieser Architektur besprechen.

Die Vorteile eines Oracle Datenbankmanagementsystems

Ehe wir uns mit den näheren Einzelheiten der Oracle Datenbankserver-Architektur beschäftigen, wollen wir erst einmal beleuchten, warum so viele Firmen diese Methode für ihre Bedürfnisse gewählt haben. Oracle ist Marktführer im Bereich der relationalen Datenbanken. Da ist zunächst einmal die Tatsache, dass Oracle sehr vielseitig ist. Oracle kann von den unterschiedlichsten Industriezweigen verwendet werden. Oracle Datenbanken lassen sich für Anwendungen jeglicher Größe einsetzen. Oracle bietet mit Real Application Cluster (RAC) und Data Guard auch Lösungen für den Bereich Hochverfügbarkeit und Disaster Recovery an.

Viele Firmen bevorzugen die Oracle Datenbankserver-Architektur auch aufgrund ihrer Transaktionsorientierten Fähigkeit. In einer Oracle Datenbank finden alle DML (Data Manipulation Language) und DDL (Data Definition Language) Befehle im Rahmen von Transaktionen statt. Dabei werden die Anforderungen des ACID Paradigmas erfüllt.
Diese sind im Einzelnen:

Atomarität (Atomicity): Man spricht von einer atomaren Operation, wenn eine beliebige Anzahl von Datenbank Befehlen entweder ganz oder gar nicht ausgeführt wird. Um dies zu erreichen werden diese Befehle in einer Transaktion zusammengefasst. Die Transaktion gilt erst als abgeschlossen, wenn alle einzelnen Befehle erfolgreich ausgeführt wurden, ansonsten wird die Transaktion zurückgerollt.

Konsistenz (Consistency): Nach Abschluss einer Transaktion müssen die Daten logisch konsistent sein, d. h. die inhaltliche und referentielle Integrität des Datenbestandes muss gegeben sein.

Abgrenzung (Isolation): Mehrere parallel verlaufende Transaktionen dürfen sich nicht gegenseitig beeinflussen.

Dauerhaftigkeit (Durability): Nach Abschluss einer erfolgreichen Transaktion muss das Datenbankmanagementsystem garantieren, dass die Daten dauerhaft gespeichert und bei einem Systemausfall wiederherstellbar sind.

Oracle Datenbank Versionen

Oracle bietet ihre Datenbankserver-Architektur sowohl für kleine und mittlere Unternehmen in Form der Standard Edition (SE) als auch für größere Industrie-Unternehmen in Form ihrer Enterprise Edition (EE) an. Die Enterprise Edition ist für höchste Anforderungen in den Bereichen Skalierbarkeit, Zuverlässigkeit, Transaktionsverarbeitung und Datenmanagement geschaffen.

Die folgende Tabelle zeigt die aktuellen Versionen, deren Einschränkungen und Mindestlizenzierung:

Standard Edition

SE2 (ab Version 12.1.0.2)
- Maximal 2 Socket Server
- Max. 16 CPU Threads.
- RAC ohne Zusatzkosten möglich.
  Einschränkung: eine CPU pro Server mit max. 8 CPU Threads
- Minimum 10 NUP bzw. 1 Prozessor Lizenz (max. 2 Prozessoren)
SE (bis Version 12.1.0.1)
- Maximal 4 Socket Server
- RAC ohne Zusatzkosten möglich. (Max. 2 CPU‘s pro Server)
SE1 (bis Version 12.1.0.1)
- Maximal 2 Socket Server

Enterprise Edition 12.1.0.2

Minimum 25 NUP pro Prozessor oder Server Lizenz. Die Oracle Datenbank Enterprise Edition kann durch kostenpflichtige Optionen und Management Packs sinnvoll ergänzt bzw. erweitert werden.

Versionen im Vergleich

Die folgenden Tabellen zeigen beide Versionen im Vergleich.

Allgemein	SE2	Enterprise
Max. Sockets	2	Kein Limit
Max. RAM	Kein Limit	Kein Limit
DB Size	Kein Limit	Kein Limit
Multitenant	---	Option

High Availability	SE2	Enterprise
Active Data Guard	---	Option
Transaction Guard	---	ja
Cross-Plattform Recovery	ja	ja
Cross-Plattform Backup	---	ja
Fail Safe (nur Windows, kein gespiegeltes Storage)	ja	ja
Flashback Query	ja	ja
Flashback Table, Database and Transaction Query	---	ja
Server Managed Backup and Recovery	ja	ja
Performance, Scalability	SE2	Enterprise
Real Application Clusters	ja	Option
Real Application Clusters One Node	---	Option
Adaptive Execution Plans	---	ja
Integrated Clusterware	ja	ja
Automatic Workload Management	ja	ja
Java, PL/SQL Native Compilation	ja	ja
In-Memory Database Cache	---	Option
Integration	SE2	Enterprise
Basic Replaction	ja	ja
Distributed Queries / Transactions	ja	ja
Security	SE2	Enterprise
Data Masking	---	Option
Real Application Security	---	ja
Database Vault	---	Option
Advanced Security	---	Option
Label Security	---	Option
Secure Application Roles	---	ja
Virtual Private Database	---	ja
Fine-Grained Auditing	---	ja
Proxy Authentification	ja	ja
Data Encryption Toolkit	ja	ja

Database Management Packs

Folgende Management Packs sind für die Oracle Enterprise Edition verfügbar:

Diagnostics Pack
Tuning Pack
Data Masking und Subsetting Pack
Lifecycle Management Pack
- Change Management Pack
- Configuration Management Pack
- Provisioning Pack
Cloud Management Pack für Oracle Database

Diagnostics Pack

Das Oracle Diagnostics Pack bietet Ihnen automatisierte Performance Diagnosen sowie eine umfangreiche System Monitoring Funktionalität.
Das Diagnostics Pack beinhaltet die folgenden Features:

Automatisiertes Workload Repository (AWR)
Automatisiertes Datenbank Diagnose Monitoring (ADDM)
Performance Monitoring Ereignisbenachrichtigungen: Benachrichtigungsmethoden, Regeln und Zeitpläne
Ereignishistorie und metrische Historie (Datenbank und Host)
Blackouts

Tuning Pack

Das Oracle Tuning Pack bietet Datenbankadministratoren professionelles Performance Management für Ihre Oracle Umgebungen, einschließlich SQL Tuning und Storage Optimierung. Um das Tuning Pack einzusetzen, benötigt man ebenfalls das Diagnostics Pack.
Das Oracle Tuning Pack beinhaltet die folgenden Features:

SQL Access Ratgeber
SQL Tuning Ratgeber
SQL Tuning Werkzeuge
Objekt Reorganisation

Data Masking and Subsetting Pack

Oracle Enterprise Manager Data Masking und Subsetting Pack bietet eine umfassende und einfach zu bedienende Lösung, um Produktionsdaten mit internen und externen Ressourcen zu teilen und schützt dabei jedoch sensitive und vertrauliche Daten vor dem Zugriff durch nicht-autorisierte Personen.

Provisioning Pack (Lifecycle Management Packs)

Das Oracle Provisioning Pack unterstützt die automatisierte Verteilung von Software, Anwendungen und Patchen. Das Pack bietet zudem reine Verteilung für Betriebssysteme und Software Images, einschließlich

Automatisiertes Patchen der Oracle Produkte und des Betriebssystems
Vereinfachten Zugang zu Critical Patches
Software Image Library
Versorgung für Datenbank, RAC, Application Server und Oracle Applications
Single-Instanz zu RAC Umwandlung
Enterprise Sicherheitsratgeber
Reports zur Verteilung und Versorgung innerhalb des Systems

Configuration Management Pack (Lifecycle Management Packs)

Die folgenden Features sind enthalten:

Ausführliche Suche über die Konfigurationsdaten, beispielsweise der Oracle home patch status, die eingesetzten Versionen, Parameter Settings, Datenbank Featurenutzung etc.
Die Möglichkeit, die Konfiguration zweier Datenbanken zu vergleichen
Host-to-host und auch host-to-mehrfach-host Vergleiche
Export der Host-Konfigurationsinformationen in der selben oder anderen Instanz des Enterprise Managers für eine spätere Durchsuchung oder Vergleich
Patch Management einschließlich automatisierte Bestimmung der Patche, welche speziell für Oracle Home benötigt werden
Datenbank und Oracle Home Softwarecloning

Oracle Datenbank Lizenzierung

Um Oracle zu benutzen bietet Oracle zwei Arten der Lizensierung an:

Named User Plus (NUP) basiert auf Personen und nicht auf benutzerdefinierte Geräte, die auf die Oracle Software zugreifen.
Prozessor basiert auf der Hardware, auf der die Software lizenziert wird. Hier ist es wichtig zu erwähnen welcher Prozessor benutzt wird und die Anzahl der Cores. Oracle stellt zur Kalkulation eine Prozessor Core Tabelle zur Verfügung. Die Cores spielen allerdings nur für die Lizensierung der Enterprise Edition eine Rolle.

Lizenzierung Beispiel 1

Ein Kunde bestellt einen zwei Socket Datenbankserver mit zwei Intel CPU’s mit jeweils acht Kernen. Wie ist dieser Server, in Abhängigkeit der unterschiedlichen Editionen und Lizenzierungsarten, zu lizenzieren?
Betrachten wir zunächst den Fall, dass der Kunde eine Standard Edition 2 (SE2) einsetzen möchte:

Named User Plus (NUP): Zwei * 10 User (Mindestlizensierung) = 20 User

Prozessor: 2 Prozessoren = 2 Prozessor Lizenzen

Anschließend betrachten wir den Fall, dass der Kunde eine Enterprise Edition (EE) einsetzen möchte:
Bei der Enterprise Edition Lizenzierung spielt, im Gegensatz zur Standard Edition 2 Lizenzierung, die Anzahl der Prozessorkerne und der Core Faktor eine Rolle. Der Core Faktor für eine Intel CPU beträgt 0,5.

Named User Plus (NUP): 8 * 25 User (Mindestlizensierung) = 200

Prozessor: Anzahl der Prozessoren * Anzahl der Cores * Corefaktor = 2 Prozessoren * 8 Cores * 0,5 = 8

Prozessor: Acht Prozessor Lizenzen

Ergebnis:
Möchte der Kunde auf dem Datenbankserver die Standard Edition 2 verwenden benötigt dieser zwei Prozessor Lizenzen.
Kommt allerdings die Enterprise Edition zum Einsatz wird von dieser acht Prozessor Lizenzen benötigt.

Lizenzierung Beispiel 2

Ein Fabrikationsbetrieb verfügt über 15 Thermostate, welche die Temperatur in ihrem Warenhaus regeln und automatisch eine Oracle Datenbank mit den aktuellen Werten updaten. Des Weiteren verfügt die Firma über 30 Gabelstapler die von 400 Angestellten im Warenhaus bedient werden. Die Gabelstapler haben eingebaute Transponder, welche die Oracle Datenbank automatisch mit Daten versorgen. Die Oracle Datenbank läuft auf einem Server mit 6 Prozessoren (single core chips).
Da die Anzahl der Sockets grösser als 2 ist kann der Kunde nur eine Enterprise Edition (EE) einsetzen und hat nicht die Option eine Standard Edition zu verwenden:
Das Produkt kann entweder entsprechend der Anzahl der Prozessoren oder als Named User Plus lizensiert werden.

Sechs Prozessoren: Sechs Prozessor Lizenzen

Named User Plus (NUP): Die Anzahl der benötigten Lizenzen ist wie folgt:

1) Named User Plus Minimum (25 Named User Plus pro Prozessor) ODER

2) Die Gesamtanzahl von Benutzern die auf die Datenbank zugreifen (= Thermostaten + Anzahl der Angestellten im Warenhaus). Die größere Nummer bestimmt die Anzahl der Lizenzen.

1) 25 * 6 Prozessoren = 150 Named User Plus

2) 15 Thermostaten + 400 Angestellte = 415 Named User Plus

Ergebnis:
415 Named User Plus Lizenzen werden benötigt.

Die Oracle Datenbank

Die Oracle Architektur gliedert sich in zwei grundlegende Bereiche:

Die Oracle Instanz (aktiver Teil)
Die Oracle Datenbank (passiver Teil)

Was ist eine Oracle Instance?

Die Oracle Instanz wird auch als der aktive Teil der Oracle Architektur bezeichnet.
Zu ihr gehören Speicherstrukturen für die Ablage von Daten sowie Hintergrundprozesse.
Der Aufbau der Instanz wird über die Parameter- oder über die Serverparameterdatei definiert.
Der Speicherort der Parameter- oder Serverparameterdatei heißt unter Linux/Unix $ORACLE_HOME/dbs unter Windows %ORACLE_HOME%\database.
Existieren in dem Speicherort sowohl eine Parameter und eine Serverparameterdatei, so hat die Serverparameterdatei Vorrang für den Start der Instanz.
In dieser Datei wird unter anderem der Name der Datenbank und deren Speicherparameter definiert.

Was ist die Oracle Datenbank?

Die Oracle Datenbank besteht aus den Datenbankdateien und befindet sich auf dem Plattensubsystem des Datenbankservers und wird als der passive Teil der Oracle Datenbank Architektur bezeichnet.
Folgende Arten von Datenbankdateien existieren:

Controlfiles
Datafiles
Online Redolog Files
Archivelog Files

Controlfile

In ihr befinden sich die Speicherorte der Datenbankdateien. Nach dem Start der Instanz wird die Kontrolldatei über den in der Parameterdatei befindlichen Initialisierungsparameter CONTROL_FILES lokalisiert, und die Speicherorte der Datenbankdateien werden ausgelesen.
Des Weiteren wird das Controlfile vom Recovery Manager als Sicherungskatalog verwendet die alle Metadaten der mit dem Recovery Manager erzeugten Sicherungen speichert.
Geht das Controlfile verloren sind somit auch die Recovery Informationen verloren. Daher sollte das Controlfile gespiegelt werden.

Online Redolog Files
Die im Redo-Log-Buffer protokollierten Änderungen werden alle drei Sekunden, bei 1MB an Blockänderungen, bei einem Drittel Füllgrad oder bei Abschluss einer Transaktion durch ein COMMIT in die Redo-Log-Dateien geschrieben. Eine Datenbank muss mindestens zwei Redo-Log-Dateien besitzen, die zyklisch beschrieben werden.

Archivelog Files
gesicherte Online Redolog Files

Das Starten der Datenbank erfolgt in drei Schritten:

Schritt 1: Starten der Instanz (Zustand NOMOUNT)
In diesem Schritt wird die Instanz gestartet, dabei wird die Serverparameterdatei zur Dimensionierung der Instanz gelesen und die Oracle Hintergrundprozesse (SMON, PMON, DBW0…) gestartet.
Außerdem ist in der Serverparameterdatei der Pfad zu den Controlfiles definiert.

Schritt 2: Mounten der Datenbank (Zustand MOUNT)
Im zweiten Schritt wird der gestarteten Instanz einer physikalische Datenbank zugeordnet, d.h. durch das Lesen der Controlfiles wird der Instanz die dazugehörigen Datafiles bekannt gemacht.
Des Weiteren kann in diesem Zustand in der Datenbank der Archivelog bzw. Flashback Modus aktiviert werden.

Schritt 3: Öffnen der Datenbank (Zustand OPEN)
Im dritten Schritt werden die aus der NOMOUNT Phase bekannten Datafiles geöffnet und die Datenbank steht den Anwender zur Verfügung.

Logische Datenbankstrukturen

Im Abschnitt „Was ist eine Datenbank?“ haben wir Ihnen die physikalische Struktur einer Oracle Datenbank vorgestellt.
Aus Sicht der Datenbank gibt es verschiedene logische Strukturen die wir uns in diesem Kapitel genauer anschauen wollen.

Datenblöcke – Diese bilden die unterste Stufe der Speicherstrukturen in einer Oracle Datenbank.
Jeder Datenblock repräsentiert eine gewisse Anzahl von Bytes eines physikalischen Datenplatzes auf dem Speichermedium.
Eine spezifische Datenblock-Größe, üblicherweise 8k, wird beim Erstellen einer Oracle Datenbank festgelegt.

Extents – diese bilden die nächste Ebene. Ein Extent ist eine logisch zusammenhängende Speichereinheit.
Segmente – diese bilden die oberste Ebene. Ein Segment besteht aus einem oder mehreren Extents.
Reicht der Speicherplatz für ein Segment nicht aus, so wird ein weiteres Extent allokiert, dabei unterscheidet man folgende Segmentarten:

- Datensegmente
- Indexsegmente
- Undo-Segmente
- Temporäre Segmente

Tablespaces – Die Oracle Datenbank speichert ihre Datenobjekte wie z.B. Tabellen, Indizies in Tablespaces,
wobei einem Tablespace ein oder mehrere Datafiles zugeordnet werden können.
Dabei kann ein Datafile genau einem Tablespace zugeordnet werden.
Vorteil dieses Konzeptes ist es, den gleichen Aufbau der Datenbank auf unterschiedlichen Betriebssystemen zu gewährleisten.
Es existieren folgende Standard Tablespaces in einer Datenbank:
- SYSTEM (für Systemobjekte / Data Dictionary)
- SYSAUX (für bestimmte Systemobjekte wie Statspack, Scheduler)
- TEMP (wird zum Sortieren verwendet)
- UNDO (für Rollback Informationen)
- USERS (für Benutzerdaten)
- Schema – logisch zusammengehörige Objekte z.B. einer Anwendung können in einem Schema zusammengefasst werden.
  Für eine saubere Trennung von verschiedenen Anwendungen wird empfohlen für jedes Schema einen eigenen Tablespace anzulegen.

Damit sollten Sie nun ein umfassendes Verständnis der Oracle Datenbankserver-Architektur erlangt haben – ausreichend genug, um diese zu implementieren und ihre vielen Vorteile zu nutzen. Falls Sie weitere Fragen haben sollten stehen wir Ihnen gerne zur Verfügung.

Topic

Telecommunications

Das könnte Sie auch interessieren

Germany , Apr 29, 2025

News

Logicalis CIO Report 2025: CIOs kritisieren Security-Systeme als kostenintensiv und schwer zu managen

Logicalis, internationaler Anbieter von IT-Lösungen und Managed Services, stellt fest: CIOs fällt es angesichts der wachsenden Bedrohungslage zunehmend schwer, einen Nutzen aus ihren Sicherheitsinvestitionen zu ziehen.