VM-DB-Systeme
Oracle Cloud Infrastructure (OCI) bietet DB-Systeme 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.
Wenn Sie ein DB-System für Entwicklungs- oder Testzwecke bereitstellen müssen, ist ein besonderes DB-System mit einem Knoten verfügbar.
- Oracle Database 19c: Zulässige Features, Optionen und Management Packs nach Oracle Database-Angebot
Hinweis:
Der Vorgang zum Ändern der Ausprägung erfolgt für RAC-DB-Systeme mit mehreren Knoten im Rolling-Modus, sodass Sie die Ausprägung ohne Datenbankausfallzeit ändern können.Verwandte Themen
Verfügbare Ausprägungen und deren Auswirkungen auf die Ressourcenzuweisung
Wenn Sie ein DB-System erstellen, wählen Sie eine Ausprägung aus, anhand der die Ressourcen bestimmt werden, die dem DB-System zugewiesen sind. Nachdem Sie das DB-System erstellt haben, können Sie seine Ausprägung so ändern, dass sie an neue Verarbeitungskapazitätsanforderungen angepasst wird. Folgende Ausprägungen sind verfügbar:
Flexible Ausprägungen
Über flexible Ausprägungen können Sie die Anzahl der einer Instanz zugewiesenen OCPUs anpassen. Wenn Sie eine Instanz mit einer flexiblen Ausprägung erstellen, wählen Sie die Anzahl der erforderlichen OCPUs für die Workloads aus, die auf der Instanz ausgeführt werden. So können Sie flexibel auf Ihre Workload abgestimmte Instanzen erstellen, die Performance optimieren und Kosten minimieren. Der zulässige Speicher basiert auf der Anzahl der ausgewählten OCPUs, und das Verhältnis zwischen Arbeitsspeicher und 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.
Tabelle -: Flexible Ausprägungen
| Form | CPU Cores | Speicher | Netzwerkbandbreite |
|---|---|---|---|
| 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. |
1 Gbit/s pro OCPU. Mindestens 1 Gbp/s und maximal 40 Gbp/s Netzwerkbandbreite. |
| AMD VM.Standard.E5. FlexFeld | Mindestens 1 OCPU und maximal 64 OCPUs. |
16 GB pro OCPU. Mindestens 16 GB und maximal 1024 GB Gesamtarbeitsspeicher. |
1 Gbit/s pro OCPU. Mindestens 1 Gbp/s und maximal 40 Gbp/s Netzwerkbandbreite. |
| AMD VM.Standard.E4.Flex | Mindestens 1 OCPU und maximal 64 OCPUs. |
16 GB pro OCPU. Mindestens 16 GB und maximal 1024 GB Gesamtarbeitsspeicher. |
1 Gbit/s pro OCPU. Mindestens 1 Gbp/s und maximal 40 Gbp/s Netzwerkbandbreite. |
| Intel X9 VM.Standard3.Flex | Mindestens 1 OCPU und maximal 32 OCPUs. |
16 GB pro OCPU. Mindestens 16 GB und maximal 512 GB Gesamtarbeitsspeicher. |
1 Gbit/s pro OCPU. Mindestens 1 Gbp/s und maximal 32 Gbp/s Netzwerkbandbreite. |
Hinweis:
- Die ARM-basierte Ampere A1-Ausprägung ist nur für die Oracle Database-Versionen 23ai und 19c ab 23.7.0.0, 19.19.0.0 und späteren Releaseupdates (RU) verfügbar.
- Die AMD-Ausprägung E5 ist nur für Oracle Database-Versionen 23ai und 19c ab 23.4.0.24.05, 19.21.0.0 und höher verfügbar Releaseupdates (RU).
- Die Ausprägung AMD E4 ist nur für die Oracle Database-Versionen 23ai, 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-Ausprägung X9 ist nur für die Oracle Database-Versionen 23ai, 21c und 19c mit den Releaseupdates 23.4.0.24.05, 21.8.0.0, 19.17.0.0 und höher (RU) verfügbar.
- Für RAC-DB-Systeme mit mehreren Knoten sind mindestens zwei OCPUs pro Knoten erforderlich.
Arm-basierte Ampere A1-Ausprägung
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-Ausprägung A1 wird nur auf DB-Systemen mit einem Knoten unterstützt.
- Oracle Database Standard Edition wird auf ausprägungsbasierten Ampere-DB-Systemen A1 nicht unterstützt.
- Ein Datenbanksoftwareimage kann nicht zum Erstellen einer Datenbank auf ausprägungsbasierten Ampere A1-DB-Systemen verwendet werden.
- Provisioning und Wiederherstellung 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 der Ampere-A1-ausprägungsbasierten DB-Systeme kann nicht in ausprägungsbasierte Intel- oder AMD-DB-Systeme geändert werden und umgekehrt.
- Ein Backup einer Ampere-A1-ausprägungsbasierten Datenbank kann auf ausprägungsbasierten Intel- oder AMD-DB-Systemen nicht wiederhergestellt werden und umgekehrt.
- Auf Ampere A1-Ausprägungen basierende DB-Systeme 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.
Tabelle -: Verfügbare VM-Ausprägungen der X7-Serie
| Form | CPU Cores | Speicher |
|---|---|---|
| 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 Database-Versionen 23ai, 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. Für jede Ausprägung sind die aktuelle Version und die beiden vorherigen Releaseversionen beim Provisioning mit den folgenden Spezifikationen verfügbar.
- Die ARM-basierte Ampere A1-Ausprägung ist nur für die Oracle Database-Versionen 23ai und 19c ab 23.7.0.0, 19.19.0.0 und späteren Releaseupdates (RU) verfügbar.
- Die AMD-Ausprägung E5 ist nur für Oracle Database-Versionen 23ai und 19c ab 23.4.0.24.05, 19.21.0.0 und höher verfügbar Releaseupdates (RU).
- Die Ausprägung AMD E4 ist nur für die Oracle Database-Versionen 23ai, 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-Ausprägung X9 ist nur für die Oracle Database-Versionen 23ai, 21c und 19c mit den Releaseupdates 23.4.0.24.05, 21.8.0.0, 19.17.0.0 und höher (RU) verfügbar.
- Intel X7-Ausprägungen sind nur für die Oracle Database-Versionen 23ai, 21c und 19c verfügbar.
- Die Migration von der Intel-Ausprägung X9 in die AMD-Ausprägungen E4 und E5 wird nicht unterstützt.
- Die Migration zur AMD-Ausprägung E4 wird nur für Instanzen unterstützt, die das Basisimage mit den 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-Ausprägung X9 wird nur für Instanzen unterstützt, die das Basisimage mit den Releaseupdates 21.8.0.0, 19.17.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.
Wenn Sie ein DB-System mit einer älteren Datenbankversion erstellen müssen, finden Sie unter Kritische Patchupdates Informationen zu bekannten Sicherheitsproblemen mit der ausgewählten Datenbankversion. Sie müssen auch bekannte Sicherheitsprobleme für das Betriebssystem analysieren und patchen, das im Lieferumfang der älteren Datenbankversion enthalten ist. Informationen zu den 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.
Verfügbarer Datenspeicher für flexible Ausprägungen
Tabelle -: Verfügbarer Datenspeicher für flexible Ausprägungen
| Verfügbarer Datenspeicher (GB) | Recovery-Bereichsspeicher (GB) | Gesamtspeicherplatz (GB) |
|---|---|---|
| 256 | 256 | 712 |
| 512 | 256 | 968 |
| 1024 | 512 | 1736 |
| 2048 | 512 | 2760 |
| 4096 | 1024 | 5320 |
| 8192 | 2048 | 10440 |
| 12288 | 4096 | 16584 |
| 16384 | 4096 | 20680 |
| 24576 | 8192 | 32968 |
| 32768 | 8192 | 41160 |
| 40960 | 10240 | 51400 |
| 49152 | 12288 | 61640 |
| 57344 | 14336 | 71880 |
| 65536 | 16384 | 82120 |
| 73728 | 18432 | 92360 |
| 81920 | 20480 | 102600 |
Verfügbarer Datenspeicher für Standardausprägungen
Tabelle -: Verfügbarer Datenspeicher für Standardausprägungen
| Verfügbarer Datenspeicher (GB) | Recovery-Bereichsspeicher (GB) | Gesamtspeicherplatz (GB) |
|---|---|---|
| 256 | 256 | 712 |
| 512 | 256 | 968 |
| 1024 | 256 | 1480 |
| 2048 | 408 | 2656 |
| 4096 | 820 | 5116 |
| 6144 | 1228 | 7572 |
| 8192 | 1640 | 10032 |
| 10240 | 2048 | 12488 |
| 12288 | 2456 | 14944 |
| 14336 | 2868 | 17404 |
| 16384 | 3276 | 19860 |
| 18432 | 3688 | 22320 |
| 20480 | 4096 | 24776 |
| 22528 | 4504 | 27232 |
| 24576 | 4916 | 29692 |
| 26624 | 5324 | 32148 |
| 28672 | 5736 | 34608 |
| 30720 | 6144 | 37064 |
| 32768 | 6552 | 39520 |
| 34816 | 6964 | 41980 |
| (36864) | 7372 | 44436 |
| 38912 | 7784 | 46896 |
| 40960 | 8192 | 49352 |
Servicelimits
Die folgenden Limits gelten für die Base Database-Ressourcen.
Tabelle - Servicelimits
| 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:
Der gesamte VM-DB-Blockspeicher umfasst den Blockspeicher für alle VM-Datenbanken VM.Standard1 und VM.Standard2.Option für schnelles Provisioning
Für DB-Systeme mit einem Knoten stellt OCI die Option "Schnelles Provisioning" bereit, mit der Sie ein DB-System mit Logical Volume Manager (LVM) als Speicherverwaltungssoftware erstellen können. 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.
- RAC-DB-Systeme mit mehreren Knoten 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.
Überlegungen zur Speicherskalierung bei der Verwendung von schnellem Provisioning
Hinweis:
Dieses Thema gilt nur für 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 für 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:
Tabelle -: Überlegungen zur Speicherskalierung bei Verwendung von schnellem Provisioning
| Anfänglicher Speicherplatz, der beim Provisioning angegeben wurde (GB) | Maximaler Speicherplatz, der für Skalierung verfügbar ist (GB) |
|---|---|
| 256 | 2560 |
| 512 | 2560 |
| 1024 | 5120 |
| 2048 | 10240 |
| 4096 | 20480 |
| 8192 | 40960 |
Ü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 mit mehreren 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 müssen. Wenn eine solche Wartung erforderlich ist, plant OCI einen Neustart Ihres DB-Systemknoten und benachrichtigt Sie über den nächsten Neustart. Durch den Neustart kann der DB-Systemknoten zu einem neuen physischen Host migriert werden, der nicht verwaltet werden muss. (Durch Stoppen und Starten wird der Knoten ebenfalls zu einem neuen physischen Host migriert.) Die einzige Auswirkung auf den DB-Systemknoten ist der Neustart selbst. Die geplante Wartung der ursprünglichen physischen Hardware erfolgt nach der Knotenmigration zum neuen Host und hat keine Auswirkung 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 zur 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 für Ihr DB-System keine Knotenwartungsereignisse 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 mit dem nächsten geplanten Knotenneustart beginnt.
Mit einer vordefinierten Abfrage im Suchservice können Sie alle DB-Systeme suchen, für die ein Neustart der Wartung geplant wurde.
Anweisungen zum Neustart eines Knoten mit der Konsole finden Sie unter DB-System neu starten.
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.
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.