Sei sulla pagina 1di 85

APJ Region Management System

SAP Daily TASK WELSPUN

SOP INTEGRATED BUILDING MANAGEMENT


SYSTEM

Preamble
Statement of Proprietary Information
The information contained in this document is confidential to HP. The document may
not be disclosed, duplicated, or used, for any purpose, in whole or in part, without the
prior written consent of HP.

Document Status
Version Number:

Version 1.0 D

Date:

15-July-2013

Copy Number:

Electronic distribution

Document Author
Title:

DL

Name:

Suresh Babu T

Document Reviewer

Title:

Regional Delivery Lead (RDL)

Name:

Bhaskar B V

Document Owner
Title:

DL

Name:

Suresh Babu T

Document Authorization

Title:

Capability Service Manager SAP

Name:

Badre Alam

Signature:

Electronic approval received

Date:

Distribution
This procedure is available to those HP team members involved with ITO India EAO
SAP for WCL functions. Any printed copies of this document are to be considered as
information only and not subject to document control. The manual is contained in the
ITO EAO SAP for WCL shared directory.
Share Point Portal URL

Shared Drive URL

http://ent141.sharepoint.hp.com/teams/WLSPUN/SitePages/Home.aspx

Glossary
QA

Quality Assurance

Referenced Documents
The following are key reference documents for the Group. Unless otherwise specified, the
latest version should be used as the valid reference point.

Document Title

Location

CHANGE HISTORY
The following Change History log contains a record of changes made to this document:
Published /
Revised

15-JULY-2013

Version
#

1.0 D

Author
(optional)

Section /
Nature of Change

1.0 D

Draft release for RDL Review


RDL ( B V Bhaskar ) review complete

1.0 D

Capability SM ( Badre Alam ) approved

1.0 D

Include links to peer review record(s):

1st Approved version in QMS format

Peer Review Link

Comments

CONTENTS
1

Daily Check List


6

Sheet Items--------------------------------------------------

Weekly Check List ----------------------------------------------------------------7

CHECK THE SYSTEM DUMPS (ST22)-------------------------------------9

CHECK THE SAPOSCOL -----------------------------------------------------10

CHECK FOR LOCKS (SM12)-------------------------------------------------13

CHECK BACKGROUND JOBS HISTORY (SM37)----------------------15

SYSTEM MONITORING (SM66 / SM50)-----------------------------------16

DAILY DB GROWTH (DB02)---------------------------------------------------20

CHECK THE BACKUP STATUS (DB13)------------------------------------21

10 CHECK THE V1, V2 UPDATE (SM13)---------------------------------------23


11 CAPTURE USERS ANALYTICAL DATA------------------------------------24
12 CAPTURE TRANSACTIONS PROFILE DATA---------------------------- 25

1. DAILY CHECK LIST SHEET ITEMS


2.
3.
4.
5.
6.
7.
8.
9.

Number of Dialog steps performed


Average Dialog Response Time
Average DB Response Time
Average Processing Time
Number of users logged-in (high, medium & low)
Scheduled background jobs
Any locks older than 24 hrs
Any critical Dumps

10.External mail from ECC / failures


11.Backup status (including online + archive)
12.Spool status
13.Update Status
14.DB growth
15.Number of transport taken to QAS and PRD
16.Number of calls received

2. WEEKLY CHECK LIST SHEET


1.
2.
3.
4.

Check the system maintenance jobs also cross check the BASIS table growth
Weekly DB growth
TOP 10 transactions of the week by DB response time
TOP 10 transactions of the week by processing time

TOP 10 transactions of the week by processing time

CHECK THE SYSTEM DUMPS (ST22)

Checking Interval:
every 30 minutes during support hours
Observation/Symptoms:
Any running sessions / processes creating continuous dumps
Number of dumps by the same program is more than 20
Action

:
Kill the process immediately

Identify the program / tcode and inform to respective module lead and APPS LEAD
If it is Z-program- inform to ABAP LEAD and respective module lead

CHECK THE SAPOSCOL

Checking Interval:
Twice in a day (start of A shift and end of B shift), Check this in all the server

Observation/Symptoms:
SAPOSCOL is not running

Action

Start the SAPOSCOL

If SAPOSCOL is not running on the DB node then stop the service using command
In OS level from putty
SAPOSCOL k
Start the OSCOL with SAPOSCOL l

Goto ST06

Check for update failure (SM13)

Checking Interval:
every 30 minutes during support hours
Observation/Symptoms:
Any (one or more than one) Update failure reported
Check for Update is active
Action

Take the screen shot and inform to the respective module lead
If update is not active due to any reason; immediately activate this.
Investigate the reason from the logs.

High Alert:
If repeated update failure reported for the same t-code / program for
more than 3 days / 3 times in a day, then it is a High alert.
Inform to Module lead, APPS LEAD. Also inform to ABAP LEAD (incase
of z tcode)

SM13

CHECK FOR LOCKS (SM12)

Checking Interval:
every 30 minutes during support hours
Observation/Symptoms:
Checks for number of locks;
in an ideal condition this should not be more than 12-15k during peak
load
After each refresh this locks are getting increased

user is occupying more than 1000 locks for more than 15 minutes
Locks for more than 24 hrs

Action :
Identify the user who is holding the maximum number of locks; also
find out the program / transaction occupying the locks
Immediately inform to Mr Sreekumar, APPS Lead. If any Z transaction
holding the same also involve the ABAP Lead.
Kill the processes in concurrence with the Basis Teamand APPS Lead.

