|
作者：佚名 责任编辑：左决 点击数： 更新时间：2008-3-27 1:22:25 |
 |
我怎样分离oracle I/O 来使得性能最高？
我是否应该分离数据文件和索引文件？
我是否应该分离redo日志？
这些问题（并且还有更多的），看起来似乎是对于数据库管理员来说的。它们在一般程度上很容易解答，但是在实际操作中可能是非常难以解决的，除非我们检查一下我们的磁盘子系统到底是怎样执行的。
我们中的许多人可能立即就不读这篇文章了，对自己说这些问题和详细程度只是对于我们的系统管理员或那些控制磁盘管理的人来说的。我经常看到两种不同的方式来配置oracle存储。第一种是当架构师要在一个存储数组中分离Oracle对象类型（数据、索引、重做、档案文件等等）时使用Oracle灵活架构（OFA，oracle‘s Flexible ArchITecture）方法。第二种方法是建立一个JBOD（Just a Bunch Of Disks，简单磁盘捆绑）配置并将所有东西都放到上面。这两种方法都缺乏能够最终形成协调的数据库系统的计划和配置。它们只是碰运气罢了，希望因为遵循了一个预先确定的方法从而一切进行顺利。但是，这些方法可能在你的环境里不起作用。不要依靠于你的系统管理员，因为他们自己可能都不知道怎么获取信息，而当他们这么做的时候通常是在更高的级别，因为他们也不能将这些信息与oracle堆栈关联起来。
所以数据库管理员必须开始从一个纯粹的I/O透视图来了解应用程序，将这个信息传递给存储管理员，然后一起开发一个配置或改变存储子系统的计划，这将用于应用程序混合。对于存储，OLTP环境的一个重要性能指示器是基于每秒I/O操作次数（IOPS）和延迟（I/O来回的时间）。OLAP数据库是你的数据仓库或报表系统，并由移动大量的主要做只读的数据来分类。对于存储数组，一个OLAP环境的性能是基于兆比特位每秒（MBPS）的。一个数据库工作负载经常描述为它的应用程序混合。了解和将一个应用程序混合转化为一个数据库工作负载对于优化存储系统来说是非常重要的。一个OLTP数据库的工作负载是由小的随机I/O来分类的，而OLAP是由大型的连续或随机I/O来分类的。
对于数据库管理员来说现在该看看你的数据库的内部了。你必须想办法获取某种形式的统计信息，使你可以在数据库级别分类SQL类型和I/O请求。例如oracle只有很少的表允许提取这个信息。举例来说，我们可以查询gv$sysstat视图（‘物理读取总的IO请求’——‘物理读取总的多块请求’）来获得系统中小量读取的次数。在一段时间内做这个操作，用结束时的值减去开始时的值，你就很快地获得了那段时间的小量读取的IOPS.必须对每一个可用的统计进行这个操作以了解你的数据库所请求的总的IOPS和MBPS.这些是你需要获得的相关统计信息。基本上，大量读写是用来计算MBPS的，而小量读写是用来进行IOPS计算的。
gv$sysstat (name, value)
Total Reads :'physical read total IO requests'
Total Writes:'physical wrITe total IO requests'
Large Reads :'physical read total multi block requests'
Large Writes:'physical wrITe total multi block requests'
Total Bytes Read :'physical read total bytes'
Total Bytes Written :'physical wrITe total bytes'
To calculate small reads:
Small Reads = Total Reads - Large Reads
Small Writes = Total Writes - Large WrITes |
使用这些数据使我们可以考虑到我们目前的数据库性能和存储请求从而作出明智的决策。数据库可能正在被讨论而实际的I/O请求可能比最优情形下的要低，所以可能需要进行调整。但是，将这些IOPS和MBPS转给存储管理员去评估存储解决方案是否是正确的和是否需要重新配置是数据库管理员的责任。这些重新配置可能需要移动数据文件来使用更多的磁盘、添加更多的磁盘用于更高的吞吐量、或者降低应用程序的IOPS和MBPS.是的，我们再次回到了应用程序。我知道你了解要做什么。
下面两个脚本使你可以开始了。我花费了很多时间来使它们变得容易使用，并提供给你信息，使你能够快速了解你的磁盘子系统在过去的时间里执行的怎么样。
[1] [2] [3] 下一页 |
|
|
|
|
|
