Re: RES: RES: RES: RES: RES: [oracle_br] Re: delete
Nelson, na verdade a nota é bem específica, reportando sobre o bug "ACCESSING REMOTE OBJECT ON 10.2 DB THRU DBLINK FROM 9.2.0.7 DB FAILS", que acontecia em conexões entre 9.2.0.7 x 10.2.0.3 - ele já foi corrigido nos patchsets posteriores 9.2.0.8 e 10.2.0.4/acima ... Como o colega lá reportor que o banco 9i já está em 9.2.0.8 E o banco 11g está em 11.2.0.4, com certeza esse bugfiz já está presente... Já que a nota Oficial de compatibilidade entre client x server (nota "Client / Server Interoperability Support Matrix for Different Oracle Versions" (Doc ID 207303.1) ) confirma Suporte entre conexões 9.2.0.8 x 11.2.0.4 em princípio nós CREMOS que deveria funcionar sem probs - eu até Recomendei acesso ao Suporte, para que seja verificada a remota chance de re-raise desse bug ou de similares, mas isso em pricnípio É suportado e Não deveria acontecer aqui... A minha Suposição na situação reportada pelo colega não é de bug nem de incompatibilidade já detectada mas sim de questão local causando demora anormal : digamos, o tempo de resposta do acesso ao dicionário no banco remoto tá anormalmente alto, ou alguém/alguma coisa tá usando recurso (tabela, latch) necessário para o PL/SQL, que aí fica waiting []s Chiappa
Re: RES: RES: RES: RES: RES: [oracle_br] Re: delete
'Row cache instance lock (L=cache)',
>
> 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218
> 219 220 221 222 223 'QM','Row cache instance lock (M=cache)',
>
> 'QN','Row cache instance lock (N=cache)',
>
> 'QO','Row cache instance lock (O=cache)',
>
> 'QP','Row cache instance lock (P=cache)',
>
> 'QQ','Row cache instance lock (Q=cache)',
>
> 'QR','Row cache instance lock (R=cache)',
>
> 'QS','Row cache instance lock (S=cache)',
>
> 'QT','Row cache instance lock (T=cache)',
>
> 'QU','Row cache instance lock (U=cache)',
>
> 'QV','Row cache instance lock (V=cache)',
>
> 'QW','Row cache instance lock (W=cache)',
>
> 'QX','Row cache instance lock (X=cache)',
>
> 224 225 226 227 228 229 230 231 232 233 234 235 'QY','Row cache
> instance lock (Y=cache)',
>
> 'QZ','Row cache instance lock (Z=cache)','') Lockt
>
> fromV$LOCK L,
>
> V$SESSION S,
>
> SYS.USER$ U1,
>
> SYS.OBJ$ T1
>
> where L.SID = S.SID
>
> and T1.OBJ# = decode(L.ID2,0,L.ID1,1)
>
> and U1.USER# = T1.OWNER#
>
> and S.TYPE != 'BACKGROUND'
>
> order by 1,2,5
>
> /
>
> 236 237 238 239 240 241 242 243 244 245 246
>
> UsernameSID Term Table Name COMMAND
> Lock HeldLock Requested ID1 - ID2 Lock Type
>
> -- -- --
> -
> --
>
> PRODUCAO 18 pts/1 None SELECT
> ExclusiveNONE 196625-5354311 TX -
> Transaction enqueue lock
>
>
>
> SQL> SELECT /*+ RULE */
>
> 2substr(DECODE(o.kglobtyp,
>
> 3 7, 'PROCEDURE', 8, 'FUNCTION', 9, 'PACKAGE', 12, 'TRIGGER', 13,
>
> 'CLASS'),1,15) "TYPE",
>
> 4substr(o.kglnaown,1,30) "OWNER",
>
> 56substr(o.kglnaobj,1,30) "NAME",
>
> 7s.indx "SID",
>
> 8s.ksuseser "SERIAL"
>
> 9 FROM
>
> 10sys.X_$KGLOB o,
>
> 11sys.X_$KGLPN p,
>
> 12sys.X_$KSUSE s
>
> 13 WHERE
>
> 14o.inst_id = USERENV('Instance') AND
>
> 15p.inst_id = USERENV('Instance') AND
>
> 16s.inst_id = USERENV('Instance') AND
>
> 17o.kglhdpmd = 2 AND
>
> 18o.kglobtyp IN (7, 8, 9, 12, 13) AND
>
> 19p.kglpnhdl = o.kglhdadr AND
>
> 20s.addr = p.kglpnses
>
> 21 ORDER BY 4, 2, 1
>
> 22 /
>
> sys.X_$KSUSE s
>
> *
>
> ERROR at line 12:
>
> ORA-00942: table or view does not exist
>
>
>
> Grato,
>
> Ednilson Silva
>
> Tecnologia da Informação
>
> JBS S/A
>
>
>
> De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br]
> Enviada em: sexta-feira, 16 de setembro de 2016 11:34
> Para: oracle_br@yahoogrupos.com.br
> Assunto: Re: RES: RES: RES: RES: [oracle_br] Re: delete
>
>
>
>
>
> Bom dia - então, como eu disse, no ** instante ** em que a sessão tá sendo
> bloqueada, CADÊ o resultado dos scripts nesse momento, EM ESPECIAL o scripts
> de WAITs e o de Transações ? Pois NECESSARIAMENTE se a sessão tá sendo
> bloqueada e/ou está esperando por um recurso isso TEM QUE aparecer nas
> colunas de WAIT da V$SESSION e no registro correspondente da V$SESSION_WAIT
> - mostra pra gente esses resultados, coletados nesse momento E com várias
> execuções, que a gente pode palpitar...
>
> []s
>
> Chiappa
>
> OBS : iirc no 9i não era default o parâmetro TIMED_STATISTICS - confirme que
> esse cara tá setado, pois se não vc Não Vai ver info de waits
> Preferencialmente, STATISTICS_LEVEL deve estar pelo menos como TYPICAL,
> também...
>
>
>
Re: RES: RES: RES: RES: RES: [oracle_br] Re: delete
Opa : então, foi cortada a sua msg, provavelmente por causa de limite de tamanho - sobe um arquivo-texto pra algum serviço de compartilhamento de arquivos e passa o link pra gente A gente não conseguiu ver mas ** creio ** que vc executou os scripts nos ** DOIS ** bancos (nos DOIS, pois mesmo que não haja sessão sendo criada ainda nós Queremos ver os outros waits/locks/acessos/transações que possam estar havendo), no momento em que a sessão que está tentando criar a package tá em waiting/congelada, né ? Nós queremos ver Principalmente o resultado nos dois bancos de algumas execuções intervaladas daquele script para consultar sessões e seus WAITs, executadas nesse intervalo de tempo em que a sessão tentando criar a package congela... Bem, mesmo sem a info completa algumas coisas podemos comentar : => sim, poderia ser questão de estatísticas faltantes/incompletas no dicionário de dados, mas iirc na versão 9i ainda NÂO EXISTIA como vc as coletar manualmente (a DBMS_STATS.GATHER_FIXED_STATS só foi introduzida na 10g), ou mesmo (por causa de tablespace SYSTEM não criada como LMT) possa ser fragmentação NO caso, na época do 9i justamente por não termos outra opção quando tínhamos algum problema desse tipo de estatísticas o Suporte Oracle indicava algum HINT, ou te autorizava a recriar os objetos do SYS... Imagino que vc não tem Contrato de Suporte extendido ativo pra esse database 9i, pra eventualmente abrir um Chamado e solicitar atuação desse tipo do Suporte, né ? => eu vi em msgs anteriores que vc só tava botando dentro de BEGIN/END o DELETE, ie, tava usando um bloco anônimo : vc Testou colocando ao invés o DELETE num stored procedure nomeado, seja Procedure, Function ou Package ? É o mesmo sintoma ? => para tentar evitar envio de dados do banco remoto pela rede, vc já pensou em criar Lá no banco remoto uma procedure/function/package que faça o DELETE (aí, obviamente, vc não terá refereência a dblink na rotina, tudo será acesso local ao dicionário local) ? Se isso for bem, aí vc simplesmente executa no banco local a procedure remota que está criada lá no banco-remoto com um @nomedoplsql@nomedodatabaselink => teste também o HINT de DRIVING SITE, cfrme o manual 9i de Tuning , online em https://docs.oracle.com/cd/B10500_01/server.920/a96533/hintsref.htm#5699 []s Chiappa
RES: RES: RES: RES: RES: [oracle_br] Re: delete
,
'QC','Row cache instance lock (C=cache)',
'QD','Row cache instance lock (D=cache)',
'QE','Row cache instance lock (E=cache)',
'QF','Row cache instance lock (F=cache)',
'QG','Row cache instance lock (G=cache)',
203 'QH','Row cache instance lock (H=cache)',
'QI','Row cache instance lock (I=cache)',
'QJ','Row cache instance lock (J=cache)',
'QL','Row cache instance lock (K=cache)',
'QK','Row cache instance lock (L=cache)',
204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219
220 221 222 223 'QM','Row cache instance lock (M=cache)',
'QN','Row cache instance lock (N=cache)',
'QO','Row cache instance lock (O=cache)',
'QP','Row cache instance lock (P=cache)',
'QQ','Row cache instance lock (Q=cache)',
'QR','Row cache instance lock (R=cache)',
'QS','Row cache instance lock (S=cache)',
'QT','Row cache instance lock (T=cache)',
'QU','Row cache instance lock (U=cache)',
'QV','Row cache instance lock (V=cache)',
'QW','Row cache instance lock (W=cache)',
'QX','Row cache instance lock (X=cache)',
224 225 226 227 228 229 230 231 232 233 234 235 'QY','Row cache
instance lock (Y=cache)',
'QZ','Row cache instance lock (Z=cache)','') Lockt
fromV$LOCK L,
V$SESSION S,
SYS.USER$ U1,
SYS.OBJ$ T1
where L.SID = S.SID
and T1.OBJ# = decode(L.ID2,0,L.ID1,1)
and U1.USER# = T1.OWNER#
and S.TYPE != 'BACKGROUND'
order by 1,2,5
/
236 237 238 239 240 241 242 243 244 245 246
UsernameSID Term Table Name COMMAND
Lock HeldLock Requested ID1 - ID2 Lock Type
-- -- -- -
--
PRODUCAO 18 pts/1 None SELECT
ExclusiveNONE 196625-5354311 TX - Transaction
enqueue lock
SQL> SELECT /*+ RULE */
2substr(DECODE(o.kglobtyp,
3 7, 'PROCEDURE', 8, 'FUNCTION', 9, 'PACKAGE', 12, 'TRIGGER', 13,
'CLASS'),1,15) "TYPE",
4substr(o.kglnaown,1,30) "OWNER",
56substr(o.kglnaobj,1,30) "NAME",
7s.indx "SID",
8s.ksuseser "SERIAL"
9 FROM
10sys.X_$KGLOB o,
11sys.X_$KGLPN p,
12sys.X_$KSUSE s
13 WHERE
14o.inst_id = USERENV('Instance') AND
15p.inst_id = USERENV('Instance') AND
16s.inst_id = USERENV('Instance') AND
17o.kglhdpmd = 2 AND
18o.kglobtyp IN (7, 8, 9, 12, 13) AND
19p.kglpnhdl = o.kglhdadr AND
20s.addr = p.kglpnses
21 ORDER BY 4, 2, 1
22 /
sys.X_$KSUSE s
*
ERROR at line 12:
ORA-00942: table or view does not exist
Grato,
Ednilson Silva
Tecnologia da Informação
JBS S/A
De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br]
Enviada em: sexta-feira, 16 de setembro de 2016 11:34
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: RES: RES: RES: [oracle_br] Re: delete
Bom dia - então, como eu disse, no ** instante ** em que a sessão tá sendo
bloqueada, CADÊ o resultado dos scripts nesse momento, EM ESPECIAL o scripts de
WAITs e o de Transações ? Pois NECESSARIAMENTE se a sessão tá sendo bloqueada
e/ou está esperando por um recurso isso TEM QUE aparecer nas colunas de WAIT da
V$SESSION e no registro correspondente da V$SESSION_WAIT - mostra pra gente
esses resultados, coletados nesse momento E com várias execuções, que a gente
pode palpitar...
[]s
Chiappa
OBS : iirc no 9i não era default o parâmetro TIMED_STATISTICS - confirme que
esse cara tá setado, pois se não vc Não Vai ver info de waits
Preferencialmente, STATISTICS_LEVEL deve estar pelo menos como TYPICAL,
também...
Re: RES: RES: RES: RES: [oracle_br] Re: delete
Bom dia - então, como eu disse, no ** instante ** em que a sessão tá sendo bloqueada, CADÊ o resultado dos scripts nesse momento, EM ESPECIAL o scripts de WAITs e o de Transações ? Pois NECESSARIAMENTE se a sessão tá sendo bloqueada e/ou está esperando por um recurso isso TEM QUE aparecer nas colunas de WAIT da V$SESSION e no registro correspondente da V$SESSION_WAIT - mostra pra gente esses resultados, coletados nesse momento E com várias execuções, que a gente pode palpitar... []s Chiappa OBS : iirc no 9i não era default o parâmetro TIMED_STATISTICS - confirme que esse cara tá setado, pois se não vc Não Vai ver info de waits Preferencialmente, STATISTICS_LEVEL deve estar pelo menos como TYPICAL, também...
RES: RES: RES: RES: [oracle_br] Re: delete
Bom Dia Chiappa,
No Banco Destino não mostra nenhum lock, executei todos os seus scripts, alias
não abre nem sessão vindo da origem.
Na Origem, matei todas as sessões, tirei o listener, parei os Jobs, fiquei
sozinho no banco e coloquei a instrução abaixo e não executa.
SQL> begin
2delete ind_saldo_estoque_diario@prd.fr_lins.gr_bertin
3 where cod_empresa = 40
4 and cod_filial = 3
5 and dat_saldo >= TO_DATE('06/09/2016', 'DD/MM/');
6 end;
7 /
Como lhe disse, na Origem existe esta mesma tabela e fazendo sem o DB Link,
funciona.
SQL> begin
2delete ind_saldo_estoque_diario
3 where cod_empresa = 40
4 and cod_filial = 3
5 and dat_saldo >= TO_DATE('06/09/2016', 'DD/MM/');
6 end;
7 /
PL/SQL procedure successfully completed
SQL> ROLLBACK;
Rollback complete
A rotina em questão, faz um DELETE e depois um INSERT, então imaginei que
poderia haver uma fragmentação. Movi essa tabela na Origem para outra
tablespace e fiz o rebuild dos indices.
Atualizei estatisticas de ambos, e dicionarios tambem. Já fiz um reboot no
Banco de Origem.
No Destino, criei uma tabela e fiz um DELETE e INSERT empsulado sem problemas.
Detalhe: o Banco Origem fica em Hong Kong e o Destino aqui em São Paulo.
O Banco Origem é 9.2.0.8 e o Destino 11.2.0.4, ambos Enterprise.
Grato,
Ednilson Silva
De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br]
Enviada em: quinta-feira, 15 de setembro de 2016 20:30
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: RES: RES: [oracle_br] Re: delete
Opa , estamos chegando em algum lugar : em especial, essa info de
"sessão. em Library Cache Load Lock" é ABSOLUTAMENTE, COMPLETAMENTE,
TOTALMENTE DIFERENTE da info de "Não gera nenhum bloqueio, ..." que vc tinha
dado em outra msg anterior, né não ?
Muito bem, agora SIM estamos chegando em algum lugar ;)
okdoc : o fato que vc consegue compilar com sucesso no banco-destino outros
stored PL/SQLs que usam esse dblink mas (ao que entendo) acessam OUTRAS tabelas
lá no banco-origem CLARAMENTE INDICA que é uma issue com essa tabela - como eu
disse lá na segunda resposta, pode ser uma Transação aberta nessa tabela, pode
ser espera por LOCK causado por algum outro DDL concorrendo com a
criação/compilação da package, E o procedimento é mesmo consultar as views e
tabelas internas de WAITs, de LOCKS, de TRANSAÇÕES e de execução de PL/SQL (e
isso nos DOIS BANCOS !!!) e ver quem/qual sessão tá acessando/mexendo/tem
locks/tá usando PL/SQL que referencia a tal tabela
Seguem abaixo FYR alguns scripts-exemplo que posso indicar, todos (repito)
devendo ser executados TANTO no banco origem da informação QUANTO no
banco-destino que possui o dblink - só AVISO que :
a. como não tenho um banco 9iR2 aqui facilmente disponível, CONFIRA na doc que
realmente todas as colunas que referencio estão presentes no 9i
b. todas as consultas devem ser executadas nos dois bancos com um usuário
Administrador/DBA
c. afaik vc não disse mas SUPONHO que esse 9iR2 EE é single-instance ou RAC :
se for RAC acesse as GV$ ao invés das V$
d. as views/tabelas internas DBA_xxx e (G)V$xxx via de regra já são
permissionadas para qualquer usuário Administrador - já as X$ normalmente não,
então se vc for executar os scripts com outro user que não o SYS ,
permissione-o adequadamente
e. os scripts que são apenas um SELECT e nada mais podem ser executados
diretamente no prompt do sql*plus (ou da sua GUI preferida), ao passo que os
que possuem outros comandos (como COLUMN, ou outros) aí necessariamente
precisam ser salvos num arquivo .SQL e executados via @nomedoarquivo.sql dentro
do sql*plus
A idéia é executar (nos DOIS BANCOS, repito!) várias vezes cada scripts numa
** outra ** janela/sessão, ao mesmo tempo em que a sessão no banco-origem que
está tentando criar a packahe tá 'congelada'...
Seguem :
==> consulta de Transações abertas
SELECT a.sid, a.saddr, b.ses_addr, a.username, b.xidusn, b.used_urec,
b.used_ublk
FROM v$session a, v$transaction b
WHERE a.saddr = b.ses_addr;
==> consulta de Waits de banco (a view DBA_WAITERS não era default no 9iR2
iirc, se vc não a tem iirc vc deve rodar scripts do SYS em
$ORACLE_HOME/rdbms/admin) :
SELECT * from dba_waiters;
==> script para consultar sessões e seus WAITs (dê ENTER nos itens de filtro
para usar o default, que lista Todas as linhas)
SET PAGES 999
column sid_serialformat A10
column seq# format 9
column event format a29 heading "Wait Event" trunc
column state format a15 heading "Wait State" trunc
column secs format 999 heading "Waited so|far (sec)"
column wt format 999 heading "Waited|Seconds"
column P1TEXT format a38
column P2TEXT format a38
column P3TEXT format a38
prompt
prompt Sessões esperando por sql*net message estão aguardando
prompt por resposta do usuário.
prompt
