Newsgroup: it.comp.software.database
Titolo: [oracle] migrazione da 7 a 9iR2...

C'e' il rischio che la patata bollente di cui al subject mi rimbalzi 
vicino.
Nel frattempo mi sto informando: ho già cercato sui vari OTN, metalink 
ecc. ed ho raggranellato parecchia documentazione tecnica di mamma 
oracle, ma devo dire che "stranamente" ho trovato molte meno 
informazioni di quello che mi aspettavo... in altre parole, mi sembra 
che la facciano troppo facile! Le "voci di corridoio" che si sentono 
parlano di ben altre horror stories...
Anche perchè la doc che ho trovato io si concentra più che altro sul 
discorso della migrazione del *DB*, che in effetti è la cosa che mi 
preoccupa relativamente meno: è sulla portabilità indolore dei package 
PL/SQL che ho seri dubbi.
A parte lo stranoto discorso sul ROWID, c'e' qualcuno che può puntarmi a 
un po' di documentazione anche di terze parti (e quindi NON reticente 
;-)) che dettagli le potenziali bucce di banana di un'operazione del genere?
Anche esperienze personali sono ben accette ;-)
Bye!
-- 
Fabrizio "Hermooz" Ermini

 vicino.
beh io la farei per passi successivi !
e non di botto passare da 7, 3.4 "?", a 9.2
felice_pago
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

il fatto è trovare ancora i cd per installare le varie versioni per gli 
upgrade...
di sicura dalla 7 alla 9r2 non è pensabile, anch'io consiglierei un 
primo step alla 7.3.4, poi 8i e poi 9i
provo a vedere se ho della documentazione e te la giro


 
cmq non utilizzare il tool di migrazione,
ammenocche' non si abbiano i laboratori sul pianerottolo :)


 e non di botto passare da 7, 3.4 "?", a 9.2
Beh, ma a parte l'export/import del DB, fare a passi successivi ci 
costringerebbe, potenzialmente, a rimettere le mani sui package due 
volte anzichè una, no?
-- 
Fabrizio "Hermooz" Ermini

 cmq non utilizzare il tool di migrazione,
Nah, quello è stato scartato a priori :-)
Come dicevo, per il DB si seguirà sicuramente la strada di una 
"ricostruzione" ex novo del DB (tanto cambia anche l'HW, ci sarà una 
finestra temporale in cui avremo entrambi i DB in linea) con 
trasferimento "logico" e non fisico dei dati.
-- 
Fabrizio "Hermooz" Ermini

 trasferimento "logico" e non fisico dei dati.
i problemi escono fouri solo quando non li vorresti,
e se gli analisti/programmatori si sono messi in
quelle situazioni di "frontiera" allora usciranno i bug :(
pero' in linea di massima ,se fai un upgrade per passi successivi,
non dovresti avere problemi, anzi se hai tempo prova a farlo in un
botto solo, pero' non saprei se c'e' la u070304.sql nella 92 :)


 botto solo, pero' non saprei se c'e' la u070304.sql nella 92 :)
Ok. Ci faccio un pensierino...
-- 
Fabrizio "Hermooz" Ermini

 Ecco. Proprio su AIX siamo... :-/
hai presente se sangui...
sono in 3 qui di fronte a me, e vorrebbero/venderanno qualcosa di :
" spettacolare "
:-0
ma le sun,
non le compra piu' nessuno ?


 volte anzichč una, no?
no, perche' la compatibilita' sara' "accettata" per gradi,
quello che cambia, sostanzialmente per i package
e' il catalogo/dizionario , e per ogni versione, dovrebbe
essere garantita verso il basso.
per quanto rigurada il pro*c pro*cobol, non saprei,
ma direi che qui precompilatori, non li hanno mai
piu' toccati dalla versione 1 :)
forse mi sfugge qualcosa, o hai troppo timore,
ma cosa significa "rimettere le mani sui package" ?
non devi mica riscriverli, o devi rifare le logiche ?
se e dico se il package fu scritto nella "norma"
senza incorrere in particolari strutture e' upgradabile,
anzi nelle versioni superiori vengono risolti i bug
di quelle inferiori, e back-portati :)
dai back-portati non lo hai mai sentito :)
dopo fatto girare x070304.sql potari fare la tua
import system/consitent.
anzi prova a procurarti la export direttamente dalla 92.
i passi sono:
1- creazione istanza cr_db.sql
2- creazione struttura risettando la OFA
3- import vedi tu come ottenerlo


 ma cosa significa "rimettere le mani sui package" ?
qualche anno fa ho preso parte ad un upgrade su AIX dalla 6.X.Y alla 8
non maneggai io il db, guardai in quanto c'era il tizio di Oracle
il percorso è stato quelle di fare upgrade alla 7.2.2 e poi alla 7.3.4 
infine alla 8
si sono dovute modificare alcune procedure plsql in quanto la sintassi 
per la declare era leggermente diversa, ma nulla di +
hope this help


certo !
oracle latita in queste cose, e ogni plus e' tanto :)


 di quelle inferiori, e back-portati :)
Quello che temo è proprio che ci sia bisogno di riscrivere parte della 
logica applicativa, a causa di incompatibilità derivanti da soluzioni di 
sviluppo non "a norma". Il fatto è che essendo software di cui non so 
nulla, temo di non poter non fare questa ipotesi...
bye!
-- 
Fabrizio "Hermooz" Ermini

 nulla, temo di non poter non fare questa ipotesi...
conosci murphy ?
allora :
1- metti le mani avanti
2- se sei interno, come sopra
3- sei sei consulente esterno, come sopra al cubo !
in questi casi:
applicazione che continua a girare sul vecchio, mentre va' avanti
la nuova versione, nuova nell'architettura,e a quanto dici nelle logiche,
mi fa' sempre venire a mente un antichissimo adagio:
giammai il pie' veloce achille,
riuscira' a raggiungere la tartaruga !
se il progetto e' piccolo, e TUTTE le persone coinvolte sono toste,
bene, ma se anche una sola persona sgarra, si va' avanti all'infinito !
ps:
murphy non prevede lo sgratt sgratt



noi abbiamo migrato diverse applicazioni dal 7.3 al 9 e non abbiamo 
trovato particolari problemi.
- uno era con i campi char, che ora nelle query rispondono divrsamente 
(mi pare di ricordare qualcosa con gli spazi che prima inseriva da solo, 
e ora non piu)
- i long raw sono obsoleti e dovresti convertirli in blob.
- non servono piu i "pragma" per functions e procedures
altre cose non mi vengono in mente, ma nel giro di una settimana abbiamo 
risolto. ovviamente devi fare un bel test delle eventuiali applicazioni 
client server che ci girano.