Las copias de seguridad de la base de datos pueden fallar durante la etapa de configuración de RMAN o durante un trabajo de copia de seguridad deRMAN en ejecución. Las tareas de configuración de RMAN incluyen la validación de la conectividad del destino de copia de seguridad, la instalación del módulo de copia de seguridad y los cambios de configuración de RMAN. Los archivos log que examine dependen de la etapa en la que se produzca el fallo.

1. Inicie sesión en el host como usuario oracle.
2. Consulte el archivo log aplicable:
   • Para identificar el ID de trabajo de una copia de seguridad automatizada, utilice el comando dbaascli database backup --dbname <dbname> --showHistory. Muestra el historial de todos los trabajos de copia de seguridad, incluidos sus correspondientes ID de trabajo.
   • Los logs de trabajos están disponibles en /var/opt/oracle/log/dtrs/jobs/, denominado con el formato <job_id>.log. Si un trabajo falla, también se genera un log de depuración correspondiente <job_id>.debug en la misma ubicación.
   • Puede encontrar los logs de ejecución del comando RMAN correspondientes para las operaciones de copia de seguridad, recuperación y configuración en el directorio /var/opt/oracle/log/<dbname>/dtrs/rman/bkup.

1. Desde un símbolo del sistema, compruebe el estado del agente:

   systemctl status dbcsagent.service

2. Si el agente tiene el estado parada/en espera, intente reiniciar el agente:

   systemctl start dbcsagent.service

3. Vuelva a comprobar el estado del agente para confirmar que tiene el estado parada/en ejecución:

   systemctl status dbcsagent.service

1. Cree un usuario de Swift en su arrendamiento. Consulte Trabajar con token de autenticación.
2. Con el usuario que ha creado en el paso anterior, utilice el siguiente comando para verificar que el host puede acceder al almacén de objetos.

   curl -v -X HEAD -u <user_ID>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>

   Consulte Preguntas frecuentes sobre Object Storage para conocer la región correcta que se debe utilizar. Consulte Descripción de los espacios de nombres de Object Storage para obtener información sobre el espacio de nombres de Object Storage.
3. Si no se puede conectar al almacén de objetos, consulte el tema Requisitos para copias de seguridad en Exadata Cloud Service para obtener información sobre la configuración de la conectividad del almacén de objetos.

Si un comando interactivo como oraenv, o cualquier comando que pueda devolver un mensaje de error o advertencia, se ha agregado al archivo .bash_profile para el usuario grid u oracle, las operaciones del servicio Database como las copias de seguridad automáticas se pueden interrumpir sin haber finalizado. Consulte el archivo .bash_profile para estos comandos y elimínelos.

Las operaciones de copia de seguridad requieren espacio en el directorio /u01 del sistema de archivos del host. Utilice el comando df -h en el host para comprobar el espacio disponible para las copias de seguridad. Si el sistema de archivos no tiene espacio suficiente, puede eliminar archivos de rastreo o archivos log antiguos para liberar espacio.

Puede que el sistema no tenga la versión necesaria del módulo de copia de seguridad (opc_installer.jar). Consulte No se han podido utilizar las copias de seguridad gestionadas en el sistema de base de datos para obtener más información sobre este problema conocido. Para corregir el problema, puede seguir el procedimiento de esa sección o simplemente actualizar el sistema de base de datos y la base de datos con el último paquete de parches.

La personalización del archivo de perfil de ubicación ($ORACLE_HOME/sqlplus/admin/glogin.sql) puede hacer que las copias de seguridad gestionadas fallen en Oracle Cloud Infrastructure. En concreto, los comandos interactivos pueden producir fallos en las copias de seguridad. Oracle recomienda no modificar este archivo para bases de datos alojadas en Oracle Cloud Infrastructure.

La base de datos debe estar activa y en ejecución (lo ideal es en todos los nodos) mientras la copia de seguridad está en curso.

Al aprovisionar una nueva base de datos, el modo de archivado se define en ARCHIVELOG por defecto. Este es el modo de archivado necesario para las operaciones de copia de seguridad. Si corresponde, compruebe el ajuste de modo de archivado de la base de datos y cámbielo a ARCHIVELOG.

Instance <instance_identifier> is running on node *<node_identifier>. Instance status: Stuck Archiver

Consulte ORA-00257: error de archivador (ID de documento 2014425.1) para obtener información sobre la resolución de un proceso de archivador parado.

Instance <instance_identifier> is running on node *<node_identifier>. Instance status: Open

Si el estado de la instancia no cambia después de resolver la incidencia subyacente con el dispositivo o recurso lleno o no disponible, intente reiniciar la base de datos mediante el comando srvctl para actualizar el estado de la base de datos en el clusterware.

