数据库性能监控指南：查看方法简介 (如何查看数据库的性能状态)
在当今的资讯时代，创造和积累的数据量日益庞大，这样的数据量需要接受管理和维护。而数据库系统正是日益壮大的数据量存储和使用的基础，因此维护数据库系统的有效性和高性能就成为了至关重要的事情。数据库性能监控，也就成为了一项必不可少的任务。本文将详细介绍一些数据库性能监控的方法和指南。
监控数据库状态
当用户访问数据库时，其性能并没有达到其更高水平，这可能是由于数据库中存在某些访问或磁盘空间的问题。这个级别的监控可以通过以下方法完成：
1.查看数据库的状态报告：在多数数据库管理系统中，你可以通过运行以下命令获取状态报告：
SHOW VARIABLES; SHOW STATUS;
通过此方法，可以及时了解数据库实例的磁盘空间、缓存使用和负载信息。
2.部署数据库性能监控工具：MySQL的Percona监控工具是在传统的MySQL监控工具上的更新，通过可视化显示，可以更好地查看数据。
3.使用命令行工具：你也可以使用命令行工具来进行数据库性能监控，诸如”TOP”命令可以快速反应系统负载和主要进程的资源消耗。
监控物理层状态
监控系统物理状态是数据库性能优化的重要步骤之一，这里物理状态指的是CPU、服务器磁盘，内存等部件的使用情况。
1.监理CPU：CPU的性能显然对系统响应时间有着严格的要求，因此使用命令lpstat来查看即可。
2.监控内存性能：内存的大小、使用情况和分配对系统性能来说都是至关重要的，使用命令free和vmstat可以查看内存的情况。
3.监控磁盘性能：磁盘执行I / O操作是数据库性能更大的瓶颈之一，通过使用Iostat和Diskstat命令，用户可以查看磁盘的使用率。
监控数据库查询优化
优化查询的执行计划是所有数据库性能优化中最困难的一项。如果查询的执行计划安排不当，则会导致查询速度变慢，严重测试将闪退发生。
1.确定性能瓶颈：使用命令Show full processlist，查看当前活动进程，判断是否有进程运行较慢；使用EXPLN命令将慢查询的执行计划输出。
2.优化缓存查询：在MySQL中，大量查询可以通过降低查询时间压缩了处理时间。MySQL缓存后的查询（如果所需数据已经存在于缓存）不需要进行磁盘读取，这个过程将会极大地减少查询时间。
3.优化索引：在许多情况下，优化索引会有助于保持数据库快速运行。
监控数据库备份和恢复
任何数据库都需要实现可靠的备份和恢复功能来保护对该数据库的全部访问。另外，通过监视备份操作，用户还可以提高数据库性能。
1.备份和恢复：备份MySQL分为物理备份和逻辑备份两种方法。物理备份是将数据库完整的复制到另一个位置，以确保在数据丢失的情况下可以以最快的速度恢复。逻辑填坑的是备份数据的关系结构，而不是复制整个数据库，此方法最适用于小型数据库和轻型的数据。
2.备份监控：监测备份和恢复数据的过程可以确保这些任务按正确的计划执行。
本文简要介绍了一些数据库性能监控的方法和指南，包括监听数据库状态，监测物理层状态，监测数据库查询优化以及数据库备份和恢复等。数据库性能监控是一个重要的任务，特别是对于商业或企业级的数据，在若干次操作后数据库性能会出现急剧下降。而通过合适的数据库性能监控技巧，用户可以确保数据库系统保持高效和可靠运行。
相关问题拓展阅读：
如何使用AWR报告来诊断数据库性能问题
一般来说，当检测到性能问题时，我们会收集覆盖了发生问题的时间段的AWR报告-但是更好只收集覆盖1个小时时间段的AWR报告-如果时间过长，那么AWR报告就不能很好的反映出问题所在。还应该收集一份没有性能问题的时间段的AWR报告，作为一个参照物来对比有问题的时间段的AWR报告。这两个AWR报告的时间段应该是一致的，比如都是半个小时的，或者都是一个小时的。
Interpretation
在处理性能问题时，我们最关注的是数据库正在等待什么。
当进程因为某些原因不能进行操作时，它需要等待。花费时间最多的等待事件是我们最需要关注的，因为降低它，我们能够获得更大的好处。
AWR报告中的”Top 5 Timed Events”部分就提供了这样的信息，可以让我们只关注主要的问题。
Top 5 Timed Events
正如前面提到的，”Top 5 Timed Events”是AWR报告中最重备告要的部分。它指出了数据库的sessions花费时间最多的等待事件，如下：
Top 5 Timed EventsAvg %Total
~~~~~~~~~~~~~~~~~~wait Call
Event Waits Time (s) (ms) Time Wait Class
db file scattered read,152,,9.6 User I/O
db file sequential read,327,,7.6 User I/O
CPU time6,0.5
read by other session,397,,2.2 User I/O
PX Deq Credit: send blkd1,,9.Other
—–
Top 5 Events部分包含了一些跟Events（事件）相关的信息。它记录了这期间遇到的等待的总次数，等待所花费的总时间，每次等待的平均时间；这一部分是按照每个Event占总体call time的百分比来进行排序的。
根 据Top 5 Events部分的信息的不同，接下来我们需要检查AWR报告的其他部分，来验证发现的问题或者做定量分析。等待事件需要根据报告期的持续时间和当时数据 库中的并发用户数进行评估。如：10分钟内1000万次的等待事件比10个小时内的1000万等待更有问题；10个用户引起的1000万次的等待事件比 10,000个用户引起的相同的等待要更有问题。
就像上面的例子，将近60%的时间是在等待IO相关的事件。
其他20%的时间旅滚世是花在使用或等待CPU time上。过高的CPU使用经常是性能不佳的SQL引起的（或者这些SQL有可能用更少的资源完成同样的操作）；对于这样的SQL，过多的IO操作也是一个症状。关于CPU使用方面，我们会在之后讨论。
在以上基础上，我们将调查是否这个等待事件是有问题的。若有问题，解决它；若是正常的，检查下个等待事件。
过多的IO相关的等待一般会有两个主要的原因：
Top 5 Events部分的显示的信息会帮助我们检查：
需要注意，接下来的分析步骤取决于我们在TOP 5部分的发现。在上面的例子里，3个top wait event表明问拆肢题可能与SQL语句执行计划不好有关，所以接下来我们要去分析”SQL Statistics”部分。
同样的，因为我们并没有看到latch相关的等待，latch在我们这个例子里并没有引发严重的性能问题；那么我们接下来就完全不需要分析latch相关的信息。
一 般来讲，如果数据库性能很慢，TOP 5等待事件里”CPU”， “db file sequential read” 和”db file scattered read” 比较明显（不管它们之间的顺序如何），我们总是需要检查Top SQL (by logical and physical reads)部分；调用SQL Tuning Advisor或者手工调优这些SQL来确保它们是有效率的运行。
是否数据库做了大量的读操作：
上面的图显示了在这段时间里两类读操作都分别大于1000万，这些操作是否过多取决于报告的时间是1小时或1分钟。我们可以检查AWR报告的elapsed time如果这些读操作确实是太多了，接下来我们需要检查AWR报告中 SQL Statistics 部分的信息，因为读操作都是由SQL语句发起的。
是否是每次的IO读操作都很慢：
上面的图显示了在这段时间里两类读操作平均的等待时间是小于8ms的
至于8ms是快还是慢取决于底层的硬件设备；一般来讲小于20ms的都可以认为是可以接受的。
我们还可以在AWR报告”Tablespace IO Stats”部分得到更详细的信息
Tablespace IO StatsDB/Inst: VMWREP/VMWREP Snaps: 1-15
-> ordered by IOs (Reads + Writes) desc
Tablespace
—
Av Av AvAv Buffer Av Buf
Reads Reads/s Rd(ms) Blks/RdWrites Writes/s Waits Wt(ms)
TS_TX_DATA
14,246, 7..6 145,263,,883 3,844,.3
USER
204,10..0 17,849, 15,.8
UNDOTS1
19, 3..0 10,064, 1,.9
AE_TS
4,287, 5..65,.7
TEMP
2,022, 0..,.0
UNDOTS3
1,310, 4..,.0
TS_TX_IDX
1,884, 7.., 73,.3
>SYSAUX
346, 5..,.0
SYSTEM
101, 7..,.7
如上图，我们关心Av Rd(ms)的指标。如果它高于20ms并且同时有很多读操作的，我们可能要开始从OS的角度调查是否有潜在的IO问题。
注：对于一些比较空闲的tablespace/files,我们可能会得到一个比较大的Av Rd(ms)值；对于这样的情况，我们应该忽略这样的tablespace/files;因为这个很大的值可能是由于硬盘自旋(spin)引起的，没有太大的参考意义。比如对
于一个有1000万次读操作而且很慢的系统，引起问题的基本不可能是一个只有10次read的tablespace/file.
虽 然高”db file scattered read”和”db file sequential read”等待可以是I / O相关的问题，但是很多时候这些等待也可能是正常的；实际上，对一个已经性能很好的数据库系统，这些等待事件往往在top 5等待事件里，因为这意味着您的数据库没有那些真正的“问题”。
诀窍是能够评估引起这些等待的语句是否使用了更优的访问路径。如果”db file scattered read”比较高，那么相关的SQL语句可能使用了全表扫描而没有使用索引（也许是没有创建索引，也许是没有合适的索引）；相应的，如果”db file sequential read”过多，则表明也许是这些SQL语句使用了selectivity不高的索引从而导致访问了过多不必要的索引块或者使用了错误的索引。这些等待可 能说明SQL语句的执行计划不是更优的。
接下来就需要通过AWR来检查这些top SQL是否可以进一步的调优，我们可以查看AWR报告中 SQL Statistics 的部分.
上面的例子显示了20%的时间花在了等待或者使用CPU上，我们也需要检查 SQL statistics 部分来进一步的分析。
数据库做了太多的读操作
每次的IO读操作都很慢
事件”db file scattered read”一般表明正在做由全表扫描或者index fast full scan引起的多块读。
事件”db file sequential read”一般是由不能做多块读的操作引起的单块读（如读索引）
SQL Statistics
AWR包含了一些不同的SQL统计值：
根据Top 5 部分的Top Wait Event不同，我们需要检查不同的SQL statistic。
在我们这个例子里，Top Wait Event是”db file scattered read”，”db file sequential read”和CPU；我们最需要关心的是SQL ordered by CPU Time, Gets and Reads。
我们会从”SQL ordered by gets”入手，因为引起高buffer gets的SQL语句一般是需要调优的对象。
SQL ordered by Gets
-> Resources reported for PL/SQL code includes the resources used by all SQL
statements called by the code.
-> Total Buffer Gets: 4,745,943,815
-> Captured SQL account for.2% of Total
GetsCPU Elapsed
Buffer Gets Executions per Exec %Total Time (s) Time (s) SQL Id
1,228,753,68 7,314,011.2 25…73 5t1y1nvmwp2
SELECT ADDRESSID”,CURRENT$.”ADDRESSTYPEID”,CURRENT$URRENT$.”ADDRESS3″,
CURRENT$.”CITY”,CURRENT$.”ZIP”,CURRENT$.”STATE”,CURRENT$.”PHONECOUNTRYCODE”,
CURRENT$.”PHONENUMBER”,CURRENT$.”PHONEEXTENSION”,CURRENT$.”FAXCOU
1,039,875,,959,.5 21…96 grr4mg7ms81
Module: DBMS_SCHEDULER
INSERT INTO “ADDRESS_RDON” (“ADDRESSID”,”ADDRESSTYPEID”,”CUSTOMERID”,”
ADDRESS1″,”ADDRESS2″,”ADDRESS3″,”CITY”,”ZIP”,”STATE”,”PHONECOUNTRYCODE”,”PHONENU
854,035,68 5,083,543.0 18…95 4at7cbx8hnz
SELECT “CUSTOMERID”,CURRENT$.”ISACTIVE”,CURRENT$.”FIRSTNAME”,CURRENT$.”LASTNAME”,CU Total Buffer Gets: 4,745,943,815
假设这是一个一个小时的AWR报告，4,745,943,815是一个很大的值；所以需要进一步分析这个SQL是否使用了更优的执行计划
Individual Buffer Gets
上面的例子里单个的SQL的buffer get非常多，最少的那个都是8亿5千万。这三个SQL指向了两个不同的引起过多buffers的原因：
注意：对于某些非常繁忙的系统来讲，以上的数字可能都是正常的。这时候我们需要把这些数字跟正常时段的数字作对比，如果没有什么太大差别，那么这些SQL并不是引起问题的元凶（虽然通过调优这些SQL我们仍然可以受益）
Load Profile
根据Top 5等待事件的不同，”Load Profile”可以提供一些有用的背景资料或潜在问题的细节信息。
Load Profile
~~~~~~~~~~~~Per SecondPer Transaction
Redo size:,585,414.,165,883.14
Logical reads:4,185. 65,028.07
Block changes:0,028. 27,636.71
Physical reads:2,206. 1,523.16
Physical writes:3,939. 2,720.25
User calls: 50..58
Parses: 26..61
Hard parses: 1..03
Sorts: 18..68
Logons: 0..09
Executes:4,925. 3,400.96
Transactions: 1.45
% Blocks changed per Read: 42.50 Recursive Call %: 99.19
Rollback per transaction %: 59.Rows per Sort: 1922.64
在这个例子里，Top 5 Events部分显示问题可能跟SQL的执行有关，那么我们接下来检查load profile部分。
如果您检查AWR report是为了一般性的性能调优，那么可以看到有比较多的redo activity和比较高的physical writes. Physical writes比physical read要高，并且有42%的块被更改了.
此外，hard parse的次数要少于soft parse.
如果mutex等待事件比较严重，如”library cache: mutex X”，那么查看所有parse的比率会更有用。
当然，如果把Load Profile部分跟正常时候的AWR报告做比较会更有用，比如，比较redo size, users calls, 和 parsing这些性能指标。
Instance Efficiency
Instance Efficiency部分更适用于一般性的调优，而不是解决某个具体问题（除非等待事件直接指向这些指标）。
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.Redo NoWait %: 100.00
Buffer Hit %: 98.14 In-memory Sort %: 99.98
Library Hit %: 99.Soft Parse %: 94.48
Execute to Parse %: 99.Latch Hit %: 99.97
Parse CPU to Parse Elapsd %: 71.% Non-Parse CPU: 99.00
从我们的这个例子来看，最有用的信息是%Non-Parse CPU，它表明几乎所有的CPU都消耗在了Execution而不是Parse上，所以调优SQL会对性能有改善。
如何进行数据库性能分析?
使用RichAPM可以直接针对不同脊唤类型的数据库性能进行分析，包括MySQL、Oracle、SQL Server三类关系型数据库及Memcache、redis两此斗类非关系型数据森野磨库。
使迟宴用LR对数据库进行性能测试，实际上有多码皮银种办法，包括通过现有的数据库协议进行CS模式的先录制后执行的模式，以及通过socket方式向服务器发包方式的测试方式。这些是常规书籍上介绍的比较简单上手的测试方法，但是不具备通用性，握罩受已有协议或soc
如何查看数据库的性能状态的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于如何查看数据库的性能状态,数据库性能监控指南：查看方法简介,如何使用AWR报告来诊断数据库性能问题,如何进行数据库性能分析?的信息别忘了在本站进行查找喔。
