Problemas Conhecidos

Detalhes: No Monitoramento Sintético, pode haver falha nos monitores de Browser e de Browser com Script ao executar aplicativos que usam quadros.

Solução Alternativa: Estamos cientes do problema e trabalhando em uma resolução. Para monitores de Browser com Script, você pode contornar esse problema substituindo index=<frame-index> por id=<id-of-frame> ou name=<name-of-frame> no script .side.

Por exemplo, se este script for a versão original:

{
      "id": "23956f51-8812-40e6-ac91-1d608871ee4c",
      "comment": "",
      "command": "selectFrame",
      "target": "index=0",
      "targets": [
        ["index=0"]
      ],
      "value": ""
    }

Este script seria a versão modificada:

{
      "id": "23956f51-8812-40e6-ac91-1d608871ee4c",
      "comment": "",
      "command": "selectFrame",
      "target": "id=frame1",
      "targets": [
        ["id=frame1"]
      ],
      "value": ""
    }

Link direto para este problema: Os monitores de Browser e de Browser com Script podem não executar aplicativos que usam quadros

Detalhes: As políticas de autorização baseadas nas tags de recursos apm-domains não funcionam para as APIs do Trace Explorer e Monitoramento Sintético, causando falhas de autorização.

Solução Alternativa: Estamos cientes do problema e trabalhando em uma resolução.

Link direto para este problema: Problemas com as políticas de autorização baseadas nas tags de recurso apm-domains

Detalhes: Quando você tenta ativar a replicação entre regiões de um volume configurado para usar uma chave de criptografia do serviço Vault, a seguinte mensagem de erro ocorre: Edit Volume Error: You cannot enable cross-region replication for volume <volume_ID> as it uses a Vault encryption key.

Solução alternativa: Estamos trabalhando em uma resolução. Não há suporte para a replicação entre regiões para volumes criptografados com uma chave gerenciada pelo cliente. Como solução alternativa para ativar a replicação, cancele a designação da chave de criptografia do serviço Vault do volume. Neste cenário, o volume é criptografado com uma chave gerenciada pela Oracle.

Link direto para este problema: Sem suporte para a replicação entre regiões para volumes criptografados com chaves gerenciadas pelo cliente

Detalhes: Para obter o nível de desempenho ideal para volumes configurados para desempenho ultra-alto, o anexo de volume deve ser habilitado para Multipath. Anexos habilitados para Multipath para instâncias de VM só são suportados para instâncias com base em formas com 16 OCPUs ou mais.

Se você tiver uma instância com menos de 16 OCPUs, poderá redimensioná-la para que ela tenha 16 ou mais OCPUs para suportar anexos habilitados para Multipath. Esta etapa não funcionará para instâncias em que o número original de OCPUs era inferior a 8 e o anexo de volume é paravirtualizado. Nesse cenário, depois que o volume for desanexado e reanexado, o anexo de volume ainda não será habilitado para Multipath, embora a instância agora suporte anexos habilitados para Multipath.

Solução alternativa: Como solução alternativa, recomendamos que você crie uma nova instância com base em uma forma com 16 ou mais OCPUs e, em seguida, anexe o volume à nova instância.

Link direto para este problema: Anexo de volume paravirtualizado não habilitado para Mutipath após o redimensionamento da instância

Detalhes: Quando você tenta anexar o número máximo de volumes em blocos a uma instância VM.Standard.A1.Flex menor, em alguns casos, pode haver falha na anexação dos volumes. Isso acontece por causa de limitações com a configuração de host físico subjacente.

Solução alternativa: Estamos trabalhando em uma resolução. Como solução alternativa, recomendamos que você aumente o tamanho da VM redimensionando a VM e, em seguida, tente anexar os volumes novamente.

Link direto para este problema: É possível que haja falha ao anexar o número máximo de volumes em blocos a instâncias VM.Standard.A1.Flex menores

Detalhes: Quando você programa backups de volumes e grupos de volumes usando uma política de backup ativada para cópia entre regiões para volumes criptografados usando chaves de criptografia do serviço Vault, as chaves de criptografia não são copiadas com o backup de volume para a região de destino. As cópias de backup de volume na região de destino são criptografadas usando chaves fornecidas pela Oracle.

Solução alternativa: Estamos trabalhando em uma resolução. Como solução alternativa, você pode copiar manualmente backups de volume e backups de grupos de volumes entre regiões, manualmente ou usando um script, e especificar o ID da chave de gerenciamento de chaves na região de destino para a operação de cópia. Para obter mais informações sobre a cópia manual entre regiões, consulte Copiando um Backup de Volume entre Regiões.

Link direto para este problema: Chaves de criptografia do serviço Vault não copiadas para a região de destino para obter cópias de backup programadas entre regiões.

Detalhes: Ao anexar um volume de inicialização do Windows como um volume de dados a outra instância, quando você tenta se conectar ao volume usando as etapas descritas em Estabelecendo Conexão com um Volume em Blocos, há uma falha na anexação do volume e você pode encontrar o seguinte erro:

Connect-IscsiTarget: The target has already been logged in via an iSCSI session.

Solução alternativa: Você precisa anexar o seguinte ao comando Connect-IscsiTarget copiado da Console:

-IsMultipathEnabled $True

Link direto para este problema: Falha ao anexar um volume de inicialização do Windows como um volume de dados a outra instância

Detalhes: Ao chamar GetInstance, o atributo bootVolumeSizeInGBs de InstanceSourceViaImageDetails é nulo.

Solução alternativa: Estamos trabalhando em uma resolução. Para contornar esse problema, chame GetBootVolume e use o atributo sizeInGBs de BootVolume.

Link direto para este problema: O atributo bootVolumeSizeInGBs é nulo

Detalhes: Quando você tenta acessar a Console usando o Firefox, a página Console nunca é carregada no browser. Esse problema é provavelmente causado por um perfil de usuário do Firefox corrompido.

Solução alternativa: Crie um novo perfil de usuário do Firefox da seguinte forma:

1. Verifique se você está na versão mais recente do Firefox. Caso contrário, atualize para a versão mais recente.
2. Crie um novo perfil de usuário e remova seu perfil de usuário antigo. Consulte o Suporte a Mozilla para obter instruções sobre como criar e remover perfis de usuário: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles.
3. Abra o Firefox com o novo perfil.

Como alternativa, você pode usar um dos outros Browsers Suportados.

Link direto para este problema: Um bug no browser Firefox pode fazer com que a Console não seja carregada

Detalhes: Os PDBs existentes não aparecem em um banco de dados recém-criado e pode levar até algumas horas para que apareçam na Console. 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:: Nenhuma

Link direto para este problema: PDBs existentes em um novo banco de dados

Detalhes: Não é permitido criar e clonar um PDB no banco de dados principal por meio da console ou da API.

Solução alternativa: Você pode usar sqlplus para criar ou clonar PDBs no banco de dados Principal e eles serão sincronizados posteriormente na console do OCI.

Link direto para este problema: PDB na configuração existente do Data Guard

Detalhes: O uso da API do Database Service para migrar uma wallet de TDE baseada em arquivo para uma wallet de TDE baseada em chave gerenciada pelo cliente no Oracle Database 12c release 1 (12.1.0.2) falha com o seguinte erro:

[FATAL] [DBAAS-11014] - Os patches necessários (30128047) não estão presentes no Oracle home <ORACLE_HOME>
AÇÃO: Aplique os patches necessários (30128047) e tente a operação novamente

nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

No comando anterior, <kms_key_ocid> refere-se ao OCID da chave gerenciada pelo cliente que você está usando.

Detalhes: O uso da API do Database Service para migrar uma wallet de TDE baseada em chaves gerenciada pelo cliente para uma wallet de TDE baseada em arquivo no Oracle Database 12c release 1 (12.1.0.2) falha com o seguinte erro:

[FATAL] [DBAAS-11014] - Os patches necessários (30128047) não estão presentes no Oracle home <ORACLE_HOME>
AÇÃO: Aplique os patches necessários (30128047) e tente a operação novamente

nohup /var/opt/oracle/dbaascli/dbaascli tde hsm_to_file --dbname <database_name> --skip_patch_check true &

Detalhes: O uso da API do Database Service para migrar uma wallet de TDE baseada em arquivo para a wallet de TDE baseada em chave gerenciada pelo cliente no Oracle Database 12c release 2 (12.2.0.1) falha com o seguinte erro:

[FATAL] [DBAAS-11014] - Os patches necessários (30128047) não estão presentes no Oracle home <ORACLE_HOME>
AÇÃO: Aplique os patches necessários (30128047) e tente a operação novamente

Solução alternativa: Migre uma wallet de TDE baseada em arquivo para uma wallet de TDE baseada em chave gerenciada pelo cliente, da seguinte forma:

1. Determine se o banco de dados criptografou tablespaces UNDO ou TEMP em qualquer um dos Autonomous Databases ou em CDB$ROOT, da seguinte forma:
   Execute a consulta a seguir em CDB$ROOT para listar todos os tablespaces criptografados contidos em todos os Autonomous Databases:

   SQL> select tstab.con_id, tstab.name from v$tablespace tstab, v$encrypted_tablespaces enctstab where tstab.ts# = enctstab.ts# and encryptedts = 'YES';

   Em seguida, na coluna NAME do resultado da consulta, procure os nomes dos tablespaces UNDO e TEMP. Se houver tablespaces UNDO ou TEMP criptografados, prossiga para a próxima etapa.

