Oracle数据库性能优化实践指南(txt+pdf+epub+mobi电子书下载)


发布时间:2021-02-21 13:35:18

点击下载

作者:霜月琴寒

出版社:电子工业出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

Oracle数据库性能优化实践指南

Oracle数据库性能优化实践指南试读:

前言

我猜在你看到这本书之前,你可能已经在互联网的各种技术博客和论坛中学习到了一些关于Oracle优化的内容。但是有些内容是如此的散乱,以至于当你真的想要开始做优化时,根本不知道如何入手。在我刚开始学习Oracle优化时,这样的问题同样困扰了我很长时间。我强烈地感到:一本权威、系统的Oracle优化指导书是多么的重要。

而本书,涉及了Oracle优化的所有方面,系统地讲述了Oracle优化的相关内容。如果能对本书的内容融会贯通,那么在从事相应工作时肯定可以做到得心应手。

本书分为5个部分。

第1部分总体介绍了性能优化涉及的3个方面:性能计划、实例优化和SQL优化。另外,也简单提及了一些优化过程中会用到的特性和工具。

第2部分描述了在一般情况下和紧急情况下的性能优化的通用方法,其中也罗列了在调优实践中最常见到的10个错误。

第3部分对在性能计划阶段应该考虑的性能优化相关的事项进行了介绍。

第4部分介绍了如何通过优化实例来提升数据库性能。实例要工作就必须借助于资源。本部分围绕资源展开。

第5部分介绍了如何对SQL进行优化,SQL的优化重点在于对执行计划的优化。本部分围绕执行计划展开。

本书可以帮你叩开Oracle 优化的大门,让你直接看到想要的正确的、完整的答案。如果你想学习Oracle优化,想要成为这方面的专家,那么本书将帮助你实现这个目标。对于想学习Oracle优化的朋友来说,本书不仅是答案,也是机会,一个让你真正了解Oracle优化的机会。希望大家可以通过本书,在Oracle优化这条路上少走弯路,在正确的、宽阔的大路上走得更痛快、更自信!

由于本人能力有限,如有不妥之处还请大家指教。霜月琴寒2015年1月6日第1部分性能优化是怎么回事儿第1部分对性能优化进行介绍和概述。第1章 了解性能优化

这章对性能优化进行介绍,包括以下两个部分:

■ 性能优化包括哪几个方面。

■ 哪些工具和特性可以帮助进行性能优化。1.1 性能优化包括几个方面

本节包含三个主题:

■ 性能计划。

■ 实例优化。

■ SQL优化。1.1.1 性能计划

这部分描述了可以大幅提高系统性能的活动,包括:

■ 理解投资选项。

■ 理解延展性。

■ 系统架构。

■ 应用程序设计原理。

■ 负载测试、建模和实现。

■ 部署新的应用程序。1.1.2 实例优化

第4部分“性能优化三件事之二:DBA如何优化资源使用而改善实例性能”将详细讨论对实例进行优化涉及的各种因素。

当考虑优化实例时,需要注意数据库的初始设计,以避免瓶颈带来的性能问题。另外,还必须要考虑:

■ 给数据库结构分配内存。

■ 调整操作系统以优化数据库性能。

在数据库安装配置完成以后,必须监视数据库的运行,以检查性能相关问题。

1.1.2.1 性能原理

性能调优前需要对系统进行初始配置,配置系统要求按照顺序分配资源以使初始的系统能够工作。调优时首先要识别最严重的瓶颈,然后做出适当的改变以减少和消除瓶颈的影响。通常,调优是被动的,它既可以在产品上线前进行,也可以在产品上线后进行。

1.1.2.2 基线

用于调整最有效的方式莫过于有一个基线,如果性能问题产生了,你可以将其用于比较。大多数DBA都很了解他们的系统处于正常负载和峰值负载的时间规律。例如,峰值期处于上午10:00到12:00和下午1:30到3:00。还可能包含一个批处理的时间段,例如,晚上12:00到凌晨6:00。

识别峰值的时间段并且利用监控工具收集高负载期间的性能数据是至关重要的。最好是在刚开始使用系统时的QA阶段就进行数据收集。如果做不到,也应该在系统一上线就开始收集数据。

在理想情况下,收集的数据应该包含以下部分:

■ 应用程序统计(事务数、响应时间)。

■ 数据库统计。

■ 操作系统统计。

■ 磁盘I/O统计。

■ 网络统计。

在AWR(Automatic Workload Repository)中,基线是通过一定范围内的快照建立起来的,它被保留并用于将来的比较。请参考第6章中的“AWR概览”。

1.1.2.3 症状和问题

在调优中最常见的教训是把症状当成问题本身。认清众多的统计数据所表示的症状是很重要的,但仅仅识别症状对于应用一个补救措施而言还是远远不够的。例如:(1)较慢的物理I/O。

一般来说,这是由配置较差的磁盘引起的。但也可能是由未经优化的SQL语句造成大量的不必要的物理I/O引起的。(2)闩锁争用。

很少有闩锁可以通过重新配置实例得到优化。相反的,闩锁争用问题通常会通过应用程序优化来解决。(3)过高的CPU使用率。

过高的CPU使用率通常意味着系统只有很少的空闲CPU。通常是由CPU资源不足的系统、未经优化的SQL语句或者效率低下的应用程序引起的。

1.1.2.4 调优的时机

有两种不同类型的调优:

■ 主动监控。

■ 消除瓶颈。(1)主动监控

主动监控通常是有计划地周期性进行的,在此期间,会检查很多性能统计数据来确认系统行为和资源的使用情况是否发生了变化。主动监控也被称作主动调优。

有时候,即便性能表现比较正常,但有经验的性能工程师还是能够发现一些潜在的性能问题。但要注意,除非发现了很严重的正在恶化的问题,否则一般情况下都不会进行系统配置的调整。在系统没有明显的问题时,拿系统做实验或者去调整系统是一件很危险的事情,这可能导致性能变坏。调整系统应该是被动的,并且应该遵循被动调整的步骤。

监控通常是整体的性能计划的一部分,在这里,需要检查资源消耗改变的方式,以及应用程序使用数据库资源和主机资源的方式。(2)消除瓶颈

调优通常只是为了修复一个性能问题。但是同时,调优也应该是应用程序生命周期的一部分,贯穿于分析、设计、编码、上线、维护的整个过程中。经常发现直到产品上线时才开始优化的情况。这时,调优变成了一个非常被动的过程,很多最重要的瓶颈才刚刚被识别并等待被修复。

