Oracle Dashboard in Graylog

As you know for the SE version is not covered performance in OEM, so you can not see the real-time DB performance.
This is a limitation (license) commissioned by Oracle for the SE, but given the continued growth and spread of this release, I thought a way to fill a bit this absence.
Graylog is an open source software for log management that lets you index, historical context, for further analysis, any type of log and not structured, servers and platforms.
My idea:

• logstash to capture SQL statements connecting to the database and then send them to the server graylog
• Graylog server to centralize all SQL statements in real-time and create dashboards.

I created a repository on github where explain these steps for installation and related resources used in my working setup.

When I connect my instance graylog I can check each sql statement executed ASH (I deliberately obscured sql statement):

Creating dashboards with Graylog, based on what you want to analyze, the reading is much easier and immediate:

Yuo can find all here in Graylog Market....

Enjoy !!!

Oracle Ash on @graylog2 by @logstash

Dai un'occhiata al Tweet di @Albertofro: https://twitter.com/Albertofro/status/601027107112751105?s=09

OraSash v2.4 RC2

Un breve post per comunicare che la nuova release 2.4 di  OraSash RC2 è disponibile.
Tra le nuove features testate e sviluppate, c'è la piena compatibilità ad Oracle 12c ed altro ancora, vi rimando alla pagina ufficiale del progetto per maggiori informazioni.

https://github.com/pioro/orasash/tree/v2.4-rc2

Java7 Update40 - Sql Developer - Ubuntu

Ieri sera ho aggiornato la mia versione Java installando l'ultimo pacchetto di update nel mio Ubuntu 12.04, risultato Sql Developer non funzionava più correttamente.
Avevo gli stessi problemi di quando lo usavo con li librerie OpenJava, ossia funzionava ma mi dava dei problemi su alcune funzioni come Debugger e altro.
Per risolvere questo avevo installato Java7 update 25 e tutto funzionava correttamente, fino a ieri sera....
Il comportamento di Java7 errato ( Update40) consiste in questo per esempio, se vado per eseguire una procedura mi capita questo:

alberto@AbeInsp:~$ java -version

java version "1.7.0_40"

Java(TM) SE Runtime Environment (build 1.7.0_40-b43)

Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)

ossia la non mi compare la schermata successiva...
Mentre con la corretta versione mi compariva:

Come faccio per risolvere questo inghippo?
Nel mio pc ho le seguenti installazioni di java in /usr/lib/jvm :

drwxr-xr-x   8 root root  4096 giu 30 11:35 java-6-oracle

drwxr-xr-x   8 root root  4096 ott  8 21:48 java-7-oracle

Quella java7 è quella con il problema ma ho installato anche la versione 6 per fortuna.
Allora si fa tutto più semplice perchè con i seguenti comandi:

sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/java-6-oracle/bin/javac" 1

sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/java-6-oracle/bin/java" 1

imposto dove l'installazione si trova mentre con questo:

sudo update-alternatives --set "javac" "/usr/lib/jvm/java-6-oracle/bin/javac"

sudo update-alternatives --set "java" "/usr/lib/jvm/java-6-oracle/bin/java"

imposto qual'è la mia installazione di default.

Fatto questo e lanciando java -version:

java version "1.6.0_45"

Java(TM) SE Runtime Environment (build 1.6.0_45-b06)

Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)

Ora Sql Developer ha ripreso a funzionare correttamente.

La mia versione di Sql Developer  3.2.20.09 è pienamente supportata con la versione Java6, mentre con la versione 7 e relativi update è uscita la versione 4 scaricabile quì.

Nel mio caso ha funzionato correttamente fino alla versione 7 update 25.

ORA-04030: out of process memory when trying to allocate 16396 bytes (koh-kghu sessi,pmucalm coll)

Problematica diffusa quando si ha una procedura PL/SQL o Packages che divorano memoria.
Nel mio caso lanciando un package di archiviazione di un software mi sono imbattuto in questo errore in una virtual machine Windows 2003 32bit con 3 GB di RAM, Oracle 10G R2.
Questo argomento è descritto anche nel doc Metalink ID 1325100.1.
Nel Metalink fanno eseguire un trace dove nel dump si vede benissimo che è un problema di allocazione di memoria.
Il_realfree_heap_pagesize_hint nella 10g fa sì che il processo di  private memory (PGA) usi pagine di allocazione più grandi, riducendo così TLB/TSB.
In questo caso occorre controllare due parametri nell'instanza:_use_realfree_heap e _realfree_heap_pagesize_hint che sono impostati per default.

select i.ksppinm name , v.ksppstvl cur_val,

v.ksppstdf default_val, v.ksppstvf

from x$ksppi i, x$ksppcv v

where i.indx = v.indx

and i.ksppinm in ('_realfree_heap_pagesize_hint', '_use_realfree_heap')



NAME                                     CUR_VAL    DEFAULT_V   KSPPSTVF

—————————————- ———- ——— ———-

_realfree_heap_pagesize_hint             65536      TRUE               0

_use_realfree_heap                       TRUE       TRUE               0

A questo punto provvedo a modificare solo il _realfree_heap_pagesize_hint :

alter system set "_realfree_heap_pagesize_hint" = 262144 scope=spfile;

e riavviare il db.

Una volta riavviato controllo se ha preso il nuovo parametro sempre con:

select i.ksppinm name , v.ksppstvl cur_val,

v.ksppstdf default_val, v.ksppstvf

from x$ksppi i, x$ksppcv v

where i.indx = v.indx

and i.ksppinm in ('_realfree_heap_pagesize_hint', '_use_realfree_heap')



NAME                                     CUR_VAL    DEFAULT_V   KSPPSTVF

