Problemas conocidos

En las listas siguientes se describen los problemas conocidos de Oracle Cloud Infrastructure.

Announcements

Actualmente, no hay problemas conocidos de Anuncios.

Anomaly Detection

Actualmente, no hay ninguna incidencia conocida con el servicio Anomaly Detection.

API Gateway

Los gateways de API no heredan los servidores DNS personalizados de las subredes

Detalles: El solucionador de Oracle Cloud Infrastructure por defecto resuelve los puntos finales de URL pública (y los puntos finales de URL con nombres de host públicos) en las direcciones IP. Además, se puede configurar una subred con un servidor de DNS personalizado que resuelva puntos finales de URL de nombre de host interno (y nombre de host privado) en direcciones IP. Sin embargo, los gateways de API que cree con el servicio de gateway de API no heredan los servidores DNS personalizados de las subredes. En su lugar, los gateways de API utilizan el solucionador de Oracle Cloud Infrastructure por defecto, que no resuelve los puntos finales de URL de nombre de host interno/privado.

Debido a esta restricción, si crea un gateway de API que tiene un punto final de URL de nombre de host interno/privado como backend de URL HTTP o HTTPS, las llamadas a la API fallarán porque el nombre de host no se puede resolver en una dirección IP.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Mientras tanto, si desea crear un gateway de API que tenga un punto final de URL interno/privado como backend de URL HTTP o HTTPS, debe especificar la dirección IP del host en la URL en lugar del nombre de host. Además, si el backend es una URL HTTPS, también debe seleccionar la opción Desactivar verificación de SSL en la consola (o incluir isSSLVerifyDisabled: true en el archivo JSON de especificación de despliegue de API).

Enlace directo a este problema: Los gateways de API no heredan los servidores DNS personalizados de las subredes

Application Migration

La migración falla para aplicaciones de Oracle Java Cloud Service que tienen nombres largos

Detalles: el servicio Classic Migration no soporta la migración de aplicaciones de Oracle Java Cloud Service con nombres superiores a 28 caracteres.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Antes de empezar a migrar una aplicación de Oracle Java Cloud Service, cambie el nombre de la aplicación para que tenga menos de 28 caracteres.

Enlace directo a este problema: La migración falla para aplicaciones de Oracle Java Cloud Service que tienen nombres largos

Atributos no soportados para la aplicación Oracle Analytics Cloud - Classic

Detalles: Al crear una migración para la aplicación Oracle Analytics Cloud- Classic mediante la API o la CLI, es obligatorio proporcionar valores para los atributos serviceInstanceUser y serviceInstancePassword. Sin embargo, el servicio Classic Migration ignora estos valores.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Puede introducir cualquier valor para estos atributos, como" no utilizado".

Enlace directo a este problema: Atributos no soportados para la aplicación Oracle Analytics Cloud - Classic

Parámetros de consulta no soportados en el comando listSourceApplications

Detalles: El comando listSourceApplications no soporta los siguientes parámetros de consulta: limit, page, sortOrder y sortBy.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. No utilice estos parámetros de consulta para filtrar los resultados de la búsqueda.

Enlace directo a este problema: Parámetros de consulta no soportados en la operación listSourceApplications

Parámetro de consulta no soportado en el comando listMigrations

Detalles: El comando listMigrations no soporta el parámetro de consulta lifecycleState.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. No utilice este parámetro de consulta para filtrar los resultados de la búsqueda.

Enlace directo a este problema: Parámetro de consulta no soportado en el comando listMigrations

Application Performance Monitoring

Es posible que las supervisiones de tipo Explorador y Explorador con scripts no ejecuten aplicaciones que utilicen marcos

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

Incidencias con las políticas de autorización basadas en las etiquetas de recurso apm-domains

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

Audit

Actualmente, no hay problemas conocidos de Auditoría.

Bastión

Fallos de sesión de SSH gestionada para instancias de Ubuntu

Detalles: para crear una sesión de SSH gestionada para una instancia informática, el plugin Bastión debe estar activado y en ejecución. Este plugin está disponible en Oracle Cloud Agent versión 1.11 o posterior. Si la instancia de Ubuntu ejecuta una versión anterior a la 1.11, fallará la creación de una sesión de SSH gestionada.

Solución alternativa:

Para actualizar una instancia informática de Ubuntu existente a fin de soportar sesiones de SSH gestionadas:

  1. Agregue un gateway de NAT a la VCN (red virtual en la nube) en la que ha creado la instancia, si no está ya presente. Consulte Configuración de un gateway de NAT.
  2. Desde el bastión, cree una sesión de reenvío de puerto (canal de SSH) al puerto de SSH (el 22 por defecto) en la instancia. Consulte Gestión de sesiones.
  3. Conéctese a la instancia mediante la sesión de reenvío de puerto. Consulte Conexión a sesiones.
  4. Para instalar la versión más reciente de Oracle Cloud Agent, ejecute el siguiente comando en la instancia:
    sudo snap refresh oracle-cloud-agent

    Para obtener más información, consulte Instalación del software Oracle Cloud Agent.

  5. Active el plugin Bastión en la instancia. Consulte Gestión de plugins mediante la consola
  6. Desde el bastión, cree una sesión de SSH gestionada en la instancia.

Si desea crear otra instancia de Ubuntu, una solución alternativa es proporcionar un script cloud-init al iniciar la instancia. En este script, utilice el mismo comando para instalar la versión más reciente de Oracle Cloud Agent:

sudo snap refresh oracle-cloud-agent

Para obtener más información sobre los scripts cloud-init, consulte Instalación del software Oracle Cloud Agent.

Enlace directo a esta incidencia: Fallos de sesión de SSH gestionada para instancias de Ubuntu

Las sesiones de SSH gestionadas están soportadas para instancias de Arm solo si ejecutan Oracle Linux

Detalles: las sesiones de SSH gestionadas no están soportadas para las instancias informáticas que cumplan todas las condiciones siguientes:

  • Se han creado con unidades de Ampere A1 Compute basadas en Arm.
  • Ejecutan un sistema operativo distinto de Oracle Linux, como Ubuntu.

Para poder crear una sesión de SSH gestionada, el plugin Bastión debe estar activado y en ejecución. Debido a que este plugin no está activado correctamente en algunas instancias basadas en Arm, falla la creación de la sesión.

Solución alternativa: cree una sesión de reenvío de puerto para conectarse a instancias que utilicen unidades de Ampere A1 Compute y que no ejecuten Oracle Linux.

Enlace directo a esta incidencia: Las sesiones de SSH gestionadas están soportadas para instancias de Arm solo si ejecutan Oracle Linux

Big data

La tarea de sincronización de bases de datos de Hive falla cuando se especifica un carácter comodín en Apache Ambari

Detalles: en los clusters de big data que utilizan Oracle Distribution con Apache Hadoop, si sincroniza las bases de datos de Hive especificando el carácter comodín * para la propiedad Synchronize Hive Databases mediante Apache Ambari, recibirá un error que indica que la sincronización de los metadatos de Hive ha fallado.

Solución alternativa:: Tenemos constancia de esta incidencia y estamos trabajando para solucionarla. Mientras tanto, no utilice el carácter comodín * para la propiedad Synchronize Hive Databases; en su lugar, especifique explícitamente las bases de datos de Hive que desea sincronizar como una lista separada por comas y sin espacios. Por ejemplo: db1,db2.

Enlace directo a esta incidencia: La tarea de sincronización de bases de datos de Hive falla cuando se especifica un carácter comodín en Apache Ambari.

Facturación

Actualmente, no hay problemas conocidos en Billing.

Block Volume

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

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

Es posible que falle la asociación del número máximo de volúmenes en bloque a instancias VM.Standard.A1.Flex más pequeñas

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: somos conscientes del problema y estamos trabajando para solucionarlo. 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

Las operaciones de compuesto del SDK de Python devuelven el error 404 NotAuthorizedOrNotFound a pesar de que la operación es correcta

Detalles: las operaciones copy_boot_volume_backup_and_wait_for_state y copy_volume_backup_and_wait_for_state del compuesto de cliente BlockStorage devuelven 404/NotAuthorizedOrNotFound cuando se copia una copia de seguridad de una región a otra. Para obtener más información, consulte: https://github.com/oracle/oci-python-sdk/issues/344.

Solución alternativa: en lugar de utilizar las operaciones de compuesto, utilice dos clientes diferentes para esta operación; un cliente en la región de origen para enviar la solicitud de duplicado de la copia de seguridad de la región A a la región B, y un segundo cliente en la región de destino para esperar a que la copia de seguridad esté disponible. Consulte el ejemplo aquí: https://github.com/oracle/oci-python-sdk/blob/master/examples/copy_volume_backup_example.py

Enlace directo a esta incidencia: Las operaciones de compuesto del SDK de Python devuelven el error 404 NotAuthorizedOrNotFound a pesar de que la operación es correcta

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

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: somos conscientes del problema y estamos trabajando para solucionarlo. 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

No se ha emitido el evento de cambio de fin de compartimento para volúmenes en bloque y volúmenes de inicio

Detalles: los eventos com.oraclecloud.blockvolumes.changevolumecompartment.end y com.oraclecloud.blockvolumes.changebootvolumecompartment.end no se emiten después de sus correspondientes eventos de inicio por el servicio de Volumen en bloque aunque las operaciones se hayan completado correctamente.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Verifique directamente que el recurso se haya movido al nuevo compartimento.

Enlace directo a este problema: no se ha emitido el evento de cambio de fin de compartimento para volúmenes en bloque y volúmenes de inicio

Falta información en los eventos updatevolumekmskey updatebootvolumekmskey para volúmenes en bloque y volúmenes de inicio

Detalles: Los eventos com.oraclecloud.blockvolumes.updatevolumekmskey.begin y com.oraclecloud.blockvolumes.updatebootvolumekmskey.begin no tienen el campo current, que debe contener el ID de clave de KMS de la nueva clave para configurar para el volumen. En su lugar, el campo previous contiene este valor, cuando el campo previous debe contener el ID de clave de KMS anterior.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Verifique que su recurso tiene el ID de clave de KMS esperado después de la actualización.

Enlace directo a este problema: Falta información en los eventos updatevolumekmskey y updatebootvolumekmskey para volúmenes en bloque y volúmenes de inicio

El formato de campo de volumeId es incorrecto en un evento de creación con copias de seguridad manuales de volúmenes y volúmenes de inicio

Detalles: el campo volumeId de additionalDetails para los eventos com.oraclecloud.blockvolumes.createvolumebackup.end y com.oraclecloud.blockvolumes.createbootvolumebackup.end se formatea como un objeto y no como una cadena para copias de seguridad creadas manualmente. Esto significa que las reglas definidas para dispararse en este campo no se dispararán para copias de seguridad creadas manualmente. Este campo se formatea correctamente como una cadena en copias de seguridad programadas.

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

Enlace directo a este problema: El formato del campo volumeId es incorrecto para el evento de creación con las copias de seguridad de volumen manual y volumen de inicio.

Falta información de additionalDetails en los eventos copyvolumebackup.begin y copyvolumebackup.end.

Detalles: los campos sourceBackupId y destinationRegion faltan en additionalDetails para los eventos com.oraclecloud.blockvolumes.copyvolumebackup.begin y com.oraclecloud.blockvolumes.copyvolumebackup.end, por lo que no se dispararán las reglas establecidas según estos campos para tal fin.

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

Enlace directo a este problema: Falta información de additionalDetails en los eventos copyvolumebackup.begin y copyvolumebackup.end

Opción de ruta de dispositivo no disponible para instancias iniciadas antes del 11 de enero de 2019

Detalles: al asociar un volumen en bloque a una instancia iniciada antes del 11 de enero de 2019, no puede especificar una ruta de dispositivo.

Enlace directo a este problema: La opción de ruta de dispositivo no está disponible para instancias iniciadas antes del 11 de enero de 2019

Se ha producido un error 409 al clonar un volumen

Detalles: al clonar un volumen que aún está asociado a una instancia, suprimir el clon y volver a clonar el volumen, puede aparecer el siguiente error:

Volume <volume-OCID> cannot be cloned in parallel while attached

Este error también puede devolver un código de respuesta 409.

Solución alternativa: si está utilizando la API, CLI, SDK o Terraform, debe supervisar el atributo isHydrated del clon suprimido y no crear el segundo clon hasta que este valor de atributo sea true. Si utiliza la consola, supervise el campo Hydrated en la página Detalles de Block Volume para la clonación suprimida y no cree el segundo clon hasta que este valor de campo sea true.

Enlace directo a este problema: se produce un error 409 al clonar un volumen

Fallo al asociar un volumen de inicio de Windows como volumen de datos a otra instancia

Detalles: al asociar un volumen de inicio de Windows como volumen de datos a otra instancia, cuando intenta conectarse al volumen mediante los pasos descritos en Connecting to a Volume, el volumen no se asocia correctamente y puede aparecer el siguiente 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

Error al crear el parámetro volume-group en instancias de Windows con la CLI

Detalles: al utilizar la CLI en Windows para crear un grupo de volúmenes y proporcionar una entrada JSON en línea para el parámetro source-details, la operación falla.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Para resolver este problema, coloque el JSON en línea entre comillas dobles en lugar de comillas simples. También debe omitir las comillas dobles en el propio JSON. Por ejemplo, el siguiente fragmento de código funciona en instancias de Linux:

--source-details '{"type": "volumeIds", 

Para empezar a trabajar en instancias de Windows, cámbielo por:

--source-details "{\"type\": \"volumeIds\", 

Un enlace directo a este problema: Error al crear el parámetro volume-group en instancias de Windows con la CLI

El cambio de tamaño del volumen de inicio falla a la hora de clonar y restaurar desde la copia de seguridad con la CLI

Detalles: al usar la CLI para clonar un volumen de inicio o restaurar un volumen de inicio desde una copia de seguridad, no puede cambiar el tamaño del volumen.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Para solucionar este problema, puede clonar el volumen de inicio o restaurarlo desde una copia de seguridad sin cambiar su tamaño y, a continuación, puede cambiar el tamaño del volumen una vez terminada la clonación o restauración.

Enlace directo a este problema: El cambio de tamaño del volumen de inicio falla a la hora de clonar y restaurar a partir de la copia de seguridad con la CLI

El texto de ayuda de la CLI no es correcto en cuanto a los comandos de creación de volumen y volumen de inicio.

Detalles: el texto de ayuda para la opción size-in-gbs y la opción size-in-mbs son incorrectos para la creación del volumen oci bv y los comandos oci bv boot-volume create CLI. Indica que estas opciones no se pueden aplicar al clonar o restaurar un volumen a partir de una copia de seguridad. Esto es incorrecto, ya que estas opciones permiten especificar cuándo se clona o se restaura un volumen a partir de una copia de seguridad en un volumen de tamaño mayor que el volumen de origen. No puede especificar un valor inferior al tamaño del volumen de origen.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Puede ignorar el texto de ayuda para estas opciones de comandos.

Enlace directo a este problema: El texto de ayuda de la CLI no es correcto en cuanto a los comandos de creación de volumen y volumen de inicio

El atributo bootVolumeSizeInGBs es nulo

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

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Para resolver este problema, llame a GetBootVolume y utilice el atributo sizeInGBs de BootVolume.

Enlace directo a este problema: El atributo bootVolumeSizeInGBs es nulo

Blockchain Platform

Para consultar los problemas conocidos de Blockchain Platform, visite Problemas conocidos.

Certificados

Actualmente, no hay problemas conocidos de certificados.

Cloud Guard

No se puede cambiar la región de informe

Detalles: la región de informe se asigna durante la activación de Cloud Guard. Una vez asignada, este valor no se puede cambiar, incluso al desactivar y activar Cloud Guard.

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

Enlace directo a este problema: No se puede cambiar la región de informe

No hay comprobación de valores para los grupos condicionales

Detalles: las reglas de detector y responsable de respuesta se aplican a un tipo de recurso concreto. Los grupos condicionales permiten especificar recursos concretos de ese tipo que se incluirán o excluirán de la aplicación de una regla.

Escenario 1: puede proporcionar OCID de recurso a un grupo condicional como valores personalizados o en una lista gestionada. Cloud Guard no comprueba la validez de estos valores.

Escenario 2: al agregar un país o región como parámetro de grupo condicional a un detector de actividad, Cloud Guard no comprueba la validez de estos valores.

Solución alternativa: en ambos escenarios anteriores, asegúrese de proporcionar valores válidos. Para obtener una lista de valores válidos de país y región, consulte Uso de grupos condicionales con detectores en Modificación de una receta de detector clonada.

Enlace directo a este problema: No hay comprobación de valores para los grupos condicionales

Cloud Shell

El SDK de Go no puede encontrar automáticamente algunas regiones mientras se ejecuta en Cloud Shell

Detalles: debido a algunas incidencias con una de sus dependencias, la función SDK de Go, que permite a los clientes utilizar automáticamente nuevos dominios que podrían ser desconocidos para el SDK, no funciona desde Cloud Shell.

Si intenta ejecutar código en Cloud Shell que utilice esta función, aparecerá el siguiente mensaje de error:
can not create client, bad configuration: failed to get security token: failed to renew security token: failed to get security token: failed to call: Post "https://<endpoint>/v1/x509": dial tcp: lookup <endpoint> on 127.0.0.11:53: server misbehaving
panicked while retrying operation. Panic was: runtime error: invalid memory address or nil pointer dereference

Solución alternativa: para resolver esta incidencia, active la resolución de regiones mediante el servicio de metadatos de instancia para el SDK de Go. Para obtener más información, consulte: Adición de Regiones

Enlace directo a esta incidencia: El SDK de Go no puede encontrar automáticamente algunas regiones mientras se ejecuta en Cloud Shell

Compliance Documents

Actualmente, no hay problemas conocidos de Compliance Documents.

Recursos informáticos

Aviso grave del núcleo al ejecutar contenedores en Ubuntu 20.04, núcleo 5.13.0-1033.39~20.04.1

Detalles: al ejecutar contenedores en una instancia de Compute que utiliza Ubuntu 20.04, la versión del núcleo linux-oracle-5.13 5.13.0-1033.39~20.04.1, se produce un aviso grave del núcleo. La instancia se bloquea y no se puede acceder a ella. Para obtener más información, consulte La creación de contenedores Docker provoca bucles del núcleo en linux-aws 5.13.0.1028.31~20.04.22.

Solución alternativa: actualice el núcleo a una versión superior ejecutando los siguientes comandos:

sudo apt-get update
sudo apt-get upgrade -y linux-image-oracle

Enlace directo a este problema: Pánico del núcleo al ejecutar contenedores en Ubuntu 20.04, núcleo 5.13.0-1033.39~20.04.1

Las instancias de VM de unidad flexible E3/E4 anteriores no se pueden iniciar después de cambiar el tamaño de la memoria a más de 1010 GB

Detalles: Las instancias de VM de unidad flexible E3/E4 creadas antes del 5 de abril de 2021 no se pueden iniciar si se cambia el tamaño de la memoria a más de 1010 GB. En este caso, verá un error que indica "fallo al iniciar".

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Como solución alternativa, reduzca el tamaño de la memoria a menos de 1010 GB. También puede volver a crear la instancia y, a continuación, cambiar el tamaño de la memoria hasta 1024 GB.

