Archivi categoria: Oracle DBA

libawt.so: libXp.so.6: cannot open shared object file

Durante l’installazione di oracle su redhat 5.2 potrebbe capitare il seguente errore:

/tmp/OraInstall2005-06-15_07-36-25AM/jre/1.4.2/lib/386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory

controllate che siano stati installati i seguenti pacchetti

rpm -ivh compat-db-4.2.52-5.1.i386.rpm compat-libstdc++-296-2.96-138.i386.rpm compat-libstdc++-33-3.2.3-61.i386.rpm gcc-4.1.2-42.el5.i386.rpm gcc-c++-4.1.2-42.el5.i386.rpm glibc-devel-2.5-24.i386.rpm glibc-headers-2.5-24.i386.rpm libgomp-4.1.2-42.el5.i386.rpm libstdc++-devel-4.1.2-42.el5.i386.rpm libXpm-devel-3.5.5-3.i386.rpm
 libXp-1.0.0-8.1.el5.i386.rpm

Fletto i muscoli e sono nel vuoto.

Non posso vedere il contenuto del campo cblog

…è la risposta di un dba oralce di una grande azienda. Alla richiesta di sapere che valore ci fosse in un campo di una riga di una tabella. Dando per scontato che un dba di un certa portata, dovrebbe mangiare pane e oracle, la risposta è veramente triste.

Fletto i muscoli e salto nel vuoto.

TNS: lost contact !

Primo “vero” momento di “crisi” per KOS. L’applicazione va in eccezione – con tempistica o azione del tutto causale – con “ORA-03113 end-of-file on communication channel”.

Vengono fatte tutte le analisi e le ipotesi del caso, risultato: nulla!, il problema continua a persistere.

E’ qui che comincia la crisi, non si riesce a capire quale sia il problema e quindi nemmeno a trovare una soluzione. L’unica cosa di cui siamo certi – analizzando i log – è che il problema è iniziato il giorno 13 Dicembre alle 13 circa. Quindi azzardiamo qualsiasi ipotesi:

Pensiamo che sia KOS:

Anche se non ci crediamo molto, l’ultima release è stata fatta giorno 12 con una release note veramente scarna: solo qualche minor bug fixing.In quanto, concentrati sulla release del nuovo modulo di MAGAZZINO/FARMACIA. Facciamo tutti i controlli del caso, risultato: nulla!

Pensiamo che sia il nuovo SERVER PACS :

Hanno da poco installato un nuovo server che fungerà da PACS. Ipotizziamo che non sia stato configurato bene oppure che il transfer di immagini sia troppo oneroso e provochi problemi. Abbiamo provato a staccarlo, risultato: nada!

Pensiamo che sia ORACLE:

Attiviamo tutti i log possibili ed immaginabili e consultiamo tutti i tips del caso, i vari forum, e quant’altro ci possa dare una mano. Devo dire che oracle permettere di indagare veramente a fondo, al punto di poter “tracciare” i singoli pacchetti inviati nella comunicazione client-server.

Qui di seguito alcuni link di riferimento:

http://www.orafaq.com/wiki/Sqlnet.ora

http://www.orafaq.com/faqnet.htm

http://www.oracle-base.com/articles/misc/OracleNetworkConfiguration.php

http://download.oracle.com/docs/cd/B14117_01/network.101/b10775/troublestng.htm

http://forums.oracle.com/forums/thread.jspa?messageID=2256122

Ma senza nessun risultato.

Pensiamo che sia il SERVER che ospita ORACLE:

Ma non troviamo alcun log che possa indicarci qualche malfunzionamento. Risutato: buio completo!

Pensiamo che sia lo SWITCH che collega i SERVER alla rete:

Ma anche qui facciamo “quasi” un buco nell’acqua, troviamo un cavo difettoso (per una scheda secondaria di un altro server). Risultato: nulla di che!

Oramai siamo in preda alla follia, azzardiamo qualsiasi ipotesi anche senza senso, torniamo a pensa che sia ORACLE:

Magari qualche query errata, o comunque qualcosa che impegni il db cosi tanto da far cadere le connessioni. Un corruzione di indici. Risultato: ancora niente.

Torniamo a pensare che sia un problema di rete:

Attiviamo ethereal, pensiamo che qualche macchina mandi pacchetti anomali provocando disconnessioni o che le workstation del pacs dia problemi. Risultato: boh!

Giorno 20 Dicembre, siamo distrutti, facciamo ipotesi che potrebbero essere definite ‘fantasiose’: “attacco DOS”:

Stacchiamo firewall, e quant’altro, siamo esclusi dal mondo esterno. Sono le 19.03, oramai c’è solo silenzio. Quando all’improvviso: “drin! drin!”. Il telefono!… direte voi! Non può essere! … abbiamo scaricato i cordless a furia di telefonate da parte degli operatori e dei medici che non riuscivano lavorare. Allora cosa ?… una cosa che ci ha inquietati tutti! Squillava un contatto skype di un collega! Tutti in coro: ma come !?! siamo scollegati da internet. A me viene i mente scene di un film come “the ring”. Un collega ha scritto come topic sul suo contatto skype:”una chiamata dall’aldilà“.

