现在我们处于信息化时代，日常生活中的每一步都会被记录成为信息的世界。那么保存和管理这些庞大信息的地方在哪里呢？过去我们使用文件记录保存信息，而如今计算机和互联网高度发达，则在数据库中保存和管理信息。企业通过数据库管理和应用大量的信息创造了巨额利润，但有效地管理日益剧增的信息非常困难。企业也因为数据增加和业务的多样化遇到性能问题及相关难处，但幸运的是，有多种方法可以改善正在运行中的数据库的性能。而重中之重仍然是调优访问数据库SQL语句的方法，因为很少能像SQL调优这样可以在短时间内以低成本得到效果。因此，为了性能考虑，开发者应不遗余力地投入时间和精力进行SQL调优。
DBMS性能下降的问题会失去客户的信任，而此类问题无法在几日内得到解决。因此，必须投入大量的时间和金钱才能解决性能问题。数据库性能下降是会给企业带来巨大损失的原因之一。
为什么会发生诸如此类的性能问题呢？性能问题可以由许多因素引起，包括：在构建数据库时，由于以结果为主的构建和时间计算问题，未能构建优化性能的数据库；随着使用发生性能下降的现象，未能优化访问数据库的SQL的情况占多数等。现已知设计不良的数据库会影响性能，但为什么说SQL是降低数据库系统性能的罪魁祸首呢？现在开始介绍SQL降低数据库系统性能的原因以及解决该问题的方法。
未进行优化的SQL性能降低一般有两个原因：不必要的数据块访问增加；资源使用增加。
1）确认不必要的数据块的访问增加
SQL的性能取决于相应SQL访问的数据块的数量。例如，我们从互联网下载文件时，下载1MB大小的文件和下载 100 MB大小的文件时速度有何差别？任何人都知道下载1MB的文件时速度快很多。那么如果要在包含相同内容的1MB大小的文件和100 MB大小的文件中选择一个文件下载，会下载哪个文件呢？当然会下载花费时间较少的1MB大小的文件。数据库性能管理中有些人常会认为包含相同内容的1MB大小的文件是否会与100 MB大小的文件毫无区别。
出于这个原因，我们必须优化 SQL。在大容量数据库中，不只是 1 MB和 100 MB的差别，出现1 MB和10 GB以上差别的情况也很常见。利用查询功能10秒钟就能查询结果，但有时会花费几个小时也是同样的道理。因此是否优化SQL可能会出现访问1MB或访问10 GB的差别。如果访问10 GB，真的能在1s内从数据库中提取到结果吗？这是即使磁盘性能非常好且CPU非常多的最新系统也无法在线使用的SQL语句。此外，如果这样低效的执行SQL语句，不仅是该应用程序，包括在该系统上执行的所有应用程序都会被影响。
2）确认资源使用增加
资源使用增加会呈现多种现象。其中，由于未优化SQL而浪费的资源主要包括：CPU使用；内存使用；磁盘 I/O和空间。(www.chuimin.cn)
查看这些项目就能了解这意味着组成系统的大多数重要资源被浪费。未优化的SQL使CPU使用增加，导致CPU的平均使用率增加。CPU的平均使用率增高意味着什么？大多数企业将CPU使用率作为增设容量的标准值。增设容量指对相应系统增设 CPU、内存等。
那么未优化的SQL和容量增设之间有何关系？如果未优化的SQL较多，相应系统的CPU使用率增高，这种现象会导致CPU的平均使用率增加。在这种情况下，自然要计划增设系统的容量。如此增设容量是否为正确的处理方式？如果对未优化的SQL进行调优，则计划增设容量的许多企业都无须执行容量增设。如果不增设容量可以减少企业用于容量增设的费用，可将此费用用于促进企业发展的其他部分。因此，时常会因为未优化 SQL而导致公司费用的错误使用。
在许多地方仍然没有意识到这个事实，还在试图无条件地增设数据库系统的容量。现在就要准确判断是相应系统上执行的所有SQL已进行优化的前提下还需要增设容量的不可避免的情况，还是未优化SQL却要增设容量的情况。
这与内存使用量有何关系？大量数据排序的SQL或者大量访问数据块的未优化的SQL，可能会过量地使用内存。如果出现这种情况，则肯定会因为内存资源争用而出现性能下降的情况。
很容易因磁盘I/O和空间使用量或未优化的SQL而出现浪费。对于磁盘I/O，如果优化SQL，只需要访问100个数据块就能提取结果。但如果未优化SQL，可能要访问10000个数据块。此时，只优化相应SQL就足以将磁盘I/O减少至1%的水平。
如果有人对出现此类现象的原因有疑问，那肯定是还未充分理解 SQL。如果只提取数据库所需的数据，可通过多种方式访问SQL。在众多提取相同结果的方法中，有些方法要访问100个数据块，而有的方法则可能为提取相同结果而访问10000个数据块。就因为这种现象，才会因未优化的SQL而出现磁盘I/O增加的情况。那么磁盘空间使用又会如何？说到优化SQL，必定会提到索引。SQL的优化过程必然也涉及索引的优化。若未优化索引将出现哪些现象？也许表中会增加不必要的索引。索引是段，构成索引的数据实际上会保存到磁盘中。因此，过多不必要的索引会使磁盘空间使用率增加，造成磁盘空间因不必要的索引而浪费。
如前文所述，未优化的SQL会造成不必要的数据块访问和不必要的资源使用，从而降低性能。那么要如何创建SQL，才能消除此类不必要的数据块访问，并为了有效地使用资源而对SQL进行优化呢？本书随后将逐一介绍。
有关数据库性能管理与调优的文章
1）例子（一）正确使用SQL的例子（一）如图5-12所示。因此B.ORDD = : TrDay或B.ORDD = : WorkDay的扫描范围较窄，使用索引时响应速度非常快。在这种情况下，优化器使用OR从内部分为两个SQL语句并各自使用索引，再将执行结果合并为一个结果。图5-13正确使用SQL的例子（二）问题：连接的两个表的条件中决定扫描范围的条件是"AND SUBSTR LIKE : IN_org_cd AND SUBSTR ＜ 600000"。因此可按以下方法变更条件公式并使用相应索引。......
2023-11-01
通过持续的调优工作和监测可以找到运行中应用程序的最佳值。此时，UNIX内核的内存不易减少，需要有效地调优数据库内存区域，使用更少内存发挥相同水平的性能。如果内核内存使用约100 MB，并发用户为30名，每个Oracle进程的内存为 10 MB，假定 sort_area_size为 1MB，按以下公式计算出430 MB。100 MB+30×=430 MB因此，物理内存为1 GB的系统，可分配大约600 MB的SGA使用。......
2023-11-01
在制定由优化器执行的SQL语句的执行计划过程中，提示为用户提供了可直接进行介入的方法。提示是用户对优化器下达的指示，但优化器可能会忽略不合理的提示。意味着除了RULE和DRIVING_SITE外的所有提示将选择CBO用作优化器。使用Orange Template Browser查看优化器提示如图2-8所示。图2-8Orange Template Browser查看优化器提示单击方框部分图标（）、单击最顶端菜单的［View］—［Template Browser］或按快捷键 Alt+F2则会运行［Template Browser］。......
2023-11-01
统计信息中保存有列选择度、数据量等大量信息，因此基于规则的优化器可以更灵活地创建执行计划。extent是由相关联的数据块构成的逻辑单位。否则，会因表的random access造成表扫描的平均成本增高。排序操作成本并非用于访问对象数据的成本，而是用于排序已提取数据的成本。若使用以特定列为标准排序的索引提取数据时，可以减少额外的排序操作成本。要了解SQL语句实际应访问的对象范围程度才能计算实际成本，这是非常重要的概念。......
2023-11-01
实例已启动意味着数据库系统运行所需的后台进程已启动，并且处于“确保内存可用于数据处理”的状态，这种实例的调优将成为DBMS性能调优的重要基础。1） DBMS 内存 区域——SGASGA 是作为实例启动时确保控制器信息保存和数据处理空间的内存区域，存在于实例访问的所有进程共享的内存区域中。SGA相关调优的基准基本以命中率评价为主，通过适当地调整相关参数，将实际运行反映到评价结果中。......
2023-11-01
图5-14考虑索引生成标准从根本上来说创建索引是为了加快查找速度。但如果创建特定索引，反而会对整体执行性能造成不良影响。因此为确定特定表的索引构成，需要调查访问表的SQL的访问模式，并基于调查结果做出综合性的判断。此外，添加索引时最好计算查找负载量减少和DML负载量增加造成的大致损益。因此生成两个索引对整个系统较为有效。......
2023-11-01
HASH JOIN是突出SORT MERGE JOIN优点并弥补其缺点的连接方法。该连接是对连接的对象表应用 HASH函数进行合并的方法。其特征是不仅只使用 HASH JOIN，而且提供通过并行处理大容量数据的最佳解决方案。但不建议在OLTP等状况下使用，因为HASH JOIN已为大容量处理进行优化，会占用大量系统资源。不会受JOIN条件（链路）索引有无的影响。2）使用标准由于链路使用HASH Key，因此仅用于EQUI-JOIN。在执行计划中成为HASHING对象的表始终在最前面，但如果是OUTER JOIN则完全相反。......
2023-11-01
图1-7磁盘I/O瓶颈现象调查最理想的I/O应用就是所有控制器相应的设备都得以均衡使用。图1-10所示为调查Oracle数据库内文件的I/O的SQL。图1-10调查Oracle数据库内文件通过上述分析结果，可采取的措施包括：将 /oracle上数据文件的一部分移至有其他控制器的挂载点，通过移动 RBS、TEMP、USERS中一两个数据文件使 I/O平衡并分散。该操作非一次性操作，分配一次后要重新进行监测，确定 I/O是否分散均衡。......
2023-11-01
相关推荐