SQL的另一种思维.doc

　一、性能调整综述 　　二、有效的应用设计 　　三、SQL语句处理的过程 　　四、ORACLE的优化器 　　五、ORACLE的执行计划 　　　　背景知识 　　　　访问路径(方法) -- access path 　　　　表之间的连接 　　　　如何产生执行计划 　　　　如何分析执行计划 　　　　如何干预执行计划 - - 使用hints提示 　　　　具体测试实例 　　　　具体案例分析 　　六、其它注意事项 　　七、整体实例分析 　　　　客户端程序优化SQL步骤 　　　　tkprof程序整体实例解说优化SQL的另一种思维1 性能调整综述【IT专家网独家】Oracle数据库是高度可调的数据库产品。本章描述调整的过程和哪些人员应与Oracle服务器的调整有关，以及与调整相关联的操作系统硬件和软件。本章包括以下方面: 　　 谁来调整系统? 　　 什么时候调整? 　　 建立有效调整的目标 　　 在设计和开发时的调整 　　 调整产品系统 　　 监控产品系统 　　谁来调整系统: 　　为了有效地调整系统，若干类人员必须交换信息并牵涉到系统调整中，例如: 　　 应用设计人员必须传达应用系统的设计，使得每个人都清楚应用中的数据流动. 　　 应用开发人员必须传达他们选择的实现策略，使得语句调整的过程中能快速、容易地识别有问题的应用模块和可疑的SQL语句. 　　 数据库管理人员必须仔细地监控系统活动并提供它们的资料，使得异常的系统性能可被快速得识别和纠正. 　　 硬件/软件管理人员必须传达系统的硬件、软件配置并提供它们的资料，使得相关人员能有效地设计和管理系统。 优化SQL的另一种思维系列文章是作者用了快一年的时间完成的SQL优化文章，它的原理实际上是通过分析SQL语句的执行计划来实现对整体SQL进行优化的，这是多年项目经验的总结，由于考虑到目前国内的Oracle部署还基本维持在Oracle 8 和Oracle 9的水平上，所以里面的模拟环境都是在Oracle 8.3下进行的，希望可以针对性更强一些。本文是系列连载的第一章：性能调整综述  　　简而言之，与系统涉及的每个人都在调整过程中起某些作用，当上面提及的那些人员传达了系统的特性并提供了它们的资料，调整就能相对的容易和更快一些。 　　不幸的是，事实上的结果是：数据库管理员对调整负有全部或主要的责任。但是，数据库管理员很少有合适的系统方面的资料，而且，在很多情况下，数据库管理员往往是在实施阶段才介入数据库，这就给调整工作带来许多负面的影响，因为在设计阶段的缺陷是不能通过DBA的调整而得以解决，而设计阶段的缺陷往往对数据库性能造成极大的影响。 　　其实，在真正成熟的开发环境下，开发人员作为纯代码编写人员时，对性能的影响最小，此时大部分的工作应由应用设计人员完成，而且数据库管理员往往在前期的需求管理阶段就介入，为设计人员提供必要的技术支持。 　　调整并不是数据库管理员的专利，相反大部分应该是设计人员和开发人员的工作，这就需要设计人员和开发人员具体必要的数据库知识，这样才能组成一个高效的团队，然而事实上往往并非如此。 　　什么时候作调整? 　　多数人认为当用户感觉性能差时才进行调整，这对调整过程中使用某些最有效的调整策略来说往往是太迟了。此时，如果你不愿意重新设计应用的话，你只能通过重新分配内存(调整SGA)和调整I/O的办法或多或少地提高性能。Oracle提供了许多特性，这些特性只有应用到正确地设计的系统中时才能够很大地提高性能。 　　应用设计人员需要在设计阶段设置应用的性能期望值。然后在设计和开发期间，应用设计人员应考虑哪些Oracle 特性可以对系统有好处，并使用这些特性。 　　通过良好的系统设计，你就可以在应用的生命周期中消除性能调整的代价和挫折。最有效的调整时间是在设计阶段。在设计期间的调整能以最低的代价给你最大的收益。当然，即使在设计很好的系统中，也可能有性能降低。但这些性能降低应该是可控的和可以预见的。 　　调整目标 　　不管你正在设计或维护系统，你应该建立专门的性能目标，它使你知道何时要作调整。如果你试图胡乱地改动初始化参数或SQl 语句，你可能会浪费调整系统的时间，而且无什么大的收益。调整你的系统的最有效方法如下： 　　 当设计系统时考虑性能 　　 调整操作系统的硬件和软件 　　 识别性能瓶颈 　　 确定问题的原因 　　 采取纠正的动作 　　当你设计系统时，制定专门的目标;例如，响应时间小于3秒。当应用不能满足此目标时，识别造成变慢的瓶颈(例如，I/O竞争)，确定原因，采取纠正动作。在开发期间，你应测试应用研究，确定在采取应用之前是否满足设计的性能目标。 　　当你正在维护生产库系统时，有多种快速有效的方法来识别性能瓶颈。 　　不管怎样，调整通常是一系列开销。一旦你已确