—————————————- ———- ——— ———-

_realfree_heap_pagesize_hint             262144     TRUE               0

_use_realfree_heap                       TRUE       TRUE               0

Ci sono moltissimi esempi tra l'altro ben documentati, per quanto riguarda macchine ovviamente Solaris o Linux, ma in ambiente Windows purtroppo non ho trovato quasi nulla.

Aspetto feedback....

Beginning Performance Tuning

Volevo consigliare la lettura di questi due articoli di Arup Nanda in merito a "Beginning Performance Tuning".
Scritti come sempre in modo chiaro e preciso per un buon inizio della tecnica di tuning delle performance a 360 gradi.

Beginning Performance Tuning

Beginning Performance Tuning: Diagnose the Past

ORA-25254: time-out in LISTEN while waiting for a message

Tramite un trigger LOG_ERRORS con caratteristica di "AFTER EVENT" presente nel DB insieme con altri packages, scrivo tutti gli errori in una tabella in modo tale che posso verificare ogni giorno lo stato del DB.
Nel mio caso si verificava ripetutamente ORA-25254.

Verificando attraverso il metalink, ho scoperto che si tratta del Bug 3498760.
Questo errore è relativo all'applicazione AQ che è configurata con un timeout di DEQUEUE che specifica il tempo effettivo di attesa per l'arrivo dei messaggi, se non ci sono messaggi in questo timeout il sistema genera questo errore.
Questo errore non è classificato come crittical e si potrebbe tranquillamente tralasciare, ma nel mio caso visto che scrivo tutti gli errori nella mia tabella di controllo è un problema, perchè la fa crescere a dismisura.

Ci sono un paio di risoluzione proposte in merito la prima è quella di interrompere il job che esegue EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS() ma questo potrebbe avere delle ripercussioni nel EM.
La seconda è quella meno drastica e preferibile, si cambia semplicemente il valore di timeout di DBMS_AQ.LISTEN.

Andiamo in $ORACLE_HOME/sysman/admin/emdrep/sql/core/latest/notification e modifichiamo il file notification_pkgbodys.sql nella sezione:

DBMS_AQ.LISTEN (agents, qtimeout_in, agent)

cambiandola in: 

DBMS_AQ.LISTEN (agents, 1200, agent);

entrare come utente SYSMAN con SQLPlus ed eseguire lo script notification_pkgbodys.sql.

Eventualmente per sicurezza è possibile fare una copia del file notification_pkgbodys.sql originale prima di modificarlo.

emca -deconfig dbcontrol db -repos drop hangs

La settimana scorsa dopo un serie di errori visualizzati nei log, mi sono deciso di riconfigurare il mio OEM 10G.
Eseguendo emca -deconfig dbcontrol db -repos drop il comando restava in hang, ma la cosa più fastidiosa è che imposta lo stato del DB in QUEISCING durante questa operazione.
E' chiaro che se il comando dura pochi minuti, nessun problema, mentre se rimane in hang per più tempo ovviamente ci potrebbe essere qualche problema in più.

Quando fermavo il comando, credevo che il DB riprendesse lo stato NORMAL, ma invece continuava ad essere in QUEISCING.

Ho eseguito ALTER SYSTEM UNQUIESCE ma con scarsi risultati.
Ho consultato la vista v$blocking_quiesce per verificare se il comando lanciato precedentemente, benchè l'avessi fermato, continuava ad essere attivo.

Infatti il processo era attivo, una volta fermato l'istanza è tornata allo stato NORMAL.
Ho provato ad eseguire questa operazione un paio di volte ma sempre con lo stesso risultato,  emca -deconfig dbcontrol db -repos drop rimaneva in hang.

Per eliminare e riconfigurare il mio OEM ho dovuto farlo nella modalità manuale cancellando l'utente SYSMAN e tutte le viste,ruoli sinonimi associati con:

DROP USER sysman CASCADE;

DROP PUBLIC SYNONYM SETEMVIEWUSERCONTEXT;

DROP ROLE MGMT_USER;

DROP PUBLIC SYNONYM MGMT_TARGET_BLACKOUTS;

DROP USER MGMT_VIEW;

A questo punto ho potuto ricreare il repository senza problemi con: emca -config dbcontrol db -repos create.

Vi segnalo questo link sull'argomento molto utile ed esaustivo.

dbms_support.start_trace

Eseguendo un'operazione con un applicativo di archiviazione dati, mi sono imbattuto in un errore software molto generico che tratterò nel prossimo post.

Questo software per archiviare i dati utilizza l'utility export di Oracle (non Datapump) in modo ciclico, infatti, prima esegue delle query per identificare tramite i parametri dati dall'utente che cosa effettivamente archiviare e poi lancia export di Oracle.

Per la quantità di dati presenti e per le capacità del server impiega circa 48 ore per eseguire l'archiviazione desiderata lanciando così l'export di Oracle circa 6 volte, eseguendo di fatto l'export a trance. Visto la durata e la modalita dell’operazione  dovevo mettere il tutto  in trace.

Parlando con il supporto del software mi è stato detto che il problema era del tool di export Oracle e di verificare quale fosse il problema, ovviamente l'errore poteva manifestarsi sia nella prima ma come nella quarta o sesta trance cioè in modo casuale, quindi non potendo essere presente e attivo per tutto questo tempo davanti ad un monitor ho creato una procedura la quale esegue il trace dell'export quando è lanciato

La procedura identifica tramite la V$SESSION la sessione da monitorare con il trace lancia il package dbms_support.start_trace. Questo package lanciato senza parametri abilita a level 1 il trace altrimenti:

Event 10046 level 4:
dbms_support.start_trace (binds=>true);

Event 10046 level 8:
dbms_support.start_trace (waits=>true);

Event 10046 level 12:
dbms_support.start_trace (binds=>true,waits=>true);

E' da ricordare inoltre che questo package non è installato di default da Oracle e per utilizzarlo bisogna lanciare lo script ..../rdbms/admin/dbmssupp.sql.

Consiglierei inoltre di verificare il valore del parametro max_dump_file_size perchè altrimenti una volta arrivato a 100MB non scrive più il file di trace, bisogna impostarlo a UNLIMITED con ALTER SYSTEM SET max_dump_file_size = UNLIMITED;

Facendo così ho trovato nella solita cartella udump i miei traces files.

Aggiornamento 23/08/2012

Ho dovuto togliere la procedura principalmente per 2 motivi:

1. Non era completa visto che, alcuni parametri gli venivano passati da un package che non posso postare perchè proprietario del software in questione.
2. Questa procedura viene lanciata proprio da questo package che ho parzialmente modificato.

Ho preferito tenere questo post, sperando a breve di poter inserire la mia procedura in modo diverso così da non creare ambiguità non violando proprietà software.

ASH (S-ASH) Update

Un rapido update sull'ottimo tool S-ASH, potete scaricare la release del tool aggiornata con delle nuove features, ultima ma sempre in continua evoluzione, quella di creare nella stesso DB il repository e l'agent anche dalla versione Oracle 9i.
E' stato aggiornato e consolidato anche per la versione Oracle XE.
Questo è il link:
https://github.com/pioro/orasash/tree/master/sash_dev

Per ulteriori informazione potete sempre consultare il blog di Marcin

ASH (S-ASH)

Oggi vorrei parlare di uno splendido tool S-ASH, visto che da sempre sono stato affascinato dall'ASH (Active Session History) di Oracle.
S-ASH project è stato creato da Kyle Hailey successivamente ripreso da Marcin Przepiorowski.
Nel mese di Novembre, Marcin ha rilasciato un'ultima versione di questo tool, ovviamente l'ho subito scaricato per testarlo con i miei DB.
Inizialmente ho trovato qualche difficoltà per l'implementazione nelle mie versioni Oracle 10G, in collaborazione con Marcin ho provveduto a modificare alcuni packages e procedures in modo tale che funzionasse tutto.
S-Ash non solo simula semplicemente ASH ma crea delle tabelle e altri oggetti dove tiene una session history, lo stato dei singoli sql e gli sql plan e molto altro ancora.
S-ASH si compone principalmente di un repository DB e degli agent installati nei DB interessati.
Questi agent invieranno tutte le informazioni al repository semplificando notevolmente il lavoro di gestione di un DBA.
Questo tool si può scaricare quì .

Space log files problems

Un aspetto importante, non secondario che un DBA deve sempre tener conto è la dimensione dei file di log di Oracle, per esempio il listener.log.
Nei database altamente transazionali questo file può raggiungere anche in pochi giorni dimensioni elevate.
Nel log file listener si trovano moltissime informazioni riguardanti la sicurezza, chi si connette al DB e i possibili errori di connessione, anche se come tutti sappiamo non è un'attività entusiasmante tenere controllato questo file soprattutto se raggiunge una dimensione molto elevata.
Così ho pensato di creare uno script sempre su Solaris che schedulato 1 volta al giorno oppure in base alla crescita del file, si occupi almeno di tenere monitorata la dimensione:

#!/usr/bin/ksh
MAX_SIZE="200000000" 

FILE="/network/log/listener.log" 
FILEO="/network/log/listener.old"
FILEZ="/network/log/listener_`date +%Y_%m_%d`.gz"
LOGFILE="/tmp/Sitlistener.log"

SIZE="$(ls -al $ORACLE_HOME$FILE | awk '{print $5}')"


if [ "$SIZE" -gt "$MAX_SIZE" ] ; then
echo "$SIZE"
echo " \n$(date) Run listener space procedure, size "$SIZE" .">> $LOGFILE 
lsnrctl set log_status off >> $LOGFILE >&1
status=$?
if [ ${status} -eq 0 ]
then
echo $status
else
echo " \n$(date) Problem listener log_status off.">> $LOGFILE 
mailx -s " Problem listener log_status off." alberto@abc.com < $LOGFILE
exit 1
fi
mv $ORACLE_HOME$FILE $ORACLE_HOME$FILEO >> $LOGFILE >&1
status=$?
if [ ${status} -eq 0 ]
then
echo $status
else
echo " \n$(date) Problem rename listener.">> $LOGFILE 
mailx -s " Problem rename listener." alberto@abc.com < $LOGFILE
exit 1
fi
lsnrctl set log_status on >> $LOGFILE >&1
status=$?
if [ ${status} -eq 0 ]
then
echo $status
else
echo " \n$(date) Problem listener log_status on.">> $LOGFILE 
mailx -s " Problem listener log_status on." alberto@abc.com < $LOGFILE
exit 1
fi
gzip -c $ORACLE_HOME$FILEO > $ORACLE_HOME$FILEZ >&1
status=$?
if [ ${status} -eq 0 ]
then
echo $status
else
echo " \n$(date) Problem gzip old listener.">> $LOGFILE 
mailx -s " Problem gzip old listener." alberto@abc.com < $LOGFILE
exit 1
fi
rm $ORACLE_HOME$FILEO >> $LOGFILE >&1
status=$?
if [ ${status} -eq 0 ]
then
echo $status
else
echo " \n$(date) Problem delete old listener.">> $LOGFILE 
mailx -s " Problem delete old listener." alberto@abc.com < $LOGFILE
exit 1
fi
else
echo " \n$(date) Check listener space, no Problem." $LOGFILE
fi

