Detaillierte grafische Erläuterung der Oracle-Datenbankarchitektur

Dieser Artikel vermittelt Ihnen relevantes Wissen über Oracle, in dem hauptsächlich Probleme im Zusammenhang mit der Datenbankarchitektur vorgestellt werden. Der Oracle-DB-Server besteht aus einer Oracle-Datenbank und einer oder mehreren Datenbankinstanzen. Die Instanz besteht aus einer Speicherstruktur und einer Backend-Prozesszusammensetzung Ich hoffe, es wird für alle hilfreich sein.

Empfohlenes Tutorial: „Oracle Tutorial“

Übersicht

Oracle DB Server besteht aus einer Oracle DB und einer oder mehreren Datenbankinstanzen. Instanzen bestehen aus Speicherstrukturen und Hintergrundprozessen. Immer wenn eine Instanz gestartet wird, wird ein gemeinsam genutzter Speicherbereich namens System Global Area (SGA) zugewiesen und Hintergrundprozesse werden gestartet.
Die Datenbank umfasst die physische Struktur und die logische Struktur. Da die physischen und logischen Strukturen getrennt sind, wird der Zugriff auf die logische Speicherstruktur bei der Verwaltung der physischen Datenspeicherung nicht beeinträchtigt.

Oracle-Instanzen nutzen Speicherstrukturen und Prozesse, um Datenbanken zu verwalten und darauf zuzugreifen. Sämtliche Speicherstrukturen liegen im Hauptspeicher der Rechner, aus denen der Datenbankserver besteht. Prozesse sind Jobs, die im Speicher dieser Computer ausgeführt werden. Ein Prozess wird als „Steuerungsstrang“ oder Mechanismus in einem Betriebssystem definiert, der eine Folge von Schritten ausführt.

Speicherstruktur

Oracle-Instanzen verfügen über zwei zugehörige grundlegende Speicherstrukturen:
1. System Global Area (SGA)
Eine Gruppe von gemeinsam genutzten Speicherstrukturen, die als SGA-Komponenten bezeichnet werden, enthalten die Daten und die Steuerung der Informationen einer Oracle-DB-Instanz . Der SGA wird von allen Servern und Hintergrundprozessen gemeinsam genutzt. Beispiele für im SGA gespeicherte Daten sind zwischengespeicherte Datenblöcke und gemeinsam genutzte SQL-Bereiche.
SGA ist der Speicherbereich, der die Daten und Steuerinformationen der Instanz enthält. Der SGA enthält die folgenden Datenstrukturen:
• Datenbankpuffer-Cache: Wird zum Zwischenspeichern von aus der Datenbank abgerufenen Datenblöcken verwendet.
• Redo-Log-Puffer: Wird zum Zwischenspeichern von Redo-Informationen verwendet, die für die Instanzwiederherstellung verwendet werden, bis sie geschrieben werden können. Physische Redo-Log-Dateien werden auf der Festplatte gespeichert
• Gemeinsamer Pool: Wird zum Zwischenspeichern verschiedener Strukturen verwendet, die von Benutzern gemeinsam genutzt werden können.
• Großer Pool: Wird für bestimmte große Prozesse (z. B. Oracle-Sicherungs- und Wiederherstellungsvorgänge) und E/A-Server verwendet. Prozesse bieten optionale Bereiche mit großen Speicherzuweisungen.
• Java-Pool: Wird für den gesamten sitzungsspezifischen Java-Code und die Daten in der Java Virtual Machine (JVM) verwendet.
• Stream-Pool: Wird von Oracle Streams zum Speichern von Informationen verwendet, die für Erfassungs- und Anwendungsvorgänge erforderlich sind.

2 )
Ein Speicherbereich, der Daten und Steuerinformationen für einen Serverprozess oder Hintergrundprozess enthält.
PGA ist nicht gemeinsam genutzter Speicher, der von Oracle DB erstellt wird, wenn der Serverprozess oder Hintergrundprozess startet. Der Serverprozesszugriff auf die PGA schließt sich gegenseitig aus. Jeder Serverprozess und Hintergrundprozess verfügt über einen eigenen PGA.
Die Program Global Area (PGA) ist ein Speicherbereich, der Daten und Steuerinformationen für jeden Serverprozess enthält. Der Oracle-Server verarbeitet Service-Client-Anfragen. Jeder Serverprozess verfügt über einen eigenen dedizierten PGA, der beim Start des Serverprozesses erstellt wird. Der Zugriff auf den PGA ist auf diesen Serverprozess beschränkt und kann nur von Oracle-Code im Namen dieses Serverprozesses gelesen und geschrieben werden.

Oracle DB verwendet Initialisierungsparameter, um Speicherstrukturen zu erstellen und zu verwalten. Die einfachste Möglichkeit zur Speicherverwaltung besteht darin, der Datenbank die automatische Verwaltung und Optimierung des Speichers zu ermöglichen. Legen Sie dazu einfach den Initialisierungsparameter für die Zielspeichergröße (MEMORY_TARGET) und den Initialisierungsparameter für die maximale Speichergröße (MEMORY_MAX_TARGET) fest (das Folgende funktioniert auf den meisten Plattformen).

Datenbankpuffer-Cache

Der Datenbankpuffer-Cache ist Teil des SGA und wird zum Speichern von Kopien von aus Datendateien gelesenen Datenblöcken verwendet. Alle parallel mit der Instanz verbundenen Benutzer teilen sich den Zugriff auf den Datenbankpuffer-Cache.
Wenn ein Oracle DB-Benutzerprozess zum ersten Mal ein bestimmtes Datenelement benötigt, durchsucht er den Datenbankpuffercache nach den Daten.
Wenn der Prozess die Daten im Cache findet (sogenannter Cache-Hit), werden die Daten direkt aus dem Speicher gelesen. Wenn ein Prozess keine Daten im Cache finden kann (Cache-Miss genannt), muss der Datenblock aus der Datendatei auf der Festplatte in einen Puffer im Cache kopiert werden, bevor auf die Daten zugegriffen werden kann. Der Zugriff auf Daten bei einem Cache-Treffer ist schneller als der Zugriff auf Daten bei einem Cache-Miss.
Puffer im Cache werden von einem komplexen Algorithmus verwaltet, der eine Kombination aus LRU-Listen (Least Latest Used) und Dock-Zählmechanismen verwendet.

Redo-Log-Puffer

