Documentación de Oracle Cloud Infrastructure

Configuración de cliente para disponibilidad continua en Autonomous Database

No es necesario reiniciar las aplicaciones para las actividades de mantenimiento planificadas cuando active la continuidad de aplicaciones y siga 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 la continuidad de aplicaciones activada

Los servicios de bases 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 los servicios de conexión de Autonomous Database. Para obtener 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 servicios de base de datos para Autonomous Data Warehouse y Nombres de servicios de base de datos para Autonomous Transaction Processing y Autonomous JSON Database.

Uso de prácticas recomendadas que soportan el vaciado

En Autonomous Database, nunca es necesario reiniciar los servidores de aplicaciones cuando el mantenimiento planificado se realiza según las mejores prácticas.

Para el mantenimiento planificado, la estrategia recomendada es proporcionar tiempo para que el trabajo actual se complete antes de que se inicie el mantenimiento. En Autonomous Database, esto ocurre automáticamente y el trabajo se vacía antes de iniciar las 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 junto con la solución de failover elegida para aquellas solicitudes que no se completen en el tiempo asignado para el vaciado. La solución de failover intentará recuperar sesiones que no se hayan vaciado 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 desproteja una conexión solo durante el tiempo que necesite. No se retiene una conexión en lugar de devolverla al pool. Por lo tanto, una aplicación debe bloquear una conexión y, a continuación, protegerla inmediatamente después de completar el trabajo. Las conexiones estarán disponibles para su uso posterior por parte de otros threads o por parte del thread cuando sea necesario de nuevo. 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

El uso de un pool de conexiones de Oracle con detección de FAN es la solución recomendada para ocultar el mantenimiento planificado. A medida que el mantenimiento avance y finalice, las sesiones se moverán y se volverán 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. Entre los pools de Oracle soportados se incluyen los proveedores UCP, WebLogic GridLink, Tuxedo, pool de sesiones de OCI y ODP.NET gestionados y no gestionados. No se necesita ningún cambio de aplicación de ningún tipo para utilizar FAN, excepto para asegurarse de que las conexiones se devuelven al pool entre solicitudes.

Uso de UCP con un pool de conexiones de terceros

Si utiliza un servidor de aplicaciones basado en Java de terceros, el método más eficaz para lograr el vaciado y el failover es sustituir el origen de datos de pool por UCP. Muchos servidores de aplicaciones admiten este enfoque, incluidos Oracle WebLogic Server, IBM WebSphere, IBM Liberty, Apache Tomcat, Red Hat WildFly (JBoss), Spring e Hibernate, entre otros.

Uso de pruebas de conexión

Si no puede utilizar un pool de Oracle con FAN, los controladores de cliente de Autonomous Database o proporcionados vaciarán la sesión. Cuando los servicios se han reubicado o parado durante el mantenimiento, o hay un 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 de la validez de la conexión al tomar prestadas o devolver conexiones de un pool de conexiones
  • Pruebas SQL personalizadas para la validez de la conexión
  • Los límites de 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 que está activada en la base de datos en el pool de conexiones o el servidor de aplicaciones. Configure también el lavado y la destrucción del pool en caso de fallo de prueba de conexión a, como mínimo, dos veces el tamaño máximo del pool o MAXINT.

Uso de pruebas de conexión con un controlador Java ligero

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

  • Active 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 pruebas siguientes:

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

Uso de pruebas de conexión con el controlador OCI

Si desea utilizar el controlador OCI directamente, utilice OCI_ATTR_SERVER_STATUS. Este es el único método que supone un cambio de código. En el código, compruebe el manejador del servidor al tomar y devolver conexiones para ver si la sesión está conectada. 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, se realiza esta comprobación de conexión.

En el siguiente ejemplo de código se 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

Realice estos pasos para utilizar la 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 de Oracle Database 19c y posteriores proporcionan soporte completo para la continuidad de aplicaciones (CA) y para la continuidad de aplicaciones transparente (CAT). 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

    • Oracle Call Interface Session Pool 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 el uso de aplicaciones consisten en desproteger (tomar prestadas) las conexiones solo durante el tiempo que se necesiten y, a continuación, protegerlas en el pool cuando se completen para las acciones actuales. Esto es importante para el mejor rendimiento de la aplicación en tiempo de ejecución, para el nuevo equilibrio del trabajo en tiempo de ejecución y durante los eventos de mantenimiento y failover. Esta práctica también es importante para el vaciado.

Al utilizar un pool de conexiones de Oracle, como Universal Connection Pool (UCP), el pool de sesiones de OCI o el proveedor no gestionado ODP.Net o al utilizar WebLogic Active GridLink, siguiendo esta práctica se incorporan los límites de solicitud que utiliza la continuidad de aplicaciones 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.

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

  • No hay ninguna transacción abierta
  • Los cursores se vuelven a la caché de sentencias o se cancelan
  • No existe ningún estado de sesión que no se pueda restaurar (consulte Limpieza del estado de sesión entre solicitudes en este documento)

