Seiten

Donnerstag, 25. April 2013

Bug im jQuery Mobile von APEX 4.2.1: "Error loading page"

Das jQuery Mobile, welches mit APEX 4.2.1 ausgeliefert wird, hat einen gemeinen Bug (bug# 16184694), der zuschlägt, sobald man nicht direkt auf den Webserver/APEXListener zugreift, sondern der Zugriff per redirect durch einen Proxy geleitet wird - das ist z.B. dann der Fall, wenn per Smartphone auf die DB zugegriffen werden soll und der Webserver in der DMZ steht.
Bei mir verhinderte der Bug bereits das Login in die Applikation.

Lösung:
Enter

$("#wwvFlowForm", apex.gPageContext$).attr("data-ajax", false);

into "Execute when Page Loads" attribute of page which contains the select list page item to not use an AJAX call for the submit. Avoiding the AJAX call will trigger a full page refresh which will also cleanup the jQuery Mobile call stack.
Quelle: https://forums.oracle.com/forums/thread.jspa?messageID=10857686&tstart=0

Freitag, 19. April 2013

Systemstatistiken

In der 01/2013 der DOAG News ist ein sehr empfehlenswerter Artikel von Thorsten W. Grebe über die Oracle Systemstatistiken zu finden: “Glücksspiel Systemstatistiken - Das Märchen vom typischen Workload“ (S.52) Auf  www.twg-it.de ist dazu sein Vortrag auf der DOAG-Konferenz zu finden.
Hr. Grebe stellt in dem DOAG-News-Artikel sehr gut dar, dass es nicht so einfach ist, an verlässliche Systemstatistiken zu kommen, wie Oracle es in seiner Doku unterstellt.
Hier sieht man die Defaultwerte einer unberührten DB:

SQL> set wrap off;
SQL> col sname format a20;
SQL> col pname format a20;
SQL> col pval2 format a20;
SQL> select * from aux_stats$;

SNAME                PNAME                     PVAL1 PVAL2
-------------------- -------------------- ---------- --------------------
SYSSTATS_INFO        STATUS                          COMPLETED
SYSSTATS_INFO        DSTART                          11-03-2011 06:38
SYSSTATS_INFO        DSTOP                           11-03-2011 06:38
SYSSTATS_INFO        FLAGS                         1
SYSSTATS_MAIN        CPUSPEEDNW           1720,20725
SYSSTATS_MAIN        IOSEEKTIM                    10
SYSSTATS_MAIN        IOTFRSPEED                 4096
SYSSTATS_MAIN        SREADTIM
SYSSTATS_MAIN        MREADTIM
SYSSTATS_MAIN        CPUSPEED
SYSSTATS_MAIN        MBRC
SYSSTATS_MAIN        MAXTHR
SYSSTATS_MAIN        SLAVETHR

13 Zeilen ausgewählt.

Abgelaufen: 00:00:00.01
SQL>
Die No-Workloadwerte sind IOSEEKTIM und IOTFRSPEED.

Die Workloadstatistiken waren mir schon lange suspekt. Weil ich mir bisher nie sicher war, wann und wie lang ich die Workloadstatistiken aufzeichnen soll, habe ich es lieber ganz sein lassen. Und das ist bis auf weiteres auch in Ordnung. Für gute Workloadstatistiken muss mehr Aufwand betrieben werden, als Oracle Glauben machen will.
Und hier gilt diesmal im Gegensatz zu den Objektstatistiken: Lieber Defaultstatistiken als schlechte Statistiken.

Wobei: Für die No-Workloadstatistiken gilt das nicht ganz, bzw. ist hier zumindest der Aufwand nicht so hoch, wie für die Generierung plausibler Workloadstatistiken.
Die No-Workload-Statistiken kann man ruhig generieren, wenn man auch tatsächlich prüft, ob die Werte sinnvoll sind. Wird der DB-Server gerade stark beansprucht, während die No-Workloadwerte generiert werden, können auch diese Statistiken verfälscht werden.

No-Workloadstatistiken generiert man mit dem Package DBMS_STATS:
SQL> exec DBMS_STATS.GATHER_SYSTEM_STATS();

PL/SQL-Prozedur erfolgreich abgeschlossen.

Abgelaufen: 00:00:08.95
SQL> select * from aux_stats$;

SNAME                PNAME                     PVAL1 PVAL2
-------------------- -------------------- ---------- --------------------
SYSSTATS_INFO        STATUS                          COMPLETED
SYSSTATS_INFO        DSTART                          04-19-2013 07:32
SYSSTATS_INFO        DSTOP                           04-19-2013 07:32
SYSSTATS_INFO        FLAGS                         1
SYSSTATS_MAIN        CPUSPEEDNW                 1460
SYSSTATS_MAIN        IOSEEKTIM                     7
SYSSTATS_MAIN        IOTFRSPEED                28796
SYSSTATS_MAIN        SREADTIM
SYSSTATS_MAIN        MREADTIM
SYSSTATS_MAIN        CPUSPEED
SYSSTATS_MAIN        MBRC
SYSSTATS_MAIN        MAXTHR
SYSSTATS_MAIN        SLAVETHR

13 Zeilen ausgewählt.

Abgelaufen: 00:00:00.00
SQL>

Workloadstatistiken lassen sich natürlich auch manuell einstellen (dbms_stats.set_systems_stats(...)) oder auf Default zurücksetzen (dbms_stats.delete_system_stats()):
SQL> exec DBMS_STATS.DELETE_SYSTEM_STATS ();

PL/SQL-Prozedur erfolgreich abgeschlossen.

Abgelaufen: 00:00:00.01
SQL> select * from aux_stats$;

SNAME                PNAME                     PVAL1 PVAL2
-------------------- -------------------- ---------- --------------------
SYSSTATS_INFO        STATUS                          COMPLETED
SYSSTATS_INFO        DSTART                          04-19-2013 07:38
SYSSTATS_INFO        DSTOP                           04-19-2013 07:38
SYSSTATS_INFO        FLAGS                         0
SYSSTATS_MAIN        CPUSPEEDNW                 1460
SYSSTATS_MAIN        IOSEEKTIM                    10
SYSSTATS_MAIN        IOTFRSPEED                 4096
SYSSTATS_MAIN        SREADTIM
SYSSTATS_MAIN        MREADTIM
SYSSTATS_MAIN        CPUSPEED
SYSSTATS_MAIN        MBRC
SYSSTATS_MAIN        MAXTHR
SYSSTATS_MAIN        SLAVETHR

13 Zeilen ausgewählt.

Abgelaufen: 00:00:00.00
SQL>

Beruhigend: Erst wenn man tatsächlich Performanceprobleme und die Systemstatistiken als Ursache identifiziert hat, muss man sich eingehend mit dem Thema befassen.
Bis dahin gilt weiter: Ursache Nr.1 für Performanceprobleme in der Anwendung ist schlechtes SQL.