SAP Basis Howto

SAP Workload Analysis - Chapter 3 R/3 Memory Management

2012-02-01T09:17:00.000+07:00

R/3 memory areas introduces the various R/3 memory areas, which may be physically located in one or more of the following:

Local memory
Shared memory
File system

R/3 memory allocation explains what the different memory areas are used for.

After the demonstration and exercise, the topic Implementing R/3 extended memory compares memory management for different hardware platforms:

UNIX versus Windows NT

32 bit versus 64 bit architecture

This unit does not explain how large you should make the various memory areas.

R/3 memory areas

Users need two kind of memory:

R/3 buffers

Memory accessible to all users, for:

- Programs
- Table and field definitions
- Customizing tables

User context

Memory attached to individual users, for:

- Variables, lists, internal tables
- Administrative data (Such as authorizations)

Physical and Virtual Memory

Maximum virtual memory <= Physical memory + operating system

swap space.

Unlike physical memory, virtual memory can be allocated. The os determines if the allocated memory area resides in the physical memory or in the os swap space.

Depending on the os, the maximum size of the virtual memory may vary between the size of the os swap space and the sum of physical memory and os swap space.

R/3 buffers contain global objects for all users and work processes, such as programs and customizing tables.

Shared memory is associated with all the processes of one instance. It is allocated at instance startup.

Extended memory contains user contexts – that is, objects associated with individual users, such as variables, lists and internal tables.

Heap memory – allocated on demand

Contains user contexts, for example, when extended memory is full

Is allocated and released on demand

R/3 paging memory contains:

ABAP objects such as extracts

Context-independent objects such as exports.

The six R/3 memory areas are

Buffers

Extended memory

Heap memory

Roll memory

R/3 paging memory – not to be confused with os paging!

Local work process memory

R/3 Memory allocation concepts

In and R/3 system, many front end users are connected to one or more application servers. The work that users request from the system is performed in the work processes. Normally there are fewer work process than front end users.

A work process is dedicated to a front end user only while a specific dialog step is being processed by the application server. A user can be dispatched to one work process in one dialog step, and to another work process in the following dialog step. Over the course of time, users are dispatched to different work processes.

In course of their work in dialog work process, users accumulate various piece of data, such as pointers to programs they are using. This accumulated data is called the “User context”.

Roll in/ Roll out process

Roll area and paging area.

Roll area in which User context objects such as authorizations, set/get parameters, internal tables and report lists are available.

Paging area stores the application program data that corresponds to specific ABAP commands including EXTRACT, IMPORT TO MEMORY, EXPORT FROM MEMORY and CALL TRANSACTION.

The size of these areas is configurable using R/3 profile parameters.

Where there is buffer space available, the roll area and the paging area are held in the respective buffers in the application servers. When there is not sufficient buffer space, the roll area and the paging area must be stored in the respective physical disk files (roll file and paging file).

The user data processed in the work processes is stored in two areas:

The roll file and its associated buffer.

The page file and its associated buffer

User contexts are not only stored in roll files and the corresponding buffers.

In R/3 extended memory, a large area of memory shared by all available work processes can be accessed through pointers. Using extended memory as well as roll files thus reduces the amount of copying from roll areas that is required during user context switches, and avoids the overload caused by large roll – in or roll-out tasks.

Allocation sequence for dialog work process

To keep the usage of the roll area to a minimum and make more use of extended memory, only a small portion of the roll area is used initially. The size of this portion is set by the parameter ztta/roll_first.

Note : Independent of parameter ztta/roll_first, there is a minimum amount of roll area that is always used. For example, if ztta/roll_first is set to 1, not just one byte is allocated, but the minimum amount required for administrative data.

Extended memory enables the data to be stored in your system, where it is efficiently accessed by pointers rather than a copy process.

The extended memory per user may vary from 1 MB to several 100 MB.

When the extended memory is full or until the user quota is reached…

The user quota defines the maximum amount of R/3 extended memory that can be used by any one user, and is set with the parameter ztta/roll_extension.

The user quota thus prevents one user from occupying all available extended memory.

The remaining portion of the R/3 roll memory is used when the system can no longer allocate R/3 extended memory, either because R/3 extended memory is full or because the quota has been reached.

The reason for using the remaining portion of R/3 roll memory is to avoid using heap memory, which is local memory, and avoid entering PRIV mode.

If the work process requires still more space after using up all available roll area and extended memory, the system is forced to allocate R/3 heap memory locally.

Heap memory allocated by one work process is not accessible to any other work process. This means that a user is unable to continue the transaction in a different work process.

The user is now effectively locked to the work process. This situation is called PRIV mode.

Since R/3 architecture uses a limited number of work processes to satisfy a larger number of front end users, other users suffer when a user goes in to PRIV mode.

If several users go into PRIV mode, they can work well, but other users can hardly work at all.

Data in R/3 roll memory is copied during context switch.

Data in R/3 extended memory is mapped during context switch.

Data in R/3 heap memory can never leave the work process. If heap memory is allocated, the work process is exclusively assigned to one user in PRIV mode.

Note: the sequence in which memory is used by work processes is not determined by the amount memory initially allocated. Thus, while the entire roll memory is allocated on work process start, it is not initially used up completely.

The memory allocation strategy for dialog work processes aims to prevent work processes from allocating R/3 heap memory and thus entering PRIV mode

When a work process enters PRIV mode, it remains connected to the user until the user ends the transaction.

Allocation sequence for non-dialog work process

Freeing heap memory

If the heap memory consumption of a work processes exceeds abap/heaplimit, after ending the transaction, the heap memory is automatically released and the wp restarted to release the swap space.

OS swap space is saved through parameter abap/heaplimit

Memory management parameters

Ztta/roll_first: Defines the first part of the roll area that is allocated to a dialog process.

Ztta/roll_area: Defines the total roll area per work process.

Rdisp/roll_SHM: Defines the size of the roll buffer.

Rdisp/roll_MAXFS: Defines the size of roll buffer and roll file.

Em/initial _size_MB: Defines the fixed size of extended memory.

Ztta/roll_extension: Defines the user quota for extended memory.

Abap/heap_area_dia: Defines the limit for the amount of local memory allocated to dialog work processes.

Abap/heap_area_nondia: defines the limit for the amount of local memory allocated to non-dialog work processes.

Abap/heap_area_total: defines the total amount of heap memory allocated to all work processes.

Here we can see that the extended memory set is completely in use.

Call the Setups/Tune buffers monitor (ST02) and choose detail analysis menu-> SAP memory -> Mode list. Here we can see that several work processes need to allocate R/3 heap memory.

The Work process Overview (SM50) shows that the work processes that need to allocate R/3 heap memory enter PRIV mode. These work processes are locked to one particular user.

Implementing R/3 extended memory

—————————————————————–

Zero Administration Strategy

Since on NT the parameter em/max_size_MB has a default value of 20,000, the size of R/3 extended memory is limited by the size of the address space of the NT paging file.

The parameter em/initial_size_MB is operating system dependent in that it is restricted by the address space of the work process.

For 32 bit architecture, address space is < 4 GB (in some operating systems even smaller).

For 64 bit architecture, the address space is <1.8 * 10 ¹⁸ bytes.

SAP recommendations

For 32 bit architecture using em/initial_size_MB <=2GB, (even less for some os).

The amount of extended memory should be proportionate to the amount of physical memory.

The default value of ztta/roll_extension is 2 000 000 000 begin_of_the_skype_highlighting 2 000 000 000 end_of_the_skype_highlighting, which effectively deactivates this parameter. The limit for the user quota is given by the parameter em/address_space_MB.

One instance start, the extended memory is allocated by em/initial_size_MB

With NT, the amount of extended memory can increase dynamically upto em/max_size_MB, as long as the maximum virtual memory (that is , physical memory + swap space) is not yet exhausted.

There are no address space restrictions for extended memory, which is restricted only by the maximum virtual memory.

With NT, the recommendations for R/3 extended memory are more generous than under UNIX. However, parameter em/address_space_MB determines the user quota – that is the amount of R/3 extended memory, which may be used by one single user context.

The amount of extended memory should be proportionate to the amount of physical memory.

Hardware Capacity Verification

From Users point of View

Lengthy response time for transactions

From the systems point of view

CPU utilization is nearly 100%

High average number of processes waiting for CPU (load average)

High paging rates

Lengthy disk response times

Lengthy network response times – ping

Analyzing Hardware bottlenecks Road map – 1

Operating System Monitor – ST06

CPU idle < 20% ?

i. Is there CPU capacity on other servers that is idle?
1. 1. Redistribute R/3 work processes and users.
ii. Operating system monitors – ST06 – Top CPU Processes
1. 1. R/3 work processes with high CPU utilization?
  1. a. Work process overview – SM50 or Systemwide work process overview – SM66
    1. i. Detailed analysis of report or transaction
2. 2. Database processes with high CPU utilization?
  1. a. Database process monitor – ST04
  2. b. Detailed analysis of SQL Statements
3. 3. External processes with high CPU utilization?
  1. a. Stop or redistribute.

If there is a CPU bottleneck:

If possible, redistribute load to other servers.
To find out which processes are using most CPU, in the OS Monitor choose Detail analysis menu -> Top CPU processes. If the processes have high CPU utilization, proceed as follows:
1. For R/3 work processes (‘disp + work’): Using the process ID indicated in Top CPU processes, identify the corresponding program name and user name in the Work process overview – SM50.
2. For database processes – identify corresponding long running SQL statements in the Database Process Monitor. To access this monitor, call transaction ST04 (database overview), and choose Detail analysis menu.
3. For external processes, find out whether the process can be stopped or redistributed.

Hardware analysis roadmap – 2

Operating system monitor – ST06
1. High paging rate (>20% of RAM per hour)?

i. Memory capacity free on other servers?
1. 1. Redistribute R/3 work processes and users
ii. File system cache > 10 % of RAM?
1. 1. Reduce file system cache
iii. Setups/Tune buffers monitor – ST02 : Mode list
1. 1. Programs / Transactions with high memory consumption.
  1. a. Detailed analysis of report or transaction.

In the OS monitor – ST06, note the amount of memory indicated beside Physical memory available .
Compare this figure with the paging rate.
1. To obtain the paging rate, dbl click Pages in/s. The paging rates for the last 24 hours are displayed in the columns Paged in [Kb/h] and Paged out [Kb /h].
2. If 20% of the total amount of physical memory is greater than the amounts indicated in these columns, you can normally be sure there is no memory bottleneck.
If there is a memory bottleneck:
1. If possible, redistribute load to other servers.
2. Check the size of the file system cache. If necessary reduce the file system cache to < 10 % of the total physical memory.
3. To identify users in their programs with high memory consumption, call the mode list for the extended memory. To do this, in the Setups/Tune buffers monitor – ST02, choose Detail analysis menu -> SAP memory -> Mode list.

Hardware Analysis Road map – 3

Work load monitor – ST03N
1. Wait time > 10% of response time

i. General performance problem
1. 1. High database time: database time >40% (response time – wait time)
  1. a. Detailed analysis of database
2. 2. Processing time > CPU time * 2
  1. a. Detailed analysis of hardware bottleneck
3. 3. Load time > 50 ms
  1. a. Detailed analysis of R/3 memory config. (program buffer too small?)
4. 4. Roll in/ Roll out time > 20 ms
  1. a. Detailed analysis of R/3 memory configuration (problems with extended memory or roll buffer?)

This part of road map guides you in analyzing workload data when looking for hardware bottlenecks:

Call the workload monitor – ST03N. In expert mode, choose detailed analysis -> last minute load. Select the current application server.
in the statistics displayed, a hardware bottleneck may be indicated if the following figures are significantly high:
1. Average wait time
2. Average load time and average roll time
3. Average database time

A high average wait time means all programs are running slowly and blocking the work process for a longer time. A high average load time and high average roll time mean that loading and rolling are slow. A high average database time means the database is running slowly and may indicate a hardware bottleneck on the database server.

From the statistics displayed, you can calculate the processing time as equivalent to the response time – the sum of wait time, database time, load time, roll time and enqueue time. A large processing time means the work processes are waiting for CPU while processing ABAP programs.

To calculate the processing time :

Processing time = Response time – wait time – Database time – Roll time – load time

= 6073 – 1562 – 2254 – 248 – 169 = 1840 ms

The processing time is thus more than twice the average CPU time:

1840 (processing time) / 546 (average CPU time) = 3.4

This indicates a resource bottleneck. In this example, the CPU bottle neck is caused by external operating system process consuming CPU.

Notice the large wait time, database time and load time.

To check for problems at operating system level, use the operating system monitor (transaction ST06). Notice high % CPU utilization: user 96%, system 4% , idle 0%.

Why is the CPU usage at almost 100% capacity?

From the operating system monitor – ST06, choose detail analysis menu -> Top CPU processes.

The DR_WATSON processes are not related to R/3 system or to the database and therefore are external processes.

One way of tuning the system in this case is to terminate the external processes that are creating an unnecessary load on the CPU.

Verify the solution by terminating the external processes and restarting the workload simulation.

Typically not all external processes but only the following runs on the database server:

R/3 work processes of the central instance.

The database processes required for the database.

These processes have to share the available CPU’s.

As the database server is being accessed from all application servers, the performance associated with the database access is critical for overall system performance.

Optimizing Memory configuration – 1

Memory for database (once per R/3 system)

Rule of thumb: 20% of the total physical memory (of all servers)

Memory of R/3 buffers (once per R/3 instance)

Approx. 500 to 800 MB (depends on applications used)

Memory for R/3 work processes

Approx. 12 MB per work process

R/3 extended memory

Approx. 10 to 20 MB per user

Optimizing Memory configuration – 2

Physical main memory (RAM)

Virtual memory should be < 2* the physical memory

Swap space

3 times physical memory

At least 2 GB

Workload

Number of active users

R/3 applications used

To check R/3 virtual memory allocation for a specific instance, in the Setups/Tune Buffers monitor- ST02, choose Detail analysis menu -> Storage. The total memory allocated for this instance is displayed beside virtual memory allocated. To this figure, add the virtual memory allocated to any other R/3 instance or database running on this server.

Compare the total virtual memory with the total physical memory. If the ratio is less than 3:2, you can normally be sure that there is no memory bottleneck.

If the ratio is greater than 3:2, check how much of the allocated virtual memory is really being used, especially in extended memory and the program buffer. To do this, in the initial screen of the transaction ST02, look at the columns Max. use [ KB] and In memory [KB].

Configuring CPU

For database : Rule of thumb : 10-30% of the total CPU of all servers.

Ensure that there is never a CPU bottleneck on the database server.