Questo script esegue in una prima fase il controllo della dimensione del listener.log e se lo trova superiore ad MAX_SIZE esegue rispettivamente:

1)Imposta set log status off del file ossia il listener smette di scrivere in questo file.
2)Rinomina il file listener in listener.old
3)Imposta set log status on del file, il listener riprendere a scrivere su un nuovo file.
4)La compressione del file attraverso il Gzip.
5)Cancella il file listener.old precedentemente compresso

Lo script inoltre va a popolare un log file.
L'exit status viene sempre controllato in modo tale da terminare lo script se l'exit status non fosse uguale a 0 mandando una mail.
Se le dimensioni del log non superano quella del MAX_SIZE ovviamente lo script non esegue niente ma viene comunque popolato il file di log dello script.
Una volta finito lo script nel path $ORACLE_HOME/network/log si visualizza una situazione simile con il comando ls- al:

drwxr-xrwx   2 oracle   dba            6 Nov 29 16:29 .
drwxr-xrwx  13 oracle   dba           13 Jun 30  2010 ..
-rw-r-----   1 oracle   dba      3165694 Nov 30 12:26 listener.log
-rw-r--r--   1 oracle   dba      19469262 Nov 29 16:17 listener_2011_11_29.gz
-rw-r-----   1 oracle   dba      1605299 Nov 30 06:45 sqlnet.log

Archiver Hung Alert Log Error - No space left on device

Questo fine settimana un DB dell'ambiente di produzione si è fermato, con il più classico degli errori: Archiver Hung Alert Log Error, No space left on device.

In effetti lo spazio su disco nel path /arch_oracle/ è finito, bloccando così di fatto la transazione del DB.
Ho lanciato lo script di backup per gli archive, e la situazione è tornata alla normalità.

Dopo questa operazione ho pensato ad un programma che facesse le stesse operazioni mie ma ovviamente in automatico.

L'ambiente è in Solaris quindi il tutto è facilitato:

ksh
MULTI_INSTANCE=0
set +u
USER=$(whoami)
LOGFILE="/tmp/Sitarch"
HOST=$(hostname)
OSTYPE=$(uname)

for i in 1 2 3 4 5 6 7 8 9 10 11 12
 do 
 ARCH=" "
        ARCH="$(df -k  /arch_oracle | awk '{print $4}' | tail -1)$ARCH"
 if [ "$ARCH" -le 10010283  ] ; then
 echo "$ARCH"
 echo " \n$(date) Space /arch_oracle is less of $ARCH, Archive job run, check mail.">> $LOGFILE
 /oracle/bckarch.sh >/dev/null 2>&1
 mailx -s " Space /arch_oracle is less of $ARCH, Archive job run, check mail." alberto@abc.com > $LOGFILE
 fi
 sleep 1710
 done

Con questo script in Korn shell schedulato nel crontab il sistema va a verificare ogni 30 min circa se lo spazio è inferiore ad un certo valore (in questo caso a 10 GB) e va a scriverlo in un file di testo, quando trova la condizione vera ossia che il valore è inferiore fa partire lo script bckarch e manda una mail.

Per esigenze il loop ovviamente cambia se volessimo farlo girare 24 * 7.
In questo caso è attivo per 6 ore.

TUNING session_cached_cursor with PL/SQL procedure

Dopo aver rivisto i miei post riguardanti session_cached_cursor ho deciso di provare a mettere insieme una procedura PL/SQL che oltre a trovare gli utenti che con la loro sessione superano il 100% di hit/parse, desse informazioni aggiuntive come per esempio il nome, l’id_sql utilizzato o precedente, sql_text, event e altro in modo da dare un quadro completo e più dettagliato.
Forse lo stesso risultato si poteva ottenere con un buon codice SQL ma ho preferito creare una procedure anche per rispolverare la mia programmazione PL/SQL.

Praticamente esegue dei loop su entrambi i cursori C1 e C2 in modo da mettere in luce solo quelle sessioni che superano il 95% di hit/parse.
Una volta compilata dando ovviamente i grant di select di un utente che non sia SYS alle tabelle di sistema come per esempio V$SESSION,v$sqlarea ecc. si può facilemente lanciare con:

CREATE OR REPLACE
PROCEDURE session_mon
IS
  CURSOR c1
  IS
    SELECT hits.sid,
      hits,
      parses,
      ROUND(hits/parses*100)
    FROM
      (SELECT sid,
        s.value hits
      FROM v$statname n,
        v$sesstat s
      WHERE s.statistic# = n.statistic#
      AND n.name         = 'session cursor cache hits'
      ) hits ,
    (SELECT sid,
      s.value parses
    FROM v$statname n,
      v$sesstat s
    WHERE s.statistic# = n.statistic#
    AND n.name         = 'parse count (total)'
    ) parses
  WHERE hits.sid             = parses.sid
  AND parses.parses          > 0
  AND ROUND(hits/parses*100)>=95
  ORDER BY 1 DESC;
  c1_sid sys.v_$sesstat.sid%TYPE;
  c1_hits v$sesstat.value%TYPE;
  c1_parses v$sesstat.value%type;
  c1_hp NUMBER :=ROUND(c1_hits/c1_parses*100);
  CURSOR c2
  IS
    SELECT s.sid,
      P.SPID,
      S.SERIAL#,
      S.OSUSER,
      SA.SQL_TEXT,
      SA.SQL_ID,
      s.prev_sql_id,
      S.STATUS,
      S.USERNAME,
      SW.STATE,
      SW.EVENT,
      S.MACHINE,
      S.PROGRAM
    FROM V$SESSION S,
      V$PX_SESSION PX,
      V$SESSION_WAIT SW,
      V$PROCESS P,
      V$SQLAREA SA,
      (SELECT * FROM V$SESSION_LONGOPS WHERE TIME_REMAINING <> 0
      ) SLO,
    (SELECT SID FROM V$MYSTAT WHERE ROWNUM = 1
    ) OWNSESSION
  WHERE s.sql_address=sa.address(+)
  AND S.SID          = SW.SID(+)
  AND S.PADDR        =P.ADDR
  AND (S.SID         = SLO.SID(+)
  AND S.SERIAL#      = SLO.SERIAL#(+))
  AND (S.SID         = PX.SID(+)
  AND S.SERIAL#      = PX.SERIAL#(+))
  AND S.TYPE         = 'USER'
  AND S.OSUSER      <> 'jdeb7333'
  AND S.OSUSER      <> 'oracle'
  ORDER BY 1 DESC;
  c2_sid v$session.sid%type;
  c2_spid V$PROCESS.spid%type;
  c2_serial V$SESSION.serial#%type;
  c2_osuser v$session.osuser%type;
  c2_SQL_TEXT v$sqlarea.sql_text%type;
  c2_SQL_id v$sqlarea.sql_id%type;
  c2_prev_SQL_id V$SESSION.prev_sql_id%type;
  c2_status v$session.status%type;
  c2_username v$session.username%type;
  c2_state v$session_wait.state%type;
  c2_event v$session_wait.event%type;
  c2_machine v$session.machine%type;
  c2_program v$session.program%type;
BEGIN
  OPEN C1;
  OPEN C2;
  <>
  LOOP
    FETCH C1 INTO c1_sid,c1_hits, c1_parses,c1_hp;
    EXIT
  WHEN C1%NOTFOUND;
    LOOP
      FETCH C2
      INTO c2_sid,
        c2_spid,
        c2_serial,
        c2_osuser,
        c2_SQL_TEXT,
        c2_SQL_id,
        c2_prev_SQL_id,
        c2_status,
        c2_username,
        c2_state,
        c2_event,
        c2_machine,
        c2_program;
      IF c2_sid = c1_sid THEN
        DBMS_OUTPUT.ENABLE (buffer_size => NULL);
        DBMS_OUTPUT.PUT_LINE(c1_hp||'% ;'|| c2_sid||'; '|| c2_spid||'; '|| c2_serial ||'; '|| c2_osuser||'; '||c2_SQL_TEXT ||'; '||c2_SQL_id ||'; '|| c2_prev_SQL_id||'; ' || c2_status||'; '|| c2_username||'; '|| c2_state||'; '|| c2_event||'; '|| c2_machine||'; '|| c2_program);
        CLOSE C2;
        OPEN C2;
        GOTO lp;
      ELSE
        IF C2%NOTFOUND THEN
          CLOSE C2;
          OPEN C2;
          GOTO lp;
        ELSE
          EXIT
        WHEN C1%NOTFOUND;
        END IF ;
      END IF ;
    END LOOP;
    EXIT
  WHEN C2%NOTFOUND;
  END LOOP;
  CLOSE C1;
  CLOSE C2;
END session_mon;

set serveroutput on;
exec session_mon;


blocco anonimo completato
  
153% ;165; 23930; 29654; mario.rossi; ; ; 7nacmhkk9c6rh; INACTIVE; *_D**_*I*; WAITING; SQL*Net message from client; domain\servername; o*xp***e.ex*

99% ;143; 24207; 62019; roberto.verdi; INSERT INTO ..... ; 8x6ddxfcuwqna; 8x6ddxfcuwqna; INACTIVE; *_D**_*I*; WAITING; SQL*Net message from client; domain\servername; o*xp***e.ex*

100% ;137; 13757; 40756; giovanni.neri; DELETE FROM ...... ; 2apjjpak50830; 2apjjpak50830; INACTIVE; *_D**_*I*; WAITING; SQL*Net message from client; domain\servername; o*xp***e.ex*

96% ;89; 13484; 37497; maria.beralda; SELECT * FROM .....; 2f3a5zqx90uxc; 2f3a5zqx90uxc;  INACTIVE; *_D**_*I*; WAITING; SQL*Net message from client; domain\servername; o*xp***e.ex*

167% ;74; 26811; 11150; guido.lavespa; ; ; 6cyvu230zxnx8; INACTIVE; *_D**_*I*; WAITING; SQL*Net message from client; domain\servername; o*xp***e.ex*

107% ;44; 14366; 41924; giovanna.coscialunga; ; ; 6cyvu230zxnx8; INACTIVE; *_D**_*I*; WAITING; SQL*Net message from client; domain\servername; o*xp***e.ex*

Notiamo che la prima colonna, anche se la formattazione non è delle migliori è rappresentata della percentuale hit/parse del sid che supera in questo caso il 95%, le altre colonne inserite rispettivamente, spid, serial, osuser,  SQL_TEXT, SQL_id,prev_SQL_id,status,username,state,event,machine e infine il program.



Ho diviso le colonne con il ; in modo da poter importare il risultato in un altro file software per avere una maggiore leggibilità e per eseguire ulteriori analisi.



Questa procedura potrebbe essere un buon inizio per un tuning, mettendo in luce gli utenti che hanno un hit/parse elevato, sfuttando la Session Cursor Cache.



Aspetto commenti...

LISTENER GETS HUNG UP in Oracle 10.2.5.0

Mi sono imbattuto in un altro bug 4518443 della versione 10.2.5.0, critico e abbastanza fastidioso.
Il servizio listener va in hang (LISTENER GETS HUNG UP) causando il blocco di nuove connessioni al DB da parte dell'applicativo.
Inizialmente quando si verifica questo problema provavo a riavviare più volte il listener senza ottenere alcun risultato.
Dopo alcuni minuti (possono essere 2 come 20) il listener riprende a funzionare senza problemi.
Controllando nel supporto oracle ho visto che il problema era già ben conosciuto, bug 4518443 .
Per risolvere questo problema il supporto suggerisce di installare la relativa patch 4518443 oppure un workaround.

Leggendo alcuni articoli e forum in OTN mi sono ben reso conto che la patch potrebbe essere non proprio risolutiva perchè fa parte di un patchset molto più corposo, inoltre in ambienti non RAC suggerivano di implementare solo il workaround.

Quindi ho fatto come suggerisce la nota:

1. Aggiungere la riga SUBSCRIBE_FOR_NODE_DOWN_EVENT_<listener_name>=OFF nel file listener.ora


2. Rinominare il file $ORACLE_HOME/opmn/conf/ons.config in ons.config.orig con il comando nel mio caso mv ons.config ons.config.orig.


3. Riavviare il listener.

Facendo così il problema sembra superato, ma il buon senso mi dice di aspettare ancora un pò.....

ora-01882 "timezone region not found" in SqlDeveloper 3.0.04

Un breve post per descrivere e risolvere  un errore molto fastidioso in SqlDeveloper versione 3.0.04.
Ho aggiornato la versione del SqlDeveloper alla 3.0.04 tutto bene per le connessioni ai DB con Oracle 10g, ma quando tento di collegarmi in un DB Oracle versione 9i ecco il misfatto:
ora-01882 "timezone region not found"

All'inizio non capivo realmente la situazione visto che con le versioni precedenti non avevo questo problema.
Ho provato a verificare le impostazione del mio db, ma il problema alla fine stava in  SqlDeveloper.
Ho verificato le impostazioni dell'applicazione ma non mi sembrava nulla di diverso dalla release precedente tale da generare questo errore.

Alla fine dopo alcune ricerche è spuntato fuori il problema e la relativa risoluzione anche se non ben documentata.
L'errore è  nel file sqldeveloper.conf dove bisogna aggiungere la seguente riga:

AddVMOption -Duser.timezone="+02:00"

Dove +02:00 sta indicare le ore di differenza da Greenwick ovviamente dall'Italia.

Una volta impostato questo parametro e riavviato il software tutto ha ripreso a funzionare magicamente.

ORA-600 [KCBLASM_1], [103] Patchset 10.2.0.5

E' da unpò di tempo che nell'alert log di una istanza compare ORA-600 [KCBLASM_1], ho verificato nel metalink e sembra che sia un bug,  precisamente il 7612454.

Sempre nel metalink ho trovato che questo bug è riportato nel documento ID 1133845.1.
Adesso proviamo a vedere le cause e le possibili soluzioni.
Quando eseguiamo un SQL utilizzando una selec ci compare l'errore:
ORA-00600: internal error code, arguments: [kcblasm_1], [103], [], [], [], [], [], []

L' execution plan di ORA-600 trace file mostra che una  hash join è stata utilizzata.
Call Stack is including:
kcblasm1 kcblasm kxhfFndFreeSlot kxhfNewBuffer qerhjGetNewBuffer ksxb1bqb kxhrPack.

In realtà  questo problema era già stato visionato con il Bug 9800302 - 10.2.0.5 GETTING ORA-00600 [KCBLASM_1] chiuso perchè uguale al nostro bug 7612454 - Abstract: DSS:PERF REGRESSIONS IN SERIAL DIRECT READS fixed in 11.2.

Sembra che il problema sia nell'algoritmo della funzione hash-join, il quale forza l'utilizzo un numero più esiguo di slots, mentre gli slots disponibili per le direct I/Os sono 4096, aggravando così maggiormente i dischi causando:

1. direct path IO to perform worse in 10.2.0.5 than earlier releases with more "direct path read" operations or 
2. ORA-600 [kcblasm_1] errors.

Come al solito Oracle come prima soluzione consiglia di passare alla versione 11.2, quindi passiamo oltre.

Come seconda opzione c'è una patch, per sistemi Windows, il Patch 3 della 10.2.0.5 o superiore mentre per il mio caso con OS Solaris si può scaricare direttamente la patch specifica.

Come terza opzione c'è un  workaround settando il paramentro "_hash_join_enabled"= false.

La patch in questione è di circa un anno fa e i problemi nel mio caso sono comunque sporadici quindi per non intaccare la stato del DB inizialmente proverò con il workaround e controllerò i bene risultati, nel frattempo per tenermi pronto ho scaricato la patch.

RMAN Backup Strategies - Part 2

Questo riepilogo non è disponibile. Fai clic qui per visualizzare il post.

RMAN Backup Strategies - Part 1

In questo post vorrei trattare, almeno per punti, le varie strategie di backup con RMAN di Oracle, ovvero le operazione quotidiane che ogni DBA dovrebbe fare per verificare se i backup sono stati eseguiti con successo e le relative verifiche di sicurezza.

Ritengo acquisito il perchè dell'utilizzo del recovery catolog di RMAN su un altro server, dove vengono scritte a livello logico tutte le informazioni relative a tutti i backup di RMAN di una o più istanze Oracle, anche di versioni differenti. (9i-10g)

I backup possono esssere possono essere di varie tipologie, quello che prenderò in esame nel mio caso è quello incremental level 0.
I backup incrementali possono essere di livello 0 o livello 1.
Il backup level 0 backup incrementale, copia tutti i blocchi che contengono dati, come un completo set di backup, che è la inoltre la base per i successivi backup incrementali level 1.
Infatti questa è l'unica differenza tra un level 0 di backup incrementale e un full backup, ossia quest'ultimo non può essere mai incluso in una strategia incrementale.

Nel mio caso ho optato proprio per questa strategia ossia un incremental level 0 eseguito 3 volte al giorno,
senza utilizzare ulteriori backup incrementali di level 1.

Queste considerazioni vanno prese dopo un'analisi attenta del DB, basate principalmente sulla dimensione,
sul tempo di esecuzione di backup e sul tempo di restore

Per esempio per un DB molto grande forse non sarà possibile eseguire un level 0 ogni giorno allora si procederà con un level 0 durante in week-end e successivi level 1 durante tutta la settimana.

In un db faccio eseguire questo script di RMAN per il backup:

run {

allocate channel 'dev_0' device type disk;

allocate channel 'dev_1' device type disk;

backup incremental level 0 filesperset 4

format '/DataDomain/****/******_%s_%t_%p.dbf'

database

include current controlfile;

sql 'alter system archive log current';

backup filesperset 1

format '/DataDomain/****/****ARCH_%s_%t_%p.arch'

archivelog all delete input;}

crosscheck backup device type disk;

delete noprompt obsolete;

delete noprompt expired backupset;



allocated channel: dev_0

channel dev_0: sid=142 devtype=DISK



allocated channel: dev_1

channel dev_1: sid=148 devtype=DISK



Starting backup at 27-JUN-11

channel dev_0: starting incremental level 0 datafile backupset

channel dev_0: specifying datafile(s) in backupset

input datafile fno=00046 name=/****/undotbs01.dbf

input datafile fno=00035 name=/****/indici01.dbf

............

channel dev_1: starting piece 1 at 27-JUN-11

channel dev_0: finished piece 1 at 27-JUN-11

piece handle=/DataDomain/****/****_72057_754923606_1.dbf tag=TAG20110627T130004 comment=NONE

..............

channel dev_0: backup set complete, elapsed time: 00:00:35

Finished backup at 27-JUN-11



Starting Control File and SPFILE Autobackup at 27-JUN-11

piece handle=/DataDomain/*****/c-1531569699-20110627-02 comment=NONE

Finished Control File and SPFILE Autobackup at 27-JUN-11



sql statement: alter system archive log current



Starting backup at 27-JUN-11

current log archived

channel dev_0: starting archive log backupset

channel dev_0: specifying archive log(s) in backup set

input archive log thread=1 sequence=69375 recid=61597 stamp=754894912

channel dev_0: starting piece 1 at 27-JUN-11

channel dev_1: starting archive log backupset

channel dev_1: specifying archive log(s) in backup set

input archive log thread=1 sequence=69379 recid=61601 stamp=754894938

channel dev_1: starting piece 1 at 27-JUN-11

channel dev_0: finished piece 1 at 27-JUN-11

piece handle=/DataDomain/*****/*****ARCH_72071_754925704_1.arch tag=TAG20110627T133503 comment=NONE

channel dev_0: backup set complete, elapsed time: 00:00:04

channel dev_0: deleting archive log(s)

..............

Starting Control File and SPFILE Autobackup at 27-JUN-11

piece handle=/DataDomain/******/c-1531569699-20110627-03 comment=NONE

Finished Control File and SPFILE Autobackup at 27-JUN-11

released channel: dev_0

released channel: dev_1

Con questo script mi assicuro che tutto il DB e gli archive log relativi vengano inclusi nel backupset.
Controllando i vari parametri di configuazione di RMAN mi soffermo per due in  particolare;

CONFIGURE RETENTION POLICY TO REDUNDANCY 1;

CONFIGURE BACKUP OPTIMIZATION ON;

Per RETENTION POLICY TO REDUNDANCY 1 specifico che voglio tenere esclusivamente l'ultimo backup effettuato,visto che nell'arco della giornata ne eseguo 3, questo è per una strategia legata allo disk space utilizzatodal backup.
Per BACKUP OPTIMIZATION ON il comando BACKUP salta il backup di alcuni datafiles per esempio quando vede che è già stato eseguito il backup,attraverso questi 3 controlli:
1) RMAN datafiles confronta DBID, SCN checkpoint, SCN creazione e SCN RESETLOGS, quindi se sono identici salta l'esecuzione.
2) Archived redo log RMAN verifica il thread, il sequence number, RESETLOGS SCN e datetime.
3) Per i backupset RMAN verifica recid e stamp.