La edición de algunos parámetros de configuración de RMAN puede producir fallos de copia de seguridad en Oracle Cloud Infrastructure. Para comprobar la configuración de RMAN, utilice el comando show all en el símbolo del sistema de la línea de comandos de RMAN.

Consulte la siguiente lista de parámetros para obtener más información sobre los valores de configuración de RMAN que no se deben modificar para las bases de datos en Oracle Cloud Infrastructure.

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS;

CONFIGURE CONTROLFILE AUTOBACKUP ON;

CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 5 BACKUP TYPE TO COMPRESSED BACKUPSET;

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2 G;

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS  'SBT_LIBRARY=/var/opt/oracle/dbaas_acfs/<db_name>/opc/libopc.so, ENV=(OPC_PFILE=/var/opt/oracle/dbaas_acfs/<db_name>/opc/opc<db_name>.ora)';

CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO 'SBT_TAPE';

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2 G;

CONFIGURE ENCRYPTION FOR DATABASE ON;

Las copias de seguridad de RMAN fallan cuando se pierde un archivo de cartera del almacén de objetos. El archivo de cartera es necesario para activar la conectividad al almacén de objetos.

Las copias de seguridad de la base de datos fallan si la cartera de TDE no tiene el estado adecuado. Los siguientes escenarios pueden provocar este problema:

Si la base de datos se ha iniciado mediante SQL*Plus y no se ha definido la variable de entorno ORACLE_UNQNAME, la cartera no se abre correctamente.

srvctl start database -d <db_unique_name>

En un entorno multiinquilino para versiones de Oracle Database que soporten el almacén de claves de nivel PDB, cada PDB tiene su propia clave de cifrado maestra. Para bases de datos de Oracle 18c, esta clave de cifrado se almacena en un único almacén de claves utilizado por todos los contenedores. (Oracle Database 19c no soporta un almacén de claves en el nivel de la PDB.) Después de crear o conectar una nueva PDB, debe crear y activar una clave de cifrado maestra para ella. Si no lo hace, la columna STATUS de la vista v$encryption_wallet mostrará el valor OPEN_NO_MASTER_KEY.

Para comprobar el estado de la clave de cifrado maestra y crear una clave maestra, realice lo siguiente:

1. Revise la columna STATUS en la vista v$encryption_wallet, como se muestra en el siguiente ejemplo:

   
   SQL> alter session set container=pdb2;
   Session altered.
   
   SQL> select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;
   
   WRL_TYPE   WRL_PARAMETER                                   STATUS             WALLET_TYPE
   ---------- ----------------------------------------------- ------------------ -----------
   FILE       /var/opt/oracle/dbaas_acfs/testdb30/tde_wallet/ OPEN_NO_MASTER_KEY AUTOLOGIN

2. Confirme que la PDB está en modo READ WRITE y que no está restringida, como se muestra en el siguiente ejemplo:

   
   SQL> show pdbs
   
   CON_ID CON_NAME     OPEN MODE              RESTRICTED
   ------ ------------ ---------------------- ---------------
   2      PDB$SEED     READ ONLY              NO
   3      PDB1         READ WRITE             NO
   4      PDB2         READ WRITE             NO

   La PDB no puede estar abierta en modo restringido (la columna RESTRICTED debe mostrar NO). Si la PDB está en modo restringido actualmente, revise la información en la vista PDB_PLUG_IN_VIOLATIONS y resuelva la incidencia antes de continuar. Para obtener más información sobre la vista PDB_PLUG_IN_VIOLATIONS y el estado restringido, consulte la Oracle Multitenant Administrator’s Guide sobre la base de datos conectable para su versión de base de datos Oracle.

3. Cree y active una clave de cifrado maestra para la PDB:

   • Defina el contenedor en la PDB:

     ALTER SESSION SET CONTAINER = <pdb>;

   • Para crear y activar una clave de cifrado maestra en la PDB, ejecute el siguiente comando:

     ADMINISTER KEY MANAGEMENT SET KEY USING TAG '<tag>' 
     FORCE KEYSTORE IDENTIFIED BY <keystore-password> WITH BACKUP USING '<backup_identifier>';

   Tenga en cuenta lo siguiente:

   • La cláusula opcional USING TAG se puede utilizar para asociar una etiqueta a la nueva clave de cifrado maestra.

   • La cláusula WITH BACKUP es opcional y se puede utilizar para crear una copia de seguridad del almacén de claves antes de crear la nueva clave de cifrado maestra.

   También puede utilizar los comandos dbaascli, dbaascli tde status y dbaascli tde rotate masterkey para investigar y gestionar las claves.

4. Confirme que el estado de la cartera ha cambiado de OPEN_NO_MASTER_KEY a OPEN consultando la vista v$encryption_wallet como se muestra en el paso 1.

Los parámetros de configuración relacionados con la cartera de TDE pueden provocar fallos en las copias de seguridad.

