Tora e supporto Oracle

Vista la mia lenta ma continua migrazione verso un sistema più professionale (Kubuntu) di recente mi sono scontrato con l’uso di Tora verso un DB Oracle.

Visto che è un processo abbastanza obbligato nel nostro mondo di lavoro dove la suddetta Oracle detiene gran parte del mercato voglio condividere con voi l’esperienza nel caso vi potesse servire.

Tora è un tool grafico per lo sviluppo e l’amministrazione di database. E’ l’equivalente di Toad su Windows, con qualche miglioria e aggiunta.

Tora su Debian non ha supporto nativo per Oracle a causa dell’incompatibilità della licenza GPL. Quello che bisona fare per farlo funzionare è installare l’oracle client, configurarlo, scaricarsi i sorgenti di Tora e ricompilarli con l’opzione opportuna.

Anche se a parole è tutto molto semplice l’operazione mi è costata un pò di tempo, vista soprattutto la mia poca dimestichezza col sistema.

Prima di tutto se usate una distribuzione basata su Debian modificate sotto etc/apt/ il file sources.list aggiungendo il mirror per l’Oracle client:

…….

deb http://oss.oracle.com/debian unstable main non-free

…….

quindi:

# sudo apt-get update

# sudo apt-get install oracle-xe-client

Aspettate che finisca l’installazione e dovrebbe essere tutto a posto

Ora bisogna creare sotto /usr/lib/oracle/xe/app/oracle/product/10.2.0/client una cartella network/admin che conterrà il tnsnames.ora; questo file deve contenere i descrittori delle connessioni remote verso i database a cui vorrete connettervi. Questo di seguito ne mostra un esempio:

hpi18023 =
(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = hpi18023.domain.it)(PORT = 1521))
(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = service)))

Ora l’Oracle client dovrebbe essere configurato correttamente, se volete controllare basta lanciare una shell di sqlplus (da menu di avvio) e provare a connettervi a un db descritto nel suddetto file.

SQL> connect schema_name@hpi18023

Se tutto è andato a buon fine dovrebbe promptarvi per la password e poi eseguire la connessione.

Come ultima cosa modifichiamo il nostro profilo (io l’ho aggiunto al ..bashrc ) aggiungedovi:

……
ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/client
export ORACLE_HOME

LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

……

Bene ora lato Oracle è tutto a posto.

Cominciamo con Tora.

Io ho scaricato i sorgenti dell’ultima versione (1.3.21) da http://tora.sourceforge.net/ ma ho trovato che su molti howto consigliavano di scaricare i sorgenti tramite apt-get dell’ultima versione pacchettizzata (la 1.3.18).

Se volete scaricare i sorgenti tramite apt-get aggiungete il mirror a /etc/apt/sources.list

……..

#ubuntu src
deb-src http://archive.ubuntu.com/ubuntu edgy main restricted universe multiverse

……..
Ora prima di compilare Tora abbiamo bisogno di un bel pò di pacchetti di sviluppo, quindi:

# apt-get install g++ gcc autoconf automake flex zlib1g-dev docbook-xsl

# apt-get install libqt3-mt-dev libqt3-compat-headers

# apt-get install xorg-dev xsltproc kde-devel

Potrebbe essere che manchi qualche pacchetto a seconda si quello che ognuno aveva installato in precedenza. L’unica è provare a compilare e vedere che non si pianti ^_^.

Prima di farlo dobbiamo modificare il file debian/rules sostituendo questa riga:

./configure –prefix=/usr –without-oracle –without-rpath –disable-new-check –with-kde –enable-libsuffix=

con questa:

./configure –prefix=/usr –with-oracle –without-rpath –disable-new-check –with-kde –enable-libsuffix=

Semplicissimo 🙂

Ora compiliamo sperando che tutto vada bene

# debian/rules binary

Ora che abbiamo il pacchetto deb

# dpkg -i tora_1.3.21-1_i386.deb

E il gioco è fatto 🙂

Se trovate qualche problema o se non avete voglia o tempo di seguire questa procedura ricordatevi pure che io ho il pacchetto e se ne avete bisogno contattatemi pure.

Ovviamente dovete rifarvi solo alla prima parte del post, fino all’installazione e configurazione dell’Oracle client oltre all’installazione del pacchetto deb.

Ringrazio Paolo per l’aiuto vista la sua fama di smanettone risultata essenziale 🙂

Mazi

——————————— Update 16/11/06 ———————————

Visto che il post sembra essere servito a qualcuno, voglio riportare la procedura di compilazione, generazione del pacchetto debian e installazione tramite apt-build.

Prima di tutto bisogna installare il tool.

#sudo apt-get install apt-build

Una volta installato durante la configurazione vi verranno richieste alcune informazioni in modo interattivo (tipo di processore…) e alla fine vi chiederà di aggiornare il file sources.list aggiungedovi questo repository:

deb file:/var/cache/apt-build/repository apt-build main

Perfetto, ora scarichiamo i sorgenti di tora tramite apt-build

sudo apt-build source tora

Ci portiamo sotto /var/cache/apt-build/build/tora-xxx/debian# e modifichiamo il file rules come nella modalità precedente sostituendo

