Minimieren des E/A-Konkurrenzbetriebs in Oracle

Von allen konfigurierbaren Komponenten einer Geodatabase wird die Speicherkomponente wohl am häufigsten und umfassendsten angepasst. Jeder Datenbankadministrator (DBA) hat eine bevorzugte Methode zur Organisation der logischen und physischen Speicherstrukturen der Oracle-Datenbank, die auf Erfahrungen und bewährten Techniken basiert.

Sie haben die Flexibilität, ein Speichermodell für Ihre Geodatabase zu entwickeln, das den Anforderungen Ihrer Daten, Anwendungen und Verwaltungsrichtlinien gerecht wird. ArcSDE weist nur wenige strikte Speicheranforderungen auf. Sie können für GIS-Daten einen einfachen Computer mit einem einzigen Datenträger und einem Tablespace oder aber einen High-End-Server mit Dutzenden von Festplatten-Arrays und Hunderten von Oracle-Dateien bereitstellen – mit beiden Möglichkeiten können Sie die entsprechenden Umgebungen erfolgreich unterstützen. Es ist ein großer Vorteil, dass Sie ArcSDE und Oracle je nach Ressourcen, die Ihnen zur Ausführung Ihrer Geodatabase zur Verfügung stehen, anpassen können.

Zur Reduzierung des Eingabe/Ausgabe-Konkurrenzbetriebs bei Oracle-Datenbanken sollten Sie falls möglich Dateien, auf die häufig zugegriffen wird, auf unterschiedlichen Festplatten platzieren, und Dateien, auf die häufig zugegriffen wird, mit Dateien, auf die selten zugegriffen wird, auf einer Festplatte kombinieren. Vorgehensweise:

1. Schätzen Sie die Größe aller Datenbankkomponenten, und bestimmen Sie deren relative Zugriffsraten.
2. Positionieren Sie die Komponenten entsprechend dem verfügbaren Festplattenspeicherplatz sowie der Größe und Anzahl der Festplattenlaufwerke.

Das Erstellen von Diagrammen der Festplattenlaufwerke und das Beschriften mit den Komponenten hilft beim Verfolgen des Speicherorts jeder Komponente. Beim Erstellen Ihrer Datenbank sollten Sie das Diagramm zur Hand haben.

Einige Empfehlungen zur Vermeidung des Ressourcen-Konkurrenzbetriebs in einer ArcSDE-Geodatabase, die in Oracle gespeichert ist, finden Sie unten. Eine Erklärung der hier erläuterten Oracle-Komponenten, z. B. Tablespaces und Segmente, finden Sie in der Oracle-Dokumentation.

• Halten Sie das Datenbank-Design so einfach wie möglich.

  Dies bedeutet nicht, dass das Design von Grund auf einfach sein muss, sondern lediglich, dass die Komplexität des Designs auf der Komplexität der verarbeiteten Daten basiert und nicht auf willkürlichen Entscheidungen. Beginnen Sie mit einem Tablespace für Ihre Geodatabase, und begründen und dokumentieren Sie alle nachfolgenden Tablespaces, die Sie erstellen. Die Dokumentierung des Zwecks der einzelnen Tablespaces nützt nicht nur jedem, der in Zukunft mit dem System arbeitet (Sie selbst eingeschlossen). Sie stellen dadurch auch sicher, dass Sie den Nutzen jedes zusätzlichen Tablespaces, den Sie verwalten müssen, sorgfältig abwägen.

• Trennen Sie Systemsegmente von Benutzersegmenten.

  Das Getrennthalten von Benutzersegmenten, z. B. Feature-Classes, und Systemsegmenten, z. B. den ArcSDE- und Oracle-Datenwörterbüchern, vereinfacht das Quota-Management und vermeidet eine Fragmentierung, die zu verminderter Leistung führen kann. Außerdem kann die Aktivität auf der Tablespace-Ebene einfacher überwacht werden, wenn diese Segmente unabhängig voneinander gespeichert werden.

