Documentación de Oracle Cloud Infrastructure

Configuración de cliente para una disponibilidad continua en Autonomous Database

No es necesario reiniciar las aplicaciones para actividades de mantenimiento planificadas cuando se activa la continuidad de aplicaciones y se siguen las mejores prácticas de codificación.

Tema principal: Uso de la continuidad de aplicaciones en Autonomous Database

Conexión mediante servicios de base de datos con continuidad de aplicaciones activada

Los servicios de base de datos de Oracle proporcionan transparencia para la infraestructura de Autonomous Database subyacente.

Las operaciones de alta disponibilidad y continuidad de aplicaciones se basan en el uso de servicios de conexión de Autonomous Database. Para obtener la continuidad de la aplicación, utilice un servicio de base de datos al conectarse a la base de datos.

Los nombres de los servicios de base de datos predefinidos en Autonomous Database son diferentes, según la carga de trabajo, como se describe en Nombres de servicio de base de datos para Autonomous Database.

Uso de prácticas recomendadas que admiten drenaje

En Autonomous Database, nunca es necesario reiniciar los servidores de aplicaciones cuando el mantenimiento planificado sigue las mejores prácticas.

Para el mantenimiento planificado, el enfoque recomendado es proporcionar tiempo para que el trabajo actual se complete antes de que se inicie el mantenimiento. En Autonomous Database, esto se produce automáticamente y el trabajo se drena antes de iniciar actividades de mantenimiento cuando sigue estas directrices:

  • FAN con pools de conexiones de Oracle o controladores de Oracle
  • Pruebas de conexión

Utilice el vaciado en combinación con la solución de failover elegida para aquellas solicitudes que no se completen dentro del tiempo asignado para el vaciado. La solución de failover intentará recuperar sesiones que no se hayan agotado en el tiempo asignado.

Devolución de Conexiones al Pool de Conexiones

La aplicación debe devolver la conexión al pool de conexiones en cada solicitud. Se recomienda que una aplicación bloquee una conexión sólo durante el tiempo en que la necesita. No se realiza la retención de una conexión en lugar de devolverla al pool. Por lo tanto, una aplicación debe desproteger una conexión y, a continuación, proteger esa conexión inmediatamente, el trabajo se ha completado. A continuación, las conexiones estarán disponibles para su uso posterior por otros threads o el thread cuando sea necesario nuevamente. La devolución de conexiones a un pool de conexiones es una recomendación general independientemente de si utiliza FAN para drenar o pruebas de conexión para drenar.

Uso de un Pool de Conexiones de Oracle

Mediante el uso de un pool de conexiones de Oracle con detección FAN para ocultar el mantenimiento planificado. A medida que el mantenimiento avanza y finaliza, las sesiones se mueven y se vuelven a equilibrar. No tiene ningún impacto en los usuarios cuando su aplicación utiliza un pool de Oracle con FAN y devuelve las conexiones al pool entre solicitudes. Los pools de Oracle soportados incluyen proveedores de UCP, WebLogic GridLink, Tuxedo, OCI Session Pool y ODP.NET gestionados y no gestionados. No es necesario ningún cambio de aplicación para utilizar FAN, aparte de asegurarse de que las conexiones se devuelven al pool entre solicitudes.

Uso de UCP con un Pool de Conexiones de Terceros

If you are using a third party, Java-based application server, the most effective method to achieve draining and failover is to replace the pooled data source with UCP. Este enfoque está soportado por muchos servidores de aplicaciones, incluidos Oracle WebLogic Server, IBM WebSphere, IBM Liberty, Apache Tomcat, Red Hat WildFly (JBoss), Spring e Hibernate, entre otros.

Usar pruebas de conexión

Si no puede utilizar un pool de Oracle con FAN, la instancia de Autonomous Database o los controladores de cliente proporcionados drenarán la sesión. Cuando los servicios se reubican o se detienen durante el mantenimiento, o cuando se realiza una operación de switchover a una ubicación en espera mediante Autonomous Data Guard, los controladores de cliente de Oracle Database y Oracle buscan lugares seguros para liberar conexiones según las siguientes reglas:

  • Pruebas de conexión estándar para la validez de conexión en préstamo o devolución desde un pool de conexiones
  • Pruebas SQL personalizadas para la validez de la conexión
  • Los límites de la solicitud están vigentes y la solicitud actual ha finalizado

