Sap Basis.docx

How to Lock (SU01) & Unlock (SU10) a SAP User Locking a user The Purpose of locking user is to temporarily deactivate the users so that they cannot longer access the system. Users can be locked in 2 ways: 

Automatically Explicitly/Forcefully

Automatically: - There are two possibilities when users get lock automatically 



Maximum number of failed attempts:- controlled via the parameter login/fails_to_user_lock. If a value is set to 3 it means after 3 failed attempts user will be locked. Auto unlock time: - "login/failed_user_auto_unlock" defines whether user locked due to unsuccessful logon attempts should be automatically removed at midnight.

Explicitly/Forcefully: We can lock and unlock users in 2 ways1. Lock single user (SU01) 2. Lock multiple user (SU10)

Procedure to lock a single user Step 1) Execute T-code SU01

Step 2) Enter a username in User field.

Step 3) Press Lock/Unlock button

Step 4) In the next screen, Press Lock button again to lock the user.

Procedure to lock multiple users

Step 1) Execute T-code SU10

Step 2) Enter users a username in User field.

Step 3) Press Lock/Unlock button

All the users listed will be locked

Procedure to unlock a user Step 1) Execute T-code su01

Step 2) Enter username in User field.

Step 3) Press Lock/Unlock button

Step 4) Press Unlock button

Procedure to unlock multiple users Step 1) Execute T-code SU10

Step 2) Enter users' username in User field.

Step 3) Press Unlock button

Users will be unlocked

Assigning SAP authorizations On this page



SAP user type



Password update requirement



SAP authorization objects Note SAP authorizations must be assigned by your SAP Security Administrator. Direct Link users require the following SAP access and authorizations in order to connect to your SAP system and extract data:



An SAP user ID and password that allows them to connect to the SAP system



Specific SAP authorization objects and authorizations, including SAP table authorizations

SAP user type To connect to your SAP system, Direct Link users must have SAP accounts configured with either of the following SAP user types:



Dialog



Service

Direct Link does not work with SAP accounts configured with any of the following SAP user types:



Communication



System



Reference

Password update requirement The password for the SAP Dialog user type must be updated on a regular basis, whereas the password for the Service user type does not have to be updated. If you schedule Direct Link extracts and use a generic SAP account to connect, you should consider using the Service user type to avoid a connection failure because of an expired password.

SAP authorization objects Direct Link users require the specific SAP authorizations listed below. Note Consult your SAP security documentation for detailed information about assigning SAP authorizations to users.

Object class

Authorization object

Field

Values

Details

Cross-

S_RFC

ACTVT

16 (authorizes Execute)

Controls a user's abil

Object class

Authorization object

Application Authorization Objects

Authorization check for RFC access

Field

Values

Details

RFC_NAME

/ACLDL/DLINK7

function modules on from a remote locatio desktop computer.

DDIF_FIELDINFO_GET GET_SYSTEM_TIME_REMOTE RFCPING RFC_GET_FUNCTION_INTERFACE RFC_TYPE

FUGR FUNC

Basis: S_TABU_DIS Administration Table maintenance

Direct Link users should be assigned authorizations for those SAP tables they need to access in order to perform their analysis. For example, a user performing a General Ledger audit needs authorizations for the general ledger tables. Note Your organization's own business processes dictate which users require table authorizations, and what authorizations they require. Work with your SAP Security Administrator to determine the appropriate level of access that your users require.

S_TABU_NAM Table maintenance

S_BTCH_JOB

JOBACTION RELE (authorizes Release)

Background processing: Operations on background jobs

JOBGROUP

S_DATASET Authorization for File Access

ACTVT

'' (a space between two single quotation marks)

06 (authorizes Delete) 33 (authorizes Read) 34 (authorizes Write)

Controls a user's acc groups of SAP tables

To control user acces table level, use the S authorization object.

Controls a user's acc SAP tables.

Controls a user's abil in background mode. Note If you intend to use S servers for the proce Linkbackground jobs enable the Batch me server. The Batch message enabled by default on SAP server where th is installed.

Controls a user's abil and delete files on th operating system of t Note

Object class

Authorization object

Field

Values

Details

FILENAME

*

PROGRAM

/ACLDL/DL7_DLINKBKGD

If stricter file security S_DATASET authori configured so that us accessing only those located in the Direct L To perform this config the * value in the FIL that it is preceded by the Direct Link outpu example: C:\Direct

/ACLDL/SAPLDLINK7

S_GUI Authorization for GUI activities

ACTVT

61 (authorizes Export)

Controls a user's abil data from the SAP sy desktop computer.

Configuring the Transport Domain Controller Prerequisites You have decided which system is to be the Transport Domain Controller.

Procedure To configure a system as the transport domain controller (and thereby configure a new transport domain): 1. Log on in client 000 in the SAP system that you want to configure as the transport domain controller. 2. Call transaction STMS. The TMS: Configure Transport Domain dialog box appears. (This dialog box only appears if you have not yet configured a transport domain.) 3. Enter a name and a short description of the transport domain.

Note The name of the transport domain may not contain blank characters. You cannot change the name of the transport domain afterwards without reconfiguring the domain controller and thereby the entire transport domain. 4. If your SAP system consists of multiple application servers, you can choose one server for the TMS. 5. Save your entries. You are asked for the password of user TMSADM. 6. Enter a secure password that you do not use for any other purpose.

Note You must remember the password. You need it to set up an SAP system group again. You can change the password of user TMSADM later by executing program TMS_UPDATE_PWD_OF_TMSADM . The program copies the password to all affected SAP systems of the TMS landscape. Your SAP system performs the following actions automatically on save: o

Creates the user TMSADM with the password that you chose, and assigns the profile S.A_TMSADM to the user

o

Stores the password of the TMSADM user in the Secure Storage of the system

o

Generates the RFC destinations required for the TMS

o

Stores the TMS configuration in the transport directory

o

Generates the transport profile for the transport control program tp

o

Configures the SAP system as a single system

Result The configuration of the transport domain is now complete for this SAP system. The initial screen of transaction STMS shows that this SAP system is now functioning as the domain controller of the transport domain.

Configuring the Backup Domain Controller Prerequisites In your transport domain, the SAP System which is configured as the domain controller is of special signifance. If this SAP System fails, you cannot make changes to the TMS configuration during this time. If your transport domain contains more than three SAP Systems, we therefore recommend that you configure a backup domain controller. If your domain controller fails, the backup controller can assume the function of the domain controller.

