Solución de fallos de copia de seguridad

Las copias de seguridad de la base de datos pueden fallar por diversos motivos. Normalmente, una copia de seguridad falla porque el host de la base de datos no puede acceder al almacén de objetos o porque hay problemas en el host o con la configuración de la base de datos.

En este artículo se incluye información que ayuda a determinar la causa del fallo y a solucionar el problema. La información se organiza en varias secciones, en función de la condición de error.

Si ya sabe la causa, puede ir al tema con la solución sugerida. De lo contrario, utilice el tema Identificación de la causa del fallo para comenzar.

En este artículo se tratan los siguientes temas:

Sugerencia:

También puede crear conexiones de consola serie para solucionar problemas del sistema en modo de usuario único. Para obtener información sobre la creación de una conexión de consola serie en la consola de OCI, consulte Gestión de conexiones de consola serie al sistema de base de datos.

Temas relacionados

Identificación de la causa del fallo

En la consola de OCI, una copia de seguridad de base de datos con fallos muestra el estado Con fallos o se bloquea en el estado Copia de seguridad en curso o Creando. Si el mensaje de error no contiene suficiente información para sugerirle una solución, puede usar la CLI y los archivos log de la base de datos para recopilar más datos. A continuación, consulte la sección correspondiente de este tema para encontrar una solución.

Se tratan los siguientes temas:

Identificación de la causa raíz del fallo de la copia de seguridad

  1. Conéctese al host como usuario raíz y vaya a /opt/oracle/dcs/bin/.

  2. Determine la secuencia de las operaciones realizadas en la base de datos.

    dbcli list-jobs | grep -i <dbname>

    Anote el último identificador de trabajo mostrado con un estado distinto de Correcto.

  3. Con el identificador de trabajo que ha anotado en el paso anterior, utilice el siguiente comando para comprobar los detalles de ese trabajo:

    dbcli describe-job -i <job_ID> -j

    Normalmente, la ejecución de este comando es suficiente para revelar la causa raíz del fallo.

  4. Si necesita más información, revise el archivo /opt/oracle/dcs/log/dcs-agent.log.

    Para buscar el identificador de trabajo en este archivo, utilice el registro de hora devuelto por el informe de trabajo en el paso 2.

  5. Si los detalles del problema sugieren una incidencia de RMAN, revise los logs de RMAN en el siguiente directorio.

    /opt/oracle/dcs/log/<hostname>/rman/bkup/<db_unique_name>/rman_backup/<yyyy-mm-dd>

Note:

Si el fallo de la base de datos está en una base de datos RAC de 2 nodos, realice los pasos 3 y 4 en ambos nodos.

Incidencias del agente de Database Service

Su base de datos OCI utiliza un marco de agente para que pueda gestionar su base de datos a través de la plataforma en la nube. En ocasiones, puede que necesite reiniciar el programa dcsagent si tiene el estado parada/en espera para resolver un fallo de copia de seguridad.

Se tratan los siguientes temas:

Reinicio del agente de servicio de base de datos

Note:

Utilice initctl en lugar de systemctl al utilizar OL6.

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

    systemctl status initdcsagent

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

    systemctl start initdcsagent

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

    systemctl status initdcsagent

Incidencias de Oracle Clusterware

Oracle Clusterware permite a los servidores comunicarse entre sí para que puedan funcionar como una unidad colectiva. En ocasiones, puede que deba reiniciar el programa Clusterware para resolver un fallo de copia de seguridad.

Una o varias de las siguientes condiciones en el host de la base de datos pueden provocar fallos en las copias de seguridad.

Reinicio de Oracle Clusterware

  1. Desde el símbolo del sistema, compruebe el estado de Oracle Clusterware:

    crsctl check crs
    crsctl stat res -t

  2. Si Oracle Clusterware no está en línea, intente reiniciar el programa:

    crsctl start crs

  3. Compruebe el estado de Oracle Clusterware para confirmar que está en línea:

    crsctl check crs

Incidencias de conectividad del almacén de objetos

Para realizar una copia de seguridad de la base de datos en OCI Object Storage, es necesario que el host pueda conectarse al punto final de Swift aplicable. Puede probar esta conectividad con un usuario de Swift.

Se tratan los siguientes temas:

Cómo asegurarse de que el host de la base de datos se puede conectar almacén de objetos

  1. Cree un usuario de Swift en su arrendamiento. Para obtener más información, consulte Trabajar con tokens de autenticación en Gestión de credenciales de usuario.

  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>
  3. Si no puede conectarse al almacén de objetos, consulte Copia de seguridad de una base de datos mediante la consola para saber cómo configurar la conectividad del almacén de objetos.

Incidencias del host

Se tratan los siguientes temas:

Una o varias de las siguientes condiciones en el host de la base de datos pueden provocar fallos en las copias de seguridad.

Comandos interactivos en el perfil de Oracle

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

El sistema de archivos está lleno

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.

Versión incorrecta del módulo Oracle Database Backup Cloud Service

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 esta incidencia conocida. 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 la actualización más recientes del paquete.

Cambios en el archivo de perfil de ubicación (glogin.sql)

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 OCI. Consulte la sección sobre configuración de SQL*Plus. En concreto, los comandos interactivos pueden producir fallos en las copias de seguridad. Oracle recomienda no modificar este archivo para las bases de datos alojadas en OCI.

Incidencias de la base de datos

Una configuración o estado de la base de datos incorrectos pueden provocar fallos en las copias de seguridad.

Se tratan los siguientes temas:

La base de datos no está en ejecución durante la copia de seguridad

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.

Comprobación de que la base de datos está activa y en ejecución

Utilice el siguiente comando para comprobar el estado de la base de datos y asegúrese de que se resuelven los problemas que pueden haber ocasionado que la base de datos esté en un estado incorrecto:

srvctl status database -d <db_unique_name> -verbose

El sistema devuelve un mensaje que incluye el estado de la instancia de base de datos. El estado de la instancia debe ser Abierto para que la copia de seguridad se realice correctamente. Si la base de datos no se está ejecutando, utilice el comando siguiente para iniciarla: 

srvctl start database -d <db_unique_name> -o open

Si la base de datos está montada pero no tiene el estado Abierto, utilice los siguientes comandos para acceder al símbolo del sistema de SQL*Plus y definir el estado en Abierto: 

sqlplus / as sysdba
alter database open;

Modo de archivado ajustado en NOARCHIVELOG

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.

Comprobación y definición del modo de archivado

Abra un símbolo del sistema de SQL*Plus e introduzca lo siguiente:

select log_mode from v$database;

Si necesita definir el modo de archivado en ARCHIVELOG, inicie la base de datos en el estado Montaje (y no en el estado Abierto) y utilice el siguiente comando en el símbolo del sistema de SQL*Plus: 

alter database archivelog;

Confirme que el parámetro db_recovery_file_dest apunta a +RECO y que el parámetro log_archive_dest_1 está ajustado en USE_DB_RECOVERY_FILE_DEST.

Para las bases de datos RAC, una instancia debe tener el estado Montaje cuando se activa el modo archive log. Para activar el modo archivelog para una base de datos RAC, realice los siguientes pasos:

  1. Cierre todas las instancias de base de datos.

    srvctl stop database -d

  2. Inicie una de las instancias de base de datos en estado MOUNT.

    srvctl start instance -d <db_unique_name> -i <instance_name> -o mount

  3. Acceda al símbolo del sistema de SQL*Plus.

    sqlplus / as sysdba

  4. Active el modo archive log y salga.

    alter database archivelog;
    exit;

  5. Pare la base de datos.

    srvctl stop instance -d <db_unique_name> -i <instance_name>

  6. Reinicie todas las instancias de base de datos.

    srvctl start database -d <db_unqiue_name>

  7. En el símbolo del sistema de SQL*Plus, confirme que el modo de archivado está definido en ARCHIVELOG. 

    select log_mode from v$database;

Proceso de archivador de base de datos parado y fallo de copia de seguridad

Las copias de seguridad pueden fallar cuando la instancia de base de datos tenga un proceso de archivador parado. Por ejemplo, esto puede ocurrir cuando el área de recuperación de flash (FRA) está llena. Puede comprobar esta condición mediante el siguiente comando.

srvctl status database -db <db_unique_name> -v

Si el comando devuelve la siguiente salida, debe resolver la incidencia del proceso de archivador parado para que las copias de seguridad se realicen correctamente:

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.

