unexpected constraint modification on import

Hello
I have spent several hours searching for similar issues, with some similar scenarios but nothing close enough. So I hope this is a worthy question!
I'm writing a migration package from 7.3.4 to 9.2. To allow for porting issues, some procedures and application code/forms etc have been modifed.(aix 4 to 5 also). The application schemas have had no structural changes though. So all index/table/constraint defs are identical for application schemas.

The strategy I've adopted is to purely import the table data from a full export taken at 7.3.4. This is performed for each schema/user by:
- creating the schema from scratch using create object DML
appropriately and installing all required proceders/triggers etc.(using incremental historical dbase upg scripts)
- make a note of all disabled constraints, jic. (Can happen due to how
the initial target schema is created as the sum of historical dbase upg scripts from day 1)
- disable all triggers for schema

• set all schema constraints to disabled
• truncate all tables in schema.
• import with "ignore=y constraints=n commit=y indexes=n" then
• enable constraints validate x2 ( error check on run 2)
• enable triggers
• rebuild indexes At this stage I'm assuming the jobs done for that schema.

However,
when this is run live, I will be validating the structure of the src dbase by performing table structure and constraint health checks. While testing though I've been making assumptions on the the state of the src data. For the most part all has worked okay.

Specific question : When I was running through the constraint enabling  after import today, all was reported as OK, athough when I inspected manually and compared the user_constraints before and after import. Afterwards, 4 constraints had been modifed from nuallable=Y to =N. They weren't SYS_ constraints, they were application generated, but I was relying on no part of the import procedure above modifying/adding constraints during imp. IS THIS TRUE? Could they have been modified as a result of the "imp". The output from imp makes no mention of constraint changes.

More generally, not withstanding the possibility of the constraint glitch being a serious problem, does this strategy sound plausable? I want to avoid a straight user import as I would like to ensure that any historical manual dbase mods are removed and the accuracy of each schema in each dbase is known. The migration will be perfomed on 600 independant database servers and "bringing them back into line" is a requisite of the operation.

I'd appreciate any discussion.

Rob Received on Mon Dec 15 2003 - 16:47:46 CST