Oracle ASM 12.2 und SnapManager für Oracle (SMO): Clone lassen sich nicht löschen
Mit SMO 3.4.1 - auch mit den Patchlevels P2, P3, P4 verifiziert - lassen sich in SAN Environments Clone von ASM 12.2 Diskgroupen unter Linux (auf OEL7/RHat7 verifiziert) nicht mehr löschen.
Ursachenforschung
SMO verwendet explizit das Script /etc/init.d/oracleasm. Der Versuch die ASM Disks zu löschen, bricht dann mit einem Fehler ab. Versucht man das verwendete Kommando manuell abzusetzen bekommt man ebenfalls die folgende Fehlermeldung:
[root@srvdb12cr201 disks]# oracleasm deletedisk -v SM_DSK_1533704532601
Clearing disk header: oracleasm-write-label: Unable to open device "/dev/oracleasm/disks/SM_DSK_1533704532601": Device or resource busy
failed
Unable to clear disk "SM_DSK_1533704532601"
Trotz Prüfung aus OS Ebene mit fuser, lsof, ... gibt es keinen Prozess, der noch auf das Device zugreift. Auch innerhalb vom ASM werden die DISKEN als FORMER gekennzeichnet und sollten somit problemlos gelöscht werden können.
Bei Oracle gibt es zu diesem Thema auch einen Metalink Eintrag: "oracleasm deletedisk Unable to open device or resource busy failed Unable to clear disk (Doc ID 2301108.1)".
Dieser ist aber nur bedingt Hilfreich, da dieser folgenden Grund nennt:
This situation might arise as many applications are not aware of the presence of multipath or any other device mapping software, as long as the application has access to the resource. If multipath keeps control over the device ASM will not be able to delete it.
Die vorgeschlagene Lösung funktioniert allerdings nicht:
# multipath –f </dev/oracleasm/disks/XXXXXX>
Now try again
$ oracleasm deletedisk –v <XXXXXX>
An anderen Stellen im Internet findet man so lustige Empfehlungen wie: "Rechner durchstarten, dann geht es (meistens) löschen" - nicht unbedingt das, was man bei Produktionssystemen so gerne macht!
Offizieller Weg das Problem zu beheben
Im SMO kann man den Clone mit "FORCE" löschen, dann wird der oracleasm Fehler ignoriert, die ASM LUNs bleiben am OS aber erhalten. Problematischer ist aber, dass man die Flex Clone Volumes in der NetApp selbst löschen muss wodurch aber "aktive" Snapshots zurück bleiben. Diese bekommt man nur los, wenn man die Snapshots davor löscht - auch nicht gerade das, warum man Snapshots einsetzt...
Workaround
Vorsicht: Sie müssen 100% sicher sein, dass ASM die Disken als FORMER markiert hat und weder mit fuser noch mit lsof (siehe Metalink Document weiter oben) kein Ergebnis bringen! Wird die LUN noch verwenden, können Programme/Applikationen abstürzen!
Es scheint sich um ein Problem beim Unmounten der ASM Disks zu handeln, das das Löschen der angelegten Disks verhindert - also helfen wir beim Löschen einfach nach!
Die Lösung ist im /etc/init.d/oracleasm die deletedisk-Option ein bisschen zu erweitern umd die Disk-Header zu überschreiben. Suchen Sie im /etc/init.d/oracleasm nach dem Code für deletedisk und ergänzen Sie diesen wie folgt:
deletedisk)
if [ -z "$2" ]
then
echo "Action \"deletedisk\" requires an argument specifying the disk to delete." >&2
echo "See oracleasm.init(8) for more information." >&2
exit 1
fi
## added for delete without reboot
if [ $2 ]
then
dd if=/dev/zero of=$2 bs=1M count=10 1>/dev/null 2>&1
fi
echo -n "Removing ASM disk \"$2\": "
"${ORACLEASM}" deletedisk -v -l "${ORACLE_ASMMANAGER}" "$2" \
1>>/var/log/oracleasm 2>&1
if_fail $? "Unable to delete disk \"$2\", see /var/log/oracleasm"
;;
Damit läuft alles wieder wie erwartet. Die ASM Disks werden sauber gelöscht und SMO kann somit den Clone der Datenbank sauber entfernen.