SMIGR_CREATE_DDL ran for wrong DB type

[Former Member]

Hello,

We are migrating a system with DB2 on z/OS to DB2 on AIX Unix. In the source system, for step 'Generate DDL statements' I selected 'Target Database' DB2 when I should have selected DB6. The program generated SQL files which I placed in the sapinst installation directory of the export. We are now thinking of reruning SMIGR_CREATE_DDL with 'Target Database' DB6 and using these SQL files for the import. My question is, do I have to redo the export with the 'DB6' SQL files placed in the export installation directory?

[Former Member]

We are now thinking of reruning SMIGR_CREATE_DDL with 'Target Database' DB6 and using these SQL files for the import.  My question is, do I have to redo the export with the 'DB6' SQL files placed in the export installation directory?

Hello,

What I understand is, you can place newly generated .SQL files (DB6 option) directly into <EXPORT_DIR>/ABAP/DB/DB6 (the export dump which you are going to use during IMPORT) now during IMPORT procedure (just before execution of import on the target)

Could you confirm where the old .SQL files generated are situated right now in old EXPORT dump (after execution of EXPORT) ? Are they in the folder <export_dir>/ABAP/DB/DB2 or in DB6 ?

Thanks

[Former Member]

Hello,

They are in /ABAP/DB/DB6 folder.

[Former Member]

Exactly what I thought ! That is because of the fact that when you did put those .SQL files in sapinst_dir during EXPORT execution then SAPinst program moved them from sapinst_dir to /ABAP/DB/DB6 folder because you chose the target DB as 'DB6' in SAPinst EXPORT screen.

So if you want to create re-run SMIGR_CREATE_DDL with 'DB6' option 'now' then the .SQL files generated can be directly placed into /ABAP/DB/DB6 folder of 'old EXPORT' dump before you begin with the IMPORT process.

I think these files are not relevant for the EXPORT procedure but needed actually for the IMPORT, BUT in the correct directory.

The only thing we should be conscious about is, Source system should not have been updated with any change after execution of that old EXPORT yet. If old EXPORT execution was very old w.r.t date and major changes might have occurred in the source system till today then better to execute the fresh EXPORT, otherwise not necessary.

Thanks

[Former Member]

Thank you DatabaseSAP,

That is because of the fact that when you did put those .SQL files in sapinst_dir during EXPORT execution then SAPinst program moved them from sapinst_dir to /ABAP/DB/DB6 folder because you chose the target DB as 'DB6' in SAPinst EXPORT screen.

There was no 'DB6' option in SAPinst Export screen. These are the options given for "Target Database Type":

Oracle

MaxDB

MS SQL Server

IBM DB2 UDB for Unix and Windows

IBM DB2 for z/OS

IBM DB2 for i5/OS

I chose IBM DB2 UDB for Unix and Windows.

[Former Member]

I believe the DB Specific objects do carry data in them.

I recommend to re-generate the SMIGR_CREATE_DDL and restart the DB Export. I';m concerned about the potential data load issues during the import.

SAP recommends to perform this step before the export.

Don't try to experiment on this step.

Thanks

Srikanth M

[Former Member]

I would be concered if the SQL files were used in the export to generate export objects. Then there would be an incompatiblility with the export that was conducted and the re-generation of DDL statements with type 'DB6.' Otherwise I would not be concerned. I guess the question is what impact does the DDL Statement generation have on the export itself?

[Former Member]

From your DEV or QAS System try to generate the TABART.SQL by checking the target db as DB2 and DB6. And compare the Files using a text editor.

Reply your findings here.

Thanks

Srikanth M

[Former Member]

Will do. May take me a few days but will post my findings here.

[Former Member]

> 
> I chose IBM DB2 UDB for Unix and Windows.

IBM DB2 UDB for Unix and Windows has short name as 'DB6'.

Thanks

[Former Member]

I would be concered if the SQL files were used in the export to generate export objects.  Then there would be an incompatiblility with the export that was conducted and the re-generation of DDL statements with type 'DB6.'  Otherwise I would not be concerned.  I guess the question is what impact does the DDL Statement generation have on the export itself?

Read the Note 888210 - NW 7.**: System copy (supplementary note) --> 3. Tasks after the export

Thanks

[sunny_pahuja2]

Hi,

This report is to collect all non-database objects. So, you have to run this report before export procedure otherwise you can face problem during import.

DB6 stands for IBM DB2 for Unix and windows, so don't get confuse with DB6 name. So, generate this file again before export and re-run export.

Thanks

Sunny

[Former Member]

We looked at the SQL files generated by the DDL statements run (type 'DB2') and counted about 2,884 tables. I have a list of these tables and am wondering if these tables aren't updated since the export is it feasible to re-generate the DDL statements with type 'DB6'' and use the SQL files from this generation. Is a re-export necessary if no changes have occured to these tables?

[Former Member]

Just analyzed the tables and found out that no structural changes to the tables have been made since the export. Looks to me as though the case is strong for DDL statement regeneration over the re-export..

[Former Member]

Looks like you are going to test the IMPORT soon.

Thanks

[former_member189725]

The <TABART>.SQL files generated by running the report SMIGR_CREATE_DDL contain DDL statements compatible for the target database type. These files are only read by R3load during the import. During the export , the sapinst just places these files in the export directory under /<DIR>/ABAP/DB/DB6 (for DB2 LUW). Hence you do not need to run the export if you have wrongly run the report. Only run the report to generate the files again, but make sure the database is in the same state when the export started and the system is still not in use,else any structural change might change the DDL and will be inconsistent with the exported data. Once these files are generated , pleace them manually under /<DIR>/ABAP/DB/DB6 . Start the import. Should resolve the problem.

[Former Member]

Hi,

The <TABART>.SQL are generated by the program means there are relevant tables existing in the system. I would recommend to rerun the export with the correct SQL files. If no files were generated then you could have ignored this.

Regards,

Srikishan