1. 技术解析Transwarp Inceptor是怎样炼成的
技术解析Transwarp Inceptor是怎样炼成的
当前Hadoop技术蓬勃发展，用于解决大数据的分析难题的技术平台开始涌现。Spark凭借性能强劲、高度容错、调度灵活等技术优势已渐渐成为主流技术，业界大部分厂商都提供了基于Spark的技术方案和产品。根据Databricks的统计，目前有11个商业的Spark版本。
在使用Spark作出计算平台的解决方案中，有两种主流编程模型，一类是基于SparkAPI或者衍生出来的语言，另一种是基于sql语言。SQL作为数据库领域的事实标准语言，相比较用API(如MapReceAPI，SparkAPI等)来构建大数据分析的解决方案有着先天的优势：一是产业链完善，各种报表工具、ETL工具等可以很好的对接;二是用SQL开发有更低的技术门槛;三是能够降低原有系统的迁移成本等。因此，SQL语言也渐渐成为大数据分析的主流技术标准。本文将深入解析Inceptor的架构、编程模型和编译优化技术，并提供基准测试在多平台上的性能对比数据。
1.Inceptor架构
TranswarpInceptor是基于Spark的分析引擎，如图1所示，从下往上有三层架构：最下面是存储层，包含分布式内存列式存储(TranswarpHolodesk)，可建在内存或者SSD上;中间层是Spark计算引擎层，星环做了大量的改进保证引擎有超强的性能和高度的健壮性;最上层包括一个完整的SQL99和PL/SQL编译器、统计算法库和机器学习算法库，提供完整的R语言访问接口。
TranswarpInceptor可以分析存储在HDFS、HBase或者TranswarpHolodesk分布式缓存中的数据，可以处理的数据量从GB到数十TB，即使数据源或者中间结果的大小远大于内存容量也可高效处理。另外TranswarpInceptor通过改进Spark和YARN的组合，提高了Spark的可管理性。同时星环不仅仅是将Spark作为一个缺省计算引擎，也重写了SQL编译器，提供更加完整的SQL支持。
同时，TranswarpInceptor还通过改进Spark使之更好地与HBase融合，可以为HBase提供完整的SQL支持，包括批量SQL统计、OLAP分析以及高并发低延时的SQL查询能力，使得HBase的应用可以从简单的在线查询应用扩展到复杂分析和在线应用结合的混合应用中，大大拓展了HBase的应用范围。
2.编程模型
TranswarpInceptor提供两种编程模型：一是基于SQL的编程模型，用于常规的数据分析、数据仓库类应用市场;二是基于数据挖掘编程模型，可以利用R语言或者SparkMLlib来做一些深度学习、数据挖掘等业务模型。
2.1SQL模型
TranswarpInceptor实现了自己的SQL解析执行引擎，可以兼容SQL99和HiveQL，自动识别语法，因此可以兼容现有的基于Hive开发的应用。由于TranswarpInceptor完整支持标准的SQL 99标准，传统数据库上运行的业务可以非常方便的迁移到Transwarp Inceptor系统上。此外Transwarp Inceptor支持PL/SQL扩展，传统数据仓库的基于PL/SQL存储过程的应用(如ETL工具)可以非常方便的在Inceptor上并发执行。另外Transwarp Inceptor支持部分SQL 2003标准，如窗口统计功能、安全审计功能等，并对多个行业开发了专门的函数库，因此可以满足多个行业的特性需求。
2.2数据挖掘计算模型
TranswarpInceptor实现了机器学习算法库与统计算法库，支持常用机器学习算法并行化与统计算法并行化，并利用Spark在迭代计算和内存计算上的优势，将并行的机器学习算法与统计算法运行在Spark上。例如：机器学习算法库有包括逻辑回归、朴素贝叶斯、支持向量机、聚类、线性回归、关联挖掘、推荐算法等，统计算法库包括均值、方差、中位数、直方图、箱线图等。TranswarpInceptor可以支持用R语言或者SparkAPI在平台上搭建多种分析型应用，例如用户行为分析、精准营销、对用户贴标签、进行分类。
3.SQL编译与优化
TranswarpInceptor研发了一套完整的SQL编译器，包括HiveQL解析器、SQL标准解析器和PL/SQL解析器，将不同的SQL语言解析成中间级表示语言，然后经过优化器转换成物理执行计划。SQL语言解析后经过逻辑优化器生成中间级表示语言，而中间表示语言再经过物理优化器生成最终的物理执行计划。从架构上分，逻辑优化器和物理优化器都包含基于规则的优化模块和基于成本的优化模块。
为了和Hadoop生态更好的兼容，Inceptor为一个SQL查询生成MapRece上的执行计划和Spark上的执行计划，并且可以通过一个SET命令在两种执行引擎之间切换。
3.1SQL编译与解析
TranswarpInceptor的SQL编译器会根据输入的SQL查询的类型来自动选择不同的解析器，如PL/SQL存储过程会自动进入PL/SQL解析器并生成一个SparkRDD的DAG从而在Spark平台上并行计算，标准SQL查询会进入SQL标准解析器生成Spark或MapRece执行计划。由于HiveQL和标准的SQL有所出入，为了兼容HiveQL，Transwarp Inceptor保留了HiveQL解析器，并可以对非标准SQL的Hive查询生成Spark或者Map Rece执行计划。
3.1.1SQL标准解析器
TranswarpInceptor构建了自主研发的SQL标准解析器，用于解析SQL99& SQL 2003查询并生成Spark和Map Rece的执行计划。词法和语法分析层基于Antlr语法来构建词法范式，通过Antlr来生成抽象语义树，并会通过一些上下文的语义来消除冲突并生成正确的抽象语义树。语义分析层解析上层生成的抽象语义树，根据上下文来生成逻辑执行计划并传递给优化器。首先Transwarp Inceptor会将SQL解析成TABLE SCAN、SELECT、FILTER、JOIN、UNION、ORDER BY、GROUP BY等主要的逻辑块，接着会根据一些Meta信息进一步细化各个逻辑块的执行计划。如TABLE SCAN会分成块读取、块过滤、行级别过滤、序列化等多个执行计划。
3.1.2PL/SQL解析器
PL/SQL是Oracle对SQL语言的模块化扩展，已经在很多行业中有大规模的应用，是数据仓库领域的重要编程语言。
为了让存储过程在Spark上有较好的性能，PL/SQL解析器会根据存储过程中的上下文关系来生成SQLDAG，然后对各SQL的执行计划生成的RDD进行二次编译，通过物理优化器将一些没有依赖关系的RDD进行合并从而生成一个最终的RDDDAG。因此，一个存储过程被解析成一个大的DAG，从而stage之间可以大量并发执行，避免了多次执行SQL的启动开销并保证了系统的并发性能。
解析并生成SQL级别的执行计划
3.2SQL优化器
TranswarpInceptor使用Spark作为默认计算引擎，并且开发了完善的SQL优化器，因此在大量的客户案例性能测试中，TranswarpInceptor的性能领先MapRece 10-100倍，并超越部分开源MPP数据库。SQL优化器对平台性能的提升居功至伟。
3.2.1基于规则的优化器(RuleBasedOptimizer)
目前为止，TranswarpInceptor共实现了一百多个优化规则，并且在持续的添加新的规则。按照功能划分，这些规则主要分布在如下几个模块：
文件读取时过滤
在文件读取时过滤数据能够最大化的减少参与计算的数据量从而最为有效的提高性能，因此TranswarpInceptor提供了多个规则用于生成表的过滤条件。对于一些SQL中的显示条件，TranswarpInceptor会尽量将过滤前推到读取表中;而对于一些隐式的过滤条件，如可以根据joinkey生成的过滤规则，Inceptor会根据语义保证正确性的前提下进行规则生成。
过滤条件前置
TranswarpInceptor能够从复杂的组合过滤条件中筛选出针对特定表的过滤规则，然后通过SQL语义来确定是否能将过滤条件前推到尽量早的时候执行。如果有子查询，过滤条件可以递归前推入最低层的子查询中，从而保证所有的冗余数据被删除。
超宽表的读取过滤
对一些列超多的表进行处理的时候，TranswarpInceptor首先会根据SQL语义来确定要读取的列，并在读取表的时候进行跨列读取减少IO和内存消耗。而如果表有过滤条件，Inceptor会做进一步优化，首先只读取过滤条件相关的列来确定该行记录是否需要被选择，如果不是就跳过当前行的所有列，因此能够最大程度上的减少数据读取。在一些商业实施中，这些优化规则能够带来5x-10x的性能提升。
Shuffle Stage的优化与消除
Spark的shuffle实现的效率非常低，需要把结果写磁盘，然后通过HTTP传输。TranswarpInceptor添加了一些shuffle消除的优化规则，对SQL的DAG中不必要或者是可以合并的shufflestage进行消除或者合并。对于必须要做Shuffle的计算任务，Inceptor通过DAGScheler来提高shuffle的效率：MapTask会直接将结果返回给DAGScheler，然后DAGScheler将结果直接交给Rece Task而不是等待所有Map Task结束，这样能够非常明显的提升shuffle阶段的性能。
Partition消除
TranswarpInceptor提供单一值Partition和RangePartition，并且支持对Partition建Bucket来做多次分区。当Partition过多的时候，系统的性能会因为内存消耗和调度开销而损失。因此，Inceptor提供了多个规则用于消除不必要的Partition，如果上下文中有隐式的对Partition的过滤条件，Inceptor也会生成对partition的过滤规则。
3.2.2基于成本的优化器(CostBasedOptimizer)
基于规则的优化器都是根据一些静态的信息来产生的，因此很多和动态数据相关的特性是不能通过基于规则的优化来解决，因此TranswarpInceptor提供了基于成本的优化器来做二次优化。相关的原始数据主要来自Meta-store中的表统计信息、RDD的信息、SQL上下文中的统计信息等。依赖于这些动态的数据，CBO会计算执行计划的物理成本并选择最有效的执行计划。一些非常有效的优化规则包括如下几点：
JOIN顺序调优
在实际的案例中，join是消耗计算量最多的业务，因此对join的优化至关重要。在多表JOIN模型中，TranswarpInceptor会根据统计信息来预估join的中间结果大小，并选择产生中间数据量最小的join顺序作为执行计划。
JOIN类型的选择
TranswarpInceptor支持Left-mostJoinTree 和 Bush Join Tree，并且会根据统计信息来选择生成哪种Join模型有最佳性能。此外，Transwarp Inceptor会根据原始表或者中间数据的大小来选择是否开启针对数据倾斜模型下的特殊优化等。此外，针对HBase表是否有索引的情况，Transwarp Inceptor会在普通Join和Look-up Join间做个均衡的选择。
并发度的控制
Spark通过线程级并发来提高性能，但是大量的并发可能会带来不必要的调度开销，因此不同的案例在不同并发度下会有最佳性能。TranswarpInceptor通过对RDD的一些属性进行推算来选择最佳并发控制，对很多的案例有着2x-3x的性能提升。
4.TranswarpHolodesk内存计算引擎
为了有效的降低SQL分析的延时，减少磁盘IO对系统性能的影响，星环科技研发了基于内存或者SSD的存储计算引擎TranswarpHolodesk，通过将表数据直接建在内存或者SSD上以实现SQL查询全内存计算。另外TranswarpHolodesk增加了数据索引功能，支持对多个数据列建索引，从而更大程度的降低了SQL查询延时。
4.1存储格式
TranswarpHolodesk基于列式存储做了大量的原创性改进带来更高的性能和更低的数据膨胀率。首先数据被序列化后存储到内存或SSD上以节省者资源占用。如图3所示，每个表的数据被存储成若干个Segment，每个Segment被划分成若干个Block，每个Block按照列方式存储于SSD或内存中。另外每个Block的头部都加上Min-MaxFilter和BloomFilter用于过滤无用的数据块，减少不必要的数据进入计算阶段。
TranswarpHolodesk根据查询条件的谓词属性对每个数据块的对应列构建数据索引，索引列采用自己研发的Trie结构进行组织存储，非索引列采用字典编码的方式进行组织存储。Trie不仅能对具有公共前缀的字符串进行压缩，而且可以对输入的字符串排序，从而可以利用二分查找快速查询所需数据的位置，从而快速响应查询需求。
HDFS2.6支持StorageTier让应用程序可以选择存储层为磁盘或者SSD，但是没有专用的存储格式设计是无法有效利用SSD的读写吞吐量和低延，因此现有的Text以及行列混合(ORC/Parquet)都不能有效的利用SSD的高性能。为此验证存储结构对性能的影响，我们将HDFS构建在SSD上并选用某基准测试来做了进一步的性能对比，结果如图4所示：采用文本格式，PCI-ESSD带来的性能提升仅1.5倍;采用专为内存和SSD设计的Holodesk列式存储，其性能相比较SSD上的HDFS提升高达6倍。
4.2性能优势
某运营商客户在12台x86服务器上搭建了TranswarpInceptor，将TranswarpHolodesk配置在PCIE-SSD上，并与普通磁盘表以及DB2来做性能对比测试。最终测试数据如图5所示：
在纯粹的count测试一项，Holodesk性能相对于磁盘表最高领先32倍;对于join测试一项，TranswarpHolodesk最高领先磁盘表多达12倍;在单表聚合测试中，Holodesk提升倍数达10~30倍。另外TranswarpHolodesk在和DB2的对比中也表现优秀，两个复杂SQL查询在DB2数据库中需要运行1小时以上，但是在使用TranswarpHolodesk均是分钟级和秒级就返回结果。
内存的价格大约是同样容量SSD的十倍左右，为了给企业提供更高性价比的计算方案，TranswarpHolodesk针对SSD进行了大量的优化，使得应用在SSD上运行具有与在内存上比较接近的性能，从而为客户提供了性价比更高的计算平台。
在对TPC-DS的IO密集型查询的测试中，无论上构建在PCI-ESSD还是内存上，Holodesk对比磁盘表有一个数量级上的性能提升;而SSD上的Holodesk性能只比内存差10%左右。
5.稳定的Spark执行引擎
企业目前应用开源Spark的主要困难在稳定性、可管理性和功能不够丰富上。开源Spark在稳定性上还有比较多的问题，在处理大数据量时可能无法运行结束或出现Outofmemory，性能时快时慢，有时比Map/Rece更慢，无法应用到复杂数据分析业务中。
TranswarpInceptor针对各种出错场景设计了多种解决方法，如通过基于成本的优化器选择最合适的执行计划、加强对数据结构内存使用效率的有效管理、对常见的内存出错问题通过磁盘进行数据备份等方式，极大提高了Spark功能和性能的稳定性，上述问题都已经解决并经过商业案例的考验。TranswarpInceptor能稳定的运行7*24小时，并能在TB级规模数据上高效进行各种稳定的统计分析。
6.SQL引擎效能验证
TPC-DS是TPC组织为DecisionSupportSystem设计的一个测试集，包含对大数据集的统计/报表生成/联机查询/数据挖掘等复杂应用，测试用的数据有各种不同的分布与倾斜，与真实场景非常接近。随着国内外各代表性的Hadoop发行版厂商以TPC-DS为标准测评产品，TPC-DS也就逐渐成为了业界公认的Hadoop系统测试准则。
6.1验证对比的平台和配置
我们搭建了两个集群分别用于TranswarpInceptor与ClouderaDataHub/Impala的测试。
6.2TranswarpInceptorVS Cloudera Impala
TranswarpInceptor由于有完善的SQL支持，能够运行全部所有的99个SQL查询。而由于Cloudera官方发布的TPC-DS测试集只包含19个SQL案例，因此我们只能运行这19个SQL，实验证明这部分查询在Impala上全部正常运行完成。
6.3TranswarpInceptorVS Map Rece
我们使用了同样的硬件和软件配置完成和开源的Hive执行效率相比，TranswarpInceptor能够带来10x-100x的性能提升。图8是TPC-DS的部分SQL查询在Inceptor和CDH5.1Hive的性能提升倍数，其中最大的提升倍数竟可达到123倍。
7.结语
随着在大数据领域国内外开始处于同一起跑线，我们相信像星环科技这样国内具有代表性的Hadoop发行版厂商将在中国的广阔市场空间中获得长足发展，并且由于中国市场激烈的竞争与磨练，逐步打磨出超越国外先进厂商的技术与实力。
刘汪根。2013年加入星环，作为早期员工参与了星环大数据平台的构建，现担任数据平台部研发经理，主要负责与管理星环大数据平台数据平台的研发工作，如SQL编译器，Spark执行引擎等工作，产品涵括TranswarpInceptor/TranswarpStream等软件。
【编者按】星环科技从2013年6月开始研发基于Spark的SQL执行引擎，在2013年底推出TranswarpInceptor1.0，并落地了国内首个7x24小时的商用项目。经过1年多的持续创新与改进，星环已经在国内落地了数十个Inceptor的商用项目。这是一篇星环Spark解决方案的技术解析，也是Spark用户可以效仿的优化之道。
2. 数据库牛人是如何进行SQL优化的
SQL 查询优化减少了查询所需的资源并提高了整体系统性能，在本文中，我们将讨论 SQL 查询优化、它是如何完成的、最佳实践及其重要性。
SQL 查询优化是编写高效的 SQL 查询，并在执行时间和数据库表示方面 提高查询性能 的迭代过程，查询优化是几个关系数据库管理系统 (RDBMS) 的一项重要功能。
查询是对来自数据库的数据或信息的问题或请求，需要编写一组数据库可以理解的预定义代码，结构化查询语言 (SQL) 和其他查询语言旨在检索或管理关系数据库中的数据。
数据库中的查询可以用许多不同的结构编写，并且可以通过不同的算法执行，写得不好的查询会消耗更多的系统资源，执行时间长，并可能导致服务损失，一个完美的查询可以减少执行时间并带来最佳的 SQL 性能。
SQL查询优化的主要目的是：
确保查询处于最佳路径和形式非常重要，SQL 查询过程需要最好的执行计划和计算资源，因为它们是 CPU 密集型操作，SQL 查询优化通过三个基本步骤完成：
解析确保查询在语法和语义上都是正确的，如果查询语法正确，则将其转换为表达式并传递到下一步。
优化在查询性能中扮演着重要的角色，并且可能很困难，任何考虑优化的查询执行计划都必须返回与之前相同的结果，但优化后的性能应该会有所提高。
SQL 查询优化包括以下基本任务：
最后，查询执行涉及将查询优化步骤生成的计划转化为操作，如果没有发生错误，此步骤将返回结果给用户。
一旦用户确定某个查询需要改进以优化 SQL 性能，他们就可以选择任何优化方法——优化 SQL 查询性能的方法有很多种，下面介绍了一些最佳实践。
提高查询性能的一种简单方法是将 SELECT * 替换为实际的列名，当开发人员在表中使用 SELECT * 语句时，它会读取每一列的可用数据。
使用 SELECT 字段名 FROM 而不是 SELECT * FROM 时，可以缩小查询期间从表中提取的数据的范围，这有助于提高查询速度。
循环中的 SQL 查询运行不止一次，这会显着降低运行速度，这些查询会不必要地消耗内存、CPU 能力和带宽，这会影响性能，尤其是当 SQL 服务器不在本地计算机上时，删除循环内的查询可提高整体查询性能。
使用SQL 服务器索引可以减少运行时间并更快地检索数据，可以使用聚集和非聚集 SQL 索引来优化 SQL 查询，非聚集索引单独存储，需要更多的磁盘空间，因此，了解何时使用索引很重要。
该OLAP功能“扩展了SQL解析函数的语法。” SQL 中的 OLAP 功能更快且易于使用，熟悉这些语法的 SQL 开发人员和 DBA 可以很容易地适应和使用它们。
OLAP 函数可以创建所有标准计算度量，例如排名、移动聚合、份额、期初至今、前期和未来期、平行期等。
查询优化器使用统计信息来确定如何最好地连接表、何时应该使用索引以及如何访问这些索引等，无论是手动还是自动，SQL 服务器统计信息都应该保持最新。
过时的 SQL Server 统计信息会影响表、索引或列统计信息，并导致查询计划性能不佳。
SQL 查询优化可以轻松提高系统性能，从而节省成本，优化 SQL 查询可以提高运营效率并加快性能，从而提高系统上线进度。
SQL 查询优化很重要，原因有很多，包括：
组织可以通过更快的响应时间获得可靠的数据访问和高水平的性能，优化 SQL 查询不仅可以提高整体系统性能，还可以提高组织的声誉，最终，SQL 查询优化的最佳实践帮助用户获得准确、快速的数据库结果。
3. SQL语句执行流程与顺序原理解析
SQL语句执行流程与顺序原理解析
Oracle语句执行流程
第一步：客户端把语句发给服务器端执行
当我们在客户端执行SQL语句时，客户端会把这条SQL语句发送给服务器端，让服务器端的进程来处理这语句。也就是说，Oracle 客户端是不会做任何的操作，他的主要任务就是把客户端产生的一些SQL语句发送给服务器端。服务器进程从用户进程把信息接收到后， 在PGA 中就要此进程分配所需内存，存储相关的信息，如：在会话内存存储相关的登录信息等。
虽然在客户端也有一个数据库进程，但是，这个进程的作用跟服务器上的进程作用是不相同的，服务器上的数据库进程才会对SQL 语句进行相关的处理。不过，有个问题需要说明，就是客户端的进程跟服务器的进程是一一对应的。也就是说，在客户端连接上服务器后，在客户端与服务器端都会形成一个进程，客户端上的我们叫做客户端进程，而服务器上的我们叫做服务器进程。
第二步：语句解析
当客户端把SQL语句传送到服务器后，服务器进程会对该语句进行解析。这个解析的工作是在服务器端所进行的，解析动作又可分为很多小动作。
1）查询高速缓存（library cache）
服务器进程在接到客户端传送过来的SQL语句时，不会直接去数据库查询。服务器进程把这个SQL语句的字符转化为ASCII等效数字码，接着这个ASCII码被传递给一个HASH函数，并返回一个hash值，然后服务器进程将到shared pool中的library cache（高速缓存）中去查找是否存在相同的hash值。如果存在，服务器进程将使用这条语句已高速缓存在SHARED POOL的library cache中的已分析过的版本来执行，省去后续的解析工作，这便是软解析。若调整缓存中不存在，则需要进行后面的步骤，这便是硬解析。硬解析通常是昂贵的操作，大约占整个SQL执行的70%左右的时间，硬解析会生成执行树，执行计划，等等。
所以，采用高速数据缓存的话，可以提高SQL 语句的查询效率。其原因有两方面：一方面是从内存中读取数据要比从硬盘中的数据文件中读取数据效率要高，另一方面也是因为避免语句解析而节省了时间。
不过这里要注意一点，这个数据缓存跟有些客户端软件的数据缓存是两码事。有些客户端软件为了提高查询效率，会在应用软件的客户端设置数据缓存。由于这些数据缓存的存在，可以提高客户端应用软件的查询效率。但是，若其他人在服务器进行了相关的修改，由于应用软件数据缓存的存在，导致修改的数据不能及时反映到客户端上。从这也可以看出，应用软件的数据缓存跟数据库服务器的高速数据缓存不是一码事。
2）语句合法性检查（data dict cache）
当在高速缓存中找不到对应的SQL语句时，则服务器进程就会开始检查这条语句的合法性。这里主要是对SQL语句的语法进行检查，看看其是否合乎语法规则。如果服务器进程认为这条SQL语句不符合语法规则的时候，就会把这个错误信息反馈给客户端。在这个语法检查的过程中，不会对SQL语句中所包含的表名、列名等等进行检查，只是检查语法。
3）语言含义检查（data dict cache）
若SQL 语句符合语法上的定义的话，则服务器进程接下去会对语句中涉及的表、索引、视图等对象进行解析，并对照数据字典检查这些对象的名称以及相关结构，看看这些字段、表、视图等是否在数据库中。如果表名与列名不准确的话，则数据库会就会反馈错误信息给客户端。
所以，有时候我们写select语句的时候，若语法与表名或者列名同时写错的话，则系统是先提示说语法错误，等到语法完全正确后再提示说列名或表名错误。
4）获得对象解析锁（control structer）
当语法、语义都正确后，系统就会对我们需要查询的对象加锁。这主要是为了保障数据的一致性，防止我们在查询的过程中，其他用户对这个对象的结构发生改变。
5）数据访问权限的核对（data dict cache）
当语法、语义通过检查之后，客户端还不一定能够取得数据，服务器进程还会检查连接用户是否有这个数据访问的权限。若用户不具有数据访问权限的话，则客户端就不能够取得这些数据。要注意的是数据库服务器进程先检查语法与语义，然后才会检查访问权限。
6）确定最佳执行计划
当语法与语义都没有问题权限也匹配，服务器进程还是不会直接对数据库文件进行查询。服务器进程会根据一定的规则，对这条语句进行优化。在执行计划开发之前会有一步查询转换，如：视图合并、子查询解嵌套、谓语前推及物化视图重写查询等。为了确定采用哪个执行计划，Oracle还需要收集统计信息确定表的访问联结方法等，最终确定可能的最低成本的执行计划。
不过要注意，这个优化是有限的。一般在应用软件开发的过程中，需要对数据库的sql语句进行优化，这个优化的作用要大大地大于服务器进程的自我优化。
当服务器进程的优化器确定这条查询语句的最佳执行计划后， 就会将这条SQL语句与执行计划保存到数据高速缓存（library cache）。如此，等以后还有这个查询时，就会省略以上的语法、语义与权限检查的步骤，而直接执行SQL语句，提高SQL语句处理效率。
第三步：绑定变量赋值
如果SQL语句中使用了绑定变量，扫描绑定变量的声明，给绑定变量赋值，将变量值带入执行计划。若在解析的第一个步骤，SQL在高速缓冲中存在，则直接跳到该步骤。
第四步：语句执行
语句解析只是对SQL语句的语法进行解析，以确保服务器能够知道这条语句到底表达的是什么意思。等到语句解析完成之后，数据库服务器进程才会真正的执行这条SQL语句。
对于SELECT语句：
1）首先服务器进程要判断所需数据是否在db buffer存在，如果存在且可用，则直接获取该数据而不是从数据库文件中去查询数据，同时根据LRU 算法增加其访问计数；
2）若数据不在缓冲区中，则服务器进程将从数据库文件中查询相关数据，并把这些数据放入到数据缓冲区中（buffer cache）。
其中，若数据存在于db buffer，其可用性检查方式为：查看db buffer块的头部是否有事务，如果有事务，则从回滚段中读取数据；如果没有事务，则比较select的scn和db buffer块头部的scn，如果前者小于后者，仍然要从回滚段中读取数据；如果前者大于后者，说明这是一非脏缓存，可以直接读取这个db buffer块的中内容。
对于DML语句（insert、delete、update）：
1）检查所需的数据库是否已经被读取到缓冲区缓存中。如果已经存在缓冲区缓存，则直接执行步骤3；
2）若所需的数据库并不在缓冲区缓存中，则服务器将数据块从数据文件读取到缓冲区缓存中；
3）对想要修改的表取得的数据行锁定（Row Exclusive Lock），之后对所需要修改的数据行取得独占锁；
4）将数据的Redo记录复制到redo log buffer；
5）产生数据修改的undo数据；
6）修改db buffer；
7）dbwr将修改写入数据文件；
其中，第2步，服务器将数据从数据文件读取到db buffer经经历以下步骤：
1）首先服务器进程将在表头部请求TM锁（保证此事务执行过程其他用户不能修改表的结构），如果成功加TM锁，再请求一些行级锁（TX锁），如果TM、TX锁都成功加锁，那么才开始从数据文件读数据。
2）在读数据之前，要先为读取的文件准备好buffer空间。服务器进程需要扫描LRU list寻找free db buffer，扫描的过程中，服务器进程会把发现的所有已经被修改过的db buffer注册到dirty list中。如果free db buffer及非脏数据块缓冲区不足时，会触发dbwr将dirty buffer中指向的缓冲块写入数据文件，并且清洗掉这些缓冲区来腾出空间缓冲新读入的数据。
3）找到了足够的空闲buffer，服务器进程将从数据文件中读入这些行所在的每一个数据块（db block）（DB BLOCK是ORACLE的最小操作单元，即使你想要的数据只是DB BLOCK中很多行中的一行或几行，ORACLE也会把这个DB BLOCK中的所有行都读入Oracle DB BUFFER中）放入db buffer的空闲的区域或者覆盖已被挤出LRU list的非脏数据块缓冲区，并且排列在LRU列表的头部，也就是在数据块放入db buffer之前也是要先申请db buffer中的锁存器，成功加锁后，才能读数据到db buffer。
若数据块已经存在于db buffer cache（有时也称db buffer或db cache），即使在db buffer中找到一个没有事务，而且SCN比自己小的非脏缓存数据块，服务器进程仍然要到表的头部对这条记录申请加锁，加锁成功才能进行后续动作，如果不成功，则要等待前面的进程解锁后才能进行动作（这个时候阻塞是tx锁阻塞）。
在记redo日志时，其具体步骤如下：
1）数据被读入到db buffer后，服务器进程将该语句所影响的并被读入db buffer中的这些行数据的rowid及要更新的原值和新值及scn等信息从PGA逐条的写入redo log buffer中。在写入redo log buffer之前也要事先请求redo log buffer的锁存器，成功加锁后才开始写入。
2）当写入达到redo log buffer大小的三分之一或写入量达到1M或超过三秒后或发生检查点时或者dbwr之前发生，都会触发lgwr进程把redo log buffer的数据写入磁盘上的redo file文件中（这个时候会产生log file sync等待事件）。
3）已经被写入redo file的redo log buffer所持有的锁存器会被释放，并可被后来的写入信息覆盖，redo log buffer是循环使用的。Redo file也是循环使用的，当一个redo file写满后，lgwr进程会自动切换到下一redo file（这个时候可能出现log file switch（check point complete）等待事件）。如果是归档模式，归档进程还要将前一个写满的redo file文件的内容写到归档日志文件中（这个时候可能出现log file switch（archiving needed）。
在为事务建立undo信息时，其具体步骤如下：
1）在完成本事务所有相关的redo log buffer之后，服务器进程开始改写这个db buffer的块头部事务列表并写入scn（一开始scn是写在redo log buffer中的，并未写在db buffer）。
2）然后包含这个块的头部事务列表及scn信息的数据副本放入回滚段中，将这时回滚段中的信息称为数据块的“前映像”，这个“前映像”用于以后的回滚、恢复和一致性读。（回滚段可以存储在专门的回滚表空间中，这个表空间由一个或多个物理文件组成，并专用于回滚表空间，回滚段也可在其它表空间中的数据文件中开辟）。
在修改信息写入数据文件时，其具体步骤如下：
1）改写db buffer块的数据内容，并在块的头部写入回滚段的地址。
2）将db buffer指针放入dirty list。如果一个行数据多次update而未commit，则在回滚段中将会有多个“前映像”，除了第一个“前映像”含有scn信息外，其他每个"前映像"的头部都有scn信息和"前前映像"回滚段地址。一个update只对应一个scn，然后服务器进程将在dirty list中建立一条指向此db buffer块的指针（方便dbwr进程可以找到dirty list的db buffer数据块并写入数据文件中）。接着服务器进程会从数据文件中继续读入第二个数据块，重复前一数据块的动作，数据块的读入、记日志、建立回滚段、修改数据块、放入dirty list。
3）当dirty queue的长度达到阀值（一般是25%），服务器进程将通知dbwr把脏数据写出，就是释放db buffer上的锁存器，腾出更多的free db buffer。前面一直都是在说明oracle一次读一个数据块，其实oracle可以一次读入多个数据块（db_file_multiblock_read_count来设置一次读入块的个数）
当执行commit时，具体步骤如下：
1）commit触发lgwr进程，但不强制dbwr立即释放所有相应db buffer块的锁。也就是说有可能虽然已经commit了，但在随后的一段时间内dbwr还在写这条sql语句所涉及的数据块。表头部的行锁并不在commit之后立即释放，而是要等dbwr进程完成之后才释放，这就可能会出现一个用户请求另一用户已经commit的资源不成功的现象。
2）从Commit和dbwr进程结束之间的时间很短，如果恰巧在commit之后，dbwr未结束之前断电，因为commit之后的数据已经属于数据文件的内容，但这部分文件没有完全写入到数据文件中。所以需要前滚。由于commit已经触发lgwr，这些所有未来得及写入数据文件的更改会在实例重启后，由smon进程根据重做日志文件来前滚，完成之前commit未完成的工作（即把更改写入数据文件）。
3）如果未commit就断电了，因为数据已经在db buffer更改了，没有commit，说明这部分数据不属于数据文件。由于dbwr之前触发lgwr也就是只要数据更改，（肯定要先有log）所有dbwr在数据文件上的修改都会被先一步记入重做日志文件，实例重启后，SMON进程再根据重做日志文件来回滚。
其实smon的前滚回滚是根据检查点来完成的，当一个全部检查点发生的时候，首先让LGWR进程将redologbuffer中的所有缓冲（包含未提交的重做信息）写入重做日志文件，然后让dbwr进程将dbbuffer已提交的缓冲写入数据文件（不强制写未提交的）。然后更新控制文件和数据文件头部的SCN，表明当前数据库是一致的，在相邻的两个检查点之间有很多事务，有提交和未提交的。
当执行rollback时，具体步骤如下：
服务器进程会根据数据文件块和db buffer中块的头部的事务列表和SCN以及回滚段地址找到回滚段中相应的修改前的副本，并且用这些原值来还原当前数据文件中已修改但未提交的改变。如果有多个”前映像“，服务器进程会在一个“前映像”的头部找到“前前映像”的回滚段地址，一直找到同一事务下的最早的一个“前映像”为止。一旦发出了commit，用户就不能rollback，这使得commit后dbwr进程还没有全部完成的后续动作得到了保障。
第五步：提取数据
当语句执行完成之后，查询到的数据还是在服务器进程中，还没有被传送到客户端的用户进程。所以，在服务器端的进程中，有一个专门负责数据提取的一段代码。他的作用就是把查询到的数据结果返回给用户端进程，从而完成整个查询动作。
从这整个查询处理过程中，我们在数据库开发或者应用软件开发过程中，需要注意以下几点：
一是要了解数据库缓存跟应用软件缓存是两码事情。数据库缓存只有在数据库服务器端才存在，在客户端是不存在的。只有如此，才能够保证数据库缓存中的内容跟数据库文件的内容一致。才能够根据相关的规则，防止数据脏读、错读的发生。而应用软件所涉及的数据缓存，由于跟数据库缓存不是一码事情，所以，应用软件的数据缓存虽然可以提高数据的查询效率，但是，却打破了数据一致性的要求，有时候会发生脏读、错读等情况的发生。所以，有时候，在应用软件上有专门一个功能，用来在必要的时候清除数据缓存。不过，这个数据缓存的清除，也只是清除本机上的数据缓存，或者说，只是清除这个应用程序的数据缓存，而不会清除数据库的数据缓存。
二是绝大部分SQL语句都是按照这个处理过程处理的。我们DBA或者基于Oracle数据库的开发人员了解这些语句的处理过程，对于我们进行涉及到SQL语句的开发与调试，是非常有帮助的。有时候，掌握这些处理原则，可以减少我们排错的时间。特别要注意，数据库是把数据查询权限的审查放在语法语义的后面进行检查的。所以，有时会若光用数据库的权限控制原则，可能还不能满足应用软件权限控制的需要。此时，就需要应用软件的前台设置，实现权限管理的要求。而且，有时应用数据库的权限管理，也有点显得繁琐，会增加服务器处理的工作量。因此，对于记录、字段等的查询权限控制，大部分程序涉及人员喜欢在应用程序中实现，而不是在数据库上实现。
Oracle SQL语句执行顺序
(8)SELECT (9) DISTINCT (11) <select_list>
(1) FROM <left_table>
(3) <join_type> JOIN <right_table>
(2) ON <join_condition>
(4) WHERE <where_condition>
(5) GROUP BY <group_by_list>
(6) WITH {CUBE | ROLLUP}
(7) HAVING <having_condition>
(10) ORDER BY <order_by_list>
1）FROM：对FROM子句中的表执行笛卡尔积(交叉联接)，生成虚拟表VT1。
2）ON：对VT1应用ON筛选器，只有那些使为真才被插入到TV2。
3）OUTER (JOIN):如果指定了OUTER JOIN(相对于CROSS JOIN或INNER JOIN)，保留表中未找到匹配的行将作为外部行添加到VT2，生成TV3。如果FROM子句包含两个以上的表，则对上一个联接生成的结果表和下一个表重复执行步骤1到步骤3，直到处理完所有的表位置。
4）WHERE：对TV3应用WHERE筛选器，只有使为true的行才插入TV4。
5）GROUP BY：按GROUP BY子句中的列列表对TV4中的行进行分组，生成TV5。
6）CUTE|ROLLUP：把超组插入VT5，生成VT6。
7）HAVING：对VT6应用HAVING筛选器，只有使为true的组插入到VT7。
8）SELECT：处理SELECT列表，产生VT8。
9）DISTINCT：将重复的行从VT8中删除，产品VT9。
10）ORDER BY：将VT9中的行按ORDER BY子句中的列列表顺序，生成一个游标(VC10)，生成表TV11，并返回给调用者。
以上每个步骤都会产生一个虚拟表，该虚拟表被用作下一个步骤的输入。这些虚拟表对调用者(客户端应用程序或者外部查询)不可用。只有最后一步生成的表才会会给调用者。如果没有在查询中指定某一个子句，将跳过相应的步骤。
4. 如何使用oracle提供的SQL
Sql性能非常差的时候,oracle提供了SQL_TRACE来跟踪sql的执行情况。
注：分析sql的方式比较多，还有根据优化器、sql执行计划来分析。
SQL_TRACE能够将sql执行的过程输出到一个trace文件里面。
首先设置自己定义的trace文件的标识方便查找。
alter session set tracefile_identifier='mytest';
然后对当前会话启动SQL_TRACE，最好不要一直打开该开关，代价比较大。
alter session set sql_trace=true;
然后我们执行一条sql语句。
最后关闭该开关的状态。
alter session set sql_trace=false;
我们可以从目录%ORACLE_BASE%/diag/rdbms/orcl/orcl/trace(11g版本的路径，如果是10g的应该不一样)中
找到自己定义的trace文件。
原始的trace文件的可读性不高，我们一般使用oracle自带的工具，tkprof来处理这个trace文件。我们可以查看tkprof的帮助。
tkprof orcl_ora_3820_mytest.trc out.txt
我们来看刚才生成的trace文件，头部信息描述了tkprof 的版本以及报告中一些列的含义，对于任何一条sql语句，都应该包含Parse—sql分析阶段，Execute—sql执行阶段，Fetch—数据提取阶段，横向的列如图所示，包含消耗cpu时间0.00秒，操作总耗时0.04秒，物理读取了0个数据块，没有发生current方式的读取(一般在update会发生)，一共提取记录1条。
Misses in library cache ring parse: 0表示这是一次软分析(关于硬分析和软分析下面会接着谈到)
Optimizer mode: ALL_ROWS表示oracle的优化器模式为ALL_ROWS。这也就是前面提到的另外的分析方式优化器。
下面是sql执行的具体计划，可以看到执行计划选择的是全表扫描。
经过处理以后的trace文件的确比较容易看明白，它有助于我们分析sql的性能问题。
下面我通过一个trace实例来解释一下，为什么OLTP系统中需要变量绑定机制。
当用户和数据库建立连接，并发送一条sql语句以后，oracle会对该sql进行hash函数运算(hash算法提供了一种快速存取数据的方法，它用一种算法建立键值与真实值之间的对应关系,每一个真实值只能有一个键值，但是一个键值可以对应多个真实值，以方便存取)，得到一个hash值，然后到共享池中寻找是否有匹配的hash值的sql存在，如果有，就直接使用该sql的执行计划去执行sql。如果没有，oracle就会认为这是一条新的sql语句，然后按照语法分析，语义分析，生成执行计划，执行sql这些步骤来执行最终把结果返回给用户。这些步骤也被成为硬分析，可以想象，如果减少硬分析，能够大大降低数据库花费在sql解析上的资源开销。
我们先执行一条sql 1000次，比较绑定变量和不绑定变量的差异。得到结果以后，要计算实际的消耗，我们需要把OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS以及OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS的时间累计起来，前者表示数据字典表的相关的信息，包含权限控制等，后者表示sql所衍生出的递归sql语句的信息。可以看到绑定变量的，整条语句执行时间为0.22+0.02=0.24秒，CPU时间0.18+0.03=0.21秒，分析次数3次，执行次数1003次。而不绑定变量的时候，整条语句执行时间为0.28+1.29=1.57秒，CPU时间0.31+1.26=1.57秒，分析次数1002次，执行次数1003次。可见绑定变量的确能够带来更低的开销。(如何设计数据库中使用绑定变量也是和系统息息相关的，很多数据库问题都是在设计以后就已经存在的)
应用级调优分析:
就通常所说的三层架构来说，中间件这一层能够起到一个缓冲池的作用，如果并发用户数到3000这个数量级的时候，中间件能够控制不是所有的用户都能直接连接到数据库，当然这里的程序会快速响应用户请求，保证缓冲池的队列等待不会很久。
对应用这一级别的调优，主要集中在app程序，中间件的监控，集群配置等方面。如果是发现应用级别的问题，首先要分析是配置问题，还是程序本身的问题。如果并发用户数很大，中间件的线程池最大值配置过小，会导致在请求队列堆积，表现就是线程监控视图中，请求的队列堆积比较多，一般可以调整线程池最大值来解决。我们来看看weblogic的监控视图。
考虑到如果为每一个请求都创建一个新线程来处理的话，那么我们难以在系统中实现足够数量的线程。不受限制的创建线程可能耗尽系统资源，因此引入了线程池。线程池的思想是在进程开始时创建一定数量的线程并将它们置入一个池(pool)中，线程在这个池中等待工作。当服务器接收到一个请求时，它就从池中唤醒一个线程(如果有可用的线程)，由它来处理请求。一旦线程服务完毕，它就返回线程池等待后面的工作。
线程池利用已存在的线程服务请求要比等待创建一个线程要快，并且线程池限制了线程的数量。
如果怀疑是程序的问题，我们一般可以通过java自带的工具来帮助分析，工具很多。这里我主要提到一个jdk1.6以后附带的jvisualvm。
我们打开jdk1.6，找到并运行jvisualvm.exe。
我们发现应用程序分为本地，远程两部分。本地包含本地运行的java进程，远程能够通过配置连接到远程服务器上的java进程。我们先启动一个tomcat。可以看到本地应用程序已经打开了一个带有tomcat以及进程标识id的菜单。双击打开。这里我们一般关心2个视图。监视、线程。
其中监视视图比较关心垃圾回收活动(顾名思义，回收那些在程序里面不再使用到的内存空间)，堆内存变化。如果在压力测试过程中，堆内存变化是一个逐渐上涨的趋势，并且经过多次手动gc回收，还是保持这个趋势，说明内存泄漏的可能性很大。如果猜测有内存泄漏，可以通过分析java的heap mp。JVM (java虚拟机)记录下问题发生时系统的运行状态并将其存储在转储(mp)文件中。Heap mp就是这样一种文件形式。
线程视图比较关心线程的当前执行状态，这里可以生成另一种转储文件 Java mp。Java mp，也叫做 Thread mp，是 JVM 故障诊断中最重要的转储文件之一。JVM 的许多问题都可以使用这个文件进行诊断，其中比较典型的包括线程阻塞，CPU 使用率过高，JVM Crash，堆内存不足，和类装载等问题。其中线程阻塞更加常见。
原文转自：http://blog.csdn.net/xuyubotest/article/details/8158241
5. 求助，请问有类似SQL语义分析器的工具吗
一般用oracle的都会用pl/sql 的工具
不过这个不是很好用。
强烈的推荐一款软件。。SqlDBX。一般的数据库都可以用oracle，serversql，mysql等。。
你可以试试。。
6. 如何获取SQL2005下的SQL语句的语义分析
我想获取一段sql语句在 mssql2005下解析成的语句，
主要是想获取这个sql所用到的所有的表的名字。（ps：复杂的sql语句的）
请高手帮忙 在线等～
我的意思是要从用户输入的sql语句中提取该语句中所用的表
或者是:
sql 执行的步骤
1. 解析器
第 1 阶段是解析器阶段，它将 SQL 文本转换成语法树。这个阶段不查找系统目录中的任何信息，不访问数据库。
2. 语义分析
第 2 阶段分析由解析器创建的语法树，并产生用于查询的查询控制块和表达式树。要构建这些内部数据结构，它执行以下操作：
验证对象
解析 UDR
如果可能的话，消除常量
验证对象
第 2 阶段访问数据库中不同的系统目录，以验证查询所引用的所有数据库对象（诸如表、列、视图、类型、UDR 等等）是否都存在。它在数据库中找到这些对象的标识，然后创建查询控制块和表达式树。
我要的就是验证对象步骤里的表的信息
7. PostgreSQL查询SQL语义分析（1）—解析查询对象addRangeTableEntry
本文主要介绍PG在执行查询时，对SQL的语义分析重写过程中的查询对象解析过程，处理的函数为addRangeTableEntry，分析查询对象信息。
本函数是解析查询 (包含增删改查操作) 执行过程中涉及的查询对象 (表、视图、子查询等) 的信息。
每次调用只解析一个对象。
1、通过观察addRangeTableEntry的执行过程，了解SQL语义解析transformFromClause的处理过程。
2、表结构信是从缓存中结构读取，然后获取自己需要的信息。
3、语义分析后转换为relid（关联对象id），提升查询执行的处理效率。
8. SQL语句执行过程详解
SQL语句执行过程详解
一条sql，plsql的执行到底是怎样执行的呢？
一、SQL语句执行原理：
第一步:客户端把语句发给服务器端执行当我们在客户端执行 select 语句时,客户端会把这条 SQL 语句发送给服务器端,让服务器端的
进程来处理这语句。也就是说,Oracle 客户端是不会做任何的操作,他的主要任务就是把客户端产生
的一些 SQL 语句发送给服务器端。虽然在客户端也有一个数据库进程,但是,这个进程的作用跟服务器
上的进程作用事不相同的。服务器上的数据库进程才会对SQL 语句进行相关的处理。不过,有个问题需
要说明,就是客户端的进程跟服务器的进程是一一对应的。也就是说,在客户端连接上服务器后,在客户
端与服务器端都会形成一个进程,客户端上的我们叫做客户端进程;而服务器上的我们叫做服务器进程。
第二步:语句解析
当客户端把 SQL 语句传送到服务器后,服务器进程会对该语句进行解析。同理,这个解析的工作,
也是在服务器端所进行的。虽然这只是一个解析的动作,但是,其会做很多“小动作”。
1. 查询高速缓存(library cache)。服务器进程在接到客户端传送过来的 SQL 语句时,不
会直接去数据库查询。而是会先在数据库的高速缓存中去查找,是否存在相同语句的执行计划。如果在
数据高速缓存中,则服务器进程就会直接执行这个 SQL 语句,省去后续的工作。所以,采用高速数据缓
存的话,可以提高 SQL 语句的查询效率。一方面是从内存中读取数据要比从硬盘中的数据文件中读取
数据效率要高,另一方面,也是因为这个语句解析的原因。
不过这里要注意一点,这个数据缓存跟有些客户端软件的数据缓存是两码事。有些客户端软件为了
提高查询效率,会在应用软件的客户端设置数据缓存。由于这些数据缓存的存在,可以提高客户端应用软
件的查询效率。但是,若其他人在服务器进行了相关的修改,由于应用软件数据缓存的存在,导致修改的
数据不能及时反映到客户端上。从这也可以看出,应用软件的数据缓存跟数据库服务器的高速数据缓存
不是一码事。
2. 语句合法性检查(data dict cache)。当在高速缓存中找不到对应的 SQL 语句时,则服
务器进程就会开始检查这条语句的合法性。这里主要是对 SQL 语句的语法进行检查,看看其是否合乎
语法规则。如果服务器进程认为这条 SQL 语句不符合语法规则的时候,就会把这个错误信息,反馈给客
户端。在这个语法检查的过程中,不会对 SQL 语句中所包含的表名、列名等等进行 SQL 他只是语法
上的检查。
3. 语言含义检查(data dict cache)。若 SQL 语句符合语法上的定义的话,则服务器进程
接下去会对语句中的字段、表等内容进行检查。看看这些字段、表是否在数据库中。如果表名与列名不
准确的话,则数据库会就会反馈错误信息给客户端。所以,有时候我们写 select 语句的时候,若语法
与表名或者列名同时写错的话,则系统是先提示说语法错误,等到语法完全正确后,再提示说列名或表名
错误。
4. 获得对象解析锁(control structer)。当语法、语义都正确后,系统就会对我们需要查询
的对象加锁。这主要是为了保障数据的一致性,防止我们在查询的过程中,其他用户对这个对象的结构发
生改变。
5. 数据访问权限的核对(data dict cache)。当语法、语义通过检查之后,客户端还不一定
能够取得数据。服务器进程还会检查,你所连接的用户是否有这个数据访问的权限。若你连接上服务器
的用户不具有数据访问权限的话,则客户端就不能够取得这些数据。有时候我们查询数据的时候,辛辛苦
苦地把 SQL 语句写好、编译通过,但是,最后系统返回个 “没有权限访问数据”的错误信息,让我们气
半死。这在前端应用软件开发调试的过程中,可能会碰到。所以,要注意这个问题,数据库服务器进程先
检查语法与语义,然后才会检查访问权限。
6. 确定最佳执行计划 ?。当语句与语法都没有问题,权限也匹配的话,服务器进程还是不会直接对
数据库文件进行查询。服务器进程会根据一定的规则,对这条语句进行优化。不过要注意,这个优化是有
限的。一般在应用软件开发的过程中,需要对数据库的 sql 语言进行优化,这个优化的作用要大大地大
于服务器进程的自我优化。所以,一般在应用软件开发的时候,数据库的优化是少不了的。当服务器进程
的优化器确定这条查询语句的最佳执行计划后,就会将这条 SQL 语句与执行计划保存到数据高速缓存
(library cache)。如此的话,等以后还有这个查询时,就会省略以上的语法、语义与权限检查的步骤,
而直接执行 SQL 语句,提高 SQL 语句处理效率。
第三步:语句执行
语句解析只是对 SQL 语句的语法进行解析,以确保服务器能够知道这条语句到底表达的是什么意
思。等到语句解析完成之后,数据库服务器进程才会真正的执行这条 SQL 语句。这个语句执行也分两
种情况。
一是若被选择行所在的数据块已经被读取到数据缓冲区的话,则服务器进程会直接把这个数据传递
给客户端,而不是从数据库文件中去查询数据。
若数据不在缓冲区中,则服务器进程将从数据库文件中查询相关数据,并把这些数据放入到数据缓冲
区中(buffer cache)。
第四步:提取数据
当语句执行完成之后,查询到的数据还是在服务器进程中,还没有被传送到客户端的用户进程。所以,
在服务器端的进程中,有一个专门负责数据提取的一段代码。他的作用就是把查询到的数据结果返回给
用户端进程,从而完成整个查询动作。从这整个查询处理过程中,我们在数据库开发或者应用软件开发过
程中,需要注意以下几点:
一是要了解数据库缓存跟应用软件缓存是两码事情。数据库缓存只有在数据库服务器端才存在,在
客户端是不存在的。只有如此,才能够保证数据库缓存中的内容跟数据库文件的内容一致。才能够根据
相关的规则,防止数据脏读、错读的发生。而应用软件所涉及的数据缓存,由于跟数据库缓存不是一码事
情,所以,应用软件的数据缓存虽然可以提高数据的查询效率,但是,却打破了数据一致性的要求,有时候
会发生脏读、错读等情况的发生。所以,有时候,在应用软件上有专门一个功能,用来在必要的时候清除
数据缓存。不过,这个数据缓存的清除,也只是清除本机上的数据缓存,或者说,只是清除这个应用程序
的数据缓存,而不会清除数据库的数据缓存。
二是绝大部分 SQL 语句都是按照这个处理过程处理的。我们 DBA 或者基于 Oracle 数据库的
开发人员了解这些语句的处理过程,对于我们进行涉及到 SQL 语句的开发与调试,是非常有帮助的。有
时候,掌握这些处理原则,可以减少我们排错的时间。特别要注意,数据库是把数据查询权限的审查放在
语法语义的后面进行检查的。所以,有时会若光用数据库的权限控制原则,可能还不能满足应用软件权限
控制的需要。此时,就需要应用软件的前台设置,实现权限管理的要求。而且,有时应用数据库的权限管
理,也有点显得繁琐,会增加服务器处理的工作量。因此,对于记录、字段等的查询权限控制,大部分程
序涉及人员喜欢在应用程序中实现,而不是在数据库上实现。
DBCC DROPCLEANBUFFERS
从缓冲池中删除所有清除缓冲区。
DBCC FREEPROCCACHE
从过程缓存中删除所有元素。
DBCC FREESYSTEMCACHE
从所有缓存中释放所有未使用的缓存条目
SQL语句中的函数、关键字、排序等执行顺序:
1. FROM 子句返回初始结果集。
2. WHERE 子句排除不满足搜索条件的行。
3. GROUP BY 子句将选定的行收集到 GROUP BY 子句中各个唯一值的组中。
4. 选择列表中指定的聚合函数可以计算各组的汇总值。
5. 此外,HAVING 子句排除不满足搜索条件的行。
6. 计算所有的表达式;
7. 使用 order by 对结果集进行排序。
8. 查找你要搜索的字段。
二、SQL语句执行完整过程：
1.用户进程提交一个 sql 语句:
update temp set a=a*2，给服务器进程。
2.服务器进程从用户进程把信息接收到后,在 PGA 中就要此进程分配所需内存,存储相关的信息,如在会
话内存存储相关的登录信息等。
3.服务器进程把这个 sql 语句的字符转化为 ASCII 等效数字码,接着这个 ASCII 码被传递给一个
HASH 函数,并返回一个 hash 值,然后服务器进程将到shared pool 中的 library cache 中去查找是否存在相
同的 hash 值,如果存在,服务器进程将使用这条语句已高速缓存在 SHARED POOL 的library cache 中的已
分析过的版本来执行。
4.如果不存在,服务器进程将在 CGA 中,配合 UGA 内容对 sql,进行语法分析,首先检查语法的正确性,接
着对语句中涉及的表,索引,视图等对象进行解析,并对照数据字典检查这些对象的名称以及相关结构，并根据
ORACLE 选用的优化模式以及数据字典中是否存在相应对象的统计数据和是否使用了存储大纲来生成一个
执行计划或从存储大纲中选用一个执行计划,然后再用数据字典核对此用户对相应对象的执行权限,最后生成
一个编译代码。
5.ORACLE 将这条 sql 语句的本身实际文本、HASH 值、编译代码、与此语名相关联的任何统计数据
和该语句的执行计划缓存在 SHARED POOL 的 library cache中。服务器进程通过 SHARED POOL 锁存
器(shared pool latch)来申请可以向哪些共享 PL/SQL 区中缓存这此内容,也就是说被SHARED POOL 锁存
器锁定的 PL/SQL 区中的块不可被覆盖,因为这些块可能被其它进程所使用。
6.在 SQL 分析阶段将用到 LIBRARY
CACHE,从数据字典中核对表、视图等结构的时候,需要将数据
字典从磁盘读入 LIBRARY
CACHE,因此,在读入之前也要使用LIBRARY
CACHE 锁存器(library cache
pin,library cache lock)来申请用于缓存数据字典。 到现在为止,这个 sql 语句已经被编译成可执行的代码了,
但还不知道要操作哪些数据,所以服务器进程还要为这个 sql 准备预处理数据。
7.首先服务器进程要判断所需数据是否在 db buffer 存在,如果存在且可用,则直接获取该数据,同时根据
LRU 算法增加其访问计数;如果 buffer 不存在所需数据,则要从数据文件上读取首先服务器进程将在表头部
请求 TM 锁(保证此事务执行过程其他用户不能修改表的结构),如果成功加 TM 锁,再请求一些行级锁(TX
锁),如果 TM、TX 锁都成功加锁,那么才开始从数据文件读数据,在读数据之前,要先为读取的文件准备好
buffer 空间。服务器进程需要扫面 LRU list 寻找 free db buffer,扫描的过程中,服务器进程会把发现的所有
已经被修改过的 db buffer 注册到 dirty list 中, 这些 dirty buffer 会通过 dbwr 的触发条件,随后会被写出到
数据文件,找到了足够的空闲 buffer,就可以把请求的数据行所在的数据块放入到 db buffer 的空闲区域或者
覆盖已经被挤出 LRU list 的非脏数据块缓冲区,并排列在 LRU list 的头部,也就是在数据块放入 DB
BUFFER 之前也是要先申请 db buffer 中的锁存器,成功加锁后,才能读数据到 db buffer。
8.记日志 现在数据已经被读入到 db buffer 了,现在服务器进程将该语句所影响的并被读
入 db buffer 中的这些行数据的 rowid 及要更新的原值和新值及 scn 等信息从 PGA 逐条的写入 redo log
buffer 中。在写入 redo log buffer 之前也要事先请求 redo log buffer 的锁存器,成功加锁后才开始写入,当
写入达到 redo log buffer 大小的三分之一或写入量达到 1M 或超过三秒后或发生检查点时或者 dbwr 之前
发生,都会触发 lgwr 进程把 redo log buffer 的数据写入磁盘上的 redo file 文件中(这个时候会产生log file
sync 等待事件)
已经被写入 redofile 的 redo log buffer 所持有的锁存器会被释放,并可被后来的写入信息覆盖,
redo log buffer是循环使用的。Redo file 也是循环使用的,当一个 redo file 写满后,lgwr 进程会自动切换到
下一 redo file(这个时候可能出现 log fileswitch(checkpoint complete)等待事件)。如果是归档模式,归档进
程还要将前一个写满的 redo file 文件的内容写到归档日志文件中(这个时候可能出现 log file
switch(archiving needed)。
9.为事务建立回滚段 在完成本事务所有相关的 redo log buffer 之后,服务器进程开始改写这个 db buffer
的块头部事务列表并写入 scn,然后 包含这个块的头部事务列表及 scn 信息的数据副本放入回滚段中,将
这时回滚段中的信息称为数据块的“前映像“,这个”前映像“用于以后的回滚、恢复和一致性读。(回滚段可以
存储在专门的回滚表空间中,这个表空间由一个或多个物理文件组成,并专用于回滚表空间,回滚段也可在其它
表空间中的数据文件中开辟。
10.本事务修改数据块 准备工作都已经做好了,现在可以改写 db buffer 块的数据内容了,并在块的头部写
入回滚段的地址。
11.放入 dirty list 如果一个行数据多次 update 而未 commit,则在回滚段中将会有多个“前映像“,除了第
一个”前映像“含有 scn 信息外,其他每个“前映像“的头部都有 scn 信息和“前前映像”回滚段地址。一个
update 只对应一个 scn,然后服务器进程将在 dirty list 中建立一
条指向此 db buffer 块的指针(方便 dbwr 进程可以找到 dirty list 的 db buffer 数据块并写入数据文件中)。
接着服务器进程会从数据文件中继续读入第二个数据块,重复前一数据块的动作,数据块的读入、记日志、建
立回滚段、修改数据块、放入 dirty list。当 dirty queue 的长度达到阀值(一般是 25%),服务器进程将通知
dbwr 把脏数据写出,就是释放 db buffer 上的锁存器,腾出更多的 free db buffer。前面一直都是在说明
oracle 一次读一个数据块,其实 oracle 可以一次读入多个数据块(db_file_multiblock_read_count 来设置一
次读入块的个数)
说明:
在预处理的数据已经缓存在 db buffer 或刚刚被从数据文件读入到 db buffer 中,就要根据 sql 语句
的类型来决定接下来如何操作。
1>如果是 select 语句,则要查看 db buffer 块的头部是否有事务,如果有事务,则从回滚段中读取数据;如
果没有事务,则比较 select 的 scn 和 db buffer 块头部的 scn,如果前者小于后者,仍然要从回滚段中读取数据;
如果前者大于后者,说明这是一非脏缓存,可以直接读取这个 db buffer 块的中内容。
2>如果是 DML 操作,则即使在 db buffer 中找到一个没有事务,而且 SCN 比自己小的非脏
缓存数据块,服务器进程仍然要到表的头部对这条记录申请加锁,加锁成功才能进行后续动作,如果不成功,则要
等待前面的进程解锁后才能进行动作(这个时候阻塞是 tx 锁阻塞)。
用户 commit 或 rollback 到现在为止,数据已经在 db buffer 或数据文件中修改完
成,但是否要永久写到数文件中,要由用户来决定 commit(保存更改到数据文件) rollback 撤销数据的更改)。
1.用户执行 commit 命令
只有当 sql 语句所影响的所有行所在的最后一个块被读入 db buffer 并且重做信息被写入 redo log
buffer(仅指日志缓冲区,而不包括日志文件)之后,用户才可以发去 commit 命令,commit 触发 lgwr 进程,但不
强制立即 dbwr来释放所有相应 db buffer 块的锁(也就是no-force-at-commit,即提交不强制写),也就是说有
可能虽然已经 commit 了,但在随后的一段时间内 dbwr 还在写这条 sql 语句所涉及的数据块。表头部的行锁
并不在 commit 之后立即释放,而是要等 dbwr 进程完成之后才释放,这就可能会出现一个用户请求另一用户
已经 commit 的资源不成功的现象。
A .从 Commit 和 dbwr 进程结束之间的时间很短,如果恰巧在 commit 之后,dbwr 未结束之前断电,因为
commit 之后的数据已经属于数据文件的内容,但这部分文件没有完全写入到数据文件中。所以需要前滚。由
于 commit 已经触发 lgwr,这些所有未来得及写入数据文件的更改会在实例重启后,由 smon 进程根据重做日
志文件来前滚,完成之前 commit 未完成的工作(即把更改写入数据文件)。
B.如果未 commit 就断电了,因为数据已经在 db buffer 更改了,没有 commit,说明这部分数据不属于数
据文件,由于 dbwr 之前触发 lgwr 也就是只要数据更改,(肯定要先有 log) 所有 DBWR,在数据文件上的修改
都会被先一步记入重做日志文件,实例重启后,SMON 进程再根据重做日志文件来回滚。
其实 smon 的前滚回滚是根据检查点来完成的,当一个全部检查点发生的时候,首先让 LGWR 进程将
redo log buffer 中的所有缓冲(包含未提交的重做信息)写入重做日志文件,然后让 dbwr 进程将 db buffer 已
提交的缓冲写入数据文件(不强制写未提交的)。然后更新控制文件和数据文件头部的 SCN,表明当前数据库
是一致的,在相邻的两个检查点之间有很多事务,有提交和未提交的。
像前面的前滚回滚比较完整的说法是如下的说明:
A.发生检查点之前断电,并且当时有一个未提交的改变正在进行,实例重启之后,SMON 进程将从上一个
检查点开始核对这个检查点之后记录在重做日志文件中已提交的和未提交改变,因为
dbwr 之前会触发 lgwr,所以 dbwr 对数据文件的修改一定会被先记录在重做日志文件中。因此,断电前被
DBWN 写进数据文件的改变将通过重做日志文件中的记录进行还原,叫做回滚,
B. 如果断电时有一个已提交,但 dbwr 动作还没有完全完成的改变存在,因为已经提交,提交会触发 lgwr
进程,所以不管 dbwr 动作是否已完成,该语句将要影响的行及其产生的结果一定已经记录在重做日志文件中
了,则实例重启后,SMON 进程根据重做日志文件进行前滚.
实例失败后用于恢复的时间由两个检查点之间的间隔大小来决定,可以通个四个参数设置检查点执行的频
率:
Log_checkpoint_interval:
决定两个检查点之间写入重做日志文件的系统物理块(redo blocks)
的大小,默认值是 0,无限制。
log_checkpoint_timeout:
两 个 检 查 点 之 间 的 时 间 长 度（秒）默 认 值 1800s。
fast_start_io_target:
决定了用于恢复时需要处理的块的多少,默认值是 0,无限制。
fast_start_mttr_target:
直接决定了用于恢复的时间的长短,默认值是 0,无限制(SMON 进程执行的前滚
和回滚与用户的回滚是不同的,SMON 是根据重做日志文件进行前滚或回滚,而用户的回滚一定是根据回滚段
的内容进行回滚的。
在这里要说一下回滚段存储的数据,假如是 delete 操作,则回滚段将会记录整个行的数据,假如是 update,
则回滚段只记录被修改了的字段的变化前的数据(前映像),也就是没有被修改的字段是不会被记录的,假如是
insert,则回滚段只记录插入记录的 rowid。 这样假如事务提交,那回滚段中简单标记该事务已经提交;假如是
回退,则如果操作是 delete,回退的时候把回滚段中数据重新写回数据块,操作如果是 update,则把变化前数据
修改回去,操作如果是 insert,则根据记录的 rowid 把该记录删除。
2.如果用户 rollback。
则服务器进程会根据数据文件块和 DB BUFFER 中块的头部的事务列表和 SCN 以及回滚段地址找到
回滚段中相应的修改前的副本,并且用这些原值来还原当前数据文件中已修改但未提交的改变。如果有多个
“前映像”,服务器进程会在一个“前映像”的头部找到“前前映像”的回滚段地址,一直找到同一事务下的最早的
一个“前映像”为止。一旦发出了 COMMIT,用户就不能rollback,这使得 COMMIT 后 DBWR 进程还没有
全部完成的后续动作得到了保障。到现在为例一个事务已经结束了。
说明:
TM 锁:
符合 lock 机制的,用于保护对象的定义不被修改。 TX 锁:
这个锁代表一个事务,是行
级锁,用数据块头、数据记录头的一些字段表示,也是符合 lock 机制,有 resource structure、lock
structure、enqueue 算法。
9. 将MySQL数据库移植为PostgreSQL
在北美，人们对于
PostgreSQL
的热情不断升温。随着
PostgreSQL
的发展，
PostgreSQL
8.x
已经从技术上超越
MySQL
5.x
，而市场的超越相信只是时间问题。而最终，用户也许有机会享受到可媲美
Oracle
的开源数据库也未尝没有可能。
我供职的互联网公司，服务约
50
万商务用户，经过多次的升级移植，目前公司已经全部将后台数据库从
MySQL
移植到
PostgreSQL
，而个人完成了其中一半的数据库移植工作，所以对数据库从
MySQL
移植到
PostgreSQL
积累了一些经验。在此整理成文，希望能对大家使用
PostgreSQL
有一些启发。
1）
准备：
使用
MySQL
数据备份工具对数据库进行全备份：
mysqlmp
-h
[hostname]
-u
[username]
-p
[password]
--extended-insert=false
[dbname]
>
mysql-db.sql
注意
disable
extended-insert
，
PostgreSQL
不支持
MySQL
的
extended-insert
2)
转化：
将
mysql-db.sql
转为
PostgreSQL
可以导入的
SQL
Script.
MySQL
和
PostgreSQL
在
SQL
语义上存在一定差异，比如
MySQL
不支持
sequence
，触发器等功能，但为此又提供了一些自有的语法规则，而对比一些系统函数，
MySQL
和
PostgreSQL
又存在比较大的差别。为此，我编写了一段语义分析和转化的程序
mysql2psql
>mysql2psql
mysql-db.sql
postgres-db.sql
3)
导入：
使用
PostgreSQL
提供的
pgAdmin
将数据文件导入数据库。
4)
SQL
语句的修改：
在实际的应用中，前端的系统往往会嵌入一些具有数据库特性的
SQL
语句，而随着后台数据库的改变，前端的系统程序也同样需要做出相应的修改。
MySQL
和
PostgreSQL
最常见的不同之处包括：Group
by，Join的使用差异，系统函数的命名和调用的差异等等。
10. 什么是sql注入如何防止sql注入
SQL注入是一种非常常见的数据库攻击手段，同时也是网络世界中最普遍的漏洞之一，简单理解就是恶意用户通过在表单中填写包含SQL关键字的数据来使数据库执行非常规代码的过程。
问题来源是，SQL数据库的操作是通过SQL语句来执行的，而无论是执行代码还是数据项都必须写在SQL语句中，也就导致如果我们在数据项中加入了某些SQL语句关键字，比如SELECT、DROP等，这些关键字就很有可能在数据库写入或读取数据时得到执行。
解决方案
方案一：
采用预编译技术
使用预编译的SQL语句，SQL语句的语义不会是不会发生改变的。预编译语句在创建的时候就已经将指定的SQL语句发送给了DBMS，完成了解析，检查，编译等工作，所以攻击者无法改变SQL语句的结构，只是把值赋给?，然后将?这个变量传给SQL语句。当然还有一些通过预编译绕过某些安全防护的操作，大家感兴趣可以去搜索一下。
方案二：
严格控制数据类型
在java、c等强类型语言中一般是不存在数字型注入的，因为在接受到用户输入id时，代码一般会做一个int id 的数据类型转换，假如我们输入的是字符串的话，那么这种情况下，程序就会报错。但是在PHP、ASP这些没有强调处理数据类型的语言，一般我们看到的接收id的代码都是如下等代码。
方案三：
对特殊的字符进行转义
数字型注入可以通过检查数据类型防止，但是字符型不可以，那么怎么办呢，最好的办法就是对特殊的字符进行转义了。比如在MySQL中我们可以对" '
"进行转义，这样就防止了一些恶意攻击者来闭合语句。当然我们也可以通过一些安全函数来转义特殊字符。如addslashes()等，但是这些函数并非一劳永逸，攻击者还可以通过一些特殊的方式绕过。