Alessandro Guimarães – Oracle Blog

August 30, 2009

Log Miner | Muito além do FlashBack

Filed under: Uncategorized — agleite @ 5:20 pm

O Oracle LogMiner é uma ferramenta que permite consultas a arquivos de redo log’s online e archives através de SQL. Os arquivos de redo contém o histórico da atividades em um banco de dados.

Entre os beneficios do LogMiner temos:

1 – Localizar um corrupção lógica devido a erros de aplicação

2 – Determinar que ações devem ser tomadas para executarmos um recover granular da transação

3 – Otimização de performance e plano de capacitação através da análise de tendencias.

4 – Pos auditoria.

Aqui tem um exmplo rápido de implementação e utilização em relação ao FlashBack:logminer

Cade a tabela que estava aqui ?

Filed under: Uncategorized — agleite @ 12:44 am

Situação : Cliente liga reclamando que algumas consultas estão mais lentas que o normal. Até aí tudo bem.

E lá vou eu pro cliente pensando que ia resolver o problema com  um pouquinho de dbms_stats,  nosso amigos de sempre statspack/awr , talvez algum tkprof, além é claro da boa e velha v$session_wait.

No entanto a  coisa tomou  outro rumo quando achei um trace com os seguintes erros:

ORA-00600: internal error code, arguments: [2662], [2293], [1693171303], [6773], [2522013792], [16], [], []
ORA-08103: object no longer exists

Nesse momento,olho para o cliente que está ao meu lado (não fazendo pressão, mas investigando também claro :) ) e vejo aquela expressão de terror estampada na sua cara. Não demora muito e ele manda a pergunta crucial “Como assim tem um objeto que não existe mais ?”.

Após ter dado um tranqüilizante no cliente, fui tentar achar qual o objeto que não existia mais.

Consegui identificar o objeto e mandei o bom e velho analyze – o objeto aqui está com XXX por razões obvias.

SQL> analyze table XXX validate structure cascade;
analyze table XXX validate structure cascade
*
ERROR at line 1:
ORA-08103: object no longer exists

Confirmando com um select

SELECT ROWID, ultima_coluna_da_tabela  from XXX

AAABz+AAHAAACDPAAp S
AAABz+AAHAAACDPAAq S
AAABz+AAHAAACDPAAr S
AAABz+AAHAAACDPAAs S
AAABz+AAHAAACDPAAt S
AAABz+AAHAAACDPAAu S
AAABz+AAHAAACDPAAv S
AAABz+AAHAAACDPAAw S
ERROR:
ORA-08103: object no longer exists

10073 rows selected.

Ok descobri qual o objeto e agora ?

Alguns detalhes.

Versão Oracle: 9.2.0.8 Standard 32bits Linux – Tabela em TS’s LMT.

Ao que parece  isso é um resultado esperado se as tabelas estão sendo alvo de algum drop/truncate, enquanto consultas referenciando estas tabelas ainda estão sendo executados.

No caso de um index, o erro pode ter sido causado por um rebuild.

Colocando de maneira bem simples o objeto foi eliminado por outra sessão, enquanto a aplicação estava sendo executada.

- Nesse momento acho que vi um developer levantar e sair correndo…mas deve ter sido só impressão.

O fato é que o data_object_id (em dba_objects) foi alterado enquanto as consultas estavam rodando. Se não me engano , esta  coluna pode mudar devido :

truncate table
alter index .. rebuild
alter table .. move

** Como internals: quando um truncate ocorre DATAOBJ# em OBJ$ aumenta de um e isso pode causar o ORA-08103.

Ah ! Isso também pode acontecer se o objeto estiver corrompido. Mas ai já é outra história :)

Voltando ao assunto do post vamos tentar simular o erro:

SQL> create table blah as select * from dual;

Tabela criada.

SQL> var c refcursor
SQL> begin open :c for select * from blah; end;
2  /

Procedimento PL/SQL concluído com sucesso.
SQL> drop table blah purge;

