Problemas Conhecidos

Detalhes: Em Monitoramento Sintético, os monitores Browser e Browser com Script podem não ser executados em 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 Browser e Browser com Script podem não executar aplicativos que usem quadros

Detalhes: As políticas de autorização baseadas nas tags do recurso apm-domains não funcionam para as APIs do Trace Explorer e Monitoramento Sintético, causando falhas na 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 da autorização com base nas tags do recurso apm-domains

Detalhes: Quando você tenta acessar a Console usando o Firefox, a página Console nunca será 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: O bug no browser Firefox pode fazer a Console não ser 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: PBDs existentes em um novo banco de dados

Detalhes: A criação e a clonagem de um PDB no banco de dados principal não são permitidas por meio do console ou da API.

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

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

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

[FATAL] [DBAAS-11014] - Os patches obrigatórios (30128047) não estão presentes no Oracle home <ORACLE_HOME>
ACTION: aplique os patches obrigatórios (30128047) e repita a operação

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: Falha no uso da API do Database Service para migrar uma wallet TDE baseada em chave gerenciada pelo cliente para uma wallet TDE baseada em arquivo no Oracle Database 12c release 1 (12.1.0.2) com o seguinte erro:

[FATAL] [DBAAS-11014] - Os patches obrigatórios (30128047) não estão presentes no Oracle home <ORACLE_HOME>
ACTION: aplique os patches obrigatórios (30128047) e repita a operação

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

Detalhes: Falha no uso da API do Serviço Database para migrar uma wallet TDE baseada em arquivo para a wallet TDE baseada em chaves gerenciada pelo cliente no Oracle Database 12c release 2 (12.2.0.1) com o seguinte erro:

[FATAL] [DBAAS-11014] - Os patches obrigatórios (30128047) não estão presentes no Oracle home <ORACLE_HOME>
ACTION: aplique os patches obrigatórios (30128047) e repita a operação

Solução alternativa: Migre uma wallet TDE baseada em arquivo para uma wallet TDE baseada em chave gerenciada pelo cliente, como se segue:

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 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: Falha no uso da API do Serviço Database para migrar uma wallet TDE baseada em chave gerenciada pelo cliente para uma wallet TDE baseada em arquivo no Oracle Database 12c release 2 (12.2.0.1) com o seguinte erro:

[FATAL] [DBAAS-11014] - Os patches obrigatórios (30128047) não estão presentes no Oracle home <ORACLE_HOME>
ACTION: aplique os patches obrigatórios (30128047) e repita a operação

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

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 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 carteira de habilitação do seu banco de dados ou sistema de banco de dados de BYOL para licença incluída, ou vice-versa, você é cobrado pelos dois tipos de carteira de habilitação pela 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 do serviço permite acesso ao repositório do Oracle YUM se você usar a Visão Geral dos Gateways de Serviço chamada Todos os Serviços <region> no 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: Os backups não gerenciados no Object Storage usando o banco de dados CLI (dbcli) ou 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 às políticas implementadas por dois web browsers comuns em relação aos certificados Symantec, a Oracle alterou recentemente a autoridade de certificado usada no 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 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 no sistema de banco de dados quando você usa 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 eles 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 do 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 nos jobs de backup automático de banco de dados gerenciados pelo Oracle Cloud Infrastructure (jobs gerenciados usando a Console ou a 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 e 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 no Object Storage usando o utilitário Exadata de Backup (bkup_api) ou o RMAN falham 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 às políticas implementadas por dois web browsers comuns em relação aos certificados Symantec, a Oracle alterou recentemente a autoridade de certificado usada no 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 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 release do recurso Home de Banco da Dados compartilhado para sistemas Exadata DB, a Console agora também sincroniza e exibe informações sobre bancos de dados 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 sob as seguintes condições:

• Se a Console tiver ativado o Data Guard 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.
• Se Data Guard tiver sido configurado manualmente, a Console não mostrará uma associação Data Guard entre os dois banco 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 para o Data Guard usando apenas a Console ou apenas os utilitários da linha do 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 Patches ao Oracle Grid Infrastructure e a Bancos de Dados Oracle com o Utilitário dbaascli para ver instruções sobre como usar o utilitário dbaascli para executar operações de aplicação de patches no Oracle Grid Infrastructure e Oracle Database no Exadata Database Service on Dedicated Infrastructure.

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: Os sistemas de banco de dados Exadata iniciados em 15 de Junho de 2018 ou posterior incluem automaticamente a capacidade de criar, listar e excluir bancos de dados usando a Console, a API ou o Oracle Cloud Infrastructure CLI. 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 Suporte Técnico da Oracle responderá fornecendo um URL pré-autenticado para um local do Oracle Cloud Infrastructure Object Storage no 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
• Certifique-se de que o sistema esteja configurado para acessar oOracle Cloud Infrastructure Object Storage com as listas necessárias de segurança para a região na qual o sistema de banco de dados foi criado. Para obter mais informações sobre conectividade com o Oracle Cloud Infrastructure Object Storage, 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 no Oracle Cloud Infrastructure CLI.

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 aplicação de patch (/var/opt/oracle/exapatch/exadbcpatch.cfg) aponta para o armazenamento de objeto da região us-phoenix-1, mesmo que o sistema de banco de dados 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 o Conjunto de Ferramentas em uma instância do Exadata Cloud Service para confirmar se a versão da release do pacote de Ferramentas é 17430 ou inferior e, em seguida, atualizá-la 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 como o Oracle Linux 7 trata arquivos temporários pode resultar na remoção dos arquivos de soquete necessá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 a versão de imagem de seu 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 de grupos de volume ao executar operações DR para computação e armazenamento entre diferentes ADs na mesma região, as transições DR anterior e posterior farão com que a computação e o armazenamento de blocos associado (que usa backups de grupos de volume) acabem em um AD diferente a cada vez.

Solução alternativa: Este problema não afeta o armazenamento de blocos que é replicado usando a replicação de grupo de volumes.

Detalhes: As definições do desempenho de ajuste automático para volumes de armazenamento de blocos não são transportadas durante as operações de DR.

Solução Alternativa: Para volumes de armazenamento de bloco que têm o desempenho de ajuste automático ativado, você deve reativar essas definições após o Full Stack DR fazer a transição desses volumes de armazenamento de bloco para outra região.

Detalhes: Se você executar uma operação de failover imediatamente após modificar um recurso protegido por DR de Pilha Completa, 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 volume que você adicionou a um grupo de proteção de DR e a região principal sofrer uma interrupção imediata posteriormente, o Full Stack DR poderá não detectar as alterações feitas nas definições da replicação do grupo de volume, e isso afetará a recuperação desse grupo de volume.

Solução Alternativa: Execute uma pré-verificação de switchover imediatamente após fazer quaisquer alterações em quaisquer recursos sob proteção de DR.

Detalhes: O Full Stack DR usa o utilitário Executar Comando do Oracle Cloud Agent (OCA) para executar scripts locais em instâncias. Quando você configura uma etapa definida pelo usuário para executar um script local em uma instância de Microsoft Windows, não é possível usar a funcionalidade Executar como Usuário do Full Stack DR, que permite especificar outro userid para executar scripts locais que residem nas instâncias.

Solução alternativa: Nas instâncias doMicrosoft Windows, o script só pode ser executado como o id de usuário padrão ocarun usado pelo utilitário Run Command do Oracle Cloud Agent. Essa limitação não afeta as instâncias do Oracle Linux.

Detalhes: O Full Stack DR usa o utilitário Executar Comando do Oracle Cloud Agent (OCA) para executar scripts locais em instâncias. Por padrão, esses scripts são executados como o usuário ocarun.

Solução alternativa: Em uma instância doMicrosoft Windows, qualquer script local configurado para ser executado como uma etapa definida pelo usuário em um plano de DR deve estar acessível e executável por este ID de usuário do ocarun.

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 os interpretadores ou scripts do script, o Full Stack DR gerará erros.

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

Detalhes: Durante operações do DR, o Full Stack DR tentará reatribuir o IP privado original designado a uma instância se o bloco CIDR da Sub-rede do Destino corresponder ao bloco CIDR da Sub-rede da Origem e se o IP privado original da instância ainda não estiver designado.

Se você usar o Full Stack DR para realocar todos os nós em um cluster do OCFS2 e o IP privado de qualquer nó do cluster não for reatribuído, esses nós serão desanexados do cluster do OCFS2 após os nós serem iniciados na região stand-by.

Solução Alternativa: Verifique se o blocos CIDR da Sub-rede do destino corresponde ao bloco CIDR da Sub-rede da Origem e se todos os endereços IP privados necessários para os nós do cluster estão disponíveis na Sub-rede do destino.

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

Não temos certeza de como conectar-se a uma instância com a qual esta imagem é usada

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 pode exibir informações incorretas para a parte Imagem de seu volume da inicialização.

Por exemplo, a coluna de informações da Imagem pode exibir a seguinte mensagem: Erro ao carregar dados

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

Detalhes: Quando não há tempo de inatividade para o comando nohup, o comando run falha ao ser executado 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 configurações de desempenho.

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

Detalhes: O upload sob solicitação de um arquivo zip criado em uma máquina Windows às vezes pode 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 solicitação de uma máquina Windows usando um arquivo zip

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

Quando pastas grandes são encontradas pelo plug-in Log Analytics do Management Agent, uma mensagem semelhante ao seguinte exemplo de mensagem é 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. Utilizar um mecanismo de limpeza para remover arquivos logo após sua coleta, de modo 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