TDMS for BI - shell creation and SMIGR_CREATE_DDL

[Former Member]

If a homogeneous system copy of a BI system is done, it's necessary to run the job SMIGR_CREATE_DDL because depending on what database is used, special SQL scripts for tables must be used (concerning primary keys).

How does that integrate into a shell creation? Is the shell creation process aware of those scripts? I mean, it's theoretically possible that the SQL scripts has a table that is excluded from being transferred?

Markus

[Former Member · Accepted solution]

Hi Markus

Shell creation of BI is aware of this and these scripts dont affect the shell process. It is required that the job SMIGR_CREATE_DDL is run as a standard system copy process for BI system the same needs to be followed for Shell process also, but it doesnt cause any known issue.

Although the script may have table which is excluded from transfer but this wont cause any effect as we do need the full structure (along with primary key information) on the receiver system also for excluded tables.

This has been tested both internally and also at customer site and is known to work fine.

In case you have any specific issue that you have encountered because of this please write back to us.

Thanks and regards,

Pankaj.

[Former Member · Accepted solution]

Markus and Pankaj:

I have created a SHELL (BW) using Markus' way as listed below.

Because Markus did not mention that SMIGR_CREATE_DDL should be run at the beginning, so I did not run it.

So how to determine in the created shell what is missing?

We do have partitioned tables and bitmap indexes.

Thanks!

Here is the way provided by Markus:

I basically do shell creation as follows:

- install the latest system copy tools (R3load, R3ldctl, R3szchk, libdb<database>slib.dll)

- create an installation directory and give full permissions to <sid>adm and SAPService<SID>

- create a directory for export location and give full permissions to <sid>adm and SAPService<SID>

- open a cmd.exe as <SID>adm, step to the installation directory and execute "R3ldctl -l R3ldctl.log -p ." (note the "dot" which means actual directory)

- in parallel start the client export of client 000 in source system using SCC8 (profile SAP_ALL) and note the file names you get in the last dialog window

- when R3ldctl is finished give permissions to SAPService<SID> for all files in the installation directory

- proceed with TDMS

- when you are at the point to start the system copy start sapinst, choose system copy and select start migration monitor manually (VERY important!)

- sapinst will run R3ldctl, R3szchk and then prompts you to start migration monitor

- step to your normal installation directory (c:\program files\sapinst_instdir....), open export_monitor_cmd.properties and adapt the file. The import thing is, that you need to point to YOUR DDL<DB>.TPL file you create in step 4 (in my list here)

- start export_monitor.cmd and export the system

- proceed with TDMS to adapt the database sizes (DBSIZE.XML)

Import:

- if you have an already installed system uninstall it

- start sapinst normally, choose system copy and point to the export you created

- install the system normally (as a new installation)

- if you want to make sure the import works as the export choose "start migration monitor manually"

- if sapinst stops and requests you to start migration monitor copy the kernel from source system to target system

- configure import_monitor_cmd.properties and start migmon

- logon in client 000, start transaction STMS and create a domain (basically only a transport profile will be created)

- start program BTCTRNS1 (this will suspend all jobs from the source system but not delete them)

- copy the files from the client copy to TRANSDIR/cofiles and TRANSDIR/data and import them to client 000 (either use STMS or use command line tp)

- adapt profile parameters (RZ10)

- run SGEN

- invalidate connections in SM59 that point to other production systems

- finished

- to re-enable all the jobs run BTCTRNS2, however, I'd do this only if you're sure you have invalidated RFCs and or sending jobs (e. g. from SCOT)

[markus_doehr2 · Accepted solution]

> So how to determine in the created shell what is missing?

> We do have partitioned tables and bitmap indexes.

This program creates SQL scripts (e. g. DFACT.SQL) which need to be put into the export directory under ABAP/DB/<DATABASE>.

R3load picks them up during the import and creates the table with those SQL statements instead of using the DDL<DB.TPL template.

Depending on which database you use it's important to check if there are updates for this program (notes) by using notes search with SMIGR_CREATE_DDL and your database component (BC-DB-<DATABASE>). This is especially true if you have MS-SQL.

I'm on my way writing an article about the shell creation process, once finished, I'll upload to the wiki.

Markus