如何使用oracle提供的SQL_TRACE来跟踪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 during 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 dump。JVM (java虚拟机)记录下问题发生时系统的运行状态并将其存储在转储(dump)文件中。Heap dump就是这样一种文件形式。

　　线程视图比较关心线程的当前执行状态，这里可以生成另一种转储文件 Java dump。Java dump，也叫做 Thread dump，是 JVM 故障诊断中最重要的转储文件之一。JVM 的许多问题都可以使用这个文件进行诊断，其中比较典型的包括线程阻塞，CPU 使用率过高，JVM Crash，堆内存不足，和类装载等问题。其中线程阻塞更加常见。

原文转自：http://blog.csdn.net/xuyubotest/article/details/8158241