Veniamo a scoprire tramite un tracert dell’esistenza di un router “sconosciuto”. Indagando, scopriamo che tale router è stato proprio installato in concomitanza con l’inizio dei nostri problemi. Come potete intuire, è un router che non dovrebbe proprio essere presente nella nostra rete e ci collegava in “malomodo” ad un’altra rete che non ha nulla a vedere con la nostra.

Risultato: Scollegandoci da quel router maledetto si è risolto il problema.

Fletto i muscoli e sono nel vuoto !

ps. Buon Natale a tutti 😀

Backup oracle flash recovery area

La flash recovery area permette di ripristinare i dati del vostro db oracle anche a pochi minuti prima dell”‘incidente”.

Tuttavia, se non gestita correttaemente, quest’area continua a crescere fino ad raggiungere il limite massimo (configurato nell’impostazioni del db).

In questo caso potreste avere errori del tipo:

ORA-16038: log 1 sequence# 230 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 1 thread 1: ‘/oradata/…/redo01.log’

Per risolvere questo problema potete seguire la seguente procedura che utilizza sqlplus e rman.

$ sqlplus sys as sysdba

avviate la vostra istanza oracle

SQL> startup mount;

se fosse già aperta chiudetela con

SQL> shutdown immediate;

dopo aver avviato l’istanza controllate quale sia la dimensione attuale della flashbackarea

SQL> show parameter db_recovery_file_dest_size

a questo punto dovrete aumentare leggermente le dimensioni della flashbackarea con il seguente comando

SQL> alter system set db_recovery_file_dest_size=25G scope=BOTH;

A questo punto chiudete e riavviate l’istanza.

SQL> shutdown immediate;
SQL> startup open;

Quindi passiamo a RMAN.

$ rman target /

Dove lanceremo il seguente script:

run {
backup database;
backup (archivelog all delete input);
} allocate channel for maintenance device type disk;
delete obsolete device type disk;

Il seguente script di occupa di fare il backup dei file del database, poi dell’archive log. E dopo, quando questa operazione si è conclusa con successo, la flash recovery area viene ripulita. Ed infine, rimuove i backup obsoleti in accordo con le politiche di gestione dei backup di rman.

Quindi avviando questo script con una certa frequenza non incorreremo più nell’errore sopracitato.

powered by IMHO 1.3

ORA-19809: limit exceeded for recovery files

Today Oracle say me ‘have a good day’ with:

ERROR at line 1:
ORA-16038: log 1 sequence# 230 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 1 thread 1: ‘/oradata/…/redo01.log’

Cause:

We register all the information about what we place in the flash recovery
area in the rman repository/controlfile. If we determine that there is not
sufficient space in the recovery file destination, as set by dest_size then
we will fail.

Fix:

Increase the parameter db_recovery_file_dest_size.

Es.: SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=10G SCOPE=BOTH;
Reference: terrencemiao

Solution: Backup oracle flash recovery area

Starting and Stopping the Oracle Management Agent

Data la complessità del database, Oracle mette a disposizione un framework per la sua gestione “Oracle Enterprise Management Framework”.

Tale framework è essenzialmente diviso in due aree funzionali:

Managed Targets. Ossia le entità gestite dall’Enterprise Manager. Es.: databases, applications servers, web servers, applicazioni e gli Oracle Agents (come Oracle Net listener, connection manager).

Management Service. Sono dei componenti Java-based al quale è possibile collegarsi per monitorare e/o gestire i Managed Targets.

Per ogni Managed Target esiste un “background process” chiamato Oracle Management Agent. Questo agent si occupa di recuperare informazioni riguardo allo specifico Managed Target, e di inviarle al Management Service.

Ecco un esempio di come far partire un agent:

/u01/app/oracle/product/10.0.1/bin> emctl start agent

E possibile gestire il singolo database (quindi separatamente dal Grid Control Framework centralizzato) tramite Enterprise Manager Database Control, alias dbconsole.

Ecco come far partire dbconsole:

/u01/app/oracle/product/10.0.1/bin> emctl start dbconsole

Per fermare un agent basta usare l’opzione stop.

/u01/app/oracle/product/10.0.1/bin> emctl stop agent

oppure

/u01/app/oracle/product/10.0.1/bin> emctl stop dbconsole

E’ possibile conoscere lo stato dell’agent dbconsole tramite l’opzione status:

/u01/app/oracle/product/10.0.1/bin> emctl status dbconsole

Per accedere a dbconsole basta collegarsi con il proprio browser all’indirizzo:

http://hostname:portnumber/em

Dove la portnumber di default è impostato 5500.

Fletto i muscoli e sono nel vuoto.

powered by IMHO 1.3

ORA-19809: limit exceeded for recovery files

Stamattina Oracle mi da il buon giorno con:

ERROR at line 1:
ORA-16038: log 1 sequence# 230 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 1 thread 1: ‘/oradata/…/redo01.log’

L’errore è generato dalla mancanza di spazio riservato al flash recovery.

Per risolvere il problema bisogna incrementare il valore di

db_recovery_file_dest_size

Es.: SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=10G SCOPE=BOTH;

Solution: Backup oracle flash recovery area