• Trennen Sie die Daten unterschiedlicher Projekte.

  Die Verwendung reservierter Tablespaces für unterschiedliche Projekte, Abteilungen oder sonstige logische Entitäten kann die Überwachung und das Management vereinfachen. Wiederherstellungsvorgänge, die den Tablespace eines Projekts betreffen, verursachen nicht, dass ein anderes Projekt offline genommen werden muss. Sie können Benutzern in einer Abteilung unbeschränkte Quota auf einen Satz von Tablespaces zuweisen, ohne das Risiko einzugehen, dass diese Benutzer Speicherplatz einer anderen Abteilung ausschöpfen. Das Verbinden von Eingabe/Ausgabe-Aktivität und Dateiwachstum mit Teams oder einzelnen Personen ist einfacher, wenn diese Entitäten ihre eigenen Tablespaces verwenden.

• Trennen Sie große Segmente von kleinen Segmenten.

  Sie können Ausdehnungsgrößen auf der Tablespace-Ebene anstatt nur auf der Segmentebene erzwingen. Die Verwendung einer einheitlichen Ausdehnungsgröße für alle Segmente in einem Tablespace vermeidet die Fragmentierung von freiem Speicherplatz und verbessert die Leistung. Hierfür müssen jedoch Segmente nach Ausdehnungsgröße gruppiert werden, um eine Balance zwischen der Ausdehnungsanzahl pro Segment, die zu verschwendetem Speicherplatz führt, und übermäßigen Ausdehnungsgrößen zu finden. Ausdehnungsgrößen von 128 KB für kleine Tabellen, 1 MB für große Feature-Classes und 128 MB für große Raster sind sinnvoll, obwohl Sie diese Werte entsprechend Ihrer Umgebung und Ihren Untersuchungen anpassen können.

• Trennen Sie schreibgeschützte Daten von nicht schreibgeschützten Daten.

  Wenn ein Tablespace nur schreibgeschützte Daten enthält, können Sie den Schreibschutzmodus explizit für diesen Tablespace aktivieren. Hierdurch wird das regelmäßig zu sichernde Datenvolumen verringert. Schreibgeschützte Datendateien sind auch bestens für die Speicherung auf RAID 5-Arrays (RAID, Redundant Array of Independent Disks) geeignet, weil sie während des Lesezugriffs vom Striping-Verfahren profitieren. Außerdem verringern schreibgeschützte Datendateien nicht die Array-Performance durch übermäßige Schreibaktivität.

• Verwenden Sie zur Speicherung von Dateien mehrere Festplatten oder Arrays.

  Bündeln oder spiegeln Sie wichtige Oracle-Dateien, z. B. Kontrolldateien, Online-Redo-Protokolldateien und archivierte Redo-Protokolldateien, um den besten Schutz zu bieten.

  Vorsicht:

  In Kontrolldateien werden kritische Informationen gespeichert, z. B. Listen von Dateien, die Teil der Datenbank sind. In archivierten und Online-Redo-Protokolldateien werden an der Datenbank vorgenommene Änderungen gespeichert, um eine Wiederherstellung zu gewährleisten. Es ist schwierig oder unmöglich, eine Datenbank ohne aktuelle Kopien dieser Dateien vollständig wiederherzustellen.

  Sogar auf Datenbankservern mit einem Speicher-Array, das aus einem einzelnen Volume besteht, ist gewöhnlich eine eigenständige interne Festplatte zum Speichern des Betriebssystems, der Auslagerungsdatei sowie der ArcSDE- und Oracle-Programmdateien vorhanden. Speichern Sie auf dieser Festplatte die gebündelten Kontroll- und Redo-Protokolldateien.

