Problemas Conhecidos

Este artigo fornece informações sobre problemas conhecidos no serviço Base Database.

Esses problemas conhecidos são identificados no Base Database Service:

Bancos de dados plugáveis existentes no novo banco de dados
Problema de faturamento ao alterar o tipo de licença
Falha ao fazer backup no Object Storage usando dbcli em decorrência de alteração no certificado
Falha ao fazer backup no Object Storage usando o RMAN em decorrência de alteração no certificado
Alterações interruptivas nos SDKs de serviço do Banco de Dados
Não é possível usar Backups Gerenciados no seu sistema de BD
Os Backups Automáticos Gerenciados falham na forma VM.Standard 1.1 devido a uma falha no processo
As operações do Oracle Data Pump retornam "ORA-00439: recurso não ativado"
Não foi possível estabelecer conexão com a console do EM Express no sistema de BD com 1 nó
Informações da Console do OCI não sincronizadas para banco de dados ativados para Data Guard ao usar o dbaascli
O Grid Infrastructure não inicia após a colocação de um disco off-line e on-line
Falha no dimensionamento do armazenamento do sistema de banco de dados
Falha no dimensionamento da forma do sistema de banco de dados

Bancos de dados plugáveis existentes no novo banco de dados

Detalhes:

Os bancos de dados plugáveis (PDB) existentes não aparecem em um banco de dados recém-criado, e pode levar algumas horas para que eles apareçam na Console do OCI. Isso inclui o PDB padrão para um novo banco de dados e PDBs existentes para bancos de dados clonados ou restaurados. No caso de uma restauração no local para uma versão mais antiga, a lista de PDBs é atualizada de forma semelhante e pode ter algum atraso.

Solução alternativa:

Nenhum.

Problema de faturamento ao alterar o tipo de licença

Detalhes:

Quando você altera o tipo de licenciamento do seu banco de dados ou sistema de banco de dados de BYOL para a licença incluída, ou o contrário, você é cobrado pelos dois tipos de licenças na primeira hora. Depois disso, você será cobrado de acordo com seu tipo de licença atualizado.

Solução alternativa:

Estamos trabalhando em uma resolução.

Falha ao fazer backup no Object Storage usando dbcli em decorrência de alteração no certificado

Detalhes:

Os backups não gerenciados no Object Storage usando a CLI (dbcli) do banco de dados falham com os seguintes erros:

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

Em resposta às políticas implementadas por dois web browsers comuns em relação aos certificados Symantec, a Oracle alterou recentemente a autoridade de certificado usada para o Oracle Cloud Infrastructure. A alteração resultante nos certificados SSL poderá causar falha nos backups no Object Storage se o Módulo Oracle Database Cloud Backup ainda apontar para o certificado antigo.

Solução alternativa:

Verifique os arquivos de log para os erros listados e, se encontrado, atualize o módulo de backup.

Revise os arquivos de log de backup do RMAN para ver os erros listados acima:

Execute o comando a seguir para determinar o ID do trabalho de backup com falha.

dbcli list-jobs

Neste exemplo de saída, o ID da tarefa de backup com falha é "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

Use o ID do job com falha para obter a localização do arquivo de log a ser verificado.

dbcli describe-job -i <failed_job_ID>

A saída relevante do comando describe-job deve ser semelhante a esta:

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.

Atualize o Módulo Oracle Database Cloud Backup:
1. Determine o ID do armazenamento de objetos Swift e o usuário que o banco de dados está usando para backups.
  1. Execute o comando dbcli list-databases para determinar o ID do banco de dados.
  2. Use o ID do banco de dados para determinar o ID da configuração de backup (backupConfigId).
```
dbcli list-databases
dbcli describe-database -i <database_ID> -j
```
  3. Usando o ID de configuração de backup que você anotou da etapa anterior, determine o ID do armazenamento de objetos (objectStoreId).
```
dbcli list-backupconfigs
dbcli describe-backupconfig -i <backupconfig_ID> -j
```
  4. Usando o ID do armazenamento de objetos que você anotou da etapa anterior, determine o usuário do armazenamento de objetos (userName).