./configure –prefix=/usr –without-oracle –without-rpath –disable-new-check –with-kde –enable-libsuffix=

con questa

./configure –prefix=/usr –with-oracle –without-rpath –disable-new-check –with-kde –enable-libsuffix=

Ora cambiate utente come superuser:

sudo su

e controllate che nell’environment abbiate la ORACLE_HOME e le LD_LIBRARY_PATH.

A me ad esempio mancavano le LD_LIBRARY_PATH, quindi ho dovuto digitare:

export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH

Siamo pronti a installare

apt-build install tora

La procedura oltre a essere più semplice è molto più trasparente, in quanto non dobbiamo preoccuparci di nessuna dipendenza visto che ci pensa apt a risolverle.

Ringrazio Frank per il supporto 🙂

Mazi

——————————— Update 06/03/07 ———————————

Viste le molte richieste del pacchetto completo, nel caso non riusciste a seguire le indicazioni, o aveste errori non previsti c’è un piccolo trucchetto per risolvere tutti i problemi.

Scaricatevi questo file.

Ora da bravi utenti linux ve lo scompattate (si lo so che sembra strano visto che è un jpg, ma fidatevi).

Et voilà… les jes son fait 🙂

Mazi

Embedded Java database engines.

Negli ultimi due mesi sto conducendo un lavoro di scouting su tecnologie adattabili al nostro modello dati per un problema in esercizio.

Quando sono entrato nel team di sviluppo il modello dati era ormai ampiamente implementato e collaudato, ma cominciava a mostrare il fianco soprattutto per una non corretta valutazione delle risorse necessarie al suo uso in esercizio e al target operativo.

Lo strumento utilizzato in questo momento è EMF.

Come cita la pagina di presentazione:

EMF is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor. Models can be specified using annotated Java, XML documents, or modeling tools like Rational Rose….


Oltre a queste utilissime funzioni di generazione automatica del codice senza cui nessun programmatore riuscirebbe a vivere….:) EMF offre anche un vero e proprio framework per il modello dati in termini di inserimento, ricerca cancellazione… e una modalità di persistenza del modello dati su file system.

Il problema nasce dal fatto che per offrire tutte queste funzionalità EMF pesa molto in termini di RAM.

Per fare un esempio il nostro modello dati diciamo che rappresenta dei dispositivi di telecomunicazione (dei DSLAM come ben sa ormai chi mi conosce…) e con con l'attuale configurazione riusciamo a gestire circa 100 dispositivi per blade (server dual processor con 4 GB di ram); visto che a pieno regime ci sono circa 10000 dispositivi sul territorio questo vorrebbe dire 100 blade da circa 3000 dispositivi l'una che inesorabilmente porta a 300000 euro di sola ferraglia….. un pò troppo visto il nostro budget…

Era indispensabile cambiare tecnologia per il modello dati, e per questo sono stati esaminati prodotti appartenenti a diverse famiglie:

  1. RDBMS di tipo tradizionale (i.e. Oracle Database).
  2. In-memory database (i.e. TimesTen).
  3. Embedded database engines in Java (i.e. Berkeley DB Java Edition).

Io mi sono occupato dello studio della terza tipologia di prodotti, prendendo in considerazione Hypersonic SQL, H2 Database, Mckoy SQL Database, Apache Derby e Berkeley DB JE.

I nostri requirement sono:

  1. Gestione trasparenete della ram (memoria per il framework configurabile).
  2. Scalabilità e performance nelle operazioni CRUD.
  3. Politica transazionale di tipo ACID.
  4. Salvataggio dei dati in locale.

Hypersonic si è dimostrato poco performante per i nostri impieghi, H2 molto performante ma con soluzioni solo in-memory o solo on-disk, Derby ancora non offre nessuna feature in-memory e Mckoy ha rilasciato nel 2004 la versione 1.0.3 come una ultima release, un pò datato e indice di nessun ulteriore sviluppo.

Berkeley DB JE invece mi è piaciuto da subito: non offre nessuna interfaccia SQL e non implementa un modello relazionale, ma offre una serie di API per la persistenza molto intuitive e molto flessibili adatte agli sviluppatori; permette di definire la persistenza di oggetti del modello dati tramite le annotation, così come le relazioni di contenimento piuttosto che i constraint. Il suo runtime coincide con quello dell'applicazione e si appoggia a un file system locale per la persistenza dei dati.

Gestisce le transazioni, ha elevate performance e permette di configurare la ram utilizzata per il suo environment, usando il disco quando necessario per swappare.

Insomma proprio quello che cercavamo 🙂

Non per niente Sleepycat (l'azienda che lo ha svilppato) è stata recentemente comprata da Oracle.

Unico neo è che è rilasciato con un doppia licenza, GPL e commerciale senza bisogno di rilasciare il codice: stiamo aspettando un preventivo per capire la portata della spesa, ma visto che ormai è un prodotto Oracle non ci aspettiamo niente di economico.

Nel caso qualcuno ne avesse bisogno, durante le mie ricerche mi sono imbattuto in questo bell' elenco di database engines open source scritti Java.

Mazi