Gestión de infraestructura de Grid

Esta sección se centra en la gestión de Oracle Grid Infrastructure, que soporta clusters y alta disponibilidad. Las tareas clave incluyen la configuración de un directorio raíz de Grid Infrastructure (dbaascli gridHome create), la actualización de Grid Infrastructure (dbaascli grid upgrade) y la gestión de certificados de TCPS (seguridad de capa de transporte) mediante la configuración (dbaascli grid configureTCPS), la eliminación (dbaascli grid removeTCPSCert) o su rotación (dbaascli grid rotateTCPSCert). Estos comandos garantizan una configuración, un mantenimiento y una seguridad eficientes de Grid Infrastructure.

creación de dbaascli gridHome
dbaascli grid configureTCPS
cuadrícula dbaascli removeTCPSCert
dbaascli grid rotateTCPSCert
dbaascli grid upgrade
dbaascli grid patch

creación de dbaascli gridHome

Para configurar el directorio raíz de Grid Infrastructure, utilice el comando dbaascli gridHome create.

Requisitos previos:

Ejecute el comando con el usuario root.

Sintaxis:

dbaascli gridHome create --version value [--resume [--sessionID value]] [--waitForCompletion value]

Parámetros:

Parámetro	Descripción
`--version`	Especifica la versión del directorio raíz de Grid
`--resume`	reanuda la ejecución anterior
`--sessionID`	Especifica que se reanude un identificador de sesión específico
`--waitForCompletion`	`false` especifica para que se ejecute la operación en segundo plano. Valores válidos: `true` o `false`

Preguntas frecuentes:

P: ¿Cuál es la finalidad del comando dbaascli gridHome create?

R: El comando dbaascli gridHome create se utiliza para configurar un directorio raíz de Grid Infrastructure para la infraestructura de Oracle Grid en un entorno de Oracle Base Database Cloud@Customer.

P: ¿Cuál es el requisito para ejecutar el comando dbaascli gridHome create?

R: El comando se debe ejecutar como el usuario root.

P: ¿Cómo especifico la versión del directorio raíz de Grid Infrastructure que se va a crear?

R: Utilice la opción --version para especificar la versión del directorio raíz de Grid. Esta es una opción obligatoria al crear el directorio raíz de Grid.

P: ¿Puedo reanudar una sesión de creación de dbaascli gridHome anterior?

R: Sí, puede utilizar la opción --resume para reanudar una sesión anterior. Opcionalmente, puede especificar el ID de sesión mediante la opción --sessionID para reanudar una sesión específica.

P: ¿Qué hace la opción –resume en el comando dbaascli gridHome create?

R: La opción --resume permite reanudar una operación interrumpida o incompleta anteriormente.

P: ¿Cómo puedo ejecutar la operación en segundo plano?

R: Puede definir la opción --waitForCompletion en false para ejecutar la operación en segundo plano. Los valores válidos para esta opción son true (valor por defecto) o false.

P: ¿Cuál es el comportamiento predeterminado si no se especifica –waitForCompletion?

R: Si no se especifica --waitForCompletion, la operación se ejecutará en primer plano y el comando esperará a que se complete la operación antes de devolver el control al usuario.

P: ¿Cuál es el propósito de la opción –sessionID?

R: La opción --sessionID se utiliza para especificar el ID de una sesión anterior que desea reanudar, en caso de una operación incompleta o interrumpida.

P: ¿Puedo utilizar el comando de creación de dbaascli gridHome para actualizar un directorio raíz de Grid existente?

R: No, este comando se utiliza específicamente para configurar un nuevo directorio raíz de Grid Infrastructure, no para actualizar uno existente.

P: ¿Qué es un comando de ejemplo para crear un directorio raíz de Grid con la versión 19.9.0.0.0?

A: A continuación, se muestra un comando de ejemplo:

dbaascli gridHome create --version 19.9.0.0.0

P: ¿Qué debo hacer si se interrumpe el comando dbaascli gridHome create?

R: Puede reanudar la operación mediante la opción --resume. Si tiene el ID de sesión, puede proporcionarlo mediante la opción --sessionID para reanudar una sesión específica.

P: ¿Puedo especificar la opción –resume sin un ID de sesión?

R: Sí, puede utilizar la opción --resume sin especificar un ID de sesión. En este caso, el sistema intentará reanudar la sesión más reciente.

P: ¿Qué sucede si especifico –waitForCompletion false?

R: Si especifica --waitForCompletion false, la operación se ejecutará en segundo plano, lo que le permitirá seguir utilizando la línea de comandos mientras se completa la operación.

P: ¿Es posible realizar un seguimiento del progreso de una operación en segundo plano?

R: El comando dbaascli no proporciona una forma directa de realizar un seguimiento de las operaciones en segundo plano. Puede que tenga que comprobar los logs del sistema o el estado de la sesión manualmente.

P: ¿Puedo especificar una versión de directorio raíz de Grid no válida al crearla?

R: No, la opción --version debe contener una versión de Grid Infrastructure válida. Si se proporciona una versión no válida, el comando devolverá un error.

P: ¿Cómo puedo determinar la versión del directorio raíz de Grid que utilizar para la creación?

R: Puede consultar la documentación de Oracle o consultar con el administrador de la base de datos para determinar la versión correcta del directorio raíz de Grid que se va a utilizar para su entorno.

P: ¿Qué debo verificar antes de ejecutar el comando dbaascli gridHome create?

R: Asegúrese de que está conectado como usuario root y de que la versión que desea utilizar para Grid Infrastructure es compatible con su entorno.

dbaascli grid configureTCPS

Para configurar TCPS para el cluster existente, utilice el comando dbaascli grid configureTCPS.

Requisitos previos:

Ejecute el comando con el usuario root.

Sintaxis:

dbaascli grid configureTCPS
[--pkcs12WalletFilePath]
[--caCertChain]
[--precheckOnly]
[--serverCert]
[--privateKey]
[--certType]
[--privateKeyPasswordProtected]

Parámetros:

Parámetro	Descripción
`--pkcs12WalletFilePath`	especifica la ruta de acceso absoluta del archivo del certificado, que tiene el formato `pkcs12` de cartera
`--caCertChain`	lista concatenada de certificados, que contienen certificados de CA intermedios y certificados de CA raíz
`--precheckOnly`	Especifica `yes` para ejecutar solo las comprobaciones previas de esta operación. Valores válidos: `yes` o `no`.
`--serverCert`	Especifica la ruta del certificado PEM que se utilizará o rotará para la configuración de TCPS.
`--privateKey`	Especifica la ruta del archivo de clave privada del certificado.
`--certType`	tipo del certificado que se agregará a la cartera de Grid Infrastructure. Los valores aceptados son: `SELF_SIGNED_CERT`, `CA_SIGNED_CERT` o `PKCS12_CERT`. Valor por defecto: `SELF_SIGNED_CERT`
`--privateKeyPasswordProtected`	Especifica si la clave privada está protegida por contraseña o no. Valores válidos: `true` o `false`. Valor por defecto: `true`.

