Newsgroup: it.comp.software.database
Titolo: template 9i su 10g

Sapete se e' possibile utilizzare la funzione creazione template su 9i
per creare un database da 10g?
visto che vorrei includere anche i datafiles per clonare il db, sono
files specifici per la versione di db immagino...


qui non ho capito,
ma penso che per far leggere i datafile
prodotti con la versione 9i , 9.2 ,
non ci sia alcun problema
ho capito !
te hai i file di creazione del db in versione 9i, meglio 9.2
e vorresti portare l'istanza sotto 10g ?
sotto $ORACLE_HOME/rdbms/admin
ci sono alcuni file di up09xxxxx.sql
servono per rinfrescare il catalogo ecc . . .
pero in questo momento non mi viene la procedura,
per startare l'istanza con i datafile della 9i :(
io l'ho fatto :)
fra 8174 e 9i, ergo si puo' fare :)
felice_pago
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 
Ciao Felice,
solo un appunto.
se il parametro compatibility e' stato settato ad una versione piu' alta 
rispetto a quella verso cui vuoi migrare allora non c'e' nulla da fare o 
quasi.
Mentre per la domanda di
-- 
Fabrizio Magni
fabrizi...@mycontinent.com
replace mycontinent with europe


Ciao,
nonostante il dbca possa creare template contenenti datafile questi non 
fa effettivamente il cloning del databse di partenza.
Per quello ti serve RMAN.
Semplicemente dovrai stare attento ai parametri dell'init e a qualche 
tablespace inutile per la 9i come la SYSAUX.



 ?


 
Non direttamente.
Ti faccio un esempio pratico. Usero' un pfile (/tmp/compatible.ora) 
esterno e non il mio pfile per ragioni di semplicita' nel risistemare 
successivamente l'ambinte.
Parto da un DB 10.1.0.3 per x86-64 in cui, per default il parametero e':
compatible='10.1.0.2.0'.
Eseguo questa modifica:
#*.compatible='10.1.0.2.0'
*.compatible='9.2.0.0.0'
nel pfile e quindi cerco di aprire il DB:
SQL> startup pfile='/tmp/compatible.ora'
ORACLE instance started.
Total System Global Area 1493172224 bytes
Fixed Size                  1321872 bytes
Variable Size             384029808 bytes
Database Buffers         1107296256 bytes
Redo Buffers                 524288 bytes
ORA-00201: controlfile version 10.1.0.2.0 incompatible with ORACLE version
9.2.0.0.0
ORA-00202: controlfile: '/u02/app/oracle/oradata/TEST4K/control01.ctl'
Opss, oracle si rifiuta di aprirlo...
Quello che posso fare?
Far partire la sola istanza senza aprire i control file:
SQL> startup nomount pfile='/tmp/compatible.ora'
ORACLE instance started.
Total System Global Area 1493172224 bytes
Fixed Size                  1321872 bytes
Variable Size             384029808 bytes
Database Buffers         1107296256 bytes
Redo Buffers                 524288 bytes


 Redo Buffers                 524288 bytes
pero' possso ricrearmi i controlfile !
e far sentire la variazione :)
00201, 00000, "controlfile version %s incompatible with ORACLE version %s"
// *Cause:  The controlfile was created by incompatible software.
// *Action: Either restart with a compatible software release or use
//          CREATE CONTROLFILE to create a new controlfile that is
//          compatible with this release.
in fondo non esistono paramteri 
che non si possono modificare,
occorre solo applicare un wa
pero' rimane il fatto che non abbiamo ancora startato i datafile della 9i
con la 10g :(
felice_pago
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
Questo caso e' piu' facile.
I datafile di una 9i sono facilmente apribili da una istanza di versione 
successiva.
Ovviamente un DB 10g richiedera' la creazione di una SYSAUX e, per la 
system, di usaer cataloghi corretti.


Beh, ho provato a reimportare il template e non funziona.
Mi sembra di avere capito che se setto il parametro compatibility a
9.2.0.0.0 posso copiarmi semplicemente i datafiles.
La procedura consigliata da Oracle e' di usare il migration assistant
(ed e' quello che sto cercando di fare ora) ma questo mi richiede di
installare 9i e 10g sulla stessa macchina, giusto?

No, mi riferivo ai templates che si possono creare con il database
configuration assistant. Se oltre alle strutture ci metto anche i dati
dovrebbe clonare il database, quello che ho fatto e' copiarmi il
template da una 9i ad una 10g per ricrearlo di la' ma non funziona

 
Il migration assistance serve per passare da una versione vecchia ad una 
piu' recente (quella del motore da cui fai partire il tool).
Non e' usabile per i downgrade (o almeno io non l'ho mai visto 
funzionare per quello scopo).
Posso chiederti quel'e' il tuo scopo finale?
Potrebbe risultare piu' facile darti una mano.
Ciao


 funzionare per quello scopo).
ma non deve portare dei df dalla 9i alla 10 g ?


 
Quello che ho capito io e' che deve portare un tamplate (comprensivo di 
datafile) da una 10g a una 9i...
Meglio sarebbe conoscere lo scopo finale e dare un'alternativa.
Il dbca serve per semplificare la vita ma l'OP sta per rendersela 
moooolto piu' difficile.


