Systemcopy without R3load and Backup/Restore

[ChristophFritz]

Hi all,

I want to copy a large maxDB database instance (> 1TB) in a homogenous environment. The Backup of the source system is performed with SnapShot-Technologie of the Storage system.

If the structure of the database (Number and Size of the data volumes) is identical in the Sourcesystem and Targetsystem it is possible to perform a homogenous system copy by copying the the latest snapshot to the /sapdata directory of the targetsystem, clear the log and restart the database. So far no problem ...

Now I tried to do the same for a test system which did not exist before. Unfortunatly I do not have enought space to perfrom a regular backup and create the instance with recovery with initialization.

So I created the new MaxDB Instance and activated it with the same number of datafiles (60 datafiles), but to save time I created them with 200M each and not 20GB. Then I restored the snapshot, cleared the log and tried to start the database.

Unfortunatley the database is too smart for that:

2007-02-27 13:53:50 10337 ERR 20043 IOMan Capacity of data volume 1 is different between configuration and info page: 25601

vs. 2560001

The information about the size of each datafile is stored in the binary file containing the database configuration. I know that there is this difference, this is right and I want to change the reference value of 200M

Is there a possibilty to change this information or create a database instance using the current data devspace? And if so: can I also change the number of datafiles in this configuration information?

Rgds

Christoph

[lbreddemann]

Dear Christoph,

to keep it simple: there's no way to get this bunch of mixed files to work.

You want to rearrange the data that is inside the database to a new file layout.

It's obvious that this has to be done by the database itself, since it has to keep track where it stores it data. So it will touch each and every single page to to this.

Now, that's the point of the story where you should begin to wonder: where is my time advantage in doing this?

Good question! There is none.

Do a database backup via the usual DB Backup facility and you won't have any problems at all.

If you've got a Storage Snapshot - fine. Use it to take the I/O peaks from the productive instance, while you backup the shadow instance with DB Tools!

But don't think that you can save so much time with that. The MaxDB backup is pretty quick - mostly dependent on the target devices. Do it in parallel, do it to pipes. It can be pretty fast.

I

t's also possible to make a backup directly into the target instance...

Beside: your procedure was never and will never be supported. Once you ran into a problem with that, your db is done.

So think about it.

KR Lars