Configuración de TCPS para Oracle Base Database Cloud@Customer:

El comportamiento de TCPS difiere según el tipo de despliegue de Oracle Base Database Cloud@Customer:

Para Oracle Database 19c y versiones posteriores, TCPS está activado por defecto para las bases de datos recién aprovisionadas. Es posible que las bases de datos existentes que se aprovisionaron antes de introducir este comportamiento no tengan activado TCPS.

Para activar TCPS para una base de datos existente, actualice el archivo sqlnet.ora específico de la base de datos en todos los nodos de base de datos agregando el parámetro WALLET_LOCATION de la siguiente manera:

WALLET_LOCATION = (SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/var/opt/oracle/dbaas_acfs/grid/tcps_wallets)))

Después de actualizar el archivo sqlnet.ora en todos los nodos de la base de datos, reinicie la base de datos para activar TCPS.

La activación de TCPS puede afectar a la conectividad de Oracle Zero Data Loss Recovery Appliance (ZDLRA) si la base de datos no está configurada para utilizar el parámetro WALLET_ROOT. Antes de activar TCPS, compruebe que se cumplan los siguientes requisitos:

La base de datos está ejecutando la versión 19.17 de Oracle Database o posterior.
La base de datos está configurada para utilizar el parámetro WALLET_ROOT.
Si la base de datos está configurada para copias de seguridad ZDLRA, compruebe que la configuración del canal de RMAN hace referencia a RA_WALLET en WALLET_ROOT/server_seps.

Por ejemplo:

Conéctese a RMAN.
Ejecute el siguiente comando:
```
SHOW CHANNEL;
```

Verifique que la salida contiene una entrada RA_WALLET similar a la siguiente:

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' FORMAT '%d_%I_%U_%T_%t' PARMS "SBT_LIBRARY=/u02/app/oracle/product/19.0.0.0/dbhome_1/lib/libra.so, ENV=(RA_WALLET='location=file:/var/opt/oracle/dbaas_acfs/dbrs19c/wallet_root/server_seps credential_alias=DBRS')";

En este ejemplo, la ubicación RA_WALLET apunta a WALLET_ROOT/server_seps, que es compatible con TCPS.

Preguntas frecuentes:

P: ¿Cuál es la finalidad del comando dbaascli grid configureTCPS?

R: El comando dbaascli grid configureTCPS se utiliza para configurar la seguridad de capa de transporte (TCPS) para el cluster existente en un entorno de Oracle Base Database Cloud@Customer.

P: ¿Cuál es el requisito para ejecutar el comando dbaascli grid configureTCPS?

R: El comando se debe ejecutar como el usuario root.

P: ¿Está activado TCPS por defecto en los sistemas Oracle Base Database Cloud@Customer?

R: No, TCPS no está activado por defecto en los sistemas Oracle Base Database Cloud@Customer. Para activar TCPS, debe actualizar el archivo sqlnet.ora para la base de datos específica y reiniciar la base de datos.

P: ¿Cuál es la consecuencia de activar TCPS en los sistemas Oracle Base Database Cloud@Customer?

R: La activación de TCPS en los sistemas Oracle Base Database Cloud@Customer provocará el fallo de las conexiones de Zero Data Loss Recovery Appliance (ZDLRA). Solo puede activar la configuración de ZDLRA o TCPS, pero no ambas simultáneamente.

P: ¿Qué especifica la opción –pkcs12WalletFilePath?

R: La opción --pkcs12WalletFilePath especifica la ruta de acceso absoluta al archivo de certificado en formato de cartera PKCS12, que se utiliza para la configuración de TCPS.

P: ¿Para qué se utiliza la opción –caCertChain?

R: La opción --caCertChain especifica una lista concatenada de certificados que contienen certificados de CA intermedios y el certificado de CA raíz.

P: ¿Qué hace la opción –precheckOnly?

R: La opción --precheckOnly especifica si se deben ejecutar solo las comprobaciones previas para la operación de configuración de TCPS. Los valores aceptados son yes o no.

P: ¿Qué especifica la opción –serverCert?

R: La opción --serverCert especifica la ruta al certificado PEM que se utilizará o rotará para la configuración de TCPS.

P: ¿Cómo puedo especificar la clave privada para la configuración de TCPS?

R: Utilice la opción --privateKey para especificar la ruta de acceso al archivo de clave privada asociado al certificado de servidor.

P: ¿Cuáles son los valores aceptados para la opción –certType?

R: Los valores aceptados para la opción --certType son:

SELF_SIGNED_CERT
CA_SIGNED_CERT
PKCS12_CERT

El valor por defecto es SELF_SIGNED_CERT.

P: ¿Está protegida por defecto la contraseña de clave privada?

R: Sí, la opción --privateKeyPasswordProtected está definida en true por defecto, lo que indica que la clave privada está protegida por contraseña. Puede definirla en false si la clave privada no está protegida por contraseña.

P: ¿Puedo ejecutar una comprobación previa antes de configurar TCPS?

R: Sí, solo puede ejecutar las comprobaciones previas para la operación definiendo la opción --precheckOnly en yes. Esto ayuda a validar el entorno antes de realizar cambios.

P: ¿Qué sucede si proporciono una ruta de acceso incorrecta para el archivo de cartera PKCS12?

R: Si --pkcs12WalletFilePath contiene una ruta incorrecta, el comando fallará y la configuración de TCPS no continuará.

P: ¿Qué debo hacer si la clave privada está protegida con contraseña?

R: Si la clave privada está protegida por contraseña, asegúrese de que la opción --privateKeyPasswordProtected esté definida en true (que es el valor por defecto).

P: ¿Puedo especificar mi propio certificado firmado por CA para la configuración de TCPS?

R: Sí, puede especificar su propio certificado firmado por una CA mediante las opciones --serverCert y --privateKey, y definiendo --certType en CA_SIGNED_CERT.

P: ¿Qué es un comando de ejemplo para configurar TCPS mediante un certificado autofirmado?

A: A continuación se muestra un ejemplo:

dbaascli grid configureTCPS --serverCert /path/to/self_signed_cert.pem --privateKey /path/to/private_key.pem --certType SELF_SIGNED_CERT

P: ¿Puedo utilizar un certificado PKCS12 para la configuración de TCPS?

R: Sí, puede utilizar un certificado PKCS12 especificando la opción --pkcs12WalletFilePath y definiendo --certType en PKCS12_CERT.

P: ¿Qué debo verificar antes de ejecutar el comando dbaascli grid configureTCPS?

R: Verifique que tiene los archivos de certificado válidos, los archivos de clave privada y que ha iniciado sesión como usuario root. Además, asegúrese de comprender las implicaciones si utiliza ZDLRA, ya que no se puede ejecutar simultáneamente con TCPS.

Ejemplo: dbaascli grid configureTCPS

Para configurar la cuadrícula mediante el certificado autofirmado:

dbaascli grid configureTCPS

Para configurar la cuadrícula mediante el certificado firmado por una autoridad de certificación (CA):

dbaascli grid configureTCPS --cert_type CA_SIGNED_CERT --server_cert /tmp/certs/server_cert.pem --ca_cert_chain /tmp/certs/ca.pem --private_key /tmp/certs/encrypted_private.key --private_key_password_protected false

cuadrícula dbaascli removeTCPSCert

Para eliminar certificados TCPS existentes de la cartera de Grid Infrastructure, utilice el comando dbaascli grid removeTCPSCert.

Requisitos previos:

Ejecute el comando con el usuario root.

Sintaxis:

dbaascli grid removeTCPSCert --subject <value>
 {
   --userCert | --trustedCert | --requestedCert
 }
 [--serialNumber <value>] [--executePrereqs] [--resume [--sessionID <value>]] [--bounceListeners]

Parámetros:

Parámetro	Descripción
`--subject`	especifica el asunto del certificado
`--userCert`	indicador para indicar el certificado de usuario
`--trustedCert`	indicador para indicar certificado de confianza
`--requestedCert`	indicador para indicar el certificado solicitado
`--serialNumber`	Especifica el número de serie del certificado.
`--executePrereqs`	ejecuta las comprobaciones de requisitos y informa de los resultados
`--resume`	reanuda la ejecución anterior
`--sessionID`	Especifica que se reanude un identificador de sesión específico
`--bounceListeners`	indicador para reiniciar el listener de Grid Infrastructure y la exploración del listener

Preguntas frecuentes:

P: ¿Cuál es la finalidad del comando dbaascli grid removeTCPSCert?

R: El comando dbaascli grid removeTCPSCert se utiliza para eliminar certificados de TCPS existentes de la cartera de Grid Infrastructure en un entorno de Oracle Base Database Cloud@Customer.

P: ¿Cuál es el requisito para ejecutar el comando dbaascli grid removeTCPSCert?

R: El comando se debe ejecutar como el usuario root.

P: ¿Qué especifica la opción –subject en el comando dbaascli grid removeTCPSCert?

R: La opción --subject especifica el asunto del certificado que se va a eliminar de la cartera de Grid Infrastructure.

P: ¿Cuál es el propósito del indicador –userCert?

R: El indicador --userCert indica que el certificado que se va a eliminar es un certificado de usuario.

P: ¿Cuándo debo utilizar el indicador –trustedCert?

R: Utilice el indicador --trustedCert al eliminar un certificado protegido de la cartera de Grid Infrastructure.

P: ¿Qué hace el indicador –requestedCert?

R: El indicador --requestedCert indica que el certificado que se va a eliminar es un certificado solicitado.

P: ¿Qué especifica la opción –serialNumber?

R: La opción --serialNumber especifica el número de serie del certificado que se va a eliminar. Es útil para identificar de forma única un certificado cuando hay varios certificados con el mismo asunto.

P: ¿Cuál es el propósito de la opción –executePrereqs?

R: La opción --executePrereqs ejecuta comprobaciones de requisitos antes de eliminar el certificado e informa de los resultados, lo que garantiza que el entorno está preparado correctamente para la operación.

P: ¿Qué hace la opción –resume?

R: La opción --resume reanuda la operación de eliminación si se interrumpió anteriormente.

P: ¿Cómo puedo especificar un ID de sesión al reanudar una operación interrumpida?

R: Utilice la opción --sessionID para especificar el ID de sesión de la operación interrumpida que desea reanudar.

P: ¿Qué hace el indicador –bounceListeners?

R: El indicador --bounceListeners se utiliza para reiniciar el listener de Grid Infrastructure y el listener de exploración después de eliminar el certificado de TCPS.

P: ¿Puedo eliminar un certificado TCPS sin devolver los listeners?

R: Sí, el indicador --bounceListeners es opcional. Si no lo especifica, los listeners no se devuelven automáticamente.

P: ¿Cómo puedo asegurarme de que la operación se ejecute de manera segura?

R: Puede utilizar la opción --executePrereqs para realizar comprobaciones de requisitos antes de ejecutar el comando, asegurándose de que todo está en orden antes del proceso de eliminación.

P: ¿Qué debo hacer si necesito eliminar un certificado de usuario específico por número de serie?

R: Utilice la opción --subject para especificar el asunto del certificado, el indicador --userCert para indicar que se trata de un certificado de usuario y la opción --serialNumber para especificar el número de serie del certificado.

P: ¿Puedo eliminar varios certificados a la vez?

R: No, el comando está diseñado para eliminar un único certificado a la vez en función del asunto proporcionado y otros parámetros.

P: ¿Qué sucede si se interrumpe el proceso de eliminación del certificado?

R: Puede reanudar la operación mediante la opción --resume junto con el --sessionID del proceso interrumpido.

P: ¿Tengo que ejecutar el comando como usuario root?

R: Sí, el comando dbaascli grid removeTCPSCert se debe ejecutar como usuario root para tener los privilegios necesarios para eliminar certificados TCPS.

P: ¿Cómo puedo identificar el certificado que quiero eliminar?

R: Puede identificar el certificado por su asunto y, opcionalmente, por su número de serie para asegurarse de que se dirige al certificado correcto para su eliminación.

P: ¿Qué es un comando de ejemplo para eliminar un certificado de confianza?

A: Este es un ejemplo:

dbaascli grid removeTCPSCert --subject "CN=example_cert" --trustedCert

dbaascli grid rotateTCPSCert

Para rotar certificados TCPS, utilice el comando dbaascli grid rotateTCPSCert.

Requisitos previos:

Ejecute el comando con el usuario root.

Sintaxis:

dbaascli grid rotateTCPSCert
[--pkcs12WalletFilePath]
[--caCertChain]
[--precheckOnly]
[--serverCert]
[--privateKey]
[--certType]
[--privateKeyPasswordProtected]

Parámetros:

Parámetro	Descripción
`--pkcs12WalletFilePath`	especifica la ruta de acceso absoluta del archivo del certificado, que tiene el formato `pkcs12` de cartera
`--caCertChain`	lista concatenada de certificados, que contienen certificados de CA intermedios y certificados de CA raíz
`--precheckOnly`	Especifica `yes` para ejecutar solo las comprobaciones previas de esta operación. Valores válidos: `yes` o `no`.
`--serverCert`	Especifica la ruta del certificado PEM que se utilizará o rotará para la configuración de TCPS.
`--privateKey`	Especifica la ruta del archivo de clave privada del certificado.
`--certType`	tipo del certificado que se agregará a la cartera de Grid Infrastructure. Los valores aceptados son: `SELF_SIGNED_CERT`, `CA_SIGNED_CERT` o `PKCS12_CERT`. Valor por defecto: `SELF_SIGNED_CERT`
`--privateKeyPasswordProtected`	Especifica si la clave privada está protegida por contraseña o no. Valores válidos: `true` o `false`. Valor por defecto: `true`.

Preguntas frecuentes:

P: ¿Cuál es la finalidad del comando dbaascli grid rotateTCPSCert?

R: El comando dbaascli grid rotateTCPSCert se utiliza para rotar certificados de TCPS (protocolo de seguridad de capa de transporte) en la cartera de Grid Infrastructure en entornos de Oracle Base Database Cloud@Customer.

P: ¿Cuál es el requisito para ejecutar el comando dbaascli grid rotateTCPSCert?

R: El comando se debe ejecutar como el usuario root.

P: ¿Qué especifica la opción –pkcs12WalletFilePath?

R: La opción --pkcs12WalletFilePath especifica la ruta de acceso absoluta al archivo de certificado en el formato de cartera PKCS12 para la configuración de TCPS.

P: ¿Cuál es el propósito de la opción –caCertChain?

R: La opción --caCertChain especifica una lista concatenada de certificados, incluidos los certificados de CA intermedios y de CA raíz, para la configuración de TCPS.

P: ¿Qué hace la opción –precheckOnly?

R: La opción --precheckOnly permite ejecutar comprobaciones previas sin realizar cambios reales. Los valores válidos son "yes" para ejecutar solo las comprobaciones previas y "no" para continuar con la rotación.

P: ¿Cómo se utiliza la opción –serverCert?

R: La opción --serverCert especifica la ruta al certificado del servidor PEM (Privacy Enhanced Mail) que se utiliza o rota para la configuración de TCPS.

P: ¿Qué especifica la opción –privateKey?

R: La opción --privateKey especifica la ruta al archivo de clave privada correspondiente al certificado de servidor utilizado para la rotación de TCPS.

P: ¿Cuáles son los valores válidos para la opción –certType?

A: La opción --certType acepta los siguientes valores para especificar el tipo de certificado que se va a agregar a la cartera de Grid Infrastructure:

SELF_SIGNED_CERT (por defecto)
CA_SIGNED_CERT
PKCS12_CERT

P: ¿Qué hace la opción –privateKeyPasswordProtected?

R: La opción --privateKeyPasswordProtected indica si la clave privada está protegida con contraseña. Los valores válidos son true (por defecto) y false

P: ¿Puedo ejecutar el comando dbaascli grid rotateTCPSCert sin rotar los certificados?

R: Sí, mediante la opción --precheckOnly yes, puede ejecutar solo las comprobaciones previas sin rotar los certificados.

P: ¿Cuál es un ejemplo de un comando para rotar un certificado mediante una cartera PKCS12?

A: A continuación, se muestra un comando de ejemplo:

dbaascli grid rotateTCPSCert --pkcs12WalletFilePath /path/to/wallet.p12 --certType PKCS12_CERT

P: ¿Cómo puedo rotar un certificado de servidor con una cadena de certificados firmada por una CA?

R: Utilice las opciones --serverCert y --caCertChain como se muestra aquí:

dbaascli grid rotateTCPSCert --serverCert /path/to/serverCert.pem --caCertChain /path/to/caChain.pem

P: ¿Qué sucede si no especifico –privateKeyPasswordProtected?

R: Si no especifica la opción --privateKeyPasswordProtected, el comando asume que la clave privada está protegida por contraseña (valor por defecto: true).

P: ¿Puedo rotar un certificado autofirmado?

R: Sí, puede rotar un certificado autofirmado mediante la opción --certType SELF_SIGNED_CERT por defecto o especificándolo explícitamente.

P: ¿Cómo puedo rotar un certificado sin proporcionar una clave privada?

R: Para determinados tipos de certificados, como PKCS12, puede que no necesite proporcionar un archivo de clave privada independiente, ya que está incluido en la cartera. Sin embargo, si se necesita una clave privada, se debe proporcionar mediante la opción --privateKey.

P: ¿Qué pasa si quiero rotar un certificado en segundo plano?

R: El comando dbaascli grid rotateTCPSCert no proporciona una opción explícita para la ejecución en segundo plano. Puede ejecutar el comando directamente en una sesión en segundo plano (por ejemplo, mediante nohup o herramientas similares).

P: ¿Cuál es el tipo de certificado por defecto si no se especifica?

R: El tipo de certificado por defecto es SELF_SIGNED_CERT.

Ejemplo: dbaascli grid rotateTCPSCert

Para rotar un certificado mediante un certificado autofirmado (opción por defecto):

dbaascli grid rotateTCPSCert

Para rotar un certificado mediante un certificado firmado por una autoridad de certificación (CA):

dbaascli grid rotateTCPSCert --cert_type CA_SIGNED_CERT --server_cert /tmp/certs/server_cert.pem --ca_cert_chain /tmp/certs/ca.pem --private_key /tmp/certs/encrypted_private.key --privateKeyPasswordProtected true

dbaascli grid upgrade

Para actualizar Oracle Grid Infrastructure de una versión principal a otra, utilice el comando dbaascli grid upgrade.

Requisitos previos:

Ejecute el comando con el usuario root.

Sintaxis:

dbaascli grid upgrade --version
[--resume]
[--executePrereqs]
[--containerURL]
[--softwareOnly]
[--targetHome]
[--revert]

Parámetros:

Parámetro	Descripción
`--version`	especifica la versión de destino
`--resume`	reanuda la ejecución anterior
`--executePrereqs`	ejecuta los requisitos para la actualización de Grid Infrastructure
`--containerUrl`	especifica la URL personalizada para recuperar la imagen de Grid Infrastructure
`--softwareOnly`	instala solo el software Grid Infrastructure
`--targetHome`	especifica la ruta del directorio raíz de grid de destino existente
`--revert`	revierte la ejecución fallida

Preguntas frecuentes:

P: ¿Cuál es la finalidad del comando dbaascli grid upgrade?

R: El comando dbaascli grid upgrade se utiliza para actualizar Oracle Grid Infrastructure de una versión principal a otra en una máquina virtual de Oracle Base Database Cloud@Customer.

P: ¿Cuál es el requisito para ejecutar el comando dbaascli grid upgrade?

R: El comando se debe ejecutar como usuario root y debe estar conectado a una máquina virtual de Oracle Base Database Cloud@Customer.

P: ¿Qué especifica la opción –version?

R: La opción --version especifica la versión de destino de Oracle Grid Infrastructure a la que desea cambiar la versión.

P: ¿Qué hace la opción –resume?

R: La opción --resume reanuda un proceso de cambio de versión de Grid Infrastructure interrumpido o fallido anteriormente.

P: ¿Cómo se utiliza la opción –executePrereqs?

R: La opción --executePrereqs solo ejecuta las comprobaciones de requisitos para el cambio de versión de Grid Infrastructure sin realizar el cambio de versión real.

P: ¿Cuál es el propósito de la opción –containerURL?

R: La opción --containerURL especifica una URL personalizada para recuperar la imagen de software de Grid Infrastructure para la actualización.

P: ¿Qué hace la opción –softwareOnly?

R: La opción --softwareOnly sólo instala el software de Grid Infrastructure sin configurar ni actualizar el entorno de Grid.

P: ¿Cuándo utilizaría la opción –targetHome?

R: La opción --targetHome especifica la ruta de acceso al directorio raíz de Grid de destino existente en el que se realizará la actualización.

P: ¿Qué sucede si falla la actualización?

R: Si el cambio de versión falla, puede utilizar la opción --revert para revertir el cambio de versión a su estado anterior.

P: ¿Puedo realizar un cambio de versión de Grid Infrastructure por etapas?

R: Sí, mediante la opción --softwareOnly, primero puede instalar el software y, luego, completar la actualización completa, lo que permite actualizaciones temporales.

P: ¿Cómo puedo utilizar el comando dbaascli grid upgrade para actualizar solo el software?

R: Utilice la siguiente sintaxis para actualizar sólo el software:

dbaascli grid upgrade --version <target_version> --softwareOnly

P: ¿Puedo comprobar los requisitos de actualización sin realizar la actualización?

R: Sí, solo puede ejecutar comprobaciones de requisitos mediante:

dbaascli grid upgrade --version <target_version> --executePrereqs

P: ¿Cómo puedo actualizar Grid Infrastructure mediante una URL de contenedor personalizada?

R: Puede especificar la URL para recuperar la imagen de Grid Infrastructure de la siguiente forma:

dbaascli grid upgrade --version <target_version> --containerURL <custom_url>

P: ¿Cómo puedo reanudar un proceso de actualización interrumpido anteriormente?

R: Para reanudar una actualización previamente interrumpida o fallida, utilice:

dbaascli grid upgrade --version <target_version> --resume

P: ¿Qué hace la opción –revert en el comando dbaascli grid upgrade?

R: La opción --revert realiza un rollback de un cambio de versión de Grid Infrastructure fallido o interrumpido a su estado original.

P: ¿Puedo realizar un cambio de versión completo sin configurar la infraestructura de grid inmediatamente?

R: Sí, primero puede instalar solo el software mediante la opción --softwareOnly y, a continuación, configurarlo más tarde.

P: ¿Qué debo hacer si falla una actualización y quiero deshacer los cambios?

R: Utilice la opción --revert para realizar un rollback del cambio de versión fallido:

dbaascli grid upgrade --version <target_version> --revert

Ejemplo: dbaascli grid upgrade

dbaascli grid upgrade --version 19.11.0.0.0 --executePrereqs
DBAAS CLI version MAIN
Executing command grid upgrade --version 19.11.0.0.0 --executePrereqs

dbaascli grid patch

Para aplicar un parche en Oracle Grid Infrastructure hacia la versión secundaria especificada, utilice el comando dbaascli grid patch.

Requisitos previos:

Ejecute el comando con el usuario root.

Sintaxis:

dbaascli grid patch
 {
            --targetVersion <value>
            | --targetHome <value>
        }
        [--executePrereqs] [--nodeList <value>] [--continueWithDbDowntime] [--drainTimeoutInSeconds <value>] [--containerURL <value>] [--imageFile <value>] [--patchInParallel]
        {
            [--resume [--sessionID <value>]]
            | [--rollback [--sessionID <value>]]
        }
        [--waitForCompletion <value>]

Parámetros:

Parámetro	Descripción
`--targetVersion`	Especifica la versión de destino del directorio Raíz de Oracle especificada como cinco segmentos numéricos separados por puntos (por ejemplo, 19.12.0.0.0)
`--targetHome`	especifica la ruta completa del directorio raíz que se utilizará para la aplicación de parche externa de Grid Infrastructure
`--containerURL`	especifica la URL personalizada para recuperar la imagen de Grid Infrastructure
`--executePrereqs`	opción para ejecutar los requisitos
`--nodeList`	especifica una lista delimitada por comas de nodos si se debe realizar la aplicación de parche en un subjuego de nodos
`--patchInParallel`	Especifica la aplicación de parches a nodos remotos en paralelo
`--rollback`	Especifica que se realice un rollback de un directorio raíz de Oracle con parches
`--resume`	reanuda la ejecución anterior
`--sessionID`	Especifica que se reanude un identificador de sesión específico
`--continueWithDbDowntime`	continúa con la aplicación del parche con Tiempo de Inactividad de la Base de Datos. Esta opción se puede utilizar en entornos en los que solo hay 1 instancia activa y la operación de aplicación de parche se puede continuar incluso con un tiempo de inactividad.
`--drainTimeoutInSeconds`	Especifica el tiempo (en segundos) para completar el vaciado de recursos mientras se detiene la base de datos
`--createImage`	crea una imagen a partir de una copia del directorio raíz activo de Grid, con parche a la versión del destino especificada
`--createImageDir`	Especifica la ruta de acceso completa del directorio en el que se creará la imagen
`--imageFile`	Especifica la ruta de acceso completa de la imagen que se utilizará
`--patchInParallel`	aplica parche a los nodos remotos en paralelo
`--waitForCompletion`	`false` especifica para que se ejecute la operación en segundo plano. Valores válidos: `true` o `false`

