Menu de navegação

[rmanParticipante]

Olá!

Gostaria de saber a opinião de vocês sobre multiplexar a geração de archive log.

Atualmente o archive log está sendo gerado na Storage que é ligado via fibra ótica. Estou pensando em multiplexar a geração, porém seria em hd sas ligado por uma rede comum 10/100 mbps. Devido a rede “lenta” pode acontecer problemas ? O tamanho de archive log é de 476 mb gerado em media 1 por hora.

Outra pergunta, o archive log é considerado gerado apenas quando termina de escrever em todas as localizações ? Caso o banco caia no meio da geração do banco, ele é considerado gerado ?

Estou utilizando Oracle 10g R2 (10.0.2.4) em Red Rat 5.3.

É uma boa ideia multiplexar o archive log neste cenário ?

[lordmacaParticipante]

[quote=”rman”:fgzr1oyu]Olá!

Gostaria de saber a opinião de vocês sobre multiplexar a geração de archive log.

Atualmente o archive log está sendo gerado na Storage que é ligado via fibra ótica. Estou pensando em multiplexar a geração, porém seria em hd sas ligado por uma rede comum 10/100 mbps. Devido a rede “lenta” pode acontecer problemas ? O tamanho de archive log é de 476 mb gerado em media 1 por hora.

Outra pergunta, o archive log é considerado gerado apenas quando termina de escrever em todas as localizações ? Caso o banco caia no meio da geração do banco, ele é considerado gerado ?

Estou utilizando Oracle 10g R2 (10.0.2.4) em Red Rat 5.3.

É uma boa ideia multiplexar o archive log neste cenário ?[/quote]

@rman,

You can choose whether to archive redo logs to a single destination or multiplex them. If you want to archive only to a single destination, you specify that destination in the LOG_ARCHIVE_DEST initialization parameter. If you want to multiplex the archived logs, you can choose whether to archive to up to ten locations (using the LOG_ARCHIVE_DEST_n parameters) or to archive only to a primary and secondary destination (using LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST). The following table summarizes the multiplexing alternatives, which are further described in the sections that follow.

o parametro LOG_ARCHIVE_DEST_n pode ser setado até 10 sendo de 0 a 9.

Possiveis Impactos:

Mais processamento pois para performance você devera aumentar o numero de arch process.
Mais I/O e Consumo de espaço para seu storage. (obs apenas)
Trafico da rede maior.

Pergunta:
Essa rede 10/100 seria dedicada so para essa tarefa?

Outra pergunta, o archive log é considerado gerado apenas quando termina de escrever em todas as localizações ? Caso o banco caia no meio da geração do banco, ele é considerado gerado ?

Sim o archivelog é considerado gerado com sucesso quando termina de escrever e fecha o arquivo, assim o status do grupo de redo logs que estava em ACTIVE muda para INACTIVE sendo assim sobrescrito no proximo LOG SWITCH.

@all

Se a base cair no meio da geração ele não será considerado gerado, quando a base reinicia e for necessario algum log ele ira buscar dos redos e o archive será feito posteriormente pelo arch0….<<– tenho duvida nesta também, acredito que funcione assim, por favor me corrijam se eu estiver errado.

É uma boa ideia multiplexar o archive log neste cenário ?

Esse cenário é produção correto? sendo assim, qual sua estrategia de backup diario?

Abraço

Vinicius

[rmanParticipante]

@lordmaca

A Rede 10/100 não é dedicada apenas para essa tarefa.

O cenário apresentado é produção, e é feito diariamente um backup full via RMAN + 2 Exports.

[PetersonParticipante]

Na configuração dos parâmetro referentes ao Archived log, você pode definir locais diferentes de gravação para fazer a multiplexação que vc quer.

ex:
LOG_ARCHIVE_DEST_1 = ‘LOCATION=D:oradataarchives MANDATORY ALTERNATE =log_archive_dest_3’
LOG_ARCHIVE_DEST_2 = ‘LOCATION=\Servidor2archives’
LOG_ARCHIVE_DEST_3 = ‘LOCATION=E:oradataarchives’

