[oracle_br] ORA-12569: TNS:packet checksum failure
Pessoal, Estou tentando criar uma View Materializada com DB Link, e estou recebendo o erro ORA-12569: TNS:packet checksum failure Origem Oracle9i Enterprise Edition Release 9.2.0.8.0 - (DB: BRAC) Red Hat Linux 4.8 Destino Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - (DB: PRD) HP-UX Script: create materialized view S_PFJ_CLASSE_PFJ pctfree 5 pctused 90 storage (initial 100M next 10M MAXEXTENTS UNLIMITED pctincrease 0) tablespace SNAP refresh fast start with (sysdate)+1/24 next (sysdate)+1/24 as select * from PRODUCAO.PFJ_CLASSE_PFJ@PRD.FR_LINS.GR_BERTIN; BRAC SQL> select count(*) from PRODUCAO.PFJ_CLASSE_PFJ@PRD.FR_LINS.GR_BERTIN; COUNT(*) -- 2522299 Já alterei o sqlnet.ora, e sem sucesso. Configurei outro listener para porta 1520, estou aguardando a liberação de rede para testar. Grato Ednilson Silva
[oracle_br] Re: PatchSet Full 11.2.0.1.0 para o 11.2.0.4.0
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
[oracle_br] PatchSet Full 11.2.0.1.0 para o 11.2.0.4.0
Pessoal, Tenho varias bases distribuidas em servidores AIX, versao 7.1. Preciso atualizar as mesmas, ou seja, entrar em cada servidor, baixar os arquivos e fazer a atualizacao. porem antes vou ter o cuidade de pedir um backup da maquia. Bem encontrei o guia abaixo. - Gostaria de saber se o pessoal com mais experiencia teria alguma recomendacao? - Posso passer direto da versao 11.2.01.0 direto para 11.2.0.4.0 sem ter que passer pela 11.2.0.3.0? - Lembrando que ja sei que o meu catalogo do RMAN deve ser atualizado tambem correto? Obrigado. Upgrade release e aplicação de Patch Set Update http://www.oracle.com/technetwork/pt/articles/database-performance/upgrade-e-aplicacao-psu-2331890-ptb.html http://www.oracle.com/technetwork/pt/articles/database-performance/upgrade-e-aplicacao-psu-2331890-ptb.html Upgrade release e aplicação de Patch Set Update http://www.oracle.com/technetwork/pt/articles/database-performance/upgrade-e-aplicacao-psu-2331890-ptb.html Com a consolidação do Oracle Database 12c é natural o processo de descontinuidade da versão 11g, seja pela fim do “Premier Support” ou por... Visualizar em www.oracle.com http://www.oracle.com/technetwork/pt/articles/database-performance/upgrade-e-aplicacao-psu-2331890-ptb.html Visualização pelo Yahoo
Re: [oracle_br] Re: commit não persiste
Obrigado Chiappa!!!
Em Quinta-feira, 11 de Junho de 2015 18:19, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Sim, esse tipo de erro lógico na programação DIFICILEMENTE a gente
pegaria... Realmente o ponto principal aí é quando um DELETE não encontra
ninguém , ele *** não dá mensagem de erro NENHUMA *** , isso Não É considerado
um erro, ele só retorna ZERO linhas deletadas :
=> vou especificar um filtro Absurdo, que NUNCA achará ninguém :
HR:@orcl:SQL>delete from employees where 1=2;
0 rows deleted.
HR:@orcl:SQL>set serveroutput onHR:@orcl:SQL>BEGIN 2 delete from employees
where 1=2; 3 exception 4 when others then 5 dbms_output.put_line('erro
no delete'); 6 end; 7 /
PL/SQL procedure successfully completed.
HR:@orcl:SQL>
Isso explica o fato de, antes na thread, vc ter dito que "Após isso,
consultando na mesma sessão e na outra sessão, a consulta me retorna 35
registros." : realmente esses 35 registros deviam ser a sua massa total de
testes e o DELETE *** nunca *** funcionou, nunca deletou ninguém... E como a
condição de filtro estava ERRADA para a Query com COUNT(*) também, o COUNT(*)
dava ZERO, sim
Fica a lição de :
a) para verificar o Sucesso de um DELETE sendo executado programaticamente
(execução direta via de regra a tool client já mostra qtdade de linhas), ** não
faça ** nunca um SELECT COUNT, mas sim após o DELETE capture a quantidade de
linhas processadas, via SQL%ROWCOUNT
b) rechecar sempre as condições de Comparação nos operadores Oracle (ie, NULL
nunca é nem igual nem diferente de nada, CHAR necessariamente é fixed-length
então a info a comparar TEM que ter o mesmo tamanho OU vc pede algum tipo de
trim ou concatenação, DATEs sempre contém a info de HORA então isso tem que ser
levado em contra no valor a comparar, etc, etc)...
[]s
Chiappa #yiv9092013105 #yiv9092013105 -- #yiv9092013105ygrp-mkp {border:1px
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9092013105
#yiv9092013105ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9092013105
#yiv9092013105ygrp-mkp #yiv9092013105hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv9092013105 #yiv9092013105ygrp-mkp #yiv9092013105ads
{margin-bottom:10px;}#yiv9092013105 #yiv9092013105ygrp-mkp .yiv9092013105ad
{padding:0 0;}#yiv9092013105 #yiv9092013105ygrp-mkp .yiv9092013105ad p
{margin:0;}#yiv9092013105 #yiv9092013105ygrp-mkp .yiv9092013105ad a
{color:#ff;text-decoration:none;}#yiv9092013105 #yiv9092013105ygrp-sponsor
#yiv9092013105ygrp-lc {font-family:Arial;}#yiv9092013105
#yiv9092013105ygrp-sponsor #yiv9092013105ygrp-lc #yiv9092013105hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9092013105
#yiv9092013105ygrp-sponsor #yiv9092013105ygrp-lc .yiv9092013105ad
{margin-bottom:10px;padding:0 0;}#yiv9092013105 #yiv9092013105actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9092013105
#yiv9092013105activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9092013105
#yiv9092013105activity span {font-weight:700;}#yiv9092013105
#yiv9092013105activity span:first-child
{text-transform:uppercase;}#yiv9092013105 #yiv9092013105activity span a
{color:#5085b6;text-decoration:none;}#yiv9092013105 #yiv9092013105activity span
span {color:#ff7900;}#yiv9092013105 #yiv9092013105activity span
.yiv9092013105underline {text-decoration:underline;}#yiv9092013105
.yiv9092013105attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv9092013105 .yiv9092013105attach div a
{text-decoration:none;}#yiv9092013105 .yiv9092013105attach img
{border:none;padding-right:5px;}#yiv9092013105 .yiv9092013105attach label
{display:block;margin-bottom:5px;}#yiv9092013105 .yiv9092013105attach label a
{text-decoration:none;}#yiv9092013105 blockquote {margin:0 0 0
4px;}#yiv9092013105 .yiv9092013105bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9092013105
.yiv9092013105bold a {text-decoration:none;}#yiv9092013105 dd.yiv9092013105last
p a {font-family:Verdana;font-weight:700;}#yiv9092013105 dd.yiv9092013105last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9092013105
dd.yiv9092013105last p span.yiv9092013105yshortcuts
{margin-right:0;}#yiv9092013105 div.yiv9092013105attach-table div div a
{text-decoration:none;}#yiv9092013105 div.yiv9092013105attach-table
{width:400px;}#yiv9092013105 div.yiv9092013105file-title a, #yiv9092013105
div.yiv9092013105file-title a:active, #yiv9092013105
div.yiv9092013105file-title a:hover, #yiv9092013105 div.yiv9092013105file-title
a:visited {text-decoration:none;}#yiv9092013105 div.yiv9092013105photo-title a,
#yiv9092013105 div.yiv9092013105photo-title a:active, #yiv9092013105
div.yiv9092013105photo-title a:hover, #yiv9092013105
div.yiv9092013105photo-title a:visited {text-decoration:none;}#yiv9092013105
div#yiv9092013105ygrp-mlmsg #yiv9092013105ygrp-msg p a
span.yiv90920