Preguntas frecuentes:

P: ¿Qué hace el comando dbaascli grid patch?

R: El comando dbaascli grid patch se utiliza para aplicar parches a Oracle Grid Infrastructure en una versión secundaria especificada.

P: ¿Necesito permisos especiales para ejecutar el comando dbaascli grid patch?

R: Sí, debe ejecutar el comando dbaascli grid patch como usuario root.

P: ¿Puedo especificar una versión de destino al aplicar parches a Oracle Grid Infrastructure?

R: Sí, puede especificar la versión de destino mediante la opción --targetVersion.

P: ¿Cómo puedo especificar la versión de destino para el parche?

R: Utilice la opción --targetVersion seguida del número de versión con el formato 19.12.0.0.0.

P: ¿Qué hace la opción –containerURL en el comando dbaascli grid patch?

R: La opción --containerURL permite especificar una URL personalizada para recuperar la imagen de Grid Infrastructure.

P: ¿Cuál es el propósito de la opción –executePrereqs?

R: La opción --executePrereqs se utiliza para ejecutar comprobaciones de requisitos antes de aplicar el parche.

P: ¿Cómo puedo aplicar parches a un subjuego de nodos mediante el comando dbaascli grid patch?

R: Utilice la opción --nodeList seguida de una lista delimitada por comas de nombres de nodo para aplicar parches solo a un subjuego de nodos.

P: ¿Qué sucede si utilizo la opción –rollback?

R: La opción --rollback realizará un rollback del directorio raíz de Oracle con parches a su estado anterior.

P: ¿Puedo reanudar una sesión de aplicación de parches anterior?

R: Sí, puede utilizar la opción --resume para reanudar la última sesión de aplicación de parches. Si tiene un identificador de sesión específico, puede especificarlo con la opción --sessionID.

P: ¿Para qué se utiliza la opción –continueWithDbDowntime?

R: La opción --continueWithDbDowntime permite seguir aplicando parches incluso si hay tiempo de inactividad de la base de datos, que se suele utilizar en entornos en los que solo hay una instancia activa.

P: ¿Cómo puedo crear una imagen a partir de un directorio raíz de Grid con parches?

R: Utilice la opción --createImage para crear una imagen. Puede especificar el directorio donde se debe crear la imagen mediante la opción --createImageDir.

P: ¿Cuál es el propósito de la opción –imageFile?

R: La opción --imageFile permite especificar la ruta de acceso completa del archivo de imagen que se va a utilizar para la aplicación de parches.

P: ¿Cómo puedo ejecutar el comando dbaascli grid patch en segundo plano?

R: Puede utilizar la opción --waitForCompletion definida en false para ejecutar la operación en segundo plano.

P: ¿Puedo utilizar una URL personalizada para recuperar la imagen del parche?

R: Sí, puede utilizar la opción --containerURL para especificar una URL personalizada para recuperar la imagen de Grid Infrastructure.

P: ¿Cómo puedo especificar a qué nodos aplicar parches si no quiero aplicar parches a todos ellos?

R: Puede especificar los nodos a los que desea aplicar parches mediante la opción --nodeList con una lista separada por comas de nombres de nodo.

P: ¿Qué debo hacer si necesito realizar un rollback de un parche?

R: Utilice la opción --rollback del comando dbaascli grid patch para realizar un rollback del parche.

P: ¿Cómo puedo manejar una operación de aplicación de parches si mi entorno solo tiene una instancia activa y necesito continuar con el tiempo de inactividad?

R: Utilice la opción --continueWithDbDowntime para seguir aplicando parches incluso con tiempo de inactividad de la base de datos.

P: ¿Puedo crear una imagen del directorio raíz de Grid con parches?

R: Sí, puede utilizar la opción --createImage para crear una imagen del directorio raíz de Grid con parches. Si es necesario, especifique el directorio donde se debe guardar la imagen mediante --createImageDir.

P: ¿Qué debo hacer si quiero reanudar una sesión de aplicación de parches después de una interrupción?

R: Utilice la opción --resume para reanudar la sesión de aplicación de parches. Si conoce el ID de sesión, puede especificarlo con --sessionID.

P: ¿Qué pasa si el proceso de aplicación de parches falla a mitad de camino?

R: Si el proceso de aplicación de parches falla, puede utilizar la opción --resume para reiniciar el proceso. También puede utilizar la opción --rollback para volver al estado anterior.

P: ¿Cómo puedo asegurarme de que se cumplen todos los requisitos previos antes de aplicar parches?

R: Utilice la opción --executePrereqs para ejecutar todas las comprobaciones de requisitos antes de aplicar el parche.

P: ¿Puedo realizar parches en segundo plano para evitar sostener el terminal?

R: Sí, puede utilizar la opción --waitForCompletion false para ejecutar el proceso de aplicación de parches en segundo plano.

P: ¿Cómo puedo crear una imagen de directorio raíz de Grid después de aplicar parches?

R: Utilice la opción --createImage para crear una nueva imagen desde el directorio raíz de Grid con parches. Especifique el directorio mediante --createImageDir si es necesario.

P: ¿Cómo puedo utilizar un archivo de imagen existente para la aplicación de parches?

R: Puede utilizar la opción --imageFile para especificar la ruta de acceso completa al archivo de imagen que desea utilizar para la aplicación de parches.

P: ¿Qué debo hacer si deseo evitar el tiempo de inactividad de la base de datos durante la aplicación de parches?

R: Asegúrese de que su entorno tiene más de una instancia activa en ejecución. Puede evitar el uso de la opción --continueWithDbDowntime, que está pensada para entornos con una sola instancia activa.

P: ¿Cómo puedo saber el progreso de un parche que se ejecuta en segundo plano?

R: Si ejecuta el parche con --waitForCompletion false, puede comprobar el estado del trabajo en segundo plano mediante comandos del sistema operativo como ps o comprobar los logs ubicados en el directorio raíz de Grid.

P: ¿Es posible aplicar parches a una versión principal superior mediante dbaascli grid patch?

R: No, dbaascli grid patch solo permite aplicar parches a una versión secundaria de la versión principal actual. Para las actualizaciones principales, deberá seguir un proceso de actualización diferente.

P: ¿Puedo omitir comprobaciones de requisitos específicas durante la aplicación de parches?

R: No, cuando utilice --executePrereqs, se ejecutarán todas las comprobaciones de requisitos. Sin embargo, puede revisar los resultados de las comprobaciones de requisitos y gestionar manualmente cualquier problema antes de continuar.

