Home » SAP » Basis

Category Archives: Basis

What are the reasons for slowness in an SAP System?

7th June 2023 / Leave a comment

There can be various reasons for slowness in a SAP (Systems, Applications, and Products in Data Processing) system. Here are some common factors that can contribute to system slowness:

  1. Hardware limitations: Insufficient server resources, such as CPU, memory, or disk space, can lead to performance issues in a SAP system.
  2. Database performance: The performance of the underlying database system, such as SAP HANA or Oracle, can significantly impact the overall system speed. Inefficient query execution, poorly optimized database tables, or inadequate indexing can result in slow response times.
  3. Network issues: Slow network connectivity or high network latency can impact the performance of a SAP system, especially when accessing data from remote locations or when multiple users are accessing the system simultaneously.
  4. Configuration settings: Inappropriate configuration settings within the SAP system can cause performance degradation. This includes parameters related to buffer sizes, thread counts, or memory allocation, which should be appropriately tuned based on the system requirements.
  5. Customizations and enhancements: Custom code modifications or enhancements made to the SAP system might introduce inefficiencies that can impact performance. Poorly written custom programs, inefficient data retrieval, or excessive use of database locks can all contribute to slowness.
  6. Batch jobs and background processing: If there are numerous long-running or resource-intensive batch jobs or background processes running in the SAP system, they can consume significant system resources and impact overall system performance.
  7. Data volume and growth: As the amount of data in the SAP system increases over time, it can lead to slower response times. Larger database sizes require more time for data retrieval and processing, affecting system performance.
  8. System monitoring and maintenance: Lack of proactive monitoring, regular system maintenance, and performance optimization activities can contribute to gradual degradation of SAP system performance.
  9. Integration issues: SAP systems often integrate with other applications or external systems. Issues with data transfers, communication delays, or errors in the integration layer can cause performance problems.
  10. User behavior and load: High user concurrency, excessive use of complex reports, or running resource-intensive transactions concurrently can overload the system and result in slower response times.

It’s worth noting that these factors can interact with each other, and multiple factors may contribute to slowness simultaneously. Identifying the root cause of performance issues requires a systematic analysis of the system, including monitoring various system components, analyzing system logs, and considering the specific context and usage patterns of the SAP system in question.

What is Heterogeneous System Copy in SAP?

6th June 2023 / Leave a comment

In SAP, a heterogeneous system copy refers to the process of copying an SAP system from one platform or database to another. It involves migrating an SAP system from its existing environment to a different hardware platform or database system. The term “heterogeneous” indicates that the source and target systems have different characteristics, such as different operating systems or database management systems.

A heterogeneous system copy is typically performed when there is a need to move the SAP system from one infrastructure to another or when there is a requirement to upgrade the underlying technology stack. For example, it may involve moving an SAP system from an older version of the operating system to a newer version, or from one database management system to another.

The process of performing a heterogeneous system copy involves several steps and considerations. Here is a high-level overview of the key stages:

  1. Preparing for the System Copy:
    • Analyzing the existing system landscape and identifying the target platform and database system.
    • Reviewing hardware and software requirements for the target system.
    • Ensuring compatibility between the source and target systems.
  2. Exporting the Source System:
    • Performing a system backup of the source system.
    • Exporting the database contents and system-specific files from the source system.
  3. Preparing the Target System:
    • Setting up the target system infrastructure, including the installation of the operating system, database system, and other prerequisites.
    • Configuring the target system to match the specifications of the source system.
  4. Importing the Source System to the Target:
    • Importing the exported data and system files into the target system.
    • Configuring the target system to ensure compatibility with the imported data.
  5. Post-Copy Activities:
    • Performing system checks and validations to ensure the integrity and consistency of the copied system.
    • Adjusting system-specific settings and configurations.
    • Testing the system to ensure its functionality and performance.

It’s important to note that a heterogeneous system copy is a complex process that requires careful planning and execution. It involves technical expertise in both the source and target platforms, including knowledge of operating systems, database systems, and SAP system administration. Additionally, it’s crucial to consider factors such as system downtime, data consistency, and potential impact on other integrated systems during the copy process.

SAP provides documentation and tools to assist with the heterogeneous system copy process, such as the Software Provisioning Manager (SWPM) and guides specific to the source and target systems involved. It is recommended to consult these resources and engage with experienced SAP consultants or administrators to ensure a successful system copy while minimizing potential risks or disruptions to the SAP landscape.

