It completely revolves around your planned usage of the data in the new
(supported) location.
What other data might reside in the 19c database and if it is already an
existing database with a character set already defined.
Quite often from 8i upwards, when the destination database has a different
character set it is a superset of the character set used in 8i, so at least you
are likely to have a lossless conversion. In provisioning space in the
destination, you will want to calculate a ballpark number if the new
characterset takes up more space. Aiming high is usually cheaper than a close
calculation.
In addition to the fine set of possibilities listed by Mladen, it *may* be
possible to use the copy command under sqlplus or its more modern versions. IF,
for example, the old and new computers are in the same computer room and can be
placed on the same LAN or cabled together, you may be able to configure things
to suck the data directly from one database into the other. I can’t remember
whether there is a security leap in sqlnet between those two versions that
means you would need a “middleman” technology version of sqlnet to talk between
8i and 19c, and it might be useful to do any required character set conversions
on the old machine into the most recent version of Oracle that can be loaded on
your old machine without an OS upgrade that would make 8i dysfunctional, and
then go from there to the new database on linux without any conversions at all.
An interesting side opportunity of the copy command is that IF there is a best
order for the old data, you can do that in the select feeding the copy.
IF you do use copy, you need to pay attention to the longest long you actually
have in each table, so that the parameter for buffering the longs is big enough
to not truncate any of them.
A migration is an opportunity to optimize the way your data is stored compared
to the way it is queried. An enormous *possible* win if a large percentage of
the data is no longer being updated in a way that can lengthen rows is to pack
it tightly in the order most often queried. Oracle projects rows, but it reads
and writes in blocks and quite often old data that is mostly just queried can
be packed much more densely than the defaults.
Good luck. This sounds interesting. IF there was an actual business reason for
delaying the upgrade for so long, that might be an interesting story.
mwf
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Shravan Kumar Kota
Sent: Thursday, November 23, 2023 1:18 PM
To: Mark Davidson
Cc: Oracle-L Freelists
Subject: Re: Oracle 8i to 19c migration
Thanks for the update Mark , as my db is in 8i and do I need to update
character set after import of the data?
Thanks
Skumar
On Thu, Nov 23, 2023, 23:43 Mark Davidson <wdavidsmc@xxxxxxxxx> wrote:
When I had to migrate from 9i to 12c, my only option was export from 9i then
import to 12c. It required downtime but it was safe. I also did a character set
scan on the source which was usacii7 because we also moved to an updated
character set and some data columns needed to be increased. Then I needed to
update the tnsnames.ora file to a newer format.
Mark
On Thu, Nov 23, 2023, 12:40 PM Shravan Kumar Kota <shravankota@xxxxxxxxx> wrote:
Hi all
We have 8i db in hpux server , now we are moving to 19c in Linux server.
Which method will be good and smooth o migrate the data.
Thanks,
Skumar.