Después de resolver el proceso parado, el comando debe devolver la siguiente salida:

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 el recurso que está lleno o no está disponible, pruebe con una de las siguientes soluciones alternativas:

  • Reinicie la base de datos utilizando el comando srvctl para actualizar el estado de la base de datos en el clusterware
  • Cambio de versión de la base de datos a los niveles de juego de parches más recientes

Errores de tablespace temporal

Si las estadísticas de tablas fijas no están actualizadas en la base de datos, las copias de seguridad pueden fallar con errores que hacen referencia al tablespace temporal presente en el archivo dcs-agent.log. Por ejemplo: 

select status from v$rman_status where COMMAND_ID=<backup_id>

Salida:

ERROR at line 1:
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP

Para resolver esta incidencia, recopile sus estadísticas de tablas fijas de la siguiente manera.

conn / as sysdba
exec dbms_stats.gather_fixed_objects_stats();

Fallos de copia de seguridad y configuración de RMAN

La edición de determinados parámetros de configuración de RMAN puede producir fallos de copia de seguridad en OCI. 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 parámetros de configuración de RMAN que no se deben modificar para las bases de datos en OCI.

Valores de configuración de RMAN que no se deben modificar

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' MAXPIECESIZE 2 G FORMAT   '%d_%I_%U_%T_%t' PARMS  
    'SBT_LIBRARY=/opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs/libopc.so 
    ENV=(OPC_PFILE=/opt/oracle/dcs/commonstore/objectstore/opc_pfile/1578318329/opc_tiger_iad3c8.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;

Política de retención de RMAN y fallos de copia de seguridad

La configuración de la política de retención de RMAN puede ser el origen de los fallos de copia de seguridad. El uso de la configuración de la política de retención REDUNDANCY en lugar de la política RECOVERY WINDOW puede producir fallos de copia de seguridad. Asegúrese de utilizar la configuración RECOVERY WINDOW OF 30 DAYS.

Configuración del valor de política de retención de RMAN

  1. Busque el identificador de base de datos con el siguiente comando:

    dbcli list-databases

  2. Busque el valor BackupConfigId para la base de datos con el siguiente comando: 

    dbcli describe-database -i <database_id>

  3. Actualice la configuración de la política de retención a RECOVERY WINDOW OF 30 DAYS: 

    dbcli update-backupconfig -i <backup_config_id> --recoverywindow 30

Pérdida del archivo de cartera del almacén de objetos y fallos de copia de seguridad

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.

Confirmación de que el archivo de cartera del almacén de objetos existe y tiene los permisos correctos

  1. Busque el identificador de base de datos con el siguiente comando:

    dbcli list-databases

  2. Busque el valor BackupConfigId para la base de datos con el siguiente comando: 

    dbcli describe-database -i <database_id>

  3. Busque el valor BackupLocation para la base de datos utilizando el siguiente comando: 

    dbcli describe-backupconfig <backup_config_id>

  4. Utilice el siguiente comando para buscar la ruta de archivo de parámetros de configuración de la copia de seguridad (opc_<backup_location_value>_BC.ora): 

    locate opc_<backup_location_value>_BC.ora

    Por ejemplo:

    locate opc_b9naijWMAXzi9example_BC.ora

    Salida:

    /opt/oracle/dcs/commonstore/objectstore/opc_pfile/13aef284-9d6b-4eb6-8751-2988a9example/opc_b9naijWMAXzi9example_BC.ora

  5. Busque la ruta de archivo en el archivo de cartera en el archivo de parámetros de configuración de copia de seguridad inspeccionando el valor almacenado en el parámetro OPC_WALLET. Para ello, vaya al directorio que contiene el archivo de parámetros de configuración de copia de seguridad y utilice el siguiente comando cat: 

    cat <backup_config_parameter_file>

    Por ejemplo:

    cat opc_b9naijWMAXzi9example_BC.ora

    Salida:

    OPC_HOST=https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/dbbackupiad
OPC_WALLET='LOCATION=file:/opt/oracle/dcs/commonstore/objectstore/wallets/13aef284-9d6b-4eb6-8751-2988aexample CREDENTIAL_ALIAS=alias_opc'
OPC_CONTAINER=b9naijWMAXzi9example

  6. Confirme que el archivo cwallet.sso existe en el directorio especificado en el parámetro OPC_WALLET y confirme que el archivo tiene los permisos correctos. Los permisos de archivo deben tener el valor octal "600" (-rw-------). Utilice el comando siguiente: 

    ls -ltr /opt/oracle/dcs/commonstore/objectstore/wallets/<backup_config_id>

    Por ejemplo:

    ls -ltr /opt/oracle/dcs/commonstore/objectstore/wallets/13aef284-9d6b-4eb6-8751-2988aexample

    Salida:

    total 4
-rw------- 1 oracle oinstall    0 Apr 20 06:45 cwallet.sso.lck
-rw------- 1 oracle oinstall 1941 Apr 20 06:45 cwallet.sso

Incidencias de la cartera de TDE

Se tratan los siguientes temas:

Especificación de ubicación de cartera de TDE incorrecta

Para que las operaciones de copia de seguridad funcionen, el archivo $ORACLE_HOME/network/admin/sqlnet.ora debe contener el parámetro ENCRYPTION_WALLET_LOCATION con el siguiente formato: 

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))

