Então...

 A partir da versão 12.1 tem um comando bem mais eficiente para substituir os discos que estão com algum problema dentro dos diskgroups ASM é replace_disk_clause Mas para minha situação ele não funcionou. Pelos testes e leitura na documentação, ele só vai funcionar se o seu disco antigo estiver defeituoso.  No meu caso, o disco não estava com problemas eu só precisava substituir. Então vejam o erro que me retornou: SQL> alter diskgroup TESTE REPLACE DISK TESTE01 with '/dev/oracleasm/disks/TESTE05' force; alter diskgroup TESTE REPLACE DISK TESTE01 with '/dev/oracleasm/disks/TESTE05' force * ERROR at line 1: ORA-15032: not all alterations performed ORA-15145: ASM disk 'TESTE01' is online and cannot be replaced. Repare que tentei até usar o force , mas mesmo assim ele retornou o erro pois o disco que estava tentando substituir , TESTE01, não estava com problema. Então a solução foi o usar o comando anterior a versão 12.1, usar ADD e DROP na me

Neste post vou passar uma simples falha de segurança que ocorre quando estamos conectando em banco de dados remoto e não temos a conexão criptografada. Irei utilizar o comando do linux tcpdump para escutar toda conexão de rede na minha máquina de banco de dados na porta 1521. tcpdump -As 1518 -i any port 1521 Fiz os teste em duas versões do banco de dados Oracle 11g e 18c. Podemos ver que a falha de segurança ocorre nas duas versões. Versão 11g   [oracle@myhost]$ sqlplus system@bd_teste SQL*Plus: Release 11.2.0.4.0 Production on Mon Nov 23 15:03:01 2020 Copyright (c) 1982, 2013, Oracle.  All rights reserved. Enter password: Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options SQL> create user user_teste identified by "minhasenha"; User created. Analisando a saída do tcpdump podemos ver em texto claro a nossa senha.   15:13:20.64

Aqui passo um breve resumo dos comandos necessários para gerência do TFA. Verificar Configurações:   tfactl print repository    O comando acima te passa um resumo, caso precise da configuração completa use: tfactl print config Gerência: tfactl start tfactl stop tfactl status tfactl disable - Desabilitar início automático tfactl enable - Habilita início automático Expurgo repositório O Oracle TFA monitor expurga automaticamente do repositório quando o espaço livre está menor que 1Gb. O processo de expurgo começa com as coletas de maior tamanho para as de menor tamanho, até que o repositório tenho espaço livre suficiente. Oracle TFA apaga automaticamente por padrão somente as coletas mais antigas que o parâmetro minagetopurge . Por padrão é 12h Para mudar o tempo de expurgo tfactl set minagetopurge=48 Habilitar expurgo automático tfactl set autopurge=ON Mudar o local do repositório  tfactl set repositorydir=/tmp/ Mudar o tamanho do repositório tfactl set reposizeMB=12480 Expurgo manual

Após realizar um restore de um ambiente de Oracle RAC para um single instance usando snapshot de storage, tentei recriar os redo logs recebi o seguinte erro durante a exclusão de um grupo de discos. SQL> alter database drop logfile group 2; ORA-01623: o log 2 é o log atual para a instância UOW (thread 1) - não é possível eliminar ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.1638.1051804433' ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.981.1051804433' O erro quer dizer que o grupo de redo pertence a outra thread. Quer dizer que ele pertence a outra instância do ambiente RAC. Como no meu caso não precisarei mais dela, basta usar o comando: SAL> alter database disable thread 2; Database altered.   Usei o SQL abaixo para gerar os comandos para excluir os redo logs SQL> select distinct 'alter database drop logfile group '||(group#)||';' from v$log where thread#=2; 'ALTERDATABASEDROPLOGFILEGROUP'||(G

Precisei movimentar um tablespace de um diskgroup com redundância no ASM EXTERNAL para um outro com redundância NORMAL. Abaixo vou descrever os passos que realizei no meu ambiente de homologação para testar. Bom, no meu caso o tablespace era bigfile e como tinha um tamanho de 34Tb,  então deixar o arquivo offline e então realizar o backup não era uma opção por conta do tempo de parada. Então fui na estratégia do backup as COPY com o RMAN e todos os dias ia fazendo o recover do arquivo de cópia. A vantagem de usar esse método é que posso criar um cópia do datafile (backup full) e ir adicionando as mudanças que foram feitas no arquivo original na minha cópia com o banco de dados online. Utilizei o bloco de comando no RMAN abaixo para a criação do arquivo de cópia, recover e backup incremental.  Executei esse bloco de comando todos os dias para deixar meu arquivo de cópia o mais próximo possível do arquivo original e no dia em que fosse realizar o procedimento em produção, o tempo de indi

Durante o upgrade da versão 18c para 19c GI, quando estava executando o script rootupgrade.sh recebi um erro no passo 8 2020/07/22 08:47:13 CLSRSC-595: Executing upgrade step 1 of 18: 'UpgradeTFA'. 2020/07/22 08:47:13 CLSRSC-4015: Performing install or upgrade action for Oracle Trace File Analyzer (TFA) Collector. 2020/07/22 08:47:13 CLSRSC-595: Executing upgrade step 2 of 18: 'ValidateEnv'. 2020/07/22 08:47:14 CLSRSC-595: Executing upgrade step 3 of 18: 'GetOldConfig'. 2020/07/22 08:47:14 CLSRSC-464: Starting retrieval of the cluster configuration data 2020/07/22 08:47:19 CLSRSC-692: Checking whether CRS entities are ready for upgrade. This operation may take a few minutes. 2020/07/22 08:49:03 CLSRSC-4003: Successfully patched Oracle Trace File Analyzer (TFA) Collector. 2020/07/22 08:49:26 CLSRSC-693: CRS entities validation completed successfully. 2020/07/22 08:49:31 CLSRSC-465: Retrieval of the cluster configuration data has successfully completed. 2020/07/22