P: ¿Qué debo hacer si el proceso de aplicación de parches está atascado o colgado?

R: Si el proceso de aplicación de parches no responde, puede pararlo mediante comandos del sistema operativo y, a continuación, reanudarlo mediante la opción --resume. Si eso no funciona, intente utilizar la opción --rollback para revertir el parche.

P: ¿Puedo automatizar el proceso de aplicación de parches en varios clusters?

R: Sí, mediante secuencias de comandos que incluyen el comando dbaascli grid patch con las opciones adecuadas, puede automatizar la aplicación de parches en diferentes clusters.

P: ¿Dónde puedo encontrar logs para el proceso de aplicación de parches?

R: Normalmente, los logs se encuentran en el directorio raíz de logs de Oracle Grid o en la ubicación por defecto especificada durante la configuración. Puede supervisar estos logs para obtener más información sobre el proceso de aplicación de parches.

P: ¿Es posible crear un proceso de parche silencioso sin interacción del usuario?

R: Sí, al especificar todas las opciones necesarias en el comando y ejecutarlo en segundo plano (--waitForCompletion false), puede crear un proceso de aplicación de parches no interactivo.

P: ¿Puedo comprobar si hay actualizaciones de parches disponibles antes de aplicar un parche?

R: El propio comando dbaascli grid patch no tiene una opción para mostrar los parches disponibles. Sin embargo, puede utilizar los métodos estándar de Oracle, como los Servicios de Soporte Oracle, para identificar los parches más recientes.

P: ¿Puedo utilizar dbaascli para aplicar parches a varios directorios raíz de Oracle?

R: No, el comando dbaascli grid patch está diseñado para aplicar parches a un directorio raíz de Oracle Grid Infrastructure específico a la vez. Debería ejecutar el comando por separado para cada directorio raíz.

P: ¿Existe alguna forma de evitar el tiempo de inactividad por completo al aplicar parches a Grid Infrastructure?

R: Para minimizar el tiempo de inactividad, asegúrese de que su entorno tenga varias instancias de base de datos activas (configuración RAC) para que la aplicación de parches se pueda realizar nodo por nodo. La opción --continueWithDbDowntime no se debe utilizar en este caso.

P: ¿Cómo puedo manejar la aplicación de parches para entornos RAC One Node?

R: En los entornos RAC One Node, debe tener cuidado con la opción --continueWithDbDowntime, ya que solo puede haber una instancia activa. Revise la documentación de Oracle para obtener directrices de aplicación de parches específicas para RAC One Node.

P: ¿Puedo ver el historial de sesiones de parches anteriores?

R: La utilidad dbaascli no proporciona una forma directa de ver el historial de sesiones. Sin embargo, los logs de las sesiones de aplicación de parches anteriores se pueden encontrar en el directorio de logs del directorio raíz de Grid.

Ejemplos:

Ejemplo: aplicación básica de parches de cuadrícula

dbaascli grid patch --targetVersion 19.12.0.0.0

Aplica parches a Oracle Grid Infrastructure en la versión 19.12.0.0.0.

Ejemplo: aplicación de parches con una URL de contenedor personalizada

dbaascli grid patch --targetVersion 19.12.0.0.0 --containerURL https://example.com/custom/url

Aplica parches a Grid Infrastructure a la versión 19.12.0.0.0, mediante una URL de contenedor personalizada para recuperar la imagen de Grid Infrastructure.

Ejemplo: Aplicación de Parches con Comprobaciones de Requisitos

dbaascli grid patch --targetVersion 19.12.0.0.0 --executePrereqs

Aplica parches a Grid Infrastructure a la versión 19.12.0.0.0 después de ejecutar las comprobaciones de requisitos.

Ejemplo: aplicación de parches en un subjuego de nodos

dbaascli grid patch --targetVersion 19.12.0.0.0 --nodeList node1,node2,node3

Aplica parches a Grid Infrastructure a la versión 19.12.0.0.0 en los nodos especificados (node1, node2 y node3).

Ejemplo: Rollback del Parche

dbaascli grid patch --rollback

Realiza un rollback del último parche aplicado en Oracle Grid Infrastructure.

Ejemplo: Reanudación de una Operación de Parche Anterior

dbaascli grid patch --resume

Reanuda la operación de aplicación de parches anterior desde donde se detuvo.

Ejemplo: reanudación de una operación de parche con un ID de sesión específico

dbaascli grid patch --resume --sessionID 12345

Reanuda la operación de aplicación de parches con el ID de sesión 12345.

Ejemplo: aplicación de parches con tiempo de inactividad de base de datos permitido

dbaascli grid patch --targetVersion 19.12.0.0.0 --continueWithDbDowntime

Aplica parches a Grid Infrastructure a la versión 19.12.0.0.0, al tiempo que permite el tiempo de inactividad de la base de datos si es necesario.

Ejemplo: creación de una imagen con parches

dbaascli grid patch --targetVersion 19.12.0.0.0 --createImage --createImageDir /path/to/dir

Crea una imagen del directorio raíz de Grid con parches (versión 19.12.0.0.0) y la almacena en el directorio especificado.

Ejemplo: uso de un archivo de imagen existente

dbaascli grid patch --targetVersion 19.12.0.0.0 --imageFile /path/to/image/file.zip

Aplica parches a Grid Infrastructure a la versión 19.12.0.0.0 mediante un archivo de imagen existente ubicado en /path/to/image/file.zip.

Ejemplo: ejecución de la operación de aplicación de parches en segundo plano

dbaascli grid patch --targetVersion 19.12.0.0.0 --waitForCompletion false

Aplica parches a Grid Infrastructure a la versión 19.12.0.0.0 y ejecuta la operación en segundo plano.

Ejemplo: combinación de requisitos previos, URL personalizada y subjuego de nodos

dbaascli grid patch --targetVersion 19.12.0.0.0 --executePrereqs --containerURL https://example.com/custom/url --nodeList node1,node2

Aplica parches a Grid Infrastructure a la versión 19.12.0.0.0, ejecuta comprobaciones de requisitos, utiliza una URL personalizada para la imagen y aplica el parche solo en node1 y node2.

Ejemplo: creación de una imagen con parches con un archivo de imagen existente

dbaascli grid patch --targetVersion 19.12.0.0.0 --createImage --createImageDir /path/to/dir --imageFile /path/to/existing/image.zip

Crea una imagen con parches y la almacena en el directorio especificado mientras utiliza un archivo de imagen existente para el parche.

