5.Oracle 优化设计与调整.doc

ORACLE 9i/10g优化设计与调整赵元杰 2006年08月23日 前 言 2006年08月10日目 录第1章Oracle数据字典构成41.1静态数据字典41.1.1USER_ 为前缀的数据字典41.1.2ALL_ 为前缀的数据字典41.1.3DBA_ 为前缀的数据字典41.1.4其它的静态数据字典41.2动态性能视图51.2.1V$_ 为前缀的动态视图51.2.2GV$_ 为前缀的动态视图51.2.3数据积累的动态视图51.2.4数据非积累的动态视图51.3数据字典与同义词51.3.1与表名一致的同义词51.3.2与表名不一致的同义词5第2章Oracle对象有关数据字典62.1Oracle表62.1.1基本表有关的数据字典6第1章 Oracle数据字典构成为了使读者对本资料所描述的内容有直接的理解，这里从总结的角度出发，给出了深入了解Oracle8i/9i的管理所需的准备知识小结，如果读者对基本的概念已经很熟悉，则可以跳过本章。本章参考:Oracle9i Database Performance Planning Release 2(9.2)Oracle9i Database Concepts, Oracle9i Application Developers Guide Fundamentals;Oracle9i Database Administrators Guide.Oracle Application Server Performance and Tuning Guide.1.1 设计与开发性能考虑一个好的系统性能要从设计开发考虑,并且贯穿整个系统的生命周期。在设计阶段经过认真的考虑将给系统的产品阶段带来容易的调整。1.1.1 Oracle 性能优化新方法由于计算机系统性能变得越来越大、系统更加复杂，及商业应用的因特网扮演重要的角色，使系统性能也变得日趋势重要。为适应这样的发展，Oracle公司了一种新的性能方法。它就是基于Oracle设计和性能性能经历，并清楚的解释和简化改善系统性能的行为。实际上系统的效力是可变的也是不同的，比如，操作系统和决策支持系统需要不同的性能技巧。下面主要考虑数据库设计者、管理员及性能专家应该关注的焦点。l系统性能在设计完成和建立后往往不是立即产生;l系统的问题往往是某些系统资源耗尽的的结果;l当系统资源好尽时，系统就不能获得更高的性;lOracle新的方法就是基于数据库的认真的规划和设计;l从而避免由于系统资源的耗尽而使系统性能下降。1.1.2 理解投资选择由于高性能的处理器、内存及磁盘驱动器的便宜，购买更多的系统资源以改善系统的性能是一种诱惑。在多数的情况下，新的CPU、内存和硬盘可立即得到性能的改善。然而，任何通过增加硬件的投资来提高性能的方法都是短期的行为。如果需求和负荷继续增长的话，你仍然面临相同的问题。在另外的情况下，增加的硬件不完全解决系统的性能问题。不好的设计方法执行的效果会不好，无论你投资多少硬件都没有用。1.1.3 理解可测量性可测量性(scalability) 经常用于许多开发环境。下面解释可测量性的内容。1.什么是可测量性？可测量性是指系统资源均衡的增长，系统处理更多工作量的一种能力。换句话说，如果你有双倍的工作量，则需要两倍的系统资源。这是显然的，但是，当系统发生冲突时，资源的使应可能超过两倍的工作量。比如：v应用是根据人口的增长而需要网络管理；v增加锁的行为；v增加数据一致性工作量；v增加操作系统工作量；v在数据访问，由于数据卷的增加而事务需要增加；v不好的SQL和索引对于相同数量的行可能产生很高的逻辑I/O结果；v硬件耗尽；v表的大量扫描导致磁盘I/O的枯竭；v过分的网络请求，导致时间安排的瓶颈；v内存分配导致页交换；v过分的处理和线程分配导致操作系统负荷增加。2.因特网可测量性应用可通过因特网来访问使得性能变得更复杂。有些应用则是专为因特网而设计和开发，甚至是后台的办公软件，比如，一个通用的会计应用系统都可利用在线请求某些或所有的数据。因特网时代的应用的特点是：v24小时，365天可用；v不可预料的和不精确的用户数；v容量规划困难；v任何类型的查询都可用性；v多节点结构；v无国界的中间件；v快速的开发时间表；v最小的时间测试。3.预防可测量性因素在创建应用时，设计者和架构师应该尽量瞄准理想的可测量性。有时称为线性可测量性，因为在这里系统是直接与CPU的对应的。在是生活中，线性测量由设计者控制这样的推理是不可能发生的，但是，使一个应用设计尽量通过硬件的扩充和CPU的进展是可以实现的。预防线性可测量因子：1不好的应用设计、实现及配置。该应用在可测量性上有很多的冲突。例如：v不好的模式设计可能引起不可测量的SQL;v不好的事务设计可能导致锁和系列问题；v不好的连结管理可能导致不好的时间响应和不可靠的系统；v然而，不仅仅是设计的问题，应用的物理实现也可能是一个要点，如：v系统可能带着不好的I/O策略移植到当前的产品环境中；v产品环境可能使用与测试有不同的规划；v内存要求高的应用可能分配超过可用的大量的内存；v不足的内存和在操作虚拟内存子系统时产生内存泄露；2.不正确的硬件部件大小也能使了测量性工作量增加。3. 软件部件的限制所有软件都有可测量性和资源使用限制。这些也适用于应用服务器、数据库服务器及操作系统。4硬件部件的限制硬件不适进行比较，多处理器与有限的CPU很接近。但是，每当增加附加的CPU，性能就会有所增加，但不是成比例地增加。可能出现增加CPU后性能没有增加，甚至降低。这种行为非常接近硬件负荷和操作系统的设置。1.1.4 系统结构硬件和软件部件1.硬件部件如今的设计者和结构设计师对在多节点环境上的硬件部件是有责任的。要达到一个平衡的设计是架构师的责任。这就类似于桥梁设计师要考虑所有过往的各种负载和所架构的桥梁。主要考虑的硬件部件有：vCPUv内存vI/O 子系统v网络lCPU 可以是一个或多个 CPU。l内存 数据库和应用服务器需要考虑内存总量。lI/O 子系统 I/O 子系统可以是不是PC机的硬盘和高性能的阵列盘。阵列盘可有上千个I/O/每秒并多路I/O来提供可用性冗余。l网络 系统中的所有计算机都要连结到网络上。可以是调制解调器线、高速因特网LAN。主要涉及到网络的带宽（值）和反映时间（速度）。2.软件部件与硬件有有通用的部件一样，软件也有通用功能部件。由于软件开发分为功能部件，它可能由应用设计组成并且结构性好。系统的有些部件通过现有的软件来执行，这样可加速应用的实现或避免通用部件的重复开发。大部分的应用有下面部件：v管理用户接口；v实现商业逻辑；v管理用户请求和资源分配；v管理数据和传送。管理用户接口v用户的绘画屏幕v搜集用户数据并传输给商业逻辑v有效的数据输入v导航和数据描述实现商业逻辑v将数据传到相关的表结构v定义表结构的相关约束v可编码的逻辑过程以实现商业规则。搜集用户数据并传输给商业逻辑v连结到数据库v有效执行SQL(光标 个SQL共享)v管理客户信息状态v通过硬件资源来平衡用户请求v为硬件和软件部件设置可操作的目标v任务异步执行稳定队列管理数据和事务 v如果发生同时访问数据则加锁v使用索引优化访问数据和内存共享v确保改变的数据在硬件失败是被记录v强迫数据的规则定义3.正确配置系统结构配置初始系统结构是一个大的反复的工作。架构师必须在预算内和进度表内完成系统的配置。交互应用有:v会计和帐薄应用v定货登录系统vEmail系统v基于Web的零售系统v贸易系统1.1.5 应用系统设计1简单的应用设计应用设计不同于其它的设计和工程产品，好的结构、机器及工具通常是可靠的，容易使用的、易于管理的。多数情况下，如果设计正确，则也许是正确的。在应用设计时要把这样的原理记在脑子里：考虑下面设计问题：v如果表设计如此复杂以至无人理解；则该表可能就是坏表。v如果SQL语句写得太长，可能任何优化器不能有效处理，该语句可能是一个坏的语句。v如果表有索引，但该列有重复项索引，则该索引可能是坏的索引。v如果查询时没有相配的而被提交，可能是一个坏的用户接口。v 如果对数据库调用总由于软件的多层而被放弃，则该软件可能是一个坏的软件开发方法。2.数据建模（Data Modeling）数据建模对成功地设计应用是非常重要的。这个步骤可采用各种方法来实现。重要大是要采用最好的建模工具。建模工具的使用可快速产生模式的定义，并对原型法非常有用。3.表和索引的设计(Table and Index Design)表的设计在事务核心性能和灵活性要有一个大的折衷。保持数据库的灵活性的同时又要能适应无法预料的工作量，表的设计类似于数据建模，也要规范为至少第3范式。然而，某些核心事务为了性能问题可能需要违反这种范式。例如，存储预先连接的表；增加起源的列及聚集值等。Oracle提供聚集存储的多种选择，并通过Cluster和实体视图(materialized view)来实现预先连接(Pre-joined)。这样的特点允许一个简单表采用初始来设计。另外就是，资源应该花费在关键的商业表上，对于非关键性的表，设计捷径可采用快速应用开发。同样地，索引的设计采用应用设计软件产生SQL也是一个大量重复的过程。然而，建立一个主键和访问模式(如个人的名字)也是一个敏感的开始。当应用在进化和实际的数据测试完成后，建立一个好的索引可改善查询效果。下面建立新的索引时的索引设计的思想：v对索引追加另外的列或使用索引结构表（Index-Organized Tables）；v使用不同的索引类型；v找出索引的代价(在Insert,Update和Delete时的代价)；v在索引内采用系列化(采用Sequence来产生)；v在索引中排序。4.使用索引(Using Views)视图可加快和简化应用的设计，一个简单的视图定义屏蔽掉数据模块的复杂性。然而，当一个视图提供一个清晰的程序接口时，它们可能产生一些子查询和资源消耗的查询。最差的例子就是视图再引用视图并且当它们在查询被连接这样的例子。在多数情况下，程序人员可直接从表(不用视图)查询出满足条件的数据。这样采用视图给优化器产生执行计划带来了困难。5.SQL 语句执行效率任何应用系统在设计和架构阶段，要关心的是使应用开发人员正确理解SQL语句的执行效率。要做到这一点，开发环境必须支持下面特性：l好的数据连接管理连接到数据库是一个很花费时间的工作。因此，对数据库的并发连接数应该尽可能的最小化。一个简单的系统，一开始就让用户连接到数据库是一般的想法。但是，在基于Web或多节点的应用中，应用服务器用于多个数据库连接连接到用户，这种情况就比较困难。由于有着这样的类型，所以，设计时要努力确保数据库的连接集中和对每个用户都不产生重复。l好的光标和管理维护用户连接对在系统中最小化分析动作是很重要。分析语句是解释SQL语句和给出执行计划的处理。这个过程有很多的步骤，包括语法检查、安全检查、执行计划的产生及加载共享结构到共享池。6.执行应用开发环境和编程语言的选择在开发组和决策决定中是一个技巧性的工作。因此，有些简单的性能管理规则可被升级到高性能的应用。1)检查开发环境适合软件部件，不要使限制你的性能设计决定。用户接口商业逻辑用户请求与资源分配数据管理与事务2)当执行一个软件部件时，就是要执行它的功能，而不是其它的关联的功能。3)在设计、实现及测试中，功能上不要留有缺陷或有软件部件。多数情况下，这些缺陷在包装和测试时不容易被发现。这往往是初始产品不好的象征。在初始产品的设计、建立和实现中，数据的归档、净化模块通常都是被忽略的。4)过程逻辑与过程语言的实现例如 C 、JAVA、PL/SQL可实现访问控制或使用SQL（DML）可实现数据改变，在商业逻辑中可混合使用不同的语言来编码。最大的好处就是将过程逻辑安排SQL 访问。比如，DECODE,MIUNS等经常被选用。5)缓存那些频繁访问，但很少改编的数据。有代表性的例子如：SELECT SYSDATE FROM DUAL; 在数据库被加载超过60%;当前的用户名;重复的变量和常数，如出租比率、折扣比率和场所信息等；6)优化各个部件间的接口，确保所有的部件在多数的配置中可用。7)使用外部键引用，通过应用来强迫使用完整性是很花时间的。你可通过从父表的列来选择子表的列实现查询其存在性。外部键约束的强制是Oracle支持的。7.应用开发趋势在今天的用开发中，两个最大的挑战是使用JAVA来替代编译的C或C+在增加和使用面向对象技术也在增加。对于称许员来说，JAVA具有代码的轻便性和实用性。然而，JAVA也有存在一些性能问题，因为JAVA是解释性语言。在执行上要比编译型语言慢些。由于这些原因，客户端机器的资源使用在增加。这就需要在客户上或在中间机器增加更强的CPU才能达到。由于JAVA是一个面向对象的语言，它鼓励数据访问到类分开，不用执行商业逻辑。因此，程序员可只调用方法而不需要知道数据访问方法的效率。在数据库访问中这种趋势比较小。有了软件设计类型，查询不仅是包括WHERE谓词要讲究效率，行过滤在JAVA中也被执行。这是非常有效的。另外，对于DML语句，特别是INSERT语句，在单个INSERT语句在使用时采用数组是不可能的。在某种情况下，这种过程调用的效果更差。更多的资源用于进行数据的来往（移动）上。一般来说，最好的方法就是采用商业逻辑来实现。现在的面向对象的程序设计，指的是可采用多种方法来实现，如：从采用BLOB存储对象结构和只有效使用索引到Oracle的关系对象特点的使用等。如果采用的面向对象规划设计，则要确保不要丢失关系存储模型的灵活性。1.1.6 数据量估计与实施数据量大小当你在设计数据库表结构时，如果没有对表的数据的增长有一个经验的估计，则可在实际中数据增长过快而没有预料。另外，就是对表的数据的删除时（只要不是删除表中的所有行），对应索引的数据仍然保留不动，这样索引的空间的占用最后可能比表的空间还大，这时，你不得不采用Alter index REBUILD ONLINE语句来释放索引所占的空间。好的DBA要监视每个对象的空间的分配和查看对象的空间使用增长。要关注那些增长快的对象，这对于任何系统的性能和可用性来说都是至关重要的。工作量的估计设计人员需要指定CPU、内存、磁盘及最终通过的应用等。有几种方法来估计工作量的大小，每种都有自己的优点，最好是采用至少两种方法来估计以便有效的作出决策。1.从类似系统中推断1）找出相同的部分的数据；2）再找出不同的部分的数据。2.基准(Benchmarking)在实际中，当一个系统完全加载时，基准可很好地确定实际的I/O需求和测试恢复过程。基准可用来测试数据库、操作系统和硬件部件。因为大多数基准都以突袭来执行，期待的出现失败和问题。基准是一个产生压力的行为，也是值得考虑的经验。3.应用建模建模可以是很复杂的数学模型，也可以是简单的计算执行；由于一种是试图做得很精确，而另外一种则是大概的估计，所以两者都有优点。估计和大小处理是一个不严密的学科，然而，作为研究，有些带智能的估计还是需要的。对于很差的SQL、不合理的索引、不好的光标管理的所产生的应用，整个都采用估计处理是不行的。4.测试、调试和确认设计测试过程主要包括功能性测试和稳定性测试。在某些测试阶段，也进行性能测试。下面列出一些性能测试规则。采用现实数据测试和分类使用正确的优化器模式测试单用户性能为所有的SQL语句获得文档计划(CPU时间和物理I/O)试图进行多用户的测试在硬件的配置正确下测试测试稳定性和性能1.1.7 配置新应用首次展示策略当一个新的应用腿出的时候，需要采用两个策略：v一炮打响方法-所有用户一次移植到新系统上v渐进式方法-用户慢慢从原来系统移植到新系统两种方法都优点和不足，一炮打响方法是建立在对需求有很好的测试的基础上，具有最小化数据转换和与旧系统同步的优点。因为它只是简单的切换。而渐进式允许可测量调试。它的用意是从旧的系统进行数据移植。性能清单在配合首次发行过程中，要建立一个任务清单。如果演示正确，则在产品上增加好的表演的机会，如果表演有问题，则快速调试问题。如：1.建立数据库控制文件当你为产品数据库建立一个控制文件时，下面将下面参数值设置为较高的值：MAXINSTANCES, MAXDATAFILES, MAXLOGFILES, MAXLOGMEMBERS,和 MAXLOGHISTORY2.为开发应用设置块大小和优化器模式如果测试已在典型的环境上进行过并且SQL执行计划是正确的话，从开发/测试环境导出模式统计到产品数据库上。3.设置最小化的初始参数重要的参数在SGA 中是可变的，附加的参数指定归档卸出目的地应该作为备份和调试目的来设置。理想情况下，多数的参数应该保留默认值。这样，如果需要性能调整的话，这些参数显示在负荷下的情况。4.通过设置数据库对象来管理块冲突表和索引经历过很高的INSERT/UPDATE/DELETE操作后，应该自动建立段的管理或多个自由列表和增加INITRANS的设置。为避免回滚段的冲突，无论是采用自动撤消管理或多个回滚段都应该支持用户数量的要求。5.所有的SQL语句都应该被检验过并且是它们的资源使用是认可的6.验证中间件和程序连接到数据库的有效性。7.验证SQL语句使用光标的有效性。每个SQL语句应该被分析一次和执行多次。确认下面参数：MAXOPENCURSORS, HOLD_CURSOR和RELEASE_CURSOR8.验证所有的模式从开发环境移植到了新环境。包括表、索引、序列、触发器、包、存储过程、函数、JAVA对象、同义词、授权及视图等。9.设置建立统计基线尽早将产品推出,从数据库和操作系统的设置建立统计基线。要实现这样的要求，可用企业管理器或Statspack来实现。10.起动预期的第1个瓶颈和使用Oracle的性能方法使性能改善。1.2 监视和改善应用性能1.2.1 统计的重要性在问题发生之前，搜集可能的统计数据和得到应用的全部描述。得到完整的统计数据可有效地进行进行管理。操作系统统计操作系统统计提供主机部件使用的性能。也是操作系统的性能。这些信息对于诊断资源使用情况是至关重要的。操作系统的统计包括：vCPU 统计v虚拟内存的统计v磁盘统计v网络统计CPU统计在调整过程中，CPU的利用是非常重要的。得到整个系统的CPU的利用情况和多处理器环境下的单个CPU的信息是非常重要的。多数操作系统都在用户间隔以时间消耗、或模式和在核心间隔时间的消耗来报告CPU的使用信息。Oracle数据服务器只产生系统在运行时的报告。包括时间表、同步、I/O、内存管理及进程/线程的建立及停止等。在所有的CPU都饱满地利用的情况下，一个健壮的Oracle系统应在用户空间的65%到95%之间。虚拟内存虚拟内存的统计主要是用于在系统中有少量的叶交换下有效性检查。当出现叶交换时系统的性能降低非常快。当某个程序失败而要从处理堆中取消分配内存时，单处理内存统计可检查内存的泄露。这种统计主要用于验证内存的使用情况，而不是在系统启动后增加内存。磁盘统计由于数据库存放在一组磁盘中，因此磁盘子系统对数据库系统的性能就非常重要。多数操作西亚提供磁盘性能的统计。最重要的统计就是当前的响应和磁盘队列的长度。这些统计显示磁盘运行最佳或当前磁盘处于过载的情况。这就是系统的瓶颈。如果磁盘队列超过两个，那么磁盘就是一个潜在的瓶颈。网络统计类似于磁盘统计，网络统计也是用于检查网络接口的过载情况或执行不佳的情况。在当今的网络应用中，网络的反应可能是用户使用响应时间的一部分。比如，会话就是一重要的调整工具。数据库统计只要内部和外部的资源被数据库使用，数据库统计就提供数据库家载类型的信息。当数据库资源使用耗光时，它可能就是应用的瓶颈。数据库统计可以直接手工用SQL查询数据库的数据字典。这些统计可以附加在数据库里面，如：INSERT INTO x AS SELECT . or CREATE TABLE x AS SELECT . 语句。这是一个简单的快照机制，它允许在整个时间搜集统计数据。多数的统计都包含在V$的虚表或视图里。这些表都是只读，而且都属于SYS帐户。为了获得数据库的统计数据，需要在初始化参数中设置TIMED_STATISTICS参数。核心数据库统计包括：v高速缓存（Buffer Cache）v共享池（Shared Pool）v等待事件(Wait Events)v应用统计1)高速缓冲区统计这个区管理从磁盘块读到内存的缓冲区。这个区也保留最近正在使用的信息和整常操作所修改过的信息。大多数的统计信息可从V$SYSSTAT中查询到。2)共享池共享池包括用户会话的信息、所有数据库会话用的数据结构及数据字典。查询共享池可以分析在数据库中运行的SQL语句。可从V$SQL中查询到SQL语句运行的CPU时间、磁盘I/O等。3)等待事件在通常的数据库服务器操作中，当进程需要共享资源或需要与其它的进程同步时，就会产生等待事件。比如，在共享池中分配内存或等待一个锁都是一个等待事件。在这种情况下，用户进程停止工作并进行等待。等待时间变为用户响应时间的一部分。如果在共享资源中或同样的外部资源中有多个进程排队，则数据库启动单进程并且是可测量的。性能分析就是确定在数据库的资源中为什么发生等待。 V$SYSTEM_EVENT, V$SESSION_EVENT和V$SESSION_WAIT 可查询出等待事件的历史信息和真实的信息。4)应用统计应用统计也许是最困难的统计，但是在改善系统性能时有是最重要的。至少，应用统计应该提供每天的用户事务的小结。更精确的统计应该提供事务类型的处理情况。1.2.1.1 统计数据搜索工具1.操作系统数据搜集工具UNIX工具：CPUSar,vmstat,mpstat,iostat内存Sar,vmstat磁盘Sar,iostat网络netstat如果是NT，则用性能监视工具2.数据库数据搜集工具Oracle提供三种主要的搜集工具，这些工具在安装和运行都较复杂，但是也比较灵活。它们是：1). StatspackStatspack 用 BSTAT/ESTAT 脚本建立。见后面章节。2). Oracle Enterprise Manager (EM)Oracle 在新版本提供图形界面工具叫OEM(Oracle Enterprise Manager )也能进行性能的搜集。3). BSTAT/ESTAT 脚本在 $ORACLE_HOME/rdbms/admin 目录下的UTLBSTAT.SQL 和 UTLESTAT.SQL文件，可产生简单的数据库在两个时间之间的活动报告。前面的Statspack实际是在UTLBSTAT.SQL 和 UTLESTAT.SQL发展而增强的新工具。1.2.1.2 历史数据与基准线对于管理性能的工程师来说最大的挑战是确定改变了什么才引起应用系统开始出现性能问题。在现代的复杂的系统里确实是个棘手的问题。在除掉许多可能的变化后，历史性能数据就是至关重要的。这就是说，从应用系统运行的第1天开始，你就应该搜集操作系统、数据库及应用系统的统计数据。1.2.1.3 性能的直觉数据库和操作系统的统计是如何进行系统优化的一些迹象。在与实际的吞吐量的统计中，你应该看到系统是如何执行的和在何处确定资源的瓶颈及资源缺乏的存在。这是一个多年在Oracle服务器上工作的经验和技巧。使用统计来理解和监视CPU的使用是一个最容易的事。监视整个时间的统计，你可看到系统在工作日和工作周是如何使用。然而，统计数据不是表示有多少个商业事务被执行或什么资源被每个事务来使用。但是两外两个统计确能反映实际的商业事务执行情况。当用户在USER COMMITS和REDO SIZE后可在V$STSSTAT中找到。这些统计显示实际事务的数量和数据库中改变的数据卷。如果这些统计是随着时间增加，而应用和事务逻辑没有改变，则你可了解到商业事务的执行情况。逻辑块读(从V$SYSSTAT查 session logical reads)也反映查询的工作量。1.2.2 Oracle性能的改善方法1.2.2.1 性能的改善Oracle性能方法学可帮助你查明你的Oracle系统的性能问题的所在，包括瓶颈问题及解决。由于性能问题的客观性，因此性能改善是一个反复的过程。比如，将瓶颈解决了还不能得到好的性能，因为可能另外的地方还遗留有瓶颈问题。甚至有时，一系列的关键问题解决了，性能反而降低了都会发生。作为经验，就应该严格查找每个可能的原因。性能问题的产生原因是缺乏吞吐量、不能接受用户/作业的响应时间或两者皆有。问题可以在应用模块间或整个系统间来定位。查询任何的数据库和操作系统的统计，从系统的最重要的部件来反馈是至关重要的。特殊用户的反馈包括的语句类似下面的情形：v联机执行是如此的糟糕；v运行时间过长；v在我体验一个很高的Web交通流量，反映时间无法接受；v我每天要完成500个交易，系统已不够。1.2.2.2 性能的优化步骤性能优化一般采用下面步骤：1.得到用户公正的反馈，确定优化方案和优化目标;2.从系统由好变坏的完整的操作系统、数据库及应用系统的统计数据；3.认真检查与用户有关的操作系统机制，检查OS、硬件等；4.检查顶上10个最关键的错误。找出最象有问题的错误并列表；5.构造一个系统发生征兆的模型；6.给出一系列补救措施的建议和对系统预先处理具体行动；7.确认改变是有效的，并且用户感觉有效。否则详细查瓶颈。8.重复第3步直到性能达到目标。1.2.2.3 如何检查操作系统操作系统征兆的检查主要包括：v在用户或核心空间检查CPU的使用；v确认没有页交换v在两台机器检查网络的反映；v找出反映慢的磁盘v确认没有硬件故障1.2.2.4 性能建模样例决策处理概念建模还是要进行的，然而，当你的性能调整增长后，你会发现没有什么规则可行。一个灵活的“向上”逼近用来解释个种统计和作出好的决策。下面是一个性能工程师是如何分析瓶颈的建议。对于有经验的工程师，还加上棘手的步骤等。下面假定操作系统和数据库的统计都搜集的情况下所要进行的分析：1.对于单用户或轻松加载的机器，响应时间/批处理时间可接受？如果不能接受，可能是代码和设计的优化，并当系统资源为共享时，多个用户不能接受。此时，需要得到应用内部的统计和SQL跟踪及SQL计划信息。与开发人员了解数据、索引、事务SQL设计及批处理和后台进程的潜在延期。2.所有的CPU都在利用？如果核心利用超过40%，则要研究操作系统的有关网络传输、页交换或进程压力等。检查是否存在非数据库作业消耗CPU资源，比如备份、文件传输、打印队列等。确定是数据库在使用大多数CPU后，研究CPU使用的顶上的SQL语句。可从V$SQL中查询语句的统计信息。如果应用是优化的并且没有无效的SQL语句，重新定义完成时间表或使用大的机器。3.在这一点上，系统性能不能满足，CPU资源不完全被使用。 此时，还得从WAIT_EVENTS统计得到服务器信息并 终止最长的系列点。1.2.2.5 找出系统关键的10个错误下面是Oracle最普通的10个错误：1. 坏的连接管理2. 坏的光标和共享池的使用在重复分析中不使用光标，如果不使用绑定变量，则要对所有语句作分析。这就有大量的性能问题并且不可测量。在绑定变量中使用打开的光标并可执行多次。3.获得数据库I/O错误多数结点出现使用不佳，而另外的结点则列出磁盘不正确，这可能是因为在配置时是逐个地配置而不考虑I/O的带宽。4.重做日志设置问题多数结点在很少而且很小的重做日志下运行，而小的重做日志会引起系统在缓冲区中和I/O系统中检查点持续走高。如果重做日志太少，则归档不能维持，并且数据库将要等待归档进程也要赶上才行。5.在缺乏自由列表、自由列表组、事务通道或缺乏回滚段的情形中，缓冲区数据块过碎在插入非常巨大的情况，应用应该增加块的大小到8K或16K。6.大表的全表扫描很高的全表扫描或交互式联机操作表示为不良的事务设计、缺少索引、不良的SQL优化。7.磁盘排序联机操作的磁盘排序表示为不良的事务设计、缺少索引或不良的SQL优化。自然，磁盘排序也是I/O 严重的和不可测量的。8.很高的递归(SYS)SQL语句在SYS上执行大量的递归SQL将表示空间管理在活动，比如，扩展分配、取得空间等。这些都是不可测量的，也是影响用户的反应时间。可在其它用户通过SQL和PL/SQL来执行这些递归SQL语句，这样做就会解决问题。9.模式错误和优化器问题在多数情况下，由于模式拥有的表不能成功地从应用环境或一个旧的执行环境进行升级，就会使一个应用使用太多的资源。例如，缺乏索引或不正确的统计。这些错误将影响到优化执行计划和不良的用户交互。要得到优化的升级，在导出模式统计时采用DBMS_STATS包来维护计划的稳定性。同样，也要设置初始化参数等。即要保持模式、模式统计及优化器一致。10.使用非标准的初始参数可能做了不良的建议或不正确的设想，在特殊情况下，在锁存器下和不正规的优化特点下，使用SPIN_COUNT参数可能产生很多问题。1.2.2.6 硬件配置的性能特点除此之外，当今的系统是如此的不同和复杂，以至于非常可靠性能分析都不能进行。因此还要考虑下面的情况：1. 磁盘特点:v大小在 512MB - 36GBv寻道在 5 - 10微秒(msec)v传输在 5 - 10微秒(msec)v吞吐量在 20 - 40 I/O 每秒(msec)v控制器吞吐量在 1750 I/Os 每秒2. 读内存速度在 1 - 10 微秒3. 点对点网络反映速率在 1 - 25微秒(msec)4. 忙系统: (最坏情形)v操作系统 - 60% usr, 40% sysv决策支持系统 - 90% usr, 10% sys1.3 紧急情况的性能技术1.3.1 紧急情况技术前面讨论的是系统的规划和设计方法。然而，系统从一个可靠变为不可预测也是经常发生的。在这种情况下，性能工程师的任务就是快速确定发生了什么变化和采取适当的措施尽快解决问题。在多数情况下，这些要求必须立即的。在寻找性能问题时，性能工程师必须搜集足够的调试信息以搞清性能问题的原因，或至少使这类问题不再发生。调试紧急性能改善的方法与前面讨论的性能改善有些类似，然而，采取的策略不同，因为这种紧急性能在时间上短暂的。对种情况，保持详细的注释和实际情况记录是往后分析调试的基础。1.3.2 紧急情况处理步骤对于紧急性能问题采取的方法是：1.测量性问题和搜集性能征兆用户反馈的系统性能不好的是怎样；是吞吐量或是时间？从最后性能还是好以来作过何种改变？从这些回答可得到一些线索。2.认真检查应用系统所在机器的部件的硬件的可用性检查最高CPU和磁盘及内存、网络性能等的使用情况。接着快速处理以识别哪里出了问题。然后分析应用的Bug。3.确定CPU上的数据库服务器情况确定CPU上的数据库服务器不良或在等待事件中被挂起如果是CPU的问题，则：则会话在OS级要求大量的CPU；会话和语句执行要求许多的缓冲区（从V$SESSTAT和V$SQL 得到）；执行计划的改变引起子优化语句的执行；不正确设置初始参数；计算后作为代码结果发布或升级所有部件。如果数据库会话是在等待事件，则可从V$SESSION_WAIT确定引起的系列问题。在有大块的库缓存冲突的情况下，一般不可能登录到数据库，也不会成功发出SQL语句到数据库。在这种情况下，利用历史数据确定为什么突然产生锁存器竞争。如果等待的I/O，那么会话正在运行的SQL就是所有I/O性能。4.应用紧急处理以稳定系统可能包括使部份应用脱机或限制应用系统的工作量。同时也包括系统的重新启动或在处理中的作业的终止。5.验证系统是稳定的，改变和限制系统验证系统现在是稳定的，搜集数据库统计参考集。第2章 Oracle系统安装问题Oracle数据库系统的安装与以后应用系统的运行有着密切的关系，如果一个中大型的应用系统没有充分设计和规划，而是采用默认的方法安装，则给以后应用系统的运行带来一定的影响。下面给出一些建议。2.1 应用系统类型考虑 在进行应用系统的物理设计和逻辑设计时，都考虑应用系统的类型。一般目前的应用类型有如下几种。2.1.1 联机事务处理（OLTP）联机事务处理(OLTP=Online Transaction Processing)系统是指一个包含繁忙的DML（INSERT、DELETE、UPDATE）操作的应用。它的重点是更新；其次是插入和删除。此外也有查询操作（SELECT）。必然民航或列车的预订系统。银行系统等。这种系统的特点是：要求有很高的并发性和及时的反应效果。2.1.2 决策支持系统（DSS）决策支持系统（DSS=Decision Support System）是一个包含有大量历史数据的、只读的数据库系统。通常的的处理主要是查询，而这种查询是一些固定的查询和统计。它的特点是：大量的查询、需要建立大的索引、大块的进行增、删、改处理。2.1.3 联机分析系统（OLAP）联机分析系统(OLAP= Online Analytical Processing)是一个可提供分析的数据库系统。它主要是采用数学、统计学、集合聚集计算对数据进行大量的计算，以得到希望的统计结果（图表、趋势图等）。它的特点是：系统要进行全表扫描；需要快速的磁盘I/O处理和快速的CPU速度，但是并发的用户数较少。2.2 操作系统规划如果在分析阶段得到用户的初步资料，在与用户讨论确认之后就可以订购数据库服务器了。当数据库服务器到货后，就可以与操作系统人员一起规划服务器的操作系统的安装和Oracle数据库系统的安装等。当数据库服务器在开箱后，就开始规划如何安装操作系统软件。因为一般的小型机或多数服务器机器在出厂后是不安装任何软件的。所有安装操作系统和其他所需要的软件都是在机器安装完成后由供应商进行的。为了使所安装的操作系统能满足Oracle系统的基本要求，有的服务器的操作系统需要注意某些Oracle的要求：2.2.1 操作交换区交换区是Oracle的一项基本的要求。可以根据Oracle的发行要求来确定。一般交换区大小的要求是该服务器内存的2倍至4倍之间。过小的交换区可能导致Oracle系统安装的失败，所以建议交换区最好是内存的4倍为佳。2.2.2 硬盘格式化的考虑在安装操作系统时，安装程序会提示将硬盘化分为不同大小的部分。在安装操作系统时就开始考虑哪个硬盘(或路径)是用来安装Oracle系统的，哪个硬盘(或路径)是用来存放数据文件的等。建议用于存放Oracle数据库系统的目录一定比Oracle系统发行要求的2倍以上。2.2.3 安装点的考虑除了考虑交换磁盘的大小外，还要考虑Oracle数据库系统的数据文件的目录所对应的硬盘的大小。Oracle系统所在硬盘最好不要与其他的软件混在一起。一般建议在安装时将数据文件、日志文件及控制文件要分别存放到不同的磁盘路径上。数据文件占空间最大，可考虑磁盘的划分2/3用来存放数据文件；其此就是控制文件空间的考虑，如果你的版本为9i以上版本，而且可能采用RMAN和归档模式运行的话，控制文件也随着时间的推移而不断增长。所以，控制文件所在路径也要留有足够的空间。一般考虑在500MB左右。第3个要考虑的就是重做日志文件的路径。日志文件一般比较小，但是为了安全，日志文件要求有几组，每组至少两个日志文件（叫成员）。每个文件（成员）大小在几MB到几十MB之间。一般建议三组日志文件，每组有两个文件。日志文件所在路径保留在200MB左右即可。2.2.4 归档文件磁盘大小考虑如果你的应用系统要求比较苛刻，可能采用归档模式运行。着样，还得考虑归档文件所在磁盘的大小问题。一般归档文件是一个不断增长的文件。所以除了将归档文件与日志文件等分开外，必须为归档文件所在路径留有足够的空间。一般不得少于几百MB。2.3 安装Oracle系统为了安装我们的规划来安装Oracle系统，建议你采用“自定义”来安装你的Oracle系统。这样，你才可以按照要求规划你的数据文件、控制文件及日志文件等。2.3.1 安装操作考虑当服务器平台已完成操作系统的安装后，就应该开始认真的考虑下面的问题：l操作系统的信号量Oracle在某些UNIX操作系统(如HP-UX、Solaris、Linux、SCO UnixWare)环境下安装需要合适的操作系统信号量。应该根据Oracle版本发行的要求进行设置，比如在SUN 环境下，需要以root 登录并根据Oracle安装手册的参数要求修改/etc目录的system文件。然后在进行Oracle RDBMS的安装。l是否采用升级方案果应用是将旧的应用系统上进行升级的话，要考虑系统的性能问题。一般建议采用非升级安装，采用人工升级。因为系统自动升级安装会给应用带来性能问题。l安装类型方案采用自定义安装进行Oracle数据库系统的安装，这样考虑根据需要定义包括字符集、数据库块的大小、数据文件的大小等。l安装点的考虑Oracle的安装点就是指数据文件、日志文件和控制文件的安置路径，为了使系统在以后运行性能达到优化，建议将数据文件、日志文件和控制文件的安置路径与数据库系统存放在不同的路径上。最好将数据文件、日志文件和控制文件分别存放在不同的路径。lSYSTEM表空间对应数据文件在自定义安装会话中，建议你根据需要设置system表空间所对应的数据文件的大小。一般要设置比默认值的2倍。该数据文件的大小最好是在300MB至500MB间。因为数据文件太小不利于系统的运行。l临时表空间对应的数据文件临时表空间对应的数据文件可以根据将来系统存放的应用的处理情况来定。比如系统将来可能要经常进程排序处理，则需要设置较大的临时表空间，也可能需要再建立新的临时表空间。这里建议临时表空间的数据文件在100MB至300MB左右。l回滚段表空间对应的数据文件如果是Oracle8i及以前的版本，则考虑为RBS表空间建立较大的数据文件。最好数据文件在300MB至500MB之间，如果不够在完成安装后再进行扩展。但是不要采用默认值。l日志文件的大小日志文件的大小对于Oracle系统的运行也是相当重要。默认值是太小。建议日志文件大小在10MB至50MB左右(Oracle9i默认大小为100MB，而Oracle 10g默认大小为10MB)。l控制文件的大小如果是Oracle8及以上版本，控制文件文件除了存放数据文件信息和日志文件信息外，换存放恢复信息等。所以控制文件所在目录应该有足够的扩展空间。一般建议在该目录应该有200MB 以上空间。l数据库实例的块大小如果你的应用系统是OLTP的话，可以采用较小的数据块(data block)。如果是DSS类型的应用系统，则可以设置较大的数据块，目前Oracle产品所允许的数据库块可以是2KB至64KB之间。无论你选择较大的块或较小的块，它的值都必须是2的整数倍，比如2048,4096,8192等。但需要注意的是，如果操作系统为64位，则可选择较大的块。总结如下： Oracle系统的最小处理单元 物理文件由多个数据块组成 系统默认的典型大小为4K或 8K 建议不要选择小于 2K 或大于 32K 数据块(Data block)由一个或多个操作系统块组成l字符集的选择字符集是Oracle系统专门支持的一项技术。详细请参考另外的章节。一般不要与另外的已经存放的Oracle系统的字符集产生冲突即可。但如果你的环境是一个新的平台，不需要与其它平台进行数据交换的话，建议选择默认的字符集。这样可以利于将来的修改。2.3.2 创建多个实例的问题一部分设计师和用户都这样认为，用户的应用系统有几个子系统，就应该建立几个数据库实例(INSTA