Is there a good way to verify if a database schema is correct after an upgrade or migration?

Question

We have customers who are upgrading from one database version to another (Oracle 9i to Oracle 10g or 11g to be specific). In one case, a customer exported the old database and imported it into the new one, but for some reason the indexes and constraints didn't get created. They may have done this on purpose to speed up the import process, but we're still looking into the reason why.

The real question is, is there a simple way that we can verify that the structure of the database is complete after the import? Is there some sort of checksum that we can do on the structure? We realize that we could do a bunch of queries to see if all the tables, indexes, aliases, views, sequences, etc. exist, but this would probably be difficult to write and maintain.

Update

Thanks for the answers suggesting commercial and/or GUI tools to use, but we really need something free that we could package with our product. It also has to be command line or script driven so our customers can run it in any environment (unix, linux, windows).

Answer 1

If you are willing to spend some, DBDiff is an efficient utility that does exactly what you need.

http://www.dkgas.com/oradbdiff.htm

Answer 2

Hi there,

In SQL DEVELOPER (the free Oracle utility) there is a Database Schema Differences feature. It's worth to try it.

Hope it helps.

SQL Developer - download

Roni.

Answer 3

I wouldn't write the check script, I'd write a program to generate the check script from a particular version of the database. Just go though the metatdata and record what's there and write it to a file, then compare the values in that file against the values in the customer's database. This won't work so well if you use system-generated names for your constraints, but it is probably enough to just verify that things are there. Dropping indexes and constraints is pretty common when migrating a database, so you might not even need to check too much; if two or three things are missing, then it's not unreasonable to assume they all are. You might also want to write a script that drops all the constraints and indexes and re-creates them, and just have your customers run that as a post-migration step. Just be sure you drop everything by name, so you don't delete any custom indexes your customer might have created.

Answer 4

Presuming a single schema, something like this - dump USER_OBJECTS into a table before migration.

 CREATE TABLE SAVED_USER_OBJECTS AS SELECT * FROM USER_OBJECTS

Then to validate after your migration

 SELECT object_type, object_name FROM SAVED_USER_OBJECTS
 MINUS
 SELECT object_type, object_name FROM USER_OBJECTS

One issue is if you have intentionally dropped objects between versions you will also need to delete the from SAVED_USER_OBJECTS. Also this will not pick up if the wrong version of objects exist.

If you have multiple schemas, then the same thing is required for each schema OR use ALL_OBJECTS and extract/compare for the relevant user schemas.

You could also do a hash/checksum on object_type||object_name for the whole schema (save before/compare after) but the cost of calculation wouldn't be that different from comparing the two tables on indexes.

Answer 5

Javid,

Take a look at SchemaCrawler for Oracle - it is a free, command-line tool that is designed to do what you are looking for. SchemaCrawler produces a text file with all of database schema objects. This text output is designed to be both human-readable, as well as diff-able against similar output from another server.

Sualeh.