IMP/EXP accross platforms: What will be missing?

Hello

Going from 8.1.7 (Solaris) to 9.2.0.4 (Linux Redhat AS2.1) I will have to do exp/imp. One instance, about 230 GB (size of DB files). My plan:

1. Do an export from the source with rows=no and freeze DB structure
2. Convert the exported dump file into executable sql scripts
3. Edit the scripts (removing storage params, etc.)
4. Generate a DB creation script with Version 9 (target environment)
5. Run the DB creation script from step 4, so creating a standard DB
6. Delete spfile, tune new DB init parameters
7. Test rman+Veritas setup (backup/restore) in new environment
8. Precreate tablespaces manually
9. Run the scripts from step 3 to precreate objects in DB from step 5 10)Do a 2nd export (full, rows=y, compress=n) into a pipe, set DB RO 11)Immediately start an import from pipe (fromuser= touser=) on target 12)Gather statistics of new DB 13)Shutdown source DB 14)Edit central tnsnames.ora for all clients, announce new platform 15)Drop example users (HR, SH, etc) cascade 16)Repeat step 7

Done.

In praxis: Not done (being realistic). I will test this of course, the goal being a reliable procedure and a minimal downtime. But what really concerns me is the kind of unexpected problems that I won't be prepared to cope with due to my lack of experience (well, I have already transferred a number of DBs this way, at times something fails and has to be fixed manually).

These are the things that seem prone to failure. Please comment or put your ideas:

1. DB Links. We have some.
2. Synonyms (no full import done...)
3. Roles
4. Object and system privileges
5. Sequences (?)
6. Constraints, triggers (?)
7. Resource Plans (yeah, they save admin's life during night jobs)
8. rdbms/admin things that were run for years in the old DB (views, packages etc.). How to find which should be rerun? One I know: Statspack :-)
9. Scheduled jobs (!!)
10. Client software. When to update? About 40 PCs.
11. ..(what else?)..

Many questions here. How to freeze a DB structure? (I am not a developer, I don't trust the developers). How do I do a quick "sanity" check of the new DB? (Something could go wrong and remain unnoticed). How can I transfer jobs? Resource plans? Are sequences an issue? Should I install the new version of the clients beforehand? (I think so, but will there be any limitation until the new DB version is up and running?). Since the DB will have a new name, will DB links still be valid? Where can I find an exact list of example users? (I don't mean OUTLN, PERFSTAT, etc.)-

Init parameters to adapt, some specific to V 9 or with changed default:

DB_CHECKSUM (false)
DB_FILE_MULTIBLOCK_READ_COUNT
PGA_AGGREGATE_TARGET
OPTIMIZER_INDEX_COST_ADJ (about 30)
OPTIMIZER_INDEX_CACHING (perhaps 50)
PARALLELITY (don't remember exactly). Four CPUs, lots of disks. START_ARCHIVING (or similar; true, of course). DISK_ASYNCH_IO (true)
QUERY_REWRITE (true)
CURSOR_CACHING (force)
NUMBER_OF_PROCESSES
JOB_QUEUE_PROCESSES (1 or 2)
..
and some other memory parameters. I am afraid that something will break. Until now, I have always done imp/exp in the same platform, same version.

You could help me minimize Murphy's chances!

Thanks a lot
Rick Denoire
(who will spend Christmas/New Year on duty). Received on Sun Nov 02 2003 - 15:14:40 CST