17.Deutsche ORACLE-Anwenderkonferenz Database Donnerstag, 11. November 2004 11h00, Mozartsaal Automatic Storage Management in der Praxis Johannes Ahrends Herrmann & Lenz Services GmbH, Burscheid Schlüsselworte: ASM, Veritas, Raid, Mirroring, Striping, OCFS, S.A.M.E Zusammenfassung Mit Oracle 10g führt Oracle ein eigenes Filesystem (ASM Automatic Storage Management) ein, das unabhängig vom Betriebssystem (z.z. Unix und MS- Windows), die optimale Implementierung für den Betrieb von Oracle Datenbanken darstellen soll. Neben der Möglichkeit der Mehrfachspiegelung werden die Filesysteme über alle verfügbaren Devices gestriped und entspricht damit der von Oracle seit längerem vertretenen These S.A.M.E (Stripe an Mirror Everything). Braucht man jetzt kein Veritas Filesystem, keine Raid-Controller und kein EMC SRDF mehr? Einleitung Automatisch scheint das Schlagwort für Oracle 10g zu sein. In sofern wundert es nicht, dass auch die Speicherung durch ASM automatisch durchgeführt wird. Sicherlich weicht die Praxis etwas von dieser Theorie ab, aber man kann tatsächlich mit relativ geringem Aufwand eine für den Betrieb von Oracle Datenbanken optimale Konfiguration des Speichersubsystems erreichen. Ein paar Worte zur Historie: Oracle hat sich im Umfeld Oracle Parallel Server und Real Application Clusters in der Vergangenheit schwer getan, die Storages zu verwalten. Zunächst wurden nur Raw-Devices unterstützt, was dazu führte, dass nur mit fest vorgegebenen Dateigrößen gearbeitet werden konnte. Mit Version 8i wurde dann auf einigen Plattformen (z.b. AIX) das von den Betriebssytemherstellern entwickelte Global Filesystem unterstützt. Leider war hier das Problem Auf einigen Plattformen. Mit Version 9i hat Oracle dann das Oracle Cluster Filesystem (OCFS), also eine eigene Implementierung des Global Filesystems eingeführt. Dieses ist Betriebssystemunabhängig und kann als separates Produkt eingesetzt werden, die Verzeichnisse sind aber z.b. unter MS-
KONFERENZ Windows als normale Dateisysteme zu erkennen und somit besteht die Gefahr wie wir sie schon erlebt haben dass diese Verzeichnisse durch Unachtsamkeit zerstört, und damit die Datenbank korrupiert wird. Außerdem steht OCFS nur für den Betrieb von Real Application Clusters zur Verfügung. Mit Version 10g wird jetzt mit ASM ein unabhängiges Produkt geschaffen, das für alle Oracle Datenbanken zur Verfügung steht und für das Betriebssystem unsichtbar ist. Funktionalität ASM besteht aus einer eigenen Instanz, in der die Disk-Devices verwaltet werden. Eine Oracle Datenbank nimmt über den ebenfalls in Oracle 10g neu eingeführten Oracle Cluster Synchronization Service (OCSS) eine Verbindung zur ASM-Instanz auf und erhält über diesen die entsprechenden Ressourcen, die vorher eingerichtet worden sind. Intern werden diese Ressourcen wie bei einem normalen Filesystem in Verzeichnissen verwaltet. Dabei werden die Devices speziell formatiert und stehen somit dem Betriebssystem nicht mehr zur Verfügung. Die Gefahr einer unbedachten Formatierung ist somit minimiert. Das Zusammenspiel von Datenbank- und ASM-Instanz über den OCSSD hat aber den Nachteil, dass wenn die ASM-Instanz oder der OCSSD Prozess abstürzt, die beteiligten Datenbanken ebenfalls beendet werden. ASM-Parametrierung Die ASM-Instanz wird standardmäßig über die ORACLE_SID +ASM angegeben. Folgende Parameter sind dabei notwendig: Wenn Sie eine Datenbank über den Database Configuration Assistant (DBCA) aufbauen, können Sie Automatic Storage Management als Speicheroption auswählen. Dann melden Sie sich, sofern Sie die ASM-Instanz schon aufgebaut haben, an die Instanz an. Alternativ können Sie hier die Diskgroup auch noch anlegen, dies hat aber in der Vergangenheit unter MS-Windows nicht funktioniert. Als Diskgroups werden Ihnen anschließend die Kandidaten, die für die Speicherung zur Verfügung stehen, angeboten. Dabei wird standardmäßig eine einfache Spiegelung ausgewählt, es kann aber auch auf die Spiegelung verzichinstance_type asm_diskgroups ='ASM' ='ORA_ASM' Mit dem Werkzeug asmtoolg kann die Konfiguration der ASM-Instanz durchgeführt werden. Dabei wird zunächst eine Diskgroup angelegt und anschließend die Devices hinzugefügt, die als unformatierte Partitionen zur Verfügung stehen müssen. Aufbauen einer Oracle Datenbank mit ASM
17.Deutsche ORACLE-Anwenderkonferenz Database tet (externe Spiegelung) oder eine Mehrfachspiegelung gewählt werden. Die Stripegröße kann nicht eingestellt werden. Hier gelten folgende Standardeinstellungen: Fine (128kB Stripegröße) für Kontrolldateien und Online-Redolog Dateien. Coarse (1MB Stripegröße) für alle Datendateien, die Parameterdatei und Backups. Bei einer Standardinstallation werden jetzt alle Komponenten der Datenbank im ASM-Filesystem abgelegt. Dazu gehören: Datendateien Controlfiles Online Redolog-Dateien Tempfiles Parameterfiles Flashback Backupset Archivierte Redolog-Dateien Diese werden in den zugehörigen Unterverzeichnissen, die automatisch angelegt werden, abgespeichert. Die gesamte Speicherung erfolgt als Oracle Managed Files (OMF), kann aber zusätzlich mit eigenen Namen und Verzeichnissen erweitert werden. Eine ASM-verwaltete Datenbank sieht also z.b. wie folgt aus: SQL> SELECT tablespace_name, file_name, bytes/1024/1024 MByte FROM dba_data_files; TABLESPACE_NAME FILE_NAME MB ----------------- ---------------------------------------- ------- SYSTEM +ORAASM1/sunasm/datafile/system.264.1 300 UNDOTBS1 +ORAASM1/sunasm/datafile/undotbs1.265.1 500 SYSAUX +ORAASM1/sunasm/datafile/sysaux.266.1 230 USERS +ORAASM1/sunasm/datafile/users.268.1 5 DEMO +ORAASM1/sunasm/datafile/demo.270.1 1000 SQL> SELECT name FROM v$controlfile; NAME --------------------------------------------- +ORAASM1/sunasm/controlfile/current.256.1 +ORAASM1/sunasm/controlfile/current.257.1
KONFERENZ Um diese Information auch in einer ASM-Instanz darstellen zu können bedarf es eines etwas umfangreicheren SQL-Befehls: SELECT '+' dg.name '/' sid.name '/' typ.name '/' datei.name Filename, round(info.bytes/1024/1024) Mbyte FROM v$asm_diskgroup dg, v$asm_alias sid, v$asm_alias typ, v$asm_alias datei, v$asm_file info WHERE sid.group_number = dg.group_number AND typ.group_number = dg.group_number AND datei.group_number = dg.group_number AND sid.reference_index = typ.parent_index AND typ.reference_index = datei.parent_index AND datei.file_number = info.file_number; FILENAME MBYTE ----------------------------------------------------------- ------ +ORA_ASM/SUNASM/CONTROLFILE/Current.256.1 2 +ORA_ASM/SUNASM/CONTROLFILE/Current.257.1 2 +ORA_ASM/SUNASM/ONLINELOG/group_1.258.1 10 +ORA_ASM/SUNASM/ONLINELOG/group_3.263.1 10 +ORA_ASM/SUNASM/DATAFILE/SYSTEM.264.1 300 +ORA_ASM/SUNASM/TEMPFILE/TEMP.267.1 20 +ORA_ASM/SUNASM/PARAMETERFILE/spfile.269.1 0 +ORA_ASM/SUNASM/FLASHBACK/log_1.270.7 8 +ORA_ASM/ARCHIVELOG/2004_06_23/thread_1_seq_50.271.1 9 +ORA_ASM/ARCHIVELOG/2004_06_23/thread_1_seq_53.277.1 0 +ORA_ASM/BACKUPSET/2004_06_23/annnf0_TAG20040623T154344_0.274.1 9 +ORA_ASM/BACKUPSET/2004_06_23/nnndf0_TAG20040623T154350_0.275.1 246 Eindrücke und Erfahrungen Die erste Frage, die sich aufdrängt, ist: Für wen ist ASM interessant. Die Antwort lautet, für jeden, der eine Datenbank im RAC betreibt, außerdem für all jene, die größere Datenbanken mit mehreren 100 GByte haben. Sicherlich ist hierbei eine Hardware-Spiegelung der ASM-Spiegelung vorzuziehen. Das Striping kann aber dennoch positiv auf die Performance auswirken. Außerdem wird bei Hinzu- oder Wegnahme einer Disk eine automatische Redistribution der Daten durchgeführt. Somit ist hier eine hohe Flexibilität gewährleistet. Unter Unix wird für große Datenbank heute oft eine entsprechende Filesystem-
17.Deutsche ORACLE-Anwenderkonferenz Database Implementierung angeboten, hier kann eine Kombination sinnvoll sein. Anfang 2004 habe ich einige Benchmarks für eine Oracle Datenbank unter SUN Solaris durchführen dürfen und dabei interessante Erfahrungen gesammelt. Ein Standardfilesystem frist u.u. mehr als 20% Performance gegenüber der Verwendung von Raw-Devices. Umgekehrt sind Raw-Devices von der Administration her sehr problematisch und unflexibel. Veritas bietet hierfür das Veritas- Filesystem, den Veritas Volume Manager und Oracle Disk Manager für Veritas Filesystem. Nur diese Kombination liefert einen wirklichen Performancevorteil gegenüber Raw-Devices. Leider müssen alle diese Teile separat lizenziert werden. Oracle ASM liefert die gleiche Funktionalität wie die Veritas Tools ohne zusätzliche Kosten. Ob allerdings in jedem Fall die gleiche Performance zu erreichen ist, muss abgewartet werden. Erste Tests, die ich während des Benchmarks durchführen durfte, waren sehr erfolgsversprechend. Leider war ich aufgrund eines Bugs in der Version 10.1.0.2 nicht in der Lage ein entgültiges Ergebnis zu liefern vielleicht gelingt mir dies noch vor der DOAG-Konferenz. Interessant ist, dass sich die Artikel, die es im Metalink über ASM gibt, in der Mehrzahl auf die Verwendung von ASM in Verbindung mit dem Einsatz des Veritas Volume Managers beziehen. Für die Fragen in der Einleitung gilt also: Veritas: wer die Kosten scheut, kann ASM einsetzten und erhält eine gute Alternative RAID-Kontroller: Ein Hardware-Raid ist wie üblich effektiver als jegliche Art der Softwarespiegelung, da macht auch Oracle keinen Unterschied. Bei RAID-5 Systemen kann aber das ASM-Mirroring und Striping sinnvoller sein, auch wenn der Platzbedarf zunächst höher ist. Mit EMC-SRDF oder anderen Hochverfügbarkeitslösungen ist ASM natürlich nicht vergleichbar. Dennoch macht es in solchen Fällen Sinn, wie auch bei RAID-Systemen ASM ohne Spiegelung aufzusetzen. Fazit Ein für Oracle optimiertes Filesystem unabhängig vom verwendeten Betriebssystem zu haben ist ein großer Schritt in Richtung Grid-Computing. In vielen Unternehmen muss sicherlich zunächst mit dem Operating gesprochen werden, ob dieses Filesystem eingesetzt werden darf, weil es dann keine Betriebssystemzugriffe mehr gibt. Das bedeutet z.b. auch, dass die Sicherung einer Oracle Datenbank nur noch mit dem Recovery Manager möglich ist und auch das Kopieren in eine ASM-Instanz oder heraus kann nur über den RMAN erfolgen.
KONFERENZ Durch die gerade verfügbare Version 10.1.0.3 sind auch die Bugs, die einen Einsatz unter MS-Windows sehr problematisch machten, behoben. Somit kann schnell und unkompliziert eine ASM-Instanz aufgebaut werden. Allerdings darf man nicht vergessen, dass ein Crash der ASM Instanz dazu führt, dass alle Datenbanken, die Ihre Daten in dieser Instanz verwalten, ebenfalls abstürzen. Ob es Ihren Anforderungen gerecht wird, können Sie nur selbst durch Tests herausfinden. Wir würden uns freuen, wenn wir Sie dabei unterstützen dürften. Kontaktadresse Johannes Ahrends Herrmann & Lenz Services GmbH Höhestr. 37 D-51399 Burscheid Telefon: +49(0)21 74-67 12-0 Fax: +49(0)21 74-67 12-22 E-Mail: johannes.ahrends@hl-services.de Internet: www.hl-services.de