A fairly standard minimum is the number of rows in each user table and the sum
of the values of numeric columns in each table. The CDP exam circa 1982 called
these “control totals.”
A more aggressive verification is to also pipe the text fields through a hasher
and compare the hash values.
A reverse migration of all the data back to the original machine (even one user
table at a time if space is a problem) with a full row by row, column by column
comparison is comprehensive, but the cost versus the benefit does need to be
considered. (This can also be done between OCI and the existing machine, but
usually the network latency doing things row by row makes a back load of the
data more performant.)
Good luck,
mwf
PS: I presume your OCI means Oracle Cloud Infrastructure, not Oracle Call
Interface
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Eriovaldo Andrietta
Sent: Sunday, April 14, 2024 8:28 AM
To: ORACLE-L
Subject: Migration validation to OCI
Hello,
An exadata database server onpremise will be migrated to OCI As Is to the same
Oracle version (12.x).
I would like to know what else would have to be validated at OCI to ensure that
the migration was successful.
I thought I would check:
- dba_users
- dba_objects (and each object type separately)
- dba_tab_privs
- dba_sys_privs
- dba_roles
- dba_synonym
- dba_extents (in order to check the volumn)
- count the number of lines for each table, or to check at the dba_tables
numrows if the statistics are updated.
I guess that the number of lines migrated are enough to accept to content of
the table
The goal is to check only in the context of objects and not configuration
(v$parameters, tablespaces, resource manager and other structures).
What else could be validated?
Regards
Eriovaldo
