应用程序部署后，在大量的用户在上面操作，有的时候会发现数据库运行很慢，并且出现假死的状态，必须重启应用后才能继续运行，请问一下如何解决？
在数据库里面看见的日志如下，应用程序无报错，只是很慢： DETAILED ADDM REPORT FOR TASK 'ADDM:3184345080_1_1649' WITH ID 3008
-------------------------------------------------------------------
Analysis Period: 02-DEC-2011 from 15:00:33 to 16:00:02
Database ID/Instance: 3184345080/1
Database/Instance Names: DSJCYZH/dsjcyzh1
Host Name: DB1
Database Version: 10.2.0.4.0
Snapshot Range: from 1648 to 1649
Database Time: 86159 seconds
Average Database Load: 24.1 active sessions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
FINDING 1: 99% impact (85416 seconds)
-------------------------------------
SQL statements were found waiting for row lock waits.
RECOMMENDATION 1: Application Analysis, 50% benefit (42866 seconds)
ACTION: Significant row contention was detected in the INDEX
"ZHPT.IDX_DOCTASK_REMARK" with object id 54792. Trace the cause of
row contention in the application logic using the given blocked SQL.
RELEVANT OBJECT: database object with id 54792
RATIONALE: The SQL statement with SQL_ID "6c39sgtshj227" was blocked on
row locks.
RELEVANT OBJECT: SQL statement with SQL_ID 6c39sgtshj227
insert into T_BPM_DOCUMENT_TASKEX (actorsName, auditDate, taskName,
processDefineId, taskId, pageUrl, actors, actorRoles, actorType,
actorLogic, dueDate, re, formConfigDes, processName,
emergencyState, smsRemind, actorDepts, taskTypeItemId,
taskTypeItemName, nodeId, expend1, expend2, expend3, expend4,
parentId, startDate, flag, expend5, expend6, seeDate, limitDate,
expend7, expend8, expend9, expend10, id) values (:1, :2, :3, :4, :5,
:6, :7, :8, :9, :10, :11, :12, :13, :14, :15, :16, :17, :18, :19,
:20, :21, :22, :23, :24, :25, :26, :27, :28, :29, :30, :31, :32, :33,
:34, :35, :36)
RATIONALE: The SQL statement with SQL_ID "50r8b447x3f0s" was blocked on
row locks.
RELEVANT OBJECT: SQL statement with SQL_ID 50r8b447x3f0s
update T_BPM_DOCUMENT_TASKEX set actorsName=:1, auditDate=:2,
taskName=:3, processDefineId=:4, taskId=:5, pageUrl=:6, actors=:7,
actorRoles=:8, actorType=:9, actorLogic=:10, dueDate=:11, re=:12,
formConfigDes=:13, processName=:14, emergencyState=:15,
smsRemind=:16, actorDepts=:17, taskTypeItemId=:18,
taskTypeItemName=:19, nodeId=:20, expend1=:21, expend2=:22,
expend3=:23, expend4=:24, parentId=:25, startDate=:26, flag=:27,
expend5=:28, expend6=:29, seeDate=:30, limitDate=:31, expend7=:32,
expend8=:33, expend9=:34, expend10=:35 where id=:36
RATIONALE: Session with ID "885", User ID "60", Program "" and Module ""
was the blocking session responsible for 40% of this recommendation's
benefit.
RATIONALE: Session with ID "917", User ID "60", Program "" and Module ""
was the blocking session responsible for 14% of this recommendation's
benefit.
RATIONALE: Session with ID "1032", User ID "60", Program "" and Module
"" was the blocking session responsible for 14% of this
recommendation's benefit.
。。
SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: Wait class "Application" was consuming significant database
time. (99% impact [85416 seconds])
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ADDITIONAL INFORMATION
----------------------
Wait class "Cluster" was not consuming significant database time.
Wait class "Commit" was not consuming significant database time.
Wait class "Concurrency" was not consuming significant database time.
Wait class "Configuration" was not consuming significant database time.
CPU was not a bottleneck for the instance.
Wait class "Network" was not consuming significant database time.
Wait class "User I/O" was not consuming significant database time.
Session connect and disconnect calls were not consuming significant database
time.
Hard parsing of SQL statements was not consuming significant database time.
The analysis of I/O performance is based on the default assumption that the
average read time for one database block is 10000 micro-seconds.
An explanation of the terminology used in this report is available when you
run the report with the 'ALL' level of detail.
再有配置一下Oracle的最大连接用户数量。