I/O-Ressourcenmanagement - AWS Präskriptive Leitlinien
Migration zu AWS

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

I/O-Ressourcenmanagement

I/O Resource Management (IORM) is an Exadata feature that manages how multiple workloads and databases share the I/O resources of an Exadata system. IORM complements the Oracle Database Resource Manager (DBRM) to provide necessary isolation for different workloads in a consolidated environment. Whenever I/O requests start to saturate the I/O capacity of storage cell servers, IORM schedules and prioritizes incoming I/OAnfragen, die auf den von Ihnen konfigurierten Ressourcenplänen basieren.

Sie können IORM-Metriken aus Exadata-Speicherzellen sammeln, indem Sie das Skript verwenden, metric_iorm.pl wie in My Oracle Support (MOS) Note 337265.1, Tool for Gathering I/O Resource Manager Metrics: metric_iorm.pl beschrieben (erfordert ein Oracle-Konto). Diese Metriken können nützlich sein, um Workloads zu organisieren, die in einer konsolidierten Umgebung in Exadata ausgeführt werden, wenn Sie die Workloads auf die Zielplattform auf AWS migrieren.

Migration zu AWS

In der empfehlen wir AWS Cloud, dass Sie verschiedene Workloads auf separaten Instanzen hosten. Dieser Ansatz bietet mehr Flexibilität bei der Verwaltung der Datenbanken entsprechend den Ressourcen-, Leistungs- und SLA-Anforderungen einzelner Anwendungen, anstatt sie in einer einzigen Instanz zu konsolidieren. Die folgenden Methoden können nützlich sein, wenn Sie solche Workloads migrieren zu: AWS

  • Identifizieren Sie Interdependenzen zwischen Datenbanken und klassifizieren Sie die Workloads, die auf dieselbe Instanz auf der Zielplattform migriert werden müssen. Diese Datenbanken verfügen möglicherweise über nicht auflösbare schemaübergreifende Verweise oder über Datenbank-Link-Konnektivität mit geringer Latenz.

  • Identifizieren Sie anhand der Statistiken, die Sie mithilfe des metric_iorm.pl Skripts gesammelt haben, Datenbanken und Workloads, die IORM initiieren und davon profitieren. Verwenden Sie diese Informationen, um die Datenbanken zu ermitteln, die konsolidiert oder auf unabhängige Instanzen migriert werden können. Wählen Sie geeignete Speichertypen und Instanzklassen, um eine Überlastung zu vermeiden I/O .

  • Wenn es sich bei der Zielplattform um Oracle Database handelt, sollten Sie den Einsatz von Oracle Database Resource Manager (DBRM) in Betracht ziehen, um Ressourcen wie CPU, PGA und Parallelität für mehrere Workloads zu priorisieren oder zu drosseln, die in derselben Instanz als mehrere austauschbare Datenbanken oder Schemas konsolidiert werden.

  • Erwägen Sie die Implementierung von Caching-Lösungen wie Amazon ElastiCache und Amazon RDS for Oracle Oracle-Read Replicas, um schreibgeschützte Workloads zu bedienen. Diese Lösungen reduzieren den I/O-Aufwand auf der primären Instance.

  • Für Workloads, die nicht von Oracle Database abhängig sind, bietet Amazon Aurora eine verteilte und entkoppelte Architektur, die einen hohen Durchsatz bietet. I/O Sie können den Anforderungen einer hohen, I/O-intensiven Arbeitslast gerecht werden, indem Sie einen Aurora-Cluster mit einer angemessenen Anzahl von Reader-Instances entwerfen und Funktionen wie globale Amazon Aurora Aurora-Datenbanken verwenden.