❶ 在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