Alberto Blog

My repository ASH (S-ASH)

2012-02-17T08:15:00.000-08:00

Un altro breve update per segnalare la creazione di un mio repository per il progetto S-ASH.
Dopo aver fatto il fork del progetto di Marcin ho implementato 2 nuove utili fetatures.

1) creazione di una funzione di Top 10.
Dove attraverso un job schedulato ogni 10 min, è possibile visionare nel proprio repository attraverso una tabella tutti gli sql_id utilizzati maggiormente per wait_class:User I/O, System I/O, Administrative, other, Configuration, Application, Concurrency e Network.

2) creazione di OBJ_PLUS.
Attraverso questa visualizzazione è possibile avere una situazione globale per tutte le tabella e indici relativi, come: leaf_block, distinct_keys, blocks e clusering factor.
E' possibile avere una panoramica globale di tutti gli oggetti (tabelle e indici) visto che è stato introdotto il campo clustering dove viene mostrato il grado di fattorizzazione dei dati di una tabella in relazione al proprio indice.
Questo è utile per capire con il CBO di Oracle lavora e come sceglie i piani di esecuzione sempre disponibili in S-ASH.

Vi consiglio di provarlo e di dare il vostro contributo perchè veramente è un tool molto potente, utile e in più è in continua evoluzione.

Repository S-ASH: https://github.com/AlbertoFro/orasash

ASH (S-ASH) Update

2012-01-25T02:51:00.000-08:00

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)

2011-12-28T06:40:00.000-08:00

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

2011-11-30T03:33:00.000-08:00

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

2011-10-11T01:46:00.000-07:00

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  else 
 echo " \n$(date) Space /arch_oracle is $ARCH.">> $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.

Clustering Factor

2011-10-04T06:47:00.000-07:00

Il clustering factor è la misura di come sono allineati i dati di una tabella in relazione al proprio indice. Inolte ci fornisce l’indicazione della quantità di I/O per leggere la tabella attraverso un full table scan.
Un valore di clustering factor vicino ai numeri di blocchi della tabella ci indica che i dati sono stati ordinati e scritti nei blocchi in modo ottimale in relazione all’indice.
Tuttavia nei casi dove il clustering factor si allontana notevolmente dai blocchi della tabella si avvicina al totale delle righe della tabella questo significa che Oracle ha bisogno di andarsi a leggere lo stesso blocco molte volte per ottenere un valore.
In questo ultimo caso l’indice perderà la sua efficenza incrementando il costo dello stesso per il suo utilizzo, rendendolo meno appetibile al CBO.
Il valore del clustering factor non subisce variazione durante la rebuid dell’indice visto che durante questa operazione non è possibile cambiare l’ordine dei dati.
Tuttavia esiste un’operazione di rebuild con clausola NOREVERSE/REVERSE che ne cambia l’ordine quindi in questo caso il valore del clustering factor viene modificato.
Adesso facciamo un esempio analizzo una tabella per verificare sia i blocchi sia il clustering factor (CF).

EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>'ABE',TABNAME=>'ABC',CASCADE=>TRUE,ESTIMATE_PERCENT=>NULL);


select blocks from user_tables where table_name='ABC';
BLOCKS                 

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

11123    



select clustering_factor from user_indexes where index_name='ABC_1';

CLUSTERING_FACTOR      

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

121360

Dove abbiamo un indice su questa tabella ABC_1 per i campi A,B,C.

Come si può notare questo è un pessimo esempio di CF essendo il valore molto lontano dai blocchi.

Rifacciamo lo stesso esempio creando la stessa tabella ma avendo un occhio di riguardo all’indice.

create table ABC_TEST as select * from ABC  order by A, B, C;

CREATE UNIQUE INDEX ABC_TEST_1 ON ABC_TEST( "A", "B", "C"  );

Ricalcoliamo le statistiche.

EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>'ABE',TABNAME=>'ABC_TEST',CASCADE>TRUE,ESTIMATE_PERCENT=>NULL); 

select blocks from user_tables where table_name='ABC_TEST';

BLOCKS                 
---------------------- 
11189 

select clustering_factor from user_indexes where index_name='ABC_TEST_1';

CLUSTERING_FACTOR      
---------------------- 
11074

In questo caso abbiamo un buon CF essendo molto vicino ai blocchi, il CBO attribuirà un costo basso all’utilizzo di questo indice in modo table da essere molto appetibile al CBO e quindi al suo utilizzo.

Nella maggior parti dei casi però non è così facile l’ottimizzazione del CF soprattutto se ci troviamo di fronte a sistemi di produzione con grandi mole di dati, e soprattutto con più indici per la stessa tabella, perchè l’aggiunta di un altro indice ci troveremo di fronte ad una situazione del genere:

CREATE UNIQUE ABC_TEST_2 ON ABC_TEST ( "D", "E", "F"  );

EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>'ABE',TABNAME=>'ABC_TEST',CASCADE=>TRUE,ESTIMATE_PERCENT=>NULL);

select blocks from user_tables where table_name='ABC_TEST';

BLOCKS                 
---------------------- 
11189 

select clustering_factor from user_indexes where index_name='ABC_TEST_2';

CLUSTERING_FACTOR      
---------------------- 
139274

Arghhhh...siamo ritornati con un CF molto alto per l'indice appena creato, la complessità della problematica sta nella maggior parte dei sistemi ERP dove esistono moltissime tabelle, con numerose colonne e di conseguenza indici, quindi ci sono molte variabili da aggiungere.
Anche se in questo esempio provassimo ad eseguire un rebuild con option NOREVERSE/REVERSE non avremo i miglioramenti desiderati:

alter index ABC_TEST_2 rebuild reverse;


EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>'ABE',TABNAME=>'ABC_TEST',CASCADE=>TRUE,ESTIMATE_PERCENT=>NULL);

select clustering_factor from user_indexes where index_name='ABC_TEST_2';


CLUSTERING_FACTOR      
---------------------- 
139274

Normalmente le righe che crescono ad ogni inserimento in modo monotòno sono inserite nell’ordine della colonna di inserimento se si parla di tablespace MSSM, il discorso cambia invece per le tabelle su tablespace in ASSM dove per freelist o gruppi di freelist multipli, le insert vengono eseguite in modo concorrente per transazione , potrebbero essere dirottate in blocchi differenti.
In questi casi anche se i dati sono ben scritti nei blocchi potrebbero avere un CF non ottimale per il modo in cui viene calcolato dal CBO.

Conclusioni:

Il Fattore di clustering di un indice viene ottimizzato quando i dati vengono inseriti per l'ordine del proprio indice.
Altri importanti fattori che vanno ad influire il clustering factor sono:

l'ordine delle colonne nell'indice
Reverse Indexes
Freelist e/o Freelist Group
ASSM

Alberto

TNS-12516: TNS:listener could not find available handler with matching protocol stack

2011-09-13T05:39:00.000-07:00

Visionando il file trace.log per una istanza ho incontrato questo errore: TNS-12516: TNS:listener could not find available handler with matching protocol stack.
Facendo una ricerca su Metalink esiste una nota 240710.1 che spiega la problematica.

Applies to:
Oracle Net Services - Version: 9.2.0.1.0 to 11.2.0.2 - Release: 9.2 to 11.2
Information in this document applies to any platform.
Checked for relevance on 15-FEB-2007.
------------------------------------------------------------------------------

Symptoms
Client connections may fail intermittently with any of the following errors:

TNS-12516 TNS: listener could not find instance with matching protocol stack
ORA-12516 TNS: listener could not find instance with matching protocol stack

TNS-12519 TNS: no appropriate service handler found
ORA-12519 TNS: no appropriate service handler found

Any or all of these errors might appear in the listener.log and may accompany an ORA-12520:

ORA-12520 TNS:listener could not find available handler for requested type of server

The output of the lsnrctl services command may show that the service handler
is in a "blocked" state.

e.g. '"DEDICATED" established:1 refused:0 state:blocked'

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

Changes

It is likely a significant increase in load has occurred.

Cause
By way of instance registration, PMON is responsible for updating the listener
with information about a particular instance such as load and dispatcher
information. Maximum load for dedicated connections is determined by the
PROCESSES parameter. The frequency at which PMON provides SERVICE_UPDATE
information varies according to the workload of the instance. The maximum
interval between these service updates is 10 minutes.

The listener counts the number of connections it has established to the instance
but does not immediately get information about connections that have terminated.
Only when PMON updates the listener via SERVICE_UPDATE is the listener
informed of current load. Since this can take as long as 10 minutes, there can be
a difference between the current instance load according to the listener
and the actual instance load.

When the listener believes the current number of connections has reached maximum
load, it may set the state of the service handler for an instance to "blocked"
and begin refusing incoming client connections with either of the following
errors:

TNS-12516 TNS:listener could not find instance with matching protocol stack
TNS-12519 TNS:no appropriate service handler found

Additionally, an ORA-12520 error may appear in the listener log.

The output of the LSNRCTL services command will likely show that the service handler is "blocked".

e.g. '"DEDICATED" established:1 refused:0 state:blocked'
Increase the pfile or spfile setting for PROCESSES.

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

Solution:
Increase the pfile or spfile setting for PROCESSES.
------------------------------------------------------------------------------

Infatti eseguendo lo statement per vedere i parametri iniziali dell'istanza compare :

select name, value from v$parameter where name in ('processes', 'sessions');

NAME VALUE
---------------------------------
processes 300
sessions 335

Verificando il conto totale dei processi nel DB quando questa segnalazione compare nel trace.log con:

select count(*) from v$process;

COUNT(*)
-----------
297

In effetti il sistema sta si avvicinando pericolosamente al limite previsto, quindi occorre aumentare il valore dei process quindi:

SQL> Alter system set processes = 350 scope=spfile;
SQL> shutdown immediate
SQL> startup open

Ovviamente l'istanza deve essere riavviata.

TUNING session_cached_cursor with PL/SQL procedure

2011-07-20T02:08:00.000-07:00

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.
La procedura è la seguente:

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;
<<lp>>
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;

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:

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

2011-07-18T06:37:00.000-07:00

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

2011-07-08T08:19:00.000-07:00

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

2011-07-08T02:23:00.000-07:00

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:

direct path IO to perform worse in 10.2.0.5 than earlier releases with more "direct path read" operations or
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

2011-06-28T02:35:00.000-07:00

Una volta conclusi i backup è possibile verificare nel catalog se quest'ultimi sono effettivamente presenti e il loro stato. Collegandosi al catalog si può lanciare:
LIST BACKUP RECOVERABLE;

List of Backup Sets
===================

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
258096 Full 8.44G DISK 00:04:33 27-JUN-11
BP Key: 258107 Status: AVAILABLE Compressed: NO Tag: TAG20110627T160014
Piece Name: \\xxx.yyy.zzz.100\BACKUP\RMAN\****\******20110627
List of Datafiles in backup set 258096
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
16 Full 7250999543 27-JUN-11 E:\*****\*****\*****\*****LARGE_3.DBF
22 Full 7250999543 27-JUN-11 E:\*****\*****\*****\*****LARGE_9.DBF
28 Full 7250999543 27-JUN-11 E:\*****\*****\*****\*****_15.DBF
34 Full 7250999543 27-JUN-11 E:\*****\*****\*****\*****_21.DBF
38 Full 7250999543 27-JUN-11 E:\*****\*****\*****\*****_LARGE_25.DBF
.............................

Ovviamente nel mio caso mi farà vedere solo l'ultimo backup eseguito come ho specificato nella retention policy. Tuttavia ogni sera mi faccio mandare un messaggio di posta per ogni DB con la situazione nel catalog per le varie istanze, se si tratta di ambienti Windows utilizzo blat con questo script:

rman target abc/abc@***T rcvcat qqqq/vvvv@*****DB log c:\rman_abc.log @c:\rmanset.rman
blat c:\rman_abc.log -to alberto.frosi -subject "RMAN Report DB"

se sono server Solaris utilizzo il classico mailx:
su - oracle -c "rman target / rcvcat 123/123@*****DB \
cmdfile=/oracle/app/oracle/product/bckonline.rcv > /DataDomain/*****/*******.log"
mailx -s "RMAN Report DB - `uname -n` " alberto.frosi@xxxxx.com < /DataDomain/*****/*******.log

Ho creato inoltre,seguendo un post di Arup Nanda, dei report che mi consentono in qualsiasi momento di verificare tutti i backup nel catalog lanciando un semplice script che mi restituisce questo output:

DB Name Start Time End Time Status Time Tak Output Size Type BackupType
-------- ------------------ ------------------ -------- -------- -------- -------- ----------
ABC 21-06-2011 16:00 21-06-2011 16:35 COMPLETE 00:34:54 54.57G DISK DB FULL
ABC 21-06-2011 17:00 21-06-2011 17:00 COMPLETE 00:00:23 117.12M DISK ARCHIVELOG
ABC 21-06-2011 21:00 21-06-2011 21:01 COMPLETE 00:01:02 753.00M DISK ARCHIVELOG
ABC 22-06-2011 01:00 22-06-2011 01:02 COMPLETE 00:01:33 735.54M DISK ARCHIVELOG
...........
ABC 27-06-2011 13:00 27-06-2011 13:01 COMPLETE 00:01:28 1009.84M DISK ARCHIVELOG
ABC 27-06-2011 16:00 27-06-2011 16:34 COMPLETE 00:34:37 54.64G DISK DB FULL
ABC 27-06-2011 16:58 27-06-2011 17:14 FAILED 00:15:53 0.00K DB FULL
. Operation Input Status
. -------------------- -------------------- --------------------
. . DB FULL FAILED
. Level Status Operation Object Type
. ------ -------- -------------------- --------------------
. > COMPLETE RMAN .
. -> COMPLETE BACKUP VALIDATE DB FULL
. -> FAILED BACKUP VALIDATE DB FULL
ABC 27-06-2011 17:00 27-06-2011 17:00 COMPLETE 00:00:31 112.46M DISK ARCHIVELOG
ABC 27-06-2011 21:00 27-06-2011 21:01 COMPLETE 00:00:49 686.41M DISK ARCHIVELOG
ABC 28-06-2011 01:00 28-06-2011 01:01 COMPLETE 00:01:41 662.65M DISK ARCHIVELOG
ABC 28-06-2011 04:00 28-06-2011 05:05 COMPLETE 01:05:38 53.88G DISK DB FULL
ABC 28-06-2011 05:00 28-06-2011 05:01 COMPLETE 00:01:14 721.03M DISK ARCHIVELOG
ABC 28-06-2011 09:00 28-06-2011 09:01 COMPLETE 00:01:04 646.32M DISK ARCHIVELOG
XYZ 21-06-2011 13:00 21-06-2011 13:36 COMPLETE 00:36:02 152.66G DISK DB INCR
XYZ 21-06-2011 19:00 21-06-2011 19:38 COMPLETE 00:38:00 150.91G DISK DB INCR
XYZ 22-06-2011 04:00 22-06-2011 04:44 COMPLETE 00:44:06 156.19G DISK DB INCR
........
XYZ 27-06-2011 19:00 27-06-2011 19:39 COMPLETE 00:39:23 150.91G DISK DB INCR
XYZ 28-06-2011 04:00 28-06-2011 04:43 COMPLETE 00:43:41 156.94G DISK DB INCR

