1) What are your daily activities?
2) What is meant by load monitoring?
3) What are the tickets you got?
4) What are the errors you got?
The typical tickets in a production Support work could
be:
1. Loading any of the missing master data attributes/texts.
2. Create ADHOC hierarchies.
3. Validating the data in Cubes/ODS.
4. If any of the load runs into errors then resolve it.
5. Add/remove fields in any of the master data/ODS/Cube.
6. Datasource Enhancement.
7. Create ADHOC reports.
And their Solutions :
1. Loading any of the missing master data attributes/texts
- This would be done by scheduling the infopackages for the attributes/texts
mentioned by the client.
2. Create ADHOC hierarchies. - Create hierarchies in
RSA1 for the info-object.
3. Validating the data in Cubes/ODS. - By using the Validation
reports or by comparing BW data with R/3.
4. If any of the load runs into errors then resolve it.
- Analyse the error and take suitable action.
5. Add/remove fields in any of the master data/ODS/Cube.
- Depends upon the requirement
6. Datasource Enhancement.
7. Create ADHOC reports. - Create some new reports based
on the requirement of client.
Load Monitoring means we check whether the data is loading properly or not and we can analyze the failures (It will show in status tab). We do monitoring at data loading level.
Monitoring Info Package is goto RSMO-> chk the
details tab->Processing -> you can find all the process availble in data
load towards the target.
Mostly in the status tab the error message will be shown.
You can look the past history of the load by using the filter option for the package for the last week or this month and last month. You can come to conclusion the average time and data for the load.
If the load is from R/3, Take request number from the
header table and goto SM37 of R/3 then chk the status of the request. Goto
its job detail chk for ARFCSTATE of each datapackage chk for the sysfail
there.
Few more errors occur in production and support like:
1. Timestamp error:replicate the ds
2. Rfc failure error: check through sm59
2. Ods data is not acivated error: manulaay activate
it
4. Alert remote is locked error: check with basis
6. Sid is not matched:check master data before loading
t data
7. Sid number range error.: schduler menu set number
ranger
8. Short dump: check it in st22
9. Cache problem.: restart the load,refresh the catch.
Generally In Production Support Project, we will use the check the loads by using RSMO for Monitoring the loads and we will rectify the errors in that by using step by step analysis.
The consultant is required to have access to the following transactions in R3.
1. ST22
2. SM37
3. SM58
4. SM51
5. RSA7
6. SM13
Authorizations for the following transactions are required in BW.
1. RSA1
2. SM37
3. ST22
4. ST04
5. SE38
6. SE37
7. SM12
8. RSKC
9. SM51
10. RSRV
The Process Chain Maintenance (transaction RSPC) is used to define, change and view process chains.
Upload Monitor (transaction RSMO or RSRQ (if the request is known).
The Workload Monitor (transaction ST03) shows important overall key performance indicators (KPIs) for the system performance.
The OS Monitor (transaction ST06) gives you an overview on the current CPU, memory, I/O and network load on an application server instance.
The database monitor (transaction ST04) checks important performance indicators in the database, such as database size, database buffer quality and database indices.
The SQL trace (transaction ST05) records all activities on the database and enables you to check long runtimes on a DB table or several similar accesses to the same data.
The ABAP runtime analysis (transaction SE30)
The Cache Monitor (accessible with transaction RSRCACHE
or from RSRT) shows among other things the cache size and the currently
cached queries. The Export/Import Shared buffer determines the cache size;
it should be at least 40MB.
Remedy, Peregrene, Vantiv are all CRM (Customer Relation Management) tools used for tracking tickets and managing in support. The issues are tracked using these tools.
Vantive : It is a problem tracking tool.
Each vantive ticked raised has a unique vantive ID.
Ticket when initially raised is in open status.
When the related team takes up the ticket, it is set to working status.
Once issue is resolved, then ticket status is changed
to resolvedafter confirming with user who raised ticket.
A responsible person checks the ticket to see that all
required information is filled and then ticket status is changed to closed.
You can also keep status on 'hold' if you are waiting
for user response.
There are also various tabs in the ticket to write updates,
to reassign the ticket etc.