For update processing : Rule of thumb : 10 – 20% of the total CPU for all servers.

For dialog/background processing : No general recommendation for CPU per user.

CPU required depends on applications used.

Example on a server with 2GB memory :

R/3 Buffers (without roll and paging) : 700 MB

Program buffer: 500 MB

R/3 table buffers: 110 MB.

Extended, roll and paging in shared memory 1500 MB

18 work process 120 MB

Virtual memory allocated for R/3 2.3 GB

Memory allocated for database 500 MB

The following R/3 parameter settings are configured in the R/3 system used in this course:

Nametab buffers:

- rsdb/ntab/entrycount: 30 000

- rsdb/ntab/ftabsize: 30 000

- rsdb/ntab/irdbsize: 4000

- rsdb/ntab/sntabsize: 2500

Program / CUA/ presentation buffers:

- abap/buffersize: 500 000

- rsdb/cua/buffersize: 5000

- zcsa/presentation_buffer_area: 20 000 000

- sap/bufdir_entries: 4500

Table buffers:

- zcsa/table_buffer_Area: 70 000 000

- rtbb/buffer_length: 40 000

SAP Workload Analysis - Chapter 4 Expensive SQL Statement

2012-01-31T09:19:00.000+07:00

SQL Statement tuning is a small part of database tuning, and is performed by many different people: R/3 System administrators, database administrators, ABAP developers, certified technical consultants.

Definition and consequences of expensive SQL statements

From user’s point of view:

Lengthy response time of transaction using the statement

Lengthy response times result if the database needs a long time to return the requested data to R/3 needs a long time to return the next screen to the user.

From the system’s point of view:

Many data blocks are scanned to find the selected records.

Monitors for detecting and analyzing expensive SQL statements

What to detect:

Reports or transactions where DATABASE REQUEST TIME is a large fraction of response time
SQL statements with a HIGH NUMBER OF BUFFER GETS.

For each expensive SQL statement find out:

TABLE NAME
WHERE CLAUSE
INDEXES USED
Name of the REPORT OR TRANSACTION containing the statement.

For each expensive SQL statement:

To find out the name of the report or transaction that uses the SQL statement, use the:

Work process Overview (transaction SM50)

Transaction Profile (transaction ST03N)

To find out the names of the tables accessed, use:

SQL trace – ST05

Shared SQL Area – ST04 -> Detail analysis menu -> SQL request

Work process Overview

Database process monitor – ST04 -> Oracle session

To find out the indexes involved , use the EXPLAIN function in:

SQL trace

Shared SQL Area

Database Process Monitor

Performance monitoring methods other than those based on checking statistics have drawbacks. The methods described here are all based on checking statistics.

The screen shows an example where the database request time makes up more than 95% of the overall response time.

The excessively large request time is likely to be due to expensive SQL statements. If so, an SQL trace (Transaction ST05) would be useful. Alternatively, the large request time may indicate a problem with the database server.

Depending on the workload caused by the expensive statements, other transactions may also be affected. These transactions show a large wait time and possibly also a large database request time.

Detection Roadmap – 1

1. In ST03N, go to the Transaction profile – Sorted by Response time total.

a. Programs where CPU time > 40% (Response time – wait time)

i Detailed analysis using ABAP trace (SE30)

b. Programs where database request time > 40% (response time – wait time)

i. SQL trace

a. Detailed analysis of SQL statement

This detection roadmap shows the procedure for the using the transaction profile, accessed through the workload monitor – ST03N.

Large database request times often indicate expensive SQL statement. Study the underlying SQL statement in detail using the SQL trace – ST05.

In the process overview, look for work processes with database actions such as sequential read, direct read, update, insert, delete and commit.

The amount of time that a work process is occupied by a report is indicated if greater than one second. If work processes are occupied for a long time by reports, the report name occurs repeatedly in the process overview, as well as the table accessed by the report. In this example, ZZSELECT is listed repeatedly in conjunction with table ZLIPS.

If work processes are occupied for a long time by reports, check for expensive SQL statements using Database process monitor – ST04; ORACLE session, and check for exclusive lock waits using the database lock monitor – DB01.

To check for expensive SQL statements and other database problems, use the database monitor. There is a database monitor for every database system.

Important statistics displayed in the monitor include:

Reads (logical reads)
Physical reads
Data buffer size and quality
Shared pool size and quality
Ratio of user calls to recursive calls
Ratio of reads to user calls

ST04 ; ORACLE session:

The following information is displayed

Client process (column Clnt proc)

In this column, the number before the colon is the PID of the related R/3 work process. Use the PID to identify the related R/3 work process in the work process overview – sM50.

Client system (column clnt system)

This column identifies the application server on which the related R/3 work process is running.

Status

SQL statements currently being executed on the database are marked active. Use the filter option to show only the active statements.

To find out the text of the full SQL statement, position the cursor on the relevant row and double click. From the subsequent screen, you can execute an EXPLAIN.

Database locks are set by, for example, the SQL commands select for update and update. Exclusive lock waits can suddenly reduce system performance. To detect exclusive lock waits, use the Database lock monitor – DB01.

If an exclusive lock wait occurs:

Monitor the program which is holding the lock, using for ex, the database process monitor – ST04; oracle session. Is the program executing expensive SQL statements after setting a database lock? As rule of thumb, all expensive SQL statements must be executed before setting the first lock.

Find out the user holding the lock so it can be released. If this is not possible, delete the lock so that other users can work. This will roll back the transaction of the lock holder. The transaction may need to be repeated. For ex, the seller may need to take the order a second time.

Database locks are generally released at the end of a dialog step or by an explicit commit.

Detection Road map -2

Work process overview – SM50 and SM66
1. Work process in status running.

i. Action/reason: “Dir.read”, “Seq.read”, “Insert”, “Update”,”delete”, “commit”
1. Database lock monitor – DB01
  1. Wait situations due to database locks (Excl. lock waits”)?
    1. i. Analyse lock holder
2. Database process monitor – ST04; Oracle session
  1. Detailed analysis: SQL statement
3. SQL Trace – ST05
  1. Identify and analyse the SQL statement in detail.

The SQL statement specifies a set of records in tables that it tries to locate. To find these records, the database must scan the corresponding data blocks.

All blocks that are not yet in the database buffer must be read on the disk. Logical reads or buffer that are read from disk.

A statement is efficient, if the optimizer can use an index that limits the number of blocks that must be scanned, thus reducing the number of buffer gets.

A statement is expensive if many blocks must be read to find the required records.

To access the shared SQL area – ST04

Buffer gets : This column refers to the total number of buffers accessed by the statement. To find statements with a highest database load, sort the display using this column.

Bgets/row: This column refers to the average number of buffers accessed per record retrieved. Find statements with a high number of buffer gets per record. These can normally be tuned.

Executions: This column refers to the number of times the SQL statement was executed.

The program to which the SQL statement belongs can be identified using either:

The Where-used list option in the ABAP dictionary – SE12

The system wide work process overview – SM66 in conjunction with the database process monitor – ST04; ORACLE session

ORACLE only: To display the last call point of SQL statement in an ABAP program from within the shared cursor cache, choose Go to-> Display call point in ABAP program.

Your goal is to identify SQL statements which can be tuned. To display the actual statement being executed, go to shared SQL area – Shared cursor cache by calling transaction ST04, choosing Detail analysis menu and making selection appropriate for your platform. In the Shared SQL area, double click on appropriate now.

Statements generated by an ABAP program are displayed in upper case and quotation marks. For example : SELECT “MANDT”, “VBELN”,”POSNR” FROM “LIPS” WHERE …….

Statements not generated by an ABAP program cannot be tuned in R/3. These include:

Statements are displayed in upper case without quotation marks. They stem, for ex, from check report RSORATDB, or from SAPDBA (options such as –check, -next). If such statements generate the highest database load, schedule the DBA tool to be executed less frequently. Ex: SELECT SEGMENT_NAME, …. FROM DBA_SEGMENTS.

Statements selecting from R/3 basis tables such as DDNTT, DDNTF, D010L, D010INF and ATAB. These statements are displayed in upper case. If such statements generate the highest database load, there may be problems with the r/3 buffers. Check the buffer for swaps.

Ex: SELECT TABNAME, TABFORM, REFNAME FROM DDNTT WHERE……

Recursive statements (with oracle): These statements are displayed in lower case. Example: select file #, block#,ts# from seg$ where type#=3

The database interface generates SQL statements that are transferred to the database, which processes the statements and responds by sending data records to the database interface. If you activate SQL trace – ST05, record of the SQL statements, the response time of the database, and the number of records is written to the SQL trace file.

One trace file is written for each R/3 instance on an application server. Therefore, you cannot run more than one SQL trace at the same time in the same R/3 instance.

A large amount of data is written to the trace file. The standard size of the SQL trace file, which is 800 KB, is too low and should be increased to 16 MB (using parameter rstr/max_diskspace = 16 384 000).

Note: the network time contributes to the response time. Therefore, network problems between the application server and the database server are detected by an SQL trace.

In R/3 transaction ST05, allows you to activate and view SQL, enqueue, RFC, and buffer traces.

If the SQL trace was activated, to view the trace results, choose list trace. A screen is displayed like the one shown above, indicating the:

Time and duration of the respective database operation

Table accessed

SQL statement used

The lines with FETCH are part of the SQL statement in the previous row. For each FETCH, the number of records transferred between application and database servers as a result of the SQL statement are indicated in Column Rec.

To find out which fields and indexes exist for the table accessed, choose DDIC info.

To find out which index has been used by the database optimizer for the SQL, choose Explain SQL.

The where-used list helps you to find expensive ABAP statements for a specific table. You may, for ex, learn that a specific table is associated with performance problems by looking at the work process overview – SM50, statistical records monitor – STAD, or SQL trace – ST05.

If a table is used in many programs, the where used list may not be useful.

To obtain where used list:

Call the ABAP dictionary with SE12

Enter the name of table

Choose utilities -> where used list.

To view the program lines of a specific program displayed, double click the program name.

In the exercise that follows, use all of the analysis tools discussed in this unit to find expensive SQL statements.

You can only detect expensive SQL statements using the work process overview during the running of the transaction using the SQL statement.

Detailed analysis and tuning

Distinguish between two types of expensive SQL statements:

Type I : the statement scans many data blocks in the database and is expensive because many records are transferred to the ABAP program. Database performance is optional.

Type II: The statement scans many data blocks in the database but transfers only few records to the ABAP program. Database performance is not optimal – For example, due to an inefficient search strategy.

Analyzing the two types of SQL statements using SQL traces – ST05 reveals:

For type I: Average duration of < 5 ms per record or < 100 ms per FETCH. Data are transferred with optimal performance.

For type II: FETCH duration is more than 500 ms.

If you look at the Shared SQL area – sT04; detail analysis menu; SQL request for the two types of SQL statements, you find:

For type I, bufgets per record < 5. This is the optimal relation between the number of records processed and the number of data blocks scanned.

For type II, bufgets per record > 5. this non-optimal relation between the number of records processed and the number of data blocks scanned is caused by an inefficient search strategy.

A poorly qualified SQL statement is one which does not use an index correctly to access data. To identify poorly qualified SQL statements, in the Shared SQL area – sT04; detail analysis menu, look for expensive statements with a high number of bufgets per record.

In general, using indexes is recommended because they make data access more efficient.

Statements are regarded as poorly qualified if:

No appropriate index is associated with the table being accessed.

An incorrect index is being used.

An index is being used but a full table scan is more effective (For ex, for small tables or where a large number of records are retrieved)

Note: do not change the standard R/3 index design unless this is recommended in an SAP note.

To find out whether an SQL statement uses an index to access the database, use the EXPLAIN function on the SQL statement. EXPLAIN can be accessed from any of the following:

SQL trace – ST05

Database process monitor – ST04;oracle session

Shared SQL area – ST04;Detailed analysis menu.

After choosing explain, to find out the index structure or the structure of the table and all associated indexes, double click on the index or table name. This also reveals information about the statistics used by the cost-based optimizer, such as when the statistics were last refreshed.

For example, a statement is expensive if an index is missing, thus making it necessary to use to full table scan.

Even an index range scan can be expensive if the index is not selective or not utilized properly.

Using explain function tells you which techniques are used by the database when executing an SQL statement. For ex:

When using an index range scan , the database retrieves a number of records using an index to limit the results before going to the data pages. This may not make access more efficient, for example, if only non-selective columns are evaluated by the index, or if the wrong index is used.

When using an index unique scan, the database retrieves a single row from an index. This access method is very efficient.

When using full table scan, the database retrieves all rows from the table to build the set of results. This is normally inefficient, unless, for ex, table is small or the application genuinely needs all the rows in the table.

When using concatenation, the database makes a union of a set of rows retrieved for the query. For OR / IN statements, concatenation normally makes access more efficient.

When using a sort, the database sorts the data before returning it.

When the database uses an index to retrieve data, explain tells you the index name. this helps you to recognize whether the database is choosing the wrong index.

SAP Workload Analysis - Chapter 3 Database Locks and R/3 Enqueue

2012-01-30T09:20:00.000+07:00

In the work process overview – SM50, you can see that session B is not responding during a direct read for table NRIV. R/3 work process 405 has sent a SELECT SINGLE for table NRIV to the database and is now waiting for the database to return the requested data.

In monitor for database locks – DB01, you can see why there is no response to the database request. Session B, which is run by WP 405, tries to create a lock on table NRIV, which is already locked by the R/3 work process 494. In the work process overview, you can see that work process 494 is processing session A.

To resolve the lock situation, session A must either release the lock or be cancelled.

The waiting session B causes SAP work process 405 to be blocked, which may cause wait situations for other users.

Situations like the one described are typically not caused by break points, but by lengthy processing of ABAP statements or SQL statements after they set a database lock. The lock on the database is released after the dialog step of session A is completed, and triggers a COMMIT or ROLLBACK.

Using R/3 enqueues and database locks.

Use enqueues to:

Explicitly exclude concurrent dialog access to data, thus preventing logical inconsistencies

A program using only read access does not need to use enqueues: Isolation levels can be used to achieve read consistency if necessary.

Database locks:

Are used in some special cases during the update phase

Should not be used in a dialog program

Exception: number ranges (SELECT single for update)

Locking and performance

Enqueues and database locks on central objects can serialize running transactions.

Avoid serialization:

In general, perform locks only when necessary

Keep locking times as short as possible:

For example, use array operations instead of single record insert/updates

For example, pre-aggregate data to enable one update instead of many

For number ranges: Fewer requirements cause less serialization

For available-to-promise quantities (ATP): additional logic can help to reduce locking times, especially over dialog steps.