In questo output è possibile avere la situazione completa di tutto il catalog.

Prima di effettuare i backup per essere sicuri, si può eseguire un check sulla consistenza per verificare se il db è corrotto a livello fisico e/o logico e per confermare che tutti i datafiles esistono e sono nelle posizioni corrette.

RMAN con questo comando non produce ulteriori set di backup, ma legge piuttosto i file specificati nella loro interezza, per determinare se possono essere sottoposti a backup e non sono danneggiati.
Se la convalida di backup scopre blocchi corrotti, aggiorna RMAN la vista V_$DATABASE_BLOCK_CORRUPTION con le righe che descrivono la corruzione.

BACKUP VALIDATE
DATABASE
ARCHIVELOG ALL;

e/o

BACKUP VALIDATE
CHECK LOGICAL
DATABASE
ARCHIVELOG ALL;

Starting backup at 27-JUN-11
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00046 name=/XXXX/aaaaaa1.dbf
input datafile fno=00035 name=/XXXX/aaaaaa2.dbf
input datafile fno=00036 name=/XXXX/aaaaaa3.dbf
input datafile fno=00029 name=/XXXX/aaaaaa4.dbf
......

E' possibile inoltre verificare se un backupset eseguito con RMAN sia andato a buon fine ed
è possibile quindi eseguirne il ripristino:

RMAN> LIST BACKUP SUMMARY;

List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
428019 B 0 A DISK 28-JUN-11 1 1 NO TAG20110628T040007
428020 B 0 A DISK 28-JUN-11 1 1 NO TAG20110628T040007
428021 B 0 A DISK 28-JUN-11 1 1 NO TAG20110628T040007
428022 B 0 A DISK 28-JUN-11 1 1 NO TAG20110628T040007
428023 B 0 A DISK 28-JUN-11 1 1 NO TAG20110628T040007

RMAN> VALIDATE BACKUPSET 428022,428023;

allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=183 devtype=DISK
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece /DataDomain/*****/******_72194_754978164_1.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/DataDomain/*****/*****_72194_754978164_1.dbf tag=TAG20110628T040007
channel ORA_DISK_1: validation complete, elapsed time: 00:04:37
channel ORA_DISK_1: starting validation of datafile backupset
channel ORA_DISK_1: reading from backup piece /DataDomain/******/********_72196_754978766_1.dbf
channel ORA_DISK_1: restored backup piece 1
piece handle=/DataDomain/*****/*****_72196_754978766_1.dbf tag=TAG20110628T040007
channel ORA_DISK_1: validation complete, elapsed time: 00:04:07

Un'altra idea è quella di adottare una politica di Long-Term Backup ossia di tenere almeno un backup consistente mensile. Questo andrebbe contro la mia retention policy ma c'è un workaround.
E' possibile eseguire questo, specificando l'opzione KEEP nel comando BACKUP. Sì puo inoltre specificare di eseguire il backup anche con l'opzione LOGS oppure NOLOGS.
Nel mio caso essendo un backup mensile ma soprattutto consistente sceglierò NOLOGS.

RMAN> SHUTDOWN IMMEDIATE;
RMAN> STARTUP MOUNT;
RMAN> BACKUP DATABASE KEEP FOREVER NOLOGS
TAG 'Backup Mensile';

Una volta eseguito cambio il TAG per farlo "uscire" dalla retention policy e farlo diventare permanente.

RMAN> CHANGE BACKUP TAG 'Backup Mensile' UNAVAILABLE;
RMAN> SQL 'ALTER DATABASE OPEN';

A questo punto nmi sembra di avere eseguito una panoramica completa di tutte o quasi le
funzionalità di RMAN più usate.

RMAN Backup Strategies - Part 1

2011-06-27T06:56:00.000-07:00

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.

TUNE SESSION_CACHED_CURSORS UPDATE

2011-06-08T07:06:00.000-07:00

Visto l'interesse per l'impostazione e il tuning di questo parametro,
ho fatto delle ulteriori ricerche.
Mi sono messo in contatto con David Fitzjarrell per chiedere un approfondimento dell'argomento,
così mi ha fornito un statement SQL per aiutare a gestire questo parametro e il
parametro open_cursor.

--
-- sess_cached_cursors.sql
--
-- Retrieve current cursor settings, current cursor allocation and
-- compute percent usage
--
-- Calculate adjusted values where necessary
--
--
-- ddf
--

set linesize 132
column parameter format a30

select parameter, value, usage||'%',
case when to_number(usage) >= 100 then (to_number(usage)+10)*value/100 else to_number(value) end new_setting
from
(select
parameter,
lpad(value, 5) value,
case when value=0 then '0' else to_char(100 * used / value, '990') end usage
from
( select
max(s.value) used
from
sys.v_$statname n,
sys.v_$sesstat s
where
n.name = 'session cursor cache count' and
s.statistic# = n.statistic#
),
( select
name parameter, value
from
sys.v_$parameter
where
name = 'session_cached_cursors'
)
union all
select
parameter,
lpad(value, 5) value,
to_char(100 * used / value, '990') usage
from
( select
max(sum(s.value)) used
from
sys.v_$statname n,
sys.v_$sesstat s
where
n.name in ('opened cursors current', 'session cursor cache count') and
s.statistic# = n.statistic#
group by
s.sid
),
( select
name parameter, value
from
sys.v_$parameter
where
name = 'open_cursors'
)
)
/
Parameter value usage% NEW_SETTING
session_cached_cursors 20 100% 22
open_cursors 900 16% 900

Questo è l'ouput dello script che ottengo in una istanza, si può facilmente
vedere che il parametro open_cursor è stato sopravvalutato, perchè solo il
16% ossia 144 cursori sono aperti, l'altro 84% rimane inutilizzato consumando però risorse.
Il session_cached_cursors è utilizzato al 100% quindi si dovrebbe aumentare
questo valore. Il campo new_setting viene valorizzato solo se il value dei
parametri è maggiore o uguale a 100.
In questo caso per esempio, si potrebbe pensare di diminuire open_cursors e di
aumentare session_cached_cursors per un migliore bilanciamento delle risorse.
Viene calcolato nel campo new_setting il nuovo valore che è praticamente il 10%.
Il 10% è stato messo come test, si potrebbe modificare lo script facendo aggiungere
anche il 50%, però per un tuning più equilibrato si deve procedere a piccoli passi,
finchè l'utilizzo non è uguale o inferiore al 100%.
Tutti i commenti sono benvenuti.

SESSION_CACHED_CURSORS

2011-05-31T01:04:00.000-07:00

Dopo aver raccolto i miei appunti sparsi in un pò di documenti vorrei riuscire a scrivere
un articolo sulla parametro di SESSION_CACHED_CURSORS.