# ls -altr /var/opt/oracle/dbaas_acfs/<database_name>/tde_wallet/ewallet.p12
total 76
-rw------ 1 oracle oinstall 5467 Oct 1 20:17 ewallet.p12

El archivo de cartera de TDE debe tener permisos de archivo con el valor octal "600" (-rw-------) y el propietario de este archivo debe formar parte del grupo del sistema operativo oinstall.

# ls -altr /var/opt/oracle/dbaas_acfs/<database_name>/tde_wallet/cwallet.sso
total 76
-rw------ 1 oracle oinstall 5512 Oct 1 20:18 cwallet.sso

El archivo de cartera de conexión automática debe tener permisos de archivo con el valor octal "600" (-rw-------), y el propietario de este archivo debe formar parte del grupo del sistema operativo oinstall.

En cada nodo de recursos informáticos asociado a la configuración de Data Guard, recopile archivos log pertenecientes al problema que ha experimentado.

• Archivos log de etapa de activación (como los que documentan la operación de creación de base de datos en espera) y logs del sistema principal o en espera correspondiente.
• Archivos log de ID de trabajo de activación. Por ejemplo: 23.
• Ubicaciones de archivos log de activación por etapa de activación y sistema de Exadata (principal o en espera).
• Archivos log de nombres de base de datos (db_name o db_unique_name, según la ruta del archivo).

Data Guard Deployer (DGdeployer) es el proceso que realiza la configuración. Al configurar la base de datos principal, se crea el archivo /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log.

Este log debe contener la causa raíz de un fallo al configurar la base de datos principal.

• El log principal de la utilidad de línea de comandos dbaasapi es: /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Busque entradas que contengan dg_api.
• Un log en espera de la utilidad de línea de comandos dbaasapi es: /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. En este log, busque entradas que contengan dg_api.
• El otro log en espera es: /var/opt/oracle/log/<dbname>/dgcc/dgcc.log. Este log es el log de configuración de Data Guard.

• El motor de despliegue de Oracle Cloud (ODCE) crea el archivo /var/opt/oracle/log/<dbname>/ocde/ocde.log. Este log debe contener la causa de un fallo al crear la base de datos en espera.
• La utilidad de línea de comandos dbaasapi crea el archivo var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Busque entradas que contengan dg_api.
• El archivo log de configuración de Data Guard es /var/opt/oracle/log/<dbname>/dgcc/dgcc.log.

• DGdeployer es el proceso que realiza la configuración. Crea el siguiente archivo /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log. Este log debe contener la causa raíz de un fallo al configurar la base de datos en espera.
• La utilidad de línea de comandos dbaasapi crea el archivo /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Busque entradas que contengan dg_api.
• El log de configuración de Data Guard es /var/opt/oracle/log/<dbname>/dgcc/dgcc.log.

DGdeployer es el proceso que realiza la configuración. Al configurar Data Guard, crea el archivo /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log. Este log debe contener la causa raíz de un fallo al configurar la base de datos principal.

En cada nodo de los sitios principales y en espera, recopile archivos log para el nombre de base de datos relacionado (db_name).

• Log de alertas de base de datos: /u02/app/oracle/diag/rdbms/<dbname>/<dbinstance>/trace/alert_<dbinstance>.log
• Log de Data Guard Broker: /u02/app/oracle/diag/rdbms/<dbname>/<dbinstance>/trace/drc<dbinstance>.log
• Archivo log de herramientas de nube para Data Guard: /var/opt/oracle/log/<dbname>/odg/odg.log

La contraseña introducida para activar Data Guard no coincide con la contraseña de administrador principal para el usuario SYS. Este error se produce durante la etapa de activación Validar principal.

Puede que la base de datos no esté en ejecución. Este error se produce durante la etapa de activación Validar principal. Compruebe con srvctl y sql en el host para verificar que la base de datos está activa y en ejecución en todos los nodos.

No se ha podido configurar la base de datos principal. Los comandos de Data Guard no válidos o la nueva configuración con fallos del listener pueden provocar este error.

No se ha podido crear la cartera de TDE. No se han podido preparar los archivos del almacén de claves (cartera) de cifrado de datos transparente (TDE) de Oracle para el transporte al sitio en espera. Este error se produce durante la etapa de activación Crear cartera de TDE. Cualquiera de los siguientes elementos puede provocar un fallo en esta etapa:

• No se ha podido acceder a los archivos de cartera de TDE
• Los comandos de activación no han podido crear un archivo que contenga los archivos de cartera

Procedimientos de solución de problemas:

1. Asegúrese de que se puede acceder al cluster. Para comprobar el estado de un cluster, ejecute el siguiente comando:

   crsctl check cluster -all

2. Si el cluster está caído, ejecute el siguiente comando para reiniciarlo:

   crsctl start crs -wait

