1. What will you do when there is a performance issue?
Check whether any long running jobs are there
Check for deadlocks
SM12 locks
Health of the database DB02 and DB01, ST04, SM50
2. How do you handle the lock entries?
1 - If there are lock entries over 24 hours old, they must be investigate (Please follow the steps below for investigate the locks).
2 Double click on the process which is over 24 hrs old (this is often indicated by the date)
3 - Look for the HOST NAME, and WORK PROCESS.
4 - Go to SM51
5 -Select the server which has the lock, and look for the work process in question.
6 - If the process is still active DO NOT REMOVE FROM SM12.
7 - If the process is no longer active, REMOVE THE LOCK FROM SM12
3. How do you handle the update failures?
We can see the update failures in SM13
The update work process reads the data from the VB* tables and executes the updates in the corresponding tables of the R/3 database. Once the update is successfully completed, the entries in the VB* tables and in the lock table are deleted.
If an error occurs, the lock table entry is deleted, but the entries in the VB* tables are not deleted. The user is notified immediately by an express mail. Depending on the business data object, the entry may be reposted.
You can update the database asynchronously using ABAP keyword Call function ... in update task. In special cases only, you can also update the database synchronously inside a dialog service (this is also called a hard update).
4. What is the purpose of a gate way server?
For external communication. From SAP to any systems...
The gateway server (GW or G) allows communication between R/3, R/2 and external Application systems.
5. What are the profiles that are maintained in the R3 system?
Instance profile, start profile and default profile.
6. Tell some profile parameter that you have maintained?
Ex) rdisp/max_wprun_time
7. Do you know about operation modes? How do you define operation modes?
An operation mode defines a resource configuration for the instances in your R/3 System. It can be used to determine which instances are started and stopped, and how the individual services are allocated for each instance in the configuration.
To provide additional dialog or background processing resources during a particular period of time without having to restart the R/3 System.
SM63, RZ04
8. What is response time?
Time taken for single dialogue step.
9. What is roll in and roll out?
The memory management system differentiates between main memory areas that are available exclusively to a work process and memory areas that can be used by all work processes. The memory space used exclusively by a work process stores session-specific data that must be kept longer than the duration of a work step. This data is automatically made available to the process at the start of a dialog step (rolled-in) and saved at the end of the dialog step (rolled-out). This data characterizes users (user context), such as their authorizations, administration information and additional data for the ABAP and dialog processor. Also it contains data collected by the system in the preceding dialog steps in the running transaction (see following slide). Additional memory areas used by all processes in shared memory include areas for the factory calendar, screen, table, and program buffers.
10. What are V1 and V2?
UPD: Update process for making V1 (time-critical) database changes
UP2: Update process for executing V2 (not time-critical) database changes
The update process can be performed in several steps. The time-critical part of an update is called a V1 update, the non-time-critical part a V2 update. An example of a V2 update is the creation of statistical business data.
When using transaction SM13 for V1 updates, we do not recommend "posting" or repeating the transaction.
If an update error occurs, first solve the problem that caused the error. Then restart the transaction.
If a V1 update was successful but the V2 update aborts, we recommend that you use transaction SM13 to post the aborted V2 update.
If you use the System Administration Assistant for your daily system checks, it provides you with direct access to transaction SM13.
11. What will you do when spool process fails?
Each of the following components is involved in the SAP spool service and each can fail:
· Spool work process (this prepares the output data and processes the print job)
· Database service and file system of operating system
· Number range service
· Transfer program (SAPLPD).
· Destination host
· Host spool system
· Output device (for example, printer)
A single spool server can support multiple spool work processes.
· When a spool server fails
An output device is tied to a single spool server. Do the following:
¡ Re-assign printers from a failed spool server to a new spool server...
¡ to anticipate the problem, set up multiple and alternate spool servers to increase the availability of your spool service. You can also implement load balancing for the spool service.
· When the database service fails
If the database service fails, no further spool requests can be generated and the following applies:
¡ Existing spool requests that have not yet been processed are not lost but they cannot be processed.
¡ Spool requests for which output requests have already been passed to the host spooler or SAPLPD (the transfer program) before the failure of the database service are processed by the host spool system. However, it is not possible to write a corresponding entry indicating "success" in the log table for the spool request.
¡ The spool service is unavailable for the period when the database is down.
· When SAPLPD, the destination host, or the host spool system fail
In this case the spool request cannot be successfully processed. Such requests are sometimes set to "failed" in the corresponding spool table entries and you can manually restart them, once you have fixed the original problem (that is, the failure in the program SAPLPD, destination host, and host spool system).
· When the spool work process fails
In this case the dispatcher restarts the failed spool work process. Then the relevant "administration transaction" on the database is rolled back, so that the uncompleted spool requests are not deleted. The new spool work process then takes over the work of the terminated one.
· When the output device (for example, printer) fails
In this case the spool request is usually not set to "failed" in the log table. Instead it is normally set to "completed". For example, this situation might arise because the host spool system incorrectly reports successful processing or because the host spool system does not report anything and processing is assumed to be complete, once the output request has been passed to the host spool system.
So that you can manually restart such spool requests, do the following:
¡. Do not set the flag "delete after print".
¡. Set the "retention period" to a high value (for example, 8 days), so that these spool requests are not deleted.
You can avoid the manual restart if the host spool system itself automatically repeats the output request, once the existing device has been repaired or an equivalent device has been installed and defined to the host spool system. In this case, the spool request in the log table is not defined as failed since the host spool system has not reported a failure.
· When a failed output device cannot be repaired
If an equivalent device is not available, then it is not possible to satisfactorily print the output requests that were prepared for the failed device type on a different device type. You need to regenerate the spool requests in this situation, or alter them, so that they can be printed on a different device type. You can redirect spool requests from list-type output (that is, from SAP reports), assuming the spool type and print control exist on the different device type, but not output from SAP script.
You can define a "device pool" containing equivalent devices. If a device defined in a device pool fails, you must remove the failed device from the device pool using the spool administration (transaction SPAD) so that the failed device does not receive any further requests. The device pool continues operating after the failure of a device but with reduced throughput. Any requests that were assigned to the failed device before it was removed from the pool are not automatically redirected to functioning devices in the pool.
12. How R3 systems are communicated?
With ALE technology, SAP R/3 allows communication between distributed applications: R/3-R/3 systems, R/3-R/2 systems, R/3 external application systems.
13. What are central user administration and its uses?
Using Central User Administration, you can maintain user mater records centrally in one system. Changes to the information are then automatically distributed to the child systems. This means that you have an overview in the central system of all user data in the entire system landscape.
Distribution of the data is based on a functioning Application Link Enabling landscape (ALE Landscape). In this way, data can be exchanged in a controlled manner and is kept consistent. ALE System Group is used by the Central User Administration to distribute user data between a central system and child systems linked by ALE. You should therefore familiarize yourself with basic information about the Central User Administration data is distributed asynchronously between the application systems in an ALE environment. This ensures that it still reaches the target system even if it was unreachable when the data was sent.
One system in the Central User Administration ALE environment is defined as the central system. The central system is linked with every child system in both directions. The child systems are not linked to each other, with the exception of the central system, which is itself a child system, from the point of view of Central User Administration.
14. How do set the alert monitors?
RZ20.
15. Diff between SM50 and SM66?
SM50-Process Monitoring for single server
SM66-Detailed Work processes overview across servers
No comments:
Post a Comment