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 REDO LOG numero switch

Con l’articolo Query REDO LOG numero switch, possiamo individuare velocemente le fasce orarie in cui il database è in piena attività.

Inoltre, nel caso in cui nell’alert log del database trovaste numerosi messaggi di Checkpoint not complete come il seguente messaggio:

Thu Nov 26 15:16:35 2019
Thread 1 cannot allocate new log, sequence 788067
Checkpoint not complete

Il quale è possibile verificare se la numerosità è elevata attraverso il seguente comando:

grep "Checkpoint not complete"  alert_nomedb.log |wc -l

Occorre effettuare tuning sui REDO LOG, poichè una sotto dimensione starà sicuramente causando numerosi switch e questo potrebbe determinare grossi rallentamenti.

Mi è capitato numerose volte di aver migliorato nettamente le performace del database individuando la corretta dimensione dei REDO LOG in base al carico del database.

Grazie alla query per vedere la quantità di switch in un ora dei REDO LOG è possibile individuare se la dimensione dei REDO LOG è corretta.

Oracle consiglia indicativamente 1 switch ogni 15 o 20 minuti, ossia 4 o 5 switch l’ora.

Quindi potete regolarvi di conseguenza, in base al numero di REDO LOG, vedrete se aumentare la dimensione per diminuire gli switch.

Query REDO LOG numero switch:

select to_char(first_time,'YYYY-MM-DD HH24'),count(*) from v$log_history group by
to_char(first_time,'YYYY-MM-DD HH24') order by
to_char(first_time,'YYYY-MM-DD HH24') ;

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 REDO LOG nome file e status

Nell’articolo Query REDO LOG nome file e status, possiamo vedere i nomi dei file che compongono i gruppi, le dimensioni e lo stato dei redo log Oracle.

I file redo log, indispensabili per il recupero dati in caso di corruzioni, a volte non sono tarati per la mole di dati che il database Oracle movimenta giornalmente e
questo comporta frequenti switch da un redolog a un altro. Il database potrebbe risentirne e per questo avremo la necessità di aumentare la dimensione.

Nel caso avessimo la necessità di aumentare la dimensione dei redolog, andremo ad utilizzare la utilissima query sulla pagina Redo Log,
la quale seleziona i seguenti campi:

GROUP# – Gruppo a cui appartiene il redo log.
MEMBER – Nome del redo log.
STATUS – Stato del redo log.
Size MB – Dimensione dei redo log Oracle in MB.

Per estrapolare queste informazioni dal database Oracle, abbiamo messo in relazione 2 viste:

V$LOGFILE
V$LOG

Nella WHERE condition, abbiamo messo in relazione le 2 viste viste V$LOGFILE e V$LOG attraverso la join lg.group# = lf.group#.

Se l’articolo vi è stato utile, mettete un like e condividete con i vostri colleghi.

Query REDO LOG nome file e status:

set lines 200
set pages 99
col member format a60 
col status for a20
col "Size MB" format 9,999,999 
select lf.group#, lf.member ,lg.status, ceil(lg.bytes / 1024 / 1024) "Size MB" 
from v$logfile lf , v$log lg 
where lg.group# = lf.group# order by 1;
;

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

DDL oggetti ORACLE

Nell’articolo DDL oggetti ORACLE, abbiamo la possibilità di estrarre la DDL degli oggetti.

La DDL (Data Definition Language) di un oggetto, è il codice con cui è definito l’oggetto. In alcuni casi, occorre estrarre il codice di creazione, per verificare le informazioni complete con cui è stato creato l’oggetto.

Quindi, quando dobbiamo estrarre il codice di creazione di un qualsiasi oggetto, possiamo procedere con l’estrazione attraverso il package Oracle dbms_metadata.get_ddl.
Se volete approfondire l’argomento vi indirizzo verso la pagina ufficiale Oracle DBMS_METADATA.

Questa è la modalità manuale per estrarre il codice di creazione.

Oltre a questo metodo, è possibile estrapolare il codice di creazione degli oggetti, attraverso tool grafici come per esempio SQL Developer o con TOAD, andando sull’oggetto nella scheda Script.

Estrazione DDL oggetti oracle TABLE:

set heading off;
set echo off;
Set pages 999;
set long 90000;
select dbms_metadata.get_ddl('TABLE','&TABLE_NAME','&user') from dual;

Estrazione DDL INDEX:

set heading off;
set echo off;
Set pages 999;
set long 90000;
select dbms_metadata.get_ddl('INDEX','&INDEX_NAME','&OWNER') from dual;

