Re: [oracle_br] Re: PatchSet Full 11.2.0.1.0 para o 11.2.0.4.0

2015-06-15 Por tôpico jlchia...@yahoo.com.br [oracle_br]
Exatamente isso, com certeza Homologação de fornecedor é uma das causas de 
força maior que impedem a ida direto pra versão mais recente de uma vez... Só, 
como eu disse, fica ** ligadíssimo ** nos Cronogramas da certificação do SAP 
com Oracle 12c, tal como mostrado em 
http://www.oracle.com/us/solutions/sap/oradb12c-sap-certification-roadmap-2506113.pdf
 , http://www.oracle.com/us/solutions/sap/sap-database/index.html e 
https://blogs.oracle.com/UPGRADE/entry/sap_is_now_certified_on 
 

  []s
  
Chiappa


[oracle_br] Re: ORA-12569: TNS:packet checksum failure

2015-06-15 Por tôpico jlchia...@yahoo.com.br [oracle_br]
Seguinte : bem claramente a msgs indica que vc teve uma perda temporária de 
conexão na sua rede - o ponto é, isso PODE ter sido causado por Firewall/filtro 
de pacotes, OU pela sua rede OU mesmo por bug no software de Rede Oracle, 
talvez até mesmo um BUG já solucionado nas versões mais recentes...
  Para vc tentar eliminar possibilidades, eu recomendo que :
 

  a. nesse mesmo servidor onde tá rodando o 9ir2, crie uma Outra instância 9ir2 
e uma nova instância 11gr2 , fazendo ambas as novas instâncias terem view 
materializadas nesse mesmo banco 11gr2 
  
  b. em algum OUTRO servidor (teste, homologação, o que tiver) crie uma nova 
instãncia 9ir2 acessando numa view materializada esse mesmo banco 11gr2
  
  c. ligue o TRACE DE REDE na camada de rede Oracle
  
  d. estabeleça algum tipo de trace de rede geral /  monitoração entre as 
máquinas envolvidas : a Oracle até disponibiliza umas coisinhas pra isso, na 
figura do OSWatcher, mas com certeza teu pessoal de rede pode lançar mão de 
ferramentas mais especialistas, como o cacti (que num Cliente anterior o 
pessoal de Rede usou com muito sucesso)
  
  e. como Teste contra bugs referentes à qtdade de colunas/array size, tente ao 
invés de SELECT * fazer SELECT poucascolunas
  
  ==> A idéia é tentar isolar se é uma issue da sua rede, ou da versão 9ir2, ou 
do 9i NESSE SEU HARDWARE específico... Algumas refs/exemplos  pra te ajudar 
nesses Requests acima são as notas metalink "Troubleshooting guide for 
ORA-12592 / TNS-12592: TNS: bad packet" (Doc ID 373431.1), "Connections via 
Firewall Fail and Report ORA-12569 TNS packet checksum failure in Trace" (Doc 
ID 976703.1) , "Getting ORA-12569: TNS:Packet Checksum Failure While Trying To 
Connect Through Client". (Doc ID 257793.1) e ""10.2.0.x Oracle Database and 
Networking Older Patches for Microsoft Platforms" (Doc ID 1207176.1)
  
   []s
   
 Chiappa


Re: [oracle_br] Re: PatchSet Full 11.2.0.1.0 para o 11.2.0.4.0

2015-06-15 Por tôpico Andre Luiz Reis Marques aandre...@yahoo.com.br [oracle_br]
Bom dia jlchiappa,
Obrigado pela orientação:
Sim:
A migração para o  12c  esta sendo planejada.  Aqui na empresa eu tenho 
separado os ambientes SAP e Nao SAP, os nao SAP e o foco principal, pois em 
relacao ao SAP nos temos que respeitar o procedimento SAP em relacao a 
atualização.
 Atenciosamente, 
André Luiz R. Marques 
Administrador de Banco de Dados - SQL Server/OracleTel: (21) 99978-4564 Evite 
imprimir. Colabore com o Meio Ambiente! "Embora ninguém possa voltar atrás e 
fazer um novo começo, qualquer um pode
começar agora e fazer um novo fim."    Chico Xavier

 


 Em Sexta-feira, 12 de Junho de 2015 15:34, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
   

     Opa, então : desde o 11g os patchsets passaram a ser full-instalations 