Enlace directo a este problema: Las instancias de VM de unidad flexible E3/E4 anteriores no se pueden iniciar después de cambiar el tamaño de la memoria a más de 1010 GB

La consola muestra Oracle Autonomous Linux disponible como una imagen Siempre gratis

Detalles: Oracle Autonomous Linux no está soportado para instancias informáticas Siempre gratis, pero, en la consola, Oracle Autonomous Linux aparece en la lista de imágenes soportadas para unidades Siempre gratis.

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

Enlace directo a esta incidencia: La consola muestra Oracle Autonomous Linux disponible como imagen Siempre gratis

El DNS no funciona como se espera en las instancias de Oracle Linux

Detalles: en la región Este de EE. UU. (Ashburn), cuando las instancias de Oracle Linux se inician por primera vez después del aprovisionamiento, es posible que el DNS no funcione del modo esperado y es posible que el campo search del archivo /etc/resolv.conf esté incompleto.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Reinicie la instancia o espere a la siguiente renovación de la cesión DHCP. Después de la renovación de la cesión DHCP, la incidencia se resuelve automáticamente. El tiempo de cesión DHCP estándar es de 24 horas, pero varía según la configuración de red.

Enlace directo a esta incidencia: el DNS no funciona como se espera en las instancias de Oracle Linux

Los valores de PCR cambian después del reinicio en Linux 7.x

Detalles: al crear una instancia blindada con Linux 7.x y, a continuación, reiniciar la instancia, los valores de PCR pueden cambiar, haciendo que aparezca el protector rojo.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Algunos valores de PCR cambian en tiempo de ejecución. Ese cambio es esperado. Como solución alternativa, restablezca las medidas doradas.

Enlace directo a esta incidencia: los valores de PCR cambian después del reinicio en Linux 7.x

Las instancias de BM.Standard.A1.160 tienen un rendimiento de red degradado en las aplicaciones que se ejecutan en las CPU del socket 1

Detalles: las instancias con hardware dedicado que utilizan la unidad BM.Standard.A1.160 tienen un rendimiento de red reducido para las cargas de trabajo que se ejecutan en las CPU del socket 1.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. En el caso de las aplicaciones responsables del procesamiento de paquetes de la red, agréguelas a las CPU del socket 0.

Enlace directo a esta incidencia: Las instancias de BM.Standard.A1.160 tienen un rendimiento de red degradado en las aplicaciones que se ejecutan en las CPU del socket 1

Oracle Cloud Agent no envía métricas en instancias de Windows de subredes privadas con solo un gateway de servicio asociado

Detalles: cuando se aprovisiona una instancia informática en Windows en una subred privada con un gateway de servicio asociado, es posible que los plugins de Oracle Cloud Agent no emitan métricas.

Solución alternativa: siga los pasos del artículo de problema conocido de Microsoft: Problemas de conectividad si no está instalado el certificado raíz DigiCert Global Root G2.

Enlace directo a esta incidencia: Oracle Cloud Agent no envía métricas en instancias de Windows de subredes privadas con solo un gateway de servicio asociado

La versión 1.11.0 de Oracle Cloud Agent no se actualiza automáticamente

Detalles: el software de Oracle Cloud Agent no se actualiza automáticamente. Esta incidencia afecta a las siguientes versiones de Oracle Cloud Agent, dependiendo de la imagen en la que esté instalado el software de Oracle Cloud Agent:

  • Windows Server: afecta a la versión 1.11.0.x de Oracle Cloud Agent
  • Oracle Linux 7, Oracle Linux 8, CentOS 7: afecta a las versiones 1.11.0.x y 1.11.1.x de Oracle Cloud Agent

Solución alternativa: actualice manualmente Oracle Cloud Agent a la versión más reciente.

Enlace directo a esta incidencia: La versión 1.11.0 de Oracle Cloud Agent no se actualiza automáticamente

Las instancias de VM.Standard.A1.Flex solo soportan la opción de inicio de redes paravirtualizadas

Detalles: las instancias que utilizan la unidad VM.Standard.A1.Flex con redes asistidas por hardware (SR-IOV) pueden experimentar incidencias de rendimiento y, en casos raros, daños en los datos. Para evitarlo, las imágenes de plataforma para Ampere A1 Compute (aarch64) están configuradas para utilizar únicamente redes paravirtualizadas. Si crea una instancia utilizando una imagen de plataforma y especifica una red asistida por hardware, el inicio fallará con un mensaje similar a Failed to validate instance launch options.

Para las imágenes personalizadas compatibles con Ampere A1 Compute, el lanzamiento se realizará correctamente, pero recomendamos encarecidamente no seleccionar redes asistidas por hardware para evitar posibles incidencias de rendimiento y corrupción de datos.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Al crear una instancia de VM.Standard.A1.Flex mediante una imagen de plataforma, deje que Oracle elija el tipo de inicio de red recomendado. Para las imágenes personalizadas, no utilice redes asistidas por hardware (SR-IOV).

Enlace directo a esta incidencia: Las instancias de VM.Standard.A1.Flex solo soportan la opción de inicio de redes paravirtualizadas

Error de unidad e imagen no válidas al crear instancias de Intel y AMD mediante Terraform

Detalles: al utilizar Terraform para crear una instancia informática de Intel o AMD mediante una imagen de plataforma Linux, la operación puede fallar con el código de error InvalidParameter y un mensaje similar a Shape <nombre_unidad> is not valid for image <OCID_imagen>.

Esto sucede si Terraform identifica la última imagen basada en la imagen display_name. Las imágenes de las unidades de Intel y AMD (arquitectura de procesador x86) tienen nombres similares a las imágenes de las unidades basadas en Arm (arquitectura de procesador aarch64), pero no son compatibles entre las distintas arquitecturas de procesador. Si la última imagen es una imagen aarch64, Terraform selecciona una imagen aarch64 para una unidad x86, lo que provoca el fallo de la operación.

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

Como solución alternativa, modifique los siguientes archivos de Terraform:
  • /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/global/global.datasources.tf
  • /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/pd/pd.datasources.tf
  • /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/nonpd/nonpd.datasources.tf
  • /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/globalDR/globalDR.datasources.tf
  • /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/pdDR/pdDR.datasources.tf

En los archivos, actualice la expresión regular que identifica la imagen para filtrar todas las imágenes de las unidades basadas en Arm. Las imágenes de las unidades basadas en Arm incluyen "aarch" en el nombre de imagen.

Por ejemplo, para las imágenes de Oracle Linux 8, realice la siguiente actualización:

  • Expresión regular actual: values = ["^.*Oracle-Linux-8[.]*[\\d]*-[^G].*$"]
  • Expresión regular actualizada: values = ["^.*Oracle-Linux-8[.][0-9]*-[\\d]{4}.[\\d]{2}.[\\d]{2}-[\\d]*$"]

Enlace directo a esta incidencia: Error de unidad e imagen no válidas al crear instancias de Intel y AMD mediante Terraform

El servicio OS Management no puede gestionar las imágenes de Oracle Linux Cloud Developer

Detalles: el servicio OS Management no puede gestionar las instancias que utilizan la imagen de Oracle Linux Cloud Developer.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. No instale el agente del servicio de OS Management (osms-agent) en instancias de Oracle Linux Cloud Developer.

Enlace directo a esta incidencia: El servicio OS Management no puede gestionar las imágenes de Oracle Linux Cloud Developer

Error de bucketName no válido al importar o exportar una imagen personalizada

Detalles: al intentar importar o exportar una imagen personalizada de un cubo de Object Storage, se puede producir un error similar al siguiente:

Invalid bucketName: Specified namespace or bucket to export image does not exist

Este error se produce para los usuarios federados y para los usuarios que se autentican con principales de instancia vinculados a un grupo dinámico.

Solución alternativa: para evitar este problema, cree una solicitud autenticada previamente y, a continuación, utilice la solicitud autenticada previamente para importar o exportar la imagen. Las solicitudes autenticadas previamente ofrecen un modo de permitir a los usuarios acceder a un cubo o a un objeto sin tener sus propias credenciales. Para obtener más información sobre cómo crear y utilizar solicitudes autenticadas previamente, consulte Uso de solicitudes autenticadas previamente y Solicitudes autenticadas previamente.

Enlace directo a esta incidencia: Error de bucketName no válido al importar o exportar una imagen personalizada

No se ha podido crear la instancia a partir de la copia de seguridad del volumen de inicio

Detalles: al intentar crear una instancia a partir de una copia de seguridad de volumen de inicio en la consola, se puede producir un error similar al siguiente:

Se ha producido un error al cargar la imagen de origen para la creación de la instancia. Es posible que no tenga permiso para acceder a esta imagen o que esta esté en una región diferente. Si la imagen está en una región diferente, debería poder iniciar la instancia.

Este error se puede producir si también se ha suprimido el compartimento que contenía los metadatos de imagen suprimidos utilizados para la copia de seguridad del volumen de inicio.

Solución alternativa: si se ha suprimido el compartimento, utilice la CLI para crear la instancia. Para obtener información sobre el uso de la CLI, consulte Interfaz de línea de comandos (CLI).

Para crear una instancia a partir de un volumen de inicio mediante la CLI, abra un símbolo del sistema y ejecute el comando launch. Para iniciar una instancia mediante una imagen o un volumen de inicio, incluya el parámetro --source-details.

oci compute instance launch --availability-domain <AVAILABILITY_DOMAIN> --compartment-id, -c <COMPARTMENT_OCID> --shape <SHAPE> --subnet-id <SUBNET_ID> --source-details <file://path/to/file>

Enlace directo a esta incidencia: No se ha podido crear la instancia a partir de la copia de seguridad del volumen de inicio

No se ha podido eliminar la instancia de la reserva de capacidad mediante Terraform

Detalles: no se puede eliminar una instancia de una reserva de capacidad mediante Terraform.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Como solución alternativa, utilice la consola, la CLI o el SDK para eliminar la instancia de la reserva de capacidad.

Enlace directo a esta incidencia: No se ha podido eliminar la instancia de la reserva de capacidad mediante Terraform

La creación de más de 30 configuraciones de capacidad genera un error interno

Detalles: al crear más de 30 configuraciones de capacidad en una reserva de capacidad, se produce un error interno. Una vez que se produce el error, no es posible iniciar instancias en la reserva de capacidad.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Para evitar este problema, no agregue más de 30 configuraciones de capacidad a su reserva de capacidad.

Enlace directo a esta incidencia: La creación de más de 30 configuraciones de capacidad genera un error interno

Límites de servicio de reserva de capacidad imprecisos

Detalles: los números del límite de servicio <unidad>-core-reserved-count son inexactos. El número de la columna Límite de servicio puede mostrar 1.000.000.000 o N/A. El número de la columna Disponible puede mostrar 1.000.000.000 menos el número de la columna Uso o N/A. El valor 1.000.000.000 representa un valor máximo y puede variar.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Para conocer los límites de servicio precisos, consulte Reservas de capacidad informática.

Enlace directo a esta incidencia: Límites de servicio de reserva de capacidad imprecisos

No hay categoría de servicio para reservas de capacidad al solicitar aumentos del límite de servicio

Detalles: al solicitar un aumento del límite de servicio, el menú Categoría de servicio no incluye una categoría para las reservas de capacidad.

Solución alternativa: en el formulario Solicitar actualizaciones de límites de servicio:

  • En Categoría de servicio, seleccione Otros.
  • En Recurso, seleccione Otros límites.
  • En el campo Motivo de solicitud, introduzca el límite específico que se va a aumentar.

Enlace directo a esta incidencia: No hay categoría de servicio para reservas de capacidad al solicitar aumentos del límite de servicio

Fallo de Windows Server en instancias de VM.Standard.E3.Flex de más de 32 OCPU

Detalles: al crear una instancia de Windows Server con la unidad VM.Standard.E3.Flex, si asigna más de 32 OCPU a la instancia, esta no se inicia.

Si cambia el tamaño de una instancia de Windows Server existente en una unidad VM.Standard.E3.Flex a más de 32 OCPU, la instancia experimenta un error de detención (pantalla azul).

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Para solucionar esta incidencia, cambie el tamaño de la instancia de modo que tenga 32 OCPU o menos.

Enlace directo a esta incidencia: Windows Server falla en instancias de VM.Standard.E3.Flex de más de 32 OCPU

La creación del pool de instancias falla cuando los recursos incluyen etiquetas por defecto

Detalles: al intentar crear un pool de instancias, la creación del pool de instancias falla con el error "Authorization failed or requested resource not found". Esto sucede porque los recursos utilizados por el pool de instancias contienen etiquetas por defecto y el usuario no tiene permiso para el espacio de nombres de etiqueta.

Solución alternativa: para solucionar este problema, agregue una sentencia de política que otorgue el permiso de grupo de usuarios del pool de instancias al espacio de nombres de etiqueta Oracle-Tags:

Allow group InstancePoolUsers to use tag-namespaces in tenancy where target.tag-namespace.name = 'oracle-tags'

Para obtener más información sobre las políticas, consulte Permitir a los usuarios gestionar configuraciones de instancias de Compute, pools de instancias y redes de cluster. Para obtener más información sobre las etiquetas por defecto, consulte Descripción de valores por defecto de etiquetas automáticas.

Enlace directo a esta incidencia: La creación del pool de instancias falla cuando los recursos incluyen etiquetas por defecto

Error de capacidad de host insuficiente al crear instancias informáticas

Detalles: al intentar crear una instancia, el inicio de la instancia falla con el código de error InternalError y un mensaje similar a Out of host capacity. Esto ocurre debido a la falta de capacidad de infraestructura física para la unidad en el dominio de errores y el dominio de disponibilidad solicitados.

Solución alternativa: la capacidad suele estar disponible en breve para la mayoría de las unidades. Para resolver esta incidencia, realice lo siguiente:

  • Si utiliza una unidad de generación anterior, cree la instancia utilizando una unidad de generación actual en su lugar. La capacidad está limitada para las unidades de generación anteriores.
  • Cree la instancia en un dominio de disponibilidad diferente.
  • Cree la instancia sin especificar un dominio de errores.
  • Cree la instancia utilizando una unidad más pequeña o una unidad de una serie diferente.
  • Espere unos minutos y vuelva a intentarlo.

Enlace directo a esta incidencia: Error de capacidad de host insuficiente al crear instancias informáticas

El cifrado en tránsito de una asociación de volumen de inicio se puede editar cuando la imagen no lo soporta

Detalles: cuando el valor de cifrado en tránsito de una imagen es nulo, el valor de cifrado en tránsito de una instancia creada a partir de la imagen se puede definir en un valor no nulo.

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

Enlace directo a este problema: El cifrado en tránsito de una asociación de volumen de inicio se puede editar cuando la imagen no lo soporta

Los plugins de Oracle Cloud Agent no están disponibles en los controladores de dominio

Detalles: cuando se utiliza una instancia de Windows Server como controlador de dominio, las funciones que dependen de Oracle Cloud Agent, como el servicio Monitoring y el servicio OS Management, no están disponibles. Esto ocurre porque los servicios instalados por Oracle Cloud Agent en Windows se ejecutan con cuentas virtuales, pero las cuentas virtuales no están soportadas en el ámbito del controlador de dominio.

Solución alternativa: desactive el actualizador de Oracle Cloud Agent ejecutando el siguiente comando de PowerShell como administrador:
net stop OCAU

(Para actualizar Oracle Cloud Agent, puede descargar e instalar manualmente la versión más reciente).

Para cada función de Oracle Cloud Agent que desee usar, utilice services.msc para actualizar el usuario que se ejecuta para el servicio NT aplicable a fin de utilizar un servicio de dominio o una cuenta de usuario. A continuación, agregue el usuario al grupo local del dominio aplicable, como se muestra en la siguiente tabla:

Función de Oracle Cloud Agent Usuario del servicio NT Tipo de cuenta de destino Grupo local del dominio de destino
Servicio NT de Oracle Cloud Agent (incluido el plugin de Compute Instance Monitoring) NT Service\OCA Cuenta de servicio o cuenta de usuario de dominio Grupos de supervisión del rendimiento
Plugin Compute Instance Run Command NT Service\OCARUN Cuenta de servicio del dominio o cuenta de usuario del dominio que tiene privilegios administrativos locales Grupo de administradores
Plugin Custom Logs Monitoring NT Service\OCAUM Cuenta de servicio del dominio o cuenta de usuario del dominio que tiene privilegios administrativos locales Grupo de administradores
Plugin OS Management Service Agent NT Service\OCAOSMS Cuenta de servicio del dominio o cuenta de usuario del dominio que tiene privilegios administrativos locales Grupo de administradores
Actualizador de Oracle Cloud Agent NT Service\OCAU Cuenta de servicio del dominio o cuenta de usuario del dominio que tiene privilegios administrativos locales Grupo de administradores

Enlace directo a esta incidencia: Los plugins de Oracle Cloud Agent no están disponibles en los controladores de dominio

Tamaño de copia de seguridad de volumen de inicio mayor de lo esperado

Detalles: Debido a un cambio reciente en la forma en que el servicio de recurso informático gestiona las imágenes, al crear una copia de seguridad de volumen de inicio, la copia de seguridad es mayor de lo esperado. En algunos casos, la copia de seguridad de volumen de inicio puede ser mayor que el tamaño del volumen de inicio.

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

Enlace directo a este problema: Tamaño de copia de seguridad de volumen de inicio mayor de lo esperado

Problemas intermitentes con acceso SSH, consultas de DNS y acceso al servicio de metadatos

Detalles:

Es posible que se produzcan errores intermitentes con alguno de los siguientes valores para la instancia informática:

  • Conexión a la instancia mediante SSH.

  • Realización de una consulta de DNS

  • Acceso al servicio de metadatos en http://169.254.169.254/*.

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

Para resolver este problema temporalmente, ejecute el siguiente comando en la instancia:

sudo ethtool -G ens3 tx 513 && sudo ethtool -G ens3 tx 512

Enlace directo a este problema: Problemas intermitentes con acceso SSH, consultas de DNS y acceso al servicio de metadatos

Los volúmenes conectados mediante iSCSI no se conectan al reiniciar

Detalles: si realizó una actualización de yum en su instancia mediante los repositorios de Oracle Linux 7 yum entre el 22 de marzo de y el 9 de abril de 2019, es posible que se produzca un problema en el que los volúmenes de bloques asociados a iSCSI no estén disponibles después de reiniciar la instancia.

Solución alternativa: esto ocurre cuando la instancia no está configurada para iniciar sesión automáticamente en nodos iSCSI al reiniciar. Para configurar el inicio de sesión automático, actualice la versión del paquete iscsi-initiator-utils ejecutando el siguiente comando:

sudo yum update -y iscsi-initiator-utils-6.2.0.874-10.0.7.el7

Enlace directo a este problema: Los volúmenes iSCSI-volumes no se conectan al reiniciar

El servicio iscsid se debe configurar para que se reinicie automáticamente