sto passando da 9i a 10g
pero' ho pure cambiato server (91 e 10g sono su due macchine diverse)
ora ho reinstallato la 9i dove avevo installato la 10g, sto cercando di
ricostruire un database 9i per aggiornarlo in seguito (ed oltretutto ho
il solito problema con le tabelle versionate, se non disabilito il
versioning i datafiles non sono buoni)


Ok. Andiamo per gradi.
Se vuoi usare il dbua devi avere il motore 10g sul sistema dove hai i 
datafile della 9i (dbua non permette operazioni in remoto).
Quindi le scelte che hai sono:
1. sposti il DB 9i sulla macchina su cui vuoi fare l'upgrade e lanci il 
dbua della 10g (non quello della 9i!);
2. ti installi la 10g sulla macchina della 9i e sposti tutto 
successivamente.
3. oppure crei un database da zero e fai export import dei dati.
dbca, con i template, permette solo di clonare la struttura del database 
(tablespace, datafile, ecc) e non il suo contenuto.
Lo puoi usare al massimo per la soluzione 3.
Le soluzioni 1 e 2 sono probabilmente le piu' veloci mentre la 3 e' la 
piu' flessibile perche' ti permette di cambiare struttura e layout del 
tuo database.
Dipende molto da quanto sei confidente su operazioni di questo tipo.
In ogni caso l'operazione non e' particolarmente complessa.
Nel caso ti dovessi arenare fai pure un fischio.
Ciao


Basta che copio i datafiles? Non c'e' bisogno di instalalrsi il server
9i? (va beh che tanto ormai l'ho fatto)
Se si' dove li metto? nella ORACLE_DATA della 10g?


Hem, in quale caso?
il primo o secondo che ti ho descritto?
In ogni caso se usi normali datafile l'alberatura dovra' essere la 
medesima, pena l'impossibilita' di aprire il database (a meno che, anche 
in questo caso, tu non ti ricre i datafile).
Procedura che ti consiglio se vuoi usare il dbua:
- installazione del motore 10g su macchina 9i,
- backup!!!!!!! (magari anche del controlfile su trace),
- uso del dbua (10g) sul database esistente (9i),
- ricreazione alberatura filesystem su macchina finale (alberatura 
uguale alla macchhina di partenza),
- copia di datafile, redolog, controlfile, spfile/pfile (l'ultimo 
potresti anche editarlo successivamente),
- termina le configurazioni di: passwordfile, tnsnames.ora, 
listener.ora, possibili hs, oratab, ecc.
Ora, se hai fatto tutto correttamente puoi tentare di riaprirti 
l'istanza sulla macchina di destinazione (su cui devi avere gia' il 
motore 10g).


Ricomincio da capo...
come faresti te a installare oracle10g su una nuova macchina, facendo
la copia di un database 9i su un'altra macchina che restera' comunque
operativo (e senza modificare nulla sulla macchina con la 9i, intendo
non posso andare ad installare la 10g sulla vecchia macchina)


il metodo piu' semplice,
e quello di crearti il db sulla 10 dopo aver installato il prodotto, dbca ?
una export system/manager full=y consistent=y dalla 9i
e una import sulla 10g.
diciamo che una import di 10 g ti puo' durare 10 ore :)
a spanne 1h=1Gb
in questo modo la import dalla 10 si creera', se possibile,
anche i datafile pari pari al server 9i.
io mi rifarei la struttura di directory come si trova
sul server della 9, cosi' vai al sicuro.
e non pensi piu' a niente,
hai solo da lanciare il logico sul fisico :)


 
Sconsiglio.
Una import dovebbe occuparsi solo della parte logica.
Un DBA dovrebbe decidere da solo dove mettere i data file (meglio se 
seguendo l'OFA).
Tra l'altro l'OP magari vuole flessibilita' maggiore o anche andare su ASM.
Buona serata.



Installazione della 10g sul server di destinazione.
Uso di dbca per la creazione di un template collegandomi al db con il 
server 9i (usa il dbca 10g puntando all'istanza remota).
creazione del db10g sul server di destinazione (decidi tu cosa usare: 
ASM, datafile, OMF),
export della 9i
import nella 10g
fai rigirare i cataloghi 10g e ricompila tutti gli oggetti invalidi.
Gioco fatto.


 
Piccola aggiunta: ad una import non faccio nemmeno creare le tablespace! 
cosa succederebbe se arrivassero da un database con delle DMT?
O anche da delle LMT con parametri di storage completamente folli?
E se ho un DB su cui si presenta un bug causato da ASSM e la import 
prevede tablespace con questa gestione dei segmenti?
Meglio sapere cosa sta facendo un'operazione invasiva come una import e 
restringerne il suo campo d'azione il piu' possibile (alla parte logica, 
appunto).
Ma se un DBA si sente maggiormente confidente... non ho nulla contro la 
pratica... se fatta su sistemi non miei!!!!
