Logo Oracle Deutschland   DBA Community  -  Dezember 2012 (ergänzt August 2013)
Services in der Datenbank
von Ulrike Schwinn, Oracle Deutschland B.V. & Co. KG

Database Services (kurz Services) bieten nicht nur die Möglichkeit, remote auf eine Datenbank zuzugreifen, sondern stellen eine Schlüsseltechnologie für die Nutzung vieler Funktionen innerhalb der Datenbank dar. Dabei müssen Services nicht unbedingt immer in den Zusammenhang mit der RAC Technologie gestellt werden. Die Nutzung von Services kann auch die Verwaltung und das Monitoring datenbankseitiger Applikationen stark vereinfachen. Da mit der in Oracle Database 12c eingeführten neuen Multitenant Architektur der Einsatz von Services unabdingbar ist, widmen wir uns im folgendem Artikel den Eigenschaften von Services und geben Tipps für mögliche Anwendungsformen.

Da der Tipp mehrere Aspekte demonstriert, ist er zur besseren Übersichtlichkeit in folgende Abschnitte unterteilt:

Grundsätzliches
Was sind Services? Services beschreiben Anwendungen und spezielle Funktionen und gruppieren bestimmte Sessions, die bestimmte Funktionen erfüllen. Dabei kann ein Service mehrere Datenbank Instanzen identifizieren, und umgekehrt kann eine Instanz zu mehreren Services gehören. Der Listener wird über die dynamische Registrierung des PMONs informiert und leitet dann die Verbindungen zwischen Client und Instanz weiter. Services lassen sich einfach über die Views DBA_SERVICES, V$SERVICES oder V$ACTIVE_SERVICES auslesen. Neu in 12c ist die zusätzliche Verwendung der View CDB_SERVICES - sie zeigt die Services aus der CDB und PDBs aus dem jeweiligen Container Kontext. Nach einer Standardinstallation liefert die Abfrage auf DBA_SERVICES in einer 11g Umgebung zum Beispiel folgendes Ergebnis. 
SQL> SELECT name, creation_date FROM dba_services;

NAME                 CREATION_
-------------------- ---------
SYS$BACKGROUND       18-JAN-10
SYS$USERS            18-JAN-10
orclXDB              18-JAN-10
orcl                 18-JAN-10
Der Default Service Name ist normalerweise der globale Datenbank Name, bestehend aus Datenbankname (DB_NAME) und Domain Name (DB_DOMAIN). In unserem Fall ist der Domain Name nicht gesetzt. Zusätzlich enthält eine Datenbank auch zwei interne Services: SYS$BACKGROUND wird ausschliesslich von Background Prozessen genutzt; und SYS$USERS wird automatisch Usern zugewiesen, die keinen Service beim Connect angeben. Da Default Services eigentlich nur für administrative Zwecke und nicht für die Nutzung in Applikationen geeignet sind, können bzw. sollten weitere Services definiert werden. Ein weiterer Vorteil der Definition eigener Services ist, dass diese bestimmte zusätzliche Eigenschaften haben können. Mit einer erweiterten Spalten Abfrage auf DBA_SERVICES lassen sich zum Beispiel Eigenschaften wie AQ_HA_NOTIFICATIONS (bei Verwendung von Fast Application Notification (FAN) für OCI/OCCI/ODP) oder auch COMMIT_OUTCOME (bei Verwendung von 12c Application Continuity) selektieren.

Jede Datenbank verfügt also über einen oder mehrere Services, die im Datenbank Repository gespeichert sind. Wenn eine Instanz startet, registriert sie sich mit einem Listener, indem sie einen Service oder mehrere Services nutzt. Die Listener sind dabei in den Datenbank Parametern LOCAL_LISTENER und REMOTE_LISTENER enthalten, die Service Namen im Parameter SERVICE_NAMES vermerkt. SERVICE_NAMES listet somit die Services auf, die zu einer Instanz gehören. Die Service Registrierung ist dynamisch und erfordert keine explizite Konfigurationsauflistung in der listener.ora Datei.