通常,优化的目的要么是减少资源消耗,要么是减少操作完成的时间,也可以说是更有效地使用某种特定的资源。性能问题通常是由于过度使用了某种资源引起的,而被过度使用的资源就是系统的瓶颈。识别和修复瓶颈有很多不同的阶段。这些内容将在后续部分进行讨论。

记住,不同形式的争用表现出的症状都可以通过以下这些地方的改变而被修复:

■ 改变应用程序或者应用程序被使用的方式。

■ 改变Oracle。

■ 改变主机的硬件配置。

在通常情况下,应用程序的改变是最有效的。1.1.3 SQL优化

第5部分“性能优化三件事之三:开发人员如何优化SQL执行计划”将讨论调整和优化SQL语句的过程。

很多应用程序的开发程序员认为SQL是一种消息语言,因为提交查询,然后就能返回数据。但是客户端工具经常生成低效的SQL语句,因此,对SQL处理引擎有一个很好的理解,对于编写出优化的SQL语句来说是必要的,尤其是对于一个高效的事务处理系统来说更是如此。

典型的,由一个OLTP系统发出的SQL语句一次只操作很少的行。如果索引能精确地指向它请求的行,Oracle就能构造一个准确的计划,以最短的路径访问这些行。而在决策支持系统(DDS)中,选择性并不重要,因为它经常访问表里的大部分行,这时全表扫描很常见,甚至根本不用索引。对于DDS和混合环境的更详细信息可以参考Oracle Database Data Warehousing Guide。

查询优化器和执行计划

当SQL语句在Oracle中执行时,查询优化器会考虑语句所涉及的对象的很多因素,以及查询的特殊条件,来决定一个最有效的执行计划。这个步骤在处理任何SQL语句时都是非常重要的,它非常明显地影响着SQL执行的时间。

在评估过程中,查询优化器再次查看系统的统计数据,以此来决定最佳数据访问路径和做一些其他的考虑。但是,你可以通过在SQL中插入“提示”来覆盖这个执行计划。1.2 哪些工具和特性可以帮助进行性能优化

有效的数据收集和分析对于识别和纠正性能问题来说是非常重要的。Oracle数据库提供了很多工具让性能工程师针对性能收集数据。除了收集数据之外,Oracle数据库还为监控性能、诊断问题、优化应用程序提供了工具。

Oracle数据库收集和监控数据的过程,主要是通过Oracle后台进程自动管理的。为了启用自动数据收集功能,以及性能相关的自动功能,初始化参数STATISTICS_LEVEL必须被设置为TYPICAL或者ALL。你可以在Oracle Enterprise Manager或者API和视图中,显示和输出性能收集与调优工具的结果。为了更好地使用这些调优和诊断工具,推荐使用Oracle Enterprise Manager Database Control。1.2.1 自动性能调优特性

Oracle自动性能调优特性包括:

■ Automatic Workload Repository(AWR):为问题侦测和自动调优而设计的收集、处理、维护性能统计的工具。

■ Automatic Database Diagnostic Monitor(ADDM):为可能存在的性能问题对AWR收集的信息进行分析。

■ SQL Tuning Advisor:在不修改任何SQL语句的情况下,快速有效地优化SQL语句。

■ SQL Access Advisor:提供关于物化视图、索引及物化视图日志的建议。

■ End-to-End Application tracing:针对特定的用户、服务和应用程序组件,识别过度的负载。

■ Server-generated alerts:当有害的问题被侦测到时自动通知。

■ 其他顾问:能够在Oracle Enterprise Manager中使用的一些其他顾问。例如,用于优化实例内存的一些顾问,这些内存顾问通常在数据库没有启用自动内存管理时使用。还有一些顾问用于优化平均恢复时间(Mean Time To Recovery,MTTR)、段的收缩、undo的设置。如果想学习Oracle Enterprise Manager中使用的顾问,可以参考Oracle Database 2 Day+Performance Tuning Guide。

■ Oracle Enterprise Manager中的数据库性能页面:显示实时监控和诊断的主机与实例服务的时间以及吞吐量。此页面可以根据选择的时间周期刷新或者手工进行刷新。如果想学习该页面的使用方法,可以参考Oracle Database 2 Day+Performance Tuning Guide。1.2.2 其他Oracle数据库工具

这节描述可以用于数据库问题诊断的其他工具。

V$性能视图

V$性能视图是所有Oracle性能优化工具所使用的信息源。V$视图是基于实例启动时初始化内存结构的。内存结构以及代表它们的视图,在实例整个生命周期中由Oracle数据库自动进行维护。关于利用V$性能视图进行性能问题诊断的相关信息,请参考第7章中的“使用性能视图进行实例调优”。

注意:Oracle推荐使用AWR收集性能数据,它已经被设计为收集所有性能分析需要的数据的工具。第2部分性能优化的通用方法总的来说,从好的程序设计开始,并且使用统计信息监控应用程序的性能,可以提高Oracle数据库性能。这部分介绍了提高Oracle性能的通用方法和对应急性能问题的处理方法。第2章 性能优化的通用方法

这章讨论Oracle性能提升的方法,包含以下内容:

■ Oracle性能提升方法。

■ 紧急情况下的性能提升方法。2.1 Oracle性能提升方法

Oracle性能方法论帮助你在Oracle数据库中识别性能问题,包括识别瓶颈和修复它们。建议只有在已经确认存在一个瓶颈时才可以做出相应的改变。

性能提升是一个迭代的过程。因为解决掉一个瓶颈可能不会立即让性能得到提升,可能会发现另一个瓶颈。另外,在一些情况下,如果串行点移动到另一个更低效的组件那里,那么性能甚至会降低。

性能问题一般表现为吞吐量不足,或者用户/任务的响应时间不可接受,或者二者兼具。而问题可能位于应用程序模块之中或者存在于整个系统中。在查看任何数据库或者操作系统统计信息前,得到系统最重要的用户反馈是最重要的。这里的“最重要的用户”是指系统用户或者最终为应用程序付费的人。典型的用户反馈可能包括下面这些话:“在线系统太慢了,以至于它让我的员工根本无法工作。”“账单的产生实在太慢了。”“当我面对巨大的网络流量时,响应时间不能接受,我丢失了客户。”“现在我们一天会完成500笔生意,系统已经用到最大限度了,下个月会让所有用户开始使用我们的产品,用户量会增加到4倍。”

……

从这些坦率的反馈中,很容易看出用户认为什么才是决定性能的最重要指标。确定好这个性能指标和终止调优过程的标准,可以让性能过程的管理更简单,而且在每个层面上都更成功。