For many enqueues, use bundling in a local enqueue container.

Use these two screens to detect high CPU usage on the database server.

Screen A, the operating system monitor – ST06, indicates a CPU utilization of 90% for user processes.

Screen B, shows the top CPU processes (ST06; Detailed analysis menu -> Top CPU processes). This screen reveals that 85.2% of the 2 CPU’s available are being used by the database process with PID 142.

High CPU usage of database processes for long periods typically indicates expensive SQL statements.

The database process monitor – ST04; oracle session can be used to analyze high CPU usage on the database server caused by expensive SQL statements. The Database process monitor enables you to display:

Database processes and the associated client processes (typically R/3 work processes).

The SQL statement currently being processed. To reveal the statement, dbl click the oracle process name. This is useful for statements that run for at least several seconds – short-running statements that are not expensive disappear too fast.

Screen A, showing the database process monitor, indicates that database process 296 is associated with the client process 494 on machine TWDFMX06.

After dbl clicking the line containing this oracle process, the database process monitor displays the expensive select on table ZLIPS: this statement is expensive because ZLIPS has many records and where clause is not supported by a suitable index. The EXPLAIN function for this SQL statement would indicate that a full table scan is being used.

Screen B, showing the work process overview – SM50 for application server TWDFMX06, identifies process 494 as an R/3 work process that is currently processing program ZZSELECT.

SAP Workload Analysis - Chapter 6 R3 Table Buffering

2012-01-27T09:22:00.000+07:00

R/3 uses several buffers that are local to the application server and hold primarily run-time data:

R/3 repository buffers

Table buffers

Program buffers

R/3 GUI buffers

R/3 roll and paging buffers

R/3 Calendar buffers

Why table buffers?

By specifying that a table is to be buffered, you can reduce the database accesses and thus improve performance.

The difference in the time required for local R/3 buffer accesses and that required for database accesses is significant and affects:

Database server load (CPU usage, size of database buffer required)

Dispatch time for R/3 dialog steps (avoids blocking R/3 work process)

Table buffering types

There are three types of table buffering:

Full buffering (“resident buffering”) : 100% of a table’s content is loaded into the buffer on the first access to any data from the table.

Generic buffering: a number of generic key fields (first n key fields) is specified when setting this option for a table. When accessing any data, all data records whose first n key fields are the same as those in the data accessed are loaded into the buffer.

A typical case of generic buffering is client-independent buffering, where the client name is the first key field. If you specify resident buffering for a client – dependent table, the ABAP dictionary automatically uses generic buffering with one key field.

Single record buffering (“partial buffering”): only single records are read from the database and loaded into the buffer.

All three table buffering types can be seen as special variants of generic buffering:

For full buffering, n = 0

For generic buffering, 0

For single record buffering, n = all key fields.

Buffer Synchronization

Two things happen when a buffered table is updated:

The update is executed on the database table.

The buffer of the local R/3 instance on application server A is either updated or contents are marked as invalid and reloaded on the next access.

An R/3 system landscape consisting of more than one R/3 instance: one R/3 instance on application server A and one R/3 instance on application server B.

The buffer of the non-local R/3 instance (on application server B) is not updated immediately.

The updating statement is executed by the R/3 database interface (DBIF), which inserts a record into the table DDLOG indicating the change to, for example, table T001

There are two profile parameters which control synchronization between buffers and the database:

Rdisp/bufrefmode

Possible values of this parameter are:

- sendoff, exeauto: used for a central system – an R/3 system with one R/3 instance.

- Sendon,. Exeauto: used for a distributed system.

Rdisp/bufreftime

- used to indicate the time interval in seconds.

A non-local R/3 instance (such as application server B in the diagram) performs synchronization every one or two minutes (depending on how the relevant profile parameter is set). That is , the instance reads database table DDLOG to check whether the tables in the instance buffer have been changed in another instance. If there have been changes, the instance invalidates some or all of the buffered tables that are affected by the changes.

In time period between synchronizations, users read the old data. After data is invalidated, on the next access to that data, the data is updated from the database.

Fully buffered tables: Any change invalidates the buffered table.

Generally buffered tables: Changes in work area mode invalidate data with the

same generic field keys.

Single record buffered tables Changes in work area mode invalidate one buffered record.

In the work area mode, only one line of a table (the work area) is used to transfer data. This occurs, for occurs, for ex, when using the ABAP command: UPDATE (where was defined using command tables ).

Changes not made in work area mode invalidate the whole table. This occurs, for ex, when using the ABAP command: UPDATE where =

Transaction SE13 (Technical settings -> change) allows you to select the type of buffering (or no buffering) for a specific table. The most important question is whether a table should be buffered at all.

A table should only be buffered if the table is read frequently and if it is acceptable from an application or business point of view that changes to the data in the table are not immediately visible on all other R/3 instances.

In addition to full, partial, and general buffering, another buffering type, “installation-dependent”, is sometimes used that enables a table to be initially not buffered, but later set to one of the above buffering types in the running system. This buffering type is used if the table can be buffered from an application point of view, but for ex, the size of the table and the amount of main memory (hence the space for buffering) vary with the R/3 installation.

Normally, the programmer has set a buffering type, which can be revealed in the access profile for the table.

SQL statements by-passing the buffer

SQL statements that cannot be satisfied from the buffer, bypass the buffer and access the database.

Statements that bypass any type of buffering should be avoided when programming with the buffered tables in order to optimize performance. An exception is maintenance transactions on buffered tables, which should use an explicit SELECT…..BYPASSING BUFFER to ensure the retrieval of the most-up-to-date data directly from the database.

Which tables should be buffered?

This slide shows some of the criteria that must be met in addition to the technical criteria, in order to make a table eligible for buffering.

The following rule of thumb can be also used to determine tables that are eligible for buffering:

For a table size of less than 1 MB, there should be no more than 1 % changes per read, and there should be at least 300 sequential reads/day.

For a table size of between 1 and 5 MB, there should be no more than 0.1% changes per read and there should be at least 1000 sequential reads/day.

Monitoring R/3 table buffering

Roadmap 1

This roadmap shows you how to leads you to find problems with table buffering problems:

1) Display the Workload Monitor (Transaction ST03) for task types Dialog and Update

2) For both respective task types, choose Transaction profile and sort according to response time

3) For the programs or transactions that have a large response time, look at the adjacent columns to find out whether they have a lengthy CPU time or a lengthy database time.

4) For transactions with database time > 40% (response time – wait time):

Analyze single records by Viewing statistical records using Transaction STAD.

5) To analyze statistical records with a lengthy database time, double-click the appropriate line.

6) To find out whether a buffer reload occurred in the corresponding dialog step, choose ‘%_and

check for the note Tables were saved in the table buffer.

7) If this note occurs for many statistical records, it indicates frequent buffer reloads.

The table buffer should be analyzed using the Table Call Statistics monitor (Transaction ST10).

To call transaction Table Call Statistics, use Transaction ST10 or, from the R/3 initial screen choose:

Tools -> Adminsitration -> Monitor -> Performance -> Setup/buffers -> Calls.

This roadmap helps you to decide which tables should be buffered.

1) Cll Transaction ST10, Select all tables since startup, and this server. Then choose Show

Statistics. The screen Performance analysis:Table call statistics is displayed, and contains a list

of tables and the related statistics. To sort the list by the figures in a particular column, place the

cursor anywhere in the column and choose Sort.

2) Sort the list by ,Buffer size (bytes) .

For the tables at the top of the list, consider the buffering rules and decide whether these tables

should be unbuffered.

3) Choose Next view and sort the list by Buffer size [bytes].

For the tables at the top of the list, consider the buffering rules and decide whether these tables

should be unbuffered.

4) Sort the list by column Rows affected under DB activity

For the tables at the top of the list, consider the buffering rules and decide whether these tables

should be unbuffered.

5) Sort the list by column Total under ABAP processor requests.

For the unbuffered tables at the top of the list, consider the buffering rules and decide whether

these tables should be buffered.

SAP Central User Administration (CUA)

2012-01-26T09:24:00.000+07:00

The procedure for Central user administration configuration in a landscape:
1) Create Logical systems to all clients for the landscape using BD54 or SALE ascomfortable.
2) Attach Logical system to clients using Same.
3) Create RFC connection to relevant systems with the same name as logical system name .
If you Logical system name is SIDCLNT100 for dev then create RFC connection to DEV with same name SIDCLNT100.
4) Let us suppose you Central system: DEVCLNT100Child system: QUACLNT200
5) Create user CUA_DEV_100 in devclnt100 system
4. Create user CUA_QUA_200 in quaclnt200 system.
Create RFC’s to child systems from central and central to child.
5) Now logon to central system and execute tcode scua to configure cua.
Enter the name of the distribution model: CUA
Press create
Enter ALL Child system RFC’s
Save your entries now result screen will appear
If you expand the nodes for
the individual systems, you normally see the following messages for
each system: .ALE distribution model was saved,. .Central User
Administration activated,. and .Text comparison was started.. If
problem messages are displayed here, follow the procedure in SAP
Note 333441:
6) Setting the Parameters for Field Distribution Enter Tcode SCUM in central system following screen will appearNow maintain your filed distribution and save it.You can use transaction SUCOMP to administer company address data.You can use transaction SCUG in the central system to perform thesynchronization activities between the central system and the childsystems by selecting your child system on the initial screen of transactionSCUG and then choosing Synchronize Company Addresses in the Central System
After you have synchronized the company addresses, you can transfer theusers from the newly connected child systems to central administration.
This is done, as with the synchronization of the company addresses, using
transaction SCUG in the central system. To do this, on the initial screen of
transaction SCUG, select your child system and choose the Copy Users to
the Central System button.
Use
You can use the report RSCCUSND from the central system of Central User Administration (CUA) to synchronize the master data of selected users with a child system of the CUA. The report sends the master data (including role and profile assignments) to a child system of the CUA.
If master data exists in the child system for the user sent, it is overwritten.
Procedure…
1. Start report RSCCUSND (for example, using transaction SA38).
2. In the Receiving System field, specify the child system to which you want to send the user data.
3. You can use the fields User and User Group to restrict the number of users.
4. Specify the data that you want to distribute under Distribution Options.
5. Choose Execute.

Oracle SAP Administration

2012-01-25T09:26:00.000+07:00

