The Lock Deadlock History screen can be used to identify the
    object that causes a deadlock event.

    The Stall Messages screen provides stall information, but when a
    lock is deadlocked, the stall is terminated and the information
    is no longer available on the Stall Messages screen.

    For each active process on the current VMScluster node, the Lock
    Deadlock History screen shows the process ID, the time that the
    process was most recently involved in a deadlock, the reason for
    the most recent deadlock, and the number of deadlocks the process
    has encountered since attaching to the database.

    The information shown in the screen includes:

    o  process ID

       The process ID of each active process.

    o  occurred

       The time that the process encountered the most recent
       deadlock. This field is blank if the process has not
       encountered any deadlocks.

    o  lock deadlock reason

       The event that caused the most recent deadlock encountered
       by the process. This field is blank if the process has not
       encountered any deadlocks. Note that the lock deadlock reason
       does not identify the cause of the deadlock. The conflicting
       process could be on a different VMScluster node. Rather, the
       lock deadlock reason provides historical information that can
       help the DBA track down the deadlock by other means, such as
       using the RMU Show Locks utility or examining the application
       transaction data flow analysis. The lock deadlock reason
       remains displayed for a process until the process is involved
       in another deadlock or detaches from the database. For more
       information on interpreting the lock deadlock reasons, see the
       descriptions for the stall reasons in the help text for the
       Stall Messages screen.

    o  deadlock

       The number of deadlocks the process has encountered since
       being attached to the database. This field is blank if the
       process has not encountered any deadlocks. This information
       may be as useful as the lock deadlock reason in determining
       the importance of the deadlock. For instance, if the database
       has been active for a week and the number of deadlocks is low,
       the system may be operating efficiently. Deadlocks are fairly
       common in a database system, and not all deadlocks are bad.

    By using the Lock Deadlock History screen to examine the most
    recent deadlocks, a DBA can more easily identify potential
    database hot spots and application bottlenecks. Looking
    at a screen full of deadlock information can help the DBA
    differentiate between frequent and infrequent problems and
    correlate common causes of the problems.

    Some of the deadlocks that appear on the Lock Deadlock History
    screen are page deadlocks. The lock deadlock reason "waiting
    for page n:nnn" appears for page deadlocks. Although a page
    deadlock is not necessarily a bad occurrence, it could indicate
    a potential performance problem. Sometimes a process that is
    experiencing a page deadlock appears on the Lock Deadlock History
    screen, and a high number of deadlocks is reported for the
    process. However, the lock deadlock reason gives the reason for
    only the most recent deadlock, so all the reported deadlocks
    for the process may not be for the indicated page. If the number
    of deadlocks reported is high for the time the process has been
    attached to the database, the DBA should examine the process in
    detail. A high number of deadlocks for a process can indicate a
    major design problem.

    In general, record deadlocks are undesirable and the cause of
    such deadlocks should be discovered and fixed. Page deadlocks are
    not always bad, but they need to be analyzed.