Oracle 数据库物理设计经验谈.docVIP

数据库物理设计经验谈(一) 发表日期：2003年11月28日 摘自: 概述 我们无论使用哪种数据库，无论怎样设计数据库，我想都会遵从一个原则：数据安全性和性能高效这两个主要方面，但是关于这两个方面的话题太多，在这里就不一一陈述，我只是从数据库物理分布设计方面和大家一起简单的探讨一下。因为数据库良好的物理分布设计也是对数据安全性和性能高效影响比较大, 就象我们在建大楼之前一定要先打好地基一样。 現实中我们在应用各种不同数据库的时候，往往会忽略数据库的物理布局，只有在数据库性能遇到问题的时候才去考虑，但这是得不偿失的，这样一来不仅会导致与设计相关的问题出现，而且会影响性能的调整效果，所以我们在创建数据库之前先进行规划数据库的物理布局也是很必要的，这也符合人们常说的”磨刀不误砍柴工”的道理。下面我就以Oracle为例从优化操作系统、磁盘布局优化和配置、数据库初始化参数的选择、设置和管理内存、设置和管理CPU、设置和管理表空间、设置和管理回滚段、设置和管理联机重做日志、设置和管理归档重做日志、设置和管理控制文件等几个方面作以陈述。 一．优化操作系统 为了获得最佳的服务器性能, 对操作系统的优化也是很必要的, 因为操作系统性能问题通常会涉及到进程管理、内存管理、调度等，所以用户需要确保有足够的I/O带宽、CPU的处理能力、交换空间来尽可能的降低系统时间。如果应用程序在缓冲区出现过多的”忙”等待, 那么系统调用的进程将会增加, 虽然可以通过优化SQL语句等方法来降低调用的数目，但是这也是治病不治根的。用户可以启动Oracle的初始化参数timed_statistics来增加系统调用的数目, 反之如果关闭此参数,那么系统调用的数目也会减少。操作系统的缓存和Oracle自己的缓存管理是不相冲突的, 虽然它能消耗一定的资源, 但是它对性能还是有一定好处的, 因为一般所有数据库的I/O需要通过系统文件缓存来访问文件存储器。 Oracle的操作可能会用到许多的进程(有的系统叫线程), 所以用户应该确保所有Oracle的进程、后台进程、用户进程具有相同的优先级, 否则就会产生恶化的现象, 导致高优先级的进程等待低优先级的进程处理完毕释放出CPU资源后再处理, 更不能将Oracle的后台进程绑定到CPU中, 这样一来也会导致被绑定的进程被CPU资源饿死。 比较好的是有些操作系统提供有操作系统资源管理器(Operating System Resource Manager), 通过它可以对系统资源访问划分优先级来降低峰值负载模式的影响，来实现多种管理策略和方法，控制用户资源的访问，限制用户资源的可消耗量。 二．磁盘布局优化和配置 在大多数产品数据库应用中，数据库文件一般都放在磁盘上，因此磁盘的良好使用和布局也是很重要的。磁盘布局的目标是：磁盘性能是不能阻碍实现数据库性能，数据库磁盘必须专用于数据库文件，否则非数据库将会影响到该数据库,且这种影响是不可预测的; 系统硬件和镜像必须满足恢复和性能的要求，数据文件大小和I/O不能超过磁盘的大小和I/O，数据库一定是可以恢复的，必须使后台进程之间的竞争最小化。在规划硬盘配置时也要注意：首先所用的磁盘容量，有时用多个容量小的磁盘比用一个大的磁盘效果更好，因为可以进行更高级的并行I/O操作; 其次磁盘的速度，如反应时间和寻道时间都将影响I/O的性能, 可以考虑使用合适的文件系统作为数据文件; 再者使用合适的RAID。 RAID(Redundant Arrays of Inexpensive Disks)廉价冗余阵列可以改善数据的可靠性，而I/O的性能又取决于RAID配置的方式：RAID1可以提供比较好的可靠性和较快的读取速度，但写的代价比较大，所以不适合频繁写的应用；RAID0+1在原RAID1的基础上读取的速度更快，所以这也是大家常会选择的方式；RAID5可以提供比较好的可靠性，有顺序的读操作比较适合这种方式，但性能会受到影响，对于写操作频繁的应用也不适合这种。对于该选择那种方式不能一概而论，要根据具体的情况而定。 有些应用软件先天性受到磁盘的I/O限制, 所以在设计的时候应尽量使Oracle的性能不受I/O的限制, 所以在设计一个I/O系统时要考虑以下的数据库需要: 存储磁盘的最小字节; 可用性, 如24X7, 9X5; 性能如I/O的输出和响应时间。决定Oracle文件的I/O统计信息可以来查询下列: 物理读数量(V$filestat.phyrds)、物理写数量 (V$filestat.phywrites)、平均时间, I/O=物理读+物理写。而I/O的平均数量=(物理读+物理写)/共用秒