Skip to end of metadata
Go to start of metadata

Introduction

SAP Systems can be installed in many different scenarios, one of which is a dual stack system, consisting in an ABAP Application Server (AS) and a Java AS. 

Systems based on NW 6.40/7.0 can be installed as dual stacks. This provides advantages in terms of Setup, Configuration, Backup and Restore efforts. However, based on SAP strategy and experience from existing customer landscape, it has been observed that the advantages of separate systems outweigh the ones from dual stacks. For example, separate systems are easier to administrate, are more flexible, scalable and you can guarantee the availability of them independently. 

As of NW 7.0, dual stack systems can no longer be installed, except in the case of Netweaver Process Integration (PI) and Solution Manager. Upgrading existing dual stack systems are still possible up to release 7.3x.

In order to split a dual stack system, SAP has developed a tool which can be downloaded from the Marketplace here. The related documentation can be found here.

In the page, the latest version of the tool can be found. It provides two methods for splitting the system, which will be presented in the next section.

In this demonstration, a Dual Stack Netweaver 7.0 running on Microsoft Windows and MSSQL Server will be used.

Info!

In all steps performed with the Split Tool, it is possible to choose between Typical and Custom modes.
In order to show all possible inputs, during this demonstration the Custom option was selected for all procedures.

Table of Contents

Ways of splitting a system

Before the system is split, it must be decided which method will be used: 'Keep DB' or 'Move DB'.

Keep DB

With this option, only the Java Central Instance (CI) will be exported and imported into a new system. The database will remain in the same server.

The figure below illustrates this procedure:

The new system will contain a new Central Services (SCS) instance and a new central instance. The SCS and CI from the source server should be removed afterwards.

In the 'Keep DB' method, the DB instance of the new Java system will be placed in the same database as the source system, configuring an MCOD (Multi Components in One Database) environment.

Move DB

In this option, the new Java system is completely independent from the source one, with exception of UME (User Management Engine). The figure below shows the procedure:

In the above scenario, the Java CI and DB are exported and imported into a new server. Afterwards, all the Java instances (SCS, CI and DB) are removed from the source system.

If the UME system uses the ABAP as data source, this cannot be changed during the target system installation. In addition, SAP does not recommend changing the UME settings.

Important!

Regardless of the splitting method selected, the items displayed in the Dual Stack Split tool must be executed in order, as explained in the next sections.

Splitting the system with the Move DB method

The environment used for this exercise is the following:

 

Source

Target

SAPSID

WKI

WKJ

DBSID

WKI

WKJ

Hostname

CRH2011

CRH2012

Once the splitting method has been chosen, the next step is to start the Split Tool on the source system to perform the export of the Java stack.

In order to start the tool, extract the downloaded SAR file and run sapinst.exe (Windows) or sapinst (Unix).

Exporting the Source System

In the initial screen, the Export Java Stack procedure under Move Database method is selected.

In the next dialog, the profile path of the system to be split must be provided. It's important to provide the path in the UNC format for Windows, that is: \\<SAPGLOBALHOST>\sapmnt\<SAPSID>\SYS\profile. For Unix systems, the path should be /sapmnt/<SAPSID>/profile.

As the tool switches to <sid>adm user to perform some activities during the procedure, it is necessary to inform its password in the next dialog.

In the next dialog, the DB to be exported should be selected. In this case, DBSID=WKI.

The export directory can be defined in the next screen. It is very important that a local directory is used to perform the export, since shared directories may lead to errors or corrupted dumps.

At this point, there is a checkbox that can be used, so the tool will remind the user to stop the system before the export.

It is possible to select whether the current Java stack should be disabled after the export or not.

After the previous screen, a summary of all the inputs is displayed, which can be reviewed and changed if necessary. Once the summary is reviewed, the export will start.

As soon as it finishes, the DSS tool will display the pop-up as in figure below.

At this point, the entire Java stack of the system has been exported to the dump directory provided. The next step will be performed in the target system.

Installing the target Java system

