KILL sessioni UTENTE Oracle

.

Se hai cercato “KILL sessioni UTENTE Oracle” sei nel posto giusto!

Mi è spesso capitato in fase di DROP di uno SCHEMA di trovare sessioni connesse al database e ricevere il classico errore ORA-01940: cannot drop a user that is currently connected.

La DROP può capitare per esempio in casi di allineamento dati da ambienti di produzione in ambienti di test. Prima di eseguire l’import, eseguo la DROP dell’utente e puntualmente ricevo l’errore ORA-01940.

Che fare in questi casi?

Individuare le sessioni Oracle dell’utente connesso potrebbe essere un buon approccio al problema.

Capire se le sessioni vengono da un application server… Se vengono da un utente direttamente connesso al database da qualche altro client.

Se volete analizzare tutte le sessioni di un determinato utente, potete utilizzare la query nell’articolo Query per vedere i dettagli di tutte le sessioni di un utente.

Nel caso in cui avessimo fretta e non possiamo aspettare le analisi?

Non c’è problema.

L’obbiettivo è eseguire il kill di tutte le sessioni dell’utente Oracle connesso al database.

Lo possiamo raggiungere eseguendo la seguente query:

select  'alter system kill session ''' || sid || ',' || serial# ||''' immediate;' 
from gv$session where USERNAME = '&USERNAME';

Se successivo al kill trovaste nuovamente sessioni, il problema è da imputare all’application server lasciato connesso.

Quando è possibile facciamo chiudere il collegamento, altrimenti agiamo in maniera astuta.

L’utente per poter essere utilizzato, deve avere l’ACCOUNT_STATUS della vista DBA_USERS a OPEN, quindi lo stato è di fatto UNLOCK.

Per poter ovviare al problema, impostiamo in maniera esplicita lo stato dell’utente a LOCK con il seguente comando:

alter user PIPPO account LOCK;

Per visionare le mie guide sui Comandi CRS clicca qui!
A questo LINK, invece, troverai le query SQL

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Query disconnect session Oracle

.

Con l’articolo Query disconnect session Oracle, possiamo disconnettere la sessione dell’utente connessa al database, quindi il termine della sessione.

Le situazioni di sessioni in LOCK in database frequentemente acceduti, capitano frequentemente. Con l’articolo Query disconnect session Oracle forniamo la soluzione.

In questi casi occorre individuarle con la query reperibile sull’articolo Query per identificare quale sessione sta determinando il LOCK, oppure con la query sull’articolo Query per vedere le sessioni detentrici di LOCK oppure con la query reperibile sull’articolo Query per individuare la sessione che sta bloccando altre sessioni.

Una volta individuato il SID che determina il LOCK e i SID bloccati, dobbiamo approfondire l’analisi recuperando informazioni utili da fornire al gruppo applicativo e farci autorizzare il kill della sessione che sta determinando il blocco.

L’analisi avviene attraverso la query reperibile sull’articolo Query per vedere i dettagli di una sessione da SID

Una volta autorizzati possiamo procedere con la disconnect della sessione.

Se non dovesse funzionare, possiamo provare con il comando di kill al posto dell’istruzione disconnect

Fare massima attenzione della provenienza della sessione che dobbiamo disconnettere, in un RAC il SID può essere uguale su tutte le istanze.
Il SERIAL con il SID identificano con precisione la sessione a noi interessata.

Query per eseguire la disconnect di una sessione per SID:

select 'alter system disconnect session '''||SID||','||SERIAL#||''' immediate;'   from gv$session where SID=&sid;

Query per eseguire la disconnect sessions per SID su ambiente RAC:

select 'alter system disconnect session '''||SID||','||SERIAL#||'@'||INST_ID||' immediate;' from gv$session where SID=&sid;

Restiamo in contatto!

Per visionare le mie guide sui Comandi CRS clicca qui!
A questo LINK, invece, troverai le query SQL

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Query per eseguire la disconnect di una sessione per SID