What is SAP Homogeneous System Copy?

5th June 2023 / Leave a comment

In SAP, a homogeneous system copy refers to the process of duplicating an entire SAP system, including its software components, configurations, and data, from one environment to another with the same characteristics. It involves copying an SAP system to a target system, ensuring that both systems are identical and compatible.

The homogeneous system copy is typically performed for various reasons, such as system upgrades, system refreshes, disaster recovery preparations, or creating sandbox/test systems. It allows organizations to replicate an existing system setup without making any fundamental changes to the system architecture or database type.

Here are the main steps involved in performing a homogeneous system copy in SAP:

  1. Preparing the source system: Before starting the system copy, it is essential to ensure that the source system is in a stable and consistent state. This includes performing necessary system checks, database backups, and ensuring the source system is free from errors or inconsistencies.
  2. Preparing the target system: The target system must be prepared to receive the copied system. This involves installing the required operating system, database software, and SAP software components. The target system should be configured with the same characteristics as the source system, such as the same SAP release, support packages, and kernel level.
  3. Exporting the source system: In this step, the source system’s data and configurations are exported to a storage medium, such as a network share or external hard drive. This process typically involves using SAP tools like Software Provisioning Manager (SWPM) or database-specific tools like BR*Tools or SQL Server Management Studio.
  4. Importing the data to the target system: Once the export process is complete, the data is transferred from the storage medium to the target system. This step involves importing the exported files into the target system’s database. It may require executing database-specific import commands or using tools provided by SAP.
  5. Post-copy activities: After the data import, several post-copy activities are performed to ensure the copied system functions correctly. This includes updating system-specific parameters, configuring network settings, adjusting database parameters, and performing system consistency checks.
  6. System verification and testing: Once the post-copy activities are completed, the target system is thoroughly tested to ensure it functions properly. This involves validating critical business processes, performing system checks, and verifying that all customizations, authorizations, and user-specific settings have been correctly copied.
  7. System cleanup and finalization: After successful testing, any temporary files or logs generated during the system copy process are removed. The source system is brought back to its original state, and any temporary modifications made during the copy process are reverted.

It’s important to note that performing a homogeneous system copy requires careful planning, thorough understanding of the SAP system landscape, and expertise in SAP administration and database management. It is recommended to follow SAP’s official documentation, guidelines, and best practices while performing a system copy to ensure a successful outcome and minimize disruptions to the production environment.

Syntax of sapcontrol

4th June 2023 / Leave a comment

The SAPControl utility is used to manage and monitor SAP systems. It provides various commands to perform actions such as starting and stopping SAP instances, checking system status, retrieving system information, and more. The syntax of SAPControl commands varies depending on the specific action you want to perform. Here is the general syntax for using SAPControl:

sapcontrol -nr <instance_number> -function <function_name> [<additional_options>]
  • <instance_number>: The number of the SAP instance you want to manage or monitor.
  • <function_name>: The name of the function you want to perform. This can be any supported SAPControl function such as GetProcessList, StopService, GetSystemInstanceList, etc.
  • <additional_options>: Optional additional parameters or options specific to the chosen function.

Start stop of HANA Database with HDB

2nd June 2023 / Leave a comment

To start and stop an SAP HANA database, you can use the following commands:

  1. Start HANA Database:
    • On Linux: sudo -u <SID> HDB start
    • On Windows: HDB start
    Replace <SID> with the System ID of your HANA database.
  2. Stop HANA Database:
    • On Linux: sudo -u <SID> HDB stop
    • On Windows: HDB stop
    Again, replace <SID> with the System ID of your HANA database.

Tools used to check slowness in an SAP System.

1st June 2023 / Leave a comment

In SAP systems, there are several transaction codes (Tcodes) and tools available to check and analyze system slowness. Here are some commonly used ones:

  1. ST03/ST03N: These Tcodes provide workload and performance statistics for SAP systems. You can analyze system performance, identify top transactions, and check response times.
  2. STAD: This Tcode allows you to analyze the workload of the SAP system and provides detailed statistics on user activities, executed transactions, and response times.
  3. SM50/SM66: These Tcodes display the process overview and can help identify any long-running or stuck processes that might be causing system slowness.
  4. ST05: This Tcode is used for SQL trace and can help analyze the performance of database calls made by SAP transactions. It allows you to identify slow-performing database queries.
  5. SE30: This Tcode is used for runtime analysis and can help identify performance bottlenecks in ABAP programs. It provides detailed information about the execution time of each statement and subroutine.
  6. SM21: This Tcode displays the system log and can help identify any system-related errors or issues that might be causing performance problems.
  7. SAP Solution Manager: It provides a range of tools for monitoring and analyzing system performance, including End-to-End Root Cause Analysis (RCA) and Performance Monitoring Dashboards.
  8. SAP EarlyWatch Alert: It is a proactive monitoring service provided by SAP that analyzes system performance, identifies potential issues, and provides recommendations for performance improvements.
  9. SAP Performance Optimization Workload Analyzer (PWA): It is a powerful tool for analyzing workload and performance data. It helps identify performance bottlenecks, provides optimization recommendations, and supports capacity planning.

