SESSION_EXIT_ON_PACKAGE_STATE_ERROR gibt das Handling für ein zustandsreiches PL/SQL-Package an, das in einer Session ausgeführt wird. Wenn ein solches Package geändert wird, z.B. während der geplanten Wartung für von Oracle bereitgestellte Objekte, wird in Sessions, die eine aktive Instanzisierung des Packages aufweisen, beim Versuch, das Package auszuführen, der folgende Fehler ausgegeben:

ORA-4068 existing state of package has been discarded

Der Anwendungscode, der den Fehler ORA-4068 empfängt, kann diesen Fehler jedoch möglicherweise nicht mit seiner Wiederholungslogik verarbeiten.

Wenn Sie SESSION_EXIT_ON_PACKAGE_STATE_ERROR auf TRUE setzen, wird in diesem Fall ein anderes Handling bereitgestellt. Wenn für SESSION_EXIT_ON_PACKAGE_STATE_ERROR TRUE gilt, wird die Session sofort beendet, wenn der Packagestatus verworfen wird, wenn der Fehler ORA-4068 nicht einfach ausgelöst wird. Dies kann vorteilhaft sein, da viele Anwendungen die Sessionbeendigung verarbeiten können, indem sie die Verbindung automatisch und transparent wiederherstellen.

Standardzeitzone für Autonomous Database

Die Autonomous Database-Standardzeitzone ist die koordinierte Weltzeit (UTC). Standardmäßig geben Aufrufe von SYSDATE und SYSTIMESTAMP Datum und Uhrzeit in UTC zurück.

Um die Zeitzone der Datenbank zu ändern, können Sie die folgende Anweisung ausführen.

In diesem Beispiel wird die Datenbankzeitzone auf UTC-5 gesetzt.

ALTER DATABASE SET TIME_ZONE='-05:00';

In diesem Beispiel wird die Datenbankzeitzone für die US-Ostküste America/New_York festgelegt, und die Zeit wird bei den Sommerzeit-Switches automatisch angepasst:

ALTER DATABASE SET TIME_ZONE='America/New_York';

Nachdem Sie die Zeitzone der Datenbank festgelegt haben, geben SYSDATE und SYSTIMESTAMP standardmäßig weiterhin Datum und Uhrzeit in UTC zurück (SYSDATE_AT_DBTIMEZONE ist standardmäßig FALSE). Wenn Sie SYSDATE_AT_DBTIMEZONE in einer Session auf TRUE setzen, geben SYSDATE und SYSTIMESTAMP die Datenbankzeitzone zurück.

Weitere Informationen zur Verwendung der Klausel SET TIME_ZONE mit ALTER DATABASE finden Sie unter Datenbank-Zeitzone festlegen in Oracle Database 19c oder Oracle Database 23ai.

SYSDATE_AT_DBTIMEZONE in einer Session verwenden

Wenn SYSDATE_AT_DBTIMEZONE in einer Session FALSE lautet, geben Aufrufe von SYSDATE und SYSTIMESTAMP Werte basierend auf der Standardzeitzone von Autonomous Database, koordinierte Weltzeit (UTC), zurück.

Wenn SYSDATE_AT_DBTIMEZONE in einer Session TRUE lautet, geben Aufrufe von SYSDATE oder SYSTIMESTAMP das Datum und die Uhrzeit basierend auf der Datenbankzeitzone zurück.

Beispiel

Das folgende Beispiel gibt Datums- und Uhrzeitwerte für zwei verschiedene Zeitzonen zurück, basierend auf dem Parameterwert SYSDATE_AT_DBTIMEZONE:

SQL> SELECT DBTIMEZONE FROM DUAL;

DBTIMEZONE
_____________
-05:00

SQL> ALTER SESSION SET SYSDATE_AT_DBTIMEZONE=FALSE;

Session altered.

SQL> SELECT SYSTIMESTAMP FROM DUAL;

SYSTIMESTAMP
______________________________________
27-JAN-22 06.59.45.708082000 PM GMT

SQL> ALTER SESSION SET SYSDATE_AT_DBTIMEZONE=TRUE;

Session altered.

SQL> SELECT SYSTIMESTAMP FROM DUAL;

SYSTIMESTAMP
_________________________________________
27-JAN-22 02.14.47.578946000 PM -05:00 

SQL> SELECT TO_CHAR(SYSTIMESTAMP,'YYYY-MM-DD"T"HH24:MI:SS TZH":"TZM') FROM DUAL;

