问题:
一个CS的软件,数据库是10g。用户近期反映打开列表和表单时系统反应迟钝,以前三到四秒,现在需要二三十秒,当前数据量最大到千万级,很显然不正常,目前还未找到彻底解决的办法,烦请有经验的高手给点建议如何优化。谢谢!
SQL语句:
---1、找出磁盘读高的语句
Select sql_text,
       disk_reads,
       executions,
       disk_reads / decode(executions, 0, 1, executions) reads_per_exec
  from v$sqlarea
 order by reads_per_exec desc;
查询结果:
    SQL_TEXT DISK_READS EXECUTIONS READS_PER_EXEC
1 SELECT ID,TemplateID FROM InstanceAddinational WHERE ParentID='{bbfc9d14-4416-4373-9570-d96085f5ed2d}' and SAFETYORCONTENT =0 295460 3 98486.6666666667
2 SELECT COUNT(*) FROM InstanceAddinational WHERE ParentID='{bbfc9d14-4416-4373-9570-d96085f5ed2d}' and SAFETYORCONTENT =0 492427 5 98485.4
3 SELECT COUNT(*) FROM InstanceAddinational WHERE ParentID='{67ff783b-d85c-4d2d-b594-8fc48beb7150}' and SAFETYORCONTENT =0 196861 2 98430.5
4 SELECT id FROM INSTANCEADDINATIONAL WHERE ParentID='{1e0cf5d0-1626-4632-bc5a-d2b69ef3eb56}' and SAFETYORCONTENT =0 order by CREATEDATETIME  196853 2 98426.5
5 SELECT COUNT(*) FROM InstanceAddinational WHERE ParentID='{0c4d447c-1f91-4ac3-a3ea-bc101cd390a7}' and SAFETYORCONTENT =0 196825 2 98412.5
6 SELECT COUNT(*) FROM InstanceAddinational WHERE ParentID='{591d26fc-fbe8-40ce-96df-8b2bc4d6934d}' and SAFETYORCONTENT =0 196811 2 98405.5
7 SELECT id FROM INSTANCEADDINATIONAL WHERE ParentID='{3304c787-f4e4-4a1a-bcb8-710c3d6fcaaf}' and SAFETYORCONTENT =0 order by CREATEDATETIME  196732 2 98366
8 SELECT COUNT(*) FROM InstanceAddinational WHERE ParentID='{8c1c2863-2a44-4c45-aaaf-9746691e1433}' and SAFETYORCONTENT =0 196700 2 98350
9 SELECT ID,TemplateID FROM InstanceAddinational WHERE ParentID='{3304c787-f4e4-4a1a-bcb8-710c3d6fcaaf}' and SAFETYORCONTENT =0 294583 3 98194.3333333333
10 select count(*) from instance i,instanceaddinational a where i.id=a.parentid and i.id='{bbfc9d14-4416-4373-9570-d96085f5ed2d}' and a.safetyorcontent=1 783625 8 97953.125
11 select count(*) from instance i,instanceaddinational a where i.id=a.parentid and i.id='{3304c787-f4e4-4a1a-bcb8-710c3d6fcaaf}' and a.safetyorcontent=1 1075375 11 97761.3636363636
12 SELECT ID,TemplateID FROM InstanceAddinational WHERE ParentID='{12737abc-9314-4d80-a403-cc7b5910418a}' and SAFETYORCONTENT =0 195451 2 97725.5
13 select count(*) from instance i,instanceaddinational a where i.id=a.parentid and i.id='{8c1c2863-2a44-4c45-aaaf-9746691e1433}' and a.safetyorcontent=1 194098 2 97049
14 select count(*) from instance i,instanceaddinational a where i.id=a.parentid and i.id='{1e0cf5d0-1626-4632-bc5a-d2b69ef3eb56}' and a.safetyorcontent=1 193739 2 96869.5
15 select count(*) from instance i,instanceaddinational a where i.id=a.parentid and i.id='{069a055f-6f1c-4384-8f55-214259e95980}' and a.safetyorcontent=1 387464 4 96866
16 SELECT id FROM INSTANCEADDINATIONAL WHERE ParentID='{8d1b8248-7406-444a-80e4-cebd78d14cb1}' and SAFETYORCONTENT =0 order by CREATEDATETIME  96837 1 96837
17 select count(*) from instance i,instanceaddinational a where i.id=a.parentid and i.id='{127d2fc7-1f8a-490b-94c2-bd99f4140188}' and a.safetyorcontent=1 193475 2 96737.5
18 select count(*) from instance i,instanceaddinational a where i.id=a.parentid and i.id='{9a2e01c3-bb83-47f8-82a1-ec983058e309}' and a.safetyorcontent=1 193153 2 96576.5
19 select count(*) from instance i,instanceaddinational a where i.id=a.parentid and i.id='{a181b123-e81b-44ed-8ba0-1be7a0ffde01}' and a.safetyorcontent=1 96506 1 96506
20 SELECT * FROM INSTANCEADDINATIONAL WHERE ParentID='{8d1b8248-7406-444a-80e4-cebd78d14cb1}' and SAFETYORCONTENT =1 order by CREATEDATETIME  96501 1 96501
21 SELECT COUNT(*) FROM InstanceAddinational WHERE ParentID='{d6782ec6-db3f-4d0e-9dfe-88baae2cf998}' and SAFETYORCONTENT =0 96492 1 96492
22 SELECT ID,TemplateID FROM InstanceAddinational WHERE ParentID='{b2505f24-f0c5-4315-9b73-739c0b71061b}' and SAFETYORCONTENT =0 96488 1 96488
23 SELECT ID,TemplateID FROM InstanceAddinational WHERE ParentID='{3b14c622-7a25-4d7f-b09a-5930059a09b3}' and SAFETYORCONTENT =0 96478 1 96478
24 SELECT ID,TemplateID FROM InstanceAddinational WHERE ParentID='{538ce67c-a00f-427f-bec5-b47905a25fad}' and SAFETYORCONTENT =0 96324 1 96324
25 select count(*) from instance i,instanceaddinational a where i.id=a.parentid and i.id='{591d26fc-fbe8-40ce-96df-8b2bc4d6934d}' and a.safetyorcontent=1 288860 3 96286.6666666667
26 SELECT COUNT(*) FROM InstanceAddinational WHERE ParentID='{b551acba-bf87-4b2f-95d7-754730101d39}' and SAFETYORCONTENT =0 96068 1 96068
27 SELECT ID,TemplateID FROM InstanceAddinational WHERE ParentID='{3848b4f9-c35d-4306-b8c4-4a9f0b46c3c6}' and SAFETYORCONTENT = 0 96064 1 96064
28 SELECT ID,TemplateID FROM InstanceAddinational WHERE ParentID='{c12dac65-765c-48f1-811d-0fb91a7e9966}' and SAFETYORCONTENT = 0 95959 1 95959
29 SELECT ID,TemplateID FROM InstanceAddinational WHERE ParentID='{1ac3f513-8015-48a5-a6c9-c5372bc07ebd}' and SAFETYORCONTENT = 0 95903 1 95903
30 select count(*) from instance i,instanceaddinational a where i.id=a.parentid and i.id='{eba21a39-0279-4454-9c14-39314957381e}' and a.safetyorcontent=1 95837 1 95837
31 SELECT ID,TemplateID FROM InstanceAddinational WHERE ParentID='{b551acba-bf87-4b2f-95d7-754730101d39}' and SAFETYORCONTENT = 0 95836 1 95836
32 SELECT ID,TemplateID FROM InstanceAddinational WHERE ParentID='{c12dac65-765c-48f1-811d-0fb91a7e9966}' and SAFETYORCONTENT = 1 order by CREATEDATETIME 95797 1 95797
33 SELECT ID,TemplateID FROM InstanceAddinational WHERE ParentID='{3848b4f9-c35d-4306-b8c4-4a9f0b46c3c6}' and SAFETYORCONTENT =0 191571 2 95785.5
34 SELECT id FROM INSTANCEADDINATIONAL WHERE ParentID='{539bcb8b-64a6-489b-9f53-71baee595aa1}' and SAFETYORCONTENT =0 order by CREATEDATETIME  191540 2 95770
35 SELECT * FROM INSTANCEADDINATIONAL WHERE ParentID='{539bcb8b-64a6-489b-9f53-71baee595aa1}' and SAFETYORCONTENT =1 order by CREATEDATETIME  95770 1 95770

