ASM oder Filesystem

ASM oder Filesystem
Benjamin Kurschies
QSC AG
Hamburg
Schlüsselworte
Oracle, ASM, GI, RAC
Einleitung
Seit nunmehr 12 Jahren bietet Oracle für sein Datenbankmanagementsystem einen eigenen
Volume Manager an, der die Storageverwaltung vereinfachen und beschleunigen soll. Durch
anfängliche Stabilitätsprobleme hat ASM immer noch unter seinem schlechten Ruf zu
leiden.
In diesem Vortrag wird beleuchtet, was ASM genau ist, wo seine Stärken liegen und welche
Werkzeuge Oracle im K-Fall bereitstellt.
Was ist ASM




Das „Automatic Storage Management“ ist ein Volume Manager, der an die
Anforderungen der Oracle Datenbank angepasst ist und kann auch nur von dieser
(und einigen Oracle Tools) gelesen und beschrieben werden.
Die Meta-Informationen werden in den Headern der jeweiligen Disks gespeichert.
Die ASM Instanz liest diese Informationen aus und stellt sie den Datenbanken zur
Verfügung.
Die Datenbanken fragen diese Meta-Informationen ab und greifen dann direkt auf
die physikalischen Disks zu. Aus diesem Grund müssen die Disks auch für den User,
unter dem die Oracle Dienste laufen, auch zugreifbar sein.
Verwaltungstools



ASMCA: Mit diesem GUI kann die ASM Instanz eingerichtet und administriert werden.
Es kann auch der „silent mode“ via CLI genutzt werden.
SQL*Plus: da es eine „normale“ Oracle Instanz ist, können viele einstellungen des
physikalischen Layouts via SQL*Plus ausgelesen oder verändert werden.
ASMCMD: Mit diesem Tool kann auf die logische Struktur des ASM zugegriffen
werden.
Vorteile gegenüber Filesystem





Flexibilität:
o Disks können im laufenden Betrieb hinzugefügt werden.
o Disks können im laufenden Betrieb entfernt werden.
Daten werden gleichmäßig über alle Disks verteilt.
Bei RAC: OCR/Votedisk werden automatisch verwaltet
ASM kann Daten redundant über mehrere Disks verteilen (RAID)
Durch die Umgehung von allen OS Caches und Queues ist ASM sehr schnell. In
unserem LAB haben wir mit dem tool „SLOB“ von Kevon Closson bis zu 19 x mehr
I/O durchsatz messen können.
Tipps & Tricks
1. ASM Disks / LUN’s eindeutig zuordnen:
unter den UNIX-artigen Betriebssystemen wird eine neue Disk fortlaufend
durchgezählt, z.B. „/dev/sdc“. Dies macht es den Administratoren schwer, normale
von ASM disks zu unterscheiden.
Lösung: via ASMlib, udev oder im multipath-treiber können sprechende Namen
vergeben werden.
# SCSI ID auslesen
/sbin/scsi_id -g -u -d /dev/sdc
# udev regel anlegen
vi /etc/udev/rules.d/99-oracle-asmdevices.rules
# <SCSI_ID> austauschen!
KERNEL=="sd*", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk",
ENV{ID_SERIAL}=="<SCSI_ID>", NAME="asm/oraasm1", OWNER="oracle",
GROUP="oinstall", MODE="0660"
2. Desaster Recovery:
Selbst wenn der Server / Das Betriebssystem zerstört wurden, sind die Daten im
ASM nicht verloren so lange die entsprechenden ASM Disks / LUN’s intakt sind. Zur
wiederherstellung sind folgende Schritte notwendig:
- Installation OS
- Installation Oracle Clusterware
o TIP: Wenn man eine dedizierte Diskgroup für die OCR / Votedisks anlegt,
kann diese vor der Installation gefahrlos gelöscht und für die
neuinstallation wieder verwendet werden
# Richtige ASM Disk finden / Header auslesen
kfed read /dev/asm/oraasm1
# Header Löschen
dd if=/dev/zero of=/dev/oraasm1 bs=1024 count=100
-
Rescan der verfügbaren Disks im ASM durchführen
# sqlplus / as sysasm
select * from v$asm_disk;
-
Diskgroup mounten
# sqlplus / as sysasm
alter diskgroup u01 mount;
3. Zugriff auf Daten im ASM
Das Betriebssystem kann nicht native auf die Daten im ASM zugreifen. Oracle liefert
jedoch Tools mit, mit denen ein Zugriff möglich ist.
- ASMCMD: innerhalb dieses Programms kann man sich fast wie auf einer linux
shell mit „cd“ und „ls“ durch die Verzeichnisse bewegen, mit cp kann man auch
dateien in das reguläre Filesystem kopieren
- Recovery Manager (RMAN): der RMAN kann natürlich auf alle
Datenbankrelevanten Daten im ASM zugreifen und diese bei Bedarf auch in das
Filesystem kopieren.
# rman target /
copy datafile 1 to ‘/tmp/datafile_1.dbf’;
backup as copy archivelog sequence 99 format ‘/tmp/ARCH_%d_%t_%s_%p’;
4. Diskgroup versehentlich gelöscht
Beim Löschen einer Diskgroup (drop diskgroup) wird nur der Header verändert. Mit
dem Tool „kfed“ kann der Header nicht nur ausgelesen sonder auch geschrieben
werden.
# Header auslesen
Kfed read /dev/asm/oraasm1 aunum=0 blknum=0 text=oraasm1
# datei modifizieren
vi oraasm1
ersetzte:
kfdhdb.hdrsts:
mit:
kfdhdb.hdrsts:
4 ; 0x027: KFDHDR_FORMER
3 ; 0x027: KFDHDR_MEMBER
# datei wieder zurück schreiben
Kfed write /dev/asm/oraasm1 aunum=0 blknum=0 text=oraasm1
# Vorgang mit allen Disks dieser Diskgroup wiederholen
# Diskgroup wieder mounten
Sqlplus / as sysasm
Alter diskgroup data mount;
5. Diskgroup teilweise zerstört
Durch physikalische Fehler kann es passieren, dass eine ASM Diskgroup nicht mehr
angebunden warden kann. Für diesen Fall stellt Oracle das Tool „amdu“ bereit, mit
dem Daten aus nicht gemounteten diskgroups gelesen werden können.
# Offset der Diskgroup +DATA erstellen
amdu –dis ’/dev/asm/oraasm*’ –dump DATA –noimage
# Datei #6 enthält die Metadaten der Diskgroup
grep F00000006 DATA.map
N0004 D0001 R00 A00000008 F00000006 I0 E00000000 U00 ...
# D0001 heißt, die map ist inerhalb der Disk 0001 in AU 00000008
# less report.txt -> suchen nach D0001 um den Namen der Disk zu bekommen
# lesen des Blocks in dem die Metadaten enthalten sind
# und suche nach der benötigten Datei-Nr.
Kfed read /dev/asm/oraasm2 aun=8 | less
# extrahieren der gesuchten Datei – das Format ist <Diskgroup>.<File#>
amdu –dis ‚dev/asm/oraasm*‘ –extract DATA.261
Kontaktadresse:
Name
Firma
Straße, Hausnummer
Telefon:
E-Mail:
Internet:
Benjamin Kurschies
QSC AG
Grasweg 62-66
22303 Hamburg
+49 (0) 40-27136-8284
[email protected]
www.qsc.de