Note:

En esta entrada de ubicación de cartera, $ORACLE_UNQNAME es una variable de entorno y no se debe sustituir por un valor real.

Comprobación de la especificación de ubicación de cartera de TDE

Utilice el comando cat para comprobar la especificación de ubicación de cartera de TDE. Por ejemplo: 

cat $ORACLE_HOME/network/admin/sqlnet.ora

Salida:

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))

No se ha definido la variable de entorno ORACLE_UNQNAME al iniciar la base de datos con SQL*Plus

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.

Para solucionar el problema, inicie la base de datos con la utilidad srvctl: 

srvctl start database -d <db_unique_name>

La base de datos conectable se ha agregado con una clave de cifrado maestra configurada incorrectamente

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. Esta clave de cifrado se almacena en un único almacén de claves utilizado por todos los contenedores. 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: 

    alter session set container=pdb2;
    select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;

    Salida:

    WRL_TYPE  WRL_PARAMETER                                           STATUS             WALLET_TYPE
--------- ------------------------------------------------------- ------------------ -----------
FILE      /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/ 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:

    show pdbs

    Salida:

    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 documentación sobre la base de datos conectable para su versión de Oracle Database.

  3. Ejecute los siguientes comandos DBCLI para cambiar el estado a OPEN: 

    sudo su –
    dbcli list-database
    dbcli update-tdekey -i <database_ID> -n <PDB_name> -p

    El comando update-tdekey que se muestra le solicitará la contraseña del administrador.

  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.

Comprobación de la configuración relacionada con la cartera de TDE

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

  1. Compruebe que el parámetro de nombre único (ORACLE_UNQNAME) de la base de datos del entorno está configurado correctamente mediante el siguiente comando:

    srvctl getenv database -d <db_unique_name>

    Por ejemplo:

    srvctl getenv database -d orclbkp_iadxyz

    Salida:

    orclbkp_iadxyz:
ORACLE_UNQNAME=orclbkp_iadxyz
TZ=UTC

  2. Compruebe la configuración de sqlnet.ora para confirmar que el archivo tiene un parámetro ENCRYPTION_WALLET_LOCATION con el valor DIRECTORY correcto. Utilice el comando siguiente: 

    cat $ORACLE_HOME/network/admin/sqlnet.ora

    Por ejemplo:

    cat $ORACLE_HOME/network/admin/sqlnet.ora

    Salida:

    ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))

  3. Confirme que el estado de la cartera es abierto y que el tipo de cartera es de conexión automática comprobando la vista v$encryption_wallet. Por ejemplo: 

    select status, wrl_parameter,wallet_type from v$encryption_wallet;

    Salida:

    STATUS  WRL_PARAMETER                                            WALLET_TYPE
------- -------------------------------------------------------- ------------
OPEN    /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/  AUTOLOGIN

    Para bases de datos conectables (PDB), asegúrese de cambiar al contenedor adecuado antes de consultar la vista v$encryption_wallet. Por ejemplo: 

    sqlplus / as sysdba
    alter session set container=pdb1;
    select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;

    Salida:

    WRL_TYPE  WRL_PARAMETER                                          STATUS  WALLET_TYPE
