Monat: Dezember 2014

Die verlorene Zeit

In der Lagebesprechung am Beginn eines Tuning Einsatzes beschrieben IT Mitarbeiter eines Schweizer Unternehmens Ihr Problem: „Unsere neue Application läuft bei uns und auch als lokale Installation bei unserem Tochterunternehmen in den USA. Beide Installationen werden von unserer lokalen Datenbank in der Schweiz bedient. Der Schritt um den es bei diesem Einsatz geht läuft bei uns 10 Sekunden, in den USA rund 2 Minuten. Wir haben die Application getraced, aber wir können das Problem nicht finden. Zugegeben, es sind zehntausende SQL Befehle die wir abarbeiten, aber jeder Einzelne ist schnell und Ihre Gesamtdauer beträgt rund 10 Sekunden.“

Was glauben Sie ist die Ursache des Problems? Wie würden Sie Ihre Annahme überprüfen? Was könnte eine kurzfristige Lösung sein? Wie sollte eine langfristige Lösung aussehen?

Advertisements

Lösung zu I/O LANDKARTE EINER APPLIKATION

Die Buffer gets ganz rechts zeigen uns die Stärke der Aktivität auf den entsprechenden Segmenten.
Die Liste ist nach Buffergets sortiert, das heisst die Segemente mit der höchsten Aktivtät sind ganz oben.
Wir können eigentlich ziemlich sicher sein, dass die Segemente mit der meisten Aktivtät auch die zentralsten und die wichtigsten der ganzen Application sind. (Wenn eine Datenbank einer Applikation entspricht.)
Damit wird Eines klar. Das Studium der Auswertung sind wichtig.
Normalerweise würden wir erwarten, dass die physical reads sich proportional zu den Buffer gets verhalten. Entsprechend der Faustregel, dass maximal 10% aller Buffer gets physical reads umgewandelt werden sollen. In der Realität gibt es jedoch sehr häufig eine Konzentration der physical reads auf wenige segmente.
Diese Segmente, welche eine überproportionale Anzahl physical reads aufweisen zeigen einen einen Engpass im physichen Design auf. Es kann sich um fehlende Indexes handeln oder um schlecht geclusterte Daten.
Eine Untersuchung aller execution Pläne welche die auffällige Segmente referenzierten hat schnell Klarheit geschaffen.

AWR Warehouse Tagebuch

Ich werde im folgenden Log die Erfahrungen beim Aufbau eines AWR warehouse aufschrieben, die für andere Oracle Anwender nützlich sein können.

Ich werde keine allgemeine Einführung in das WAR warehouse schreiben. Um heraus zu finden was es ist und wozu man es braucht, möchte ich z.B. auf den Blog von Kellyn Pot’Vin-Gorman verweisen: http://dbakevlar.com/2014/06/awr-warehouse-in-em12c-rel-4/.

Tag 1 (24.12.2014)

Beim verbinden der Datenbanken mit dem AWR warehouse wird PL/SQL code im User DBSNMP installiert.  In einigen Datenbanken traten beim compilieren Fehler auf.
Wir stellten fest, dass diese Datenbanken gehärtet worden waren.
Dabei werden einem User alle Rechte entzogen, die er nicht unmittelbar braucht.  Wir mussten die folgenden Rechte nachträglich vergeben:

grant execute on utl_file to dbsnmp;
grant execute on  DBMS_RANDOM  to dbsnmp;
grant execute on   DBMS_SCHEDULER  to dbsnmp;

Die Rechte für die Datenbanken im AWR warehouse haben wir über SSH vergeben. Bei einer Einzeldatenbank war dies ohne weiteres möglich, bei einer cluster datenbank wurde die Möglichkeit gar nicht angeboten. Es handelt sich um einen Fehler im GUI, der mit dem nächsten patch korrigiert werden soll. Vorläufig kann man als Workaround EMCLI verwenden.

Apropos EMCLI. Die Adminstration des AWR warehouse über EMClI ist lückenhaft. Auch das soll sich mit dem nächsen Patch vom Dezember 2014 ändern.