OSDB signal files Mig; import monitor hangs early on SAPNTAB.STR

[Former Member]

Has anyone out there worked with signal file controlled OSDB migrations?

We’re having an issue on the target that the import_monitor (aka migmon) hangs (not errors in the log) after these lines:

INFO: 2013-03-07 11:55:19

Version table 'SVERS' is found in STR file '/oracle/XXX/O2O/EXPORT/DATA/SAPNTAB.STR' from package 'SAPNTAB'.

INFO: 2013-03-07 11:55:19

Data conversion tables 'DDNTF,DDNTF_CONV_UC,DDNTT,DDNTT_CONV_UC' are found in STR file '/oracle/XXX/O2O/EXPORT/DATA/SAPNTAB.STR' from package 'SAPNTAB'.

So

• the export is running and files followed by signal files are being transferred
• All STR files are pre-copied over.
• If I comment out all but 2 or 3 STR files (in DATA) then the import starts running without issue for these files, but with all STR files there (as I would expect for full migration) it finds SAPNTAB.STR and before anything really kicks off the monitor hangs at this point

Any ideas?

[Former Member · Accepted solution]

Hi Jamie,

As per the system copy guide, there shouldn't be any conversion of tables happening.

Usually we will delete all the contents in the following tables before start of the migration.

DDNTF

DDNTF_CONV_UC

DDNTT

DDNTT_CONV_UC

I would suggest you to open the corresponding package TSK file and set the status as ign and continue with the import.

Please refer the system copy guide for more information.

Thanks and Regards,

Vimal

[Former Member · Accepted solution]

You can see the tables in conversion using the tcode ICNV... Please check in source system whether these tables are there ..

If yes, please proceed as suggested above.

[Former Member · Accepted solution]

Thanks for your responses Maria -

select tabname from <schema>.ddntf where tabname like 'QCM%';

finds nothing.

There should be no conversion here I think (already all unicode).

I think the problem is rather with the signal files migration logic, however I sincerely appreciate the notes on SAPNTAB and DDNTF*

I will update all here once this is solved

[former_member188883 · Accepted solution]

Hi Jamie,

You may use updated migmon.SAR files along with latest R3Load, R3szchk and R3TA files.

Regards,

Deepak Kori

[Former Member · Accepted solution]

I did update them - but in fact the answer was this:

I tweaked order_by.tpl to reorder packages to optimise the migration but did NOT put SAPNTAB 1st. This should always be the case.

Now it's working.

Cheers all

[former_member188883]

Hi Jamie,

In the OS/DB Migration approach using Signal files, the import starts with SAPNTAB.STR and ends with SAPVIEW.STR.

The import may not be hanging. Basically it might be waiting for STR files as well as it subsequent datafiles to initiate the import. Please check on availability of data files on the target system.

You may check in import_monitor.log for mode details on current operation.

Regards,

Deepak Kori

[Former Member]

Hi Deepak - that is good to know. Do you know why the signal files method specifically starts with SAPNTAB? Because actually I found that I re-ran again after extra signal files were across and this time I did NOT see SAPNTAB in the import log... weird.

As this is a conversion table and I expect no conversion I do find it strange that this is occurring.

NB It is hanging - in fact if I comment out all but say 4 test STR files (in DATA) then it starts importing them... but if I uncomment ALL the STR files then this occurs and it hangs. Strange!

I left it going a while and watched the ORACLE alert log, import log, console log, file system usage, inode usage, etc. - nothing happening.

I HAVE found that the kernels are not on the same patch level on source v target so I will update that and re-run.