Quando una applicazione chiude un cursore, Oracle imposta lo stato di questo cursore come "closeable". Tuttavia questo non sarà effettivamente chiuso finchè Oracle non avrà
bisogno di spazio per aprirne un altro.
Quindi sebbene un applicazione chiuda tutti i propri cursori bene, (fatto alquanto raro, dipende dallo sviluppatore) quest'ultimi rimarranno aperti consumando risorse.

Come punto di partenza per potere eseguire un'analisi eseguiamo uno Statepack del sistema, ci focalizziamo sul Execute to Parse %.
Se il numero di parse calls si avvicina al numero di execute calls, allora questa percentuale si avvicinerà allo 0.Se il numero di execute calls aumenterà, la percentuale tenderà ad avvicinarsi al 100, il che significa che uno statement SQL il DB lo carica una volta sola (parse) e l'esegue molte volte (executes), ossia la situazione ottimale.

Dobbiamo prendere questa percentuale come un indicatore, nel mio caso per esempio ho un Execute to Parse di 54,87 calcolato con la seguente formula:
100*(executions - parses) / executions ossia 100 * (371,14 - 167,48) / 371,14.

Vediamo come sono impostati alcuni parametri nel DB:

open_cursors=900
cursor_sharing=Exact
session_cached_cursors=20

Adesso lanciamo

select a.value, s.username, s.sid, s.serial#
from v$sesstat a, v$statname b, v$session s
where a.statistic# = b.statistic# and s.sid=a.sid
and b.name = 'opened cursors current'
order by a.value desc;

VALUE USERNAME SID SERIAL#
---------------------- ------------------------------ ---------------------- ----------------------
92 XXXXXX 189 47764
90 AAAAAA 243 4188
82 BBBBBBBBB 196 35102
82 CCCCCCCCC 142 41252
81 DDDDDDDDD 257 29099
80 EEEEEEEEE 227 2522
......

possiamo notare che il SID 189 ha 92 open_cursor, quindi ben sotto al 900 impostato.

Adesso verifichiamo se il parametro SESSION_CACHED_CURSORS potrà aiutarci.

select cach.value cache_hits, prs.value all_parses,
prs.value-cach.value sess_cur_cache_not_used
from v$sesstat cach, v$sesstat prs, v$statname nm1, v$statname nm2
where cach.statistic# = nm1.statistic#
and nm1.name = 'session cursor cache hits'
and prs.statistic#=nm2.statistic#
and nm2.name= 'parse count (total)'
and cach.sid= &sid and prs.sid= cach.sid ;

SID=189

CACHE_HITS ALL_PARSES SESS_CUR_CACHE_NOT_USED
---------------------- ---------------------- -----------------------
5460 5680 220

Il valore "session cursor cache hits" è il numero di volte che uno statemet SQL viene trovato in session cursor cache, quindi non ha bisogno di essere reparsed, adesso se raffrontiamo i valori "parse count (total)" meno "session cursor cache hits" otteniamo "parse count (total)" vedremo il numero di parse di cui abbiamo bisogno.

Procediamo con

select a.value curr_cached, p.value max_cached, s.username, s.sid, s.serial#
from v$sesstat a, v$statname b, v$session s, v$parameter2 p
where a.statistic# = b.statistic# and s.sid=a.sid and a.sid=&sid
and p.name='session_cached_cursors'
and b.name = 'session cursor cache count' ;

SID=189

CURR_CACHE MAX_CACHED USERNAME    SID SERIAL#
--------------   -------------- -------------- ------      --------------
20 20   XXX   189 47764

Se session cursor cache count ha raggiunto il valore massimo e session_cursor_cache_hits è più basso comparato con all parses, potrebbe nascere il sospetto che l'applicazione in questo caso riesegue gli stessi SQL in modo ripetitivo, potremo quindi scegliere di aumentare SESSION_CURSOR_CACHE per aiutarci con latch contention.
Tuttavia se l'applicazione non riesegue gli stessi SQL, quindi session_cursor_cache_hits sarà più basso dei parses e il session cursor cache raggiunge il valore massimo, anche aumentando il tale valore non si otterranno i risultati sperati, questo significa che l'applicazione utilizzerà SQL non condivisi.

Ovviamente questo è un esempio della sessione con il sid 189.

In questo caso si potrebbe inizialmente impostare il valore session_cached_cursors a 100 per poter arrivare ad un buon compromesso.
Questo articolo ha lo scopo di analizzare e di gestire al meglio il parametro SESSION_CURSOR_CACHE tutti i commenti sono benvenuti.

WARNING: inbound connection timed out (ORA-3136)

2011-05-03T05:29:00.000-07:00

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

Failed to shutdown DBConsole Gracefully

2011-04-29T08:51:00.000-07:00

Oggi tratterò un argomento importante che riguarda Enterprise Manager Console nella versione 10G.
Stamattina dopo un riavvio del server di produzione non riuscivo più ad entrare nella console di EM.
Mi sono collegato al server e ho digitato:

$ emctl stop dbconsole
Oracle Enterprise Manager 10g Database Control Release 10.2.0.5.0
Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved.
https://jdesun:1158/em/console/aboutApplication
Stopping Oracle Enterprise Manager 10g Database Control ...
--- Failed to shutdown DBConsole Gracefully ---

Subito sono rimasto un pò stupito, sono andato a vedermi il log nel file emagent.trc nel path /oracle/app/oracle/product/10.2.0/..../sysman/log:

2011-04-29 14:23:30 Thread-1049 ERROR pingManager: nmepm_pingReposURL: Cannot connect to https://jdesun:1158/em/upload/: retStatus=-1
2011-04-29 14:23:30 Thread-1049 ERROR ssl: nzos_Handshake failed, ret=29024
2011-04-29 14:23:30 Thread-1049 ERROR http: 257: Unable to initialize ssl connection with server, aborting connection attempt
2011-04-29 14:23:30 Thread-1049 ERROR pingManager: nmepm_pingReposURL: Cannot connect to https://jdesun:1158/em/upload/: retStatus=-1

Ho notato in questa sezione la segnalazione Thread-1049 ERROR http: 257: Unable to initialize ssl connection with server, aborting connection attempt

Si tratta di un errore http riguardante la connessione SSL con il server.

Con il comando ps -fe | grep oracle|more ho verificato se c'era qualcosa rimasto in "hang" che potesse bloccare tutte le nuove connessioni per poter gestire EM console.

oracle 24044 56 0 14:31:07 pts/1 0:05 /oracle/app/oracle/product/10.2.0/jdk/bin/java -server -Xmx256M -XX:MaxPermSize
oracle 24761 24382 0 14:35:54 pts/1 0:01 /oracle/app/oracle/product/10.2.0/bin/emagent

in effetti ho trovato due processi interessanti e che potrebbero essere i responsabili di questo errore.

Con il comando kill li ho terminati.

Ho riprovato quindi a rilanciare:

$ emctl stop dbconsole
Oracle Enterprise Manager 10g Database Control Release 10.2.0.5.0
Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved.
https://jdesun:1158/em/console/aboutApplication
Stopping Oracle Enterprise Manager 10g Database Control ...
... Stopped.

e questa volta senza problemi ;-)

Vedendo che si trattava di un errore SSL ho deciso di rigenerare un nuovo certificato di connessione per il server con l'apposito comando:

$emctl secure dbconsole
Oracle Enterprise Manager 10g Database Control Release 10.2.0.5.0
Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved.
https://jdesun:1158/em/console/aboutApplication
Enter Enterprise Manager Root password :
Enter a Hostname for this OMS : server_name