.

Bene, prima di partire con l’articolo “Query per eseguire la disconnect di una sessione per SID” vorremmo introdurre questo sito a te che lo vedi per la prima volta!
Scriptdba è il primo sito verticale su database Oracle completamente in italiano. In realtà durante il 2020 usciremo con la versione in inglese, ma l’italiano ci sarà sempre e comunque.
Hai capito bene, un sito in doppia lingua. Perchè? Perchè a noi piace fare le cose semplici, semplici per voi lettori ovviamente! (un po meno per noi).

Su scriptdba.com troverai guide, tutorial e troubleshooting sul database più enterprise che ci sia!

Nel caso in cui abbiamo la necessità di eseguire il kill di tutte le sessioni con un determinato SID, con la seguente query dinamica,
costruiremo il comando da lanciare per eseguire il kill di tutte le sessioni su tutte le istanze del RAC da una sola istanza.
Fare massima attenzione della provenienza della sessione che dobbiamo uccidere, in un RAC il SID può essere uguale su tutte e due le istanze.
Il SERIAL con il SID identificano con precisione la sessione a noi interessata.

Disconnect session per SID su database Single Instance

Kill session per SID su ambiente RAC:

select 'alter system disconnect session '''||SID||','||SERIAL#||',@'||INST_ID||''' immediate;'   from gv$session where SID=&sid;

Query disconnect SID

Stay tuned! Non solo Query disconnect SID

Per visionare le nostre guide sui Comandi CRS clicca qui!
A questo LINK, invece, troverai le query SQL

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Per chi ancora non lo avesse fatto, consigliamo di salvare tra i propri bookmark questo sito, così da avere sempre a portata di mano le nsotre soluzioni ai problemi più comuni su database, in particolar modo, database oracle.

KILL sessioni UTENTE Oracle su RAC

.

Lo statement nell’articolo KILL sessioni UTENTE Oracle su RAC, è da me tanto amato per via del suo prezioso utilizzo, poichè attraverso il campo INST_ID, riusciamo ad eseguire il KILL su ogni istanza che compone il RAC Oracle.

Nelle numerose richieste che arrivano dai clienti che gestisco, spesso mi vengono assegnate attività di allineamento dati da ambiente di produzione ad ambiente di test.

Questo comporta: l’export dei dati dall’ambiente di produzione, il trasferimento del dump di export dal server di produzione al server di test, drop dello SCHEMA da importare in ambiente di test e successiva import dei dati e metadati ossia di tutto lo SCHEMA.

Però nel caso in cui sono connessi utenti o sono presenti sessioni applicative legate allo SCHEMA, il comando di DROP fallirà segnalando che sono presenti sessioni connesse al DB.
Andando più nello specifico, si presenterà il seguente messaggio d’errore:

ORA-01940: cannot drop a user that is currently connected

Come possiamo risolvere il problema?

Prima di tutto dobbiamo individuare le sessioni e successivamente dovremo eseguire il KILL delle stesse.

Quindi, nel caso in cui abbiamo la necessità di eseguire il kill di tutte le sessioni Oracle di un determinato utente, con la seguente query dinamica,
costruiremo il comando da lanciare per eseguire il kill di tutte le sessioni su tutte le istanze del RAC da una sola istanza.

KILL sessioni UTENTE Oracle su RAC

select  'alter system kill session ''' || sid || ',' || serial# || ','||'@'|| INST_ID || ''' immediate;' 
from gv$session where USERNAME = '&USERNAME';

Per visionare le mie guide sui Comandi CRS clicca qui!
A questo LINK, invece, troverai le query SQL

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Query LOCK e numero sessioni Oracle

.

L’articolo Query LOCK e numero sessioni Oracle vi sarà di grande aiuto, sopratutto quando il gruppo applicativo è fermo per via degli errori provenienti dal database e il manager dietro le spalle che fa domande a raffica giusto per farti perdere ulteriore tempo.

