Problemas conocidos

Detalles: en la Supervisión sintética, es posible que las supervisiones de tipo Explorador y Explorador con scripts no se ejecuten en aplicaciones que utilicen marcos.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. En las supervisiones de tipo Explorador con scripts, puede solucionar esta incidencia sustituyendo index=<frame-index> por id=<id-of-frame> o name=<name-of-frame> en el script .side.

Por ejemplo, si este script es la versión original:

{
      "id": "23956f51-8812-40e6-ac91-1d608871ee4c",
      "comment": "",
      "command": "selectFrame",
      "target": "index=0",
      "targets": [
        ["index=0"]
      ],
      "value": ""
    }

El siguiente script sería la versión modificada:

{
      "id": "23956f51-8812-40e6-ac91-1d608871ee4c",
      "comment": "",
      "command": "selectFrame",
      "target": "id=frame1",
      "targets": [
        ["id=frame1"]
      ],
      "value": ""
    }

Enlace directo a esta incidencia: es posible que los supervisores de tipo Explorador y Explorador con scripts no ejecuten aplicaciones que utilicen marcos

Detalles: las políticas de autorización basadas en las etiquetas de recursos apm-domains no funcionan para las API del explorador de rastreo y la supervisión sintética, lo que provoca fallos de autorización.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo.

Enlace directo a esta incidencia: Incidencias con las políticas de autorización basadas en las etiquetas de recurso apm-domains

Detalles: cuando intenta activar la replicación entre regiones para un volumen configurado para utilizar una clave de cifrado de Vault, se genera el siguiente mensaje de error: Edit Volume Error: You cannot enable cross-region replication for volume <volume_ID> as it uses a Vault encryption key.

Solución alternativa: estamos intentando solucionar este problema. La replicación entre regiones no está soportada para volúmenes cifrados con una clave gestionada por el cliente. Como solución alternativa para activar la replicación, anule la asignación de la clave de cifrado de Vault al volumen. En este escenario, el volumen se cifra con una clave gestionada por Oracle.

Enlace directo a esta incidencia: La replicación entre regiones no está soportada para volúmenes cifrados con claves gestionadas por el cliente

Detalles: para lograr el nivel de rendimiento óptimo para los volúmenes configurados para un rendimiento ultra alto, la asociación de volúmenes debe estar activada para rutas múltiples. Las asociaciones activadas para rutas múltiples a instancias de máquina virtual solo están soportadas para instancias basadas en unidades con 16 o más OCPU.

Si tiene una instancia con menos de 16 OCPU, puede cambiar su tamaño para que tenga 16 o más OCPU y que pueda soportar asociaciones con rutas múltiples activadas. Este paso no funcionará en instancias en las que el número original de OCPU sea inferior a 8 y la asociación de volúmenes esté paravirtualizada. En este escenario, después de desasociar y volver a asociar el volumen, la asociación de volumen aún no estará activada para rutas múltiples aunque la instancia ahora soporte asociaciones activadas para rutas múltiples.

Solución alternativa: como solución alternativa, le recomendamos que cree una nueva instancia basada en una unidad con 16 o más OCPU y, a continuación, asocie el volumen a la nueva instancia.

Enlace directo a este problema: La asociación de volumen paravirtualizada no está activada para rutas múltiples después de cambiar el tamaño de la instancia

Detalles: si se intenta asociar el número máximo de volúmenes en bloque a una instancia VM.Standard.A1.Flex más pequeña, es posible que en algunos casos los volúmenes no se puedan asociar. Esto sucede debido a las limitaciones con la configuración del host físico subyacente.

Solución alternativa: estamos intentando solucionar este problema. Como solución alternativa, le recomendamos que aumente el tamaño de la máquina virtual cambiando el tamaño de la máquina virtual y, a continuación, intente volver a asociar los volúmenes.

Enlace directo a esta incidencia: Es posible que falle la asociación del número máximo de volúmenes en bloque a instancias de VM.Standard.A1.Flex

Detalles: cuando se programan copias de seguridad de volumen y grupo de volúmenes mediante una política de copia de seguridad que está activada para la copia entre regiones para volúmenes cifrados mediante claves de cifrado del servicio Vault, las claves de cifrado no se copian con la copia de seguridad de volumen en la región de destino. Las copias de seguridad de volumen de la región de destino se cifran con claves proporcionadas por Oracle.

Solución alternativa: estamos intentando solucionar este problema. Como solución alternativa, puede copiar manualmente copias de seguridad de volumen y grupo de volúmenes entre regiones, ya sea manualmente o mediante un script, y especificar el identificador de clave de gestión de claves en la región de destino para la operación de copia. Para obtener más información sobre la copia manual entre regiones, consulte Duplicado de una copia de seguridad de volumen entre regiones.

Enlace directo a este problema: Las claves de cifrado del almacén no se han copiado en la región de destino para las copias de seguridad entre regiones programadas

Details: When you attach a Windows boot volume as a data volume to another instance, when you try to connect to the volume using the steps described in Connecting to a Block Volume the volume fails to attach and you may encounter the following error:

Connect-IscsiTarget : The target has already been logged in via an iSCSI session.

Solución alternativa: debe agregar lo siguiente al comando Connect-IscsiTarget copiado de la consola:

-IsMultipathEnabled $True

Enlace directo a este problema: Fallo al asociar un volumen de inicio de Windows como volumen de datos a otra instancia

Detalles: cuando se llama a GetInstance, el atributo bootVolumeSizeInGBs de InstanceSourceViaImageDetails es nulo.

Solución alternativa: estamos intentando solucionar este problema. Para resolver este problema, llame a GetBootVolume y utilice el atributo sizeInGBs de BootVolume.

Enlace directo a este problema: El atributo bootVolumeSizeInGBs es nulo

Detalles: al intentar acceder a la Consola mediante Firefox, la página Consola no se carga en el explorador. Es probable que este problema se deba a un perfil de usuario de Firefox dañado.

Solución alternativa: cree un nuevo perfil de usuario de Firefox de la siguiente manera:

1. Asegúrese de usar la versión más reciente de Firefox. Si no es así, actualice a la última versión.
2. Cree un nuevo perfil de usuario y elimine el antiguo. Consulte la Ayuda de Mozilla para obtener instrucciones sobre cómo crear y eliminar perfiles de usuario: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles.
3. Abra Firefox con el nuevo perfil.

También puede utilizar uno de los otros exploradores soportados.

Enlace directo a este problema: El bug del explorador de Firefox puede hacer que la Consola no se cargue

Detalles: las PDB existentes no aparecen en una base de datos recién creada y pueden tardar unas horas en aparecer en la consola. Esto incluye la PDB por defecto de una nueva base de datos y las PDB existentes de las bases de datos clonadas o restauradas. En caso de una restauración in situ a una versión anterior, la lista de PDB se actualiza de manera similar y puede tener algún retraso.

Solución alternativa: ninguna

Enlace directo a esta incidencia: PDB existentes en una nueva base de datos