DBCONSOLE already stopped...   Done.
Agent is already stopped...   Done.
Securing dbconsole...   Started.
Checking Repository...   Done.
Checking Em Key...   Done.
Checking Repository for an existing Enterprise Manager Root Key...   Done.
Fetching Root Certificate from the Repository...   Done.
Updating HTTPS port in emoms.properties file...   Done.
Generating Java Keystore...   Done.
Securing OMS ...   Done.
Generating Oracle Wallet Password for Agent....   Done.
Generating wallet for Agent ...    Done.
Copying the wallet for agent use...    Done.
Storing agent key in repository...   Done.
Storing agent key for agent ...   Done.
Configuring Agent...
Configuring Agent for HTTPS in DBCONSOLE mode...   Done.
EMD_URL set in /oracle/app/oracle/product/10.2.0/...../sysman/config/emd.properties
  Done.
Configuring Key store..   Done.
Securing dbconsole...   Sucessful.

Il nuovo certificato è stato creato con successo allora perchè non provare subito.....

$ emctl start dbconsole
Oracle Enterprise Manager 10g Database Control Release 10.2.0.5.0
Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved.
https://jdesun:1158/em/console/aboutApplication
Starting Oracle Enterprise Manager 10g Database Control ........................... started.
------------------------------------------------------------------
Logs are generated in directory /oracle/app/oracle/product/10.2.0/...../sysman/log

Wow...adesso tutto è ripartito ;-)...

Dovrò aspettarmi fra un paio di mesi lo stesso errore ??

Probabilmente sì, ma per adesso tutto funziona....

:-)

Ubuntu Party

2011-04-19T02:11:00.000-07:00

Nelle giornate del 30 Aprile e 1 Maggio 2011 si svolgerà a Schio in provincia di Vicenza,l'Ubuntu Party.
Sono giornate dedicate alla presentazione e divulgazione del concetto di software libero, oltre che ovviamente dimostrazioni sulle potenzialità di Ubuntu, tra l'altro è il weekend sucessivo dopo il rilascio della nuova release Natty Narval, un motivo in più per non perdere l'evento.
Ci saranno numerosi talk, vi allego il
link per maggiori info ubuntu party
Un appuntamento da non perdere....

Oracle Statistics.....

2011-04-08T03:48:00.000-07:00

Oggi tratterò un argomento di particolare interesse in ambito DBA:raccolta delle statistiche di un DB.
La raccolta delle statistiche è un'operazione di vitale importantanza per tutto il database e serve per poter dare al CBO (Cost Based Optimizer)
tutte le informazioni per poter eseguire al meglio, ossia al costo più basso tutte le operazioni del DB.
Avere le statistiche sempre aggiornate è molto importante, tuttavia la frequenza di questa operazione è molto soggettiva, può essere una
volta alla settimana, una al mese oppure anche quotidianamente in relazione anche alla dimensione del database.

La procedura corretta imporrebbe di esportare le vecchie statistiche prima di prenderne delle nuove questo è molto
importante per prevenire possibili variazioni dei piani di esecuzioni degli statement SQL, in quanto il costo calcolato potrebbe subire delle modifiche e
quindi indurre al CBO per esempio di utilizzare un indice al posto di un altro e non solo, aumentando così il costo e la durata dello statement.

Caso tipico il giorno prima un batch, una query o un altro statement SQL, impiega magari 1 min e il giorno
successivo (dopo aver aggiornato le statistiche) 5 min, avendo le vecchie statistiche esportate è possibile ripristinarle

Tuttavia questa operazione va seriamente valutata.

Nel tempo ho cercato di rendere più facile la consultazione di questa operazione ossia ho cercato di rispondere principalmente a queste domande:
1) Quanto impiega a raccogliere le statistiche (magari anche per SCHEMA) ?
2) Come faccio a verificare il buon esito dell'operazione?
3) Posso creare un file di log oppure altro per tenere uno storico dell'operazione?

Ho creato così nel db un Package,una Procedure e una sequence che vanno a scrivere in un tabella del DB una serie di informazioni molto utili in modo tale che
anche un utente, non DBA con accessi ridotti, può andare a consultare i risultati, oltre a centralizzare per chi gestisce più di un DB questo genere
di informazioni

Cominciamo dal package con relativo body:

create or replace
PACKAGE "STATISTICS_LOG" as
procedure log( p_APP IN varchar2,
p_MSG IN varchar2,
p_CODE IN varchar2 := '',
p_MOD IN varchar2 := '',
p_SECTION IN varchar2 := '');
end;

create or replace
package body STATISTICS_LOG as
procedure log( p_APP IN varchar2,
p_MSG IN varchar2,
p_CODE IN varchar2 := '',
   p_MOD IN varchar2 := '',
p_SECTION IN varchar2 := '')
   is
PRAGMA AUTONOMOUS_TRANSACTION;

begin

insert into HSTATISTICS_TAB (
ID,
APP_KEY,
MOD_KEY,
SECTION_KEY,
MSG_CODE,
MSG_TEXT,
TIME_STAMP)
select
seq_stat_id.nextval,
p_APP,
p_MOD,
p_SECTION,
p_CODE,
p_MSG,
sysdate
from
dual;

commit;

exception
when others then
commit;
raise;
end log;

end;

e la sequence relativa:

CREATE SEQUENCE "SEQ_STAT_ID" MINVALUE 1 MAXVALUE 999999999999999999999999999 INCREMENT BY 1 START WITH 15859 CACHE 20 NOORDER NOCYCLE ;

Con questo package imposto delle variabili che richiamerò durante la procedura di raccolta statistiche per andare ad inserirle in un tabella HSTATISTICS_TAB che
creo così:

CREATE TABLE HSTATISTICS_TAB
  (
   "ID" NUMBER,
   "APP_KEY" VARCHAR2(255 BYTE) NOT NULL ENABLE,
   "MOD_KEY" VARCHAR2(255 BYTE),
   "SECTION_KEY" VARCHAR2(255 BYTE),
   "MSG_CODE" NUMBER,
   "MSG_TEXT" VARCHAR2(4000 BYTE) NOT NULL ENABLE,
   "TIME_STAMP" DATE NOT NULL ENABLE
  )

La sequence la utilizzo per generare un ID progressivo.

A questo punto non ci resta di scrivere la procedure che esegue la raccolta delle statistiche:

create or replace
procedure analyze_job is
v_owner varchar2(10);

begin

   select DISTINCT owner into v_owner from all_all_tables
   where owner='123'
   GROUP BY owner;

   dbms_stats.gather_schema_stats (ownname => '123',
   estimate_percent=>dbms_stats.auto_sample_size,
   method_opt => 'FOR ALL INDEXED COLUMNS SIZE 1',
   granularity => 'ALL',
   cascade => TRUE,
   degree => 7);

   STATISTICS_LOG.log(p_APP => 'Your app name',
   p_MOD => 'DBA',
   p_SECTION => 'ANALYZE',
   p_MSG => 'Analyzing tables/indexes '|| to_char(v_owner)||' ...');

   STATISTICS_LOG.log(p_APP => 'Your app name',
   p_MOD => 'DBA',
   p_SECTION => 'ANALYZE',
   p_MSG => 'End Daily Analyze: Successfully executed '|| to_char(v_owner)||'!');

exception
when others then

   STATISTICS_LOG.log( p_APP => 'Your app name',
   p_MOD => 'DBA',
   p_SECTION => 'ANALYZE',
   p_CODE => SQLCODE,
   p_MSG => 'Abort Daily Analyze: Error "' || SQLERRM || '" ocured '|| to_char(v_owner)||'!');