Der Redo-Log-Puffer ist ein Ringpuffer in SGA, der Informationen über an der Datenbank vorgenommene Änderungen enthält. Diese Informationen werden in Redo-Einträgen gespeichert. Redo-Einträge enthalten die Informationen, die zum Wiederherstellen (oder Wiederherstellen) von Änderungen erforderlich sind, die durch DML, DDL oder interne Vorgänge an der Datenbank vorgenommen wurden. Bei Bedarf werden Redo-Einträge zur Datenbankwiederherstellung verwendet.
Wenn der Serverprozess den Puffercache ändert, generiert das System Redo-Einträge und schreibt die generierten Redo-Einträge in den Redo-Log-Puffer im SGA. Redo-Einträge belegen zusammenhängenden sequentiellen Platz im Puffer. Der LGWR-Hintergrundprozess schreibt Redo-Log-Puffer in aktive Redo-Log-Dateien (oder Dateigruppen) auf der Festplatte.

Gemeinsamer Pool

Der gemeinsam genutzte Pool-Teil von SGA enthält Bibliothekscache, Datenwörterbuch-Cache, SQL-Abfrageergebnis-Cache, PL/SQL-Funktionsergebnis-Cache, Puffer für parallele Ausführungsnachrichten und Kontrollstrukturen.
Ein „Datenwörterbuch“ ist eine Sammlung von Datenbanktabellen und -ansichten, die Referenzinformationen über eine Datenbank, ihre Struktur und ihre Benutzer enthalten. Während der Analyse von SQL-Anweisungen greift Oracle DB häufig auf das Datenwörterbuch zu. Dieser Zugriffsvorgang ist für den weiteren Betrieb von Oracle DB von entscheidender Bedeutung.
Oracle DB greift sehr häufig auf das Datenwörterbuch zu, daher sind im Speicher zwei spezielle Speicherorte zum Speichern von Wörterbuchdaten vorgesehen.
Ein Bereich namens „Datenwörterbuch-Cache“, auch bekannt als „Zeilen-Cache“, da er Daten in Form von Zeilen und nicht in Form von Puffern speichert (Puffer werden zum Speichern vollständiger Datenblöcke verwendet). Ein weiterer Speicherbereich, der für Wörterbuchdaten verwendet wird, wird als „Bibliothekscache“ bezeichnet. Alle Oracle DB-Benutzerprozesse nutzen diese beiden Caches gemeinsam für den Zugriff auf Datenwörterbuchinformationen.
Oracle DB verwendet gemeinsam genutzte SQL-Regionen (sowie im PGA reservierte private SQL-Regionen), um jede ausgeführte SQL-Anweisung darzustellen. Oracle DB erkennt, wenn zwei Benutzer dieselbe SQL-Anweisung ausführen, und verwendet den gemeinsam genutzten SQL-Bereich für diese Benutzer erneut.
Der „Shared SQL Area“ enthält den Analysebaum und den Ausführungsplan für eine bestimmte SQL-Anweisung. Oracle DB spart Speicher, indem es einen gemeinsam genutzten SQL-Bereich für mehrfach ausgeführte SQL-Anweisungen verwendet. Wenn viele Benutzer dieselbe Anwendung ausführen, wird dieselbe SQL-Anweisung häufig mehrmals ausgeführt.
Beim Parsen einer neuen SQL-Anweisung reserviert Oracle DB Speicher aus dem gemeinsam genutzten Pool, um die Anweisung im gemeinsam genutzten SQL-Bereich zu speichern. Die Größe dieses Speichers hängt von der Komplexität der Anweisung ab.
Oracle DB behandelt PL/SQL-Programmeinheiten (Prozeduren, Funktionen, Pakete, anonyme Blöcke und Datenauslöser) auf die gleiche Weise wie einzelne SQL-Anweisungen. Oracle DB weist einen gemeinsam genutzten Bereich zum Speichern der Programmeinheit in ihrer analysierten und kompilierten Form zu. Oracle DB weist einen privaten Bereich zum Speichern von Werten zu, die für die Sitzung spezifisch sind, in der die Programmeinheit ausgeführt wird, einschließlich lokaler Variablen, globaler Variablen und Paketvariablen (auch „Paketinstanziierung“ genannt), und zum Speichern von Puffern, die zum Ausführen von SQL verwendet werden . Wenn mehrere Benutzer dieselbe Programmeinheit ausführen, verwenden alle Benutzer denselben gemeinsam genutzten Bereich, behalten jedoch separate Kopien ihrer eigenen privaten SQL-Bereiche bei, um für ihre eigenen Sitzungen spezifische Werte zu speichern.
Einzelne SQL-Anweisungen, die in einer PL/SQL-Programmeinheit enthalten sind, werden ähnlich wie andere SQL-Anweisungen verarbeitet.
Unabhängig vom Ursprung dieser SQL-Anweisungen in der PL/SQL-Programmeinheit verwenden sie alle einen gemeinsamen Bereich zum Speichern ihrer Parsing-Darstellung und einen dedizierten Bereich für jede Sitzung, in der die Anweisung ausgeführt wird.
SQL-Abfrageergebnis-Cache und PL/SQL-Funktionsergebnis-Cache sind neue Funktionen in Oracle Database 11g.
Sie nutzen dieselbe Infrastruktur, erscheinen in derselben dynamischen Leistungsansicht (V$) und werden mit demselben bereitgestellten Paket verwaltet.
Die Ergebnisse von Abfragen und Abfragefragmenten können im Speicher im „SQL Query Results Cache“ zwischengespeichert werden. Auf diese Weise kann die Datenbank die zwischengespeicherten Ergebnisse verwenden, um spätere Ausführungen dieser Abfragen und Abfragefragmente zu beantworten. Da das Abrufen von Ergebnissen aus dem SQL-Abfrageergebniscache viel schneller ist als das erneute Ausführen der Abfrage, kann das Zwischenspeichern der Ergebnisse häufig ausgeführter Abfragen die Leistung dieser Abfragen erheblich verbessern.
Diese Funktion wird manchmal verwendet, um die Ergebnisse einer Berechnung zurückzugeben, wenn die Eingabe in die Berechnung eine oder mehrere parametrisierte Abfragen ist, die von einer PL/SQL-Funktion ausgegeben werden. In einigen Fällen greifen diese Abfragen auf Daten zu, die sich selten ändern (verglichen mit der Häufigkeit, mit der die Funktion aufgerufen wird).
Sie können Syntax in den Quelltext einer PL/SQL-Funktion einfügen, um anzufordern, dass die Funktionsergebnisse im „PL/SQL Function Result Cache“ zwischengespeichert werden und dass der Cache geleert wird, wenn DML in einer Tabelle in der Tabellenliste gefunden wird (um die korrekte Richtigkeit sicherzustellen).

