PL-SCO-30049 SnapCenter Clone

Oracle Standard Edition Datenbank und NetApp SnapCenter

Oracle SE Lizensierungsregeln

Wenn man die Oracle Standard Edition Datenbank Lizenzkonform nutzen möchte, gibt es zwei Varianten, wie man das Ziel für die Archivelog Files definiert:

Eine Flash Recovery Area mittels db_recovery_file_dest sowie db_recovery_file_dest_size oder
die beiden Parameter log_archive_dest und log_archive_duplex_dest.

Wichtig dabei ist das oder - man darf nicht beides nutzen. Auch die Nutzung der log_archive_dest_x Parameter ist mit der Oracle Standard Edition Datenbank nicht erlaubt.

Damit man die Möglichkeit hat, dass die Archivelog Files vom SnapCenter gelöscht werden können, darf man die Flash Recovery Area aber nicht nutzen - Oracle möchte nicht, dass Fremdprodukte darin Files einfach löschen und NetApp hält sich korrekterweise daran.

NetApp SnapCenter (bis inkl. 4.1.1P1 verifiziert) verhalten

NetApp SnapCenter geht aber davon aus, dass man die log_archive_dest_x nutzt. Die beiden von Oracle für die Standard Edition vorgesehenen Parameter werden einfach ignoriert.

Zusätzlich verlangt NetApp, dass bei allen log_archive_dest´s lediglich der PFAD angegeben wird. Der Filename für das Archivelogfile muss mittels log_archive_format definiert sein. Nachdem Oracle bei anlegen der Archivelogfiles einfach die Inhalte von log_archive_dest und log_archive_format zusammengehängt hat, hat es sich bei vielen DBAs eingebürgert, dass im Destinationsparameter auch die ersten Zeichen für den Filenamen enthalten ware. Das darf aber aus Sicht von NetApp SnapCenter nicht der Fall sein und gehört sauber getrennt.

Was ist jetzt eigentlich das Problem?

Nun, das Problem ist, dass SnapCenter aktuell die beiden Parameter log_archive_dest und log_archive_duplex_dest einfach ignoriert und nicht in das init.ora/spfile.ora des Clones mit aufnimmt. Nachdem die Parameter nicht vorhanden sind, können Sie auch nicht auf das Verzeichnis wohin der SnapShot der Archivelogs gemountet wird, angepasst werden. Somit nutzt Oracle das Defaulting für die Archivelog Parameter und das lautet, dass die Archivelogs in $ORACLE_HOME/dbs gesucht werden. Nur werden dort die für das Recovery benötigten Archivelogs ganz sicher nicht gemounted...

Hier ein Beispiel, wie das Recovery im alert.log eines Clones fehl schlägt:

ALTER DATABASE RECOVER AUTOMATIC DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL PARALLEL 1
	Media Recovery Start
	Serial Media Recovery started
	Media Recovery Log /u01/app/oracle/product/11.2.0/dbhome_2/dbs/arch1_3475_969199969.arc
	Errors with log /u01/app/oracle/product/11.2.0/dbhome_2/dbs/arch1_3475_969199969.arc
	ORA-279 signalled during: ALTER DATABASE RECOVER AUTOMATIC DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL PARALLEL 1 ...
	ALTER DATABASE RECOVER CANCEL
	ORA-1547 signalled during: ALTER DATABASE RECOVER CANCEL ...
	ALTER DATABASE RECOVER CANCEL
	ORA-1112 signalled during: ALTER DATABASE RECOVER CANCEL ...
	Mon Feb 25 10:44:33 2019
	Checker run found 12 new persistent data failures
	Mon Mar 04 15:12:29 2019
	Shutting down instance (immediate)

Was wiederum den SnapCenter Oracle Agent zu folgender Fehlermeldung während der Cloneerzeugung veranlasst:

PL-SCO-30049: Recovery of cloned database with SID CLONE1 failed with error: 
"ORA-30036 Recovery of CLONE1 failed due to the following error(s): 
[ORA-00308: cannot open archived log, 
 ORA-27037: unable to obtain file status, 
 ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below, 
 ORA-01195: online backup of file 1 needs more recovery to be consistent]". 
Manual recovery of the database will be required.

Wie die Meldung schon aussagt, man kann die Datenbank - nachdem man sich das Archivelog Snapshot auf den Server gemounted hat - manuell weiter Recovern und dann korrekt öffnen (OPEN RESETLOGS). Das ist aber nicht das, was wir uns erwarten!

NetApp Bug Report

NetApp arbeitet an dem Problem. Da ist im Bug Report 1223289 nachzulesen. Trotzdem wäre ein Workaround hilfreich....

Workaround

Gemeinsam mit NetApp Support haben wir folgenden Workaround gefunden:

Wenn man im Clone Dialog auf beim Schritt 4 PreOps folgenden Datenbank Parameter hinzufügt, funktioniert das Clonen:

log_archive_duplex_dest=/var/opt/snapcenter/scu/clones/u01_app_oracle_oradata_sid_arch_scu_clone_1

Der Pfad setzt sich aus folgenden Teilen zusammen:

Fix, der Pfad wo SnapCenter Unix zu finden ist: /var/opt/snapcenter/scu/clones/
Der Pfad, auf den LOG_ARCHIVE_DEST in der Quelldatenbank zeigt, wobei "/" durch "_" ersetzt sind: u01_app_oracle_oradata_sid_arch
Fix, der String "_scu_" für SnapCenter Unix
Variable, der String "clone_1" - da man normalerweise nur einen Clone (gleichzeitig) erzeugt, ist das vermutlich in den meisten Fällen "clone_1"

Mit diesem Workaround wird der Clone der Oracle Standard Edition Datenbank erfolgreich durchgeführt.

Breadcrumb