Client Export/Archive and re-import

[Former Member]

Hi

We have a QA client where we perform our certification testing (we are a medical company so require certification and sign off), we are performing a European rollout accross various regions, we need to update the data in the QA verification client before the next region rollout, so I am looking at doing a SAP_ALL Copy from Prod to the QA client, before that, the project wants to archive/keep the current QA cerification client to retain a copy as is, as we may have to show our verification testing in the future, the client refresh from prod will lose this testing scenarios.

The current QA client is quite large as its a copy from production from last year, so I would rather not copy it to another client and have it stored there long term on QA (we will be doing this again for the next region i'm sure), so I am looking to do a client export to OS files and retain these on a different file server, then if we need the client for any verification auditing in the future (upto 7 years) I can re-import it, I presume when I reimport it the Data dictionary will need to be the same, my concern is as development continues, the dictionary will change and could cause a problem with trying to re-import the client back to QA, particularly after applying support pack stacks in the future which we do every 6 months to keep uptodate.

Has anyone re-imported a client from an export taken a few years earlier ? has anyone got a better solution ? only other option I have considered is a full DB backup to a tape we retain for 7 years and then a restore onto a test server/instance if auditing inspection is required.

We are running ECC 5 on Windows 2003/MS SQL Server 2000.

Thanks for any help.

[Former Member · Accepted solution]

Ecnirp,

That's quite a good idea actually, however, for the time period you expect to keep this client export, I see one issue. Remember that with client copies/exports, the source and target systems need to be on the same release, and even the same patch levels. One question I'd ask is, over the next say 7 years, will you apply a support pack to the system? Will you even upgrade to ECC 6.0? If so, the client export you took may not work when you load it into whatever the current system is.

A backup would work, and so would a SAPINST export of the system. Agreed these are both system and not client level solutions, but unless you will not change your system over the next 7 years, I can't offer you a good answer on how to solve this versioning problem.

Hope this helps.

Tim

[Former Member]

Thanks for the explanation Tim, I will take a look at the SAPINST export, I've installed NW04 using SAPINST but not had much chance to investigate it further, so it looks like the backup/restore or SAPINST option is the way to go.

Sounds like the client export is a no, it cannot be relied upon to recreate the client via import due to SP stacks and possible future upgrades over the time scale (7 years) I am talking.

I'll just have to make sure I keep the ECC 5 installation disks safe incase I need to recreate the client once we're on ECC 6 or 7 by then !!!!

[Former Member]

Thanks for the replys so far

Ruchit - if a developer removes a field or a Z**** table in the data dictionary in the future, I thought the import would perform a dictionary comparison and fail that the table/field is required as data was in the table when the export took place, the same process as remote comparison before a remote client copy.

Tim - We will be applying Support Pack stacks to the system, otherwise SAP don't help with OSS notes and just say apply the SP !!! we normally apply them, just before a new region go-live, as we test the SP as part of the new region/regression testing, normally every 6-12 months we go upto the latest SP stack depending on region size, so we will be quickly out of line on Support packs.

How does the SAPINST export work? I'm quite new to NetWeaver, i'm more used to the 4.6* releases at my previous company, thats why I considered a DB and Kernel backup at the time, then a fresh install and restore.

Paul.

[Former Member]

Hi Ecnrip,

You have a very valid point. I agree with you on that count.

Regards.

Ruchit.

[Former Member]

Ecnirp,

That's cool. Your installation master CD has an option to 'export the data from the database. This is essentially, the same toolset SAP uses to create the exports stamped onto the CDs of your installation kit. Essentially, you'd be copying the contents of your database into a series of flat files that SAPINST can use to install subsequent systems. SAPINST has a few advanteages over a straight Oracle backup/restore:

1) More compact - you can get up to (at least I've seen) an 8 to 1 compression ratio. So your 800GB database would become 100GB in an export format.

2) Platform independent. Say you went from a UNIX/Oracle environment today to a Windows/SQL environment 3 years down the road. You could still use this export to re-create the system on the SQL platform.

3) SID independence. By using a SAPINST export, you can use the export to create new systems with different SIDs, without the need for extensive BDLS runs. The installation program will take care of this for you.

All of these topics are covered under OS/DB migration. These toolsets are much more advances in the WAS releases, and is a really excellen toolset to add to your options. There are several guides and notes on it. It'll take some ersearch on your side, but I beleive you'll see how it fits in to your toolset as well as when you'd use this option over others.

Hope this has helped.

Cheers,

Tim

[Former Member]

Hello ecnrip,

I think by data dictionary you mean only the ABAP repository part. Please note than client copy affect customising,master data and transactional data (SAP_ALL profile) but doesnot change repository. So in this case you dont need to worry. However you customising will get changed.

Regards.

Ruchit.