Caution The SAP System that you want to use as the backup controller must have the same release version as the transport domain controller. Otherwise, configuration information may be lost when changing the domain controller.

Procedure To configure a backup domain controller: 1. Log on to the SAP system that functions as the transport domain controller. 2. Call transaction STMS. 3. Choose

Overview

Systems

. The system overview appears.

4. Position the cursor on the domain controller. 5. Choose

SAP System

Change

. The screen Change TMS

Configuration: System <SID> appears. 6. In the field Backup, enter the SAP System to be used as the backup controller of your transport domain. 7. Save your entries and distribute the configuration change.

How to Configure STMS (SAP Transport Management System) STMS is the transport tool that assists the CTO for central management of all transport functions. TMS is used for performing:   



Defining Transport Domain Controller. Configuring the SAP system Landscape Defining the Transport Routes among systems within the system Landscape Distributing the configuration

 Transport Domain Controller – one of the systems from the landscape that contains complete configuration information and controls the system landscape whose transports are being maintained jointly. For availability and security reasons, this system is normally the Productive system. Within transport domain, all systems must have a unique System Ids and only one of these systems is identified as the domain controller, the transport domain controller is the system where all TMS configuration settings are maintained. Any changes to the configuration settings are distributed to all systems in the landscape. A transport group is one or more systems that share a common transport directory. Transport Domain – comprises all the systems and the transport routes in the landscape. Landscape, Group, and Domain are the terms that are used synonymously by system administrators.

TMS Configuration Step 1: Setting up the Domain Controller 



Log on to the SAP system, which is decided to be the Domain Controller, in client 000 and enter the transaction code STMS. If there is no Domain Controller already, a system will prompt you to create one. When the Transport Domain is created for the first time, following activities happen in the background: o Initiation of the Transport Domain / Landscape / Group o Creating the user TMSADM o Generating the RFC Destinations required for R/3 Configurations, TMSADM is used as the target login user. o Creating DOMAIN.CFG file in usr/sap/trans/bin directory – This file contains the TMS configuration and is used by systems and domains for checking existing configurations.

Step 2: Transaction STMS

Step 3: Adding SAP systems to the Transport Domain 







Log on to SAP systems (to be added in the domain) in client 000 and start transaction STMS. TMS will check the configuration file DOMAIN.CFG and will automatically propose to join the domain (if the domain controller already created). 'Select' the proposal and save your entries. For security purpose, system status will still be in 'waiting' status, to be included in the transport domain. For complete acceptance, login to Domain Controller System (Client 000) -> STMS -> Overview -> Systems. New system will be visible there. From the menu choose 'SAP System' -> Approve.

Step 4: Configuring Transport Routes 



Transport Routes – are the different routes created by system administrators and are used to transmit changes between the systems in a system group/landscape. There are two types of transport routes: o Consolidation (From DEV to QAS) – Transport Layers are used o Delivery (From QAS to PRD) – Transport Layers not required Transport Layer – is used to group the changes of similar kinds, for example, changes are done in

development objects of same class/category/package, logically should be sent through same transport route. Therefore transport layers are assigned to all objects coming from DEV system. Layers are used in Consolidation routes, however after Testing happens in QAS, layers are not used and the changes are moved using single routes towards PRD system. Package – (formerly known as Development Class) is a way to classify the objects logically belonging to the same category or project. A package can also be seen as an object itself and is assigned to a specific transport layer (in consolidation route), therefore, changes made in any of the development object belonging to a particular Package, will be transmitted towards target system through a designated Transport Layer only, or else the change will be saved as a Local (non-transportable) modification.

SAP Routes & Layers: Step by Step Configuration Consolidation routes – We need to establish a consolidation route for each transport layer. Development/ Integration system is taken as the source of these consolidation routes. Quality assurance/ Consolidation system as the transport target. Any modified objects that have a consolidation route for their transport layer can be included in change/transport requests. After the request has been released the objects can be imported into the consolidation system. If the changes are made to the objects with no consolidation route set-up (or in Customizing requests without a transport target) for their transport layer, such changes will be automatically taken as local change requests, i.e., not-transportable. Only one

consolidation route per transport layer per system can be set-up.

Setting up Transport Routes Once the Domain and other systems of a landscape are defined, we need to connect them with the help of proper transport routes (and layers). As for many customers' systems landscape fall into the same categories, the TMS provides some standard system groups that can be used for easily defining routes. When standard options are used, routes are generated automatically; we can select one of the following options:   

Single System Two-System landscape: DEV and PRD Three System landscape: DEV, QAS, and PRD

If we need to define a more complex transport system, we can also use standard options initially and there after defining additional consolidation and delivery routes.

Transport Routes – Standard Configuration

Transport Routes – Manual Configuration

Transport Routes

Distributing and Verifying the Configuration 



After the transport route settings are made or modified in the domain controller, all other member systems of the domain ought to know the new configuration. For that we need to execute STMS -> Transport Routes Screen -> Systems Overview -> Configuration -> Distribution and Activate Configuration Additionally, we should also verify various check-points, to ensure that the whole arrangement is behaving in the desired manner: o For RFC Connections: Overview -> Systems -> SAP System ->Check -> Connection Test o For Network: Transport Routes Overview -> Config. -> Check -> Request Consistency o For tp & TPPARAM: System Overview Screen -> SAP System -> Check -> Transport Tool

Client copy how to for beginners FollowRSS feedLike 8 Li kes 41,327 Vi ews 8 C omments

1.1 Client overview



A client is a self-contained unit in commercial, organizational, and technical terms, with its own user

master data and set of table key ranges. 

Data from different clients is kept separate at the kernel level. SQL statements executed by an application

use the client number in the where-clause. Although a table may contain data from several different clients, the where-clause limits access to particular clients. 

Examples of client-specific data include:

User master data – such as parameters, authorization, user groups Customizing data – such as organizational units, assignments, and document types Application data – such as business transaction data, and material master data



The SAP client concept can integrate several companies or subsidiaries in a single client – by using

company codes and the SAP authorization concept.









Company codes define the smallest corporate organizational units for which a complete self-contained set of accounts can be drawn up for external reporting. The SAP authorization concept enables the parent company to access all subsidiaries for report purposes, while subsidiary-specific data is protected against access from other subsidiaries through company code definition.

