ORA-00354: corrupt redo log block header

Olá pessoal, tudo bom ?

Hoje vou postar uma situação que aconteceu durante um atendimento a um cliente durante uma restauração do backup RMAN, isso mesmo, não basta ter backup, o que vale mesmo é um restore válido como dizia meu amigo Bruno Murassaki.

Logo após a resutaração, banco de dados quase pronto para ser liberado para o cliente fui verificar o alert.log como parte da rotina. E para minha surpresa, várias entradas apontando para possiveis problemas de archivamento.

Errors in file /oracle/app/oracle/diag/rdbms/target/trace/target_arc2_7645.trc;
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 939 change 83047523485 time 09/12/2012 22:33:54
ORA-00312: online log 15 thread 1: ‘+DATA/target/onlinelog/group_15.278.793109619’
ARC2: All Archive destinations made inactive due to error 354
ARC2: Clossing local archive destination LOG_ARCHIVE_DEST1: ‘/oracle/app/oracle/product/11gR2/dbs/arch1_451_793109613.dbf”  (error 354)  (target)
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance test1 – Archival Error

A partir do alert.log, temos que o o grupo de redo log 15 estava marcado como corrompido. Proximo passo foi verificar o status do grupo de redo log 15 na v$log, e lá encontramos o grupo como INACTIVE e também nao tinha sido realizado o ARCHIVE dele.

GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS
———- ———- ———- ———- ———- ———- — ————–
5          1      44342   26214400        512          1 NO  CURRENT
6          1      44343   26214400        512          1 YES INACTIVE
7          1      44344   26214400        512          1 YES INACTIVE
8          1      44345   26214400        512          1 YES INACTIVE
9          1      44346   26214400        512          1 YES INACTIVE
10          1      44347   26214400        512          1 YES INACTIVE
11          1      44348   26214400        512          1 YES INACTIVE
12          1      44349   26214400        512          1 YES INACTIVE
13          1      44339   26214400        512          1 YES INACTIVE
14          1      44340   26214400        512          1 YES INACTIVE
        15          1      44341   26214400        512          1 NO  INACTIVE      

Resolução:

SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 15;

Database altered.

Neste mesmo momento no alert.log aparecia

ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 15
WARNING! CLEARING REDO LOG WHICH HAS NOT BEEN ARCHIVED. BACKUPS TAKEN
    BEFORE 09/12/2012 22:33:58 (CHANGE 83047525487) CANNOT BE USED FOR RECOVERY.
Clearing online log 15 of thread 1 sequence number 451
Completed: ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 15

Com isso,  banco de dados funcinando normalmente e sem entradas no alert.log.

É importante lembrar também que assim como mostrado no alert.log, os backups realizados antes da alteração 83047525487  nao poderão ser usados para RECOVERY, ou seja, é muito importante que um backup FULL seja realizado imediatante após esta operação.

Um grande abraço e até lá !

Impedir usuario realizar IMPORT / EXPORT dentro do proprio esquema

Olá pessoal,
Hoje vou compartilhar com voces uma dica bem interessante para impedir que um usuario comum consiga importar ou exportar objetvos dentro do proprio esquema.

No Oracle, para um usuario realizar uma importacao ou exportacao de/para outro SCHEMA precisamos garantir que ele tenha as permissoes de EXP_FULL_DATABASE ou IMP_FULL_DATABASE. Mas e quando essa importacao ou exportacao é para o proprio SCHEMA , como podemos impedir ?

Para contornar essa situação, podemos usar um simples e elegante comando:

SQL> revoke select on EXU8FUL from public;

Revoke succeeded

E o resultado ao tentar fazer um EXP do usuario:

 

c:\>exp IMPORTA/IMPORTA@rafabd file=importa.dmp

Export: Release 10.2.0.3.0 – Production on Qui Set 13 02:11:13 2012

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

EXP-00008: Erro Oracle: 942 encontrado
ORA-00942: a tabela ou view nÒo existe
EXP-00024: Views de exportaþÒo nÒo instaladas; por favor notifique o DBA
EXP-00000: ExportaþÒo encerrada sem Ûxito

Pronto, a partir de agora os usaurio comuns não poderão mais realizar IMP ou EXP dentro do seu proprio SCHEMA. Lembrando que os usuarios SYSTEM e SYS continuarão funcionando.

 

Espero que a dica tenha ajudado, um grande abraco e até a proxima.

 

TNS-12541: TNS:não há listener TNS-12560: TNS:erro de adaptador de protocolo

Fala moçada, hoje vou postar um incidente que aconteceu durante um atendimento a um cliente com Oracle Database 10g esta semana.

Logo pela manha o cliente me ligou informando que o banco de dados não estava diponivel. Mão a massa, primera checagem sempre o bom e velho alert log. Até ai tudo indo muito bem, nenhum problema, nada encontrado no aler.og, entao fiz a checagem dos servicos oracle que estavam rodando na máquina e lá estavam eles, todos rodando. Status do banco verificado: OPEN …ótimo.

Segundo passo, checar o listener. E logo de cara  a surpresa:

 

[oracle@base ~]$ lsnrctl status

