Newsgroup: it.comp.software.database
Titolo: Migrare da Access a Oracle

Ciao a tutti, ho la necessita' di migrare da Access a Oracle. Il database in
questione e' grandino, contiene circa 20 tabelle e la tabella + grande
arriva anche a 30000 record. Qualcuno conoscce un modo per poter trasferire
le tabelle da Access a Oracle in modo se non semplice almeno lineare?
Grazie in anticipo per la risposta.



 lineare?
"trasferire" le tabelle cosi' come sono e' una 'azzata mostruosa.
Ti conviene pianificare bene cio' che vuoi fare e rivedere l'intero
database in modo da sfruttare al meglio cio' che Oracle ti 
fornisce (Stored Procedure, Functions, tabelle partizionate,
trigger etc).
Una volta fatto questo e creata la struttura su Oracle, puoi
farti un programmello che piglia i dati da Access e li trasferisce
su Oracle con opportuna "manipolazione".
Davide
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ha scritto nel messaggio
news:a551p0$lvi$1...@newsreader.mailgate.org...


 Grazie in anticipo per la risposta.


 Davide
grazie e ciao, a.
--
--
andrea....@tin.it
www.sundaysw.com

 praticamente è enorme, che sò saranno un paio di mega !
non avrà mai visto un db 'grandino'...
:-)

 non avrà mai visto un db 'grandino'...
Insomma, perche' impuntarsi su dei termini? Per Access 86 Mb secondo me e'
"grandino" perche' con InterBase, Oracle, o altri DBMS le prestazioni
aumentano di 10 volte, e per questi DBMS "seri" 86Mb sono una bazzeccola.
Va bene ora?
Vogliamo anche puntare sul termine "DBMS seri"?

 su Oracle con opportuna "manipolazione".
Ok, magari con ADO o con JDBC... il punto e' che, almeno in fase prototipale
volevo evitare questo...

 cos'e' una tabella partizionata ?
Una tabella in cui i singoli record vengono memorizzati in un
diverso "blocco" a seconda di cosa contengono, in questo modo
fare una query che interessa un singolo "blocco" e' molto piu'
veloce, inoltre i singoli "blocchi" possono essere cancellati
in un colpo solo, rendendo la costruzione/manutenzione degli
indici molto, ma molto piu' veloce. Tipico esempio sono le
tabelle in cui i dati sono suddivisi per data e che vengono
sempre manipolati per data. Se crei una tabella partizionata le
informazioni sono suddivise su disco in modo piu' efficiente.


 ha scritto nel messaggio
news:a551p0$lvi$1...@newsreader.mailgate.org...


 86Mb
Neanche una tabella di 86 mb può essere considerata grossa :-))))
Ciao Matteo

 wrote in message
news:a55ah2$qu0$1...@newsreader.mailgate.org...

allora sei recidivo !
ho per le mani una copia di un db access, solo una parte, 400 MB,
se un db oracle se è sotto i 2-3 Gb vuol dire che chi ha 
disegnato l'architettura non capisce più di tanto !
mai sentito parlare di Tb ?
non ti si stà prendendo in giro, magari queste informazioni
potrebbero servirti anche per il lavoro, e solo portarti
a conoscenza del mondo dei DB, per cui il consiglio è 
resta su access finchè le cifre sono quelle, 400 Mb,
se hai problemi di performance con un decimo di quello
che costa oracle compri un pIV con 2 Gb di ram e vedi 
le pippe che ti fà !
ciao


 Davide
86 Mb di dbf !
se si dà corda a qualcuno non sai mai a che scopo 
possa utilizzarla !


 
Hai piu' strade:
1) scegliere un tool di conversione (io userei ERWIN, ma e' molto costoso)
2) scrivere un po' di codice che analizza la struttura delle tabelle access 
e crea il DDL per oracle (e meno difficile di quanto sembri)
3) Analizzare su carta il problema (20 tabelle non sono tante) creare le 
tabelle in Oracle e dopo averle collegate via ODBC in access popolarle con 
query di accodamento.
L'accortezza maggiore va posta nella conversione dei tipi dato soprattutto 
se hai usato dei contatori.
francesco
P.S.
Oracle puo' essere utlizzato anche per piccole basi dati, quello che lo fa 
scegliere sono altri argomenti come affidabilita', sicurezza, gestione di 
un alto numero di utenti contemporanei etc, etc.....

...che vuoi farci Francesco, qui sono tutti grandi esperti... e non
capiscono che un database non si misura in base alle dimensioni, ma a come è
stato realizzato.
Sarei curioso di sapere quanti hanno lavorato su un progetto che comportasse
più di 5Gb di database... E non parlo di mettersi li a fare la tesina
universitaria, parlo di andare da un cliente e gestire i suoi 5Gb di dati.
Ultima nota, la più triste, come invece di aiutare, chi non ha di meglio da
fare, perda il suo tempo a prendere in giro.
Segui il consiglio di Mela e usa il migration tool di Oracle... lasciando
perdere queste bestie.
Al consiglio di Mela ne aggiungo un altro: importa si i dati e le tabelle su
Oracle, poi creati un altro schema e inizia a riprogettare il tutto in modo
da ottimizzarlo per le tue necessità: i dati saranno sempre facilmente
reperibili, così come le strutture delle tabelle e tu potrai ricreare il
tutto da zero usando le molteplici possibilità che ti offre Oracle.
Se hai bisogno di una consulenza chiedi ancora... e ignora chi, con tutta
probabilità, non sa far altro che sfottere.
Saluti,
Ender Motion