In database molto acceduti, può capitare che, tra le numerose richieste che arrivano dagli application server, più sessioni insistono sulla stessa tabella o partizione.

Le numerose operazioni DML su oggetti già utilizzati da altre sessioni sono la principale causa di contese e tradotto in parole povere, attese che possono creare pericolosi colli di bottiglia.

Quindi, quando ci vengono segnalate situazioni di LOCK, dobbiamo essere pronti nell’individuare la sessioni che sta causando il blocco.

Analizzando la vista V$LOCK, richiamata dalla seguente query, abbiamo la possibilità di individuare informazioni utili per raggiungere il nostro scopo, ossia individuare con precisione la sessione che sta determinando la contesa.

Con la seguente query troverete quale sessione sta determinando i forti rallentamenti o il blocco del database in breve tempo.

Vi sarà indicato il SID che sta determinando il blocco e il numero di sessioni che sono bloccate.

Query LOCK e numero sessioni Oracle:

SELECT bs.sid BSID, count(ws.sid) as NumWait 
FROM v$lock hk, v$session bs, v$lock wk, v$session ws 
WHERE hk.BLOCK = 1 AND wk.TYPE(+) = hk.TYPE AND wk.id1(+) = hk.id1 
AND wk.id2(+) = hk.id2 AND hk.sid = bs.sid(+) 
AND wk.sid = ws.sid(+) AND bs.sid != ws.sid group by bs.sid 
order by 2 desc;

Per visionare le mie guide sui Comandi CRS clicca qui!
A questo LINK, invece, troverai le query SQL

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Query per individuare le sessioni bloccate da un’altra sessione

.

Query per individuare le sessioni bloccate da un’altra sessione

Bene, prima di partire con l’articolo “Query per individuare le sessioni bloccate da un’altra sessione” vorremmo introdurre questo sito a te che lo vedi per la prima volta!
Scriptdba è il primo sito verticale su database Oracle completamente in italiano. In realtà durante il 2020 usciremo con la versione in inglese, ma l’italiano ci sarà sempre e comunque.
Hai capito bene, un sito in doppia lingua. Perchè? Perchè a noi piace fare le cose semplici, semplici per voi lettori ovviamente! (un po meno per noi).

Query per individuare le sessioni bloccate da un'altra sessione
Hard disk and database icon isolated on white background

Su scriptdba.com troverai guide, tutorial e troubleshooting sul database più enterprise che ci sia!

Con la query Blocking LOCK, riusciamo ad individuare la sessione che sta bloccando altre sessioni.
Queste situazioni di LOCK, in alcuni casi potrebbe determinare grossi colli di bottiglia e quindi forti rallentamenti se non il blocco del database.
Con la seguente query troverete quale sessione sta determinando i rallentamenti o il blocco del database in breve tempo.

Query per individuare la sessione che sta bloccando altre sessioni:

select a.inst_id as WInst ,a.sid as WSid, a.serial# as WSer, a.sql_id as WSql , a.seconds_in_wait as WSec,
 b.sid as BSid , b.serial# as BSer , a.event as WEvent , b.event as BEvent, b.sql_id as BSql
from gv$session a , gv$session b
where a.BLOCKING_SESSION_STATUS='VALID' and b.inst_id=a.BLOCKING_INSTANCE and b.sid=a.BLOCKING_SESSION;

Stay tuned! Non solo Query per vedere le sessioni bloccate, infatti…

Per visionare le nostre guide sui Comandi CRS clicca qui!
A questo LINK, invece, troverai le query SQL

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Per chi ancora non lo avesse fatto, consigliamo di salvare tra i propri bookmark questo sito, così da avere sempre a portata di mano le nsotre soluzioni ai problemi più comuni su database, in particolar modo, database oracle.

Query per vedere i dettagli di una sessione Oracle di un utente

.

