The Oracle Conversion, day 14, continues and it is not as exciting as I envisioned.  Oh, don’t get me wrong, the end result, Global Domination for SQL Server, will be the ends that justify the means.  But until then, migrate data, check data, clean data, remigrate date, check data, clean data, time migration, repair migration process, check data, clean data, remigrate, ad nauseam.  Rinse, lather, repeat.

Oh, this is not my first rodeo, I’ve converted many projects before but never have I converted Oracle before.  Granted, the SQL Server Migration Assistant for Oracle has made life much easier but at the same time it has made life much more difficult. 

It is a quirky tool that is very temperamental.  We had to restart it before we did a successive migration or it would fail we are guessing because it possibly caches information from the previous migration process and the MSDN blog wasn’t much help.  We also had to hit apply on every setting change or it would revert some of them back to the original value. 

In addition, we would have to convert schema sometimes four or five times before it would synchronize them properly to SQL Server, saying that the SQL execution failed.  That answer gives me a huge amount of troubleshooting possibilities.  When it works, it was a great time saver but had we known the quirkiness we probably could have scripted it all out and saved a lot of headaches. 

Doesn’t sound like a big deal? 

Well when you have some big tables and it takes eight hours to convert the schema and you try synchronizing and it fails and you have to convert the schema again, you watch the progress bar for many hours.  Oh yeah, I left out the fact that the vendor is responsible for the migration contractually, so I guess ultimately they should have scripted it out.  Enjoy!