• Wenn Sie RAID-Speicher nutzen, wählen Sie das RAID-System sorgfältig aus.

  Bei RAID handelt es sich um ein Speichermanagement-Konzept. Es gibt mehrere allgemeine RAID-Strategien. Diese Strategien sind durch Nummern gekennzeichnet, die so genannten RAID-Stufen. Diese werden wie folgt definiert: RAID 0 arbeitet mit Striping, d. h. kleine Teile oder "Streifen" desselben Dateisystems werden über mehrere physische Festplatten hinweg in Einheiten, die als "Stripes" (Streifen) bezeichnet werden, angeordnet. Dadurch kann eine bessere Leistung erzielt werden. Indem der Inhalt eines Dateisystems über mehrere Datenträger verteilt wird, kann der RAID-Controller gleichzeitig von mehreren Festplatten lesen bzw. auf mehrere Festplatten schreiben. Der Nachteil von RAID 0 besteht darin, dass bei Ausfall einer Festplatte im RAID 0-Array das gesamte Array ausfällt.

  RAID 1 arbeitet mit Mirroring (Spiegelung), wobei eine Kopie aller Daten, die auf eine Festplatte geschrieben werden, auf einer zweiten Festplatte gespeichert wird. Der Vorteil hierbei ist der Ausfallschutz. Beim Ausfall einer Festplatte kommt es weder zum Datenverlust noch zur Verschlechterung der Service-Leistung. Aus diesem Grund wird RAID 1 für viele Geodatabases verwendet, insbesondere für solche mit hohen Verfügbarkeitsanforderungen. Der Nachteil der Mirroring-Methode sind die Kosten. Da alle Daten doppelt gespeichert werden, ist die doppelte Menge an Festplattenspeicher erforderlich. Außerdem kommt es durch die Notwendigkeit, die Daten doppelt zu schreiben, zu einer geringfügigen Write Penalty (Performance-Einbuße durch Schreibvorgänge). RAID 10, auch als RAID 1+0 bezeichnet, kombiniert die Vorteile von RAID 1 und RAID 0. Bei RAID 10-Arrays werden die Daten in Stripes über Gruppen gespiegelter Festplatten verteilt. Hierdurch erhalten Sie den Performance-Vorteil von RAID 0 und den Vorteil des Ausfallschutzes von RAID 1. RAID 10 sowie anbieterspezifische Implementierungen auf Basis der RAID 10-Strategie bieten die beste E/A-Performance für Geodatabases mit hoher Auslastung.

  RAID 10 ist jedoch kostenintensiv, da zusätzliche Hardware zur Speicherung der gespiegelten Daten erforderlich ist. Eine Möglichkeit besteht darin, RAID 10 für die Dateien einzusetzen, die am häufigsten bearbeitet werden, um dafür die bestmögliche Performance sicherzustellen, und andere RAID-Systeme oder eigenständige Konfigurationen für schreibgeschützte, archivierte und weniger häufig geänderte Daten zu verwenden. Wenn Ihr Budget Ihnen erlaubt, RAID 10 für den gesamten Datenbankspeicher einzusetzen, sollte Sie dies tun. Andernfalls empfehlen wir, unterschiedliche RAID-Systeme und Konfigurationen mit eigenständigen Festplatten zu kombinieren, um mit den verfügbaren Hardware-Ressourcen die bestmögliche Zuverlässigkeit und Performance zu erzielen. Speichern Sie Dateien, die häufig geändert werden, möglichst auf RAID 1- oder RAID 10-Systemen. Hierzu gehören Redo-Protokolldateien und Datendateien für Undo-Tablespaces. Falls erforderlich, verwenden Sie Oracle Multiplexing und eine umfassende Sicherungsstrategie.

  RAID 5, auch als "Striping mit verteilter Parität" bezeichnet, erfordert das Äquivalent von nur einer zusätzlichen Festplatte im gesamten Array zur Speicherung redundanter Informationen. Hierzu werden die Daten in Stripes auf mehrere Festplatten aufgeteilt, wobei für den gesamten Stripe jeweils ein zusätzlicher Chunk an Paritätsinformationen gespeichert wird. Wenn eine Festplatte im Array ausfällt, kann der RAID-Prozessor die fehlenden Daten anhand der verbleibenden Festplatten und der Paritätsinformationen rekonstruieren. Die Vorteile von RAID 5 sind eine bessere Lese-Performance durch Verwendung von Striping und kostengünstige Redundanz durch Verwendung von Paritätsinformationen statt der vollständigen Spiegelung. Da der Lesezugriff auf Geodatabases meist sehr hoch ist, eignet sich RAID 5 gut für Geodatabase-Anwendungen, insbesondere, wenn die Verfügbarkeitsanforderung im mittelhohen Bereich liegt.

  Da mit RAID 5 die Redundanz jedoch nicht vollständig ist, birgt es ein höheres Datenverlustrisiko als RAID 10. Dies kommt zwar selten vor, aber wenn zwei Festplatten in einem RAID 5-Array gleichzeitig ausfallen, reichen die verbleibenden Informationen nicht aus, um die fehlenden Daten zu rekonstruieren, sodass das gesamte Volume ausfällt. Darüber hinaus können zwei Faktoren sich negativ auf die Leistung auswirken. Wenn Daten auf das Array geschrieben werden, müssen auch die Paritätsinformationen berechnet und gespeichert werden. Und wenn eine Festplatte ausfällt, ist die Lese- und Schreib-Performance erheblich schlechter, während der RAID-Prozessor die fehlenden Daten rekonstruiert. Bei Geodatabases mit hoher Aktivität reicht der Datendurchsatz in diesem Zeitraum möglicherweise nicht aus, um eine akzeptable Service-Qualität sicherzustellen.