end ANALYZE_JOB;

Una volta eseguita, scriverà nella tabella HSTATISTICS_TAB delle informazioni molti utili vediamo adesso se sono riuscito a
rispondere alle domande precedenti:

1)Attraverso la colonna time_stamp è possibile verificare la durata dell'operazione anche per singolo SCHEMA.
2)Attraverso la colonna MSG_TEXT e MSG_CODE posso verificarne l'esito, in caso di errore inserirà nella colonna MSG_CODE un ORA:.
3)Creando la tabella HSTATISTICS_TAB posso far consultare anche un utente non DBA, con appositi permessi e soprattutto tenere
uno storico per la raccolta delle statistiche.

Complex_view_merging - DataPump

2011-03-25T06:32:00.000-07:00

Un paio di giorni fa mi sono imbattuto in un bug Oracle precisamente il 5879865 presente nel mia 10.2.0.3.
Dopo delle ricerche in internet ho pensato di sfruttare il Metalink e in effetti il bug è ben noto e viene presentata la risoluzione finale applicando la patch oppure un accrocchio (workaround) finchè la patch non fosse uscita, questo documento veniva scritto nel Gennaio 2008 e modificato a settembre 2010.
Ad oggi ho verificato, la patch è stato rilasciata ma non ovviamente per tutti gli OS, infatti per Windows non c'è ancora.
Allora sono intervenuto come descritto nel workaround.
In pratica l'errore che si verificava era questo usando DataPump nel mio caso:

ORA-39014: One or more workers have prematurely exited.
ORA-39029: worker 1 with process name "DW01" prematurely terminated
ORA-31672: Worker process DW01 died unexpectedly.
The alert log shows a core dump:
ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [_evaopn2+578]

Il problema è che se una sub-query utilizza l'EXISTS e va ad intterogare una vista non-mergeable si verifica questo errore.

La soluzione proposta in assenza di patch è quella di modificare principalmente 3 parametri:

_complex_view_merging
event
_optimizer_cost_based_transformation

in

alter system set event= '38066 trace name context forever, level 2' scope=spfile;
alter system set "_complex_view_merging" = false scope=spfile;
alter system set "_optimizer_cost_based_transformation"=off scope=spfile;

Ho preferito farlo utilizzando anche scope=spfile anche se dopo l'istanza andava riavviata, tuttavia si poteva fare anche a livello solo di system eliminando il parametro scope.

In effetti dopo questa modifica il Data Pump ha ripreso a funzionare.

L'unica cosa che mi stupisce è che in un altro database sempre Oracle 10.2.0.3 però nella versione Enterprise, questo errore non è mai avvenuto.

ASH Point

2011-03-16T07:13:00.000-07:00

In oracle 10G OEM Grid è stata introdotta una nuova funzionalità a livello grafico chiamata ASH.
Sinceramente sono stato sempre affascinato da questa nuova feature, perchè permette di controllare quello che gli utenti eseguono in tempo reale nel database.
Oltre ad avere una funzione ovviamente di Tuning, in caso di bottleneck è uno dei primi check che ogni DBA dovrebbe eseguire.

Tendo a sottilineare che non tutti i problemi si possono identificare tramite ASH ma è un primo passo per verificare in tempo reale cosa sta accadendo all'interno del DB.

Sapere che statement sta eseguendo un utente aiuta, e non poco, a scoprire che cosa non funziona in una singola istruzione SQL.
Caso comune: squilla il telefono e un utente domanda come mai l'operazione che sta eseguendo ci impiega un "troppo" tempo o per utilizzare un'espressione più appropriata, un tempo maggiore diverso dalle aspettative o dallo standard.
Lasciando un attimo da parte la infrastruttura di rete e le relazioni tra client server, anch'esse molto importanti per determinare la causa, ci focalizziamo all'interno del db.

Collegandosi con OEM è possibile verificare che cosa sta facendo l'utente in questione ossia lo statement SQL, gli eventi di attesa e tanto altro ancora.
Tutto molto bello con grafici e altro ovviamente stiamo utilizzando un'interfaccia grafica.
Ma se volessi eseguire tutto ciò con un script sql sarebbe possibile?
Ovviamente sì, ci sono molti script che fanno questo tipo di analisi ma io per comodità e per capire di più dell'argomento ne ho creato uno.

select V$SQL_PLAN.child_number,
V$SQL_PLAN.OPERATION,OBJECT_NAME,OPTIONS, CARDINALITY as ROWS_,(bytes)/1024 as KByte,COST,(V$SQL_PLAN.TIME) as TIME_SEC, CPU_COST,io_cost,V$SQL_PLAN.PLAN_HASH_VALUE,
sid,serial#,status,osuser,machine, terminal, program,sql_text,executions,first_load_time,COMMAND_TYPE,state,OPTIMIZER_MODE,OPTIMIZER_COST, event,buffer_gets,
logon_time, blocking_session_status from v$session,v$sql,V$SQL_PLAN
where v$sql.sql_id = V$session.sql_id
and v$sql.CHILD_NUMBER=v$session.sql_child_number
and V$SQL_PLAN.SQL_ID = V$SQL.SQL_ID
order by SID;

Con questo script è possibile identificare tutto ciò che un utente sta facendo all'interno del DB. Inoltre ho aggiunto altri funzionalità per esempio l'execution plan di uno statement con i relativi costi, in base all'optimizer, di CPU e IO e il numero di righe che restituisce.
Lo script mostra inoltre l'event di attesa ed eventuali lock oltre il sid e tante informazioni utili.

Per un uso corretto si potrebbe aggiungere anche status <> 'INACTIVE' per vedere solo quelli attivi ed eventualmente bloccati o bloccanti e poi magari inserire un filtro in machine, terminal e program per scartare alcuni server, client o addirittura applicativi.

Con questo script si riesce ad avere tutte le informazioni nel caso di una telefonata di uno o più utenti, per vericare dove quello statement SQL rimane in HANG.
Poi nel caso si possono eseguire controlli diversi con altri strumenti tipo AWR, ADDM ecc, che collezionano una serie di statistiche in una determinata forbice di tempo.

Inoltre aggiungo degli utilissimi link al sito di Kyle Hailey vero fautore dell'ASH per comprenderne meglio le potenzialità.

http://ashmasters.com/

http://sites.google.com/site/oraclemonitor/kyle-hailey

Script Maintenance e Tuning per OS Solaris - Oracle

2011-03-10T03:16:00.000-08:00

Oggi vorrei scrivere un post descrivendo alcuni miei script che sono molto utili quando si deve effettuare del tuning di un DB Oracle in ambiente OS Solaris.
Quando si parla di tuning di sistema è sempre meglio suddividere l'analisi in 2 punti:

OS che in che questo post si parlerà di Solaris
DB Oracle

Questo articolo si sviluppa intorno al primo punto, magari in un secondo momento si potrà descrivere un approccio di tuning (almeno il mio) per il secondo.

Il primo script chiamato mem.sh esegue un controllo della memoria attraverso il comando iostat messo in loop con la pecurialità, che accompagna tra l'altro tutti gli script successivi di mandare, una mail qualora si verifichino delle condizioni, in questo caso quanto la CPU Idle è inferiore a 5%.

Questo significa che il sistema sta lavorando a pieno regime e quindi è necessario eseguire un check per verificare che processi stiano utilizzando la cpu correttamente.