Andando avanti con lo script di RMAN per il backup troviamo questi 2 comandi,crosscheck e delete noprompt obsolete.
Il crosscheck esegue una verifica tra i backupset presenti nel recovery catalog e quelli presenti fisicamente su disco, se non trova corrispondenza vengono segnati cosa "EXPIRED" all'interno del catalog, se trova invece corrispondenza ma non viene soddisfatta la retention policy vengono segnati come "OBSOLETE".

Con il delete noprompt cancello quelli "OBSOLETE" da disco, quelli che non corrispondono alla retention policy, inoltre rimuove quelli in stato "EXPIRED" dal catalog e quelli che ci sono ancora nel catalog ma che non si trovano fisicamente nel disco.
Con questo comando eseguo una sorta di pulizia del catalog tenendo solo quelli in stato "AVAILABLE".
Nell'esecuzione dello script possiamo trovare:

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=142 devtype=DISK

crosschecked backup piece: found to be 'AVAILABLE'

backup piece handle=/DataDomain/****/*_71674_754891210_1.dbf recid=71617 stamp=754891210

crosschecked backup piece: found to be 'AVAILABLE'

backup piece handle=/DataDomain/****/*_71673_754891209_1.dbf recid=71618 stamp=754891210

crosschecked backup piece: found to be 'AVAILABLE'