TO_CHAR(SYSTIMESTAMP,'YYYY-MM-DD"T"HH24:MI:SSTZH":"TZM')
___________________________________________________________
2022-01-27T14:15:00 -05:00

Der Parameter CLIENT_PREFETCH_ROWS kann mit ALTER SESSION oder ALTER SYSTEM festgelegt werden. Wenn sich der Parameterwert mit ALTER SESSION ändert, wird der neue Wert für diese bestimmte Session bei nachfolgenden Ergebnismengenabfragen wirksam. Wenn sich der Parameterwert mit ALTER SYSTEM ändert, wird der neue Wert für die Anweisungen wirksam, die auf Verbindungen ausgeführt werden, die nach dem Befehl ALTER SYSTEM erstellt wurden.

Beispiel: Wenn CLIENT_PREFETCH_ROWS auf 100 gesetzt ist und eine Clientanwendung 10 Zeilen abruft, werden insgesamt 110 Zeilen an den Clienttreiber zurückgegeben. Die ersten 10 Zeilen aus den 110 Zeilen werden der Anwendung übergeben, und der Clienttreiber pufft die restlichen 100 Zeilen intern. Die nächsten 10 Zeilen werden aus der Clientanwendung abgerufen. Jede Zeile mit 10 Zeilen pro Fetch-Iteration kann aus den 100 Zeilen ausgeführt werden, die vom Clienttreiber intern gepuffert werden. Dieser Prozess reduziert die Anzahl der erforderlichen Netzwerk-Roundtrips zur und von der Datenbank. In diesem Beispiel wird beim 11. Fetch ein neuer Netzwerk-Roundtrip angefallen, und die Datenbank gibt den nächsten Batch von 110 Zeilen zurück, solange die Ergebnismenge nicht erschöpft ist und der Zyklus wiederholt wird.

Hinweise zum Festlegen von CLIENT_PREFETCH_ROWS:

• Wenn CLIENT_PREFETCH_ROWS auf einen Wert ungleich Null gesetzt ist, hat sein Wert Vorrang vor dem Standardwert OCI_ATTR_PREFETCH_ROWS für die Anzahl der vorab abgerufenen Zeilen.

• Wenn der Wert OCI_ATTR_PREFETCH_ROWS auf einen Nicht-Standardwert gesetzt ist, wird der Wert CLIENT_PREFETCH_ROWS für die Anzahl der Prefetch-Zeilen ignoriert.

• Verwenden von CLIENT_PREFETCH_ROWS mit OCIAttrSet():

  OCI_ATTR_PREFETCH_ROWS legt die Anzahl der Zeilen der obersten Ebene fest, die vorab abgerufen werden sollen. Der Standardwert ist 1 Zeile. Wenn CLIENT_PREFETCH_ROWS jedoch festgelegt ist, wird die Anzahl der vorab abzurufenden Zeilen der obersten Ebene durch die folgende Priorität bestimmt:

  1. Wenn Sie das Attribut OCI_ATTR_PREFETCH_ROWS mit der Funktion OCIAttrSet() oder oraaccess.xml als Wert "1" festlegen, hat der Wert des Datenbankinitialisierungsparameters CLIENT_PREFETCH_ROWS Vorrang und bestimmt die Anzahl der Zeilen der obersten Ebene, die vorab abgerufen werden sollen.

  2. Wenn Sie das Attribut OCI_ATTR_PREFETCH_ROWS mit der Funktion OCIAttrSet() oder oraaccess.xml als anderen Wert als 1 als x festlegen, wird die Anzahl der Zeilen der obersten Ebene mit x vorab abgerufen, und der Datenbankinitialisierungsparameter CLIENT_PREFETCH_ROWS wird ignoriert.

  3. Wenn Sie keinen OCI_ATTR_PREFETCH_ROWS-Wert mit OCIAttrSet() oder oraaccess.xml festlegen, hat der Wert des Datenbankinitialisierungsparameters CLIENT_PREFETCH_ROWS Vorrang und bestimmt die Anzahl der Zeilen der obersten Ebene, die vorab abgerufen werden sollen.

