Parámetros de inicialización

SESSION_EXIT_ON_PACKAGE_STATE_ERROR especifica el manejo de un paquete PL/SQL con estado que se ejecuta en una sesión. Cuando un paquete de este tipo se modifica, como durante el mantenimiento planificado de objetos proporcionados por Oracle, las sesiones que tienen una instanciación 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 recibe el error ORA-4068 no esté equipado para manejar este error con su lógica de reintento.

La definición de SESSION_EXIT_ON_PACKAGE_STATE_ERROR en TRUE proporciona un manejo diferente para este caso. Cuando SESSION_EXIT_ON_PACKAGE_STATE_ERROR es TRUE, en lugar de simplemente emitir el error ORA-4068 cuando se desecha el estado del paquete, la sesión se cierra inmediatamente. Esto puede resultar ventajoso porque muchas aplicaciones pueden manejar la terminación de sesiones restableciendo la conexión de forma automática y transparente.

Zona horaria de Autonomous Database por defecto

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';

Este ejemplo define la zona horaria de la base de datos para la costa este de EE. UU.: America/New_York y la hora se ajusta automáticamente en los conmutadores de horario de ahorro de energía:

ALTER DATABASE SET TIME_ZONE='America/New_York';

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 UTC (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 Setting the Database Time Zone in Oracle Database 19c u Oracle Database 23ai 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 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 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 recuperaciones de juegos de resultados posteriores. 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 en buffer internamente las 100 filas restantes. Las 10 filas siguientes 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 internamente en buffer. Este proceso reduce el número de recorridos de ida y vuelta de red necesarios hacia y desde la base de datos. En este ejemplo, en la 11ª recuperación, se realiza 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 agote 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 que no es el valor 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 por defecto 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 el 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 valor de fila de recuperación previa efectivo definido en 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, es posible que el valor devuelto por OCIAttrGet() no sea el valor final de las filas de recuperación previa y se pueda restringir 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 según el modelo de cálculo que utilice. Consulte Modelos de recursos informáticos en Autonomous Database para obtener más información.

El coordinador de trabajos y los trabajadores de trabajos de Oracle Scheduler están controlados por el parámetro JOB_QUEUE_PROCESSES. El programador ajusta automáticamente el número real de trabajadores 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 proporciona 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 ajuste a todos los entornos.

Al definir el valor de JOB_QUEUE_PROCESSES en 0, se desactivan los trabajos del programador no proporcionados por Oracle. Cuando JOB_QUEUE_PROCESSES se define en 0, no desactiva ningún trabajo interno para los usuarios proporcionados por Oracle (los trabajos relacionados con el servicio ejecutados por los usuarios proporcionados por Oracle siguen programándose).

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.

Autonomous Database utiliza perfiles de bloqueo para restringir determinadas funciones y funcionalidades de la base de datos. Por defecto, la base de datos emite un error cada vez que intenta ejecutar un comando SQL restringido por el perfil de bloqueo de Autonomous Database. El parámetro LOCKDOWN_ERRORS permite suprimir los errores del perfil de bloqueo. Además, cuando LOCKDOWN_ERRORS se define en el valor IGNORE, al ignorar un error, la base de datos registra los detalles relativos a la sentencia SQL, el usuario y el registro de hora del comando.

Puede utilizar la vista DBA_LOCKDOWN_ERRORS para obtener información sobre los errores de perfil de bloqueo. Consulte Vista Errores de Bloqueo para obtener más información.

Valores

• ENFORCED: independientemente del valor 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 utilizan construcciones posiblemente no deterministas como candidatas para el almacenamiento en caché de resultados. Por ejemplo, las consultas que utilizan funciones PL/SQL que no se declaran 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.