Administering an Oracle/SAP system, and maximizing the performance of its database, is a formidable job. You need to fully understand how both the SAP and Oracle systems work in isolation, and you need to know how they work together. In subsequent chapters of this book, I’ll describe the specifics of that interaction. You’ll learn how to use the special Oracle/SAP utilities, how to deal with the limitations of conventional Oracle functions, and how to place and reorganize files. Furthermore, after reading this book, you’ll know more about monitoring databases during operation, tuning them, running backup and recovery, and performing special operations for systems that use parallel technologies or that support unusually large databases.
This chapter presents the fundamentals of the SAP architecture and describes how Oracle fits into the SAP runtime system. It also explains fundamental Oracle/SAP concepts — the client/server model, special Oracle/SAP naming conventions, administrator roles, and basic administrative operations. First, though, let’s take a step back and look at what SAP is.
Introduction to SAP
The SAP system is a collection of software that performs standard business functions for corporations. The system has become very popular because it provides a complete solution to standard business requirements such as manufacturing, accounting, financial management, and human resources. It incorporates the concepts of enterprise resource planning (ERP) and business process reengineering (BPR) into an integrated solution for business applications.
SAP is a product developed and marketed by the German company SAP AG. SAP is a German acronym for “Systemanalyse und Programmentwicklung,” which can be loosely translated into “Systems and Application Products.” Founded in 1972 by IBM application developers, SAP AG originally developed application products for the European marketplace. For nearly two decades, the company grew slowly. Early versions of its software were mainframe-based and appealed particularly to very large European corporations. Within the United States, sales were mainly to the Fortune 500.
SAP’s R/3 System
During the 1990s, companies of all sizes began to embrace the concept of ERP systems and to gravitate toward prewritten business applications. With the introduction of its client/server SAP R/3 system in 1992, SAP AG, which already had a sizeable lead in the ERP market, unveiled a system that was attractive to medium- and small-sized companies as well as to the large companies already using SAP software. The SAP R/3 system runs on virtually any hardware/software platform and can use many different database management systems. One SAP system might be based on an IBM AS/400 running OS/400 using DB2; another might be based on a Sun Solaris (a dialect of Unix) using the Oracle RDBMS; still another might be based on an IBM PC running Windows NT using SQL Server. While SAP can be run with many different database products, nearly 85% of SAP customers now choose Oracle because of its dominance in the database marketplace. SAP software has become very popular in the U.S., and the company is now the world’s leading application package vendor. SAP competes directly with Oracle Applications products and PeopleSoft products in the ERP marketplace.
The SAP R/3 code is written in an interpretive language called ABAP. (ABAP is a German acronym that, loosely translated, means “Advanced Business Application Programming.”) ABAP is very similar to COBOL in its syntax. Use of the ABAP language allows SAP customers to extend the functionality of the base product, as described in the next section.
SAP Application Products
The SAP R/3 application offers end users the ability to run their entire business from a single application vendor. Some SAP customers choose to run their entire enterprise from SAP, while others run SAP only for specific business processes, such as manufacturing or finance. SAP is designed to allow customers to choose their own set of business functions, and it is sold in many configurations–both as specific business functions and as enterprise-wide solutions.
An SAP customer can choose whatever applications meet his site’s specific business requirements. In addition, the customer is free to customize his SAP installation, adding new database entities as well as new functionality. For example, a company may use an inventory method that is nonstandard but essential to the company’s efficiency; the basic SAP functionality can be modified to accommodate the specific requirements of that inventory method. The result of all of this flexibility is that virtually every SAP installation has its own specific configuration and set of functions. However, there are costs associated with customizing SAP. An organization that makes thousands of customizations to its SAP application may find itself spending millions of dollars to upgrade SAP: when SAP is upgraded, every customization must be identified in the ABAP code, and these changes must be reapplied to the upgraded SAP software, increasing the cost of the upgrade.
SAP products are distributed as applications with functional modules inside each application. Applications are generally focused on particular business functions. The modules within each application perform specific business tasks such as capital investment management, personnel administration, and quality management. The major applications are financials, human resources, and logistics, described briefly in the following sections.
In addition to basic business functions, SAP also offers products in the following areas (see http://www.sap.com/products/ for details):
SAP Business Intelligence initiative
SAP Supply Chain Management initiative
SAP Customer Relationship Management initiative
SAP Electronic Commerce
SAP Human Resources
SAP Treasury
SAP Real Estate
SAP Environment, Health, & Safety
When an SAP application is purchased with Oracle, each of the modules is delivered with a complete Oracle schema consisting of thousands of tables and indexes. Because the end user may purchase one or more components of SAP, SAP delivers the definition for many more Oracle tables and indexes than will be used by the running application. It is not uncommon to see an SAP application where thousands of tables and indexes are allocated but never used by SAP.
SAP has also branched out from traditional online transaction processing (OLTP) products into data warehousing with its Business Information Warehouse (BIW) and Supply Chain Optimization, Planning, and Execution (SCOPE) products.
Financials applications
The SAP Financials applications contain all of the functionality needed for enterprise-wide financial management. The modules within the Financials applications include the following:
Financial Accounting (FI)
Provides a complete financial accounting solution, including income statements, balance sheets, journals, ledgers, and all areas of financial accounting.
Enterprise Controlling (EC)
Assists in controller tasks.
Capital Investment Management (IM)
Assists finance organizations in their capital investments and tracking.
Controlling (CO)
Assists the controller organization.
Treasury (TR)
Assists with transactions related to the U.S. Treasury.
Human Resources applications
The SAP Human Resources (HR) applications are designed to provide a fully functioning HR system. They include two primary modules:
Personnel Administration (PA)
Assists with all areas of personnel administration, including applicant tracking and personnel history.
Personnel Development (PD)
Assists with training and educational status of employees.
These systems handle all of the mundane HR tasks, such as personnel and payroll, and also a number of more esoteric HR functions, such as seminar and convention management.
Logistics applications
The SAP Logistics applications include SAP’s most popular modules. Logistics was the first area of entry for SAP. This includes virtually every area of manufacturing, from the initial acquisition of raw materials to the delivery of finished goods. The modules in this area include the following products:
Materials Management (MM)
Manages raw materials, inventory, and all aspects of goods manufacturing.
Production Planning (PP)
Offers sophisticated tools for planning large production environments.
General Logistics (LO)
Manages logistics for companies that require large-scale deployment of goods and resources.
Sales and Distribution (SD)
Manages the inventory and distribution of finished goods.
Plant Maintenance (PM)
Manages the resources required for large manufacturing plants.
Quality Management (QM)
Captures and maintains quality control for manufacturing environments.
Project System (PS)
Assists with the scheduling of project tasks and interdependencies between tasks.
The SAP R/3 System Architecture
All SAP R/3 applications are delivered in a three-tier client/server architecture, shown in Figure 1-1.
Figure 1-1. The SAP three-tier client/server architecture

The three layers are:
Presentation layer
The PC-based GUI interface that is used by the end-user community.
Application layer
The SAP application servers that service requests for data and manage the interface to the presentation layer.
Database layer
The actual DBMS that communicates with the application servers to fulfill their requests for data.
A piece of “middleware” called BASIS links the application to the database and the operating system. BASIS is most commonly associated with the GUI interface to SAP (called SAPGUI), and the BASIS Administrator is an SAP professional who is responsible for configuring the SAP environment, including the GUI screens and the SAP application servers.
SAP end users log into their PCs using SAPGUI, and are connected to a specific application server. This application server has pre-established connections with the Oracle database, and it services all requests for data. As I mentioned earlier, the access language for Oracle data is SAP ABAP. ABAP generates Oracle SQL (Structured Query Language), which is then used to service the end user’s request for data. The communication between the application servers and the database, and between the client and the application servers, is TCP/IP.
While SAP is available for many different hardware platforms and operating systems, the majority of SAP systems use Unix-based servers for hosting SAP and the Oracle database. For this reason, as mentioned in the Preface, this book assumes the use of Unix in most examples.
The application server
While SAP uses the generic term application server to define a computer that receives connections from SAP clients, the actual connections are managed by SAP dialog servers.
A dialog instance is a software program that is running the SAP kernel (similar to an Oracle instance), and it is the job of the dialog instance to execute the ABAP programs and manage the requests for data and services. While there is generally a one-to-one mapping between an application server and a dialog instance, it is possible to have more than one dialog instance on an application server.
The central instance
The central instance is a concept that is unique to SAP. The central instance is a combination of hardware and software. It contains a physical server (the application server) and numerous software components, including a message server, a database gateway (a pre-established connection between SAP and Oracle–or another database), and various update, enqueue, dialog, and spool facility software. In most generic SAP architectures, there are numerous application servers but only a single central instance. However, in addition to managing the SAP interfaces, the central instance can also serve as an application server.
Bear in mind that SAP is very flexible, and there are many different ways to configure an SAP architecture to meet your business needs. However, most companies that implement SAP wisely choose to alter their business practices to accommodate SAP. By avoiding customization of its SAP application, a company can more easily upgrade its SAP software.
TIP: In 1998 SAP AG announced that the company is planning a four-tiered client/server architecture that will isolate the database from the SAP applications. Under the four-tiered architecture, the database will be insulated from SAP by the use of an active database cache called liveCache. This expanded memory cache will act as a separate layer, further insulating the Oracle database from the SAP application and allowing for the real-time manipulation of database objects.
Work processes
Any computer is capable of running one or more application servers. The main purpose of a dialog instance is to intercept requests for work from the SAP clients and to execute ABAP programs to service the requests for data. In addition, a dialog instance contains a dispatcher task and a set of work processes (WPs). The WPs are Unix tasks that can easily be identified by logging on to the Unix server and entering the following command:
ps -ef|grep dw
All SAP WPs contain the string “dw” (an acronym for Dialog Work) in their process names. The dispatcher on an SAP dialog receives requests from the SAP users (see Figure 1-2). In cases where a computer is running more than one dialog instance, there is one dispatcher for each dialog instance.
Figure 1-2. The SAP Dialog instance configuration

The WP is the task that is charged with executing the application’s tasks. As such, a WP consists of an ABAP language interpreter and processor, a task handler, and a means of connecting to the Oracle database. SAP defines several types of work processes, as follows:
Dialog (DIA)
Executes interactive dialogs
Batch (BTC)
Executes background tasks
Update (UPD)
Manages database updates
Enqueue (ENQ)
Manages resource locks
Spool (SPO)
Manages data formatting and printing
The WPs can be viewed from a variety of places via SAPGUI, the SAP management tool. In SAPGUI, each screen has a name, and the SAPGUI screen called SM50 shows the currently executing WPs on a dialog instance (see Figure 1-3). SAPGUI has more than 100 screens, but in this book I’ll focus on the major database screens. See Chapter 2, Oracle/SAP Utilities, for a discussion of SAPGUI and SAPDBA, the primary SAP utilities.
Figure 1-3. SAPGUI transaction SM50 displaying SAP work processes

The SAP system administrator, commonly called the BASIS administrator, controls the number of WPs that are defined to each application server. (See the “Oracle/SAP Administrators and Tasks” section later in this chapter.) In addition, the BASIS administrator can define “op modes” that control the number and type of WPs for each application server. For example, the BASIS administrator might define a day mode consisting of more dialog WPs for interactive sessions, and a night mode consisting of more batch WPs for the evening batch processes. These op modes are automatically switched by SAP according to the timetable specified by the BASIS administrator.
Oracle/SAP Naming Conventions
In order to maintain control over a vast set of applications, SAP has devised a convention for naming common components. These conventions are more than suggestions; in many cases, deviation from the naming conventions may cause some management components of SAP (e.g., SAPDBA) to function improperly. Thus, it’s very important that all SAP systems follow these naming conventions.
One firm rule relates to the Oracle table and index names. Obviously, the SAP table structures and table names cannot be changed without changing the ABAP programs that access these tables, and SAP strongly urges customers not to alter the Oracle entities without the express consent of SAP AG. However, the Oracle administrator does have control over the naming of some Oracle entities (tablespaces and datafiles) and their placement within the filesystems and disk devices. The main areas of concern for the Oracle administrator are the Oracle SID name, the name and location of the Oracle initialization file, and the names of the Oracle tablespaces and datafiles; these objects are described in the following sections.
The Oracle SID in SAP
SAP mandates that the Oracle SID (System IDentifier), specified in Unix and some other operating systems as ORACLE_SID, always begin with an uppercase “SA,” followed by a single alphanumeric digit or a single uppercase alphabetic character. Thus, the SID may have the values SA0-SA9 or SAA-SAZ. These are the only allowable choices for Oracle database SIDs. Throughout this book, I’ve used the notation sapsid to refer to the Oracle SID established for your own database.
The Oracle Initialization File (INIT.ORA) in SAP
Within an SAP system, the Oracle initialization file must exist with a specific name in a specific directory; if it does not, the SAPGUI and SAPDBA utilities will not work properly. Within both Oracle documentation and third-party books, the initialization file is ususally referred to as INIT.ORA, and I’ve followed that convention in this book. Note, however, that the actual name of this file in your system will be INITsapsid.ORA, where sapsid is the Oracle SID for your database (described in the previous section) and has the name you’ve specified for it. For example, if your Oracle SID is SA9, your initialization file will have the name INITSA9.ORA. In SAP systems, the intialization file must be located in the directory oracle//dbs; for example, oracle/SA9/dbs.
In addition to the basic initialization file, SAP allows configuration or subinitialization files to be called from the INIT.ORA file. Most Oracle administrators find it more convenient to place all of the Oracle initialization parameters in a single file; however, sometimes it makes sense to segregate different types of parameters into several files. For example, if your site is configured differently for transaction processing (during the day) and for batch processing (at night), you might include common initialization parameters in a single configuration (CONFIG.ORA) file but have separate INIT.ORA files for day and night processing. You’d restart with the appropriate INIT.ORA file for each time period. (This approach should not be confused with BASIS op modes.)
Within the INIT.ORA file, you must follow the SAP conventions for parameters summarized in Table 1-1.
Table 1-1: SAP Conventions for the INIT.ORA File
INIT.ORA Parameter Filesystem Destination
USER_DUMP_DEST /oracle//saptrace/usertrace
LOG_ARCHIVE_DEST /oracle//saparch/SAPSID_
BACKGROUND_DUMP_DEST /oracle//saptrace/background
AUDIT_FILE_DEST /oracle//rdbms/audit
CONTROL_FILES /oracle//sapdata-nn/cntrl1.data1
Oracle Tablespaces in SAP
In an SAP system, Oracle tablespace names always begin with the string “PSAP” and end with a “D” (data tablespace) or an “I” (index tablespace). Some of the common SAP tablespaces are PSAPCLUD, PSAPLOADD, and PSAPDICD.
A standard SAP system contains only a handful of tablespaces. These tablespaces are designed to contain all of the SAP tables, and are defined as a part of the default SAP installation. Figure 1-4 shows the sample tablespace descriptions for an SAP installation. Within an Oracle/SAP tablespace, many of the tablespaces will remain small–for example, the metadata information in the DICT tablespace.
Figure 1-4. Standard SAP tablespaces

SAP has segregated the Oracle tables into tablespaces according to their functions. As shown in Figure 1-4, each tablespace can be classified as a transaction tablespace, a BASIS tablespace, or an SAP system tablespace. Note that the SAP application has a system tablespace (called PSAPDICTD), just as the Oracle database has a system tablespace. The following sections describe these tablespaces. SAP folks disregard the leading PSAP in each tablespace and the ending “D” or “I” in each tablespace name. Hence, the PSAPSTABD tablespace is commonly referred to as STAB.
Transaction tablespaces
Transaction tablespaces hold the application data for individual transactions. These transaction tablespaces include the BTAB, STAB, and USER1 tablespaces:
BTAB
Holds the SAP transaction tables. These tables constitute the heart of SAP, and the Oracle administrator may choose to migrate the largest and most active tables into other tablespaces for improved data management.
STAB
Holds the SAP master data and transparent tables. These are normally the master reference tables for the SAP application holding commonly referenced application information.
USER1
Commonly defined to hold user customization tables that are not defined with the SAP software.
In an operational SAP database, these tablespaces will experience the highest read-write activity and will grow very large as your end users load SAP with their business data. Thus, you’ll need to monitor these tablespaces very closely, since they may fill and cause the entire SAP application to stop. Many Oracle/SAP administrators run scripts to identify the largest and most active tables in these tablespaces and move these tables into separate tablespaces. These separate tablespaces are then segregated by disk for better overall I/O management. Oracle administrators sometimes use file striping for these tablespaces to balance the load across many disk devices, and thereby improve throughput. I’ll describe SAP tablespace monitoring in some detail in Chapter 4, SAP Database Monitoring.
BASIS tablespaces
The BASIS tablespaces include BTABD, STABD, DICT, LOAD, PROT, and SOURCE. SAP uses these Oracle tablespaces to store data that is used to perform basic SAP system functions. For example:
PROT
Holds the output from ABAP reports while they are waiting to be printed, and contains spool, converter, and log tables.
SOURCE and LOAD
Contain the ABAP source code for reports and screens. In an SAP system, remember that ABAP is run in an interpretive mode, and the source code is gathered from these tablespaces at runtime for interpreting.
DICT
Contains the ABAP data dictionary, and consists of SAP metadata; in this sense, the DICT tablespace is very similar to the traditional Oracle SYSTEM tablespace.
System tablespaces
The most important SAP system tablespaces are POOL, CLU, and DOCU:
POOL
Used to store the SAP system pool tables. These are similar to the master data tables found in the STAB (transaction) tablespaces, but SAP considers them too small to require their own Oracle tables. The items from the POOL tablespaces are generally buffered and loaded into the memory of the dialog instance, so POOL is not heavily accessed except at SAP startup time.
CLU
Contains SAP cluster tables. Unlike Oracle clusters, SAP cluster tables are stored into Oracle tables with LONG RAW datatypes. The data within the LONG RAW columns are used by SAP as subtables, and each row within an SAP cluster table may contain data that is completely unrelated to the next row in the table. These pseudo-tables present a challenge to the Oracle administrator, especially when they must be reorganized, because you can’t use Oracle’s CREATE TABLE AS SELECT command with tables that contain LONG RAW columns. Consequently, reorganizations of the CLU tables must be performed with Oracle’s slower Export/Import utilities. I’ll discuss this topic in Chapter 5, Table, Tablespace, and Index Reorganization.
DOCU
Contains the document tables, including the sapscript and sapfind tables. This is a relatively small tablespace with fewer than 30 tables.
Oracle Files in SAP
In a typical Oracle configuration, you can map an Oracle tablespace to a single datafile or to many datafiles. Because of the large size of many SAP installations, an Oracle/SAP tablespace generally maps to many datafiles. In a production SAP environment, many of these tables will never be used, while other tables will grow very rapidly. Thus, in general, you should identify and segregate the highly active tables into separate tablespaces. Chapter 4 includes a script you can use to identify the SAP tables that are growing.
SAP is quite strict about the names for its default tablespaces, so you cannot change these names, but you can add new tablespaces. When you segregate SAP tables into a separate tablespace, however, you can name that tablespace anything you like. Although SAP gives you complete freedom in tablespace naming, SAP AG suggests that when a new tablespace contains a single table, the tablespace name be a permutation of the table name. For example, the table named VBAP could be moved into a tablespace with any of the following names: PSAPVBAPD, VBAPD, or VBAP. An SAP purist would preface the tablespace name with PSAP and end the tablespace with the letter “D.” This is helpful in order to be consistent with the other SAP naming conventions, and it can also be helpful when using SAPGUI to view tablespace information.
Oracle system files
While many standard Oracle configurations generally follow Oracle’s Optimal Flexible Architecture (OFA) standard, SAP has changed this standard somewhat, in an effort to create a “flat” file hierarchy (see Figure 1-5).
Figure 1-5. The Oracle/SAP file architecture

Note that $ORACLE_HOME is set to the same value as /oracle/, and all of the Oracle database software is located directly beneath this directory. For example, the Oracle executables are always located in /oracle//bin.
Oracle datafiles
Within SAP, Oracle database files are named somewhat differently from the way they’re named in traditional Oracle databases. The default SAP installation uses datafile names in which the prefix matches the tablespace name. For the filename suffix, rather than using a dbf suffix, SAP requires that datafiles contain the datan suffix. In this way, the Oracle datafile called psappooli.data3, for example, will be instantly recognizable as the third datafile for the POOL data indexes.
Oracle indexes
SAP also follows a standard for index naming. All Oracle index names default to eight characters in length; they always begin with the table name, end with a number, and use between one and three underscore characters in between. All indexes that end with a zero represent the primary key indexes for the table, and all nonzero numbers represent secondary indexes. For example, you will be able to tell that VBEP_ _ _0 is the primary key index for the VBEP table, and that VLPMA_ _1 is the secondary index for the VLPMA table. To properly display indexes within SAPGUI, all new SAP indexes should begin with the table name and end with a unique numeric character. Also, it is important that the index names be eight characters long, using a variable number of underscore ( _ ) characters.
SAP Filesystems on Unix
In addition to the required Oracle filesystems, some SAP-specific filesystems are found on most of the SAP application servers. These filesystems are used to hold certain Unix files that are required for SAP to function in the Unix environment. These include the SAP executable programs, SAP configuration files, and other SAP system-related datafiles, as follows:
/usr/sap/trans
This directory contains the common transport directory, .sapconf, as well as other SAP and Oracle configuration files. For distributed Oracle systems, this directory may also contain the master tnsnames.ora and sqlnet.ora files.
/sapmnt/
This directory stores system-wide files for SAP, including executables, global files, and profiles.
/usr/sap/
This directory stores instance-specific files for each SAP dialog instance.
The Oracle Database Layer of SAP
As you know, SAP is designed to work with many database management systems; interfaces are available for Oracle, DB2, Informix, and several other database products. Since SAP is database-independent, the SAP architecture requires the database to be defined as a part of the initial SAP installation. Once defined, the SAP programs (ABAP programs) will generate SQL that is compliant with the target database product.
Native Oracle SQL is generated by the ABAP program at runtime, and the SQL is then passed to Oracle for execution. The dynamic nature of ABAP SQL greatly increases its flexibility, but it makes it very difficult for the Oracle administrator to provide SQL tuning for Oracle. Because the SQL is generated from the ABAP at runtime, there is no way to change the execution plan for SQL by adding hints as you would in a traditional Oracle system. I’ll discuss this limitations of SQL tuning, and some strategies you can adopt to overcome it, in Chapter 6, SAP Tuning.
Viewing Connections to the Oracle Database
From Oracle’s perspective, the SAP application looks just like any other application. The SAP instance predefines a set of database connections that are created when the SAP instance is started, and these connections are held for the life of the SAP instance. In the example that follows (see Example 1-1), I’ve issued the following Unix command to display the processes for the ORACLE_SID called SA9:
ps -ef|grep -i sa9
This command displays the Oracle background processes (arch, pmon, reco), as well as all of the preestablished connections to SAP.
Example 1-1: The SAP Connections to the Oracle Database

sa9adm 94456 1 0 08:54:43 - 0:00 ora_arch_SA9
sa9adm 106746 1 0 08:54:47 - 0:00 ora_ckpt_SA9
sa9adm 71153 1 0 08:54:39 - 0:00 ora_pmon_SA9
sa9adm 15100 1 0 08:54:51 - 0:00 ora_reco_SA9
orasa9 72915 1 0 09:33:18 - 0:00 oracleSA9 (LOCAL=NO)
sa9adm 12118 30211 0 08:57:35 - 0:00 oracleSA9 T:I,,5
sa9adm 24665 30211 0 08:57:35 - 0:00 oracleSA9 T:I,,5
sa9adm 26179 30211 0 08:56:42 - 0:00 oracleSA9 T:I,,5
sa9adm 27494 30211 0 08:58:05 - 0:00 oracleSA9 T:I,,5
sa9adm 29528 30211 0 08:57:35 - 0:00 oracleSA9 T:I,,5
sa9adm 31300 30211 0 08:56:42 - 0:00 oracleSA9 T:I,,5
sa9adm 40034 30211 0 08:58:05 - 0:00 oracleSA9 T:I,,5
sa9adm 52567 30211 0 08:57:35 - 0:00 oracleSA9 T:I,,5
sa9adm 73573 30211 0 08:58:05 - 0:00 oracleSA9 T:I,,5
sa9adm 74088 30211 0 08:58:05 - 0:00 oracleSA9 T:I,,5
sa9adm 74852 30211 0 08:58:05 - 0:00 oracleSA9 T:I,,5
sa9adm 82796 30211 0 08:58:06 - 0:00 oracleSA9 T:I,,5
sa9adm 93799 30211 0 08:58:05 - 0:00 oracleSA9 T:I,,5

Flow of Data from Oracle to SAP
One of the confounding aspects of the Oracle/SAP architecture is the many layers that exist in an SAP environment. On its way to the SAPGUI client, Oracle data must be read from disk into the local disk cache, transferred onto the database server Journal File System (JFS) cache, then transferred into the Oracle buffer cache. Once the data reaches Oracle, it is shipped to the application server, where it is cached again before making the final trip to the SAPGUI client.
As you may know, memory buffers are used to save data from a prior disk read so that they do not have to be reread the next time the data is required. In an Oracle/SAP configuration, there are many layers of data buffers, and each buffer caches much of the same data as its predecessor (see Figure 1-6). However, this redundant caching does not mean that all of the extra data buffers are wasted. As data makes the trip from the disk to the SAP client, the data cached in each buffer is successively refined. For example, at the disk level, a physical I/O may result in an entire track of data being stored on the disk array cache. As the data reaches Oracle, only a single database block is cached. Once the data reaches the SAP application server, only specific row information will be stored in the SAP buffer.
Figure 1-6. The path of data from Oracle to SAP clients

Oracle/SAP Administrators and Tasks
Who does what in an Oracle/SAP environment? If you are accustomed to traditional Oracle environments (those not using SAP), you might find yourself confused by the very different roles within an SAP environment. For example, many Oracle DBAs are dismayed to learn that the Oracle software is installed by the BASIS administrator when the SAP environment is first established, and that they do not have any direct control over the installation process.
The next sections briefly describe the different roles you’ll encounter when using Oracle with SAP, as well as the functions for which each role is responsible.
SAP Functional Job Titles
In the Oracle/SAP technical arena, there are four major players:
The BASIS administrator (BA)
The Oracle administrator (DBA)
The system administrator (SA)
The network administrator (NA)
At many shops, these duties are shared–for example, the BA might also act as the DBA–but there are some generalities in job descriptions for these roles.
BASIS administrator
The BASIS administrator (BA) is responsible for the installation and maintenance of both SAP and Oracle. The BA is also responsible for the configuration of the SAP topology, the configuration of the application servers and central instance that make up the system, and the performance and tuning of the SAP application servers. In addition, the BA is charged with many administrative tasks that are typically performed by the DBA or SA in a generic Oracle database. For example, the BA is responsible for creating SAP users, maintaining passwords, defining printers and spools, and adjusting the number of work processes on each SAP dialog instance. A successful BA must have an intimate knowledge of the SAP environment and must act as a buffer between the end users and the DBA/SA staff.
Oracle administrator
The Oracle administrator (DBA) is responsible for ensuring that Oracle has been correctly installed by the BASIS administrator and for applying Oracle-specific maintenance patches.
TIP: Unlike administrators of traditional systems, the Oracle/SAP DBA generally contacts SAP AG headquarters before applying any patches to the Oracle database.
In addition, the DBA must ensure that the SAP objects (tables and indexes) don’t fully consume their tablespaces. The DBA is also responsible for database monitoring, performance and tuning, and periodic table and index reorganization.
System administrator
The system administrator (SA) is responsible for ensuring that the host servers are properly installed and configured. The SA is also responsible for the monitoring and performance tuning of all hardware devices. This can be a major undertaking because many large SAP landscapes have dozens of application and database servers. At many shops, the SA must develop an Oracle backup and recovery plan and must perform the Oracle database backups. While the roles for backup and recovery are shared between the SA and the DBA, in many SAP shops the SA works on the backup software (e.g., ADSM or Legato), while the DBA works with the Oracle component of backup and recovery (e.g., Oracle Enterprise Backup Utility or Oracle Recovery Manager).
Network administrator
Because of all the connections between each layer of SAP, the network administrator (NA) has an especially important role in the Oracle/SAP environment. The NA must constantly monitor the network, looking for bottlenecks and ensuring the smooth flow of data among all of the servers.
SAP Job Functions
The day-to-day tasks within SAP are also very different from those within conventional Oracle databases. Because of the special characteristics of the SAP architecture, many functional roles normally performed by the Oracle DBA shift to other administrators.
Oracle software installation
The Oracle software is installed as a part of the SAP installation process, which is performed by the BA.
SAP user administration
All SAP user administration and user security is performed by the BA. The rationale for this assignment has to do with the way end users connect to the Oracle database. In SAP, all end-user connections from the SAP application servers to the Oracle database are done with Oracle SQL*Net connections. This means that there is no need for any Unix userids. Also, the pre-established connections with Oracle are made with a single user (schema owner) called SAP R/3, so there is no need for specific Oracle userids.
SAP security administration
While this job is the primary responsibility of the BA, the SA and DBA play ancillary roles. The BA is responsible for creating SAP users and maintaining their passwords. The BA is also charged with all SAP application security.
The SA ensures the appropriate file permissions and controls the master SAP Unix account adm. (For example, the SAP system SA9 would have a master Unix account called sa9adm.) For Oracle, all SAP connections are done via the SAP schema owner, SAP R/3, so there is no Oracle role security to maintain.
The DBA ensures SQL*Net security for the connections between the application servers and the database server, and controls the password for the Oracle schema owner, SAP R/3.
WARNING: A breach of security for the SAP R/3 Oracle user could be a major disaster. Since the sapr3 user owns the entire Oracle/SAP schema, any or all of the database entities could be deleted if the sapr3 password were exposed.
Backup and recovery
This function is generally split between the SA and the DBA. The DBA has overall responsibility for the integrity of the Oracle database, including the online redo logs. However, the SA is usually responsible for writing the backup scripts and ensuring that the Oracle/SAP database is successfully transferred to tape. If recovery is required, the DBA requests the disk media restore from the SA; from that point on, the DBA is responsible for the database roll-forward activities.
Oracle maintenance
The installation of Oracle patches is performed by the DBA, but only after being given the go-ahead by the SAP AG company representative. SAP is only certified for specific releases of Oracle, and some Oracle patch upgrades could produce unwanted results.
Printer management
This function is split between the BA and the SA. The SA must install and define the printer, but it is the job of the BA to define the printer and a spool to the SAP system.
Problem resolution
This is the most confusing function within SAP. Because of the complex nature of SAP, a response-time problem could be due to any number of factors — database problems, network problems, hardware resource problems, SAP software problems, and many others. Thus, most SAP shops notify all of the administrators when a response-time problem occurs, and all parties work in parallel to examine the problem. The key to successful problem resolution within SAP is to ensure that all of the members of the technical team have a close and trusting working relationship

How to activate Industry Specific Solutions and Short Text Conversion

2012-01-24T09:27:00.000+07:00

A.Activating Industry Specific Solutions Like(IS OIL, IS RETAIL, IS MILL, IS MEDIA):
1) Go to T-code SPRO.
2) Click On SAP Reference IMG button.
3) Check for Activate SAP ECC Extension
4) Select Business Function Set as SAP oil and Gas.
5) Change Status Of All the business function to ON.
6) Accept Prompt For LicenseSO Add-on Has been Activated…(Running in background)
B. Short Text Conversion:
While SAP ECC or SAP R/3 uses terms that are linked to its industry sectors (material and plant in production, article and site in SAP Retail), in other components you will find the more universally-employed terms product and location.
1) Log on to your SAP system, client 000 as user SAP*.
2) Start report RSBRAN03 and fill the selection fields as follows:
BRANCHE: ISR
LANG:
All other fields remain default.
3)Run the report in background (F9).
4) After the job finished, reset the text buffers by entering /$SYNC in the command line.
Please note: Resetting buffers can significantly change the performance of the entire system. Nevertheless the reset of the buffers is necessary.
5) Please note that the report must be executed in every system separately.
Do not check CL_FORCE and UP_FORCE because they are reserved for SAP internal services.

