Authentifizierung bei APEX-Zugriff deaktivieren

Installiert man APEX mit PL/SQL Listener in einer Datenbank (außer XE), so muss man bei jedem Zugriff auf die APEX-Weboberfläche ein Username und Passwort eingeben. Es handelt sich hierbei um die Authentifizierung an der XML-Datenbank. Um dies abzustellen muss der folgende Code ausgeführt werden:

SET SERVEROUTPUT ON

DECLARE
  l_cfgxml XMLTYPE;
  l_value VARCHAR2(5) := 'true'; -- (true/false)
BEGIN
  l_cfgxml := DBMS_XDB.cfg_get();

  IF l_cfgxml.existsNode('/xdbconfig/sysconfig/protocolconfig/httpconfig/allow-repository-anonymous-access') = 0 THEN
    SELECT insertChildXML (
      l_cfgxml, '/xdbconfig/sysconfig/protocolconfig/httpconfig',
      'allow-repository-anonymous-access',
      XMLType('<allow-repository-anonymous-access xmlns="http://xmlns.oracle.com/xdb/xdbconfig.xsd">' ||
      l_value || '</allow-repository-anonymous-access>'),
      'xmlns="http://xmlns.oracle.com/xdb/xdbconfig.xsd"'
    ) INTO l_cfgxml FROM dual;

    DBMS_OUTPUT.put_line('Element inserted.');
  ELSE
    SELECT updateXML (
      DBMS_XDB.cfg_get(),
      '/xdbconfig/sysconfig/protocolconfig/httpconfig/allow-repository-anonymous-access/text()',
      l_value, 'xmlns="http://xmlns.oracle.com/xdb/xdbconfig.xsd"'
    )
    INTO l_cfgxml FROM dual;

    DBMS_OUTPUT.put_line('Element updated.');
  END IF;

  DBMS_XDB.cfg_update(l_cfgxml);
  DBMS_XDB.cfg_refresh;
END;
/

(Quelle: My Oracle Support)
That's IT

APEX mit PL/SQL Embedded Gateway

Diese Konstellation ist nur für Umgebungen mit einer geringen Anzahl von Usern geeignet. Es empfielt sich immer einen Web-Server vor APEX zu hängen; Ich habe gute Erfahrungen mit Tomcat gemacht.
Zurück zum PL/SQL Embedded Gateway. Um eine akzeptable performance zu erreichen, sollte der Shared Server konfiguriert werden. Hier ein Beispiel für eine solche Konfiguration:

alter system set shared_servers=5;
alter system set max_shared_servers=20;
alter system set dispatchers='(PROTOCOL=TCP) (SERVICE=XE) (DISPATCHERS=3)';

Der SERVICE muss natürlich auf die entsprechende Umgebung angepasst werden.
That's IT.

log_file_sync

Thank you Riyaj Shamsudeen for your good post on resolving log_file_sync wait events.
Here is the article: http://orainternals.wordpress.com/2008/07/07/tuning-log-file-sync-wait-events/

"Execute to Parse"-Wert ist negativ

Bei einer Datenbank-Analyse fiel mir kürzlich auf, dass bei der Instanz-Effektivität des Statspack-Berichts (gilt auch für AWR) ein negativer Wert für Execute to Parse angegeben wurde. Zunächst bin ich einfach darüber hinweggegangen mit der Annahme, dass dies ein Erfassungsfehler oder sonst ein Bug im Bericht sei.

Instance Efficiency Indicators
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %: 100.00       Redo NoWait %:  99.99
               Buffer Hit %:  99.99  Optimal W/A Exec %: 100.00
              Library Hit %:  93.59        Soft Parse %:  93.83
         Execute to Parse %: -43.82         Latch Hit %:  99.54
Parse CPU to Parse Elapsd %:  98.17     % Non-Parse CPU:  96.70

Was steckt jedoch wirklich hinter dieser negativen Zahl?
Die Anwendung, die diese Datenbank benutzt, hält nicht viel von Bind-Variablen. Deshalb war zu erwarten, dass dieser Wert gegen "0" geht. Ein negativer Wert bedeutet jedoch das Folgende:
Der Wert setzt sich zusammen aus [geparste SQLs]/[ausgeführte SQLs]*100. Normaler Weise sind die ausgeführten SQLs deutlich höher als die geparsten. Deshalb geht der Wert auch eher gegen 100% statt gegen 0%. In diesem Fall war aber die Anzahl der geparsten SQLs deutlich höher als die Anzahl der ausgeführten SQLs. Mit anderen Worten, die Anwendung lässt SQLs von der Datenbank parsen, die aber nie ausgeführt werden. Es werden hier also Datenbankressourcen verschwendet mit Operationen die niemand benötigt.
Was hier zu tun ist, liegt auf der Hand. Die Anwendung muss untersucht und bereinigt werden.

Update 2015-08-27:
Dieses Phänomen habe ich mittlerweile bei mehreren Datenbanken beobachtet. Wann immer die Entwickler der Anwendungen damit konfrontiert wurden, wurde dieses Verhalten der Anwendung vehement abgestritten. Meistens wird behauptet, dass SQLs nicht "prepared" werden und deshalb keine negative Zahl erscheinen kann. Es muss also mehr dahinter stecken als nur diese einfache Rechnung. Fakt ist, dass in der Datenbank etwas nicht ordnungsgemäß läuft.
Updates folgen...

Thrat's IT

Oracle 12c zum Download bereit

Heute ist Oracle 12c zum download freigegeben worden. Hier gehts zur Download-Seite.

Probleme beim Löschen einer Standby Datenbank

Diesen Blogeintrag liegt folgende Umgebung zu grunde:
Eine Oracle Datenbank vom Release 11.2.0.3 läuft auf einem Windows 2008 Server (das Betriebsystem spielt aber keine Rolle). Diese Datenbank hat 2 Standby-DBs die mit Oracle Dataguard Broker konfiguriert sind.
Eine der beiden Standby-Datenbanken sollte still gelegt werden was mit dem Befehl

DGMGRL> disable database "<DBUNIQUE_NAME>"

... normalerweise funktioniert.
Ein paar Tage später wurde die Standby-Datenbank dann komplett entfernt mit DGMGRL> remove database "<DBUNIQUE_NAME>". Zu dem Zeitpunkt war der Standby-Server nicht mehr verfügbar.
Kurze Zeit darauf fiel auf, dass im Enterprise Manager mehrere ARCH-Prozesse hohe Wartezeiten vom Typ "Unknown" haben. Im Alertlog konnten auch Timeouts beim Archivelog-Transport festgestellt werden. Ein Blick in das dazugeörige Tracefile machte dann deutlich, dass die stillgelegte Archivelog Destination Schuld an dem Problem trug. Anscheinend wird mit dem Broker-Befehl "disable database" bzw. "remove database" nur halbe Sache gemacht. Auch ein erneutes "enable configuration" half nichts. Oft ist das ja ein Heilmittel für solche Fälle.
Die Lösung war schlussendlich, die Archivelog-Destination von Hand mit

ALTER SYSTEM SET log_archive_dest_3='';

... zu löschen.
That's IT