Detalles: Oracle Cloud Infrastructure soporta volúmenes en bloque e inicio remoto asociados con iSCSI a instancias informáticas. Estos volúmenes iSCSI asociados los gestiona el servicio iscsid. Cuando se detiene este servicio por algún motivo, por ejemplo, este se bloquea o un administrador del sistema lo detiene sin darse cuenta, es importante que el servicio iscsid se reinicie automáticamente para aumentar la estabilidad de la infraestructura.

Solución alternativa: consulte Updating the Linux iSCSI Service to Restart Automatically y vea una guía paso a paso para configurar el servicio iscsid de manera que se reinicie automáticamente.

Enlace directo a este problema: El servicio iscsid se debe configurar para que se reinicie automáticamente

Las instancias de máquina virtual (VM) se inician con un volumen de inicio asociado iSCSI al especificar un valor para el atributo ipxeScript

Detalles: al especificar un valor para el atributo ipxeScript de la instancia para una instancia de máquina virtual (VM), la instancia se iniciará con un anexo iSCSI para el volumen de inicio en lugar de un anexo paravirtualizado.

Enlace directo a este problema: Las instancias de máquina virtual (VM) se inician con un volumen de inicio asociado iSCSI cuando se especifica un valor para el atributo ipxeScript

Las instancias bloquean el sistema después de ejecutar firewall-cmd-- reload

Detalles: una instancia informática puede experimentar un bloqueo del sistema después de ejecutar el siguiente comando para volver a cargar el firewall:

firewall-cmd --reload

Volver a cargar el firewall con este comando en una instancia en ejecución puede hacer que el volumen de inicio de la instancia pierda la conexión iSCSI y se bloquee, según el orden en que se recargan las reglas de firewall.

Solución alternativa: para evitar que esto ocurra, no utilice el parámetro reload para firewall-cmd. En su lugar, ejecute el comando firewall-cmd dos veces con el parámetro permanent la primera vez que lo llame para asegurarse de que no pierde la conectividad de iSCSI.

Por ejemplo:

firewall-cmd --permanent
firewall-cmd

Enlace directo a este problema: el sistema de experiencia de las instancias se bloquea después de ejecutar firewall-cmd --reload

El icono de red en instancias de Windows 2016 muestra un estado incorrecto

Detalles: en las instancias que ejecutan Windows 2016, aparece una "x" roja en el icono de conexión de red de la barra de tareas, aunque no hay ningún problema con la conectividad de red de la instancia.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Si recicla el proceso explorer.exe, el icono mostrará el estado correcto. Sin embargo, no es una corrección permanente; la "x" roja volverá a aparecer al reiniciar la instancia.

Enlace directo a este problema: El icono de red de las instancias de Windows 2016 muestra un estado incorrecto

Las instancias que ejecutan la versión de octubre de 2018 de Ubuntu 18.04 experimentan un bloqueo del sistema

Detalles: iSCSId está desactivado por defecto en la versión de octubre de 2018 de la imagen de plataforma Ubuntu 18.04, por lo que las instancias que utilizan este sistema operativo pueden experimentar un bloqueo del sistema si se produce una pausa momentánea en la comunicación de iSCSI.

Solución alternativa: para solucionar este problema, ejecute el siguiente comando para activar iSCSId en la instancia:

sudo systemctl enable iscsid && sudo systemctl start iscsid

Enlace directo a este problema: Las instancias que ejecutan la versión de octubre de 2018 de Ubuntu 18.04 experimentan un bloqueo del sistema

El atributo kmsKeyId es nulo

Detalles: al llamar a las operaciones GetInstance o ListInstances, el atributo kmsKeyId de InstanceSourceViaImageDetails es nulo.

Solución alternativa: para resolver este problema, llame a la operación de GetBootVolume y recupere el valor del atributo kmsKeyId de BootVolume.

Enlace directo a este problema: El atributo kmsKeyId es nulo

La instancia de Ubuntu no se puede reiniciar después de activar Uncomplicated Firewall (UFW)

Detalles: después de activar UFW en una instancia informática que ejecuta Ubuntu, la instancia no se reinicia correctamente.

Solución alternativa: no utilice UFW para editar reglas de firewall. Las imágenes de plataforma están preconfiguradas con reglas de firewall para permitir que las instancias establezcan conexiones salientes a los volúmenes en bloque y de inicio de la instancia. Para obtener más información, consulte Reglas esenciales del firewall. UFW puede eliminar estas reglas de modo que, durante un reinicio, la instancia no pueda conectarse a los volúmenes de inicio y bloqueo.

Para modificar o agregar nuevas reglas de firewall, actualice el archivo /etc/iptables/rules.v4 en su lugar. Las modificaciones en las reglas de firewall se aplicarán después de reiniciar. Para que las reglas se apliquen inmediatamente, ejecute lo siguiente:

$ sudo su -
# iptables-restore < /etc/iptables/rules.v4

Enlace directo a este problema: La instancia falla al reiniciar después de activar UFW

No se ha podido conectar a la instancia iniciada desde la nueva imagen personalizada de Windows generalizada

Detalles: no puede conectarse a una instancia iniciada desde una imagen de Windows personalizada recién creada.

Solución alternativa: este es el resultado del proceso de generalización de la imagen que falla debido a un problema con Sysprep después de actualizar a WMF 5.0. Para resolver este problema, siga los pasos que se describen en Sysprep falla después de la instalación de WMF 5.0.

Enlace directo a este problema: No se ha podido conectar a la instancia iniciada desde la nueva imagen personalizada de Windows

La imagen personalizada creada desde la instancia de Windows puede hacer que Windows se inicie en modo seguro

Detalles: después de crear una imagen personalizada de Windows, la instancia o instancias iniciales iniciadas desde la imagen pueden iniciarse en modo seguro o en modo de recuperación. Las instancias iniciadas en cualquier modo no responderán al protocolo de escritorio remoto. Esto puede ocurrir cuando la instancia no puede cerrarse por completo antes de que se realice la imagen personalizada. Puede acceder a la instancia conectándose a la consola de VNC, mediante los pasos descritos en Conexión a la Consola de VNC.

Solución alternativa: para resolver este problema, antes de crear la imagen personalizada, conéctese e inicie sesión en la instancia mediante el protocolo de escritorio remoto e inicie el cierre desde allí.

El enlace directo a este problema: La imagen personalizada creada a partir de la instancia de Windows puede hacer que Windows se inicie en modo seguro

Las instancias iniciadas desde imágenes personalizadas de Ubuntu 16 necesitan configuración de red personalizada