Email Configuration(Sending Mail from SAP)

2012-01-23T09:28:00.000+07:00

Steps to Sending Internet Mail from SAP R/3
As of SAP Web Application Server 6.10, the SAP system’s kernel supports SMTP (Simple Mail Transfer Protocol) directly, meaning that e-mails can be exchanged between the SAP system and any SMTP-compliant mail server without the need for any additional external components.
SAP OSS Note 455140 can be referred for Configuring Internet Mail in SAP R/3 WAS 6.10 and above & the following steps are to be followed for the same;
Changing Profile Parameter (Txn RZ10)
Following 2 parameters to be included in the instance profile Parameters
is/SMTP/virt_host_0 = *:25000
icm/server_port_0 = PROT=SMTP,PORT=25000
Save/Activate the Profile & R/3 Instance to be stopped/Started
User Creation (Txn SU01)
This user will be used for the process of sending outbound e-mail from SAP R/3, as a background process.
User ID mailadmin user to be created with profile S_A.SCON & type is System User.
Client Assignment (Txn SICF)
In transaction SICF, there should be one SMTP server (called SAPconnect) supplied in every SAP system. Use this one for the first client then create (if required) an additional SMTP server for each additional client. Following settings are to be done;
Host data
Profile Parameter No. : 0
Service data
Client & user details entered (say client 100 with user mailadmin)
Handler list
Entered CL_SMTP_EXT_SAPCONNECT as item 1.
As of SAP Web AS 6.20, each SMTP server has to be activated (Service/Virt. Host ® Activate) after being created or changed.
SAPconnect Administration (Txn SCOT)
Make the SAPconnect settings in each client that is to be used to send communications.
Node
There is always one SMTP node in each client. This node is created by the SAP system and cannot be deleted. To configure the node for sending Internet mail,
Ensure you are in the Node view.
Double-click on the node name.
Select Node in use.
Specify the mail server (to which outbound mails are to be passed in Mail Host and
Mail Server : mailservername
Port : 25
Choose Set adjacent to Internet.
Specify the address areas of recipient addresses that are to be reached via this node. This is usually * if all e-mails are to be sent using SMTP. Enter output formats for SAP documents. The following settings are recommended here:
SAPscript/Smart Forms : PDF
ABAP List : HTM
Business Object/Link : HTM
RAW Text : TXT
Confirm.
Default domain should be given as follows
Txn SCOT à Menu Option à Settings à Default Domain à lntebg.com
E-mails sent from an SAP application are merely put into a queue. A periodic background process, known as the SAPconnect send job, takes the e-mails from this queue and sends them via the Internet. To schedule this job from SAPconnect administration, you:
Choose View ® Jobs.
If there is not already a job scheduled, choose Job ® Create.
Enter a job name “SEND INTERNET MAIL” and confirm.
Select the variant SAP&CONNECTALL by placing the cursor on it.
Choose Schedule Job.
Choose Schedule Periodically.
Enter an appropriate time period, such as 30 minutes.
Choose Create.

How to unlock SAP* and DDIC

2012-01-11T09:31:00.000+07:00

If SAP* and DDIC logins are locked and you are not able to login through SAP GUI then we can unlock SAP* and DDIC at database level by resetting the flags of SAP* and DDIC to 0 in the table USR02 where all the user records are saved. When the logins are locked out then the flag value will be 128. If we change it to 0 at database level then it will get unlocked.
Below is the query for resetting the flag
UPDATE prd.USR02 set UFLAG = ’00′ where MANDT = ’000′ and bname= ‘DDIC’;
Here prd is the database name; UFLAG is the field which we need to set to 0, MANDT represents in which client the login belongs to and BNAME is the field which contains logins. If you want to reset the flag for SAP* when it gets locked then replace DDIC with SAP* in above query.
or
1) Login to database using / as sysdba
2) select aname from sapsr3.usr02 where mandt=000;
3)delete from sapsr3.usr02 where aname=’SAP*’ and mandt=000;