Großer Pool

Ein Datenbankadministrator kann einen optionalen Speicherbereich namens „Großer Pool“ konfigurieren, um große Speicherzuweisungen für Folgendes bereitzustellen:
• Gemeinsam genutzter Serversitzungsspeicher und Oracle (wird bei der Interaktion mit mehreren Datenbanken verwendet)
• E/A Serverprozesse
• Oracle DB-Sicherungs- und Wiederherstellungsvorgänge
Oracle DB kann hauptsächlich den gemeinsam genutzten Pool nutzen, indem es Sitzungsspeicher aus einem großen Pool für gemeinsam genutzte Server, Oracle XA oder parallele Abfragepuffer reserviert und den durch die Verkleinerung verursachten Leistungsaufwand vermeidet der gemeinsam genutzte SQL-Cache.
Darüber hinaus wird der für Oracle DB-Sicherungs- und Wiederherstellungsvorgänge, E/A-Serverprozesse und parallele Puffer verwendete Speicher in Puffern von Hunderten von KB zugewiesen. Große Pools können derart große Speicheranforderungen besser bedienen als gemeinsam genutzte Pools.
Für große Pools gibt es keine LRU-Liste. Es unterscheidet sich vom reservierten Speicherplatz im gemeinsam genutzten Pool, der dieselbe LRU-Liste verwendet wie anderer vom gemeinsam genutzten Pool zugewiesener Speicher.

Java-Pool und Stream-Pool

Serverspeicher, der den gesamten sitzungsspezifischen Java-Code und alle Daten in der JVM speichert, verwendet Java-Pool-Speicher. Je nach Betriebsmodus von Oracle DB kann der Java-Poolspeicher auf verschiedene Arten genutzt werden.
Java Pool Guidance-Statistiken liefern Informationen über den Bibliotheks-Cache-Speicher für Java und sagen voraus, wie sich Änderungen in der Java-Pool-Größe auf die Parsing-Raten auswirken. Wenn „statistics_level“ auf „TYPICAL“ oder höher eingestellt ist, wird die Java-Pool-Anleitung intern aktiviert. Diese Statistiken werden zurückgesetzt, wenn Sie die Anleitung schließen.
Der Stream-Pool wird ausschließlich von Oracle Streams verwendet. Der Stream-Pool speichert gepufferte Warteschlangennachrichten und stellt Speicher für Oracle Streams-Erfassungsprozesse und Anwendungsprozesse bereit.
Sofern der Stream-Pool nicht speziell konfiguriert ist, beginnt seine Größe bei Null. Bei der Verwendung von Oracle Streams wächst die Poolgröße je nach Bedarf dynamisch.

Program Global Area (PGA)

Die Program Global Area (PGA) ist ein dedizierter Speicherbereich, der Daten und Steuerinformationen für den Serverprozess enthält. Jeder Serverprozess verfügt über einen eigenen PGA. Auf den PGA kann nur der entsprechende Serverprozess zugreifen und nur Oracle-Code, der im Auftrag dieses Serverprozesses handelt, kann ihn lesen. Der Entwicklercode kann nicht auf die PGA zugreifen.
Jeder PGA enthält Stapelplatz. In einer dedizierten Serverumgebung gibt es für jeden Benutzer, der eine Verbindung zur Datenbankinstanz herstellt, einen separaten Serverprozess. Für diesen Verbindungstyp enthält der PGA eine Speicherunterteilung, die User Global Area (UGA) genannt wird. UGA besteht aus den folgenden Teilen:
• Cursorbereich, der zum Speichern von Laufzeitinformationen für den Cursor verwendet wird
• Benutzersitzungsdatenspeicher, der zum Speichern von Steuerinformationen über die Sitzung verwendet wird
• SQL-Arbeitsbereich, der zum Verarbeiten von SQL-Anweisungen verwendet wird, einschließlich:

• Sortierbereich, der für Funktionen zum Sortieren von Daten wie ORDER BY und GROUP BY verwendet wird.
• Hash-Bereich, der zum Durchführen von Hash-Joins von Tabellen verwendet wird.
• Bitmap-Erstellungsbereich, der zum Erstellen von Bitmap-Indizes verwendet wird, die häufig in Data Warehouses verwendet werden.
• Bitmap Zusammenführungsbereich, der zum Parsen der Ausführung von Bitmap-Indexplänen verwendet wird
  In einer gemeinsam genutzten Serverumgebung teilen sich mehrere Clientbenutzer den Serverprozess. In diesem Modus wird der UGA in den SGA (gemeinsam genutzter Pool oder großer Pool, falls konfiguriert) verschoben und der PGA enthält nur Stapelspeicherplatz.

Prozessstruktur

Die Prozesse im Oracle DB-System sind hauptsächlich in zwei Gruppen unterteilt:
1. Benutzerprozesse, die Anwendungs- oder Oracle-Toolcode ausführen
Bei verschiedenen Oracle DB-Konfigurationen ist die Benutzerprozessstruktur je nach Betriebssystem unterschiedlich und ausgewählte OracleDB-Optionen. Code für verbundene Benutzer kann als dedizierter Server oder gemeinsam genutzter Server konfiguriert werden.
• Dedizierter Server: Für jeden Benutzer wird der Benutzerprozess, der die Datenbankanwendung ausführt, von einem dedizierten Serverprozess bedient, der den Oracle DB-Servercode ausführt.
• Gemeinsam genutzter Server: Es ist nicht erforderlich, für jede Verbindung einen dedizierten Serverprozess zu haben. Der Dispatcher leitet mehrere eingehende Netzwerksitzungsanforderungen an den gemeinsam genutzten Serverprozesspool weiter. Der gemeinsam genutzte Serverprozess bedient alle Clientanforderungen.
2. Oracle DB-Prozess (einschließlich Serverprozess und Hintergrundprozess), der Oracle DB-Servercode ausführt
2.1. Oracle DB erstellt einen Serverprozess, um Anforderungen von mit der Instanz verbundenen Benutzerprozessen zu verarbeiten. Benutzerprozesse stellen Anwendungen oder Tools dar, die eine Verbindung zu Oracle DB herstellen. Es kann sich auf demselben Computer wie Oracle DB oder auf einem Remote-Client befinden, der über das Netzwerk auf Oracle DB zugreift. Der Benutzerprozess kommuniziert zunächst mit einem Listener-Prozess, der in einer dedizierten Umgebung einen Serverprozess erstellt.
Der Serverprozess, der zur Darstellung der Anwendung jedes Benutzers erstellt wurde, kann einen oder mehrere der folgenden Schritte ausführen:
• Die über die Anwendung ausgegebenen SQL-Anweisungen analysieren und ausführen.
• Die SQL-Anweisungen aus einer Datendatei auf der Festplatte abrufen. Erforderliche Datenblöcke werden in die eingelesen Gemeinsamer Datenbankpuffer von SGA (wenn sich diese Datenblöcke derzeit nicht im SGA befinden)
• Ergebnisse werden zurückgegeben, damit die Anwendung die Informationen verarbeiten kann

