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: 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 y 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: falla el uso de 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: falla el uso de 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: falla el uso de 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: falla el uso de 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 base de datos del sistema de base de datos 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 buscando una solución.

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 la visión general de los gateways de servicio denominada Todas las <regiones> Servicios en la red de servicios Oracle. 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 navegadores web comunes con certificados de Symantec, Oracle ha cambiado recientemente la autoridad de certificación utilizada para Oracle Cloud Infrastructure. El cambio resultante en los certificados SSL 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 navegadores web comunes con certificados de Symantec, Oracle ha cambiado recientemente la autoridad de certificación utilizada para Oracle Cloud Infrastructure. El cambio resultante en los certificados SSL 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 solo 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 bases de datos Oracle Grid Infrastructure y Oracle mediante dbaascli para obtener instrucciones sobre cómo utilizar la utilidad dbaascli para realizar operaciones de aplicación de parches para Oracle Grid Infrastructure y Oracle Database en Exadata Database Service 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 lanzados 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 proporcionándole una URL autenticada previamente para una ubicación de Oracle Cloud Infrastructure Object Storage en la que pueda 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 a Oracle Cloud Infrastructure Object Storage con las listas de seguridad necesarias para la región en la que se ha creado 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 DR para recursos informáticos y almacenamiento entre diferentes 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 informático (que utiliza copias de seguridad de grupo de volúmenes) finalice en un AD diferente cada vez.

Solución alternativa: este problema no afecta al almacenamiento de bloques que se replican 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 Full Stack DR 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 por 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, es posible que Full Stack DR no detecte 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: Full Stack DR usa la utilidad Ejecutar 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 DR 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: Full Stack DR usa la utilidad Ejecutar 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, Full Stack DR 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 DR, la DR 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 Full Stack DR para reubicar todos los nodos de un cluster OCFS2 y la IP privada de cualquiera de los nodos del cluster no se puede reasignar, 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 Full Stack DR ha reubicado una instancia en 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 replica una instancia en 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 del 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 tenga que 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 a petición 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 recursos (memoria/almacenamiento/CPU) por parte del agente de gestión, lo que puede provocar una recopilación lenta de logs, afectar a otras funcionalidades del agente de gestión y también ralentizar la máquina host.

Cuando el plugin de Management Agent Logging Analytics 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 que se hayan recopilado, 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: Modo especial al supervisar logs en carpetas grandes