cancel
Showing results for 
Search instead for 
Did you mean: 

Option to pre-install MaxDB using SWPM or other for System Copy ?

nelis
Active Contributor
0 Kudos

Good day,

I am busy with a Unicode Conversion project which involves MaxDB and a System Copy.

During the import and installation of the target system we had several issues relating to parameters not being correct in MaxDB. This caused huge delays in the whole process and unnecessary downtime.

To avoid having to do these parameter changes after waiting for the target install to fail once it has built the database I want to pre-install MaxDB and upgrade it with the necessary parameter changes so that we can avoid issues experienced during the target installation and import of data. I also want to avoid having to wait for 1TB of database volumes to be built during the target install.

My question is then, where in SWPM or what is the best method to use to pre-install MaxDB so it can be used for SAP ? I do not see any option in SWPM to install MaxDB as a standalone database. Note, this is not a distributed system, just a standard Central instance installation. I just want the option to install and configure MaxDB first.

We will be using MaxDB 7.8 since this is what all databases are using in the landscape. After the Unicode Conversion we will upgrade to 7.9 and install the latest enhancements. I have the installation media for 7.8.02.31 - this will be patched to build 41 before the import.

Thanks.

Regards,

Nelis

Accepted Solutions (1)

Accepted Solutions (1)

nelis
Active Contributor
0 Kudos

To answer my original question here are some suggestions:

1) During the import and configuration there is a chance to change your input parameters at a summary screen in SWPM. At this point in the install a DB parameter file is created in your working directory e.g.

/tmp/sapinst_instdir/NW702/LM/COPY/ADA/SYSTEM/CENTRAL/AS-ABAP/<SID>_sapdb_db_parameter.txt

You can change certain parameters in this file before continuing.

2) The other suggestion, but clearly not optimal, is to first install SAP and then uninstall it but uncheck the option to remove the database. You can then drop the schema and it is ready for a System Copy import.

SAP MaxDB Team - if you are listening, you need to provide an easy method to install MaxDB before installation of a SAP instance in System Copy! Your customers should not have to do the workarounds as above. You could easily provide a template in SDBSETUP or add it to SWPM. You also need to fix the default MAXSQLOCKS setting of 300000 which is insufficient.

By "fixing" this parameter issue I was able to reduce my import time by half. This downtime could be further reduced if the option to install MaxDB existed because I wouldn't have to wait for database volumes to be built and I could patch the DB beforehand with optimal settings.

Regards,

Nelis

Answers (1)

Answers (1)

0 Kudos

Hello Nelis,

a simple (and unsupported...) but effective way to stop SWPM is to simply rename R3load.exe just before the import. The initial connection check to DB will fail and SWPM will stop with an error leaving the DB in a consistent state. You will have time to do you activities and retry the SWPM later on.

You must rename R3load.exe as soon as it is installed by SWPM, obviously this imply a rather quick action and at least a test run is required, but you should have enough time to do that.

Best regards,

Valerio

nelis
Active Contributor
0 Kudos

Thanks for your reply Valerio.

I would prefer a solution that allows me to run the import without error saving me downtime and money for that matter. The way I see it SAP has two options:

Option 1) allow a person to set parameters before start of the installation and import which the database will use once it is created

Option 2) allow a person to install MaxDB first before the installation so these parameters can be configured and the necessary database volumes created

To give us none of these options is, in my opinion, unacceptable. At the very least they must give me a fix for e.g. MAXSQLLOCKS being set too low.

At the moment I have about 20 tables that fail to load because of "Too many lock requests" error. This means that it must now first go and drop(to maintain consistency) all that data and then re-import it which is costing us unnecessary downtime!

Nelis