2.2, Hintergrundprozess

Um die Leistung zu maximieren und den Anforderungen mehrerer Benutzer gerecht zu werden, werden mehrere Prozess Oracle DB-Systeme verwenden eine Reihe zusätzlicher Oracle DB-Prozesse, die als „Hintergrundprozesse“ bezeichnet werden. Eine Oracle DB-Instanz kann mehrere Hintergrundprozesse haben.
Zu den gängigen Hintergrundprozessen in Nicht-RAC- und Nicht-ASM-Umgebungen gehören:
• Datenbankschreibprozess (DBWn)
• Protokollschreibprozess (LGWR)
• Prüfpunktprozess (CKPT)
• Systemüberwachungsprozess (SMON)
• Prozessmonitor Prozess (PMON)
• Wiederherstellungsprozess (RECO)
• Job-Warteschlangenkoordinator (CJQ0)
• Job-Slave-Prozess (Jnnn)
• Archivprozess (ARCn)
• Warteschlangenüberwachungsprozess (QMNn)
Fortgeschrittener Möglicherweise gibt es einen anderen Hintergrund Prozesse in der Konfiguration (z. B. RAC). Weitere Informationen zu Hintergrundprozessen finden Sie in der Ansicht V$BGPROCESS.
Einige Hintergrundprozesse werden beim Starten einer Instanz automatisch erstellt, während andere bei Bedarf erstellt werden.
Andere Prozessstrukturen sind nicht spezifisch für eine einzelne Datenbank, sondern können von mehreren Datenbanken auf demselben Server gemeinsam genutzt werden. In diese Kategorie fallen Netzinfrastrukturprozesse und Netzwerkprozesse.
Oracle Grid Infrastructure-Prozesse auf Linux- und UNIX-Systemen umfassen:
• ohasd: Oracle High Availability Service Daemon, verantwortlich für den Start von Oracle Clusterware-Prozessen
• ocssd: Cluster Synchronization Service Daemon
• diskmon: Disk Monitoring Daemon, verantwortlich für die Überwachung von HP Input und Ausgabe von Oracle Exadata Storage Server
• cssdagent: Starten, stoppen und überprüfen Sie den Status des CSS-Daemons ocssd
• oraagent: Erweitern Sie die Clusterware, um Oracle-spezifische Anforderungen und komplexe Ressourcen zu unterstützen
• orarootagent: Ein dedizierter Oracle-Agent-Prozess, kann helfen Verwalten Sie Ressourcen, die dem Root-Benutzer gehören (z. B. das Netzwerk)

Datenbankschreibprozess (DBWn)

