Pular para o conteúdo principal

Mover tablespace Oracle ASM para diskgroup diferente

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 indisponibilidade seria menor.

 

RUN{
ALLOCATE CHANNEL disk1 DEVICE TYPE DISK FORMAT '+OCRVOTE/copia.dbf';
RECOVER COPY OF DATAFILE 5 WITH TAG 'MOVE_DISKGROUP';
BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'MOVE_DISKGROUP' DATAFILE 5;
}
allocated channel: disk1
channel disk1: SID=74 device type=DISK

Starting recover at 09-SEP-20
no copy of datafile 5 found to recover
Finished recover at 09-SEP-20

Starting backup at 09-SEP-20
no parent backup or copy of datafile 5 found

channel disk1: starting datafile copy
input datafile file number=00005 name=+OCRVOTE/uow/datafile/tbs_novo.309.1050678701
output file name=+OCRVOTE/copia.dbf tag=MOVE_DISKGROUP RECID=62 STAMP=1050678919
channel disk1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 09-SEP-20
released channel: disk1

Explicação do bloco de comandos:

 1 - Aloca um canal do tipo disco e indica para qual diskgroup no ASM vou jogar minha cópia. Aqui como estamos usando backup as copy, não conseguimos fazer em paralelo.

2- Faço o recover da minha imagem. Caso eu tenha algum backup incremental feito, o RMAN vai aplicar as alterações na cópia.

3 - Realizar o backup incremental do datafile 5. Caso não exista um backup full, o RMAN vai irá iniciar um.


Abaixo podemos ver que temos umas cópia do datafile 5 no caminho +OCRVOTE/copia.dbf.

RMAN> list copy of datafile 5;

List of Datafile Copies
=======================

Key     File S Completion Time Ckp SCN    Ckp Time
------- ---- - --------------- ---------- ---------------
62      5    A 09-SEP-20       784340     09-SEP-20
        Name: +OCRVOTE/copia.dbf
        Tag: MOVE_DISKGROUP


Bom, com a cópia já feita e atualizada, agora precisamos deixar o datafile indisponível antes de executar o comando switch. Esse comando vai realizar a troca do arquivo de cópia com o arquivo original.


RUN
{
SQL "ALTER TABLESPACE TBS_NOVO OFFLINE IMMEDIATE";
SWITCH DATAFILE '+OCRVOTE/uow/datafile/tbs_novo.309.1050678701' TO DATAFILECOPY '+OCRVOTE/copia.dbf';
RECOVER TABLESPACE TBS_NOVO;
SQL "ALTER TABLESPACE TBS_NOVO ONLINE";
}

sql statement: ALTER TABLESPACE TBS_NOVO OFFLINE IMMEDIATE

datafile 5 switched to datafile copy
input datafile copy RECID=62 STAMP=1050678919 file name=+OCRVOTE/copia.dbf

Starting recover at 09-SEP-20
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=74 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=97 device type=DISK

starting media recovery
media recovery complete, elapsed time: 00:00:00

Finished recover at 09-SEP-20

sql statement: ALTER TABLESPACE TBS_NOVO ONLINE

Explicação do bloco de comandos:


1 - Deixa o tablespace offline. No meu caso, se tratava de um tablespace bigfile, então só havia uma datafile nesse tablespace.


2 - Realizar o troca entre os arquivos origem e cópia. Aqui você indica os arquivos origem e cópia.


3 - Pega as últimas alterações feitas na origem e aplica no arquivo de cópia


4 - Coloca o tablespace online.


Pronto, seu datafile está no novo diskgroup. 

RMAN> report schema;

Report of database schema for database with db_unique_name UOW

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    700      SYSTEM               ***     +OCRVOTE/uow/datafile/system.272.1050582827
2    600      SYSAUX               ***     +OCRVOTE/uow/datafile/sysaux.273.1050582827
3    760      UNDOTBS1             ***     +OCRVOTE/uow/datafile/undotbs1.274.1050582829
4    5        USERS                        ***     +OCRVOTE/uow/datafile/users.276.1050582833
5    50       TBS_NOVO             ***     +OCRVOTE/copia.dbf

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    59       TEMP                 32767       +OCRVOTE/uow/tempfile/temp.275.1050582829



Comentários

Postagens mais visitadas deste blog

Configurando a política de retenção de backups no RMAN

                       Configurando a politica de reten çã o de backups no RMAN        O objetivo deste post é explicar como podemos configurar a reten çã o de backups na poderosa ferramenta de backup do bando de dados Oracle RMAN. Podemos configurar nossa pol í tica tendo por base dois tipos: janela de recupera çã o (recovery window) ou redundãncia (redundancy). Abaixo iremos abordar os dois tipos.       Para identificar qual dos dois tipos o RMAN está usando, use: RMAN> show retention policy; Política baseada em redundância CONFIGURE RETENTION POLICY TO REDUNDANCY 1; Política baseada em janela de recuperação CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS; ·        Política baseada em redund â ncia ( REDUNDANCY )       De uma maneira bem simples e objetiva, o par â metro REDUNDANCY especifica quantos backups full ou incremental level 0 de cada datafile o RMAN vai manter, os demais são considerados obsoletos. Veja o exemplo abaixo

Permissões necessárias para criar triggers no Oracle

Há pouco tempo passei por um problema durante a criação de uma trigger de LOGON na versão 12c do banco de dados Oracle. Estava com alguns problemas em uma aplicação que tinha uma trigger de Logon. A trigger em si era bem simples, vou por o código mais abaixo, o problema é que ela estava criada dentro do usuário SYSTEM. Provavelmente foi a maneira mais fácil e preguiçosa de criar o objeto, uma vez que o SYSTEM já possui todas as permissões necessárias para criação. Porém isso não uma boa prática. Então resolvi tirar do SYSTEM e jogar para o usuário dono dos objetos da aplicação. Quando fui tentar criar o objeto no SCHEMA dono dos objetos da aplicação, recebi um erro com falta de permissões: ORA-01031: insufficient privileges . O erro ocorreu porque estava esquecendo de conceder a role ADMINISTER DATABASE TRIGGER para o usuário. Em resumo, as permissões necessárias para criação de uma trigger: CREATE TRIGGER - para criar uma trigger no seu próprio esquema (SCHEMA) CREATE AN

ORA-01623 ORA-00312 - Removendo redo logs

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