SESSION_EXIT_ON_PACKAGE_STATE_ERROR especifica la gestión de un paquete PL/SQL con estado que se ejecuta en una sesión. Cuando se modifica un paquete de este tipo, como durante el mantenimiento planificado de los objetos proporcionados por Oracle, las sesiones que tienen una instancia activa del paquete reciben el siguiente error cuando intentan ejecutar el paquete:

ORA-4068 existing state of package has been discarded

Sin embargo, es posible que el código de aplicación que reciba el error ORA-4068 no esté equipado para manejar este error con su lógica de reintentos.

La definición de SESSION_EXIT_ON_PACKAGE_STATE_ERROR en TRUE proporciona una gestión diferente para este caso. Cuando el valor de SESSION_EXIT_ON_PACKAGE_STATE_ERROR es TRUE, en lugar de solo emitir el error ORA-4068 cuando se descarta el estado del paquete, la sesión se cierra inmediatamente. Esto puede ser útil porque muchas aplicaciones pueden gestionar la terminación de sesión restableciendo de forma automática y transparente la conexión.

Zona horaria por defecto de Autonomous Database

La zona horaria por defecto de Autonomous Database es la hora universal coordinada (UTC) y, por defecto, las llamadas a SYSDATE y SYSTIMESTAMP devuelven la fecha y la hora en UTC.

Para cambiar la zona horaria de la base de datos, puede ejecutar la siguiente sentencia. En este ejemplo, se define la zona horaria de la base de datos como UTC-5.

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

Después de definir la zona horaria de la base de datos, por defecto SYSDATE y SYSTIMESTAMP siguen devolviendo la fecha y la hora en formato UTC (el valor de SYSDATE_AT_DBTIMEZONE es FALSE por defecto). Si define SYSDATE_AT_DBTIMEZONE en TRUE en una sesión, SYSDATE y SYSTIMESTAMP devuelven la zona horaria de la base de datos.

Consulte Configuración de la zona horaria de la base de datos para obtener más información sobre el uso de la cláusula SET TIME_ZONE con ALTER DATABASE.

Uso de SYSDATE_AT_DBTIMEZONE en una sesión

Cuando el valor de SYSDATE_AT_DBTIMEZONE es FALSE en una sesión, las llamadas a SYSDATE y SYSTIMESTAMP devuelven valores basados en la zona horaria por defecto de Autonomous Database, hora universal coordinada (UTC).

Cuando el valor de SYSDATE_AT_DBTIMEZONE es TRUE en una sesión, las llamadas a SYSDATE o SYSTIMESTAMP devuelven la fecha y la hora según la zona horaria de la base de datos.

Ejemplo

En el siguiente ejemplo, se devuelven fechas y horas para dos zonas horarias diferentes, según el valor del parámetro 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

El parámetro CLIENT_PREFETCH_ROWS se puede definir con ALTER SESSION o ALTER SYSTEM. Si el valor del parámetro cambia mediante ALTER SESSION, el nuevo valor entra en vigor para esa sesión específica en las siguientes recuperaciones de juegos de resultados. Si el valor del parámetro cambia mediante ALTER SYSTEM, el nuevo valor se aplica a las sentencias que se ejecutan en conexiones creadas después del comando ALTER SYSTEM.

Por ejemplo, si CLIENT_PREFETCH_ROWS se define en 100 y una aplicación cliente solicita recuperar 10 filas, se devuelve un total de 110 filas al controlador de cliente. Las primeras 10 filas de las 110 filas se proporcionan a la aplicación y el controlador de cliente almacena internamente en buffer las 100 filas restantes. Las siguientes 10 filas se recuperan de la aplicación cliente, cada una con 10 filas por iteración de recuperación se puede satisfacer a partir de las 100 filas que el controlador de cliente almacena en buffer internamente. Este proceso reduce el número de recorridos en red necesarios hacia y desde la base de datos. En este ejemplo, en la 11a recuperación, se produce un nuevo recorrido de ida y vuelta de red y la base de datos devuelve el siguiente lote de 110 filas, siempre que el juego de resultados no se haya agotado y el ciclo se repita.

Notas para definir CLIENT_PREFETCH_ROWS:

• Cuando CLIENT_PREFETCH_ROWS se define en un valor distinto de cero, su valor tiene prioridad sobre el valor OCI_ATTR_PREFETCH_ROWS por defecto para el recuento de filas de recuperación previa.

• Si el valor OCI_ATTR_PREFETCH_ROWS se define en un valor no por defecto, el valor CLIENT_PREFETCH_ROWS se ignora para el recuento de filas de recuperación previa.

