Prerequisites for Client Export/Import

[Former Member]

Hi all Gurus,

I have planned for a client export/import coming this weekend, before i start the process i just wanted to know the prerequisites for the export/import process.

And i have few questions on the same

1) DO we have to lock all the users on the target and source clients

2) If NO , will there not be any data inconsistency

3) Which is better Client Import/Export or Remote Client copy thru scc9

4) Which will take more time Client Import/export or Remote Client Copy

We are on 2 sys landscape (DEV and PRD)

Target Client = 009 (DEV)

Source Client= 009 (PRD)

ECC 6.0

Ms SQL 2005

Win 2003 server.

Thanks and regards

Hunky

[Former Member]

Hi all Gurus,

Can you help me how to find the size of the client before the TEST RUN is performed.

I am planning to go for client export/import rather than full system copy or Remote client copy for a very simple reason that the client is not HUGE nor BIG enough.

And Do we have to perform any actions after the Export./import process..

Please guide me...

Thanks a million to all for your valuable inputs..

Will surely award points..

Regards

Hunkydude

[markus_doehr2]

Execute the client copy as test run - this will give you the size of the client.

Make sure, the dictionary of both systems are identical (same support package level, same workbench transports in both systems) - otherwise your import in the target will fail.

Markus

[Former Member]

HI Markus,

The TEST RUN was completed with Dictonary errors as u mentioned, bu i am unsure WHY this happened.

The support packs are same, but i have no clue how to check if the workbench bench transports are same on both the systems.

What can i do if there are workbench transport differences...

Can i follow the directions in the SAP NOTE NO: 665134 to over come the DDIC errors.

In the results it shows that many tables are missing both related to transactions and data.

Can you help me run a successful CLIENT COPY that is scheduled for SATURDAY, and once if this fails this time it is not possible to take downtime for another 4 weeks.

Waiting to hear

Thanks a million in advance

Regards

Hunky

[markus_doehr2]

Well... you problem is common - that´s why system copies are much easier to handle.

You can find out the corresponding transport for the tables missing using transaction SE03 - you will need to enter the tables one by one and import the transport request to the target system.

Markus

[Former Member]

Hello All,

Thats not entirely accurate, you can do a system copy of a dual stack system, this is documented in the homogeneous system copy guide.

To clarify what I think Markus was trying to say, you cannot do a system copy of a dual stack system using a backup / restore of the database on its own.

For Dual Stack you have two options

- A complete export of the System using R3load and Jload.

- A combination of a database Backup and an export of the Java Stack. This is to accomodate the part of the java which exists in the filesystem.

Depending on the state of your system you may or may not be able to use sapinst to take an export of the Java Stack and use this in combination with your Database backup.

Regards,

David

[markus_doehr2]

Sorry - you´re right. I wanted to say: You can´t do client copies from dual stack systems to dual stack systems.

Markus

[Former Member]

if your system is ABAP stuck then system copy (db copy) base on backup/restore is prefered.

if your system is dual stuck then I would go for remote client copy

Nahum

[markus_doehr2]

If it´s dual stack you CAN´T do system copies. The Java part won´t be copied and thus the target system will be inconsistent. In that can the only thing you can do is a complete systemcopy.

Markus

[markus_doehr2]

If you don´t lock all the users there may be inconsistencies.

To choose between "remote copy" and "import/export" it would be good to know your client size. Bigger clients are copied better using import/export, if the client is VERY big, it´s better to do a full system copy.

Markus