Menu de navegação

[rmanParticipante]

[quote=”lordmaca”:i4my8b8w][quote=”rman”:i4my8b8w]@lordmaca

Sim, entendi o conceito de MANDATORY, isso vai me garantir que sempre as duas localizações seram gravadas…

Tudo bem, se a base congelar, o que fazer ?

shutdown immediate e startup ?[/quote]

Nesse caso apos o tempo do reopen ele vai tentar gravar denovo ai se for com sucesso a base volta sozinho, mas isso ‘e impacto na base.

@all,

Alguem sabe me dizer se forcar um archivelog all caso a base congela ele tenta regravar mesmo que o tempo do reopen nao tenha expirado? aqui ja ‘e 1h da manha e minhas vms estao com RAC e APPS nao consigo testar agora ate subir os servers e monta o cenario vai ser tarde rs rs.

Att,[/quote]

O REOPEN só deve ser utilizando quando utilizado SERVICE ? Ou pode ser utilizado também com LOCATION ?

Essa dúvida surgiu lendo a documentação oficial:

http://download.oracle.com/docs/cd/B193 … htm#i78421

Estou utilizando LOCATION, os hds SAS foram montados, para o SO, os hds são “locais”.

[vpapaParticipante]

@rman

Funciona com LOCATION sim.

@all

A minha duvida anterior foi sanada, quando a base congela pelo local de gravação de destino ter tido um erro e o comando archivelog all ‘e executado, ele tenta regravar no location( e todos os outros) que falhou anteriormente, se archivado com sucesso base “descongela”.

Att,

[rmanParticipante]

@vpapa

O archivelog all que você se refere é o ALTER SYSTEM ARCHIVE LOG ALL ?

É a mesma coisa que ALTER SYSTEM SWITCH LOGFILE ?

[felipegParticipante]

Rman

O ALTER SYSTEM ARCHIVE LOG ALL dirá ao Oracle para arquivar todos os redos que estejam cheios e ainda não foram arquivados, este comando pode ser executado com a base em modo mount.

Já o ALTER SYSTEM SWITCH LOGFILE dirá ao Oracle para “trocar” o redo corrente pelo próximo, independente de ele estar cheio ou não.
Ao executar esse comando o Oracle implicitamente dispara também um checkpoint, o que obriga a base de dados a estar no modo Open.

Atenciosamente,
Felipe.

[vpapaParticipante]

[quote=”felipeg”:2ij29c9x]Rman

O ALTER SYSTEM ARCHIVE LOG ALL dirá ao Oracle para arquivar todos os redos que estejam cheios e ainda não foram arquivados, este comando pode ser executado com a base em modo mount.

Já o ALTER SYSTEM SWITCH LOGFILE dirá ao Oracle para “trocar” o redo corrente pelo próximo, independente de ele estar cheio ou não.
Ao executar esse comando o Oracle implicitamente dispara também um checkpoint, o que obriga a base de dados a estar no modo Open.

Atenciosamente,
Felipe.[/quote]

@felipeg

Muito bem explicado !!

Att,

[felipegParticipante]

@vinicius , Obrigado.

Falei, falei e não respondi todas as perguntas do RMAN.
No caso de travar o comando é o ARCHIVELOG ALL mesmo.

Atenciosamente,
Felipe.

[rmanParticipante]

@all

Obrigado pela atenção e participação de todos.

[rmanParticipante]

@all

O archive log gerado é de 476 mb, e está sendo gerado 1 por hora… Estou achando inviável a solução por se tratar de archive deste tamanho, passando por uma rede gigabit (é gigabit, me referi errado quando disse que era 10/100). Eu estou enganado ou o archive log está muito grande ?

Outra pergunta, se o Oracle demora 1 segundo pra gravar o archive log na storage, e demora 1 min pra gravar no HD SAS, isso quer dizer que a base vai congela por 1 min ? Qualquer operação de escrita no banco vai esperar o archive log ser arquivado ? Operações de leitura seguem normalmente ?

[felipegParticipante]

Rman

Isso vai depender das seguintes configurações
– Quantidade de arquivos de redo
– Tamanho dos redos
– Archive gerado por minuto.
– Maior tempo de gravação para o destino

O status do redo pode ser, principalmente*, CURRENT , ACTIVE ou INACTIVE.