find if a parameter is dynamic in HANA

16th August 2021 / Leave a comment

We many times need to know whether a hana parameter is dynamic or a restart is required to make it effective. To check this goto below

  • open cdexe on the OS side, if you already configured this alias
  • otherwise go to the folder “cd /usr/sap/$SAPSYSTEMNAME/SYS/exe/hdb”
  • open the config folder by command “cd config”
  • open the Master ini files you need with the editor (do not adjust value in these files)
  • check the hint for the parameter you are looking for, there you will find configure online or offline

Example

Below files contains details about

  • Default values (not to be adjusted)
    • /usr/sap/<sid>/HDB<inst>/exe/config
    • /hana/shared/<sid>/HDB<inst>/exe/config
  • Valid for a specific service (e.g. indexserver) or component (e.g. multidb) on all hosts
    • /usr/sap/<sid>/SYS/global/hdb/custom/config/<service_or_component>.ini
    • /hana/shared/global/hdb/custom/config/<service_or_component>.ini
  • Valid for all services on all hosts
    • /usr/sap/<sid>/SYS/global/hdb/custom/config/global.ini
    • /hana/shared/<sid>/global/hdb/custom/config/global.ini
  • Valid for a specific service (e.g. indexserver) or component (e.g. multidb) on a specific host <host>
    • /usr/sap/<sid>/HDB<inst>/<host>/<service_or_component>.ini
    • /hana/shared/HDB<inst>/<host>/<service_or_component>.ini
  • Valid for all services on a specific host <host>
    • /usr/sap/<sid>/HDB<inst>/<host>/global.ini
    • /hana/shared/<sid>/HDB<inst>/<host>/global.ini

 

understanding sgen and pxa buffer

15th August 2021 / Leave a comment

There are n number of ABAP program in the system used for various functionalities/purposes, all these ABAP programs are stored in REPOSRC, for example below are the total number of programs in a S4HANA system.

Some are kind of must programs that needs to be compiled instantly when a user logs into the system or executes a transaction code. These compiled codes are placed in a table REPOLOAD, for example below are the total entries in a S4HANA system.

This table REPOLOAD is tightly integrated with PXA buffer, the PXA buffer is controlled by below parameters

  • abap/buffersize
  • abap/pxa_cache
  • abap/pxa_preload
  • abap/buffer_fragments

we can see the utilization of PXA or program buffer in ST02

Now,

  • When we start the AS ABAP Server, pxastat and pxanew in work directory is created, first wp-1 loads pxauserload, then pxanew, then pxastat, then will rename pxanew to pxastat, this deletes old pxastat, the pxa buffer is filled up to the percentage specified in abap/pxa_preload, once it is reached the preload is stopped. Once wp shutsdown it writes its pxa to pxanew.
  • if we run the ABAP program (or tcode) first time, it compiles and stores in REPOLOAD then stores in PXA buffer.
  • If we run another time the same ABAP program (or tcode), and the compiled program in REPOLOAD is changed then it will relook in REPOSRC compile it, place the compiled program in REPOLOAD, whenever a program is compiled it is placed in PXA buffer.

Now as I mentioned above parameters, there can be situations where the program might be dropped, then it will be again picked up from REPOLOAD into PXA, now if DB version is different we will get dump LOAD_PROGRAM_LOST.

Now if we activate a program from SE80 or SE38 then the activation timestamp is changed and PXA marks it as old, this information is sent to all abap servers asynchronously. Then all the reactivation process mentioned above is carried out.

With S4HANA we have a new job introduced with 1909, “SAP_SGEN_REGENERATE_LOADS”. The purpose of this is to minimize waiting times for users or developers by regenerating invalidated loads.

This job is periodic job which runs every hour, and run sgen for invalidated loads.

References

Post navigation

← Older posts