Aktuelles

SSFS und BRTOOLS

Dienstage sind aktuell sehr kurzweilig. Anstatt in die Firma geht es zum wöchentlichen Vor-Ort Einsatz beim Kunden in Frankfurt. Aus dem Rheinland sind das gute 2,5 Stunden Fahrt für eine Strecke. An solchen Tagen freut man sich auf Routineaufgaben, die man zeitlich gut terminieren kann. Diese Woche steht ein Kernel Tausch auf der SAP Entwicklungs- und Testumgebung des Kunden an. „Habe ich schon häufig gemacht, ist kein Problem!“, denke ich und mache mich an die Arbeit. Schnell ist der neue Kernel  sowie die BRTOOLS vom SAP Marketplace heruntergeladen, und abgemischt. Die Tage komplizierter Fehler in neuen Kernels sind vorbei, was soll da schon passieren?

Da es sich um SAP Systeme auf Windows Basis handelt, beende ich die Instanzen per Microsft Management Console MMC.  Danach die SAP Dienste in der Computerverwaltung stoppen und eine Sicherungskopie des Kernelverzeichnisses erstellen. Im Anschluss kopiere ich den neuen Kernel über den bestehenden. Das vermeidet den Verlust von Programmen, die manuell dort abgelegt wurden. Ein Neustart der Instanz und nach knapp 30 Minuten ist die Wartung abgeschlossen. Eine kurze Prüfung im System sieht sauber aus, die Benutzer können wieder arbeiten. Wenn es eins gibt was ich im Laufe der Zeit gelernt habe, dann ist es eine Prüfung der periodischen Datenbankjobs. Zu oft wurde man nachts nach einem Kerneltausch alarmiert, weil irgendwer unsauber gearbeitet hat. Ein Sprung auf die Kommandozeile und ich gehe die gängigsten BRTOOLS Kommandos durch. Der Update Statistics läuft sauber durch, doch die Datenbankprüfung bricht mit einer böse Überraschung ab:

orasid > brconnect –p initSID.sap –l E –f check
ORA-01031 insufficient privileges

„Welch fantastischer Start in den Tag ...“ kann man meine Gedanken in diesem Moment freundlich formuliert beschreiben. Ich gehe in Gedanken alle Schritte durch und frage mich, wie es zu diesem Fehler kommen mag. Mein erster Gedanke ist in diesem Moment, dass die neue Programmversion mehr Rechte benötigt und das Problem mit den sapdba_role.sql und den sapconnect.sql  Skripten und den damit verbundenen Rollen zu tun hat. Also das ganze im richtigen Datenbankschema ausgeführt, ausprobiert und erneut die Ernüchterung – keine Verbesserung der Situation. So quäle  ich an mich im Marketplace durch viele (teils veraltete) SAP Notes, die mir alle leider nicht wirklich weiterhelfen. Nach ergebnisloser Suche vergleiche ich die Konfiguration mit dem ungepatchten Produktivsystem - dort funktioniert immerhin noch alles. Auch dort setzt der Kunde zwar einen älteren 7.40er Kernel ein, aber aus irgendeinem Grund sind die BRTOOLS noch auf einem alten 7.20er Stand. Diese benutzen im Gegensatz zu der 7.40er Version den alten OPS$ Mechanismus zur Anmeldung an der Datenbank. Beim letzten Upgrade wurden der Kernel auf SSFS umgestellt.

SSFS ist ein gutes Stichwort! Ein kurzer Anruf bei den Teamkollegen in Köln und ich erhalte den  hilfreichen Tipp, dass für die BRTOOLS SSFS separat konfiguriert werden muss. Die Dokumentation ist zwei Minuten später per Mail da und ähnelt sehr stark den Einstellungen für den Kernel.

Im ersten Schritt lege ich die SSFS Dateistruktur auf dem System an. Der Pfad kann frei gewählt werden. Es müssen die üblichen Verzeichnisse „security/rsecssfs/data“ und „security/rsecssfs/key“ vorhanden sein. Darüber hinaus lege ich einen User für die Kommunikation mit BRTOOLS an. Ich nehme in meinem Fall den User BRT$ADM. Erstellt wird er über das Kommando:

CREATE USER BRT$ADM IDENTIFIED BY PASSWORD;

Nachdem der User angelegt ist, muss dieser auch die entsprechende Berechtigungen auf der Datenbank erhalten. Der Einfachheit halber reicht die Rolle „SAPDBA“, da diese alle notwendigen Datenbankberechtigungen enthällt:

GRANT SAPDBA TO BRT$ADM;

Im folgenden Schritt muss das Passwort im SSFS Speicher hinterlegt werden. Praktischerweise bieten die BRTOOLS eine automatisiertes Verfahren über das Kommando:

orasid > brconnect –u system/password –f change –o BRT$ADM –p password –s brtools

Nach der Anpassung, starte ich die Datenbankprüfung erneut.

brconnect –p initSID.sap –l E –f check
ORA-01031 insufficient privileges

Zu früh gefreut? Nein nur die Dokumentation nicht zu Ende gelesen. Die Kommandozeile muss von „–u /“ auf „-u //“ angepasst werden. Erst damit benutzt BRTOOLS nämlich automatisch den User BRT$ADM. Ein Beispiel wie es aussehen sollte, sobald alles sauber konfiguriert ist und BRTOOLS im entsprechenden Menü gestartet ist:

BRCONNECT main options for database system check
 1 - BRCONNECT profile (profile) .......... [initSID.sap]
 2 - Database user/password (user) ........ [//]
 3 - Use default check settings (default) . [no]
 4 ~ Database owner for check (owner) ..... []
 5 ~ Ignore DBCHECKORA table (ignore) ..... []
 6 ~ Ignore DBSTATC table (igndbs) ........ []
 7 ~ Exclude from check (exclude) ......... []

Da die Einplanung der Jobs über die Transaktion DB13 läuft, müssen auch dort die Aufrufparameter angepasst werden. Dafür ist die Tabelle „SDBAC“ anzupassen. In der Standardauslieferung ist nur die klassiche Anmeldung mittels „-u /“ hinterlegt. Ich passe alle Kommandos an und endlich läuft die Datenbankprüfung auch wieder über die DB13.

Ein kurzes Fazit vor dem Mittagessen: Der Kerneltausch hat fast 3 Stunden gedauert und ich habe mal wieder viel Zeit mit Recherche im Service Marketplace verbracht. Mit der Suchmaske muss ich mich noch besser anfreunden. Immerhin hat das firmeninterne Wissensnetzwerk gut funktioniert und der Kunde ist zufrieden. Für den nächsten Kerneltausch ist man gewarnt ... zumindest solange bis sich SAP wieder etwas neues ausdenkt.