Perdeu os archives ???
Perdeu o backup ???
Não tem mais jeito ???
Demissão ???
È pessoal pode ser que ainda exista a última esperança.
_allow_resetlogs_corruption = true
Com esse parametro no spfile, pode ser que o banco abra resetando os
logs , ai você recupera os dados e reza, mas raza muito pra ninguém
descobrir o que realmente aconteceu.
Bem não preciso nem dizer que esse é um parâmetro não documentado,
que a chance de dar errado é grande, e se você ferrou seu ambiente de
produção pra testar se ele funciona, boa demissão!!!
Sem brincadeiras, já testei o parâmetro em um ambiente de testes, fiz
o backup, deletei todos os archives e exclui alguns datafiles,
acrescentei ele no spfile e dei um alter database open resetlogs e ele
subiu.
Já presenciei outra situação na qual ele também funcionou, mas espero
que nem eu nem vocês nunca tenham que usá-lo pra valer.
Abraços!!
quarta-feira, 23 de junho de 2010
domingo, 13 de junho de 2010
Cache Hit Ratio Oracle
A Buffer Cache é um recurso compartilhado, acessível por todos os usuários.
Quando um usuário emite uma consulta , O Oracle antes de ir nos datafiles buscar os blocos necessários para retornar o resultado, primeiro olha para os blocos de dados na buffer cache.
Se os dados colocados no cache são retornados para o solicitante imediatamente .
Ocorre o famoso Hit Ratio .
Quando os dados não forem encontrados, um cache miss ocorre e o processo do usuário irá lêr os dados do disco para um buffer disponível no cache.
A taxa de acerto do cache é a percentagem total de solicitações de dados que são servidos diretamente a partir da buffer cache.
No Oracle, o buffer cache hit ratio normalmente é calculado utilizando a seguinte fórmula:
Cache Hit Ratio = 100 * (1 - leituras físicas / lógicas leituras)
Nesta fórmula, "leituras físicas", corresponde à falta de cache e 'leituras lógicas "corresponde ao total de solicitações de dados.
Ajustando o buffer cache para optimizar o desempenho normalmente ocorre a adição de buffers no cache até que a taxa de acerto foi maximizada.
O número de buffers no cache é especificado pelo parâmetro de inicialização DB_BLOCK_BUFFERS.
Abraços !!
Quando um usuário emite uma consulta , O Oracle antes de ir nos datafiles buscar os blocos necessários para retornar o resultado, primeiro olha para os blocos de dados na buffer cache.
Se os dados colocados no cache são retornados para o solicitante imediatamente .
Ocorre o famoso Hit Ratio .
Quando os dados não forem encontrados, um cache miss ocorre e o processo do usuário irá lêr os dados do disco para um buffer disponível no cache.
A taxa de acerto do cache é a percentagem total de solicitações de dados que são servidos diretamente a partir da buffer cache.
No Oracle, o buffer cache hit ratio normalmente é calculado utilizando a seguinte fórmula:
Cache Hit Ratio = 100 * (1 - leituras físicas / lógicas leituras)
Nesta fórmula, "leituras físicas", corresponde à falta de cache e 'leituras lógicas "corresponde ao total de solicitações de dados.
Ajustando o buffer cache para optimizar o desempenho normalmente ocorre a adição de buffers no cache até que a taxa de acerto foi maximizada.
O número de buffers no cache é especificado pelo parâmetro de inicialização DB_BLOCK_BUFFERS.
Abraços !!
Marcadores:
blocos,
buffer cache,
buffers,
Cache de Hit Hatio,
database buffer cache,
Go Horse,
Go Horse Process,
Hit Ratio,
oracle
quarta-feira, 2 de junho de 2010
Tempo de Recuperação e outros parâmetros no Oracle
Fala Pessoal,
A visão V$Instance_Recovery merece destaque nesse assunto, as principais colunas são:
recovery_estumated_ios - > O número de operações de i/o nos datafiles que seriam necessárias para a recuperação se a instância falhasse.
actual_redo_blocks - > O número de blocos de redo do sistema operacional que se precisariam ser aplicados aos datafiles para a recuperaçõ se a intância falhasse agora.
estimated_mttr - > O número de segundos necessários para abrir o banco de dados caso ele falhasse agora.
writes_mttr -> O número de vezes que o DBWn teve de gravar, além das gravações que ele normalmente faria, para atingir a meta do mttr.
Enfim uma mão na roda......
A visão V$Instance_Recovery merece destaque nesse assunto, as principais colunas são:
recovery_estumated_ios - > O número de operações de i/o nos datafiles que seriam necessárias para a recuperação se a instância falhasse.
actual_redo_blocks - > O número de blocos de redo do sistema operacional que se precisariam ser aplicados aos datafiles para a recuperaçõ se a intância falhasse agora.
estimated_mttr - > O número de segundos necessários para abrir o banco de dados caso ele falhasse agora.
writes_mttr -> O número de vezes que o DBWn teve de gravar, além das gravações que ele normalmente faria, para atingir a meta do mttr.
Enfim uma mão na roda......
Marcadores:
actual_redo_blocks,
blocos,
DBWN,
I/O,
oracle,
recuperação,
tempo,
V$Instance_Recovery
Assinar:
Postagens (Atom)