DB-Systeme
Oracle Cloud Infrastructure (OCI) bietet DB-Systeme auf virtuellen Maschinen.
Es gibt zwei Typen von Datenbanksystemen (DB-Systemen) auf virtuellen Maschinen:
- DB-System mit einem Knoten: Ein DN-System mit einem Knoten besteht aus einer virtuellen Maschine.
- RAC-DB-System mit mehreren Knoten: Ein DB-System mit zwei Knoten besteht aus zwei virtuellen Maschinen.
Sie müssen ein DB-System für Entwicklungs- oder Testzwecke bereitstellen, ist ein spezielles Fast-Provisioning-DB-System mit einem Knoten verfügbar.
Wenn Sie ein DB-System erstellen, wählen Sie die Oracle AI Database-Edition und -Version, die auf die Datenbank in diesem DB-System angewendet werden. Sie können die ausgewählte Edition nicht ändern. Abhängig von der ausgewählten Oracle AI Database-Edition und -Version kann Ihr DB-System mehrere integrierbare Datenbanken (PDBs) unterstützen. Weitere Informationen über die maximale Anzahl an integrierbaren Datenbanken und Containerdatenbanken (CDBs), die für Ihre ausgewählte Oracle AI Database-Version verfügbar ist, findest du im folgenden Thema zur Lizenzierung von Oracle AI Database.
- Oracle Database 19c: Zulässige Features, Optionen und Management Packs nach Oracle AI Database-Angebot
Ein DB-System kann nur ein einziges Datenbank-Home aufweisen, das wiederum nur eine einzige Datenbank enthalten kann. Eine DB-Systemdatenbank verwendet OCI-Blockspeicher anstelle des lokalen Speichers. Sie geben beim Erstellen des DB-Systems eine Speichergröße an. Sie können den Speicher jederzeit nach Bedarf vertikal skalieren. Um die Anzahl der CPU-Cores auf einem vorhandenen DB-System zu ändern, müssen Sie die Ausprägung dieses DB-Systems ändern. Weitere Informationen finden Sie unter Ausprägung eines DB-Systems verändern.
Hinweis: Der Vorgang zur Änderung der Ausprägung erfolgt im Rolling-Modus für RAC-DB-Systeme mit mehreren Knoten, sodass Sie die Ausprägung ohne Datenbankausfallzeit ändern kann.
Verfügbare Ausprägungen und deren Auswirkungen auf die Ressourcenzuweisung
Wenn Sie ein DB-System erstellen, wählen Sie eine Ausprägung aus, mit der die Ressourcen bestimmt werden, die dem DB-System zugewiesen ist. Nachdem Sie das DB-System erstellt haben, können Sie seine Ausprägung ändern, um sich an neue Anforderungen an die Verarbeitungskapazität anzupassen. Folgende Ausprägungen sind verfügbar:
Hinweis:
Oracle Base Database Service hat mit Wirkung zum 31. Juli 2026 die Einstellung der VM.Standard.x86-Ausprägung, der Enterprise Edition - Extreme Performance-(EE-EP-)Softwareedition und der OCPU-abhängigen Service-SKUs bekannt gegeben. Vorhandene Deployments werden weiterhin ausgeführt, aber neue Provisioning- und Vertragsverlängerungen sind davon betroffen.
Planen Sie gegebenenfalls die Migration zu VM.BaseDB.x86 mit der ECPU-Metrik oder zu Oracle Exadata Database Service on Exascale Infrastructure (ExaDB-XS) für EE-EP-Workloads. Informationen zu betroffenen SKUs, Kundenauswirkungen und Migrationsrichtlinien finden Sie unter Artikel zu My Oracle Support KB921246.
Flexible Ausprägungen
Mit flexiblen Ausprägungen können Sie die Compute-Ressourcen anpassen - ECPUs oder OCPUs, die einer Instanz zugewiesen sind. Wenn Sie Eine Instanz mit einer flexiblen Ausprägung erstellen, wählen Sie die erforderliche Compute-Ressource für die Workloads, die auf der Instanz ausgeführt werden. Mit dieser Flexibilität können Sie Instanzen erstellen, die Ihrer Workload entsprechen. So können Sie die Performance optimieren und Kosten minimieren. Die zulässige Arbeitsspeichermenge basiert auf der Anzahl der ausgewählten ECPUs oder OCPUs, und das Verhältnis von Arbeitsspeicher zu ECPUs oder OCPUs hängt von der Ausprägung ab.
Flexible Ausprägungen sind mit Ampere-, AMD- und Intel-Prozessoren verfügbar. In der folgenden Tabelle sind die verfügbaren Ausprägungen aufgeführt.
| Ausprägung | Berechnen | Arbeitsspeicher |
|---|---|---|
| VM.BaseDB.x86 | Der Mindestwert beträgt 4 ECPUs und der Höchstwert 256 ECPUs. Sollte in Schritten von 4 angegeben werden. |
8 GB für alle 4 ECPUs. Mindestens 8 GB und maximal 512 GB Gesamtarbeitsspeicher. |
| VM.Standard.x86 | Der Mindestwert beträgt 4 ECPUs und der Höchstwert 252 ECPUs. Sollte in Schritten von 4 angegeben werden. |
8 GB für alle 4 ECPUs. Mindestens 8 GB und maximal 504 GB Gesamtarbeitsspeicher. |
| Ampere VM.Standard.A1. FlexFeld | Der Mindestwert beträgt 1 OCPU und der Höchstwert 57 OCPUs. | 8 GB pro OCPU. Mindestens 8 GB und maximal 456 GB Gesamtarbeitsspeicher. |
| AMD VM.Standard.E5. Flexibel | Der Mindestwert beträgt 1 OCPU und der Höchstwert 64 OCPUs. | 16 GB pro OCPU. Mindestens 16 GB und maximal 1024 GB Gesamtarbeitsspeicher. |
| AMD VM.Standard.E4.Flex | Der Mindestwert beträgt 1 OCPU und der Höchstwert 64 OCPUs. | 16 GB pro OCPU. Mindestens 16 GB und maximal 1024 GB Gesamtarbeitsspeicher. |
| Intel X9 VM.Standard3.Flex | Der Mindestwert beträgt 1 OCPU und der Höchstwert 32 OCPUs. | 16 GB pro OCPU. Mindestens 16 GB und maximal 512 GB Gesamtarbeitsspeicher. |
Hinweis:
- ARM-basierte Ampere A1-Ausprägung ist nur für Oracle AI Database-Versionen 26ai und 19c verfügbar, beginnend mit 23.7.0.0, 19.19.0.0 und späteren Releaseupdates (RU).
- Die AMD E5-Ausprägung ist nur für Oracle AI Database-Versionen 26ai und 19c ab Version 23.4.0.24.05, 19.21.0.0 und höher als Releaseupdates (RU) verfügbar.
- Die AMD E4-Ausprägung ist nur für die Oracle AI Database-Versionen 26ai, 21c und 19c mit den Releaseupdates (RU) 23.4.0.24.05, 21.6.0.0, 19.15.0.0 und höher verfügbar.
- Die Intel X9-Ausprägung ist nur für die Oracle AI Database-Versionen 26ai, 21c und 19c mit den Releaseupdates (RU) 23.4.0.24.05, 21.8.0.0, 19.17.0.0 und höher verfügbar.
- Für RAC-DB-Systeme mit mehreren Knoten sind mindestens zwei OCPUs pro Knoten erforderlich.
Generation-Agnostische X86-Form
Die Ausprägung VM.BaseDB.x86 und die Ausprägung VM.Standard.x86 sind generationsunabhängige, flexible x86-Ausprägungen, mit denen Sie die Anzahl der einem DB-System zugewiesenen ECPUs anpassen können. Diese Ausprägungen bieten eine konsistente Erfahrung über unterstützte x86-Infrastrukturgenerationen hinweg und ermöglichen es Ihnen, Compute-Ressourcen basierend auf Workload-Anforderungen zu skalieren.
Die x86-Ausprägungen weisen folgende Eigenschaften auf:
- Verwenden Sie die ECPU-basierte Abrechnung, um eine detailliertere, nutzungsbasierte Preisgestaltung zu ermöglichen.
- VM.BaseDB.x86 unterstützt Oracle AI Database 26ai und Oracle Database 19c.
- VM.Standard.x86 unterstützt nur Oracle AI Database 26ai.
-
Unterstützen Sie die folgenden Oracle AI Database-Softwareeditionen:
- Standard Edition
- Enterprise Edition
- Enterprise Edition - High Performance
- Unterstützen Sie Logical Volume Manager für die Speicherverwaltung.
- Nur DB-Systeme mit einem Knoten unterstützen.
Hinweis: Die x86-Ausprägungen unterstützen keine Faultdomain.
Arm-basierte Ampere A1-Form
ARM-basierte Ampere A1-Ausprägungen sind flexibel und ermöglichen es Ihnen, die Anzahl der einer Instanz zugewiesenen OCPUs anzupassen. Im Folgenden finden Sie einige zusätzliche Details zu Ampere A1-Ausprägungen:
- Ampere A1-Ausprägung wird nur in Logical Volume Manager unterstützt.
- Die Ampere A1-Ausprägung wird nur auf DB-Systemen mit einem Knoten unterstützt.
- Oracle AI Database Standard Edition wird auf Ausprägungs-basierten DB-Systemen von Ampere A1 nicht unterstützt.
- Ein Datenbanksoftwareimage kann nicht zum Erstellen einer Datenbank auf ausprägungsbasierten DB-Systemen von Ampere A1 verwendet werden.
- Provisioning und Restore des ausprägungsbasierten DB-Systems von Ampere A1 werden nicht unterstützt, wenn das Backupziel für die Datenbank der Autonomous Recovery Service ist.
- Die Ampere A1-Ausprägung wird für Datenbanken, die OCI Vault-Verschlüsselung verwenden, nicht unterstützt.
- Die Ausprägung von DB-Systemen mit Ampere-A1-Ausprägung kann nicht in DB-Systeme mit Intel- oder AMD-Ausprägung geändert werden, und umgekehrt.
- Ein Backup einer Ampere A1-ausprägungsbasierten Datenbank kann auf DB-Systemen mit Intel- oder AMD-Ausprägung nicht wiederhergestellt werden und umgekehrt.
- DB-Systeme mit Ampere-A1-Ausprägung unterstützen keine Data Guard-Verknüpfungen mit ausprägungsbasierten Intel- oder AMD-DB-Systemen.
Standardausprägungen
Standardausprägungen sind mit Intel-Prozessoren verfügbar.
In der folgenden Tabelle sind die verfügbaren Ausprägungen in der X7-Serie aufgeführt.
| Ausprägung | CPU-Cores | Arbeitsspeicher |
|---|---|---|
| VM.Standard2.1 | 1 | 15 GB |
| VM.Standard2.2 | 2 | 30 GB |
| VM.Standard2.4 | 4 | 60 GB |
| VM.Standard2.8 | 8 | 120 GB |
| VM.Standard2.16 | 16 | 240 GB |
| VM.Standard2.24 | 24 | 320 GB |
Hinweis:
- Intel X7-Ausprägungen sind nur für die Oracle AI Database-Versionen 26ai, 21c und 19c verfügbar.
- Die Ausprägung VM.Standard2.1 kann nicht für RAC-DB-Systeme mit mehreren Knoten verwendet werden.
Verfügbare Datenbankversionen
OCI unterstützt die Erstellung von DB-Systemen mit älteren Datenbankversionen, vorbehaltlich der folgenden Ausprägungsanforderungen.
Das letzte genehmigte Releaseupdate ist standardmäßig verfügbar. Sie können auch eine der beiden vorherigen Releaseupdates (N-1 oder N-2) auswählen, nachdem Sie die angezeigte Meldung bestätigt haben. Um ein Releaseupdate zu verwenden, das älter als N-2 ist, müssen Sie eine Serviceanfrage einreichen.
- ARM-basierte Ampere A1-Ausprägung ist nur für Oracle AI Database-Versionen 26ai und 19c verfügbar, beginnend mit 23.7.0.0, 19.19.0.0 und späteren Releaseupdates (RU).
- Die AMD E5-Ausprägung ist nur für Oracle AI Database-Versionen 26ai und 19c ab Version 23.4.0.24.05, 19.21.0.0 und höher als Releaseupdates (RU) verfügbar.
- Die AMD E4-Ausprägung ist nur für die Oracle AI Database-Versionen 26ai, 21c und 19c mit den Releaseupdates (RU) 23.4.0.24.05, 21.6.0.0, 19.15.0.0 und höher verfügbar.
- Die Intel X9-Ausprägung ist nur für die Oracle AI Database-Versionen 26ai, 21c und 19c mit den Releaseupdates (RU) 23.4.0.24.05, 21.8.0.0, 19.17.0.0 und höher verfügbar.
- Intel X7-Ausprägungen sind nur für die Oracle AI Database-Versionen 26ai, 21c und 19c verfügbar.
- Die Migration von Intel X9-Ausprägungen auf AMD E4- und E5-Ausprägungen wird nicht unterstützt.
- Die Migration zu AMD E4-Ausprägungen wird nur für Instanzen unterstützt, die das Basisimage mit dem Releaseupdates 21.6.0.0, 19.15.0.0 und höher verwenden. Instanzen, die vor diesen Releaseupdates erstellt wurden, können nicht aktualisiert und migriert werden, da das Basisimage selbst keine Migration unterstützt.
- Die Migration zur Intel X9-Ausprägung wird nur für Instanzen unterstützt, die das Basisimage mit 21.8.0.0-, 19.17.0.0- und späteren Releaseupdates verwenden. Instanzen, die vor diesen Releaseupdates erstellt wurden, können nicht aktualisiert und migriert werden, da das Basisimage selbst keine Migration unterstützt.
Wenn Sie ein DB-System mit einer älteren Datenbankversion erstellen müssen, finden Sie unter Kritische Patchupdates Informationen über bekannte Sicherheitsprobleme mit einer ausgewählten Datenbankversion. Sie müssen auch bekannte Sicherheitsprobleme für das Betriebssystem analysieren und patchen, die im Lieferumfang der älteren Datenbankversion enthalten sind. Informationen zu Best Practices zur Sicherheit für Datenbanken in OCI finden Sie unter Datenbanken sichern.
Auswirkungen verschiedener Konfigurationen auf den nutzbaren Speicher
Die DB-Systeme verwenden OCI-Blockspeicher. In der folgenden Tabelle sind Details der verfügbaren Speicheroptionen aufgeführt. Der Gesamtspeicherplatz umfasst den verfügbaren Speicherplatz plus die Recovery-Logs.
Allgemeine Informationen
- Sie können den Datenspeicher und Recovery-Speicher separat skalieren. Oracle empfiehlt, dass Sie den Recovery-Speicher stets auf mindestens 20% des Gesamtspeicherplatzes setzen.
- Bei RAC-DB-Systemen mit mehreren Knoten wird die Speicherkapazität von den Knoten gemeinsam verwendet.
- Der Recovery-Bereichsspeicher wird basierend auf dem ausgewählten Speicher bestimmt. Sie können den Recovery-Bereichsspeicher jedoch nach dem Provisioning unabhängig ändern.
- Der Gesamtspeicher ist die Summe aus verfügbarem Datenspeicher, Recovery-Bereichsspeicher und 200 GB, die für die DB-Systemsoftware reserviert sind.
Verfügbarer Datenspeicher für flexible Ausprägungen
| Verfügbarer Datenspeicher (GB) | Recovery-Bereichsspeicher (GB) | Gesamtspeicherplatz (GB) |
|---|---|---|
| 256 | 256 | 712 |
| 512 | 256 | 968 |
| 1.024 | 512 | 1.736 |
| 2.048 | 512 | 2.760 |
| 4.096 | 1.024 | 5.320 |
| 8.192 | 2.048 | 10.440 |
| 12.288 | 4.096 | 16.584 |
| 16.384 | 4.096 | 20.680 |
| 24.576 | 8.192 | 32.968 |
| 32.768 | 8.192 | 41.160 |
| 40.960 | 10.240 | 51.400 |
| 49.152 | 12.288 | 61.640 |
| 57.344 | 14.336 | 71.880 |
| 65.536 | 16.384 | 82.120 |
| 73.728 | 18.432 | 92.360 |
| 81.920 | 20.480 | 102.600 |
Verfügbarer Datenspeicher für Standardausprägungen
| Verfügbarer Datenspeicher (GB) | Recovery-Bereichsspeicher (GB) | Gesamtspeicherplatz (GB) |
|---|---|---|
| 256 | 256 | 712 |
| 512 | 256 | 968 |
| 1.024 | 256 | 1.480 |
| 2.048 | 408 | 2.656 |
| 4.096 | 820 | 5.116 |
| 6.144 | 1.228 | 7.572 |
| 8.192 | 1.640 | 10.032 |
| 10.240 | 2.048 | 12.488 |
| 12.288 | 2.456 | 14.944 |
| 14.336 | 2.868 | 17.404 |
| 16.384 | 3.276 | 19.860 |
| 18.432 | 3.688 | 22.320 |
| 20.480 | 4.096 | 24.776 |
| 22.528 | 4.504 | 27.232 |
| 24.576 | 4.916 | 29.692 |
| 26.624 | 5.324 | 32.148 |
| 28.672 | 5.736 | 34.608 |
| 30.720 | 6.144 | 37.064 |
| 32.768 | 6.552 | 39.520 |
| 34.816 | 6.964 | 41.980 |
| 36.864 | 7.372 | 44.436 |
| 38.912 | 7.784 | 46.896 |
| 40.960 | 8.192 | 49.352 |
Servicelimits
Die folgenden Limits gelten für die Base Database-Ressourcen.
| Ressourcen | Oracle Universal Credits | Pay-as-you-go oder Testversion |
|---|---|---|
| VM-DB-Blockspeicher gesamt | 150TB | 2TB |
| VM.Standard1 - OCPUs gesamt | 300 Kerne | 2 Kerne |
| VM.Standard2 - OCPUs gesamt | 300 Kerne für US West (Phoenix), 300 Kerne für US East (Ashburn), 50 Kerne für Germany Central (Frankfurt), 50 Kerne für UK South (London) |
2 Kerne |
Hinweis: VM-DB-Blockspeicher gesamt umfasst Blockspeicher für alle VM.Standard1- und VM.Standard2-Virtual-Machine-Datenbanken.
Option für schnelles Provisioning
Bei DB-Systemen mit einem einzigen Knoten stellt OCI die Option "Schnelles Provisioning" bereit, mit der Sie ein DB-System mit Logical Volume Manager (LVM) als Speicherverwaltungssoftware erstellen. Die Standardmethode ("Standard-Provisioning") ist das Provisioning mit Automatic Storage Management (ASM).
Die folgenden Details gelten für die Option für schnelles Provisioning:
- Wenn Sie die Option für schnelles Provisioning verwenden, bestimmen die Anzahl und die Größe der Block-Volumes, die beim Provisioning angegeben werden, den maximalen Gesamtspeicher, der für Skalierung verfügbar ist.
- Multi-Knoten-RAC-DB-Systeme erfordern ASM und können nicht mit der Option für schnelles Provisioning erstellt werden.
- DB-Systeme, die mit der Option für schnelles Provisioning erstellt wurden, können geklont werden.
- Sie können kein benutzerdefiniertes Datenbanksoftwareimage verwenden, wenn Sie ein DB-System mit LVM bereitstellen.
Weitere Informationen:
Überlegungen zur Speicherskalierung bei der Verwendung von schnellem Provisioning
Hinweis: Dieses Thema gilt nur für VM-DB-Systeme mit einem Knoten.
Wenn Sie ein DB-System mit der Option für schnelles Provisioning bereitstellen, bestimmt der Wert Verfügbarer Speicher (GB), den Sie beim Provisioning angeben, den maximalen Gesamtspeicher, der durch Skalierung verfügbar ist. In der folgenden Tabelle wird der maximal für die Skalierung verfügbare Speicherwert für die einzelnen Einstellungen im Provisioning-Workflow angegeben:
| Anfänglicher Speicherplatz, der beim Provisioning angegeben wurde (GB) | Maximaler Speicherplatz, der für Skalierung verfügbar ist (GB) |
|---|---|
| 256 | 2.560 |
| 512 | 2.560 |
| 1.024 | 5.120 |
| 2.048 | 10.240 |
| 4.096 | 20.480 |
| 8.192 | 40.960 |
Überlegungen zu Faultdomains bei RAC-DB-Systemen mit mehreren Knoten
Wenn Sie ein RAC-DB-System mit mehreren Knoten bereitstellen, weist das System standardmäßig jedem Knoten eine andere Faultdomain zu. Mit dem Link Erweiterte Optionen im Provisioning-Dialogfeld können Sie die Faultdomains auswählen, die für RAC-DB-Systeme, die für mehrere Knoten verwendet werden sollen. Das System weist die Knoten dann den ausgewählten Faultdomains zu. Oracle empfiehlt, jeden Knoten eines RAC-DB-Systems mit mehreren Knoten in einer anderen Faultdomain abzulegen.
Weitere Informationen zu Faultdomains finden Sie unter Regionen und Availability-Domains.
DB-Systemknoten für geplante Wartung neu starten
Die DB-Systemknoten verwenden zugrunde liegende physische Hosts, die regelmäßig gewartet werden. Wenn ein derartiger Wartungsaufwand erforderlich ist, plant OCI einen Neustart Ihres DB-Systemknotens und benachrichtigt Sie über den bevorstehenden Neustart. Durch den Neustart kann die DB-Systemknoten zu einem neuen physischen Host migriert werden, der nicht gewartet wird. (Durch Stoppen und Starten wird der Knoten ebenfalls zu einem neuen physischen Host migriert.) Die einzige Wirkung auf den DB-Systemknoten ist der Neustart selbst. Die geplante Wartung der ursprünglichen physischen Hardware erfolgt nach dem Migrieren des Knotens zum neuen Host und hat keine Wirkung auf das DB-System.
Wenn für Ihr DB-System ein Wartungsneustart geplant ist, können Sie den Knoten mit der Konsole oder der API proaktiv neu starten (indem Sie ihn stoppen und starten). So können Sie kontrollieren, wie und wann Ihr Knoten ausfällt. Wenn Sie den Knoten nicht vor der geplanten Zeit neu starten, startet OCI den Knoten zur geplanten Zeit neu und migriert ihn.
Um die DB-Systemknoten zu ermitteln, die Sie proaktiv neu starten können, navigieren Sie in der Konsole auf die Seite DB-Systemdetails des Systems, und prüfen Sie das Feld Knotenwartungsneustart. Wenn für die Instanz ein Wartungsneustart geplant ist und der Neustart proaktiv durchgeführt werden kann, werden in diesem Feld Datum und Uhrzeit für den Neustart angezeigt. Wenn im Feld Wartungsneustart kein Datum angezeigt wird, sind keine Knotenwartungsereignisse für Ihr DB-System geplant.
Um mit der API nach geplanten Wartungsereignissen zu suchen, prüfen Sie mit dem Vorgang GetDbNode das Feld timeMaintenanceWindowEnd der Ressource DbNode. In diesem Feld wird angegeben, wann das System den nächsten geplanten Knotenneustart startet.
Um die Suche nach Knoten zu erleichtern, die geplante Wartungsneustarts aufweisen, können Sie mit dem Suchservice anhand einer vordefinierten Abfrage alle DB-Systeme suchen, die einen geplanten Wartungsneustart aufweisen.
Anweisungen zum Neustarten eines Knotens mit der Konsole finden sie unter DB-System neu booten.
Tool zur Sicherheitshärtung für DB-Systeme
Mit Oracle Linux 7 bereitgestellte DB-Systeme umfassen ein Python-Skript, das als STIG-Tool (Security Technical Implementation Guide) bezeichnet wird. Damit können Sie die Sicherheitshärtung für Ihr DB-System durchführen.
Weitere Informationen:
- Security Technical Implementation Guide-(STIG-)Tool für das DB-System.
- FIPS, SE Linux und STIG in den DB-Systemkomponenten aktivieren.
Boot-Volume-Backups
Oracle führt ein wöchentliches Boot-Volume-Backup des DB-Systems durch, sodass das System bei schwerwiegenden Fehlern oder Systemausfall problemlos wiederhergestellt werden kann. Benutzer können derzeit nicht auf Boot-Volume-Backups zugreifen (kein Zugriff über Konsole, API oder CLI auf ein Boot-Volume-Backup für ein DB-System). Oracle trägt die Kosten für die Aufbewahrung und Verwaltung des Backups. Wenden Sie sich bei einem Systemfehler an My Oracle Support, um eine Wiederherstellung Ihres DB-Systems aus dem Boot-Volume-Backup anzufordern.