```
dbcli list-objectstoreswifts
dbcli describe-objectstoreswift -i <objectstore_ID> -j
```
2. Usando as credenciais do armazenamento de objetos obtidas na etapa 1, atualize o módulo de backup.
```
dbcli update-objectstoreswift -i <objectstore_ID> -p -u <user_name>
```

Falha ao fazer backup no Object Storage usando o RMAN em decorrência de alteração no certificado

Detalhes:

Backups não gerenciados no Object Storage usando o RMAN falham com os seguintes erros:

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

Solução alternativa:

Verifique os arquivos do log do RMAN para as mensagens do erro listadas. Se for encontrado, faça log-on no host como o usuário oracle e use as credenciais do Swift para reinstalar o módulo de backup.

Observação: As senhas swift agora são chamadas "Tokens de autenticação". Para obter mais informações, consulte Gerenciando Credenciais do Usuário.

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 um sistema de BD com vários nós, execute a solução alternativa em todos os nós do cluster.

Para obter mais informações sobre o Módulo Oracle Database Cloud Backup, consulte Usando o Oracle Database Backup Cloud Service.

Alterações interruptivas nos SDKs de serviço do Banco de Dados

Detalhes:

Os SDKs liberados em 18 de outubro de 2018 introduzem alterações que quebram o código no tamanho do banco de Dados e nos atributos da edição do banco de Dados nas APIs de backup.

Solução alternativa:

Consulte a documentação específica do idioma para obter mais detalhes sobre as alterações de interrupção e atualize seu código existente, conforme aplicável.

Não é possível usar Backups Gerenciados no seu sistema de BD

Detalhes:

As operações de backup e restauração talvez não funcionem no sistema de banco de dados quando você usa a Console ou a API da OCI.

Solução alternativa:

Instale o Oracle Database Cloud Backup Module e entre em contato com o Oracle Support Services para obter mais instruções.

Execute as seguintes etapas para instalar o Módulo Oracle Database Cloud Backup:

Conecte-se via SSH ao sistema de BD e faça log-in como opc.
```
ssh -i <SSH_key> opc@<DB_system_IP address>
login as: opc
```
Como alternativa, você pode usar opc@<DB_system_hostname> para fazer log-in.
Faça download do Módulo do Oracle Database Cloud Backup no Oracle Database Cloud Backup Module.
Extraia o conteúdo do opc_installer.zip para um diretório de destino, por exemplo, /home/opc.
Em sua tenancy, crie um usuário temporário e conceda a eles privilégios para acessar o Object Storage da tenancy.
Para esse usuário temporário, crie um token de autenticação e anote a senha. Para obter mais informações sobre como criar um token de autenticação, consulte Gerenciando Credenciais do Usuário.

Observação: As senhas swift agora são chamadas "Tokens de autenticação".
Verifique se as credenciais funcionam executando o comando curl a seguir:
```
curl -v -X HEAD -u  <user_id>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>
```
Para determinar a região correta, consulte Perguntas mais Frequentes sobre o Object Storage.

O comando deve retornar o código da resposta de status HTTP 200 ou HTTP 204 No Content bem-sucedido. Qualquer outro código do status indica um problema ao estabelecer conexão com o Object Storage.
Execute o seguinte 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
```
etapa <target_dir> é o diretório para onde você extraiu opc_installer.zip na etapa 3.

Este comando pode levar alguns minutos para concluir porque faz o download de libopc.so e outros arquivos. Quando o comando for concluído, você deverá ver vários arquivos (incluindo libopc.so) em seu diretório de destino.
Altere o diretório para seu diretório de destino e copie os arquivos lipopc.so e opc_install.jar no diretório /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
```
(Talvez você precise usar sudo com os comandos de cópia para executá-los como root.)
Execute o seguinte comando para verificar se o diretório indicado existe:
```
ls /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
```
Se esse diretório existir, execute as seguintes etapas:
1. Faça backup dos arquivos no diretório /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs.
2. Execute estes dois comandos para substituir os arquivos libopc.so e opc_install.jar existentes nesse diretório:
```
cp libopc.so /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
cp opc_install.jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
```

Verifique a versão do opc_install.jar.

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

Se o /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs existir, execute também o seguinte comando:

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

Os dois comandos devem retornar a seguinte saída:

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

(Opcional) Exclua o usuário temporário e o diretório de destino usados para instalar o módulo de backup.

