SESSION_EXIT_ON_PACKAGE_STATE_ERROR specifica la gestione per un package PL/SQL con conservazione dello stato in esecuzione in una sessione. Quando un pacchetto di questo tipo viene modificato, ad esempio durante la manutenzione pianificata per gli oggetti forniti da Oracle, le sessioni con un'istanza attiva del pacchetto ricevono il seguente errore quando tentano di eseguire il pacchetto:

ORA-4068 existing state of package has been discarded

Tuttavia, il codice dell'applicazione che riceve l'errore ORA-4068 potrebbe non essere in grado di gestire questo errore con la logica dei nuovi tentativi.

L'impostazione di SESSION_EXIT_ON_PACKAGE_STATE_ERROR su TRUE fornisce una gestione diversa per questo caso. Quando SESSION_EXIT_ON_PACKAGE_STATE_ERROR è TRUE, invece di generare solo l'errore ORA-4068 quando lo stato del pacchetto viene eliminato, la sessione viene chiusa immediatamente. Ciò può essere vantaggioso perché molte applicazioni sono in grado di gestire l'interruzione della sessione ristabilendo automaticamente e in modo trasparente la connessione.

Fuso orario predefinito di Autonomous Database

Il fuso orario predefinito di Autonomous Database è UTC (Coordinated Universal Time) e per impostazione predefinita le chiamate a SYSDATE e SYSTIMESTAMP restituiscono la data e l'ora in UTC.

Per modificare il fuso orario del database, è possibile eseguire la seguente istruzione.

In questo esempio il fuso orario del database viene impostato su UTC-5.

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

In questo esempio viene impostato il fuso orario del database per la costa orientale degli Stati Uniti: America/New_York e l'ora viene regolata automaticamente agli switch DST:

ALTER DATABASE SET TIME_ZONE='America/New_York';

Dopo aver impostato il fuso orario del database, per impostazione predefinita SYSDATE e SYSTIMESTAMP continuano a restituire la data e l'ora in UTC (SYSDATE_AT_DBTIMEZONE è FALSE per impostazione predefinita). Se si imposta SYSDATE_AT_DBTIMEZONE su TRUE in una sessione, SYSDATE e SYSTIMESTAMP restituiscono il fuso orario del database.

Per ulteriori informazioni sull'utilizzo della clausola SET TIME_ZONE con ALTER DATABASE, vedere Impostazione del fuso orario del database in Oracle Database 19c o Oracle Database 23ai.

Utilizzo di SYSDATE_AT_DBTIMEZONE in una sessione

Quando SYSDATE_AT_DBTIMEZONE è FALSE in una sessione, chiama i valori restituiti da SYSDATE e SYSTIMESTAMP in base al fuso orario predefinito di Autonomous Database, UTC (Coordinated Universal Time).

Quando SYSDATE_AT_DBTIMEZONE è TRUE in una sessione, le chiamate a SYSDATE o SYSTIMESTAMP restituiscono la data e l'ora in base al fuso orario del database.

Esempio

Nell'esempio seguente vengono restituite date e ore per due fusi orari diversi, in base al valore del parametro 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

Il parametro CLIENT_PREFETCH_ROWS può essere impostato con ALTER SESSION o ALTER SYSTEM. Se il valore del parametro cambia utilizzando ALTER SESSION, il nuovo valore diventa effettivo per la sessione specifica durante i successivi recuperi del set di risultati. Se il valore del parametro cambia utilizzando ALTER SYSTEM, il nuovo valore diventa effettivo per le istruzioni eseguite sulle connessioni create dopo il comando ALTER SYSTEM.

Ad esempio, se CLIENT_PREFETCH_ROWS è impostato su 100 e un'applicazione client chiede di recuperare 10 righe, al driver client viene restituito un totale di 110 righe. Le prime 10 righe delle 110 vengono fornite all'applicazione e il driver client esegue internamente il buffer delle 100 righe rimanenti. Le 10 righe successive vengono recuperate dall'applicazione client, ognuna con 10 righe per iterazione di recupero può essere evasa dalle 100 righe inserite nel buffer interno dal driver client. Questo processo riduce il numero di roundtrip di rete necessari da e verso il database. In questo esempio, all'11° recupero, viene eseguito un nuovo roundtrip di rete e il database restituisce il batch successivo di 110 righe, a condizione che il set di risultati non sia esaurito e il ciclo si ripete.

Note per l'impostazione di CLIENT_PREFETCH_ROWS:

• Quando CLIENT_PREFETCH_ROWS è impostato su un valore diverso da zero, il relativo valore ha la precedenza sul valore OCI_ATTR_PREFETCH_ROWS predefinito per il conteggio delle righe di recupero preliminare.

• Se il valore OCI_ATTR_PREFETCH_ROWS è impostato su un valore non predefinito, il valore CLIENT_PREFETCH_ROWS viene ignorato per il conteggio delle righe di recupero preliminare.