3. Si este error se produce cuando se puede acceder al cluster, consulte los logs para crear la cartera de TDE (fase de activación) para determinar la causa y la resolución del error.

Es probable que el archivo que contiene la cartera TDE no se transmitiera al sitio en espera. Volver a intentarlo suele resolver el problema.

• Es posible que los sitios principales y en espera no se puedan comunicar entre sí para configurar la base de datos en espera. Estos errores se producen durante la etapa de activación Configurar base de datos en espera. En esta etapa, las configuraciones se realizan en la base de datos en espera, incluido el comando rman duplicate de la base de datos principal. Para resolver esta incidencia:
  1. Verifique el estado de conectividad de los sitios principales y en espera.
  2. Asegúrese de que el host se puede comunicar desde el puerto 1521 con todos los puertos. Compruebe la configuración de red, incluidos los grupos de seguridad de red (NSG), las listas de seguridad de red y la configuración de intercambio de tráfico de VCN remoto (si corresponde). La mejor manera de probar la comunicación entre el host y otros nodos es acceder a las bases de datos mediante SQL*PLUS desde la principal a la en espera y desde la espera a la principal.
• Es posible que las VIP SCAN o los listeners no se estén ejecutando. Utilice la prueba anterior para ayudar a identificar el problema.

Causas posibles:

• Es posible que las VIP SCAN o los listeners no se estén ejecutando. Puede confirmar esta incidencia mediante los siguientes comandos en cualquier nodo de cluster.

  • [grid@exa1-****** ~]$ srvctl status
                scan

  • [grid@exa1-****** ~]$ srvctl status
                  scan_listener

• Tal vez no se pueda acceder a las bases de datos. Puede confirmar este problema intentando conectarse mediante un alias de Oracle Net existente.

Procedimientos de solución de problemas:

1. Como usuario oracle OS, compruebe la existencia de un alias de Oracle Net para la base de datos de contenedor (CDB). Busque un alias en $ORACLE_HOME/network/admin/<dbname>/tnsnames.ora.

   En el siguiente ejemplo, se muestra una entrada para una base de datos de contenedores denominada db12c:

   cat $ORACLE_HOME/network/admin/db12c/tnsnames.ora 
   DB12C = (DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = exa1-*****-scan.********.******.******.com)(PORT = 1521)) 
   (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = db12c.********.******.******.com) 
   (FAILOVER_MODE = (TYPE = select) (METHOD = basic))))

2. Verifique que puede utilizar el alias para conectarse a la base de datos. Por ejemplo, como sysdba, introduzca el siguiente comando:

   sqlplus sys@db12c

Una causa posible de este error es que las contraseñas de usuario sys o system de Oracle Database para la base de datos y la cartera de TDE no sean las mismas. Para comparar las contraseñas:

1. Conéctese a la base de datos como usuario sys y compruebe el estado de TDE en

   V$ENCRYPTION_WALLET

   .
2. Conéctese a la base de datos como usuario system y compruebe el estado de TDE en

   V$ENCRYPTION_WALLET

   .
3. Actualice las contraseñas correspondientes para que coincidan. Inicie sesión en el host del sistema como opc y ejecute los siguientes comandos:
   1. Para cambiar la contraseña SYS:

      sudo dbaascli database changepassword --dbname <database_name>

   2. Para cambiar la contraseña de la cartera de TDE:

      sudo dbaascli tde changepassword --dbname <database_name>

Para conocer las posibles causas y resoluciones de las incidencias de la cartera de TDE, consulte Cartera de TDE y fallos de copia de seguridad.

Cuando se ejecutan los comandos switchover, failover y reinstate, se pueden producir varios mensajes de error. Consulte la documentación de Oracle Database para obtener información sobre estos mensajes de error.

Nota

Oracle recomienda utilizar la interfaz de línea de comandos (dgmgrl) de Data Guard Broker para validar las configuraciones.

1. Como usuario de Oracle, conéctese a la base de datos principal o en espera con dgmgrl y verifique la configuración y la base de datos:

   dgmgrl sys/<pwd>@<database>
   DGMGRL> VALIDATE CONFIGURATION VERBOSE
   DGMGRL> VALIDATE DATABASE VERBOSE <PRIMARY>
   DGMGRL> VALIDATE DATABASE VERBOSE <STANDBY>

2. Consulte la documentación de Oracle Database para consultar el mensaje de error respectivo. Por ejemplo:
   • ORA-16766: la aplicación de redo está parada.
   • ORA-16853: la demora de aplicación ha excedido el umbral especificado.
   • ORA-16664: no se ha podido recibir el resultado de un miembro (para la base de datos en espera).
   • ORA-12541: TNS: no hay listener (para la base de datos principal).

Para conocer la causa y la solución, revise los errores en Mensajes de error de Database.

Logs de DBAASCLI