Is this too much of data validtion?

Question

HI, All:
I am doing one_to_one data migration from SQLSERVER to Oracle dev database. No thing fancy involved, no function, no calculation, no where clause, no join etc. All I do is using an ETL tool to move the data as is from Sqlserver to Oracle. Lots of tables, most of them have less them hundred records. And ETL tool is very good, tells you how many is in source table and how many rows get into target table. or errors if there is any. Usually, when there is error, data won't get loaded into target table.
After I finish migration, I just did some count(*), and randomly check some records and done with it.
But my manager asks me to do following for each table:
Summing up some of the numeric fields on each side to see if the totals match
Counting occurrences of some specific dates on date columns
Performing count(distinct()) on some fields to compare values
Perform a min/max on some fields and compare values
Perform some of the above on tables that are normally joined
Other things that may be specific to the table and columns that have been brought over
I really don't think that's necessary. It's a simple data move with a commercial ETL tool, no any manipulation in between. If there is no error, a quick check is enough. I don't see any possibility that data may get messed up during the migration that requires such detailed validation. I am thinking by his over-cautiousness, I should do all this thorough checking even after each export and import.....
Any one agree with me?

Answer 1

Personally I think it's a stupid idea. It's only going to show you any differences that you happen to spot.
If there is some reason to suspect that the ETL tool might not be transactionally sound and insufficiently instrumented to flag up any potential issues then I'd suggest it was a poor choice of tool in the first place!
Personally I would used the native distributed heterogeneous database support provided by default for free with Oracle.
Now, since there is data type mapping involved in migrating from SQL Server to Oracle, and since there is clearly no management buy in to the integrity of the tool, I'd think it was now necessary (if this database is of any importance) to check for any and all discrepancies.
To do this just create database link from Oracle to SQL Server and write some infrastructure that will show you all differences (e.g. MINUS views)
This will be trivial to write with the small exception that you must formally decide how to map from (say) an Oracle date to a SQL Server date/SQL Server Text columns to Oracle (Varchar2/CLOBs), how string trimming is expected etc.
It's very easy to do since it is iterative, and you will see each difference dissolve away.
This will be a worth while exercise.
At the end you can show your boss living proof that there are 100% no un-known differences, and then at the same time compile a list of all known differences (datatype maps) so that these can be used in impact analysis of the application, so that changes can be made along with the obviously required change in the transaction model of the applications.