The Library Cache 库缓存
(page 54)
The first thing that must happen to every SQL statement you execute is that it must be parsed and
loaded into the library cache.
The library cache, as mentioned earlier, is the area within the shared pool
that holds previously parsed statements. Parsing involves verifying the statement syntax, validating
objects being referred to, and confirming user privileges on the objects.
If those checks are passed, the
next step is for Oracle to see if that same statement has been executed previously. If it has, then Oracle
will grab the stored information from the previous parse and reuse it. This type of parse is called a soft
parse
. If the statement hasn’t previously been executed, then Oracle will do all the work to develop the
execution plan for the current statement and then store it in the cache for later reuse. This type of parse is called a hard parse
.
你所执行的每条SQL语句,首先发生的事是它被解析然后加载到库缓存。
如前所述,库缓存是在共享池中的一块区域,存放之前解析的语句。解析涉及到验证语句的语法,校验引用的的参数,以及确认用户对对象的权限。
如果这些检查都通过了,下一步Oracle就会看是否之前执行过相同的语句。如果是,Oracle将从之前解析的存储信息中取出并重用它。这种类型的解析称之为“软解析
”。如果语句之前没有执行过,Oracle将会对当前语句开发执行计划然后存储它必备重用。这种类型的解析称之为“硬解析
”。
Hard parses require Oracle to do a lot more work than soft parses. Every time a hard parse occurs,
Oracle must gather all the information it needs before it can actually execute the statement. In order to
get the information it needs, Oracle will execute a bunch of queries against the data dictionary.
The
easiest way to see what Oracle does during a hard parse is to turn on extended SQL tracing, execute a
statement and then review the trace data. Extended SQL tracing captures every action that occurs so not only will you see the statement you execute, but you’ll see every statement that Oracle must execute as well. Since I haven’t covered the details of how tracing works and how to read a trace file, I’m not going to show the detailed trace data. Instead, Table 2-1 provides the list of system tables that were queried during a hard parse of select * from employees where department_id = 60.
硬解析相比软解析需要Oracle做更多的工作。每次硬解析发生,在Oracle实际执行语句之前它必须先收集所有必要的信息。为了获得它需要的信息,Oracle将针对数据字典进行一大串查询。
查看Oracle在硬解析期间做了什么的最简单的方式是开启扩展的SQL tracing(追踪),执行一语句然后检查追踪的数据。扩展的SQL tracing捕获发生的每个动作,这样你不仅能看到你所执行的语句,还将看到Oracle必须执行的每条语句。由于我还没有深入讲解如何追踪以及如何解读追踪文件,我不打算展示详细的追踪文件。(而是直接给出结果),表2-1提供在硬解析select * from employees where department_id = 60期间Oracle所查询的一列系统表。
Table 2-1. System Objects Queried During Hard Parse
Tables #Queries Purpose 目的
access$ 1 Permissions used by a dependent object against its parent依赖对象是否有其父对象的授权
ccol$ 10 Constraint column-specific data 约束列数据
cdef$ 3 Constraint-specific definition data 约束定义数据
col$ 1 Table column-specific data 表列数据
dependency$ 1 Interobject dependencies 对象依赖
hist_head$ 12 Histogram header data 柱状图头信息
histgrm$ 3 Histogram specifications 柱状图规范
icol$ 6 Index columns 索引列
ind$, ind_stats$ 1 Indexes, index statistics 索引列,索引统计
obj$ 8 Objects 对象
objauth$ 2 Table authorizations 表授权
seg$ 7 Mapping of all database segments 映射所有数据库段
syn$ 1 Synonyms 同义词
tab$, tab_stats$ 1 Tables, table statistics 表,表统计
user$ 2 User definitions 用户定义
In total, there were 59 queries against system objects executed during the hard parse. The soft parse
of the same statement did not execute any queries against the system objects since all that work was
done during the initial hard parse. The elapsed time for the hard parse was .060374 seconds while the
elapsed time for the soft was was .000095 seconds. So, as you can see, soft parsing is a much more
desirable alternative to hard parsing. Don’t ever fool yourself into thinking hard parsing doesn’t matter.
As you can see, it does!
总体而言,在执行硬解析期间对系统对象执行了59次查询。相同语句的软解析不需要执行任何针对系统对象的查询,因为所有的工作都有最初的硬解析做了。硬解析耗时.060374秒而同比软解析耗时.000095 秒。这样你就能看出,软解析相比硬解析是非常可取的方案。不要自以为是的认为硬解析没什么。你将看到,它确实(很影响性能)。
分享到:
相关推荐
flink-sql-connector-oracle-cdc 2.5-SNAPSHOT
《Pro Oracle SQL》是Oracle数据库查询的一本权威指南,Chapter 5主要探讨了与数据相关的问题,特别是关于NULL值的处理。在Oracle SQL中,NULL是一个特殊的值,表示未知或缺失的信息,它与任何其他值都不相等,包括...
Practical Guide for Oracle SQL,T-SQL and MySQL 英文无水印原版pdf pdf所有页面使用FoxitReader、PDF-XChangeViewer、SumatraPDF和Firefox测试都可以打开 本资源转载自网络,如有侵权,请联系上传者或csdn删除 ...
《Pro Oracle SQL》是Oracle数据库查询的一本权威指南,其中第9章主要讲解了如何使用Model子句进行行间引用,这是一个高级SQL特性,用于处理复杂的行与行之间的计算和逻辑操作。9.2章节专注于Inter-Row Referencing...
《Pro Oracle SQL》是Oracle数据库查询的一本权威指南,其中第二章主要讲解SQL查询的高级技巧。在2.8节“子查询展开(Subquery Unnesting)”中,我们将会深入探讨Oracle SQL中一种优化查询性能的重要策略。这一部分...
Chapter 2 - The Oracle Network Architecture Chapter 3 - Attacking the TNS Listener and Dispatchers Chapter 4 - Attacking the Authentication Process Chapter 5 - Oracle and PL/SQL Chapter 6 - ...
《Pro Oracle SQL》一书的第9章,重点关注了使用"Model"子句进行性能调优的方法。在Oracle数据库中,Model子句是一种强大的功能,它允许数据建模和复杂的计算,尤其适用于解决多步骤计算问题,如模拟、预测和序列...
《Pro Oracle SQL》一书的第10章深入探讨了SQL优化,特别是10.2节,重点关注如何测试执行计划,这是SQL性能调优的关键环节。在这个部分,作者旨在帮助读者理解如何有效地评估和改进SQL查询的性能,以提高数据库系统...
《Pro Oracle SQL》是Oracle数据库查询优化的经典之作,其中Chapter 3深入探讨了SQL查询的执行机制。在3.1.4章节中,主要讲解了全扫描(Full Scans)和高水线标记(Highwater Mark)的概念及其对查询性能的影响。这...
《Pro Oracle SQL》一书的第七章第7.8节主要探讨了如何通过GROUPING_ID()函数来扩展Oracle SQL报告的功能。GROUPING_ID()在数据分析和报表生成中扮演着重要角色,尤其在处理分组数据时,能提供更详细的分组信息。本...
《Pro Oracle SQL》是Oracle数据库查询的一本权威指南,其中Chapter 9深入探讨了SQL查询的各种高级技巧。在9.11章节中,主要讲解了Subquery Factoring,也被称为Common Table Expression(CTE),这是一个非常实用且...
《Pro Oracle SQL》是Oracle数据库查询的一本权威指南,其中Chapter 7着重讲解了SQL查询中的聚合函数与分组操作。在7.10 GROUP BY Restrictions这一部分,作者深入探讨了在使用GROUP BY子句时的一些限制和注意事项,...
《Pro Oracle SQL》是Oracle数据库查询优化的一本权威著作,其中第三章着重讲解了全面扫描(Full Scan Access Methods)这一重要的访问方法。在数据库查询优化中,了解并掌握不同的访问方法对于提高SQL查询性能至关...
《Pro Oracle SQL》是Oracle数据库查询优化的经典之作,第六章主要聚焦在Execution Plans(执行计划)上,这是数据库查询性能优化的关键。本章节的第四部分深入探讨了如何理解和解析执行计划,以及它对SQL性能的影响...
### Pro Oracle SQL - 成为SQL语言编写专家 #### 核心概念回顾与SQL语言能力介绍 本书《Pro Oracle SQL》由Karen Morton、Kerry Osborne、Robyn Sands、Riyaj Shamsudeen 和 Jared Still 共同撰写,旨在帮助读者...
Oracle Hyperion Chapter 2 - Tips for building your HFM Application
综上,文件提供的信息主要涵盖了关于“Pro Oracle SQL”这本书的出版细节、版权信息和内容摘要,通过这些信息我们可以推断出该书将为读者提供深入的Oracle SQL知识,并针对Oracle数据库的特定特性进行详细讲解。
Oracle Hyperion Chapter 4 - Reporting
Oracle Hyperion Chapter 3 - Rules and Calculation
Oracle-SQL-Developer-使用教程