Uso de pruebas de conexión con Autonomous Database

Puede agregar, suprimir, activar o desactivar pruebas de conexión para Autonomous Database.

Utilice la vista DBA_CONNECTION_TESTS para mostrar las pruebas de conexión disponibles.

Por ejemplo:

SQL> EXECUTE 
   dbms_app_cont_admin.add_sql_connection_test('SELECT COUNT(1) FROM DUAL');
SQL> EXECUTE 
   dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.sql_test, 
                                             'SELECT COUNT(1) FROM DUAL');
SQL> SELECT * FROM DBA_CONNECTION_TESTS;

Configure la misma prueba de conexión activada en la base de datos en el pool de conexiones o el servidor de aplicaciones. Configure también el vaciado y la destrucción del pool en caso de fallo de prueba de conexión hasta al menos dos veces el tamaño máximo del pool o MAXINT.

Uso de Pruebas de Conexión con Controlador Java Fino

Si desea utilizar pruebas de conexión locales para el controlador y no puede utilizar el soporte completo de FAN de UCP:

  • Activar validate-on-borrow=true
  • Defina las propiedades del sistema Java:
    • -Doracle.jdbc.fanEnabled=true
    • -Doracle.jdbc.defaultConnectionValidation=SOCKET

A continuación, utilice una de las siguientes pruebas:

  • java.sql.Connection.isValid(int timeout)
  • oracle.jdbc.OracleConnection.pingDatabase()
  • oracle.jdbc.OracleConnection.pingDatabase(int timeout)
  • Una HINT al inicio del SQL de prueba:
    • /*+ CLIENT_CONNECTION_VALIDATION */

Uso de pruebas de conexión con el controlador de OCI

Si desea utilizar el controlador de OCI directamente, utilice OCI_ATTR_SERVER_STATUS. Este es el único método que es un cambio de código. En el código, compruebe el identificador del servidor al pedir prestado y devolver conexiones para ver si la sesión está desconectada. Durante el mantenimiento, el valor de OCI_ATTR_SERVER_STATUS se define en OCI_SERVER_NOT_CONNECTED. Al utilizar el pool de sesiones de OCI, esta comprobación de conexión se realiza por usted.

El siguiente ejemplo de código muestra cómo utilizar OCI_ATTR_SERVER_STATUS: 

ub4 serverStatus = 0OCIAttrGet((dvoid *)srvhp,
          OCI_HTYPE_SERVER,             
        (dvoid *)&serverStatus, (ub4 *)0, OCI_ATTR_SERVER_STATUS,
      errhp);if (serverStatus ==
        OCI_SERVER_NORMAL)printf("Connection is
        up.\n");else if (serverStatus ==
        OCI_SERVER_NOT_CONNECTED) printf("Connection is down.\n");

Pasos para el uso de la continuidad de aplicaciones

Lleve a cabo los siguientes pasos para utilizar Continuidad de Aplicaciones:

  • Como requisito, active y configure la continuidad de aplicaciones o la continuidad de aplicaciones transparente (TAC) para el servicio de base de datos en Autonomous Database. Consulte Configuración de la continuidad de aplicaciones en Autonomous Database para obtener más información.

  • Oracle recomienda utilizar los controladores de cliente más recientes. Los controladores de cliente 19c de Oracle Database y posteriores proporcionan soporte completo para la continuidad de aplicaciones (AC) y para la continuidad de aplicaciones transparente (TAC). Utilice uno de los siguientes controladores de clientes soportados:

    • Oracle JDBC Replay Driver 19c o posterior. Se trata de una función de controlador JDBC que se proporciona con Oracle Database 19c para la continuidad de aplicaciones

    • Oracle Universal Connection Pool (UCP) 19c o posterior con Oracle JDBC Replay Driver 19c o posterior

    • Oracle Weblogic Server 12c con Active GridLink o servidores de aplicaciones JDBC de terceros que utilicen UCP con Oracle JDBC Replay Driver 19c o posterior

    • Pools de conexiones Java o aplicaciones Java independientes que utilicen Oracle JDBC Replay Driver 19c o posterior

    • Pool de Sesión de Oracle Call Interface 19c o posterior.SQL*Plus 19c (19.8) o posterior

    • ODP.NET agrupado, controlador no gestionado 19c o posterior ("Pooling=true" por defecto en 12.2 y versiones posteriores)

    • Aplicaciones basadas en Oracle Call Interface que utilicen un controlador OCI 19c o posterior

