Sunteți pe pagina 1din 98

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 ways-

1. 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
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.
Consult your SAP security documentation for detailed information about assigning SAP authorizations to users.

Object class object Field Values Details

Cross- S_RFC ACTVT 16 (authorizes Execute) Controls a user's abil

Object class object Field Values Details

Application Authorization RFC_NAME /ACLDL/DLINK7 function modules on

Authorization check for RFC DDIF_FIELDINFO_GET from a remote locatio
Objects access desktop computer.


Basis: S_TABU_DIS Direct Link users should be assigned Controls a user's acc
Administration Table authorizations for those SAP tables groups of SAP tables
maintenance they need to access in order to To control user acces
perform their analysis. For example, table level, use the S
a user performing a General Ledger authorization object.
audit needs authorizations for the
general ledger tables.
S_TABU_NAM Note Controls a user's acc
Table SAP tables.
Your organization's own business
maintenance 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_BTCH_JOB JOBACTION RELE (authorizes Release) Controls a user's abil

Background in background mode.
Operations on (a space between two single If you intend to use S
background quotation marks) servers for the proce
jobs Linkbackground jobs
enable the Batch me
The Batch message
enabled by default on
SAP server where th
is installed.

S_DATASET ACTVT 06 (authorizes Delete) Controls a user's abil

Authorization 33 (authorizes Read) and delete files on th
for File Access operating system of t
34 (authorizes Write) Note
Object class object Field Values Details

FILENAME * If stricter file security

S_DATASET authori
PROGRAM /ACLDL/DL7_DLINKBKGD configured so that us
/ACLDL/SAPLDLINK7 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

S_GUI ACTVT 61 (authorizes Export) Controls a user's abil

Authorization data from the SAP sy
for GUI desktop computer.

Configuring the Transport

Domain Controller

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


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

(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.


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.


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
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

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

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.


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.


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
 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

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
o Initiation of the Transport Domain / Landscape /
o Creating the user TMSADM
o Generating the RFC Destinations required for R/3
Configurations, TMSADM is used as the target login
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

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

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
 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
 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


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
 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
 Remote client copy in order to copy client beetween different SAP
 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

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
 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
 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<number> will hold the cross client data,

Request <S-SID>KT<number> will hold the client dependant data,

Request <S-SID>KX<number> will also hold some client dependant data.

 2nd Step : import

 Log on to the newly created target client using SAP* and password
 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<number> (client independant),

request <S-SID>KT<number> (client dependant),

request <S-SID>KX<number> (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
 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


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
 Go to "SAP Service Marketplace. "
(https:\\ You will need your OSS ID and
 Then go to Downloads à SAP Support Packages -> Entry
By Application Group -> SAP Kernel 6.00 64 Bit -> Select
Dependent and Database independent Kernel Patch.
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<ddmmyy>".
Step 2: Transfer these SAPEXEDB.SAR & SAPEXE.SAR
files which you have downloaded to the new directory at OS
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<ddmmyy>).
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<ddmmyy>". Take the backup of existing
kernel.Copy (only copy not move) the existing kernel from exe
directory to "exe_old<ddmmyy>"
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<ddmmyy> to the existing kernel directory exe

cp -rp /sapmnt/<SID>/exe_new<ddmmyy>/* /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
Step 9:
Then logon to OS level as root (specific to UNIX). In the
kernel directory, there is a script called Execute
this script

./ <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

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
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
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
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
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

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 ->

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
 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
 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<Number> [Not modifiable by system
 SID – System ID
 K – Is fixed keyword/alphabet
 Number – can be anything from a range starting with
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

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
 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 ->
 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
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
o Action Log – which displays actions that have
taken place: exports, test import, import and so
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.

 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

 Diff between local client copy and remote client copy?..
 Answer / Sanjay
 local copy is made within 2 clients in single/same SAP

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
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
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?
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

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.

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

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
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
 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 :

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 :
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 :
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

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: Downtime-
● 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.
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
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
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
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

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 system

performance. Also less memory is required for the table buffer.

Logon groups for certain user groups:

i) 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)
ii) 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
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