TDMS - Looking for best approach

[Former Member]

Good day.

We're trying to successfully implement TDMS to populate our development system / QA system with 1 year's worth of production data. We are currently using a sandbox with a copy of our dev. system as a playground to validate the data.

Unfortunately, after executing a one year scenario, our Functional Analyst have found the data to be corrupt and unusable. All issues point to 2 major problems:

1) Missing configuration (ex: top level Cost Center S group missing)

2) Missing master data (ex: not all material masters transferred)

We were curious what the proper approach to solving this problem would be?

Here is the approach we took:

1) Copy DEV to a Sandbox.

2) Delete all un-nessassary clients

3) Export main client (100)

4) Import main client (config and user master data only)

5) Execute TDMS Time based reduction for 1 year.

We were curious if we could leverage any of the other package types to potentially resolve our issues.

- Shell Creation: Should this package be executed first?

- Master Data and Customizing: Will the master data from this package be deleted by the Time Based Reduction?

Any help would be greately appreciated.

Thank you,

Charles.

[Former Member]

Hi Charles,

If you could mention which transactions are not working, we can help you out on that.

Regards,

Srila.

[Former Member]

We were able to address this issue by executing systematic TDMS transfers, each time resolving issues identified from the previous load.

Thanks,

Charles.

[Former Member]

Sourabh,

What is the recommended landscape for TDMS. I suggested at our company to to use our Solution Manager 4.0 systems as the TDMS Central/Contol system. Do you have to have a seperate installation for the Central/Control System?

Thanks

Donna

[Former Member]

Hello Donna.

We opted to install TDMS on it's own independent server. This gave us the ability to udpate the TDMS Support Packs withought worying about breaking SolMan.

As your TDMS Support Packs might require different BASIS and/or ABAP levels, upgrading these on SolMan could potentially break SolMan due to dependencies.

Charles.

[Former Member]

Charles,

Thank you for your response. In our shop we have the SAP application servers on AIX with a DB2 database on the mainframe. We are considering purchasing TDMS and I have been asked to research the best landscape for the product. The TDMS Master guide recommends exactly what you recommended, to put the Central/Control component on its own server. Also the Master guide point me to the Operations Guide to assist in hardware configuration however the document is not on the service market place where they advise to find it. (service.sap.com/customdev-tdms). Could you tell me the hardware requirements and platforms you use for your TDMS Central/control server?

Thanks,

Donna

[Former Member]

Hello Donna.

We're a Windows shop and installed the central TDMS on an HP DL580, 4 CPU @ 2.83 GH with 8GB of RAM and 120 GB of local disk. This box was quite overpowered. Your transfer rates will depend on the speed of you Sender and Reciever systems.

[Former Member]

Hi,

SAP TDMS runs on a system infrastructure that contains

A sender system (client) with productive data ( may be a copy or mirror)

A central system (client) ( at least WAS 620 )

A control system (client)

A receiver system (client) ( the non-production system to be filled)

The current release (TDMS 2006) supports SAP releases R/3 4.6C, R/3 4.7 (110 and 200), ECC

4.0, ECC 5.0 and ECC 6.0.

minimum hardware recommendations for the TDMS server => Separate server with 4,000 SAPS (u2245 4 CPU, 4 GB RAM, 20 GB DB)

SAP TDMS runs on all platforms that are supported by WebAS

SAP TDMS can run on any server on which WebAS 6.20 or higher is installed.

For more details please refer to note 890797.

Regards,

Srila.

[sourabhshah]

Hello,

TDMS basically transfers the client dependant data and assumes that the repositories of the sender(PRD) and the receiver(QA) systems are same.Repository means that all client independant objects and cross client customizing be the same.

The TDTIM scenario is a time based reduction scenario which transfers the data based on a given period.This package also transfers the master & customizing data along with the sliced transaction data.This package can be executed independantly with out running the TDMDC scenario.

The TDMDC scenario transfers the Master data & Customizing only and not the transaction data.

The TDSHL or shell creation creates an empty repository and makes the system ready for the TDTIM or TDMDC scenarios.However after the shell creation it is necessary that the TDTIM or TDMDC scenario is run to obtain consistancy.

In your case, the material master should have been transferred as a part of the TDTIM/TDMDC package.Check if the conversion object for Material Master table is transferred.If not the trouble shooting provided for TDMS should help you to transfer a conversion object which has failed during migration.

Regards,

Sourabh

[Former Member]

HI ,

Since the config is not proper in your scenario, I feel ur approach is right, in the way u have copied DEV to a sandbox.Perform a POC in ur sandbox(u can take another copy of a client) and make sure all the config is done properly.Your Masters should be accurate so that you can make sure all ur transaction data is usable.

Once you are convinced that ur Scenario works fine , you can proceed .

How TDMS Works : The TDMS is free system architecture and it acts like a middleman. You have the source( the production server) and the destination (the test server) It just copies a slice out of the

production database, stores it temporarily in the production

system itself. It is then copied from the temporary tables to the

test server. Your production processes are not affected at all. The most significant feature of TDMS is that it supports a multi-client environment.

Thanks,

Felix

Edited by: Felix on Apr 16, 2008 4:59 AM