segunda-feira, 17 de setembro de 2012

[ORACLE] Criando um catalogo de recuperação para RMAN


Passo 1:
Crie uma instância para o RMAN.

Passo 2:
Crie a tablespace que irá conter o catálogo:

create tablespace CLOG datafile 'C:\Oracle\RMAN\TBS\CLOG01.DBF' size 200M;

Crie um usuário para o RMAN:

create user userrman identified by userrman default tablespace CLOG temporary tablespace TEMP;

E conceda os privilégios necessários:

grant connect, resource, recovery_catalog_owner to userrman;

Passo 3:
Conecte-se ao RMAN:

C:\>rman
connect catalog userrman/userrman

Passo 4:
Crie o catalogo:

create catalog tablespace CLOG;

E saia do RMAN.

Passo 5:
Após a criação do catálogo, é necessário registrar a instância no catálogo de recuperação:

C:\>set ORACLE_SID=ORCL
C:\>rman target / catalog userrman/userrman@RMAN

RMAN>register database;
RMAN> exit

Pronto, agora você tem um catálogo de recuperação para o RMAN!

quinta-feira, 13 de setembro de 2012

[ORACLE] Perda de REDOLOGS


Antes de iniciar o procedimento, vai uma dica:
Sempre mantenha seus redologs multiplexados (recomenda-se dois membros para cada grupo), para evitar que o banco de dados pare, além de também evitar perda de dados, caso ocorra a perda de um grupo/membro de redolog em estado current.

Perda de somente um membro de um grupo de redolog:

Se os membros dos grupos de redolog estiverem multiplexados é muito simples corrigir este problema:

Como o banco de dados não para quando ocorre a perda de somente um membro de um grupo de redolog deve se prestar atenção nas mensagens logadas no log de alert e vindas do GRID CONTROL.

Exemplo de mensagem logada no log de alert:

Errors in file C:\APP\ORA\diag\rdbms\orcl\orcl\trace\orcl_lgwr_4560.trc:
ORA-00313: a abertura falhou para os membros do grupo 3 de log do thread 1
ORA-00312: thread 3 do log 1 on-line: 'C:\APP\ORA\ORADATA\ORCL\REDO03.LOG'
ORA-27041: n?o e possivel abrir arquivo
OSD-04002: não é possível abrir arquivo
O/S-Error: (OS 2) O sistema não pode encontrar o arquivo especificado.
Errors in file C:\APP\ORA\diag\rdbms\orcl\orcl\trace\orcl_lgwr_4560.trc:
ORA-00321: log 3 do thread 1; n?o e possivel atualizar o cabecalho do arquivo de log
ORA-00312: thread 3 do log 1 on-line: 'C:\APP\ORA\ORADATA\ORCL\REDO03.LOG'

Conecte-se a instância Oracle como usuário SYS:

C:\>sqlplus / as sysdba

E remova o membro de redolog perdido do dicionário de dados:

ALTER DATABASE
  DROP LOGFILE MEMBER 'C:\app\ORA\oradata\ORCL\REDO03.log';

Após isso, o criamos novamente:

ALTER DATABASE
  ADD LOGFILE MEMBER 'C:\app\ORA\oradata\ORCL\REDO03.log'
      TO GROUP 3;

Caso o membro de redolog perdido seja do grupo no estado current, deve-se forçar a troca de grupo de redolog, antes de se executar os passos acima:

SQL>alter system switch logfile;

Perda de todos os membros de um grupo de REDOLOG:

Caso você perca todos os membros de um grupo de redolog (que não esteja no estado CURRENT), conforme já informado, a instância irá parar.

Neste caso, inicie a instância em modo MOUNT;

SQL>startup mount;

E remova do dicionário de dados o grupo de redolog perdido:

ALTER DATABASE DROP LOGFILE GROUP 2;

Após isso, crie-o novamente:

ALTER DATABASE
  ADD LOGFILE GROUP 2 ('C:\APP\ORA\ORADATA\ORCL\REDO02.LOG', 'C:\APP\ORA\ORADATA\ORCL\REDO02_B.LOG')
      SIZE 50M;

E abra a instância:

SQL>alter database open;


Perda de todos os membros de um grupo de REDOLOG no estado CURRENT:

Neste caso, haverá a perda dos dados que estavam neste grupo de redolog, pois eles não foram para disco, nem para a área de archive (por estarem no estado CURRENT).

Inicie a instância no modo MOUNT:

SQL>startup mount;

Será necessária uma recuperação incompleta do banco de dados para conseguir abri-lo novamente. Conecte-se ao RMAN:

C:\>rman target /

E inicie a restauração:

RMAN> RESTORE DATABASE UNTIL TIME '08-09-2012:17:00:00';

*Sempre mantenha em dia seus backups, pois caso ocorra uma situação desta, podemos diminuir a quantidade de dados perdidos.

E depois a recuperação:

RMAN> RECOVER DATABASE UNTIL TIME '08-09-2012:17:00:00';

Repare que ocorrerá erros ao final da recuperação justamente pela perda do grupo de redolog, ignore estes erros e ao término da recuperação, inicie a instância utilizando a opção RESETLOGS:

SQL>alter database open resetlogs;









segunda-feira, 10 de setembro de 2012

[MYSQL] Mover InnoDB

Passo 1:
Pare o MySQL Server:

# /etc/init.d/mysqld stop

Passo 2:
Através de comandos do sistema operacional, mova o arquivo ibdata1 para outro diretório ou partição (/ibdata).

Passo 3:
Edite o arquivo my.cnf e adicione a seguinte linha:
innodb_data_home_dir=/ibdata

Passo 4:
Inicie o MySQL Server:

# /etc/init.d/mysqld start

sexta-feira, 7 de setembro de 2012

[ORACLE] Configurando FRA

A Flash Recover Area (FRA) é muito simples de ser configurada, mas antes, confirme se sua instância atende os requisitos abaixo:

  • A instância deve estar em modo archivelog;
  • Deve-se ter uma área para recuperação habilitada;
  • Se você usar RAC, a área de recuperação deve ser armazenada no sistema de arquivos do cluster ou no ASM.
Agora vamos aos passos para a configuração do FRA!
Passo 1:
Dê um shutdown limpo na instância:

SQL>shutdown immediate;

E inicie a instância em modo MOUNT:

SQL>startup mount;

Passo 2:
Altere o parâmetro DB_FLASHBACK_RETENTION_TARGET para o tempo de retenção que você deseja ter na área de recuperação. O valor padrão é 1440 minutos.

SQL>alter system set DB_FLASHBACK_RETENTION_TARGET=2880 scope=both;

Passo 3:
Indicamos o tamanho que nossa área de recuperação pode ter:

SQL>alter system set DB_RECOVERY_FILE_DEST_SIZE=4G scope=both;

Passo 4:
Neste passo definimos o diretório do sistema operacional utilizado pelo FRA, devemos antes criar o diretório no sistema operacional:

SQL>alter system set DB_RECOVERY_FILE_DEST='/u00/FRA' scope=both;

Passo 5:
Este passo é opcional, caso você queira trabalhar com o mecanismos de Flashback, você pode habilita-lo neste momento:

SQL> alter database flashback on;

Passo 6:
Abra o banco de dados:

SQL>alter database open;