数据库io？如何判断数据库IO是否慢

本篇文章给大家谈谈数据库io，以及如何判断数据库IO是否慢对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。

数据库cpu很高,io很低

cpu高估计还是sql语句有问题,我也是新手,转帖一个给你参考参考

1--检查系统

sar-u 5 5

2--看谁在用CPU

topas

ps-ef|grep ora#检查第四列，C的大小（unit，100 per cpu）

3--检查CPU数量

/usr/sbin/bindprocessor-q

lsattr El proc0

4-- 2种可能：

1) A Background(instance) process

2) An oracle(user) process＃此种可能最大。

5--如果是用户进程：那么高CPU的主要原因有：

Large Queries, Procedure compilation or execution, Space management and Sorting

5.1--查看每个Session的CPU利用情况：

select ss.sid,se.command,ss.value CPU,se.username,se.program from v$sesstat ss, v$session se where ss.statistic# in(select statistic# from v$statname where name='CPU used by this session') and se.sid=ss.sid and ss.sid>6 order by ss.sid;

5.2--比较上述Session，看那个session的CPU使用时间最多，然后查看该Session的具体情况：

select s.sid, w.event, w.wait_time, w.seq#, q.sql_text from v$session_wait w, v$session s, v$process p, v$sqlarea q where s.paddr=p.addr and s.sid=&p and s.sql_address=q.address;

5.3--得到上述信息后，查看相应操作是否有hash joins和 full table scans。如果有hash joins和 full table scans那么必须创建相应的Index或者检查Index是否有效。

另外必须检查是否有并行的查询存在和同一时刻有多个用户在执行相同的SQL语句，如果有必须关闭并行的查询和任何类型的并行提示(hints);如果查询使用intermedia数据，那么为了减少总的Index大小，必须限制使用Intermedia的Worldlist。（try restricting the wordlist that intermedia uses to help reduce the total indexsize）。

6--上述方案只能根据已经运行完成的操作，对于正在执行的长时间操作只能等操作完成后才能检测得到。因此我们可以通过另外一个很好的工具来检测正在运行的长时间操作语句。v$session_longops,这个视图显示那些操作正在被运行，或者已经完成。每个process完成后会刷新本视图的信息。

7--怎样寻找集中使用CPU的Process：

很多时候会发现有N个Process在平均分享着CPU的利用率，这种情况唯一的可能性就是这些Process在执行着相同的Package或者Query.

这种情况：建议通过statspack,在CPU高利用率额时候运行几个快照，然后根据这些快照检查Statspack报告，检查报告中最TOP的 Query。然后使用 sql_trace and tkprof工具去跟踪一下。同时检查buffer cache的命中率是否大雨95％。

同时在报告中还需要检查一下table scans(long tables)，看是否在报告生成期间有存在全表扫描。

8--另外还有一些不是特别重要的，但是也必须关心检查的参数可能消耗CPU。

如何判断数据库IO是否慢

我们可能经常会遇到SQLServer数据库频繁关闭的情况。在分析了内存和CPU使用情况后，我们需要继续调查根源是否在I/O。我们应该如何识别SQLServer是否有I/O相关的瓶颈？

解决：

当数据页经常从缓冲池中移进移出的时候，I/O子系统就会成为SQLServer性能问题的关键因素之一。事务日志和tempdb同样也会产生重大的I/O压力。因此，你必须确保你的I/O子系统能按照预期运行。否则你将会成为响应时间增长和频繁超时的受害者。在这篇文章中，将描述如何使用内置工具识别I/O相关瓶颈，并提供一些磁盘配置的方法：

性能计数器（Performance Monitor）：

可以使用性能计数器来检查I/O子系统的负荷。下面的计数器可用于检查磁盘性能：

PhysicalDisk Object:Avg.DiskQueue

Length：计算从物理磁盘中的平均读和写的请求队列。过高的值代表磁盘操作处于等待状态。当这个值在SQLServer峰值时长期超过2，证明需要注意了。如果有多个硬盘，就需要把这些数值除以2。比如，有4个硬盘，且队列为10，那么平均值就是10/4=2.5，虽然也证明需要关注，但不能使用10这个值。

Avg.Disk Sec/Read和Avg.Disk

Sec/Write：显示从磁盘读或者写入磁盘的平均时间。10ms内是很好的表现，20以下还算能接受。高于此值证明存在问题。

Physical Disk:%Disk

Time：在磁盘忙于读或者写请求的时候持续时间的比率。根据拇指定律，此值应该小于50%。

Disk Reads/Sec和Disk

Writes/Sec计数器显示出在磁盘中读写操作的速率。这两个值应该小于磁盘能力的85%。当超过此值，磁盘的访问时间将以指数方式增长。

可以通过以下方式来计算逐渐增长的负载的能力。一种方法是使用SQLIO。你应该找到吞吐量比较稳定，但缓慢增长。

可以使用以下公式来计算RAID配置：

Raid 0: I/O per disk=(reads+ writes)/ number

ofdisks

Raid 1: I/O per disk= [reads+(writes*2)]/

2

Raid 5: I/O per disk= [reads+(writes*4)]/ number of

disks

Raid