Seit Oracle Database 12c sind Services unabdingbar für die Nutzung der Multitenant Database Architektur. Wenn man beispielsweise eine PDB erzeugt, kreiert und startet Oracle automatisch einen Default Service in der zugehörigen CDB. Database Services besitzen daher neuerdings zusätzlich eine optionale PDB Eigenschaft (property) - eine Abfrage auf DBA_SERVICES listet dabei die zugehörige PDB in der Spalte PDB auf. Der Default Service hat dabei den gleichen Namen wie die PDB - in unserem Beispiel US_PDB oder PDB1. Der PDB Name muss allerdings eindeutig in der CDB sein. Folgender Ausschnitt zeigt eine kleines Beispiel. 
SQL> SELECT name, pdb FROM v$services;
NAME                 PDB
-------------------- --------------------
us_pdb               US_PDB
pdb1                 PDB1
orclXDB              CDB$ROOT
orcl                 CDB$ROOT
SYS$BACKGROUND       CDB$ROOT
SYS$USERS            CDB$ROOT
6 rows selected.
Nicht vergessen sollte man im Zusammenhang mit Services die Möglichkeit eines Connects über die Easy Connect Naming Methode. Sie ermöglicht ein Connect auch ohne TNS Service Names und ohne tnsnames.ora Datei. Die Easy Connect Naming Methode ist eine out-of-the-box TCP/IP Connection, die beispielsweise über die Nennung von Hostname und Service möglich ist. Folgendes Beispiel zeigt die Syntax und gibt ein Beispiel. 
CONNECT username/password@host[:port][/service_name][:server][/instance_name]
--Beispiel
SQL> connect scott@"sccloud003.de.oracle.com/orcl"
Enter password:
Connected.
Services erzeugen und verwalten
Wie können nun Services erzeugt werden außer durch einen manuellen Eintrag in die Liste des Parameters SERVICE_NAMES? Hierzu eignet sich speziell im Single Instance Umfeld das Package DBMS_SERVICE. Dabei erlaubt DBMS_SERVICE nicht nur das Erzeugen, Löschen, Starten und Stoppen eines Service, sondern ermöglicht auch ein Disconnect aller Sessions, die sich mit einem bestimmten Service verbunden haben. Ausführlich beschrieben ist die Nutzung dieses Package übrigens im Tipp Datenbank Services im RAC und Single Instanz mit DBMS_SERVICE .

Services können darüberhinaus auch einfach mit graphischen Mitteln wie Net Configuration Assistant oder Net Manager erzeugt werden. Die Konfiguration kann gesichert werden und sorgt somit für syntaktisch korrekte Einträge in den beteiligten Net Dateien wie tnsnames.ora, sqlnet.ora oder listener.ora. Ein manuelles Editieren dieser Dateien ist zwar möglich, allerdings wird dies nicht empfohlen.



Mit der Einführung von Oracle Restart für Single Instanz Datenbanken werden die Services auch ähnlich wie bei RAC über den Befehl "srvctl add service" angelegt. Im Clusterware und Oracle Restart Umfeld wird fast ausschliesslich die Nutzung von SRVCTL empfohlen. Services werden dabei von SRVCTL case INsensitiv verwendet. Übrigens lässt sich nur mit SRVCTL die PDB Eigenschaft (property) eines Service ändern, dies ist mit DBMS_SERVICE nicht möglich. SRVCTL erzeugt neben dem impliziten Aufruf von DBMS_SERVICE die entsprechende Ressource in Oracle Restart und in der Oracle Clusterware. Vielleicht noch ein paar wichtige Hinweise zu der Nutzung von SRVCTL und DBMS_SERVICE. Folgende Prozeduren sind seit 11g im RAC und Oracle Restart Umfeld obsolet:
  • CREATE_SERVICE
  • MODIFY_SERVICE
  • START_SERVICE
  • STOP_SERVICE
Wie man leicht erkennen kann, ist die Prozedur DELETE_SERVICE zumindest in 11g noch im RAC und Restart Umfeld verwendbar. Hintergrund ist der Umstand, dass "srvctl remove service" die Services nicht aus der Datenbank löscht (siehe DBA_SERVICES), dazu ist ein zusätzlicher Aufruf mit DELETE_SERVICE nötig. In Oracle Database 12c hingegen sollte auch die Prozedur DELETE_SERVICE im RAC, Restart oder Oracle Global Data Services Umfeld nicht mehr verwendet werden. Hinweis: Laut Oracle Database Net Services Administrator's Guide 12c Release 1 (12.1) ist Oracle Restart mit Oracle Database 12c Release 1 (12.1) "deprecated".