backup piece handle=/DataDomain/****/*__71676_754891742_1.dbf recid=71619 stamp=754891743

.............

RMAN retention policy will be applied to the command

RMAN retention policy is set to redundancy 1

using channel ORA_DISK_1

Deleting the following obsolete backups and copies:

Type                 Key    Completion Time    Filename/Handle

-------------------- ------ ------------------ --------------------

Backup Set           425324 27-JUN-11       

Backup Piece       425339 27-JUN-11    /DataDomain/****/*_71674_754891210_1.dbf

Backup Set           425325 27-JUN-11       

Backup Piece       425340 27-JUN-11    /DataDomain/******/*_71673_754891209_1.dbf

Backup Set           425326 27-JUN-11       

Backup Piece       425341 27-JUN-11    /DataDomain/*****/*_71676_754891742_1.dbf

Backup Set           425327 27-JUN-11       

Backup Piece       425342 27-JUN-11    /DataDomain/*****/*_71675_754891735_1.dbf

.........

backup piece handle=/DataDomain/******/*ARCH_72126_754925794_1.arch recid=72057 stamp=754925794

deleted backup piece

backup piece handle=/DataDomain/******/*ARCH_72127_754925797_1.arch recid=72058 stamp=754925797

deleted backup piece

backup piece handle=/DataDomain/******/*ARCH_72128_754925797_1.arch recid=72059 stamp=754925797