SAP ECC6 EHP3 Upgrade

2012-01-08T09:35:00.000+07:00

Procedure:
1. Download EHP3 patches using solution manager mopz.
2. upgrade latest kernel, tp and r3trans.
3. extend the file system /usr/sap/trans – 25 GB and tablespace should not be full.
4. uncar all the addons and patches and put it in EPS/in.
5. transaction SAINT start
6. select all the components including addon patches.
7. ddic activation phase errors solve using the note no:1083533
DDIC Activation
- Activation errors may occur that can be solved by repeating the
activation phase. If errors occur, try to correct them.
- The following activation errors cannot be solved by repeating
the activation phase. For these, proceed as follows:
“Indexes 001 and KEY for table PFO_GO_00IS have identical
fields.”
In transaction SE11, call the table PFO_GO_00IS in change mode,
and choose the menu ‘Go to -> Indexes’. In the dialog box that
is then displayed, select the index ‘KEY’ and choose ‘Delete
Index’. Do not activate Index 001 or the table, but continue
with the import in transaction SAINT. A corrected version of
this table is delivered with EA-APPL 603 Support Package 01.
8. Complete the installation.

Default Clients in R/3 system and default users with passwords

2012-01-07T08:02:00.000+07:00

There are 3 standard clients in sap r/3 system. They are 000, 001 and 066. These three clients come with default users along with default passwords. I have listed in the following paragraphs.

What is a client: A client is an independent unit within the R/3 system or an area in the system with data on which a user works.

We have to do client copy right after installation of the software as our first job to begin the technical phase of implementation. We have to copy from one of the standard clients available. We can use copied clients for testing, training or for starting real customization.

We will discuss about what is data and what types of data is available in the sap R/3 system before going into the explaining of definition of the standard clients.

Data: The information residing in the database tables is called data. There are different types of data involved in the R/3 system. They are client dependent data, client-independent data and the client repository data.

Client dependent data: The data which is accessible through a particular client is called client dependent data. The user data is one of the examples of client dependent data.

Client-independent data: The data which can be accessible from any client or which is common to any client in the system is called client-independent data. The transaction code or t-code data is example of the client-independent data.

Client repository data: The different application programs which makes SAP runs is called client repository data. The transaction data, application data, customizing data are other different types of data of the sap r/3 system.

Standard clients of the SAP R/3 system:

000 Client: This client is called as master client in the r/3 system. This client is included in the sap r/3 system as default. We can find this client in the system as soon as we install sap r/3 software. Client 000 contains a simple organizational structure of a test company and includes parameters for all applications, standard settings, configurations for the control of standard transactions and examples to be used in many different profiles of the business applications. For these reasons, 000 is a special client for the R/3 system since it contains the client−independent settings. We can access the entire standard data with this client. We should not do any changes in the data through master client. The default users of this client are mentioned below along with default passwords.

User name: sap*
Password: This password will be set by the person during the sap r/3 installation
User name: ddic
Password: This password will be set by the person during the sap r/3 installation

001 client: This client is best example for customizing or development client and we can access entire customizing data. This client is a copy of the 000 client including the test company. This client’s settings are client-independent if it is configured or customized. This client is reserved for the activities of preparing a r/3 system for the production environment. The customers of the SAP normally use this client as a source for copying other new clients. The default users and passwords of this client are listed below.

User name: sap*
Password: 06071992
User name: ddic
Password: 19920706

066 Client: This client also called as early watch client which is reserved for sap access. SAP will access their customer systems using this client to perform the Early Watch service. SAP will generate the performance report of its customer system and this report is called as Early Watch report. The default users of this client are listed below.

User name: sap*
Password: 06071992
User name: earlywatch
Password: support

There are 3 standard clients in sap r/3 system. They are 000, 001 and 066. These three clients come with default users along with default passwords. I have listed in the following paragraphs.

What is a client: A client is an independent unit within the R/3 system or an area in the system with data on which a user works.

We will discuss about what is data and what types of data is available in the sap R/3 system before going into the explaining of definition of the standard clients.

Client dependent data: The data which is accessible through a particular client is called client dependent data. The user data is one of the examples of client dependent data.

Standard clients of the SAP R/3 system:

User name: sap*
Password: This password will be set by the person during the sap r/3 installation
User name: ddic
Password: This password will be set by the person during the sap r/3 installation

User name: sap*
Password: 06071992
User name: ddic
Password: 19920706

User name: sap*
Password: 06071992
User name: earlywatch
Password: support

What is SAP ?

2012-01-06T08:04:00.000+07:00

