Oracle Database und Autonomous Database: die Zielentscheidung

Drei Oracle-Datenbanken, bewertet

Eine für diese Seite geschriebene Demo-Umgebung, bewertet am 4. November 2026: ein DB-System mit zwei Knoten und zwei Autonomous Databases, eine für Transaktionen und eine für Analysen. Links die Eingabe, rechts die Entscheidung, die der Lauf festgehalten hat, wie sie in assessment.json steht. Da assessment.json in einer einzigen Zeile geschrieben ist, zeigt der Ausschnitt ausgewählte Felder jeder Einheit, eingerückt und so verschachtelt wie in der Datei, mit unveränderten Werten.

resource "oci_database_db_system" "erp" {
  compartment_id          = var.compartment_id
  availability_domain     = var.availability_domain
  subnet_id               = oci_core_subnet.db.id
  hostname                = "erpdb"
  shape                   = "VM.Standard.E5.Flex"
  database_edition        = "ENTERPRISE_EDITION"
  license_model           = "LICENSE_INCLUDED"
  node_count              = 2
  data_storage_size_in_gb = 512
  ssh_public_keys         = ["ssh-rsa AAAAexample"]
  display_name            = "erp"

  db_home {
    db_version   = "19.0.0.0"
    display_name = "erp-home"

    database {
      admin_password = var.db_admin_password
      db_name        = "ERP"
      character_set  = "AL32UTF8"
    }
  }
}

resource "oci_database_autonomous_database" "orders" {
  compartment_id           = var.compartment_id
  db_name                  = "ORDERS"
  display_name             = "orders"
  db_workload              = "OLTP"
  admin_password           = var.db_admin_password
  compute_model            = "ECPU"
  compute_count            = 4
  data_storage_size_in_tbs = 1
  license_model            = "LICENSE_INCLUDED"
}

resource "oci_database_autonomous_database" "reporting" {
  compartment_id           = var.compartment_id
  db_name                  = "REPORTING"
  display_name             = "reporting"
  db_workload              = "DW"
  admin_password           = var.db_admin_password
  compute_model            = "ECPU"
  compute_count            = 2
  data_storage_size_in_tbs = 2
  license_model            = "BRING_YOUR_OWN_LICENSE"
}

[
  {
    "id": "oci_database_db_system.erp",
    "result": {
      "class": "REDESIGN",
      "confidence": "LOW",
      "reason": "STACKIT has no Oracle Database service. Decide whether the database changes engine, with a schema and procedure conversion, or stays on self-managed Oracle under your own licence."
    }
  },
  {
    "id": "oci_database_autonomous_database.orders",
    "result": {
      "class": "REDESIGN",
      "confidence": "LOW",
      "reason": "STACKIT has no Oracle Database service. Decide whether the database changes engine, with a schema and procedure conversion, or stays on self-managed Oracle under your own licence."
    }
  },
  {
    "id": "oci_database_autonomous_database.reporting",
    "result": {
      "class": "REDESIGN",
      "confidence": "LOW",
      "reason": "STACKIT has no Oracle Database service. Decide whether the database changes engine, with a schema and procedure conversion, or stays on self-managed Oracle under your own licence."
    }
  }
]

• REDESIGN, niedrige Konfidenz, kein Ziel

  Alle drei sind REDESIGN mit niedriger Konfidenz und schlagen keinen STACKIT-Dienst vor. Die Begründung ist jeweils dieselbe: Die Wahl liegt zwischen neuer Engine und selbst betriebenem Oracle.

• Nur das Netzwerk ist zugeordnet

  Von den 5 Einheiten im Lauf sind VCN und Subnetz RECONFIGURE mit mittlerer Konfidenz. Jede offene Entwurfsentscheidung dieser Umgebung betrifft die drei Datenbanken.

• Die Einstellungen, an denen die Entscheidung hängt

  Der Bericht überlässt Ihnen 16 kritische Einstellungen des DB-Systems, darunter Edition, Knotenzahl, Speichergröße und die Referenz auf das Administrator-Passwort, und je 9 für die Autonomous Databases, darunter Compute-Modell und -Anzahl sowie Speicher in Terabyte.

Die Optionen nebeneinander

Drei Wege, einen Oracle-Workload auf STACKIT zu bringen. Die ersten beiden nennt der Lauf; der dritte ist eine verbreitete Aufteilung und als Praxis gekennzeichnet.

Die Angaben zu PostgreSQL Flex stammen aus Einführung und FAQ von STACKIT, die Support-Aussage aus der OCI-Übersicht zu Base Database, der Lizenzpunkt aus der Begründung des Laufs.

So entscheiden Sie, Workload für Workload

Der Lauf kann das nicht für Sie entscheiden: Ihm fehlen Größen, Abfragemix und Lizenzdaten. Diese Fragen klären es.

• Wie viel Code in der Datenbank liegt

  Stored Procedures, Packages und Trigger bestimmen den Konvertierungsaufwand. Eine Datenbank aus Tabellen und einfachem SQL lässt sich ganz anders umziehen als ein ERP-Schema mit prozeduralem Code aus vielen Jahren.