这些重要的性能指标最好以真实的业务目标来定义,而不是以系统的统计数据来定义。

对于真实的业务目标,以典型的用户语言来说可能是:

账单系统必须在3小时内可以处理100万个账户。

在网站峰值期间,刷新一个页面一定不要超过5秒。

系统必须能够在8小时内处理25000笔生意。

终极的成功是用户对系统性能的认可。性能工程师的角色就是要消除任何让性能降低的瓶颈,这些瓶颈可能是由于低效地使用了有限的共享资源或者滥用了共享资源引起的,这引起了串行化。由于共享资源是有限的,性能工程师的目标就是要高效地使用共享资源,并使系统可以处理的业务量达到最大化。在一个很高的层面上,整个数据库就是一个共享的资源。相应的,在较低层次上,一个CPU或者一个磁盘也可以被看成一个共享的资源。

你可以不断循环地使用Oracle性能提升方法,直到达到性能目标,或者确认目标根本不可能达到。这个过程是高度迭代的。有时,某些调查对改善系统性能可能只有很小的帮助或者根本没有任何帮助。要想能够精准、快速地发现系统最严重的瓶颈,时间和经验都是必要的。但是,对于某些有经验的性能工程师来说,经验优先的原则可能导致他们忽略一些有价值的数据和统计结果。这类行为更倾向于通过神话和传说来调优。这是非常危险的、昂贵的、不会成功的数据库调优方法。

自动化数据库诊断监视器(ADDM)使用一些性能提升方法,并为主要的性能问题的自动诊断提供分析和统计功能。使用ADDM,能大幅缩短提升系统性能所需要的时间。对于ADDM的描述,请参考第7章中的“自动化的性能诊断”。

系统是如此的不同和复杂,以至于找到有力且快速的规则是不可能的。本质上,Oracle性能提升方法只是定义了一个工作方向,而不是一堆最终的规则。最棒的性能工程师会利用系统提供的数据和灵活的思考来确定每个具体的性能问题。2.1.1 Oracle性能提升方法的步骤(1)做如下常规检查。

①从用户那里得到坦率的反馈。确定性能项目的工作范围,以及后续的性能目标。这个过程对将来做性能计划是非常关键的。

②得到系统中的操作系统、数据库和应用程序在性能良好和性能糟糕时的完整的统计信息。如果不能全部得到,那就尽量得到可以得到的统计信息。丢失统计信息就像在犯罪现场丢失证据一样,这使得侦测工作更难、更耗时。

③检查所有与用户性能相关的计算机的操作系统。通过检查操作系统,可以找到那些被耗尽的硬件资源和系统资源。请列出任何被过度使用的资源以作为症状,等待今后的进一步分析。另外,检查所有硬件是否都没有报错信息。(2)在当前系统中检查Oracle常见的10大错误,如果发现问题就将其列出来作为今后分析的症状。这是因为它们是最可能出现的问题。OracleADDM可以对这10个问题中的9个进行自动报告。请看第7章中的“自动化的性能诊断”,以及本章中的“Oracle系统中最常发生的10大错误”。(3)使用症状作为线索建立一个模型,用以模拟系统中正在发生的事情,以此来了解是什么原因导致了性能问题。请看本章中的“性能概念建模的决策过程”。(4)准备一系列补救措施,并对措施的效果进行预估,然后将这些措施以对系统最适合的顺序应用于系统。ADDM的每个建议都带有相应的效果说明。在性能工作中一个黄金定律就是一次只改变一件事情,然后测试改变前后的区别。然而,遗憾的是,系统宕机时间必须越短越好,这不允许进行特别缜密的调查。所以,如果不得不同时实施多个改变,那么试着确保它们是相互隔离互不影响的,以便于独立验证每个改变的效果。(5)确认实施的改变是否已经产生了期望的效果,并且看看用户的接受程度是否提高。如果效果不佳,就得找到更多的瓶颈,并且不断地完善模型,直到你对应用程序的理解变得更精确。(6)重复后3步,直到性能目标被达到,或者由于一些其他的限制达到性能目标变得不可能。

这个方法可以识别最大的瓶颈,其焦点在于通过提高应用程序的效率和消除资源的短缺,让性能大幅提升。在这个过程中,估计只能从针对实例的调整中得到很少的性能提升(小于10%),而巨大的性能提升则来自于针对低效的应用程序的调整。2.1.2 性能概念建模的决策过程

概念建模完全就是一个做决定的过程。但是,随着你获得的调优经验越来越多,你就可能开始庆幸没有真正已经存在的规则必须被遵守。在解释统计信息和做出正确决定的过程中,主观的拍脑袋的方法是必需的。

一个既快又简单的性能调优方法就是使用ADDM。ADDM自动监控Oracle系统,并且为解决性能问题提供建议。例如,假设一个DBA接到一个用户的电话,抱怨系统太慢。这个DBA可以很简单地查看一下ADDM报告,看看有什么建议应该被实施来解决这个问题。请参考第7章中的“自动化的性能诊断”。

下面的步骤描述了一个性能工程师如何能够不使用自动诊断特性而找到瓶颈。这些步骤只作为手工过程的指导。根据经验,性能工程师可以自己增加一些步骤。这个分析假设操作系统和数据库的统计信息已经收集好了。(1)单个用户在空闲系统或者轻负载系统上的响应时间/批处理时间是否可以接受?

如果不可接受,那么可能应用程序根本就没有进行编码或者设计优化,多用户在分享资源条件下的性能就更不可能被接受了。在这种情况下,需要进一步获取应用程序内部统计数据,还要获取SQL Trace和SQL计划的信息。这需要和开发人员一起调查数据、索引、SQL事务设计、潜在的批处理,以及后台进程工作延迟方面的问题。(2)CPU资源被完全使用了吗?

如果内核使用率超过40%,那么就需要调查操作系统的网络传输、页面调度、交换内存或者进程抖动。还要继续检查用户模式下的CPU使用率,查看是否有任何非数据库任务正在消耗共享的CPU资源,例如备份、文件传输、打印队列等。在确认数据库确实正在使用最多的CPU资源之后,接着需要调查以CPU使用率排序的前几个SQL,这些语句是将来分析的基础。检查这些SQL和提交这些SQL的执行情况。Oracle数据库在V$SQL 和V$SQLSTATS中提供SQL统计数据。

对于V$SQL 和V$SQLSTATS,可以从Oracle Database Reference获取更多信息。