A opção MANDATORY diz que esse local de geração dos archives deve ser obrigatório. os demais são opcionais. Caso ele não consiga gravar no local mandatório, ele vai para onde o parâmetro log_archive_dest_3 indica.

Há também o parâmetro LOG_ARCHIVE_MIN_SUCCEED_DEST que define a quantidade mínima de locais de arquivamento onde as cópias dos redo logs devem ser geradas. No seu caso, vc poderia configurar esse parâmetro como 1 e caso ele tenha falhas ao gravar na área de disco pela rede, ele prosseguiria sem parar o banco.

A propriedade MANDATORY tem precedência sobre o parâmetro LOG_ARCHIVE_MIN_SUCCEED_DEST.

[rmanParticipante]

[quote=”Peterson”:11oyyn6s]Na configuração dos parâmetro referentes ao Archived log, você pode definir locais diferentes de gravação para fazer a multiplexação que vc quer.

ex:
LOG_ARCHIVE_DEST_1 = ‘LOCATION=D:oradataarchives MANDATORY ALTERNATE =log_archive_dest_3’
LOG_ARCHIVE_DEST_2 = ‘LOCATION=\Servidor2archives’
LOG_ARCHIVE_DEST_3 = ‘LOCATION=E:oradataarchives’

A opção MANDATORY diz que esse local de geração dos archives deve ser obrigatório. os demais são opcionais. Caso ele não consiga gravar no local mandatório, ele vai para onde o parâmetro log_archive_dest_3 indica.

Há também o parâmetro LOG_ARCHIVE_MIN_SUCCEED_DEST que define a quantidade mínima de locais de arquivamento onde as cópias dos redo logs devem ser geradas. No seu caso, vc poderia configurar esse parâmetro como 1 e caso ele tenha falhas ao gravar na área de disco pela rede, ele prosseguiria sem parar o banco.

A propriedade MANDATORY tem precedência sobre o parâmetro LOG_ARCHIVE_MIN_SUCCEED_DEST.[/quote]

A situação é o seguinte, atualmente está configurado apenas o LOG_ARCHIVE_DEST_1 que aponta para storage via fibra ótica. Minha idéia era configurar o LOG_ARCHIVE_DEST_2 para o hd sas que vai via rede. Veja se estou certo, pensei que desta forma sempre iria ser gerado o archive nas duas localizações, um clone do outro, é isso?

O storage está meio suspeito, por isso quero garantir a cópia do archive no hd sas, o storage pode apresentar problemas a qualquer momento, já planejaram a solução do problema da storage, mas enquanto isso não acontece preciso garantir o backup e os archive log.

[PetersonParticipante]

coloque o hd SAS como LOG_ARCHIVE_DEST_2 e o LOG_ARCHIVE_DEST_1 como MANDATORY.
Monitore se os archives estão sendo satisfatoriamente gerados no LO_ARCHIVE_DEST_2 e mantenha sua estratégia de backup em dia. Recomendável fazer um teste de Restore com seus backups.

E alerta todo mundo da criticidade do problema

8)

[lordmacaParticipante]

[quote=”rman”:2oiu5z1l]
A situação é o seguinte, atualmente está configurado apenas o LOG_ARCHIVE_DEST_1 que aponta para storage via fibra ótica. Minha idéia era configurar o LOG_ARCHIVE_DEST_2 para o hd sas que vai via rede. Veja se estou certo, pensei que desta forma sempre iria ser gerado o archive nas duas localizações, um clone do outro, é isso?

O storage está meio suspeito, por isso quero garantir a cópia do archive no hd sas, o storage pode apresentar problemas a qualquer momento, já planejaram a solução do problema da storage, mas enquanto isso não acontece preciso garantir o backup e os archive log.[/quote]

@rman