mem.sh

MULTI_INSTANCE=0

set +u

USER=$(whoami)

LOGFILE="/tmp/LogMEM"

HOST=$(hostname)

OSTYPE=$(uname)

for i in 1 2 3 4 5 6 7 8 9 10 11 12

MEM=" "

MEM="$(iostat -c 5 8 |sort -nr | head -n1 | awk '{print $4}')$MEM"

if [ "$MEM" -le 5 ] ; then

echo " \n$(date) La CPU idle del sistema è $MEM%" . ATTENZIONE >> $LOGFILE

iostat -c 5 8 |sort -nr | head -n1 | awk '{print $4}' > /tmp/log_mem

mailx -s "La CPU idle del sistema è $MEM%. ATTENZIONE " mail@domain.com

else

echo "\n$(date) La CPU idle del sistema è $MEM%" >> $LOGFILE

sleep 285

done

Il secondo script si chiama statcpu.sh, molto simile al primo ma con la caratteristica di inserire i dati campionati sempre con il comando iostat in loop, in una tabella Oracle.

Questo potrebbe essere utile in caso di analisi e statistiche in un periodo di tempo medio/lungo per poterli poi eleborare e presentare con grafici ed altro.

statcpu.sh

SERVER_NAME=`uname -a|awk '{print $2}'`

typeset -u SERVER_NAME

export SERVER_NAME

for i in 1 2 3 4 5 6 7 8 9 10 11 12

CPUUSR=" "

CPUIDLE=" "

CPUSYS=" "

CPUWAY=" "

CPUUSR="$(iostat -c 1 2 |sort -nr | head -n1 | awk '{print $1}')$CPUUSR"

CPUSYS="$(iostat -c 1 2 |sort -nr | head -n1 | awk '{print $2}')$CPUSYS"

CPUWAY="$(iostat -c 1 2 |sort -nr | head -n1 | awk '{print $3}')$CPUWAY"

CPUIDLE="$(iostat -c 1 2 |sort -nr | head -n1 | awk '{print $4}')$CPUIDLE"

$ORACLE_HOME/bin/sqlplus -s scott/tiger <<EOF

insert into cpu_stat values (

SYSDATE,

$CPUUSR,

$CPUSYS,

$CPUWAY,

$CPUIDLE,

'$SERVER_NAME');

commit;

EXIT

EOF

sleep 285

done

Il terzo e ultimo script serve per controllare sempre in tempo reale con il comando ps quali processi che superano un certa soglia di cpu in questo caso il 15% .

Questo potrebbe essere utile se stiamo effettuando un tuning attivo.

Quando la condizione si verifica, cpu per un processo cha va oltre il 15% il sistema manda un mail.

cpu_new.sh

MULTI_INSTANCE=0

set +u

USER=$(whoami)

LOGFILE="/tmp/LogCPU"

HOST=$(hostname)

OSTYPE=$(uname)

for i in 1 2 3 4 5 6 7 8 9 10 11 12

CPU=" "

CPU="$(ps -efo pcpu,pid,args | sort -nr | head -n 1|awk '{print $1}')$CPU"

if [ "$CPU" -ge 15.0 ] ; then

echo " \n$(date) Trovato processo maggiore del 15% di CPU. Massimo utilizzo di CPU è di $CPU%" >> $LOGFILE

ps -efo pcpu,pid,args | sort -nr | head -n 1 > /tmp/log

ps -efo pcpu,pid,args | sort -nr | head -n 1 >> $LOGFILE

mailx -s " Trovato processo maggiore di 15% di CPU in `uname -n`. Massimo utilizzo di CPU è di $CPU% " nome@domain.com < /tmp/log

else

echo "\n$(date) Non è stato trovato nussun processo maggiore del 15% di CPU. Massimo utilizzo di CPU è di $CPU%" >> $LOGFILE

ps -efo pcpu,pid,args | sort -nr | head -n 1 >> $LOGFILE

sleep 285

done

Tutti questi script, in realtà ne ho altri, sono stati scritti in Korn Shell in principio, ma si possono benissimo adattare anche ad una shell più friendly come la Bourne.

Utilizzando questi script e parallelamente gli strumenti che il db Oracle ci mette a disposizione, tipo AWR, Statepack, ADDM e altri, abbiamo tutti i dati per poter al meglio effettuare un analisi completa sul nostro sistema.

HTH

EXP-00091

2011-02-24T02:39:00.000-08:00

Stamattina controllando i files di log delle varie operazioni notturne di Oracle mi sono imbattuto in un EXP-0091: Exporting questionable statistics, durante un exp non full di un DB ver 9.2.0.1.0 in un server Windows 2003.

Ho provato ad esportare solo la tabella interessata per verificare meglio il tutto ma ovviamente l'errore si ripresentava:

Username: XXXX
Password:

Connected to: Oracle9i Release 9.2.0.1.0 - Production
JServer Release 9.2.0.1.0 - Production
Enter array fetch buffer size: 4096 >

Export file: EXPDAT.DMP >

(2)U(sers), or (3)T(ables): (2)U > 3

Export table data (yes/no): yes >

Compress extents (yes/no): yes >

Export done in WE8MSWIN1252 character set and AL16UTF16 NCHAR character set
server uses WE8ISO8859P1 character set (possible charset conversion)

About to export specified tables via Conventional Path ...
Table(T) or Partition(T:P) to be exported: (RETURN to quit) > AAAA

. . exporting table AAAA 48668 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
Table(T) or Partition(T:P) to be exported: (RETURN to quit) >

Export terminated successfully with warnings.

Verificando meglio ho visto che era un'errore di conversione del character set.
Allora lo imposto manualmente dalla sessione in uso uguale a quello del server come suggerisce un post nel forum OTN http://forums.oracle.com/forums/thread.jspa?threadID=339093 :

C:\Documents and Settings\Admin>SET NLS_LANG=.WE8ISO8859P1

C:\Documents and Settings\Admin>exp

Export: Release 9.2.0.1.0 - Production on Thu Feb 24 10:40:06 2011

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Username: XXXX
Password:

Connected to: Oracle9i Release 9.2.0.1.0 - Production
JServer Release 9.2.0.1.0 - Production
Enter array fetch buffer size: 4096 >

Export file: EXPDAT.DMP >

(2)U(sers), or (3)T(ables): (2)U > 3

Export table data (yes/no): yes >

Compress extents (yes/no): yes >

Export done in WE8ISO8859P1 character set and AL16UTF16 NCHAR character set

About to export specified tables via Conventional Path ...
Table(T) or Partition(T:P) to be exported: (RETURN to quit) > AAAA

. . exporting table AAAA 48668 rows exported
Table(T) or Partition(T:P) to be exported: (RETURN to quit) >

Export terminated successfully without warnings.

Adesso lanciandolo manualmente tutto va bene, ma non mi riesco a spiegare il perchè di questa variazione, negli export precedenti benchè il problema del character set ci sia sempre stato, l'operazione si concludeva con successo.

Nel DB server non è stata fatta nessuna variazione e tra l'altro nelle specifiche dell'export imposto l'opzione STATISTICS=NONE, quindi non mi dovrebbe esportare nessuna statistica.
L'errore poi è solo per questa tabella mentre nelle altre che esporto di questo problema non c'è traccia.
Provo ad indagare meglio....

AGGIORNAMENTO