Detalles: no se permite crear ni clonar una PDB en la base de datos primaria mediante la consola o la API.

Solución alternativa: puede utilizar sqlplus para crear o clonar las PDB en la base de datos primaria y estas se sincronizarán más tarde en la consola de OCI.

Enlace directo a esta incidencia: PDB en la configuración existente de Data Guard

Detalles: se produce un fallo al usar la API del servicio Database para migrar una cartera de TDE basada en archivos a una cartera de TDE basada en claves y gestionada por el cliente en Oracle Database 12c versión 1 (12.1.0.2) con el siguiente error:

[FATAL] [DBAAS-11014]: los parches necesarios (30128047) no están presentes en el directorio raíz de Oracle <ORACLE_HOME>
ACCIÓN: aplique los parches necesarios (30128047) y vuelva a intentar la operación

nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

En el comando anterior, <kms_key_ocid> hace referencia al OCID de la clave gestionada por el cliente que está utilizando.

Detalles: se produce un fallo al usar la API del servicio Database para migrar una cartera de TDE basada en claves y gestionada por el cliente a una cartera de TDE basada en archivos en Oracle Database 12c versión 1 (12.1.0.2) con el siguiente error:

[FATAL] [DBAAS-11014]: los parches necesarios (30128047) no están presentes en el directorio raíz de Oracle <ORACLE_HOME>
ACCIÓN: aplique los parches necesarios (30128047) y vuelva a intentar la operación

nohup /var/opt/oracle/dbaascli/dbaascli tde hsm_to_file --dbname <database_name> --skip_patch_check true &

Detalles: se produce un fallo al usar la API del servicio Database para migrar una cartera de TDE basada en archivos a una cartera de TDE basada en claves y gestionada por el cliente en Oracle Database 12c versión 2 (12.2.0.1) con el siguiente error:

[FATAL] [DBAAS-11014]: los parches necesarios (30128047) no están presentes en el directorio raíz de Oracle <ORACLE_HOME>
ACCIÓN: aplique los parches necesarios (30128047) y vuelva a intentar la operación

Solución alternativa: migre una cartera de TDE basada en archivos a una cartera de TDE basada en claves y gestionada por el cliente de la siguiente forma:

1. Determine si la base de datos ha cifrado los tablespaces UNDO o TEMP en cualquiera de las instancias de Autonomous Database o en CDB$ROOT de la siguiente forma:
   Ejecute la siguiente consulta de CDB$ROOT para mostrar todos los tablespaces cifrados incluidos en todas las instancias de Autonomous Database:

   SQL> select tstab.con_id, tstab.name from v$tablespace tstab, v$encrypted_tablespaces enctstab where tstab.ts# = enctstab.ts# and encryptedts = 'YES';

   En la columna NAME del resultado de la consulta, busque los nombres de los tablespaces UNDO y TEMP. Si hay tablespaces UNDO o TEMP cifrados, continúe con el siguiente paso.

2. Descifre los tablespaces UNDO o TEMP de la siguiente forma:

   Si un tablespace UNDO está cifrado

   Descifre los tablespaces UNDO existentes de la siguiente forma:

   SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

   Repita este procedimiento para todos los tablespaces UNDO cifrados.

   Si un tablespace TEMP está cifrado

   1. Compruebe el tablespace TEMP por defecto de la siguiente forma:

      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';

      Si el tablespace TEMP por defecto no está cifrado pero hay otros tablespaces TEMP cifrados, borre los demás tablespaces TEMP de la siguiente forma:

      SQL> drop tablespace <temp_tablespace_name>;

      Omita el resto de los pasos de este procedimiento.

      Si el tablespace TEMP por defecto está cifrado, continúe con los pasos restantes para crear y definir un tablespace TEMP por defecto no cifrado.

   2. Defina el parámetro encrypt_new_tablespaces en DDL de la siguiente forma:

      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;

   3. Cree un tablespace TEMP con las especificaciones del tablespace TEMP actual de la siguiente forma:

      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;

   4. Defina el nuevo tablespace TEMP como tablespace TEMP por defecto para la base de datos de la siguiente forma:

      SQL> alter database default temporary tablespace <temp_tablespace_name>;

   5. Borre los tablespaces TEMP existentes de la siguiente forma:

      SQL> drop tablespace <temp_tablespace_name>;

   Repita este procedimiento para todos los tablespaces TEMP cifrados.

   La base de datos se está ejecutando ahora con los tablespaces TEMP y UNDO por defecto que no están cifrados y también se descifran todos los tablespaces TEMP y UNDO más antiguos.

   Defina encrypt_new_tablespaces en su valor original de la siguiente forma:

   SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

   Continúe con la migración del almacén de claves a claves gestionadas por el cliente.

3. Una vez que haya confirmado que no hay ningún tablespace UNDO o TEMP cifrado en ninguna de las bases de datos conectables o en CDB$ROOT, use la utilidad DBAASCLI con el indicador --skip_patch_check true para omitir la validación del parche para el bug 30128047. Asegúrese de que ha aplicado el parche para el bug 31527103 en el directorio raíz de Oracle y, a continuación, ejecute el siguiente comando dbaascli:

   nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

   En el comando anterior, <kms_key_ocid> hace referencia al OCID de la clave gestionada por el cliente que está utilizando.

Detalles: se produce un fallo al usar la API del servicio Database para migrar una cartera de TDE basada en claves y gestionada por el cliente a una cartera de TDE basada en archivos en Oracle Database 12c versión 2 (12.2.0.1) con el siguiente error:

[FATAL] [DBAAS-11014]: los parches necesarios (30128047) no están presentes en el directorio raíz de Oracle <ORACLE_HOME>
ACCIÓN: aplique los parches necesarios (30128047) y vuelva a intentar la operación

Solución alternativa: migre una cartera de TDE basada en claves y gestionada por el cliente a una cartera de TDE basada en archivos de la siguiente forma:

1. Determine si la base de datos ha cifrado los tablespaces UNDO o TEMP en cualquiera de las instancias de Autonomous Database o en CDB$ROOT de la siguiente forma:
   Ejecute la siguiente consulta de CDB$ROOT para mostrar todos los tablespaces cifrados incluidos en todas las instancias de Autonomous Database:

   SQL> select tstab.con_id, tstab.name from v$tablespace tstab, v$encrypted_tablespaces enctstab where tstab.ts# = enctstab.ts# and encryptedts = 'YES';

   En la columna NAME del resultado de la consulta, busque los nombres de los tablespaces UNDO y TEMP. Si hay tablespaces UNDO o TEMP cifrados, continúe con el siguiente paso.

