Duration of a homogeneous system copy

[Former Member]

Hi together,

I am hosting SAP on IBM iSeries, so I have little idea from running SAP on Oracle.

My question is, how long do you need to do a homogeneous system copy from a prod system to an existing QA system.

I only want to know the technical time from the time you are stopping the QA system until SAP QA is running again for administering for SAP-Basis people.

I don't want to know the time for the work what is to do before and after the technical part.

Please write the amount of hours and the database size and if you want OS and SAN.

Thank you very much.

Kind regards,

Carsten Schulz

[volker_borowski2 · Accepted solution]

<br>

Well, I'll throw in a couple of thoughts:<br>

<br>

<br>

ABAP only, using the "unsupported" way of exchanging the DB underneath an<br>

already installed QAS System with a restored backup of production, you'll need:<br>

<br>

- The time for the restore / recovery of your backup (this is the biggest block of runtime)<br>

<br>

plus some 2 hours if the procedure is established, means you have <br>

- you'll do all the postprocessing (esp. BDLS) with db-logging disabled<br>

- you have your SQL-Scripts to do the DB-Postprocessings ready (several TRUNCATES / "DELETE from ...")<br>

- you have all permissions, userids and passwords required<br>

<br>

- your create INDEX Scripts utilizing parallel Query for the Support of BDLS <br>

-> this requires SQL Monitoring when you do the BDLS next time to identify the fields<br>

of tables which will benefit from additional indexes. Create the indexes directly on DB level,<br>

use parallel DDL and NOLOGGING if you db supports it. Drop theses again after BDLS is done.<br>

BDLS is one of the ugliest beasts to calculate. We have it down to 35 Mnutes from 16 hours<br>

now after all relevant tables have been identified. To create the indexes beforehand requires ~40 Minutes.<br>

This might vary depending on wich tables require the updates in your system.<br>

And the number of clients/logical Systems that require BDLS.<br>

<br>

- All keys / licensescripts and so on ready for access and no need to wait for the internet to get them<br>

- An excellent checklist for what needs to be done inside your system to full fill all points mentioned<br>

in the systemcopy guide. Pay special attention to interfaces to other systems.<br>

<br>

As for the backup/restore procedure:<br>

<br>

On a 1 GBit/s LAN, you might get a theoretical throughput of 6 GB / min (taking the byte for 10 Bits<br>

for ease of calculation) If you reach 4GB/min your Ok, if you are slower, check your I/O, <br>

i.e. utilize more processes.<br>

<br>

If you use Oracle, consider a try utilizing device_type "disk_copy". In this case the backup<br>

copies the files directly to the new target location (Which might be an NFS mount)<br>

Usually it is slower to access via NFS, but if you do the backup over night, you save the restore time<br>

next morning, as your restore is already in place.<br>

But you are in trouble if the backup fails and NFS might be rotten slow.<br>

<br>

If you have SAN and a bunch of CPUs, do a backup with SW-Compress and several slaves to a SAN disk instead.<br>

For restore switch the disk to the other system and do the restore utilizing all CPU you have got.<br>

8-12 sessions should be able to restore a compressed backup of a 200GB DB in ~ one hour.<br>

<br>

<br>

<br>

ABAP only (the supported way, utilizing SAPINST and BACKUP/RESTORE)<br>

Takes an hour longer for handling SAPINST<br>

Ensure to exchange the kernel archives from the CD location with a recent patch version<br>

and backup your old SAP-profiles, because SAPINST is disruptive to them.<br>

<br>

<br>

<br>

ABAP+JAVA or JAVA only (Supported Copy via SAPINST utilizing backup/restore):<br>

This gets more Complicated. Esp. because for you JAVA Instance need to be set up in a new way.<br>

This requires an JAVA Export to be taken on the sourcesystem and SAPINST to be run to set up your<br>

Targetsystem.<br>

Export of JAVA only (no DB-Export, you can do the DB via BACKUP/RESTORE also) takes roughly an hour<br>

on recent hardware (may be two).<br>

Running SAPINST for a Systemcopy with "DB-specific method (restore) takes a bit longer to do the <br>

java Import, and you'll need all the stuff (the two hours mentioned above) in addition.<br>

I did not so many of theses yet, but I'll estimate, it might be possible to do it in 4-6 hours plus restore time.<br>

<br>

<br>

<br>

<br>

An excellent scheduling for the unsuported ABAP procedure would be:<br>

<br>

18:00 Evening<br>

shutdown QAS and delete DB datafiles on QAS<br>

Start online Backup of PRD (i.e. "brbackup -d disk_copy" directly to NFS-Mounted QAS-SAPDATA Home)<br>

<br>

go home, get some sleep<br>

<br>