Após concluir o procedimento, entre em contato com o Suporte Técnico da Oracle ou com o administrador tenant para obter mais instruções. Forneça o OCID do sistema de BD cujos backups você deseja ativar.

Os Backups Automáticos Gerenciados falham na forma VM.Standard1.1 em decorrência de uma falha do processo

Detalhes:

As limitações de memória das máquinas host que executam a forma VM.Standard1.1 podem causar falhas nos jobs de backup automático de banco de dados gerenciados pelo Oracle Cloud Infrastructure (jobs gerenciados usando a Console do OCI ou a API). Você pode alterar os parâmetros do sistema de memória para resolver esse problema.

Solução alternativa:

Altere os parâmetros de memória do sistema da seguinte forma:

Alterne para o usuário oracle no sistema operacional.
```
[opc@hostname ~]$ sudo su - oracle
```
Defina a variável de ambiente para fazer log-in na instância do banco de dados. Por exemplo:
```
oracle@hostname ~]$ . oraenv
ORACLE_SID = [oracle] ? orcl
```

Inicie o SQL*Plus.

[oracle@hostname ~]$ sqlplus / as sysdba

Altere os parâmetros da memória inicial da seguinte forma:

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

Reinicie a instância do banco de dados.

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

As operações do Oracle Data Pump retornam "ORA-00439: recurso não ativado"

Detalhes:

No sistema de Banco de Dados de Alto Desempenho e Desempenho Extremo, as operações de utilitário do Data Pump que usam compactação e/ou paralelismo podem falhar e retornar o erro ORA-00439: recurso não ativado. Este problema afeta as versões de banco de dados 12.1.0.2.161018 e 12.1.0.2.170117.

Solução alternativa:

Aplique a correção 25579568 ou 25891266 aos homes de banco de dados do Oracle Database para versões 12.1.0.2.161018 ou 12.1.0.2.170117, respectivamente. Como alternativa, use a Console do OCI para aplicar o patch de abril de 2017 ao sistema de banco de dados e home do banco de dados.

Observação: para determinar a versão de um banco, execute $ORACLE_HOME/OPatch/opatch lspatches como usuário do oracle ou dbcli list-dbhomes como usuário do root.

Não foi possível estabelecer conexão com a console do EM Express no sistema de BD com 1 nó

Detalhes:

Talvez você obtenha uma mensagem de erro "Falha de Conexão Severa" ao tentar estabelecer conexão com o console EM Express por meio do sistema de banco de dados de 1 nó porque as permissões corretas não foram aplicadas automaticamente.

Solução alternativa:

Adicione permissões de leitura para o grupo asmadmin no diretório da wallet do sistema de BD e tente novamente a conexão. Execute as seguintes etapas para adicionar permissões de leitura.

Conecte-se por SSH ao host do sistema de banco de dados, faça login como opc e sudo ao usuário grid.

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

Obtenha o local do diretório wallet. É o valor do my_wallet_directory na saída de comando a seguir.

[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))

Retorne ao usuário opc, alterne para o usuário oracle e altere para o diretório wallet.

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

Liste o conteúdo do diretório e observe as permissões.