• Verwenden Sie Oracle Automated Storage Management.

  In Oracle 10g wurde die Komponente Automated Storage Management (ASM) eingeführt. ASM ist im Grunde ein für Oracle-Datenbanken optimiertes RAID-System. ASM verwendet eine Oracle-Instanz zur Vermittlung von E/A-Anforderungen auf eine Gruppe unformatierter Partitionen, die als Festplattengruppe verwaltet wird. Festplattengruppen können Striping, Mirroring und eine spezielle Mirroring-Variante bereitstellen, die als "High Redundancy" (hohe Redundanz) bezeichnet wird, da sie drei statt zwei Datenkopien speichert.

• Verwenden Sie einen kleinen PCTFREE-Wert für schreibgeschützte Daten.

  Beim Einfügen neuer Daten in eine Tabelle dürfen Sie bei Oracle eine bestimmte Menge freien Speicherplatz in jedem Datenblock reservieren. Sobald die Grenze des freien Speicherplatzes für einen Block erreicht ist, können Sie keine zusätzlichen Daten in diesen Block einfügen. Dieser freie Speicherplatz kann nur verwendet werden, wenn in diesem Block gespeicherte Zeilen aktualisiert werden. Durch das Reservieren von Speicherplatz, der nur bei Aktualisierungen freigegeben wird, können Sie verhindern, dass Zeilen den verfügbaren Speicherplatz in ihrem ursprünglichen Block überschreiten und in einen neuen Block migrieren. Die Migration einer Zeile ist ein arbeitsintensiver Vorgang, sowohl beim Aktualisieren als auch bei späteren Zugriffen in nachfolgenden Vorgängen, z. B. Abfragen.

  Viele Geodatabases werden sehr selten aktualisiert, entweder weil die Tabellen statisch sind, wie dies größtenteils bei Rastern der Fall ist, oder weil sie in einem mehrfach versionierten Arbeitsablauf bearbeitet werden. Bei Arbeitsabläufen ersetzen Paare von Lösch- und Einfügevorgängen die tatsächlichen Aktualisierungen.

  Zur Maximierung des Speicherplatzes in jedem Block, der zur Speicherung der Geodatabase-Daten verwendet wird, ist ArcSDE deshalb so vorkonfiguriert, dass kein freier Speicherplatz reserviert wird. Dies wird durch Festlegen der Klausel PCTFREE 0 in der DBTUNE-Speicherzeichenfolge erreicht. Wenn Sie freien Speicherplatz für SQL-Aktualisierungen durch benutzerdefinierte Anwendungen reservieren möchten, ändern Sie die PCTFREE-Werte in der standardmäßigen DBTUNE-Konfiguration. Weitere Informationen zu DBTUNE-Konfiguration finden Sie unter Was ist die Tabelle DBTUNE?, Was sind DBTUNE-Konfigurationsschlüsselwörter und -Parameter? und DBTUNE-Konfigurationsparameter für Oracle.