RE: Oracle 8i to 19c migration

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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] 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_at_gmail.com> 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_at_gmail.com> 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.

--
http://www.freelists.org/webpage/oracle-l