Info!

The RDBMS software should be already installed on the target system. More details can be found in the installation guides for the respective SAP system release.

In the target system, the DSS tool must be run again. However, at this point the option Install Java System should be selected.

The dump files from the export procedure should have already been copied to the target system, as they must be provided as the "Migration Export" media for the installation.

In the next screen, the path to the export dump directory should be entered.

In the next screen, the SID for the new Java only system should be provided. For Windows systems, the installation drive should also be informed in this step.

In case URLs for ABAP and Java systems need to be used after the system is installed, the Domain Name should be set. In the case of this artcile, this parameter will not be set. The value informed here will be reflected in the value of parameter SAPFQDN.

As in a regular installation, a master password must be set.

If the new system will be a distributed or HA environment, the Domain Installation option must be selected. It is technically possible to use a local installation for such scenarios and the instructions can be found in the installation guide. However, in case of any issues, the system will not be supported by SAP.

As the Custom option was selected in previous dialogs, the passwords for <SAPSID>adm and SAPService<SAPSID> (in Windows) can be set.

The MS SQL instance should be selected in the next dialog.

If SAPSID is the same as the DBSID, the message below is displayed. The installation can continue normally, this is not an issue.

The password for the Java Database user SAP<SAPSID>DB must also be provided in the next dialog.

The number of data files can be selected depending on the size of the system.

It is also possible to add additional data files, or remove existing ones and set their size.

A Secure Store key should be entered. This key is used to encrypt the data in secure store from the Configtool, which is used to connect to the Database.

SAPinst will display all the instance it finds in the current host and allows you to select the number for the Central Instance (CI) and Central Services Instance (SCS). The number must be unique for each instance in the host.

The transport host should be provided. The SCS port can also be configured at this point.

SAPinst needs the Java Components media to proceed with the installation. This media can be downloaded from the Marketplace .

The Administrator user must be informed in the next dialog. The name and password must be the same as in the source system. The password can be modified after the installation finishes.

The SDM password must also be provided.

The next dialog presents the SAR files and the path to where they will be extracted.

A Summary will be presented at the end of Define Parameters phase, in which it is possible to perform any necessary adjustments.

During the installation of the target system, the pop-up below will be displayed. The User Management Engine (UME) requires the ABAP system to retrieve the data for the Java users.

At the end of the procedure, sapinst will display a pop-up indicating the installation finished successfully.

Removing the Java Stack from the source system

As a last step, the Java stack from the source system must be removed. This can be achieved by running the "Remove Java Stack from Dual-Stack System" task from the DSS tool.

It's necessary to inform the path to the profiles of the source system.

As the removal procedure is quite simple, the only required information besides the profile path are the system administrator password and the database SID.

As in the previous tasks, sapinst will present a summary screen of the input information for review. Once the summary is approved, the execution phase starts.

As soon as it finishes, a pop-up is displayed informing that the procedure was completed successfully.

Splitting the system with the Keep DB method

The environemt used in this exercise is the following:

 

Source

Target

SAPSID

VM1

VM2

DBSID

VM1

VM1

Hostname

CRH2011

CRH2012

Exporting the source system

As in the previous method, the first step is to start sapinst to perform the export of the source system. The main difference is that only the Central Instance will be exported and the database will remain in the current host.

The input parameters for the CI export are basically the same ones as in the Move DB export process, it is necessary to provide the path to the profiles, the password of the system administrator and the DB SID. Also, the location in which the export dump should be placed must be informed. It is important to use a local directory rather than a shared one.

As in the previous method the option to disable the AS Java is displayed. When this option is checked the parameter rdisp/j2ee_start is set to 0 in the central instance profile, which prevents the Java engine from starting.

After all the inputs have been entered, a summary screen is displayed and any modifications can be performed. Once the summary is reviewed, the execution of the export takes place.

A message will be displayed requesting to stop the SAP system in case it is still running during the process.

The split tool will inform once the export is completed successfully.

Installing the SCS instance