2. Descifre los tablespaces UNDO o TEMP de la siguiente forma:

   Si un tablespace UNDO está cifrado

   Descifre los tablespaces UNDO existentes de la siguiente forma:

   SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

   Repita este procedimiento para todos los tablespaces UNDO cifrados.

   Si un tablespace TEMP está cifrado

   1. Compruebe el tablespace TEMP por defecto de la siguiente forma:

      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';

      Si el tablespace TEMP por defecto no está cifrado pero hay otros tablespaces TEMP cifrados, borre los demás tablespaces TEMP de la siguiente forma:

      SQL> drop tablespace <temp_tablespace_name>;

      Omita el resto de los pasos de este procedimiento.

      Si el tablespace TEMP por defecto está cifrado, continúe con los pasos restantes para crear y definir un tablespace TEMP por defecto no cifrado.

   2. Defina el parámetro encrypt_new_tablespaces en DDL de la siguiente forma:

      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;

   3. Cree un tablespace TEMP con las especificaciones del tablespace TEMP actual de la siguiente forma:

      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;

   4. Defina el nuevo tablespace TEMP como tablespace TEMP por defecto para la base de datos de la siguiente forma:

      SQL> alter database default temporary tablespace <temp_tablespace_name>;

   5. Borre los tablespaces TEMP existentes de la siguiente forma:

      SQL> drop tablespace <temp_tablespace_name>;

   Repita este procedimiento para todos los tablespaces TEMP cifrados.

   La base de datos se está ejecutando ahora con los tablespaces TEMP y UNDO por defecto que no están cifrados y también se descifran todos los tablespaces TEMP y UNDO más antiguos.

   Defina encrypt_new_tablespaces en su valor original de la siguiente forma:

   SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

   Continúe con la migración del almacén de claves a claves gestionadas por el cliente.

3. Una vez que haya confirmado que no hay ningún tablespace UNDO o TEMP cifrado en ninguna de las bases de datos conectables o en CDB$ROOT, use la utilidad DBAASCLI con el indicador --skip_patch_check true para omitir la validación del parche para el bug 30128047. Asegúrese de que ha aplicado el parche para el bug 29667994 en el directorio raíz de Oracle y, a continuación, ejecute el siguiente comando dbaascli:

   nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

   En el comando anterior, <kms_key_ocid> hace referencia al OCID de la clave gestionada por el cliente que está utilizando.

Detalles: al cambiar el tipo de licencia del sistema de base de datos o de Database de BYOL a una licencia incluida o viceversa, se le facturarán ambos tipos de licencias durante la primera hora. Después, se le facturará según el tipo de licencia actualizado.

Solución alternativa: estamos intentando solucionar este problema.

Enlace directo a esta incidencia: Incidencia de facturación al cambiar el tipo de licencia

Detalles: si configura la red virtual en la nube con gateway de servicio, la subred privada bloquea el acceso a los repositorios de YUM necesarios para actualizar el sistema operativo. Este problema afecta a todos los tipos de sistemas de base de datos.

Solución alternativa: este problema ya está resuelto. Esta es la solución alternativa recomendada antes de la resolución del problema:

El gateway de servicio permite acceder a los repositorios de Oracle YUM si utiliza las etiquetas CIDR de servicio disponibles denominadas Todos los servicios de <region> de Oracle Services Network. Sin embargo, puede haber problemas al acceder a los servicios de YUM a través del gateway de servicios. Hay una solución para la incidencia. Para obtener más información, consulte la sección sobre incidencias de acceso de instancias a servicios de Oracle yum a través del gateway de servicio.

Enlace directo a este problema: El gateway de servicio no admite las actualizaciones del sistema operativo

Detalles: las copias de seguridad no gestionadas en el almacenamiento de objetos realizadas mediante la CLI (dbcli) de la base de datos o RMAN fallan con los siguientes errores:

-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error

En respuesta a las políticas implementadas por dos exploradores web comunes con respecto a certificados de Symantec, Oracle ha cambiado recientemente la autoridad de certificación utilizada para Oracle Cloud Infrastructure. El cambio resultante en los certificados de capa de conexión segura puede hacer que las copias de seguridad en el almacenamiento de objetos fallen si el módulo Oracle Database Cloud Backup sigue apuntando al certificado anterior.

Solución alternativa para dbcli: compruebe que los archivos log no contengan los errores enumerados y, si los hay, actualice el módulo de copia de seguridad.

Revise los archivos log de copia de seguridad de RMAN para comprobar si aparecen los errores mostrados anteriormente:

1. Determine el ID del trabajo de copia de seguridad fallido.

   dbcli list-jobs

   En este resultado de ejemplo, el ID de trabajo de copia de seguridad con fallos es "f59d8470-6c37-49e4-a372-4788c984ea59".

   root@<node name> ~]# dbcli list-jobs
    
   ID                                       Description                                                                 Created                             Status
   ---------------------------------------- --------------------------------------------------------------------------- ----------------------------------- ----------
   cbe852de-c0f3-4807-85e8-7523647ec78c     Authentication key update for DCS_ADMIN                                     March 30, 2018 4:10:21 AM UTC       Success
   db83fdc4-5245-4307-88a7-178f8a0efa48     Provisioning service creation                                               March 30, 2018 4:12:01 AM UTC       Success
   c1511a7a-3c2e-4e42-9520-f156b1b4cf0e     SSH keys update                                                             March 30, 2018 4:48:24 AM UTC       Success
   22adf146-9779-4a2c-8682-7fd04d7520b2     SSH key delete                                                              March 30, 2018 4:50:02 AM UTC       Success
   6f2be750-9823-4ed5-b5ff-8e49f136dd22     create object store:bV0wqIaoLA4xLT4dGjOu                                    March 30, 2018 5:33:38 AM UTC       Success
   0716f464-1a10-40df-a303-cadee0302b1b     create backup config:bV0wqIaoLA4xLT4dGjOu_BC                                March 30, 2018 5:33:49 AM UTC       Success
   e08b21c3-cd09-4e3a-944c-d1da96cb21d8     update database : hfdb1                                                     March 30, 2018 5:34:04 AM UTC       Success
   1c3d7c58-79c3-4039-8f48-787057ce7c6e     Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname>    March 30, 2018 5:37:11 AM UTC       Success
   f59d8470-6c37-49e4-a372-4788c984ea59     Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname>    March 30, 2018 5:43:45 AM UTC       Failure

2. Utilice el ID del trabajo fallido para obtener la ubicación del archivo log que se va a revisar.

   
   dbcli describe-job -i <failed_job_ID>

   El resultado relevante del comando describe-job debería ser similar al siguiente:

   Message: DCS-10001:Internal error encountered: Failed to run Rman statement.
   Refer log in Node <node_name>: /opt/oracle/dcs/log/<node_name>/rman/bkup/<db_unique_name>/rman_backup/<date>/rman_backup_<date>.log.

Actualice el módulo de Oracle Database Cloud Backup:

1. Determine el ID de almacén de objetos Swift y el usuario que utiliza la base de datos para las copias de seguridad.

   1. Ejecute el comando dbcli list-databases para determinar el ID de la base de datos.

   2. Utilice el ID de base de datos para determinar el ID de configuración de copia de seguridad (backupConfigId).

      dbcli list-databases
      dbcli describe-database -i <database_ID> -j

   3. Mediante el ID de configuración de copia de seguridad indicado en el paso anterior, determine el ID del almacén de objetos (objectStoreId).

      dbcli list-backupconfigs
      dbcli describe-backupconfig –i <backupconfig_ID> -j

   4. Mediante el ID del almacén de objetos indicado en el paso anterior, determine el usuario del almacén de objetos (userName).

      dbcli list-objectstoreswifts
      dbcli describe-objectstoreswift –i <objectstore_ID> -j

2. Con las credenciales del almacén de objetos obtenidas en el paso 1, actualice el módulo de copia de seguridad.

   dbcli update-objectstoreswift –i <objectstore_ID> -p –u <user_name>

Solución alternativa para RMAN: compruebe los archivos log de RMAN para ver los mensajes de error mostrados. Si la encuentra, conéctese al host como usuario oracle y utilice las credenciales de Swift para volver a instalar el módulo de copia de seguridad.

java -jar <opc_install.jar_path> -opcId '<swift_user_ID>' -opcPass '<auth_token>' -container <objectstore_container> -walletDir <wallet_directory> -configfile <config_file> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -import-all-trustcerts

Para un sistema de base de datos de varios nodos, realice la solución alternativa en todos los nodos de la agrupación.

Consulte la documentación del módulo Oracle Database Cloud Backup para obtener más información sobre el uso de este comando.

Enlace directo a este problema: Fallo al realizar una copia de seguridad en el almacenamiento de objetos mediante dbcli o RMAN debido a un cambio de certificado

Detalles: los SDK publicados el 18 de octubre de 2018 introducen nuevos cambios en el tamaño de la base de datos y los atributos de edición de la base de datos en las API de copia de seguridad de la base de datos.

Solución alternativa: consulte la siguiente documentación específica de idioma para obtener más información sobre los nuevos cambios y actualice el código existente según corresponda:

Enlace directo a este problema: Nuevos cambios en los SDK de servicio de base de datos

Detalles: es posible que las operaciones de copia de seguridad y restauración no funcionen en su sistema de base de datos al usar la consola o la API.

Solución alternativa: instale el módulo de Oracle Database Cloud Backup y, a continuación, póngase en contacto con los Servicios de soporte Oracle para obtener más instrucciones.

Para instalar el módulo de Oracle Database Cloud Backup:

1. Establezca una conexión de shell seguro con el sistema de base de datos e inicie sesión como opc.

   
   ssh -i <SSH_key> opc@<DB_system_IP address>
   login as: opc

   También puede utilizar opc@<DB_system_hostname> para iniciar sesión.

2. Descargue el módulo de Oracle Database Cloud Backup de http://www.oracle.com/technetwork/database/availability/oracle-cloud-backup-2162729.html.
3. Extraiga el contenido de opc_installer.zip a un directorio de destino, por ejemplo, /home/opc.
4. En su arrendamiento, cree un usuario temporal y concédale privilegios para acceder al almacenamiento de objetos del arrendamiento.
5. Para este usuario temporal, cree un token de autenticación y anote la contraseña.

6. Verifique que las credenciales funcionan al ejecutar el siguiente comando curl:

   Nota
   
   Las contraseñas de Swift ahora se denominan "tokens de autenticación". Para obtener más información, consulte Uso de un token de autenticación con Swift.

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

   Consulte https://cloud.oracle.com/infrastructure/storage/object-storage/faq para conocer la región correcta que se va a utilizar.

   El comando debe devolver el código de respuesta del estado correcto de HTTP 200 o HTTP 204 No Content. Cualquier otro código de estado indica un problema de conexión al almacenamiento de objetos.

7. Ejecute el siguiente comando:

   java -jar opc_install.jar -opcid <user_id> -opcPass '<auth_token>' -libDir <target_dir> -walletDir <target_dir> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -configFile config.txt

   Tenga en cuenta que <target_dir> es el directorio en el que extrajo opc_installer.zip en el paso 3.

   Este comando puede tardar unos minutos en completarse porque descarga libopc.so y otros archivos. Una vez terminado el comando, debe ver varios archivos (que incluyan libopc.so) en el directorio de destino.

8. Cambie al directorio de destino y copie los archivos lipopc.so y opc_install.jar en el directorio /opt/oracle/oak/pkgrepos/oss/odbcs.

   cp libopc.so /opt/oracle/oak/pkgrepos/oss/odbcs

   
   
   cp opc_install.jar /opt/oracle/oak/pkgrepos/oss/odbcs

   (Puede que tenga que usar sudo con los comandos copiar para ejecutarlos como raíz).

9. Ejecute el siguiente comando para comprobar si el directorio indicado existe:

   
   
   ls /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs

   Si este directorio existe, siga los siguientes pasos:

   1. Haga una copia de seguridad de los archivos en el directorio /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs.

   2. Ejecute estos dos comandos para sustituir los archivos libopc.so y opc_install.jar existentes en ese directorio:

      
      cp libopc.so /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
      cp opc_install.jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs

10. Verifique la versión de opc_install.jar.

    
    java -jar /opt/oracle/oak/pkgrepos/oss/odbcs/opc_install.jar |grep -i build
    

    Si existe /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs, ejecute también el siguiente comando:

    
    java -jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs/opc_install.jar |grep -i build

    Ambos comandos deben devolver el siguiente resultado:

    Oracle Database Cloud Backup Module Install Tool, build MAIN_2017-08-16.

11. (Opcional) Suprima el usuario temporal y el directorio de destino que ha utilizado para instalar el módulo de copia de seguridad.

Después de completar el procedimiento, póngase en contacto con los Servicios de Soporte de Oracle o con el administrador del inquilino para obtener más instrucciones. Debe proporcionar el OCID del sistema de base de datos para el que desea activar las copias de seguridad.

Enlace directo a este problema: No se han podido utilizar las copias de seguridad gestionadas en el sistema de base de datos

Detalles: las limitaciones de memoria de las máquinas host que ejecutan la forma VM.Standard1.1 pueden causar fallos en los trabajos de copia de seguridad automática de la base de datos gestionados por Oracle Cloud Infrastructure (trabajos gestionados mediante la consola o la API). Puede cambiar los parámetros de memoria de los sistemas para resolver este problema.

Solución alternativa: cambie los parámetros de memoria de los sistemas de la siguiente manera.

1. Cambie al usuario oracle en el sistema operativo.

   [opc@hostname ~]$ sudo su - oracle

2. Defina la variable de entorno para conectarse a la instancia de base de datos. Por ejemplo:

   
   [oracle@hostname ~]$ . oraenv
    ORACLE_SID = [oracle] ? orcl
   				

3. Inicie SQL*Plus.

   [oracle@hostname ~]$ sqlplus / as sysdba

4. Cambie los parámetros de memoria iniciales de la siguiente manera:

   
   SQL> ALTER SYSTEM SET SGA_TARGET = 1228M scope=spfile;
   SQL> ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 1228M;
   SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT = 2457M;
   SQL> exit
   							

