Obrigado pelas explicações mestre!!!
:)
Em Terça-feira, 23 de Agosto de 2016 15:33, "jlchia...@yahoo.com.br
[oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
Opa, seguinte : começando pelo DG físico, é Conceitual que para um
Dataguard "normal", não-active é exigido para que a base-réplica possa ser
Atualizada que ela ** TEM ** que estar em MOUNT, ie, aberta em modo
mono-usuário, digamos assim, - portanto, ela vai estar INDISPONÍVEL até para
consultas por parte dos usuários finais e suas aplicações....
É verdade, vc está 100% correto ao indicar que até se pode abrir o
banco-réplica em read-only e o disponibilizar para os usuários finais mas para
isso OBRIGATORIAMENTE vc tem que "pausar" / interromper temporariamente o
processo de recebimento, E no instante que vc faz isso ele ** DEIXA ** de ser
um banco-standby, ele não está mais sendo atualizado.... O que vai acontecer
nesse cenário é que o banco PROD obviamente vai continuar gerando e gerando
mais e mais archives E o banco que antigamente era standby não está recebendo
esses archives - EVIDENTEMENTE, esse GAP vai crescendo (às vezes rapidamente,
dependendo de quanto é Ativo teu banco PROD, não é difícil que, se essa 'pausa'
de Atualização for longa, o gap, o "buraco", o passivo de archives fique tão
grande que depois de vc 'reativar' o dataguard seja preciso um tempo enorme de
grande pro servidor réplica receber e processar esses archives passados....
Junte isso com um ambiente PROD que é intensamente ativo tipo 24 horas por dia
e vc acabou de cair no que se chama de RACE CONDITION : vc tinha, digamos, 500
archives pra enviar e aplicar no standby, no tempão que levou pra os transmitir
pela rede (ou voltar um backup com eles - isso é POSSÌVEL TAMBÉM !!) e os
aplicar PROD já gerou outros 500, que vc tenha aplicar aí PROD já gerou nesse
intervalo outros tantos.... Ninguém ganha essa corrida não - só mesmo se o
volume da sua base é mediano, e/ou se vc tem uma Produção que só gera archives
intensamente durante algumas horas de pico do dia (digamos) é que é Viável se
interromper o standby por longos períodos para que ele possa ser aberto
(read-only, que seja) - num caso assim, em tese vc teria as horas da Noite pra
eliminar esse gap, receber e aplicar os archives faltantes todos...
Nem preciso dizer que :
a) ULULANTEMENTE ÓBVIO, no que vc interrompe a sincronização, não só vc está
gerando um gap de archives mas TAMBÉM necessariamente vc tá com dados
DESATUALIZADOS - nem preciso dizer que em muitas situações isso é Inaceitável
e
b) Óbvio #2, afora a possibilidade de backup com remoção, os archives não
enviados/aplicados AINDA TEM QUE PERMANECER no ambiente PROD, e isso **** VAI
*** consumir espaço em disco, é claro, Além de criar uma demanda dessesperada
por BANDA DE REDE na hora que vc os for enviar - teu hardware ** tem ** que
Suportar se vc for pensar nisso...
Tá claro ? Então sim, a sua frase :
" A diferença que vejo da option Active DAtaguard eh que voce *SEMPRE* tera seu
standby sincronizado com o servidor primario, mesmo que ele esteja aberto para
a utilização dos usuarios em modo ready-only."
Está perfeita, é isso mesmo, a Documentação Oracle mesmo nos diz :
" Opening a Physical Standby Database
A physical standby database can be opened for read-only access and used to
offload queries from a primary database.
If a license for the Oracle Active Data Guard option has been purchased, a
physical standby database can be open while redo apply is active. This
capability is known as real-time query. See Section 9.2.1 for more details.
If a license for the Oracle Active Data Guard option has not been purchased, a
physical standby database cannot be open while redo apply is active, so the
following rules must be observed when opening a physical standby database
instance or starting redo apply:
Redo apply must be stopped before any physical standby database instance is
opened.
If one or more physical standby instances are open, those instances must be
closed before starting redo apply.
"
okdoc ? Espero que tenha ficado CLARO a importância de vc ter um banco aberto
sem interromper a sincronização num caso de PROD extremamente ativo - eu já
estive em algumas situações de RACE CONDITION, onde o gap/intervalo de archives
a transmitir+aplicar era grande e PROD era intensamente ativo, acredite que NÃO
É uma situação confortável...
Agora respondendo sobre o Dataguard Lógico/Logical Standby : o Conceito básico
desse cara é (vide DOcumentação e http://www.orafaq.com/node/957 como refs) é
que os SQLs gerados / executados em PROD são ENVIADOS e RE-EXECUTADOS no banco
standby - Obviamente, para que um banco possa processar SQLs em tabelas
não-internas do RDBMS ele ** TEM ** que estar Aberto, sim ?? Isso é
conceitual...
Então SIM, é verdade que um banco standby lógico pode ser em tese consultado
(modo READ ONLY, óbvio) por usuários finais, sim.... Qual é o senão, o 'ponto
oculto' do logical standby ?? Bem óbvio : como eu falei, ** cada SQL **
contendo DMLs VAI SER REPROCESSADO : imagine aqueles SQLs complexos, com
UPDATEs os mais loucos, que leva meia horas pra processar em PROD - ele VAI ser
reprocessado no standby, e VAI (no mínimo!!) levar essa mesma meia hora.... OU
SEJA, vc tem um banco-réplica que tanto pode estar up-to-date em questão de
minutos QUANTo pode estar atrasado meia hora, uma hora, sei lá, Dependendo de
quanto tempo levou o SQL a ser reprocessado... INSTÁVEL é o mínimo que eu
chamaria isso... O paper oficial em
http://www.oracle.com/technetwork/database/features/availability/active-faq-098935.html
não fala isso claramente, preferindo focar na maior facilidade administrativa
e de setup do Active Data Guard mas IMHO a diferença PRINCIPAL e CRUCIAL entre
um Logical Standby versus um Active data Guard Físico é essa : embora ambos
permitam desviar o overhead de prod possibilitando queries no standby, com o
ADG vc pode se assegurar de que a diferença de dados para as tais queries é
mínima entre prod x standby, pois como vc NÂO está reprocessando SQLs, vc NÃO
vai ter que parsear, montar planos, fazer os trocentos I/Os que os DMLs
exigiram em PROD ** novamente ** no banco standby , o que normalmente é
IMPREVISÍVEL - às vezes os SQLs foram curtos e a diff ficou pequena, às vezes
os SQLs foram longos e demorados aí vc tem uma diff enorme...
E nem preciso dizer, opcionalmente
(http://www.oracle.com/technetwork/database/availability/active-data-guard-wp-12c-1896127.pdf
mostra no 12c mas isso funciona mais ou menos igual pra todo dataguard) vc
pode ter o dataguard em ZERO DATA LOSS MODE, aí vc sabe que vai ser ZERO a
diferença de dados entre PROD x STANDBY, se o seu hardware permitir.... OK ?
Finalmente, a resposta derradeira : lógico que sim, caso a sua demanda não
seja de , digamos, poucos minutos (ou ZERO) de diferença de dados entre PROD x
STANDBY, sim, vc pode restaurar no server standby o backup de PROD para
atualizar o banco standby, pode ter essa banco temporariamente com a
atualização pausada (OU MESMO pode ter snapshot dele, sim, permitindo até mesmo
abertura READ WRITE num caso de emergência) mas isso DESDE QUE vc tenha tempo
hábil pra voltar o backup/reaplicar os archives/refazer o standby como for o
caso - como creio que ficou Claro, isso tudo LEVA TEMPO, vc tem que ter uma
janela viável pra fazer isso enquanto PROD não está gerando alterações - num
ambiente quase 24x7 OU que seja de grande volume, óbvio que um standby desse
tipo *** NUNCA *** vai ficar atualizado, pois até se fazer todo o procedimento
no standby server PROD já gerou trocentos dados novos que não vai estar
presentes no standby....
[]s
Chiappa #yiv7722255283 #yiv7722255283 -- #yiv7722255283ygrp-mkp {border:1px
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv7722255283
#yiv7722255283ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv7722255283
#yiv7722255283ygrp-mkp #yiv7722255283hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv7722255283 #yiv7722255283ygrp-mkp #yiv7722255283ads
{margin-bottom:10px;}#yiv7722255283 #yiv7722255283ygrp-mkp .yiv7722255283ad
{padding:0 0;}#yiv7722255283 #yiv7722255283ygrp-mkp .yiv7722255283ad p
{margin:0;}#yiv7722255283 #yiv7722255283ygrp-mkp .yiv7722255283ad a
{color:#0000ff;text-decoration:none;}#yiv7722255283 #yiv7722255283ygrp-sponsor
#yiv7722255283ygrp-lc {font-family:Arial;}#yiv7722255283
#yiv7722255283ygrp-sponsor #yiv7722255283ygrp-lc #yiv7722255283hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv7722255283
#yiv7722255283ygrp-sponsor #yiv7722255283ygrp-lc .yiv7722255283ad
{margin-bottom:10px;padding:0 0;}#yiv7722255283 #yiv7722255283actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv7722255283
#yiv7722255283activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv7722255283
#yiv7722255283activity span {font-weight:700;}#yiv7722255283
#yiv7722255283activity span:first-child
{text-transform:uppercase;}#yiv7722255283 #yiv7722255283activity span a
{color:#5085b6;text-decoration:none;}#yiv7722255283 #yiv7722255283activity span
span {color:#ff7900;}#yiv7722255283 #yiv7722255283activity span
.yiv7722255283underline {text-decoration:underline;}#yiv7722255283
.yiv7722255283attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv7722255283 .yiv7722255283attach div a
{text-decoration:none;}#yiv7722255283 .yiv7722255283attach img
{border:none;padding-right:5px;}#yiv7722255283 .yiv7722255283attach label
{display:block;margin-bottom:5px;}#yiv7722255283 .yiv7722255283attach label a
{text-decoration:none;}#yiv7722255283 blockquote {margin:0 0 0
4px;}#yiv7722255283 .yiv7722255283bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv7722255283
.yiv7722255283bold a {text-decoration:none;}#yiv7722255283 dd.yiv7722255283last
p a {font-family:Verdana;font-weight:700;}#yiv7722255283 dd.yiv7722255283last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv7722255283
dd.yiv7722255283last p span.yiv7722255283yshortcuts
{margin-right:0;}#yiv7722255283 div.yiv7722255283attach-table div div a
{text-decoration:none;}#yiv7722255283 div.yiv7722255283attach-table
{width:400px;}#yiv7722255283 div.yiv7722255283file-title a, #yiv7722255283
div.yiv7722255283file-title a:active, #yiv7722255283
div.yiv7722255283file-title a:hover, #yiv7722255283 div.yiv7722255283file-title
a:visited {text-decoration:none;}#yiv7722255283 div.yiv7722255283photo-title a,
#yiv7722255283 div.yiv7722255283photo-title a:active, #yiv7722255283
div.yiv7722255283photo-title a:hover, #yiv7722255283
div.yiv7722255283photo-title a:visited {text-decoration:none;}#yiv7722255283
div#yiv7722255283ygrp-mlmsg #yiv7722255283ygrp-msg p a
span.yiv7722255283yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv7722255283
.yiv7722255283green {color:#628c2a;}#yiv7722255283 .yiv7722255283MsoNormal
{margin:0 0 0 0;}#yiv7722255283 o {font-size:0;}#yiv7722255283
#yiv7722255283photos div {float:left;width:72px;}#yiv7722255283
#yiv7722255283photos div div {border:1px solid
#666666;min-height:62px;overflow:hidden;width:62px;}#yiv7722255283
#yiv7722255283photos div label
{color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv7722255283
#yiv7722255283reco-category {font-size:77%;}#yiv7722255283
#yiv7722255283reco-desc {font-size:77%;}#yiv7722255283 .yiv7722255283replbq
{margin:4px;}#yiv7722255283 #yiv7722255283ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv7722255283 #yiv7722255283ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv7722255283
#yiv7722255283ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv7722255283
#yiv7722255283ygrp-mlmsg select, #yiv7722255283 input, #yiv7722255283 textarea
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv7722255283
#yiv7722255283ygrp-mlmsg pre, #yiv7722255283 code {font:115%
monospace;}#yiv7722255283 #yiv7722255283ygrp-mlmsg *
{line-height:1.22em;}#yiv7722255283 #yiv7722255283ygrp-mlmsg #yiv7722255283logo
{padding-bottom:10px;}#yiv7722255283 #yiv7722255283ygrp-msg p a
{font-family:Verdana;}#yiv7722255283 #yiv7722255283ygrp-msg
p#yiv7722255283attach-count span {color:#1E66AE;font-weight:700;}#yiv7722255283
#yiv7722255283ygrp-reco #yiv7722255283reco-head
{color:#ff7900;font-weight:700;}#yiv7722255283 #yiv7722255283ygrp-reco
{margin-bottom:20px;padding:0px;}#yiv7722255283 #yiv7722255283ygrp-sponsor
#yiv7722255283ov li a {font-size:130%;text-decoration:none;}#yiv7722255283
#yiv7722255283ygrp-sponsor #yiv7722255283ov li
{font-size:77%;list-style-type:square;padding:6px 0;}#yiv7722255283
#yiv7722255283ygrp-sponsor #yiv7722255283ov ul {margin:0;padding:0 0 0
8px;}#yiv7722255283 #yiv7722255283ygrp-text
{font-family:Georgia;}#yiv7722255283 #yiv7722255283ygrp-text p {margin:0 0 1em
0;}#yiv7722255283 #yiv7722255283ygrp-text tt {font-size:120%;}#yiv7722255283
#yiv7722255283ygrp-vital ul li:last-child {border-right:none
!important;}#yiv7722255283
