segunda-feira, 25 de janeiro de 2010

ENTENDENDO MEUS ENQUEUES WAITS EVENTS


Olá , como estão todos?

Hoje venho aqui trazer uma explanação sobre algo muito comum e rotineiro nos bancos de dados de todo o mundo, estou falando dos eventos de espera de fila ou ENQUEUES se preferirem.

Vamos então conhecer um pouco mais sobre essas estruturas.


ENQUEUES (Fileiras)

Conceito: os ENQUEUES são estruturas de memória que serializam o acesso aos recursos de banco de dados e estão intimamente ligados com as sessões de banco ou transações.
Uma particularidade dos enqueues é que em ambientes RAC ( Real Application Cluster), eles podem ser encontrados de maneira global, consultando as visões GV$, onde no campo INST_ID indicará a qual instância do seu ambiente RAC tal evento pertence, em se tratando de ambientes SINGLE INSTANCE estes serão encontrados localmente.
Ainda conceituando , os enqueues são uma espécie de lock que protegem os recursos compartilhados, tal como os DADOS por exemplo, prevenindo que um mesmo processo atualize os mesmos dados simultaneamente. Isto ocorre graças ao mecanismo de FIFO ( First In First Out) existente nas estruturas de enqueues.

TIPOS DE ENQUEUES MAIS COMUNS

Todavia é muito visual encontrarmos em nosso database vários tipos de enqueues, onde muitas vezes ocorrem confusões quanto as suas nomenclaturas e interpretações, principalmente se você é um iniciante e está se aventurando pela área de Tunning em Banco de Dados, este é o melhor período para firmar conceitos e nomenclaturas, para que assim consiga adquirir know-how com o passar dos anos.

Bem, vejamos então quais os tipos de enqueues mais comuns encontrados, são eles : TX enqueues, TM enqueues, ST enqueues e HW enqueues.

FUNÇÕES DOS TIPOS DE ENQUEUES

Conheceremos agora um pouco mais sobre o trabalho dessas estruturas de banco de dados, que proporcionam não só segurança mas também maior credibilidade quanto as informações transacionadas nos Bancos de Dados Oracle.

TX ENQUEUE : é o mais comum encontrado nos bancos de dados. Este tipo pode aparecer quando temos em questão várias atualizações para um mesmo fragmento de um índice BITMAP. Via de regra , um único fragmento pode conter vários ROWID’s. Quando muitos usuários tentam atualizar o mesmo fragmento, um commit ou rollback se faz necessário para liberar a fila. Esta situação é mais comum quando diversos usuários estão atualizando o mesmo bloco. Caso não haja slots ITL livres, um lock a nível de bloco pode ocorrer.

Nota : Para entender mais sobre ITL veja o link : http://www.rampant-books.com/art_nanda_interested_tarnsaction_list_itl.htm.

Este cenário pode ser evitado se quiser, basta que você aumente seus paramentros de INITRANS ou MAXTRANS para que possa permitir múltiplos ITL slots, também pode-se obter êxito aumentando o PCTFREE das tabelas.

TM ENQUEUE : ocorre geralmente em operações do tipo DML prevenindo assim que operações DDL afetem o objeto em questão. Índices nas FOREIGN KEYS devem ser usados para evitar esses lock’s em questão.

ST ENQUEUE : está mais ligado as questões de armazenamento e gerenciamento das tablespaces do Banco de Dados. Nestes casos devemos usar tablespaces gerenciadas locamlmente ( LMT’s) , a fim de evitar problemas com tamanho de extent’s no processo de pré-alocação.

HW ENQUEUE : são os locks ligados a “marca d’agua” dos segmentos, que podem ser contornados alocando manualmente os extents.

VERIFICANDO MEUS ENQUEUES

Agora vejamos como podemos resgatar em nosso Banco de Dados, as informações pertinentes a existências desses WAIT EVENTS, o script abaixo lhes mostrará uma pequena relação dos seus enqueues :

Select * from v$sysstat
Where class = 4;

Select chr(bitand(p1,-16777216)/16777215)||
Chr(p1,16711680)/65535) “Lock”,
To_char(bitand(p1,65565)) “Mode”
From v$session_wait
Where event = ‘enqueue’;

Select * from v$enqueue_stat
Where cum_wait_time > 0
Order by cum_wait_time desc;



Este script irá mostrar os tipos, quantidade de ocorrencias dos mesmos em seu banco de dados, e também um relatório cumulativo de quantas vezes ocorre um determinado tipo de Lock. Mediante essa informação o DBA deve analisar, ver se é possível implementar algum tipo de “workarround”, caso estas incidências estejam causando problemas, e manter sempre uma monitoração constante no seu Banco a fim de manter uma boa saúde do mesmo.

Bom , espero que tenham gostado , um abraço á todos e até breve!!!

Referencias : Oracle Tuning Power ScriptsRampant H. Conway,Mike Ault e Donald K. Burleson.