La tabella in questione è una tabella che ogni 30 min viene cancellata e ricreata.
Questa operazione dura pochi secondi ma se nel durante viene eseguito l'export può generale questo errore.
Ci sono altre tabelle che vengono cancellate e ricreate ma non hanno presentato mai questo errore.
Stasera riviene eseguito l'export alla stessa ora e vediamo cosa succede.

Android Market.....

2011-02-10T08:51:00.000-08:00

Circa 20 giorni fa mi sono preso un tablet con Android versione 2.2 installata, tutto contento per l'acquisto l'ho messo alla prova e verificato tutte le funzionalità.
Mi sono detto...Wow...perfetto adesso provo a scaricare delle nuove Apps, fiore all'occhiello di tutti i sistemi basati su Android.
Lancio l'applicazione dal mio tablet e vedo delle applicazioni ma però non mi soddisfano, allora provo a cercarle...non mi trova praticamente nulla o quasi....
Allora provo ad andare direttamente nel sito ufficiale http://market.android.com, ovviamente visto che ho Gmail il login è semiautomatico e accedo al sito.

Cerco un'applicazione per scaricarla ma mi compare l'errore..."there are no android phones associated with this account".
Sono rimasto molto sorpreso.
Credendo che sia l'unico (come sempre) a cui compaiono questi errori, visto che possiedo un tablet,ho guardato un pò in giro in internet ed ho scoperto che non solo quelli che hanno i tablet come me rimangono a bocca asciutta di app ma anche quelli che hanno alcuni smartphone.
Google ha instituito un forum dove raccoglie tutte le problematiche relative a questo ed altri errori simili...
http://www.google.com/support/forum/p/Android+Market/thread?fid=2ef0ea226c27a0fd00049b61590415ee&hl=en

All'inizio di questa settimana ho scoperto un altro sito dove dichiarava SOLVED questo problema, ho dato un'occhiata, ho provato ad eseguire step by step la risoluzione ma niente da fare, a me non funziona...
Questo è il sito http://phandroid.com/2011/02/04/solved-android-market-website-says-there-are-no-android-phones-associated-with-this-account/ dove ho scoperto nei commenti,che ad alcuni funziona ed altri no, spero vivamente che Google metta a posto questo assurdo problema.....in tempi anche abbastanza rapidi....

Oracle Partitioning

2011-02-04T00:35:00.001-08:00

Da un po' i tempo sto facendo dei test con il Partitioning di Oracle 10g.
Questa feature si trova solo nella versione Enterprise ed è molto utile oltre ad ottimizzare le performance anche solo per "archiviare" dei dati.
In certe aziende o per ragione legali o per ragioni di qualifica ISO o per altri motivi non si esegue una archiviazione dati, alcune tabelle contengono milioni di dati e questo potrebbe sfociare in un problema di performance.
Anche se si continua a implementare hardware / server sicuramente più veloci e performanti questo problema nel tempo va affrontato perchè tutti i nodi vengono al pettine, ve lo dice uno che di capelli ne ha veramente molti.....
Per implementare il partitioning occorre fare una analisi molto accurata dell'applicativo e il modo di accesso che quest'ultimo fa alle tabelle Oracle, quì ci vengono incontro due tool: Partitioning,
Tuning Pack che ovviamente non sono gratuiti.
Per natura sono un pò scettico per questi tools che vengono venduti come risolutori di problemi ma penso che possano essere almeno di aiuto.
Partizionare le tabelle per "archiviare" (lo scrivo tra doppi apici perchè non è una vera a propria archiviazione) risulta essere molto utile perchè con dei campi data si possono creare delle partition key suddivise molto semplicemente per anno per far sì che Oracle esegua il partition pruning, accendendo di fatto solo alla partizione interessata.
Facendo così il CBO ( però le statistiche devono sempre essere aggiornate) capisce e accede solo alla partizione interessata facendo risparmiare moltissimo tempo, pensando a tabelle con milioni di records.Questo risparmio può essere visto eseguendo l'explain plan e il trace dello statement sql interessato.
Questo è ovviamente è un esempio molto semplice di partitioning di tipo range ma c'è ne sono altri, Hash, List e questi possono essere composite o single level.
Vi rimando a questo sito (in inglese) che è molto esplicativo come concepts del Partitioning.

Mail Evolution in Ubuntu - Update

2011-02-04T00:33:00.001-08:00

Come promesso ho provato nella versione di Evolution 2.28.3 con Ubuntu 10.04 come descritto nei workaround dei link e....funziona :-)
Il problema è della libreria liborg-gnome-exchange-operations.so che va sostitutita.
I passi sono molto semplici:
1) Si scarica da questo indirizzo http://packages.debian.org/sid/i386/evolution-exchange/download il pacchetto evolution-exchange_2.30.3-1_i386.deb.
2) Poi si apre il .deb con l'applicazione Gestore archivi e si va in /./usr/lib/evolution/2.30/plugins/ a questo punto si estrae solo la libreria liborg-gnome-exchange-operations.so
3) Si apre una console e si va nel percorso /usr/lib/evolution/2.28/plugins (attenzione io ho la 2.28 ma la ver nel vostro potrebbe essere diversa) poi:
- eseguo il comando sudo cp liborg-gnome-exchange-operations.so OLD_liborg-gnome-exchange-operations.old così rinomino la vecchia libreria poi la cancello l'originale con il comando rm liborg-gnome-exchange-operations.so .
- eseguo il comando sudo cp dal percorso dove avete estratto la nuova libreria dall'archivio liborg-gnome-exchange-operations.so in /usr/lib/evolution/2.28/plugins
4) Rilanciate Evolution ed il gioco è fatto.
Nel mio caso ha funzionato inoltre ho provato a chiudere più volte l'applicazione e riaprirla ma non si blocca più, anzi è molto più veloce nella connessione con MSExchange.... ;-)
A presto
Ciao

Mail Evolution in Ubuntu

2011-02-04T00:32:00.000-08:00

Questo post tratterà di Evolution 2.28.3, software di posta elettronica, calendar in Ubuntu.
Sono già parecchi mesi da quando è uscita la rel di ubuntu 10.04 che utilizzo questo software e in ufficio l'ho collegato con Exchange server ma mi sta facendo tribolare .
Il demone evolution-exchange-storage che ha la funzione di collegarsi al server exchange e di trasferire i messaggi nel client locale è lentissimo a sincronizzarsi, inoltre alla mattina quando lancio il software non si collega mai al primo colpo ma devo più volte farlo ripartire prima che finalmente si colleghi al server visto che questo demone va in crash molto spesso .
Ci sono diversi siti ufficiali che parlono di questo visto che si tratta di un Bug eccone alcuni:
https://bugs.launchpad.net/ubuntu/+source/evolution-exchange/+bug/557120
https://bugs.launchpad.net/ubuntu/+source/evolution-exchange/+bug/548570
Spererei che nell'ultima Rel. Ubuntu la 10.10 le cose foessero cambiate con questo demone ma invece come per magia...
https://bugs.launchpad.net/ubuntu/+source/evolution-exchange/+bug/631395
Stesso problema...stesso bug...
...ma per fortuna c'è già un workaround, io non l'ho ancora provato visto che ho ancora la 10.04 ma in questi link è descritta molto bene come fare:
http://jaub.wordpress.com/2010/10/12/ubuntu-10-10-evolution-exchange-bug-e-workaround/
http://blog.dinel.org.uk/?p=200
e sembra funzionare...
A presto...
P.S.: Quasi quasi provo questo workaround anche con la 10.04...non si sa mai... ;-)