• Welche Oracle-Funktionen die Anwendung braucht

  Listen Sie auf, was die Anwendung über einfaches SQL hinaus nutzt: RAC, Data Guard, Editionen, Workload-Typen. Für Base Database Service nennt Oracle Enterprise Edition - Extreme Performance als Voraussetzung für RAC-DB-Systeme mit mehreren Knoten und hat das Auslaufen dieser Edition zum 31. Juli 2026 angekündigt.

• Welche Lizenz Sie halten

  Die Demo-Umgebung setzt license_model bei zwei Datenbanken auf LICENSE_INCLUDED und bei einer auf BRING_YOUR_OWN_LICENSE. Bei den beiden License-Included-Datenbanken läuft der Support über das OCI-Abonnement; für selbst betriebenes Oracle brauchen Sie eine eigene Lizenz- und Support-Grundlage. Prüfen Sie auch die BYOL-Datenbank mit Ihrem Lizenzverantwortlichen.

• Transaktional oder analytisch

  Die Orders-Datenbank ist OLTP, die Reporting-Datenbank DW. Beide führen db_workload unter den kritischen Einstellungen, aber der Lauf sagt nichts darüber, wie sich die Workload-Typen konvertieren lassen oder welches Ziel zu analytischen Abfragen passt. Testen Sie mit Ihren eigenen Abfragen, bevor Sie wählen.

• Wer den Betrieb übernimmt

  Ein verwalteter Dienst wie PostgreSQL Flex gibt Replikation und Backups an STACKIT ab; bei selbst betriebenem Oracle bleiben Patchen, Backups und Failover bei Ihrem Team. Entscheiden Sie danach, wer Rufbereitschaft hat.

• Welche Ausfallzeit Sie akzeptieren

  Der Plan zum Datenumzug führt alle drei Datenbanken mit Verfahren UNKNOWN und Ausfalltoleranz NOT_PROVIDED. Tragen Sie Ihre Werte in die Anwendungsdatei ein; der Lauf übernimmt sie unverändert.

Was der Lauf zu den Daten sagt

Die Datei zum Datenumzug führt die drei Datenbanken als zustandsbehaftete Einheiten und wählt kein Verfahren. Das sind die Zeilen, genau wie in migration/data-movement.md.

| Unit | Source service | Target service | Application | Mechanism | State | Data class | RPO | Downtime tolerance |
|---|---|---|---|---|---|---|---|---|
| oci_database_autonomous_database.orders | oci_database_autonomous_database | NO_TARGET_PROPOSED |  | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| oci_database_autonomous_database.reporting | oci_database_autonomous_database | NO_TARGET_PROPOSED |  | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| oci_database_db_system.erp | oci_database_db_system | NO_TARGET_PROPOSED |  | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |

• Kein Ziel vorgeschlagen

  Die Zielspalte lautet bei allen drei Datenbanken NO_TARGET_PROPOSED. Solange Ihre Architekten keine Option gewählt haben, gibt es kein Umzugsziel.

• Die Größe nennen Sie

  Der Lauf führt Datengröße, Änderungsrate und tolerierte Ausfallzeit als unbekannt. Auch die bereitgestellte Kapazität gibt er als nicht in der Quelle angegeben aus, obwohl die Eingabe 512 GB für das DB-System und 1 bzw. 2 TB für die Autonomous Databases setzt; übernehmen Sie diese Größen selbst aus der Quelle. StackToIT überträgt nie Daten und misst sie nicht; eine Person wählt das Verfahren anhand dieser Zahlen.

Die vorgeschlagene Reihenfolge

Die Abhängigkeitsreihenfolge hat drei Wellen. Sie beschreibt die Einheiten der Umgebung, nicht die Datenarbeit.

1. 01

   Welle 1

   Das VCN und beide Autonomous Databases, die von keiner anderen Einheit abhängen.

2. 02

   Welle 2

   Das Datenbank-Subnetz.

3. 03

   Welle 3

   Das DB-System, das im Subnetz liegt.

Was Ihre Architekten verantworten

• Die Engine-Entscheidung, festgehalten

  Tragen Sie die gewählte Option je Datenbank in die Notiz ihres Schritts in review/progress.yaml und in Ihren Change-Record ein. Für diese Einheiten hat der Lauf keine Entscheidungsdatensätze angelegt; decisions.yaml ist daher leer.

• Den Konvertierungsumfang

  Zählen Sie Prozeduren, Packages und Oracle-spezifisches SQL, bevor Sie wählen. Der Lauf markiert die Konvertierung; das Inventar ist Aufgabe eines Konvertierungswerkzeugs und Ihrer Entwickler.

• Die Lizenzlage

  Klären Sie mit dem Lizenzverantwortlichen, was gilt, wenn Oracle auf STACKIT läuft, bevor Sie einen Server dimensionieren. Der Lauf hält nur fest, dass die Lizenz Ihre ist.

• Datenverfahren und Probe

  Wählen Sie das Transferverfahren nach Größe, Änderungsrate und tolerierter Ausfallzeit und proben Sie es vor dem Fenster mit einem Restore-Test.

Fragen aus Datenbankteams

Quellen

• Oracle-Dokumentation: Überblick über Base Database Service
• Oracle-Dokumentation: Über Autonomous Database Serverless
• STACKIT-Dokumentation: Einführung in PostgreSQL Flex
• STACKIT-Dokumentation: FAQ zu PostgreSQL Flex