5. Reinicie la instancia de la base de datos.

   
   [oracle@hostname ~]$ srvctl stop database -d db_unique_name -o immediate
   [oracle@hostname ~]$ srvctl start database -d db_unique_name -o open								

Enlace directo a este problema: Las copias de seguridad automáticas gestionadas fallan en la forma VM.Standard1.1 debido a un bloqueo del proceso

Detalles: en los sistemas de base de datos de alto rendimiento y rendimiento extremo, las operaciones de herramientas de Data Pump que utilizan compresión o paralelismo pueden fallar y devolver el error ORA-00439: función no activada. Este problema afecta a las versiones de base de datos 12.1.0.2.161018 y 12.1.0.2.170117.

Solución alternativa: aplique el parche 25579568 o 25891266 a los directorios raíz de Oracle Database para las versiones de base de datos 12.1.0.2.161018 o 12.1.0.2.170117, respectivamente. Como alternativa, utilice la Consola para aplicar el parche de abril de 2017 al sistema de base de datos y al directorio raíz de la base de datos.

Enlace directo a este problema: Las operaciones de Oracle Data Pump devuelven "ORA- 00439: función no activada"

Detalles: puede que aparezca un mensaje de error "Fallo de conexión segura" al intentar conectarse a la consola de EM Express desde el sistema de base de datos de un nodo, ya que los permisos correctos no se han aplicado automáticamente.

Solución alternativa: añada permisos de lectura al grupo asmadmin en el directorio de cartera del sistema de base de datos y vuelva a intentar la conexión,

1. Shell seguro para el host del sistema de base de datos, conéctese como opc, sudo al usuario de la cuadrícula.

   [opc@dbsysHost ~]$ sudo su - grid
   [grid@dbsysHost ~]$ . oraenv
   ORACLE_SID = [+ASM1] ?
   The Oracle base has been set to /u01/app/grid
   

2. Obtenga la ubicación del directorio de cartera, mostrada en rojo debajo, en el resultado del comando.

   [grid@dbsysHost ~]$ lsnrctl status | grep xdb_wallet
   
   (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=dbsysHost.sub04061528182.dbsysapril6.oraclevcn.com)(PORT=5500))(Security=(my_wallet_directory=/u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet))(Presentation=HTTP)(Session=RAW))

3. Vuelva al usuario opc, cambie al usuario oracle y cambie al directorio de cartera.

   [opc@dbsysHost ~]$ sudo su - oracle
   [oracle@dbsysHost ~]$ cd /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet

4. Muestre el contenido del directorio y anote los permisos.

   
   [oracle@dbsysHost xdb_wallet]$ ls -ltr
   total 8
   -rw------- 1 oracle asmadmin 3881 Apr  6 16:32 ewallet.p12
   -rw------- 1 oracle asmadmin 3926 Apr  6 16:32 cwallet.sso
   