Nel caso abbiamo la necessità di controllare le sessioni di utente Oracle,
con la seguente query,
ricaviamo molte informazioni richieste.

Le prime righe riguardano la formattazione delle tabelle,
per avere una visuale accettabile.

I campi che andremo a selezionare sono:

LOGON TIME: indica l’orariov in cui è iniziata la sessione
STATUS – Lo stato della sessione se ACTIVE o INACTIVE.
IST_ID – Nel caso di un RAC (Real Application Cluster), il numero dell’istanza dove è presente la sessione.
SQL_ID – Il codice identificativo della query.
PROCESS – Il processo del sistema operativo.
PROGRAM – Il client che state utilizzando (Toad, SQL Developer)
SCHEMANAME – L’utente con è partita la sessione Oracle.
SID – Il codice identificativo della sessione Oracle.
SERIAL# – Il codice seriale univoco di una sessione Oracle.
SPID – Processo del sistema operativo legato alla sessione Oracle.
OSUSER – L’utente del sistema operativo con cui è partita la sessione Oracle.
MACHINE – Il nome del client da dove parte la sessione Oracle.
TERMINAL – Il nome del sistema operativo da dove parte la sessione Oracle.
LAST_CALL_ET – L’orario in cui la sessione ha cambiato stato da ACTIVE a INACTIVE e vice versa.
USERNAME – Nome dell’utente Oracle.
COMMAND – Il comando che è stato eseguito sul database Oracle.

Per estrapolare queste informazioni dal database Oracle, abbiamo messo in relazione tre tabelle:

GV$SESSION
GV$PROCESS
DBA_USERS

Inoltre nella WHERE condition,
per prima cosa abbiamo messo in relazione le viste
V$PROCESS e
V$SESSION attraverso la JOIN
P.ADDR=S.PADDR
e messo in relazione la vista V$SESSION
con la vista DBA_USERS attraverso la JOIN S.USER#=U.USER_ID.


Infine dopo la relazione delle tabelle V$PROCESS V$SESSION e DBA_USERS, per controllare le informazioni che abbiamo selezionato di un determinato utente,
gli passiamo la condizione
S.USER#=il nome dell’utente.

Sessioni per utente:

Set lines 300
Set pages 60
Col LAST_CALL for a18
Col LOGON_TIME for a18
Col schemaname for a16
Col command for a24
Col machine for a16
Col action for a12
Col username for a16
Col osuser for a16
Col terminal for a16
select to_char(S.logon_time,'DD-MON-YYYY hh24.mi.ss') LOGON_TIME, s.status,s.inst_id,s.sql_id, s.process,s.program, s.schemaname,
s.sid, s.serial#, p.spid, s.osuser, S.machine, S.terminal,to_char(sysdate -(LAST_CALL_ET/86400),'DD-MON-YY hh24:mi:ss') LAST_CALL , 
U.username, S.ACTION, decode(S.command,0, 'No command in progress.', 1, 'CREATE TABLE',2, 'INSERT', 3, 'SELECT', 4, 'CREATE CLUSTER', 5, 'ALTER CLUSTER', 6, 'UPDATE', 7, 'DELETE') COMMAND
 from gv$session S, dba_users U, gv$process P
where P.ADDR = S.PADDR and 
      S.user# = U.user_id and 
      s.schemaname='&user'
order by LOGON_TIME;



  

 

Query dettagli sessione Oracle
Profile side view portrait of his he nice attractive skilled focused serious, guy writing script ai tech support devops creating digital solution front-end in dark room workplace station indoors

Per visionare le mie guide sui Comandi CRS clicca qui!
A questo LINK, invece, troverai le query SQL

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Per qualsiasi dubbio non esitate a commentare l’articolo.

Query sessioni processi transazioni cursori Oracle

.

Con l’articolo Query sessioni processi transazioni cursori Oracle, abbiamo la possibilità di individuare il numero di sessioni o di processi o di transazioni o di cursori è il loro utilizzo in percentuale.

