Então...

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