10: I/O per disk= [reads+

(writes*2)]/ number of disks

比如：对于RAID 1，如果得到下面的计数器：

Disk Reads/sec= 90

Disk

Writes/sec=75

根据公式：[reads+(writes*2)]/ 2 or [90+(75*2)]/

2= 120I/Os每个磁盘。

动态管理视图（DMVs）：

有很多游泳的DMVs可以用于检查I/O瓶颈：

当一个页面被用于读或者写访问且页面在缓冲池中不存在或不可用时，会引发一个I/O闩锁等待（I/O

latch），它会在PAGEIOLATCH_EX/PAGEIOLATCH_SH（具体根据请求类型而定）。这些等待表明一个I/O瓶颈。可以使用sys.dm_os_wait_stats找到闩锁等待的信息。如果你保存了SQLServer正常运行下的waiting_task_counts和wait_time_ms值，并且于此次的值做对比，可以识别出I/O问题：

select*

from sys.dm_os_wait_stats

where wait_type like

'PAGEIOLATCH%'

order by wait_type asc

挂起的I/O请求可以在下面查询中查到，并且用于识别那个磁盘负责的这个瓶颈：

select database_id,

file_id,

io_stall,

io_pending_ms_ticks,

scheduler_address

from sys.dm_io_virtual_file_stats(NULL, NULL) iovfs,

sys.dm_io_pending_io_requests as iopior

where iovfs.file_handle= iopior.io_handle

磁盘碎片（Disk Fragmentation）：

建议你检查磁盘碎片和配置用于SQLServer实例的磁盘。在NTFS文件系统中的碎片会产生严重的性能影响。磁盘需要经常整理碎片并且指定整理碎片计划。研究表明，一些情况下SAN在整理碎片后性能更差。因此，SAN必须根据实际情况对待。

NTFS上的索引碎片同样能引起高I/O好用。但是这和在SANs中的效果是不一样的。

磁盘配置/最佳实践：

常规情况，你应该把日志文件和数据文件分开存放以获得更好的性能。对于重负载的数据文件（包括tempdb）的I/O特性是随机读取。对于日志文件，是顺序访问的，除非事务需要回滚。

对于内置磁盘仅仅可以用于数据库日志文件，因为它们对顺序I/O有很好的性能，但是对随机I/O性能低下。

数据库的数据和日志文件应该放在对应专用的磁盘中。确保良好的性能。建议日志文件放在两个内置磁盘，并配置为RAID

1。数据文件驻留在仅用于给SQLServer访问的SAN系统中，并只被查询和报表控制。特殊访问应该被禁止。

写缓冲在可能的情况下应该被允许，并保证断电也能使用。

为了尽可能保证对于OLTP系统的I/O瓶颈影响最小化，不应该把OLAP和OLTP环境混合。并且保证你的代码优化及有合适的索引来避免不必要的I/O。

数据库是指什么呢

数据库，可视为电子化的文件柜，即存储电子文件的处所。

所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。在数据库中，用户可以对文件中的数据进行新增、查询、更新、删除等操作。

因为使用io流文件存储数据有很多弊端如文件存储数据存储效率低、不管存还取操作都较麻烦、一般只能保存小量字符串数据等。为了解决这些弊端，才有数据库的出现，使用数据库存储数据就可以很好的解决这些弊端。

数据库管理系统：

数据库管理系统是为管理数据库而设计的电脑软件系统，一般具有存储、截取、安全保障、备份等基础功能。

数据库管理系统可以依据它所支持的数据库模型来作分类，例如关系式、XML；或依据所支持的计算机类型来作分类，例如服务器群集、移动电话。

或依据所用查询语言来作分类，例如SQL、XQuery；或依据性能冲量重点来作分类，例如最大规模、最高运行速度；亦或其他的分类方式。

数据库是什么

数据库，可视为电子化的文件柜，即存储电子文件的处所。

所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。在数据库中，用户可以对文件中的数据进行新增、查询、更新、删除等操作。

因为使用io流文件存储数据有很多弊端如文件存储数据存储效率低、不管存还取操作都较麻烦、一般只能保存小量字符串数据等。为了解决这些弊端，才有数据库的出现，使用数据库存储数据就可以很好的解决这些弊端。

扩展资料：

数据库的结构：

一个数据库由一个或一组数据表组成。每个数据库都以文件的形式存放在磁盘上，即对应于一个物理文件。不同的数据库，与物理文件对应的方式也不一样。

对于dBASE,FoxPro和Paradox格式的数据库来说，一个数据表就是一个单独的数据库文件，而对于Microsoft Access、Btrieve格式的数据库来说，一个数据库文件可以含有多个数据表。

数据库中的数据是以表为单位进行组织的。一个表是一组相关的按行排列的数据；每个表中都含有相同类型的信息。表实际上是一个二维表格，例如，一个班所有学生的考试成绩，可以存放在一个表中，表中的每一行对应一个学生，这一行包括学生的学号，姓名及各门课程成绩。

参考资料来源：百度百科-数据库

关于本次数据库io和如何判断数据库IO是否慢的问题分享到这里就结束了，如果解决了您的问题，我们非常高兴。