如果应用程序已经优化过,并且也不存在低效的SQL,那么可以考虑重新规划工作时间表,尽量将负载分散,而不要集中在很短的时间内,或者使用更强大的计算机。(3)有一种情况是,系统性能并不令人满意,但是CPU资源并没有被完全使用。

这种情况意味着,在服务器内有串行行为和不可延展的行为发生。从服务器获取WAIT_EVENTS统计数据,并且判断最大的串行点。如果没有串行点,那么问题可能位于数据库之外,并且这应该就是调查的焦点。消除WAIT_EVENTS的过程可能会包括修改应用程序的SQL和调整数据库参数。这个过程是迭代的,并且要求对等待事件有系统且深入的了解,才能消除串行点。2.1.3 Oracle系统中最常发生的十大错误

本节列出了在Oracle系统中最常发生的十大错误。通过Oracle性能提升方法论,应该能够避免所有的这些错误。如果在系统里发现了这些错误,那么就需要重新设计系统。请参考第1章中的“自动性能调优特性”来帮助诊断和调整数据库。关于等待事件如何帮助揭示系统性能问题的症状,请参考第7章中的“使用性能视图进行实例调优”。(1)糟糕的连接管理。

在每次数据交互中,应用程序都要连接和断开连接。这在无状态的应用服务器中间件上很常见。这个问题对性能有特别大的影响,而且完全不可延展。(2)游标和共享池的使用很差劲。

不使用游标会导致重复解析。如果没有使用绑定变量,就要对所有的SQL语句进行硬解析。这个问题对性能有巨大的影响,而且完全不可延展。请使用带有绑定变量的游标,打开它,并且多次执行。由应用程序生成的动态SQL是值得怀疑的。(3)糟糕的SQL。

糟糕的SQL,相对于它所完成的任务而言,它消耗了过多的资源。这可能是一个决策支持系统(DDS)中的查询,它可能运行了超过24小时,也可能是一个运行超过1分钟的来自OLTP系统的查询。为了潜在的提升,你应该调查那些消耗了大量系统资源的查询。ADDM可以用于识别高负载SQL,SQL调优顾问也能提供提升建议。关于这些信息,请看第7章中的“自动化的性能诊断”和第11章中的“SQL调优顾问:针对SQL语句改善执行计划”。(4)使用非标准的初始化参数。

这些非标准的初始化参数可能由于糟糕的建议和错误的假设而被使用。大部分提供可接受性能的数据库只使用基本参数集。特别是在非标准参数中关于分配器的SPIN_COUNT参数和未被文档化的优化器参数,使用它们可能会带来非常多的问题。

另外,在初始化参数文件中设置的优化参数是可以覆盖执行计划中的相关内容的,这些参数的优先级更高。因为这些原因,模式、模式统计及优化器设置应该作为一个组来管理,以确保一致的性能。(5)数据库I/O错误。

有些网站在布局数据库时对于可用磁盘的使用方式很不合理,还有一些网站则指定了不正确的磁盘数,因为他们根据空间来配置磁盘而不是根据I/O带宽。有关磁盘的配置,请看第4章中的“I/O的配置和设计”。(6)在线重做日志配置问题。

有些网站的重做日志文件太少了,而且日志文件本身又很小,太小的日志文件导致系统检查点不断地向缓冲区和I/O系统施以高压。如果重做日志文件太少,归档就坚持不住了,数据库必须等待归档跟上来。对于指定重做日志文件大小的相关信息,请看第5章中的“指定重做日志文件的大小”。(7)由于自由列表(free list)或事物槽(INITRANS)的短缺,或者回滚段的短缺,数据块在缓存区(buffer cache)中被串行化。

这在带有大量INSERT操作、数据块大于8KB或者那些具有大量活动用户而回滚段很少的应用程序上很常见。使用自动段空间管理(Automatic Segment-Space Management,ASSM)和自动撤销管理可以解决这个问题。(8)长的全表扫描。

对于大量的或者交互的在线操作来说,长的全表扫描可能意味着较差的事务设计、丢失了一些索引或者较差的SQL优化。长表扫描肯定会加重I/O,并且是不可延展的。(9)大量的递归SQL(sys)。

大量的由sys执行的递归SQL,可能表示正在发生空间管理活动(例如扩展的分配),这是不可延展的,并且影响用户的响应时间。可以使用本地管理表空间来减少分配扩展造成的递归SQL。在其他用户ID下执行的递归SQL,可能是SQL或者PL/SQL本身就要求写成递归SQL造成的,这不是问题。(10)部署和迁移错误。

很多时候,应用程序之所以使用了太多的资源,是因为拥有这些表的模式(schema)没有从开发环境或者之前的实施系统中被成功地迁移,比如说丢失的索引和不正确的统计数据。这些错误可能会导致低效的执行计划和糟糕的交互用户的性能体验。当迁移一个已知性能的应用程序时,使用DBMS_STATS包导出模式统计信息以维护执行计划的稳定性。

虽然这些错误不能由ADDM直接侦测到,但ADDM会挑拣出那些造成高负载的SQL语句。2.2 紧急情况下的性能提升方法

这节提供处理紧急的性能问题的技术。你大概已经具备了建立和提升性能的方法论。但是,在紧急情况下,如果系统的组件已经发生变化,从一个可靠的、可预知的系统,变成了一个不可预料的、不满足用户要求的系统。

在这种情况下,性能工程师必须更迅速地确定到底是什么发生了变化,并且要采取合适的行动使服务尽快恢复。很多时候,有必要立即采取行动,而缜密的性能提升步骤是不现实的。

在遇到紧急性能情况时,性能工程师还是必须要收集足够的调试信息,一是为了更好地了解问题的情况;二是为了不让问题再次发生。

这个调试紧急性能问题的方法和本书前面在描述性能提升方法时使用的方法是一样的。但是,由于这个问题的时间很紧迫,所以在各个步骤中都采取了一些捷径。要记住,保留调试过程中所发现的事实的笔记和记录,对今后的分析和采取任何补救措施的判断都是至关重要的。这就类似于医生保留病人的记录以便日后参考一样。

紧急情况下性能提升方法的步骤

紧急性能提升方法的步骤如下。(1)保留性能问题并且收集性能问题的症状。此过程包含如下内容:

用户关于性能问题的反馈。问题在于吞吐量还是响应时间?

从最近可以确定的正常性能之后,什么发生了变化?这个答案能给出问题的线索。在一个条件不断扩大的情况下,想要得到没有偏见的答案是很困难的。但是,可以试着定位一些参考点,例如收集的统计数据或者日志文件,这应该包括问题发生之前和之后的。