Suponhamos que você tenha 10 Grupos de redo multiplexados com 100Mb cada e que gere uma média de 8Mb por minuto (476/60) 8)

Se considerarmos que o Oracle estava no grupo 1 e trocou para o 2 e o processo de Archive ainda não terminou no 1 veremos, ao consultar na V$LOG o seguinte status

1 – ACTIVE
2 – CURRENT
3 – INACTIVE
4 – INACTIVE…

E assim por diante, o status ACTIVE diz ao Oracle que este redo ainda é necessário em caso de falha na instância, geralmente enquanto continuar neste status significa que o mesmo não teve todos os dados pertencentes gravados do buffer pelo DBWr.

Logo você pode perceber que, nesse caso, é praticamente impossível com a quantidade de informação gerada deixar o LGWR em uma situação onde não há redos disponíveis para gravação.

No segundo exemplo se houver apenas dois grupos e o primeiro estiver ainda arquivando durante o logswitch do segundo o Oracle será OBRIGADO a esperar para poder manter a consistência das informações e a integridade em caso de uma possível recuperação.

OBS: Coloquei um asterico em principalmente pois o redo pode ter outros status como UNUSED, CLEARING ou CLEARING_CURRENT.

Acho que é isso.
Atenciosamente,
Felipe.

[rmanParticipante]

@felipeg

Deixa eu ver se entendi, para cair a situação de congelar a base os redo log deveria estar:

1- ACTIVE
2- CURRENT
3- ACTIVE
4- ACTIVE

Ou seja, a geração do archive log é tão rápida que não deu tempo do arquivamento. Isso acontece devido o redo estar pequeno.

Com o cenário assim, 1 segundo para arquivar no storage e 1 min para arquivar, então a base ia congelar por 1 min.

É isso ?

[felipegParticipante]

Se você chegar a uma situação dessas em que não há redo para gravar o Oracle irá aguardar até um ficar disponível, porém não irá apresentar erro.

Você simplesmente sentirá uma lentidão absurda e, se o problema for com redo cheio para continuar o processo de log switch você encontrará no alert.log a mensagem “checkpoint not complete, cannot allocate new log”.

Só para confirmar.
http://download.oracle.com/docs/cd/B193 … neredo.htm

Condition: LGWR cannot access the next group at a log switch because the group needs to be archived

LGWR Action: Database operation temporarily halts until the group becomes available or until the group is archived.

Lembrando que ele pode estar no estado CURRENT e já estar arquivado, ele só vai sair deste estado quando o DBWr completar o checkpoint.

Atenciosamente,
Felipe.

[rmanParticipante]

@felipeg

Eu já presenciei a lentidão absurda, isso aconteceu quando a area de archive log lotou.

Mas nunca reparei a situação dos redo, provalmente vai estar:

1- CURRENT
2- ACTIVE
3- ACTIVE
4- ACTIVE

[felipegParticipante]

Da uma conferida


SELECT group#,members,archived,status FROM v$log;


O que você tem que olhar.

Se está como ARCHIVED NO significa que o redo ainda não foi arquivado.

Se está como ACTIVE o DBWr ainda não completou o chekpoint, o que significa que a instância precisa desse redo para possível recuperação.

Atenciosamente,
Felipe.

[rmanParticipante]

@felipeg

No momento está normal:


SQL> SELECT group#,members,archived,status FROM v$log;

GROUP#    MEMBERS ARCHIVED STATUS

---

     1          3 YES      INACTIVE
     2          3 NO       CURRENT
     3          3 YES      INACTIVE
     4          3 YES      INACTIVE

[vpapaParticipante]

[quote=”rman”:3q53kdqi]@felipeg

No momento está normal:


SQL> SELECT group#,members,archived,status FROM v$log;

GROUP#    MEMBERS ARCHIVED STATUS

---

     1          3 YES      INACTIVE
     2          3 NO       CURRENT
     3          3 YES      INACTIVE
     4          3 YES      INACTIVE

[/quote]

@rman,

Bem voltando ao forum depois de uma semana muito corrida rs rs, me diga o tamanho dos seus grupos !!

Se a area de archive ficar cheia ‘e natural acontecer a lentidao ou congelamento, por isso podemos criar alertas !! thresholds**

O momento que vc fez este select a base estava em horario de pico?

Abraco !!

[Autor]

Posts