Diverse volte mi è capitato di essere contattato dal gruppo di monitoraggio per via dell’aumento del numero di sessioni. Se il numero aumenta fino al raggiungimento del numero limite di sessioni. il database non accetterà più connessioni in entrata.

Le sessioni che stanno dentro al database continueranno a lavorare ma le nuove sessioni restituiranno l’errore ORA-00018 maxiumum number of sessions exceeded.

Nel caso in cui ci trovassimo in questa situazione ci resta che eseguire il kill delle sessioni più datate da sistema operativo individuabili con il seguente comando:

ps -ef |grep nomedb |grep LOCAL=NO

Una volta che siamo riusciti ad entrare possiamo controllare l’attuale utilizzo di sessioni e di processi affianco al loro limite massimo e con l’utilizzo in percentuale

L’output della procedura Sessioni processi cursori e transazioni

TAG   PARAMETER                                                        CURRENT MAXIMUM USAGE%
----- ---------------------------------------------------------------- ------- ------- ------
PSTAT open_cursors                                                          33     300     11
PSTAT processes                                                             52     300     17
PSTAT sessions                                                              33     472      6
PSTAT transactions                                                           0     519      0

Query sessioni processi transazioni cursori Oracle:

set verify off
set termout off
set feedback off
set echo off
set serveroutput on size 999999
set linesize 132
set termout on
declare
MISSING_PARAMETER exception;
MISSING_STAT_OPENCURS exception;
--
MaxIdxParameter integer;
type parameter_name is record (
name varchar2(64),
value integer);
type parameter_list_array is table of parameter_name index by binary_integer;
parameter_lst parameter_list_array;
type parameter_type is record (
current_value integer);
type parameter_array is table of parameter_type index by binary_integer;
parameter_stat parameter_array;
--
function LoadParameterList return number is
cursor parameter_list is
select 1 parameter_id, name, to_number(value) value from v$parameter where name = 'open_cursors'
union all
select 2, name, to_number(value) from v$parameter where name = 'processes'
union all
select 3, name, to_number(value) from v$parameter where name = 'sessions'
union all
select 4, name, to_number(value) from v$parameter where name = 'transactions';
begin
MaxIdxParameter := 1;
for rec_parameter_list in parameter_list loop
if rec_parameter_list.parameter_id = MaxIdxParameter then
parameter_lst(MaxIdxParameter).name := rec_parameter_list.name;
parameter_lst(MaxIdxParameter).value := rec_parameter_list.value;
MaxIdxParameter := MaxIdxParameter + 1;
else
return MaxIdxParameter;
end if;
end loop;
MaxIdxParameter := MaxIdxParameter - 1;
return 0;
end LoadParameterList;
--
procedure LoadParameterStat is
stat_id number;
cursor parameter_list (p_stat in number) is
select 1 parameter_id, max(count(*)) current_value from v$open_cursor group by sid
union all
select 2, count(*) current_value from v$process
union all
select 3, count(*) current_value from v$session
union all
select 4, count(*) current_value from v$transaction;
begin
begin select statistic# into stat_id from v$statname where name = 'opened cursors current';
exception when no_data_found then raise MISSING_STAT_OPENCURS;
end;
for rec_parameter_list in parameter_list(stat_id) loop
parameter_stat(rec_parameter_list.parameter_id).current_value := rec_parameter_list.current_value;
end loop;
end LoadParameterStat;
--
procedure OutputStats is
ParameterId integer;
PctUsage number;
begin
dbms_output.put(rpad('TAG',5));
dbms_output.put(' '||rpad('PARAMETER',64));
dbms_output.put(' '||rpad('CURRENT',7));
dbms_output.put(' '||rpad('MAXIMUM',7));
dbms_output.put(' '||rpad('USAGE%',6));
dbms_output.new_line;
dbms_output.put(rpad('-',5,'-'));
dbms_output.put(' '||rpad('-',64,'-'));
dbms_output.put(' '||rpad('-',7,'-'));
dbms_output.put(' '||rpad('-',7,'-'));
dbms_output.put(' '||rpad('-',6,'-'));
dbms_output.new_line;
for ParameterId in 1..MaxIdxParameter loop
dbms_output.put(rpad('PSTAT',5));
dbms_output.put(' '||rpad(parameter_lst(ParameterId).name,64));
PctUsage := trunc(100*parameter_stat(ParameterId).current_value/parameter_lst(ParameterId).value);
dbms_output.put(' '||lpad(parameter_stat(ParameterId).current_value,7));
dbms_output.put(' '||lpad(parameter_lst(ParameterId).value,7));
dbms_output.put(' '||lpad(PctUsage,6));
dbms_output.new_line;
end loop;
end OutputStats;
begin
-----------------------------------------------------
-- catalogazione parametri sistema
-----------------------------------------------------
if LoadParameterList != 0 then raise MISSING_PARAMETER;
end if;
LoadParameterStat;
-----------------------------------------------------
-- output statistiche
-----------------------------------------------------
OutputStats;
exception
when MISSING_PARAMETER then raise_application_error(-20000,'missing parameter id='||MaxIdxParameter);
when MISSING_STAT_OPENCURS then raise_application_error(-20001,'missing statistic: "opened cursors current"');
end;
/