Anwendungsgebiete von Services
Wofür eignen sich nun Services? Welche Anwendungsfelder gibt es speziell auch im Single Instance (kurz SI) Umfeld? Neben dem speziellen Nutzen in Data Guard Umgebungen ist der Einsatz von Services auch unabhängig von der Architektur und des Datenbank Release sehr hilfreich im Monitoring und Tuning Umfeld sein. Viele Standard Views beinhalten mittlerweile die Spalte SERVICE_NAME oder SERVICE und helfen somit das Monitoren zu erleichtern. Ein einfaches Beispiel liefert die View V$SESSION, die detaillierte Informationen über einzelne Sessions ausgibt. Auch beim Realtime Monitoring spielt die Nutzung von Services eine Rolle, wie man an der View V$SQL_MONITOR erkennen kann. Spezielle V$SERVICE Views ermöglichen zusätzlich gewisse Aussagen über die Performance der einzelnen Services wie zum Beispiel V$SERVICE_STATS. 
SQL> SELECT service_name, stat_name, value FROM v$service_stats
     WHERE service_name IN ('orcl','TEST','XYZ');

SERVICE_NAME    STAT_NAME                           VALUE
--------------- ------------------------------ ----------
XYZ             logons cumulative                       1
orcl            logons cumulative                     201
TEST            logons cumulative                       1
XYZ             user calls                             17
orcl            user calls                         588456
TEST            user calls                             17
XYZ             DB time                             56341
orcl            DB time                         881701076
TEST            DB time                             60114
XYZ             DB CPU                              16000
...
Einen Überblick über die Wait Statistiken der einzelnen Services gibt die View V$SERVICE_EVENT. Auch im AWR Report gibt es dazu einen Abschnitt, der über die Nutzung der einzelnen Services Auskunft gibt. So kann statt Tuning auf "Session und SQL" Ebene nun Tuning auf "Service und SQL" Ebene erfolgen.



Ein weiteres Anwendungsfeld liefert der Database Resource Manager. Hier können Services auf bestimmte Consumer Gruppen abgebildet werden. So kann ein Service automatisch eine gewisse Priorität gegenüber den anderen Services erhalten. Folgendes Beispiel zeigt eine mögliche Prioritätenliste im Resource Manager. 
SQL> SELECT * FROM dba_rsrc_mapping_priority;

ATTRIBUTE                        PRIORITY STATUS
------------------------------ ---------- ------------------------------
EXPLICIT                                1
SERVICE_MODULE_ACTION                   2
SERVICE_MODULE                          3
MODULE_NAME_ACTION                      4
MODULE_NAME                             5
SERVICE_NAME                            6
ORACLE_USER                             7
CLIENT_PROGRAM                          8
CLIENT_OS_USER                          9
CLIENT_MACHINE                         10
CLIENT_ID                              11
Ausführliche Informationen zum Resource Manager können Sie in folgenden beiden Tipps nachlesen Auch für den Einsatz von Scheduler Jobs kann die Nutzung von Services hilfreich sein. Man kann bei der Definition von Job Klassen nicht nur Ressource Gruppen sondern auch lokale Services angeben. Bei der Ausführung werden die Jobs den entsprechenden Job Klassen zugeordnet und laufen dann unter dem entsprechenden Service ab. 
SQL> SELECT job_class_name, resource_consumer_group, service 
     FROM dba_scheduler_job_classes;

JOB_CLASS_NAME                 RESOURCE_CONSUMER_GROUP        SERVICE
------------------------------ ------------------------------ ---------------
DEFAULT_JOB_CLASS
DBMS_JOB$
ORA$AT_JCURG_OS                ORA$AUTOTASK_URGENT_GROUP
...
SCHED$_LOG_ON_ERRORS_CLASS
TEST_RESOURCE                  GRUPPE_HIGH                    XYZ
...
Auf diese Weise kann Workload Management bzw. Performance Tuning auch auf Scheduler Jobs angewendet werden.

Zurück zur Community-Seite