Re: [oracle_br] Re: Trigger com disconnect
Grande Chiappa.
Sim... Depois de postado a mensagem que percebi que nenhum evento poderia
ser detectado pelo banco nestas condições... E acabei montando uma procedure
(disparada por job) que faz essa validação que precisava a cada x minutos...
Como notamos que essas sessões que estavam órfãs no banco apareciam com os
campos machine e terminal como null, ficou mais simples de filtrá-las no
banco...
Vou postar aqui tb pois pode ser útil pra alguns do grupo...
##
CREATE TABLE SessoesMortas
(SqlAtualVARCHAR2(1000),
ValorSIDVARCHAR2(30),
ValorSerial#VARCHAR2(30),
ValorSPID VARCHAR2(30),
ValorUsername VARCHAR2(30),
ValorProgramVARCHAR2(100),
ValorOSUser VARCHAR2 (30),
ValorMachineVARCHAR2 (30),
ValorTerminal VARCHAR2 (30),
ValorLogonTime DATE,
HoraObito DATE
);
CREATE OR REPLACE PROCEDURE finaliza_sessoes_inativas
IS
ComandoKill VARCHAR2(200);
SqlAtualVARCHAR2(1000);
ValorSID VARCHAR2(30);
ValorSerial# VARCHAR2(30);
ValorSPIDVARCHAR2(30);
ValorUsername VARCHAR2(30);
ValorProgram VARCHAR2(100);
ValorOSUserVARCHAR2 (30);
ValorMachineVARCHAR2 (30);
ValorTerminalVARCHAR2 (30);
ValorLogonTimeDATE;
CURSOR testa_condicao IS
select s.sid, s.serial#, s.username, s.program, s.osuser, s.machine,
s.terminal, t.sql_text, p.spid, s.logon_time
from v$session s, v$sql t, v$process p
where s.username like 'DBA%'
and s.status in ('ACTIVE','INACTIVE','KILLED')
and s.machine is null
and s.terminal is null
and t.address=s.sql_address
and s.paddr=p.addr;
BEGIN
FOR sessao in testa_condicao
LOOP
SqlAtual := sessao.sql_text;
ValorSID := sessao.sid;
ValorSerial# := sessao.serial#;
ValorSPID := sessao.spid;
ValorUsername := sessao.username;
ValorProgram := sessao.program;
ValorOSUser := sessao.osuser;
ValorMachine := sessao.machine;
ValorTerminal := sessao.terminal;
ValorLogonTime := sessao.logon_time;
ComandoKill:= 'ALTER SYSTEM KILL SESSION ''' || ValorSID ||
',' || ValorSerial# || ''' IMMEDIATE';
Execute Immediate(ComandoKill);
Insert Into SessoesMortas
Values
(SqlAtual, ValorSID, ValorSerial#, ValorSPID, ValorUsername,
ValorProgram, ValorOSUser, ValorMachine, ValorTerminal, ValorLogonTime,
sysdate);
END LOOP;
Commit;
END;
/
##
Em 02/06/07, jlchiappa [EMAIL PROTECTED] escreveu:
Gustavo, trigger eu acho que não faz sentido, pois triggers
respondem a eventos, e vc NÃO ESTÁ falando de desconexão graciosa, e
sim está falando de programa ABORTADO, absolutamente FORA DE CONTROLE
por parte do banco, qual evento vc acga que poderia disparar aí ???
O que vc poderia fazer é via config de sql*net estabelecer um DCD
(dead cliente detection) , OU via profile vc estabelecer tempo máximo
de inatividade OU ter um job (job Oracle ou job de So, como preferir,
embora job Oracle seja mais fácil de administrar neste caso), job que
a cada X minutos é disparado e procurar por sessões mortas - só
LEMBRANDO que em sendo conexão dedicada vc tem um PROCESSO SHADOW
atendendo à conexão, NEM SEMPRE quando uma sessão de cliente morre o
processo morre junto, vc TERIA que consultar v$session, v$process, E
teria que verificar se no SO o processo realmente existe...
Agora, cliente morrendo constantemente IMPLICA qe vc tem sim algum
bug sério aí, aplicação, rede, hardware, etc , TEM QUE serem
rigorosamente checadas pra vc descobrir ONDE o prob reside...
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br oracle_br%40yahoogrupos.com.br,
Gustavo Venturini de Lima
[EMAIL PROTECTED] escreveu
Boa noite pessoal...
Sei que já passaram algumas mensagens com este assunto por aqui, mas não
consegui achar alguma nos meus históricos que possam me ajudar
muito...
Estou tendo o seguinte problema: Algumas sessões de usuários (jobs
locais)
estão travando e suas sessões (do aplicativo) morrem... Porém, a
sessão no
banco continua a existir, e em algum casos processando...
Pensei em fazer fazer algo como uma trigger que validasse o campo
machine
da v$session, e quando for nulo (não sendo usuário oracle é claro),
e com o
owner da aplicação ele limpar esta sessão. É possível isso? Alguém tem
alguma outra sugestão ou pode exemplificar esta que dei???
HP-UX myserver B.11.23 U ia64 2052350653 unlimited-user license
BANNER
--
Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
PL/SQL Release 9.2.0.8.0 - Production
CORE 9.2.0.8.0 Production
TNS
[oracle_br] Re: Reflexões sobre a política de p reços da Oracle
Olá Chiapa. Josir, primeiro de tudo lembre que há as EDIÇõES do banco Oracle - a Enterprise (que é a Oracle, é completinha, que efetivamente possui as features que fazem do bd Oracle o bd Oracle), a Personal (que só não tem Replicação e correlatos, mas o resto tem, perfeita portanto para soft-houses e pessoal que vai gerar aplicativo), e as mais No nosso caso, a Standard é mais do que suficiente para as nossas necessidades. O QUERY_REWRITE (que não tem no Standard) até seria útil mas não é fundamental... área Assim, se é principalmente patches que te preocupam, vc TRANQUILAMENTE poderia ter um contrato de Suporte apenas, para o produto Oracle mais barato (digamos, um Standard One, ou mesmo um produto não-bd como o Oracle Collaboration Suite), e com esse acesso vc baixa QUAISQUER patches, lista de bugs e notas de QUAISQUER outros produtos...Isso NÂO É algo que vc vê muito frequentemente pelaí... Eu acredito que não se vê muito isso pois as empresas que antes compraram Oracle, não têm que enxugar o orçamento pois o investimento de R$50.000 (supondo 100 usuários) é porcaria para uma grande empresa. Entretanto, como as pequenas empresas estão começando a utilizar Oracle, a questão de preço começa a ficar evidente. Em tese, sim, a estratégia que vc propõe funcionaria, e está prevista pela licença (já que o XE vc pode fazer o que quiser com ele,com dados reais inclusive, e que o Standard não tem restrições a conectar com XE), obviamente isso IMPLICARIA em : a. RISCOS não pequenos : já que o XE não tem suporte algum, se ele ir pro beleléu amanhã, ou se vc cair num bug feroz dele, vc estria TOTAL e COMPLETAMENTE por sua conta, com produção parada, etc Sabe Chiappa, em 10 anos usando Oracle, eu já perdi o banco apenas 4 vezes. Todas as vezes, foram problemas de hardware, nunca do Oracle. Sempre que tive um ORA-600, consegui contornar recriando o banco ou realizando outras artimanhas. Dessas 4 vezes, em apenas uma ocasião, eu perdi dados de produção que foram recuperados em apenas 2h (com 2 pessoas trabalhando). E isso utilizando apenas formas de backup primárias (com IMPORT e EXPORT). Ainda não tive tempo de aprender como usar o ARCHIVELOG. Atualmente, utilizando virtualização, eu coloco uma instância do SO com Oracle no ar em 10 minutos e gasto +20 minutos para recuperar o backup. Assim, na pior das hipóteses (quando o SYSTEM vai para o espaço), eu recupero tudo zero em 30 minutos. Com certeza, a forma com que as minhas aplicações funcionam e a quantidade de usuários, facilitam a recuperação de dados e entendo que outros tipos de aplicações não tem facilidades implícitas no meu tipo de negócio e por isso o DBA tem que ser mais precavido. Enfim, o ponto em que quero chegar é que o Oracle, como software, é muito estável e o risco é bem pequeno. Já estou utilizando o XE desde o seu lançamento e ele tem apresentado a mesma robustez da versão Standard. A Enterprise eu não posso falar pois só a usei como programador e nunca como DBA (se é que posso me considerar um). b. custos de administração : ie, vc teria MAIS coisas a administrar/monitorar, teria MAIS processos (os de integração aí no caso) a controlar/verificar, os dados provavelmente NÂO ESTARIAM real- time no banco final Com certeza teremos um custo de administração mas já fizemos as contas: sai mais barato que comprar todas as licenças. Existia até uma 3a opção de continuar apenas com o XE mas aí o custo de administração sairia mais caro. E finalmente, em outra msg outro colega falou sobre a esperança dele de que os avanços dos outros bancos de dados (principalmente os freewares) influencie a política da Oracle : eu digo, todos nós esperamos que coisas do tipo aconteçam, MAS não vou prender a respiração por isso, em se analisando a situação da tecnologia Concordo que os bancos opensource ainda estarão bem longe do Oracle por um bom tempo. Principalmente, na parte da programação server-side que não tem igual em nenhum banco. Entretanto, é uma boa opção para pequenas/médias empresas. Obrigado pelo reply! Suas considerações sempre abrem a mente para boas idéias! Boa semana para todos. Josir.
