Re: [oracle_br] Sincronismo standby

2018-05-11 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Espero que não seja, senão essas consultas ** TODAS ** com V$ que ele faz vão 
pro saco : em RAC deberia ser GV$ e levar em conta o INST_ID ...

[]s

  Chiappa

Re: [oracle_br] Sincronismo standby

2018-05-11 Por tôpico Junior Cesar juniorcesa...@yahoo.com.br [oracle_br] 
Opa mano, tudo bem?
Uma duvida, é rac?
Abs,
   Em sexta-feira, 11 de maio de 2018 14:54:09 BRT, Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]  escreveu:  
 
     

Senhores, boa tarde.
Cenario:
Oracle 11gR2 - Um primary db e um physical standby DB (OPEN WITH APPLY) - 
Active DG

Estou com um problema em uma configuração de DataGuard. Utilizamos uma query 
para monitorar o sincronismo entre o primary e o standby database. Temos em 
torno de 20 dataguards, e o monitoramento está ok e funciona bem em todos 
ambientes, *MAS EM UM AMBIENTE ESPECIFICO* a monitoração está alertando o tempo 
inteiro enquanto não deveria alertar, segue:

NO PRIMARY DATABASE:
SELECT  DATABASE_MODE       , SUBSTR (RECOVERY_MODE, 1, 8) AS "RECOV_MODE"    , 
PROTECTION_MODE AS "PROTECTION_MODE"       , SUBSTR (DESTINATION, 1, 10) AS 
"DEST"       , ARCHIVED_SEQ#        , APPLIED_SEQ#       , SUBSTR 
(SYNCHRONIZATION_STATUS, 1, 8) AS "SYNC_STATUS"       , SYNCHRONIZED AS "SYNC"  
     , GAP_STATUS    , STATUSFROM     V$ARCHIVE_DEST_STATUSWHERE    TYPE <> 
'LOCAL'/


DATABASE_MODE  |RECOV_MO|PROTECTION_MODE     |DEST      
|ARCHIVED_SEQ#|APPLIED_SEQ#|SYNC_STA|SYN|GAP_STATUS              
|STATUS---|||--|-|||---||-OPEN_READ-ONLY
 |MANAGED |MAXIMUM PERFORMANCE |sdemp_std |       139745|      139659|CHECK 
CO|NO |NO GAP                  |VALID


Se voces perceberem o valor da coluna ARCHIVED_SEQ# (primary) = 139744e o valor 
da coluna APPLIED_SEQ# (standby) = 139659
Será visto que existe uma diferença grande entre ambos. Porém, se eu realizar a 
consulta abaixo, irá me mostrar o seguinte:

QUery executada no STANDBY DATABASE:

SELECT 'Last applied  : '                         Logs,       
To_char(next_time, 'DD/MM/YY HH24:MI:SS') TimeFROM   v$archived_logWHERE  
sequence# = (SELECT Max(sequence#)                      FROM   v$archived_log   
                  WHERE  applied = 'YES')UNIONSELECT 'Last received : '         
                Logs,       To_char(next_time, 'DD/MM/YY HH24:MI:SS') TimeFROM  
 v$archived_logWHERE  sequence# = (SELECT Max(sequence#)                    
FROM   v$archived_log);

LOGS             TIME -Last applied  :  
11/05/18 14:40:37Last received :  11/05/18 14:40:37

se eu fizer um outro select no standby:
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)--        139745

Ou seja, a ultima sequence aplicada no standby bate com o do primary database.

Agora analisando o alert.log do physical standby:


Media Recovery Log /sdemp/arch/u01/archives/sdemp_1_139744_847202734.arcMedia 
Recovery Waiting for thread 1 sequence 139745 (in transit)Fri May 11 14:40:37 
2018RFS[27]: Selected log 8 for thread 1 sequence 139746 dbid 843466460 branch 
847202734Fri May 11 14:40:37 2018Archived Log entry 142021 added for thread 1 
sequence 139745 ID 0x38b9c4c7 dest 1:Fri May 11 14:40:38 2018Media Recovery Log 
/sdemp/arch/u01/archives/sdemp_1_139745_847202734.arcMedia Recovery Waiting for 
thread 1 sequence 139746 (in transit)


Ou seja, o recebimento e o apply está ocorrendo no standby, porém o 
monitoramento no primary database não está OK.
Obs: Esse comportamento só ocorre nesse ambiente, em mais de 10 configurações 
de DG, o APPLIED_SEQ# bate com o ARCHIVED_SEQ#. 

Esse problema está nos dando dor de cabeça por o monitoramento está alertando e 
enviando chamado o tempo inteiro. Se alguémm puder ajudar eu agradeço.

  #yiv6967922749 #yiv6967922749 -- #yiv6967922749ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv6967922749 
