Problemas Conhecidos
As listas a seguir descrevem os problemas conhecidos com o Oracle Cloud Infrastructure.
Anúncios
Atualmente, não há problemas conhecidos de Anúncios.
Anomaly Detection
Atualmente, não há problemas conhecidos com o serviço Anomaly Detection.
API Gateway
Para saber os problemas conhecidos do serviço API Gateway, consulte Problemas conhecidos do serviço API Gateway.
Serviço Application Performance Monitoring
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
Serviço Artifact Registry
Para problemas conhecidos do serviço Artifact Registry, consulte Problemas Conhecidos.
Audit
Atualmente, não há problemas de Auditoria conhecidos.
Serviço Automated CEMLI Execution
Para saber os problemas conhecidos do serviço Automated CEMLI Execution, consulte Problemas Conhecidos.
Autonomous Linux
Para problemas conhecidos do Autonomous Linux, consulte Problemas Conhecidos.
Bastion
Para problemas conhecidos do serviço Bastion, consulte Problemas Conhecidos.
Serviço Big Data
Para problemas conhecidos do Big Data Service, consulte Problemas Conhecidos.
Gerenciamento de Custos e Faturamento
Para problemas conhecidos do Billing and Cost Management, consulte Problemas Conhecidos do Billing and Cost Management.
Block Volume
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
Blockchain Platform
Para problemas conhecidos do serviço Blockchain Platform, consulte Problemas Conhecidos.
Certificados
Para problemas conhecidos do serviço Certificates, consulte Problemas Conhecidos.
Serviço Cloud Guard
Para problemas conhecidos do serviço Cloud Guard, consulte Problemas Conhecidos.
Cloud Shell
Para problemas conhecidos do Cloud Shell, consulte Problemas Conhecidos do Cloud Shell.
Grupos de Posicionamento de Clusters
Para problemas conhecidos dos Grupos de Posicionamento do Cluster, consulte Problemas Conhecidos.
Compartment Quotas
Para problemas conhecidos de Compartment Quotas, consulte Problemas Conhecidos do Compartment Quotas.
Compliance Documents
Para problemas conhecidos do serviço Compliance Documents, consulte Problemas Conhecidos do Serviço Compliance Documents.
Computação
Para problemas conhecidos do serviço Compute, consulte Problemas Conhecidos do Serviço Compute.
Compute Cloud@Customer
Para problemas conhecidos do serviço Compute Cloud@Customer, consulte Questões Conhecidas.
Connector Hub
Para problemas conhecidos do Connector Hub, consulte Problemas Conhecidos do Connector Hub.
Console
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:
- Verifique se você está na versão mais recente do Firefox. Caso contrário, atualize para a versão mais recente.
- 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.
- 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
Console Dashboards
Para saber os problemas conhecidos com os Painéis da Console, consulte Problemas Conhecidos dos Painéis de Controle da Console.
Container Instances
Para problemas conhecidos do serviço Container Instances, consulte Problemas Conhecidos do Serviço Container Instances.
Container Registry
Para problemas conhecidos do serviço Container Registry, consulte Problemas conhecidos.
Data Catalog
Para problemas conhecidos do serviço Data Catalog, consulte Problemas Conhecidos.
Data Flow
Para problemas conhecidos do serviço Data Flow, consulte Problemas Conhecidos.
Data Integration
Para problemas conhecidos do serviço Data Integration, consulte Problemas Conhecidos.
Data Labeling
Para problemas conhecidos do serviço Data Labeling, consulte Problemas Conhecidos.
Data Science
Atualmente, não há problemas conhecidos com o serviço Data Science.
Serviço Data Transfer
Atualmente, não há problemas conhecidos no serviço Data Transfer.
Banco de Dados
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
--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 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
--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 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:
- 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.
- 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- 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.
- Defina o parâmetro
encrypt_new_tablespaces
como DDL, da seguinte forma:SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;
- 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;
- 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>;
- 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.
Definaencrypt_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.
- Verifique o tablespace TEMP padrão da seguinte forma:
- 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 comandodbaascli
: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 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:
- 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.
- 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- 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.
- Defina o parâmetro
encrypt_new_tablespaces
como DDL, da seguinte forma:SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;
- 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;
- 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>;
- 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.
Definaencrypt_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.
- Verifique o tablespace TEMP padrão da seguinte forma:
- 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 comandodbaascli
: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 a Visão Geral dos Gateways de Serviço chamada 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
Somente Sistemas de BD Bare Metal e de Máquina Virtual
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:
-
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
-
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:
-
Determine o ID do armazenamento de objetos Swift e o usuário que o banco de dados está usando para backups.
-
Execute o comando
dbcli list-databases
para determinar o ID do banco de dados. -
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
-
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
-
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
-
-
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.
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.
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:
Idioma | Versão | Documentação |
---|---|---|
Java | 1.2.49 | https://github.com/oracle/oci-java-sdk/releases |
Python | 2.0.6 | https://github.com/oracle/oci-python-sdk/releases |
Ruby | 2.3.9 | https://github.com/oracle/oci-ruby-sdk/releases |
Ir | 2.7.0 | https://github.com/oracle/oci-go-sdk/releases |
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:
-
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.
- 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.
- Extraia o conteúdo de opc_installer.zip para um diretório de destino, por exemplo, /home/opc.
- Em sua tenancy, crie um usuário temporário e conceda a ele privilégios para acessar o Object Storage da tenancy.
- Para este usuário temporário, crie um token de autenticação e anote a senha.
-
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.
-
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.
-
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).
-
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:
- Faça backup dos arquivos no diretório
/opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
. -
Execute estes dois comandos para substituir os arquivos
libopc.so
eopc_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
- Faça backup dos arquivos no diretório
-
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.
- (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:
-
Alterne para o usuário oracle no sistema operacional.
[opc@hostname ~]$ sudo su - oracle
-
Defina a variável de ambiente para fazer log-in na instância do banco de dados. Por exemplo:
[oracle@hostname ~]$ . oraenv ORACLE_SID = [oracle] ? orcl
-
Inicie o SQL*Plus.
[oracle@hostname ~]$ sqlplus / as sysdba
-
Altere os parâmetros 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
-
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.
Determinando a Versão de um Banco de Dados em um Home do Banco de Dados
Para determinar a versão de um banco de dados em um home de banco de dados, execute $ORACLE_HOME/OPatch/opatch lspatches
como usuário oracle ou dbcli list-dbhomes
como usuário root.
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:
-
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
-
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))
-
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
-
Liste o conteúdo do diretório e observe as permissões.
[oracle@dbsysHost xdb_wallet]$ ls -ltr total 8 -rw------- 1 oracle asmadmin 3881 Apr 6 16:32 ewallet.p12 -rw------- 1 oracle asmadmin 3926 Apr 6 16:32 cwallet.sso
-
Altere as permissões:
[oracle@dbsysHost xdb_wallet]$ chmod 640 /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet/*
-
Verifique se as permissões de leitura foram adicionadas.
[oracle@dbsysHost xdb_wallet]$ ls -ltr total 8 -rw-r----- 1 oracle asmadmin 3881 Apr 6 16:32 ewallet.p12 -rw-r----- 1 oracle asmadmin 3926 Apr 6 16:32 cwallet.sso
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ó
Somente Sistemas de BD Exadata
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.
Antes de usar a solução alternativa aplicável nesta seção, siga as etapas em Atualizando as Ferramentas em uma Instância do Exadata Cloud Service para garantir que a versão mais recente do
dbaastools_exa
esteja instalada no sistema.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.
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.
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.
-
Verifique se a versão do GI é 12.2.0.1 sem qualquer aplicação de pacote de patches:
[root@rmstest-udaau1 ~]# su - grid [grid@rmstest-udaau1 ~]$ . oraenv ORACLE_SID = [+ASM1] ? +ASM1 The Oracle base has been set to /u01/app/grid [grid@rmstest-udaau1 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory Oracle Interim Patch Installer version 12.2.0.1.6 Copyright (c) 2018, Oracle Corporation. All rights reserved. Oracle Home : /u01/app/12.2.0.1/grid Central Inventory : /u01/app/oraInventory from : /u01/app/12.2.0.1/grid/oraInst.loc OPatch version : 12.2.0.1.6 OUI version : 12.2.0.1.4 Log file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/opatch2018-01-15_22-11-10PM_1.log Lsinventory Output file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/lsinv/lsinventory2018-01-15_22-11-10PM.txt -------------------------------------------------------------------------------- Local Machine Information:: Hostname: rmstest-udaau1.exaagclient.sretest.oraclevcn.com ARU platform id: 226 ARU platform description:: Linux x86-64 Installed Top-level Products (1): Oracle Grid Infrastructure 12c 12.2.0.1.0 There are 1 products installed in this Oracle Home. There are no Interim patches installed in this Oracle Home. -------------------------------------------------------------------------------- OPatch succeeded.
-
Verifique o arquivo
/u01/app/grid/diag/crs/<hostname>/crs/trace/ocssd.trc
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
-
Você também pode usar o SQL*Plus para confirmar se os voting disks estão corrompidos:
-
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
-
Faça log-in no SQL*Plus como o usuário
SYSASM
.$ORACLE_HOME/bin/sqlplus / as sysasm
-
Execute as duas seguintes consultas:
SQL> select name, voting_file from v$asm_disk where VOTING_FILE='Y' and group_number !=0; SQL> select CC.name, count(*) from x$kfdat AA JOIN (select disk_number, name from v$asm_disk where VOTING_FILE='Y' and group_number !=0) CC ON CC.disk_number = AA.NUMBER_KFDAT where AA.FNUM_KFDAT= 1048572 group by CC.name;
Se o sistema estiver íntegro, os resultados deverão se parecer com o exemplo a seguir.
&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.
-
-
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.
-
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.
-
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.
-
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 serONLINE
e ovoting_file
NÃO deve serY
.
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
-
-
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:
- Faça log-on no nó como raiz.
-
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
-
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
- 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
Se você estiver dimensionando o armazenamento regular de dados ou o armazenamento da área de recuperação (RECO) de um valor inferior a 10.240 GB (10 TB) para um valor superior a 10.240 GB, execute o dimensionamento em duas operações. Primeiro, dimensione o sistema para 10.240 GB. Depois que essa primeira operação de dimensionamento estiver concluída e o sistema estiver no estado "disponível", execute uma segunda operação de dimensionamento, especificando o valor do armazenamento de destino acima de 10.240 GB. A tentativa de dimensionar de um valor inferior a 10.240 GB para um valor superior a 10.240 GB em uma única operação pode levar a uma falha da operação de dimensionamento. Para obter instruções sobre dimensionamento, consulte Para Ampliar o Armazenamento para um Sistema de BD de Máquina Virtual.
Detalhes: Ao dimensionar um sistema de Banco de Dados de máquina virtual para usar uma forma de sistema maior, a operação de dimensionamento falhará se um parâmetro DB_Cache_nX
não estiver definido como 0 (zero).
Solução alternativa: ao dimensionar um sistema de Banco de Dados virtual, certifique-se de que todos os parâmetros DB_Cache_nX
(por exemplo, DB_nK_CACHE_SIZE
) estejam definidos como 0.
Serviço Database Migration
Para problemas conhecidos com o serviço Database Migration, consulte Problemas Conhecidos do Database Migration.
OCI Database com PostgreSQL
Para problemas conhecidos do OCI Database com PostgreSQL, consulte OCI Database com Problemas Conhecidos PostgreSQL.
Ferramentas do Desenvolvedor
Para problemas conhecidos com as Ferramentas do Desenvolvedor, consulte Problemas Conhecidos das Ferramentas do Desenvolvedor.
DNS
Atualmente, não há problemas de DNS conhecidos.
Noções Básicas do Documento
Para problemas conhecidos do serviço Document Understanding, consulte Problemas Conhecidos.
Email Delivery
Para saber os problemas conhecidos, consulte Problemas Conhecidos do Email Delivery.
Events
Atualmente, não há problemas conhecidos no serviço Events.
File Storage
Para problemas conhecidos do serviço File Storage, consulte Problemas Conhecidos do Serviço File Storage.
Fleet Application Management
Para saber os problemas conhecidos do Fleet Application Management, consulte Problemas Conhecidos do Fleet Application Management.
Full Stack Disaster Recovery
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.
Solução alternativa: Para volumes de armazenamento em blocos que têm o desempenho ajustado automaticamente ativado, você deverá reabilitar essas definições depois que o Full Stack DR fizer a transição desses volumes de armazenamento em blocos 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 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.
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 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.
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 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 DR de Pilha Completa 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.
/bin/sh /path/to/myscript.sh arg1 arg2
em vez de sh myscript.sh arg1 arg2
Detalhes: Durante as operações de DR, o DR de Pilha Completa tentará designar novamente 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 redesignado, esses nós do cluster serão desconectados do cluster OCFS2 depois que os nós forem iniciados na região stand-by.
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: Após o DR de Pilha Completa realocar 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.
sleep
no script wrapper, conforme mostrado aqui: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.
Functions
Para obter problemas conhecidos do serviço Functions, consulte Problemas Conhecidos do Serviço OCI Functions.
Globally Distributed Autonomous Database
Para saber os problemas conhecidos do Globally Distributed Autonomous Database, consulte Problemas Conhecidos.
GoldenGate
Health Checks
Para problemas conhecidos do serviço Health Checks, consulte Problemas Conhecidos do Serviço Health Checks.
IAM
Para o serviço IAM com problemas do Domínio de Identidades, consulte Problemas Conhecidos do Serviço IAM com Domínios de Identidades.
Para o serviço IAM com problemas do Domínio de Identidades, consulte Problemas Conhecidos do Serviço IAM sem Domínios de Identidades.
Integração
Para problemas conhecidos do serviço Integration Generation, consulte Problemas Conhecidos.
Para problemas conhecidos do serviço Integration 3, consulte Problemas Conhecidos.
Serviço Java Management
Para obter detalhes sobre problemas conhecidos no serviço Java Management, consulte Problemas Conhecidos.
Mecanismo Kubernetes
Para saber os problemas conhecidos do Kubernetes Engine, consulte Problemas Conhecidos do Kubernetes Engine (OKE).
Idioma
Atualmente, não há problemas conhecidos com o serviço Language.
Balanceador de Carga
Para saber os problemas conhecidos do serviço Load Balancer, consulte Problemas Conhecidos.
Log
Para problemas conhecidos do serviço Logging, consulte Problemas Conhecidos do Serviço Logging.
Logging Analytics
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 Agente de Gerenciamento, o que pode levar a uma coleta lenta de logs, afetar outras funcionalidades do Agente de Gerenciamento e também diminuir a velocidade da máquina host.
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, de modo que o Agente de Gerenciamento 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.
- Aumente o tamanho de heap do Management Agent. Para diretórios com um grande número de arquivos, o tamanho do heap necessário aumenta com o número de arquivos. Consulte documentação do Management Agent.
- Certifique-se de que haja espaço em disco e inodes suficientes disponíveis para tratar o grande número de arquivos de estado que o Agente de Gerenciamento pode ter que manter. Isso depende do tipo de origem de log e do parser usado. Se o analisador usar a função Header-Detail, o agente criará e armazenará o cabeçalho em um arquivo de cache, desde que o arquivo de log original exista.
- Certifique-se de que a definição do sistema operacional para o número de arquivos abertos possa suportar o Agente de Gerenciamento lendo a pasta grande e o número potencialmente grande de arquivos de estado.
Link direto para este problema: Tratamento especial ao monitorar logs em pastas grandes
Serviço Managed Access
Para saber os problemas conhecidos do serviço Managed Access, consulte Problemas Conhecidos.
Managed Cloud Self Service Platform
Para saber os problemas conhecidos do Managed Cloud Self Service Platform, consulte Problemas Conhecidos.
Serviço Management Agent
No momento, não há problemas conhecidos do serviço Management Agent.
Marketplace
Para saber quais são os problemas conhecidos do Marketplace, consulte Problemas conhecidos.
Media Services
Para saber os problemas conhecidos do serviço Media Flow, consulte Problemas Conhecidos.
Para saber os problemas conhecidos do serviço Media Streams, consulte Problemas Conhecidos.
Monitoring
Para problemas conhecidos do serviço Monitoring, consulte Problemas Conhecidos do Serviço Monitoring.
Network Load Balancer
Para saber os problemas conhecidos do serviço Network Load Balancer, consulte Problemas Conhecidos.
Networking
Para saber quais são os problemas conhecidos do Networking, consulte Problemas Conhecidos do Networking.
Notifications
Para problemas conhecidos do serviço Notifications, consulte Problemas Conhecidos do Serviço Notifications.
Object Storage
Para problemas conhecidos do serviço Object Storage, consulte Problemas conhecidos do serviço Object Storage.
OCI Control Center
Para obter problemas conhecidos do OCI Control Center, consulte Problemas Conhecidos.
Ops Insights
Atualmente, não há problemas conhecidos no Ops Insights.
Oracle Cloud Marketplace
Para saber quais são os problemas conhecidos do Marketplace, consulte Problemas Conhecidos.
OS Management
Para obter detalhes sobre problemas conhecidos no serviço OS Management, consulte Problemas Conhecidos do Serviço OS Management.
OS Management Hub
Para problemas conhecidos do OS Management Hub, consulte Problemas Conhecidos.
Serviço Partner Portal
Para saber os problemas conhecidos do serviço Partner Portal, consulte Problemas Conhecidos.
Serviço Process Automation
Para obter detalhes sobre problemas conhecidos no serviço Process Automation, consulte Problemas Conhecidos.
Editor
Para saber quais são os problemas conhecidos do Marketplace, consulte Problemas Conhecidos.
Fila
Atualmente, o serviço Queue não tem problemas conhecidos.
Resource Manager
Para problemas conhecidos do Resource Manager, consulte Problemas Conhecidos do Resource Manager.
Roving Edge Infrastructure
Atualmente, não há problemas conhecidos no serviço Roving Edge Infrastructure.
Desktops Seguros
Para saber os problemas conhecidos do Secure Desktops, consulte Problemas Conhecidos.
Pesquisar
Para problemas conhecidos do serviço Search, consulte Problemas Conhecidos.
Search com OpenSearch
Para problemas conhecidos do Search with OpenSearch, consulte Problemas Conhecidos.
Security Zones
Para saber os problemas conhecidos do serviço Bastion, consulte Problemas Conhecidos.
Service Mesh
Para saber os problemas conhecidos do Service Mash, consulte Problemas Conhecidos.
Service Catalog
Para saber os problemas conhecidos do Service Catalog, consulte Problemas Conhecidos.
Fala
Atualmente, não há problemas conhecidos com o serviço Speech.
Fluxo
Para problemas conhecidos do serviço Streaming, consulte Problemas Conhecidos do Serviço Streaming.
Tagging
Para saber os problemas conhecidos do serviço Tagging, consulte Problemas Conhecidos do Tagging
Gerenciamento de Tenancies
Para problemas conhecidos do Gerenciamento de Tenancy, consulte Problemas Conhecidos.
Serviço Threat Intelligence
Para saber os problemas conhecidos do serviço Threat Intelligence, consulte Problemas Conhecidos.
Traffic Management Steering Policies
Atualmente, não existem problemas conhecidos do Traffic Management.
Vault
Atualmente, não há problemas conhecidos do serviço Vault.
Vision
Para saber os problemas conhecidos do serviço Vision, consulte Problemas Conhecidos.
Visual Builder
Para problemas conhecidos com o Visual Builder, consulte Problemas Conhecidos do Oracle Visual Builder.
Visual Builder Studio
Para problemas conhecidos do Visual Builder Studio, consulte Problemas Conhecidos do Oracle Visual Builder Studio.
Firewall de Aplicativo Web (WAF)
Para problemas conhecidos do Web Application Firewall, consulte Web Application Firewall-Problemas Conhecidos.
Serviço Web Application Management
Para saber os problemas conhecidos do serviço Web Application Acceleration, consulte Problemas Conhecidos.