Incidencias conocidas

En este artículo se proporciona información sobre los problemas conocidos en el servicio Base Database.

Estos problemas conocidos se identifican en Base Database Service:

Temas relacionados

Bases de datos conectables existentes en la nueva base de datos

Detalles

Las bases de datos conectables existentes (PDB) no aparecen en una base de datos recién creada y pueden tardar unas horas en aparecer en la consola de OCI. 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

Ninguno.

PDB en la configuración existente de Data Guard

Detalles

La creación y clonación de una PDB en la base de datos primaria no está permitida a través de la consola o la API de OCI.

Solución alternativa

Puede utilizar SQL*Plus para crear o clonar PDB en la base de datos principal y estas se sincronizarán más tarde en la consola del servicio OCI.

Incidencia de facturación al cambiar el tipo del permiso

Detalles

When you change the license type of your database or DB system from BYOL to license included, or the other way around, you are billed for both types of licenses for the first hour. Después, se le facturará según el tipo de licencia actualizado.

Solución alternativa

Estamos intentando solucionar este problema.

Falló la copia de seguridad en Almacenamiento de objetos mediante dbcli debido a un cambio de certificado

Detalles

Las copias de Seguridad no gestionadas en Object Storage realizadas mediante la CLI (dbcli) de la base de datos 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 al certificado de Symantec, Oracle ha cambiado recientemente la autoridad de certificado utilizada para Oracle Cloud Infrastructure. El cambio resultante en el certificado SSL puede hacer que las copias de seguridad en el almacenamiento de objetos fallen si el módulo Oracle Database Cloud Backup sigue apuntando al certificado anterior.

Solución alternativa

Compruebe que los archivos log no contienen los errores enumerados y, si los encuentra, actualice el módulo de copia de seguridad.

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

    1. Ejecute el siguiente comando para determinar el ID del trabajo de copia del respaldo 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.

  2. Actualización del módulo de Oracle Database Cloud Backup:

    1. Determine el ID del 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>

Fallo al realizar una copias de seguridad en Object Storage mediante RMAN debido a un cambio de certificado

Detalles

Las copias de Seguridad no gestionadas en el almacenamiento de objetos realizadas mediante el 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 al certificado de Symantec, Oracle ha cambiado recientemente la autoridad de certificado utilizada para Oracle Cloud Infrastructure. El cambio resultante en el certificado SSL puede hacer que las copias de seguridad en el almacenamiento de objetos fallen si el módulo Oracle Database Cloud Backup sigue apuntando al certificado anterior.

Solución alternativa

Compruebe los archivos log de RMAN para comprobar 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.

Note:

Las contraseñas de Swift ahora se denominan "tokens de autenticación". Para obtener más información, consulte Gestión de credenciales de usuario. 
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.

Para obtener más información sobre el módulo Oracle Database Cloud Backup, consulte Uso de Oracle Database Backup Cloud Service.

Desglosar cambios en SDK de servicio de base de datos

Detalles

Los SDK lanzados el 18 de octubre del 2018 introducen nuevos cambios en el tamaño de la Base de Datos y los atributos a la edición de la base de Datos en las API a las que se aplica la copia de Seguridad de la Base de Datos.

Solución alternativa

Consulte la documentación específica de idioma para obtener más información sobre los cambios de ruptura y actualice su código existente según corresponda.

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

Solución alternativa

Instale el módulo Oracle Database Cloud Backup y, a continuación, póngase en contacto con Oracle Support Services para obtener más instrucciones.

Realice los siguientes pasos para instalar el módulo Oracle Database Cloud Backup:

  1. Establezca una conexión de SSH con el sistema de base de Datos e inicia 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 Oracle Database Cloud Backup desde el módulo de Oracle Database Cloud Backup.
  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édele 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. Para obtener más información sobre la creación de token de autenticación, consulte Gestión de credenciales de usuario.

    Note:

    Las contraseñas de Swift ahora se denominan "tokens de autenticación".

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

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

    Para determinar la región correcta, consulte Preguntas frecuentes sobre Object Storage.

    El comando debe devolver el código HTTP 200 o el código HTTP 204 No Content de respuesta de estado correcta. 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 de copia para ejecutarlos como root).

  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 la siguiente salida:

    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.

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