The next step displayed by the tool is to install the SCS instance. This takes place in the target system.

The export dump should be moved to the target system, since it will be requested during the SCS installation. This dump contains the kernel independent part of the system, therefore it is not required to download any separate medias for the kernel. That means the source and target system will contain the same kernel patch level.

The new system must have a different SAPSID than the source system. As this is a Microsoft Windows environment, the option to choose the drive in which the system will be installed is also presented.

In the case of this article, no FQDN was informed.

As usual, the master password must be provided in the initial steps.

In this case, a local installation will be performed.

The password for each individual user can be reviewed and changed if necessary. If not changed, master password will be used.

The tool will display all the instances found in this environment by looking into the Windows Services. As this is a clean system, no instances were displayed.

Then, the SCS instance number must be informed.

The Message Server port can also be changed if necessary. The standard value is 39<nn>, where <nn> is the instance number.

The tool will take the kernel from the dump directory and extract it to the specified destination.

The above is the last dialog displayed before the summary, in which the inputs can be reviewed.

As soon as the installation finishes, the pop-up below is displayed concluding the procedure.

Adapt Database

This step is unique for the Keep DB procedure and it must be executed in the source system, which is the DB host.

The purpose is to adjust the parameter of the profiles of the new system to point to the current Database.

Once again the export dump path must be provided.

In the next dialog the profile path for the target instance must be provided.

In this case, the FQDN is not being set.

Sapinst requests the master password as a last step, and then it displays the Summary screen.

When the procedure is complete, a pop-up like the one below should be displayed indicating the profiles were adjusted successfully.

This should be a fairly quick step.

Install Java Central Instance

The next step is to install the Java CI and should be executed in the target system.

Here the export dump is needed again in order to install the application specific data and SDM for the Java CI.

Most of the parameters which will be requested in the next steps are similar to the ones requested during the SCS installation (profile path, master password and FQDN).

It is also necessary to inform the DBSID, which should be the one from the source system.

In the next step, the previously installed SCS should already be detected and the instance number of the new CI should be informed.

The host in which the transport directory should be created is requested in the next dialog. In this case, the local host was used.

During the Java Central Instance installation, it is necessary to provide the location of the Java Components media. This media should be downloaded from the SAP Service Marketplace and it varies according to the system release.

After providing the Java Components media, some user information is requested. The first one refers to the J2EE engine administrator of the source system (in this case, the source is VM1).

Usually the administrator user for the java engine in dual stack systems is the J2EE_ADMIN user.

Next, the password to connect SDM GUI to the SDM server should be specified.

As in the SCS installation, the kernel is taken from the export dump directory and extracted to the specified destination. 

As the EXE.SAR had already been extracted, it is not selected by default in this case.

The summary screen should be displayed as soon as the kernel destination is confirmed.

During  the execution phase, the installer will request to ensure that the central instance in the source system is up and running.

The usual pop-up informing the procedure was completed successfully should appear once all steps are performed.

Remove Java CI

At this point, the new system is ready for use. The remaining step is to uninstall the Java stack from the source system.

This can also be achieved by using the Dual Stack Split Tool.

The profile of the source system must be provided in this step.

Sapinst will request the password of <sid>adm user. After that, the database instance and DBSID must be informed.


After that, the summary screen will be displayed and, at the end of the procedure, the pop-up below is presented.

Remove Java dialog instances

If the system contains dialog instances, this step must be executed in each of the hosts. In this case, there are no dialog instances. Therefore, this step will not be executed.

Remove SCS

The last step is to uninstall the SCS instance itself.

For this taks, only the profile path is necessary.

After that, you get the summary screen and can start the procedure.
This step should be quick as well and the pop-up below is shown at the end.

  • No labels

3 Comments

  1. This wiki is fantastico

    thank you

    Andy.

  2. About Wikis like that, in tradition of Captain Kirk i would say " On the screen ! "

    Thx

  3. Former Member

    Can we split PI 731 system first and then update to 750? Is this scenario supported for PI system?