呵呵 這個怎麼說呢 其實功能跟你的連接SQL一樣的 首先你必須要有傳輸值 一般我們在SQL存儲過程中設置（針對一般計算的存儲過程，發郵件就除外），在delphi裡面你直接用一個ADO 連接下就可以了 不是select 而是exec ！
❷ 如何解析oracle執行計劃
一、通過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
❸ mysqldb select 是不是緩存到內存中
ORACLE緩存是把ORACLE近期查看的語句防止在ORACLE設定的緩存當中
ORACLE緩存表是把表某個表放置在緩存當中，緩存是ORACLE在內存中的一個分區
表緩存的設定
oracle中如何將表緩存到內存中
由於在一些靜態資料表在資料庫中被頻繁的訪問，所以可以考慮將這些數據量不大的表緩存到內存當中。
將fisher表緩存到內存中
alter table fisher cache;方法一
2）alter table fisher storage(buffer_pool keep);方法二
--取消緩存
1）alter table fisher nocache;
2）alter table fisher storage(buffer_pool default);
select table_name,OWNER,cache,buffer_pool from dba_tables where table_name='FISHER'; --查看是否緩存
select * from dba_segments where segment_name='FISHER' ; --查看錶大小
方法一： cache是將表緩存到share pool 中，該操作直接將表緩存的熱端，受LRU演算法控制。
方法二：將表緩存到一個固定的內存空間中，默認情況下buffer_pool空間為0,。需手動設置空間大小。
設置空間大小：alter system set db_keep_cache_size=50M scope=both sid=『*';
--表緩存
alter table table_name cache = alter table table_name storage(buffer_pool default);
alter table table_name storage(buffer_pool keep);
--已經加入到KEEP區的表想要移出緩存，使用
alter table table_name nocache;
--查看哪些表被放在緩存區 但並不意味著該表已經被緩存
select table_name from dba_tables where buffer_pool='keep';
--查詢到該表是否已經被緩存
select table_name,cache,buffer_pool from user_TABLES where cache like '%Y';
--查詢當前用戶下表的情況
select table_name,cache,buffer_pool from user_TABLES;
--對於普通LOB類型的segment的cache方法
alter table t2 modify lob(c2) (storage (buffer_pool keep) cache);
--取消緩存
alter table test modify lob(address) (storage (buffer_pool keep) nocache);
keep Buffer Pool
Keep Buffer Pool 的作用是緩存那些需要經常查詢的對象但又容易被默認緩沖區置換出去的對象，按慣例，Keep pool設置為合理的大小，以使其中存儲的對象不再age out，也就是查詢這個對象的操作不會引起磁碟IO操作，可以極大地提高查詢性能。
默認的情況下 db_keep_cache_size=0，未啟用，如果想要啟用，需要手工設置db_keep_cache_size的值，設置了這個值之後 db_cache_size 會減少。
並不是我們設置了keep pool 之後，熱點表就一定能夠緩存在 keep pool ，keep pool 同樣也是由LRU 鏈表管理的，當keep pool 不夠的時候，最先緩存到 keep pool 的對象會被擠出，不過與default pool 中的 LRU 的管理方式不同，在keep pool 中表永遠是從MRU 移動到LRU，不會由於你做了FTS而將表緩存到LRU端，在keep pool中對象永遠是先進先出。當oracle發現你的表太太，大過你設定keep pool的大小是，根本就不會放到keep池中去的（如keep pool設定100M ，設定的用戶緩存的表為200M）。可以用select segment_name from dba_segments where BUFFER_POOL = 'KEEP';語句查看便知。
10g中SGA自動管理，ORACLE並不會為我們管理keep pool ，ORACLE只會管理default pool。
查看 keep pool 大小
SQL> select component,current_size from v$sga_dynamic_components
2 where component='KEEP buffer cache';
COMPONENT CURRENT_SIZE
---------------------------------------------------------------- ------------
KEEP buffer cache 0
手動分配keep pool
SQL> show parameter keep
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
buffer_pool_keep string
control_file_record_keep_time integer 7
db_keep_cache_size big integer 0
SQL> alter system set db_keep_cache_size=10m;
系統已更改。
SQL> show parameter keep
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
buffer_pool_keep string
control_file_record_keep_time integer 7
db_keep_cache_size big integer 16M這里keep pool 16M，可我前面設置命名是10m了看
SQL> select component,current_size from v$sga_dynamic_components where component='KEEP buffer cache';
COMPONENT CURRENT_SIZE
---------------------------------------------------------------- ------------
KEEP buffer cache 16777216 這里keep pool 16M，可我前面設置命名是10m了看
查看keep pool剩餘大小
SQL> select p.name,a.cnum_repl "total buffers",a.anum_repl "free buffers" from x$kcbwds a, v$buffer_pool p
2 where a.set_id=p.LO_SETID and p.name='KEEP';
NAME total buffers free buffers
-------------------- ------------- ------------
KEEP 1984 1984
可以看到沒有使用過keep 池
指定table的緩存池
SQL>create table test as select * from dba_objects;;
Table created.
SQL> alter table test storage(buffer_pool keep);
Table altered.
或者是
create table test storage(buffer_pool keep) as select * from dba_objects;
查看放入Keep的對象
SQL> select segment_name from dba_segments where BUFFER_POOL = 'KEEP';
SEGMENT_NAME
--------------------------------------------------------------------------------
TEST
SQL> /
NAME total buffers free buffers
-------------------- ------------- ------------
KEEP 1984 1962 可以看到使用了22個block
查看以上的表佔用了db_keep_cache_size 多大的空間看
SQL> select substr(sum(b.NUMBER_OF_BLOCKS) * 8129 / 1024 / 1024, 1, 5) || 'M'
from (SELECT o.OBJECT_NAME, COUNT(*) NUMBER_OF_BLOCKS
FROM DBA_OBJECTS o, V$BH bh, dba_segments dd
WHERE o.DATA_OBJECT_ID = bh.OBJD
AND o.OWNER = dd.owner
and dd.segment_name = o.OBJECT_NAME
and dd.buffer_pool != 'DEFAULT'
GROUP BY o.OBJECT_NAME
ORDER BY COUNT(*)) b; 2 3 4 5 6 7 8 9
SUBSTR(SUM(
-----------
3.643M
SQL> select table_name,cache,blocks from dba_tables where wner='ROBINSON' and buffer_pool='KEEP';
TABLE_NAME CACHE BLOCKS
------------------------------ -------------------- ----------
TEST N 22
可以看到這個表的 22個block 全部cache 到 keep pool ，這里的cache 欄位表明 這個表 還沒有使用 這個命令 alter table test cache,如果 使用了 alter table test cache ,命令，那麼 N 將變成Y
總結：如果表經常使用，而且表較小，可以設置 keep pool ，將table 全部 cache 到 keep pool, keep pool 要麼 全部 cache 一個table ，要麼不cache 。所以，對於大表來說，如果想要 cache 到 keep pool， 就需要設置 較大的 keep pool ，以容納大的 table，否者就沒有作用了。
Recycle Buffer Pool
Recycle Buffer Pool正好相反。Recycle Buffer Pool用於存儲臨時使用的、不被經常使用的較大的對象，這些對象放置在Default Buffer Pool顯然是不合適的，這些塊會導致過量的緩沖區刷新輸出，而且不會帶來任何好處，因為等你想要再用這個塊時，它可已經老化退出了緩存。要把這些段與默認池和保持池中的段分開，這樣就不會導致默認池和保持池中的塊老化而退出緩存。
SQL> show parameter recyc
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
buffer_pool_recycle string
db_recycle_cache_size big integer 12M
recyclebin string on
如何將一個表放入Recycle Buffer Pool中：
SQL> alter table test1 storage (buffer_pool recycle);
Table altered.
很多老的文檔會提及buffer_pool_keep和buffer_pool_recycle 這兩個參數，其實這兩個參數已經廢棄，由新參數db_keep_cache_size和db_recycle_cache_size 替代：
SQL>select ISDEPRECATED,NAME from v$parameter where name = 'buffer_pool_keep';
ISDEP NAME
----- -----------------
TRUE buffer_pool_keep
=======================================================================================
--表緩存
alter table ..... storage(buffer_pool keep);
--查看哪些表被放在緩存區 但並不意味著該表已經被緩存
select table_name from dba_tables where buffer_pool='keep';
--查詢到該表是否已經被緩存
select table_name,cache,buffer_pool from user_TABLES where cache like '%Y';
--已經加入到KEEP區的表想要移出緩存，使用
alter table table_name nocache;
--批量插入ORACLE建議用
insert all into ...insert into ...select 1 from al;
insert all into ... insert into ...select 1 from al;
--查詢當前用戶下表的情況
select table_name,cache,buffer_pool from user_TABLES;
--對於普通LOB類型的segment的cache方法
alter table t2 modify lob(c2) (storage (buffer_pool keep) cache);
--取消緩存
alter table test modify lob(address) (storage (buffer_pool keep) nocache);
--查詢段
select segment_name,segment_type,buffer_pool from user_segments;
--對基於CLOB類型的對象的cache方法
alter table lob1 modify lob(c1.xmldata) (storage (buffer_pool keep) cache);
--查詢該用戶下所有表內的大欄位情況
select column_name,segment_name from user_lobs;
來一段Tom關於Multiple Buffer Pools的解釋，講解得很清楚：
實際上，這3 個池會以大體相同的方式管理塊；將塊老化或緩存的演算法並沒有根本的差異。這樣做的目標是讓DBA 能把段聚集到逗熱地區（hot）、逗溫地區（warm）和逗不適合緩存地區（do not care to cache）。
理論上講，默認池中的對象應該足夠熱（也就是說，用得足夠多），可以保證一直呆在緩存中。緩存會把它們一直留在內存中，因為它們是非常熱門的塊。可能還有一些段相當熱門，但是並不太熱；這些塊就作為溫塊。這些段的塊可以從緩存刷新輸出，為不常用的一些塊（逗不適合緩存地塊）騰出空間。為了保持這些溫段的塊得到緩存，可以採取下面的某種做法：將這些段分配到保持池，力圖讓溫塊在緩沖區緩存中停留得更久。將逗不適合緩存地段分配到回收池，讓回收池相當小，以便塊能快速地進入緩存和離開緩存（減少管理的開銷）。這樣會增加DBA 所要執行的管理工作，因為要考慮3 個緩存，要確定它們的大小，還要為這些緩存分配對象。還要記住，這些池之間沒有共享，所以，如果保持池有大量未用的空間，即使默認池或回收池空間不夠用了，保持池也不會把未用空間交出來。總之，這些池一般被視為一種非常精細的低級調優設備，只有所有其他調優手段大多用過之後才應考慮使用。
按以上步驟把表storage到keep pool中，然後調用alter system flush buffer_cache清空緩存，再全表掃描該表並打開執行計劃跟蹤，發現有physical reads，如下：
第一次執行計劃如下：
----------------------------------------------------------
0 recursive calls
0 db block gets
253 consistent gets
251 physical reads
0 redo size
520 bytes sent via SQL*Net to client
469 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
第二次執行計劃如下：
----------------------------------------------------------
0 recursive calls
0 db block gets
253 consistent gets
0 physical reads
0 redo size
520 bytes sent via SQL*Net to client
469 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
不知道是否可以這樣理解：對於storage到keep pool中的表，第一次會直接physical reads 到keep pool中，下次就直接從keep pool中讀了。flush buffer_cache會清空keep pool，這個試驗就可以證明。
像上面這樣連續執行2次再看執行計劃，和不設置keep pool時的執行計劃應該一樣的，因為讀第二次時，也是從default cache中讀。但是當我們多讀幾個大表到buffer cache後，也就是替換原來從default cache中讀取的數據後，再去讀放入keep中的表時，就會發現keep確實起作用了，唉，終於明白怎麼一回事，害得我為flush buffer導致keep中的表也phisical郁悶了半天。
ORACLE緩存設置
Oracle緩存由兩個參數控制SGA_TARGET和PGA_AGGREGATE_TARGET，設置了這兩個參數，其他的基本內存部分都由Oracle自動配置為最優值，這也是Oracle推薦的方式。
SGA_TARGET 和PGA_AGGREGATE_TARGET是動態參數，可以在不重啟資料庫的情況下修改。但是SGA_TARGET受限於 sga_max_size，SGA_TARGET不能超過sga_max_size，所以要增大sga_target先要增大sga_max_size，而sga_max_size是靜態參數，修改sga_max_size必須重啟Oracle。
所以修改sga_target和pga_aggregate_target的過程如下：
1、修改sga_max_size
SQL>ALTER SYSTEM SET sga_max_size=4g scope=spfile;
2、重啟Oracle
3、設置參數sga_target和pga_aggregate_target，
alter system set sga_target=4G;
alter system set pga_aggregate_target=1g;
如果使用的是10g，已經是ASM, oracle會根據統計的信息，自動的來調整你的內存組件的大小，你只需要設置sga_target即可。當然你可以手動設置 db_cache_size，如果設置了的話，Oracle會在自動調整內存大小的時候把這個作為db_cache_size的最小值。
對於sga_target,在動態修改的時候，最大值不能操過sga_max_size, 如果是用scope=spfile這個方式來修改可以超過sga_max_size，應該此時sga_max_size也跟著變大了，如果超過的話。
Oracle 對資料庫的cache有他自己的計算的，10g以後，內存是動態的根據對你使用系統的統計來進行調整的，如果出現問題，這塊不是原因，你之所以db cache還沒有上去，可能是訪問的數據比較少，不過你加大db_cache_size的值，會保留這個內存空間的，但是也是一樣的，數據 load到內存里，才看得到變化。
數據訪問是什麼樣的訪問，你的系統是OLAP還是OLTP，這些應用上的東西對你的決定也有影響的，要謹記，資料庫的優化和維護，不僅僅是DBA來做的。如果是到了只能通過DBA來做這一步的話，就相當於看病已經到了拿手術刀這一步了。你的改變帶來的風險和代價最高。
要想減少磁碟讀,只能增大內存的使用.樓主可以看看這個視圖v$db_cache_size,並執行下面的查詢:
select block_size, size_for_estimate, size_factor, estd_physical_read_factor, estd_physical_reads from v$db_cache_advice;
Oracle在這個視圖中針對db_cache_size的大小會給出一些建議。
下面解釋幾個列的含義
size_for_estimate：估計的cache size大小
size_factor： 估計的cache size大小與當前大小的比值
estd_physical_reads：在估計的cache size大小情況下，會產生的物理讀數量
estd_physical_read_factor：估計的物理讀數量與當前物理讀數量的比值。
例子：
SIZE_FOR_ESTIMATE SIZE_FACTOR ESTD_PHYSICAL_READ_FACTOR ESTD_PHYSICAL_READS
❹ 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，並返回給調用者。
以上每個步驟都會產生一個虛擬表，該虛擬表被用作下一個步驟的輸入。這些虛擬表對調用者(客戶端應用程序或者外部查詢)不可用。只有最後一步生成的表才會會給調用者。如果沒有在查詢中指定某一個子句，將跳過相應的步驟。
❺ sql運行問題
sql運行問題？
資料庫運行過程中常見的故障有3類：事物故障、系統故障、介質故障。
恢復策略：
1、事物故障：
發生事務故障時，被迫中斷的事務可能已對資料庫進行丁修改，為了消除該事務對資料庫的影響，要利用日誌文件中所記載的信息，強行回滾該事務，將資料庫恢復到修改前的初始狀態。
為此，要檢查日誌文件中由這些事務所引起的發生變化的記錄，取消這些沒有完成的事務所做的一切改變，這類恢復操作稱為事務撤銷。
2、系統故障：
系統故障的恢復要完成兩方面的工作，既要撤銷所有末完成的事務，還要重做所有已提交的事務，這樣才能將資料庫真正恢復到一致的狀態。
3、介質故障：
介質故障比事務故障和系統故障發生的可能性要小，但這是最嚴重的一種故障，破壞性很大，磁碟上的物理數據和日誌文件可能被破壞，這需要裝入發生介質故障前最新的後備資料庫副本，然後利用日誌文件重做該副本後所運行的所有事務。
「數據故障恢復」和「完整性約束」、「並發控制」一樣，都是資料庫數據保護機制中的一種完整性控制。所有的系統都免不了會發生故障，有可能是硬體失靈，有可能是軟體系統崩潰，也有可能是其他外界的原因，比如斷電等等。
資料庫運行的突然中斷會使資料庫處在一個錯誤的狀態，而且故障排除後沒有辦法讓系統精確地從斷點繼續執行下去。這就要求DBMS要有一套故障後的數據恢復機構，保證資料庫能夠回復到一致的、正確地狀態去。
❻ 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 演算法。
❼ SQL為什麼預估執行計劃與真實執行計劃會有差異
第一種，就是優化器的輸出結果，成為預估執行計劃，裡面的操作符或者步驟都是邏輯步驟，因為他們代表著執行計劃在優化器中的視圖，但是並不表現在實際執行中物理層面的發生。
另外一種計劃是表示查詢實際執行的輸出結果。這種類型叫做實際執行計劃，表示查詢在實際執行時發生的事情。
這兩個計劃顯示獨立的不同的結果集，但是可以看出有巨大的相同之處。大部分情況下，相同的開銷的相同的操作符會出現在兩種執行計劃中。但是當發生重編譯，SQLServer會刪除計劃緩存中的計劃並重建它，此時兩者就會有明顯的差異。這種情況通常發生於統計信息的更改，或存儲引擎在處理查詢時發生的其他事情。
預估執行計劃是存放在計劃緩存中的計劃，所以對於實際執行計劃，只能通過捕捉查詢運行的時候產生的執行計劃。預估計劃從不直接訪問數據，但是它對大型的、復雜的、可能運行很久的查詢分析相當有效。但是實際計劃是首選的，因為它能顯示很多運行過程中重要的統計信息如特定操作符實際訪問的行數。通常情況下，這種額外的信息使得實際計劃成為最常用的方式，但是預估計劃機器重要，特別是因為可以從計劃緩存中獲取。
❽ 存儲過程作用是什麼，優缺點以及適用范圍是什麼
中用戶通過指定存儲過程的名字並給出參數（如果該存儲過程帶有參數）來執行它。存儲過程是SQL 語句和可選控制流語句的預編譯集合，以一個名稱存儲並作為一個單元處理。存儲過程存儲在資料庫內，可由應用程序通過一個調用執行，而且允許用戶聲明變數、有條件執行以及其它強大的編程功能。存儲過程在創建時即在伺服器上進行編譯，所以執行起來比單個SQL語句快。 存儲過程的優點： 1.存儲過程只在創造時進行編譯，以後每次執行存儲過程都不需再重新編譯，而一般SQL語句每執行一次就編譯一次,所以使用存儲過程可提高資料庫執行速度。 2.當對資料庫進行復雜操作時(如對多個表進行Update,Insert,Query,Delete時），可將此復雜操作用存儲過程封裝起來與資料庫提供的事務處理結合一起使用。 3.存儲過程可以重復使用,可減少資料庫開發人員的工作量 4.安全性高,可設定只有某此用戶才具有對指定存儲過程的使用權 缺點：1.如果更改范圍大到需要對輸入存儲過程的參數進行更改，或者要更改由其返回的數據，則您仍需要更新程序集中的代碼以添加參數、更新 GetValue() 調用，等等，這時候估計比較繁瑣了。
2.可移植性差
由於存儲過程將應用程序綁定到 SQL Server，因此使用存儲過程封裝業務邏輯將限制應用程序的可移植性。 優點： 1.由於應用程序隨著時間推移會不斷更改，增刪功能，T－SQL過程代碼會變得更復雜，StoredProcere為封裝此代碼提供了一個替換位置。 2.執行計劃（存儲過程在首次運行時將被編譯，這將產生一個執行計劃－－ 實際上是 Microsoft SQL Server為在存儲過程中獲取由 T-SQL 指定的結果而必須採取的步驟的記錄。）緩存改善性能。 ........但sql server新版本，執行計劃已針對所有 T-SQL 批處理進行了緩存，而不管它們是否在存儲過程中，所以沒比較優勢了。 3.存儲過程可以用於降低網路流量，存儲過程代碼直接存儲於資料庫中，所以不會產生大量T-sql語句的代碼流量。 4.使用存儲過程使您能夠增強對執行計劃的重復使用，由此可以通過使用遠程過程調用 (RPC) 處理伺服器上的存儲過程而提高性能。RPC 封裝參數和調用伺服器端過程的方式使引擎能夠輕松地找到匹配的執行計劃，並只需插入更新的參數值。 5.可維護性高，更新存儲過程通常比更改、測試以及重新部署程序集需要較少的時間和精力。 6.代碼精簡一致，一個存儲過程可以用於應用程序代碼的不同位置。 7.更好的版本控制，通過使用 Microsoft Visual SourceSafe 或某個其他源代碼控制工具，您可以輕松地恢復到或引用舊版本的存儲過程。 8.增強安全性： a、通過向用戶授予對存儲過程（而不是基於表）的訪問許可權，它們可以提供對特定數據的訪問； b、提高代碼安全，防止 SQL注入（但未徹底解決，例如，將數據操作語言－－DML，附加到輸入參數）； c、SqlParameter 類指定存儲過程參數的數據類型，作為深層次防禦性策略的一部分，可以驗證用戶提供的值類型（但也不是萬無一失，還是應該傳遞至資料庫前得到附加驗證）。 缺點： 1.如果更改范圍大到需要對輸入存儲過程的參數進行更改，或者要更改由其返回的數據，則您仍需要更新程序集中的代碼以添加參數、更新 GetValue() 調用，等等，這時候估計比較繁瑣了。 2.可移植性差 由於存儲過程將應用程序綁定到 SQL Server，因此使用存儲過程封裝業務邏輯將限制應用程序的可移植性。
❾ 如何清除特定語句的執行計劃緩存
應該是與執行計劃有關，Oracle執行一個語句要先進行解析分解執行，這需要時間，並把相關結果存儲，再次執行相同語句時就不需要進行解析，從而縮段時間。舉個例子，比如需要多次在翻頁查找某一行記錄時，在第1次找時要一頁頁地去找，待找到這行記錄時，就可以記住是在第幾頁，第2次找時就可以直接翻到。