deleted backup piece

backup piece handle=/DataDomain/******/*ARCH_72129_754925800_1.arch recid=72060 stamp=754925800

deleted backup piece

backup piece handle=/DataDomain/******/*ARCH_72130_754925800_1.arch recid=72061 stamp=754925800

deleted backup piece

.....

Deleted 86 objects



Recovery Manager complete.

Nella seconda parte tratterò altre operazioni sempre con RMAN come, la reportistica e come validare un backup.

WARNING: inbound connection timed out (ORA-3136)

Nel log file di alert del DB Oracle è possibile trovare questa segnalazione:

WARNING: inbound connection timed out (ORA-3136)

Significa che un tentativo di connessione è stato fatto, ma la sessione di autenticazione non è stata fornita prima del parametro impostato in SQLNET.INBOUND_CONNECT_TIMEOUT.
Questo parametro si trova nel file sqlnet.ora in $ORACLE_HOME/network/admin/ ed è impostato a 60 secondi.

La segnalazione può essere trascurata se si verifica sporadicamente ma se dovesse essere una costante quotidiana l'Oracle doc prevede 2 action per questa anomalia:

1) Check SQL*NET and RDBMS log for trace of suspicious connections.
2) Configure SQL*NET with a proper inbound connect timeout value if necessary.

Bisogna quindi analizzare bene la situazione soprattutto se si sospetta qualche connessione strana come al punto 1 prima ovviamente di apporre qualsiasi modifica.
Tuttavia si può procedere a impostare il parametro SQLNET.INBOUND_CONNECT_TIMEOUT con un valore appropriato nel file $ORACLE_HOME/network/admin/sqlnet.ora come richiesto nel punto 2.

Ma se non il file non ci fosse nel percorso indicato e ci fosse solo il tnsnames.ora?
Il listener in questo caso ci darebbe un grosso aiuto con:

$ lsnrctl



LSNRCTL for Solaris: Version 10.2.0.5.0 - Production xxxxxxxxxxxxxxx



Copyright (c) 1991, 2010, Oracle.  All rights reserved.



Welcome to LSNRCTL, type "help" for information.



LSNRCTL> set help

The following operations are available after set

An asterisk (*) denotes a modifier or extended command:



password                    rawmode                   

displaymode                 trc_file                   

trc_directory               trc_level                 

log_file                    log_directory             

log_status                  current_listener           

inbound_connect_timeout     startup_waittime           

save_config_on_stop         dynamic_registration 



LSNRCTL>set inbound_connect_timeout 3 (per esempio)

Impostando per noi il nuovo parametro.....

Senza questo parametro, una connessione client/server può rimanere aperta all'infinito senza autenticazione. Le connessioni senza autenticazione possono introdurre possibili attacchi di tipo denial-of-service, per cui dei client malintenzionati possono tentare di tempestare il server DB con richieste di connessioni che ovviamente consumano risorse.

Ci sono 2 link molto utili tratti dai documenti Oracle che spiegano molto bene i vari scenari, anche perchè per una protezione totale è posibile anche impostare un secondo parametro INBOUND_CONNECT_TIMEOUT_listener_name nel file listener.ora.

Bisogna fare attenzione perchè il parametro  SQLNET.INBOUND_CONNECT_TIMEOUT non richiede riavvio del DB visto che viene letto quando una connessione viene richiesta mentre il INBOUND_CONNECT_TIMEOUT_listener_name viene letto quando viene avviato il servizio listener quindi per poter attivare il parametro con i nuovi settaggi bisogna riavviarlo.

I settaggi dei parametri di networking di Oracle sono fondamentali per costruire delle connessioni client/server affidabili e performanti, tuttavia certe volte questi  vengono sottovalutati creando non pochi problemi.

Di seguito i links della documentazione Oracle e un doc id di Metalink (per chi ha accesso):

http://download.oracle.com/docs/cd/B19306_01/network.102/b14213/listener.htm#sthref833
http://download.oracle.com/docs/cd/B19306_01/network.102/b14213/sqlnet.htm#sthref481

Metalink doc Id #465043.1