2. Cancele a criptografia de tablespaces UNDO ou TEMP, como se segue:

   Se um tablespace de UNDO for criptografado

   Decriptografe tablespaces UNDO existentes, como se segue:

   SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

   Repita este procedimento para todos os tablespaces UNDO criptografados.

   Se um tablespace TEMP for criptografado

   1. Verifique o tablespace TEMP padrão da seguinte forma:

      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';

      Se o tablespace TEMP padrão não for criptografado, mas outros tablespaces TEMP forem criptografados, elimine os outros tablespaces TEMP, da seguinte forma:

      SQL> drop tablespace <temp_tablespace_name>;

      Ignore o restante das etapas neste procedimento.

      Se o tablespace TEMP padrão for criptografado, prossiga com as etapas restantes para criar e definir um tablespace TEMP padrão não criptografado.

   2. Defina o parâmetro encrypt_new_tablespaces como DDL, da seguinte forma:

      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;

   3. Crie um tablespace TEMP com as especificações do tablespace TEMP atual, como se segue:

      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;

   4. Defina o novo tablespace TEMP como o tablespace TEMP padrão para o banco de dados da seguinte forma:

      SQL> alter database default temporary tablespace <temp_tablespace_name>;

   5. Elimine os tablespaces TEMP existentes da seguinte forma:

      SQL> drop tablespace <temp_tablespace_name>;

   Repita este procedimento para todos os tablespaces TEMP criptografados.

   O banco de dados agora está em execução com tablespaces UNDO e TEMP padrão que não são criptografados e quaisquer tablespaces TEMP e UNDO mais antigos também são decriptografados.

   Defina encrypt_new_tablespaces como seu valor original, da seguinte forma:

   SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

   Continue com a migração de armazenamento de chaves para chaves gerenciadas pelo cliente.

3. Depois de confirmar que não há tablespaces UNDO ou TEMP criptografados em nenhum dos bancos de dados plugáveis ou em CDB$ROOT, use o utilitário DBAASCLI com o flag --skip_patch_check true para ignorar a validação do patch do bug 30128047. Certifique-se de ter aplicado o patch para o bug 31527103 no Oracle home e, em seguida, execute o seguinte comando dbaascli:

   nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

   No comando anterior, <kms_key_ocid> refere-se ao OCID da chave gerenciada pelo cliente que você está usando.

Detalhes: O uso da API do Database Service para migrar uma wallet de TDE baseada em chave gerenciada pelo cliente para uma wallet de TDE baseada em arquivo no Oracle Database 12c release 2 (12.2.0.1) falha com o seguinte erro:

[FATAL] [DBAAS-11014] - Os patches necessários (30128047) não estão presentes no Oracle home <ORACLE_HOME>
AÇÃO: Aplique os patches necessários (30128047) e tente a operação novamente

Solução alternativa: Migre uma wallet de TDE baseada em chave gerenciada pelo cliente para uma wallet de TDE baseada em arquivo, da seguinte forma:

1. Determine se o banco de dados criptografou tablespaces UNDO ou TEMP em qualquer um dos Autonomous Databases ou em CDB$ROOT, da seguinte forma:
   Execute a consulta a seguir em CDB$ROOT para listar todos os tablespaces criptografados contidos em todos os Autonomous Databases:

   SQL> select tstab.con_id, tstab.name from v$tablespace tstab, v$encrypted_tablespaces enctstab where tstab.ts# = enctstab.ts# and encryptedts = 'YES';

   Em seguida, na coluna NAME do resultado da consulta, procure os nomes dos tablespaces UNDO e TEMP. Se houver tablespaces UNDO ou TEMP criptografados, prossiga para a próxima etapa.

2. Cancele a criptografia de tablespaces UNDO ou TEMP, como se segue:

   Se um tablespace de UNDO for criptografado

   Decriptografe tablespaces UNDO existentes, como se segue:

   SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

   Repita este procedimento para todos os tablespaces UNDO criptografados.

   Se um tablespace TEMP for criptografado

   1. Verifique o tablespace TEMP padrão da seguinte forma:

      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';

      Se o tablespace TEMP padrão não for criptografado, mas outros tablespaces TEMP forem criptografados, elimine os outros tablespaces TEMP, da seguinte forma:

      SQL> drop tablespace <temp_tablespace_name>;

      Ignore o restante das etapas neste procedimento.

      Se o tablespace TEMP padrão for criptografado, prossiga com as etapas restantes para criar e definir um tablespace TEMP padrão não criptografado.

   2. Defina o parâmetro encrypt_new_tablespaces como DDL, da seguinte forma:

      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;

   3. Crie um tablespace TEMP com as especificações do tablespace TEMP atual, como se segue:

      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;

   4. Defina o novo tablespace TEMP como o tablespace TEMP padrão para o banco de dados da seguinte forma:

      SQL> alter database default temporary tablespace <temp_tablespace_name>;

   5. Elimine os tablespaces TEMP existentes da seguinte forma:

      SQL> drop tablespace <temp_tablespace_name>;

   Repita este procedimento para todos os tablespaces TEMP criptografados.

   O banco de dados agora está em execução com tablespaces UNDO e TEMP padrão que não são criptografados e quaisquer tablespaces TEMP e UNDO mais antigos também são decriptografados.

   Defina encrypt_new_tablespaces como seu valor original, da seguinte forma:

   SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

   Continue com a migração de armazenamento de chaves para chaves gerenciadas pelo cliente.

