- 浏览: 978790 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
孤星119:
好熟悉的数据库字段啊, 上家公司做的项目每天都跟这些字段打招呼 ...
Oracle exp compress参数引起的空间浪费 -
itspace:
quxiaoyong 写道遇到个问题,网上一搜,全他妈这篇文章 ...
数据库连接错误ORA-28547 -
quxiaoyong:
遇到个问题,网上一搜,全他妈这篇文章。你转来转去的有意思吗?
数据库连接错误ORA-28547 -
hctech:
关于version count过高的问题,不知博主是否看过ey ...
某客户数据库性能诊断报告 -
itspace:
invalid 写道写的不错,我根据这个来安装,有点理解错误了 ...
AIX 配置vncserver
转自metalink 33883.1
需要提醒的是:Database tuning never must be driven by hit ratios. They only provide additional information to understand how the instance is operating.
Definition:
~~~~~~~~~~~
The "cache hit ratio" is a derived statistic referred to in a number of
manuals and articles. There is more than one definition of the cache hit
ratio in existence.
The hit ratio is intended to give an indication of how often the various
processes accessing the data buffers find the blocks in the Oracle buffer
cache. The exact value of the hit ratio is of less importance than the
ability to monitor it over time to notice any significant changes in the
profile of activity on the database.
*** Important: A very high hit ratio (close to 100%) is not necessarily good
The reasons for this are explained later.
Calculation:
~~~~~~~~~~~~
The most common formula in circulation for the hit ratio for the buffer cache
for Oracle7/8 is:
hit ratio = 1 - ( physical reads )
-----------------------------------
( consistent gets + db block gets )
This is often expressed as a percentage (by multiplying the result by 100).
However, in 7.3.4 and Oracle8 onwards the definition of the "physical reads"
statistic changed to include direct block reads as well as reads to get data
into the buffer cache. Hence the above formula only gives an lower bound for
the hit ratio on these releases.
A better formula in Oracle8i/9i is:
hit ratio =
1 - ( physical reads - (physical reads direct + physical reads direct (lob)) )
--------------------------------------------------------------------------
( db block gets + consistent gets - (physical reads direct + physical reads direct (lob)) )
In Oracle8.0 onwards it is possible to use multiple buffer pools (by setting
the BUFFER_POOL_KEEP or BUFFER_POOL_RECYCLE init.ora parameters). Multiple
buffer pools are not discussed here but the hit ratios for each pool can be
seen using the V$BUFFER_POOL_STATISTICS view (which is created by the
CATPERF.SQL script in Oracle8 and is a standard view in Oracle8i onwards)
thus:
SELECT name, 1-(physical_reads / (consistent_gets + db_block_gets ) ) "HIT_RATIO"
FROM V$BUFFER_POOL_STATISTICS
WHERE ( consistent_gets + db_block_gets ) !=0
;
(Note that this view shows 0 for CONSISTENT_GETS and DB_BLOCK_GETS in 8.1.7 and so
the above select is useless in this release - See Bug 1491213 )
The "Miss Ratio"
~~~~~~~~~~~~~~~~
Occasionally you may see reference to the "miss ratio". This is just
Miss ratio = 100% - Hit Ratio (expressed as a percentage)
Notes about the Hit Ratio
~~~~~~~~~~~~~~~~~~~~~~~~~
A good hit ratio is expected for OLTP type systems but decision support type
systems may have much lower hit ratios. Use of parallel query will make the
hit ratio less meaningful if using the first form of calculation based on
"physical reads" only.
A hit ratio close to 100% does not mean the application is good. It is quite
possible to get an excellent hit ratio by using a very unselective index in a
heavily used SQL statement.
Eg: Consider a statement like:
SELECT * FROM employee WHERE empid=1023 AND gender='MALE';
If EMPLOYEE is a large table and this statement always uses the GENDER index
rather than the EMPID index then you scan LOTS of blocks (from the GENDER
index) and find nearly all of them in the cache as everyone is scanning this
same index over and over again. The hit ratio is very HIGH but performance
is very BAD. A common 'variation' on an "unselective" index is a heavily
skewed index where there are a large number of entries with one particular
value (eg: a workflow status code of CLOSED) - the index may perform well for
some queries and very poorly for the most common value.
A few comments:
~~~~~~~~~~~~~~~
- The "good" hit ratio is generally considered to be one >80%
There is probably still scope for tuning if it is <90% *BUT*
note that the hit ratio is not the best measure of performance.
- The ratio can be artificially high in applications making
poor use of an UNSELECTIVE index.
- In Oracle8.1 onwards "physical reads direct" are recorded
- Some documentation incorrectly reports hit ratio to be:
Hit Ratio = Logical Reads / ( Logical Reads + Physical Reads )
this is incorrect for any version of Oracle.
需要提醒的是:Database tuning never must be driven by hit ratios. They only provide additional information to understand how the instance is operating.
Definition:
~~~~~~~~~~~
The "cache hit ratio" is a derived statistic referred to in a number of
manuals and articles. There is more than one definition of the cache hit
ratio in existence.
The hit ratio is intended to give an indication of how often the various
processes accessing the data buffers find the blocks in the Oracle buffer
cache. The exact value of the hit ratio is of less importance than the
ability to monitor it over time to notice any significant changes in the
profile of activity on the database.
*** Important: A very high hit ratio (close to 100%) is not necessarily good
The reasons for this are explained later.
Calculation:
~~~~~~~~~~~~
The most common formula in circulation for the hit ratio for the buffer cache
for Oracle7/8 is:
hit ratio = 1 - ( physical reads )
-----------------------------------
( consistent gets + db block gets )
This is often expressed as a percentage (by multiplying the result by 100).
However, in 7.3.4 and Oracle8 onwards the definition of the "physical reads"
statistic changed to include direct block reads as well as reads to get data
into the buffer cache. Hence the above formula only gives an lower bound for
the hit ratio on these releases.
A better formula in Oracle8i/9i is:
hit ratio =
1 - ( physical reads - (physical reads direct + physical reads direct (lob)) )
--------------------------------------------------------------------------
( db block gets + consistent gets - (physical reads direct + physical reads direct (lob)) )
In Oracle8.0 onwards it is possible to use multiple buffer pools (by setting
the BUFFER_POOL_KEEP or BUFFER_POOL_RECYCLE init.ora parameters). Multiple
buffer pools are not discussed here but the hit ratios for each pool can be
seen using the V$BUFFER_POOL_STATISTICS view (which is created by the
CATPERF.SQL script in Oracle8 and is a standard view in Oracle8i onwards)
thus:
SELECT name, 1-(physical_reads / (consistent_gets + db_block_gets ) ) "HIT_RATIO"
FROM V$BUFFER_POOL_STATISTICS
WHERE ( consistent_gets + db_block_gets ) !=0
;
(Note that this view shows 0 for CONSISTENT_GETS and DB_BLOCK_GETS in 8.1.7 and so
the above select is useless in this release - See Bug 1491213 )
The "Miss Ratio"
~~~~~~~~~~~~~~~~
Occasionally you may see reference to the "miss ratio". This is just
Miss ratio = 100% - Hit Ratio (expressed as a percentage)
Notes about the Hit Ratio
~~~~~~~~~~~~~~~~~~~~~~~~~
A good hit ratio is expected for OLTP type systems but decision support type
systems may have much lower hit ratios. Use of parallel query will make the
hit ratio less meaningful if using the first form of calculation based on
"physical reads" only.
A hit ratio close to 100% does not mean the application is good. It is quite
possible to get an excellent hit ratio by using a very unselective index in a
heavily used SQL statement.
Eg: Consider a statement like:
SELECT * FROM employee WHERE empid=1023 AND gender='MALE';
If EMPLOYEE is a large table and this statement always uses the GENDER index
rather than the EMPID index then you scan LOTS of blocks (from the GENDER
index) and find nearly all of them in the cache as everyone is scanning this
same index over and over again. The hit ratio is very HIGH but performance
is very BAD. A common 'variation' on an "unselective" index is a heavily
skewed index where there are a large number of entries with one particular
value (eg: a workflow status code of CLOSED) - the index may perform well for
some queries and very poorly for the most common value.
A few comments:
~~~~~~~~~~~~~~~
- The "good" hit ratio is generally considered to be one >80%
There is probably still scope for tuning if it is <90% *BUT*
note that the hit ratio is not the best measure of performance.
- The ratio can be artificially high in applications making
poor use of an UNSELECTIVE index.
- In Oracle8.1 onwards "physical reads direct" are recorded
- Some documentation incorrectly reports hit ratio to be:
Hit Ratio = Logical Reads / ( Logical Reads + Physical Reads )
this is incorrect for any version of Oracle.
发表评论
-
buffer cache 的内部结构
2020-03-18 14:21 578BUFFER CACHE作为数据块的 ... -
Oracle OMC介绍
2020-03-18 13:19 487Oracle管理云服务(OMC)的大数据平台,自动收集的企业 ... -
参加Oracle勒索病毒防范专题培训会议
2019-09-27 17:15 5132019年7月22日,受邀参加Oracle勒索病毒防范专题培训 ... -
记一次内存换IO的Oracle优化
2019-09-27 16:50 827某客户数据库从P595物理 ... -
如何定位Oracle SQL执行计划变化的原因
2019-07-03 14:49 1460性能优化最难的是能够 ... -
如何定位Oracle SQL执行计划变化的原因
2018-10-30 09:24 1185性能优化最难的是能够 ... -
数据库性能优化目标
2018-10-08 10:59 518从数据库性能优化的场 ... -
数据库无法打开的原因及解决办法
2018-10-05 20:45 2120数据库的启动是一个相当复杂的过程。比如,Oracle在启动之前 ... -
怎么样彻底删除数据库?
2018-09-18 11:10 599Oracle提供了drop database命令用来删除数据库 ... -
Oracle减少日志量的方法
2018-09-10 10:17 867LGWR进程将LOG BUFFER中的 ... -
如何快速关闭数据库
2018-09-09 13:14 1233“一朝被蛇咬,十年怕井绳”。在没被“蛇”咬之前,很多DBA喜欢 ... -
关于《如何落地智能化运维》PPT
2018-05-17 10:19 1129在DTCC 2018发表《如何落地智能化运维》演讲,主要内容如 ... -
记录在redhat5.8平台安装oracle11.2容易忽视的几个问题
2018-05-11 19:58 578问题一:ping不通问题 在虚拟机上安装好linux系统后, ... -
《Oracle DBA实战攻略》第一章
2018-05-11 10:42 947即日起,不定期更新《OracleDBA实战攻略》一书电子版,请 ... -
Oracle 12c新特性
2018-05-11 10:33 900查询所有pdb [oracle@gj4 ~]$ sqlplu ... -
关于修改memory_target的值后数据库无法启动的问题
2017-02-28 12:24 3983操作系统:RHEL6.5 数据库版本:11.2.0.4 ... -
10g rac安装error while loading shared libraries libpthread.so.0 问题
2017-02-28 12:22 69311g rac安装在二节点跑脚本一般会报此错误: 解决这个问 ... -
记一次Oracle会话共享模式故障处理过程
2017-02-27 19:16 799故障简述 XXX第八人民医院HIS数据库7月13日11点左右从 ... -
RESMGR:cpu quantum等待事件处理过程
2017-02-27 18:23 2615由于数据库上线过程中出现大量的RESMGR:cpu quant ... -
谈谈log file sync
2014-03-19 14:18 1759数据库中的log file sync等待事件指的是,当user ...
相关推荐
idea 2018 Statistic插件下载
安装并启用"Statistic-4.1.7.jar"后,用户可以在IntelliJ IDEA的侧边栏看到统计信息,无需离开编辑环境就能了解项目的整体情况,这对于团队协作和代码质量管理尤其有价值。在进行代码审计、重构或优化时,这样的信息...
maven-statistic-plugin-0.0.1.jar
插件根据文件类型分类统计。 插件版本和intellij版本的对应关系: | - 文件名 - | - 插件版本 - | - intellij版本 - | | - Statistic_7531.jar - | - ... | - Statistic-4.3.2.jar - | - 4.3.2 - | - 2024.2+ - |
idea统计代码行数可以用到插件:Statistic。解决老版本idea不显示该插件问题 Statistic-3.8.1.jar 详见:https://blog.csdn.net/Sun__Kings/article/details/109285389
maven-statistic-plugin-0.0.2.jar
jar包,官方版本,自测可用
$ git clone https://github.com/radosz99/statistic-xml-reader-v2.git && cd statistic-xml-reader-v2 $ pip install -r requirements.txt $ python app.py PyInstaller可执行 $ git clone ...
jar包,官方版本,自测可用
jar包,官方版本,自测可用
jar包,官方版本,自测可用
jar包,官方版本,自测可用
jar包,官方版本,自测可用
jar包,官方版本,自测可用
jar包,官方版本,自测可用
jar包,官方版本,自测可用
jar包,官方版本,自测可用
jar包,官方版本,自测可用
《IDEA代码统计插件Statistic 4.1.2版详解》 在软件开发过程中,了解项目代码的规模和结构是至关重要的。这有助于我们评估项目的复杂性,追踪代码维护,以及进行性能优化。IntelliJ IDEA,作为一款强大的Java集成...
IDEA统计代码量Statistic插件,可... -> 选择下载好的Statistic-3.8.jar文件 -> OK -> 安装好后重启IDEA,即可在底部工具栏找到Statistic。若找不到,在IDEA顶部菜单选择View -> Tool Windows -> 选择Statistic即可。