Possiamo estrarre le Viste Oracle, che sono query memorizzate nel database per velocizzare il recupero dei dati.

Estrazione DDL VIEW:

set heading off;
set echo off;
Set pages 999;
set long 90000;
select dbms_metadata.get_ddl('VIEW','&VIEW_NAME','&OWNER') from dual;

Successivamente possiamo sfruttare il package Oracle DBMS_METADATA per estrarre interi software programmati all’interno del database come di seguito riportato:

Estrazione DDL PACKAGE:

set heading off;
set echo off;
Set pages 999;
set long 90000;
select dbms_metadata.get_ddl('PACKAGE','&PACKAGE_NAME','&OWNER') from dual;

Estrazione DDL PROCEDURE:

set heading off;
set echo off;
Set pages 999;
set long 90000;
select dbms_metadata.get_ddl('PROCEDURE','&PROCEDURE_NAME','&OWNER') from dual;

Infine sfruttiamo lo stesso Package anche per TRIGGER e FUNCTION.

Estrazione DDL TRIGGER:

set heading off;
set echo off;
Set pages 999;
set long 90000;
select dbms_metadata.get_ddl('TRIGGER','&TRIGGER_NAME','&OWNER') from dual;

Estrazione DDL FUNCTION:

set heading off;
set echo off;
set lines 210
Set pages 999;
set long 90000;
select dbms_metadata.get_ddl('FUNCTION','&FUNCTION_NAME','&OWNER') from dual;

Oltre a questi oggetti, nel sito sono presenti altri articoli, dove viene indicato il modo per poter estrarre le DDL, per esempio sulla creazione dell’utente con le suo RUOLI e PRIVILEGI di riferimento.

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

dbms_ijob remove JOB Oracle

Con l’articolo dbms_ijob remove JOB Oracle, forniamo uno statement che permette di rimuovere definitivamente un JOB dal database Oracle.

Il dbms_ijob è un package nascosto che viene richiamato dal package dbms_job. Questo permette la creazione, cancellazione o la messa in broken di un JOB Oracle ossia fermare la schedulazione del JOB impostando in maniera esplicita lo stato di Broken.

Inoltre la funzione principale del package dbms_ijob, permette la modifica di un JOB con il proprietario un altro utente.

Ossia se entro con l’utente SYS, posso utilizzare il comando dbms_ijob.remove per rimuovere un JOB dell’utente per esempio PIPPO.

Quindi la cancellazione avviene attraverso il package di sistema dbms_ijob con l’opzione remove.

Inoltre il package dbms_ijob a differenza del package dbms_job, permette di rimuovere il JOB che appartiene ad un altro utente.

Rimozione del JOB con il comando dbms_ijob remove JOB Oracle :

exec dbms_ijob.remove(&JOB);

Inoltre, per verificare lo stato se in broken o no, il numero di fallimenti, gli orari della precedente e della successiva esecuzione e il dettaglio di ciò che fa il JOB va interrogata la vista DBA_JOBS con la query reperibile nell’articolo Query JOB Oracle status.

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

DBMS_IJOB BROKEN FALSE

Con l’articolo DBMS_IJOB BROKEN FALSE, forniamo uno statement che permette di abilitare un JOB di un altro utente dallo stato di BROKEN. Ossia lo riabilitiamo con la schedulazione programmata in fase di creazione.

Quando un JOB schedulato nel database Oracle incontra un fallimento, viene rieseguito dopo 1 minuto.
Se fallisce viene eseguito dopo 2 minuti.
Se rifallisce viene di nuovo eseguito dopo 4 minuti e cosi via, fino ad arrivare al sedicesimo tentativo.

Questo permette la fine di questo ciclo e mette il JOB nello stato di BROKEN.

Con l’articolo DBMS_IJOB Broken abbiamo impostato in maniera esplicità lo stato di BROKEN di un JOB con il parametro TRUE.

Invece in questo caso riabilitiamo il JOB, sempre in maniera esplicità con lo stesso package, ma a differenza di prima, invece di lanciare con il parametro TRUE lo lanceremo con il parametro FALSE.

Nel seguente articolo forniamo lo statement per abilitare un JOB dallo stato di BROKEN.

Rimozione del JOB dallo stato di BROKEN con i parametri DBMS_IJOB BROKEN FALSE:

exec dbms_ijob.broken (&JOB,FALSE);

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

DBMS_IJOB BROKEN

Con l’articolo DBMS_IJOB BROKEN, forniamo uno statement che permette di bloccare la normale schedulazione di un determinato JOB.