If you observed that any locks are hold for 24 hrs or above,
immediately contact the respective user and based on his confirmation
delete the lock.

High Alert:
If repeated locks reported for the same t-code / program for more than
3 days / 3 times in a day, then it is a High alert.
Inform to Module lead, APPS LEAD. Also inform to ABAP LEAD (incase
of z tcode) to investigate the reason.

Correct the program (if it is Z tode)


Raise the very high message with OSS incase of SAP standard
transactions

SM12

CHECK BACKGROUND JOBS HISTORY

(SM37)

Checking Interval:

Twice in a day (start of A shift and end of B shift); Capture the failed jobs in the daily report.
List down all the batch jobs module-wise, running frequency and its owners

Observation/Symptoms:
Scheduled business jobs failed
Action

Inform to the job owner, respective module lead and if it is Ztcode /zprogram job; inform to respective module and ABAP Lead.

T code SM37

SYSTEM MONITORING (SM66 / SM50)

Checking Interval:
every 30 minutes during support hours
Observation/Symptoms:
1. One user running single background job for more than 6 hrs
2. One user running multiple background jobs (> 4) for more than 4 hrs
3. Multiple DIALOG processes occupied by one user for more than 30
minutes

4. DIALOG processes are almost occupied (i.e. only 3 / 4 DIA processes


are free)
5. Processes are in PRIV mode
6. Multiple time restart of processes
T Code SM66

T Code SM50

Action :
1. For point 1
o Inform to respective user that you are running transaction for
these many hours; based on his confirmation take appropriate
action.
o OR Send mail to the end-user who is running the jobs; if the
users confirm then kill it.
o For any long running background jobs i.e. more than 24 hrs
immediately call the user / send mail / popup message thru SAP.
o If user not reverted within 30 minutes; kill the processes

BACKGROUND JOBS for more than 24 hrs allowed only in


exceptional cases but user has to inform to BASIS team in
advance.
2. For point 2
o Send mail to the end-user who is running the jobs;
o If user not reverted within 30 minutes; send the 2 nd reminder
o If the users confirm then kill it otherwise wait for additional 1 hr.
o If no response received from the end user and jobs reached to 6
hrs+ then inform to
o

BASIS team take appropriate actions after business


confirmation.
3. For point 3
o Inform to respective user that you are running transactions in
dialog mode for more than 30 minutes; based on his
confirmation take appropriate action.
o OR Send mail to the end-user who is running the transaction
o If user not reverted within 15 minutes; kill the dialog processes
4. For point 4 (High Alert)

o
o
o
o

Inform to Basis Teamand APPS LEAD immediately.


Based on approval, kill few of the long running dialog processes
Keep monitoring the system very carefully
Investigate the reason from the logs what transactions / user
lead to this situation

5. For point 5 & 6


Analyze it, how many users are getting into PRIV mode and
what is the reason.

Also check if there is any multiple restart of processes


reported.

Check the System Logs (SM21)


Checking Interval:
every 30 minutes during support hours
Observation/Symptoms:

Correlate the messages with the current system status; if any errors reported; investigate this.

Action:

Proactive evaluation of the warning / error


T Code SM21

DAILY DB GROWTH (DB02)

Checking Interval:
Once in a day (start of A shift)

Observation/Symptoms:
Record the database delta growth day-wise in the daily monitoring sheet

Action

:
Reporting purpose
If high volume of data growth (i.e. > 5 gb) reported on any day; immediately speak to APPS Lead /
Basis Teamto find out the additional activities performed that led to the sudden growth.

Also investigate the table growth (i.e. which table grown more during the day)
Record this in the daily monitoring sheet with remarks about the observation.

TCode DB02

CHECK THE BACKUP STATUS (DB13)

Checking Interval:
Once in a day (start of A shift)

Observation/Symptoms:
Record the backup status (completed / failed) in the daily monitoring sheet

Action

:
Reporting purpose
Also note down the last log number that was taken during the backup.

T Code DB13

T Code DB12

10

CHECK THE V1, V2 UPDATE (SM13)

Checking Interval:
every 30 minutes during support hours
Observation/Symptoms:

Correlate the messages with the current system status; if any errors reported; investigate this.

High Alert

If you observe that V1/V2 update (Sm13) processes are pilling-up for more than 15 minutes inform
to APPS LEAD, Basis Team immediately.
Take the screen shot and inform to respective module lead
Check the number of locks occupied

Action:

Identify the user who is holding the maximum number of V1/V2


updates under Initial state.
After confirmation from APPS LEAD, Basis Team; kill the specific user
processes that holding the update in queue.

Immediately contact the respective lead and investigate the reason


what led to pilling of V1/V2 update
Lock the user after confirmation from Basis Team.
In case of Z-transactions, inform to ABAP lead.
For any other SAP standard transactions raise the very high message
with OSS

11

CAPTURE USERS ANALYTICAL DATA

Checking Interval:
Once in a day (start of A shift)

Observation/Symptoms:
Top 5 users based on number of DIALOG steps executed
Top 5 users based on DB response times
Action

Analysis
The same report shall be used for weekly review meeting to analyze
the users behavior in terms of executing the transactions and response
time.

12

CAPTURE TRANSACTIONS PROFILE DATA

Checking Interval:
Once in a day (start of A shift)

Observation/Symptoms:
TOP 10 transactions based on number of DIALOG steps
TOP 10 transactions based on number of DB response time
Action

ST03n

Analysis
The same report shall be used for weekly review meeting to analyze
the users behavior in terms of executing the transactions and response
time.

1.

Potrebbero piacerti anche