Il nostro ORACLE e\ diventato un mostro

[BugIT]

Salve a tutti,
vorrei un vostro parere in merito a una cosa che mi ha un po\ stupido...la societa'per cui lavoro da qualche giorno ha un database in gestione a una azienda esterna che si occupa dell'amministrazione..solo che...sto DB, tra viste, tabelle e trigger conta 3700 oggetti..solo le tabelle fisiche sono 332...ora loro (la mia azienda)si occupano di promozioni, hanno un tot di sostenitori.tengono traccia di operazioni di mkt,di sottoscrizioni, pagamenti, le solite cose...ma io mi domando...anche in vista del fatto che vorremmo prendere un dba interno..
ma non e' assurdamente grande sto DB..io ho programmato in sql e ho come l\impressione che la societa\ che gestisce il db per facilitarsi le query abbia spezzetato i dati su un numero di tabelle insostenibile...
voi che ne pensate?
grazie a tutti quelli che vorranno offrirmi il loro parere..

[pjfry]

certo, 332 tabelle non sono poche... però non credo che possiamo stabilire se sono troppe con i dati che ci dai
di sicuro tante tabelle non facilitano le query come dici, ma dovrebbero favorire la flessibilità di gestione

[BugIT]

si` ma io mi domando...
...
ma 330 tabelle..ma come si fa a avere una visione complessiva del db?
Boh a me sembra una dimesnione assurda...mi interesserebbe sapere una azienda di medie dimensioni o anche di grandi, che ne so una banca, quante tabelle mediamente ha sul db...
boh...

[BugIT]

..anche perche` volevo aggiungere una volta avevo letto uno studio di datawarehouse per una azienda che gestiva carte di credito e il db era di 200 GB con 60 tabelle..il nostro e` di 40GB con 330 tabelle...

[pjfry]

ma cosa c'è sopra? se viene gestito 'a mano' tramite sql magari sono tante, ma se c'è un framework java o altro è diverso

[archimede]

Ma il tuo problema sono le prestazioni (è lento) oppure sei preoccupato per la manutenzione? Oppure ancora non ti sembrano razionali le modalità di inserimento dei dati in questo db?

Insomma, il numero di oggetti in sé e per sé non è un parametro per giudicare un applicativo.

Alessandro

[BugIT]

grazie a tutti delle risposte, scusate se sono impreciso ma ripeto io mi occupo della rete non del db..il problema e` che la gestione esterna del db ci costa parecchio, inoltre questi che lo gestiscono continuano a cambiare il dba di riferimento, io vorrei capire come fa uno a capirci qualcosa quando gli passano un mostro da 330 tabelle...
cmq il gestionale che usano da noi gli utenti e` fatto in java, in sostanza ogni dipartimento consulta e inserisce dati tramite questo applicativo java che pero` utilizza delle viste sulle famose 330 tabelle...

non so a livello di gestione del db come facciano, ma io cmq mi domando, avendo programmato per poco in sql come diavolo si raccapezzano o meglio come fara` il poveretto che verra` preso (se verra- preso) per gestire sto db...francamente secondo me 330 tabelle sono troppe...mi sembra una cifra esagerata, per questo volevo che qualcuno che ha esperienza come dba mi desse qualche delucidazione...anche perche` ho dei dubbi su chi gestisce sto db visto che non e` manco stato implementato un sistema di svuotamento dellle tabelle in fase di design del database e ci ritroviamo delle tabello con 3.000.000 di record ON - LINE non so se rendo...insomma sono diffidente...cmq si` utlimamente il mostro e` lento..certe query ci mettono tipo 3 ore...

[BugIT]

le tabelle da 3.000.000 di record contengono dati vecchi di 3 anni...

[ilvampiro]

salve , sono uno specialista ORACLE e gestisco diversi database per la mia azienda con decine di clienti, da 12 anni sono partner ORACLE e conosco abbastanza bene la release fino alla 9. Utlizzo application server 10G : MORALE

3.000.000 di record per ORACEL sono veramente una bazzecola (se opportunamente indicizzati) le 330 dipendono ovviamente da come è gestito l'aplicativo (anni fa avevamo realizzaro una gestione contabile aziendale con piu' di 4000 TABELLE di gestione).

A volte invece si fa una 1 tabella per i dati e si esegue lo splitting su multi TABLESPACE per ottimizzare le prestazioni.

E' difficile, senza conoscere le logiche applicative fare un'analisi del sistema. Andrebbe fatta una perizia circostaziata in funzione della quale si potrebbe repertare una ridondanda delle tabelel suddette o meno.

Ciao, e sai bisogno mi trovi quì sul FORUM.

il vampiro

[BugIT]

grazie e mille il vampiro per il chiarimento...francamente ero rimasto perplesso perche` l`unica volta che avevo sentito parlare di 3600 database objects (non tabelle fisiche quindi)era stato per la fusione di tre banche tra cui la Banca di Bergamo...inoltre il nostro e` un vecchio 8i su nt4...e tenere milioni di record inutili mi sembra davvero una cavolata..
..cmq a sto punto mi domando..forse non conviene prendere un dba interno anche perche` non ho idea delle cifre che chiedono...mi immagino siano abbastanza alte...
in realta` fosse per me se ve lo devo dire. butterei tutto e metterei su qualche bsd o linux ...e magari potrei tentare pure con il MySql, anche se dovrei documentarmi che non lo conosco molto...ma non ho mai tempo e sopratutto mi manca un ambiente di test, quindi prevedo che continueremo a farci salassare...anche perche` a furia di implementazioni sto db aumenta di 20 tabelle ogni 3 mesi..anche se ora abbiamo bloccato tutto...

[ilvampiro]

potreste rivolgervi a società , come la mia, che offre invece servizi di "application server " comprensivi di database e sviluppo, in maniera tale da non investire su hardware, macchine personale etc, ma avere solo un collegamento in banda larga verso il service provider in application server.

Io ho decine di clienti in questa soluzione e sono soddisfatti, poichè tutta la parte di gestione del db (backup, ottimizzazione etc) non la vedono nemmeno, 2 qualunque pc si danneggi presso il cliente basta sostiuirlo in tempo reale con uno che abbia una minima connessione as internet (software e dati risiedono, ad esempio nel mio caso sui server centrale posti sulla dorsale in fibra italiana) etc etc etc.

NON ABBANDONARE ORACLE PER NESSUN MOTIVO......

ha il 73% della fetta dei db mondiale : ci sarà un motivo ..... Hai dei tools di sviluppo e delle soluzioni che gli altri ambienti solo lontanamente se li sognano.

ora ti lascio. ciao