Newsgroup: it.lavoro.informatica
Titolo: [Aiuto!] Migrare Oracle in SQL Server

Ciao a tutti!
Sto prendendo in mano una applicazione di un cliente. Ho buttato giů il 
progetto di massima, ma ho ancora un problema.
L'applicativo si basa su un Oracle in versione - credo - 6, oltre tutto 
non licenziata.
Visto che il cliente utilizza un MSDE2000 per altre applicazioni, 
pensavo di migrare la base dati in Oracle in modo da eliminarlo 
completamente. Se su MSDE non si puň (devo ultimare le verifiche), 
pensavo di usare PostgreSQL.
Non č che qualcuno di voi abbia mai fatto una cosa del genere e mi possa 
dare una mano (magari in zona da me, a Vicenza provincia, e ovviamente 
retribuita)?
Ho scaricato il corposo guideline di Microsoft, ma ho qualche dubbio...
Grazie in anticipo.
PS. Oggi vado a vedere se si riescono a recuperare le password 
amministratore di Oracle. Credo non si possa fare molto, altrimenti...
-- 
Ciao!
Luca



Sinceramente non ho capito bene se vuoi migrare "da" oracle a MS o civeversa
In generale se sei su oracle scaricati il "toad" light che e' free.
Da quello vai su tutte le tabelle indici eccetera e se "smanetti un po'
troverai semplicissimo ottenere gli script "sql.
Li metti tutti assieme in un file di estensione xxx.sql
A questo punto traduci i dialetti, che mi pare differiscono prevalentemente
per il terminatore ( una barra mi parew )
Poi vai sul "profiler" di sql server e importi il file xxx.sql e il giochino
dovrebbe essere fatto.
Viceversa eventualemtne e' lo stesso.
In "MS SQL" smanetti un po' e ottieni gli script sql. Ce la fai col tasto
destro ( come semprte in MS) direttamente dalle tabelle o se ricordo bene
addirittura dal db.
Poi Editi il file generato e applichi la traduzione dialettale.
Infine vai in SQL+ ( che e' un tool console di oracle) oppure nel solito
ottimo TOAD ( la *rana* per capirci) copi e incolli tutto lo script e lo
esegui.
A questo punto hai clonato le strutture
Ora tocca ai dati.
In MS SQL Server c'e' un certo DTS che e' un tool integrato.
Se dinuovo ti metti *smanettare* scoprirai che ti crei facilmente 2 fonti
dati con in mezzo una "freaccia colorata" col mouse destro sulla freccia
colorata ci sara' una tabella di mappatura da un db all'altro.
Schiacci *play* , vedi degli ingranaggi che girano :-) , e tadaaa, il
giochino e' fatto di nuovo e i dati sono passati.
N
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 non licenziata.
da utente sys/system/dba :
select * from v$instance;
altrimenti se hai perso le password di cui sopra,
lanci come utente oracle:
$>svrmgrl
svrmgrl>connect internal
svrmgrl>select * from v$instance;
gia' che sei in svrmgrl, POTRESTI cambiare qualche password, alla bisogna :)
ed ottieni la versione :)
poi si vede
felice_pago


 giochino e' fatto di nuovo e i dati sono passati.
Ho presente. Conosco decentemente SQL Server. Il fatto è che:
a) non conosco assolutamente Oracle, e non riesco a trovare 
documentazione di versioni cosi' vecchie.
b) già devo capire e modificare l'applicazione, avessi trovato qualcuno 
che lo faceva per me avrei volentieri messo il suo costo nel progetto.
Vabbè, vedo che riesco a fare poi vi allineo!
-- 
Ciao!
Luca

 Inviato via 
http://arianna.libero.it/usenet/
-- 
Ciao!
Luca

 non licenziata.
Che tipo di applicativo?
Ci sono trigger/stored procedure da convertire?
Il problema sarà, con ogni probabilità, dover rimettere mani
sull'applicativo. Io farei una valutazione, perchè in queste operazioni
rischi davvero di perdere la strada per tornare a casa... migrare i dati
da un db all'altro è proprio l'ultimo dei problemi.
PS: davvero la versione 6? Avrà più di 10 anni...
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 retribuita)?
La cosa dipende molto dalle possibilità che hai di collegarti al DB Oracle. 
Non conosco affatto la versione 6, ma presumo abbia dei driver ODBC o 
(meglio) OLE DB... in tal caso, puoi usare tranquillamente i DTS di SQL 
Server per importare il tutto, usando Oracle come origine dati e il tuo DB 
di riferimento come destinazione.
Personalmente, uso i DTS anche quando il DB di destinazione *non* è SQL 
Server... quegli arnesi sono potentissimi, possono spostare dati da 
qualunque origine a qualunque destinazione, basta che ci sia un provider 
dati disponibile.
Unico neo: così facendo non copi stored procedure (ovvio) e viste (meno 
ovvio). Per le viste puoi risolvere copiandoti le istruzioni SQL che le 
generano, ma se il tuo DB ha procedure di qualche tipo dovrai riscrivertele 
a seconda del DB di destinazione.
Se dovessi poi avere problemi con i dialetti SQL, puoi sempre usare i DTS 
per esportare tabelle e dati in un formato intermedio (Access, CSV, quello 
che vuoi) e poi importarli dove devono andare.
Con questo trucchetto ho spostato un database da 3 o 4 GB di roba su una 
connession lentissima, esportandolo in testo e zippandolo: sono venuti fuori 
5 MB ;-)
Se ti serve una mano, fammi un fischio in mailbox.
Massimo

 pensavo di usare PostgreSQL.
tieni conto che c'č anche un bel oracle express gratuito

 tieni conto che c'è anche un bel oracle express gratuito
Prendo nota. Pero' non volevo usare troppi DBMS, e visto che hanno già 
un MSDE che gira e che la quantità di dati che viene trattata è 
ampiamente entro le limitazioni del DBMS Microsoft, pensavo di unire il 
tutto - e di consentire loro di spegnere definitivamente quella 
macchina, utilizzata solo per Oracle.
-- 
Ciao!
Luca

Luca Menegotto ha scritto:

vedi tu.
Io fossi in te metterei su l'oracle xe a meno che tu non voglia farti 
pagare proprio per migrare l'applicazione da oracle a m$.

ti avevo scritto una pappardella con tutti i dettagli ma non ha
inviato, riassumo:
concordo con massimo sui DTS come strumento per fare la migrazione.
Accorgimento1 : controlla bene lo schema per vedere se l'oracle usa
attributi non implementati in maniera comaptibile in MS (sequence)
accorgimento2: benche molto  potenti i DTS spesso falliscono il
bulkinsert quindi lavora su copie di tabelle temporanee per
eventualmente  lanciarli senza dover rifare dei restore.
tabella originale ---> copia della tabella originale ---> DTS ------>
tabella temporanea del nuovo db ----> verifica -----> rinomina tabella
temporanea in tabella definitiva
riscrivi stored procedure e funzioni eventuali e hai finito.
Il lavoro è avvastanza facile, ma il problema è che devi essere
certosino in tutte le fasi della migrazione.
Occupati molto dell'analisi dello schema e prendi decisioni reversibili
(nel caso vogliano tornare su un oracle)
non mi viene in mente nient'altro ma prima avevo scritto molto di più
....... va beh per ora  accontentati di questo.