(portanto NÃO exigindo absolutamente a presença de coisa alguma), e desde muito 
antes disso eles já eram Cumulativos ( o que garante que TODOS os bugfixes 
introduzidos nos patchsets anteriores de uma versão VÃO estar presentes no 
patchset mais recente) - então, no seu caso, vc pode SIM confiar que PODE 
instalar o patchset 11.2.0.4 em cima do 11.2.0.1, ou 11.2.0.2 ou 11.2.0.3, OU 
mesmo numa máquina SEM binário Oraclke algum, E pode confiar QUE 
necessariamente os bugfixes introduzidos nos patchsets 11.2.0.2 E 11.2.0.3 vão 
estar SIM no 11.2.0.4... Essas informações vc confirma tanto no README do 
patchset quanto nas notas metalink relacionadas à patchsets e bugfixes, 
consulta lá que vc acha...
 Sobre recomendações, eu diria :  - não esqueça que para ficar Totalmente 
Atualizado, *** depois *** de ter Aplicado o patchset 11.2.0.4 vc TEM que 
aplicar os patches emergenciais mais recentes, seja com o conjunto do PSU 
(Patch Set Update, contém todos os patches emergenciais a se aplicar em cima do 
patchset), seja com o CPU (Critical Patch Update, contém os patches 
emergenciais mais críticos apenas). Lembro também que via de regra, uma vez 
optado pelo PSU ou CPU, daí pra frente vc tem que continuar aplicando aquele 
conjunto de patches emergenciais pelo qual optou  - beleza que vc está deixando 
atual/corrente/seguro seus databases 11gR2, isso é muito bom, e recomendado, 
mas *** IMAGINO *** que :    1. vc não está indo pro 12c neste momento porque 
ainda depende de alguma Homologação do teu Fornecedor de aplicativos, ou algum 
motivo de força maior do tipo
   E
   2. o seu Plano de teste para o 12c já está a todo vapor, vc já migrou para 
12c algum banco-teste, E está cutucando constantemente quem de direito pra 
receber a Homologação ou seja o que for que tá impedindo a ida pro 12c    ==> 
Isso pelo simples motivo que o 11gR2 já está Fora de Suporte regular (Premier 
Support), e que já está Correndo o primeiro ano grátis de Suporte Extendido : 
assim a partir do ano que vem, não tem choro nem vela, só vai ter Suporte (e 
poder baixar patchsets e abrir Chamados) quem pagar uma baba de grana pelo 
Suporte Extendido, além do que já pagou pelo Premier 
 - sim, o catálogo RMAN vai ter que ser atualizado, sim , E (óbvio) vc VAI 
aplicar nos binários do RDBMS que contém o catálogo o mesmo patchset E os 
mesmos bugs emergenciais : o Ideal é vc ter tanto o banco de catálogo quanto os 
bancos-target do RMAN na mesma exata versão/release/conjunto de patches...   
para refs, busca no metalink/my oracle support por UPGRADE CATALOG RMAN que vc 
acha várias refs, é um procedimento Relativamente simples...
 - sobre BACKUPs, que fique claro :
   1. vc TEM que ter backups reais, físicos (só export/backup lógico imho não é 
Garantia suficiente)      2. TEM que ter backup não só de cada database (e suas 
necessidades, como archives, initfiles/spfiles, controlfiles, etc) QUANTO da 
ORACLE_HOME em si      3. como vc vai ter mesmo alguma INDISPONIBILIDADE para 
aplicar o patchset e o PSU/CPU (a não ser que vc tenha RAC ou standby ou coisas 
do tipo), eu Consideraria a opção de fazer um backup COLD de cada database a 
atualizar    []s
   Chiappa  #yiv1567609963 #yiv1567609963 -- #yiv1567609963ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv1567609963 
#yiv1567609963ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv1567609963 
#yiv1567609963ygrp-mkp #yiv1567609963hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv1567609963 #yiv1567609963ygrp-mkp #yiv1567609963ads 
{margin-bottom:10px;}#yiv1567609963 #yiv1567609963ygrp-mkp .yiv1567609963ad 
{padding:0 0;}#yiv1567609963 #yiv1567609963ygrp-mkp .yiv1567609963ad p 
{margin:0;}#yiv1567609963 #yiv1567609963ygrp-mkp .yiv1567609963ad a 
{color:#ff;text-decoration:none;}#yiv1567609963 #yiv1567609963ygrp-sponsor 
#yiv1567609963ygrp-lc {font-family:Arial;}#yiv1567609963 
#yiv1567609963ygrp-sponsor #yiv1567609963ygrp-lc #yiv1567609963hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv1567609963 
#yiv1567609963ygrp-sponsor #yiv1567609963ygrp-lc .yiv1567609963ad 
{margin-bottom:10px;padding:0 0;}#yiv1567609963 #yiv1567609963actions 
{font-