Quando un JOB schedulato nel database Oracle incontra un fallimento, il JOB viene rieseguito dopo 1 minuto. Se rifallisce, viene eseguito dopo 2 minuti. Se fallisce di nuovo viene di nuovo eseguito dopo 4 minuti e cosi via, fino ad arrivare al sedicesimo tentativo, il quale termina questo ciclo e mette il JOB nello stato di BROKEN.

Può capitare che per qualche motivo che vada bloccata la schedulazione di un determinato JOB Oracle o su richiesta del cliente, o per una particolare attività

Quindi abbiamo 2 possibilità. O impostiamo il JOB in broken con il package DBMS_IJOB BROKEN, oppure se i JOB sono tanti, possiamo impostare il parametro JOB_QUEUE_PROCESSES a 0 in modo tale da disabilitare la partenza automatica dei JOB.
Questo parametro può essere modificato a caldo ed eseguito come segue:

alter systems set job_queue_processes=0 scope=both;

Invece, nel caso in cui dobbiamo disabilitare lo start di un singolo JOB, nell'articolo forniamo uno DBMS_IJOB Broken, vi permetterà di bloccare la normale schedulazione di un JOB.

Inoltre il package dbms_ijob a differenza del package dbms_job, permette di rimuovere il JOB che appartiene ad un altro utente.

exec dbms_ijob.broken (&JOB,TRUE);

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 JOB Running

Nell’articolo Query JOB Running, forniamo una query che permette di identificare i JOB in esecuzione di tutti gli utenti del database.

La vista che permette l’accesso alle informazioni dei JOB Running è la tabella DBA_JOBS_RUNNING, da cui è possibile reperire molte informazioni utili tra cui il numero il SID della sessione associata, il numero del JOB in esecuzione, orario di inizio, ultima esecuzione, prossima esecuzione, il dettaglio del JOB più l’istanza in cui sta girando nel caso in cui fosse un ambiente RAC.

Quindi se dobbiamo approfondire l’analisi, attraverso il SID possiamo reperire informazioni utili relativa alla sessione generata grazie alla query nell’articolo Query sessioni SID Oracle.

Una volta recuperate le informazioni di orario di LOGON, SCHEMA di riferimento ecc., abbiamo la possibilità di verificare quale statement sta girando attraverso SQL_ID, reperibile dalla query precedente attraverso lo statement nell’articolo Query per estrarre statement da un SQL_ID successivo EXPLAIN PLAIN dello statement

Quindi se vogliamo approfondire l’analisi abbiamo le giuste query per analizzare la sessione.

Query per controllare i JOB Running:

select /*+ rule */ * from dba_jobs_running;

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 JOB Oracle status

Con l’articolo Query JOB Oracle status, forniamo uno statement per individuare informazioni sui JOB schedulati nel database.

Il JOB è una schedulazione di un procedura, di un package PL/SQL o di una semplice istruzione che viene programmata per partire in un determinato giorno e orario in cui vogliamo eseguire il software.

Quindi, se vogliamo far partire un istruzione in un determinato momento dobbiamo programmare un JOB nello scheduler Oracle.

Una volta che il JOB è programmato lui partirà ogni volta che viene richiesto.

Nel caso in cui il JOB dovesse fallire, viene rieseguito in maniera automatica di default per 16 volte, fino ad arrivare allo stato di BROKEN ossia che viene interrotta la schedulazione per via dei troppi fallimenti.

Quindi per verificare lo stato di un JOB, forniamo la query in fondo alla pagina.

Selezioniamo il numero del JOB, l’utente con cui è stato schedulato e l’utente proprietario.

Inoltre selezioniamo la data e l’orario dell’ultima e della prossima esecuzione.

Infine selezioniamo il numero di fallimenti, lo stato di BROKEN e il codice o la procedura schedulata.

Quindi recuperiamo le informazioni alla vista DBA_JOBS
e i filtriamo i record per numero di JOB.

Query JOB Oracle status:

set lines 200 pages 999
col log_user format a15
col priv_user format a15
col schema_user format a15
col last_run format a15
col next_run format a15
col what format a60
col fails format 999
select job
, log_user
, priv_user
, schema_user
, to_char(last_date, 'hh24:mi dd/mm/yy') last_run
, to_char(next_date, 'hh24:mi dd/mm/yy') next_run
, failures fails
, broken
, substr(what, 1, 60) what
from dba_jobs
where job=&job
order by 4;

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.

Wordpress Social Share Plugin powered by Ultimatelysocial