--------- ------------------------------------------------------ ------- ------------
FILE      /opt/oracle/dcs/commonstore/wallets/tde/tiger_iad3c8/  OPEN    AUTOLOGIN

Archivo de cartera de TDE ausente

El archivo de cartera de TDE (ewallet.p12) puede hacer que las copias de seguridad fallen si falta, o si los permisos o la propiedad del sistema de archivos no son compatibles. Compruebe el archivo como se muestra en el siguiente ejemplo: 

ls -ltr /opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME/ewallet.p12

Salida:

-rwx------ 1 oracle oinstall 5680 Apr 18 13:09 /opt/oracle/dcs/commonstore/wallets/tde/orclbkp_iadxzy/ewallet.p12

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

Archivo de cartera de conexión automática ausente

El archivo de cartera de inicio de sesión automático (cwallet.sso) puede hacer que las copias de seguridad fallen si falta, o si los permisos o la propiedad del sistema de archivos no son compatibles. Compruebe el archivo como se muestra en el siguiente ejemplo: 

ls -ltr /opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME/cwallet.sso

Salida:

-rwx------ 1 oracle oinstall 5725 Apr 18 13:09 /opt/oracle/dcs/commonstore/wallets/tde/orclbkp_iadxyz/cwallet.sso

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

Otras causas de fallo de copia de seguridad

Se tratan los siguientes temas:

Punto de montaje de Commonstore no montado

El punto de montaje /opt/oracle/dcs/commonstore debe estar montado; de lo contrario, fallarán las copias de seguridad.

Comprobación del punto de montaje de Commonstore

Confirme que el punto de montaje /opt/oracle/dcs/commonstore está montado, como se muestra en el siguiente ejemplo: 

srvctl config filesystem -volume commonstore -diskgroup data

Salida:

Volume device: /dev/asm/commonstore-5
Diskgroup name: data
Volume name: commonstore
Canonical volume device: /dev/asm/commonstore-5
Accelerator volume devices:
Mountpoint path: /opt/oracle/dcs/commonstore
Mount point owner: oracle
Mount users:
Type: ACFS

Confirme que ora.data.commonstore.acfs está en línea

  1. El estado de ora.data.commonstore.acfs debe ser en línea, de lo contario, fallarán las copias de seguridad. Confírmelo como se muestra en el siguiente ejemplo: 

    crsctl stat resource ora.data.commonstore.acfs -v

    Salida:

    NAME=ora.data.commonstore.acfs
TYPE=ora.acfs.type
LAST_SERVER=orcl
STATE=OFFLINE
TARGET=OFFLINE
...
STATE_DETAILS=admin unmounted /opt/oracle/dcs/commonstore
...

  2. Muestre el contenido del directorio commonstore para confirmar que está montado 

    ls -ltr /opt/oracle/dcs/commonstore

  3. Si el valor de STATE_DETAILS es unmounted, monte el sistema de archivos como se muestra en el siguiente ejemplo: 

    srvctl start filesystem -volume commonstore -diskgroup data

  4. Confirme que el cambio se ha realizado correctamente, como se muestra en el siguiente ejemplo:

    crsctl stat resource ora.data.commonstore.acfs -v

    Salida:

    NAME=ora.data.commonstore.acfs
TYPE=ora.acfs.type
LAST_SERVER=orcl
STATE=ONLINE on orcl
TARGET=ONLINE
CARDINALITY_ID=ONLINE
...
STATE_DETAILS=mounted on /opt/oracle/dcs/commonstore

  5. Muestre el contenido del directorio commonstore para confirmar que está montado, como se muestra en el siguiente ejemplo: 

    ls -ltr /opt/oracle/dcs/commonstore

    Salida:

    total 220
drwx------ 2 root   root     65536 Apr 18 10:50 lost+found
drwx------ 3 oracle oinstall 20480 Apr 18 11:02 wallets
drwxr-xr-x 3 root   root     20480 Apr 20 06:41 pkgrepos
drwxr-xr-x 4 oracle oinstall 20480 Apr 20 06:41 objectstore

La base de datos no se ha registrado correctamente

Las copias de seguridad de la base de datos fallan si la base de datos no está registrada con dcs-agent. Este escenario se puede producir si migra manualmente la base de datos a OCI y no ejecuta el comando dbcli register-database.

