Ein Gastartikel von Oliver Frese
Regelmäßige Backups können extrem anstrengend sein. Vor allem, wenn immer wieder die Chefs mit einer neuen Backupstrategie um die Ecke kommen: neue Anzahl an Versionen, neue Anzahl an Backups pro Woche und ähnliche Forderungen.
Nach meiner Teilnahme an Philipps Automation Engine Database Knowledge Workshop kam mir eine Idee, wie ich das bei mir im Betrieb vereinfachen kann: Mit einer VaraXML.
Die VaraXML und 3 JOBs
Ich habe also EINE VaraXML angelegt, um alle SAP Backups zentral zu steuern: Meine Vara.Systeminfos. Pro SID gibt es einen Eintrag. Neben den Backups benutze ich diese Vara mittlerweile auch für viele andere Verarbeitungen.
Sie enthält alle Infos, die zur Durchführung der Backups nötig sind. Wichtige Eckdaten wie Name, Agent, OS, SAP System, Datenbank, Pfade. Aber auch Steuerungsparameter für wichtige Jobs sowie Logeinträge der Backups.
<?xml version="1.0" encoding="ISO-8859-15" standalone="no"?>
<sid>
<name><em>SID</em></name>
<agent><em>Agentname</em></agent>
<host><em>Hostname</em></host>
<os><em>AIX</em></os>
<rolle><em>E</em></rolle>
<db><em>ORACLE</em></db>
<db_home<em>>/oracle/SID/122</em></db_home>
<db_port><em>PORT</em></db_port>
<db_schema><em>Schemaname</em></db_schema>
<stack><em>abap</em></stack>
<utl_home<em>>/oracle/SID/122/dbs</em></utl_home>
<backup_versions><em>{VARA.ALL@BACKUP$VERSIONEN,Entwicklung,1}</em></backup_versions>
<backup_sessions><em>4</em></backup_sessions>
<last>13122019</last>
<start>01:00:19</start>
<end> 01:23:16</end>
<length>22 min 55 sec.</length>
<size>946120.797 MB</size>
<logfile>bfcrevsz.anf</logfile>
<tss><em>BACKUP Location</em></tss>
<backup><em>AKTIV</em></backup>
...Das Backup wird dann mit einem einfachen Workflow aus 3 Jobs durchgeführt.
Der Plan zieht sich im Script zuerst den Inhalt der Vara und prüft, ob das Backup laufen soll (<backup>AKTIV</backup>) und ob die letzte Backup-Location gefüllt ist (<tss>BACKUP Location</tss>). Falls nicht gibt es ein Fehlerhandling und Mails werden verschickt. Außerdem wird die Generierung des Plans abgebrochen.
- Der erste Job erstellt zur Laufzeit das UTL File für das Backup
- Der zweite ist das Backup selbst
- Der dritte lässt im Falle ORACLE noch einen br-archive laufen. Sprich der Plan gilt sowohl für Oracle als auch DB2
JOB 1 ist maßgeblich für die Vereinfachung des Backup-Prozesses verantwortlich. Wenn ich neue Anforderungen oder Strategien vorgelegt bekomme, muss ich mich nicht mehr wie früher in 70 Betriebssystemen anmelden und manuell die UTL-Files anpassen. Stattdessen holt sich JOB 1 die Werte aus der VaraXML und schreibt dynamisch die UTL-Datei.
JOB 2 ruft dann je nach DB-Typ den jeweiligen Commandline-Befehl für das Backup auf und achtet dabei darauf, ein Flip-Flop-Verfahren zu gewährleisten. Hierfür wird der letzte Sicherungsstandort aus der Vara geholt und dann der andere Standort an den Befehl übergeben.
Der gesamte Prozess läuft jetzt zentralisiert im UC4 ab.
Anwendungsbeispiele für die VARA.SYSTEMINFOS
Die VARA.SYSTEMINFOS ist nicht nur beim Durchführen der Backups nützlich. Sie erleichtert mir auch ansonsten sehr oft die Arbeit.
Ganz simpel ist das erste Anwendungsbeispiel: Ich habe mir einen Job gebaut, der mir eine XLS aus den Informationen der VARA schreibt. Per Knopfdruck bekommen wir damit eine Übersicht über alle Infos zu unseren SAP Systemen. Ich frage dafür zusätzlich per SQL ab, an welchen Tagen die jeweiligen Backups im Schedule eingeplant sind und visualisiere die Infos in der Tabelle.
Beim zweiten Anwendungsfall zeigt sich mal wieder, dass Faulheit ein wichtiger Antrieb für menschliche Innovation ist. Innerhalb kurzer Zeit musste ich zweimal die Anzahl Versionen der Backups ändern. Ich hätte also zweimal 70 Einträge in meiner VARA.SYSTEMINFOS anpassen müssen. Das war mir zu viel.
Deshalb habe ich eine statische VARA eingeführt und verweise innerhalb der VARA.SYSTEMINFOS mit einer geschweiften Klammer auf die statische VARA:
<backup_versions>{VARA.ALL@BACKUP$VERSIONEN,Entwicklung,1}</backup_versions> In ihr steht wie viele Versionen bei welcher Rolle des Systems vorgesehen sind.
Und um alles noch ein wenig automatischer zu machen, lasse ich auch immer, wenn wir ein neues SAP System bekommen, automatisch den Sicherungsjobplan erstellen. Dafür benutze ich ein PromptSet, eine Sicherungsplanvorlage und das folgende Skript:
...
: PSET &VORLAGE# = 'JOBP.HOST@ONLINE_SICHERUNG_FF$SID'
: PSET &JOBNAME# = 'JOBP.&AGENT#@ONLINE_SICHERUNG_FF$&SID#'
...
! XML laden & ändern & zurückschreiben
!Bei Jobplänen nur den Jobplannamen anpassen
: SET &HND# = PREP_PROCESS_FILE(UC4SERVER, &FILE_EXP#)
: SET &XML_PROCESS# = XML_PROCESS_TO_DOM(&HND#)
: SET &XML_NODE# = XML_SELECT_NODE(&XML_PROCESS#, '/uc-export/JOBP')
: SET &XML_ATT# = XML_SET_ATTRIBUTE(&XML_NODE#,"@name","&JOBNAME#")
: SET &XML_RET# = XML_PRINTINTOFILE('&FILE_EXP#', &XML_PROCESS#)
: XML_CLOSE Nach dem Import der erstellten XML-Datei muss ich die Sicherung nur noch einplanen.
Nebenbei werden auch direkt die CONN.OBJs für die DB angelegt, dort die Verbindungsparameter und Anmeldedaten eingetragen, die Loginobjekte erweitert und ein Eintrag in meiner VARA.SYSTEMINFOS erstellt.
Noch mehr Anwendungsfälle?
Viele der Ideen, die ich in diesem Artikel vorgestellt habe, kamen mir, nachdem ich am Automation Engine Database Knowledge Workshop teilgenommen hatte. Vorher hatte ich noch nie mit einer VaraXML gearbeitet, jetzt kann ich mir kaum mehr vorstellen, wie ich ohne sie zurechtkommen sollte.
Ich bin mir auch sicher, dass es noch viel mehr Möglichkeiten gibt, diese VARAs zu benutzen.
Benutzt du auch XML Varas für ähnliche Anwendungsfälle? Erzähle uns davon in den Kommentaren.
Oliver Frese
Automic/SAP/DMS Administrator
Oliver ist gelernter IT-Kaufmann. Seit 2010 ist er bei Count+Care GmbH & Co KG tätig als Automic Admin/Operator/Programmierer, SAP Systemadministrator und als DMS Administrator.