• Utilizzando CLIENT_PREFETCH_ROWS con OCIAttrSet():

  OCI_ATTR_PREFETCH_ROWS imposta il numero di righe di livello superiore da preimpostare. Il valore predefinito è 1 riga. Se tuttavia è impostato CLIENT_PREFETCH_ROWS, il numero di righe di livello superiore da preimpostare è determinato dalla seguente priorità:

  1. Se si imposta l'attributo OCI_ATTR_PREFETCH_ROWS utilizzando la funzione OCIAttrSet() o oraaccess.xml come valore '1', il valore del parametro di inizializzazione del database CLIENT_PREFETCH_ROWS ha la precedenza e determina il numero di righe di livello superiore da preimpostare.

  2. Se si imposta l'attributo OCI_ATTR_PREFETCH_ROWS utilizzando la funzione OCIAttrSet() o oraaccess.xml come valore 'x' diverso da 1, il numero di righe di livello superiore 'x' verrà preimpostato e il parametro di inizializzazione del database CLIENT_PREFETCH_ROWS verrà ignorato.

  3. Se non si imposta un valore OCI_ATTR_PREFETCH_ROWS utilizzando OCIAttrSet() o oraaccess.xml, il valore del parametro di inizializzazione del database CLIENT_PREFETCH_ROWS ha la precedenza e determina il numero di righe di livello superiore da preimpostare.

• Utilizzando CLIENT_PREFETCH_ROWS con OCIAttrGet():

  La funzione OCIAttrGet() restituisce il valore effettivo della riga di recupero preliminare impostato da OCI_ATTR_PREFETCH_ROWS, oraaccess.xml e dal parametro di inizializzazione del database CLIENT_PREFETCH_ROWS. Se il valore OCI_ATTR_PREFETCH_MEMORY è impostato, il valore restituito da OCIAttrGet() potrebbe non essere il valore delle righe di recupero preliminare finale e potrebbe essere limitato al numero massimo di righe consentito dal valore di memoria specificato dall'attributo OCI_ATTR_PREFETCH_MEMORY.

I valori predefiniti e massimi per JOB_QUEUE_PROCESSES variano a seconda del modello di computazione utilizzato. Per ulteriori informazioni, vedere Modelli di computazione in Autonomous Database.

Il coordinatore dei processi e i job worker di Oracle Scheduler sono controllati dal parametro JOB_QUEUE_PROCESSES. Il numero effettivo di job worker creati per i job di Oracle Scheduler viene sottoposto a tuning automatico dallo scheduler in base a diversi fattori, tra cui le risorse disponibili, le impostazioni di Resource Manager e i job attualmente in esecuzione.

Il valore predefinito di JOB_QUEUE_PROCESSES fornisce un compromesso tra la qualità del servizio per le applicazioni e un uso ragionevole delle risorse di sistema. Tuttavia, è possibile che il valore predefinito non sia adatto a tutti gli ambienti.

L'impostazione del valore JOB_QUEUE_PROCESSES su 0 disabilita i processi Scheduler forniti da Oracle. Quando JOB_QUEUE_PROCESSES è impostato su 0, non viene disabilitato alcun job interno per gli utenti forniti da Oracle (i job correlati al servizio eseguiti dagli utenti forniti da Oracle continuano a essere pianificati).

Gli utenti forniti da Oracle sono utenti contrassegnati come ORACLE_MAINTAINED con il valore Y. Gli utenti non forniti da Oracle sono utenti contrassegnati come ORACLE_MAINTAINED con valore N.

Vedere ALL_USERS.

Autonomous Database utilizza i profili di lockdown per limitare determinate funzionalità e funzioni del database. Per impostazione predefinita, il database genera un errore ogni volta che si tenta di eseguire un comando SQL limitato dal profilo di lockdown di Autonomous Database. Il parametro LOCKDOWN_ERRORS consente di eliminare gli errori del profilo di blocco. Inoltre, quando LOCKDOWN_ERRORS è impostato sul valore IGNORE, dopo aver ignorato un errore, il database registra i dettagli relativi all'istruzione SQL, all'utente e all'indicatore orario per il comando.

È possibile utilizzare la vista DBA_LOCKDOWN_ERRORS per ottenere informazioni sugli errori del profilo di blocco. Per ulteriori informazioni, vedere Vista Errori di blocco.

Valori

• ENFORCED: indipendentemente dall'impostazione di RESULT_CACHE_MODE o dai suggerimenti specificati, solo i costrutti deterministici sono idonei per l'inserimento dei risultati nella cache. Ad esempio, le query che utilizzano funzioni PL/SQL non dichiarate come deterministiche non vengono mai inserite nella cache (a meno che le funzioni non vengano dichiarate deterministiche, i risultati delle query con tali funzioni non verranno inseriti nella cache).

• TRUSTED: il database rispetta l'impostazione di RESULT_CACHE_MODE e i suggerimenti specificati e prenderà in considerazione le query che utilizzano costrutti non deterministici come candidati per l'inserimento dei risultati nella cache. Ad esempio, è possibile inserire nella cache query che utilizzano funzioni PL/SQL non dichiarate come deterministiche. Si noti, tuttavia, che i risultati noti per essere non deterministici non vengono inseriti nella cache (ad esempio SYSDATE o costrutti che coinvolgono SYSDATE).

Vedere RESULT_CACHE_MODE.