Der Datenbankschreibprozess (DBWn) kann den Inhalt des Puffers in die Datendatei schreiben. Der DBWn-Prozess ist für das Schreiben geänderter Puffer (graue Datenpuffer) im Datenbankpuffer-Cache auf die Festplatte verantwortlich. Obwohl für die meisten Systeme ein Datenbankschreibprozess (DBW0) ausreichend ist, können zusätzliche Prozesse (DBW1 bis DBW9 und DBWa bis DBWz) konfiguriert werden, um die Schreibleistung zu verbessern. Diese zusätzlichen DBWn-Prozesse sind auf Einprozessorsystemen nicht sinnvoll.
Wenn ein Puffer im Datenbankpuffer-Cache geändert wird, markiert das System ihn als grauen Datenpuffer und fügt ihn in der SCN-Reihenfolge an den Kopf der Prüfpunktwarteschlange hinzu. Daher stimmt die Reihenfolge mit der Reihenfolge überein, in der die Redo-Einträge für diese geänderten Puffer in das Redo-Log geschrieben werden. Wenn die Anzahl der freien Puffer im Puffercache unter einen internen Schwellenwert fällt (bis zu dem Punkt, an dem der Serverprozess es als schwierig erachtet, freie Puffer zu erhalten), schreibt DBWn selten verwendete Puffer in die Datendatei und schreibt die Reihenfolge am Ende Die LRU-Liste ermöglicht es Prozessen, Puffer nach Bedarf zu ersetzen. DBWn schreibt auch vom Ende der Prüfpunktwarteschlange, um künftige Prüfpunkte zu schützen.
Im SGA gibt es eine Speicherstruktur, die die Redo-Byte-Adresse (RBA) des Speicherorts im Redo-Stream speichert, von dem aus die Wiederherstellung gestartet wird, wenn eine Instanz ausfällt. Diese Struktur dient als Zeiger auf Redo und wird alle drei Sekunden vom CKPT-Prozess in die Steuerdatei geschrieben. Da DBWn den grauen Datenpuffer in der SCN-Reihenfolge schreibt und die Wiederherstellung in der SCN-Reihenfolge erfolgt, wird der in der SGA-Speicherstruktur gehaltene Zeiger auch nach vorne verschoben, wenn DBWn den grauen Datenpuffer aus der LRUW-Liste schreibt, um die Instanzwiederherstellung zu erleichtern ( (Falls erforderlich) Starten Sie die Lesewiederholung ungefähr an der richtigen Position und vermeiden Sie unnötige E/A. Dies wird als „inkrementeller Prüfpunkt“ bezeichnet.
Hinweis: Es gibt andere Situationen, in denen DBWn möglicherweise Schreibvorgänge ausführt (z. B. wenn der Tablespace schreibgeschützt ist oder offline geschaltet wird). In diesen Fällen treten keine inkrementellen Prüfpunkte auf, da die Reihenfolge, in der die grauen Datenpuffer, die nur zu den entsprechenden Datendateien gehören, in die Datenbank geschrieben werden, unabhängig von der SCN-Reihenfolge ist.
Der LRU-Algorithmus behält Blöcke, auf die häufiger zugegriffen wird, im Puffercache, um Festplattenlesevorgänge zu minimieren. Sie können die CACHE-Option mit der Tabelle verwenden, um Blöcke länger im Speicher zu halten.
Der Initialisierungsparameter DB_WRITER_PROCESSES gibt die Anzahl der DBWn-Prozesse an. Die maximale Anzahl von DBWn-Prozessen beträgt 36. Wenn der Benutzer diese Anzahl von Prozessen beim Start nicht angibt, bestimmt Oracle DB, wie DB_WRITER_PROCESSES basierend auf der Anzahl der CPUs und Prozessorgruppen festgelegt wird.
Der DBWn-Prozess schreibt unter den folgenden Bedingungen graue Datenpuffer auf die Festplatte:
• Wenn der Serverprozess nach dem Scannen einer Schwellenwertanzahl von Puffern keinen sauberen wiederverwendbaren Puffer finden kann, wird DBWn benachrichtigt, einen Schreibvorgang durchzuführen. DBWn schreibt den grauen Datenpuffer asynchron auf die Festplatte, während andere Verarbeitungen ausgeführt werden.
• DBWn-Schreibpuffer zum Erweitern von Prüfpunkten. Ein Prüfpunkt ist die Startposition im Redo-Thread (Protokoll), der zur Durchführung der Instanzwiederherstellung verwendet wird. Die Protokollposition wird durch den ältesten grauen Datenpuffer im Puffercache bestimmt. In allen Fällen führt DBWn gestapelte (Multiblock-)Schreibvorgänge aus, um die Effizienz zu verbessern. Die Anzahl der bei einem Multiblock-Schreibvorgang geschriebenen Blöcke variiert je nach Betriebssystem.

Log Write Process (LGWR)

Der Log Write Process (LGWR) ist für die Verwaltung des Redo-Log-Puffers verantwortlich, indem er Redo-Log-Puffereinträge in die Redo-Log-Datei auf der Festplatte schreibt. LGWR schreibt alle seit dem letzten Schreibvorgang in den Puffer kopierten Redo-Einträge.
Der Redo-Log-Puffer ist ein Ringpuffer. Nachdem LGWR die Redo-Einträge im Redo-Log-Puffer in die Redo-Log-Datei geschrieben hat, kann der Serverprozess die neuen Einträge zusätzlich zu den auf die Festplatte geschriebenen Einträgen in den Redo-Log-Puffer kopieren. Die Schreibgeschwindigkeit von LGWR ist normalerweise schnell genug, um sicherzustellen, dass im Puffer immer Platz für neue Einträge ist, auch wenn der Zugriff auf das Redo-Log intensiv ist. LGWR schreibt einen zusammenhängenden Teil des Puffers auf die Festplatte.
LGWR führt Schreibvorgänge aus, wenn:
• Wenn ein Benutzerprozess eine Transaktion festschreibt
• Wenn ein Drittel des Redo-Log-Puffers voll ist
• Wenn der DBWn-Prozess den geänderten Puffer vorher auf die Festplatte schreibt (falls erforderlich)
• Alle 3 Sekunden
Alle mit den Pufferänderungen verbundenen Redo-Datensätze müssen auf die Festplatte geschrieben werden, bevor DBWn einen geänderten Puffer auf die Festplatte schreiben kann (Write-Ahead-Protokoll). Wenn DBWn feststellt, dass einige Redo-Datensätze noch nicht geschrieben wurden, benachrichtigt es LGWR
, diese Redo-Datensätze auf die Festplatte zu schreiben und zu warten, bis LGWR den Schreibvorgang des Redo-Log-Puffers abgeschlossen hat, bevor es in den Datenpuffer schreibt. LGWR schreibt in die aktuelle Protokollgruppe. Wenn eine Datei in dieser Gruppe beschädigt oder nicht mehr verfügbar ist, schreibt LGWR weiterhin in andere Dateien in der Gruppe und protokolliert einen Fehler in der LGWR-Tracedatei und im Systemwarnprotokoll. Wenn alle Dateien in einer Gruppe beschädigt sind oder die Gruppe nicht verfügbar ist, weil sie nicht archiviert wurde, kann LGWR nicht weiterarbeiten.
Wenn der Benutzer eine COMMIT-Anweisung ausgibt, platziert LGWR einen Commit-Datensatz im Redo-Log-Puffer und schreibt den Datensatz sofort zusammen mit dem Redo-Log der Transaktion auf die Festplatte. Entsprechende Änderungen an den Datenblöcken werden verzögert, bis sie effizienter geschrieben werden können. Dies wird als „Fast-Commit-Mechanismus“ bezeichnet. Ein atomares Schreiben eines Redo-Eintrags, der einen Transaktions-Commit-Datensatz enthält, ist ein einzelnes Ereignis, das bestimmt, ob eine Transaktion festgeschrieben wurde.
Oracle DB gibt einen Erfolgscode für festgeschriebene Transaktionen zurück, obwohl der Datenpuffer noch nicht auf die Festplatte geschrieben wurde.
Wenn mehr Pufferspeicherplatz benötigt wird, schreibt LGWR manchmal Redo-Log-Einträge, bevor die Transaktion festgeschrieben wird. Diese Einträge werden erst dauerhaft, wenn die Transaktion später festgeschrieben wird. Wenn ein Benutzer eine Transaktion festschreibt, wird der Transaktion eine Systemänderungsnummer (SCN) zugewiesen, die Oracle DB zusammen mit den Redo-Einträgen der Transaktion im Redo-Log aufzeichnet. SCNs werden im Redo-Log aufgezeichnet, sodass Wiederherstellungsvorgänge zwischen Real Application Clusters und verteilten Datenbanken synchronisiert werden können.
Bei hoher Aktivität kann LGWR mithilfe von Gruppen-Commits Redo-Log-Dateien schreiben. Angenommen, ein Benutzer sendet eine Transaktion. LGWR muss die Redo-Einträge für diese Transaktion auf die Festplatte schreiben. In diesem Fall geben andere Benutzer COMMIT-Anweisungen aus. Allerdings kann LGWR nicht in die Redo-Log-Dateien schreiben, um diese Transaktionen festzuschreiben, bis der vorherige Schreibvorgang abgeschlossen ist. Nachdem die Einträge der ersten Transaktion in die Redo-Log-Datei geschrieben wurden, kann die gesamte Liste der Redo-Einträge für ausstehende (noch nicht festgeschriebene) Transaktionen in einem einzigen Vorgang auf die Festplatte geschrieben werden, was schneller ist als die individuelle Verarbeitung einzelner Transaktionseinträge. O ist erforderlich. Dadurch kann Oracle DB die Festplatten-E/A minimieren und die Leistung von LGWR maximieren. Wenn die Rate der Festschreibungsanforderungen konstant hoch ist, kann jeder Schreibvorgang aus dem Redo-Log-Puffer (durchgeführt von LGWR) mehrere Festschreibungsdatensätze enthalten.

Checkpoint Process (CKPT)

Ein „Checkpoint“ ist eine Datenstruktur, die eine Systemänderungsnummer (SCN) im Redo-Thread einer Datenbank definiert. Prüfpunkte werden in der Steuerdatei und im Header jeder Datendatei aufgezeichnet. Sie sind entscheidende Elemente von Wiederherstellungsvorgängen.
Wenn ein Prüfpunkt auftritt, muss Oracle DB die Header aller Datendateien aktualisieren, um die Details des Prüfpunkts aufzuzeichnen. Dies erfolgt durch den CKPT-Prozess. Der CKPT-Prozess schreibt keine Blöcke auf die Festplatte; diese Arbeit wird von DBWn ausgeführt. Der im Dateiheader aufgezeichnete SCN garantiert, dass alle Änderungen an Datenbankblöcken bis zu diesem SCN auf die Festplatte geschrieben werden.
Der SYSTEM_STATISTICS-Monitor in Oracle Enterprise Manager zeigt Statistiken zu DBWR-Prüfpunkten an, die die Anzahl der abgeschlossenen Prüfpunktanforderungen angeben.

System Monitor Process (SMON)

Der System Monitor Process (SMON) führt die Wiederherstellung durch, wenn die Instanz startet (falls erforderlich). SMON ist auch für die Bereinigung temporärer Segmente verantwortlich, die nicht mehr verwendet werden. Wenn während der Instanzwiederherstellung aufgrund von Dateilese- oder Offlinefehlern abgebrochene Transaktionen übersprungen werden, setzt SMON diese Transaktionen fort, wenn der Tabellenbereich oder die Datei wieder online ist.
SMON prüft regelmäßig, ob der Prozess erforderlich ist. Andere Prozesse können es auch aufrufen, wenn sie die Notwendigkeit von SMON erkennen.

Process Monitor Process

Der Process Monitor Process (PMON) führt eine Prozesswiederherstellung durch, wenn ein Benutzerprozess fehlschlägt. PMON ist dafür verantwortlich, den Datenbankpuffer-Cache zu löschen und vom Benutzerprozess belegte Ressourcen freizugeben. PMON setzt beispielsweise den Status aktiver Transaktionstabellen zurück, gibt Sperren frei und entfernt die Prozess-ID aus der Liste der aktiven Prozesse.
PMON überprüft regelmäßig den Status von Dispatcher- und Serverprozessen und startet alle Dispatcher- und Serverprozesse neu, die nicht mehr ausgeführt werden (sofern sie nicht absichtlich von OracleDB beendet werden). PMON registriert außerdem Informationen über die Instanz- und Dispatcher-Prozesse beim Netzwerk-Listener.
Wie SMON prüft PMON regelmäßig, ob es ausgeführt werden muss; auch andere Prozesse können es aufrufen, wenn sie erkennen, dass es benötigt wird.

Recoverer-Prozess

Der Recovery-Prozess (RECO) ist ein Hintergrundprozess für verteilte Datenbankkonfigurationen, der Fehler bei der verteilten Transaktionsverarbeitung automatisch behebt. Der RECO-Prozess der Instanz stellt automatisch eine Verbindung zu anderen Datenbanken her, die an der betreffenden verteilten Transaktionsverarbeitung beteiligt sind. Wenn der RECO-Prozess die Verbindungen zwischen den beteiligten Datenbankservern wiederherstellt, löst er automatisch alle problematischen Transaktionen auf und entfernt aus der Tabelle der ausstehenden Transaktionen jeder Datenbank alle Transaktionen, die den gelösten problematischen Transaktionen entsprechen.
Wenn der RECO-Prozess keine Verbindung zum Remote-Server herstellen kann, versucht RECO nach einem bestimmten Zeitintervall automatisch, die Verbindung wiederherzustellen. Allerdings wartet RECO immer länger (exponentiell), bevor es erneut versucht, eine Verbindung herzustellen.

Archivierungsprozess (ARCn)

Nach einem Protokollwechsel kopiert der Archivierungsprozess (ARCn) die Redo-Log-Dateien auf das angegebene Speichergerät. Der ARCn-Prozess existiert nur, wenn sich die Datenbank im ARCHIVELOG-Modus befindet und die automatische Archivierung aktiviert ist.
Wenn Sie mit einer hohen Archivierungsarbeitslast rechnen (z. B. beim Batch-Laden von Daten), können Sie die maximale Anzahl der Archivierungsprozesse mithilfe des Initialisierungsparameters LOG_ARCHIVE_MAX_PROCESSES erhöhen. Die ALTER SYSTEM-Anweisung kann den Wert dieses Parameters dynamisch ändern, um die Anzahl der ARCn-Prozesse zu erhöhen oder zu verringern.

Speicherstruktur

Die Dateien, aus denen Oracle DB besteht, können in die folgenden Kategorien unterteilt werden:
• Steuerdateien: Enthält Daten, die sich auf die Datenbank selbst beziehen, d. h. Informationen zur physischen Datenbankstruktur. Diese Dateien sind für die Datenbank von entscheidender Bedeutung. Ohne diese Dateien können die Datendateien nicht geöffnet werden, um auf die Daten in der Datenbank zuzugreifen.
• Datendateien: Enthält die Benutzer- oder Anwendungsdaten der Datenbank sowie Metadaten und Datenwörterbuch.
• Online-Redo-Log-Dateien: Wird beispielsweise für die Wiederherstellung der Datenbank verwendet. Wenn der Datenbankserver abstürzt, aber keine Datendateien verloren gehen, kann die Instanz die Informationen in diesen Dateien verwenden, um die Datenbank wiederherzustellen.
Die folgenden zusätzlichen Dateien sind für den erfolgreichen Betrieb der Datenbank sehr wichtig:
• Parameterdatei: Wird zum Definieren der Konfiguration beim Start der Instanz verwendet.
• Passwortdatei: Ermöglicht sysdba, sysoper und sysasm, sich remote mit der Instanz zu verbinden und Verwaltungsaufgaben auszuführen
• Sicherungsdatei: Wird für die Datenbankwiederherstellung verwendet. Sicherungsdateien werden normalerweise wiederhergestellt, wenn die Originaldateien aufgrund eines Medienfehlers oder eines Benutzerfehlers beschädigt oder gelöscht wurden.
• Archivierte Redo-Log-Dateien: Enthält einen Echtzeitverlauf der Datenänderungen (Redos), die auf einer Instanz aufgetreten sind. Mithilfe dieser Datei- und Datenbanksicherungen können verlorene Datendateien wiederhergestellt werden. Mit anderen Worten: Archivprotokolle können wiederhergestellte Datendateien wiederherstellen.
• Trace-Dateien: Jeder Server und Hintergrundprozess kann in zugehörige Trace-Dateien schreiben. Wenn ein Prozess einen internen Fehler erkennt, speichert der Prozess Informationen über den Fehler in der entsprechenden Trace-Datei. Einige der in die Trace-Datei geschriebenen Informationen werden für den Datenbankadministrator bereitgestellt, während andere Informationen für Oracle Support Services bereitgestellt werden.
• Alarmprotokolldateien: Diese Dateien enthalten spezielle Trace-Einträge. Das Warnprotokoll der Datenbank ist ein Nachrichtenprotokoll und ein Fehlerprotokoll, die in chronologischer Reihenfolge aufgeführt sind. Oracle empfiehlt, das Warnprotokoll regelmäßig zu überprüfen.

Logische und physische Datenbankstruktur

Datenbank, Tablespaces und Datendateien

Diese Folie erklärt die Beziehung zwischen Datenbanken, Tablespaces und Datendateien. Jede Datenbank ist logisch in zwei oder mehr Tabellenbereiche unterteilt. In jedem Tabellenbereich werden explizit eine oder mehrere Datendateien erstellt, um die Daten aller logischen Strukturen im Tabellenbereich physisch zu speichern. Für TEMPORÄRE Tablespaces werden keine Datendateien, sondern temporäre
-Dateien erstellt. Tabellenbereichsdatendateien können mit jeder unterstützten Speichertechnologie physisch gespeichert werden.

Tablespaces

Eine Datenbank ist in mehrere logische Speichereinheiten, sogenannte „Tablespaces“, unterteilt, die zum Gruppieren zusammengehöriger logischer Strukturen oder Datendateien verwendet werden. Beispielsweise gruppieren Tabellenbereiche normalerweise alle Segmente einer Anwendung in einer Gruppe, um einige Verwaltungsvorgänge zu vereinfachen.
Eine Datenbank ist in „Tabellenbereiche“ unterteilt, bei denen es sich um logische Speichereinheiten handelt, mit denen zusammengehörige logische Strukturen gruppiert werden können. Jede Datenbank ist logisch in zwei oder mehr Tabellenbereiche unterteilt: SYSTEM- und SYSAUX-Tabellenbereiche. In jedem Tabellenbereich werden explizit eine oder mehrere Datendateien erstellt, um die Daten aller logischen Strukturen im Tabellenbereich physisch zu speichern.
Ein Segment mit einer Größe von 160 KB erstreckt sich über zwei Datendateien und besteht aus zwei Extents. Der erste Bereich befindet sich in der ersten Datendatei und ist 64 KB groß; der zweite Bereich befindet sich in der zweiten Datendatei und ist 96 KB groß. Beide Extents bestehen aus mehreren zusammenhängenden 8-KB-Oracle-Blöcken.
Hinweis: Es ist möglich, einen großen Dateitabellenbereich zu erstellen, der nur eine Datei enthält, die normalerweise sehr groß ist. Die Datei kann die maximale Größe erreichen, die die Zeilen-ID-Architektur zulässt. Diese maximale Größe ist die Blockgröße des Tabellenbereichs multipliziert mit 236, oder wenn die Blockgröße 32 KB beträgt, beträgt die maximale Größe 128 TB. Ein herkömmlicher Tablespace für kleine Dateien (Standard) kann mehrere Datendateien enthalten, diese Dateien sind jedoch nicht sehr groß.

Datenblöcke

Oracle DB-Daten werden in „Datenblöcken“ gespeichert, die die niedrigste Granularitätsebene darstellen. Ein Datenblock entspricht einer bestimmten Anzahl Bytes physischen Speicherplatzes auf der Festplatte. Die Datenblockgröße jedes Tabellenbereichs wird beim Erstellen des Tabellenbereichs angegeben. Die Datenbank nutzt und weist freien Datenbankspeicher in Einheiten von Oracle-Datenblöcken zu.

Bezirk

Die nächste Ebene des logischen Datenbankraums ist „Bezirk“. Ein Extent ist eine bestimmte Anzahl zusammenhängender Blöcke von Oracle-Daten (die aus einer einzelnen Zuordnung stammen), die zum Speichern eines bestimmten Informationstyps verwendet werden. Oracle-Datenblöcke innerhalb eines Bereichs sind logisch zusammenhängend, können jedoch physisch an verschiedenen Stellen auf der Festplatte verteilt sein (RAID-Striping und Dateisystemimplementierungen können dieses Verhalten verursachen).

Segment

Die obere Ebene des logischen Datenbankspeicherbereichs wird als „Segment“ bezeichnet. Ein Segment ist eine Reihe von Bereichen, die einer bestimmten logischen Struktur zugeordnet sind. Zum Beispiel:
• Datensegment: Jede nicht gruppierte, nicht indexorganisierte Tabelle verfügt über ein Datensegment, mit Ausnahme externer Tabellen, globaler temporärer Tabellen und partitionierter Tabellen, die jeweils aus einem oder mehreren Teilen bestehen. Alle Daten in der Tabelle werden im Umfang des entsprechenden Datensegments gespeichert. Bei partitionierten Tabellen gibt es für jede Partition ein Datensegment. Jeder Cluster verfügt außerdem über ein Datensegment. Daten für jede Tabelle im Cluster werden im Datensegment des Clusters gespeichert.
• Indexsegment: Jeder Index verfügt über ein Indexsegment, in dem alle seine Daten gespeichert sind. Bei einem partitionierten Index gibt es für jede Partition ein Indexsegment.
• Undo-Segment: Das System erstellt für jede Datenbankinstanz einen UNDO-Tablespace. Dieser Tabellenbereich enthält eine große Anzahl von Wiederherstellungssegmenten, die zum vorübergehenden Speichern von Wiederherstellungsinformationen verwendet werden. Die Informationen im Wiederherstellungssegment werden verwendet, um lesekonsistente Datenbankinformationen zu generieren, um nicht festgeschriebene Benutzertransaktionen während der Datenbankwiederherstellung rückgängig zu machen.
• Temporäres Segment: Ein temporäres Segment wird von Oracle DB erstellt, wenn eine SQL-Anweisung einen temporären Arbeitsbereich benötigt, um die Ausführung abzuschließen. Nachdem die Ausführung der Anweisung abgeschlossen ist, wird der Umfang des temporären Segments zur zukünftigen Verwendung an die Instanz zurückgegeben. Sie können für jeden Benutzer einen temporären Standardtabellenbereich angeben oder einen temporären Standardtabellenbereich angeben, der im Rahmen der Datenbank verwendet wird.
Hinweis: Es gibt auch einige andere Arten von Segmenten, die oben nicht aufgeführt sind. Darüber hinaus gibt es einige Schemaobjekte wie Ansichten, Pakete, Trigger usw., die zwar Datenbankobjekte sind, aber nicht als Segmente gelten. Segmente verfügen über separate Speicherplatzzuweisungen. Andere Objekte werden als Zeilen im Systemmetadatensegment gespeichert.
Der Oracle DB-Server weist Speicherplatz dynamisch zu. Wenn die vorhandenen Extents im Segment voll sind, werden zusätzliche Extents hinzugefügt. Da Extents nach Bedarf zugewiesen werden, können die Extents in einem Segment auf der Festplatte benachbart sein oder auch nicht, und sie können aus verschiedenen Datendateien stammen, die zum selben Tabellenbereich gehören.

Automatic Storage Management

Automatic Storage Management (ASM) bietet eine vertikale Integration von Dateisystemen und Volume-Managern für Oracle DB-Dateien. ASM kann einen einzelnen SMP-Computer (Symmetric Multiprocessing) oder mehrere Knoten eines Clusters verwalten, um Oracle Real Application Clusters (RAC) zu unterstützen.
Oracle ASM Cluster File System (ACFS) ist eine plattformübergreifende, skalierbare Dateisystem- und Speicherverwaltungstechnologie, die die Funktionalität von ASM erweitert, um Anwendungsdateien außerhalb von Oracle DB zu unterstützen, wie z. B. ausführbare Dateien, Berichte, BFILE, Video, Audio, Text, Bilder und andere allgemeine Anwendungsdateidaten.
ASM verteilt die Eingabe-/Ausgabelast (E/A) auf alle verfügbaren Ressourcen, wodurch eine manuelle Optimierung der E/A entfällt und die Leistung optimiert wird. ASM unterstützt Datenbankadministratoren bei der Verwaltung dynamischer Datenbankumgebungen, indem es Datenbankadministratoren ermöglicht, Speicherzuteilungen anzupassen, indem sie die Größe der Datenbank erhöhen, ohne die Datenbank herunterzufahren.
ASM kann redundante Kopien von Daten verwalten, um Fehlertoleranz zu gewährleisten, oder es kann auf vom Anbieter bereitgestellten Speichermechanismen aufbauen. Die Datenverwaltung erfolgt durch die Auswahl der erforderlichen Zuverlässigkeits- und Leistungsmetriken für jeden Datentyp und nicht durch manuelle Interaktion auf Dateibasis.
Durch die Automatisierung von Speicheraufgaben, die manuell ausgeführt werden, spart die ASM-Funktionalität Datenbankadministratoren Zeit und erhöht dadurch die Möglichkeiten von Administratoren, mehr und größere Datenbanken effizienter zu verwalten.

ASM behindert keine bestehende Datenbankfunktionalität. Vorhandene Datenbanken können wie gewohnt funktionieren. Neue Dateien können als ASM-Dateien erstellt werden und vorhandene Dateien können unverändert verwaltet oder nach ASM migriert werden.
Das obige Diagramm veranschaulicht die Beziehung zwischen Oracle DB-Datendateien und ASM-Speicherkomponenten. Das Krähenfußzeichen stellt eine Eins-zu-Viele-Beziehung dar. Es besteht eine Eins-zu-Eins-Beziehung zwischen Oracle DB-Datendateien und Dateien oder ASM-Dateien, die im Dateisystem des Betriebssystems gespeichert sind.
Eine Oracle ASM-Festplattengruppe ist eine Sammlung von einer oder mehreren Oracle ASM-Festplatten, die als logische Einheit verwaltet werden. Die Datenstrukturen in der Festplattengruppe sind in sich geschlossen und nutzen einen Teil des Speicherplatzes für Metadatenanforderungen. Oracle ASM-Festplatten sind Speichergeräte, die für Oracle ASM-Festplattengruppen bereitgestellt werden und physische Festplatten, Partitionen, logische Einheitennummern (LUNs) in einem Speicherarray, logische Volumes (LVs) oder mit einem Netzwerk verbundene Dateien sein können. Jede ASM-Festplatte ist in eine Anzahl von ASM-Zuweisungseinheiten (AU) unterteilt. Dies ist die kleinste Menge an zusammenhängendem Festplattenspeicher, die ASM zuweisen kann. Wenn Sie eine ASM-Festplattengruppe erstellen, können Sie die Größe der ASM-Zuordnungseinheit je nach Kompatibilitätsgrad der Festplattengruppe auf 1, 2, 4, 8, 16, 32 oder 64 MB festlegen. Eine oder mehrere ASM-Zuteilungseinheiten bilden eine ASM-Region. Oracle ASM-Bereiche sind Rohspeicher, der zum Speichern der Inhalte von Oracle ASM-Dateien verwendet wird. Oracle ASM-Dateien bestehen aus einem oder mehreren Dateierweiterungen. Um sehr große ASM-Dateien zu unterstützen, können Extents variabler Größe verwendet werden, wobei Extent-Größen dem 1-fachen, 4-fachen und 16-fachen der AU-Größe entsprechen.

Empfohlenes Tutorial: „

Oracle Video Tutorial“

Das obige ist der detaillierte Inhalt vonDetaillierte grafische Erläuterung der Oracle-Datenbankarchitektur. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!