MaxDB Homogenous System Copy and SID Rename

[Former Member]

Hi,

We are looking to run a cheap and cheerful copy of a (7.6.3) MaxDb Database by file copy, i.e. to copy across all data/log volumes etc from the source to the target system. An added difficulty is that we also wish to rename the SID.

So far we have:

1) Installed the target MaxDB instance

2) Copied across the data and log files

When we start the dbmgui it still shows the original 2 data volumes (the source database has 8 volumes), ie the old config file is still being used. If we now copy across the config file from the source system and edit it to change the SID from 'old SID' to 'new SID' we get the following RTE error when trying to bring the database online or even into admin mode:

ERR

-24994,ERR_RTE: Runtime environment error

20062,RTE error checksum does not match, parameter file may be corrupt

When I compare the file size of the config file, it is smaller after editing which probably explains the above error, which brings me to my question(s)

1) Is it possible to edit the config file in this was or can what i am trying to achieve by done by dbmcli commands?

2) Is it at all possible to copy a database and change the SID in this way or do we have to look for alternative methods?

Regards,

mark

Edited by: Simon Gorman on Sep 7, 2009 12:29 PM

OK - A little more information...

We copied back the original target systems config file and used the param_put command to add the extra log volumes and amend the file size information so that when we run param_getvolsall on the source and target systems, they match (apart from the different SIDs of coourse). Now when I run db_warm, I get the following error in krnldiag:

"1 ERR 20052 RTE Too many volumes, type='MSYS', allowed=2"

Does nyone know what parameter this is referring to??

[lbreddemann]

Hi Simon,

sorry to say that but you're just doing it plain wrong.

For a system copy of MaxDB you don't copy files around.

Take a complete data backup (online, offline - just what you like - technically it does make much difference).

Then create a new database instance with the name (SID) you like.

You can configure the disk layout as you wish (just make sure the data backup will fit into the new data area) and adapt parameters.

Once you're done: simply restore the data backup.

That's it.

No config file problems, no renaming issues, no nothing.

The whole process is also documented in sap note "#864650 - Homogeneous system copy with DBMGUI 7.5"

and

in the documentation [Database Copy |http://maxdb.sap.com/doc/7_7/44/d8a8c41c8a4427e10000000a155369/content.htm]

and

in the MaxDB Wiki [http://wiki.sdn.sap.com/wiki/display/MaxDB/HowTo-CreatingacloneofaSAPMaxDB+database].

Copying files and manipulating config data is so... Oracle in the early nineties...

Just don't do that !

regards,

Lars

[Former Member]

Hi Lars,

Thanks for the info. As you can see, this is quite new to me!

The homogenous system copy guides you mention are fine for a system copy where the target SID and source SID are the same, but what about if we need to have a different target SID?

Best Regards,

Mark

Edited by: Simon Gorman on Sep 7, 2009 1:48 PM

Hi Lars, A bit more iinformation that may help. The source MaxDB is currently backed up to tape using a pipe to NetBackup. Currently we are just restoring the data and log volumes onto the target host (which has MaxDB already installed) and then using the param_put commands so that the output of param_getvolsall is the same on both hosts. This is much like what is recommended in the 'Creating a clone od a SAP maxDb database' you mentioned. As you say this is not the way to run such a copy/SID rename, so what would be your recommendation in this scenario?

Best Regards,

Mark

[lbreddemann]

> The homogenous system copy guides you mention are fine for a system copy where the target SID and source SID are the same, but what about if we need to have a different target SID?

Hi there - I'm not sure to which of the three resources I pointed you to you're referring right now.

However, the SID of the database doesn't matter a bit for the recovery process.

You can change it, you can leave it - it's your decision.

All you've to take care of is of course to adapt the logon information of the application servers to point to the new server/sid.

>

> Edited by: Simon Gorman on Sep 7, 2009 1:48 PM

> Hi Lars, A bit more iinformation that may help. The source MaxDB is currently backed up to tape using a pipe to NetBackup. Currently we are just restoring the data and log volumes onto the target host (which has MaxDB already installed) and then using the param_put commands so that the output of param_getvolsall is the same on both hosts. This is much like what is recommended in the 'Creating a clone od a SAP maxDb database' you mentioned. As you say this is not the way to run such a copy/SID rename, so what would be your recommendation in this scenario?

>

First of all: the file copy approach is NOT recommended.

The only reason we put the How-To up there is that in certain, specific situations it may come in handy.

However, for the normal system copy: use the database backup.

For your backup - hell, *DON'T just copy the files.

You get no consistency check, no safe online backup and no way to check whether this worked or not.

MaxDB supports NetBackup to make backups to - why don't you use it?

So again: the right way to do a system copy of MaxDB is to create a full data backup (use DBMGUI or DB Studio for that), create the target instance and recover the backup to this target instance.

regards,

Lars