解决方案 »

  1.   

    把 TOP 10 语句,单独跑一下,看看执行计划是什么样的。
      

  2.   

    从sql文本和物理读上看,至少有两个问题:
    1、未使用绑定变量,不过这个在并发不高的情况下可能不会有太大问题;
    2、该建的索引没有建,每次都是表扫描,因为表越来越大,sql性能也越来越差了~
      

  3.   

    逐个分析,比如:
    SELECT ID,TemplateID FROM InstanceAddinational WHERE ParentID='{bbfc9d14-4416-4373-9570-d96085f5ed2d}' and SAFETYORCONTENT =0    
    表的数据量是多少,查看其执行计划,是否有合理的索引,是否需要分区。
      

  4.   

    如果知道了是什么操作引起的性能问题,可以直接找开发人员,由开发人员提供SQL。如果找不到了,需要使用AWR,把出现问题最明显的时段的AWR报告拿出来基本上能确认问题了,ADDM也可以帮助分析性能问题。
      

  5.   

    可以找开发让提供对应逻辑的sql,分析执行计划,看是不是有该建的索引没建,是不是有该走的索引没走。有明确的sql,又不容易分析的话也可以做个10046事件看耗时在哪里,针对性优化。
    数据库整体性能的话,可以跑个awr报告,分析优化下topsql。