Devolución de Conexiones al Pool de Conexiones

La aplicación debe devolver la conexión al pool de conexiones de Oracle en cada solicitud. Las mejores prácticas para utilizar aplicaciones consisten en desproteger (prestar) las conexiones solo durante el tiempo que se necesiten y, a continuación, protegerlas en el pool cuando finalice la acción actual. Esto es importante para el mejor rendimiento de la aplicación en tiempo de ejecución, para volver a equilibrar el trabajo en tiempo de ejecución y durante los eventos de mantenimiento y failover. Esta práctica también es importante para el drenaje.

Al utilizar un pool de conexiones de Oracle, como Universal Connection Pool (UCP) o OCI Session Pool, o ODP.Net Unmanaged Provider o al utilizar WebLogic Active GridLink, tras esta práctica se embeben los límites de solicitud que utiliza Application Continuity para identificar lugares seguros para reanudar y finalizar la captura. Esto es necesario para la continuidad de aplicaciones y se recomienda para la continuidad de aplicaciones transparente.

Además, la continuidad de aplicaciones transparente detectará los límites de la solicitud si un pool no está en uso o si la reproducción está desactivada. Las condiciones para descubrir un límite son:

  • No hay ninguna transacción abierta
  • Los cursores se devuelven a la caché de sentencias o se cancelan
  • No existe ningún estado de sesión que no se pueda restaurar (consulte Estado de Sesión Limpia entre Solicitudes de este documento)

Activación de Colocaciones Utilizadas en la Aplicación

Las funciones modificables son funciones que pueden devolver un nuevo valor cada vez que se ejecutan. Se proporciona soporte para mantener los resultados originales para SYSDATE, SYSTIMESTAMP, SYS_GUID y sequence.NEXTVAL. Si los valores originales no se mantienen y se devuelven diferentes valores a la aplicación en la reproducción, se rechaza la reproducción.

Si necesita archivos mutables para PL/SQL, emita GRANT KEEP según sea necesario.

Por ejemplo:

SQL> GRANT KEEP DATE TIME to adb_user;
SQL> GRANT KEEP SYSGUID to adb_user;
SQL> GRANT KEEP SEQUENCE mySequence to adb_user on mysequence.myobject;

Efectos Secundarios

Cuando una solicitud de base de datos incluye una llamada externa, como el envío de MAIL o la transferencia de un archivo, esto se denomina efecto secundario.

Los efectos secundarios son acciones externas, no se revierten. Cuando se produce la reproducción, hay una opción en cuanto a si los efectos secundarios deben repetirse. Muchas aplicaciones optan por repetir efectos secundarios como los asientos contables y el envío de correo, ya que las ejecuciones duplicadas no causan ningún problema. Para la continuidad de aplicaciones, los efectos secundarios se reproducen a menos que la solicitud o la llamada de usuario estén explícitamente desactivadas para la reproducción. Por el contrario, dado que la continuidad de aplicaciones transparente está activada por defecto, TAC no reproduce efectos secundarios. La captura está desactivada y se vuelve a activar en el siguiente límite implícito creado por TAC.

Mejores prácticas para desarrolladores de disponibilidad continua

Siga estas mejores prácticas para codificar la disponibilidad continua en Autonomous Database.

Devolución de Conexiones al Pool de Conexiones

La práctica de desarrollador más importante es devolver conexiones al pool de conexiones al final de cada solicitud. Esto es importante para el mejor rendimiento de la aplicación en tiempo de ejecución, para vaciar el trabajo y para volver a equilibrar el trabajo en tiempo de ejecución y durante el mantenimiento, y para gestionar eventos de failover. Algunas aplicaciones tienen una idea falsa de que mantener las conexiones mejora el rendimiento. Mantener una conexión no funciona ni escala.

Limpiar estado de sesión entre solicitudes

Se recomienda limpiar el estado de la sesión entre las solicitudes de base de datos.

