Initialisierungsparameter

SESSION_EXIT_ON_PACKAGE_STATE_ERROR gibt die Verarbeitung für ein zustandsbehaftetes 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, erhalten Sessions, die eine aktive Instanziierung des Packages aufweisen, den folgenden Fehler, wenn sie versuchen, das Package auszuführen:

ORA-4068 existing state of package has been discarded

Der Anwendungscode, der den ORA-4068-Fehler empfängt, ist jedoch möglicherweise nicht dazu geeignet, diesen Fehler mit seiner Wiederholungslogik zu behandeln.

Wenn Sie SESSION_EXIT_ON_PACKAGE_STATE_ERROR auf TRUE setzen, ist für diesen Fall eine andere Behandlung möglich. Wenn SESSION_EXIT_ON_PACKAGE_STATE_ERROR TRUE ist, wird die Session sofort beendet, anstatt nur den ORA-4068-Fehler auszulösen, wenn der Packagestatus verworfen wird. Dies kann von Vorteil sein, da viele Anwendungen die Sessionbeendigung verarbeiten können, indem sie die Verbindung automatisch und transparent wiederherstellen.

Autonomous Database-Standardzeitzone

Die Autonomous Database-Standardzeitzone ist Coordinated Universal Time (UTC). Standardmäßig geben Aufrufe von SYSDATE und SYSTIMESTAMP das Datum und die 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 Zeitzone der Datenbank auf UTC-5 gesetzt.

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

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

ALTER DATABASE SET TIME_ZONE='America/New_York';

Nachdem Sie die Datenbank-Zeitzone festgelegt haben, geben standardmäßig SYSDATE und SYSTIMESTAMP 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 Datenbank-Zeitzone 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.

Verwenden von SYSDATE_AT_DBTIMEZONE in einer Session

Wenn SYSDATE_AT_DBTIMEZONE in einer Session FALSE ist, geben Aufrufe von SYSDATE und SYSTIMESTAMP Werte basierend auf der Standard-Autonomous Database-Zeitzone Coordinated Universal Time (UTC) zurück.

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

Beispiel

Im folgenden Beispiel werden Datums- und Uhrzeitangaben für zwei verschiedene Zeitzonen basierend auf dem Parameterwert SYSDATE_AT_DBTIMEZONE zurückgegeben:

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 Ergebnissetabrufen 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 zugewiesen, und der Clienttreiber pufelt intern die restlichen 100 Zeilen. Die nächsten 10 Zeilen können aus der Clientanwendung abgerufen werden, wobei jede mit 10 Zeilen pro Fetch-Iteration aus den 100 Zeilen erfüllt werden kann, 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 mit 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 OCI_ATTR_PREFETCH_ROWS-Standardwert für die Anzahl der Vorabrufzeilen.

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

• Verwenden Sie 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 Zeilen der obersten Ebene, die vorab abgerufen werden sollen, 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 für den Datenbankinitialisierungsparameter 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 "x" als 1 festlegen, wird die Anzahl der Zeilen der obersten Ebene im Voraus 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 für den Datenbankinitialisierungsparameter CLIENT_PREFETCH_ROWS Vorrang und bestimmt die Anzahl der Zeilen der obersten Ebene, die vorab abgerufen werden sollen.

• Verwenden Sie CLIENT_PREFETCH_ROWS mit OCIAttrGet():

  Die Funktion OCIAttrGet() gibt das effektive Prefetch-Zeilenwerteset 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 endgültige Prefetch-Zeilenwert und kann auf die maximale Anzahl von Zeilen beschränkt werden, die durch den vom Attribut OCI_ATTR_PREFETCH_MEMORY angegebenen Speicherwert zulässig sind.

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.

Oracle Scheduler-Jobkoordinator und Job-Worker werden durch den Parameter JOB_QUEUE_PROCESSES gesteuert. Die tatsächliche Anzahl der Job-Worker, die für Oracle Scheduler-Jobs erstellt wurden, wird vom Scheduler automatisch optimiert. Dies hängt von verschiedenen Faktoren ab, darunter verfügbaren Ressourcen, Resource Manager-Einstellungen und aktuell ausgeführte Jobs.

Der Standardwert für JOB_QUEUE_PROCESSES stellt einen Kompromiss zwischen der Servicequalität für Anwendungen und der angemessenen Nutzung von Systemressourcen dar. Es ist jedoch möglich, dass der Standardwert nicht für jede Umgebung geeignet ist.

Wenn Sie den Wert 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 markiert sind. Nicht von Oracle bereitgestellte Benutzer sind Benutzer, die als ORACLE_MAINTAINED mit dem Wert N markiert sind.

Weitere Informationen finden Sie unter ALL_USERS.

Autonomous Database verwendet Sperrprofile, 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 Autonomous Database-Sperrprofil eingeschränkt ist. Mit dem Parameter LOCKDOWN_ERRORS können Sie Lockdown-Profilfehler unterdrücken. Wenn LOCKDOWN_ERRORS auf den Wert IGNORE gesetzt ist, protokolliert die Datenbank beim Ignorieren eines Fehlers die Details zur SQL-Anweisung, zum Benutzer und zum Zeitstempel für den Befehl.

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

Werte

• ENFORCED: Unabhängig von der Einstellung von RESULT_CACHE_MODE oder angegebenen Hints sind nur deterministische Konstrukte für das Ergebnis-Caching zulässig. 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 angegebenen Hints und berücksichtigt Abfragen, die möglicherweise nicht deterministische Konstrukte als Kandidaten für das Ergebnis-Caching verwenden. Beispiel: Abfragen, die PL/SQL-Funktionen verwenden, die nicht als deterministisch deklariert sind, können gecacht werden. Beachten Sie jedoch, dass Ergebnisse, die bekanntermaßen nicht deterministisch sind, nicht gecacht werden (z.B. SYSDATE oder Konstrukte mit SYSDATE).

Weitere Informationen finden Sie unter RESULT_CACHE_MODE.