3. Depois de confirmar que não há tablespaces UNDO ou TEMP criptografados em nenhum dos bancos de dados plugáveis ou em CDB$ROOT, use o utilitário DBAASCLI com o flag --skip_patch_check true para ignorar a validação do patch do bug 30128047. Certifique-se de ter aplicado o patch para o bug 29667994 no Oracle home e, em seguida, executado o seguinte comando dbaascli:

   nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

   No comando anterior, <kms_key_ocid> refere-se ao OCID da chave gerenciada pelo cliente que você está usando.

Detalhes: Quando você altera o tipo de licença de seu Banco de Dados ou sistema de DB, de BYOL para licença incluída, e vice-versa, a cobrança é feita pelos dois tipos de licença 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.

Link direto para este problema: Problema de faturamento ao alterar o tipo de licença

Detalhes: Se você configurar sua VCN com um gateway de serviço, a sub-rede privada bloqueará o acesso aos repositórios YUM necessários para atualizar o SO. Este problema afeta todos os tipos de sistemas de BD.

Solução alternativa: Este problema agora foi resolvido. Esta é a solução alternativa recomendada antes da resolução do problema:

O gateway de serviço permitirá o acesso ao repositório do Oracle YUM se você usar os Labels CIDR de Serviço Disponível chamados Todos os Serviços de <region> na Oracle Services Network. No entanto, você ainda pode ter problemas para acessar os serviços YUM por meio do gateway de serviço. Há uma solução para o problema. Para obter detalhes, consulte Problemas com acesso das instâncias aos serviços yum da Oracle por meio do gateway de serviço.

Link direto para este problema: O gateway de serviço não suporta atualmente atualizações de SO

Detalhes: Backups não gerenciados para o Object Storage usando a CLI do banco de dados (dbcli) ou 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

Em resposta a políticas implementadas por dois Web browsers comuns em relação aos certificados Symantec, a Oracle alterou recentemente a autoridade de certificação usada para o Oracle Cloud Infrastructure. A alteração resultante em certificados SSL pode fazer com que os backups no Object Storage falhem se o Módulo de Backup do Oracle Database Cloud ainda apontar para o certificado antigo.

Solução alternativa para dbcli: Verifique os arquivos de log para ver os erros listados e, se encontrados, atualize o módulo de backup.

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

1. Determine o ID do job de backup com falha.

   dbcli list-jobs

   Neste exemplo de saída, o ID do job 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

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

Atualizar o Módulo de Backup do Oracle Database Cloud:

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>

Solução alternativa para RMAN: Verifique os arquivos de log do RMAN para obter as mensagens de 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.

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.

Consulte a documentação do Módulo de Backup do Oracle Database Cloud para obter detalhes sobre a utilização deste comando.

Link direto para este problema: Falha no backup do Object Storage usando dbcli ou RMAN em decorrência de alteração no certificado

Detalhes: Os SDKs liberados em 18 de outubro de 2018 introduzem alterações interruptivas no tamanho do banco de dados e nos atributos de edição do banco de dados nas APIs de backup do banco de dados.

Solução alternativa: Consulte a documentação específica do idioma a seguir para obter mais detalhes sobre alterações interruptivas e atualize o código existente conforme aplicável:

Link direto para este problema: Alterações interruptivas nos SDKs de serviço do Banco de Dados

Detalhes: As operações de backup e restauração podem não funcionar em seu sistema de BD quando você usar a Console ou a API.

Solução alternativa: Instale o Módulo de Backup do Oracle Database Cloud e entre em contato com o Oracle Support Services para obter mais instruções.

Para instalar o Módulo de Backup do Oracle Database Cloud:

1. SSH para o 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.

2. Faça download do Módulo de Backup do Oracle Database Cloud em http://www.oracle.com/technetwork/database/availability/oracle-cloud-backup-2162729.html.
3. Extraia o conteúdo de opc_installer.zip para um diretório de destino, por exemplo, /home/opc.
4. Em sua tenancy, crie um usuário temporário e conceda a ele privilégios para acessar o Object Storage da tenancy.
5. Para este usuário temporário, crie um token de autenticação e anote a senha.

6. Verifique se as credenciais funcionam executando o comando curl a seguir:

   Observação
   
   As senhas do Swift agora são chamadas de "Tokens de autenticação". Para obter detalhes, consulte Usando um Token de Autenticação com Swift.

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

   Consulte https://cloud.oracle.com/infrastructure/storage/object-storage/faq para obter a região correta a ser usada.

   O comando deve retornar HTTP 200 ou o código de resposta do status de sucesso HTTP 204 Sem Conteúdo. Qualquer outro código de status indica um problema ao estabelecer conexão com o Object Storage.

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

   Observe que <target_dir> é o diretório para o qual você extraiu opc_installer.zip na etapa 3.

   Este comando pode levar alguns minutos para ser concluído porque faz download de libopc.so e de outros arquivos. Após a conclusão do comando, você deverá ver vários arquivos (incluindo libopc.so) no diretório de destino.