5. Cambie los permisos:

   
   [oracle@dbsysHost xdb_wallet]$ chmod 640 /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet/*

6. Verifique que se hayan agregado permisos de lectura.

   [oracle@dbsysHost xdb_wallet]$ ls -ltr
   total 8
   -rw-r----- 1 oracle asmadmin 3881 Apr  6 16:32 ewallet.p12
   -rw-r----- 1 oracle asmadmin 3926 Apr  6 16:32 cwallet.sso
   

Enlace directo a este problema: No se ha podido conectar a la consola de EM Express desde el sistema de base de datos de un nodo

Detalles: las operaciones de copia de seguridad en el almacenamiento de objetos con las herramientas de copia de seguridad de Exadata (bkup_api) o RMAN fallan con los siguientes errores:

* DBaaS Error trace:
-> API::ERROR -> KBHS-00715: HTTP error occurred 'oracle-error'
-> API::ERROR -> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> API::ERROR -> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> API::ERROR -> ORA-27023: skgfqsbi: media manager protocol error
-> API::ERROR Unable to verify the backup pieces
-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error

En respuesta a las políticas implementadas por dos exploradores web comunes con respecto a certificados de Symantec, Oracle ha cambiado recientemente la autoridad de certificación utilizada para Oracle Cloud Infrastructure. El cambio resultante en los certificados de capa de conexión segura puede hacer que las copias de seguridad en el almacenamiento de objetos fallen si el módulo Oracle Database Cloud Backup sigue apuntando al certificado anterior.

Solución alternativa para bkup_api: compruebe que los archivos log no contengan los errores enumerados y, si los hay, vuelva a instalar el módulo de copia de seguridad.

Utilice el siguiente comando para comprobar el estado de la copia de seguridad con fallos:

/var/opt/oracle/bkup_api/bkup_api bkup_status --dbname=<database_name>

Ejecute el siguiente comando para volver a instalar el módulo de copia de seguridad:

/var/opt/oracle/ocde/assistants/bkup/bkup -dbname=<database_name>

Solución alternativa para RMAN: compruebe los archivos log de RMAN para ver los mensajes de error mostrados. Si aparece algún mensaje de error, conéctese al host como usuario oracle y vuelva a instalar el módulo de copia de seguridad con las credenciales de Swift.

java -jar <opc_install.jar_path> -opcId '<Swift_user_ID>' -opcPass '<auth_token>' -container <objectstore_container> -walletDir <wallet_directory> -configfile <config_file> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -import-all-trustcerts

Lleve a cabo esta solución alternativa en todos los nodos del cluster.

Consulte la documentación del módulo Oracle Database Cloud Backup para obtener más información sobre el uso de este comando.

Enlace directo a este problema: Fallo al realizar una copia de seguridad en el almacenamiento de objetos mediante bkup_api o RMAN debido a un cambio de certificado

Detalles: Con la versión de la función de directorio raíz de base de datos compartida para los sistemas de base de datos de Exadata, la consola ahora también se sincroniza y muestra información sobre las bases de datos que se crean y gestionan mediante las herramientas dbaasapi y dbaascli. Sin embargo, las bases de datos con Data Guard configurado no muestran la información correcta en la consola en las siguientes condiciones:

• Si Data Guard se ha activado mediante la consola y, a continuación, se realiza un cambio en la base de datos primaria o en espera mediante dbaascli (como mover la base de datos a un directorio raíz diferente), el resultado no se refleja en la consola.
• Si Data Guard se ha configurado manualmente, la consola no muestra una asociación de Data Guard entre las dos bases de datos.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Mientras tanto, Oracle recomienda que gestione las bases de datos activadas para Data Guard solamente mediante la consola o las herramientas de la línea de comandos.

Enlace directo a este problema:La información de la consola no se sincroniza para las bases de datos activadas para Data Guard cuando se utiliza dbaascli

Detalles: se trata de un problema de clusterware que se produce solo cuando la versión de Oracle GI es la 12.2.0.1 sin ningún parche de paquete. El problema se debe que un disco de quorum está dañado después de desconectarlo y conectarlo.

Solución alternativa: determine la versión de GI y si el disco de quorum está dañado. Repare el disco, si corresponde, y aplique el último paquete de GI.

1. Verifique que la versión de GI es la 12.2.0.1 sin ningún parche de paquete aplicado:

   
   [root@rmstest-udaau1 ~]# su - grid
   [grid@rmstest-udaau1 ~]$ . oraenv
   ORACLE_SID = [+ASM1] ? +ASM1
   The Oracle base has been set to /u01/app/grid
   [grid@rmstest-udaau1 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory
   Oracle Interim Patch Installer version 12.2.0.1.6
   Copyright (c) 2018, Oracle Corporation.  All rights reserved.
   
   
   Oracle Home       : /u01/app/12.2.0.1/grid
   Central Inventory : /u01/app/oraInventory
      from           : /u01/app/12.2.0.1/grid/oraInst.loc
   OPatch version    : 12.2.0.1.6
   OUI version       : 12.2.0.1.4
   Log file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/opatch2018-01-15_22-11-10PM_1.log
   
   Lsinventory Output file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/lsinv/lsinventory2018-01-15_22-11-10PM.txt
   
   --------------------------------------------------------------------------------
   Local Machine Information::
   Hostname: rmstest-udaau1.exaagclient.sretest.oraclevcn.com
   ARU platform id: 226
   ARU platform description:: Linux x86-64
   
   Installed Top-level Products (1):
   
   Oracle Grid Infrastructure 12c                                       12.2.0.1.0
   There are 1 products installed in this Oracle Home.
   
   
   There are no Interim patches installed in this Oracle Home.
   
   
   --------------------------------------------------------------------------------
   
   OPatch succeeded.

2. Compruebe el archivo /u01/app/grid/diag/crs/<hostname>/crs/trace/ocssd.trc para saber si GI no se ha podido iniciar debido a que el disco de quorum está dañado.

   ocssd.trc
    
   2017-01-17 23:45:11.955 :    CSSD:3807860480: clssnmvDiskCheck:: configured 
   Sites = 1, Incative sites = 1, Mininum Sites required = 1 
   2017-01-17 23:45:11.955 :    CSSD:3807860480: (:CSSNM00018:)clssnmvDiskCheck: 
   Aborting, 2 of 5 configured voting disks available, need 3 
   ...... 
   . 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: clssnmCheckForNetworkFailure: 
   skipping 31 defined 0 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: clssnmRemoveNodeInTerm: node 4, 
   slcc05db08 terminated. Removing from its own member and connected bitmaps 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: 
   ################################### 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: clssscExit: CSSD aborting from 
   thread clssnmvDiskPingMonitorThread 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: 
   ################################### 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: (:CSSSC00012:)clssscExit: A 
   fatal error occurred and the CSS daemon is terminating abnormally 
    
   ------------
    
   2017-01-19 19:00:32.689 :    CSSD:3469420288: clssnmFindVF: Duplicate voting disk found in the queue of previously configured disks 
   queued(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009 
   cbd]), 
   found(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009c 
   bd]), is not corrupted 
   2017-01-19 19:01:06.467 :    CSSD:3452057344: clssnmvVoteDiskValidation: 
   Voting disk(o/192.168.10.19/PCW_CD_02_slcc05cel11) is corrupted

3. También puede utilizar SQL*Plus para confirmar que los discos de quorum están dañados:

   1. Inicie sesión como usuario de cuadrícula y establezca el entorno en ASM.

      [root@rmstest-udaau1 ~]# su - grid
      [grid@rmstest-udaau1 ~]$ . oraenv
      ORACLE_SID = [+ASM1] ? +ASM1
      The Oracle base has been set to /u01/app/grid

   2. Inicie sesión en SQL*Plus como SYSASM.

      $ORACLE_HOME/bin/sqlplus / as sysasm

   3. Ejecute las dos consultas siguientes:

      SQL> select name, voting_file from v$asm_disk where VOTING_FILE='Y' and group_number !=0;
      SQL> select  CC.name, count(*) from x$kfdat AA JOIN (select disk_number, name from v$asm_disk where VOTING_FILE='Y' and group_number !=0) CC ON CC.disk_number = AA.NUMBER_KFDAT where AA.FNUM_KFDAT= 1048572 group by CC.name;

      Si el sistema está en buen estado, los resultados deberían ser similares al siguiente ejemplo.

      Resultados de la consulta 1

      NAME                           VOTING_FILE
      ------------------------------ ---------------
      DBFSC3_CD_02_SLCLCX0788        Y
      DBFSC3_CD_09_SLCLCX0787        Y
      DBFSC3_CD_04_SLCLCX0786        Y

      Resultados de la consulta 2

      NAME                           COUNT(*)
      ------------------------------ ---------------
      DBFSC3_CD_02_SLCLCX0788        8
      DBFSC3_CD_09_SLCLCX0787        8
      DBFSC3_CD_04_SLCLCX0786        8

      En un sistema en buen estado, todos los discos de quorum devueltos en la primera consulta también se deben devolver en la segunda, y los recuentos de todos los discos deben ser distintos de cero. De lo contrario, uno o más de los discos de quorum están dañados.

4. Si los discos de quorum están dañados, desconecte el disco de cuadrícula que contiene el disco de quorum. Las celdas moverán automáticamente el disco de quorum dañado al otro disco de cuadrícula conectarán ese disco de quorum.

   1. El siguiente comando desconecta un disco de cuadrícula denominado DATAC01_CD_05_SCAQAE08CELADM13.

      SQL> alter diskgroup DATAC01 offline disk DATAC01_CD_05_SCAQAE08CELADM13;
           Diskgroup altered.

   2. Espere 30 segundos y vuelva a ejecutar las dos consultas del paso 3c para verificar que el disco de quorum se ha migrado al nuevo disco de cuadrícula y que está en buen estado.

   3. Compruebe que el disco de cuadrícula que ha desconectado esté en línea:

      SQL> select name, mode_status, voting_file from v$asm_disk where name='DATAC01_CD_05_SCAQAE08CELADM13';

      mode_status debe ser ONLINE y voting_file NO debe ser Y.

   Repita los pasos de 4a a 4c en cada disco de cuadrícula restante que contenga un disco de quorum dañado.

   Nota
   
   

   Si el sistema central de reservas no se inicia debido a que el disco de quorum está dañado, inícielo con el modo Exclusivo antes de ejecutar el comando en el paso 4.

   crsctl start crs -excl

    

5. Si utiliza Oracle GI versión 12.2.0.1 sin ningún parche de grupo, debe actualizar la versión de GI al último grupo de GI, se haya dañado o no un disco de quorum.

   Consulte Aplicación de parches en Oracle Grid Infrastructure y Oracle Database mediante dbaascli para obtener instrucciones sobre cómo usar la utilidad dbaascli para realizar operaciones de aplicación de parches para Oracle Grid Infrastructure y Oracle Database enExadata Database on Dedicated Infrastructure.

Enlace directo a este problema: la infraestructura de grid no se inicia después de desconectar y conectar un disco

Detalles: los sistemas de base de datos Exadata publicados a partir del 15 de junio de 2018 incluyen automáticamente la capacidad de crear, mostrar y suprimir bases de datos con la Consola, la API o la CLI de Oracle Cloud Infrastructure. Sin embargo, los sistemas aprovisionados antes de esta fecha necesitan pasos adicionales para activar esta funcionalidad.

Si se intenta utilizar esta funcionalidad sin seguir los pasos adicionales, aparecerán los siguientes mensajes de error:

• Al crear una base de datos: "Crear base de datos no es compatible con este sistema de base de datos Exadata. Para activar esta función, póngase en contacto con los Servicios de Soporte Oracle".
• Al finalizar una base de datos: "El sistema de base de datos Exadata no soporta DeleteDbHome. Para activar esta función, póngase en contacto con los Servicios de Soporte Oracle".

Solución alternativa: debe instalar el agente de Exadata en cada nodo del sistema de base de datos de Exadata.

En primer lugar, cree una solicitud de servicio para obtener ayuda de los Servicios de Soporte Oracle. Los Servicios de Soporte Oracle responderán al proporcionar una URL autenticada previamente para una ubicación de Almacenamiento de objetos de Oracle Cloud Infrastructure, donde podrá obtener el agente.

Antes de instalar el agente de Exadata:

• Actualice las herramientas (dbaastools rpm) a la versión más reciente en todos los nodos del sistema de base de datos Exadata. Consulte Actualización de herramientas en una instancia de Exadata Cloud Service.
• Asegúrese de que el sistema está configurado para acceder al almacenamiento de objetos de Oracle Cloud Infrastructure con las listas de seguridad necesarias para la región en la que se creó el sistema de base de datos. Para obtener más información sobre la conectividad con Oracle Cloud Infrastructure Object Storage, consulte Requisitos para copias de seguridad en Exadata Cloud Service.

Para instalar el agente de Exadata:

1. Inicie sesión en el nodo como raíz.

2. Introduzca los siguientes comandos para instalar el agente.

   [root@<node_n>~]# cd /tmp
   [root@<node_n>~]# wget https://objectstorage.<region_name>.oraclecloud.com/p/1q523eOkAOYBJVP9RYji3V5APlMFHIv1_6bAMmxsS4E/n/dbaaspatchstore/b/dbaasexadatacustomersea1/o/backfill_agent_package_iwwva.tar
   [root@<node_n>~]# tar -xvf /tmp/backfill_agent_package_*.tar -C /tmp
   [root@<node_n>~]# rpm -ivh /tmp/dbcs-agent-2.5-3.x86_64.rpm

   Resultado de ejemplo:

   [root@<node_n>~]# rpm -ivh dbcs-agent-2.5-3.x86_64.rpm
   Preparing...                ########################################### [100%]
   Checking for dbaastools_exa rpm on the system
   Current dbaastools_exa version = dbaastools_exa-1.0-1+18.1.4.1.0_180725.0000.x86_64
   dbaastools_exa version dbaastools_exa-1.0-1+18.1.4.1.0_180725.0000.x86_64 is good. Continuing with dbcs-agent installation
      1:dbcs-agent             ########################################### [100%]
   initctl: Unknown instance:
   initctl: Unknown instance:
   initzookeeper start/running, process 85821
   initdbcsagent stop/waiting
   initdbcsadmin stop/waiting
   initdbcsagent start/running, process 85833
   initdbcsadmin start/running, process 85836
   

3. Confirme que el agente esté instalado y en ejecución.

   [root@<node_n>~]# rpm -qa | grep dbcs-agent
   dbcs-agent-2.5-0.x86_64
   [root@<node_n>~]# initctl status initdbcsagent
   initdbcsagent start/running, process 97832

4. Repita los pasos de 1 a 3 en los demás nodos.

Después de instalar el agente en todos los nodos, deje hasta 30 minutos para que Oracle realice tareas de flujo de trabajo adicionales, como la actualización del agente a la última versión, la rotación de las credenciales de agente, etc. Una vez completado el proceso, podrá usar las funciones gestionadas de Exadata en la Consola, la API o la CLI de Oracle Cloud Infrastructure.

Enlace directo a este problema: Funciones gestionadas no activadas para sistemas aprovisionados antes del 15 de junio de 2018

Detalles: el archivo de configuración de parches (/var/opt/oracle/exapatch/exadbcpatch.cfg) apunta al almacén de objetos de la región us-phoenix-1, incluso si el sistema de base de datos Exadata está desplegado en otra región.

Este problema se produce si la versión del paquete de herramientas de base de datos (dbaastools_exa) es 17430 o inferior.

Solución alternativa: siga las instrucciones en Actualización de herramientas en una instancia de Exadata Cloud Service para confirmar que la versión del paquete de herramientas es 17430 o inferior y, a continuación, actualícela a la última versión.

Enlace directo a este problema: La aplicación de parches al archivo de configuración apunta a una región incorrecta

Detalles: si cambia la forma en que Oracle Linux 7 maneja los archivos temporales, puede eliminar los archivos de socket necesarios del directorio /var/tmp/.oracle. Este problema afecta solo a los sistemas de bases de datos Exadata que ejecutan la versión de la imagen del sistema operativo 19.1.2.

Solución alternativa: ejecute sudo /usr/local/bin/imageinfo como usuario opc para determinar la versión de la imagen del sistema operativo. Si su versión de imagen es 19.1.2.0.0.190306, siga las instrucciones de ID de documento 2498572.1 para solucionar el problema.

Enlace directo a este problema: Varios fallos del flujo de trabajo de la base de datos debido a que Oracle Linux 7 ha eliminado los archivos temporales necesarios

Detalles: si utiliza copias de seguridad de grupo de volúmenes al realizar operaciones de recuperación ante desastres (DR) para recursos informáticos y almacenamiento entre diferentes dominios de disponibilidad (AD) dentro de la misma región, las transiciones de DR hacia adelante y hacia atrás harán que el almacenamiento de bloques asociado y de recursos informáticos (que utiliza copias de seguridad de grupo de volúmenes) finalice en un AD diferente cada vez.

Solución alternativa: esta incidencia no afecta al almacenamiento de bloques que se replica mediante la replicación del grupo de volúmenes.

Detalles: la configuración de rendimiento con ajuste automático para volúmenes de almacenamiento de bloques no se transfiere durante las operaciones de DR.

Solución alternativa: para los volúmenes de almacenamiento de bloques que tienen activado el rendimiento con ajuste automático, debe volver a activar esta configuración después de que la recuperación ante desastres de pila completa transfiera estos volúmenes de almacenamiento de bloques a otra región.

Detalles: si realiza una operación de failover inmediatamente después de modificar un recurso protegido contra DR de pila completa, es posible que falle la recuperación del recurso o que el recurso no se recupere correctamente. Por ejemplo, si cambia el destino de replicación u otras propiedades de un grupo de volúmenes que ha agregado a un grupo de protección de DR y la región principal sufre una interrupción inmediata posteriormente, la recuperación ante desastres de pila completa puede no detectar los cambios que ha realizado en la configuración de replicación de grupo de volúmenes, y esto afectará a la recuperación de ese grupo de volúmenes.

Solución alternativa: realice una comprobación previa de switchover inmediatamente después de realizar cambios en cualquier recurso protegido mediante DR.

Detalles: la recuperación ante desastres de pila completa usa la ejecución del comando de Oracle Cloud Agent (OCA) para ejecutar scripts locales en instancias. Al configurar un paso definido por el usuario para ejecutar un script local en una instancia de Microsoft Windows, no puede utilizar la función Ejecutar como usuario de recuperación ante desastres de pila completa que permite especificar un userid diferente para ejecutar scripts locales que residen en instancias.

Solución alternativa: en instancias de Microsoft Windows, el script solo se puede ejecutar como el identificador de usuario ocarun por defecto que usa la utilidad Ejecutar comando de Oracle Cloud Agent. Esta limitación no afecta a las instancias de Oracle Linux.

Detalles: la recuperación ante desastres de pila completa usa la ejecución del comando de Oracle Cloud Agent (OCA) para ejecutar scripts locales en instancias. Por defecto, estos scripts se ejecutan como usuario ocarun.

Solución alternativa: en una instancia de Microsoft Windows, cualquier script local que configure para que se ejecute como un paso definido por el usuario en un plan de DR debe ser accesible y ejecutable por este identificador de usuario ocarun.

Detalles: al ejecutar un script local mediante un paso definido por el usuario en un plan de DR, si no proporciona las rutas de acceso completas a los intérpretes de scripts o a los scripts, la recuperación ante desastres de pila completa devolverá errores.

Solución alternativa: al configurar un paso definido por el usuario en un plan de DR para ejecutar un script local que resida en una instancia, asegúrese de proporcionar la ruta de acceso completa a cualquier intérprete que pueda preceder al nombre del script, así como la ruta completa al script.

Detalles: durante las operaciones de reconfiguración dinámica, la recuperación ante desastres de pila completa intenta reasignar la IP privada original asignada a una instancia si el bloque de CIDR de la subred de destino coincide con el bloque de CIDR de la subred de origen y si la IP privada original de la instancia no está aún asignada.

Si utiliza la recuperación ante desastres de pila completa para cambiar la ubicación de todos los nodos de un cluster OCFS2 y la IP privada de cualquiera de los nodos del cluster no se puede asignar, esos nodos de cluster se desconectarán del cluster OCFS2 después de que los nodos se inicien en la región en espera.

Solución alternativa: asegúrese de que el bloque de CIDR de la subred de destino coincida con el bloque de CIDR de la subred de origen y de que todas las direcciones IP privadas necesarias para los nodos de cluster estén disponibles en la subred de destino.

Detalles: una vez que la recuperación ante desastres de pila completa ha asignado una instancia a una región diferente, la página de recursos de la instancia puede mostrar el siguiente mensaje para Acceso a instancias:

No estamos seguros de cómo realizar la conexión a una instancia que utiliza esta imagen

Solución alternativa: ignore este mensaje. Las conexiones SSH a la instancia funcionarán con normalidad si utiliza el archivo de claves SSH original para conectarse a la instancia y autenticarla.

Detalles: una vez que la recuperación ante desastres de pila completa se traslada a una instancia a una región diferente, la página de recursos de la instancia puede mostrar información incorrecta para la parte de imagen de su volumen de inicio.

Por ejemplo, la columna de información de imagen puede mostrar el siguiente mensaje: Error al cargar datos

Solución alternativa: este mensaje de error es para la visualización del nombre de imagen, pero no afecta el funcionamiento de la instancia o a su volumen de inicio.

Detalles: cuando no hay tiempo de inactividad para el comando nohup, el comando run no se puede ejecutar y no puede informar el estado correctamente.

nohup sh enabler.sh  &> enabler.log &
sleep 10
exit 0

Detalles: durante una transición de DR, cuando los volúmenes en bloque se mueven a una región diferente, la configuración de rendimiento (IOPS y rendimiento) no se replica ni se restaura automáticamente. Puede que necesite volver a configurar estos valores de rendimiento.

Solución alternativa: después de ejecutar un plan de DR, configure la configuración de rendimiento manualmente.

Detalles: Puede que a veces la carga bajo demanda de un archivo zip creado en una máquina con Windows no pueda cargar el contenido del log. El motivo del fallo es que el zip creado en Windows tiene la misma hora de última modificación que la hora de creación del archivo. Por lo tanto, cuando se descomprime el archivo, la hora de última modificación del archivo se define como la hora de creación del archivo, que puede ser anterior al registro de hora de las entradas de log en el archivo log. En este caso, no se cargan las entradas de log con un registro de hora más reciente que la hora de última modificación del archivo.

Ejemplo de la incidencia:

Registro de hora en la entrada de log: 2020-10-12 21:12:06

Hora de última modificación del archivo del archivo log: 2020-10-10 08:00:00

Solución alternativa: copie los archivos log en una nueva carpeta y cree un archivo zip. Esta acción hace que la hora de última modificación del archivo sea más reciente que el registro de hora de las entradas del log. Utilice este nuevo archivo zip para la carga bajo demanda.

Utilizando el ejemplo anterior, después de implementar la solución alternativa:

Registro de hora en la entrada de log: 2020-10-12 21:12:06

Hora de última modificación del archivo del archivo log: 2021-03-31 08:00:00

Enlace directo a esta incidencia: Carga bajo demanda desde una máquina con Windows mediante un archivo zip

Detalles: las carpetas que contienen más de 10 000 archivos pueden provocar un uso elevado de los recursos (memoria, almacenamiento y CPU) por parte del agente de gestión, lo que puede provocar una recopilación de logs lenta, afectar a otras funcionalidades del agente de gestión y también ralentizar la máquina host.

Cuando el plugin de Logging Analytics Management Agent encuentra carpetas grandes, se agrega un mensaje similar al siguiente mensaje de ejemplo al archivo mgmt_agent_logan.log de Management Agent:

2020-07-30 14:46:51,653 [LOG.Executor.2388 (LA_TASK_os_file)-61850] INFO - ignore large dir /u01/service/database/logs. set property loganalytics.enable_large_dir to enable. 

Resolución: recomendamos evitar las carpetas grandes. Utilice un mecanismo de limpieza para eliminar archivos poco después de recopilarlos, de modo que Management Agent tenga tiempo suficiente para volver a recopilarlos.

Sin embargo, si desea continuar supervisando logs en carpetas grandes, puede activar el soporte realizando la siguiente acción:

sudo -u mgmt_agent echo "loganalytics.enable_large_dir=true" >> INSTALL_DIRECTORY/agent_inst/config/emd.properties

Sustituya INSTALL_DIRECTORY por la ruta de acceso a la carpeta agent_inst y reinicie el agente.

Enlace directo a este problema: Manejo especial al supervisar logs en carpetas grandes