Activación de los Mutables Utilizados 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 de las funciones modificables para SYSDATE, SYSTIMESTAMP, SYS_GUID y la secuencia NEXTVAL. Si los valores originales no se mantienen y se devuelven valores diferentes a la aplicación durante la reproducción, la reproducción se rechazará.

Si necesita modificables 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, existe la opción de si se deben reproducir los efectos secundarios. Muchas aplicaciones optan por repetir efectos secundarios, como los asientos y el envío de correo, ya que las ejecuciones duplicadas no causan ningún problema. Para la continuidad de aplicaciones, se reproducen efectos secundarios a menos que la solicitud o la llamada de usuario esté desactivada explícitamente para la reproducción. Por el contrario, si la continuidad de aplicaciones transparente está activada por defecto, la CAT no reproduce efectos secundarios. La captura está desactivada y se activa de nuevo en el siguiente límite implícito creado por la CAT.

Mejores prácticas para desarrolladores para la disponibilidad continua

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

Devolución de conexiones al pool de conexiones

La práctica de desarrollador más importante es devolver las conexiones al pool de conexiones al final de cada solicitud. Esto es importante para un mejor rendimiento de la aplicación en tiempo de ejecución, para el vaciado del trabajo y para el nuevo equilibrio del trabajo en tiempo de ejecución y durante el mantenimiento, así como para la gestión de eventos de failover. Algunas aplicaciones tienen una idea falsa de que mantener las conexiones mejora el rendimiento. Al mantener una conexión no se mejora el rendimiento ni la escala.

Limpiar estado de sesión entre solicitudes

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

Cuando una aplicación devuelve una conexión al pool de conexiones, los cursores con estado FETCH y el estado de sesión definido en esa sesión permanecen tal cual, 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 sesión relacionado con la aplicación para evitar la pérdida de reutilizaciones posteriores de esa sesión de base de datos. La limpieza del estado de la sesión garantiza que la TAC pueda detectar los límites.

Para limpiar automáticamente el estado entre solicitudes con Oracle Database 21c, defina el atributo de servicio RESET_STATE=LEVEL1. De esta forma 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 las variables globales PL/SQL. Utilice TRUNCATE para borrar las tablas temporales, SYS_CONTEXT.CLEAR_CONTEXT para borrar el contexto y cancelar los cursores devolviéndolos a la caché de sentencias.

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

No incrustar COMMIT en PL/SQL y evitar la confirmación en caso de éxito y confirmación automática

Se recomienda utilizar una confirmación de nivel superior (OCOMMIT, COMMIT() o OCITransCommit). Si la aplicación utiliza COMMIT integrado en PL/SQL, AUTOCOMMIT o COMMIT ON SUCCESS, puede que no sea posible la recuperación después de una interrupción o timeout. PL/SQL no es reentrante. Una vez ejecutada una confirmación en PL/SQL, ese bloque PL/SQL no se puede volver a enviar. Las aplicaciones deben anular la selección de la confirmación que no sea correcta, ya que es posible que se hayan leído esos datos, o bien utilizar un punto de control y una técnica de reinicio para el lote. Al utilizar AUTOCOMMIT o COMMIT ON SUCCESS, la salida se pierde.

Si la aplicación utiliza una confirmación de nivel superior, habrá soporte completo para Transparent Application Continuity (TAC), Application Continuity (AC) y TAF Select Plus. Si la aplicación utiliza COMMIT incorporado en PLSQL o AUTOCOMMIT o COMMIT ON SUCCESS, puede que no sea posible reproducir para casos en los que la llamada que incluye COMMIT no se ha ejecutado hasta su finalización.

Uso de 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 un valor SELECT utiliza ORDER BY o GROUP BY, el orden se conserva. En Autonomous Database, la mayoría de las veces el optimizador de consultas utiliza la misma ruta de acceso, lo que puede ser útil 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 donde se permita AS OF.

Consideraciones para SQL*Plus

SQL*Plus suele ser la herramienta que usamos 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 el plan de failover y medir la protección. SQL*Plus no es una aplicación del pool, por lo que no tiene límites de solicitud explícitos. Algunas aplicaciones utilizan SQL*Plus, por ejemplo, para los 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 la CAD a partir de Oracle Database 19c. Para obtener mejores resultados, defina un tamaño de matriz grande. Por ejemplo (establezca arraysize 1000). Evite activar serveroutput, ya que de esta forma se crea un estado de sesión que no se puede restaurar.