To increase the size of a trace file in SAP

Few cases, it is required in SAP to increase the size of a trace file from default value, so that more trace or log can be captured.

Login to SAP ABAP system. Go to transaction RZ11/RZ10 and set below parameter


Parameter rstr/max_filesize_MB , the parameter sets the maximum file size of a trace. Default value of trace file is 16MB. The maximum value is 100MB.


As rstr/max_filesize_MB is a dynamic, parameter takes effect immediately without restart of the SAP system.However, the parameter lasts only till restart of the server. After restart, default value will be set again for this parameter

ABAP & JAVA stack checks

ABAP Stack Checks

Check process overview(SM51)
Check overall system process overview(SM66)
Check application servers status (SM51)
Check for any pending locks (SM12)
Check for any pending database locks (DB01)
Check for Dumps in the system(ST22)
Check  Outbound (SMQ1) entries
Check Inbound (SMQ2) entries
Check SMQR and SMQS (inbound & Oubound regestration)
Check System log for any errors(SM21)
Check for any hanged updates or update status(SM13)
Check for excessive swapping and buffer monitoring (ST02)
Check for critical job status like backup,updatestats,checkdb etc(DB13)
Check for long running/failed jobs status(SM37)
Check database alertlogs and performance(ST04)
Check spool job status (SP01)
Check STO6 for OS monitoring
Check cache status (sxi_cache) for PI System
Check SLD functionality(SLDCHECK)
Check SXI_MONITOR for XI/PI system
Check SXMB_ADMIN for XI/PI system
Check for Tablespaces,Missing indexes in DB02
Check ST03 for workload analysis.
Check SM58 for Trfc entries
Check SP12 spool buffer consistency

...............................................................................................................................................................
SM50:

Work process over view:

Transaction code SM50 is used to monitor and manage work processes. In the work process overview, you can:

• End an ABAP program that is running.
• Debug an ABAP program that is running.
• Cancel a process (with or without core) – long running jobs
• End a session
• Activate/deactivate the restart option after an error
• Execute various functions for the process trace

No:
The internal ID number of a process. Used to identify messages that belong to a work process
 in the system log.

Type:
• DIA: Work process for executing dialog steps in user transactions.
• UPD: Update process for making U1 (time-critical) database changes.
• UP2: Update process for executing U2 (not time-critical) database changes.
• ENQ: For locking or releasing SAP lock objects.
• BTC: For processing background jobs.
• SPO: For spool formatting processes.

PID:
Process ID of the work process (on the operating system).

Status:
• Running (executing a request)
• Waiting (idle and waiting for work)
• Hold (held for one user) is not an abnormal state, but a work process can only serve a single user.
If too many processes are in hold status, then system performance suffers.
You can use the Reason column to identify work processes with status hold that
can be released.
• Stopped (aborted with Restart set to No)

Reason:
If a work process is in hold status, the reason is displayed. Typical reasons are: Debugging, CPIC activity, locks, updates, GUI (system waits for response from the SAPGUI front-end program, for example, for a remote function call (RFC)). You may also see PRIV (PRIVate use) as a reason for holding a work process. PRIV indicates that a work process is reserved for a single user for memory management use. The work process has exceeded the limit of the SAP memory that is used by other processes. The process is held as long as the current user requires local memory.

Start:
Indicates whether the process should be automatically restarted if a process ends prematurely. You can change the restart status of a process by choosing Process > Restart after error > Yes/No. Normally, leave Restart set to Yes. If a work process aborts during its startup, the system automatically sets Restart to No. This measure protects against endless attempts to restart a process if a database system is not available, or another serious problem is affecting the system. After correcting the problem, you can change Restart to Yes so that the system starts the work processes.

Error
Indicates how many times a work process has aborted.

Sem:
Indicates the number of the semaphore for which a work process is waiting. Normally, this field should be empty. If one or more semaphore numbers frequently appears, evaluate the performance of your system using the Performance Monitor.

CPU:
Cumulative CPU time since the start of a work process.