#yiv6967922749ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv6967922749 
#yiv6967922749ygrp-mkp #yiv6967922749hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv6967922749 #yiv6967922749ygrp-mkp #yiv6967922749ads 
{margin-bottom:10px;}#yiv6967922749 #yiv6967922749ygrp-mkp .yiv6967922749ad 
{padding:0 0;}#yiv6967922749 #yiv6967922749ygrp-mkp .yiv6967922749ad p 
{margin:0;}#yiv6967922749 #yiv6967922749ygrp-mkp .yiv6967922749ad a 
{color:#ff;text-decoration:none;}#yiv6967922749 #yiv6967922749ygrp-sponsor 
#yiv6967922749ygrp-lc {font-family:Arial;}#yiv6967922749 
#yiv6967922749ygrp-sponsor #yiv6967922749ygrp-lc #yiv6967922749hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv6967922749 
#yiv6967922749ygrp-sponsor #yiv6967922749ygrp-lc .yiv6967922749ad 
{margin-bottom:10px;padding:0 0;}#yiv6967922749 #yiv6967922749actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv6967922749 
#yiv6967922749activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv6967922749
 #yiv6967922749activity span {font-weight:700;}#yiv6967922749 
#yiv6967922749activity span:first-child 
{text-transform:uppercase;}#yiv6967922749 #yiv6967922749activity span a

[oracle_br] Sincronismo standby

2018-05-11 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
Senhores, boa tarde.
Cenario:
Oracle 11gR2 - Um primary db e um physical standby DB (OPEN WITH APPLY) - 
Active DG

Estou com um problema em uma configuração de DataGuard. Utilizamos uma query 
para monitorar o sincronismo entre o primary e o standby database. Temos em 
torno de 20 dataguards, e o monitoramento está ok e funciona bem em todos 
ambientes, *MAS EM UM AMBIENTE ESPECIFICO* a monitoração está alertando o tempo 
inteiro enquanto não deveria alertar, segue:

NO PRIMARY DATABASE:
SELECT  DATABASE_MODE       , SUBSTR (RECOVERY_MODE, 1, 8) AS "RECOV_MODE"    , 
PROTECTION_MODE AS "PROTECTION_MODE"       , SUBSTR (DESTINATION, 1, 10) AS 
"DEST"       , ARCHIVED_SEQ#        , APPLIED_SEQ#       , SUBSTR 
(SYNCHRONIZATION_STATUS, 1, 8) AS "SYNC_STATUS"       , SYNCHRONIZED AS "SYNC"  
     , GAP_STATUS    , STATUSFROM     V$ARCHIVE_DEST_STATUSWHERE    TYPE <> 
'LOCAL'/


DATABASE_MODE  |RECOV_MO|PROTECTION_MODE     |DEST      
|ARCHIVED_SEQ#|APPLIED_SEQ#|SYNC_STA|SYN|GAP_STATUS              
|STATUS---|||--|-|||---||-OPEN_READ-ONLY
 |MANAGED |MAXIMUM PERFORMANCE |sdemp_std |       139745|      139659|CHECK 
CO|NO |NO GAP                  |VALID


Se voces perceberem o valor da coluna ARCHIVED_SEQ# (primary) = 139744e o valor 
da coluna APPLIED_SEQ# (standby) = 139659
Será visto que existe uma diferença grande entre ambos. Porém, se eu realizar a 
consulta abaixo, irá me mostrar o seguinte:

QUery executada no STANDBY DATABASE:

SELECT 'Last applied  : '                         Logs,       
To_char(next_time, 'DD/MM/YY HH24:MI:SS') TimeFROM   v$archived_logWHERE  
sequence# = (SELECT Max(sequence#)                      FROM   v$archived_log   
                  WHERE  applied = 'YES')UNIONSELECT 'Last received : '         
                Logs,       To_char(next_time, 'DD/MM/YY HH24:MI:SS') TimeFROM  
 v$archived_logWHERE  sequence# = (SELECT Max(sequence#)                    
FROM   v$archived_log);

LOGS             TIME -Last applied  :  
11/05/18 14:40:37Last received :  11/05/18 14:40:37

se eu fizer um outro select no standby:
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)--        139745

Ou seja, a ultima sequence aplicada no standby bate com o do primary database.

Agora analisando o alert.log do physical standby:


Media Recovery Log /sdemp/arch/u01/archives/sdemp_1_139744_847202734.arcMedia 
Recovery Waiting for thread 1 sequence 139745 (in transit)Fri May 11 14:40:37 
2018RFS[27]: Selected log 8 for thread 1 sequence 139746 dbid 843466460 branch 
847202734Fri May 11 14:40:37 2018Archived Log entry 142021 added for thread 1 
sequence 139745 ID 0x38b9c4c7 dest 1:Fri May 11 14:40:38 2018Media Recovery Log 
/sdemp/arch/u01/archives/sdemp_1_139745_847202734.arcMedia Recovery Waiting for 
thread 1 sequence 139746 (in transit)


Ou seja, o recebimento e o apply está ocorrendo no standby, porém o 
monitoramento no primary database não está OK.
Obs: Esse comportamento só ocorre nesse ambiente, em mais de 10 configurações 
de DG, o APPLIED_SEQ# bate com o ARCHIVED_SEQ#. 

Esse problema está nos dando dor de cabeça por o monitoramento está alertando e 
enviando chamado o tempo inteiro. Se alguémm puder ajudar eu agradeço.