SAP CI/DB split -Issues and Analysis:

[former_member200384]

SAP CI/DB split - Issues and Analysis:-

In SAP Production landscape, we are having CI (Central Instance) including all application servers and DB in a single Host .As HANA Database is there in market the SAP clients are splitting their CI/DB from the host and Keeping CI in one Host (Linux Host) and DB in old host. Later they can move the Database to HANA from IBM DB.

During this the OS of CI also have to change for eg. AIX to Linux.CI will be moved to Linux and DB2 retained on AIX itself. Here the CI should be moved to Linux because SAP HANA is not going to support in AIX environment.so moving CI to Linux is the first step to install SAP HANA database in future. After moving the DB to HANA they can again keep both CI/DB in new Linux host. Both CI and DB should have Linux OS.

Generally after CI/DB split in SAP Landscape we may face many issues regarding communication, Online/offline backups of SAP, performance of BW server etc.

Some of the common issues I have listed below and how the BW, BASIS and DB Team will work together .Actually after CI/DB split we may face performance issues on BW.Some time it may takes long time to open the Transaction code in BW.

In RSA1 go to modelling, and then click on Info provider after that the system will hang. This will happen for most of the work areas in SAP BW.

The first step is to update SAP Basis and DB to check from their end. Both Teams should work together as CI and DB are on different Host.

As per BASIS analysis and advice, the DB team can run “Update Statics” on BW. They will run Reorg and Runstats on BW .it all depends on number of tables present in database and how much data they are carrying.

REORG helps DB2 to ensure indexes should become aware of all new data and also no longer include deleted data and collapse all empty page space created by deletion of data and indexes

RUNSTATS gathers the updated statistics on the volume and distribution of data within tables and indexes. This information is stored in the system tables and is used to query the data.

As a result all tables have been Re-orged and Runstated.

The DB team can add Significant Memory to the DB2 buffer pools as much memory as possible. Then BW Team can validate BW server performance degradation. If performance is still slow, they can run an SAP trace to see where the time is being spent.

SAP BASIS can restart SAP.

Stopping the SAP System: Login into the OS level as a user with SAP administrator authorization (<SID> adm).

Enter the command: stopsap [DB|R3|ALL].

DB stops the database system: stopsap DB

R3 stops the instances & associated processes of the SAP System: stopsap R3

ALL stops both the database system & the SAP System. Stopsap ALL

Starting the SAP System: Log on in your OS level as a user with SAP administrator authorization (<SID>adm).

Enter the command: startsap [DB|R3|ALL].

The following applies to this command:

DB starts the database system:     startsap DB

R3 starts the instances & associated processes of the SAP System:     startsap R3

ALL starts both the database system & the SAP System:    startsap ALL

The DB team can do the settings so that more memory should be given to both SAP and DB2.

If the performance is still down then Basis can analyze the performance issues. They can clear user Buffer from their end. This below screen shows user BUFFER AREA, if we want to reset these area just do the following step

TCODE –> SU56

Authorization Values –> Reset User Buffer

Now BW Team can validate the performance.

In Some cases, we can see some issues like the Sequential read time of Transaction codes will be different for different user. Some user’s id are taking less time for Tcode RSA1 and some users Tcode will hang for more time.

We tried accessing RSA1 Tcode from other users (DDIC/USER1) it opens quickly. Whereas it is not so for USER2.

Response time log both the user can be compared. We tried accessing RSA1 Tcode from other users (DDIC/USER1) it opens quickly. Whereas it is not so for USER2.

USER2:

USER1:-

On further Analysis, Now issue looks to be happening for all the user ids. It’s hanging while accessing table RSDVCHA

Tracing the transaction execution RSA1 is showing hanging on multiple tables.

We can go for quick restart of application and server as well. If BASIS unable to stop database on BW then DB team can stop it from their end. We can ask that Currently SAP application is down please stop the database. And Once DB is stopped, we can go for Restart the servers DB instance and CI instance.

Application has been stopped on server CI instance.

In some scenario if communication is not happening between CI and DB. We can check R3trans from DB servers, if processes are getting hanged.

R3trans Return Codes:-

R3trans sets a return code that shows whether or not the transport has succeeded. You can view details on transports in the log file. Here are the following return codes:

0: No errors or problems have occurred.

4: Warnings have occurred but they can be ignored.

8: Transport could not be finished completely. Problems occurred with certain objects.

12: Fatal errors have occurred, such as errors while reading or writing a file or unexpected errors within the database interface, in particular database problems.

16: Situations have occurred that should not have.

If it happens, the DB team can dig in to DB and it occurs mainly due to multiple locks in db. Which should be cleared up from DB end and they have to check DB2CLI driver for communication. If possible they can reinstall db2cli driver again to verify that db2cli is working perfect.

Accessing DB2 Database using DB2 CLI: -   A DB2 CLI uses a standard set of functions to execute SQL statements and related services at run time. DB2 Call Level Interface is IBM's callable SQL interface to the DB2 family of database servers. It uses function calls to pass dynamic SQL statements as function arguments. DB2 CLI does not require host variables or a pre compiler.

Install the DB2 CLI driver on database server.  To do this, we require free space of approximately 50 MB for each operating system of application servers.

We should also ensure that the main version of the DB2 CLI driver matches the main version of the DB2 software on the database server. The fix pack level of the DB2 CLI driver must be equal to or lower than the fix pack level of the DB2 software on the database server.

After installing again Check whether the SAP system and the SAP programs can then determine the DB2 CLI driver and use it.

In a random directory, execute the following command:

R3trans –x

This call should not return any errors and should report the following:

"R3trans finished (0000)."

BWadm 10> R3trans –d

This is R3trans version 6.24 (release 741 - 12.05.14 - 20:14:05).

Unicode enabled version

R3trans finished (0000).

By this we can ensure communication is happening between CI and DB.

In Another Scenario we can have R3trans is responding fine and application is also connecting fine. But the performance is again slow.

This may be due to online or offline backup’s. Tivoli Storage Manager (TSM) provides a powerful and centralized backup, archive, and storage management. Tivoli Storage Manager also plays a role in backup and recovery of DB2 Content Manager Databases in the event of hardware failure. The DBAs and the storage team can work together to get backup issues solved. Sometime the backup job is continually hanging on a TSM resource (Storage device resource) for long periods of time. And it will create numerous locks that can impact the all SAP jobs which will ends up in hanging BW Transactions codes. In this case we have to cancel the backup jobs and check the BW performance.

In DB daily online backups will be taken and during the case of Application upgrade and before CI/DB Split the offline backup should be taken .After CI/DB split we should monitor the backup jobs as well whether it is creating any locks.

----------------------------------------------------------------------------------------------------------