Successivamente occorre approfondire le analisi per individuare la motivazione per cui le sessioni non stanno completando la disconnessione.

Per visionare le mie guide sui Comandi CRS clicca qui!
A questo LINK, invece, troverai le query SQL

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Query sessioni detentrici di LOCK

.

Con l’articolo Query sessioni detentrici di LOCK, riusciamo ad individuare la sessione che blocca l’accesso ad altre sessioni sullo oggetto conteso.

Abbiamo già discusso nei precedenti articoli riguardanti le contese nel database Oracle: Query LOCK e numero sessioni Oracle e …

La principale causa di contese all’interno del database Oracle riguarda le numerose sessioni che accedono alle stesse tabelle. Queste situazioni di lock, in alcuni casi potrebbero determinare grossi colli di bottiglia tradotto in blocchi del database.

La nostra bravura stà nell’agilità e nella prontezza ad individuare qual’è la sessione che sta causando il dramma per molti utenti e di conseguenza nostri responsabili e manager.

Obbiettivo, individuare e tranquillizzare tutti facendo presente che hai trovato la causa del problema.

Prima di tutto, ci dirigiamo su scriptDBA.com, candiamo nella sezione Gestione sessioni Oracle e cerchiamo le query relative ai LOCK per individuare il prima possibile l’anomalia.

Con la seguente query, possiamo individuare il SID della sessione che sta bloccando la sessione con SID.

Query sessioni detentrici di LOCK:

select 'SID ' || l1.sid ||' is blocking ' || l2.sid blocking 
from v$lock l1, v$lock l2 
where l1.block =1 and 
      l2.request > 0 and 
      l1.id1=l2.id1 and 
      l1.id2=l2.id2;

Una volta individuata, dobbiamo fornire più dettagli possibili dei SID (Bloccante e Bloccato) al gruppo applicativo di riferimento, in modo tale da farci autorizzare ad eseguire un eventuale DISCONNECT o KILL che potrà essere effettuato con lo statement reperibile sull’articolo Query disconnect session Oracle

Per visionare le mie guide sui Comandi CRS clicca qui!
A questo LINK, invece, troverai le query SQL

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Query sessioni Oracle recuperate dalla DATA

.

Query per recuperare le sessioni Oracle antecedenti una determinata DATA e ora.

Nell’articolo Query sessioni Oracle recuperate dalla DATA, possiamo controllare le sessioni Oracle antecedenti una determinata data o ora, utilizzando la seguente query.

Qualche volta mi è capitato di dover individuare le sessioni più “vecchie” presenti nel database. Fino a qui nulla di complicato. Tuttavia per via delle numerose sessioni può risultare difficile individuarle.

