oracle重新生成执行计划语句,oracle,导出,执行计划.docx

oracle,导出,执行计划

1.最简单的办法　　执行完语句后，会显示explainplan与统计信息。这个语句的优点就是它的缺点，这样在用该方法查看执行时间较长的sql语句时，需要等待该语句执行成功后，才返回执行计划，使优化的周期大大增长。　　这样，就只会列出执行计划，而不会真正的执行语句，大大减少了优化时间。虽然也列出了统计信息，但是因为没有执行语句，所以该统计信息没有用处，如果执行该语句时遇到错误，解决方法为：　　(1)在要分析的用户下　　(2)用sys用户登陆　　2.用explainplan命令　　(1)sqlplus>@?\rdbms\admin\　　(2)sqlplus>explainplansetstatement_id=’???’forselect………………　　注意，用此方法时，并不执行sql语句，所以只会列出执行计划，不会列出统计信息，并且执行计划只存在plan_table中。所以该语句比起setautotracetraceonly可用性要差。需要用下面的命令格式化输出，所以这种方式我用的不多。　　上面这2种方法只能为在本会话中正在运行的语句产生执行计划，即我们需要已经知道了哪条语句运行的效率很差，我们是有目的只对这条SQL语句去优化。其实，在很多情况下，我们只会听一个客户抱怨说现在系统运行很慢，而我们不知道是哪个SQL引起的。此时有许多现成的语句可以找出耗费资源比较多的语句。　　从而对找出的语句进行进一步优化。当然我们还可以为一个正在运行的会话中运行的所有SQL语句生成执行计划，这需要对该会话进行跟踪，产生trace文件，然后对该文件用tkprof程序格式化一下，这种得到执行计划的方式很有用，因为它包含其它额外信息，如SQL语句执行的每个阶段(如Parse、Execute、Fetch)分别耗费的各个资源情况(如CPU、DISK、elapsed等)。　　3.用dbms_system存储过程Oracle生成执行计划　　因为使用dbms_system存储过程可以跟踪另一个会话发出的sql语句，并记录所使用的执行计划，而且还提供其它对性能调整有用的信息。因其使用方式与上面2种方式有些不太一样，所以在附录中单独介绍。这种方法是对SQL进行调整比较有用的方式之一，有些情况下非它不可。具体内容参见附录。　　文章　　--------------------------------------------------------------------------　　|0|SELECTSTATEMENT||8|64|2(0)|00:00:01|　　|1|TABLEACCESSFULL|DAVE|8|64|2(0)|00:00:01|　　--------------------------------------------------------------------------　　统计信息　　----------------------------------------------------------　　0recursivecalls　　0dbblockgets　　4consistentgets　　0physicalreads　　0redosize　　609bytessentviaSQL*Nettoclient　　416bytesreceivedviaSQL*Netfromclient　　2SQL*Netroundtripsto/fromclient　　0sorts(memory)　　0sorts(disk)　　8rowsprocessed　　SQL>　　使用SQL　　SQL>EXPLAINPLANFORsql语句;　　SQL>SELECTplan_table_outputFROMTABLE(DBMS_('PLAN_TABLE'));示例：　　SQL>EXPLAINPLANFORSELECT*FROMDAVE;　　已解释。　　SQL>SELECTplan_table_outputFROMTABLE(DBMS_('PLAN_TABLE'));或者：　　SQL>select*fromtable(dbms_);　　PLAN_TABLE_OUTPUT　　--------------------------------------------------------------------------------　　Planhashvalue:　　--------------------------------------------------------------------------　　|Id|Operation|Nam