还可以使用自动调优特性诊断和监视问题。另外,也可以使用Oracle企业管理器的性能特性来识别顶级SQL和会话。(2)快速查看这个应用系统的所有组件的硬件使用率。检查最高的CPU使用率发生在哪里,检查磁盘和内存的使用,还有所有系统组件的网络性能。这一快速过程可以用于识别到底是哪层引起的问题。如果问题发生在应用程序上,那么就把分析转向应用程序,否则就转向数据库进行分析。(3)确定数据库服务器是否在CPU上被限制住了,或者是否在等待事件上消耗了大量时间。如果数据库服务器是被CPU限制住了,那么调查下面这些情况:

■ 在操作系统和数据库级别消耗大量CPU的会话。对于数据库使用CPU的情况可以查看V$SESS_TIME_MODEL。

■ 在数据库层面做很多缓冲获取动作的会话和语句。查看V$SESSTAT 和V$SQLSTATS。

■ 执行计划改变引起的低效SQL执行。尽管这些可能比较难定位。

■ 不正确的初始化参数设置。

■ 由于组件代码的改变或升级引起的算法改变。

如果数据库正在等待一些事件,那么可以根据V$SESSION_WAIT来确定是什么引起了串行。V$ACTIVE_SESSION_HISTORY视图包含一些历史会话活动的采样,即使在事故已经结束而系统已经恢复正常操作之后,你还是可以用它来做诊断。在有大量的库缓存争用的情况下,可能根本无法登录或者向数据库提交SQL。这时,可以用历史数据来确定为什么会在这些闩锁上突然发生争用。如果大量等待是关于I/O的,那么可以查看V$ACTIVE_SESSION_HISTORY,以此来确定那些正在做输入和输出操作的会话所运行的SQL。对于等待事件的讨论,请参考第7章中的“使用性能视图进行实例调优”。(4)实施紧急动作让系统稳定。这可能包括让部分应用程序下线或者限制负载,还可能包括重启系统或者终止正在运行的任务。这些当然会有服务层面的损害。(5)确认系统是稳定的。在已经对系统做了一些改变和限制之后,需要确认系统现在已经是稳定的了,同时收集一系列可参考的数据库统计数据。按照本书前面所描述的缜密的性能方法,恢复所有功能并让用户回到系统中。在完成前,可能需要重建应用程序。第3部分性能优化三件事之一:设计者如何优化设计和开发应用程序的性能问题不是突然产生的,如同程序中的功能问题经常与设计和开发紧密相关一样,性能问题在最初也经常产生于设计和开发中。第3章 性能优化从设计和开发开始

优化系统性能应该从最初的设计开始,并一直贯穿于系统的整个生命周期。在最初设计阶段应该仔细考虑性能问题,以便在上线后更容易地对系统进行优化。3.1 Oracle方法论

Internet在业务中扮演着越来越重要的角色,操作系统变得越来越大、越来越复杂,系统的性能就变得越来越重要了。为了适应这个变化,Oracle基于多年的设计和优化经验产生了一个方法论,这个方法论解释了一些非常简单的活动,它们可以极大地提高系统性能。

不同的性能策略会产生不同的效果,并且具有不同特点的系统(例如事务联机系统和决策支持系统),在调优时会要求不同的性能技巧。本书包含了在设计任何数据库时,管理专家和性能专家都必须关注的一些问题。

在系统被设计好的同时,系统的性能也就被一起设计好了。性能问题不是恰巧发生的。

性能问题通常是资源争用和过度使用的结果。当系统资源被耗尽后,系统性能就不可能再提升到更高的水平。这个新的方法论是建立在数据库合理设计基础上的,它可以用来防止系统发生资源耗尽和宕机的情况。通过消除使用资源时发生的矛盾,系统性能可以延展到业务要求的水平。3.2 理解投资选项

由于CPU、内存和磁盘设备相对廉价,这就产生了一种通过购买更多的系统资源而获得性能提升的诱惑。在很多情况下,新的CPU、内存或者更多的磁盘设备可以立即改善性能。但是通过增加硬件而获得的性能改善都只能让性能问题得到暂时的缓解。随着应用程序的需求和负载不断增加,同样问题可能很快就会再次出现。

而且,在某些情况下,新增加的硬件根本不能提升性能。如果系统设计得很糟糕,即便投入更多的硬件也无济于事。在购买更多的设备之前,首先应该保证应用程序没有使用单线程或者存在串行化问题。从长远来看,依靠提高每个事务使用的物理资源的效率来提升性能才是更加值得的。3.3 理解延展性“延展性”一词在开发环境中被应用于各种语境中。下面将针对设计人员和性能专家对延展性进行解释。

这部分包含三个主题:

■ 什么是延展性。

■ 系统延展性。

■ 阻碍延展性的因素。3.3.1 什么是延展性

延展性是系统的一种能力,它要求伴随着资源使用率的适当增加,系统能够处理更多的负载。换句话说,一个可延展的系统,如果把负载加倍,相应的,系统就会使用加倍的资源。这听起来显而易见,但由于一些系统内部的冲突,使用的资源可能会超过原来的两倍。

由于资源冲突所造成的较差延展性的例子如下:

■ 当用户数量增加时,应用要求大量的并发管理。

■ 增加的锁活动。

■ 增加的数据一致性压力。

■ 增加的操作系统压力。

■ 由于数据量增加,每个事务要求增加数据访问的次数。

■ 糟糕的SQL和索引设计导致返回同样数量的行需要更多的逻辑I/O。

■ 可用性降低,因为数据库对象需要更长的维护时间。

当系统的负载增加时,如果在某个点系统资源被耗尽而不能再提供更多的吞吐量,这时应用程序就会被说成是没有延展性的。这种应用程序会表现出固定不变的吞吐量和糟糕的响应时间。

资源耗尽的例子包括:

■ 硬件资源被耗尽。

■ 大量事务的表扫描引起I/O短缺。

■ 过多的网络请求导致网络和调度瓶颈。

■ 内存的不合理分配导致页面被换入/换出。

■ 过多的进程和线程分配导致操作系统超负荷运转。

这意味着应用程序设计人员必须创造出这样一种设计:无论用户和数据量如何上升,对于同样的一个用户,应用程序都使用同样数量的资源(相比于上升前),并且不会让操作系统负载超出它的能力限制。3.3.2 系统延展性

通过Internet来访问的应用程序具有更复杂的性能和可用性需求。即便是传统的后台办公应用,比如一个总账系统,都会要求在线获取部分或者全部数据。而有些应用程序甚至被设计成只能应用于Internet。

