Re: [oracle_br] Re: Upgrade 9i para 12cR1
Entendi, São verdadeiros "monstros" de processamento, só que, ao meu ver, é um ambiente meio "caro" de manter, Mas se tem parceiro, então deve andar bem, torna a vida mais simples 2018-05-11 15:43 GMT-03:00 jlchia...@yahoo.com.br [oracle_br] < oracle_br@yahoogrupos.com.br>: > > > É verdade que em alguns casos um hardware x86-64 com Linux pode dar o > mesmo nível de performance que um Power RISC (que é onde se roda AIX, > normalmente), sim, E que via de regra é mais fácil se encontrar ref e > expertise para Linux do que pra AIX ... Porém, sabemos lá se na Empresa do > colega isso é verdade, de repente eles tem uma Parceria com a IBM, sabe-se > lá... > > Mas se ele for mudar de servidor sempre vale a pena uma Boa pesquisa pra > ver se outros provedores podem preencher as necessidades dele, sim sim... > > []s > > Chiappa > >
Re: [oracle_br] Sincronismo standby
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
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
{color:#5085b6;text-decoration:none;}#yiv6967922749 #yiv69679227
Re: [oracle_br] Re: Upgrade 9i para 12cR1
É verdade que em alguns casos um hardware x86-64 com Linux pode dar o mesmo nível de performance que um Power RISC (que é onde se roda AIX, normalmente), sim, E que via de regra é mais fácil se encontrar ref e expertise para Linux do que pra AIX ... Porém, sabemos lá se na Empresa do colega isso é verdade, de repente eles tem uma Parceria com a IBM, sabe-se lá... Mas se ele for mudar de servidor sempre vale a pena uma Boa pesquisa pra ver se outros provedores podem preencher as necessidades dele, sim sim... []s Chiappa
Re: [oracle_br] Re: Upgrade 9i para 12cR1
Entao esse cliente tem parceria forte com a IBM, tudo deles eh da IBM (menos o
rdbms), servidor eh uma power 8. Todos os servidores sao AIX, nao existe essa
possibilidade infelizmente.
Em sexta-feira, 11 de maio de 2018 15:29:28 BRT, angelo
angelolis...@gmail.com [oracle_br] escreveu:
uma pergunta de curioso,
O negocio dele não comporta rodar o Oracle no Linux ? Já que ta pensando em
atualizar o sistema operacional...
Pois em matéria de SO, atualizado está e uma boa galera compreende mais, se
comparado ao AIX que nem todo mundo acessa e o hardware é restrito ( ibm )
On 10 May 2018 at 13:35, Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]
wrote:
Pessoal obrigado pelas explicações.
Além dessa base 9i, existem mais 4 bases na versão 10gR2 nesse mesmo servidor.
Então o que eu entendo qual seria o procedimento mais simples:
a) Atualizar o sistema operacional para uma versão compatível com a versão 12c
e a 10gR2 (vou olhar no metalink se existe, talvez o AIX 6 seja)
b) Adicionar um novo file system e instalar o Oracle 12cRx em um novo
oracle_home nesse file system
c) Criar um banco vazio 12cRx
d) realizar o export dos dados 9i
e) importar 12xRx
Vou levar todas as considerações mencionadas acima, tanto realizar isso em um
servidor de teste e verifiar as questões dos clients de conexão.
Obrigado :)
Em quarta-feira, 9 de maio de 2018 18:57:01 BRT, jlchia...@yahoo.com.br
[oracle_br] escreveu:
E uma obs final : tudo fica MUITO, mas MUUUITO MAIS fácil E seguro se o upgrade
puder ser feito num outro servidor pra onde vc transfira os arquivos todos do
database 9i , tendo antes já instalodo lá a nova versão de SO e a nova versão
do RDBMS . Se o cliente não tava pensando nisso, insista : só se ele fechar
questão de modo absoluto é que aí não tem jeito e vc terá que assumir os
riscos...
[]s
Chiappa
#yiv1514955474 #yiv1514955474 -- #yiv1514955474ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv1514955474
#yiv1514955474ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv1514955474
#yiv1514955474ygrp-mkp #yiv1514955474hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv1514955474 #yiv1514955474ygrp-mkp #yiv1514955474ads
{margin-bottom:10px;}#yiv1514955474 #yiv1514955474ygrp-mkp .yiv1514955474ad
{padding:0 0;}#yiv1514955474 #yiv1514955474ygrp-mkp .yiv1514955474ad p
{margin:0;}#yiv1514955474 #yiv1514955474ygrp-mkp .yiv1514955474ad a
{color:#ff;text-decoration:none;}#yiv1514955474 #yiv1514955474ygrp-sponsor
#yiv1514955474ygrp-lc {font-family:Arial;}#yiv1514955474
#yiv1514955474ygrp-sponsor #yiv1514955474ygrp-lc #yiv1514955474hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv1514955474
#yiv1514955474ygrp-sponsor #yiv1514955474ygrp-lc .yiv1514955474ad
{margin-bottom:10px;padding:0 0;}#yiv1514955474 #yiv1514955474actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv1514955474
#yiv1514955474activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv1514955474
#yiv1514955474activity span {font-weight:700;}#yiv1514955474
#yiv1514955474activity span:first-child
{text-transform:uppercase;}#yiv1514955474 #yiv1514955474activity span a
{color:#5085b6;text-decoration:none;}#yiv1514955474 #yiv1514955474activity span
span {color:#ff7900;}#yiv1514955474 #yiv1514955474activity span
.yiv1514955474underline {text-decoration:underline;}#yiv1514955474
.yiv1514955474attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv1514955474 .yiv1514955474attach div a
{text-decoration:none;}#yiv1514955474 .yiv1514955474attach img
{border:none;padding-right:5px;}#yiv1514955474 .yiv1514955474attach label
{display:block;margin-bottom:5px;}#yiv1514955474 .yiv1514955474attach label a
{text-decoration:none;}#yiv1514955474 blockquote {margin:0 0 0
4px;}#yiv1514955474 .yiv1514955474bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv1514955474
.yiv1514955474bold a {text-decoration:none;}#yiv1514955474 dd.yiv1514955474last
p a {font-family:Verdana;font-weight:700;}#yiv1514955474 dd.yiv1514955474last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv1514955474
dd.yiv1514955474last p span.yiv1514955474yshortcuts
{margin-right:0;}#yiv1514955474 div.yiv1514955474attach-table div div a
{text-decoration:none;}#yiv1514955474 div.yiv1514955474attach-table
{width:400px;}#yiv1514955474 div.yiv1514955474file-title a, #yiv1514955474
div.yiv1514955474file-title a:active, #yiv1514955474
div.yiv1514955474file-title a:hover, #yiv1514955474 div.yiv1514955474file-title
a:visited {text-decoration:none;}#yiv1514955474 div.yiv1514955474photo-title a,
#yiv1514955474 div.yiv1514955474photo-title a:active, #yiv1514955474
div.yiv1514955474photo-title a:hover, #yiv1514955474
div.yiv1514955474photo-title a:visited {text-decoration:none;}#yiv1514955474
div
[oracle_br] Re: Sincronismo standby
Bom, com CERTEZA não parece ser algo simples, não : acho que vc vai acabar tendo que abrir um Chamado no Suporte Oracle mesmo... De momento, eu recomendo : a. cheque se de repente esse banco não está numa encarnação diferente, ou se no passado ele foi convertido de snapshot standby de volta para physical standby , tipo o que é mostrado na nota metalink/mos V$ARCHIVE_GAP doesn't show a existing GAP (Doc ID 974730.1) : claro, aqui ele está reportando BUG causando a V$ARCHIVE_GAP não funcionar, mas não é impossível que um dos bugs influencie alguma outra V$ b. execute os script de verificação e os passos indicados nas notas metalink/mos "Troubleshooting Data Guard" (Doc ID 237213.1) e (principalmente) na "Data Guard Physical Standby - Configuration Health Check" (Doc ID 1581388.1)... Em especial também faz uma consulta com SELECT * na V$DATABASE, V$INSTANCE, v$dataguard_status e views relacionadas procurando por eventuais diferenças nos databases : afora algumas coisas específicas pra standby (como a ROLE, o STATUS de abertura, etc) o resto Deveria ser similar nos dois databases c. não deveria acontecer, mas TALVEZ (por qquer motivo) vc tenha caído numa situação onde alguma sequência de archive mais antiga tenha falhado no envio ou na aplicação mas as subsequentes aplicaram ok : faz (no SQL DEVELOPER, já que vai ser uma consulta com muitas colunas e linhas) SELECT * ORDER BY SEQUENCE# nas views todas relacionadas a redo log ao invés de pedir o MAX como os scripts mostram ===> SE nenhuma dessas checagens/destes procedimentos mostrou nada, tua Alternativa Única é mesmo um chamado no Suporte Oracle, creio... []s Chiappa
Re: [oracle_br] Re: Upgrade 9i para 12cR1
uma pergunta de curioso, O negocio dele não comporta rodar o Oracle no Linux ? Já que ta pensando em atualizar o sistema operacional... Pois em matéria de SO, atualizado está e uma boa galera compreende mais, se comparado ao AIX que nem todo mundo acessa e o hardware é restrito ( ibm ) On 10 May 2018 at 13:35, Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] wrote: > > > Pessoal obrigado pelas explicações. > > Além dessa base 9i, existem mais 4 bases na versão 10gR2 nesse mesmo > servidor. Então o que eu entendo qual seria o procedimento mais simples: > > a) Atualizar o sistema operacional para uma versão compatível com a versão > 12c e a 10gR2 (vou olhar no metalink se existe, talvez o AIX 6 seja) > > b) Adicionar um novo file system e instalar o Oracle 12cRx em um novo > oracle_home nesse file system > > c) Criar um banco vazio 12cRx > > d) realizar o export dos dados 9i > > e) importar 12xRx > > > Vou levar todas as considerações mencionadas acima, tanto realizar isso em > um servidor de teste e verifiar as questões dos clients de conexão. > > Obrigado :) > > > > Em quarta-feira, 9 de maio de 2018 18:57:01 BRT, jlchia...@yahoo.com.br > [oracle_br] escreveu: > > > > > E uma obs final : tudo fica MUITO, mas MUUUITO MAIS fácil E seguro se o > upgrade puder ser feito num outro servidor pra onde vc transfira os > arquivos todos do database 9i , tendo antes já instalodo lá a nova versão > de SO e a nova versão do RDBMS . Se o cliente não tava pensando nisso, > insista : só se ele fechar questão de modo absoluto é que aí não tem jeito > e vc terá que assumir os riscos... > > []s > >Chiappa > > >
[oracle_br] Sincronismo standby
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.
