Webbasierende Applikationen haben häufig die Eigenschaft, Datenbankverbindungen und somit Connection-Ressourcen der Datenbank zu benötigen. Beim Öffnen einer Website beispielsweise wird eine Datenbankverbindung eingerichtet, nach dem Laden der Website ist die Verbindung zur Datenbank wieder getrennt. Bei wiederholten weiteren Zugriffen auf diese Website werden dann erneut Datenbankverbindungen aufgebaut. Dies bedeutet, dass u.U. eine grosse Anzahl von simultanen Verbindungen (auch Connections) für Webapplikationen in der Datenbank zur Verfügung gestellt werden müssen. Was hat dies nun mit Ihrer Arbeit als Datenbankadministrator zu tun?

Die Ressourcen könnten natürlich mit dem Datenbank Ressource Manager beschränkt werden (siehe dazu auch den Tipp Ressourcen managen mit Database Resource Manager). In der Regel möchte man dies wahrscheinlich verhindern.

Der Einsatz von Oracle Shared Server kann eine Unterstützung liefern, um diese Anforderungen zu lösen, indem Oracle Server Prozesse auf der Datenbankseite "shared" zur Verfügung gestellt werden. Sinnvoll ist dies besonders daher, weil insgesamt weniger Prozesse auf Datenbankseite allokiert werden und somit weniger Ressourcen benötigt werden. Häufig werden diese Prozesse dann auch längere Zeit gehalten. Was ist allerdings bei vielen kurzen Sessions, die wie im obigen Fall beschrieben, ihre Datenbankaktivität über mehrere Requests unabhängig vom "Session State" definieren?

Database Resident Connection Pooling (kurz DRCP), ein neues Feature in Oracle Database 11g, das standardmässig zur Verfügung steht, addressiert genau diese Problematik auf sehr einfache Art und Weise.

Wie funktioniert nun DRCP? Nach dem Einschalten von DRCP wird automatisch eine Menge von dedizierten Datenbankservern zu sogenannten Pooled Servern zusammengefasst. Diese können dann gemeinsam von mehreren Applikationen genutzt werden. Die Clients sind dabei fest mit einem Broker verbunden, der die Zuweisung zu einem Server im Pool regelt. Nach dem Verbindungsaufbau ist das Verhalten vergleichbar mit einer dedizierten Serververbindung - so wird auch PGA Memory statt SGA Memory verwendet.

Wird zum Beispiel die Verbindung von der Clientseite zum Pooled Server beendet, besteht die Verbindung zum Broker weiterhin. Ein weiterer Unterschied zur Shared Server Architektur ist die Tatsache, dass Server im Pool oder Clients, die "idle" sind, nach einer gewissen einstellbaren Zeit beendet werden.

Folgende Graphik zeigt einen Architekturüberblick.


Für eine größere Ansicht auf das Bild klicken.

Danach können Applikationen, die kein eigenes Connection Pooling zur Verfügung stellen, beispielsweise in PHP oder Perl implementierte Applikationen, von dieser Funktionalität profitieren, um ihre Connection-Ressourcen zu verringern.

Die Funktionalität ist datenbankseitig durch das PL/SQL Paket DBMS_CONNECTION_POOL implementiert. DRCP wird dabei mit START_POOL gestartet und STOP_POOL gestoppt. Zu Beginn ist DRCP nicht eingeschaltet und kann, wie im Listing zu sehen ist, folgendermaßen gestartet werden.

execute DBMS_CONNECTION_POOL.START_POOL

sqlplus scott/tiger@stusunmuc-xyz.de.oracle.com:1521/servicename:POOLED

SESPOOL =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = tcp)(HOST = stusunmuc-xyz)(PORT = 1521))
    (CONNECT_DATA =
      (SERVICE_NAME = servicename)
      (SERVER = POOLED)
    )
  )

execute DBMS_CONNECTION_POOL.ALTER_PARAM ('','MAX_THINK_TIME','300');

SELECT * FROM DBA_CPOOL_INFO;

CONNECTION_POOL
--------------------------------------------------------------------------------
STATUS              MINSIZE    MAXSIZE   INCRSIZE SESSION_CACHED_CURSORS
---------------- ---------- ---------- ---------- ----------------------
INACTIVITY_TIMEOUT MAX_THINK_TIME MAX_USE_SESSION MAX_LIFETIME_SESSION
------------------ -------------- --------------- --------------------
SYS_DEFAULT_CONNECTION_POOL
ACTIVE                   10         20          2                     20
               300            120          500000                86400

SELECT pool_name, num_open_servers, num_busy_servers, num_auth_servers, num_requests 
FROM V$CPOOL_STATS;

POOL_NAME
--------------------------------------------------------------------------------
NUM_OPEN_SERVERS NUM_BUSY_SERVERS NUM_AUTH_SERVERS NUM_REQUESTS
---------------- ---------------- ---------------- ------------
SYS_DEFAULT_CONNECTION_POOL
              10                3                1            9

Zurück zur Community-Seite