cancel
Showing results for 
Search instead for 
Did you mean: 

OSDB migration; import migmon trying to access wrong STR file for split table

Former Member
0 Kudos

We have an OSDB migration running.

We have an issue where tableA is split into 15 pieces.

tableA-1

tableA-2

etc.

13 of those pieces have imported on the target without issue

but for two of the pieces we get an error like this:

ERROR: 2013-03-27 11:00:57 com.sap.inst.migmon.LoadTask run

Loading of 'tableA-2' import package is interrupted with exception.

java.io.FileNotFoundException: DATA/tableA-2.STR

        at com.sap.inst.migmon.LoadTask.buildTaskFileCommand(LoadTask.java:463)

        at com.sap.inst.migmon.LoadTask.processPackage(LoadTask.java:267)

        at com.sap.inst.migmon.LoadTask.run(LoadTask.java:195)

        at java.lang.Thread.run(Thread.java:676)

        at com.sap.inst.lib.util.ThreadDispatcher$ThreadWrapper.run(ThreadDispatcher.java:113)

This error is especially strange as there is NO tableA-2.STR file. When a table is split like this you get *WHR files, but you keep a single whole table STR file still - i.e. tableA.STR

So then has anyone any idea how migmon generates the STR file name/location?

Or has anyone seen a similar issue before?

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Jamie,

  I would suggest that you can spilt the tables again  ..

Secondly, open the export_state.properties file, and make the status as table=0 and start the export again.

It should go through.

Thanks and Regards,

Vimal

Former Member
0 Kudos

I'm open to trying this but then I still wonder what could cause this... but I'll report my findings from re-running

Former Member
0 Kudos

Hi Jamie,

Are you going to do a full export  or only to that table?

Thanks and Regards,

VImal

Former Member
0 Kudos

Blimey just that table! The export of some of the larger packages takes over 24 hours. I've re-split it and re-exported it - it's in transit to the target server now - I'll let you know how import goes.

NB We ran a mock of this migration already previously and did NOT hit this issue... though there was a server issue last night and we're not sure if that could be related.

Former Member
0 Kudos

That could also be the reason

I believe R3load was killled during the R3load was creating the STR Files.

Not sure... Just a guess.

Glad your issue is fixed.

You can close this thread if your query is answered.

🙂

Former Member
0 Kudos

No not fixed

Re-ran all steps from split to export to import

It's still trying to use the wrong STR format file - it's like it's treating these pieces of a split table packages as a normal package. Very weird - and the same 2 of 13 pieces that acts like this.....

Former Member
0 Kudos

Did you try with latest R3* files ???

Former Member
0 Kudos

Yes they have been updated recently -- also we previously have run a mock migration of this same system and found no issue. Since then we copied the source DB to a temp server to run another test and now get this issue. But all other split tables are OK and all other packages from this table are OK. We have opened a SAP message - I'll be very interested to get to the bottom of this!

Answers (1)

Answers (1)

Former Member
0 Kudos

To update this.

It's clear that parts 2 and 4 (of 13 split parts of tableA) are NOT being picked up as parts of a split table by migmon for some reason.

The *cmd *TSK and *log files for all the other 11 parts all have this added to the name before each suffix: "__TPI"

e.g. tableA-5__TPI.TSK

Whereas parts 2 and 4 do NOT get generated this way.

e.g. tableA-2.TSK

Has anyone seen this stange behaviour before?

ashish_vikas
Active Contributor
0 Kudos

I think i have seen this when one of my collegue was performing Migrations.. seems to a Bug.

I think. you are getting this error for for that package while generaing .TSK file for import. What you can try now is.. try to generate .TSK file manually and then generate .CMD file. (you can use similar commands what you have for other 11-12 runs of this and will be available in .LOG file). Then try to run R3load by changing - to 0 in importmonitor file. If this also do not work, try to run R3load import manually.

Let me know if this works.

For finding correct problem, I will suggest a OSS to SAP.

best regards

ashish

Former Member
0 Kudos

Thanks ashish this is helpful and I'll let you know

ashish_vikas
Active Contributor
0 Kudos

@Jamie : did u managed this and raised a OSS ??