[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

Altere as permissões.

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

Verifique se as permissões de leitura foram adicionadas.

[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

Informações da Console do OCI não sincronizadas para banco de dados ativados para Data Guard ao usar o dbaascli

Detalhes:

A Console do OCI sincroniza e exibe informações sobre bancos de dados que são criados e gerenciados usando os utilitários dbaasapi e dbaascli. No entanto, os banco de dados com Data Guard configurado não exibem informações corretas na Console do OCI sob as seguintes condições:

Se você tiver ativado o Data Guard usando a Console do OCI e, em seguida, uma alteração for feita no banco de dados principal ou stand-by usando dbaascli (como mover o banco de dados para outro home), o resultado não será refletido na Console do OCI.
Se a Console do OCI tiver sido configurada manualmente, a Console do Data Guard não mostrará uma associação entre os dois bancos.

Solução alternativa:

Estamos cientes do problema e trabalhando em uma solução. Nesse meio tempo, a Oracle recomenda que você gerencie seus bancos de dados ativados pelo Data Guard usando apenas a Console do OCI ou apenas os utilitários do comando.

O Grid Infrastructure não inicia após a colocação de um disco off-line e on-line

Detalhes:

Este é um problema de clusterware que ocorre somente quando a versão do Oracle Grid Infrastructure (GI) é 12.2.0.1 sem qualquer patch de pacote. O problema é causado pela corrupção de um voting disk depois que você coloca o disco off-line, depois on-line.

Solução alternativa:

Determine a versão do GI e se o voting disk está corrompido. Repare o disco, se aplicável; em seguida, aplique o pacote GI mais recente.

Faça o seguinte:

Verifique se a versão do GI é 12.2.0.1 sem qualquer aplicação de pacote de patches:

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

Verifique o arquivo /u01/app/grid/diag/crs/<hostname>/crs/trace/ocssd.trc em busca de evidências de que o GI falhou ao iniciar em decorrência de corrupção no voting disk:

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

Você também pode usar o SQL*Plus para confirmar se os voting disks estão corrompidos:

Efetue log-in como o usuário da grade e defina o ambiente como ASM.

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

Faça log-in no SQL*Plus como o usuário SYSASM.
```
$ORACLE_HOME/bin/sqlplus / as sysasm
```

Execute as duas seguintes consultas:

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;

Se o sistema estiver íntegro, os resultados deverão se parecer com o exemplo a seguir.

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

Em um sistema íntegro, todo voting disk retornado na primeira consulta também deve ser retornado na segunda consulta e as contagens de todos os discos devem ser diferentes de zero. Caso contrário, um ou mais dos seus voting disks serão corrompidos.

Se um voting disk estiver corrompido, coloque off-line o disco de grade que contiver o voting disk. As células moverão automaticamente o voting disk inválido para o outro disco do grid e on-line esse voting disk.
1. O comando a seguir destaca um disco de grade chamado DATAC01_CD_05_SCAQAE08CELADM13.
```
SQL> alter diskgroup DATAC01 offline disk DATAC01_CD_05_SCAQAE08CELADM13;
     Diskgroup altered.
```
2. Aguarde 30 segundos e execute novamente as duas consultas na etapa 3c para verificar se o voting disk migrou para o novo disco de grade e se está íntegro.
3. Verifique se o disco de grade que você colocou off-line agora está on-line:
```
SQL> select name, mode_status, voting_file from v$asm_disk where name='DATAC01_CD_05_SCAQAE08CELADM13';
```
  O mode_status deve ser ON-LINE e o voting_file NÃO deve ser S.
Repita as etapas de 4a a 4c para cada disco de grades restante que contenha um voting disk corrompido.
Observação:

Se o CRS não iniciar por causa dos danos no voting disk, inicie-o usando o modo Exclusivo antes de executar o comando na etapa 4.
```
crsctl start crs -excl
```
Se você estiver usando o Oracle GI versão 12.2.0.1 sem nenhum pacote de patches, será necessário fazer upgrade da versão do GI para o pacote GI mais recente, independentemente de um voting disk ter sido danificado ou não.

Falha no dimensionamento do armazenamento do sistema de banco de dados

Detalhes:

A tentativa de dimensionar de um valor inferior a 10.240 GB para um valor superior a 10.240 GB em uma única operação pode gerar uma falha na operação de dimensionamento.

Solução alternativa:

Se você estiver dimensionando o armazenamento regular de dados ou o armazenamento da área de recuperação (RECO) de um valor inferior a 10.240 GB (10 TB) para um valor superior a 10.240 GB, execute o dimensionamento em duas operações. Primeiro, dimensione o sistema para 10.240 GB. Depois que a primeira operação for concluída e o sistema estiver no estado "disponível", execute uma segunda operação, especificando o valor de armazenamento de destino acima de 10.2440 GB.

Falha no dimensionamento da forma do sistema de banco de dados

Detalhes:

Ao dimensionar um sistema do BD para usar uma forma maior, a operação falhará se um parâmetro DB_Cache_nX não for definido como 0 (zero).

Solução alternativa:

Ao dimensionar um sistema de banco de dados, verifique se todos os parâmetros DB_Cache_nX (por exemplo, DB_nK_CACHE_SIZE) estão definidos como 0 (zero).