Tabela eliminada.

SQL> print c;

D
-
X

SQL>

No entanto se eu fizer o drop na tabela e re-utilizar este espaço (recriando outra tabela), o cursor vai falhar.

SQL> create table blah as select * from dual;

Tabela criada.

SQL> var c refcursor
SQL>  begin open :c for select * from blah; end;
2  /

Procedimento PL/SQL concluído com sucesso.

SQL> drop table blah purge;

Tabela eliminada.

SQL>  create table blah(a int); — este comando vai sobrescrever o header do bloco da tabela anterior

Tabela criada.

SQL> print c
ERROR:
ORA-08103: o objeto não existe mais

Não tem muito o que fazer não é ? O Objeto não existe mais. Fim da História.

E como ficou o cliente ? Ele ficou mais calmo depois que fiz um TSPITR com export e import desta tabela.


August 29, 2009

Problemas com Hints ? | Sql Profile

Filed under: Uncategorized — agleite @ 4:49 pm

Testando uma maneira nova de fazer posts.

Fiz um documento sobre como utilizar Sql Profile ao invés da Hint em um comando sql. O motivo é que fica mais fácil de ver os planos de execução do que se eu fizesse print screen aqui no wordpress.

Pra download é so clicar aqui: SqlProfileExemplo

July 1, 2009

Metalink 3 | Upgrade

Filed under: Uncategorized — Tags: — agleite @ 2:00 am

Metalink 3 vai se chamar “My Oracle Support” a partir de Agosto de 2009
vai aqui para fazer o registro. Precisa do CSI

June 30, 2009

Estrategias para migrar de FS para ASM

Filed under: Uncategorized — Tags: , — agleite @ 1:30 am

* Rman
* Dbms_file_transfer
* Online reconfiguration
* Ftp
* Alter table move.
* Migração gradual com datafiles em FS e ASM

Lembrando que o RMAN, aparecendo como o primeiro da lista, não é mera coincidencia :)

May 26, 2009

Data Guard | Modos de Proteção

Filed under: banco de dados — agleite @ 8:07 pm

Recentemente fiz uma apresentação sobre as possiveis  configurações do Oracle  StandBy, para um grupo de gerentes não técnicos. A configuração de Data Guard desejada era o modo de Performance Maxima, no entanto, a empresa estava preocupada com a possibilidade de perda de dados, pelo fato de executar de modo assincrono.

Abaixo tem um resumo do que apresentei pra eles. Nada muito tecnico como ja tinha dito anteriormente.

Introdução

Na configuração do Oracle Standby database, existem 3 modos possivel de se enviar os dados do banco primário (atual banco de produção) e o banco de dados standby (aquele que será feito o failover). Dois deles são sincronos e um assincrono.

Para escolher qual modo é melhor, a empresa tem que avaliar o impacto entre Proteção x Performance no ambiente de produção.

A tabela abaixo mostra os beneficios e as desvantagens de cada modo

Modo de Operação
SYNC/

ASYNC

Beneficios
Desvantagens
Maxima Proteção SYNC Sem perda de dados. O Dado só é confirmado no Primario , após ter sido gravado no StandBy Tempo de Resposta lento no primario. Na falta  de conectividade entre o primário e o standby, o banco primario é desligado
Maxima Disponibilidade SYNC Atualizações devem estar no  standby antes de serem  aceitas no primario,
Se a rede parar de funcionar  o primario continua ativo e as  atualizações serão enviadas para o standby quando ele estiver acessivel novamente.
Tempo de resposta lento no primário . Perda de dados possivel se a rede falhar e logo após o site stanby falhar também.
Maxima Performance ASYNC Sem problem de performance para as aplicações no primario. Perda de Dados poderá acontecer

O cliente no momento está no modo Maxima Performance, sem nenhum impacto na performance do tempo de resposta das aplicações.

Existem dois fatores que podem impactar na peformance das aplicações se for decidido ir para um nivel maior de proteção. São eles: a latencia e a largura de banda da rede.

