Multi-Process Multi-Threaded Oracle
Wenn man Oracle Datenbanken unter Unix und Linux betreibt, dann weiß man, dass jede Datenbank zig Prozesse hat. Wenn man die Datenbank jedoch unter Microsoft Windows betreibt, hat man einen einzigen Prozess „Oracle“ und alle weiteren Aktionen gliedern sich in Tasks ein. Mit Oracle 12c ist es jetzt möglich, auch unter Unix und Linux die Oracle Instanz mit wenigen Prozessen und darin eingegliederten Tasks zu betreiben. Das Stichwort hierfür heißt „Multi-Threaded Oracle„.
Wie geht das und was passiert?
Zunächst einmal muss der Parameter threaded_execution auf „TRUE“ gesetzt werden. Nach dem Restart der Instanz sind anschließend nur noch wenige Prozesse zu sehen (u.A. der pmon). Die Benutzerprozesse bleiben hiervon allerdings zunächst ausgenommen. Erst durch den Listener-Parameter DEDICATED_THROUGH_BROKER_LISTENER=ON wird erreicht, dass die Benutzerprozesse ebenfalls als Threads ausgeführt werden und man sieht anschließend mit dem Befehl ps keinerlei weitere Prozesse mehr auf dem Datenbank Server.
Allerdings gibt es nach dieser Umstellung eine kleine aber feine Einschränkung: Wenn die Instanz im Multi-Threaded Modus betrieben wird, ist kein Connect mehr mit Betriebssystem Authentifizierung mehr möglich – also auch kein sqlplus / as sysdba. Statt dessen muss immer der Benutzer und dass Passwort angegeben werden.
Beispiel
Hier die Prozessliste einer „normalen“ Oracle 12c Datenbank:
% ps -ef|grep WAGNER1 oracle 8994 1 0 12:36 ? 00:00:00 ora_pmon_WAGNER1 oracle 8996 1 0 12:36 ? 00:00:00 ora_psp0_WAGNER1 oracle 8998 1 1 12:36 ? 00:00:51 ora_vktm_WAGNER1 oracle 9002 1 0 12:36 ? 00:00:00 ora_gen0_WAGNER1 oracle 9004 1 0 12:36 ? 00:00:00 ora_mman_WAGNER1 oracle 9008 1 0 12:36 ? 00:00:00 ora_diag_WAGNER1 oracle 9010 1 0 12:36 ? 00:00:00 ora_dbrm_WAGNER1 oracle 9012 1 0 12:36 ? 00:00:02 ora_dia0_WAGNER1 oracle 9014 1 0 12:36 ? 00:00:00 ora_dbw0_WAGNER1 oracle 9016 1 0 12:36 ? 00:00:00 ora_lgwr_WAGNER1 oracle 9018 1 0 12:36 ? 00:00:00 ora_ckpt_WAGNER1 oracle 9020 1 0 12:36 ? 00:00:00 ora_smon_WAGNER1 oracle 9022 1 0 12:36 ? 00:00:00 ora_reco_WAGNER1 oracle 9024 1 0 12:36 ? 00:00:00 ora_lreg_WAGNER1 oracle 9026 1 0 12:36 ? 00:00:03 ora_mmon_WAGNER1 oracle 9028 1 0 12:36 ? 00:00:02 ora_mmnl_WAGNER1 oracle 9030 1 0 12:36 ? 00:00:00 ora_d000_WAGNER1 oracle 9032 1 0 12:36 ? 00:00:00 ora_s000_WAGNER1 oracle 9044 1 0 12:37 ? 00:00:00 ora_tmon_WAGNER1 oracle 9046 1 0 12:37 ? 00:00:00 ora_tt00_WAGNER1 oracle 9048 1 0 12:37 ? 00:00:00 ora_smco_WAGNER1 oracle 9050 1 0 12:37 ? 00:00:00 ora_fbda_WAGNER1 oracle 9052 1 0 12:37 ? 00:00:00 ora_w000_WAGNER1 oracle 9054 1 0 12:37 ? 00:00:00 ora_aqpc_WAGNER1 oracle 9056 1 0 12:37 ? 00:00:01 ora_cjq0_WAGNER1 oracle 9060 1 0 12:37 ? 00:00:00 ora_p000_WAGNER1 oracle 9062 1 0 12:37 ? 00:00:00 ora_p001_WAGNER1 oracle 9064 1 0 12:37 ? 00:00:00 ora_p002_WAGNER1 oracle 9066 1 0 12:37 ? 00:00:00 ora_p003_WAGNER1 oracle 9098 1 0 12:37 ? 00:00:00 ora_qm02_WAGNER1 oracle 9102 1 0 12:37 ? 00:00:00 ora_q002_WAGNER1 oracle 9104 1 0 12:37 ? 00:00:00 ora_q003_WAGNER1 oracle 9283 1 0 12:47 ? 00:00:00 ora_w001_WAGNER1 oracle 9520 1 0 13:07 ? 00:00:00 ora_w002_WAGNER1 ...
Jetzt wird der Instanz Parameter threaded_execution auf „TRUE“ gesetzt und die Instanz neu gestartet:
SQL> ALTER SYSETM SET threaded_execution=TRUE scope=spfile; System altered. SQL> shutdown immediate ... SQL> startup ORA-01017: invalid username/password; logon denied
Wie man sieht, funktioniert die OS-Authentication nicht, sondern man muss sich mit Benutzername und Passwort anmelden.
% sqlplus sys/manager as sysdba
Jetzt sieht die Prozessliste so aus:
% ps -ef|grep WAGNER oracle 19286 1 0 10:39 ? 00:00:00 ora_pmon_WAGNER1 oracle 19288 1 0 10:39 ? 00:00:00 ora_psp0_WAGNER1 oracle 19290 1 1 10:39 ? 00:00:02 ora_vktm_WAGNER1 oracle 19294 1 0 10:39 ? 00:00:00 ora_u004_WAGNER1 oracle 19300 1 3 10:39 ? 00:00:05 ora_u005_WAGNER1 oracle 19306 1 0 10:39 ? 00:00:00 ora_dbw0_WAGNER1 oracle 19369 1 0 10:41 ? 00:00:00 oracleWAGNER1 (LOCAL=NO) oracle 19373 1 0 10:42 ? 00:00:00 oracleWAGNER1 (LOCAL=NO) oracle 19376 1 0 10:42 ? 00:00:00 oracleWAGNER1 (LOCAL=NO)
Die Instanz verwendet nur noch 6 Hintergrundprozesse, die Benutzerprozesse sind aber weiterhin dediziert. Mit dem Listener-Eintrag kann auch dies geändert werden:
% cat listener.ora DEDICATED_THROUGH_BROKER_LISTENER=ON ... % lsnrctl stop % lsnrctl start % ps -ef |grep WAGNER oracle 19286 1 0 10:39 ? 00:00:00 ora_pmon_WAGNER1 oracle 19288 1 0 10:39 ? 00:00:00 ora_psp0_WAGNER1 oracle 19290 1 1 10:39 ? 00:00:12 ora_vktm_WAGNER1 oracle 19294 1 0 10:39 ? 00:00:00 ora_u004_WAGNER1 oracle 19300 1 1 10:39 ? 00:00:09 ora_u005_WAGNER1 oracle 19306 1 0 10:39 ? 00:00:00 ora_dbw0_WAGNER1
Jetzt sind die Benutzerprozesse nicht mehr sichtbar bzw. laufen jetzt als Threds unter dem Prozess 19300 (ora_u005_WAGNER1). Das kann man über die View v$processes feststellen.
SQL> SELECT spid, stid, pname, execution_type, program
FROM v$process
ORDER BY execution_type, stid;
SPID STID PNAME EXECUTION_ PROGRAM
------- -------- ----- ---------- --------------------------------------
NONE PSEUDO
19300 19510 W001 THREAD oracle@wagner.carajandb.intern (W001)
19300 19515 THREAD oracle@wagner.carajandb.intern
19300 19516 THREAD oracle@wagner.carajandb.intern
Fazit
Benchmarks zu den Unterschieden zwischen dem Multi-Threaded und Multi-Process Datenbank Betrieb stehen noch aus, aber man kann sicherlich davon ausgehen, dass sich, ähnlich wie bei den Pluggable Databases, durch die Einsparung von Prozessen Vorteile für den Betrieb von mehreren Datenbanken auf einem Server ergeben werden. Allerdings gibt es aufgrund der Einschränkung, dass keine Betriebssystem Authentifizierung mehr möglich ist, das Problem, dass viele Skripte nicht mehr funktionieren.
Über Kommentare und Erfahrungen würde ich mich sehr freuen.