The query on regardless of whether SAP will be the finest Enterprise Resource Planning software package system on the market is something which is tough to response but one particular point is specified, SAP could be the biggest of all of them. Acquiring the largest industry reveal and more than forty thousand consumers throughout the world (in the US it’s reportedly utilized by 10 from the leading ten organizations, SAP could possibly claim it truly is without a doubt the best.

What are the attributes of this ERP System? Properly, SAP has all of the traits a great ERP system should have. It does all which is anticipated of it and after that a lot more. 1st it has the modular performance wherever it could provide answers for every one of the core facets of a business. It’s got modules for financials, human resource, warehousing and provide chain, client relations management (also called CRM), offline and online income management, etc. These modules provide sufficient overall flexibility this kind of that it may be reconfigured and custom-made according towards the requirements from the business.

Furthermore, it includes a builder’s suite that will be employed to build custom computer software the core modules can’t offer. SAP has its very own programming language called the ABAP or Sophisticated Business Application Programming which it utilizes to make custom apps. In the event you learn this language, deemed to get relatively simple, you’ll be set for a very good occupation in SAP consulting.

Getting widely used also affords it to get be on the list of most rewarding job choice for all those fortunate plenty of to have trained into it. SAP consulting is huge currently especially taking into consideration the number of organizations use this ERP solution for his or her business intelligence wants. Turning out to be a SAP professional is probably the best job route to consider right now should you be in a very skilled while in the area of business.

Why are SAP specialists in need? Effectively, fundamentally that is because of the fact that SAP has grown into these an enormous and difficult system that no person can maintain mastery about it. In-house personnel of firms adopting this system will almost never reduce it and for this reason they search for consultants who may have expended a lot of time honing their expensive knowledge to help them create their system.

So not simply is SAP one of the top rated business computer software solutions, it is also among the leading profession options. SAP is simply with the top today and it really is once and for all purpose and it is undoubtedly nicely deserved. SAP was borne out of a vision of 5 founding engineers for the business computer software application that will provide data in genuine time to help the company’s management in decision-making. It’s definitely arrived at that vision and in some cases surpassed it as it has become one of the greatest model of how filling a require is usually a fantastic business technique.

Jobs, Roles and Responsibilities of a SAP Basis Consultant

2012-01-05T08:04:00.000+07:00

SAP basis consultant should have primarily the knowledge of network administration. Then only he can install and configure operating system perfectly to install a SAP system. Because any SAP system mostly depend on the underlying database, he also should be able to install, configure and administer any type of relational database system. He should have through understanding about different computer programs or applications to use the sap system properly. He should be able to understand the complete structure and functionality of the entire SAP R/3 system. The following are the general day to day roles of a SAP basis consultant.

Basis consultant should be able to handle the administration of sap including the installation,configuration and maintenance.
Installation may include SAP R/3, ECC, Net weaver, Net Weaver components, Solution Manager etc..
He should be able to do user administration like creating and deleting users, assigning and resetting passwords, locking and unlocking users.
He should be able to do client administration like local client copy, remote client copy, create and deleting clients.
He should be able to create and restore data backups
He should be able to do printer or spool configuration and administration
He should be able to create RFCs and should be able to configure TMS (Transport Management System)
He should be able to monitor and manage the servers, background jobs, performacne of the system
He should be able to create roles using different methods like transactions, direct objects, missing authorizations, restrictions…etc
He should be able to analyze and fix missing authorizations
He should be able to do the sap license management
He should be able to troubleshoot security or authorization problems using SU53, ST01 and SUIM
He should be able to monitor the status of work processes, application servers and system logs etc…
He should be able to analyze the ABAP dumps
He should be able to manage the database space allocation
He should be able to do system copies
He should be able to rectify any type of problem related to opearing systems
He should be able to configure SAP GUI at client computers
He should be able to rectify minor networking problems
He should have through understanding of IP address configurations and pinging concept
He must able to troubleshoot any client or server problems

In my openion an SAP administraor is all one in computer industy. He must have knowledge in all the subjects like operating ssstems, databases, applications, security systems…etc

SAP ERP 6.0 Installation in brief

2012-01-04T08:07:00.000+07:00

ECC 6.0 installation is very easy to install in a desktop or laptop is very easy. You should have the entire software ready before installing ECC. You also should be ready with the sufficient hardware ready to install ECC software in your desktop or laptop. You should have server operating with latest service pack to install sap ECC 6.0 software. Windows server 2003 or 2008 is required to install sap ECC 6.0 sr2 or sr3.

Hard disk partitioning is very important to install sap ECC 6.0 in your desktop or laptop. you should have minimum 320 GB hard disk to install SAP ECC 6.0 sr2. You make the partitions as 20 GB for c and 250 GB for d and 50 GB for e. The operating system will be installed in C: and SAP will be installed in D: and software dump will be copied to E: drive

you should set the system time to something forward before starting installation of ECC 6.0. for example if you are planning to install the software today i.e. may 19, 2010 you set the system as may 19, 2021. Both the dates are representing same day (Wednesday). So that there is no confusion in determining dates and days. You can bring this date back to its original date as May 19, 2010 or May 20, 2010. Sap training software by default gives 4 weeks license. We can get more than one month by doing above date setting. We can practice sap modules for ever without having any license problems.

You keep the system name as per the name which is generated by your solution manager, because the installation/solman key works with the system name which generated by solution manager. You should be very careful in giving system name while installation of windows server 2003/2008.

You should install a dummy network adapter as you should have a network server to install ECC. So that you can install Microsoft loop back adapter to avoid the need of a networked computer. Microsoft loop back adapter makes the computer as a network computer and can be tested with self ping with the ip address which is assigned to loop back adapter. So that the computer with network is ready to install ECC in your standalone computer.

you have to set the performance settings from computer properties. You have to set the page file according to your installed RAM in your computer. You set this size as double as your installed ram. You can set this file either in your c or d drive. The minimum ram required to install sap ECC 6.0 sr2 is 2GB and recommended is 4GB. So the page file should be double of this installed ram.

The next step is Java installation. Install java software which will be available with the sap software. You can install it easily without any problem. You have to create JAVA Home and path in environment variables using system icon which will be available in control panel. you can check the java installation from command prompt after setting environment variables. you can check using java and javac commands.

Install oracle from the software provided with sap software. While installation of oracle software it will ask you to enter global database name, you should enter this as orcl two times and continue installation by answering all default. After completion of the oracle software the global database also will be installed and configured automatically.

You should see for the installation master in your sap software and apply oracle patches. You should search for the sapinst in your sap software and start the installation of sap ECC 6.0 by selecting ECC central instance for oracle database. Give all the paths of all exports and other software components as per the guidance of all screens. You will not have any confusion if you have proper sap software. You have to give database SID as you generated by solution manager and also ask you to enter solution manager key during the installation of ECC. You should have all this information ready before starting installation of sap ECC 6.0 sr2 in your desktop or laptop. This phase will take minimum 18 hours to finish. You should be very patient during this time. You can do other works or you can sleep during this phase of this installation.

You have to install GUI client software after completion of above step. This client software will be used to connect to your main sap software. So you can configure clients and can access your sap modules as per your interest. You can practice SD, MM, FI/CO, PP and ABAP modules using this software.

You can also ask me any more questions on installing sap ECC 6.0 sr2 or sr3 software on your computer or laptop. I will provide help at free of cost for some of the minor problems you face while installing sap ECC software. I will take nominal charges for major problems. So keep in touch with this blog for more updates on latest technology.

SAP Application Modules

2012-01-03T08:13:00.000+07:00

SAP has several layers. The Basis System is the heart of the data operations and should be not evident to higher level or managerial users. Other customizing and implementation tools exist also. The heart of the system from a manager’s viewpoint are the application modules. These modules may not all be implemented in a typical company but they are all related and are listed below:

FI Financial Accounting–designed for automated management and external reporting of general ledger, accounts receivable, accounts payable and other sub-ledger accounts with a user defined chart of accounts. As entries are made relating to sales production and payments journal entries are automatically posted. This connection means that the “books” are designed to reflect the real situation.

CO Controlling–represents the company’s flow of cost and revenue. It is a management instrument for organizational decisions. It too is automatically updated as events occur.
AM Asset Management–designed to manage and supervise individual aspects of fixed assets including purchase and sale of assets, depreciation and investment management.
PS Project System–is designed to support the planning, control and monitoring of long-term, highly complex projects with defined goals.
WF Workflow–links the integrated SAP application modules with cross-application technologies, tools and services
IS Industry Solutions–combine the SAP application modules and additional industry-specific functionality. Special techniques have been developed for industries such as banking, oil and gas, pharmaceuticals, etc.
HR Human Resources–is a complete integrated system for supporting the planning and control of personnel activities.
PM Plant Maintenance–In a complex manufacturing process maintenance means more than sweeping the floors. Equipment must be services and rebuilt. These tasks affect the production plans.
MM Materials Management–supports the procurement and inventory functions occurring in day-to-day business operations such as purchasing, inventory management, reorder point processing, etc.
QM Quality Management–is a quality control and information system supporting quality planning, inspection, and control for manufacturing and procurement.
PP Production Planning–is used to plan and control the manufacturing activities of a company. This module includes; bills of material, routings, work centers, sales and operations planning, master production scheduling, material requirements planning, shop floor control, production orders, product costing, etc.
SD Sales and Distribution–helps to optimize all the tasks and activities carried out in sales, delivery and billing. Key elements are; pre-sales support, inquiry processing, quotation processing, sales order processing, delivery processing, billing and sales information system

Each of these Modules may have sub-modules designed for specific tasks as detailed below.

SAP Support Packages

2012-01-02T08:14:00.000+07:00

What is Support Packs in SAP:

SAP releases Support packs, which are a collection of advanced corrections.

Types of Support Packages are listed below:

HR Support Package

ABAP Support Package

APPL Support Package

Basis Support Package

Add-on Support Packages

These are available for download directly from the SAP Service marketplace at below link

SPAM package download: service.sap.com/patches

On demand the Support packs available are sent in form of CDs to SAP’s customers. The system should be update by the designated personnel as early as possible. The support packages have certain dependencies and the same is to be checked on. Basis and ABAP support packages can be loaded independently whereas special care is to be taken while loading application support packages to include the CRTs of addon packages otherwise some conflict can arise and system can go to an unstable state.

How to apply Support Packs (SPAM package) to SAP :

After collecting the required information on CRTs and the like, the Support packs can either be downloaded from the SAPNET or uploaded from (Support packages) CD into the usr/sap/trans/EPS/in directory. The CAR files will also have to be extracted to the same directory.

Login to the system on client 000 – With any user-id other than SAP* or DDIC. The login-id should have SAP-ALL and SAP-NEW authorizations.

Run transaction code SPAM to invoke the SAP Patch manager. You can choose the upload button to upload data directly from /usr/sap/trans/EPS/in directory on the server or from a path on your local Front end.

Execute the “SPAM” transaction again. You will now be able to see the support packs window. Use the drop down box menu to verify the queue. The support packs will be in the queue followed by their corresponding CRT’s for the different add-on. Press the consistency check button to verify the queue is okay.

Go to the Menu Option settings on the SPAM screen and change the settings from ”S” to “T” (Standard to Test mode) The queue may be applied in test mode to check if it has conflict with any object that is already modified in the system. If there are any modifications to the program that the hot pack is also affecting, then the hot pack will create versions for the same. It will make the program delivered by it to be the current request the active version. Transaction “SPAU” (SAP Adjustments) will need to be run to make the required adjustments. If CIN programs are also affected, please check with SAP India.

Please Note:

Make sure that you have applied the latest SPAM update before you apply any other patches.

Always apply patches to your test system before you start to apply them to your production system!

Only the system administrator should be able to download, apply, confirm, or reset the status of patches. To use all the SPAM functions, you require the authorizations.S_CTS_TR_ALL and S_CTS_ADMIN. You can find both of them in the authorization profile S_A.SYSTEM

Ensure that you are logged into client 000 with the proper authorizations. If you log into another client, or do not have the correct authorizations, you can only use the display functions.

Make all the users log off before you apply patches in scenario ‘S’. During the patch application steps, the R/3 system must not be in use, i.e. only the system administrator is allowed to be logged on. Otherwise you risk program terminations.

Shut down all application servers except the central one for the duration of the import. Otherwise, buffer synchronization problems with program terminations, and possibly data inconsistency, may result.

You cannot have any incompletely applied patches in your system. To check this, under Directory choose Aborted patches and then choose Display. No patches should be displayed. Under the section Patch, the status should display a green traffic light.

Check the logs before confirming the patch application.

Never apply patches directly with tp. You will lose all of your modifications and overwrite your Add-On, if you have installed one. If you have made a modification adjustment for the Patch Queue in your test system, ensure that you do not import the resulting modification adjustment transport into further systems until you have applied the same patches to these systems.

While a patch is being applied the session is blocked. Open a second session before you apply the patch to avoid logging on again.

How to install Language using SMLT

2012-01-01T08:14:00.000+07:00

Language Installation in SAP with SMLT

Steps to install extra languages in to a SAP system.

1. Download Language DVD from SAP Service Market Place suitable to your SAP ECC version(e.g SAP 4.7, ECC 6.0 etc)

2.Place .PAT files to EPS/in folder.

3.Login to SAP in client 000 with Admin user.

4. Execute SE38

5. Execute program RSCPINST

6.Add an entry for the language you are willing to install.

7. Execute transaction SMLT

8. Create a new entry in SMLT for the required language. Give Supplementation language as English.

9.Click on the Import Language/Package symbol next to newly created entry for your language.

10.Default path is set to EPS/in folder, where it will search for the .PAT file required.

11.Found language should show either Green or Yellow button. If it is showing Red button it means you have downloaded the wrong source. Double check on SAP Service Market Place and download the right source files.

12. Press Execute to install the selected Language.

13.Monitor the import process in SM37 and Import transport logs.

14.Once installation get finished go to SE38, execute RSCPINST.

15. Click on Simulate button and copy new value for parameter zcsa/installed_languages.

16.Go back and activate the settings.

17. Go to RZ10 and change instance profile.Add new parameter zcsa/installed_languages and set its value as suggested in point 15 above.

18.Restart the SAP instance and try login with new Language.

19. Go to SE38

Execute RSTLAN_IMPORT_OCS

Select the newly installed language and press OK

It will show you the support packages whose language parts you want to import.

20. GO to Next screen.

Copy the PAR or CAR files to EPS/in folder for all support packages showing in RED.

This will import the language specific parts of those support packages.

Press Import Language Data and Overwrite.

It will show you the message “The Support Package Language Data was imported correctly.All system languages are up to date.

21. Next step is to copy the client specific data to required client.

Go to SE38 and execute RSREFILL.

22. Refference Language EN

Language to be updated Newly installed one

Update Mode I

Log Directory sapmnttrans*.snd

23. Go to SE38

Execute RSTLAN_SUPPLEMENT_UNI

Select your language from drop down

Press Client Maintenance with Customizing Translations

SAP Security Tasks

2011-12-31T08:17:00.000+07:00

Creating a user role

The easiest way to create a new user role is to copy an already existing user role, either one of your own or one of the ones provided to you in the installation of SAP. So let’s assume that you have none of your own and use one of the SAP role templates provided. It might assist you with picking one of these roles if you have someone dump the appropriate information into a spreadsheet containing the Role Name, Role Description, Transactions contained in the Role, and the Transaction description. The SQL query would be something like this:

SELECT AGR_TEXTS.AGR_NAME, AGR_TEXTS.TEXT, AGR_TCODES.TCODE, TSTCT.TTEXT
FROM AGR_TEXTS, AGR_TCODES, TSTCT
WHERE AGR_TEXTS.MANDT = ‘000′ AND
AGR_TEXTS.SPRAS = ‘E’ AND
AGR_TEXTS.LINE = 0 AND
AGR_TCODES.MANDT = ‘000′ AND
AGR_TCODES.AGR_NAME = AGR_TEXTS.AGR_NAME AND
TSTCT.SPRSL = ‘E’ AND
TSTCT.TCODE = AGR_TCODES.TCODE
ORDER BY AGR_TEXTS.AGR_NAME, AGR_TCODES.TCODE;

This query should be changed based on the details of your SAP instance. Identify the roles(s) to be used as the source for your role copy.

1. Log on to client needing the role.

2. Go to transaction PFCG.

3. On the Role Maintenance screen, either type in the role name to be copied or select it from a dropdown. Press Enter to confirm that the role exists.

4. Click the Copy role button or press Shift+F11.

5. One the Query popup box, fill in the to role field with the name to be given the new role. Come up with a standard that everyone follows so the base original role is designated in some way so you don’t forget where you got the original. The name must begin with Z or Y. Most people will add a Z- in the first two characters of the role name. If you want to only select specific roles from a Composite role, you would click the Copy selectively button, otherwise click the Copy all button.

6. Once the role has been copied, you will be taken back to the original PFCG screen where you will see the name of your new role. Change you Role description and save the new role before working with it any further

Modifying a user role

1. Log on to client needing the role change.

2. Go to transaction PFCG.

3. On the Role Maintenance screen, either type in the role name to be changed or select it from a dropdown. Press Enter to confirm that the role is found.

4. Click the Change Role little yellow pencil button role button or press F6.

5. Click the Authorizations tab and then the Change Authorization Data button.

6. On the Change Role: Authorizations screen, expand and change the authorizations you need to adjust. When finished click first the Save button and then the Generate button – looks like a little red and white beachball.

7. Back out to the Change Roles screen and click the User tab. Click on User Comparison and then Complete Comparison. Once the comparision is done, click Save one more time and you are done!

Deleting a user role.

1. Log on to client needing the role deletion.

2. Go to transaction PFCG.

3. On the Role Maintenance screen, either type in the role name to be changed or select it from a dropdown. Press Enter to confirm that the role is found.

4. Click the Role Delete button or Shift+F2.

5. On the Delete Role popup, confirm that you wish to delete the deletion. If you get an Information popup, confirm it also.

6. Your deletion will return a successful message in the bottom status bar.

(Transport System Method)

Transporting user roles between clients

When a modification is made to a role in the 100 client, the roles must be transported to the 800 client. One role, several roles, or all roles can be done if needed. They can all be added to the same transport change request. After the roles have been moved to other clients, you will need to log on to each of those clients and do a user comparison. You will also need to do a text comparison in client 100 of the appropriate SAP system.

1. Log on to client 100 of the appropriate SAP system.

2. Go to transaction PFCG.

3. On the Role maintenance screen, type in the Role name of the first role to be transported. Click the Truck picture-icon.

4. You will see an Information popup. Click the green √ picture-icon.

5. In the Choose objects popup, unclick the □s beside User assignment and Personalization. If you want to transport the users along with the role, profiles, and authorizations, you can √ the □ to the left of User assignment. Click the green √ picture-icon.

6. On the Prompt for Customizing request popup, click the blank page picture-icon to create a new change request. On the Create Request popup, fill in the Short description and click the Save picture-icon. You will be returned to the Prompt for Customizing request popup which contains the generated change request number for this system change. Click the green √ to continue.

7. You will see a Data entered in change request message in the status bar at the bottom of the screen. Now enter the name of the next role to be transported and click the Truck picture-icon.

8. You will see an Information popup. Click the green √ picture-icon.

9. In the Choose objects popup, unclick the □s beside User assignment and Personalization. If you want to transport the users along with the role, profiles, and authorizations, you can √ the □ to the left of User assignment. Click the green √ picture-icon.

10. On the Prompt for Customizing request popup, continue to use the same transport you created in step 6. Click the green √ to continue.

11. Continue to perform steps 7 through 10 until all the roles you need to transport have been attached to the transport change request.

12. The generated transport can now be released and transported into the clients needing the modified roles.

13. You may now leave the PFCG transaction.

Transporting User Roles between Clients (Upload/Download Method)

Central User Administration distributes clients and their information to the other clients connected to the Distribution Model. It does not, however, do the same for roles and role authorizations. So when a modification is made to a role in the 100 client, the roles must be transported to the 800 client. One role, several roles, or all roles can be done if needed. They can all be added to the same transport change request. After the roles have been moved to other clients, you will need to log on to each of those clients and do a user comparison. You will also need to do a text comparison in client 100 of the appropriate SAP system.

1. Log on to client 100 of the appropriate SAP system.

2. Go to transaction PFCG.

3. On the Role maintenance screen, type in the Role name of the first role to be transported. Click the Truck picture-icon.

4. You will see an Information popup. Click the green √ picture-icon.

7. You will see a Data entered in change request message in the status bar at the bottom of the screen. Now enter the name of the next role to be transported and click the Truck picture-icon.

8. You will see an Information popup. Click the green √ picture-icon.

10. On the Prompt for Customizing request popup, continue to use the same transport you created in step 6. Click the green √ to continue.

11. Continue to perform steps 7 through 10 until all the roles you need to transport have been attached to the transport change request.

12. The generated transport can now be released and transported into the clients needing the modified roles.

13. You may now leave the PFCG transaction.

Performing a User Comparison on the Modified Roles

1. Log on to client 100 of the appropriate SAP system.

2. Go to transaction PFCG.

3. On the Role maintenance screen, type in the Role name of the first role to be transported. Click the Change button.

4. On the Change Roles screen, click the User tab.

5. On the User tab, click the User compare button.

6. On the Compare Role User Master Record popup, click the Complete compare button.

7. You will receive a User master record for role was adjusted message in the status bar at the bottom of the screen. You may now leave the PFCG transaction.

Performing a Text Comparison to Refresh Role Selection Lists

1. Log on to client 100 of the appropriate SAP system.

2. Go to transaction SU01.

3. On the User Maintenance: Initial Screen screen, type in the user “model_user”. Click the pencil picture-icon.

4. On the Maintain User screen, click the Text comparison from child Syst. button.

5. On the CUA: Text comparison from Child Systems screen, type “LSDEV100” for the Receiving system and “LSQAS800” for the to system. This is a range, and since LSPRD300 falls alphabetically between LSDEV100 and LSQAS800, all three systems will have the text comparison performed. Click the clock picture-icon.

6. On the CUA: Text comparison from Child Systems results screen, you will see a list of the systems compared and the compare results. Click the white arrow on green picture-icon 3 times, or until you have left the SU01 transaction.

Users, Roles, and Authorizations

SAP security is based on authorization objects and authorizations. An authorization object is used to indicate that a user can perform a certain activity. An authorization is used to limit the scope of that activity.

For example, a profile contains the S_DEVELOP authorization object. This authorization object allows a user to perform ABAP workbench activities. Some users will need to do all ABAP activites while others will only need to perform a few. So S_DEVELOP has a selection of authorizations you can use: ACTVT, DEVCLASS, OBJNAME, OBJTYPE, and P_GROUP. The authorizations are set to the appropriate values as needed. A tree view of the S_DEVELOP authorization object can be seen below:

S_DEVELOP

ACTVT

Create or generate

Change

Display

Delete

Activate, generate

Execute

Create in DB

Delete in DB

Convert to DB

Administer

Copy

All Functions

Deactivate Mod. assistant

DEVCLASS

Single Value or Value Range

OBJNAME

Single Value or Value Range

OBJTYPE

Single Value or Value Range

P_GROUP

Single Value or Value Range

The S_DEVELOP authorization object in a profile lets a user perform ABAP workbench activities. But having a S_DEVELOP authorization object with the ACTVT authorization value set to Display (03) means that the user is limited to display only in the ABAP workbench transactions. Thus we see that authorization objects grant while authorizations limit. It is important to remember, however, that a user with a profile having a S_DEVELOP with full authorizations still cannot access an ABAP workbench transaction until a matching S_TCODE (start up transaction code) has been added as well. In other words, a user may have the rights to add, modify and delete ABAP programs but until an entry for SE38 has been added to the S_TCODE authorization object, he cannot access transaction SE38 which is the ABAP Editor.

All authorization objects and authorizations are grouped into profiles before being attached to users. Profiles use a combination of authorization objects and their respective authorizations, and their creation can be complex as well as tedious. In order to simplify the creation of profiles, the Profile Generator (transaction PFCG) was created. Roles are created via a more user-friendly interface which generates profiles based on the information added via this interface.

Manually creating profiles is the “old” way of doing things. There are times, such as the start of a new SAP landscape where no roles exist, that the use of profiles is handy. But once the landscape has been completed all users, with the exception of the Basis team, should be attached to roles. There should never be a need to manually create a SAP new profile. To add a new role, the easiest method is to copy an existing role that matches your needs as closely as possible and make the changes you need for the new role.

This documentation covers changing user security via both methods.

Adding Authorization Objects and/or Authorizations to a Profile

Remember that profiles are NOT the standard way to implement SAP security

1. Log on to the appropriate client in the appropriate SAP system.

2. Go to transaction SU02.

3. In the Manually edit authorization profiles section of the Profile: Initial Screen screen, enter the Profile you want to change. Make sure the Active only □ is checked. Click the Create work area for profiles button.

4. On the Profile List screen, double-click the profile to be changed.

5. A profile can contain authorization objects only (single profile) or one or more other profiles (collective profile). If the next screen is titled Maintain Profile, this is a single profile, and you should proceed to the next step. If the next screen is titled Collect Profiles, this is a collective profile and you should skip to step 13.

6. On the Maintain Profile screen, you must decide if you need to add a new authorization object and one or more of its authorizations, or add a new authorization to an authorization object already in the profile. If you need to add a new authorization to an authorization object already in the profile, skip to step 7. Otherwise, scroll down the Consisting of authorizations list until you find a blank line. Type the authorization object you need to add and press Enter. You will need to scroll through the list again until you find the authorization object you just added (it is was to find since the Authorizationcolumn should still be blank). Once you find the new entry line, use the drop down to fill in the Authorization column. Click on the Save picture-icon.

7. If you need to add another authorization to an authorization object already in the profile list, click on the +Add authorization button.

8. From the Maintain Profiles: Object Classes screen, double-click the Object class of the authorization you are adding.

9. On the Maintain Profiles: List of Authorizations screen, select the authorization you need to add by double-clicking the appropriate line. This will return you to the Maintain Profile screen where you can see that your authorization has been added.

10. On the Maintain Profile screen, click the Save picture-icon. Then click the lit match picture-icon to activate the new profile changes.

11. On the Activate Profile: Execution Screen screen, click on the lit match picture-icon to complete the profile activation process.

12. You may now leave the SU02 transaction.

13. In order the change a profile collection, you must make the changes in one or more of the dependent profiles, save the changes in the dependent profile(s), activate the dependent profile(s), save the collection owner profile, and activate the collection owner profile. On the Collect Profiles screen, double-click on the profile you want to change.

14. You will be taken to the Maintain Profile screen. Perform steps 6 to 11. Then use the white arrow on green picture-icon to go back.

15. On the Collect Profiles screen, click the Save picture-icon. Then click the lit match picture-icon to activate the new profile changes.

16. On the Activate Profile: Execution Screen screen, click on the lit match picture-icon to complete the profile activation process.

17. You may now leave the SU02 transaction.

Adding Authorization Objects and/or Authorizations to a Role

1. Log on to client 100 in the DEV SAP system.

2. Go to transaction PFCG.

3. On the Role Maintenance screen, enter the Role you want to change. Click the Change button.

4. On the Change Role screen, click the Authorizations tab and then click the pencil picture-icon.

5. If you are only adding a start up transaction to the role, skip to step 10. Otherwise, the assumption is that a new authorization object is to be added. On the Change role: Authorizations screen, click the +Manually button.

6. On the Manual selection of authorizations popup, enter the authorizations objects that need to be added (ie S_DEVELOP, S_PROGRAM, etc.) Click the green √ when you are finished.

7. Back on the Change role: Authorizations screen, if all the displayed signal lights are green, skip to step 8. Otherwise, fully expand the lines that are yellow and/or red and supply the necessary information. All signal lights should be green before moving to the next step.

8. On the Change role: Authorizations screen, click the Save picture-icon. You will receive a Data saved confirmation message in the status bar at the bottom of the screen.

9. On the Change role: Authorizations screen, click the red-and-white beach ball picture-icon to generate a profile from the saved role. Reply affirmatively if any confirmation popups. You will receive a Profile(s) created message in the status bar at the bottom of the screen. If you do not need to add any start up transactions to the profile, you may now leave thePFCG transaction.

10. On the Change Role: Authorizations screen, expand the Cross-application Authorization Objects → Authorization Check for Transaction Start → Authorization Check for Transaction Start until you see the Transaction code entry line. Double-click on the entry portion of the Transaction code line.

11. In the Maintain Field Values popup, scroll down the list until you find a blank From and To line. Enter the transaction(s) to be added, and click the Save picture-icon when you have finished.

12. On the Change role: Authorizations screen, click the Save picture-icon. You will receive a Data saved confirmation message in the status bar at the bottom of the screen.

13. On the Change role: Authorizations screen, click the red-and-white beach ball picture-icon to generate a profile from the saved role. Reply affirmatively if any confirmation popups. You will receive a Profile(s) created message in the status bar at the bottom of the screen.

14. You may now leave the PFCG transaction.

Granting Transaction access to a user via profile

*** Since SAP R/3 4.5, this is not the standard for user authorizations.

***

Granting Transaction Access to a User via Role

1. Log on to the applicable SAP instance and client.

2. Go to transaction SU01.

3. On the User Maintenance: Initial Screen screen, fill in the User ID for the user you want to change, either by typing it in or choosing it from the drop down. Click the little yellow pencil Change button.

4. On the Maintain User screen, click on the Roles tab. Fill in the new role in the first available Role field. Press ENTER to confirm that the role exists. Click the Save button.

5. Make sure to use transaction PFCG to run a user comparion to rebuilt the role-to-user connections.

6. You may now leave the PFCG transaction.

*** Since SAP R/3 4.5, this is not the standard for user authorizations.

***

Revoking Authorizations from a User via Role

Use the same procedure as Adding Authorization Objects and/or Authorizations to a

Role

Revoking Transaction Access from a User via Profile

*** Remember that profiles are NOT the standard way to implement SAP security. ***

Attaching a Profile to a User

*** Since SAP R/3 4.5, this is not the standard for user authorizations.

***

Attaching a Role to a User

1. Log on to the applicable SAP instance and client.

2. Go to transaction SU01.

4. On the Maintain User screen, click on the Roles tab. Fill in the new role in the first available Role field. Press ENTER to confirm that the role exists. Click the Save button.

5. Make sure to use transaction PFCG to run a user comparion to rebuilt the role-to-user connections.

6. You may now leave the PFCG transaction.

SAP R/3 dispatcher and work processes

2011-12-30T08:18:00.000+07:00

Types of work processes:

Message : Coordinates the communication between different instances of a single SAP R/3 system. Used for Logon purpose and load balancing.

Dispatcher : Redirect the request from GUI client to free process.

Dialog : Interpreting the ABAP code and execute the business logic. Used for interactive online processing.

Batch : For Background jobs.

Enqueue : Single “Central Lock Management Service” that controls the locking mechanism between the different application servers and the database.

Update : Responsible for consistency in asynchronous data changes.

Gateway : Used for transport of bigger amount of data between application servers as well as external (non SAP) systems that communicate with SAP.

Job profile for SAP BASIS Administrator

2011-12-29T08:20:00.000+07:00

Job profile for SAP BASIS Administrator

SAP Administration

Starting and Stopping SAP instance/(s)
User Administration – Setup & Maintenance
Authorization/Role/ Profiles – Setup & Maintenance
Setup SAP Security
Maintenance of System’s Health
Monitor System Performance and Logs
Spool and Print Administration
Maintain System Landscape
Transport Management Systems
Manage Change Requests
Create/Manage Batch Jobs
Backup Schedule,run & Monitor Backup of SAP
Apply Patches,Kernel & OSS Notes

2. Database Administration

Database Space Management
Database Backup
Database Recovery
Database log (Redo log, Archive Log) management
Database Performance Tunning

3. Operation System Administration

Operatin System Security
Operation System Performance Tunning
OS Space management
OS level background Job Management
OS level backup and recovery

4. Overall System Monitoring

Monitoring R3 Servers and Instances
Monitoring Users and Authorizations
Monitoring Security Part
Monitoring workload analysis
Monitoring Processes
Monitoring Buffers
Monitoring Operating system
Monitoring Database
Monitoring Backups

Creating a Local Frontend Printer or Desktop Printer

2011-12-28T08:21:00.000+07:00

Local or frontend printing is sometimes confusing in concept but actually very easy to understand. As a rule, local printer is simply another way of saying that the user is going to print to the default printer designated on his/her workstation. You probably do this all the time with Windows to printerspreadsheets, Word documents, etc without thinking about it. You can do the same thing using SAP.

1. Log on to any client in the appropriate SAP system.

2. Go to transaction SPAD.

3. On the Spool Administration: Initial Screen screen, click the Output Devices

button.

4. On the Spool Administration: List of Output Devices screen, click the

Change button and then the Create button.

5. On the Spool Administration: Create Output Device screen, fill in the

Output Name and Short name – I normally use a short name of “DESK” for

“Desktop Printing” but alot of people use a Short name “SWIN” or “LOCL”

as well. Use the following DeviceAttributes fields:

Device type = SWIN
Device Class = standard printer

And the following Access Method fields:

Host spool access method = F: Printing on frontend computer Host printer = __DEFAULT. That is _ _ D E F A U L T

Save the printer.

6. You may now leave the SPAD transaction.

Using this printer will cause print to go to SAPLPD which will use the default printer of the current workstation.

How to Generate a Developer’s Key for a Programmer/ABAPER

2011-12-27T08:24:00.000+07:00

Log on to the SAP Marketplace using an OSS ID with Administration rights –http://service.sap.com/sscr.

2. In the navigator tree on the right-hand side of the SSCR screen, click onRegistration.

3. On the SSCR – Registration screen, click the Register developer radio button and click an Installation hyperlink. Make sure you select the correct Installation Number for the SAP “flavor” you need or the generated key will not work.

4. On the SSCR – Register Developer screen, type in the developer’s SAP user ID and click the Register button.

5. A new Details section will appear. Note the generated developer’s key or cut-and-paste for other storage.

6. You may now close your web browser session.

Reporting a Problem/bug to SAP

2011-12-26T08:25:00.000+07:00

Log on to the SAP Marketplace using an OSS ID with Administration rights –

http://service.sap.com/message.

2. On the Create Customer Messages screen, click on the Start Message Wizardbutton.

3. On the Customer messages – Create screen, click the Select a Systembutton.

4. On the System Selection popup, click on the + sign next to Show systemsto see a list of your SAP systems registered with SAP. From the expanded list of system, click on the radio button just left of the for which you are reporting the problem. Click the Choose button and you will be returned to the Customer messages – Create screen.

5. On the Customer messages – Create screen, click on the radio button to the left of the System type which has the problem: development system,test system, or production system. From the Release dropdown, select the appropriate SAP software release. Click the Continue hyperlink.

6. On the next Customer messages – Create screen, scroll down to the bottom of the screen. If the problem involves an add-on, select the appropriateAdd-on and Add-on release from the dropdowns; if an add-on is not involved, leave these dropdowns blank. Verify that the information showing in theOper. System, Database, and Frontend dropdowns is correct. If it is not correct, selection your SAP system’s information from the appropriate dropdowns. Click the Continue hyperlink.

7. On the next Customer messages – Create screen, scroll down to the bottom of the screen. From the Priority dropdown, select the appropriate priority of Low, Medium, High, or Very High. From the Component dropdown, select which SAP component is having the problem. Once you select a component, a secondary Component dropdown will appear. Select a secondary component and a third component as well. Do the best you can to make all three component pieces fit your problem as closely as possible. Click the Continuehyperlink.

8. On the next Customer messages – Create screen, scroll down to the bottom of the screen. Select a language from the Language dropdown, type a short but descriptive summary of your problem in the Short description box, and type a more detailed description of your problem in the Long test box.

9. If there are logs or other files which might assist SAP in resolving the issue, rename them all so that they have a suffix of “.log” and use the Add attachment hyperlink and the Attachments popup to attach them to the message. After attaching all the necessary files, click the Closehyperlink to return to the Customer messages – Create screen.

10. When you have provided as much information as possible, click the Send to SAP hyperlink.

11. You will receive a confirmation screen with a generation problem number. Write this problem number down for later use.

12. You may now leave the Message Wizard and close the web browser window.