Detalles: al importar Ubuntu 16 LTS y versiones posteriores, el protocolo de configuración dinámica de host no puede obtener la configuración de la puerta de enlace y, por lo tanto, no puede configurar una ruta predeterminada a la puerta de enlace en la VNIC.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Para resolver este problema, configure de forma estática la ruta por defecto después de la importación. Para ello, siga estos pasos:

  1. Cree el siguiente script:

    #! /bin/bash -e
    								ROUTER_IP=$(/usr/bin/curl --silent http://169.254.169.254/opc/v1/vnics/ | grep "virtualRouterIp" | grep -oP "\d+\.\d+\.\d+\.\d+" | head -n 1)
    								echo "Found Router IP $ROUTER_IP"
    
    							ip route add default via $ROUTER_IP

    y guárdelo en /usr/local/bin/configure_default_route.sh

  2. Ejecute el siguiente comando para que se pueda ejecutar la secuencia de comandos:

    sudo chmod +x /usr/local/bin/configure_default_route.sh
  3. Agregue lo siguiente a /etc/network/interfaces para que se inicie cada vez que arranque el sistema:

    # OCI Emulated boot network interface
    								auto ens3
    								iface ens3 inet dhcp
    							post-up /usr/local/bin/configure_default_route.sh

Enlace directo a este problema: Las instancias iniciadas desde imágenes personalizadas de Ubuntu 16 necesitan configuración de red personalizada

Se ha producido una interrupción de la desconexión de VNIC secundario en algunas instancias iniciadas desde imágenes personalizadas importadas

Detalles: al desasociar un VNIC secundario de instancias iniciadas desde imágenes personalizadas importadas, la operación puede interrumpirse.

Solución alternativa: el módulo de conexión en caliente, acpiphp, se debe cargar para que los VNIC secundarios se desasocien correctamente en Linux. Si un VNIC no se desconecta, ejecute el comando lsmod para mostrar la lista de módulos cargados y compruebe si aparece acpiphp. Si no lo ve en la lista, cargue el módulo ejecutando el siguiente comando:

modprobe acpiphp

Vuelva a intentar la operación de desasociación para el VNIC secundario. Es posible que deba reiniciar el sistema para que la operación se realice correctamente.

Enlace directo a este problema: Se ha producido una interrupción de la desconexión de VNIC secundario en algunas instancias iniciadas desde imágenes personalizadas importadas

Es posible que el VNIC secundario no funcione en imágenes anteriores de CentOS, Oracle Linux y RHEL

Detalles: la función de VNIC secundario no se admite en los siguientes sistemas operativos debido a un bug en el núcleo:

  • CentOS 4, 5

  • Oracle Linux 4, 5

  • RHEL 4, 5

Los VNIC secundarios no funcionarán después de un reinicio.

Enlace directo a este problema: Es posible que el VNIC secundario no funcione en imágenes anteriores de CentOS, Oracle Linux y RHELL

Error de imagen no válida al exportar una imagen

Detalles: al intentar exportar una imagen, la exportación falla y muestra un error que indica que la imagen no es válida. Este error solo se produce en la región oeste de EE. UU. (Phoenix).

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

  1. Inicie una nueva instancia basada en la imagen que desea exportar y especifique una de las siguientes formas de la imagen:

    • BM.Standard1.36

    • BM.DenseIO1.36

    • VM.DenseIO1.4

    • VM.DenseIO1.8

    • VM.DenseIO1.16

  2. Cree una imagen personalizada siguiendo los pasos descritos en Para crear una imagen personalizada.

Una vez creada la imagen personalizada, puede exportar esta nueva imagen.

Enlace directo a este problema: Error de imagen no válida al exportar una imagen

Se produce un error de autenticación al conectarse a la consola serie para una instancia con hardware dedicado

Detalles: al establecer una conexión de shell seguro con una instancia con hardware dedicado, el cliente de shell seguro debe enviar la clave correcta en el primer intento. Si tiene más de una clave de SSH configurada en ~/.ssh o en el archivo ~/.ssh/config, es posible que el cliente no envíe la clave correcta en el primer intento de autorización y que aparezca el siguiente mensaje de error:

Received disconnect from UNKNOWN port 65535:2: Too many authentication failures.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Para solucionar este problema, modifique la cadena de conexión del comando de shell seguro para utilizar el indicador configfile, -F para sustituir el archivo de configuración predeterminado, la opción -o IdentitiesOnly=yes para forzar al cliente de shell seguro a utilizar la clave especificada, y el indicador de archivo de identidad -i para especificar la clave de shell seguro que se debe utilizar, como se muestra en el siguiente ejemplo:

ssh -F /dev/null -o IdentitiesOnly=yes -i /<path>/<ssh_key> -o ProxyCommand='ssh -i /<path>/<ssh_key> -W %h:%p -p 443...

Enlace directo a este problema: Se produce un error de autenticación al conectarse a la consola serie para una instancia con hardware dedicado

Tiempo de sistema incorrecto en las instancias de máquina virtual de Windows cuando se cambia la zona horaria predeterminada

Detalles: si cambia el valor predeterminado de la zona horaria en las instancias de máquina virtual de Windows, cuando la instancia se reinicia o se sincroniza con el reloj de hardware, la hora del sistema volverá a la hora predeterminada de la zona horaria. Sin embargo, la configuración de la zona horaria permanecerá definida en la nueva zona horaria, por lo que el reloj del sistema será incorrecto.

También verá los eventos en el log de eventos, que indica que la hora del sistema se cambió con los siguientes detalles:

Change Reason: System time synchronized with the hardware clock.

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

  1. Abra el Editor de registro y navegue a:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
  2. Cree una nueva clave DWORD denominada RealTimeIsUniversal y defina el valor en 1.

  3. Reinicie la instancia.
  4. Restablezca la hora y la zona horaria manualmente.

Enlace directo a este problema: Hora del sistema incorrecta en las instancias de máquina virtual de Windows al cambiar la zona horaria predeterminada

Las conexiones de la consola serie no funcionan para instancias anteriores

Detalles de instancia de máquina virtual: solo puede crear conexiones de consola serie a instancias de máquina virtual (VM) iniciadas a partir del 26 de agosto de 2017.

Detalles de instancia con hardware dedicado: solo puede crear conexiones de consola serie a instancias con hardware dedicado iniciadas el 21 de octubre de 2017 o después.

Solución alternativa: si necesita acceso de la consola serie a una instancia iniciada antes de las fechas especificadas para las instancias de máquina virtual y hardware dedicado, puede solucionar este problema creando una imagen personalizada de la instancia. Al iniciar una nueva instancia basada en la imagen personalizada, esta tendrá acceso a la consola serie. Para obtener más información sobre la creación de una imagen personalizada, consulte Gestión de imágenes personalizadas.

Enlace directo a este problema: Las conexiones de la consola serie no funcionan para instancias anteriores

Parámetros listImage inactivos y campos de respuesta de imagen faltantes

Detalles: la operación ListImages de la API de Recursos informáticos incluye parámetros para el filtrado del servidor en operatingSystem y operatingSystemVersion. Sin embargo, estos parámetros están actualmente inactivos. Además, la documentación del objeto de respuesta de imagen incluye los atributos de operatingSystem y operatingSystemVersion, pero el objeto no devuelve estos campos.

Solución alternativa: el nombre mostrado para las imágenes de plataforma incluye el sistema operativo y la versión del sistema operativo, por ejemplo, "Oracle- Linux-7.2-2016.09.18-0". "Oracle Linux" es el sistema operativo y la versión es "7.2".

Somos conscientes de la omisión y planificamos dar soporte a estos parámetros y atributos.

Enlace directo a este problema: Parámetros listImage inactivos y campos de respuesta de imagen faltantes

El reinicio de la instancia falla si el servicio de gestor de red está instalado

Detalles: si el servicio de gestor de red está instalado, una instancia puede fallar al reiniciar.

Solución alternativa: si el servicio de gestor de red no es necesario, puede desinstalarlo. Si se necesita el servicio del gestor de red, modifique el archivo de configuración de la interfaz de red antes de reiniciar la instancia. Defina la clave de configuración de NM_CONTROLLED en "no":

NM_CONTROLLED="no"

Normalmente, el archivo de configuración de la interfaz de red se encuentra en:

/etc/sysconfig/network-scripts/ifcfg-<interface_name>

Enlace directo a este problema: El reinicio de la instancia falla si el servicio del gestor de red está instalado

Los caracteres no ASCII del nombre de la instancia pueden producir errores de inicio de Windows

Detalles: cuando el nombre de una instancia de Windows incluye caracteres que no son ASCII, la instancia puede fallar al iniciarse. Esto sucede porque el nombre de la instancia se utiliza para definir el nombre de la computadora de Windows durante la creación de la instancia. Windows restringe los caracteres permitidos en los nombres de computadoras y los caracteres que no sean ASCII pueden provocar fallos en la creación de instancias de Windows.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Para solucionar esta incidencia temporalmente, asigne un nombre a las instancias de Windows utilizando solo estos caracteres ASCII: letras mayúsculas (A-Z), letras minúsculas (a-z), números (0-9) y guiones (-).

Enlace directo a este problema: Los caracteres no ASCII del nombre de la instancia pueden provocar fallos de inicio de Windows.

Fallo de las actualizaciones automáticas de Oracle Ksplice con algunas configuraciones de red de FastConnect

Detalles: algunas configuraciones de red de FastConnect impiden las actualizaciones automáticas de parches de utilidades como Oracle Ksplice.

Solución alternativa: en el archivo /etc/uptrack/uptrack.conf, sustituya todas las instancias de:
oraclecloud-updates-ksplice.oracle.com
por:
updates.ksplice.<region>.oci.oraclecloud.com 
Por ejemplo, si la región principal es Oeste de EE. UU. (Phoenix), sustituya:
oraclecloud-updates-ksplice.oracle.com
por:
updates.ksplice.us-phoenix-1.oci.oracle.com

Esta solución alternativa se aplica a gateways de servicio. No se aplica a puntos finales privados.

Enlace directo a este problema: Fallo de las actualizaciones automáticas de Oracle Ksplice con algunas configuraciones de red de FastConnect

El indicador que falta es necesario para el servicio OS Management para las instancias creadas antes de septiembre de 2019

Detalles: al utilizar el servicio OS Management en instancias de Oracle Linux creadas antes de septiembre de 2019, la página Detalles de instancia puede indicar incorrectamente que el servicio OS Management está activado (Oracle Cloud Management Agent: activado) cuando el servicio no está activado.

Este problema afecta a las instancias creadas antes de definir el indicador isManagementDisabled en los metadatos de las instancias informáticas. Debido a que este indicador no está presente, los metadatos de estas instancias no se han definido correctamente para el servicio OS Management.

Solución alternativa: para resolver este problema, defina el indicador isManagementDisabled en false:

  1. En la configuración del agente para la instancia, defina la opción isManagementDisabled en false:

    oci compute instance update --instance-id <instance_OCID> --agent-config '{"isManagementDisabled": false, "isMonitoringDisabled": false}'
  2. Utilice la CLI para verificar que se ha actualizado el indicador:

    oci compute instance get --instance-id <instance_OCID>

    En la salida, el indicador actualizado aparece como "is-management-disabled": false.

    {
      "data":
        "agent-config": {
          "is-management-disabled": false,
          "is-monitoring-disabled": false
        },
    ...
    }
  3. Conéctese a la instancia mediante SSH y, a continuación, utilice cURL para llamar al servicio de metadatos de la instancia y verificar que el indicador se ha actualizado en la instancia informática:

    curl http://169.254.169.254/opc/v1/instance/

    En la salida, el indicador actualizado aparece como "managementDisabled" : false.

    {
      ...
      "agentConfig" : {
        "monitoringDisabled" : false,
        "managementDisabled" : false
      }
    }

Enlace directo a este problema: El indicador que falta es necesario para el servicio OS Management para las instancias creadas antes de septiembre de 2019

RESUELTO: No se han podido crear instancias con unidades VM.Standard3.Flex y BM.Standard3.64

Detalles: al intentar crear instancias con unidades VM.Standard3.Flex y BM.Standard3.64, puede que falle la creación de la instancia o que el ancho de banda de red disponible no coincida con el ancho de banda de red documentado.

Solución alternativa: este problema ya está resuelto.

Enlace directo a esta incidencia: RESUELTO: No se han podido crear instancias con unidades VM.Standard3.Flex y BM.Standard3.64

RESUELTO: se muestra un tamaño de almacenamiento incorrecto para algunas unidades

Detalles: para la siguiente lista de unidades de computación, se muestra un valor incorrecto para el tamaño de las unidades NVMe en la consola devuelto por la operación de API ListShapes.

  • BM.DenseIO1.36
  • BM.DenseIO2.52
  • BM.GPU4.8
  • BM.HighIO1.36
  • BM.HPC2.36
  • VM.DenseIO1.4
  • VM.DenseIO2.8

Solución alternativa: este problema ya está resuelto.

Enlace directo a esta incidencia: RESUELTA: se muestra un tamaño de almacenamiento incorrecto para algunas unidades

RESUELTA: la imagen de HPC de Marketplace no soporta unidades Optimized3 en redes de cluster RDMA

Detalles: la imagen de HPC de Marketplace se ha creado para unidades de la instancia BM.HPC2 y no es compatible con las nuevas unidades BM.Optimized3.

Solución alternativa: este problema ya está resuelto.

Enlace directo a esta incidencia: RESUELTA: la imagen de HPC de Marketplace no soporta unidades Optimized3 en redes de cluster RDMA

RESUELTO: El servicio OS Management no puede gestionar las imágenes de Oracle Autonomous Linux

Detalles: el servicio OS Management no puede gestionar las instancias que utilizan la imagen de Oracle Autonomous Linux.

Solución alternativa: esta incidencia se resuelve comenzando por la imagen de plataforma de Oracle Autonomous Linux de agosto de 2021.

Enlace directo a este problema: El servicio OS Management no puede gestionar las imágenes de Oracle Autonomous Linux

RESUELTA: las conexiones de la consola de VNC en las instancias de Ampere A1 Compute son de solo lectura

Detalles: cuando se crea una conexión de la consola de VNC a una instancia que utiliza la unidad VM.Standard.A1.Flex o la unidad BM.Standard.A1.160, la conexión de consola es de solo lectura.

Solución alternativa: este problema ya está resuelto.

Enlace directo a esta incidencia: RESUELTA: las conexiones de la consola de VNC en las instancias de Ampere A1 Compute son de solo lectura

Consola

El bug en el explorador de Firefox puede hacer que la Consola no se cargue

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

Motor de contenedor para Kubernetes

Propiedades de nodo de trabajador no sincronizadas con propiedades del pool de nodos actualizadas

Detalles: las propiedades de los nuevos nodos de trabajador que se inician en un pool de nodos no reflejan los últimos cambios de las propiedades del pool de nodos. La causa probable es el uso de los atributos quantityPerSubnet y subnetIds en desuso al utilizar la operación de API UpdateNodePoolDetails para actualizar las propiedades del pool de nodos.

Soluciones alternativas: realice una de las siguientes acciones:
  • Comience a utilizar el atributo nodeConfigDetails al utilizar la operación de API UpdateNodePoolDetails. En primer lugar, ajuste el pool de nodos a 0 mediante quantityPerSubnet. A continuación, deje de utilizar los atributos subnetIds y quantityPerSubnet y utilice el atributo nodeConfigDetails en su lugar.
  • Póngase en contacto con los Servicios de soporte Oracle para reiniciar el componente backend responsable de la sincronización (el componente inquilino-agente).

Enlace directo a este problema: Propiedades de nodo de trabajador no sincronizadas con propiedades del pool de nodos actualizadas

No se puede iniciar el panel de Kubernetes

Detalles: cuando inicia el panel de control de Kubernetes, en algunas situaciones puede encontrar mensajes de error "net/http: TLS handshake timeout" y "connection reset by peer" en el explorador web. Este problema solo se ha observado en las agrupaciones creadas recientemente que ejecutan Kubernetes versión 1.11. Para obtener más información sobre un problema relacionado con Kubernetes, consulte https://github.com/kubernetes/dashboard/issues/3038.

Solución alternativa:

  1. En una ventana de terminal, escriba:

    $ kubectl -n kube-system port-forward svc/kubernetes-dashboard 8443:443
  2. En el explorador web, vaya a https://localhost:8443

Enlace directo a este problema: No se ha podido iniciar el panel de control de Kubernetes

No se ha podido acceder a Helm en cluster

Detalles: cuando utiliza un token de Kubeconfig versión 2.0.0 para acceder a las versiones de Helm/Tiller anteriores a la versión 2.11, recibirá uno de los siguientes errores:

  • Error: no autorizado
  • Error: no se pudo obtener el cliente de Kubernetes: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1beta1"

Solución alternativa: actualice Helm/Tiller de la siguiente manera:

  1. En una ventana de terminal, descargue una versión de token 1.0.0 de Kubeconfig mediante la introducción del siguiente comando:

    $ oci ce cluster create-kubeconfig --token-version=1.0.0 --cluster-id=<cluster_ocid>
  2. Identifique la clave de región que se utilizará para especificar el registro de Oracle Cloud Infrastructure Registry en la región del cluster (consulte Disponibilidad por región). Por ejemplo, si el cluster está en Este de EE. UU. (Ashburn), iad es la clave de región que se utilizará para especificar el registro en dicha región.

  3. Actualice Tiller introduciendo el siguiente comando:

    $ helm init --upgrade -i <region-key>.ocir.io/odx-oke/oke-public/tiller:v2.14.3

    donde <region-key> es la clave que ha identificado en el paso anterior.

  4. En un explorador, navegue a https://helm.sh/docs/using_helm/#installing- the-helm-client y siga las instrucciones para descargar e instalar el binario del cliente Helm.

  5. Después de actualizar Helm/Tiller, descargue una versión del token de Kubeconfig 2.0.0 introduciendo el siguiente comando:

    $ oci ce cluster create-kubeconfig --token-version=2.0.0 --cluster-id=<cluster_ocid>

Enlace directo a este problema: No se ha podido acceder a Helm en el cluster

Algunas funciones de Kubernetes (por ejemplo, el servidor de métricas) no se pueden comunicar con el kubelet a través de http/2

Detalles: la versión de Motor de contenedor para Kubernetes 1.8.0 incluía una mejora de seguridad para la solidez del cifrado en el kubelet que se ejecuta en los nodos de los trabajadores del cliente. Los nuevos nodos de trabajadores creados entre el 20 de agosto de y el 16 de septiembre de 2019 incluyen esta configuración. El nuevo conjunto de cifrados no permite conexiones al kubelet a través de http/2. Esta restricción afecta al servidor de métricas y a la escala automática de pod horizontal que depende del servidor de métricas.

Solución alternativa:

Para cada nodo de trabajador existente, a su vez:

  1. Evite que los nuevos pods inicien y eliminen los pods existentes en el nodo de trabajo introduciendo kubectl drain <node_name>. Para obtener más información:

    Recomendado: aproveche los presupuestos de interrupción de pod según corresponda en su aplicación con el fin de garantizar que haya un número suficiente de pods de réplica en ejecución durante la purga.

  2. Suprima el nodo de trabajo (por ejemplo, finalizando el nodo en la consola ).
  3. Espere a que se inicie un nodo de trabajo de sustitución.

Los nodos de trabajo de sustitución incluyen una nueva configuración que permite la comunicación con el kubelet.

Enlace directo a este problema: Algunas funciones de Kubernetes (por ejemplo, el servidor de métricas) no se pueden comunicar con el kubelet a través de http/2

Los pods de Kubernetes no pueden montar volúmenes debido a timeouts

Detalles: cuando se inicia un nuevo pod en un nodo de trabajador de un cluster, en algunas situaciones, el pod no puede montar todos los volúmenes asociados al nodo debido a timeouts y aparece un mensaje similar al siguiente:

Unable to mount volumes for pod "<pod_name>(<pod_uid>)": timeout expired waiting for volumes to attach or mount for pod "<namespace>"/"<pod_name>". list of unmounted volumes=[<failed_volume>]. list of unattached volumes=[<… list of volumes >]

Una posible causa identificada para este problema es que la especificación del pod incluye un campo fsGroup en el campo securityContext. Si el contenedor se está ejecutando en un nodo de trabajador como usuario no raíz, la definición del campo fsGroup en securityContext puede provocar timeouts debido al número de archivos en los que Kubernetes debe realizar cambios de propiedad (consulte https://github.com/kubernetes/kubernetes/issues/67014).

Si la especificación del pod no incluye un campo fsgroup en securityContext, la causa se desconoce.

Soluciones alternativas:

Si la especificación del pod incluye el campo fsgroup en securityContext y el contenedor está ejecutando un usuario no raíz, considere las siguientes soluciones alternativas:

  • Elimine el campo fsgroup de securityContext.
  • Utilice el campo supplementalGroups en securityContext (en lugar de fsgroup) y defina supplementalGroups en el identificador de volumen.
  • Cambie la especificación del pod para que el contenedor se ejecute como raíz.

Si la especificación del pod no incluye el campo fsgroup en securityContext o si el contenedor ya se está ejecutando como raíz, debe reiniciar o sustituir el nodo de trabajador. Por ejemplo, parando e iniciando la instancia, reiniciando la instancia o terminando la instancia para que se inicie una nueva instancia. Siga las instrucciones de Parada e inicio de una instancia o Terminación de una instancia según corresponda para utilizar la consola o la API. También puede utilizar comandos de CLI, como el siguiente ejemplo, para terminar una instancia:

$ INSTANCE_OCID=$(kubectl get node <name> -ojsonpath='{.spec.providerID}')
$ oci compute instance terminate --instance-id $INSTANCE_OCID

donde <name> es el nombre del nodo de trabajador, derivado de la propiedad de dirección IP privada de la instancia (por ejemplo, 10.0.10.5).

Enlace directo a este problema: Los pods de Kubernetes no pueden montar volúmenes debido a timeouts

Las nuevas etiquetas introducidas en la versión 1.17 de Kubernetes no se agregan a los nodos

Detalles: una serie de etiquetas de nodo de beta.kubernetes.io están en desuso en la versión 1.17 de Kubernetes y se ha pasado a usar sus equivalentes de GA. En concreto:

Etiqueta en desuso Etiqueta equivalente en la versión 1.17 de Kubernetes
beta.kubernetes.io/instance-type node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/region topology.kubernetes.io/region
failure-domain.beta.kubernetes.io/zone topology.kubernetes.io/zone

Sin embargo, Container Engine for Kubernetes sigue agregando las etiquetas en desuso a los nodos de trabajo, en lugar de las etiquetas equivalentes de GA.

Solución alternativa:

Somos conscientes del problema y estamos trabajando para solucionarlo.

Enlace directo a esta incidencia: Las nuevas etiquetas introducidas en la versión 1.17 de Kubernetes no se agregan a los nodos

OS Management provoca que fallen los pools de nodos de cluster de Kubernetes

Detalles: al utilizar el servicio OS Management para gestionar actualizaciones y parches del sistema operativo en instancias de Oracle Cloud Infrastructure, hay algunas situaciones en las que falla la puesta en línea de los pools de nodos de cluster creados en Container Engine for Kubernetes.

Solución alternativa:

Hay dos soluciones alternativas posibles:

  • Solución alternativa 1: si desea utilizar OS Management para gestionar instancias de Oracle Cloud Infrastructure, active Oracle Enterprise Linux en OS Management. Consulte Gestión de orígenes de software.
  • Solución alternativa 2: si no desea utilizar OS Management para gestionar las instancias de Oracle Cloud Infrastructure, asegúrese de que no hay ninguna política que permitan la ejecución de OS Management. En concreto, elimine la política que otorga a un grupo dinámico de instancias acceso al servicio OS Management. Consulte Configuración de políticas para OS Management.

Enlace directo a esta incidencia: OS Management provoca que fallen los pools de nodos de cluster de Kubernetes

Incidencias de montaje de volumen en pools de nodos con nodos maestros que ejecutan la versión 1.19 (o posterior) de Kubernetes y nodos de trabajo que ejecutan la versión 1.18 (o anterior) de Kubernetes

Detalles: si los pools de nodos tienen nodos maestros que ejecutan la versión 1.19 (o posterior) de Kubernetes y nodos de trabajo que ejecutan la versión 1.18 (o anterior) de Kubernetes, es posible que el montaje de volúmenes en bloque asociados al cluster con el plugin de volumen FlexVolume no funcione como se espera. Por ejemplo, puede ver:

  • El mensaje de advertencia FailedMount en los eventos de un pod que se ejecuta en un nodo de trabajo, aunque el volumen en bloque se haya asociado correctamente.
  • El mensaje de error Volume not attached according to node status for volume en los logs del kubelet que se ejecuta en un nodo de trabajo.

Solución alternativa:

  1. Si aún no hay un pool de nodos en el cluster con nodos de trabajo que ejecutan la versión 1.19 (o posterior) de Kubernetes, agregue dicho pool de nodos ahora.
  2. Elimine el nodo de trabajo afectado que ejecuta la versión 1.18 (o anterior) de Kubernetes de la siguiente manera:
    1. Evite que los nuevos pods inicien y eliminen los pods existentes en el nodo de trabajo afectado introduciendo kubectl drain <nombre_nodo>. Para obtener más información:
    2. Suprimir el nodo de trabajo afectado (por ejemplo, finalizando el nodo en la consola).

Enlace directo a esta incidencia: Incidencias de montaje de volumen en pools de nodos con nodos maestros que ejecutan la versión 1.19 (o posterior) de Kubernetes y nodos de trabajo que ejecutan la versión 1.18 (o anterior) de Kubernetes

Incidencias al resolver con DNS (nslookup, dig o curl)
Detalles: si el módulo de núcleo de Bridge Netfilter no está activado, la comunicación de tráfico con localhost no se enruta correctamente. Por ejemplo:
/ # nslookup www.oracle.com
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; reply from unexpected source: 10.244.0.167#53, expected 10.96.5.5#53
;; connection timed out; no servers could be reached 
Para verificar esta incidencia, abra una ventana de terminal en la instancia y ejecute el siguiente comando:
sudo /usr/sbin/lsmod | grep br_netfilter 

Si no se devuelve ningún resultado, el módulo de núcleo de Bridge Netfilter no está activado. Se necesita el módulo de núcleo de Bridge Netfilter para enmascarar el tráfico VxLAN para los pods de Kubernetes.

Solución alternativa: active el módulo de núcleo de Bridge Netfilter. Abra una ventana de terminal en la instancia y ejecute los siguientes comandos:
sudo modprobe br_netfilter 
sudo sh -c 'echo "br_netfilter" > /etc/modules-load.d/br_netfilter.conf'

Enlace directo a esta incidencia: Incidencias al resolver con DNS (nslookup, dig o curl)

Data Catalog

Se pierden algunos formatos de texto enriquecido al exportar o importar un glosario

Detalles: Al exportar o importar un glosario, se pierden algunos formatos de texto enriquecido aplicados a los campos de descripción.

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

Enlace directo a este problema: Se ha perdido el formato de texto enriquecido al exportar un glosario

Recogida incremental de activos de datos de Autonomous Database

Detalles: al utilizar la opción de recogida incremental para recoger activos de datos de Autonomous Database, Data Catalog no identifica los cambios en la columna de comentarios de Oracle Database.

Solución alternativa: vuelva a recoger el activo de datos sin seleccionar la opción de recogida incremental. Esto garantiza que el último estado del activo de datos se refleje en el catálogo de datos.

Enlace directo a este problema: Recogida incremental de activos de datos de Autonomous Database

No se han podido asociar los tipos 'Archivo no reconocido' y 'Archivo' a la misma propiedad personalizada

Detalles: si una propiedad personalizada ya está asociada a un tipo Archivo no reconocido, no se le permitirá asociar una propiedad personalizada a un tipo Archivo y viceversa.

Solución alternativa: realice una de las siguientes acciones:
  • Utilice propiedades personalizadas independientes para cada uno de los tipos.
  • Asocie la propiedad personalizada a todas las entidades de datos.

Enlace directo a esta incidencia: No se pueden asociar los tipos 'Archivo no reconocido' y 'Archivo' a la misma propiedad personalizada.

Durante la exportación del glosario, el campo Propietario (nombre) está vacío si el propietario es un usuario federado

Detalles: al exportar un glosario, si el propietario de un término o una categoría es un usuario federado, el valor del campo Propietario (nombre) no se exporta al archivo de Microsoft Excel.

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

Enlace directo a esta incidencia: No se exporta el nombre de un usuario federado en un glosario.

Data Flow

Los archivos necesarios para cada aplicación deben estar en la misma región en la que se crea la aplicación.

Detalles: Las aplicaciones deben crearse en la misma región que el cubo del almacén de objetos que contiene todos los archivos relacionados, archivos jar y configuraciones necesarios para una ejecución correcta de la aplicación. El escenario Entre regiones no está soportado.

Solución alternativa: Somos conscientes de este problema. No hay solución alternativa, excepto asegurarse de que todos los archivos, los archivos jar, la configuración, etc., están en la misma región.

Enlace directo a este problema: Los archivos necesarios para cada aplicación deben estar en la misma región en la que se crea la aplicación.

Errores de la interfaz de usuario de Spark

Detalles: Puede que aparezca un error al acceder a la interfaz de usuario de Spark. La causa típica de este error es que la aplicación Spark está terminando.

Solución alternativa: Si aparece un error, espere un minuto antes de volver a acceder a la interfaz de usuario de Spark.

Enlace directo a este problema: Errores de la interfaz de usuario de Spark

Data Integration

No se pueden leer datos de un origen de BIP de Oracle Fusion Applications en algunas situaciones

Detalles: para utilizar un activo de datos de BIP Fusion Applications en un flujo de datos, debe utilizar un cubo de Object Storage como ubicación temporal.

Al abrir un flujo de datos que tiene un operador de origen configurado en un activo de datos BIP, los datos pueden fallar al recuperarse en las siguientes situaciones:

  • No se especificó una ubicación temporal por defecto cuando se creó el activo de datos de BIP. Durante el diseño del flujo de datos, se configuró un cubo de ubicación temporal en el operador de origen de BIP.
  • Se especificó una ubicación temporal por defecto en el activo de datos BIP. Durante el diseño del flujo de datos, el operador de origen de BIP se configuró para utilizar un cubo temporal diferente.

Solución alternativa:: Tenemos constancia de esta incidencia y estamos trabajando para solucionarla. Mientras tanto, edite el activo de datos BIP para agregar o cambiar el cubo de ubicación temporal:

Vaya a la lista Activos de datos.

Para el activo de datos BIP que desea modificar, seleccione Editar en el icono de acciones.

En la página de detalles del activo de datos, amplíe la sección Ubicación temporal por defecto.

Utilice los menús para seleccionar el activo de datos, la conexión, el compartimento y, a continuación, el bloque que desea utilizar como ubicación temporal.

Haga clic en Guardar cambios.

Enlace directo a este problema: No se pueden leer datos de un origen de BIP de Oracle Fusion Applications en algunas situaciones

Excepción de tiempo de ejecución con expresiones que hacen referencia a atributos de datos DATE

Detalles: En una versión anterior, Data Integration realizó un cambio para tratar los datos de Oracle DATE como DATETIME en las expresiones de flujo de datos. Si un atributo de datos de origen o de destino tiene el tipo DATE, se envía una excepción de discrepancia de tipo de datos durante el análisis de la expresión.

Solución alternativa:: Tenemos constancia de esta incidencia y estamos trabajando para solucionarla. Mientras tanto, edite las expresiones y convierta las referencias DATE en DATETIME.

Enlace directo a este problema: Excepción de tiempo de ejecución con expresiones que hacen referencia a atributos de datos DATE

Pipeline con un cuerpo de solicitud con parámetros en una tarea REST corrupto

Detalles: Para un pipeline creado en la versión de mayo de 2022: al abrir el pipeline inmediatamente después de haberlo creado correctamente, falta el valor configurado para un parámetro de cuerpo de solicitud JSON entrante.

Para un pipeline creado en una versión anterior a mayo de 2022: al abrir el pipeline, se pierden las conexiones entre operadores y falta el valor configurado para un parámetro de cuerpo de solicitud JSON entrante.

Solución alternativa:: Tenemos constancia de esta incidencia y estamos trabajando para solucionarla.

Mientras tanto, para un pipeline creado en la versión de mayo de 2022, puede editar la tarea REST en el pipeline reconfigurando el valor del parámetro JSON entrante.

Enlace directo a este problema: Pipeline con un cuerpo de solicitud con parámetros en una tarea REST corrupto

Fallo de prueba de conexión para un activo de datos de BIP de Oracle Fusion Applications

Detalles: Cuando intenta conectarse a un host de BIP Fusion Applications mediante una contraseña que incluye $ o /, la conexión falla.

Solución alternativa:: Tenemos constancia de esta incidencia y estamos trabajando para solucionarla. Mientras tanto, al crear un activo de datos de BIP de Oracle Fusion Applications, en la sección de información de conexión por defecto, no utilice una contraseña que tenga $ ni / para conectarse al host de Fusion Applications.

Enlace directo a este problema: Fallo de prueba de conexión para un activo de datos de BIP de Oracle Fusion Applications

La ejecución de un pipeline con tareas SQL falla cuando no se encuentra un procedimiento almacenado

Detalles: solo se pueden ejecutar procedimientos almacenados válidos en tareas SQL. Durante la ejecución del pipeline, si un procedimiento almacenado válido se vuelve no válido por cualquier motivo y el procedimiento ahora invalidado se utiliza en una tarea posterior, la tarea secundaria falla con el mensaje de error:

<PROCEDURE_NAME> Procedure not found in Schema : <SCHEMA_NAME>

Resolución: corrija el procedimiento almacenado y valídelo para su uso en la tarea SQL. En la interfaz de usuario de SQL Developer puede:

Utilizar la tabla DBA_ERRORS o ejecutar SHOW ERRORS PROCEDURE <PROCEDURE_NAME> para comprobar por qué el procedimiento almacenado tiene un estado no válido.

En la posición adecuada del procesamiento, agregue código para volver a compilar explícitamente el procedimiento almacenado antes de que se ejecute la tarea secundaria. Por ejemplo:

ALTER PROCEDURE <SCHEMA_NAME>.<PROCEDURE_NAME> COMPILE;

Enlace directo a este problema: La ejecución de un pipeline con tareas SQL falla cuando no se encuentra un procedimiento almacenado

La ejecución de tareas falla cuando una tabla de origen tiene nombres de columna con caracteres especiales

Detalles: cuando una columna de una tabla de origen tiene caracteres especiales en el nombre (como 'Nombre#') y hay un operador de expresión descendente que realiza una transformación en cualquiera de las columnas de la tabla entrante, la ejecución de la tarea falla.

Solución alternativa:: Tenemos constancia de esta incidencia y estamos trabajando para solucionarla. Mientras tanto, desactive la opción de ejecución en el operador de origen:

En el flujo de datos, seleccione el operador.

Seleccione el separador Opciones avanzadas en el panel Propiedades.

Desactive la casilla de control Permitir ejecución.

Vuelva a publicar la tarea de integración.

Enlace directo a este problema: La ejecución de tareas falla cuando una tabla de origen tiene nombres de columna con caracteres especiales

La ejecución de pipeline falla porque la salida de JSON desde una tarea de REST no se puede extraer y consumir de forma descendente

Detalles: actualmente, solo las salidas escalares desde una tarea de REST se pueden consumir directamente en tareas descendentes de un pipeline.

Solución alternativa:: Tenemos constancia de esta incidencia y estamos trabajando para solucionarla. Mientras tanto, utilice la siguiente solución alternativa:

Para utilizar la salida de JSON desde una tarea REST como entrada para una entrada descendente, inserte un operador de expresión entre la tarea de REST y la tarea descendente.

A continuación, utilice la función REGEXP_SUBSTR para extraer el valor escalar de la propiedad de la salida de respuesta de JSON.

Por ejemplo, para extraer el valor de la propiedad 'base', escriba la expresión:

REGEXP_SUBSTR(<REST_TASK_IDENTIFIER>.SYS.RESPONSE_PAYLOAD, '"base"\s*:\s*"([^"]+)')

Enlace directo a esta incidencia: La ejecución de pipeline falla porque la salida de JSON desde una tarea de REST no se puede extraer y consumir de forma descendente

Etiquetado de datos

El prefijo que coincide con un nombre de archivo provoca el estado Precisa atención

Problema: el prefijo de un nombre de archivo se utiliza para búsquedas "empieza por" y no para coincidencias exactas. Si algún archivo tiene un nombre que coincide exactamente con el prefijo, la generación del registro falla y el juego de datos pasa al estado "Precisa atención" después de que finalice la acción Generar registros.

Solución alternativa: cambie el prefijo o el nombre del archivo en Object Storage. Cargue los nuevos archivos en el juego de datos y vuelva a generar los registros.

Los registros de la lista solo devuelven 1000 entradas

Problema: List Records no devuelve más de 1000 entradas en una sola llamada de API.

Solución alternativa: hay tres opciones:
  • Si necesita recuperar más de 1000 registros, utilice varias llamadas de API.
  • Si busca un registro determinado, incluya el nombre con el parámetro name.
  • Si desea un recuento de los registros, puede obtenerlo llamando a la API Summarize Records para ese compartimento y juego de datos.
Las etiquetas no se pueden ver si amplía demasiado

Problema: para la clasificación de extracción de entidades, si amplía demasiado, la etiqueta y el texto se superponen.

Solución alternativa: aleje hasta que pueda ver claramente las etiquetas.

No se puede indicar nada para etiquetar con extracción de entidad o detección de objetos

Problema: al clasificar un texto mediante la extracción de entidades o clasificar una imagen mediante la detección de objetos, no puede indicar que no haya nada que etiquetar. Al no etiquetar dicha parte de texto o imagen, se considera un registro sin etiqueta, no un registro con nada que etiquetar.

Solución alternativa:: no hay ninguna solución alternativa.

Los archivos con extensión de archivo en mayúsculas no se reconocen

Problema: no se reconocen los archivos con una extensión de archivo en mayúsculas.

Solución alternativa: utilice minúsculas para las extensiones de archivo. Por ejemplo, file.jpg, no file.JPG.

Data Science

Actualmente, no hay problemas conocidos del servicio de ciencia de datos.

Database

PDB existentes en una nueva base de datos

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

PDB en la configuración existente de Data Guard

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

Migración de la cartera de TDE basada en archivos a la cartera de TDE basada en claves y gestionada por el cliente en Oracle Database 12c R1

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

Solución alternativa: 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.

Migración de la cartera de TDE basada en claves y gestionada por el cliente a la cartera de TDE basada en archivos en Oracle Database 12c R1

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

Solución alternativa: 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 hsm_to_file --dbname <database_name> --skip_patch_check true &
Migración de la cartera de TDE basada en archivos a la cartera de TDE basada en claves y gestionada por el cliente en Oracle Database 12c R2

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.

Migración de la cartera de TDE basada en claves y gestionada por el cliente a la cartera de TDE basada en archivos en Oracle Database 12c R2

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.

Incidencia de facturación al cambiar el tipo de licencia

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: somos conscientes del problema y estamos trabajando para solucionarlo.

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

RESUELTO: El gateway del servicio no soporta actualmente las actualizaciones del sistema operativo

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 Problemas para acceder a los servicios de yum de Oracle a través del gateway de servicios.

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

Solo sistemas de base de datos con hardware dedicado y máquina virtual

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

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.

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.
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

Desglosar cambios en SDK de servicio de base de datos

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

No se han podido utilizar las copias de seguridad gestionadas en el sistema 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

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

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

Las operaciones de Oracle Data Pump devuelven "ORA- 00439: función no activada"

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.

Nota

Determinar la versión de una base de datos en un directorio raíz de base de datos

Para determinar la versión de una base de datos en un directorio raíz de base de datos, ejecute $ORACLE_HOME/OPatch/opatch lspatches como usuario oracle o dbcli list-dbhomes como usuario raíz.

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

No se ha podido conectar a la consola de EM Express desde el sistema de base de datos de un nodo

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

Solo sistemas de base de datos Exadata

Fallo al realizar una copia de seguridad en Almacenamiento de objetos mediante bkup_api o RMAN debido a un cambio de certificado

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.

Importante

Antes de utilizar la solución alternativa aplicable en esta sección, siga los pasos descritos en Actualización de herramientas en una instancia de Exadata Cloud Service para asegurarse de que se ha instalado la última versión de dbaastools_exa en el sistema.

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.

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.
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

La información de la consola no se sincroniza para las bases de datos activadas para Data Guard cuando se utiliza dbaascli

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

La infraestructura de cuadrícula no se inicia después de desconectar y conectar un disco

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 dbaascl 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 Cloud Service.

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

Funciones gestionadas no activadas para sistemas aprovisionados antes del 15 de junio de 2018

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:

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

La aplicación de parches en el archivo de configuración apunta a una región incorrecta

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

Varios fallos de flujo de trabajo de base de datos debido a que Oracle Linux 7 ha eliminado los archivos temporales necesarios

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

Escalado de almacenamiento del sistema de base de datos de máquina virtual

Si va a escalar el almacenamiento de datos normal o el almacenamiento del área de recuperación (RECO) de un valor inferior a 10 240 GB (10 TB) a un valor superior a 10 240 GB, realice el escalado en dos operaciones. En primer lugar, escale el sistema a 10 240 GB. Una vez completada esta primera operación de escalado y cuando el sistema tiene el estado "disponible", realice una segunda operación de escalado y especifique el valor de almacenamiento de destino por encima de 10 240 GB. Si se intenta escalar de un valor inferior a 10 240 GB a un valor superior a 10 240 GB en una sola operación, se puede producir un fallo en la operación de escalado. Para obtener instrucciones sobre el escalado, consulte Ampliación de almacenamiento de un sistema de base de datos de máquina virtual.

Fallo al escalar la unidad de los sistemas de base de datos de máquina virtual porque el parámetro DB_Cache_nX no es 0 (cero)

Al escalar un sistema de base de datos de máquina virtual para utilizar una unidad de sistema más grande, la operación de escalado falla si un parámetro DB_Cache_nX no está definido en 0 (cero).

Solución alternativa

Al escalar un sistema de base de datos virtual, asegúrese de que todos los parámetros DB_Cache_nX (por ejemplo, DB_nK_CACHE_SIZE) estén definidos en 0.

Herramientas de desarrollador

Posible problema de corrupción de datos en el SDK de Java de OCI con carga de datos binarios mediante reintentos por defecto

Detalles: Si está utilizando cualquiera de los clientes síncronos del SDK de Java de OCI que cargan flujos de datos (por ejemplo, ObjectStorageClient o DataSafeClient) y no define RetryConfiguration en el nivel de cliente o nivel de solicitud, puede que se vea afectado por daños de datos silenciosos.

Solución alternativa: estamos trabajando activamente para solucionar esta incidencia. Para obtener más información y posibles soluciones alternativas, consulte el problema en GitHub.

Enlace directo a esta incidencia: Posible problema de corrupción de datos en el SDK de Java de OCI con carga de datos binarios mediante reintentos por defecto

Regresión del rendimiento en las versiones 2.14.1 y posteriores de OCI Java SDK para todas las operaciones de API

Detalles: si está utilizando las versiones 2.14.1 y posteriores del SDK de Java de OCI, puede que detecte regresiones del rendimiento al utilizar el SDK para llamar a operaciones de API en cualquiera de los servicios de OCI. La regresión provoca un aumento de entre el 30% y el 60% en la latencia en las operaciones de SDK en cualquiera de los servicios de OCI.

Solución alternativa: estamos trabajando activamente para solucionar esta incidencia. Para obtener más información y posibles soluciones alternativas, consulte el problema en GitHub.

Enlace directo a este problema: Regresión del rendimiento en las versiones 2.14.1 y posteriores del SDK de Java de OCI para todas las operaciones de API

Regresión del rendimiento con el proveedor del conector Apache en el SDK de OCI para Java

Detalles: a partir de la versión 2.0.0, el SDK de OCI para Java soporta el uso de ApacheConnectorProvider de Jersey en lugar del valor por defecto HttpUrlConnectorProvider de Jersey para permitir que Apache HttpClient realice llamadas de servicio de OCI.

ApacheConnectorProvider soporta el uso de la cabecera Expect por defecto para algunas operaciones del servicio Object Storage (consulte https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100). Se ha observado que esto provoca una regresión del rendimiento en las mismas operaciones del servicio Object Storage.

Solución alternativa: puede desactivar el uso de la cabecera Expect volviendo al conector por defecto de Jersey (consulte https://docs.oracle.com/iaas/Content/API/SDKDocs/javasdkconfig.htm) o, si ya está utilizando ApacheConnectorProvider, puede desactivar la cabecera Expect con ApacheConnectorProvider haciendo lo siguiente al inicializar el cliente:
final ApacheConnectorProperties apacheConnectorProperties =
        ApacheConnectorProperties.builder()
                .expectContinue(false) // disable the Expect header
                .build();

final ApacheConfigurator configurator =
        new ApacheConfigurator.NonBuffering(apacheConnectorProperties);
        
ObjectStorageClient objectStorageClient =
        ObjectStorageClient.builder()
                .clientConfigurator(configurator)
                .build(provider);

Enlace directo a esta incidencia: Regresión del rendimiento con el proveedor del conector Apache en el SDK de OCI para Java

Respuesta truncada para las operaciones que devuelven datos binarios con el SDK de Java de OCI

Detalles: en las versiones 2.0.0 a 2.13.0 de la API del SDK de Java de OCI, algunas operaciones que devuelven un flujo de datos pero no devuelven la cabecera content-length en la respuesta podrían devolver datos truncados. Esto se debe al cierre prematuro del flujo por parte del SDK antes de leer todos los datos.

Solución alternativa: actualice el cliente de SDK de Java de OCI a la versión 2.13.1 o una versión posterior. Para obtener más información sobre esta incidencia y soluciones alternativas, consulte https://github.com/oracle/oci-java-sdk/issues/357.

Enlace directo a esta incidencia: Respuesta truncada para las operaciones que devuelven datos binarios con el SDK de Java de OCI

El SDK de Go no puede encontrar automáticamente algunas regiones mientras se ejecuta en Cloud Shell

Detalles: debido a algunas incidencias con una de sus dependencias, la función SDK de Go, que permite a los clientes utilizar automáticamente nuevos dominios que podrían ser desconocidos para el SDK, no funciona desde Cloud Shell.

Si intenta ejecutar código en Cloud Shell que utilice esta función, aparecerá el siguiente mensaje de error:
can not create client, bad configuration: failed to get security token: failed to renew security token: failed to get security token: failed to call: Post "https://<endpoint>/v1/x509": dial tcp: lookup <endpoint> on 127.0.0.11:53: server misbehaving
panicked while retrying operation. Panic was: runtime error: invalid memory address or nil pointer dereference

Solución alternativa: para resolver esta incidencia, active la resolución de regiones mediante el servicio de metadatos de instancia para el SDK de Go. Para obtener más información, consulte: Adición de Regiones

Enlace directo a esta incidencia: El SDK de Go no puede encontrar automáticamente algunas regiones mientras se ejecuta en Cloud Shell

Aumento de las incidencias de latencia en operaciones realizadas para algunos servicios de OCI mediante los SDK y otras herramientas.

Detalles: puede que observe un aumento de la latencia en operaciones realizadas en algunos servicios de OCI mediante los SDK, Terraform, Ansible y la CLI. Se ha confirmado que esta incidencia afecta al servicio OCI Streaming, y que puede afectar también a los servicios Email Delivery, Health Checks, NoSQL Database Cloud, Registry, los artefactos genéricos y Web Application Acceleration and Security. Esta lista no es exhaustiva, por lo que es posible que también detecte esta incidencia en otros servicios de OCI. Se ha confirmado que esta incidencia NO afecta a los servicios Object Storage y Functions de OCI.

Los siguientes SDK y herramientas se ven afectados:

  • SDK de Go (versión 41.2.0 y posterior)
  • SDK de .NET (versión 14.2.0 y posterior)
  • SDK de Java (versión 2.0.0 y posterior)
  • SDK de Python (versión 2.38.4 y posterior)
  • CLI (versión 2.25.0 y posterior)
  • Módulos de PowerShell (versión 9.2.0 y posterior)
  • Módulos de Ansible (versión 2.23.0 y posterior)
  • Proveedor de Terraform (versión 4.30.0 y posterior)

Soluciones alternativas y más información: Estamos trabajando activamente para solucionar esta incidencia. Para obtener más información y posibles soluciones alternativas, consulte lo siguiente:

Enlace directo a esta incidencia: Aumento de las incidencias de latencia en operaciones realizadas para algunos servicios de OCI mediante los SDK y otras herramientas

Las operaciones de compuesto del SDK de Python devuelven el error 404 NotAuthorizedOrNotFound a pesar de que la operación es correcta

Detalles: las operaciones copy_boot_volume_backup_and_wait_for_state y copy_volume_backup_and_wait_for_state del compuesto de cliente BlockStorage devuelven 404/NotAuthorizedOrNotFound cuando se copia una copia de seguridad de una región a otra. Para obtener más información, consulte: https://github.com/oracle/oci-python-sdk/issues/344.

Solución alternativa: en lugar de utilizar las operaciones de compuesto, utilice dos clientes diferentes para esta operación; un cliente en la región de origen para enviar la solicitud de duplicado de la copia de seguridad de la región A a la región B, y un segundo cliente en la región de destino para esperar a que la copia de seguridad esté disponible. Consulte el ejemplo aquí: https://github.com/oracle/oci-python-sdk/blob/master/examples/copy_volume_backup_example.py

Enlace directo a esta incidencia: Las operaciones de compuesto del SDK de Python devuelven el error 404 NotAuthorizedOrNotFound a pesar de que la operación es correcta

Posible incidencia de redondeo de datos para números grandes con el SDK de OCI para TypeScript y JavaScript

Detalles: el SDK de OCI para TypeScript y JavaScript tiene una incidencia conocida con números grandes mayores que Number.MAX_SAFE_INTEGER de JavaScript. Cualquier número mayor que Number.MAX_SAFE_INTEGER generará una incidencia de redondeo.

Solución alternativa: Tenemos constancia de la incidencia por la que una respuesta de API puede devolver un número mayor que Number.MAX_SAFE_INTERGER de JavaScript. En este momento, la incidencia de redondeo de números no afecta a la llamada a ninguna API.

Enlace directo a esta incidencia: Posible incidencia de redondeo de datos para números grandes con el SDK de OCI para TypeScript y JavaScript

Posible incidencia de datos en los datos con el SDK de Java de OCI en la carga de datos binarios con RefreshableOnNotAuthenticatedProvider

Detalles: si está utilizando la versión 1.25.1 o anterior de los clientes de SDK de Java de OCI que cargan flujos de datos (por ejemplo, ObjectStorageClient o FunctionsInvokeClient), de forma síncrona y asíncrona, y utiliza RefreshableOnNotAuthenticatedProvider (por ejemplo, para los principales de recursos o los principales de instancia), puede verse afectado por daños silenciosos en los datos.

Solución alternativa: actualice el cliente de SDK de Java de OCI a la versión 1.25.2 o una versión posterior. Para obtener más información sobre esta incidencia y soluciones alternativas, consulte Posible incidencia de daños en los datos con el SDK de Java de OCI en la carga de datos binarios con RefreshableOnNotAuthenticatedProvider.

Enlace directo a esta incidencia: Posible incidencia de daños en los datos con el SDK de Java de OCI en la carga de datos binarios con RefreshableOnNotAuthenticatedProvider

Posible incidencia de daños en los datos con el conector HDFS de OCI en la carga de datos binarios con RefreshableOnNotAuthenticatedProvider

Detalles: si utiliza la versión 3.2.1.1 o anterior de los clientes del conector HDFS de OCI y usa RefreshableOnNotAuthenticatedProvider (por ejemplo, InstancePrincipalsCustomAuthenticator o, generalmente, para principales de recurso o principales de instancia), puede que se vea afectado por daños silenciosos en los datos.

Solución alternativa: actualice el cliente del conector HDFS de OCI a la versión 3.2.1.3 o una versión posterior. Para obtener más información sobre esta incidencia y soluciones alternativas, consulte Posible incidencia de daños en los datos para el conector HDFS de OCI con RefreshableOnNotAuthenticatedProvider.

Enlace directo a esta incidencia: Posible incidencia de daños en los datos con el conector HDFS de OCI en la carga de datos binarios con RefreshableOnNotAuthenticatedProvider

Posibles daños de los datos con el SDK para Python en la carga binaria

Detalles: al utilizar el SDK para Python para realizar operaciones de carga binaria, puede que aparezca un problema relacionado con daños de los datos si los reintentos están activados o si está utilizando UploadManager.upload_file.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Para obtener más información sobre este problema y las soluciones alternativas, consulte Posible problema de daños de los datos para el reintento del SDK de Python en la carga de datos binarios.

Enlace directo a este problema: Posibles daños de los datos con el SDK para Python en la carga binaria

Posible incidencia de daños en los datos con el SDK para Python y flujos de carga

Actualización: la causa raíz de la incidencia que causa daños en los datos se ha corregido con la versión v2.54.0. Utilice oci v2.54.0 o una versión superior para evitar daños en los datos. A continuación se explica el comportamiento de las versiones anteriores del SDK de Python de OCI con respecto a esta incidencia.

Detalles: los clientes que utilizan el SDK de OCI para Python y oci.object_storage.UploadManager.upload_stream en modo FIPS pueden ser vulnerables a daños silenciosos en los datos. Si las circunstancias para producir la incidencia son verdaderas para su entorno, el SDK informa que la operación de carga se ha realizado correctamente, pero se carga un objeto de longitud 0.

La resolución varía en función del estado del entorno:

  1. El uso de UploadManager.upload_stream() en un entorno que utiliza una versión de OpenSSL compatible con FIPS en la que el SDK para Python no está funcionando en modo FIPS, como se describe en Uso de bibliotecas validadas por FIPS.

    Para determinar si entra dentro de este escenario:

    • Verifique que está utilizando una versión de OpenSSL compatible con FIPS mediante la ejecución del comando openssl version. Si "fips" forma parte del nombre de la versión y no está utilizando el SDK en modo FIPS, entonces entraría dentro de este escenario.

    • Si oci.fips.is_fips_mode() no devuelve True, quiere decir que el SDK no está funcionando en modo FIPS.

    Solución alternativa: actualice el SDK de OCI para Python a la versión 2.53.1 o posterior y utilice el SDK para Python en modo FIPS, como se describe en Uso de bibliotecas validadas por FIPS.
    Importante

    Si no usa el SDK en modo FIPS mientras utiliza una versión de OpenSSL compatible con FIPS, los datos se dañarán al utilizar UploadManager.upload_stream().
  2. El uso de UploadManager.upload_stream() cuando el SDK para Python está funcionando en modo FIPS, como se describe en Uso de bibliotecas validadas por FIPS, y la versión del SDK para Python es v2.53.0 o inferior.

    Si oci.fips.is_fips_mode() devuelve True, quiere decir que el SDK está funcionando en modo FIPS.

    Resolución: actualice el SDK de OCI para Python a la versión 2.53.1 o posterior.

Para obtener más información sobre esta incidencia, consulte la sección sobre la posible incidencia de corrupción de datos para la carga de flujos de varias partes para el SDK de Python de OCI en GitHub.

Enlace directo a esta incidencia: Posible incidencia de daños en los datos con el SDK para Python y flujos de carga

DNS

Actualmente, no hay problemas conocidos de DNS.

Email Delivery

No se ha podido acceder a las credenciales de SMTP para los arrendamientos federados anteriores

Detalles: los usuarios federados están admitidos para la entrega de correo electrónico, con excepción de los arrendamientos anteriores que no utilizan el sistema para la gestión de identidad entre dominios (SCIM). SCIM será el estándar para todos los accesos a información de identidad. Todos los arrendamientos después de diciembre de 2018 son SCIM.

Solución alternativa: pida a un administrador en su arrendamiento de Oracle Cloud Infrastructure que cree un nuevo usuario en la Consola que se utilizará con el servicio de entrega de correo electrónico. La conexión directa a la Consola (no federada) permitirá el acceso a la configuración de usuario y a las credenciales SMTP.

Enlace directo a este problema: No se puede acceder a las credenciales SMTP para ningún arrendamiento federado

Se produce un error al intentar agregar una supresión desde un compartimento que no sea raíz

Detalles: en la consola, si selecciona un compartimento que no sea raíz y, a continuación, navega a la lista Supresión de correo electrónico, se producirá el siguiente error cuando intente agregar una supresión:

Error: The required compartmentId ocid1.compartment.oc1..aaaaaaaacq3ztcbrxvgfb35zj6wztdpwlkmzfh4rnsq63sugge624qr5cdla must be the root compartment for suppressions

Solución alternativa: navegue hasta la página Remitentes aprobados, seleccione el compartimento raíz y, a continuación, vuelva a la lista Supresión de correo electrónico.

Enlace directo a esta incidencia: Se produce un error al intentar agregar una supresión desde un compartimento que no sea raíz

Se producen incidencias de JavaMail cuando se configuran varios destinatarios en un correo electrónico y se suprimen una o varias de las direcciones de correo electrónico

Detalles: al enviar correo electrónico a varios destinatarios con un cliente que utiliza la biblioteca JavaMail, si una o varias de las direcciones de correo electrónico están en la lista de supresión, el servicio Email Delivery devuelve el código de estado de SMTP 254. Este error indica que se ha enviado un correo electrónico con una dirección de destinatario suprimida.

La biblioteca JavaMail tiene la capacidad de aceptar una lista de destinatarios y enviar solo los que son válidos configurando el indicador sendPartial. Sin embargo, este código no puede detectar el nuevo código de estado del servidor de supresión y borrar solo las direcciones suprimidas; en su lugar, aborta el envío completo y devuelve una excepción. Las aplicaciones deben capturar esta excepción y eliminar el destinatario suprimido de la lista de destinatarios para enviar solo los destinatarios válidos del juego. Es decir, el código de aplicación puede detectar com.sun.mail.smtp.SMTPAddressFailedException y llamar a ex.getAddress() con el objeto de excepción para obtener las direcciones que se van a eliminar y volver a enviar con estas direcciones eliminadas.

Solución alternativa: supervise activamente las listas de supresiones y actualice las listas de envío según corresponda, de modo que las direcciones suprimidas no formen parte de las listas de envío de correo electrónico. Para obtener más información, consulte Gestión de la lista de supresión.

Enlace directo a esta incidencia: Se producen incidencias de JavaMail cuando se configuran varios destinatarios en un correo electrónico y se suprimen una o varias de las direcciones de correo electrónico

Events

Actualmente, no hay problemas conocidos en los eventos.

File Storage

File Storage no soporta actualmente listas de control de acceso (ACL)
Detalles: File Storage no soporta listas de control de acceso (ACL) a nivel de archivo. Solo se soportan los permisos user, group y world. File Storage utiliza el protocolo NFSv3, que no incluye soporte para ACL. setfacl falla en los sistemas de archivos montados. getfacl solo devuelve permisos estándar.
Nota

Algunas implementaciones pueden ampliar el protocolo NFSv3 y agregar soporte para ACL como parte de un programa rpc independiente.

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

Enlace directo a este problema: File Storage no soporta actualmente listas de control de acceso (ACL)

Error de timeout de semáforo al crear una instantánea con la línea de comandos de Windows

Detalles: al utilizar el comando mkdir en Windows CMD para crear una instantánea de un sistema de archivos montado, aparece un error. Por ejemplo: 

C:\>mkdir X:\.snapshot\snapshot1

Se ha agotado el tiempo de espera máximo del semáforo.

Aunque aparece el error, la instantánea se ha creado correctamente.

Solución alternativa: utilice la Consola, la API o la CLI para crear instantáneas.

Enlace directo a este problema: Error de timeout de semáforo al crear una instantánea con la línea de comandos de Windows

No se han podido mover los recursos de almacenamiento de archivos a otro compartimento

Detalles: al mover un sistema de archivos o un destino de montaje de un compartimento a otro, la operación falla. Los usuarios deben ser miembros del grupo de administradores.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Para solucionar este problema, asegúrese de que el usuario sea miembro del grupo de administradores. Para obtener más información, consulte Gestión de Grupos.

Enlace directo a esta incidencia: No se pueden mover recursos de almacenamiento de archivos a otro compartimento.

Se produce un error 409 al crear o mover un sistema de archivos o un destino de montaje

Detalles: al crear o mover un sistema de archivos o un destino de montaje de un compartimento a otro, puede que aparezca uno de los siguientes errores de API 409:

Creación de sistema de archivos:

oci.exceptions.ServiceError: {'opc-request-id': <<OPC REQUEST ID>>, 'code': 'Conflict', 'message': 'Another filesystem is currently being provisioned, try again later', 'status': 409}

Traslado de sistema de archivos:

oci.exceptions.ServiceError: {'opc-request-id': <<OPC REQUEST ID>>, 'code': 'Conflict', 'message': 'filesystem <<FILE SYSTEM OCID>> is currently being modified, try again later', 'status': 409}

Creación de destino de montaje:

oci.exceptions.ServiceError: {'opc-request-id': <<OPC REQUEST ID>>, 'code': 'Conflict', 'message': 'Another mount target is currently being provisioned, try again later', 'status': 409}

Traslado de destino de montaje:

oci.exceptions.ServiceError: {'opc-request-id': <<OPC REQUEST ID>>, 'code': 'Conflict', 'message': 'mount target<<MOUNT TARGET OCID>> is currently being modified, try again later', 'status': 409}

La función Visión general de cuotas de compartimento introduce restricciones que limitan el número de operaciones simultáneas que un arrendamiento puede realizar en los recursos del destino de montaje y el sistema de archivos de una región:

  • Cada arrendamiento de una región puede tener una operación CreateFileSystem o ChangeFilesystemCompartment en curso de cada vez.
  • Cada arrendamiento de una región puede tener una operación CreateMountTarget o ChangeMountTargetCompartment en curso de cada vez.

Si un arrendamiento intenta realizar más de una operación simultánea, una operación se realiza correctamente y las demás reciben el código de respuesta del error 409. La estrategia de reintento por defecto para el SDK de OCI es no reintentar los conflictos 409. Consulte SDK Behaviors - Retries (Comportamientos de SDK - Reintentos).

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Para resolver este problema, cree una estrategia de reintento personalizada que reintente los errores 409. En https://github.com/oracle/oci-python-sdk/blob/master/examples/retries.py se proporcionan varios ejemplos de creación de una estrategia de reintento personalizada.

Enlace directo a este problema: Se produce un error 409 al crear o mover un sistema de archivos o un destino de montaje

El cifrado en tránsito de File Storage no soporta actualmente nombres de host de DNS

Los sistemas de archivos que utilizan el cifrado en tránsito no se pueden montar mediante un nombre de host de DNS. Solo se pueden utilizar direcciones IP para montar sistemas de archivos con cifrado en tránsito.

Detalles: la herramienta de cifrado en tránsito oci-fss-utils no soporta actualmente el uso de nombres de host de DNS para montar sistemas de archivos.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Hasta que se resuelva esta incidencia, utilice la dirección IP del destino de montaje en el comando de montaje oci-fss-utils. Por ejemplo:
sudo mount -t oci-fss 10.x.x.x:/fs-export-path /mnt/yourmountpoint
Reemplace 10.x.x.x: por la dirección IP de subred local asignada al destino de montaje, fs-export-path por la ruta de exportación especificada al asociar el sistema de archivos al destino de montaje y yourmountpoint por la ruta al punto de montaje local. La ruta de exportación es la ruta al sistema de archivos (relativa a la dirección IP del destino de montaje). Consulte Uso del cifrado en tránsito para obtener más información.

Enlace directo a esta incidencia: El cifrado en tránsito de File Storage no soporta actualmente nombres de host de DNS

Functions

Actualmente, no hay problemas conocidos con las funciones.

Health Checks

Actualmente, no hay problemas conocidos de Comprobaciones del sistema.

IAM

Las preguntas de seguridad no están disponibles como factores de MFA

Detalles: las preguntas de seguridad como factores de MFA están causando incidencias de suscripción a regiones para cuentas en la nube que utilizan dominios de identidad de IAM.

Solución alternativa: en las cuentas en la nube que utilizan dominios de identidad de IAM, no utilice preguntas de seguridad como factores de MFA.

Enlace directo a esta incidencia: las preguntas de seguridad no están disponibles como factores de MFA

Los permisos otorgados mediante políticas que especifican grupos o grupos dinámicos por nombre se mantienen a pesar de los cambios de nombre

Detalles: las sentencias de política que hacen referencia a un grupo o grupo dinámico por nombre siguen siendo válidas incluso tras cambiar el nombre del grupo o grupo dinámico. Cualquier acceso otorgado al grupo o al grupo dinámico por su nombre anterior se mantiene. La política sigue otorgando a los miembros del grupo o grupo dinámico acceso a los recursos sin ningún cambio en la propia sentencia de política. Esto sucede porque IAM aplica la política al OCID del asunto en lugar de a su nombre.

Solución alternativa: Oracle recomienda que actualice las sentencias de política para mantenerse actualizadas con los nombres de grupo o grupo dinámico deseados o que haga referencia a los OCID de asunto en su lugar. Suprima también cualquier sentencia de política con referencias obsoletas que ya no necesite.

Enlace directo a esta incidencia: los permisos otorgados mediante políticas que especifican grupos o grupos dinámicos por nombre se mantienen tras los cambios de nombre

No se propagan los nuevos permisos en los tipos de recursos

Detalles: cuando se agrega un nuevo permiso a un tipo de recurso existente, el permiso no se propaga a ninguna política que incluya el tipo de recurso. Esto sucede porque IAM no recompila una política a menos que haya un cambio en la sentencia de política.

Solución alternativa: para todas las políticas existentes que utilice tipos de recursos, cuando se agreguen nuevos permisos al tipo de recurso, edite la política agregando un espacio en blanco. A continuación, guarde la política.

Enlace directo a esta incidencia: No se propagan los nuevos permisos en los tipos de recursos

No se han podido configurar nuevas federaciones con Microsoft® Active Directory

Detalles: durante el proceso de configuración, después de cargar el documento de metadatos de federación de Oracle Cloud Infrastructure, Microsoft AD FS activa automáticamente el cifrado de afirmaciones. Oracle Cloud Infrastructure no soporta el cifrado en este momento, por lo que la configuración falla.

Solución alternativa: este problema está resuelto. El servicio IAM ahora soporta el cifrado de afirmaciones. Consulte Federación con Microsoft Active Directory.

Enlace directo a este problema: No se han podido configurar nuevas federaciones con Microsoft® Active Directory

Los compartimentos suprimidos siguen contando según los límites del servicio

Detalles: los compartimentos suprimidos siguen contando según el límite de servicio de compartimento para su arrendamiento. Un compartimento suprimido se elimina del recuento después de 90 días. Este es también el valor que especifica el período de tiempo que los compartimentos suprimidos permanecerán en la Consola.

Solución alternativa: hasta que se resuelva este problema, puede solicitar un mayor límite de servicio para los compartimentos. Consulte Solicitud de aumento del límite de servicio.

Enlace directo a este problema: Los compartimentos suprimidos siguen contando según los límites del servicio

Integración

Para consultar los problemas conocidos de Integration, visite Problemas conocidos.

Java Management

Para obtener información sobre las incidencias conocidas en el servicio Java Management, consulte Incidencias conocidas.

Language

Actualmente, no hay ninguna incidencia conocida con el servicio Language.

Load Balancing

El equilibrador de carga muestra "Desconocido" en el indicador de estado de juegos de backends de la consola

Detalles: Al realizar comprobaciones del equilibrador de carga en la consola, puede que el estado de juegos de backends aparezca como" Desconocido" aunque el equilibrador de carga esté funcionando correctamente. El estado" Desconocido" no afecta a la ruta de acceso de datos.

Solución alternativa: Consulte los gráficos de telemetría pública en la consola de Oracle Cloud Infrastructure para obtener una indicación precisa del estado de juego de backends del equilibrador de carga.

Enlace directo a este problema: El equilibrador de carga muestra "Desconocido" en el indicador de estado de juegos de backends de la consola

Logging

Se pueden ignorar algunas advertencias del agente

Detalles: pueden producirse advertencias benignas para el agente basado en fluentd de Oracle similares a las siguientes:

Sep 22 05:47:43 ociutv3mgftp02 ruby[1278962]: /opt/unified-monitoring-agent/embedded/lib/ruby/gems/2.6.0/gems/oci-2.9.0.1125/lib/oci/identity/models/base_tag_definition_validator.rb:23: warning: already initialized constant OCI::Identity::Models::BaseTagDefinitionValidator::VALIDATOR_TYPE_ENUM
Sep 22 05:47:43 ociutv3mgftp02 ruby[1278962]: /opt/unified-monitoring-agent/embedded/lib/ruby/gems/2.6.0/gems/oci-2.9.0.1125/lib/oci/identity/models/base_tag_definition_validator.rb:24: warning: previous definition of VALIDATOR_TYPE_ENUM was here

Puede ignorar las advertencias benignas. Estas advertencias no afectan a la funcionalidad del agente.

Enlace directo a este problema: Se pueden ignorar algunas advertencias de agente

Logging Analytics

Carga bajo demanda desde una máquina con Windows mediante un archivo zip

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

Manejo especial al supervisar logs en carpetas grandes

Detalles: las carpetas que contienen más de 10 000 archivos pueden provocar problemas de recopilación de logs (así como problemas del sistema operativo).

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.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.

Sin embargo, si desea continuar supervisando logs en carpetas grandes, puede activar la propiedad indicada en el archivo mgmt_agent.log 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.

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

Management Agent

Actualmente, no hay problemas conocidos de Management Agent.

Marketplace

Actualmente, no hay problemas conocidos de Marketplace.

Supervisión

No se reciben mensajes de alarma en los compartimentos gestionados de los servicios de plataforma de Oracle

Detalles: no se reciben los mensajes de alarma enviados a temas de compartimentos gestionados de los servicios de plataforma de Oracle (denominados "ManagedCompartmentForPaas"). Esta incidencia se produce cuando el servicio Monitoring no tiene permiso para utilizar temas en ese compartimento.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Para solucionar esta incidencia, mueva la alarma a un compartimento no gestionado y actualice el destino de notificación de la alarma para que utilice un tema de un compartimento no gestionado.

Enlace directo a esta incidencia: No se reciben mensajes de alarma en los compartimentos gestionados de los servicios de plataforma de Oracle

Networking

Configuración de VNIC secundarias en Linux

Detalles: el script que Oracle pone a su disposición en https://docs.cloud.oracle.com/iaas/Content/Resources/Assets/secondary_vnic_all_configure.sh está destinado a utilizarse en situaciones en las que se debe asignar una dirección IP y una VNIC adicionales a instancias informáticas sin hipervisor. El script no es útil para aplicaciones de Kernel-based Virtual Machine (KVM) en una instancia con hardware dedicado.

Solución alternativa: realice las siguientes acciones: para aplicaciones de KVM en una instancia con hardware dedicado, consulte el documento técnico "Installing and Configuring KVM on Bare Metal Instances with Multi-VNIC" (Instalación y configuración de KVM en instancias con hardware dedicado y varias VNIC).

Enlace directo a este problema: Configuración de VNIC secundarias en Linux

Configuration Helper de CPE: especificación del proveedor de CPE

Detalles: Si ocurren los siguientes elementos, en la consola de Oracle recibirá un error que indica que falta la información del proveedor (el tipo de dispositivo) en el CPE. Actualice el CPE y agregue la información del proveedor:

  • Tiene un CPE que existía antes de que se lanzara la función Configuration Helper de CPE.
  • Aún no ha editado el CPE en la consola de Oracle y ha especificado el proveedor que corresponde con su CPE.
  • Ha intentado generar el contenido de Helper para el CPE o cualquier conexión de IPSec que utilice ese CPE.

Solución alternativa: Realice las siguientes acciones:

  1. En la consola de Oracle, visualice el CPE.
  2. Haga clic en Editar.
  3. En la sección Información de proveedor de CPE, seleccione el proveedor que corresponde con su CPE. Si no está seguro de cuál es el proveedor que corresponde con su CPE o no aparece en la lista, seleccione Otro.
  4. Si se le solicita, seleccione un valor para Plataforma/Versión. Estas son las directrices:

    • Oracle recomienda utilizar una configuración basada en rutas si es posible.
    • Si no ve su plataforma o versión de CPE específica en la lista, seleccione la plataforma o versión más cercana con fecha anterior a su versión de CPE.
  5. Haga clic en Guardar cambios. Es importante hacer clic aquí incluso si no ha cambiado el valor del proveedor.

A continuación, puede generar el contenido de Helper correctamente para el CPE o cualquier conexión de IPSec que utilice ese CPE.

Enlace directo a este problema: Configuration Helper de CPE: especificación del proveedor de CPE

RESUELTO: VPN de sitio a sitio: soporte del este de EE. UU. (Ashburn) para NAT-T

Detalles: NAT-T aún no está soportado por completo en todos los túneles de VPN de sitio a sitio en la región del este de EE. UU. (Ashburn).

Solución alternativa: este problema ya se ha resuelto.

Enlace directo a esta incidencia: RESUELTO: VPN de sitio a sitio: soporte del este de EE. UU. (Ashburn) para NAT-T

VPN de sitio a sitio: datos incorrectos en varios gráficos de Monitoring

Detalles: varios de los gráficos de Monitoring de los túneles de VPN de sitio a sitio muestran datos incorrectos y no deben utilizarse para determinar los niveles de tráfico recientes en el túnel.

En resumen, estos son los gráficos de Monitoring disponibles para los túneles de VPN de sitio a sitio:

  • Estado del túnel de IPSec: este gráfico es preciso y muestra correctamente el estado activo o caído del túnel.
  • Bytes o paquetes enviados o recibidos: estos cuatro gráficos no son precisos y no muestran el nivel correcto de bytes o paquetes enviados o recibidos por el túnel.
  • Paquetes con errores: este gráfico no es preciso y no muestra el número correcto de paquetes borrados con errores.

Para obtener más información sobre los gráficos, consulte Métricas de VPN de sitio a sitio.

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

Enlace directo a esta incidencia: VPN de sitio a sitio: datos incorrectos en varios gráficos de Monitoring

RESUELTO: VPN de sitio a sitio: incidencia con la disponibilidad de NAT-T regional y Libreswan

Detalles: si todas las siguientes opciones son verdaderas:

  • Está utilizando Libreswan como su CPE para la VPN de sitio a sitio
  • Su CPE está detrás de un dispositivo NAT
  • Se conecta a una de estas regiones de Oracle Cloud Infrastructure: este de EE. UU. (Ashburn), Corea del Sur Central (Seúl), este de Japón (Tokio) o sudeste de Canadá (Toronto)

Por ello, es posible que tenga incidencias de conectividad con la VPN de sitio a sitio debido a una incidencia de interoperabilidad de NAT traversal (NAT-T) con el software actual en los enrutadores de Oracle de esas regiones.

Oracle es consciente del problema y está en proceso de actualización del software para eliminar ese problema.

Fondo: NAT traversal (NAT-T) activado por Oracle para algunos enrutadores de VPN de sitio a sitio en el este de Estados Unidos (Ashburn) y para todos los enrutadores de Corea del Sur Central (Seúl), este de Japón (Tokio) y sudeste de Canadá (Toronto). Sin embargo, la versión actual del software en esos enrutadores tiene un problema de interoperabilidad con NAT-T. Si sigue la documentación actual de Oracle, que indica que NO active NAT-T en su CPE, NO debería experimentar problemas relacionados con esta incidencia.

Sin embargo, si utiliza Libreswan para su CPE detrás de un dispositivo NAT y va a conectarse a una de esas regiones, podría experimentar problemas de conectividad durante el período en el que Oracle está actualizando el software del enrutador. En concreto, es posible que el túnel se active pero no transfiera tráfico.

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

Si tiene problemas de conectividad, para los usuarios de Libreswan correspondientes en las regiones afectadas:

A. Active NAT-T en su CPE.

  1. En el archivo ipsec.conf de la conexión relevante, cambie el valor de encapsulation de no a yes.
  2. Reinicie el servicio de Libreswan.

Si sigue teniendo problemas de conectividad:

B. Configure la conexión de nuevo.

  1. Vuelva a crear la conexión de IPSec en la Consola de Oracle.
  2. Vuelva a crear la configuración de Librewswan con la información de la nueva conexión de IPSec.
  3. Vuelva a cargar el servicio Libreswan.

Si sigue teniendo problemas de conectividad:

C. Póngase en contacto con My Oracle Support para obtener ayuda adicional. Para obtener instrucciones, consulte Abrir una solicitud de servicio de soporte.

Enlace directo a esta incidencia: RESUELTO: VPN de sitio a sitio: incidencia con la disponibilidad de NAT-T regional y Libreswan

Problemas con el acceso privado a Oracle Analytics Cloud a través de un gateway de servicios para su red local
Detalles: si hace todo lo siguiente, se puede producir el enrutamiento asimétrico para el tráfico entre su red local y Oracle Analytics Cloud. El enrutamiento asimétrico implica que el tráfico de solicitud y respuesta pasa por rutas diferentes. Aquí tiene más detalles de por qué se puede producir el enrutamiento asimétrico: cuando Oracle Analytics Cloud inicia conexiones a clientes en la red local, las solicitudes de conexión deben pasar por una ruta pública (ya sea el intercambio de tráfico público de Internet o FastConnect). Sin embargo, la respuesta recorre una ruta privada, en función de la recomendación en Preferencias de enrutamiento para el tráfico desde su red local hasta Oracle.

Solución alternativa: tiene dos opciones.

  • Opción 1 (preferentemente): con Oracle Analytics Cloud, pase de usar un conector remoto de datos a un gateway de datos.
  • Opción 2: configure el equipo local de cliente (CPE) para que prefiera una ruta de intercambio de tráfico de público Internet o de FastConnect mediante la agregación de rutas estáticas para la dirección IP de origen regional de Oracle Analytics Cloud. De este modo, todo tráfico de respuesta a Oracle Analytics Cloud devolverá la misma ruta de acceso que la solicitud de conexión entrante.

Solo se necesita una solución alternativa si utiliza Oracle Analytics Cloud para iniciar conexiones a clientes de la red local y aún usa un gateway de datos en la red.

Enlace directo a este problema: Problemas con el acceso privado a Oracle Analytics Cloud a través de un gateway de servicios para su red local

Problemas de acceso de servicios de Oracle mediante un gateway de servicios a sus instancias públicas
Detalles: si la tabla de rutas asociada a su subred pública en una red virtual en la nube incluye las dos siguientes reglas de ruta en conflicto, los servicios de Oracle no podrán acceder a las instancias públicas en esa subred.
  1. Regla de ruta con el tipo de destino definido como gateway de Internet.
  2. Regla de ruta con el servicio de destino definido como Todos los servicios de <region> de Oracle Services Network y el tipo de destino definido como gateway de servicio.
Las dos reglas de ruta anteriores pueden conducir al enrutamiento asimétrico cuando los servicios de Oracle inician conexiones a instancias públicas en la red virtual en la nube. Oracle Cloud Infrastructure no admite estas reglas simultáneamente en la misma tabla de rutas. Oracle ha actualizado las API de servicio y la Consola para desactivar el soporte para esta configuración.

Solución alternativa: se recomienda eliminar la regla de ruta que tiene el servicio de destino definido como Todos los servicios de <region> de Oracle Services Network y el tipo de destino definido como gateway de servicio. Revierta a la configuración que utilizaba antes de adoptar el gateway de servicios para Oracle Services Network. Con este cambio, las instancias públicas mantienen el acceso a todos los servicios de Oracle a través del gateway de Internet. Los servicios de Oracle pueden seguir accediendo a sus instancias públicas.

Sin embargo, sus instancias en la subred pública pueden seguir accediendo al almacenamiento de objetos mediante el gateway de servicios. Actualice la tabla de rutas de la subred para que incluya una regla de ruta con el servicio de destino definido como Object Storage de <region> de OCI y el destino definido en el gateway de servicio de la red virtual en la nube.

Este problema conocido solo se aplica a las subredes públicas que tienen acceso a un gateway de Internet. Con respecto a las subredes privadas, puede configurar la tabla de rutas de una subred privada para proporcionar acceso a Todos los servicios de ><region> de Oracle Services Network o a Object Storage de <region> de OCI a través del gateway de servicios de la red virtual en la nube.

Enlace directo a este problema: Problemas con el acceso de los servicios de Oracle a través de un gateway de servicios a las instancias públicas

Despliegue de una máquina virtual de dispositivo virtual de red para unir dos VCN

Detalles: si despliega una máquina virtual de dispositivo virtual de red para unir dos VCN y ha instalado una regla de ruta, es posible que los servicios de Oracle no puedan acceder a sus instancias públicas en esa subred.

Solución alternativa: agregue una ruta estática específica al CIDR de Oracle para recorrer el tráfico de vuelta a la VCN de origen.

RESUELTO: Reglas de ruta de gateway de servicio y restricción de consola

Detalles: si utiliza la Consola para configurar una regla de ruta que utilice un gateway de servicio como destino, el servicio de destino de la regla debe coincidir con la etiqueta CIDR del servicio que está activada para ese gateway. Por ejemplo, supongamos que utiliza la Consola para activar la etiqueta denominada Todos los <region> servicios en Oracle Services Network para el gateway de servicio. A continuación, utilice la Consola para configurar una regla de ruta y seleccione OCI <region> Almacenamiento de objetos para el servicio de destino en lugar de la etiqueta CIDR de servicio que especificó para el gateway de servicio. Al intentar definir el destino para la regla de ruta, el gateway de servicio no aparece en la lista de gateways de servicio entre los que elegir. Esto se debe a que la consola toma el servicio de destino especificado para la regla y muestra solo los gateways de servicio con ese CIDR de servicio activado. La red virtual en la nube solo puede tener un gateway de servicios y, en este caso, no coincide con la lógica. Esta restricción solo existe cuando configura la regla de ruta en la Consola. Otras interfaces (SDK, CLI, Terraform) no tienen esta restricción. Oracle pretende eliminar esta restricción de la interfaz de la Consola.

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

Use la misma etiqueta CIDR de servicio para el gateway de servicio y el servicio de destino de la regla de ruta. Si lo desea, use una interfaz diferente que no tenga la restricción (por ejemplo, la CLI). Además, recuerde que puede filtrar el tráfico desde y a las instancias mediante listas de seguridad y puede utilizar cualquier etiqueta CIDR de servicio (o un CIDR específico) en una regla de lista de seguridad.

Enlace directo a este problema: Reglas de ruta del gateway de servicio y restricción de la Consola

Problemas para acceder a los servicios de yum de Oracle a través del gateway de servicios
Detalles: si desea utilizar un gateway de servicios con red virtual en la nube sin utilizar también un gateway de Internet o un gateway de traducción de direcciones de red para el acceso a Internet, puede que las instancias no tengan acceso al servidor regional de yum de Oracle correspondiente. Hay dos posibles incidencias:
  • Las instancias creadas antes de noviembre de 2018 podrían tener sus repositorios apuntando a direcciones URL a las que no se puede acceder a través del gateway de servicios
  • Las instancias que no han podido contactar con el servidor de yum de su región local pueden haber recurrido a yum.oracle.com, al que no se puede acceder mediante el gateway de servicios
Requisito: para utilizar cualquiera de las siguientes estrategias de mitigación, debe tener uno de los siguientes gateways configurados para alcanzar el servidor de yum de la región: gateway de servicio, gateway de traducción de direcciones de Internet o gateway de Internet.

Mitigación automatizada:

Pruebe la siguiente mitigación automatizada. Si falla por algún motivo, use el método de mitigación manual que se indica a continuación.

Copie la siguiente secuencia de comandos en el sistema local y ejecútela. La secuencia de comandos desactiva los repositorios existentes y descarga el archivo repo, que dirige el sistema a los servidores yum locales de la región a los que se puede acceder mediante el gateway de servicios.

#!/bin/bash
REPODIR='/etc/yum.repos.d'
REPOS=$REPODIR/*
REGION=$(curl -sfm 3 http://169.254.169.254/opc/v1/instance/ | jq -r '.region' | cut -d '-' -f 2)
VERSION=$(egrep '^VERSION_ID' /etc/os-release | cut -d '"' -f 2 | cut -d '.' -f 1)
REPOURL="http://yum-${REGION}.oracle.com/yum-${REGION}-ol${VERSION}.repo"

echo "Disabling existing repos"
for i in $REPOS
do
  if [[ "$i" != *".disabled" ]]; then
    mv $i $i.disabled
    echo "$i disabled"
  else
    echo "$i repofile already disabled"
  fi
done
yum clean all
echo "Pulling new regional repository file"
wget -q $REPOURL -O "$REPODIR/yum-${REGION}-ol${VERSION}.repo"
retval=$?
if [[ "$retval" -ne 0 ]]; then
  echo "Unable to pull repo file, please run manual steps"
  exit 1
fi
yum makecache fast
Mitigación manual:

Si se produce un fallo en la mitigación automatizada, puede mitigar el problema manualmente. Aquí puede desactivar los archivos de repositorio existentes y extraer el último archivo de repositorio del servidor de yum de su región. Para identificar la clave de región de la instancia, consulte la lista de regiones en Regiones y dominios de disponibilidad.

Para desactivar los archivos de repositorio existentes, navegue al directorio /etc/yum.repos.d y cambie el nombre de todos los archivos presentes para incluir .disabled al final del nombre de archivo.

Ejemplo:

ls /etc/yum.repos.d ksplice-uptrack.repo.disabled public-yum-ol7.repo.disabled

Descargue el archivo de repositorio de su región en el sistema local. En el siguiente ejemplo se utiliza Ashburn (con la clave de región iad). Sustituya iad por la clave de región aplicable a la instancia.

cd /etc/yum.repos.d/
wget http://yum-iad.oracle.com/yum-iad-ol7.repo
chown root:root yum-iad-ol7.repo
yum makecache fast

Enlace directo a este problema: Acceso a los servicios de Yum a través del gateway de servicios para determinadas imágenes

RESUELTO: las instancias existentes en una subred no obtienen una lista actualizada de servidores DNS en las opciones DHCP

Detalles: si actualiza la lista de servidores DNS en un conjunto de opciones DHCP de una subred, las nuevas instancias o VNIC que cree posteriormente en esa subred mostrarán la lista actualizada de servidores DNS, pero no las instancias/VNIC existentes en la subred.

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

Puede crear nuevas instancias en la subred para sustituir las existentes. Otra opción es ponerse en contacto con My Oracle Support con la siguiente información:

  • OCID de VCN
  • OCID de la subred
  • OCID de instancia afectada

Por lo general, el problema de esa instancia en concreto se puede resolver en un día.

Vínculo directo a este problema: Las instancias existentes en una subred no obtienen una lista actualizada de los servidores DNS en las opciones DHCP

FTP activo no soportado en instancias de Windows

Detalles: el cliente de FTP por defecto proporcionado por Microsoft Windows solo soporta FTP en modo activo, lo cual no funciona con las reglas de firewall con estado de Oracle ni con las instancias desplegadas detrás de un gateway de NAT.

Solución alternativa: Oracle recomienda que las instancias de Windows utilicen un cliente de FTP de terceros que se ejecute en modo pasivo.

Enlace directo a esta incidencia: FTP activo no soportado en instancias de Windows

Notifications

Actualmente, no hay problemas conocidos de notificaciones.

Object Storage

Actualmente, no hay problemas conocidos de almacenamiento de objetos.

Operations Insights

Actualmente, no hay ninguna incidencia conocida de Operations Insights.

OS Management

Para obtener información sobre los problemas conocidos en el servicio OS Management, consulte Problemas conocidos.

Registry

Utilice el espacio de nombres de arrendamiento en lugar del nombre de arrendamiento en las etiquetas de imagen y las credenciales de conexión de Docker a más tardar el 30 de septiembre de 2019

Detalles: hasta ahora, puede que haya estado utilizando el nombre de arrendamiento o el espacio de nombres del arrendamiento al conectarse a Oracle Cloud Infrastructure Registry y al realizar operaciones en imágenes en el Registro de contenedor.

Después del 30 de septiembre de 2019, tendrá que utilizar el espacio de nombres de arrendamiento en lugar del nombre del arrendamiento al utilizar Oracle Cloud Infrastructure Registry.

Fondo: después del 30 de septiembre de 2019, no podrá:

  • Especificar el nombre de arrendamiento al conectarse a Oracle Cloud Infrastructure Registry.
  • Realizar operaciones en imágenes que incluyen el nombre de arrendamiento en la ruta de acceso al repositorio.

En su lugar, tendrá que utilizar el espacio de nombres de arrendamiento en vez del nombre de arrendamiento al utilizar Oracle Cloud Infrastructure Registry.

Un espacio de nombres de arrendamiento es una cadena aleatoria automáticamente generada e inmutable de caracteres alfanuméricos. Por ejemplo, el espacio de nombres del arrendamiento acme-dev puede ser ansh81vru1zp. Puede ver el espacio de nombres de arrendamiento en la página Registro de contenedor de la consola.

Tenga en cuenta que para algunos arrendamientos más antiguos, el espacio de nombres de arrendamiento puede ser el mismo que el nombre de arrendamiento. En ese caso, no se necesita ninguna acción.

Antes de que acabe el día 30 de septiembre de 2019, si el espacio de nombres de arrendamiento y el nombre de arrendamiento no coinciden, debe:

  • Empezar a especificar el espacio de nombres de arrendamiento al conectarse a Oracle Cloud Infrastructure Registry, en lugar del nombre de arrendamiento.
  • Empezar a especificar el espacio de nombres de arrendamiento al transferir nuevas imágenes a Oracle Cloud Infrastructure Registry, en lugar del nombre de arrendamiento.
  • Migrar las imágenes existentes en Oracle Cloud Infrastructure Registry que incluyan el nombre de arrendamiento en la ruta.

Las siguientes soluciones alternativas y ejemplos suponen lo siguiente:

  • el nombre de arrendamiento es acme-dev
  • el espacio de nombres de arrendamiento es ansh81vru1zp
  • el nombre de usuario es jdoe@acme.com

Solución alternativa para conectarse a Oracle Cloud Infrastructure Registry: anteriormente, cuando se conectaba a Oracle Cloud Infrastructure Registry y se le solicitaba un nombre de usuario, podía introducirlo con el formato <tenancy-name>/<username>.

Por ejemplo:

$ docker login phx.ocir.io

Username: acme-dev/jdoe@acme.com
Password:

Antes de que acabe el día 30 de septiembre de 2019, debe comenzar a utilizar el espacio de nombres de arrendamiento en lugar del nombre de arrendamiento al conectarse a Oracle Cloud Infrastructure Registry. Cuando se le solicite el nombre de usuario, introdúzcalo con el formato <tenancy-namespace>/<username>.

Por ejemplo:

$ docker login phx.ocir.io

Username: ansh81vru1zp/jdoe@acme.com
Password:

Solución alternativa para enviar nuevas imágenes a Oracle Cloud Infrastructure Registry: anteriormente, al enviar una nueva imagen a Oracle Cloud Infrastructure Registry, podría especificar el nombre de arrendamiento como parte de la ruta de repositorio en el comando docker push. Podría introducir el comando en el formato:

$ docker push <region-key>.ocir.io/<tenancy-name>/<image-name>:<tag>

Por ejemplo:

$ docker push phx.ocir.io/acme-dev/helloworld:latest

Antes de que acabe el día 30 de septiembre de 2019, debe comenzar a utilizar el espacio de nombres de arrendamiento en lugar del nombre de arrendamiento en el comando docker push cuando envíe nuevas imágenes. Introduzca el comando en el formato:

$ docker push <region-key>.ocir.io/<tenancy-namespace>/<image-name>:<tag>

Por ejemplo:

$ docker push phx.ocir.io/ansh81vru1zp/helloworld:latest

Solución alternativa para imágenes existentes en Oracle Cloud Infrastructure Registry que incluyen el nombre de arrendamiento en la ruta del repositorio: si ya ha enviado imágenes a Oracle Cloud Infrastructure Registry, esas imágenes existentes pueden incluir el nombre de arrendamiento como parte de la ruta del repositorio. Por ejemplo, phx.ocir.io/acme-dev/helloworld:latest.

A partir del 30 de septiembre de 2019, no podrá realizar operaciones en imágenes existentes en el Registro de contenedor que incluyan el nombre del arrendamiento en la ruta del repositorio.

Por lo tanto, antes de que acabe el día 30 de septiembre de 2019, debe sustituir el nombre del arrendamiento de toda imagen existente en la ruta del repositorio que lo contenga por el espacio de nombres de arrendamiento.

Para sustituir el nombre de arrendamiento por el espacio de nombres de arrendamiento en la ruta de acceso al repositorio de una imagen existente:

  1. Extraiga la imagen al escribir lo siguiente:

    $ docker pull <region-key>.ocir.io/<tenancy-name>/<image-name>:<tag>

    Por ejemplo:

    $ docker pull phx.ocir.io/acme-dev/helloworld:latest
  2. Utilice el comando docker tag para cambiar la ruta del repositorio introduciendo:

    $ docker tag <region-key>.ocir.io/<tenancy-name>/<image-name>:<tag> <region-key>.ocir.io/<tenancy-namespace>/<image-name>:<tag>

    Por ejemplo:

    $ docker tag phx.ocir.io/acme-dev/helloworld:latest phx.ocir.io/ansh81vru1zp/helloworld:latest
  3. Inserte la imagen con la nueva ruta de repositorio en el Registro de contenedor introduciendo:

    $ docker push <region-key>.ocir.io/<tenancy-namespace>/<image-name>:<tag>

    Por ejemplo:

    $ docker push phx.ocir.io/ansh81vru1zp/helloworld:latest
  4. Repita los pasos anteriores con cada imagen existente que tenga un nombre de arrendamiento en la ruta de acceso al repositorio.

Enlace directo a este problema: Utilice el espacio de nombres de arrendamiento en lugar del nombre de arrendamiento en las etiquetas de imagen y las credenciales de conexión de Docker a más tardar el 30 de septiembre de 2019

Resource Manager

Error: el disyuntor está abierto

Detalles: los logs de un trabajo muestran lo siguiente: Error: Circuit breaker is open. Este error suele indicar un error con un servicio descendente.

Solución alternativa: somos conscientes del problema y estamos trabajando para solucionarlo. Siga estas instrucciones para identificar el servicio descendente que causa el error y, a continuación, póngase en contacto con ese servicio para determinar la resolución.

  1. Recopile información de depuración ejecutando un nuevo trabajo en la pila:

    1. Muestre el panel de trabajo para el tipo de trabajo que desea ejecutar (Plan, Aplicar o Destruir).

    2. En el panel de trabajo, haga clic en Mostrar opciones avanzadas.

    3. Defina Nivel de log detallado en Depurar.

      Espere a que el trabajo termine de ejecutarse.

      Para obtener más información sobre la depuración de logs de trabajos de Terraform, consulte la sección sobre depuración de Terraform.

  2. Descargue el log detallado: en la página Detalles del trabajo del trabajo que acaba de ejecutar, haga clic en Descargar archivo log detallado (en el separador Información del trabajo, a la derecha de Nivel de log detallado).

  3. Revise el log descargado para identificar los servicios descendentes asociados al error.

  4. Póngase en contacto con el servicio descendente asociado para determinar la resolución.

Enlace directo a esta incidencia: Error: el disyuntor está abierto

Es posible que los cubos de Object Storage no estén disponibles en la consola para las nuevas pilas

Detalles: al utilizar la consola para crear una pila a partir de un cubo en Object Storage, la lista de valores de Cubos de almacenamiento de objetos solo está disponible cuando el espacio de nombres de cubo es idéntico al nombre de arrendamiento.

Solución alternativa: cree la pila mediante el SDK, la CLI o la API en su lugar. Somos conscientes del problema y estamos trabajando para solucionarlo.

Enlace directo a esta incidencia: Es posible que los cubos de Object Storage no estén disponibles en la consola para las nuevas pilas

Fallo de detección de recursos (incidencia de permisos)

Detalles: al utilizar la detección de recursos para crear una pila desde un compartimento, la solicitud de trabajo falla.

Posible causa: el usuario que crea la pila carece de permisos para inspeccionar compartimentos para el arrendamiento.

Solución alternativa: para resolver este problema, asegúrese de que el usuario que está creando la pila tiene permisos para inspeccionar los compartimentos del arrendamiento. Para el grupo al que pertenece el usuario, cree la siguiente política.

Allow group <group name> to inspect compartments in tenancy

Enlace directo a este problema: Fallo de la detección de recursos

Faltan atributos en algunos recursos detectados

Detalles: faltan atributos en algunos recursos soportados capturados mediante la detección de recursos.

Servicio Tipo de recurso Campos que faltan (con enlaces a la documentación del proveedor Terraform de oci)
Big Data Service Instancias

cluster_admin_password

cluster_public_key

Block Volume (principal) Volúmenes volume_backup_id
Compute (principal) Imágenes instance_id

image_source_details

Compute (principal) Configuraciones de instancia instance_id

source

Compute (principal) Conexiones de consola de instancias public_key
Compute (principal) Instancias

hostname_label (en desuso)

is_pv_encryption_in_transit_enabled

subnet_id (en desuso)

Compute (principal) Asociaciones de volumen use_chap
Motor de contenedor para Kubernetes Pools de nodos node_source_details
Data Catalog Conexiones enc_properties
Database Bases de datos de contenedor autónomas maintenance_window_details
Database Bases de datos autónomas

admin_password

autonomous_database_backup_id

autonomous_database_id

clone_type

is_preview_version_with_service_terms_accepted

source

source_id

timestamp

Database Infraestructuras de Exadata autónomas maintenance_window_details
Database Bases de datos

admin_password

backup_id

backup_tde_password

db_version

source

Database Directorios raíz de bases de datos

admin_password

backup_id

backup_tde_password

source

Database Sistemas de bases de datos

admin_password

backup_id

backup_tde_password

maintenance_window_details

IAM Proveedores de identidad metadata
Equilibrio de carga Equilibradores de carga ip_mode
Marketplace Acuerdos aceptados signature
Networking (principal) Conexiones cruzadas

far_cross_connect_or_cross_connect_group_id

near_cross_connect_or_cross_connect_group_id

NoSQL Database Cloud Índices is_if_not_exists
Almacenamiento de objetos Objetos

cache_control

content

content_disposition

content_encoding

content_language

source

source_uri_details

Seguridad y Web Application Acceleration Certificados

certificate_data

is_trust_verification_disabled

private_key_data

Seguridad y Web Application Acceleration Políticas

are_redirects_challenged

is_case_sensitive

is_nat_enabled (human_interaction_challenge)

is_nat_enabled (js_challenge)

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

Enlace directo a este problema: Faltan atributos en algunos recursos detectados

Service Connector Hub

Varios mensajes SMS para una sola notificación

Detalles: una notificación que excede el máximo de caracteres soportado para un único mensaje SMS se divide y se envía como varios mensajes SMS, lo que tiene implicaciones de facturación.

Esta incidencia se produce cuando el origen de Flujo se especifica para un conector de servicio que utiliza el destino Notificaciones, que hace referencia a un tema que contiene suscripciones de SMS.

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

Enlace directo a esta incidencia: Varios mensajes SMS para una sola notificación

Service Mesh

Actualmente, no hay ningún problema conocido con el servicio Service Mesh.

Speech

Actualmente, no hay ninguna incidencia conocida con el servicio Speech.

Storage Gateway

Excepciones de conformidad con POSIX

Detalles: no se admiten las siguientes traducciones de archivo a objeto.

  • ACL
  • Symlinks, enlaces físicos, tubos con nombre y dispositivos especiales
  • Bits de permanencia

Solución alternativa: si necesita copiar archivos especiales en el almacenamiento de objetos, cree un archivo tar de los archivos.

Enlace directo a este problema: Excepciones a la conformidad con POSIX

El comando df no puede informar de un tamaño y capacidad precisos

Detalles: si ejecuta el comando df en un sistema de archivos de un cliente de sistema de archivos de red, df informa de un tamaño de sistema de archivos de 0 (cero) bytes y una capacidad de 8 EB (capacidad máxima). Dado que el almacenamiento de objetos no tiene cuotas y puede almacenar una cantidad ilimitada de datos, no hay una manera de informar del tamaño del sistema de archivos. Debido a que el bloque de almacenamiento de objetos no informa del uso del almacenamiento, no hay una forma de informar de la capacidad.

Solución alternativa: puede ejecutar el comando du para obtener el uso. Sin embargo, este comando consume muchos metadatos y tarda más en informar del uso. También puede enumerar todos los objetos en Almacenamiento de objetos y agregar el tamaño del objeto para determinar el uso actual de Almacenamiento de objetos. Sin embargo, este método no tiene en cuenta la cantidad de datos almacenados en la caché del sistema de archivos. También puede explorar mecanismos fuera de banda que realicen un cálculo aproximado del uso de almacenamiento.

Enlace directo a este problema: El comando df no puede informar de un tamaño y capacidad precisos

Etiquetado

Fallo al crear un valor predeterminado de etiqueta en determinadas condiciones

Detalles: la creación de un valor predeterminado de etiqueta falla cuando se cumplen las dos condiciones siguientes: el espacio de nombres de etiqueta solo contiene una definición de clave activa y el espacio de nombres de etiqueta contiene varias definiciones de clave de etiqueta retiradas.

Solución alternativa: para resolver este problema, puede crear otra definición de clave de etiqueta en el espacio de nombres de etiqueta.

Enlace directo a este problema: Fallo al crear un valor predeterminado de etiqueta en determinadas condiciones

Fallo al suprimir un valor predeterminado de etiqueta al retirarla

Detalles: si intenta suprimir un valor predeterminado de una etiqueta que se ha retirado, recibirá un mensaje de error.

Solución alternativa: vuelva a activar la definición de etiqueta y, a continuación, suprima el valor predeterminado de etiqueta.

Enlace directo a este problema: Fallo al suprimir un valor predeterminado de etiqueta al retirarla

Cambio de estado de Terraform con valores predeterminados de etiquetas y etiquetas para recursos secundarios

Detalles: en algunas creaciones de Terraform, no se crean etiquetas para los recursos secundarios y las etiquetas predeterminadas configuradas para un compartimento no se aplican automáticamente a los recursos. Esto puede causar que falten etiquetas predeterminadas y que los recursos secundarios no tengan etiquetas que coincidan con los recursos principales. En algunos casos, Terraform puede entrar en un bucle infinito.

Solución alternativa: evalúe la secuencia de comandos de Terraform y cada compartimento en el arrendamiento para detectar posibles problemas de etiquetado.

  1. Evalúe la secuencia de comandos de Terraform.

    • Para cualquier recurso principal que encuentre que contenga etiquetas, copie el formato libre o la etiqueta definida en el recurso secundario. Por ejemplo, si la configuración de Terraform tiene un recurso principal, como una instancia informática y un recurso secundario anidado, como una VNIC asociada, copie las etiquetas de la instancia informática en la VNIC. Las VCN y los pools de instancias también son recursos principales que pueden crear recursos secundarios.

  2. Evalúe el árbol de directorios en el arrendamiento que va a crear.

    1. Comience en el compartimento raíz y determine si dicho compartimento tiene etiquetas predeterminadas configuradas. Aunque los valores de etiqueta son opcionales, los valores predeterminados de etiqueta pueden especificar que una etiqueta necesita un valor.

    2. Se definen valores predeterminados de etiqueta para un compartimento específico, y los gestiona en la Consola, en la página Detalles de compartimento.

      Esta captura de pantalla muestra la página Detalles de compartimento en la Consola

    3. Si el compartimento tiene etiquetas predeterminadas para recursos creados en este compartimento, aplique las etiquetas y los valores de etiquetas necesarios que crearán estos valores predeterminados a todos los recursos que cree con la secuencia de comandos de Terraform. Debido a la herencia de etiquetas, la etiqueta predeterminada se aplica a todos los recursos que se crean en el compartimento, incluidos los compartimentos secundarios y los recursos creados en los compartimentos secundarios. Consulte Herencia de etiquetas.
    4. Repita estos pasos en todos los compartimentos secundarios, actualizando la secuencia de comandos de Terraform para llevar cuenta de las etiquetas predeterminadas.

Enlace directo a este problema: Cambio del estado de Terraform con valores predeterminados de etiquetas y etiquetas para recursos secundarios

Políticas de dirección de gestión de tráfico

Actualmente, no hay problemas conocidos de las políticas de dirección de gestión de tráfico.

Vault

Actualmente, no hay problemas conocidos del servicio de almacén.

Firewall de aplicaciones web (WAF)

No se ha podido agregar el origen por defecto a la política de WAF creada con la API

Detalles: al crear una política de WAF con la API, si no se especifica un origen por defecto, no se puede agregar el origen por defecto más tarde mediante la consola o la API. Esta incidencia no se aplica a las políticas creadas mediante la consola.

Solución alternativa: suprima la política creada sin un origen por defecto y cree una nueva política con el origen por defecto especificado.

Enlace directo a esta incidencia: No se ha podido agregar el origen por defecto a la política de WAF creada con la API

Las versiones TLS_V1 y TLS_V1_1 de TLS están en desuso

Detalles: las versiones TLS_V1 y TLS_V1_1 de TLS están en desuso y no se pueden utilizar en configuraciones de políticas. Si utiliza estas versiones, es posible que se produzca una validación.

Solución alternativa: para solucionar esta incidencia, actualice la configuración de la política para utilizar la versión TLS_V1_2 o TLS_V1_3, o ambas.

Enlace directo a esta incidencia: Las versiones TLS_V1 y TLS_V1_1 de TLS están en desuso

El cambio global de DNS causará la interrupción del servicio si las nuevas subredes no aparecen en la lista blanca

Detalles: se realizarán cambios globales de DNS para todos los clientes de Oracle Web Application Firewall (WAF) a partir de diciembre de 2019. Todos los clientes que tienen un bloqueo de origen (mediante una lista blanca de IP explícita) y no incluyen en la lista blanca las nuevas subredes sufrirán tiempo de inactividad y una degradación del servicio.

Solución alternativa: (acción necesaria) los clientes deben incluir en la lista blanca las nuevas subredes para evitar la interrupción del servicio. Para obtener la documentación de API, consulte ListEdgeSubnets.

Lista blanca de expansión OCI WAF

130.35.0.0/20

130.35.128.0/20

130.35.240.0/20

138.1.32.0/21

138.1.128.0/19

147.154.96.0/19

192.29.96.0/20

130.35.16.0/20

130.35.48.0/20

130.35.64.0/19

130.35.96.0/20

130.35.120.0/21

130.35.144.0/20

130.35.176.0/20

130.35.192.0/19

130.35.224.0/22

130.35.232.0/21

138.1.48.0/21

147.154.0.0/18

147.154.64.0/20

147.154.80.0/21

130.35.112.0/22

138.1.16.0/20

138.1.80.0/20

138.1.208.0/20

138.1.224.0/19

147.154.224.0/19

138.1.0.0/20

138.1.40.0/21

138.1.64.0/20

138.1.96.0/21

138.1.104.0/22

138.1.160.0/19

138.1.192.0/20

147.154.128.0/18

147.154.192.0/20

147.154.208.0/21

192.29.0.0/20

192.29.64.0/20

192.29.128.0/21

192.29.144.0/21

192.29.16.0/21

192.29.32.0/21

192.29.48.0/21

192.29.56.0/21

Enlace directo a este problema: El cambio global de DNS causará la interrupción del servicio si las nuevas subredes no aparecen en la lista blanca