Ir para conteúdo

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

rodrigo.rizzo

ArchiveLog

Recommended Posts

Srs,Aos que tiveram alguma experiencia com os archivelogs do Oracle 9i:Como estimar o tamanho necessario do filesystem para poder utilizar os archivelogs sem prejudicar a produção, o receio seria se a area destinada aos arquivo chegasse ao limite e desta forma travando o banco de dados...Além disso, gostaria de saber se alguem já teve algum problema relacionado aos archives...Grato,Rodrigo

Compartilhar este post


Link para o post
Compartilhar em outros sites

Olá,

 

O tamanho dos Archives vai ser o tamanho total do seus arquivos de REDO LOG (Somando todos os membros).

 

Pelo ALERT.LOG você consegue saber em quanto tempo o Oracle Server está gerando um ARCHIVE, isso irá depender muito do seu ambiente, caso, tenha muitas transações esse tempo de geração será pequeno, pois o Oracle Server sofrerá log switch.

 

É muito recomendavel que você calcule o valor de geração para 12Horas, então veja em 12Horas pelo ALERT.LOG quantos ARCHIVES foram gerados e seu tamanho.

 

Sempre coloque um backup de ARCHIVE para executar em 3 em 3 horas ou 6 em 6. Pois caso tenha problemas na execução do backup pelo RMAN, vocÊ tem algum tempo para solucionar. Assim, evita travar o banco de dados.

 

Abraços, http://forum.imasters.com.br/public/style_emoticons/default/joia.gif

Compartilhar este post


Link para o post
Compartilhar em outros sites

Rodrigo,Na minha base, para que o local destinado aos achives não chegue ao limite, passamos todos os dias os archives para uma fita na hora do backup. Mas com certeza isso não seria necessário se vocês tiver um número pequeno de transações na sua base, gerando um número pequeno de log switch e conseqüentemente um número pequeno de archive.O archive nada mais é do que uma cópia que é feita do redo log file no momento do log switch, sendo assim, cada grupo de redo log terá um archive, ex.:grupo 1 de redo /u01/redo1.log /u02/redo1.logAqui temos um espelhamento de redo e imaginemos que cada arquivo tenha 50MB. Ao log switch teremos apenas um arquivo gerado pelo processo arch (responsável pelo arquivamento dos logs) que terá no máximo o tamanha de 50MB. É feita apenas uma cópia para este caso porque temos dois arquivos idênticos e não teria porque serem gerados 2 archives ou um archive de 100MB. Este processo acontecerá exatamente igual para cada log switch.grupo 2 de redo /u01/redo2.log /u02/redo2.logV$LOG tem a coluna bytes que informa o tamanho do arquivo de log.É isso aí, abraço!!

Compartilhar este post


Link para o post
Compartilhar em outros sites

Obrigado Rodrigo e Rafael pelas respostas... http://forum.imasters.com.br/public/style_emoticons/default/thumbsup.gif

 

Atualmente os arquivos de log não são multiplexados, tenho 3 grupos com 1 membro cada, e 100MB para cada log.

 

Minha base de dados tem modelo transacional, mas serve basicamente para extração de relatórios, portanto há apenas algumas importações que são realizadas em um determinado periodo, de madrugada.

 

A v$log possui uma coluna (FIRST_TIM) que referencia uma data, seria a data que alternou a log?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Exatamente rodrigo, no momento do switch de log o campo first_tim assume a data em que foi realizado o switch. Podes fazer um teste executando um switch de log manual com o comando:

 

alter system switch logfile;

O comando executará um switch.....

 

É isso Rodrigo...abraço!!!

Compartilhar este post


Link para o post
Compartilhar em outros sites

Neste caso, vejo dois grupos com a data de hoje, creio que deveria ter cerca de 200MB por dia disponivel para o archive...Para fazer o recover utilizando os archives, basta ter um backup fisico (tenho um cold backup diario) e os archives pós backup fisico, correto?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Na verdade, sempre que o oracle é iniciado é executado o processo smon(sistem monitor) que faz a verificação da consistência do banco de dados e, caso seja necessário (como no caso de uma queda de energia), inicia o recover (recuperação) da base. Para fazer isso, o smon checa a seqüência do redo corrente e verifica se é a mesma do data file, caso não seja, ele inicia a recuperação a partir do redo. Esse processo acontece sempre sem que percebamos. Caso a transação na qual parou o data file já não esteja mais nos redo log (como quando recuperamos um backup de uma semana atrás, ), na inicialização da base o oracle não abre a base e nos avisa que o data file precisa ´de recover, então, é só digitar o comando "recover database" o oracle novamente sugere o archive a partir do qual deve ser iniciada a recuperação. Resumindo: startup mount da base e recover database.A recuperação com archives tb pode ser feita com a base on-line (open). Neste caso temos mais duas opções: - recover tablespace nome_da_tablespace (a tablespace precisa estar off-line) - recover datafile nome_do_data_file Com os archives, podemos ainda fazer uma recuperação point-in-time, na qual podemos fazer a base ser recuperada até duas horas atrás por exemplo.startup mount;recover database until 'yyyy-mm-dd:hh24:mi:ss'; (não lembro se a data deve ficar entre aspas)a recuperação point-in-time pode ser feita tb pelo scn (número da transação)recover database until change numero_da_transaca.resumindo é isso cara....acho que esses são os mais importantes a saber!! :)Abraço!!

Compartilhar este post


Link para o post
Compartilhar em outros sites

×

Informação importante

Ao usar o fórum, você concorda com nossos Termos e condições.