Come possiamo fare?

Con la seguenti query, possiamo individuare con facilità le sessioni per esempio antecedenti un mese.

Basta impostare la data che vogliamo nella condizione di where e avremo a video tutte le sessioni precedenti la data che abbiamo impostato.

Inoltre possiamo vedere le prime righe che riguardano la formattazione delle tabelle, per avere una visuale accettabile.

Inoltre i campi che andremo a selezionare sono:

LOGON_TIME – Indica l’orario in cui è iniziata la sessione.
STATUS – Lo stato della sessione se ACTIVE o INACTIVE.
INST_ID – Nel caso di un RAC (Real Application Cluster), il numero dell’istanza dove è presente la sessione.
SQL_ID – Il codice identificativo della query.
PROCESS – Il processo del sistema operativo.
PROGRAM – Il client che state utilizzando.
SCHEMANAME – L’utente con è partita la sessione Oracle.
SID – Il codice identificativo della sessione Oracle.
SERIAL# – Il codice seriale univoco di una sessione Oracle.
Succesivamente:

SPID – Processo del sistema operativo legato alla sessione Oracle.
OSUSER – L’utente del sistema operativo con cui è partita la sessione Oracle.
MACHINE – Il nome del client da dove parte la sessione Oracle.
TERMINAL – Il nome del sistema operativo da dove parte la sessione Oracle.
LAST_CALL_ET – L’orario in cui la sessione ha cambiato stato da ACTIVE a INACTIVE e vice versa.
USERNAME – Nome dell’utente Oracle.
COMMAND – Il comando che è stato eseguito sul database Oracle.

Pertanto per estrapolare queste informazioni dal database Oracle, abbiamo messo in relazione tre tabelle:

GV$SESSION
GV$PROCESS
DBA_USERS

Dunque nella WHERE condition,
abbiamo messo in relazione le viste
V$PROCESS e
V$SESSION attraverso la JOIN P.ADDR=S.PADDR.

Inoltre abbiamo messo in relazione la vista V$SESSION
con la vista DBA_USERS
attraverso la JOIN
S.USER#=U.USER_ID.

Infine dopo la relazione delle tabelle V$PROCESS,
V$SESSION e
DBA_USERS,
Pertanto per controllare le informazioni che abbiamo selezionato antecedenti un determinata data, gli passiamo la condizione to_char(S.logon_time,'DD-MM-YY HH24:MI')con il formato indicato nella funzione to_char.

Per esempio:
to_char(S.logon_time,'DD-MM-YY HH24:MI') < '15-01-17 12:30'

Query sessioni Oracle recuperate dalla DATA:

Set lines 300
Set pages 60
Col LAST_CALL for a18
Col LOGON_TIME for a18
Col schemaname for a16
Col command for a24
Col machine for a16
Col action for a12
Col username for a16
Col osuser for a16
Col terminal for a16
select to_char(S.logon_time,'DD-MON-YY hh24:mi:ss') LOGON_TIME, s.status, s.inst_id, 
s.sql_id, s.process,s.program, s.schemaname, s.sid, s.serial#, p.spid, p.pid, s.osuser, S.machine, S.terminal,to_char(sysdate -(LAST_CALL_ET/86400),'DD-MON-YY hh24:mi:ss') LAST_CALL , U.username, S.ACTION, decode(S.command,0, 'No command in progress.', 1, 'CREATE TABLE',2, 'INSERT', 3, 'SELECT', 4, 'CREATE CLUSTER', 5, 'ALTER CLUSTER', 6, 'UPDATE', 7, 'DELETE') COMMAND from gv$session S, dba_users U, gv$process P where P.ADDR = S.PADDR and S.user# = U.user_id and to_char(s.logon_time,'DD-MM-YY HH24:MI') < '&data';

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Wordpress Social Share Plugin powered by Ultimatelysocial