• Uso de CLIENT_PREFETCH_ROWS con OCIAttrSet():

  OCI_ATTR_PREFETCH_ROWS define el número de filas de nivel superior que se van a recuperar previamente. El valor predeterminado es 1 fila. Sin embargo, si se define CLIENT_PREFETCH_ROWS, el número de filas de nivel superior que se van a recuperar previamente viene determinado por la siguiente prioridad:

  1. Si define el atributo OCI_ATTR_PREFETCH_ROWS mediante la función OCIAttrSet() o oraaccess.xml como valor '1', el valor CLIENT_PREFETCH_ROWS del parámetro de inicialización de la base de datos tiene prioridad y determina el número de filas de nivel superior que se van a recuperar previamente.

  2. Si define el atributo OCI_ATTR_PREFETCH_ROWS mediante la función OCIAttrSet() o oraaccess.xml como valor 'x' distinto de 1, se recuperará previamente el número de filas de nivel superior 'x' y se ignorará el parámetro de inicialización de la base de datos CLIENT_PREFETCH_ROWS.

  3. Si no define un valor OCI_ATTR_PREFETCH_ROWS mediante OCIAttrSet() o oraaccess.xml, el valor CLIENT_PREFETCH_ROWS del parámetro de inicialización de la base de datos tiene prioridad y determina el número de filas de nivel superior que se van a recuperar previamente.

• Uso de CLIENT_PREFETCH_ROWS con OCIAttrGet():

  La función OCIAttrGet() devuelve el juego de valores de fila de recuperación previa efectiva de OCI_ATTR_PREFETCH_ROWS, oraaccess.xml y el parámetro de inicialización de la base de datos CLIENT_PREFETCH_ROWS. Si se define el valor OCI_ATTR_PREFETCH_MEMORY, puede que el valor devuelto por OCIAttrGet() no sea el valor de filas de recuperación previa final y que esté restringido al número máximo de filas permitido por el valor de memoria especificado por el atributo OCI_ATTR_PREFETCH_MEMORY.

Los valores por defecto y máximos para JOB_QUEUE_PROCESSES varían en función del modelo informático que utilice. Consulte Modelos de recursos informáticos en Autonomous Database para obtener más información.

El coordinador de trabajos de Oracle Scheduler y los trabajadores del trabajo están controlados por el parámetro JOB_QUEUE_PROCESSES. El programador ajusta automáticamente el número real de trabajadores de trabajos creados para los trabajos de Oracle Scheduler en función de varios factores, incluidos los recursos disponibles, la configuración del gestor de recursos y los trabajos en ejecución.

El valor por defecto para JOB_QUEUE_PROCESSES ofrece un compromiso entre la calidad del servicio para las aplicaciones y el uso razonable de los recursos del sistema. Sin embargo, es posible que el valor por defecto no se adapte a todos los entornos.

Al definir el valor de JOB_QUEUE_PROCESSES en 0, se desactivan los trabajos del planificador no proporcionados por Oracle. Cuando JOB_QUEUE_PROCESSES está definido en 0, no se desactivan los trabajos internos para los usuarios proporcionados por Oracle (los trabajos relacionados con el servicio ejecutados por los usuarios proporcionados por Oracle siguen programados).

Los usuarios proporcionados por Oracle son usuarios marcados como ORACLE_MAINTAINED con el valor Y. Los usuarios no proporcionados por Oracle son usuarios marcados como ORACLE_MAINTAINED con el valor N.

Consulte ALL_USERS para obtener más información.

Valores

• ENFORCED: independientemente de la configuración de RESULT_CACHE_MODE o de las indicaciones especificadas, solo las construcciones deterministas son elegibles para el almacenamiento en caché de resultados. Por ejemplo, las consultas que utilizan funciones PL/SQL que no se declaran como deterministas nunca se almacenan en caché (a menos que las funciones se declaren como deterministas, los resultados de la consulta con dichas funciones no se almacenarán en caché).

• TRUSTED: la base de datos respeta el valor de RESULT_CACHE_MODE y las indicaciones especificadas y considerará las consultas que utilicen construcciones posiblemente no deterministas como candidatos para el almacenamiento en caché de resultados. Por ejemplo, las consultas que utilizan funciones PL/SQL que no se declaran como deterministas se pueden almacenar en caché. Sin embargo, tenga en cuenta que los resultados que se sabe que no son deterministas no se almacenan en caché (por ejemplo, SYSDATE o construcciones que implican SYSDATE).

Consulte RESULT_CACHE_MODE para obtener más información.