LSNRCTL for Linux: Version 9.2.0.6.0 – Production on 10-SET-2012 08:38:57

Copyright (c) 1991, 2002, Oracle Corporation.  All rights reserved.

Conectando a (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC)))
TNS-12541: TNS:não há listener
TNS-12560: TNS:erro de adaptador de protocolo
TNS-00511: Não há listener
Linux Error: 111: Connection refused
Conectando a (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=cliente)(PORT=1521)))
TNS-12541: TNS:não há listener
TNS-12560: TNS:erro de adaptador de protocolo
TNS-00511: Não há listener
Linux Error: 111: Connection refused

Até ai tudo bem, vamos tentar subir o listener:
[oracle@base ~]$ lsnrctl start

LSNRCTL for Linux: Version 9.2.0.6.0 – Production on 10-SET-2012 08:37:51

Copyright (c) 1991, 2002, Oracle Corporation.  All rights reserved.

Iniciando /disk0/oracle/product/9.2.0/orcl/bin/tnslsnr: aguarde…

TNS-12547: TNS:contato perdido
TNS-12560: TNS:erro de adaptador de protocolo
TNS-00517: Contato perdido
Linux Error: 32: Broken pipe

 

E ai a grande surpresa. A primeira ação após este erro foi consultar o Metalink e verificar quais as melhores praticas para solucionar este caso mas a tentativa foi em vão, muitas sugestoes para aplicar patch e procedimentos que num primeiro momento nao tinham muito a ver com meu problema. Depois de muito tempo analisando toda essa documentacao uma luz no fim do túnel. Um artigo bem simples  (nao lembro agora qual, mas vou procurar para colocar como referencia) onde o DBA por um problema semelhante.

Solução:

Verificar o tamanho do arquivo de log do LISTENER.LOG ($ORACLE_HOME/network/admin). Aos amigos SYSADMIN, algo muito comum acontece no SQUID quando um arquivo de log atinge 2 GB e o proxy cai. NEste caso, a correcao foi parecida.

[oracle@base log]$ ls -lh
total 2,1G
-rw-rw-r–  1 oracle oinstall  813 Jul 28  2009 dbsnmp.nohup
-rw-rw-r–  1 oracle oinstall 2,0G Set 10 01:44 listener.log
-rw-r–r–  1 oracle oinstall 3,4M Ago 13 17:15 sqlnet.log

Olha o danado lá. Bom, o passo agora é recriar o arquivo fazendo um backup do antigo:

[oracle@base log]$ mv listener.log listener.log.old
[oracle@base log]$ touch listener.log
[oracle@base log]$ chown oracle.oinstall listener.log   (atenção no grupo que o usuario oracle faz parte, no meu caso era oinstall)

Verificando se tudo esta ok, arquivo novo criado com sucesso:

[oracle@base log]$ ls -lh
total 2,1G
-rw-rw-r–  1 oracle oinstall  813 Jul 28  2009 dbsnmp.nohup
-rw-r–r–  1 oracle oinstall    0 Set 10 08:40 listener.log
-rw-rw-r–  1 oracle oinstall 2,0G Set 10 01:44 listener.log.old
-rw-r–r–  1 oracle oinstall 3,4M Ago 13 17:15 sqlnet.log

E o grande final para nossa alegria:
[oracle@base log]$ lsnrctl start

LSNRCTL for Linux: Version 9.2.0.6.0 – Production on 10-SET-2012 08:40:48

Copyright (c) 1991, 2002, Oracle Corporation.  All rights reserved.

Iniciando /disk0/oracle/product/9.2.0/orcl/bin/tnslsnr: aguarde…

TNSLSNR for Linux: Version 9.2.0.6.0 – Production
O arquivo de parâmetros do sistema é /disk0/oracle/product/9.2.0/orcl/network/admin/listener.ora
Mensagem de log gravada para /disk0/oracle/product/9.2.0/orcl/network/log/listener.log
Atendendo em: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
Atendendo em: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=cliente.localdomain)(PORT=1521)))

Conectando a (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC)))
STATUS do LISTENER
————————
Apelido                   LISTENER
Versão                   TNSLSNR for Linux: Version 9.2.0.6.0 – Production
Data Inicial                10-SET-2012 08:40:48
Tempo de funcionamento                    0 dias 0 hr. 0 min. 0 seg
Nível de Análise               off
Segurança                  OFF
SNMP                      OFF
Arquivo de Parâmetros do Listener   /disk0/oracle/product/9.2.0/orcl/network/admin/listener.ora
Arquivo de Log do Listener         /disk0/oracle/product/9.2.0/orcl/network/log/listener.log
Resumo de Atendimento…
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=cliente.localdomain)(PORT=1521)))
Resumo de Serviços…
O serviço “PLSExtProc” tem 1 instância(s).
Instância “PLSExtProc”, status UNKNOWN, tem 1 handler(s) para este serviço…
O serviço “orcl” tem 1 instância(s).
Instância “orcl”, status UNKNOWN, tem 1 handler(s) para este serviço…
O comando foi executado com êxito

Bom pessoal , é isso ai…espero que esse caso possa ajudar em problema semelhantes. Um grande abraço e até a proxima !