Cuando una aplicación devuelve una conexión al pool de conexiones, los cursores en estado FETCH y el estado de sesión definido en esa sesión permanecen en su lugar a menos que se realice una acción para borrarlos. Si la aplicación está definiendo el estado, se recomienda devolver los cursores a la caché de sentencias y borrar el estado de la sesión relacionada con la aplicación para evitar que se produzcan fugas en las reutilizaciones posteriores de esa sesión de base de datos. La limpieza del estado de la sesión garantiza que el TAC pueda detectar límites.

Para limpiar automáticamente el estado entre solicitudes con Oracle Database 23ai, defina el atributo de servicio RESET_STATE=LEVEL1. Al hacerlo, se evitará la pérdida de estado y la recuperación de cursores mediante el uso posterior del pool de conexiones.

Si utiliza Oracle Database 19c, utilice DBMS_SESSION.RESET_PACKAGE para borrar variables globales PL/SQL, utilice TRUNCATE para borrar tablas temporales, SYS_CONTEXT.CLEAR_CONTEXT para borrar el contexto y cancelar los cursores devolviéndolos a la caché de sentencias.

Si su aplicación no tiene estado, como REST, APEX, Microservice y la mayoría de las aplicaciones web, se recomienda utilizar RESET_STATE.

No embeba COMMIT en PL/SQL y evite la confirmación correcta y la confirmación automática

Se recomienda utilizar una confirmación de nivel superior, (OCOMMIT o COMMIT() o OCITransCommit). Si la aplicación utiliza COMMIT embebido en PL/SQL o AUTOCOMMIT o COMMIT ON SUCCESS, puede que no se pueda recuperar después de una interrupción o un timeout. PL/SQL no se vuelve a introducir. Una vez que se ha ejecutado una confirmación en PL/SQL, ese bloque PL/SQL no se puede volver a ejecutar. Las aplicaciones deben anular el retiro de la confirmación, que no es válida, ya que es posible que se hayan leído los datos, o bien utilizar por lotes una técnica de punto de control y reinicio. Al utilizar AUTOCOMMIT o COMMIT ON SUCCESS, se pierde la salida.

Si la aplicación utiliza una confirmación de nivel superior, hay soporte completo para la continuidad de aplicaciones transparente (TAC), la continuidad de aplicaciones (AC) y TAF Select Plus. Si la aplicación utiliza COMMIT embebido en PLSQL o AUTOCOMMIT o COMMIT ON SUCCESS, puede que no sea posible reproducirla en los casos en los que la llamada, incluido el COMMIT, no se haya ejecutado hasta su finalización.

Utilizar ORDER BY o GROUP BY en consultas

La continuidad de aplicaciones garantiza que la aplicación vea los mismos datos en la reproducción. Si no se pueden restaurar los mismos datos, la continuidad de aplicaciones no aceptará la reproducción. Cuando SELECT utiliza ORDER BY o el orden GROUP BY se conserva. En Autonomous Database, el optimizador de consultas suele utilizar la misma ruta de acceso, lo que puede ayudar en el mismo orden de los resultados. La continuidad de aplicaciones también utiliza una cláusula AS OF para devolver los mismos resultados de consulta en los que se permite AS OF.

Consideraciones para SQL*Plus

SQL*Plus suele ser nuestra herramienta para probar cosas. SQL*Plus, por supuesto, no refleja nuestra aplicación real que se utilizará en producción, por lo que siempre es mejor utilizar el conjunto de pruebas de aplicación real para probar su plan de failover y medir su protección. SQL*Plus no es una aplicación de pool, por lo que no tiene límites de solicitud explícitos. Algunas aplicaciones utilizan SQL*Plus, por ejemplo, para informes. Para utilizar SQL*Plus con failover, compruebe lo siguiente:

  1. FAN siempre está activado para SQL*Plus. Utilice la cadena de conexión recomendada que configura automáticamente los puntos finales de ONS.

  2. Al utilizar SQL*plus, la clave es minimizar los recorridos de ida y vuelta a la base de datos: https://blogs.oracle.com/opal/sqlplus-12201-adds-new-performance-features

  3. SQL*Plus está soportado para TAC a partir de Oracle Database 19c. Para obtener los mejores resultados, defina un tamaño de matriz grande. Por ejemplo (configurar el tamaño de lectura de datos 1000). Evite activar serveroutput, ya que esto crea un estado de sesión no recuperable.