Internet时代应用程序的特点如下:

■ 一天24小时、一年365天的可用性。

■ 不可预期且模糊的并发用户数。

■ 很难做出性能计划。

■ 各种类型查询的可用性。

■ 多层结构。

■ 无状态的中间件。

■ 快速开发的时间标准。

■ 最少的测试时间。

图3-1给出了典型的负载增长曲线。图3-1 典型的负载增长曲线

应用程序受到非常短的时间表和非常有限的测试评估时间的挑战。同时,糟糕的设计又常常导致系统重新构造和实现。如果你设计的应用程序对于Internet具有已知的架构和实现上的限制,并且实际负载超出了设计的限制,那么失败就不可避免。从商业角度来看,糟糕的性能就意味着丢失客户,例如,如果Web用户不能在7秒内得到响应,那么你的应用程序可能会永远失去用户对它的关注。

如果在最初时恰当地设计和建造了系统,就不会造成现在的下线、重新设计系统并迁移到新系统上的成本。这个教训很简单:在一开始时就应该在头脑中设计和实现具有可延展性的系统。3.3.3 阻碍延展性的因素

当建立应用程序时,设计师和架构师应以完美的系统延展性为目标。这有时被称为线性延展性,也就是系统的吞吐量直接与CPU个数成比例关系。

在现实生活中,由于设计者不能控制的一些因素,导致线性延展性的实现是不可能的。但是,通过硬件组件的增加和CPU技术的发展,应该让应用程序的设计和实现具有尽可能的延展性以满足当前和将来的性能需求。

可能阻碍线性延展性的因素如下。(1)糟糕的程序设计、实现和配置。

应用程序在延展性上具有最大的影响,例如:

■ 糟糕的schema设计引起昂贵的SQL。

■ 糟糕的事务设计引起锁和串行问题。

■ 糟糕的连接管理导致糟糕的响应时间和不稳定的系统。

设计并不是唯一的问题,应用程序的物理实现可能是一个较弱的环节:

■ 系统具有糟糕的I/O策略却被转移到生产环境中。

■ 生产环境可能使用与测试时生成的不同的执行计划。

■ 具有内存密集型倾向的应用程序使用了大量的内存却没有思考如何在运行时释放内存,这导致内存被过度使用。

■ 低效的内存使用和内存溢出导致虚拟内存子系统的压力增加,这影响了性能和可用性。(2)硬件组件的大小不合适。

硬件价格相对较低,硬件的缺乏很少成为问题。但是当系统负载增加时,强大的硬件能力可能掩盖延展性问题。(3)软件组件的限制。

所有的软件组件都具有资源和延展性的限制,对于应用服务器、数据库服务器和操作系统都是如此。应用程序的设计不应在软件组件上期望超过其掌控能力的需求。(4)硬件组件的限制。

硬件的延展性并不完美,大多数多处理器计算机能够在使用有限的几个CPU时基本达到线性延展性。但是,在某个点以后,增加的CPU还是会提升整体的性能,但不再是成比例的。3.4 系统架构

本节主要包括两个部分:

■ 硬件和软件组件。

■ 为需求配置匹配的系统架构。3.4.1 硬件和软件组件

这部分讨论:

■ 硬件组件。

■ 软件组件。

3.4.1.1 硬件组件

当今的设计师和架构师需要负责多层结构中每层的大小和性能设计,而架构师对于获得一个平衡的设计负有责任。这和一个桥梁设计师类似,他无须考虑桥梁的所有负载和结构需求,因为桥梁的强壮性取决于它最脆弱的组件。因此,桥梁会采取均衡的设计,这样所有组件都可以同时达到其限制。

主要的硬件组件包括:

■ CPU

■ 内存

■ I/O子系统

■ 网络

1.CPU

系统可以有一个或者多个CPU,可以是简单的手持设备上的CPU,也可以是高性能服务器上的CPU。请参考第4章中的“管理操作系统资源”。

2.内存

数据库和应用服务器要求使用相当数量的内存用于缓冲数据以避免耗时的磁盘访问。请参考第4章中的“配置和使用内存”。

3.I/O子系统

I/O子系统,可以是PC上的大磁盘,也可以是高性能磁盘阵列。磁盘阵列每秒可以完成数千次I/O访问。它可以通过多I/O路径冗余提供可用性,并且可以热插拔镜像磁盘。请参考第4章中的“I/O的配置和设计”。

4.网络

系统中的所有计算机都要连接到网络上,可以使用Modem,也可以是高速的内部局域网。这里主要关心的是带宽和网速。

软件组件

通过把软件开发任务分解到不同的功能组件上,可能能够更好地理解应用程序的设计和架构。

软件与硬件的区别在于:硬件只能执行一种任务,而一套软件则可以扮演各种组件的角色。例如,磁盘设备只能用于存储和抽取数据,而客户端程序既可以管理用户界面,又可以完成业务逻辑。

很多应用程序都包含下列组件:

■ 管理用户界面。

■ 实现业务逻辑。

■ 管理用户请求和资源分配。

■ 管理数据和事务。

1.管理用户界面

对用户来说这个组件更可见,通常包括:

■ 将数据显示在用户的屏幕上。

■ 收集用户数据,并将其转移到业务逻辑。

■ 验证输入数据的有效性。

■ 在应用程序的不同层次和状态间跳转。

2.实现业务逻辑

这个组件实现应用程序核心的业务逻辑。如果在这个组件上犯错误将会带来很高的成本。这个组件需要通过一些声明和程序来实现,一个声明的例子就是创建唯一键和外键;而实现一个给商品打折的策略,则是实现一个业务逻辑的例子。

这个组件的常见功能包括:

■ 将数据模型转换到相关的表结构。

■ 在相关的表结构上定义约束。

■ 编码以实现业务逻辑。

3.管理用户请求和资源分配

这个组件在所有软件中都要被实现。

对于多层应用程序,分配用户所申请的资源由数据库或者操作系统来完成。但是,对于一个巨大的应用程序来说,用户数量和使用模式可能是未知的,而用户数量还可能是快速增长的,系统架构必须可以保证不会有任何软件组件过载或者不稳定。

这个组件的常见功能包括:

■ 与数据库的连接管理。

■ 高效地执行SQL(游标和SQL共享)。

■ 管理客户端状态信息。

■ 在整体硬件资源上平衡用户请求带来的负载。

■ 设置可操作的硬件和软件组件目标。

■ 管理与异步执行任务相关的队列。

4.管理数据和事务

这个组件涉及数据库服务器和操作系统最大的职责。

其常见功能包括:

■ 使用事务和锁对数据实现并发访问。

■ 使用索引和内存缓冲对数据进行优化访问。

■ 当硬件失败时,确保变化的数据已经被记录到日志中。

■ 执行在数据上定义的所有规则。3.4.2 为需求配置匹配的系统架构

配置初始的系统架构是一个巨大的迭代过程,系统架构师必须在预算和计划阶段提出满足系统需求的架构。如果系统要求基于数据库内容的用户交互事务,那么会以用户需求驱动架构;如果在系统中只有很少的交互用户,那么架构则是过程驱动的。

一些具有交互用户的应用程序的例子如下:

■ 记账和管账的应用程序

■ 订单输入系统

■ 邮件服务器

■ 基于Web的零售应用程序

■ 贸易系统

一些过程驱动的应用程序的例子如下:

■ 次品监测系统

■ 直邮广告系统

过程驱动的应用程序的设计比多用户应用程序的设计要简单些,因为没有用户界面元素。但是,由于目标是面向过程的,不习惯处理大数据量的系统架构师会变得混乱。设计过程驱动的应用程序既需要基于用户的应用程序的设计技巧,也需要数据仓库的设计技巧。本书仅仅聚焦于以交互用户驱动的架构设计。

注意:产生一个系统架构不是一个简单的做决定的过程,它要求仔细考虑业务需求、技术选择、已存在的结构和系统以及实际的物理资源,例如预算和人力。

下面的问题在系统架构中应该予以考虑,虽然它们不是指导系统架构设计的最终定义。这些问题描述了业务需求是如何影响架构的,以及实现的简单性、系统整体的性能及可用性。例如:(1)系统必须支持多少用户?

大多数应用程序可以归为以下类别之一:

■ 很少用户,很少使用,或者只有一台专用计算机。

对于这类应用程序,常常只有一个用户在使用系统,设计的焦点应集中在通过提供最好的响应时间使单个用户尽可能地得到最大产出。这种应用程序所需要的管理是最少的,因为这类应用程序的用户很少相互干扰,并具有最小的资源冲突。

■ 中等数量的用户使用大家共享的应用程序。

对于这种应用程序,用户数量实际受到团体内成员所做的业务数量的限制,因此,用户数是可预期的。对于这样的应用程序,稳定的服务对于业务来说是非常重要的。由于这些用户必须共享一些资源,设计的重点要放在系统重压下的响应时间、每个会话资源的扩大,以及将来增长的空间上。

■ 无限数量的用户分布在Internet上。

对于这种应用程序,额外的工作量是要确保没有系统组件超出它的设计限制;否则就会造成瓶颈,让系统停下来或者不稳定。这种应用程序要求复杂的负载平衡、无状态的应用服务器以及高效的数据库连接管理。另外,如果数据库由于过载不能满足用户的请求,还要使用统计和调节器来确保用户收到相应的反馈。(2)用户的交互方法是什么?

用户界面可以是一个简单的Web浏览器,也可以是一个定制的客户端程序。(3)用户位于哪里?

对于局域网的用户和公网的用户而言,要获得同样的100Mbps带宽,就需要采用不同的方式架设网络。位置也影响到一天当中哪个时段最忙,哪个时段不应该做批处理的系统维护工作。(4)网络速度怎么样?

网速影响到数据量,也影响到用户界面的特点。一个高级的用户界面可以与后端服务器在每个关键动作和字段的验证上进行交流,而较为简单的界面只能完成简单的信息显示。在一个慢速的网络中,是不可能获得大量数据的。(5)用户会访问多少数据?最多有多少数据是只读访问的?

在线请求的数据影响到设计的每个方面,包括从表和索引的设计到表现层。设计必须努力确保用户的响应时间不是数据大小的函数。如果应用程序有大量的只读数据,那么可以将这些数据复制和分布到应用服务器本地,这减少了核心事务服务器的压力。(6)用户对响应时间的要求是怎样的?

考虑用户的类型是很重要的。如果用户是一个执行人,他可能会请求精确的数据来做一个快速的决策,那么用户的响应时间就不能被折中。而对于其他类型的用户,比如做输入动作的用户,就不需要这么好的性能。(7)用户希望24小时的服务吗?

对于现在的Internet上的应用程序来说,这是必需的,业务一天24小时都在进行。但是运行于单个时区的公司的系统,可能可以忍受几个小时的停工时间。你可以用这几个小时的停工时间做一些批处理或者管理任务。在这种情况下,运行一个非全天候的系统可能更经济。(8)所有的变化必须是实时的吗?

实时很重要,它决定了事务是必须在用户的响应时间内被运行,还是可以用排队的方式来异步执行。

下面要考虑的问题也影响了设计,但更多的是影响了预算,还有实现的难易程度。(1)数据库会有多大?

这影响到数据库服务器的大小。对于一个拥有巨大数据库的服务器来说,可能拥有一个比负载要求的更强大的计算机是必要的。这是因为,对于一个大数据库来说,管理的开销大都是数据库大小的函数。随着表和索引的增长,为了让表的重新组织和索引的建立在可接受的时间内完成,相应地需要消耗更多的CPU资源。(2)业务事务需要多少吞吐量?(3)可用性的需求如何?(4)具备建立和管理这个应用程序的技巧吗?(5)因为预算的限制会进行怎样的折中?3.5 应用程序设计原理

本节介绍如下这些与设计相关的内容:

■ 简单的应用程序设计。

■ 数据建模。

■ 表和索引设计。

■ 使用视图。

■ SQL执行效率。

■ 应用程序的实现。

■ 应用程序开发的趋势。3.5.1 简单的应用程序设计

应用程序与其他任何经过设计和工程化的产品没什么区别。设计精良的机械、计算机和工具,通常稳定、易于使用和维护且概念简单。一般来说,如果设计看上去是正确的,那么它可能就是正确的。当建立应用程序时,应该始终在头脑中保持这个概念。

考虑下面的设计问题:

■ 如果表的设计非常复杂,以至于没有人能完全理解它,那么这很可能是一个糟糕的设计。

■ 如果SQL语句又长又难懂,以至于使用任何优化器都没法实时优化它,那么有可能这是一个差劲的SQL语句、含混不清的事务或者表的设计。

■ 如果有些列被重复索引,那么这可能是一个糟糕的索引设计。

■ 如果为了加快用户的响应时间,一个不合格的查询被提交了,那么可能存在一个较差的用户界面或者事务设计。

■ 如果对数据库的调用是经由很多层软件从应用程序的逻辑抽象而来的,那么有可能暗示着一个糟糕的软件开发方法。3.5.2 数据建模