Data of a SAP System can be divided into two categories:  Client-specific data is data affecting only one client, such as user master and application data.  Cross-client data is data affecting the whole system environment, such as cross-client Customizing data and all Repository objects. The ABAP Dictionary is a data dictionary that is part of the ABAP Repository:  Each piece of ABAP Dictionary information is entered only once and is then available anywhere in the system at any time. The ABAP Dictionary automatically supplies all new or changed information, thus providing current runtime objects and ensuring data consistency and security.  The SAP runtime environment consists of all ABAP programs required during execution. The ABAP interpreters in the runtime environment do not use the original of an ABAP program. Rather, they use a copy generated once only during runtime (early binding). Runtime objects, such as programs and screens, are automatically regenerated (late binding) when a time stamp comparison between the object and the ABAP Dictionary detects a difference.  This combination of early binding and late binding ensures that the active integration of ABAP

Dictionary information does not affect system-wide performance. All performance-critical information is stored in the runtime objects and is always kept up-to-date.

1.2 Client Copy





 

SAP delivers 3 client copy methods :  Local client copy in order to perform client copies inside a given instance,  Remote client copy in order to copy client beetween different SAP instances,  Client export / import also to perform client copies beetween different SAP instances. The difference beetween the remote client copy and the client export / import lies in the way the data is transfered :  In remote client copies the data is transfered immediately across the network using RFCs.  Using client export/import, the data is exported in files to the transport directory. The import is done in a second time. Client copy tools let you copy the following data types : users data, cross client customizing, application data and client dependant customizing. The objects from the ABAP dictionnary like ABAP reports, table definitions and so on , are not handled by the client copy tools. These objects can only be transported through transport requests accross the instances.

1.2.1

Client copy pre requisites

The client copy should be performed on a low system activity timeframe. To have a consistent client copy you should not have any activity on the source system. Therefore, it is recommended to :

 

Disconnect and lock dialog users. Suspend background jobs :

This can be done using report BTCTRNS1. The jobs will be released afterwards using report BTCTRNS2.



For remote client copies, the data dictionnaries beetween the source and target systems should be the same.

If not, in case of client copy beetween a production and development system ,you can exclude tables from the client copy using report RSCCEXPT. You have to be sure that your target client will still be usable and consistent compared to your needs depending on the table excluded.

1.2.2

Local client copy

Local client copy is performed using Tcode sccl. The client copy logs are available using tcode scc3. Local client copy steps :     

Log on to the target system Create an entry for your new target client using scc4 Log on to this new target client with user SAP* and default password pass. Start the client copy using transaction sccl. Select the source client and the copy profile.

 

Schedule the client copy in bacground The client copy logs are available in scc3



1.2.3

Remote client copy

This method uses RFCs. The network must have good performances in order for the client copy to be as fast as possible. An RFC must have been declared in sm59 to access the source client.

Remote client copy steps :

      

Log on to the target system Create an entry for your new target client using scc4 Log on to this new target client with user SAP* and default password pass. Start the remote client copy tcode : scc9. Select the source client ( select the right rfc destination ) and the copy profile. Schedule the client copy in background The client copy logs are available in scc3.

NOTE :The first step is the dictionnary comparison beetween the source and target system. If these are not identical, the client copy will be canceled. Still, it is possible to exclude the tables that are not the same using RSCCEXPT. But this must be done carefully as it can have a negative impact on the data consistency in the target client. You have to make sure that this will not have any impact on the target client usability.

1.2.4

Client Export / import

The copy is performed in 2 steps :  

The client export during which the source client is exported to files in /usr/sap/trans/data | cofiles. The client import during which data is imported in the target client.

You must have enough space in the /usr/sap/trans file system to perform the client export.



1st step : export  Log on to the target system  Create an entry for your new target client using scc4  Log on to the source system / source client.  Start Tcode scc8

   

Select the target system and export profile Schedule the export in background The transport request containing the client export are then shown Depending on the choosen export profil there can be up to 3 transport requests created :

Request <S-SID>KO will hold the cross client data, Request <S-SID>KT will hold the client dependant data, Request <S-SID>KX will also hold some client dependant data.



2nd Step : import  Log on to the newly created target client using SAP* and password pass.  Start the stms transaction  Display the target system’s import queue,  Select the transport requests generated by the client export and import theses transport requests on the target client.  The transport requests will be imported in the following sequence :

request <S-SID>KO (client independant), request <S-SID>KT (client dependant), request <S-SID>KX (client dependant). 



The system automatically detects these are client export transport requests and automatically performs the import of the 3 requests.  The import logs can be seen in stms. 3rd step : post import phase:  Once the import is done, start the scc7 Tcode to perform the post client import actions,  Schedule the post import job,  The log will be available in scc3.

Download & Upgrade SAP Kernel: Step by Step Tutorial

What is a Kernel? 







The Kernel is a central program which acts as an interface between SAP application and operating system. The Kernel consists of the executable programs that reside under the path "/sapmnt/<SID>/exe" (UNIX) or \usr\sap\SID\SYS\exe\run (Windows) These files help startup the R/3 system, initialize the memory, create buffers and start managing the requests from users and effectively utilizing of hardware resources. The kernel is also responsible for starting and stopping all the application services like dispatcher, message server, collector etc.

Why Kernel Upgrade? 





SAP Kernel is the core of the application. Like all other applications, the Kernel contains the executable files (.EXE files for stating various processes in SAP). The Kernel is the heart of the operating system. It contains those files which are used to run every event in SAP. E.g.|: starting database, shutdowns of the database, starting sap, shutdown of sap, saposcol, to uncar the sap files etc. That's the reason why when a Kernel upgrade is done it means new versions of the various EXE files replace the older versions.

How to check Kernel Version? There are many ways to check the Kernel Version Method 1) Logon to SAP system and go to SM51 à Release Notes

Method 2) Logon to SAP system and go to System tab in the menu bar and select Status

Method 3) Logon in operating system, switch to user <SID>adm and give the command disp+work You can also give disp+work –version

Download Kernel from Service Marketplace







Go to "SAP Service Marketplace. " (https:\\service.sap.com) You will need your OSS ID and password. Then go to Downloads à SAP Support Packages -> Entry By Application Group -> SAP Kernel 6.00 64 Bit -> Select your OS (LINUX/WINDOWS/SOLARIS/AIX) -> Database Dependent and Database independent Kernel Patch. Two SAR files SAPEXE.SAR and SAPEXEDB.SAR are downloaded from Service Marketplace.

Database Independent

Database Dependent: ORACLE