8. Altere o diretório para o diretório de destino e copie os arquivos lipopc.so e opc_install.jar para o 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

   (Pode ser necessário utilizar sudo com os comandos de cópia para executá-los como raiz).

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

10. Verifique a versão de opc_install.jar.

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

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

    Ambos os comandos devem retornar a seguinte saída:

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

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

Link direto para este problema: Não é possível usar Backups Gerenciados no seu Sistema de BD

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

Solução alternativa: Altere os parâmetros de memória do sistema da seguinte forma:

1. Alterne para o usuário oracle no sistema operacional.

   [opc@hostname ~]$ sudo su - oracle

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

3. Inicie o SQL*Plus.

   [oracle@hostname ~]$ sqlplus / as sysdba

4. Altere os parâmetros de memória iniciais 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
   							

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

Link direto para este problema: Os Backups Automáticos Gerenciados falharam na forma VM.Standard1.1 em decorrência de uma falha do processo

Detalhes: Nos sistemas de BD High Performance e Extreme Performance, as operações do utilitário 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 o patch 25579568 ou 25891266 aos homes do Oracle Database para as versões de banco de dados 12.1.0.2.161018 ou 12.1.0.2.170117, respectivamente. Como alternativa, use a Console para aplicar o patch de abril de 2017 ao sistema de BD e ao home do banco de dados.

Link direto para este problema: Operações do Oracle Data Pump retornam "ORA-00439: recurso não ativado"

Detalhes: Você pode obter uma mensagem de erro "Falha na Conexão Segura" quando tentar estabelecer conexão com a console do EM Express pelo sistema de BD com 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 repita a conexão:

1. SSH para o host do sistema do BD, faça log-in como opc, sudo para o usuário do grid.

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

2. Obtenha a localização do diretório da wallet, mostrada em vermelho abaixo na saída do 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. Retornar ao usuário opc, alternar para o usuário oracle e alterar para o diretório da wallet.

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

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

5. Altere as permissões:

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

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

Link direto para este problema: Não foi possível estabelecer conexão com a console do EM Express do seu sistema de BD com 1 nó

Detalhes: As operações de backup para o Object Storage usando o utilitário de backup do Exadata (bkup_api) ou RMAN falharam com os seguintes erros:

* DBaaS Error trace:
-> API::ERROR -> KBHS-00715: HTTP error occurred 'oracle-error'
-> API::ERROR -> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> API::ERROR -> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> API::ERROR -> ORA-27023: skgfqsbi: media manager protocol error
-> API::ERROR Unable to verify the backup pieces
-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error

Em resposta a políticas implementadas por dois Web browsers comuns em relação aos certificados Symantec, a Oracle alterou recentemente a autoridade de certificação usada para o Oracle Cloud Infrastructure. A alteração resultante em certificados SSL pode fazer com que os backups no Object Storage falhem se o Módulo de Backup do Oracle Database Cloud ainda apontar para o certificado antigo.

Solução alternativa para bkup_api: Verifique os arquivos de log quanto aos erros listados acima e, se forem encontrados, reinstale o módulo de backup.

Use o seguinte comando para verificar o status do backup com falha:

/var/opt/oracle/bkup_api/bkup_api bkup_status --dbname=<database_name>

Execute o seguinte comando para reinstalar o módulo de backup:

/var/opt/oracle/ocde/assistants/bkup/bkup -dbname=<database_name>

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

java -jar <opc_install.jar_path> -opcId '<Swift_user_ID>' -opcPass '<auth_token>' -container <objectstore_container> -walletDir <wallet_directory> -configfile <config_file> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -import-all-trustcerts

Execute essa solução alternativa em todos os nós do cluster.

Consulte a documentação do Módulo de Backup do Oracle Database Cloud para obter detalhes sobre a utilização deste comando.

Link direto para este problema: Falha no backup do Object Storage usando bkup_api ou RMAN em decorrência de alteração no certificado

Detalhes: Com a versão do recurso Home do Banco de Dados compartilhado para sistemas de BD Exadata, a Console agora também sincroniza e exibe informações sobre bancos de dados criados e gerenciados por meio dos utilitários dbaasapi e dbaascli. Entretanto, os bancos de dados com o Data Guard configurado não exibem informações corretas na Console nas seguintes condições:

• Se o Data Guard tiver sido ativado usando a Console 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 se refletirá na Console.
• Se o Data Guard tiver sido configurado manualmente, a Console não mostrará uma associação do Data Guard entre os dois bancos de dados.

Solução alternativa: Estamos cientes do problema e trabalhando em uma resolução. Enquanto isso, a Oracle recomenda que você gerencie seus bancos de dados ativados pelo Data Guard usando apenas a Console ou apenas utilitários de linha de comando.

Link direto para esse problema: Informações de console não sincronizadas para bancos de dados ativados pelo Data Guard ao usar dbaascli

Detalhes: Este é um problema do clusterware que ocorre somente quando a versão do Oracle GI é 12.2.0.1 sem qualquer pacote de patches. 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.

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