06:00 Morning (may be backup is still running, depending on Size/latency/NFS performance)<br>

Do logswitch on PRD and start to move the redologs required for recover over to QAS<br>

<br>

07:30 I.E. Backup is finished, start getting remaining redologs<br>

force logswitch and get final log -> QAS will have production Timestamp of this logfile<br>

<br>

07:45 Generate Script to CREATE CONTROLFILE ( 5-15 Min depending on manual interaction)<br>

<br>

08:00 Startup nomount the QAS DB <br>

CREATE the CONTROLFILES (NOARCHIVELOG !)<br>

Recover the DB up to 07:30+last-log (check alert-log if the db utilizes parallel recovery, <br>

-> if not adjust parameters)<br>

OPEN RESETLOGS the copied QAS DB<br>

Run Scripts to do actions according to Systemcopy Postprocessing<br>

Run Scripts to CREATE OPS$ User<br>

Run sapdba_role <br>

Adjust DB-Passwords<br>

<br>

08:30 Start SAP<br>

While SAP starting<br>

- Run Oradict_stats and system Stats<br>

- Run Scripts to create Indexes for BDLS<br>

<br>

While Scripts for indexes run -> Do your Postactivities inside SAP<br>

SE06<br>

STMS <br>

...<br>

according to System Copy guide<br>

<br>

09:00 Everything beside BDLS is finished: Ready to run BDLS when then indexes are created.<br>

While BDLS is running, some Key user might be allowed to do some application tests if required<br>

<br>

While BDLS is running, i.E. additional actions can be done <br>

like repeat transports that have been done to old QAS, but have not<br>

been imported to PRD yet or likewise. <br>

<br>

i.E. 10:30 Depending on BDLS runtime<br>

Shut down QAS System, enable logging<br>

Start QAS System, do online backup<br>

<br>

System available for testing, <br>

- effective Downtime 16 hours and 30 minutes<br>

- effective work to do the copy 4 hours 30 minutes<br>

<br>

I'll say one might not be able to reach 4:30 on the first try, but meanwhile I <br>

have (small) systems where I do the whole procedure in 6 hours with a work of ~ 2 hours.<br>

But again, the bigest parts are the restore time and the BDLS<br>

<br>

Every 5 systemcopies, review the systemcopy Guide and related notes for changes ( 1 Hour)<br>

<br>

<br>

Have fun and try to improve <br>

<br>

Volker<br>

Edited by: Volker Borowski on Oct 5, 2009 9:42 PM

Added "< br >" Tags to support linebreaks after clipped in Text

[Former Member]

Hi together,

I know that it depends on different matters. This is the secret.

But I want to have example times !!!

I only want to know the technical time from the time you are stopping the QA system until SAP QA is running again for administering for SAP-Basis people.

Please write the amount of hours and the database size and if you want OS and SAN.

The first example from me :

Technical Time: 12 hours for 700GB Database

regards

Carsten Schulz

[stefan_koehler]

Hello Carsten,

> I know that it depends on different matters. This is the secret. But I want to have example times !!!

I already wrote you the time expectation for the "unsupported" ways. I have performed a complete export/import wit R3load (unicode conversion) and many tuning in round about 10 hours.

For more information about my environment please check this thread:

Regards

Stefan

[markus_doehr2]

> I know that it depends on different matters. This is the secret.

> But I want to have example times !!!

nobody will be able to give you a time estimate for YOUR system.

If you use e. g. 5 R3load processes and you have 10 CPUs it may take 10 hours; if you use 10 processes it may take 5 hours. There are too many unknown variables.

The easiest thing (and the only thing to estimate on YOUR environment) would be to just do a test run.

Markus

[Former Member]

>

> nobody will be able to give you a time estimate for YOUR system.
> Markus

Hi Markus,

Hi all,

I know this. I don't want to get an estimation for my system.

I wrote:

> > * I want to have example times from your enviroments !!!*

Please post technical-system-copy-time and size of database.

I want to see how different the times are for homogeneous system in the systems around the world.

I think, from a feeling, my time is too long and therefore I am asking here.

kind regards,

Carsten

[markus_doehr2]

> Please post technical-system-copy-time and size of database.

> I want to see how different the times are for homogeneous system in the systems around the world.

> I think, from a feeling, my time is too long and therefore I am asking here.

I can do a copy of a 2,7 TB system using SAN copy/split mirror in a few minutes (no matter what database). Sun Solaris with ZFS as filesystem and using ZFS snapshots/cloning can be likewise fast. I'm sure Veritas VxFS can do that too.

Using R3load with high parallelism and several application servers to export the data it's possible to copy 800 GB (or more) in an hour and importing the same into the target system in parallel. This requires, however, a good planning and estimation before and some tweaking of the system copy tools (table splitting, using ROWNUM, unsorted export etc.) and the proper SAN infrastructure that is able to handle that I/O.