Para comprobar si la base de datos está registrada correctamente, revise la información devuelta ejecutando el comando srvctl config database y el comando dbcli list-databases. Si alguno de los comandos no devuelve un registro de la base de datos, póngase en contacto con los Servicios de Soporte Oracle.

Para obtener instrucciones sobre cómo registrar la base de datos, consulte los siguientes temas:

Obtención de ayuda adicional

Si no ha podido resolver el problema con la información de este tema, siga los procedimientos siguientes para recopilar la información de diagnóstico y de bases de datos relevante. Después de recopilar esta información, póngase en contacto con los Servicios de Soporte Oracle.

Se tratan los siguientes temas:

Recopilación de información de la base de datos para su uso en informes de problemas

Utilice los siguientes comandos para recopilar detalles sobre la base de datos. Registre la salida de cada comando como referencia:

dbcli list-databases
dbcli describe-database -i <database_id>
dbcli describe-component

Recopilación de información de diagnóstico sobre los trabajos fallidos

  1. Conéctese al host como usuario root y vaya al directorio /opt/oracle/dcs/bin/.

  2. Ejecute los dos comandos siguientes para generar información sobre el trabajo fallido:

    dbcli list-jobs
    dbcli describe-job -i <job_ID> -j

    El <job_ID> del segundo comando debe ser el identificador del trabajo fallido más reciente notificado del primer comando.

  3. Ejecute el script del recopilador de diagnósticos para crear un archivo zip con la información de diagnóstico para los Servicios de Soporte Oracle.

    diagcollector.py

    Este comando crea un archivo denominado diagLogs -<timestamp>.zip en el directorio /tmp.

Recopilación de los archivos log del agente DCS

Para recopilar los archivos log del agente DCS, realice lo siguiente:

  1. Conéctese como usuario opc.

  2. Ejecute el siguiente comando:

    sudo /opt/oracle/dcs/bin/diagcollector.py

    El sistema devuelve un mensaje que indica que hay logs de agente disponibles en un archivo zip de un directorio específico. Por ejemplo:

    Logs are being collected to: /tmp/dcsdiag/diagLogs-1234567890.zip

Recopilación de detalles de configuración de TDE

  1. Ejecute el comando srvctl getenv database -d <db_unique_name> y registre la salida como referencia.

  2. Registre la salida de la vista v$encryption_wallet. Por ejemplo: 

    select status, wrl_parameter,wallet_type from v$encryption_wallet;

    Salida:

    STATUS   WRL_PARAMETER                                           WALLET_TYPE
-------- ------------------------------------------------------- ---------
OPEN     /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/ AUTOLOGIN

  3. Registre la salida del comando ls -ltr <wrl_parameter>. Por ejemplo: 

    ls -ltr /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/

    Salida:

    total 28
-rw----- 1 oracle asmadmin 2400 May  2 09:42 ewallet_2018050209420381_defaultTag.p12
-rw----- 1 oracle asmadmin 5680 May  2 09:42 ewallet.p12
-rw----- 1 oracle asmadmin 5723 May  2 09:42 cwallet.sso

Recopilación del archivo de informe de copia de seguridad de RMAN

Genere el archivo de informe de copia de seguridad de RMAN mediante el siguiente comando: 

dbcli create-rmanbackupreport -i <db_id> -w detailed -rn <report_name>

Por ejemplo:

dbcli create-rmanbackupreport -i 57fvwxyz-9dc4-45d3-876b-5f850example -w detailed -rn bkpreport1

Localice el archivo de informe mediante el comando dbcli describe-rmanbackupreport -in <report_name>. La ubicación del informe se proporciona en la salida. Por ejemplo: 

dbcli describe-rmanbackupreport -in bkpreport1

Salida:

Backup Report details                                           
----------------------------------------------------------------
ID: b55vwxyz-c49f-4af3-a956-acccdexample
Report Type: detailed
Location: Node patchtst: /opt/oracle/dcs/log/patchtst/rman/bkup/example_iadxyz/rman_list_backup_detail
    /2018-05-02/rman_list_backup_detail_2018-05-02_11-46-51.0359.log
Database ID: 57fvwxyz-9dc4-45d3-876b-5f850example
CreatedTime: May 2, 2018 11:46:38 AM UTC