Support Phase
It is used to provide the support to End Users. There are various types of Supports provided by the partners to the customers. Partner (Partner) is a company which provides support services. Ex: IBM, HP, HCL, TCS, WIPRO, SATYAM
1 L1 Support Tier-1 Level-1 Support-1
2 L2 Support Tier-2 Level-2 Support-2
3 L3 Support Tier-3 Level-3 Support-3
4 L 4Support Tier-4 Level-4 Support-4
1.
Level-1 Support : It is a front end support or end user support to Reset the Passwords lock and unlock users. GUI related issues.
(Installation, patches, upgrade) performance check list activities etc… Note: Very less privileges are assigned to the users there will be no input on the system by this users there will be no input on the system by this users i.e. they can’t Delete, Drop, Change objects in the
system. It is also referred as monitoring Job. 2.
Level-2 Support : The reports from the Level-1 consultants along with recommendations are evaluated and ensure that they are resolved. Level-2 consultant handle assignments of roles, Background Jobs rescheduling, data transfers, notes etc…..
3. The issues which could not be resolved can be escalated to Level-3 4.
Level-3 Support : Recommend the parameters for Tuning, Support Package application, Scheduling down times, working with SAP, database activities etc….
5.
Level-4 Support ( Onsite ) :The consultant works with data center and knowledge of O/S, R/3, DB etc is required for this. Responsible to Start Up the BOX. Responsible for Backup, Restore, Recovery, DR, Standby, Clustering, Mirroring, H/W migration,. UPS aircom etc.
Based on the nature of the company the following activities are also segregated.
Security Performance
Data Base O/S
Transports
Normal BASIS Support
We can also propose to perform all the activities.
Roles and Responsibilities: Define the Checklist
Working on Tickets/Requests/Cases Configuring Work Processes
Configuring Buffers
Resolving Runtime Issues
Working with Dialog Process, Update Process, background Process, Message, Spool and Enqueue Processes
Define Background Jobs and Monitoring Monitoring Critical Update
Define the Printers
Working with SAP Archiving Creating RFC Destinations
Define various methods for data transfer Monitor EDI and IDOC
Release change request and import target systems Applying patches notes etc…
Configuring CCMS and monitoring Configuring logon load balancing
Configuring operation modes Monitoring the log files
Defining and scheduling standard background jobs Monitoring backup regularly
Support Architecture:
Offshore Components IBM, HP, WIPRO
CVONNECT Connectivity Landscape
Leased Line/VPN GE, COKE, HP
Work for CustomerConnectivity Directory NESTLE: ST02 PFCG 30 Employees HP: ……. ……. 17 Employees KODAK: SM36 SM37 SM50 SM66 12 Employees VIDEOC ON RELIANC E TVS PHARMA OFFSHOR E SAMSUN G RIGHT SHORE CUSTOME R
Connectivity from OFFSHORE to CUSTOMER/CLIENT:
Leased Line: If the trust is established between the supporting partner and the customer dedicated leased line can be used. (Trust means the data security of the customer). Each leased line is backed up by dialup or another alternative leased line.
VPN: (Virtual Private Network). It is a service which establishes a tunnel between the customer and supporting partner. CISCO VPN is widely used. We need to key in USER-ID and Password and Access Key to logon into the Private Network.
Remote Access Cards (RAC) are used to generate Random Number (Remote Authentication Key) i.e. generated access key.
User Request Mechanism: User request management tools are utilized for this purpose.
FAX
Ticketing Tool
Phone
When the request is created in the tool the status is NEW. USER Request REMEDY CLARIFY HP Overview Seibel SAP CRM SYNERGY CUSTOMID EXCEL Help Desk (Phone, FAX, Email)
Status Description
New Raised Problem
Assigned When the Consultant Accept the Ticket
Work In progress Processing
Temp Fix Temporary Fixed, Job Aborted, Run Temporary
Pending For Approval
Closed/Completed/ Finished Problem is Fixed Severity of the Problem:
S.No Severity Response
Time Closure Time
1 Low/Normal 24 Hrs 72 Hrs
2 Medium 12 Hrs 48Hrs
3 High 8 Hrs 24 Hrs
4 Very High/ Critical 2 Hrs 4 Hrs
5 Diasster 15 Min 15 MIN
Low/Normal: It can be solved with in 72 Hrs. Tickets such as Password Reset, User Creation, GUI related issues or user specific problems
Medium: Updates, Background processing, Batch Input processing, Roll assignment etc…
High: Printing, Update, Deactivation, Transport Errors etc…
Very High: Printers Down, Instance Down, Services are partially inturepted Disaster: Server Down
SLA: Service Level Agreement.
SLA is an agreement between the supporting partner and the company which describes the level of agreement between the parties and the work will be done based on the agreement conditions.
Parameters for defining the Number of W.P’s:
rdisp/wp_no_dia= For defining the number of Dialog W.P’s rdisp/wp_no_btc= For defining the number of Background W.P’s rdisp/wp_no_vb= Defining the number of update W.P’s
rdisp/wp_no_vb2= Defining the number of update W.P’s (secondary) rdisp/wp_no_enq=1 Defining the number of enqueue W.P’s
rdisp/wp_no_spo= Defining the number of spool W.P’s
rdisp/max_wprun_time= 600-1800 sec this defines the maximum time that a (Dialog)W.P can run .
DIAG Protocol Roll In
Dialog
Work Process
: Roll OutHandles the user Request interactively At least Two dialog processes are required
Each Dialog W>P requires around 75MB-150 MB of memory on an average (Memory varies between the systems)
USER Central Instance W0,W1……… Wn Dispatche r QUEU E U C SCREEN ABAP SQL R/3 Buffers DBCL DATA BASE
Every Dialog W>P an handle 5 to 10 users 9Depending upon the type of users (Lo, Medium, High))
Each Dialog W.P will be timed out for every 600 eseconds or the time specified by parameter “rdisp/max_wprun_time”
Note: The parameter rdisp/max_wprun_time is instance specific and will take
default value of 600 if not changed. Each request will be handled for 600 seconds. Otherwise the request will be timed out.
Each Dialog W.Pis not restricted to a user session Each process can serve multiple users
Each process can serve only a part of a Transaction Dialog Steps:
It is a part of a transaction. It can be also called as a sub transaction.
Transaction: It consists of multiple dialog steps and it commits as a group or it can be rolled back. In order to complete a transaction with multiple dialog steps multiple dialog work processes are used.
Monitoring Dialog Work Process: Work processes are monitored in Transaction’s
SM50 (Local Instance) SM66 (Global Instance)
Go to SM50 to display the list of processes configured on that instance. It is used to display the following:
1. No: Serial Number of Work Processes (W0, W1……, Wn-1)
2. Type: It shows the type of work process. It can be any one of DVEBMGS
3. Process ID: (PID) It represents a process Id at O/S level. This is used to identify the critical process running at O/S level and to take a decision whether to continue or Kill the W.P.
4. Status: It shows the status of the W.P
a. Running: The W.P is executing the user task until it complete the task or timed out. It written in the status of running
b. Waiting: It is waiting for the user request they are free t handle the task assigned by the dispatcher
c. Holding: The process is on hold. (It is also running) and waiting for the communication from an RFC system.
d. Terminated or Stopped: The process is terminated due to an error, time out after 600 seconds, explicitly killed.
e. Ended: The W.P is ended i.e. it could not be started and it can’t handle any user request
5. Reason: The reason for the status.
For running and hold press F1 to display the various reasons
Sleep Mode: It’s waiting for the resources on the target system
Private Mode: It is dedicated to a user. Time out will not work for this process
Enqueue: Communicating with enqueue process.
6. START: It ensures the W.P to start during W.P termination or Restart. It can be change from menu process restart after error Yes or No If it is set to No it can’t be started to handle the Queue. But it’s useful to debug, why the process has been terminated or stopped.
7. Err( Error): Indicates the number of times the process is terminated
8. Semaphore: It indicates the number of the semaphore which blocked the W.P i.e. each W.P needs to work at O/S level and gets blocked for the various resources. There are 55 semaphores which are displayed by pressing F1
9. CPU: Click on CPU to display the time utilized by the W.P while accessing CPU. It is also reffered as CPU time.
10. Time: The time spent by the dialog W.P to execute the current dialog step of a transaction. If it goes beyond 600 seconds it will be terminated automatically. 11. Report: The report which is executed by the process
12. Client: The client NO through which user logged in 13. User: Name of the user who is executing the process
14. Action: Specify the action performed by the W.P. Ex: Logical Read, Sequential Read, Physical read, Roll In, Roll Out etc…
Monitoring
:1. SM50: It is used to monitor the status of various W.P’s on an instance.
2. SM66: It is used to display the W.P of all instances. It is used to monitor the time
consuming W.P’s with respect to users, report, reason for the long running and the type of action on the database along with the time consuming for that dialog step. 3. As part of the checklist you need to identify the total number of work processes with various statistics and mark them with red which are consuming lot of time. The reason for this is also very important. (Sleep Mode, PROID, CPIC….) to identify the expensive W.P.
4. If all the W.P’s are in the status of running we can assume that the system is over loaded due to lack of memory or the users are overloading the system i.e. more than the expected. (The system designed for 200 users but it is being utilized by 300 users)
5. We can also kill the expensive W.P from SM50 (Inform the user before killing the W.P). Select the user W.P Go to Menu Process Cancel with core or Without Core
WITH CORE: Means it will generate a trace file at O/S level. WITHOUT CORE: Means no trace file generated.
Double click on the W.P to check the details of the W.P
SM50 is also used to change the layout. Go to Menu Settings Layout We can customize the layout as per our requirement.
Note: Sometimes it may be recommended to end the user session instead of killing
user W.P.
“./kill -9” (In UNIX) Dpmon:
It is used to monitor the status of W.P at O/S level. If the system is congested and user can not log on to GUI then use dpmon at o/s level. It displays the list similar to SM50.
We can select the process which is time consuming and use the option kill with core or without core. If we can’t kill identify the Project ID and kill at O/S level
Note: Dialog Process is used to handle the user request to schedule the job in the
background to update the database to print the requests and to get the logs before updating a record.
Disadvantages: Dialog process can’t be used to run the long running, time consuming expensive programs or Reports.
Background Process
:The time consuming, expensive, long running programs can be scheduled in the background to run during Off Peak hours without user intervention.
Background jobs running in Non Interactive mode and doesn’t require any user inputs
The max work process runtime is not applicable to background W.P i.e. they can run for any number of hours.
Background process doesn’t handle part of the transaction but in time the complete transaction is handled by them.
Background jobs are created by using Dialog W.P’s Background jobs are defined in the transaction SM36.
Go to SM36 Specify Job Name Specify the Job Class Specify the job triggering mechanism (Immediate/Date & Time/Event/After Job/ At Operation Mode…etc) Save the job definition
Job Class:
Class-A: It is used to define high priority jobs. We need a dedicated process of Type A which is defined in operation mode. Class A job will be executed by only Class A work processes.
Don’t schedule more Class-A jobs unless it has a dedicated work process at that point of time.
Class-B: It is used to handle medium priority jobs i.e. system defined jobs like SAP standard housekeeping jobs which runs periodically at regular intervals.
Class-C: It is the default class for all the Jobs. It is used to schedule low priority jobs. Status of a Background Job:
1. Scheduled : When the job is defined the status is scheduled
2. Released: When you specify the date and time to a scheduled job it’s status is
released
4. Active: The job is currently running
5. Completed: the job is completed successfully 6. Canceled: The job is canceled i.e. an error occurred
Background job Mechanism:
When the dialog user defines the run a job in the background it is entered into the tables “TBTCT” and “TBTCS”
Background processing time scheduled in table (TBTCS) Compare value for batch job selection TBTCT
Background Job Scheduler: SAPMSSY2 is the ABAP program that runs every rdisp/btctime
It runs for every 60 seconds or the time specified by the parameter “rdisp/btctime=”
It checks for the jobs in the ready state and brings them into background job queue. It runs in the dialog process.
1. User logon to the system to schedule a report or program in the background mode
2. It is stored in the tables TBTCT, TBTCS
3. A background job scheduler runs for every 60 seconds in the dialog mode to pick the background jobs
4. If the job is picked and ready to execute the status is set to ready 6. When the background process is assigned status is ACTIVE
7. Canceled when the job is not complete.
Background Job Steps:
Background Job can be defined by using an ABAP program, External Program and External Commands
1. ABAP Program: It is a standard program or custom defined program which will be executed using Variant
Variant: It is a program selection criterion to provide the inputs during run time or execution of the program
Ex: Delete the background jobs for every two days 9The jobs which are terminated or completed successfully)
Delete the old log files for every 3 days or delete the log files which are older than 2 days.
Note: Variants are stored in the table TVARV (Table of variable in selection criteria) 2. External Program: It is used to define the program to trigger on the host wwith the specified parameter
Ex: R3trans, SAPstart, SAPEVT,
This type of job step allows you to run programs outside the SAP System. External programs are unrestricted, directly entered commands reserved for system administrators.
3. External Command: These are the commands which are not specific to O/S Ex: brbackup, brrestore, brconnect etc…
These commands are defined I transaction SM69 and executed through SM49. This type of job step allows you to run programs outside the SAP System. External commands are predefined, authorization-protected commands for end users.
The type of external command and external program is unrestricted, meaning that you can use either compiled programs or scripts. Such programs can be run on any computer that can be reached from the SAP System. Parameter passing to non-SAP programs is completely unrestricted except by the
predefinition mechanism for external commands.
Output of non-SAP programs, particularly error messages, is included in the job's log file. Specifications required for an external command or program is:
o External command + Type of operating system + (Parameters) + Target host system o External program + Parameters + Target host system
External Commands and External Programs Definition
• The background processing system makes a distinction between external commands for normal users and external programs for system administrators. You can see this distinction when scheduling a job from Transaction SM36, with separate fields for external commands and external programs.
External commands
• External commands are predefined commands for end users. They are operating-system independent and are protected by authorizations, so that normal end users can schedule only those commands that the system administrator permits them to.
• With an external command, an ordinary end user—any user without background processing administrator authorization—may run a host system command or program that has been pre-defined by the administrator in the SAP System. The user who schedules the external command must have the authorization required for the external command.
• External commands let you control what your users do outside the SAP System. End users can run only the commands and arguments that you specify in external command definitions. And you can control access to external commands with SAP authorizations.
• For additional security, external command definitions are operating-system specific. For example, you can define variants of a command for UNIX and Windows NT hosts. A user who schedules an external command must specify the type of operating system in which the command is to run. The system then automatically selects the correct operating system variant or issues an error if the required variant has not been defined.
External programs
• External programs are unrestricted commands that are neither pre-defined or restricted by authorizations. A user with administrator authorization can enter any of these in a job step.
• With an external program, a system administrator can enter any desired host operating system command or program in a job step. No SAP authorizations test is carried out before executing the command.
• External programs give an administrator—a user with the background processing administration authorization (authorization object S_BTCH_ADM Batch processing: Batch Administrator)—the flexibility to run any required host system command without any administrative preparation in the SAP System.
• The purpose of this distinction is to let system administrators execute any required external program while restricting normal users to authorizations-tested external commands.
Defining Background Job with a Variant:
Ex: Program Name: RSPO1041
Go to SA38 Specify the program Name as RSPO1041 Execute or F8 Specify the inputs Go to Variants and save as variant Specify the Variant name Specify the Description
Now Go to SM36 Specify the Job Name Specify the Job Class Status as ScheduledSpecify the server where the Job needs to be executed Click on Job Steps Click on ABAP program Specify the Program Name Specify the Variant Save the Job Steps Click on Start Time (Condition) Specify the time or the start condition for the job execution and save the job definition.
Job start condition can be any one of the following: Immediate: To schedule immediately.
Date and Time: To specify at later date and time i.e. date and time for the job execution After Job: The success of one job starts the other job. Failure may terminate further steps After Event: Event triggers the job using SAPEVT (SAPEVT is an executable in run directory) At operation Mode: Once the operation mode switch takes place the jobs will get executed
We also can define the output using spool list recipient i.e. output can be to a printer, Email, Fax…etc when defining the background job.
One can use the Job wizard to define your jobs.
Housekeeping Jobs: Click on the standard jobs to define the standard housekeeping jobs. Some of the Housekeeping jobs are:
1. RSBCOLL: It is a background job to collect the statistics of all the Jobs 2. RSPO1041 (or) RSPO0041: To delete all old spool requests
3. RSSNAPDL: To delete old ABAP dumps
4. RSBDCRED: To delete the old batch input jobs or files 5. RSBTCDEL: To delete the old background job
6. RSM13003: To delete old update requests
Background Job Monitoring:
1. Go to SM37 Specify the job name or user name with job status and start data and time. 2. The jobs are displayed with various statuses. Select the job. Click on the job log to display the execution of the background job.
3. Select the job click on spool to check the spool generated by the background job
4. The background job can be deleted ( Including Active jobs) we can also reschedule and repeat the scheduling or move to other dialog instances.
5. We can also apply the job change to the inputs of the job before it becomes active. Purpose of the Background Job:
1. Schedule backup
2. Customize the in house reports such as daily sales, purchases to display the report to the usewr in the PDF form.
3. Run the pay roll and email the pay slips
4. Data Transfer from R/3 system to file system and vice versa. Ex: Manual Time in and Time out entries or schedule to move in to SAP periodically
Background Job Problems: 1. File system problems:
a. File is not available b. File permission Problem c. File couldn’t be opened d. File is corrupted 2. Authorization issues:
a. User Id is expired in the system b. The password is expired
c. Password is locked due to illegal attempts 3. Database Issues
a. The database space is not enough and results in errors (ora- 1653, 1654, 1631, 1632, 255, 272 ….)
4. ABAP dumps due to programmatically errors (S-Note, Support Packages, patches, Kernel upgrade) 5. Third party tools
6. SAP background mechanism is not so intelligent to work based on multiple conditions a. Maestro Toll
b. Tidal Tool
c. SAP Job Scheduler d. Other IBM products (Tivoli)
Note: In order to work with above tools customer provides adequate training to the consultants
SM62: It is used to display SAP events which will be triggered in the background by using SAPEVT SM64: To trigger the event in the background
Reorganizing Background Jobs:
Schedule report RSBTCDEL to delete the old background jobs based on outdated variants Background Job scheduling will be done in the following Way:
Authorizations for Background Processing:
Authorizations for accessing background processing jobs can be set up for two types of users: administrators and end users.
A user’s jobs are defined and run in the user’s current logon client, regardless of whether the user’s background processing authorizations are set for user or for administrator.
Setting Up Authorizations
Administrator authorization setup requires the following authorization objects:
Authorization Object Value
S_BTCH_ADM (Batch Processing: Batch Administrator)
Allows all of the activities listed above except for maintaining external command definitions.
No default profile with ONLY this authorization is currently shipped with SAP, but the standard SAP_ALL profile contains this authorization.
Y
S_RZL_ADM (CC Control Center: System Administration)
Allows an administrator to maintain external command definitions and to trigger commands from the external command function (Transactions SM49 and SM69).
01
S_BTCH_JOB (Batch Processing: Operations on Batch Jobs) Allows an administrator to view job-generated spool requests.
To protect sensitive data, this authorization is not included in the standard administrator authorization.
LIST
S_DEVELOP (ABAP Workbench)
Allows an administrator to capture and debug background jobs by providing access to ABAP debugging tools
User authorization setup beyond job scheduling and status checking requires the following authorization objects:
Authorization Object Value(s)
S_BTCH_JOB (Batch Processing: Operations on Batch Jobs)
Allows all of the activities listed above except for maintaining external command definitions. No default profile with ONLY this authorization is currently shipped with SAP, but the standard SAP_ALL profile contains this authorization.
DELE (delete other users’ jobs) LIST (display spool requests) PLAN (copy other users’ jobs) PROT (display anyone’s job log) SHOW (display job details)
RELE (release other users’ jobs to start; a user’s own jobs are automatically
released when scheduled.) S_BTCH_NAM (Batch Processing: Batch User)
Allows a user to specify other users for runtime authorization for a job.
permissible users
Operating System Commands)
Allows a user to run external commands. S_ADMI_FCD (System Authorizations)
For special functions, such as debugging active jobs.
SAP Transaction
:A transaction is defined as a sequence of dynpros (sap term for screens) having input and output fields and corresponding processing logic behind them to perform a particular task.
Every transaction has a 4 or more character code assigned to it. To invoke the transaction the user needs to enter this transaction code in the command window. This takes the control to the first screen of the transaction.
It consists of multiple transactions which are handled by different dialog W.P. Each transaction is a logical unit of work (L.U.W) in the database.
Each L.U.W is a transaction which can be committed or rolled back
Committed
Not Committed then Roll Back
A logical unit consisting of dialog steps, whose changes are written to the database in a single database LUW is called an SAP LUW. Unlike a database LUW, an SAP LUW can span several dialog steps, and be executed using a series of different work processes. If an SAP LUW contains database changes, you should either write all of them or none at all to the database. To ensure that this happens, you must include a database commit when your transaction has ended successfully, and a database rollback in case the program detects an error. However, since database changes from a database LUW cannot be reversed in a subsequent database LUW, you must make all of the database changes for the SAP LUW in a single database LUW. To maintain data integrity, you must bundle all of you database changes in the final database LUW of the SAP LUW.
The following diagram illustrates this principle:
DB L.U.W L.U.W L.U.W L.U.W T E M P T A B L E
The bundling technique for database changes within an SAP LUW ensures that you can still reverse them. It also means that you can distribute a transaction across more than one work process, and even across more than one R/3 System.
Update Mechanism
:Whenever a user wants to update or create a transaction logs into the system using dialog process
User logs into the Database/ R/3 system using SAPGUI
User request is received by dispatcher and keep in the queue
Whenever a free work process is available dispatcher assign it to the work process
Work process rolls the user context to task handler
Dialog user initiates a update transaction like sales order, purchase order, invoice, billing. (Let us say modify/ change)
If the request is related to the update it communicates with Enqueue process to issue lock to update the records. Time= 1 millisecond. If the request is from a Dialog instance, dialog work process communicates with message server in the central instance and message server to communicate with enqueue process to issue the lock. This entire process should be completed within 100 milliseconds
As a transaction consist of multiple dialog steps they are updated into temporary tables called as VB* tables. These tables are updated by the dialog work process
Update process reads the temporary tables to update the database based on Transaction Id.
Dialog process updates each dialog step task in temporary tables. These tables are called as VB* tables.
These are VB* tables and the tables contains: 1. VBHDR: Update header information is stored in this 2. VBMOD: Update module information
3. VBDATA: Data tables of update process
4. VBERR: Errors occurred during the update process 5. VBLOG: Update log files
Upon the successful update (Temp Table) a transaction Id is generated Transaction Id is generated form NRIV table (Number range Intervals)_ Update process gets initiated, reads the temporary tables and updates the database synchronously based on Transaction Id.
Types of Updates:
1. Local Update
2. Synchronous Update 3. Asynchronous Update
1. Local Update: Dialog process updates the database directly (System tables, direct update tables, users etc…)
2. Synchronous Update: Update process reads the temporary tables and updates the database synchronously
3. Asynchronous Update: The process of updating temporary tables by a dialog process is referred as asynchronous update
Types of Update Processes: 1. V1 Update
2. V2 update 3. V3 update
V1 Update: It handles the update with high priority V2 update: It handles the update with low priority V3 update: Reserved by SAP
Define V1, V2 updates properly to ensure that update mechanism works properly.
Note: There should be at least one V1 update to handle the updates
There should be at least one V1 update process defined for every 5 Dialog processes.
If V2 is not defined then V1 handles the V2 request
The V1 and V2 mechanism is defined in the update programs defined by SAP. SAP never recommends custom updates on the standard tables
SE12: Display the database tables
Note: The update process inherit the locks from dialog process Update Monitoring:
Updates are monitored in Transaction SM13
Go to SM13 to display the records based on client, user, from date and To date and status.
The records are displayed with the following status: Init: Update is getting initited to update the database Run: Update running
Auto: If the update is cancelled due to any reasons it will be set to automatic update once the problem is solved
Err: The update process is thrown in to error
Update Errors:
1. There is no space on the database (errors are prompted with message Err-1653, 1654, 1631, 1632, 255, 272 and so on)
2. there is a problem in the program which can be fixed by applying note or support package
3. Number range problem: Cannot insert duplicate records. During the above problems we can set the system to deactivate the complete update mechanism to keep the system consistent
4. After resolving the above issues we need to manually activate the update mechanism to update the records. The records with errors state will turn into Auto Status
5. There are some records where the error message says that error (Couldn’t repeat the update) that means these records can’t be updated again
6. If there is no such error we can select the record and repeat the update 7. Do not delete the update records.
Use the following transaction to get the granular formation about the update failure
SM14: It is used to deactivate and activate the update manually and we can fix problems manually
Update Parameters:
1) rdisp/vb_stop_active: Set to “0” so thatupdate can be deactivated. If the value is set to be 1 update can’t be deactivated
2) rdisp/vbdelete: This parameter is used to delete the old update requests based on number of days which are older than 50 days it will delete the default 50 days
3) rdisp/vbmail: It is used to send an email if update throws an error which can be viewed in SBWP (SAP busiess work place) based on yuour user. Will be set to either 0 or 1
4) rdisp/vbname: Name of the server where updatesa are processes 5) rdisp/vbreorg: used to delete the incomplete update requests. 1- Delete, 0- No
We can also schedule a background job RSM13002. But it will delete the update request which are in completed. Alternatively use rdisp/vbreorg set to 1 so that it will be deleted after restarting.
6) rdisp/vb_delete_after_execution: It’s used to delete the delete update requests soon after the execution of the update. Set it o 1 to delete the record or 2 to the record will not be deleted. It is set to 1 the background job RSM13002 is not required, if not schedule periodically daily during the off peak hours.
Update Advantages: 1. Database consistency
2. User is not waiting for the status of update in database 3. User updates i.e. dialog updates temp tables asynchronously
4. Update process reads the data from temp tables and update the database synchronously.
Number Assignment: During the implementation number range intervals are defined in the table “INRIV”. The numbers are buffered and assigned to the transactions when they are committed. The numbers are buffered and assigned to the transactions when they are committed. The update process updates the database with same transaction number. That is the reason we need to monitor updates continuously.
Update Problems:
1. Less number of work processes configured
2. The number queue increases and more updates are init state
Resolution: Try to find out the status of other back ground job which are updating the data base.
The update is consuming more time to update the database, the update queue increases. If it is a generic problem try to resolve it.
If it is a regular problem consider increasing update process based on the availability of resources
3. Check if the update mechanism is deactivated (SM14). Go to SM14 check the status of update mechanism if it is deactivated check the system log (SM21)
Note: Update can be deactivated and activated manually in SM14
4. Programmatical Errors: There is a programatical for which the update is thrown into error state. Refer the problem to development team, it is a
customizing program. If the problem popped up after applying support package and patches refer to sap notes for a consult or else write to SAP.
5. Table Space Overflow: When the table gets overflowed we could not update the database. Increase the table space and rerun the update.
Enqueue Process:
It is used to communicate to obtain a lock while updating a record. It is completely different with database locks.
Database locks are only at DB level, where as enqueue locks hold the transaction in large.
Enqueue Mechanism:
1. User requests for an update. Dialog process communicates with wnqueue to hold lock on that record. (If the request is to the central instance).
2. If the request is coming from dialog instance dialog process communicates with message server on the central instance and the message server
communicates with wenqueue to get the lock and issue to dialog process.
3. The enqueue locks are issued from the shared memory of the central instance which are displayed in transaction SM12
4. The use update the record in temp tables and locks will be inherited to the update process till the final update into permanent tables in the database. 5. The enqueue time will be 1 millisecond to 5 milliseconds on central instance, where as it is 100 milliseconds for the requests that are coming from dialog instance. USER TSKTT MESSAGE SERVER DISPATCHER U C ENQUEUE DI
6. There will be only one enqueue process in most of the environments. It is also possible to configure more than one enqueue process but ensure that all the processes shares the same lock table.
7. Enqueue locks are monitored in transaction SM12.
8. Enqueue displayed based on table name, client and user name. It displays lock arguments, time and the table.
9. No lock should be older than 24 hrs. If long pending locks are displayed we nedd to evaluate clearly.
Enqueue Problems: Lock table over flow
Enqueue lock table resides on shared memory of the central instance The lock table size is configured by parameter enqueue/table_size= 4-100 MB. By default it is 4 MB in size which can be increased up to 4-100 MB
When the lock table overflow the error message recorded in SM21, ST22
If the update is processing the records and releasing the records in time. If not the lock table will be filled and you can not issue any locks. We can use the parameters to increase the enqueue size.
Enqueue time increases (4 or 100 Milliseconds) i.e. enqueue could not process the locks with in time or in any massive update system, the enqueue process alone cannot serve the reuquests in this scenario. We can increase enqueue work process by using process
Rdisp/wp_no_enq= 0 to 100. Increase the enqueue process on the same server where the earlier enqueue processes are defined
Dead Locks: If the object required by one user is locked by another user and simultaneously the object required by the other user is locked by this user then there is a dead lock. But mixture of programs and SAP programs makes a way to a deadlock. In a dead lock situation either one of the user has t log off.
Releasing Locks: Rlease the locks only with the permission of the user. Te
The following is the procedure for the lock release:
User requires a ticket that he couldn’t update the record
Get the detail of the user from SM12 and communicate with the user to release the lock
If the user is not in the office communicate over mobile (Verbal) and send a mail (As per the conversation in releasing the lock….).
Send the mail cc to project manager, team leader etc..
Get the approval to log off the user session in SM04 and release the lock.
Spool Management:
It’s only the process which is used to output the documents to the printers, fax…. Spool Process work Flow:
Dialog process or background process creates a spool request i.e. to print the documents.
Ex: Dialog process use to print an individual pay slip, sales order, purchase order invoice etc…
Background processes use to run the pay roll to generate pay slips for all the employees. To print delivery orders in batch (bunch) invoices etc…
When the print order is specified by the user or background work process the spool request is stored in database or at O/S level in the global directory. The storage location is specified by the parameter rspo/store_location. This parameter has two values Global-G and database- DB
These spool requests are also referred as TEMSE. (Temporary sequential objects). These are stored in the location rspo/store_location parameter.
TEMSE is nothing but spool requests. Spool process reads Temse and generates output requests.
G- Means it is stored in global directory \usr\sap\SID\sys\global DB: Means it is stored in Database tables TST01 and TST03
TST01: It stores the objects and details of the spool requests such as name of the Author, Number of copies, name of the printer etc..
TST03: It contains spool data to be printed
DB (Database) TST01, TST03 USER DIALO G BTC Jobs DIALOG Spool Request
G (\usr\sap\sid\sys\global) TEMSE
Parameter G: The Temse resides at O/S level. It will be faster to access than
database (DB). When the spool size is small (around 300 MB) and If the spool size increases it will be difficult to locate them to print . O/S memory is used. Dedicated space needs to be taken to store the backup of Temse.
Parameter DB: Time consuming to wrote into DB. But with the help of indexes
it can be printed out fast. No special care for backup is required because it’s backed up along with normal database. O/S memory is not required.
SA38: RSOSR002 is the report used for deleting the old requests. Advantages of Temse:
The out of the spool request can be viewed before it is pronted. Spool process reads Temse and generates out put requests.
Output requests are depends upon the access method. Access Method specifies the type of access to the printer.
There are various access methods
Access Methods:
Local Access Method: The spool process and the host spool (Printer Spool) reside in the same system. Access method type L is used for unix operating systems. C is used for windows which makes a direct call to the host spooler.
Note: The printer can be remote or local
Remote Access Method: The spool process host spooler resies on two different machines. Access method U based on unix barkle protocol. User for unix os access method. S sup protocol used for windows. Front End printer: Access Method F. The printers ae connected to end user desktop do not configure too many front end printers because the resources will be blocked by the user.
F
It’s also not used for scheduling background jobs because the interactive inputs.
Defining a Printer:
Go to transaction SPAD (Spool Administration) Click O/P device Click on change Click on create Specify the output device name.
Output device name should be meaningful to identify the location and type of printer.
Specify the short name Define model, location, and message.
Device Type: Specify the type of the output device. Name of manufacturer most of the device types are available in the SAP system. But new printers which are released after the release of SAP component we need to get the new device types.
Go to SPAD Utilities for device types Import.
Spool Servers: The server with at least one spool process is called spool server. Spool server can be logical or real server. Spool servers are created in SPAD
Go to SPAD Click on Spool Server Click on create Specify the spool server name Specify server class specify device class (Standard printer) Authorization group
Note: Specify the group so that only the group assigned can access the printer
Logical Spool Server:
It is defined for fail over and load balancing between printers. USER
(Logical Server)
Click on the Access Method: Host spool access method C for Windows NT
L for UNIX
C and L are local access methods U and S for remote access method U for UNIX
S for Windows NT F for front end printing
Note: Don’t configure too many front end printers. If configured spool congestion
occurs.
To avoid spool congestion configure the parameter rdisp/wp_no_spo_fro_max=2 This parameter allows using the work process for the front end printing, let us say if we have 10 processes only 2 can be used for front end.
Specify the name of the printer
Destination Host : Name of the host where the printers are configured.
Check Box: Don’t query host spooler for output status. Each work process goes to the printer and gets the status of the printing. If this box is not checked the spool process are busy getting the status.
Output Attributes:
To print the cover page
USER LGS1 Real Spool Server Real Spool Server
Author Name Number of copies Name of the printer
Process request sequentially. Used to print the documents s sequentially. If numbering is important select this option. If not deselect the check box
Note: If the device types are not available select SWIN a default device type which will run a suplpd (Line print daemon). Suplpd is a protocol to print by default, if the device types are not available.
Spool Monitoring:
Go to SP01 Specify the User Name, Date and Time to display the list of spool requests. The following statistics of the spool requests are displayed.
“-“: The request has not been sent to the host system or the output request doesn’t exist.
“+”: Spool request generated stored in Temse
Waiting: Spool request is waiting to be processed by a spool work process.
In Process: The spool process is generating the output request based on spool request.
Printing: Printer is printing the request. The status will be displayed approximately 1 min and status sets to either Complete or Error.
Completed: The job might be completed but assume that handling over the print job to the printer is completed. The printer might not be
printed.
Problem: The output request printed but contains mirror errors such as page format, character set etc….
Error: The request has not printed. Handling Spool Requests:
Go to SP01 and select the spool requests which are thrown into errors. However we may need to act based on user requests such as the status shown completed but the documents could not be completed.
Waiting Status: These requests are waiting in the waiting status for more than one hour
Conclusion: Spool process is busy in handling the spool requests or the spool work process is not sufficient to handle the request.
User complaints that the spool request could not be generated: The printer is not available or locked in the system.
By default SAP allows 32,000 requests to be stored in Temse we can increase that up to 99,000. We cannot increase beyond 99,000 because the maximum spool number is 99,000.
Rspo/spool_id/max_number=32,000 to 99,000 Schedule the following background jobs in SA38: RSPO0041 (or) RSPO1041.
This above reports deletes the old spool requests based on status.
Schedule the reports RSPO0043 or RSPO1043 to check the consistency of the spool periodically.
Spool Problems:
The printer is not available (Printer power off, No network etc…) Paper out. No paper, Paper Jam
Cartridge or toner out Printer problem
Go to SP02. This will provide to all the users to display their own spool requests.
If the spool request is thrown in to error to a particular printer then select the printer and print select the printer with change parameter
SPIC: Spool installation check. This is used to check the spool device and pending requests along with consolidated problems and warnings.
SP12: Temse administration. It is used to check the memory allocation objects and perform the Temse consistency check
L/C U/S F Reque st Dialog Dialog Back Groun d Spool Request
Spool Server/Spool Process
LGS Local Access Remote Access Front End
Data Transfer:
Interface
SMS FAX Email Printer Internet 90% DB Fill The data has to be transferred in to SAP system in the following situations.
During implementation to transfer the data from legacy systems to SAP system. To test with live data.
Migration of legacy system DB to R/3 system Data transfer during parallel run
Parallel Run: It is an activity where both SAP and Non-SAP systems run parallel. The data entered in NON SAP system will be transferred to SAP system periodically during Off Peak hours without any user intervention. Periodic data transfer from suppliers vendors etc….
In order to communicate with vendors back end systems we need to define RFC connections.
SAP SYSTEM
BW Old Legacy
Remote Function Call: There are various types of RFC’s which are used to transfer the data.
Asynchronous RFC (ARFC) Synchronous RFC (SRFC) Transactional RFC ( TRFC) Queued RFC (QRFC)
ARFC: Does not check for the acknowledgment from the target system. These are not reliable because there is no confirmation from the target system.
SRFC: It communicates synchronously with target system and ensures that data is transferred. During the data transfer the process may go into sleep mode or CPIC mode.
CPIC Mode: Common programming interface communication. It is an SAP proprietary protocol to communicate between systems.
TRFC: It is similar to asynchronous but a transaction Id is created and is monitored in transaction SM58. A background job RSARFCSE is scheduled for every 60 seconds to check for the transaction Id’s in the transaction SM58 QRFC: It is similar to TRFC and it ensures that the transactions are
processed in the same sequence they entered in to the queue. Defining a RFC connection:
Go to SM59 Click on create Define the RFC destination name. The name should be able distinguish between the connectivity. Define the connection Type:
3 for connection to R/3 system 2 for connection to R/2 system Give description
Specify the system number Specify the system number Specify the Gateway options Gateway host
Gate way sapgw<instance number> Click on logon details
Save
Click on test connection.
If the specified user is a dialog you can click on remote login to check the connectivity.
ALE: Application Linking and Enabling
It is used to communicate between two loosely coupled systems. Use transaction SALE to define systems.
Logical System: Logical systems are used to identify the client uniquely in the landscape.
As client is identified by a number we need to assign logical system between <SID>CLNT000
Ex: DEVCLNT000, QASCLNT000, PRDCLNT000
BAPI: Business Application Programming Interface
It is used to communicate between sending system and receiving system based on interface and method.
Select the Model View Select the Send Client Select the Receiver/Server OBJ Name / Interface Method C Simulator
Add message type and specify the message type.
Note: Most of the data transfer methods are defined by functional consultants during implementation.
Ex: Central user administration uses ALE mechanism to transfer the data between clients
EDI: Electronic Data Interchange
It is used to exchange the data between SAP and NON SAP systems. SAP system needs to understand NON SAP systems.
Non SAP systems needs to understand SAP systems language In order to understand the language between systems IDOCS are implemented.
IDOC: Idoc is an intermediate document which is in the understandable format by both the systems.
Ex: Customer is having VB_SQL_Server based system. Where as SAP is based on ABAP language
Customer sends purchase order through VB system, which is converted into IDOC and sends to SAP system.
SAP system sends invoice in the native format which is converted to IDOC and sends to customer VB system.
Note: This mechanism is defined by functional and technical consultants. BASIS consultants monitor the flow of the IDOC. IDOC’s are monitored through IDOC and WE05
The sending system documents are out bound documents in the sending system. The receiving system documents are inbound documents from the sending system.
Go to WE05 select the date and time to display the IDOC’s with various statuses
00-49: Out Bound 50 and above: Inbound
Some of the states is 51 document not posted. 64- IDOC ready to transferred to application . QRFC Monitor:
GO to SMQR is used to monitor the QRFC’s. SMQ1: Is used for out bound queues
SMQ2: Is used for inbound queues
SM58: Is used for monitor the transactional RFC’s based on transaction Id’s Data Transfer Methods:
LSMW: Legacy system migration work bench: It is used to transfer the data from NON SAP system to SAP R/3 systems. This is used during implementation and mostly one time activity.
Process: Identify the data which needs to be transferred from the legacy systems. Pause truncate and PUDD the data if required i.e. mapping between the source data and receiver data.
Ex: Char (50) is source but an receiver char (40) so we may need to truncate the source by 10 characters. If receivers is char(60) se ma need to padd the data.
Session Method: This also programmed by developer but this can be used for periodic data transfer. This familiarize with error message handling
Errors during Data Transfer:
Source /target system not available
Document problems (Document is not readable, Junk character, Permissions, document not found, document is too old)
RFC erros lik t ID. RFC: Error like USERID, Password, USER ID not active WE05 IDoc expenses.
Instance
:Instance provides a set of services, work processes, Buffer-Areas to an application instance is controlled by various parameters i.e. start up
parameters, instance parameters and default parameters. These parameters describe the characteristics of an instance.
Instance mainly depends on memory resources based on available memory. We need to configure the parameters.
These parameters reside in usr\sap\sys\profile directory.
Default Profile: It provides default parameters for all the instances in the R/3 system. Some of the parameters that can be configured globally are as follows:
login/system_client=999 this determines the default client for all the users
zcsa/system_language= To specify the language during log on
login/* : All the login parameters to control password, user id etc. This can be modified based on requirement by administrators. But it
requires a restart of the instance to take effect. It’s naming convention is “default.pfl”.
Start Up Profile: It is used to start the instance. It is recommended not to change any parameters in this profile. Your instance may not start if any changes are made to this profile. Changes are allowed only when there is a change in Host names or SID. It’s naming convention will be as follows:
Start_DEVBMGS<nr>_Hostname (Central Instance) Start_D<nr>_Host name (Dialog instance)
Sapcpe.exe : It is used to communicate with database when a dialog instance is installed. It is also initiated when the central instance and database instance installed separately.
Instance Profile: It start with <SID> of instance
<SID>_D<nr>_<Host Name> (Dialog instance)
IT consists of the instance specific parameters like work processes, buffers. Go to the table “TPFYPRODTY” to display the instance specific properties grouped by dispatcher, ABAP etc. Some of the parameters are as follows: rdisp/wp_no_dia rdisp/wp_no_btc rdisp/wp_no_vb1 rdisp/wp_no_vb2 rdisp/wp_no_spo rdisp/wp_no_enq rdisp/max_wprun_time=600-1800
All ST02 transaction like abap/buffersize. If the field dynamic is set to X the parameter can be changed or in RZ11. If there is an option change value we change that parameters dynamically without restarting
server.
Profile management:
Go to RZ10 for static profiles and RZ11 for dynamic profiles:
Go to RZ10 to import profile from O/S level to database. So that
parameters are maintained at Database level and consistency between the required and threshold value is checked.
Ex: Work process should not be configured more than 100 where as this is allowed at O/S level but Database level it gives warnings. Table “TPFRT” is used to store the parameter values along with versions.
Administrative Data: Which will gives you the path of each profile. Do not change this until there is change in path of the profiles
BASIS Maintenance: This is used by technical team where
maintenance is performed without knowing the parameter names. You can toggle between the values by increasing and decreasing the
values. It is used to maintain work process buffers, memory management.
Extended Maintenance: It is used to change the parameters based on parameter names. It is used by experts and ensures that necessary care is taken while modifying parameters. Note that your instance may not start due to change parameters (Wrong parameter).
Go to RZ11 and get the documentation of the parameter before you make any changes to the parameters
Go to RZ10 select the profile to be maintained. Let us say instance profile and select Radio Button for extended maintenance. Click on create parameters. Specify the parameter and its value click on copy. Go back and save and activate profile. It will request you to restart the server for the parameter to get effected.
The existing profile in SYS/Profile will be renamed to “.bak” and profile is copied from database to O/S level. Restart the server.
Operation Modes:
Operation modes are used to define system optimally by utilizing the resources during the peak hours and off peak hours. Operation modes toggles between the day mode and Night Mode (Peak and Off peak) by utilizing the work process optimally.
Defining the operation mode is done in 2 levels:
Defining the Operation Mode: Go to RZ04 Define operation Mode SAP System name, Operation mode Click on Instance/ Operation Mode
Assigning the Time interval: Go to SM63 Select the interval and assign the operation modes
Purpose of Operation Modes: Operation modes are used to utilize the dialog process during day time and background process during the off peak hours i.e. we may not require dialog during off peak hours. We may require more BTC during off peak. We can dynamically switch between the processes without restarting the server. When opmode switch occurs it is resulted in SM21.
Don’t configure too many modes.
Note: If a background job is running, during operation mode switch it is allowed to continue t run after completing the job the operation mode switch occurs for this background work process.
Logon Load Balancing
Message Server
Logon Groups: These are used to define load balancing mechanism between the instances.
These are used for logon load balancing\fail over between the instances. These are used for optimal utilization of buffers.
Defining logon Groups:
Go to SMLG Define log on groups and assign instance
Logon groups are defined based on geographical locations based on application models.
Message server keeps the list of all logon instances and displays the favorite computer server by calculating answer time and think time.
Mechanism: End User DB L G 1 D.I D.I C.I D.I L G 2 D.I
User logon to the system using logon group
System communicated with message server based on sapmsg.ini and communicate with 3600+ instance number through entry in etc\services i.e. you need to maintain all the user desktops with the above two entries ( sapmsg.ini and etc\services)
Message server keeps the info of favorite server and route the request to that instances
Advantages:
Load balancing Fail over
Effective utilization of buffers and system resources
Performance improvement similarly logon server groups are used for RFC communication
RFC Server Groups:
These are used by RFC users to identify the least loaded server and route the request.
Go to RZ12 Define the server group and assign the instance.
We can specify various conditions i.e. number of logon’s, maximum number of work processes, maximum wait time etc.
These are mainly used for background job processing. These are used for optimally utilization of resources so that background processes are utilized effectively
System Monitoring
It is used to monitor system health on a periodic schedule to avoid the last minute surprises and accidental growth or utilization of resources
abnormally.
SM51: To identify the types of process configured and the status of the instances. As per our checklist we need to count the servers and ensure that all the active servers are running
Click on the release notes to identify the R/3 Kernel, DB Kernel, O/S kernel and support package information
Select the systems and use option “Goto” to display various properties of the instance
RZ03: Ensure that this transaction is locked in the production system. It is used to stop the instances to toggle between the operation modes.
Note: Do not stop the instances using RZ03 SM21: System logs
It is used to display the logs based on instance. Go to SM21 display the logs based on Date, Time, User and Transaction Code.
The messages are displayed with various colors.
SM21 displays error message, warnings and messages 1. Max time out reached
2. Oracle errors (ORA 1631, 1632, 1653, 1654, 255, 273, 1555) 3. Update deactivation
4. Work start up and shut down 5. Operation Mode switch
6. User distribution 7. O/S errors
9. Background job errors 10. Number range intervals
Mostly it records all the important activities. We need to look in to the errors that are displayed in RED color and light Red color
Analysis: Click on the error message. Get the error message. Identify the uses and check with the user. If any abnormalities are found get the error message and check out in market place.
ST22: ABAP Dumps
SAP system is built on ABAP language. So it executes based on ABAP
programs. If any one of the program could not be executed it will thrown into errors and recorded in SM22 and SM21.
The programs can be thrown in to dump under the following circumstances 1. Time out Error: Schedule in the background or fine tune the program
by restarting selection criteria
2. Data Base Errors: ORA 1631, 1632, 1653, 1654, 255, 272, 1555 3. PXA Errors/ Buffers: Space is not enough to store the content
4. Memory Errors: When memory to execute the program is not sufficient it will be thrown into error
5. Program Bugs: Which can be fixed by applying notes and support packages
6. Kernel Mismatch: Upgrade Kernel
7. Upgrade errors and background job errors: SQL_array_cannot_insert_duplicaterecords
8. Too many conditions and indefinite loops throws the custom program in to dump
Go to ST22 Double click on the dump and read the dump thoroughly and
understand the problem. Thoroughly understand stand the problem. Go to how to correct error and try to resolve get the error message and resolve by searching in the market place.
SM04: To display the list of users logged on to the instance. RSUSR006 is the report
we can find all users.
ST11: Developer trace of work directory
SSAA: Transaction help you to know the user has navigated to the transaction or
not. It own all the reports (Monthly, Weekly, Daily) List of transactions to be monitored:
Front End Time (or) GUI Time: The time taken by the user request to reach the
dispatcher is refereed as GUI Time or Front End time.
Normally this time should not take more than 200 m/s. If it goes beyond 200 m/sec it is considered as expensive. However it is not going to be the part of Response Time.
If GUI time increases consider the following:
1. Problem with network (Check the connectivity between GUI to Server) 2. Check whether it is a generic & Common problem (Remote Desktop) 3. GUI problems (We may need to upgrade or apply patch)
4. Logon through VPN or Firewall and proxy and filters may also be a problem
5. Using Dial Up connectivity
Wait Time: The amount of time the users request waits in the dispatcher queue.
Usually it will be 50 m/sec or 10% of response time. If Wait Time is expensive consider the following:
1. Work process congestion
2. Work processes are not sufficiently configured at the rate of ratio 1:5 (5 user, 1 work process)
3. Work process configuration is fine but the processes are held up with expensive user requests
4. The work process might gone into private mode, sleep mode, RFC, CPIC modes
Solution: Identify the expensive process and logoff the user session based on approval. We can also consider increasing of work process or deploying the
additional instance based on the load. Alternatively configure logon load balancing.
Roll-In-Time: The time taken by the work process to roll the user information into
task handler
Roll Out Time: The time taken by the work process to roll out the user information
Gateway Process:
It is used to provide gateway to the instance i.e. incoming and outgoing connections are performed through gateway.
There will be only one gateway process for each instance. Gateway is monitored in SMGW. The RFC connections, The ICM connections are displayed in SMGW
The maximum gateway connections that are allowed through gateway is 100. It is configured by process.
rdisp/max_gateway=100
Message Server
:There will be only one message server in R/3 system (Irrespective of instances).
Message server is monitored through SMMS.
It is used to handle all the dispatcher and first process to be started. In the R/3 system the instance on which it is installed is called central instance.
It is used to balance the load when groups are configured.
When log on load balancing is configured we need to maintain the entries sapmsg.ini, etc/service and define the logon groups in the GUI entry for each user. Alternatively we can copy relative saplogon.ini to the end user desktop.
SAP Archiving:
It is the process of moving the old data (which cannot be updated any more but required for data analysis and for statutory auditing requirements). The data cane be moved into global directory. If the archiving is not performed time to time the following issues are cropped up in the data center.
1. Response Time should shoots high
2. Database size grows and hardware must not sufficient in terms of memory, CPU and storage
3. The existing tapes becomes un utilized when the size groups beyond the size of the type
4. Admin costs will be high so it is recommended to archive the data from time to time
Database reorganizations should follow the SAP Data Archiving. There are third party tools available for performing archiving.
1. IXOS
2. Archiving- Archiving Pack 3. Data warehouse solution –BIW
Process: Identify the data based on objects and tables i.e. users complain that response modifying certain objects
Ex: Material, Sales order, Purchase order etc…
Go to transaction DB15: It displays objects and tables along with the size of the tables.
Go to transaction File: TO define the logical path for archiving and assign logical path to physical path.
1. Click on New entries
2. Specify logical path and name
3. Click on assignment of physical paths 4. Define syntax group (Windows NT)
5. Click on logical file name to move the data 6. Specify the logical file
7. Specify name
8. Specify the physical file 9. Specify date format
10. Specify the application area 11. Specify logical path
12. Click on SAVE
1. Go to SARA (SAP Archiving) Select the object name Click on pre processing to define the variant to schedule archiving in the
background by start date and spool parameters specify the start date and spool parameters.
2. Click on Write: To write the data click on delete specify date and parameters Execute
3. Click on delete: Select Archive selection and delete complete archive. GO to again delete and select.
4. Click on Read: we can read document 5. Storage System: We can store files.
Go to SAR1: which is archiving information system to check the status. Go to SF01: File transaction is used for cross client where as SF01 is used for client specific files.
CCMS Monitoring
CCMS: Computer center monitoring systemGo to RZ20 Extras menu Activate maintenance function
It is used to raise the alerts based on the threshold values which are defined in the system.
RZ20:
Display monitor sets Monitors Monitoring trace elements properties methods Variants
Monitor Set: It consists of all the monitoring activities Monitor: Specific to a certain function
Monitor Tree Elements: Elements to be monitored Method: This is specific to a process or activity Property: Monitoring category variant is value
Go to RZ20 Extras Activate maintenance function
It is used to raise the alerts based on the threshold values which are defined in the system
Add define your own monitor se from the existing templates: 1. Create: Define elements
2. Copy: include only the monitoring required elements CCMS displays the elements in color:
1. RED: Problem 2. YELLOW: Warning 3. GREEN: ok
4. WHITE: Information not obtained/ not collected MTE: Monitoring tree element