If you do the copy as copy-of-database-files over the network and creating new control files the significant time will be the copy process. Using 1 GB or 10 GB on the network can make a big difference (theoretically factor 10).

So just asking "how long do you need to do a system copy" without giving any parameters/variables of it is like comparing apples with pears since those values are not comparable.

If you just run sapinst and you do the copy using R3load and use the default settings you may be slower, yes.

Markus

[Former Member]

Hi Markus,

thanks for these data.

Of course, I can compare apples with oranges. This is my intention. I want to look beyond my own horizons.

I want to know how other admin make system copies for QA system and in what time.

kind regards,

Carsten

[markus_doehr2]

> Of course, I can compare apples with oranges. This is my intention. I want to look beyond my own horizons.

Well - if you'd give us your data we could certainly give you some tips/advises what you can do to increase the copy speed

Markus

[Former Member]

>

> The first example from me :
> 
> Technical Time: 12 hours for 700GB Database

Hi Markus,

I wrote some posts earlier that I need 12 hours for 700GB Database.

6 hours deleting DB and so on, 1-2 hours running SAPInst and approx. 4 hours restoring DB from tape.

This are the technical times until SAP is running again.

We are running IBM iSeries with OS i5/OS.

I find it fascinating to see how other platforms are managing there basis topic, especially systemcopy.

@all readers

I only want to know the technical time from the time you are stopping the QA system until SAP QA is running again for administering for SAP-Basis people.

Please write the amount of hours and the database size and if you want OS and SAN.

Thank you very much.

Kind regards,

Carsten

[Former Member]

Hello Carsten,

I don't understand that part:

6 hours deleting DB and so on

What are you doing in these 6 hours?

Usually I do a restore from backup, that is, only the Oracle datafiles will be restored. I keep old Oracle software and SAP software.

I takes a few minutes to shut down SAP and Oracle, and to delete the sapdata files.

And by the way, I am not trying to break speed records. I tell the users that the Q-system will not be available for about two days. The first day, in the morning or in the afternoon, I will delete the old data files, and start the restore process. The next morning new controlfiles will be created, and the adjustments in Oracle and SAP will be done. In the afternoon SAP will be up and running.

DB size 2.5 TB, by the way.

regards

regards

[Former Member]

Hello Joe,

thanks for your experience.

>

> What are you doing in these 6 hours?

I have to delete the DB. The IBM i DB2/UDB is an integrated system. So to delete the database it takes some time. Apprx. 5-6 hours. Because the DB2/UBD is not killed in one 'del'. It has to be done by a command which goes through the database and deletes every DB File serially. Afer that I have to delete SQL-Packages and the journal files (Oracle: log files)

>

> And by the way, I am not trying to break speed records. I tell the users that the Q-system will not be available for about two days. The first day, in the morning or in the afternoon, I will delete the old data files, and start the restore process. The next morning new controlfiles will be created, and the adjustments in Oracle and SAP will be done. In the afternoon SAP will be up and running.

I do the same. We say two days. And we need two days with all work which is to do after SAP QA system is running.

best regards,

Carsten

[Former Member]

At our place we calculate roughly two days for a systemcopy, but including the BASIS post processing like BDLS etc.

So only the copy takes up to 10 hours, depending on the db size, 2tb -> 10hrs, 100gb -> 1hr. Most of the times we use online backups, so we have to do recovery. For an oracle db you can just delete all files on the filesystem and do the restore.

Cheers Michael

[Former Member]

Hi,

We use the database restore procedure for an ECC6 Oracle database of 1.6 TB.

We tell it is a 2 work days job.

Database restore takes 3hours and a half or 4 hours.

What takes the longest time now is running the BDLS transaction to change the logical systems.

It can run up to 15 hours now and it is really becoming a pain where I cannot tell here !

Regards,

Olivier

[stefan_koehler]

Hello Carsten,

it depends on the way, how you want to perform a system copy.

1) Official supported way

Unload / load your database with R3load .. then it really depends on your hardware and the database size

2) Unofficial / unsupported way

2.1) Restore

With a restore it takes as long as your backup and maybe 1 hour more (for setting the new SID, etc.)

2.2) Use hardware / OS depend features

As you already told, you are running SAP on IBM hardware - you maybe also have an IBM SAN storage which supports FlashCopy. Then copy process itself takes a few seconds with the 1 hour more (for setting the new SID, etc.)

Btw. we are using both methods that are listed under point 2, because of our database size.

Regards

Stefan

[sunny_pahuja2]

Hi Carsten,

It depends upon your database size and on your hardware. There is no exact time lines for it.

Thanks

Sunny