对于成功的应用程序设计来说,数据建模是很重要的,必须以一种可以代表业务实际情况的方式来建模。对于正确的数据模型可能会发生激烈的辩论,但无论如何,最重要的是要把最多的精力放在那些被最频繁的业务事务所影响的实体上。在建模阶段,一个很大的诱惑是花太多时间为非核心数据建模,这将导致建模时间的增加。使用建模工具可以加速模式定义的产生,并且在要求快速产生一个原型时是很有用的。3.5.3 表和索引设计

表的设计需要在核心事务的灵活性和性能之间进行折中。为了既保持表的灵活性,又可以满足不可预见的压力,表的设计应该非常近似于数据模型,并且至少应该模式化到第三范式。但是,用户实际业务需要的某种事务可能因为性能问题,要求非模式化。

这一技术的例子包括:存储预连接表、额外的推断列和聚合值。Oracle利用簇和物化视图提供很多选项来存储聚合值和预连接数据。这些特性允许采纳一个非模式化的表的设计。

另外,应该将精力和资源放在核心业务表上,以获得最佳性能。对于非核心表,为了加快应用程序的开发速度,可以采用一些快捷的方法。但是,如果在原型和测试中非核心表造成了一个性能问题,那么就应该立即开始设计的补救。

基于设计者提出的SQL,索引设计大都是一个迭代过程。但是也可以有一个明智的开始,例如:建立主键约束索引;在已知的访问模式上(例如,在人名上)建立索引。当应用程序要求时,或者已经以真实的数据量做过测试之后,你可能需要构建更好的索引来提高某个特定查询的性能。当建立索引时,可以考虑以下这些建议:

■ 为索引添加更多的列或者使用索引组织表。

■ 使用不同的索引类型。

■ 找到索引的代价。

■ 索引的串行。

■ 在索引中对列排序。

3.5.3.1 为索引添加更多的列或者使用索引组织表

加快查询速度的最简单方法之一就是从执行计划中消除对表的访问来减少逻辑IO。这可以通过将查询涉及的所有列都添加到索引中来实现。这些列可以是查询的可选列的列表,或者任何需要连接和排序的列。这种技术对于加快在线应用程序的响应时间尤其有用,它减少了IO的耗时。当使用合适的数据量测试后,首先就该使用这种技术。

最极致地使用这种技术的形式就是建立索引组织表(IOT)。但是应该小心,这种技术会让叶子节点的大小增加,这意味着索引上的IO会有所增加。使用这种技术时需要考虑表的IO减少和索引IO增加后,总的IO是否真的减少了。

3.5.3.2 使用不同的索引类型

Oracle提供了很多可用的索引类型,并且每种类型都在某种特定的情形下有一定的优势。下面给出了每种类型的性能特性。

1.B-Tree索引

这是标准的索引类型。这种索引对于主键和高选择性索引来说很棒。当作为级联索引来使用时,数据库可以使用B-Tree索引抽取那些被索引列排过序的数据。

2.位图(Bitmap)索引

这种索引适合于低基数的数据。通过压缩基数,只使用很少的I/O就可以生成大量的行ID(RowID)。在一些选择性不高的列上使用位图索引,可以以最少的I/O得到大量的被and和or操作的行ID。位图索引对于带有count()的查询尤其有效,因为查询可以在索引内部得到回答。

3.基于函数(Function-based)的索引

这种索引允许通过B-Tree索引访问一个值,这个值是从基础数据的一个函数推断而来的。基于函数的索引在使用null时有些限制。另外,要想使用它就要启用查询优化器。

如果需要在一个推断的结果上进行查询,或者查询需要克服数据存储方式上的限制,这时,基于函数的索引是很有用的,例如:可以使用upper()函数实现大小写不敏感的查询。

4.分区索引

将全局索引分区,允许在索引访问中发生分区修剪,这会使I/O减少。如果可以定义一个恰当的分区列表,那么对索引分区进行的快速索引扫描就会得到非常快的响应。

5.翻转索引

当INSERT操作很频繁时会产生索引热点,这种索引可以用来消除索引热点,它的插入性能非常优秀。但是这种索引也有限制,数据库不能用它来做索引范围扫描。

3.5.3.3 找到索引的代价

建立和维护索引可能代价很高,并且需要消耗资源,例如磁盘空间、CPU,还有I/O,设计师必须确保使用索引得到的好处相对于维护它所付出的代价是值得的。

使用这个简单的方法来估计维护索引的代价:在索引关键字上的每个INSERT、UPDATE、DELETE操作所耗费的资源相当于表上同样的DML操作所消耗资源的3倍。这样,当你在一个有3个索引的表上进行一次INSERT操作时,这个操作要比插入到没有索引的表中慢大约10倍。对于DML,尤其是对于插入较多的应用程序,索引的设计应该被认真地复审,这可能会要求在插入和查询之间进行一些折中。

3.5.3.4 索引内的串行

如果采取序列或者时间戳生成索引值,那么索引本身就可能引起数据库热点问题,它会导致性能和吞吐量下降。这通常是一个纯增长关键字的问题,它导致一个向右增长的索引。为了避免这个问题,应该试着在整个索引范围内插入索引键。这会得到一个更好的索引,它更具备延展性,空间的利用率更好。你可以使用翻转索引或者对索引的前缀和序列值使用循环序列来获得这个效果。

3.5.3.5 在索引中对列排序

设计师在为建立索引定义规则时应该是灵活的。基于实际情况,使用下面两种方法之一在索引中对关键字进行排序。

■ 按照选择性排序,选择性最好的排在最前面。这个方法最常用,因为对于被请求的行ID,可以用最少的I/O提供最快的访问。这种技术主要用于主键和选择性很高的范围扫描。

■ 通过簇来对列进行排序以减少 I/O 或者对数据进行排序。在大范围扫描中,以最小选择性对列进行排序,通常可以减少 I/O 次数;或者,就以将来抽取数据时会使用的排列顺序对列进行排序。3.5.4 使用视图

视图能够加速并且简化应用程序的设计。一个简单的视图的定义可以掩盖数据模型的复杂性,使程序员更注重数据的抽取、显示、收集和存储。

但是,视图在提供清晰的程序接口的同时,也会导致次优化和资源密集型的查询。最不该使用视图的情况就是当一个视图参考了其他视图,并且在查询中它们被连接在一起时,在这种情况下开发人员最

试读结束[说明:试读内容隐藏了图片]

下载完整电子书


相关推荐

最新文章


© 2020 txtepub下载