2. Verifique o arquivo /u01/app/grid/diag/crs/<hostname>/crs/trace/ocssd.trc para ver se o GI falhou ao ser iniciado em decorrência de corrupção do 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

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

   1. Faça login como o usuário grid 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

   2. Faça log-in no SQL*Plus como o usuário SYSASM.

      $ORACLE_HOME/bin/sqlplus / as sysasm

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

      Resultados da Consulta 1

      NAME                           VOTING_FILE
      ------------------------------ ---------------
      DBFSC3_CD_02_SLCLCX0788        Y
      DBFSC3_CD_09_SLCLCX0787        Y
      DBFSC3_CD_04_SLCLCX0786        Y

      Resultados da Consulta 2

      NAME                           COUNT(*)
      ------------------------------ ---------------
      DBFSC3_CD_02_SLCLCX0788        8
      DBFSC3_CD_09_SLCLCX0787        8
      DBFSC3_CD_04_SLCLCX0786        8

      Em um sistema íntegro, cada 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.

4. 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 de grade e colocarão esse voting disk on-line.

   1. O comando a seguir coloca off-line 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 ONLINE e o voting_file NÃO deve ser Y.

   Repita as etapas 4a a a 4c para cada disco de grade restante que contenha um voting disk danificado.

   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

    

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

   Consulte Aplicando Patch no Oracle Grid Infrastructure e no Oracle Databases com dbaascli para obter instruções sobre como usar o utilitário dbaascli para executar operações de aplicação de patch para o Oracle Grid Infrastructure e o Oracle Database em Serviço Exadata Database em Infraestrutura Dedicada.

Link direto para este problema: O Grid Infrastructure não inicia após a colocação de um disco off-line e on-line

Detalhes: Sistemas de BD Exadata iniciados a partir de 15 de junho de 2018 incluem automaticamente a capacidade de criar, listar e excluir bancos de dados usando a Console, API ou a CLI do Oracle Cloud Infrastructure. No entanto, os sistemas provisionados antes dessa data exigem etapas extras para ativar essa funcionalidade.

As tentativas de usar essa funcionalidade sem as etapas extras resultam nas seguintes mensagens de erro:

• Na criação de um banco de dados - "Não há suporte para a criação de Banco de Dados neste sistema de BD Exadata. Para ativar esse recurso, entre em contato com o Suporte Técnico da Oracle."
• No encerramento de um banco de dados - "Não há suporte para DeleteDbHome neste sistema de BD Exadata. Para ativar esse recurso, entre em contato com o Suporte Técnico da Oracle."

Solução alternativa: Você precisa instalar o agente Exadata em cada nó do sistema de BD Exadata.

Primeiro, crie uma solicitação de serviço para obter assistência do Oracle Support Services. O Oracle Support responderá fornecendo um URL pré-autenticado para uma localização do Oracle Cloud Infrastructure Object Storage na qual você pode obter o agente.

Antes de instalar o agente Exadata:

• Faça upgrade da ferramenta (dbaastools rpm) para a versão mais recente em todos os nós no sistema de BD Exadata. Consulte Atualizando Ferramentas em uma Instância do Exadata Cloud Service
• Verifique se o sistema está configurado para acessar o Oracle Cloud Infrastructure Object Storage com as listas de segurança necessárias para a região na qual o sistema de BD foi criado. Para obter mais informações sobre a conectividade com o Object Storage do Oracle Cloud Infrastructure, consulte Pré-requisitos para Backups no Exadata Cloud Service.

Para instalar o agente Exadata:

1. Faça log-on no nó como raiz.

2. Execute os seguintes comandos para instalar o agente:

   [root@<node_n>~]# cd /tmp
   [root@<node_n>~]# wget https://objectstorage.<region_name>.oraclecloud.com/p/1q523eOkAOYBJVP9RYji3V5APlMFHIv1_6bAMmxsS4E/n/dbaaspatchstore/b/dbaasexadatacustomersea1/o/backfill_agent_package_iwwva.tar
   [root@<node_n>~]# tar -xvf /tmp/backfill_agent_package_*.tar -C /tmp
   [root@<node_n>~]# rpm -ivh /tmp/dbcs-agent-2.5-3.x86_64.rpm

   Exemplo de saída:

   [root@<node_n>~]# rpm -ivh dbcs-agent-2.5-3.x86_64.rpm
   Preparing...                ########################################### [100%]
   Checking for dbaastools_exa rpm on the system
   Current dbaastools_exa version = dbaastools_exa-1.0-1+18.1.4.1.0_180725.0000.x86_64
   dbaastools_exa version dbaastools_exa-1.0-1+18.1.4.1.0_180725.0000.x86_64 is good. Continuing with dbcs-agent installation
      1:dbcs-agent             ########################################### [100%]
   initctl: Unknown instance:
   initctl: Unknown instance:
   initzookeeper start/running, process 85821
   initdbcsagent stop/waiting
   initdbcsadmin stop/waiting
   initdbcsagent start/running, process 85833
   initdbcsadmin start/running, process 85836
   

