migrating from oracle 7.3.3 to 8.1.7 question
michael.cooke
this is a 2fold operation moving 7.3.3 to a new server then in a few weeks
time migrating to 8.1.7. I am testing the procedure at present and have both
oracle versions on the same server in different home directories. The 7.3.3
dbase is up and running. I have tried a test migration using the gui
migration tool in 8.1.7 and have a listener problem in tha it can't find it.
my question is is there a step by step migration guide covering each item in
turn and given that the dbase in question is only 4GB what sort of timescale
would be usual for this migration as i believe that in simple terms it is
the file pointers that are updated along with a number of internal
datadictionary changes. p.s. I did an export from 7.3 to 8.1.7 which worked
problem was it took about 6 hrs (I hope the migration is shorter.).
thanks for any help
Mick
Sybrand Bakker
"michael.cooke" <michae...@tinyworld.co.uk> wrote in message
news:3ccaf...@mk-nntp-1.news.uk.worldonline.com...
There is a separate migration manual, please read it.
> would be usual for this migration as i believe that in simple terms it is
> the file pointers that are updated along with a number of internal
> datadictionary changes. p.s. I did an export from 7.3 to 8.1.7 which
worked
> problem was it took about 6 hrs (I hope the migration is shorter.).
You would wish it was a simple as that. As of 8.0 the format of the rowid
changed. You need to know whether any of your applications make *explicit*
use of the rowid, and *explicitly* expect it to be in the V7 format.
Any rowids used by Oracle behind the scenes are dealt with automatically.
As a result during migration the old rowids remain unchanged. Individuals
rows will be converted as soon as your app uses them.
That is why, and also for purposes of database reorganisation, you are
advised to use exp/imp. As imp is basically a series of inserts, the rowid
is converted to the new format everywhere, and your database is reorganized
at the same time.
Also, migrating (which means in situ migration, you don't have 2 databases,
so if the migration bombs out, you need to restore) might not be possible at
all from 7.3.3 to 8.1.7, as the version difference is too big.
Hth
--
Sybrand Bakker
Senior Oracle DBA
to reply remove '-verwijderdit' from my e-mail address
Ban Spam
news:3ccaf...@mk-nntp-1.news.uk.worldonline.com:
> Oracle 7.3.3 on NT4 sp6a to 8.1.7 on NT4 sp6a
> this is a 2fold operation moving 7.3.3 to a new server then in a few
> weeks time migrating to 8.1.7. I am testing the procedure at present
> and have both oracle versions on the same server in different home
> directories. The 7.3.3 dbase is up and running. I have tried a test
> migration using the gui migration tool in 8.1.7 and have a listener
> problem in tha it can't find it.
-----------------^^------------^^
Please be a little more vauge next time. ;-)
Why Not?
What were the exact error message(s)?
> My question is is there a step by step
> migration guide covering each item in turn and given that the dbase in
> question is only 4GB what sort of timescale would be usual for this
Earlier today I migrated a 120GB DB from V7.3.4.5 to V9.0.1.3
in less than 30 minutes.
For my migration I had the V7.3.4.5 DB up with NO listener.
I set my enviroment variables to be correct for a V9.0.1.3 DB
and simply invoked "odma".
HTH & YMMV
HAND!
Anton Buijs
You can count 3 or 4 times as long for the import.
Time needed for Migration is not directly related to the db size, more to
the size of the dictionary.
With your 8.1.7 software there should be a documentation CD, containing all
generic documentation in HTML and PDF format. In the group "Oracle8i server
and SQL*Plus" you will find the book "Oracle8i Migration". Chapter 4 tells
you all about the migration from Oracle7 using the Migration Utility.
Check the NT specific release notes too for Windows specific actions (like
the services that start the database).
I know the Migration Utility is not that much reliable. It may work for you.
If possible I would use full export/import.
Beside the problems with Migration Utility another argument is that the
rowid format has changed. That means every block of all database files will
be converted to Oracle8i format the first time it is touched, not during the
Migration. I have no experience with it but I wonder what the impact is on
performance, specially the first days/weeks after migration.
Some export/import advices:
1. make sure system and rollback tablespaces are large enough. System is
much bigger in V8. The Migration book tells you about it.
2. import without indexes, use import indexfile=... to build a sql script
that can create the indexes later (will not work for indexes build by
constraints). The total time for doing it in 2 steps is much more shorter
than letting import build all indexes (this is experience, if someone could
explain me why?)
3. during import and index build, have a speciall (larger) value for
init.ora parameter sort_area_size (like 2M or so) and make
initial=next=sort_area_size+1 oracle block in the temporary tablespace to
optimize the sort that's part of index creation.
4. look in the 7.3.3 database what objects you created as SYS (against
Oracles advice) and what grants are given by SYS to others (you can't always
prevent this; not standard things like grants to public or system). This is
because the SYS schema is no part of the export (not a bug, that's by design
because it contains the administration of the database which should not be
imported to another database for obvious reasons).
michael.cooke <michae...@tinyworld.co.uk> schreef in berichtnieuws
3ccaf...@mk-nntp-1.news.uk.worldonline.com...