Para as aplicações que fazem alterações nos dados, o tempo de resposta será afetado pelo “round trip time”  para o standby.

Periodos com um volume maior de ativade podem congestionar a rede, aumentando o tempo de resposta.

Conclusão

Quanto maior o nivel de proteção, a lagura de banda da rede deve ser ajustado para causar menor impacto no tempo de resposta da aplicações.

Geralmente vemos um atraso no transporte das informações para o site stanby,  de  aproximadamente 10 segundos e este seria o total de dados que perderiamos em uma situação de desastre.Durante os horários de pico, este tempo pode aumentar.

April 21, 2009

Oracle Compra a Sun

Filed under: Uncategorized — agleite @ 11:09 pm

Provavelmente o Solaris vai se tornar um SO mais viavel para rodar Oracle na plataforma x64.  Na verdade este SO  já é muito bom, mas agora deve ser devidamente apoiado pela  Oracle.

Mais detalhes em : http://www.oracle.com/sun/index.html

March 7, 2009

Oracle Enterprise Manager 10g Release 5 | Grid Control

Filed under: Uncategorized — agleite @ 11:04 pm

O produto está disponivel nas  versões Windows (32 bits)  e Linux (x86) desde quarta-feira pela manhã.

O download pode ser feito aqui.

Pontos a ressaltar:

1 – ADDM para  RAC (finalmente)

2 – Database Vault

3 – 11g advisors : Partition Advisor, Data Recover Advisor

4 – Database Replay pode fazer a  captura de  workloads a partir do release  9.2.0.8

Todas as novas caracteristicas podes ver no  otn

December 29, 2008

PLS-00101 | Piada Pronta

Filed under: banco de dados — Tags: — agleite @ 12:45 am

O que não falta na Oracle é bom humor. Tava olhando o   “Oracle® Database Error Messages: 10g Release 2 (10.2)” Quando vi esta mensagem de erro:

PLS-00101: reserved for future use

Cause: This error message is not used yet. (Heh, heh, that”s a joke, son.)

Action: none

 Embora tenha sido reservada para uso futuro, de alguma forma ela aparece neste manual. Aproveitei e fui olhar o mesmo manual, só que na versão 11g e… não tem este erro lá.

Quem sabe ela aparece no 12g  ;)

December 27, 2008

11g ASM|Variable Sized Extents

Filed under: Uncategorized — agleite @ 12:34 am

ASM (10G), define uma Allocation Unit (AU) como a unidade fundamental de alocação dentro de um diskgroup. Por default uma AU no ASM equivale a 1m.

ASM Data Extents são utilizados para manter o conteudo de um arquivo ASM. No Oracle 10g, cada “data extent” é igual a uma AU, ou seja, 1m. Por causa deste relacionamento de um pra um entre o tamanho do extent e uma AU, um mapa de extensões de um arquivo ASM pode crescer até terabytes em bancos de dados muito grandes criando ineficiencias no uso de memória e abertura dos arquivos.

No 11g esse overhead é minimizado através de Variable Sized Extents. Por exemplo : Imagine um datafile pequeno com digamos 1G de tamanho, então o file extent utilizado será de 1 AU. A medida que este arquivo aumenta, o tamanho das AU’s  irá variar de acordo com a quantidade de extents . A tabela abaixo mostra os limites do numero de extents  e os tamanhos das AU’s

Number of Extents Size
0 – 19999 1*AU
20000 – 39999 8*AU
40000 – 59999 64*AU

O primeiro limite é 20G (20.000 extents de 1m) . O tamanho dos extents validos são 1, 8 e 64 AU’’s (1m, 8m e 64m). O ASM administra estes tamanhos automaticamente. Neste sentido esta feature é bastante similar ao comportamento da Alocação de Extensão Automatica que o RDBMS utiliza.

« Newer PostsOlder Posts »

Blog at WordPress.com.