rz10.de – das SAP Basis- und Security Blog

Fehler beim BI_CONT einspielen: Quellsystem existiert nicht

Bei der Aktualisierung des BI Contents (auf BI_CONT 7.06) gab es in der SAINT einen Abbruch in der Phase RS_DTRF_AFTER_IMPORT/XPRA_EXECUTION: Quellsystem <Name des Quellsystems> existiert nicht (RSAR203). Nach kurzer Suche sind wir auf Hinweis 1564964 gestoßen: Den Funktionsbaustein RSAR_LOGICAL_SYSTEM_DELETE in der SE37 mit I_LOGSYS = <zu löschendes Quellsystem> und alle anderen Parameter = ‚X’ ausführen. (Vorher beachten, ob der dort erwähnte Hinweis eingespielt worden ist)

Das Problem dabei war: Wir mussten den Import in der SAINT immer wieder starten und jedes mal wurde nur genau ein Quellsystem als verwaist gemeldet. Es stellte sich aber hinterher heraus, dass verwaiste Einträge von fast einem Duzend Quellsystemen im System vorhanden waren. Die Laufzeit des Upgrades steigerte sich damit um zwei Tage, da er immer wieder nach der Bereinigung eines Systems neu gestartet werden musste.

Ich habe leider keinen offiziellen Weg gefunden, um im Vorfeld verwaiste Quellsysteme zu finden. Daher habe ich versucht, der Datenbank etwas Brauchbares zu entlocken. Die Tabelle RSBASIDOC enthält die Quellsysteme, so wie man sie auch in der RSA13 sehen kann. Da in den Hinweisen die Tabelle RSOLTPSOURCE für BW 3.x als Workaround genannte wird, habe ich schließlich folgendes SQL-Statement entwickelt:

select distinct logsys from  RSOLTPSOURCE where logsys not in (select slogsys from RSBASIDOC)

Dieses Statement kann man z.B. auch über das DBACOCKPIT absetzen. Die Ergebnisliste wurde dann vom Anwendungssupport geprüft. Tatsächlich waren alle Treffer Quellsysteme, die schon vor einiger Zeit aus der RSA13 entfernt worden sind. Mit der Liste und dem Vorgehen aus Hinweis 1564964 konnten wir die verwaisten Quellsysteme im Vorfeld löschen und die Upgradezeit in den Folgesystemen von drei Tagen auf wenige Stunden verkleinern.

Performance Analysen im BW – ein erster Ansatz

In diesem Beitrag geht es um die ersten Schritte zur Performance Analyse in einem BW System. Vieles kann natürlich auch für ERP Systeme betrachtet werden.

Performance Engpässe in einem SAP BW System liegen aus meiner technischen Sicht natürlich eher in der Applikation Um das der Anwendungsbetreuung auch zu dokumentieren, können die folgenden Schritte hilfreich sein.

Zuerst schauen wir in der st03n

Hier sind folgende Aspekte zu beachten:

• Proc. Time ist eine berechnete Zeit
• RFC ist wichtig für BEx Queries
• Wenn Proc. Time = ein Vielfaches der CPU, dann deutet das auf einen CPU Engpass hin
• Die mittlere Wartezeit sollte zwischen 1 und 10 % der durchschnittlichen Antwortzeit betragen => sonst liegt ein allgemeines Performance Problem vor. Ausgelöst eventuell durch nicht genügend Workprozesse. Für den Anwender bedeutet das lang laufende Transaktionen
• Die mittlere DB Zeit sollte nicht mehr als 40 – 45 % der Antwortzeit betragen. Alles andere könnte seine Ursache in DB Problemen (z.B. auch CPU Engpass auf dem DB Server) oder Netzwerkproblemen (zwischen Appl. Und DB Server) haben
• GUI Zeit sollte bei < 250 ms liegen => sonst NW Engpass oder Probleme auf dem Präsentationsserver

   

  

• In diesem Beispiel ist die Durchschnittliche Wartezeit kleiner als 50 ms, damit liegt kein allgemeines HW Problem bezüglich der Performance vor.

• Tauchen in den Hitlisten (Ranking List) SAPMHTTP Aufrufe auf, so können das BW Queries sein
• Wenn man dann einen Doppelklick auf einen Eintrag macht, dann bekommt man die alle Zeiten zu dem Workprozeß angezeigt:

^

• Hier schaut man auch wieder auf die durchschnittliche Wait Time, ist diese zu hoch, stehen nicht genügend Ressourcen zur Verfügung (CPU)

Diese Übersicht könnte der erste Schritt sein, wenn Performance Engpässe in einem BW System auftauchen.

Natürlich gibt es noch viele weitere Aspekte, z.B. Einstellungen auf dem DB Server, Performance Aspekte innerhalb der DB etc.. Auf diese werde ich in weiteren Beiträgen eingehen.