Ejemplo: Verificación de Requisitos sin Aplicación de Parches

dbaascli grid patch --targetVersion 19.12.0.0.0 --executePrereqs

Verifica si se cumplen todos los requisitos para aplicar parches a la versión 19.12.0.0.0 sin aplicar realmente el parche.

Ejemplo: Ejecución de Parches e Ignoración de Fallos de Requisitos

dbaascli grid patch --targetVersion 19.12.0.0.0 --continueWithDbDowntime --executePrereqs

Ejecuta el parche incluso si fallan algunas comprobaciones de requisitos. Esto resulta útil en casos en los que se permite el tiempo de inactividad y se pueden ignorar ciertos requisitos.

Ejemplo: Comprobación de logs de parches para incidencias

tail -f /u01/app/grid/logs/grid_patch.log

Supervisa el log de parches en tiempo real para diagnosticar cualquier problema durante el proceso de aplicación de parches.

Ejemplo: Aplicación del parche en un entorno paralelo

dbaascli grid patch --targetVersion 19.12.0.0.0 --nodeList node1,node2 --waitForCompletion false

Aplica parches a Grid Infrastructure en un subjuego de nodos (node1 y node2) y ejecuta el proceso en segundo plano.

Ejemplo: uso de un archivo de imagen específico de un origen externo

dbaascli grid patch --targetVersion 19.12.0.0.0 --imageFile /mnt/images/grid_patch_19.12.zip

Aplica parches a Grid Infrastructure mediante un archivo de imagen descargado previamente ubicado en un dispositivo de almacenamiento externo.

Ejemplo: Ejecución de Parche con un ID de Sesión Personalizado

dbaascli grid patch --targetVersion 19.12.0.0.0 --resume --sessionID 67890

Reanuda una operación de aplicación de parches que se interrumpió con el ID de sesión 67890.

Ejemplo: programación de la aplicación de parches para que se ejecute posteriormente

echo "dbaascli grid patch --targetVersion 19.12.0.0.0" | at 02:00

Programa el comando de aplicación de parches para que se ejecute a las 2:00 a. m. mediante el comando at en Linux.

Ejemplo: especificación de timeout para finalización

dbaascli grid patch --targetVersion 19.12.0.0.0 --waitForCompletion true --continueWithDbDowntime --timeout 7200

Aplica parches a Grid Infrastructure al tiempo que permite el tiempo de inactividad, pero espera hasta 7200 segundos (2 horas) para que se complete antes del timeout.

Ejemplo: creación de una imagen personalizada para otro entorno

dbaascli grid patch --targetVersion 19.12.0.0.0 --createImage --createImageDir /backups/images/grid_patch

Crea una imagen personalizada de la infraestructura de grid con parches que se va a almacenar en el directorio /backups/images/grid_patch para utilizarla en otros entornos.

Ejemplo: recuperación de parches después de la interrupción

dbaascli grid patch --resume --continueWithDbDowntime

Recupera y reanuda el proceso de aplicación de parches si se ha interrumpido, con tiempo de inactividad de la base de datos permitido.

Ejemplo: combinación de comprobación de requisitos previos con ejecución en segundo plano

dbaascli grid patch --targetVersion 19.12.0.0.0 --executePrereqs --waitForCompletion false

Comprueba los requisitos y ejecuta el parche en segundo plano.

Ejemplo: omisión de la creación de imágenes para aplicar parches más rápido

dbaascli grid patch --targetVersion 19.12.0.0.0 --patchInParallel --continueWithDbDowntime --waitForCompletion false

Aplica parches a Grid Infrastructure a la versión 19.12.0.0.0 en paralelo entre nodos, con tiempo de inactividad de la base de datos permitido y sin crear una imagen para acelerar el proceso.

Ejemplo: Supervisión del Progreso de Parches a través de Logs

tail -f /u01/app/grid/logs/grid_patch_progress.log

Supervisa el archivo log para el progreso de la aplicación de parches en tiempo real, proporcionando información sobre cada paso del proceso de aplicación de parches.

Ejemplo: aplicación de parches con timeout de drenaje personalizado

dbaascli grid patch --targetVersion 19.12.0.0.0 --drainTimeoutInSeconds 3600 --continueWithDbDowntime

Aplica parches a Grid Infrastructure y define un timeout personalizado de 1 hora (3600 segundos) para permitir un drenaje de recursos controlado durante el tiempo de inactividad de la base de datos.

Ejemplo: Aplicación de un parche a nodos específicos con comprobaciones de requisitos

dbaascli grid patch --targetVersion 19.12.0.0.0 --nodeList node1,node4 --executePrereqs

Aplica parches solo a los nodos node1 y node4 de la versión 19.12.0.0.0 y ejecuta las comprobaciones de requisitos de antemano.

Ejemplo: aplicación de parches sin esperar a la finalización

dbaascli grid patch --targetVersion 19.12.0.0.0 --waitForCompletion false

Comienza a aplicar parches a Grid Infrastructure a la versión 19.12.0.0.0 en segundo plano, lo que permite que se realicen otras tareas sin esperar a que se complete el proceso.

Ejemplo: Reaplicación de un parche con fallos después de un problema de timeout de drenaje

dbaascli grid patch --resume --drainTimeoutInSeconds 7200

Reanuda la sesión de aplicación de parches anterior y amplía el timeout de drenaje del recurso a 2 horas (7200 segundos) en caso de que falle debido a un tiempo insuficiente en el intento anterior.

Ejemplo: Visualización de logs de parches en tiempo real con un ID de sesión específico

tail -f /u01/app/grid/logs/grid_patch_12345.log

Supervisa el archivo log para la sesión de aplicación de parches con el ID de sesión 12345 en tiempo real.

Ejemplo: Aplicación de parches a un nuevo directorio raíz de destino

dbaascli grid patch --targetHome /u01/app/grid_home_19c --executePrereqs

Realiza un parche externo a un nuevo directorio raíz de Oracle Grid ubicado en /u01/app/grid_home_19c, con comprobaciones de requisitos.

Ejemplo: Parada de un Trabajo de Parche de Fondo

ps -ef | grep dbaascli | grep patch | awk '{print $2}' | xargs kill -9

Para un trabajo de parche en segundo plano mediante la búsqueda y parada del ID de proceso (PID) asociado.

Ejemplo: Verificación de la Finalización de Parches sin Logs

dbaascli grid status --targetVersion 19.12.0.0.0

Verifica si el parche de la versión 19.12.0.0.0 se ha aplicado correctamente comprobando el estado actual de la versión de Grid Infrastructure.