❶ 在ORACLE中，如何找到任意sql字符串中的表，并将表进行指定规则的替换，比如在表名后加DBLINK
动态SQL 实质就是执行的SQL字符串，所以你完全可以用拼接的方式，先把 字符串 拼接出来，然后用execute immediate 'sql' 来执行；
至于如果拼接出来 SQL，那就需要你去找规律，其唯伏实你可以对字符串做对此拼接，例如一下：str1 :='SELECT QW,QE,QR FROM Q WHERE Q=1'态模;
str2 :='SELECT QW,COUNT(1) FROM EW,' || str1 || 'WHERE EW=QW GROUP BY QW;'
这类问题 完全属于个别案例，因为SQL的规律只有你自己最清楚，谁帆山缓都无法提供一个完整的解决方案！
❷ 怎么查看oracle数据库表的sql语句
装一个PL/SQL或者toad三方软件，可以查看表和视图的sql语句。还有其他的功能，很方便。比较推荐toad
❸ 怎样查看oracle中创建建表的sql语句
打开PL/SQL Developer，找到tables底下对应的表，右键选择“查看”菜单，右下角有个“查看SQL”的按钮，点下就可以看到建笑祥表语句了。或者“新建”-->“SQL窗口”，然后输入表名，右键选择“查看”菜单，再点击“查看SQL”按钮碰圆搏。
❹ oracle查看sql来自哪里
查看SESSION就可以看到相应SQL语句。
或者通过以下语句查看
select sid,
v$session.username 用户名,
last_call_et 持罩租续时间,
status 状态物埋兆,
LOCKWAIT 等待锁,
machine 用户电脑名,
logon_time 开始登液仿入时间,
sql_text
from v$session, v$process, v$sqlarea
where paddr = addr
and sql_hash_value = hash_value
and status = 'ACTIVE'
and v$session.username isnotnull
orderby last_call_et desc;
❺ 如何查看oracle服务器上正在执行的SQL语句
首先，你要以dba身份登陆数据库。 第二，为某个用户开启sql跟踪。那个用户就是你要跟踪的、正在执行sql语句的那个用户。命令如下： execute dbms_system.set_sql_trace_in_session(sid,serial#,true) 其中参数的意义是，sid-会话id，serial#-序列号，这两个参数可以从v$session中得到。 第三，上面的命令执行成功之后数据库就自动对该用户所发出的所有sql语句进行跟踪，并把结果写在用户跟踪文件里。用户跟踪文件存放在数据库服务器上，路径请参考init.ora文件中的ump参数值。文件名为ora_sid_xxxx.trc(for unix)或者oraxxxxx.trc(for NT)，其中xxxx文件系统进程编号，这个编号可以从v$process和v$session两个表通过关联的方式查询得到。
❻ 如何查看Oracle执行的sql
Select /*a.Sid,
a.SERIAL#,
a.status,
a.USERNAME, --哪个用户运行的SQL*/
d.SPID 进程号,
b.sql_text SQL内容,
a.MACHINE 计算机名称,
a.MODULE 运行方式,
to_char(cast((c.sofar / totalwork * 100) as decimal(18, 1))) || '%' 执行百分比,
c.elapsed_seconds 已耗时_秒,
c.time_remaining 预计剩余_秒猜罩雹,
cast(c.elapsed_seconds / 60 as decimal(18, 2)) 已耗时_分,
cast(c.time_remaining / 60 as decimal(18, 2)) 预计剩余_分,
cast(c.elapsed_seconds / 3600 as decimal(18, 2)) 已闷肢耗时穗帆_时,
cast(c.time_remaining / 3600 as decimal(18, 2)) 预计剩余_时
from v$session a, v$sqlarea b, v$session_longops c, v$process d
where a.sql_hash_value = b.HASH_VALUE
and a.sid = c.sid(+)
and a.SERIAL# = c.SERIAL#(+)
--and to_char(cast((c.sofar / totalwork * 100) as decimal(18, 1))) <> '100'
and a.PADDR = d.ADDR;
❼ 怎样查找oracle并行查询sql
直接用hint即可。例如：select/*+parallel(o2)*/粗前厅*fromt_objectso其中o为要开启并岩隐行的表的别名，2为并行度。不过不一定会提升效率，一般查询中使用parallel的情景如下：需要大量的表的扫描、连接或悔纤者分区索引扫描。聚合操作（计数）。
❽ 如何查找Oracle中存在全表扫描的SQL语句
1． 对返回的行无任何限定条件，即没有where 子句
2． 未对数据表与任何索引主列相对应的行限定条件
例如：在City-State-Zip列创建了三列复合索引，那么仅对State列限定条件不能使用这个索引，因为State不是索引的主列。
3． 对索引的主列有限定条件，但是在条件表达式里使用以下表达式则会使索引失效，造成全表扫描：
（1）where子句中对字段进行函数、表达式操作，这将导致引擎放弃使用索引而进行全表扫描,
Demo:
where upper(city)='TokYo' 或 City || 'X' like 'TOKYO%',
select id from t where num/2=100 应改为: select id from t where num=100*2
select * from emp where to_char(hire_date,'yyyymmdd')='20080411' (不使用)
select * from emp where hire_date = to_char('20080411','yyyymmdd') (使用)
（2）查询字段is null时索引失效，引起全表扫描。
where City is null 或 ,where City is not null,
解决方法：SQL语法中使用NULL会有很多麻烦，最好索引列都是NOT NULL的；对于is null，可以建立组合索引，nvl(字段,0),对表和索引analyse后，is null查询时可以重新启用索引查找,但是效率还不是值得肯定；is not null 时永远不会使用索引。一般数据量大的表不要用is null查询。
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
(3)查询条件中使用了不等于操作符（<>、!=）会限制索引、引起全表扫描
Where city!='TOKYO'.
解决方法：通过把不等于操作符改成or，可以使用索引，避免全表扫描。例如，把column<>’aaa’，改成column<’aaa’ or column>’aaa’，就可以使用索引了。
(4)对索引的主列有限定条件，但是条件使用like操作以及值以‘%’开始或者值是一个赋值变量。例如：
where City like '%YOK%'
where City like: City_bind_Variable xl_rao
select * from emp where name like '%A' (不使用索引)
select * from emp where name like 'A%' (使用索引)
解决办法：首先尽量避免模糊查询，如果因为业务需要一定要使用模糊查询，则至少保证不要使用全模糊查询，对于右模糊查询，即like ‘…%’，是会使用索引的；左模糊like ‘%...’无法直接使用索引，但可以利用reverse + function index 的形式，变化成 like ‘…%’；全模糊是无法优化的，一定要的话考虑用搜索引擎。出于降低数据库服务器的负载考虑，尽可能地减少数据库模糊查询。
4． or语句使用不当会引起全表扫描
原因：where子句中比较的两个条件，一个有索引，一个没索引，使用or则会引起全表扫描。例如：where A=：1 or B=：2，A上有索引，B上没索引，则比较B=：2时会重新开始全表扫描
5．模糊查询效率很低：
原因：like本身效率就比较低，应该尽量避免查询条件使用like；对于like‘%...%’（全模糊）这样的条件，是无法使用索引的，全表扫描自然效率很低；另外，由于匹配算法的关系，模糊查询的字段长度越大，模糊查询效率越低。
解决办法：首先尽量避免模糊查询，如果因为业务需要一定要使用模糊查询，则至少保证不要使用全模糊查询，对于右模糊查询，即like‘…%’，是会使用索引的；左模糊like
‘%...’无法直接使用索引，但可以利用reverse + function index的形式，变化成like‘…%’；全模糊是无法优化的，一定要的话考虑用搜索引擎。出于降低数据库服务器的负载考虑，尽可能地减少数据库模糊查询。
6．查询条件中含有is null的select语句执行慢
原因：Oracle 中，查询字段is null时单索引失效，引起全表扫描。
解决方法：SQL语法中使用NULL会有很多麻烦，最好索引列都是NOT NULL的；对于is null，可以建立组合索引，nvl(字段,0),对表和索引analyse后，is null查询时可以重新启用索引查找,但是效率还不是值得肯定；is not null时永远不会使用索引。一般数据量大的表不要用is null查询。
7.查询条件中使用了不等于操作符（<>、!=）的select语句执行慢
原因：SQL中，不等于操作符会限制索引，引起全表扫描，即使比较的字段上有索引
解决方法：通过把不等于操作符改成or，可以使用索引，避免全表扫描。例如，把column<>’aaa’，改成column<’aaa’or column>’aaa’，就可以使用索引了。
8.使用组合索引，如果查询条件中没有前导列，那么索引不起作用，会引起全表扫描；但是从Oracle9i开始，引入了索引跳跃式扫描的特性，可以允许优化器使用组合索引，即便索引的前导列没有出现在WHERE子句中。例如：create index skip1 on emp5(job,empno); 全索引扫描select count(*) from emp5 where empno=7900; 索引跳跃式扫描select /*+ index(emp5 skip1)*/ count(*) from emp5 where empno=7900;前一种是全表扫描，后一种则会使用组合索引。
9. or语句使用不当会引起全表扫描
原因：where子句中比较的两个条件，一个有索引，一个没索引，使用or则会引起全表扫描。例如：where A=：1 or B=：2，A上有索引，B上没索引，则比较B=：2时会重新开始全表扫描。
10.组合索引，排序时应按照组合索引中各列的顺序进行排序，即使索引中只有一个列是要排序的，否则排序性能会比较差。例如：create index skip1 on emp5(job,empno，date); select job，empno from emp5 where job=’manager’and empno=’10’order by job,empno,date desc;实际上只是查询出符合job=’manager’and empno=’10’条件的记录并按date降序排列，但是写成order by date desc性能较差。
11.Update语句，如果只更改1、2个字段，不要Update全部字段，否则频繁调用会引起明显的性能消耗，同时带来大量日志。
12.对于多张大数据量的表JOIN，要先分页再JOIN，否则逻辑读会很高，性能很差。
13.select count(*) from table；这样不带任何条件的count会引起全表扫描，并且没有任何业务意义，是一定要杜绝的。
14.sql的where条件要绑定变量，比如where column=：1，不要写成where column=‘aaa’，这样会导致每次执行时都会重新分析，浪费CPU和内存资源。
15.不要使用in操作符，这样数据库会进行全表扫描，
推荐方案：在业务密集的SQL当中尽量不采用IN操作符
16.not in 使用not in也不会走索引
推荐方案：用not exists或者（外联结+判断为空）来代替
17.> 及 < 操作符（大于或小于操作符）
大于或小于操作符一般情况下是不用调整的，因为它有索引就会采用索引查找，但有的情况下可以对它进行优化，如一个表有100万记录，一个数值型字段 A，30万记录的A=0，30万记录的A=1，39万记录的A=2，1万记录的A=3。那么执行A>2与A>=3的效果就有很大的区别了，因为A>2时ORACLE会先找出为2的记录索引再进行比较，而A>=3时ORACLE则直接找到=3的记录索引。
18.UNION操作符
UNION在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。实际大部分应用中是不会产生重复的记录，最常见的是过程表与历史表UNION。如：
select * from gc_dfys
union
select * from ls_jg_dfys
这个SQL在运行时先取出两个表的结果，再用排序空间进行排序删除重复的记录，最后返回结果集，如果表数据量大的话可能会导致用磁盘进行排序。
推荐方案：采用UNION ALL操作符替代UNION，因为UNION ALL操作只是简单的将两个结果合并后就返回。
19.WHERE后面的条件顺序影响
WHERE子句后面的条件顺序对大数据量表的查询会产生直接的影响，如
Select * from zl_yhjbqk where dy_dj = '1K以下' and xh_bz=1
Select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1K以下'
以上两个SQL中dy_dj及xh_bz两个字段都没进行索引，所以执行的时候都是全表扫描，第一条SQL的dy_dj = '1KV以下'条件在记录集内比率为99%，而xh_bz=1的比率只为0.5%，在进行第一条SQL的时候99%条记录都进行dy_dj及xh_bz的比较，而在进行第二条SQL的时候0.5%条记录都进行dy_dj及xh_bz的比较，以此可以得出第二条SQL的CPU占用率明显比第一条低。
20.查询表顺序的影响
在FROM后面的表中的列表顺序会对SQL执行性能影响，在没有索引及ORACLE没有对表进行统计分析的情况下ORACLE会按表出现的顺序进行链接，由此因为表的顺序不对会产生十分耗服务器资源的数据交叉。（注：如果对表进行了统计分析，ORACLE会自动先进小表的链接，再进行大表的链接）
❾ 如何查找Oracle中存在全表扫描的SQL语句
对于SQL的执行计划，歼或旁一般尽量避免TABLE ACCESS FULL的出现，那怎样去定位，系统里面哪些氏橡SQL脚本存在TABLE ACCESS FULL行为，对于9i及以后版本，使用以团肆下语句即可
1
2
3
4
5
select *
from v$sql_plan v
where v.operation = 'TABLE ACCESS'
and v.OPTIONS = 'FULL'
and v.OBJECT_OWNER='MS';--指定用户下
查询得到SQL_ID，以及ADDRESS,HASH_VALUE,PLAN_HASH_VALUE,OBJECT_NAME后，就可以定位到具体的SQL语句了。
如：
select s.SQL_TEXT
from v$sqlarea s
where s.SQL_ID = '4dpd97jh2gzsd'
and s.HASH_VALUE = '1613233933'
and s.PLAN_HASH_VALUE = '3592287464';
或者
1
select s.SQL_TEXT from v$sqlarea s where s.ADDRESS = '00000000A65D2318';
❿ oracle如何查看运行了什么sql
一、通过PL/SQL Dev工具
1、直接File->New->Explain Plan Window，在窗口中执行sql可以查看计划结果。其中，Cost表示cpu的消耗，单位为n%，Cardinality表示执行的行数，等价Rows。
2、先执行 EXPLAIN PLAN FOR select * from tableA where paraA=1，再 select * from table(DBMS_XPLAN.DISPLAY)便可以看到oracle的执行计划了，看到的结果和1中的一样，所以使用工具的时候推荐使用1方法。
注意：PL/SQL Dev工具的Command window中不支持set autotrance on的命令。还有使用工具方法查看计划看到的信息不全，有些时候我们需要sqlplus的支持。
二、通过sqlplus
1．最简单的办法
Sql> set autotrace on
Sql> select * from al;
执行完语句后，会显示explain plan 与 统计信息。
这个语句的优点就是它的缺点，这样在用该方法查看执行时间较长的sql语句时，需要等待该语句执行成功后，才返回执行计划，使优化的周期大大增长。如果不想执行语句而只是想得到执行计划可以采用：
Sql> set autotrace traceonly
这样，就只会列出执行计划，而不会真正的执行语句，大大减少了优化时间。虽然也列出了统计信息，但是因为没有执行语句，所以该统计信息没有用处，如果执行该语句时遇到错误，解决方法为：
(1）在要分析的用户下：
Sqlplus > @ ?
dbmsadminutlxplan.sql
(2) 用sys用户登陆
Sqlplus > @ ?sqlplusadminplustrce.sql
Sqlplus > grant plustrace to user_name;
- - user_name是上面所说的分析用户
2．用explain plan命令
(1) sqlplus > explain plan for select * from testdb.myuser
(2) sqlplus > select * from table(dbms_xplan.display);
上面这2种方法只能为在本会话中正在运行的语句产生执行计划，即我们需要已经知道了哪条语句运行的效率很差，我们是有目的只对这条SQL语句去优化。其实，在很多情况下，我们只会听一个客户抱怨说现在系统运行很慢，而我们不知道是哪个SQL引起的。此时有许多现成的语句可以找出耗费资源比较多的语句，如：
SELECT ADDRESS, substr(SQL_TEXT,1,20) Text, buffer_gets, executions,
buffer_gets/executions AVG FROM v$sqlarea
WHERE executions>0 AND buffer_gets > 100000 ORDER BY 5;
ADDRESS TEXT BUFFER_GETS EXECUTIONS AVG
-------- ---------------------------------------- ----------- ---------- ------------------------------------------------------------
66D83D64 select t.name, (sel 421531 60104 7.01336017
66D9E8AC select t.schema, t.n 1141739 2732 417.913250
66B82BCC select s.synonym_nam 441261 6 73543.5
从而对找出的语句进行进一步优化。当然我们还可以为一个正在运行的会话中运行的所有SQL语句生成执行计划，这需要对该会话进行跟踪，产生trace文件，然后对该文件用tkprof程序格式化一下，这种得到执行计划的方式很有用，因为它包含其它额外信息，如SQL语句执行的每个阶段(如Parse、Execute、Fetch)分别耗费的各个资源情况(如CPU、DISK、elapsed等)。
3、启用SQL_TRACE跟踪所有后台进程活动：
全局参数设置： .OracleHome/admin/SID/pfile中指定: SQL_TRACE = true (10g)
当前session中设置：
SQL> alter session set SQL_TRACE=true;
SQL> select * from al;
SQL> alter session set SQL_TRACE=false;
对其他用户进行跟踪设置：
SQL> select sid,serial#,username from v$session where username='XXX';
SID SERIAL# USERNAME
------ ---------- ------------------
127 31923 A
128 54521 B
开启跟踪:SQL> exec dbms_system.set_SQL_TRACE_in_session(127,31923,true);
关闭跟踪:SQL> exec dbms_system.set_SQL_TRACE_in_session(127,31923,false);
然后使用oracle自带的tkprof命令行工具格式化跟踪文件。
4、使用10046事件进行查询：
10046事件级别：
Lv1 - 启用标准的SQL_TRACE功能,等价于SQL_TRACE
Lv4 - Level 1 + 绑定值(bind values)
Lv8 - Level 1 + 等待事件跟踪
Lv12 - Level 1 + Level 4 + Level 8
全局设定：
OracleHome/admin/SID/pfile中指定: EVENT="10046 trace name context forever,level 12"
当前session设定：
开启:SQL> alter session set events '10046 trace name context forever, level 8';
关闭:SQL> alter session set events '10046 trace name context off';
对其他用户进行设置：
SQL> select sid,serial#,username from v$session where username='XXX';
SID SERIAL# USERNAME
------ ---------- ------------------
127 31923 A
SQL> exec dbms_system.set_ev(127,31923,10046,8,'A');
5、使用tkprof格式化跟踪文件： (根据下面SQL语句得到的文件都不存在该目录下,郁闷啊,懵懂啊...)
一般，一次跟踪可以分为以下几步：
1、界定需要跟踪的目标范围，并使用适当的命令启用所需跟踪。
2、经过一段时间后，停止跟踪。此时应该产生了一个跟踪结果文件。
3、找到跟踪文件，并对其进行格式化，然后阅读或分析。
--使用一下SQL找到当前session的跟踪文件：
SELECT d.value|| '/' ||lower(rtrim(i.instance, chr( 0 )))|| '_ora_' ||p.spid|| '.trc' trace_file_namefrom( select p.spid from v$mystat m,v$session s, v$process pwhere m.statistic# = 1 and s.sid = m.sid and p.addr = s.paddr) p,( select t.instance from v$thread t,v$parameter vwhere v.name = 'thread' and (v.value = 0 or t.thread# = to_number(v.value))) i,( select value from v$parameter where name = 'user_mp_dest' ) d;-- 其它用户的 session SELECT d.value|| '/' ||lower(rtrim(i.instance, chr( 0 )))|| '_ora_' ||p.spid|| '.trc' trace_file_name from ( select p.spid from v$session s, v$process p where s.sid= '27' and s. SERIAL#= '30' and p.addr = s.paddr) p, ( select t.instance from v$thread t,v$parameter v where v.name = 'thread' and (v.value = 0 or t.thread# = to_number(v.value))) i, ( select value from v$parameter where name = 'user_mp_dest' ) d;
--查找后使用tkprof命令,将TRACE文件格式为到D盘的explain_format.txt文件中
SQL> $tkprof d:/oracle/admin/FZLGFM/ump/fzlgfm_ora_3468.trc d:/explain_format.txt
文件内容大致如下(看不太懂....懵懂啊.....天啊....神啊.....过几时就懂了/////////////)
TKPROF: Release 9.2.0.1.0 - Proction on 星期二 4月 20 13:59:20 2010
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Trace file: d:/oracle/admin/FZLGFM/ump/fzlgfm_ora_3468.trc
Sort options: default
********************************************************************************
count = number of times OCI procere was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call********************************************************************************
alter session set events '10046 trace name context forever, level 8'
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 1 0.00 0.00 0 0 0 0
Misses in library cache ring parse: 0
Misses in library cache ring execute: 1
Optimizer goal: CHOOSE
Parsing user id: SYS