Detalles

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

Solución alternativa

Cambie los parámetros que contienen memoria de los sistemas de esta 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 iniciales de memoria de esta 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

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

Detalles

En los sistemas de base de datos del alto rendimiento y el rendimiento extremo, las operaciones de la utilidad de pump de datos que utilizan compresión y 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 la base de datos Oracle Database para la versión 12.1.0.2.161018 o 12.1.0.2.170117, respectivamente. Como alternativa, utilice la consola de OCI para aplicar el parche del mes de abril de 2017 al sistema y al directorio raíz de la base de Datos.

Note:

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

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

Detalles

Puede que aparezca el mensaje de error "Secure Connection Failed" al intentar conectarse a la consola de EM Express desde el sistema de base de datos de 1 nodo porque los permisos correctos no se aplicaron 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. Realice los siguientes pasos para agregar permisos de lectura.

  1. SSH en el host de sistema de base de datos, inicie sesión como opc y sudo en el usuario grid. 

    [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 wallet. Es el valor de my_wallet_directory en la siguiente salida de 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 wallet. 

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

  4. Enumere 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 han 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

Información de la consola de OCI no se sincroniza para las bases de Datos activadas para Data Guard cuando Se utiliza dbaascli

Detalles

La consola de OCI sincroniza y muestra información sobre bases de datos que se crean y gestionan mediante las utilidades dbaasapi y dbaascli. Sin embargo, las bases de datos con Data Guard configurado no muestran la información correcta en la consola de OCI en las siguientes condiciones:

  • Si Data Guard se ha activado mediante la consola de OCI y, a continuación, se realiza un cambio de 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 de OCI.
  • Si Data Guard se ha configurado manualmente, la consola de OCI no muestra una asociación de Data Guard entre las dos bases.

Solución alternativa

Somos conscientes del problema y estamos trabajando para solucionarlo. Entre tanto, Oracle recomienda que gestione las bases de Datos Activadas para Data Guard solamente mediante la consola de OCI o las herramientas de las líneas de comandos.

La infraestructura de cuadrícula no comienza después de desconectar y conectarse a un disco

Detalles

Se trata de un problema de clusterware que se produce solo cuando la versión de Oracle Grid Infrastructure (GI) es 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.

Realice los siguientes pasos:

  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 ha podido iniciar debido a que el disco de quorum es 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.

      Query 1 Results
NAME                           VOTING_FILE
------------------------------ ---------------
DBFSC3_CD_02_SLCLCX0788        Y
DBFSC3_CD_09_SLCLCX0787        Y
DBFSC3_CD_04_SLCLCX0786        Y

Query 2 Results
NAME                           COUNT(*)
------------------------------ ---------------
DBFSC3_CD_02_SLCLCX0788        8
DBFSC3_CD_09_SLCLCX0787        8
DBFSC3_CD_04_SLCLCX0786        8

      En un sistema que está en buen estados, todos las unidades de quorum devueltas en la primera consulta también se deben devolver en la segunda, y los recuentos de todos las unidades deben ser diferentes 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 y 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 4a a 4c para cada disco de cuadrícula restante que contenga un disco de quorum corrupto.

    Note:

    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.

Fallo de escala de almacenamiento del sistema de base de datos

Detalles

Si se intenta escalar desde un valor inferior a 10 240 GB hasta un valor superior a 10 240 GB en una sola operación, puede producirse un fallo en la operación de escalado.

Solución alternativa

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 hasta 10 240 GB. Después de completar esta primera operación de escalado y de que el sistema tenga el estado "disponible", realice una segunda operación de escalado y especifique el valor de almacenamiento de destino por encima de 10 240 GB.

Fallo de escala de unidad de sistema de base de datos

Detalles

Al escalar un sistema del sistema para utilizar una unidad del 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 del sistema del DB, asegúrese que todos los parámetros DB_Cache_nX (por ejemplo, DB_nK_CACHE_SIZE) estén definidos en 0 (cero).