Time:
Indicates the elapsed time used by a work process for the dialog step that it is currently processing

• Report – ABAP program or report that is currently being executed
• Client – Client for the session that is currently being executed
• User – User whose request is currently being processed
• Action – Action that is being executed by the current program. The actions displayed are recorded by the SAP Performance Monitor. The Performance Monitor must be active (SAP profile parameter stat/level = 1(default)) for actions or database table accesses to be displayed.
• Table – If the database is being accessed, this column shows the name of the table being accessed.

.................................................................................................................................................................

SM66:  Global work process over view:

SAP SM50 transaction is used to report information for all configured SAP work processes under 
one SAP server/instance while SAP SM66 reports all occupied SAP work processes from all servers/instances of a SAP system

Transaction code SM66 is used to quickly investigate the potential cause of a system performance problem by checking the work process load. You can use the global work process overview to:

• Monitor the work process load on all active instances across the system
• Identify locks in the database (lock waits).

Using the Global Work Process Overview screen, you can see at a glance:

• The status of each application server
• The reason why it is not running
• Whether it has been restarted
• The CPU and request run time
• The user who has logged on and the client that they logged on to

• The report that is running

................................................................................................................................................................

SM51: List of active servers:

Transaction code SM51 is to display list of active application servers that have registered in the SAP message server. Further, you can manage & display the status, users, work process in all application servers belonging to the SAP System.

In this example the SAP system only has 1 application server. (See the indication at the bottom *** 1 active servers ***)
It doesn’t mean there is only one server configured on this system, but that only one is up and running for now, and because we want to check the work processes, that’s the only information we need to know.

So here you have two options, which are in this case do exactly the same thing. Either go to the SM50 transaction and double-click the Server Name. Please note, if you had more than one server being displayed then the only option left would be to double-click the Server Name to open the SM50 transaction on the targeted server.

By Double-Clicking or going to SM50 you have a screen similar to the one below:

.................................................................................................................................................................

SM12:

The SAP System is equipped with a special lock mechanism that synchronizes access to data on the database. 

The purpose of the lock mechanism is to prevent two transactions from changing the same data on 
the database simultaneously.

Lock entries are usually set and deleted automatically when user programs access a data object & release it again. The lock mechanism is closely related to the Update Mechanism.

                                         

1. You can use SM12 to check and delete lock entries.
2. In SM12, check any lock entry older > 2 days. If any outdated entry found, check the corresponding user is user online/offline in AL08 or SM04 (you can get the transaction code that been use by the user). Get the user contact from SU01 and inform about the lock else if the user is offline, release the table from lock by deleting the lock.

Note:
Important profile parameters for the lock concept:-

• enque/table_size – Size of the lock table managed by the enqueue server in the main memory. The lock table contains information on which locks are currently held by whom. You can check whether the update server is functioning correctly, since the lock table can grow very fast if the update function stops. If no update problems exist, you can use this parameter to increase the size of the lock table. Default value: 4096Kb

• rdisp/wp_no_enq – Number of enqueue work processes that are to run on this instance.
• rdisp/enqname – Name of the application server that provides the enqueue service.

The lock mode:-

• Shared Lock (S) – Several users can access locked data at the same time in display mode. Requests from further shared locks are accepted, even if they are from different users. An exclusive lock set on an object that already has a shared lock will be rejected.
• Exclusive (E) – An exclusive lock protects the locked object against all types of locks from other transactions. Only the same lock owner can reset the lock .

-When there are thousands of SAP lock/enqueue entries
using those SM12 selection criteria is a better paractove when there.

1. use less system resource (memory,cpu..etc) by filtering
unnecessary data

2. Make it easy for you find what you are looking for since data
is filtered.

If you want to see all lock, keep blank fields and press enter


                                 

Imp Note: Pay attention to different color of rows

Blue color row: means that the lock has already been transferred to the update task
and lock entry has been writeen to a system level backup file.

This SAP mechanism is to prevent lock/enqueue loss due to system failure.
when system reboot , lock entry in backup file would be imported to SAP lock/Enqueue table
which is in memory.