3. Confirme se o agente está instalado e em execução.

   [root@<node_n>~]# rpm -qa | grep dbcs-agent
   dbcs-agent-2.5-0.x86_64
   [root@<node_n>~]# initctl status initdbcsagent
   initdbcsagent start/running, process 97832

4. Repita as etapas 1 a 3 nos nós restantes.

Depois que o agente for instalado em todos os nós, aguarde até 30 minutos para que o Oracle conclua tarefas adicionais do workflow, como o upgrade do agente para a versão mais recente, a rotação das credenciais do agente e assim por diante. Quando o processo estiver concluído, você poderá usar os recursos gerenciados do Exadata na Console, na API ou na CLI do Oracle Cloud Infrastructure.

Link direto para este problema: Recursos gerenciados não ativados para sistemas provisionados antes de 15 de junho de 2018

Detalhes: O arquivo de configuração de patch (/var/opt/oracle/exapatch/exadbcpatch.cfg) aponta para o armazenamento de objetos da região us-phoenix-1, mesmo que o sistema de BD Exadata esteja implantado em outra região.

Esse problema ocorrerá se a versão da release do pacote de ferramentas do banco de dados (dbaastools_exa) for 17430 ou anterior.

Solução alternativa: Siga as instruções em Atualizando as Ferramentas em uma Instância do Exadata Cloud Service para confirmar que a versão da release do pacote de ferramentas é 17430 ou anterior e, em seguida, atualize-a para a versão mais recente.

Link direto para este problema: O arquivo de configuração de aplicação de patches aponta para uma região incorreta

Detalhes: Uma alteração na forma pela qual o Oracle Linux 7 trata os arquivos temporários pode resultar na remoção dos arquivos de soquete obrigatórios do diretório /var/tmp/.oracle. Este problema afeta somente sistemas de BD Exadata que executam a imagem do sistema operacional da versão 19.1.2.

Solução alternativa: Execute sudo /usr/local/bin/imageinfo como o usuário opc para determinar sua versão da imagem do sistema operacional. Se sua versão de imagem for 19.1.2.0.0.190306, siga as instruções em ID do Doc 2498572.1 para corrigir o problema.

Link direto para este problema: Várias falhas de workflow do banco de dados em decorrência da remoção de arquivos temporários obrigatórios do Oracle Linux 7

Detalhes: Se você usar backups do grupo de volumes ao executar operações de DR para computação e armazenamento em diferentes ADs dentro da mesma região, as transições de DR anteriores e posteriores farão com que a computação e o armazenamento em blocos associado (que usa backups de grupos de volumes) terminem em um AD diferente a cada vez.

Solução alternativa: esse problema não afeta o armazenamento em blocos replicado usando a replicação do grupo de volumes.

Detalhes: O ajuste automático das definições de desempenho para volumes de armazenamento em blocos não é realizado durante as operações de DR.

Workaround: For block storage volumes which have auto-tuned performance enabled you must re-enable these settings after Full Stack DR transitions these block storage volumes to another region.

Detalhes: Se você executar uma operação de failover imediatamente após modificar um recurso protegido por DR do Full Stack, a recuperação do recurso poderá falhar ou o recurso poderá não ser recuperado corretamente. Por exemplo, se você alterar o destino da replicação ou outras propriedades de um grupo de volumes que você adicionou a um grupo de proteção DR e a região primária sofrer uma interrupção imediata daí em diante, o Full Stack DR poderá não detectar as alterações feitas nas definições de replicação do grupo de volumes, e isso afetará a recuperação desse grupo de volumes.

Solução alternativa: Execute uma pré-verificação de switchover imediatamente após fazer qualquer alteração em qualquer recurso sob proteção DR.

Details: Full Stack DR uses the Oracle Cloud Agent (OCA) Run Command utility to run local scripts on instances. Quando você configura uma etapa definida pelo usuário para executar um script local em uma instância do Microsoft Windows, não é possível usar o recurso Executar como Usuário do Full Stack DR que permite especificar outro userid para executar scripts locais que residem em instâncias.

Solução alternativa: Nas instâncias do Microsoft Windows, o script só pode ser executado como o userid padrão ocarun usado pelo utilitário Executar Comando do Oracle Cloud Agent. Essa limitação não afeta as instâncias do Oracle Linux.

Details: Full Stack DR uses the Oracle Cloud Agent (OCA) Run Command utility to run local scripts on instances. Por padrão, esses scripts são executados como o usuário ocarun.

Solução alternativa: Em uma instância do Microsoft Windows, qualquer script local que você configurar para executar como etapa definida pelo usuário em um plano de DR deve estar acessível e executável por este id de usuário ocarpo.

Detalhes: Ao executar um script local usando uma etapa definida pelo usuário em um plano de DR, se você não fornecer caminhos completos para interpretadores ou scripts de script, o Full Stack DR gerará erros.

