oracle性能监控sql-监控当前会话、执行的sql及io等信息
Oracle sql
--MingJie Tian
sql plsql developer
sga
select * from v$sgainfo;
io io
select v$sess_io.*,(block_gets+consistent_gets) reads,
((block_gets+consistent_gets-physical_reads)/(block_gets+consistent_gets)) ratio from v$sess_io
where (block_gets+consistent_gets)>=1000
order by (block_gets+consistent_gets) desc;
sql
select last_load_time,
disk_reads,
sorts,
fetches,
buffer_gets,
optimizer_cost,
cpu_time,
sql_fulltext,
sql_text
from v$sql
where to_char(last_load_time)> '2011-05-10/14:00:00' # sql
order by last_load_time desc;
io
select a.sid,
block_gets,
consistent_gets,
physical_reads,
block_changes,
consistent_changes,
b.serial#,
https://www.wendangku.net/doc/1b12269612.html,ername,
https://www.wendangku.net/doc/1b12269612.html,mand,
b.server,
b.machine,
b.terminal,
b.program
v$session b
where a.sid=b.sid
order by5desc;
sql io select a.sql_text,
a.sql_fulltext,
a.cpu_time,
b.sid,
b.serial#,
https://www.wendangku.net/doc/1b12269612.html,ername,
b.machine,
b.terminal,
b.program,
c.block_gets,
c.consistent_gets,
c.physical_reads,
c.block_changes,
c.consistent_changes
from v$sql a,
v$session b,
v$sess_io c
where a.address=b.sql_address and b.sid=c.sid
order by c.block_changes desc;
sql io select a.sql_text,
a.sql_fulltext,
a.cpu_time,
b.sid,
b.serial#,
https://www.wendangku.net/doc/1b12269612.html,ername,
b.machine,
b.terminal,
b.program,
c.block_gets,
c.consistent_gets,
c.physical_reads,
c.block_changes,
c.consistent_changes
from v$sql a,
v$session b,
where a.address=b.prev_sql_addr
and b.sid=c.sid
order by c.block_changes desc;
select a.tablespace_name,b.file_name,sum(a.bytes/1024/1024) free_mb,b.bytes/1024/1024 size_mb,b.autoextensible,b.maxbytes/1024/1024 max_mb
from dba_free_space a,dba_data_files b where a.file_id=b.file_id
group by a.tablespace_name,b.file_name,b.bytes,b.autoextensible,b.maxbytes order by a.tablespace_name,b.file_name;
实验5 数据库监视与性能优化
实验项目名称：数据库监视与性能优化实验学时： 4 同组学生姓名：实验地点： 实验日期：实验成绩： 批改教师：批改时间： 一、实验目的和要求 1、利用索引优化查询性能、优化SQL语句。 2、了解通过对SQL profiler跟踪系统运行数据。 二、实验仪器和设备 设备：奔腾Ⅳ或奔腾Ⅳ以上计算机； 环境：WINDOWS 7 或WINDOWS XP、Microsoft SQL Server 2008。 三、实验过程 1、完成以下的实验。 1）使用对象资源管理器创建、管理索引 ①为员工表创建一个索引名为“emp_id”的唯一性非聚集索引，索引关键字是“员工号”，填充因子80 % 。 ②重命名索引，将索引“emp_id”重命名为“员工表_员工号”。 ③删除索引“员工表_员工号”。 2）使用T-SQL语句创建、管理索引 ①为员工表创建一个索引名为“emp_id”的唯一性非聚集索引，索引关键字是“员工号”，填充因子80 % 。 ②重命名索引，将索引“emp_id”重命名为“员工表_员工号”。 ③为员工参与项目表创建一个索引名为“员工_项目_index”的非聚集复合索引，索引关键字为“员工号”，升序，项目编号，降序，填充因子50%。 ④删除索引“员工表_员工号”和“员工_项目_index”。 3）索引前后的执行计划 ①删除员工表中员工号上的主键。按员工姓名和项目名称查询对应的职责，然后观察执行计划信息，计算总的I/O和CPU开销。（员工表和员工参与项目表中的员工号都没有索引）②为员工参与项目表创建一个索引名为“员工参与项目_员工号”的非聚集索引，索引关键字为“员工号”，升序；按员工姓名和项目名称查询对应的职责，然后观察执行计划信息，计算总的I/O和CPU开销。（员工表中员工号没索引，员工参与项目表中的员工号有非聚集
sql语句(mysql优化)绝对经典
sql语句（mysql优化）绝对经典 误区1：count(1)和count(primary_key) 优于count(*) 很多人为了统计记录条数，就使用count(1) 和count(primary_key) 而不是count(*) ，他们认为这样性能更好，其实这是一个误区。对于有些场景，这样做可能性能会更差，应为数据库对count(*) 计数操作做了一些特别的优化。 误区2：count(column) 和count(*) 是一样的 这个误区甚至在很多的资深工程师或者是DBA 中都普遍存在，很多人都会认为这是理所当然的。实际上，count(column) 和count(*) 是一个完全不一样的操作，所代表的意义也完全不一样。count(column) 是表示结果集中有多少个column字段不为空的记录，count(*) 是表示整个结果集有多少条记录 误区3：select a,b from … 比select a,b,c from …可以让数据库访问更少的数据量 这个误区主要存在于大量的开发人员中，主要原因是对数据库的存储原理不是太了解。实际上，大多数关系型数据库都是按照行(row)的方式存储，而数据存取操作都是以一个固定大小的IO单元(被称作block 或者page)为单位，一般为4KB，8KB… 大多数时候，每个IO单元中存储了多行，每行都是存储了该行的所有字段(lob等特殊类型字段除外)。 所以，我们是取一个字段还是多个字段，实际上数据库在表中需要访问的数据量其实是一样的。当然，也有例外情况，那就是我们的这个查询在索引中就可以完成，也就是说当只取a,b两个字段的时候，不需要回表，而c这个字段不在使用的索引中，需要回表取得其数据。在这样的情况下，二者的IO量会有较大差异。(覆盖索引) 误区4：order by 一定需要排序操作 我们知道索引数据实际上是有序的，如果我们的需要的数据和某个索引的顺序一致，而且我们的查询又通过这个索引来执行，那么数据库一般会省略排序操作，而直接将数据返回，因为数据库知道数据已经满足我们的排序需求了。实际上，利用索引来优化有排序需求的SQL，是一个非常重要的优化手段。延伸阅读：MySQL ORDER BY 的实现分析，MySQL 中GROUP BY 基本实现原理以及MySQL DISTINCT 的基本实现原理。（order by null）
SQL监控及性能优化
SQL 性能监控及SQL 语句优化 性能监控 作为SQL的数据库服务器，我们可以将其比作一个人，而SQL则是他的心脏，管理员就是他的大脑。要监控心脏是否健康首先要看他这个人是否健康。这两者是相辅相成的，少了一方都是不健康的。 数据库服务器的性能监视器 性能监视器 性能工具的介绍 性能监视器是一种简单而功能强大的可视化工具，用于实时收集系统状态并从日志文件中查看性能数据。 使用性能监视器可以: 获得对诊断系统问题和规划系统资源增长有用的性能数据、了解工作负载及其对系统资源的影响、观察工作负载和资源使用情况的变化和趋势，以便计划未来的升级、通过监视结果来测试配置变化、诊断问题并确定需要优化的组件或进程。 现在，可以开始选择这些对象和要监视的计数器了。 https://www.wendangku.net/doc/1b12269612.html, 应用程序性能计数器有关https://www.wendangku.net/doc/1b12269612.html, 应用程序性能计数器的大部分信息最近已被合并到一个题为“改善 .NET 应用程序的性能和伸缩性”的综合文档中。下表描述了一些可用于监视和优化 https://www.wendangku.net/doc/1b12269612.html, 应用程序（包括 Reporting Services）性能的重要计数器。
除了上表中介绍的这些核心监视要素之外，在您试图诊断 https://www.wendangku.net/doc/1b12269612.html, 应用程序具有的特定性能问题时，下表中的性能计数器也可对您有所帮助。
Reporting Services 性能计数器 Reporting Services 包括一组它自己的性能计数器，用于收集有关报告处理和资源消耗方面的信息。可通过 Windows 性能监视器工具中出现的两个对象来监视实例和组件的状态和活动：MSRS 2005 Web Service 和 MSRS 2005 Windows Service 对象。 MSRS 2005 Web Service 性能对象包括一组用来跟踪 Report Server 处理过程的计数器，这些处理过程通常通过在线交互式报告浏览操作而引发。这些计数器在https://www.wendangku.net/doc/1b12269612.html, 停止该 Web 服务后被重设。下表列出了可用于监视 Report Server 性能的计数器，并描述了它们的目的。 性能对象：RS Web Service
第3章 自动数据库性能监视器
第3章自动数据库性能监视器 自动数据库性能监视器（ADDM）自动检查和报告数据库的性能问题。结果作为ADDM调查报告显示在Oracle企业管理器的数据库主页中，审查ADDM调查结果让你可以快速找出性能问题。 每个ADDM调查结果都提供了一串有关减少性能问题影响的建议，审查ADDM调查结果并执行建议是你每天正常维护数据库应该要做的事情，即使数据库处于未最佳的性能状态，你也应该继续使用ADDM监视数据库性能。 3.1 自动数据库诊断监视器概述 ADDM是构建在Oracle数据库内部的自我诊断软件，ADDM检查并分析自动工作量仓库（AWR）捕获到的数据，确定Oracle数据库可能存在的性能问题，然后它定位性能问题的根本原因，为纠正这些性能问题提供建议，并量化预计的性能收益，ADDM也可以识别不需要行动的区域。 3.1.1 ADDM分析 每次AWR快照（默认每小时一次）后就会执行ADDM分析，分析报告保存在数据库中，你可以通过Oracle企业管理器来查看这些报告，在使用本指南描述的另一个性能调整方法之前，先审查一下ADDM分析报告。 ADDM分析是从上到下执行的，首先确定症状，然后完善分析报告，指出导致性能问题的根本原因，ADDM使用DB time统计信息确定性能问题，DB time是数据库除了用户请求花去的递增式时间，包括等待时间和所有非空闲会话的CPU时间。 数据库性能调整的目标是减少给定工作量的DB time，通过减少DB time，数据库使用相同数量的资源可以支持更多用户请求，ADDM报告使用了大量DB time的系统资源，将其显示在问题区域，并按消耗的DB time数量进行倒序排序，关于DB time统计信息的更多信息请参考"时间模型统计"小节的内容。 3.1.2 ADDM建议 除了诊断性能问题外，ADDM还会给出建议解决方案，并且有时会建议多个可选的解决方案让你选择，ADDM建议包括： 硬件改造 添加CPU或修改I/O子系统配置 数据库配置 修改初始化参数配置 方案修改 对表或索引进行哈希分区，或使用自动段空间管理（ASSM） 修改应用程序 为序列使用缓存选项或使用绑定变量 使用其它顾问 在高负载SQL语句上运行SQL调整顾问或在热点对象上运行分段顾问。 ADDM应用在生产系统上受益良多，即使在开发和测试系统上，ADDM也可以提前提供潜在的性能问题警报。 性能调整是一个反复的过程，修复一个问题可能会导致瓶颈转移到系统的其它部分，即使使用ADDM分析报告，也要经过多次反复的调整才能使性能达到理想的水平。 3.1.3 Oracle真正应用集群中的ADDM 在Oracle真正引用集群（Oracle RAC）环境中，你可以使用ADDM分析整个数据库集群的性能，Oracle RAC中的ADDM会认为DB time是所有数据库实例数据库时间的总和，它只会报告集群级别的重要分析结果，例如，考虑局部各个集群节点的I/O水平就没什么意义，但所有节点的I/O水平的总和对于判定集群问题就显得很重要了。 3.2 配置自动数据库诊断监视器 3.2.1 设置初始化参数启用ADDM 默认情况下自动数据库诊断监视功能是被启用的，由初始化参数CONTROL_MANAGEMENT_PACK_ACCESS和STATISTICS_LEVEL控制。 CONTROL_MANAGEMENT_PACK_ACCESS初始化参数应该被设置为DIAGNOSTIC+TUNING（默认）或DIAGNOSTIC以确保启用自动数据库诊断监视器，如果将CONTROL_MANAGEMENT_PACK_ACCESS设置为NONE，就会禁用掉许多Oracle数据库特性，包括ADDM，强烈建议不要这么做。
SQL2019系统性能优化解决方案共12页文档
SQL Server 系统性能调优解决方案 前言 近几年,医药流通市场经历了激烈的震荡,导致行业逐步成熟和企业的快速变革,差异化经营成为众多医药流通的竞争选择。时空产品在中国医药流通企业的发展过程中得到了广泛且深入应用,大量的客户化开发和定制支撑了企业管理中横向和纵向的变化，很好的适应了企业在发展过程中不断变化的需求。 对于数据库管理系统的使用，很多用户都面临着一个很棘手的问题：系统效率下降。产生效率下降的因素是多方面： 1.硬件问题 2.软件问题 3.实施问题 正因为产生效率下降的因素很多，所以如何去查找原因成为我们首要关注的问题，时空公司也处在积极探索过程中。时空公司在解决一些客户问题的过程中积累了一些方法和思路，归纳总结后呈现给体系内的技术人员，本方案就系统效率调整所必需的基础知识、方法、技巧等几个方面进行阐述，从而让技术人员能够快速定位问题，解决问题，为合作伙伴提供优质，快捷的服务。 索引简介 索引是根据数据库表中一个或多个列的值进行排序的结构。索引提供指针以指向存储在表中指定列的数据值，然后根据指定的排序次序排列这些指针。数据库使用索引的方式与使用书的目录很相似，通过搜索索引找到特定的值，然后跟随指针到达包含该值的行。 索引键：用于创建索引的列。 索引类型 ?聚集索引： 聚集索引基于数据行的键值在表内排序和存储这些数据行。由于数据行按基于聚集索引键的排序次序存储，因此聚集索引对查找行很有效。每个表只能有一个聚集索引，因为数据行本身只能按一个顺序存储。数据行本身构成聚集索引的最低级别（叶子节点）。只有当表包含聚集索引时，表内的数据行才按排序次序存储。如果表没有聚集索引，则其数据行按堆集方式存储。 聚集索引对于那些经常要搜索范围值的列特别有效。使用聚集索引找到包含第一个值的行后，便可以确保包含后续索引值的行在物理相邻。例如：如果应用程序执行的一个查询经常检索某一日期范围内的记录，则使用聚集索引可以迅速找到包含开始日期的行，然后检索表中所有相邻的行，直到到达结束日期。这样有助于提高此类查询的性能。同样，如果对从表中检索的数据进行排序时经常要用到某一列，则可以将该表在该列上聚集（物理排序），避免每次查询该列时都进行排序，从而节省成本。 ?非聚集索引 非聚集索引具有完全独立于数据行的结构。非聚集索引的最低行包含非聚集索引的键值，并且每个键值项都有指针指向包含该键值的数据行。数据行不按基于非聚集键的次序存储。如
Oracle SQL性能优化方法研究
Oracle SQL性能优化方法探讨 Oracle性能优化方法(SQL篇) (1) 1综述 (2) 2表分区的应用 (2) 3访问Table的方式 (3) 4共享SQL语句 (3) 5选择最有效率的表名顺序 (5) 6WHERE子句中的连接顺序． (6) 7SELECT子句中幸免使用’*’ (6) 8减少访问数据库的次数 (6) 9使用DECODE函数来减少处理时刻 (7) 10整合简单,无关联的数据库访问 (8) 11删除重复记录 (8) 12用TRUNCATE替代DELETE (9) 13尽量多使用COMMIT (9) 14计算记录条数 (9) 15用Where子句替换HAVING子句 (9) 16减少对表的查询 (10) 17通过内部函数提高SQL效率 (11)
18使用表的不名(Alias) (12) 19用EXISTS替代IN (12) 20用NOT EXISTS替代NOT IN (13) 21识不低效执行的SQL语句 (13) 22使用TKPROF 工具来查询SQL性能状态 (14) 23用EXPLAIN PLAN 分析SQL语句 (14) 24实时批量的处理 (16)
1综述 ORACLE数据库的性能调整是个重要，却又有难度的话题，如何有效地进行调整，需要通过反反复复的过程。在数据库建立时，就能依照顾用的需要合理设计分配表空间以及存储参数、内存使用初始化参数，对以后的数据库性能有专门大的益处，建立好后，又需要在应用中不断进行应用程序的优化和调整，这需要在大量的实践工作中不断地积存经验，从而更好地进行数据库的调优。 数据库性能调优的方法 ●调整内存 ●调整I/O ●调整资源的争用问题 ●调整操作系统参数 ●调整数据库的设计 ●调整应用程序 本文针对应用程序的调整，来讲明对数据库性能如何进行优化。 2表分区的应用 关于海量数据的表，能够考虑建立分区以提高操作效率。建
使用SpotLight监控数据库性能
使用SpotLight监控数据库性能 8.1.4 使用SpotLight监控数据库性能（1） SpotLight On Oracle是由Quest公司出品的一款针对Oracle进行监控的软件。SpotLight监控Oracle的基本原理与LoadRunner监控类似，通过获取Oracle的数据字典和动态性能视图，然后把性能数据按直观的方式展现出来，如图8.11所示。 （点击查看大图）图8.11 SpotLight On Oracle监控数据库下面简要介绍使用SpotLight对Oracle进行监控的过程。 1．建立Oracle连接 第一步要建立Connection，如图8.12所示，这样才能够使用SpotLight连接到要监测的数据库。
新建连接，然后输入Oracle连接用户账号，确定之后即可进入监控主页面。 2．查看系统主界面进行Oracle监控 系统主界面反映了系统的整体运行情况，如果系统哪方面出现问题，会报相应的警告，最严重为红色警告。然后根据警告可转到相应的子窗口，查看相应的情况。下面介绍各子窗口。 1）Sessions面板 Response：系统的响应时间。 Total Users：总的用户Session数量。 Active Users：当前正在执行的用户Session数量。 2）Host面板 Host面板主要显示CPU利用率和内存使用情况。 3）Server Processes面板 Server Processes面板主要显示服务器进程的信息。主要关注以下几点。 PGA Target/Used：PGA目标总数及当前使用数。 Dedicated：专用服务器进程的个数。 Shared：共享服务器进程的个数。 Job Queue：作业进程的个数。 4）SGA面板 SGA面板主要显示SGA中各组件的内存使用情况，主要关注以下几点。
DB2数据库-性能测试监控
DB2数据库-性能测试监控 一．DB2数据库介绍 1. DB2架构介绍 概要介绍 DB2是IBM公司研发的关系数据库产品，目前广泛应用于金融、通信、交通等行业，在IBM随需应变的战略体系中扮演着重要角色。因为川农信属于金融行业，因此也在使用DB2，其版本为v9.7，所以在这里介绍一些9.7版本的新特性。 ●支持索引压缩、临时表数据压缩和xml压缩，更加降低了存储空间成本。 ●支持内联大对象。 ●在线表迁移功能。 ●支持实时表字段更改。 ●在性能监控方面DB29.7有了极大增强，新的监控模型不仅可以快速找出问题瓶颈，而且对系统的影响非常小。特别是对锁的监控，通过新的Locking Event Monitor可同时监控死锁、锁等待和锁超时。 ●移植性增强。 ●HADR备机可读。 三种常用架构简介 当前的应用系统主要分为两类：联机事务处理（OLTP）和联机分析处理（OLAP）。 OLTP主要执行日常的事务处理，比如银行存取款、商场购物等，它的主要特点是对响应时间要求高，数据量一般较小，并发多，面向应用。OLAP主要指数据仓库、决策分析类系统，主要特点是数据量大，对实时性要求不高，面向主题。 针对这两种典型的系统，DB2提供了很好的支持。对于OLTP系统和数据量较小的OLAP系统，可以采用单分区架构。 但是有一些OLAP系统，比如国内一些通信公司和电力公司的经营分析系统，包含的数据超过几十TB，一台机器的处理性能根本无法满足要求。这时，可考虑DB2的多
分区架构，即Shared Nothing架构。这种架构的优点就是能够充分利用系统资源，将一个大型的查询分解成若干个小查询并行运行在不同的系统中。由于每一个分区只能够访问自己分区的数据，当查询数据需要关联时。需要在分区中交换必要的数据，分区之间使用一种叫做FCM（Fast Communication Manager）的通信机制。这种架构对系统设计人员要求较高，一定要充分理解优化器与系统访问数据的规则，并且设计很好的分区键，才能够尽可能避免分区间大量的数据交换。 与Share-Nothing相对的另外一种常见的架构是Share-Disk。Share-Disk架构允许所有机器都可以访问全部的数据，好处是管理起来相对方便，而且任意一台机器宕机后，只要存储部分不出问题，其他机器上的系统可以照样访问数据。Share-Disk的设计目标主要是提供高可用性，一般用于OLTP系统。 2. 主要模块介绍 上图描述了DB2的进程模型，长方形代表处理进程，椭圆形代表处理线程，DB2的主进程是db2sysc，在这个处理进程下有许多线程，最主要的线程也是叫db2sysc，这个主要的线程派生了其他子线程。当一个远程的应用程序比如采用sql connect语句链接服务器时，通讯协议的远程监听器将接收这个请求，并联系db2agent，agent是一个代表DB2实现一些小操作的处理程序，当发出请求的应用程序是本地的，也就是和DB2服务器在同一服务器上，如果不在同一个服务器上，那么采用db2tcpcm处理本地请求，如果在一台服务器上采
数据库性能问题处理及监控
`数据库性能问题处理及监控 思想重视 掌握方法 主动学习 善于协调 一、培训背景 系统性能是功能的延伸和深化。从某种程度上说，性能问题比单一的功能问题对客户造成的影响更大、更深、更恶劣，没有人愿意使用功能完备却性能糟糕的系统。改善和提升客户的系统操作体验，提高产品及客户服务满意度，系统的优异性能必不可少。从技术层面来说，这需要通过良好的数据库结构设计及应用程序架构设计来保证。 然而实际上，无论前期做多么的周密设计，都无法保证系统在客户实际使用过程中持续优良的性能。随着业务的提升，功能和数据也随之膨胀，性能稳定的挑战越来越大。此时，就需要现场系统维护人员迅速跟进并做有效的问题处理。 二、培训目的 明确系统维护人员性能问题处理的职责分工 明晰数据库性能问题的处理流程 性能调整需要团队协作，涉及DBA、操作系统管理人员、网络管理人员、应用程序设计及开发人员、应用系统现场维护人员等岗位 性能调整方法：调整业务功能、调整数据设计、调整过程设计、调整SQL语句、调整内存分配、调整IO、调整资源争用、调整OS 现场人员性能调整工作的角色分配：调整业务功能、调整SQL语句 明确、清晰的问题处理流程，可以规范问题处理步骤，缩短问题处理时间最小化性能问题的影响，有利于缓解后期解决问题的压力，进而促进问题的最终解决！
三、数据库性能故障处理流程 所谓数据库故障，简单讲就是数据库响应缓慢甚至不能响应客户端发起的请求。例如，客户端提交一个SQL请求后，会话处于等待数据库实例返回结果的状态。很多现场情况下，用户有7*24的运行需求。在系统突然遭遇性能问题时，我们并没有时间去收集数据，对比统计数据，进行索引分析和调整操作。 此时，需要几分钟或者几十分钟内解决这样的突发性能问题，我们工作重点应该是迅速确定发生了什么问题，并尽可能快速的恢复正常服务，严谨的优化方式并不现实。因此，应该先处理问题，再研究问题。 如何处理问题？没有简单答案！性能调整的普遍规则并不存在，但制定一个规范的工作流程和实施步骤是切实可行的。性能问题千差万别，需要有一个符合实际情况的性能问题处理的流程图，作为性能问题搜寻的方法指导。否则，由于性能问题分布在系统的各个层面，性能调整就会变成大海捞针。
SQLServer性能优化工具
SQLServer性能优化工具 数据和工作负荷示例 使用下例说明 SQL Server 性能工具的使用。首先创建下表。 create table testtable (nkey1 int identity, col2 char(300) default 'abc', ckey1 char(1)) 接下来，在这个表中填充 10,000 行测试数据。可以为列 nkey1 中所填充的数据创建非聚集索引。可以为列 ckey1 中的数据创建聚集索引，col2 中的数据仅仅是填充内容，将每一行增加 300 字节。 declare @counter int set @counter = 1 while (@counter <= 2000) begin insert testtable (ckey1) values ('a') insert testtable (ckey1) values ('b') insert testtable (ckey1) values ('c')
insert testtable (ckey1) values ('d') insert testtable (ckey1) values ('e') set @counter = @counter + 1 end 数据库服务器将进行下面的两个查询： select ckey1,col2 from testtable where ckey1 = 'a' select nkey1,col2 from testtable where nkey1 = 5000 Profiler SQL Server Profiler 记录数据库服务器中所发生活动的详细信息。可以配置 Profiler 以便用大量的可配置性能信息监视并记录在 SQL Server 中执行查询的一个或多个用户。可在 Profiler 中记录的性能信息有：I/O 统计信息、CPU 统计信息、锁定请求、T-SQL 和 RPC 统计信息、索引和表扫描、警告和引发的错误、数据库对象的创建/除去、连接/断开、存储过程操作、游标操作等等。有关 SQL Profiler 可记录的全部信息，请在SQL Server Books Online 中搜索字符串“Profiler”。 将 Profiler 信息装载到 .trc 文件中以便用于 Index Tuning Wizard 中 Profiler 和 Index Tuning Wizard 是强大的工具组合，以帮助数
数据库性能监控分析系统的设计与实现
—105— 数据库性能监控分析系统的设计与实现 王 娜，宿红毅，白 琳，王 鑫，郝子昭 (北京理工大学计算机科学与工程系，北京 100081) 摘 要：在讨论Oracle 体系结构和性能优化的基础上介绍了一个基于J2EE 的数据库性能监控和分析系统(DMI)的总体设计思想及其部分实现。 关键词：性能优化；Oracle ；实时监控；JMS ；RMI Design and Realization of Database Performance Monitoring and Analyzing System WANG Na, SU Hongyi, BAI Lin, WANG Xin, HAO Zizhao (Dept. of Computer Science and Engineering, Beijing Institute of Technology, Beijing 100081) 【Abstract 】This paper presents the design and part of implementation of a database performance monitoring and analyzing system (DMI) based on J2EE with discussing the architecture and performance optimizing of Oracle. 【Key words 】Performance optimizing; Oracle; Real-time monitoring; JMS; RMI 计 算 机 工 程Computer Engineering 第31卷 第24期 Vol.31 № 24 2005年12月 December 2005 ·软件技术与数据库· 文章编号：1000—3428(2005)24—0105—03 文献标识码：A 中图分类号：TP311.13 随着数据库应用的不断深入和扩大，数据库中的数据量迅速增长，数据操作也越来越复杂，数据库工作效率逐渐下降。因此，实施对数据库的管理维护、性能调优越来越受到广大数据库管理员(DBA)的关注和重视。虽然目前各种数据库产品本身也提供了大量功能强大的性能监控和调试工具，如Oracle 的OEM 、Performance Manager 、Capacity Planer 等，来帮助数据库管理人员对数据库性能进行调整、优化，但遗憾的是，精通掌握这些工具并能通过它们来有效地分析数据库性能状态，进而合理配置数据库以调整其性能也十分困难。因此开发一个简单高效的数据库性能监控管理工具来辅助DBA 对数据库进行性能分析调优成为数据库应用不断扩展的需要。 针对这种情况，本文结合业界先进的数据库管理经验，开发了Database Management Insight(DMI)——一个简单、实用、方便、安全的数据库监控管理平台。它可以有效地辅助数据库管理人员对数据库进行性能优化，确保数据库正常、平滑、高效地运转。DMI 可以监控Oracle 、Sybase 、DB2等数据库，本文以Oracle 为例来对该系统进行阐述。 1 总体设计 1.1 Oracle 的结构和性能优化 数据库优化的目的是更改系统的一个或多个组件，使其满足一个或多个目标的过程。对Oracle 数据库来说，优化是进行合理的资源配置，达到组件之间的均衡以改善其性能，即增加吞吐量、提高响应时间。数据库性能优化要考虑到系统的各个组成部分，由图1可以看出，Oracle 应用系统主要包含以下几个部分[1]： (1)用户进程和服务器进程 用户进程是SQL 语句的提出者，服务器进程则负责执行由用户进程传递过来的SQL 语句，与SGA 区交互。用户进程和服务器进程是数据库性能调整的一个重要方面，尤其是当用户的数量随着时间的推移而 不断增大时，建立与数据库的重复性临时连接的Web 应用系统会导致性能下降[2]。 (2)Oracle 实例 一个Oracle 实例是存储结构和后台进程的组合体。其中，SGA 是用来存放所有数据库进程共享的数据和控制信息的存储区域，当数据库一启动，SGA 就立即占有服务器的内存空间。SGA 中的库高速缓存、字典高速缓存、数据高速缓存、日志缓冲区以及大缓冲池和Java 池等组件的大小对系统性能有极大的影响，它们直接影响磁盘I/O 的频率，从而影响数据库效率[3]。实施性能优化时应注意DB_CACHE_SIZE 、SHARED_POOL_SIZE 、LOG_BUFFER 、LARGE_POOL_SIZE 和JAVA_POOL_SIZE 这几个参数的值，如果配置不合理会造成系统资源的极大浪费。 图 1 Oracle 体系结构 基金项目：武器装备预研项目 作者简介：王 娜(1981—)，女，硕士生，主研方向：计算机网络与分布式处理；宿红毅，副教授；白 琳、王 鑫、郝子昭，硕士生 收稿日期：2004-10-28 E-mail ：sdbzwn@https://www.wendangku.net/doc/1b12269612.html,
数据库性能监测指标
数据库性能监测指标（如Oracle、SqlServer）、LoadRunner 性能测试指标 1.%Disk Time(PhysicalDisk_Total) 2.%Processor Time(Processor_Total) 3.File Data Operations/sec(System) 4.Interrupts/sec(Processor_Total) 5.Page Faults/sec(Memory) 6.Pages/sec(Memory) 7.PoolNonpaged Bytes(Memory) 8.Private Bytes(Process_Total) 9.Processor Queue Length(System) 10.Threads(Objects) dbm: rem_cons_in 到正在被监视的数据库管理器实例的当前连接数，从远程客户端启动 agents_from_pool 代理程序池中已分配的代理程序数 agents_stolen 从应用程序中盗用代理程序的次数。重新分配与应用程序相关联的空闲代理程序，以便对其他应用程序执行操作，称作“盗用” sort_heap_allocated 拍快照时，以所选择的级别为所有排序分配的排序堆空间的总页数post_threshold_sorts 达到排序堆阈值后，已请求的堆的排序数 db: appls_cur_cons 当前已连接到数据库的应用程序数 appls_in_db2 当前已连接到数据库并且数据库管理器当前正在处理其请求的应用程序数sort_heap_allocated 拍快照时，以所选择的级别为所有排序分配的排序堆空间的总页数total_sorts 已经执行的排序总数 total_sort_time 所有已执行排序的总已用时间（以毫秒为单位） sort_overflows 用完排序堆并且可能需要临时磁盘存储空间的排序总数 hash_join_small_overflows 哈希联接数据大小超过可用排序堆空间，但超出比率小于10% 的次数 pool_data_l_reads 已经通过缓冲池的数据页逻辑读取请求数 pool_data_p_reads 要求I/O 将数据页放入缓冲池的读取请求数 pool_index_l_reads 已经通过缓冲池的索引页逻辑读取请求数 pool_index_p_reads 需要将索引页放入缓冲池的物理读取请求数 files_closed 已关闭的数据库文件的总数 pkg_cache_lookups 应用程序在程序包缓存中查找一个节或程序包的次数。在数据库级，它表示自从启动数据库或重置监视器数据以来的引用总数 pkg_cache_inserts 请求的一个节不可用，因而必须加载到程序包缓存中的总次数。此计数包括由系统执行的任何隐式准备
SQL性能优化
近期因工作需要，希望比较全面的总结下SQL SERVER数据库性能优化相关的注意事项，在网上搜索了一下,发现很多文章,有的都列出了上百条,但是仔细看发现，有很多似是而非或者过时(可能对SQL SERVER6.5以前的版本或者ORACLE是适用的)的信息，只好自己根据以前的经验和测试结果进行总结了。 我始终认为，一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优的任务，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意，进行有效工作才能达到的。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。 一、分析阶段 一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能有各种需求的量化的指标。 另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP（联机事务处理系统）和OLAP（联机分析处理系统）。 二、设计阶段 设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能调优的过程—数据库设计。 在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效率的代码，为整个系统的性能打下良好的基础。 以下是性能要求设计阶段需要注意的： 1、数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式： 第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。 第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。 第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三范式，系统会产生较少的列和较多的表，因而减少了数据冗余，也利于性能的提高。 2、合理的冗余 完全按照规范化设计的系统几乎是不可能的，除非系统特别的小，在规范化设计后，有计划地加入冗余是必要的。
MySQL数据库性能(SQL)优化方案
MySQL数据库性能（SQL）优化方案本文探讨了提高MySQL 数据库性能的思路，并从8个方面给出了具体的解决方法。 1、选取最适用的字段属性 MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN 来定义整型字段。 另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。 对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。 2、使用连接（JOIN）来代替子查询(Sub-Queries) MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询，如下所示： DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )
数据库性能监控
数据库性能监控 1.纲要： 数据库性能监控是一个常非大范围。 包含：表空间、段、索引、主键、数据缓冲区、库缓冲、用户锁、等待事件、回滚段、I/O、共享池等等。（空间、索引、等待事件） 2.概述： 在日常生产系统中，我们的系统都使用相当长的时间，SGA 中重做日志缓存区的命中率，应该小于1%、高速缓存命中>=90%率等等一般都是正常的，当然一个非常低的命中率的确意味着系统配置或应用存在严重问题；非常高的缓存命中率存在严重低效率的SQL语句（极差的SQL造成%99以上的命中率）, 但命中率的多少义意不是很大，主要是查看系统的等待事件,系统的反应时间,吞吐率(I/O)。 在系统的配置都没有问题情况下，影响性能的主要方面集中在： 1、索引 2、oracle、操作系统某些资源利用的不合理 3、系统的等待事件 3.索引 要开始监控一个索引的使用，使用这个命令： ALTER INDEX pk_addr MONITORING USAGE;
要停止监控一个索引，输入： ALTER INDEX pk_addr NOMONITORING USAGE; 开始监控索引的使用之后，就可以在sys.v$object_usage视图中查到你所监控的索引的使用情况。 所有被使用过至少一次的索引都可以被监控并显示到这个视图中。不过，一个用户只可以接收它自己schema中的索引使用。Oracle并没有提供一个视图来接收所有模式中的索引。 4.oracle、操作系统某些资源利用的不合理 内存分配不合理 内存的利用率多于80%时，这时说明内存方面应该调节一下。方法大体有以下几项： 划给Oracle使用的内存不要超过系统内存的1/2，一般保在系统内存的40%为益。 为系统增加内存； 如果你的连接特别多，可以使用MTS的方式；（MTS（Multi-Threaded Server）是ORACLE SERVER的一个可选的配置选择，是相对DEDICATE方式而言，它最大的优点是在以不用增加物理资源（内存）的前提下支持更多的并发的连接。） 打全补丁，防止内存漏洞。 表空间分配的不合理 表空间不足的时候，系统前台根本无法使用。 回滚段空间的不足，持行脚本就回失败。 --监控表空间使用率与剩余空间大小的语句 SELECT D.TABLESPACE_NAME,SPACE "空间(M)", BLOCKS ,SPACE-NVL(FREE_SPACE,0) "使用空间(M)", ROUND((1-NVL(FREE_SPACE,0)/SPACE)*100,2) "使用率(%)", FREE_SPACE "空闲空间(M)" FROM (SELECT TABLESPACE_NAME, ROUND(SUM(BYTES)/(1024*1024),2) SPACE, SUM(BLOCKS) BLOCKS FROM DBA_DATA_FILES GROUP BY TABLESPACE_NAME) D,
Oracle_SQL性能优化技巧大总结
（1）选择最有效率的表名顺序(只在基于规则的优化器中有效)： ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表. （2） WHERE子句中的连接顺序．： ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE 子句的末尾. （3） SELECT子句中避免使用 * ： ORACLE在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间 （4）减少访问数据库的次数： ORACLE在内部执行了许多工作: 解析SQL语句, 估算索引的利用率, 绑定变量 , 读数据块等； （5）在SQL*Plus , SQL*Forms和Pro*C中重新设置ARRAYSIZE参数, 可以增加每次数据库访问的检索数据量 ,建议值为200 （6）使用DECODE函数来减少处理时间： 使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表. （7）整合简单,无关联的数据库访问： 如果你有几个简单的数据库查询语句,你可以把它们整合到一个查询中(即使它们之间没有关系) （8）删除重复记录： 最高效的删除重复记录方法 ( 因为使用了ROWID)例子： DELETE FROM EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID)FROM EMP X WHERE X.EMP_NO = E.EMP_NO); （9）用TRUNCATE替代DELETE： 当删除表中的记录时,在通常情况下, 回滚段(rollback segments ) 用来存放可以被恢复的信息. 如果你没有COMMIT事务,ORACLE会将数据恢复到删除之前的状态(准确地说是恢复到执行删除命令之前的状况) 而当运用TRUNCATE时, 回滚段不再存放任何可被恢复的信息.当命令运行后,数据不能被恢复.因此很少的资源被调用,执行时间也会很短. 译者按: TRUNCATE只在删除全表适 用,TRUNCATE是DDL不是DML) （10）尽量多使用COMMIT： 只要有可能,在程序中尽量多使用COMMIT, 这样程序的性能得到提高,需求
一次TOP_SQL的性能调优经历
1.问题发现 1.1一份AWR报告 今天，收到一份100个并发用户访问下压力测试的AWR报告，并发事务数平均每秒只有6个不到。 在这个26.53分钟间隔的报告里，CPU TIME在整个TOP 事件中最突出 占了近97.6%，在8个CPU系统中，数据库给CPU造成的压力为： (5740/(26.53*60*8)*100%=45.07%，这么小的压力下，CPU就能冲得这么高，说明
系统中肯定是有问题的。下面转向TOP SQL去确认下造成资源争用最明显的SQL语句。 1.2TOP SQL 1.2.1SQL ordered by Elapsed Time 1.2.2SQL ordered by CPU Time
1.2.3SQL ordered by Gets 1.3问题发现 对一个OLTP系统来说，每一个语句的执行，都是要将其消耗的资源降到最低，这跟 OLAP系统是有差别的。对于后者来说，它需要的是短的时间返回结果，不管中间你会拿多大的成本做代价。 从上面反映的问题来看，我们的性能，无疑就是葬送在了SQL_ID为4841ajtgh43qy、1hwqh7kvxn6yg、g295mubwupf52和anyty5rts5tzf这四个语句上面，下面将对这四个SQL语句一 一做出分析，并给出相应的调优建议。
2.SQL_ID为4841ajtgh43qy的语句 2.1调整前 2.1.1语句 SELECT * FROM (SELECT TT.*, ROWNUM AS ROWNO FROM (select to_char(c.cust_id), c.password from CUST_CERTIFICATION c where c.cust_id = :CUST_ID) TT WHERE ROWNUM <= 10) TABLE_ALIAS where TABLE_ALIAS.rowno > 0 ; 2.1.2解释计划 又见全表扫