• Verwenden von CLIENT_PREFETCH_ROWS mit OCIAttrGet():

  Die Funktion OCIAttrGet() gibt den effektiven vorab abgerufenen Zeilenwert aus OCI_ATTR_PREFETCH_ROWS, oraaccess.xml und dem Datenbankinitialisierungsparameter CLIENT_PREFETCH_ROWS zurück. Wenn der Wert OCI_ATTR_PREFETCH_MEMORY festgelegt ist, ist der von OCIAttrGet() zurückgegebene Wert möglicherweise nicht der letzte Prefetch-Zeilenwert und kann auf die maximal zulässige Anzahl von Zeilen durch den Speicherwert begrenzt werden, der durch das Attribut OCI_ATTR_PREFETCH_MEMORY angegeben wird.

Die Standardwerte und Höchstwerte für JOB_QUEUE_PROCESSES unterscheiden sich je nach verwendetem Compute-Modell. Weitere Informationen finden Sie unter Compute-Modelle in Autonomous Database.

Job-Koordinator und Job-Worker von Oracle Scheduler werden vom Parameter JOB_QUEUE_PROCESSES gesteuert. Die tatsächliche Anzahl von Job-Workern, die für Oracle Scheduler-Jobs erstellt wurden, wird vom Scheduler in Abhängigkeit von verschiedenen Faktoren automatisch optimiert, darunter verfügbare Ressourcen, Resource Manager-Einstellungen und derzeit ausgeführte Jobs.

Der Standardwert für JOB_QUEUE_PROCESSES bietet einen Kompromiss zwischen der Servicequalität für Anwendungen und einer angemessenen Nutzung von Systemressourcen. Es ist jedoch möglich, dass der Standardwert nicht jeder Umgebung entspricht.

Wenn Sie den Wert von JOB_QUEUE_PROCESSES auf 0 setzen, werden nicht von Oracle bereitgestellte Scheduler-Jobs deaktiviert. Wenn JOB_QUEUE_PROCESSES auf 0 gesetzt ist, werden keine internen Jobs für von Oracle bereitgestellte Benutzer deaktiviert (servicebezogene Jobs, die von von Oracle bereitgestellten Benutzern ausgeführt werden, werden weiterhin geplant).

Von Oracle bereitgestellte Benutzer sind Benutzer, die als ORACLE_MAINTAINED mit dem Wert Y gekennzeichnet sind. Nicht von Oracle bereitgestellte Benutzer sind Benutzer, die als ORACLE_MAINTAINED mit dem Wert N gekennzeichnet sind.

Weitere Informationen finden Sie unter ALL_USERS.

Autonomous Database verwendet Lockdown-Profile, um bestimmte Datenbankfunktionen und -features einzuschränken. Standardmäßig löst die Datenbank einen Fehler aus, wenn Sie versuchen, einen SQL-Befehl auszuführen, der durch das Lockdown-Profil von Autonomous Database eingeschränkt ist. Mit dem Parameter LOCKDOWN_ERRORS können Sie Fehler im Sperrprofil unterdrücken. Wenn LOCKDOWN_ERRORS auf den Wert IGNORE gesetzt ist, protokolliert die Datenbank beim Ignorieren eines Fehlers außerdem die Details zu SQL-Anweisung, Benutzer und Zeitstempel für den Befehl.

Mit der View DBA_LOCKDOWN_ERRORS können Sie Informationen zu Lockdown-Profilfehlern abrufen. Weitere Informationen finden Sie unter Ansicht "Lockdown-Fehler".

Werte

• ENFORCED: Unabhängig von der Einstellung von RESULT_CACHE_MODE oder angegebenen Hints können nur deterministische Konstrukte für das Ergebnis-Caching verwendet werden. Beispiel: Abfragen, die PL/SQL-Funktionen verwenden, die nicht als deterministisch deklariert sind, werden nie gecacht (es sei denn, die Funktionen werden als deterministisch deklariert, die Abfrageergebnisse mit solchen Funktionen werden nicht gecacht).

• TRUSTED: Die Datenbank berücksichtigt die Einstellung von RESULT_CACHE_MODE und die angegebenen Hints und berücksichtigt Abfragen, die möglicherweise nicht deterministische Konstrukte als Kandidaten für das Ergebnis-Caching verwenden. Beispielsweise können Abfragen, die PL/SQL-Funktionen verwenden, die nicht als deterministisch deklariert sind, gecacht werden. Beachten Sie jedoch, dass Ergebnisse, die bekanntermaßen nicht deterministisch sind, nicht gecacht werden (Beispiel: SYSDATE oder Konstrukte mit SYSDATE).

Weitere Informationen finden Sie unter RESULT_CACHE_MODE.