Solução alternativa: Ao configurar uma etapa definida pelo usuário em um plano DR para executar um script local que reside em uma instância, certifique-se de fornecer o caminho completo para qualquer interpretador que possa vir antes do nome do script, bem como o caminho completo para o script.

Detalhes: Durante as operações de DR, o DR de Pilha Completa tentará redesignar o IP privado original designado a uma instância se o bloco CIDR da sub-rede de destino corresponder ao bloco CIDR da sub-rede de origem e se o IP privado original da instância ainda não tiver sido designado.

Se você usar o DR de Pilha Completa para realocar todos os nós em um cluster OCFS2 e o IP privado de qualquer nó do cluster não puder ser reatribuído, esses nós do cluster serão desconectados do cluster OCFS2 depois que os nós forem iniciados na região standby.

Solução alternativa: Certifique-se de que o bloco CIDR da sub-rede de destino corresponda ao bloco CIDR da sub-rede de origem e que todos os endereços IP privados necessários para nós do cluster estejam disponíveis na sub-rede de destino.

Detalhes: Depois que o Full Stack DR realoca uma instância para outra região, a página de recursos da instância pode exibir a seguinte mensagem para Acesso à Instância:

Não temos certeza absoluta de como estabelecer conexão com uma instância que usa essa imagem

Solução alternativa: Ignore esta mensagem. As conexões SSH com a instância funcionarão normalmente se você usar o arquivo de chaves SSH original para estabelecer conexão e autenticar a instância.

Detalhes: Depois que o Full Stack DR realoca uma instância para outra região, a página de recursos da instância poderá exibir informações incorretas para a parte Imagem de seu volume de inicialização.

Por exemplo, a coluna Informações da imagem pode exibir a seguinte mensagem: Erro ao carregar dados

Solução alternativa: Esta mensagem de erro é para exibição do nome da Imagem, mas não afeta a operação da instância ou seu volume de inicialização.

Detalhes: Quando não há tempo de espera para o comando nohup, o comando run falha na execução e falha ao reportar o status com sucesso.

nohup sh enabler.sh  &> enabler.log &
sleep 10
exit 0

Detalhes: Durante uma transição de DR, quando os volumes em blocos são movidos para outra região, as definições de desempenho (IOPS e Throughput) não são replicadas e restauradas automaticamente. Talvez seja necessário reconfigurar essas definições de desempenho.

Solução alternativa: Depois de executar um plano de DR, configure a definição de desempenho manualmente.

Detalhes: O upload sob demanda de um arquivo zip criado em uma máquina Windows pode, às vezes, falhar ao fazer upload do conteúdo do log. O motivo da falha é que o zip criado no Windows tem o mesmo horário para a última modificação e a criação do arquivo. Portanto, quando o arquivo é descompactado, o horário da última modificação do arquivo é definido como o horário de criação do arquivo, que pode o timestamp das entradas de log no arquivo de log. Nesse caso, as entradas de log com o timestamp mais recente do que o horário da última modificação do arquivo não são carregadas.

Um exemplo do problema:

Timestamp na entrada de log: 2020-10-12 21:12:06

Horário da última modificação do arquivo de log: 2020-10-10 08:00:00

Solução alternativa: Copie os arquivos de log para uma nova pasta e crie um arquivo zip. Esta ação torna o horário da última modificação do arquivo mais recente que o timestamp das entradas de log. Use esse novo arquivo zip para upload sob demanda.

Usando o exemplo anterior, após a implementação da solução alternativa:

Timestamp na entrada de log: 2020-10-12 21:12:06

Horário da última modificação do arquivo de log: 2021-03-31 08:00:00

Link direto para este problema: Upload sob demanda de uma máquina Windows usando um arquivo zip

Detalhes: As pastas que contêm mais de 10.000 arquivos podem causar alto uso de recursos (memória/armazenamento/CPU) pelo Management Agent, o que pode levar à coleta lenta de logs, afetar outras funcionalidades do Management Agent e também pode tornar a máquina host mais lenta.

Quando pastas grandes são encontradas pelo plug-in do Management Agent Logging Analytics, uma mensagem semelhante à seguinte mensagem de exemplo é adicionada ao arquivo mgmt_agent_logan.log do Management Agent:

2020-07-30 14:46:51,653 [LOG.Executor.2388 (LA_TASK_os_file)-61850] INFO - ignore large dir /u01/service/database/logs. set property loganalytics.enable_large_dir to enable. 

Resolução: Recomendamos evitar pastas grandes. Utilize um mecanismo de limpeza para remover arquivos logo após eles serem coletados para que o Management Agent tenha tempo suficiente para coletá-los novamente.

No entanto, se você quiser continuar monitorando logs em pastas grandes, poderá ativar o suporte executando a seguinte ação:

sudo -u mgmt_agent echo "loganalytics.enable_large_dir=true" >> INSTALL_DIRECTORY/agent_inst/config/emd.properties

Substitua INSTALL_DIRECTORY pelo caminho para a pasta agent_inst e reinicie o agente.

Link direto para este problema: Tratamento especial ao monitorar logs em pastas grandes