Sim, sera como um clone, mas se você quiser realmente garantir que seja multiplexado 100% coloque a clausula MANDATORY nos dois destinos, pois se o Oracle tenta gravar no destino e ele falhar ele pula para o segundo destino e assim por diante, nisso entra a regra do reopen e o parametro citado pelos colegas LOG_ARCHIVE_MIN_SUCCEED_DEST.

OBS: caso o Oracle tente gravar no destino com MANDATORY e não conseguir sua base ira congelar assim garantindo o multiplex, lembre-se de aumentar o numero de ARCHn.

Quanto ao storage, aconselho que seja resolvido o mais rápido possível para não ter o Down time caso sua base não possa ter.

Abraco.

[PetersonParticipante]

Vinicius,

Colocar como MANDATORY uma área de disco de acesso lento não pode fazer com que o Oracle trave caso haja problemas na gravação?

[felipegParticipante]

Prezados bom dia,

Respondendo as situações

@Vinicius
Sobre a sua afirmação do archive, ela é verdadeira e faz parte do processo de instance recovery.

Quando o ARCn não consegue finalizar um diretório marcado como MANDATORY, com a cláusula REOPEN ou o total de diretórios do log_archive_min_succeed_dest ele vai tentar gravar novamente assim que a instância subir.

Os diretórios opcionais que não completarem essa gravação podem receber os archives prontos de outro diretório apenas copiando-se os mesmos.

@Peterson
Ótima análise dos parâmetros, não tem mais o que comentar.

Sobre a pergunta dos diretórios mandatórios x área de disco eu creio que teríamos uma queda de performance tendo como gargalo justamente a rede, afinal o Oracle precisará sempre gravar nesses caras.

@Rman
Nesses casos de multiplexação eu sempre vou na aba do Tom Kyte:


ARCn typically copies online redo log files to at least two other locations (redundancy being a key to not losing data!). These other locations may be disks on the local machine or, more appropriately, at least one will be located on another machine altogether, in the event of a catastrophic failure. In many cases, these archived redo log files are copied by some other process to some tertiary storage device, such as tape.


Expert Oracle Database Architecture 9i, 10g and 11g (Apress)

Acho que é isso, se eu também tiver dito alguma besteira por favor me corrijam 8)

Atenciosamente,
Felipe.

[rmanParticipante]

@all

Como verificar a quantidade atual de processos ARCn ?

Como dimensionar e aumentar a nova quantidade de processos ARCn?

Estou utilizando o Red Hat Enterprise Linux 5.3.

[lordmacaParticipante]

@peterson

Você esta totalmente certo, mas como ele disse o storage esta apresentando problema então ele precisa por segurança que os archives sejam multiplexados, então ele não pode assumir o risco de ter falhas la, apesar que será reescrito depois que o tempo do reopen for atingido, como felipeg falou vai ter um gargalo de performance, complicado.

@felipeg

A copia do archive de um destino para o outro você diz sendo automatico ou manual?

@rman

em nivel os:

ps -ef | grep arc

No oracle voce pode checar a view v$archive_processes

O parametro é LOG_ARCHIVE_MAX_PROCESSES

Att,

[rmanParticipante]

@lordmaca

Tenho 2 processos rodando atualmente, pensei em por +2, ficando com 4 processos para exportar para 2 localizações…

@all

Estou pensando em aplicar as seguintes configurações:


LOG_ARCHIVE_DEST_1 = /local1 MANDATORY REOPEN = 300
LOG_ARCHIVE_DEST_2 = /local2 MANDATORY REOPEN = 300
log_archive_min_succeed_dest = 2
LOG_ARCHIVE_MAX_PROCESSES = 4


Falta alguma coisa ?

[lordmacaParticipante]

@rman,

Esteja ciente do impacto de por mandatory nos 2 como disse, se falhar 1 dos 2 a base congela.

Quanto aos 2 processos a mais, você tem que ver como esta a utilização do seu hardware, isso ira usar mais processamento.

att,

[rmanParticipante]

@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 ?

[lordmacaParticipante]

[quote=”rman”:107pbf9g]@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,

[Autor]

Posts