Lavorare su Oracle è mistico (e forse il nome non è casuale...)

Le mie avventure con Oracle e l'Oracle Data Provider non sono finite. Alcune cose che ho scoperto oggi:

1) Il metodo che ha Oracle di registrare gli oggetti nella GAC e come questi vengono referenziati da .Net è sostanzialmente mistico. Nel senso che ci vuole la pazienza di un santo per non incartarsi. Attualmente esiste una sola versione di Orale Data Provider per .Net (il prodotto chiamato normalmente ODP): la 10.0.4. Sul mio notebook di sviluppo ho installato un server Oracle e, dato che a casa avevo fretta ed i CD "ufficiali" erano in ufficio, ci ho installato Oracle 10g R2 di cui avevo un CD mandatomi da Oracle. Bene, il risultato è che qualunque cosa compilata sul mio notebook non ne vuole più sapere di andare su nessun altro PC dell'azienda, anche se l'ODP è lo stesso. Lezione imparata, sulla macchina di Build ho religiosamente installato solo l'ODP corretto ed almeno le robe buildate e rilasciate vanno perfettamente.

2) Se iniziate a vedere degli errore "Specified cast is not valid" potete tranquillamente iniziare a pregare, sempre perchè si deve essere mistici. Ci ho perso 2 ore ed il tutto succede perchè c'era un metodo che settava la proprietà ArrayBindCount di un OracleCommand e non la resettava, la chiamata successiva non usava variabili di questo tipo ed il risultato era l'errore in questione. Assolutamente non parlante e poco chiaro, ma anche qui lezione imparata: quando usate un OracleCommand è buona cosa, se questo non è locale ad una funzione, includerlo in un blocco Try...Finally e nella Finally provvedere a resettarlo (Parameters.Clear, ArrayBindCount=0 e così via)

3) Attenzione ad usare la fantastica feature "where RowID < 2" per fare l'equivalente di una TOP 1. Il RowID viene calcolato e gestito PRIMA di fare una Order By. Anche questa cosa nota, ma ci ho perso 2 ore buone. Lezione imparata: non appena vedete la parola chiave RowID... fate attenzione

4) Anche questa è vecchia ma ve la riporto: attenzione alle tabelle temporanee. In SQL quando fate la close di una connection e questa viene rimessa nel pool le tabelle temporanee spariscono, con Oracle no. Quindi è necessario creare le tabelle temporanee nel modo giusto (ON COMMIT DELETE ROWS, notate anche che non è possibile creare tabelle temporanee da codice ma devono essere inserite nello Schema del database) ed usare le Transaction anche in sola lettura per gestire la cosa (oppure date una delete prima della close, sempre usando una bella Try...Finally, però mi piace meno).

Insomma, Oracle continua a piacermi sempre di meno, ma vedo la fine del tunnel.

La cosa impressionante (e va detto) è che a database e stored procedure assolutamente NON ottimizzati (solo gli indici di PK e FK definiti, nessun indice ausiliario, SP portate e basta, senza ottimizzazioni specifiche per usare feature sofistiche di plsql) sullo stesso ambiente (stessi DB server che vanno sulla stessa SAN) le performance sono già di un 10% migliori di SQL Server 2000 (sia come concorrenza che come performance pura). Prima o poi mi toglierò la curiosità di fare le stesse prove con SQL 2005, speriamo che MS abbia recuperato il gap.

 

posted @ martedì 8 novembre 2005 21:46

Print

Comments on this entry:

# re: Lavorare su Oracle è mistico (e forse il nome non è casuale...)

Left by Eugenio at 08/11/2005 22:47
Gravatar
Ciao Massimo.<BR>
Il nome non casuale, dici bene, ma in un altro senso.<BR>
Nel senso che il progetto pagato dalle agenzie americane (profumatamente) ad Ellison e soci doveva essere un sistemone capace di rispondere a tutte le domande possibili (l'Oracolo, infatti...). Poi il progetto fu abbandonato, Ellison saldato (credo) e...il resto è storia.<BR>
Ciao!

# re: Lavorare su Oracle è mistico (e forse il nome non è casuale...)

Left by Gaetano at 15/01/2006 19:15
Gravatar
guarda che è Oracle che gestisce correttamente le tabelle temporanee e i RowID. SQL Server è in questo senso bacato o non provvisto.

# re: Lavorare su Oracle è mistico (e forse il nome non è casuale...)

Left by Riccardo at 18/01/2006 19:16
Gravatar
Sono passato da sql server 2000/2005 a oracle 10g r2 e ti posso assicurare che tutto un altro lavorare.

1) I tool grafici 3rd parti non fanno le "cazzate" senza dirtelo. Ad esempio il riposizionamento delle colonne in una tabella: em/ide col cavolo ti dice che deve creare un'altra tabella e droppare la prima.

2) Non avendo grossi tool grafici a disposizione capisci cosa stai facendo e non ti impprovvisi dba.

3) Oracle ha più tempo di lavorare sulle prestazioni, invece di presentare i fiorellini.

Non ce l'ho con sql server. Forse si sta confrontando banane con mele: tutti e 2 frutti ma con scopi e referenze differenti.

ps: Il dts di sql 2000 è potente. Il sssi (2005) ancora di più ma è di difficile comprensione

ciao
Comments have been closed on this topic.