Kernel Upgrade Steps: Step 1: Create a new Directory at OS level with enough space. Name of Dir can be "exe_new". Step 2: Transfer these SAPEXEDB.SAR & SAPEXE.SAR files which you have downloaded to the new directory at OS level. Step 3: Change your current directory to path .SAR files are created (cd /sapmnt/PR2/exe_new20122006). Check the directory path with command 'pwd' to ensure you are in the same dir (exe_new). Step 4: Now uncompress these. SAR files by sapcar exe. The command used for the same would be SAPCAR –xvf sapexe. SAR

SAPCAR –xvf sapexedb.SAR

Step 5: Now create one more directory in that path with the name "exe_old". Take the backup of existing kernel.Copy (only copy not move) the existing kernel from exe directory to "exe_old"

Step 6: Now stop the SAP application. (For kernel upgrade the shutdown of database is not essential but we need to stop the SAP application) stopsap r3

Step 7: Then copy the files from the new kernel directory exe_new to the existing kernel directory exe

cp -rp /sapmnt/<SID>/exe_new/* /sapmnt/<SID>/exe/

Step 8: This will copy / replace all the files in the existing kernel directory with a new kernel files. Then check the kernel version from OS level by the command disp+work. It should show that the patch number has been increased. Step 9: Then logon to OS level as root (specific to UNIX). In the kernel directory, there is a script called saproot.sh. Execute this script

./saproot.sh <SID>

Step 10: This script assigns the correct permissions to all the executable programs in the kernel such br* file etc... Step 11: Then start the SAP system

startsap r3

Step 12: Now you can also check the kernel version level from SM51 or by selecting system à status

SAP Background Job Processing SM36: Create, Schedule, Reschedule What is a Background Job? Background job is a non-interactive process that runs behind the normal interactive operations. They run in parallel and do not disturb interactive (foreground jobs) processes and operations. It is scheduled from SM36. You can analyze it from SM37 by viewing its job log.

Advantages of Background Jobs   



It reduces manual effort & automates the task. It can be scheduled as per user's choice. It reduces user interaction and can run seamlessly in the background without user input Once you define the variant for background job, the user doesn't have to worry about value input in the field. Thus, user confusion is also reduced.



Ideal for time- consuming/resource intensive programs which can be scheduled to run in the night(when system load is low).

Background jobs are classified into three categories -

1. Class A (High/critical Priority): - Some tasks are urgent or critical and must be scheduled with class A priority job. Class A priority reserves one or more background work processes. Users have to decide how many background work processes should be assigned to Class A priority job. Suppose a user chooses 2 background work processes for this category then available background work processes for class B and C = (Total number of work processes set in operation modes RZ03)- (Background work processes allowed to class A category). 2. Class B(Medium Priority): - Once Class A jobs are completed , Class B job will start executing in the background before class C jobs. 3. Class C(Low Priority): -It runs after both class A and class B jobs are completed.

Possible status of background jobs

1. Scheduled: - You have defined the program name and variant but not defined start condition like Start Date, End Date, Frequency etc. That means you have not defined when a job should be scheduled in system. 2. Released: - All required criteria are fulfilled for job definition. Start condition is must for the job to be in release status. 3. Ready: - All the required conditions are met to run the job in a background workprocess. But job scheduler has put the job in the queue because it is waiting for background workprocess to be free. 4. Active: - Job has started running in the background. We cannot change the status of the job once it is in Active status. 5. Finished: - Job is executed successfully. It means the desired task is competed without any error. 6. Cancelled: - There are two possibilities for this. The Administrator has forcefully canceled the job or there might be some issue with job. You can investigate this from Job logs.

How to schedule the background job?

You can schedule the background job using SM36. Planned or immediate jobs can be scheduled.

Step 1) Execute T-code SM36.

Step 2) Fill the job name, priority(A/B/C) and the target server. Background jobs once scheduled on a target server run on that server. Main purpose of defining target server is the workload balancing.

Step 3) Click on "spool list recipient". You will get output in your mailbox. You can check email from SBWP.

Step 4) Insert your SAP username and click the copy button.

Step 5) Click Step button to define ABAP program, variant's details, etc.

Step 6) Define program name, variant details. 1. Enter your program name, Variant name in the field. If you have not created variant as per your requirement, then leave it blank.

2. Press save button.

Step 7) Once you schedule the job you will get the following screen.

Step 8) Click Start conditions to fill start date, end date, frequency, etc for job. If you do not specify start condition then job will always remain in scheduled status. A job in scheduled status will never run. 1. Click on Date/Time(For periodic jobs). If you click "Immediate" then job will start running right away. But it will not be set as periodic job. It's like "press and run." 2. Define job's start date/time, end date/time. The job will be released only once it meets its Scheduled start date/time. 3. Press periodic values.

Step 9) Click on Hourly/Daily/Weekly period to define the frequency of the job as per your requirement.We will select Other Period

Step 10) Here you specify the recurring criteria of the job.For example, You can have the Job run after every 5 days from the Start Date. Here we select job to run every 10 minutes

Step 11) Click on save button.

Step 12) Click on save again.

Step 13) Click save again

Step 14) Once Job step and start conditions are defined the following window will appear.

Step 15) Press save.

Step 16) Goto SM37 to know the status of the job.

Step 17) Select your criteria for the job which you want to monitor. 1. Put your job name and username who scheduled the job. 2. Select the status of the job. 3. Specify the date range. In our scenario, we just specify the end date while keeping From Date Open.

Step 18) You will get the following screen. Look at the status, it's a released means start conditions are met, and the job is in the queue is waiting for background work process to be free.

How to Reschedule a background job Rescheduled jobs will not run in the future. Remeber, you cannot deschedule the job once it's in active status.

Step 1) Execute SM37.

Step 2) Fill the criteria. 1. Job name and username by which job is scheduled. 2. Select the status. To deschedule the job you can only select Released/Ready status. 3. Specify the date range. 4. Press Execute(F8) button.

Step 3) Select specified job and press Job -> (Released -> Scheduled).

Step 4) You will find the message in the status bar once you press "Released -> Scheduled".

What is SAP Transport Request? How to Import/Export TR What is a Transport Request?







Transport Requests (TRs) – is a kind of 'Container / Collection' of changes that are made in the development system. It also records the information regarding the type of change, the purpose of transport, request category and the target system. It is also known as Change Requests. Each TR contains one or more change jobs, also known as change Tasks (minimum unit of transportable change). Tasks are stored inside a TR, just like multiple files are stored in some folder. TR can be released only once all the tasks inside a TR are completed, released or deleted. Change Task is actually a list of objects that are modified by a particular user. Each task can be assigned to (and released by) only one user. However multiple users can be assigned to each Transport Request (as it can contain multiple tasks). Tasks are not transportable by themselves, but only as a part of TR.

Change requests are named in a standard format as: <SID>K [Not modifiable by system administrators]   

SID – System ID K – Is fixed keyword/alphabet Number – can be anything from a range starting with 900001

Example: DEVK900030 Tasks also use the same naming convention, with 'numbers' consecutive to the number used in TR containing them. For Example, Tasks in the above mentioned TR Example can be named as: DEVK900031, DEVK900032 …



The project manager or designated lead is responsible to create a TR and assign the project members to the TR by creating task/s for each project member.





Hence, she/he is the owner with control of all the changes that are recorded in that TR and therefore, she/he can only release that TR. However, assigned project members can release their respective change tasks, once completed.

Workbench Request – contains repository objects and also 'cross-client' customizing objects. These requests are responsible for making changes in the ABAP workbench objects. Customizing Request – contains objects that belong to 'client-specific' customizing. As per client settings, these requests are automatically recorded as per when users

perform customizing settings and a target system is automatically assigned as per the transport layer (if defined). SE01 – Transport Organizer – Extended View

Create a Change Request



Change Request can be created in two ways: o Automatic – Whenever creating or modifying an object, or when performing customizing settings, the system itself displays the 'Dialog box' for creating a change request or mention name of an already created request, if available.

o

Manually – Create the change request from the Transport Organizer, and then enter required attributes and insert objects.

> Release the Transport Request (Export Process) 



Position the cursor on the TR name or a Task name & choose the Release icon (Truck), a record of the TR is automatically added to the appropriate import queues of the systems defined in the TMS. Releasing and importing a request generates export & import logs.

The Import Process

Importing TRs into the target system 

After the request owner releases the Transport Requests from Source system, changes should appear in quality







and production system; however, this is not an automatic process. As soon as the export process completes (releasing of TRs), relevant files (Cofiles and Data files) are created in the common transport directory at OS level and the entry is made in the Import Buffer (OS View) / Import Queue (SAP App. View) of the QAS and PRD. Now to perform the import, we need to access the import queue and for that, we need to execute transaction code STMS -> Import Button OR select Overview -> Imports It will show the list of systems in the current domain, description, and a number of requests available in Import Queue and the status.

Import Queue -> is the list of TRs available in the common directory and are ready to be imported into the target system, this is the SAP Application View, at the OS level it is also known as Import Buffer.

The Import Status

Import Queue shows some standard 'status icons' in the last column, here are the icons with their meanings, as defined by SAP:

In case, a request is not added automatically in the import queue/buffer, even though the OS level files are present, then we can add such requests by the following method, however, we should know the name of intended TR:

Import History

We can also check the previous imports that happened in the system as follows:

Transport logs and return codes 

After the transport has been performed, the system administrator must check whether it was performed properly or not, for that SAP has provided us with the following type of logs (SE01 -> GOTO -> Transport Logs):

Action Log – which displays actions that have taken place: exports, test import, import and so forth. o Transport Logs – which keep a record of the transport log files. One of the important information provided by logs are the return codes: o 0: The export was successful. o 4: Warning was issued but all objects were transported successfully. o 8: A warning was issued and at least one object could not be transported successfully. o 12 or higher: A critical error had occurred, generally not caused by the objects in the request. o



  

Diff between local client copy and remote client copy?.. Answer / Jayesh Shah Local Client copy mean Client copy in same server mean you copy Quality to quality and remote client copy mean one server to other server mean Production server to Quality server for local Client copy use SCCL Transaction Code and Remote client copy use SCC9, for Local client copy no RFC Connection req. for Remote client copy RFC Connection require.

   

Diff between local client copy and remote client copy?.. Answer / Sanjay local copy is made within 2 clients in single/same SAP system remote client copy can perform with a single sap system or from one sap system to another sap system in RFC connection method, for which we have to first define RFC communication

in SM59. the difference is only about the communication method.    

Diff between local client copy and remote client copy?.. Answer / Keshav Verma remote client copy can perform with a single sap system but its required two CI or from one sap system to another sap system through RFC connection use t code sm59 to make RFC and then copy through scc9 t code

Suspending Background Jobs during an upgrade downtime Hi We are upgrading to ECC 6.0 soon and there will be an extended downtime to facilitate the cutover. The downtime will cover two days so there may be some daily jobs that will fall twice within the downtime. If I run program BTCTRNS1 to suspend Background jobs, and the run BTCTRNS2 to recommence, will the daily jobs that were scheduled to tun twice during the downtime, actually run twice or will only the most recent instance run? Similarly for hourly jobs, when I run BTCTRNS2 will all hourly jobs that were due to run in the downtime, actually run when i execute BTCTRNS2 to recommence? Rgds Richie

What Is a Control File? Every Oracle database has a control file. A control file is a small binary file that records the physical structure of the database and includes: 

The database name



Names and locations of associated datafiles and online redo log files



The timestamp of the database creation



The current log sequence number



Checkpoint information

The control file must be available for writing by the Oracle database server whenever the database is open. Without the control file, the database cannot be mounted and recovery is difficult. The control file of an Oracle database is created at the same time as the database. By default, at least one copy of the control file is created during database creation. On some operating systems the default is to create multiple copies. You should create two or more copies of the control file during database creation. You might also need to create control files later, if you lose control files or want to change particular settings in the control files.

Performing a SAP on Oracle Full Backup

A full backup is the most comprehensive backup and is the baseline for incremental backups. Note: When you perform an offline backup from the CommCell Console, the database is shut down by default. You can set the sNOOFFLINEFORCE Additional Setting to Y to disable the forced database shutdown. You can specify database log only backups to start when the log files on the disk reach a specified percentage of the disk or the number of log files on the disk matches the specified number. For more

information on automatic log backup schedule policies, see Creating an Automatic Schedule for Database Log Backups.

Before You Begin 

Configure one of the following subclients: o

offline

o

online

o

consistent online

o

datafile

o

log

If the database is in NOARCHIVELOG mode, you must create an offline subclient. If the database is in ARCHIVELOG mode and database accessibility is a priority, create an online or consistent online subclient.

About This Task A consistent online backup includes the data and the offline redo logs that are generated during the data backup. When you perform a backup on a consistent online data subclient, the data is consistent because the offline redo log files created by BRBACKUP backed up with the database files on the same volume. The logs that are part of the consistent online backup are part of the data backup and included in the BRBACKUP summary file.

Procedure 1. From the CommCell Browser, expand Client Computers > client > SAP for Oracle >instance.

2. Right-click the subclient and click Backup. 3. On the Backup Options for Subclient dialog box, select the backup type and job initiation: a. In the Backup Type section, select the Full option. b. In the Job Initiation section, choose to run the backup now or schedule it. Note: If you selected Schedule, set up the schedule. For information on configuring a backup schedule, see Schedule Backups. 4. Click OK to close the Backup Options dialog box.

SAP for Oracle Backups You can back up SAP on Oracle databases, the control file, log files, or SAP on Oracle datafiles and tablespaces. You can back up the database when it is online or offline. If the database must be accessible and you have a small backup window, run a series of online backups for different database portions.

Full Backups SAP on Oracle full backups include the entire database and the control file. A full backup is the most comprehensive backup and is the baseline for incremental backups. Full backups of online databases include the log files.

Incremental Backups A SAP on Oracle incremental backup contains the changed data from the last full backup. Incremental backups use less media and resources than full backups.

Selective Online Full Backups A selective online full backup is a backup taken when the database is online. The backed up data is copied to a selective copy, which you can use for a restore. This backup is useful in disaster recovery scenarios because the data and logs are stored together.

What is Backed Up 

Oracle database files that include the datafiles and control files



Archived redo logs

What Is Not Backed Up Application files that are associated with the SAP on Oracle installation. Tip: Use the File System Agent to back up the application files. Note: You can configure the software to exclude the database application files from the UNIX file system backup. For more information, see Excluding Database Application Files from a UNIX File System Backup.

Performing Backups You can perform backups immediately or schedule them through the CommCell Console or by using the BR*Tools interface.

Job Restartability For information on the default rules and how to change them, see Changing the Default SAP for Oracle Backup Job Restartability Behavior.

SAP Profiles This article answers the following queries: 

What are SAP Profiles? Why are they needed?



What are the different types of SAP Profiles and their significance?



What is the path of profile directory in SAP?



What is the location of profiles in SAP?



Which SAP profile is used to define system wide settings?

 What are the contents of Default profile ( DEFAULT.PFL), Start Profile and Instance Profiles ? 

What are the naming conventions of various SAP Profiles?



If instance profile is modified, what needs to be done for the changes to take effect?



If default profile is modified, what needs to be done for the changes to take effect?

 What is the significance of cdpro command in SAP related to AIX or HPUX Operating systems? 

If an instance profile is modified is it required to restart entire SAP system?



What is the sequence in which SAP profiles are read by the SAP system?

 If some value is set for a parameter in default profile and in instance profile another value is set for an instance. For that instance which value will take precedence? Is it default profile value or instance profile value?  What is the sap parameter that is used to set the profiles path in an SAP system? In which profile it would be set? ---------------------------------------------------------------------------------------SAP R/3 systems uses Profiles to define the properties of an SAP R/3 Instance such as the type and number of work processes, the size of main memory reserved for SAP R/3 and various parameters like multiple logon, idle time out value etc There are 3 types of profiles in SAP. They are

  

DEFAULT.PFL (known as System Profile) Start Profile Instance Profile

All the profiles mentioned above are stored in the profile directory defined during installation of the SAP system. This path can be set using DIR_PROFILE profile parameter in the start profile. Ideally the path of profile directory would be In Unix Systems : /usr/sap/<SID>/SYS/profile or /sapmnt/<SID>/profile In Windows NT : \\<SAPGLOBALHOST>\sapmnt\<SID>\sys\profile Tip: Please note in AIX or HP-UX environment, we can go to the above profile directory location using cdpro command at Os level. All instances of a SAP system can read these profiles with share ( Systems based on Windows ) or mount (Systems based on Unix) technology. DEFAULT.PFL : This profile exists uniquely in an SAP R/3 system. It means if there are 5 application servers in an SAP system, even then there will be only one DEFAULT.PFL file. It contains system-wide settings which include 

Name of the SAP system



The database system



Name of the enqueue server

Each SAP R/3 instance to be started reads this profile first. The information specified in this profile is very vital for the functioning of the SAP system. START PROFILE : Unlike default profile, the start profile is specific to an instance. It means if there are 5 application servers each will have one separate start profile with the settings specific to an instance. The startup process of the SAP system is controlled by the start profile that is read by the start program [sapstart]. Here the services(eg: message, gateway, dialog , batch etc) that are to be started are listed. Hence every instance will have separate start profile. In other words, the start profile determines how, where and under what name individual SAP R/3 services and processes are to start. The naming convention of START PROFILE will be as below : START__ Eg: START_DVEBMGS00_prdserv4 For the start profile default names are assigned during the installation of an instance based on the services that are running on the instance. For example, DVEBMGS in the start profile above confirms that following services are available for that instance. D – Dialog V – Update E – Enqueue B – Batch M – Message G – Gateway S - Spool INSTANCE PROFILE : Like start profile, Instance profile is specific to an instance. It means if there are 5 application servers each will have one separate start profile with the settings specific to an instance. The runtime environment of the instance is configured in the instance profile. In instance profile parameters specific to an instance can be set like auto gui logout time(rdisp/gui_auto_logout), number of various workprocesses (rdisp/wp_no_dia), memory related parameters like abap/buffer_size, em/initial_size_MB, rdisp/PG_SHM, rdisp/ROLL_SHM etc The naming convention for the instance profile will be as below : <SID>__ Eg : SQ1_DVEMBSG00_prdsapk1 During the installation of an SAP R/3 system, the profiles are created with standard values. Later it is Basis administrator’s responsibility to tune the parameters. The source code of the SAP Kernel already sets standard default values for most of the system parameters. However, you must specify some specific details like computer name, system name and distribution of resources in the profiles. The SAP profiles are read during the startup of an instance. The values defined in the system profile (ie. DEFAULT.PFL) overwrite the standard settings in the source code. The values defined in the instance profile overwrites the parameter values of DEFAULT.PFL for the instance. In case of any changes to System Profile ( DEFAULT.PFL or Default Profile), you must restart all the instances of the SAP system as this is common for all instances. However in case of any changes to instance profile, it is sufficient to take restart of only that particular instance for the changes to take effect.

Sequence of SAP profiles that are read while starting SAP system :   

First start profiles of various instances are read by the sapstart program Secondly Default profile is read Finally, instance profiles of various instances are read.

Installing and Upgrading Add-Ons Use Add-On Installation Tool can process two different types of add-on delivery packages: add-on installations and add-on upgrades.

Only import packages when the system load is low, since users must not be logged onto the system and there should be no background jobs running. Otherwise, problems can arise, such as terminated transactions or problems with synchronization. If you want to minimize the downtime when installing add-on packages, you can perform the process in import mode Downtime-minimized.Add-On Installation Tool then performs many of the phases during production operation and prompts you to stop production operation. The tool also informs you when you can resume production operation. (See Import Mode: Downtimeminimized)

Prerequisites ● You are logged on in client 000. ● You have loaded the relevant installation packages into your system. ● You have selected the required installation mode in the Add-On Installation Tool settings.

Procedure

Since the add-on installation procedure is identical to the add-on upgrade procedure, the installation is used as an example here. 1. Call Add-On Installation Tool (transaction SAINT). The initial screen is displayed, listing add-ons that have already been installed. 2. Choose Start to begin the installation process. A screen now appears showing a list of installable Add-On Packages. 3. To search for additional installation packages in the current system’s EPS directory, choose Load. The system displays any new packages it finds. See Loading Installation Packages. 4. To prepare the installation queue for an add-on, select the add-on that you want to install, and choose Continue. This can have varying results: ○ The add-on cannot be installed in this system, as not all installation conditions have been met. If this happens, you are informed of the conditions in question. ○ Additional packages (Support Packages or CRTs) are needed for the installation. The system specifies which packages are missing. The installation does not start. Load the missing packages.

If errors occur during queue definition, read the queue calculation log. ○ If all installation requirements have been met, and all required Support Packages are available, the relevant queue is displayed (all packages that make up the installation in the correct order). You can now start the installation process.

5. You can now add additional Support Packages to the installation queue. To do this, go to the Support Package Selection tab page for each component that you require and select the highest Support Package that you want to import from the selection list. If you do not want to add any other Support Packages for a component, select the empty field from the selection list. The system automatically enters the Support Package Level of the chosen Support Package in the Level field. 6. Once you have selected the target Support Packages for all the components you require, choose Continue. The system calculates the maximum possible queue using the chosen target Support Packages and the installation queue that has already been calculated. The results of the queue calculation are summarized in the Status/Commentsection, whilst the resulting queue is listed in detail on the Installation Queue tab page. At the same time, the Support Package Level reached with the calculated queue is displayed on the Software Components tab page for each component, and linked to the Support Package Level of the chosen target Support Package using a comparison symbol. This provides you with a rapid overview of the result of the queue calculation. The queue calculation can have the following results: ○ The extended queue is consistent and corresponds completely to the target Support Packages that you have chosen. ○ The extended queue is consistent, but does not correspond completely to your chosen target Support Packages. For certain components, the chosen target Support Package levels could not be reached using the calculated queue, or more Support Packages from a component had to be included in the queue than had originally been required, in order to ensure a consistent queue. These variances occur because of the dependencies between

Support Packages from different components. These make it impossible to completely match the target Support Package levels that you have chosen. This can happen if you need to include Conflict Resolution Transports (CRTs). ○ The system could not extend the installation queue consistently. An error message is displayed to this effect.

If errors occur during queue definition, read the queue calculation log. 7. If the queue does not meet your requirements, choose Back to return to the Support Package selection. Modify your selections and start a new queue calculation. 8. If the queue does meet your requirements, choose Continue. 9. The system prompts you to decide whether to include the modification adjustment transports in the installation queue.

You can suppress this question in the Add-On Installation Tool settings. If you confirm the question, a dialog box appears containing a list of the available modification adjustment transports. a. If no adjustment transports are displayed in the list, you need to notify the system of the transports. To do this, choose Find Adjustment Transports. The system searches for adjustment transports in the Transport Management System import queue and in the transport directory on the application server. The system lists the transport requests that you have selected as modification adjustment transports and released in the export system.

For each adjustment transport listed, the Status field shows whether or not it fits the current installation queue and can be included. Adjustment transports that match the queue are already selected in the table. An adjustment transport "matches" the queue if the target Package status of the current queue is the same as the one in the export system when the modification adjustment transport is exported. b. If required, change the adjustment transport selection. You cannot select adjustment transports that do not match the queue. To hide adjustment transports that do not match the queue, choose Activate Filter. c. To add the modification adjustment transports to the installation queue and start the installation, choose Continue.

When a modification adjustment transport is imported as part of an installation queue, it is deleted from the normal transport flow for Workbench requests. Requests are not QAS) and production system (PRD), the modification adjustment transport is put into the QAS import queue after being exported from the DEV system. Including the adjustment transport in an installation queue in system QAS means that it is deleted from the QAS import queue. Since no transport forwarding takes place when importing an installation queue, the adjustment transport is not forwarded to the PRD system’s import queue.forwarded to follow-on systems automatically. If you are working with the classic three-system landscape comprising a development system (DEV), quality assurance system (

You then need to import the adjustment transport into the PRD system as part of an installation queue, using the same procedure as in the QAS. 10. A dialog box is displayed, where you can select the Start Options. Define your required start options and choose Continue. Conventional Import Mode If you have not changed the default start options, Add-On Installation Tool now performs the entire process in the dialog. At this stage, your system should no longer be in production operation. After starting installation, Add-On Installation Tool runs through a set series of phases. If errors occur in any of these phases, the installation process terminates, and a description of the error is provided. Once the problem has been corrected, choose Continue to restart the installation process. If you cannot correct the problem, you can reset the installation up to module Import 1 (phase SCHEDULE_RDDIMPDP, see Phases) by choosing Back.

In later phases, the content of the database has already been changed, meaning that you have no choice but to continue the installation process. Import Mode Downtime-Minimized If you have selected import mode downtime-minimized, some of the objects are imported inactively. You can continue using your system productively during this phase. a. Add-On Installation Tool performs all the usual preparation and test steps (module Preparation). It then runs through the import

steps for inactive objects that can be performed during production operation (module Import 1). The development environment is blocked when module Import 1 starts, thus ensuring that modifications do not endanger the consistency of the system. b. Add-On Installation Tool then displays a dialog box informing you that you need to stop production operation for the next import module (Import 2). ○ To stop the installation process and change the state of the system, choose Cancel. Terminate any background jobs that are running. Prompt all users to close any transactions they are working in and to log off from the SAP system. ○ To continue the installation process, choose Continue. c. Continue the installation process. The next phase activates the inactively imported objects and imports the remaining objects from the Installation Packages in the queue. Once these phases have been completed, Add-On Installation Tool informs you that you can restart production operation in your system.

This applies only if you have made either no or very few modifications to SAP objects. 11. If you have modified SAP objects but have not included any adjustment transports, or if the included adjustment transports do not cover all objects that need adjusting, Add-On Installation Tool prompts you to

perform a modification adjustment during one of the subsequent phases. To do this, proceed as described under Adjusting Modifications. 12. To complete the installation process, choose Continue. In the subsequent installation phases, program code and program texts that have been made obsolete by the imported objects are physically deleted from the database. The installation process is complete.

Logon group configuration in SAP This article answers following questions: How to configure/setup logon groups in SAP?  What are logon groups in SAP?  What transaction code is used for logon group configuration?  How to perform work load distribution in SAP system?  Explain the benefits of logon groups in SAP?  What are the advantages of creating logon groups?  What are the guidelines for creating logon groups in SAP?  What is the default logon group in SAP?  How to delete logon group in SAP?  How to check logon load distribution in SAP? -------------------------------------------------------------------------

Logon Groups: Logon groups (or work groups) are configured to dynamically distribute the load being processed by the dialog work processes. In many cases, SAP systems will have 2 or more sap abap instances. In these cases, logon groups can be configured to achieve dynamic distribution of dialog users on the ABAP instances. Setting up logon groups helps in uniform distribution of the work load across the available instances. While logging on using a logon group, the

ABAP message server is contacted to identify the instance with best performance statistics within the selected logon group. A report runs in SAP every 5minutes which determines the load across each server and updates in the memory area of the message server. This information will be used by SAP GUI to determine the best instance to distribute the next user. SPACE is the default logon group. By default, every instance of an SAP system (including central instance) is assigned to the logon group SPACE. This performs uniform distribution of the dialog workload. However, if you want to distribute users on some other criteria as following, you can create additional logon groups using SMLG transaction code. Other criteria: Logon groups according to SAP application / module: Separate logon groups can be setup for applications/modules such as HR, FI/CO, SD, MM etc. It means HR module users will be restricted to logon to identified instances, similarly other module users are allowed to login to their respective identified instances. The advantages of this method, is only the programs of the respective module are loaded into the program buffer of the particular instances of that logon group. Due to this, program buffer requires less memory and this helps to avoid buffer displacements thus improving system performance. Logon groups according to language, country or company division: If your SAP system is operating across multiple countries or languages, in that case it is good idea to create logon groups specific to a country or language. By this way the data and text related to specific country or language will be loaded into the buffers of the respective instances.

This minimizes buffer displacements and improves performance. Also less memory is required for the table buffer.

system

Logon groups for certain user groups: i)

ii)

We can setup separate logon groups for some department like sales whose work is performance critical. For that logon groups we assign instances which operates with high level of performance (e.g: high speed processors, less users per server, no background or update workprocesses configured or a dedicated network etc) Some department users may take time-consuming reports in dialog mode. For these type of users, you may have to create separate logon group

and assign an sap instance where profile parameter rdisp/max_wprun_time is set to very high In this way we can separate performance critical/resource intensive applications from others. Logon groups for the SAP Web Dispatcher: For direct ABAP web service requests, we can setup logon groups that the SAP Web Dispatcher can use. If logon groups are not configured for web dispatcher, the load is distributed to all ABAP instances on which ICM is configured. Also, based on URLs we can distribute certain group of requests to dedicated logon groups. Logon groups for ALE/RFC: Asynchronous RFCs are used to process in parallel. However if the parallel processes are not limited properly, they can occupy all the available processes which impacts dialog users and can bring down the application. So, it is good idea to create separate logon groups for incoming RFC calls so that RFCs are kept separate from workprocesses of online users and thus avoids impact to dialog users. Guide lines: After assigning instances to logon groups We need to verify whether the instances of logon groups are evenly distributed or not  If an instance hangs or temporarily got disconnected, you should be able to redistribute the users. So, you need to setup at least 2 sap instances for each logon group.  Setting up logon groups involves extra administration and monitoring. So, unnecessarily large number of logon groups shouldn’t be setup 

How to setup logon groups? SMLG transaction code is used for creating logon groups. Logon to SAP system and goto SMLG transaction as shown below:

In the above example there are 2 instances (00 and 09) in this SAP system. These are not yet assigned to any logon group.

We can create a new logon group by clicking on highlighted create icon on the above screen. It results in below screen.

In the above screen, either select logon group from dropdown or provide its name if you are newly creating. After that assign instance for that logon group and click on copy to save the assignment. In this example iam creating two logon groups hr and fico and assigning instances 00 and 09 respectively. Please find below screenshots which explains the same.

Repeat the same step and create logon group fico and assign instance 09 for it as shown above. After doing this, you can see following logon groups in SMLG

Once you are done with logon group setup, please log off from SAP system and goto SAPGUI of the respective SAP system.

Click on properties of the respective GUI entry and goto to connection tab as shown below.

Please select Group/Server selection option from the drop down of Connection Type as shown above and maintain description and system id of the instance as shown above. Now, you should be able to view the newly created logon groups as shown in below figure:

Also, please note you are able to view logon group SPACE also which gets created by default

Now, you can configure any desired logon group to the users as shown below:

For example in the above screen fico group is assigned to the end users in his GUI so that now onwards, he will login into instance number 09 only. How to delete logon group or assignment? If you no longer require any logon group, you can delete by proceeding as shown below: i)Goto SMLG transaction ii) Select the respective row and click on delete assignment which deletes the assignment of an instance to a logon group (highlighted in green color in below screen)

Click on delete icon above which confirms deletion of assignment iii)If you wish to delete logon group itself, then select the respective logon group and click on “delete group” in the above screen highlighted in red color (please refer screen 1 of point ii above). This deletes the logon group itself and removes all assignments related to this group. How to check logon load distribution in SAP? Goto transaction code SMLG as shown below and click on highlighted icon below to view the load distribution across instances

Alternatively, you can view this by navigating to Goto -> Load Distribution or by pressing F5 key in the above screen