- 浏览: 980909 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
孤星119:
好熟悉的数据库字段啊, 上家公司做的项目每天都跟这些字段打招呼 ...
Oracle exp compress参数引起的空间浪费 -
itspace:
quxiaoyong 写道遇到个问题,网上一搜,全他妈这篇文章 ...
数据库连接错误ORA-28547 -
quxiaoyong:
遇到个问题,网上一搜,全他妈这篇文章。你转来转去的有意思吗?
数据库连接错误ORA-28547 -
hctech:
关于version count过高的问题,不知博主是否看过ey ...
某客户数据库性能诊断报告 -
itspace:
invalid 写道写的不错,我根据这个来安装,有点理解错误了 ...
AIX 配置vncserver
数据库性能报告(awr)共取样了4份,我们主要分析比较典型的,能反映数据库运行状态的报告进行分析。从此报告来看,数据库响应正常。以下分别从各个角度进行分析。
一、抽样时间
DB Name DB Id Instance Inst num Release RAC Host
SITEDB 203036004 sitedb 1 10.2.0.3.0 NO sitedb1
Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 19429 24-Feb-11 09:00:33 43 4.4
End Snap: 19437 24-Feb-11 17:00:50 43 3.9
Elapsed: 480.29 (mins)
DB Time: 10.64 (mins)
分析:
sitedb在长达8小时的性能采样时间中,session数为43个,每个session打开的cursors为4个,反应出数据库并发度不高。数据库消耗时间(DB Time)为10.64分,可以看出数据库在取样的时间里平均消耗操作资源及其有限,操作系统资源不会成为数据库运行缓慢的瓶颈。
二、数据库负载
Cache Sizes
Begin End
Buffer Cache: 512M 512M Std Block Size: 8K
Shared Pool Size: 976M 976M Log Buffer: 14,356K
Load Profile
Per Second Per Transaction
Redo size: 7,725.75 56,051.19
Logical reads: 684.35 4,965.02
Block changes: 46.80 339.54
Physical reads: 388.82 2,820.94
Physical writes: 1.84 13.34
User calls: 8.66 62.83
Parses: 3.30 23.97
Hard parses: 0.05 0.37
Sorts: 2.53 18.34
Logons: 0.02 0.17
Executes: 12.48 90.58
Transactions: 0.14
% Blocks changed per Read: 6.84 Recursive Call %: 76.65
Rollback per transaction %: 0.00 Rows per Sort: 156.65
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 43.19 In-memory Sort %: 100.00
Library Hit %: 98.92 Soft Parse %: 98.46
Execute to Parse %: 73.54 Latch Hit %: 100.00
Parse CPU to Parse Elapsd %: 21.95 % Non-Parse CPU: 99.88
Shared Pool Statistics
Begin End
Memory Usage %: 72.44 75.60
% SQL with executions>1: 99.20 98.13
% Memory for SQL w/exec>1: 93.62 93.00
分析:
在设置了sga_target=1610612736的前提下,buffer cache和shared pool size均保持不变,反应出数据库内存组件大小足够,数据库运行稳定。
1、 从buffer cache角度分析:结合三项指标Logical reads,Physical reads,Buffer Hit %,(在不考虑direct read的情况下,Logical reads=684.35次,其中Physical reads占了388.82次,Buffer Hit %=43.19),可以看出整个系统全表扫描比较严重,但并没有引起数据库cache buffer latch的争用或者等待(Buffer Nowait %=100)。
2、 从shared pool角度分析:结合三项指标Parses,Hard parses,Library Hit %,Soft Parse %(Parses=3.30/s,其中Hard parses为0.05/s, Library Hit %=98.92),可以看出shared pool负载较轻,而且Soft Parse %和Latch Hit %分别达到了98.46%和100%,在没有baseline的前提下,指标非常理想。
SGA Target Advisory
SGA Target Size (M) SGA Size Factor Est DB Time (s) Est Physical Reads
768 0.50 114,628 1,867,202,139
1,152 0.75 102,325 1,815,496,678
1,536 1.00 102,264 1,814,226,719
1,920 1.25 101,006 1,815,315,255
2,304 1.50 100,955 1,814,045,296
2,688 1.75 100,536 1,804,611,317
3,072 2.00 100,536 1,804,611,317
分析:
由以上指标可以看出,目前sga_target=1,536M,但增大此参数对减少物理IO,提高buffer cache命中率并没有多大用处。
PGA Target Advisory
Low Optimal High Optimal Total Execs Optimal Execs 1-Pass Execs M-Pass Execs
2K 4K 55,750 55,750 0 0
64K 128K 266 266 0 0
128K 256K 62 62 0 0
256K 512K 49 49 0 0
512K 1024K 430 430 0 0
1M 2M 56 56 0 0
2M 4M 14 14 0 0
4M 8M 3 3 0 0
16M 32M 1 1 0 0
分析:
在pga_aggregate_target=606076928的前提下,Oracle进行磁盘排序为0(1-Pass Execs和M-Pass Execs均为0)
三、等待事件
Top 5 Timed Events
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
CPU time 588 92.1
db file scattered read 725,872 55 0 8.7 User I/O
Log archive I/O 308 20 66 3.2 System I/O
db file sequential read 87,491 10 0 1.6 User I/O
log file parallel write 26,148 9 0 1.5 System I/O
Wait Events
• s - second
• cs - centisecond - 100th of a second
• ms - millisecond - 1000th of a second
• us - microsecond - 1000000th of a second
• ordered by wait time desc, waits desc (idle events last)
Event Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
Log archive I/O 308 0.00 20 66 0.08
分析:
在长达8小时的统计中,以上等待事件中db file scattered read比例比较大,也反映出系统可能full table ssan或者index fast scan较多,但是等待时间较小(Time(s)=55秒,Avg Wait(ms)=0),可以不需关注。
平均事务响应时间=(66ms*0.08)/0.032=165ms,从采样时间来看,平均事务响应时间非常迅速,在没有baseline的前提下,系统响应正常。
附:获取数据库全表扫描语句
注意:由于此脚本需要解析SQL语句,最好在数据库空闲时段进行。
create table full_sql (sql_text varchar2(1000), executions number);
create or replace procedure p_findfullsql as
v_csr number;
v_rc number;
v_string varchar2(2000);
v_count number;
cursor c1 is select sql_text,executions from v$sqlarea where lower(sql_text) like '%select%';
begin
for x1 in c1 loop
delete from plan_table ;
Begin
v_Csr := DBMS_SQL.OPEN_CURSOR;
v_string := 'explain plan for ' ;
v_string := v_string||x1.sql_text ;
DBMS_SQL.PARSE(v_csr, v_string, DBMS_SQL.V7);
v_rc := DBMS_SQL.EXECUTE(v_csr);
DBMS_SQL.CLOSE_CURSOR(v_csr);
Exception
when others then
null;
End ;
select count(*) into v_count from plan_table where options like '%FULL%' and operation like '%TABLE%' ;
if v_count > 0 then
insert into full_sql(sql_text,executions) values (x1.sql_text, x1.executions) ;
end if;
end loop ;
commit;
end ;
/
execute p_findfullsql ;
select * from full_sql;
通过select * from full_sql;可以知道执行全表扫描的语句,加以着重研究,比如可以讲小表放入keep_buffer,让其常驻内存
一、抽样时间
DB Name DB Id Instance Inst num Release RAC Host
SITEDB 203036004 sitedb 1 10.2.0.3.0 NO sitedb1
Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 19429 24-Feb-11 09:00:33 43 4.4
End Snap: 19437 24-Feb-11 17:00:50 43 3.9
Elapsed: 480.29 (mins)
DB Time: 10.64 (mins)
分析:
sitedb在长达8小时的性能采样时间中,session数为43个,每个session打开的cursors为4个,反应出数据库并发度不高。数据库消耗时间(DB Time)为10.64分,可以看出数据库在取样的时间里平均消耗操作资源及其有限,操作系统资源不会成为数据库运行缓慢的瓶颈。
二、数据库负载
Cache Sizes
Begin End
Buffer Cache: 512M 512M Std Block Size: 8K
Shared Pool Size: 976M 976M Log Buffer: 14,356K
Load Profile
Per Second Per Transaction
Redo size: 7,725.75 56,051.19
Logical reads: 684.35 4,965.02
Block changes: 46.80 339.54
Physical reads: 388.82 2,820.94
Physical writes: 1.84 13.34
User calls: 8.66 62.83
Parses: 3.30 23.97
Hard parses: 0.05 0.37
Sorts: 2.53 18.34
Logons: 0.02 0.17
Executes: 12.48 90.58
Transactions: 0.14
% Blocks changed per Read: 6.84 Recursive Call %: 76.65
Rollback per transaction %: 0.00 Rows per Sort: 156.65
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 43.19 In-memory Sort %: 100.00
Library Hit %: 98.92 Soft Parse %: 98.46
Execute to Parse %: 73.54 Latch Hit %: 100.00
Parse CPU to Parse Elapsd %: 21.95 % Non-Parse CPU: 99.88
Shared Pool Statistics
Begin End
Memory Usage %: 72.44 75.60
% SQL with executions>1: 99.20 98.13
% Memory for SQL w/exec>1: 93.62 93.00
分析:
在设置了sga_target=1610612736的前提下,buffer cache和shared pool size均保持不变,反应出数据库内存组件大小足够,数据库运行稳定。
1、 从buffer cache角度分析:结合三项指标Logical reads,Physical reads,Buffer Hit %,(在不考虑direct read的情况下,Logical reads=684.35次,其中Physical reads占了388.82次,Buffer Hit %=43.19),可以看出整个系统全表扫描比较严重,但并没有引起数据库cache buffer latch的争用或者等待(Buffer Nowait %=100)。
2、 从shared pool角度分析:结合三项指标Parses,Hard parses,Library Hit %,Soft Parse %(Parses=3.30/s,其中Hard parses为0.05/s, Library Hit %=98.92),可以看出shared pool负载较轻,而且Soft Parse %和Latch Hit %分别达到了98.46%和100%,在没有baseline的前提下,指标非常理想。
SGA Target Advisory
SGA Target Size (M) SGA Size Factor Est DB Time (s) Est Physical Reads
768 0.50 114,628 1,867,202,139
1,152 0.75 102,325 1,815,496,678
1,536 1.00 102,264 1,814,226,719
1,920 1.25 101,006 1,815,315,255
2,304 1.50 100,955 1,814,045,296
2,688 1.75 100,536 1,804,611,317
3,072 2.00 100,536 1,804,611,317
分析:
由以上指标可以看出,目前sga_target=1,536M,但增大此参数对减少物理IO,提高buffer cache命中率并没有多大用处。
PGA Target Advisory
Low Optimal High Optimal Total Execs Optimal Execs 1-Pass Execs M-Pass Execs
2K 4K 55,750 55,750 0 0
64K 128K 266 266 0 0
128K 256K 62 62 0 0
256K 512K 49 49 0 0
512K 1024K 430 430 0 0
1M 2M 56 56 0 0
2M 4M 14 14 0 0
4M 8M 3 3 0 0
16M 32M 1 1 0 0
分析:
在pga_aggregate_target=606076928的前提下,Oracle进行磁盘排序为0(1-Pass Execs和M-Pass Execs均为0)
三、等待事件
Top 5 Timed Events
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
CPU time 588 92.1
db file scattered read 725,872 55 0 8.7 User I/O
Log archive I/O 308 20 66 3.2 System I/O
db file sequential read 87,491 10 0 1.6 User I/O
log file parallel write 26,148 9 0 1.5 System I/O
Wait Events
• s - second
• cs - centisecond - 100th of a second
• ms - millisecond - 1000th of a second
• us - microsecond - 1000000th of a second
• ordered by wait time desc, waits desc (idle events last)
Event Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
Log archive I/O 308 0.00 20 66 0.08
分析:
在长达8小时的统计中,以上等待事件中db file scattered read比例比较大,也反映出系统可能full table ssan或者index fast scan较多,但是等待时间较小(Time(s)=55秒,Avg Wait(ms)=0),可以不需关注。
平均事务响应时间=(66ms*0.08)/0.032=165ms,从采样时间来看,平均事务响应时间非常迅速,在没有baseline的前提下,系统响应正常。
附:获取数据库全表扫描语句
注意:由于此脚本需要解析SQL语句,最好在数据库空闲时段进行。
create table full_sql (sql_text varchar2(1000), executions number);
create or replace procedure p_findfullsql as
v_csr number;
v_rc number;
v_string varchar2(2000);
v_count number;
cursor c1 is select sql_text,executions from v$sqlarea where lower(sql_text) like '%select%';
begin
for x1 in c1 loop
delete from plan_table ;
Begin
v_Csr := DBMS_SQL.OPEN_CURSOR;
v_string := 'explain plan for ' ;
v_string := v_string||x1.sql_text ;
DBMS_SQL.PARSE(v_csr, v_string, DBMS_SQL.V7);
v_rc := DBMS_SQL.EXECUTE(v_csr);
DBMS_SQL.CLOSE_CURSOR(v_csr);
Exception
when others then
null;
End ;
select count(*) into v_count from plan_table where options like '%FULL%' and operation like '%TABLE%' ;
if v_count > 0 then
insert into full_sql(sql_text,executions) values (x1.sql_text, x1.executions) ;
end if;
end loop ;
commit;
end ;
/
execute p_findfullsql ;
select * from full_sql;
通过select * from full_sql;可以知道执行全表扫描的语句,加以着重研究,比如可以讲小表放入keep_buffer,让其常驻内存
发表评论
-
buffer cache 的内部结构
2020-03-18 14:21 581BUFFER CACHE作为数据块的 ... -
Oracle OMC介绍
2020-03-18 13:19 488Oracle管理云服务(OMC)的大数据平台,自动收集的企业 ... -
参加Oracle勒索病毒防范专题培训会议
2019-09-27 17:15 5232019年7月22日,受邀参加Oracle勒索病毒防范专题培训 ... -
记一次内存换IO的Oracle优化
2019-09-27 16:50 831某客户数据库从P595物理 ... -
如何定位Oracle SQL执行计划变化的原因
2019-07-03 14:49 1464性能优化最难的是能够 ... -
如何定位Oracle SQL执行计划变化的原因
2018-10-30 09:24 1185性能优化最难的是能够 ... -
数据库性能优化目标
2018-10-08 10:59 523从数据库性能优化的场 ... -
数据库无法打开的原因及解决办法
2018-10-05 20:45 2133数据库的启动是一个相当复杂的过程。比如,Oracle在启动之前 ... -
怎么样彻底删除数据库?
2018-09-18 11:10 602Oracle提供了drop database命令用来删除数据库 ... -
Oracle减少日志量的方法
2018-09-10 10:17 869LGWR进程将LOG BUFFER中的 ... -
如何快速关闭数据库
2018-09-09 13:14 1237“一朝被蛇咬,十年怕井绳”。在没被“蛇”咬之前,很多DBA喜欢 ... -
关于《如何落地智能化运维》PPT
2018-05-17 10:19 1134在DTCC 2018发表《如何落地智能化运维》演讲,主要内容如 ... -
记录在redhat5.8平台安装oracle11.2容易忽视的几个问题
2018-05-11 19:58 582问题一:ping不通问题 在虚拟机上安装好linux系统后, ... -
《Oracle DBA实战攻略》第一章
2018-05-11 10:42 948即日起,不定期更新《OracleDBA实战攻略》一书电子版,请 ... -
Oracle 12c新特性
2018-05-11 10:33 902查询所有pdb [oracle@gj4 ~]$ sqlplu ... -
关于修改memory_target的值后数据库无法启动的问题
2017-02-28 12:24 3986操作系统:RHEL6.5 数据库版本:11.2.0.4 ... -
10g rac安装error while loading shared libraries libpthread.so.0 问题
2017-02-28 12:22 70011g rac安装在二节点跑脚本一般会报此错误: 解决这个问 ... -
记一次Oracle会话共享模式故障处理过程
2017-02-27 19:16 805故障简述 XXX第八人民医院HIS数据库7月13日11点左右从 ... -
RESMGR:cpu quantum等待事件处理过程
2017-02-27 18:23 2646由于数据库上线过程中出现大量的RESMGR:cpu quant ... -
谈谈log file sync
2014-03-19 14:18 1774数据库中的log file sync等待事件指的是,当user ...
相关推荐
- **ADDM (Automatic Database Diagnostic Monitor)**:自动数据库诊断监控器是一种基于AWR数据的分析工具,能够自动生成关于数据库性能问题的诊断报告。 ##### 3.2 SQL语句优化 SQL语句是与数据库交互的主要方式...
【数据库课程设计报告文档】 本课程设计的主题是“民航销售管理子系统数据库设计”,旨在让学生掌握数据对象特性的分析、数据组织方法、选择适合的存储结构,并将实际问题转化为计算机可处理的形式,同时提升学生的...
《某宾馆客房管理系统——数据库课程设计报告》是一个关于构建宾馆客房管理系统的数据库设计项目,旨在通过信息化手段提高宾馆的管理效率和服务质量。本系统利用数据库技术,尤其是SQL语言,实现客户信息、客房信息...
- **性能维度**:现有的性能测试报告往往来源于特定的厂商或客户的局部测试,缺乏足够的权威性和说服力。真正的性能比较应当基于国际权威机构发布的标准化测试结果。 - **特殊场景支持**:针对特定业务场景(如...
【某宾馆客房管理系统-数据库课程设计报告】 这篇报告主要涵盖了设计和实现一个宾馆客房管理系统的全过程,该系统旨在提升宾馆的现代化和网络化管理水平。系统的核心目标是优化客房信息管理,提高工作效率,减少...
### 某宾馆客房管理系统——数据库课程设计报告 #### 一、问题描述 ##### 1.1 背景 随着宾馆业的竞争日益激烈,如何有效地利用信息化手段提高宾馆的经营管理水平成为了一个重要的议题。传统的宾馆管理系统虽然在...
+ 能够熟练的对数据库进行性能分析和优化 + 能够对相关的开发人员进行数据库方面的培训和技术指导 + 有良好的英语阅读能力,能够阅读英文测试资料 * 态度: + 良好的理解能力,好学上进,耐心细致 + 工作勤奋,...
某电信营业厅收费管理系统是一个典型的业务信息系统,其核心在于有效地处理与电信服务相关的费用计算、客户管理以及员工管理。这个系统的设计涉及到以下几个关键知识点: 1. **费用类型和业务员管理**: - 费用...
【实施和维护】阶段,系统上线后需定期进行数据库的监控、备份、性能调优和故障排查,确保系统的稳定运行。 系统【背景】中提到,随着宾馆业竞争加剧,利用信息技术进行管理变得尤为重要。宾馆管理系统能帮助宾馆...
报表分析则通过查询和统计数据库中的数据,生成各类报表,如销售报告、库存周转报告等,帮助企业决策。 在实现过程中,学生可能使用SQL语言进行数据操作,包括CRUD(创建、读取、更新、删除)操作,以及复杂的查询...
6. **性能监控**:监控数据库性能,定期进行数据库维护和调整,如定期备份、碎片整理等。 综上所述,木制厂数据库设计需关注业务流程的数字化,满足不同用户角色的特定需求,通过数据字典规范数据结构,并结合...
在实际数据库设计中,还需要考虑更多的细节,比如数据类型的选择、索引的设置、参照完整性的约束、数据安全性、性能优化等方面。此外,可能还需要考虑未来的扩展性和可维护性,以适应银行业务的变化和发展。 总的来...
在逻辑结构设计中,我们还需要对关系模式进行规范化,以便提高数据库的性能和可靠性。关系模式的规范化包括消除数据冗余、减少数据重复等。 四、创建数据库及相关操作 在逻辑结构设计完成后,我们需要创建煤气管理...
在实验报告中,你可能会看到一些示例代码和结果分析,这些都是理解和掌握数据库操作的重要实践。尽管这份报告可能不完整,但它依然能提供丰富的学习材料,帮助你深入理解数据库系统的运作机制和实际应用。在学习过程...
### 数据库课程设计报告书知识点总结 #### 一、背景与意义 - **市场竞争与信息管理**:随着市场竞争的加剧,信息管理变得尤为重要。企业通过建立高效的信息管理系统,不仅可以优化内部运作,还能提升对外竞争力。 ...
电信收费管理信息系统作为一种典型的数据库应用,其设计与实现不仅要求学生掌握数据库系统的核心知识,而且要涉及到前端应用设计、用户交互逻辑以及系统性能优化等多方面技能。 电信收费管理信息系统的核心在于对...
5. 其他相关功能:可能包括客户满意度调查、特殊服务请求、报告生成等,以满足酒店日常运营的各种需求。 在数据库设计阶段,通常遵循以下步骤: 1. 需求分析:明确系统的需求,包括功能需求和非功能需求,这有助于...
该系统通过数据库技术实现对客户数据的存储、管理和分析,以便做出明智的业务决策。在这个系统中,数据库的设计是至关重要的,因为它直接影响到系统的性能和功能。 系统需求分析表明,CRM系统应具备客户基本信息...
字段是数据存储的基本单元,每个字段通常包含与数据库描述的实体相关的某一属性或方面的信息。用户通过关键词和排序命令,能够迅速搜索、重新排列、组合和选择记录中的字段,从而获取或创建特定数据聚合的报告。 在...