While Color means that the lock in that row is (still) held by the non-updating task owner
owner like SAP dialog work process.

To review the lock entries,Double click on lock entry.


                              

For explanation on field displayed in lock entry list:
                                                 

Review Lock/Enqueue statistics:

SM12 -> Extras -> Statistics

      

                           
Top capacity used

Sm12 -> Extras -> Top capacity

There are three options:

Current
History
Delete History

                    

Java Stack Checks:

Check java portal accessibility using link
Check server0 log for java system for critical errors
Check accessibility of management console
Check server node status
Check default trace for critical java errors
Check java reports for memoryconsumption/swapping

Os-level checks

Check filesystems usage (shouldb be <90%)
Check for swap space using topas/nmon etc
Check for work directory log files at oslevel for errors
Check work dir logs
Cluster/server0 logs for java system performance issues.

Useful information for OS/DB Migration -5

SAPInst and R3SETUP:

The SAP installation tools SAPInst and R3SETUP are used to install SAP
systems or to unload or load systems during a system copy procedure. They
invoke other tools (for example, R3ldctl, R3szchk, and R3load) and control the
entire installation and migration process. Some of the tasks that the tools perform
include:

1. Creating users or groups on the operating system level
2. Adapting file system rights
3. Installing SAP binaries (Kernel)
4. Triggering the database unload and load processes.
5. riggering post processing such as collecting database statistics

NOTE:SAPInst is used as of SAP basis Release 6.10, whereas R3SETUP supports

basis Releases 3.1I up to 4.6D



To simplify the migration process, the SAP installation tool SAPInst provides
software life-cycle options.

1. Export preparation
2. Table splitting preparation
3. Database Instance export

R3load:  R3load is the core migration tool. It exports SAP ABAP table data from the
source database and imports it into the target database.

                                     

R3ldctl: R3ldctl unloads SAP ABAP data dictionary structures from the source system. It
generates structure files (*.STR files) that describe the definition of tables,
indexes, and views. In addition, it generates database-specific template files
(*.TPL files) with definitions of DDL statements, for example, statements to
create a table, to drop a table, and so on.


R3szchk:  R3szchk computes the size of tables and indexes for the target database.


You may run the R3szchk while the system is still up and running and used for
production

Note: R3szchk requires that the STR files created by R3ldctl calculate the
target size. If running R3szchk and R3ldctl while the system is up and
running, no change of the data definition is allowed afterwards (for
example, by new transports). These changes will not be reflected in the
STR files, so the export will not be consistent or will fail.


Another option for reducing the runtime is to use the option –r together with
an input file to avoid the expensive statements. This file contains the name of
the table and the number of records for this table. Running R3szchk with the
option –r and the file containing the number of records will reduce the runtime
by factors


Migration monitor: MigMon:

The main aspects and attributes of the MigMon are:

• Allow advanced control of R3load export and import.
• Automate dump shipping between source and target system.
• Support parallel unload and load processing.
• MigMon is controlled by properties files.

Properties files are constantly reread after a defined time period, so some
attributes, such as the number of parallel R3load processes, can be adjusted
dynamically.


For every package you get the following information:

Package: The name of the package that was exported (may also be only one
 table, if split out).
Time: The runtime needed to export the package.
Start date: Date and time when the export of the package starts.
End date: Date and time when the export of the package ends.
Size MB: Size of the exported package in MB (for example, on disk).
MB/min: Export rate in MB per minute (related to the export file size).


At the end of the output you have information  about the following items:

Sum of the export times
Start time of the export process
End time of the export process
Size of the export (sum of all export files)



SAP provides several tools for splitting packages or tables:

Package Splitter:

This splits tables from existing structure files. You can explicitly specify the
tables that should be split into separate structure files. You can also split
tables into separate packages if their size exceeds a configurable threshold.
Other split options are also available.

R3ta:

This tool can generate multiple WHERE conditions for a table, which can then
be used to export the data of this table with multiple R3load processes in
parallel. Each R3load process requires a WHERE condition to select only a
subset of the data in the table.

SAPInst:

This tool can be used for the table splitting preparation. It invokes R3ta and
the Package Splitter, and also automates some of the tasks that would
otherwise need to be performed manually.


SAP system stores table definitions in the data dictionary table DD02L

                                           

Note: If a code page conversion is performed, table clusters must be unloaded
sorted. As of R3load 6.40 patch level 55 (compile date February 10, 2006) and
R3load 7.00 patch level 10 (compile date February 10, 2006), R3load
automatically ensures that table clusters are exported in sorted order during a
code page conversion


When using the MigMon, you may use the ddlMap option in the export properties
file, which names a file that contains the mapping between the package names
and the DDL template files.


Package splitting:

Image:

All tables in an SAP system are assigned to a data class (TABART).
The relationship between a table and the data class is maintained in table DD09L.

                                           

                               
During the export preparation, R3ldctl generates one structure file (STR file) for
each data class. Each structure file is processed by a single R3load process.

You can specify a size limit for the data packages that are generated by the R3load
process in the corresponding cmd file, but all data packages of the structure file
are created sequentially by one R3load process.

Therefore, depending on the amount and size of tables defined in the structure file, the export can take a long time.

Usually, there are a lot of tables in the APPL data classes and some very large
tables in data class APPL1.

When exporting such a system without splitting the structure files, the processing
of packages that contain several large tables may dominate the total runtime of
the export.

One solution is to split a single structure file into multiple files with the package
splitting tool. There are two different versions available:

Perl based
Java™ based

Since only the Java tool is to be maintained in the future, this is the tool of choice.


The Java STR splitting tool provides the following features:

•  Split out the largest <n> tables into separate structure files. Each file contains  a single table.
• Split tables that exceed a defined size limit into separate structure files. Each file contains a single table.
• Split structure files for which the tables exceed a defined size limit. Each file may contain one or more tables.
• Split tables into separate structure files by specifying their names in an input file. Each line of this input file contains a single table name.
•  You can invoke the package splitter manually or by using SAPInst.
•  The parameters that are required to control the program flow can be supplied on the command line or by defining them in a file named
•  package_splitter_cmd.properties.

                                             

Reorg of Table

Reorg of BALDAT

Pre-requisites "

1) Take the DB02 snap shot of BALDAT size,


2) To check total size of the table:

select segment_name,segment_type,bytes/1024/1024 MB from dba_segments where segment_type='TABLE' and segment_name='<yourtablename>';


3) To see count of rows for specfic table:

      select count(*) from  sapr3."BALDAT";


4) To see indexes for Specific tables:

select TABLE_NAME,Index_name,UNIQUENESS from all_indexes where TABLE_NAME
like'%BALDAT%';


Fragmentation of tables to check:

SQL> select table_name,round((blocks*8),2)||'kb' "size" from dba_tables where table_name = 'BALDAT';

TABLE_NAME                     size
------------------------------ ------------------------------------------
BALDAT                         40941440kb




Actual data in table:

SQL> select table_name,round((num_rows*avg_row_len/1024),2)||'kb' "size" from dba_tables where table_name = 'BIG1';

TABLE_NAME                     size
------------------------------ ------------------------------------------
BALDAT                          30604.2kb


Note: Fragmentation size - Actual size = XXXXXXX Kb is wasted space in table

You will achieve this much of space after reorg.


Below is the command to reorg online:

brspace -u / -f tbreorg -s PSAPTABD -t BALDAT -p 5 -e 5


++++++++++++++++++++++++++++++++++

Missing stats to collect:
brconnect -p init<SID>.sap -1 E -u / -f stats -t missing -c 30 -p 1 -f collect

-----------------------------------------------------------
Table clean-up command:
brspace -p init<SID>.sap -s 20 -l E -u / -f tbreorg -a cleanup -s PSAPTABD -t BALDAT

Useful information for OS/DB Migration -4