A. sql優化器基於規則優化器和基於成本優化器的區別
Oracle有兩種優化器：RBO和CBO。 RBO的最大的問題在於它是靠硬編碼在ORACLE資料庫代碼中的一系列規定的規則來決定目標SQL的執行計劃的，而並沒有考慮目標SQL中所涉及的對象的時間數據量，實際數據分布情況，這樣一旦規定規則並不適用於該SQL中所涉及的實際對象時，RBO根據規定規則產生的執行計劃就很可能不是當前情況下的最優執行計劃了。
下面我們來看如下的例子：
select * from EMP_TEMP where manager_id=100;
假設在EMP_TEMP的manager_id上事先有名為IDX_MGR_TEMP的單鍵值B數索引，如果我們用的是RBO，則不管EMP_TEMP的數據量多大，也不管MANAGER_ID的數據分布如何，ORACLE執行的時候始終會選擇做對IDX_MGR_TEMP的范圍索引掃描，並回表取得EMP_TEMP中的記錄。ORACLE是不會選擇全表掃描EMP_TEMP表的，因為對於RBO而言，全表掃描的等級值要高於索引范圍掃描值的等級值。
RBO的這種選擇在表EMP_TEMP的數據量不大，而且滿足manager_id=10的條件的記錄少的情況下是影響不大的，如果表EMP_TEMP的數據量非常大，例如1000萬條記錄，
而且這1000萬條記錄的MANAGER_ID的值都是100，在這種極端的情況下，如果是RBO,顯然它任然用IDX_MGR_TEMP索引范圍掃描，這個時候性能肯定是很差的。因為相當於以單塊順序掃描所有的1000萬行索引，然後再回表1000萬次。顯然沒有使用多塊以全表掃描方式直接掃描表EMP_TEMP的執行效率高。所以為了解決RBO的這個先天的缺陷，從ORACLE 7開始，ORACLE就引入了CBO。CBO在選擇目標SQL的執行計劃時，是用執行成本作為判斷原則的。CBO會從目標SQL諸多可能的執行路徑中選擇一條成本值最小的執行路徑作為其執行計劃，各條執行路徑的成本是根據目標SQL語句所涉及的表，索引，列等相關對象的統計信息計算出來的。這些信息存儲在ORACLE的資料庫的數據字典里，且從多個維度描述了ORACLE資料庫里相關對象的實際數據量，實際數據分布等詳細信息。
NOTE:ORACLE在對一條執行路徑計算成本時，並不一定從頭到尾完整計算完，只是要ORACLE在計算過程中發現算出來的部分成本值已經大於之前保存下來的到目前為止的最小成本值，就會馬上終止對當前執行路徑成本值的計算，並轉而開始計算下一條新的執行路徑的成本。這個過程會一直持續下去，直到目標SQL的給各個可能的執行路徑全部計算完畢或已經達到預先定義好的待計算的執行路徑數量的閥值。
RBO是根據硬編碼在ORACLE資料庫中來決定目標SQL的執行計劃的，並沒有考慮目標SQL所所涉及的對象的實際數據量，實際分布情況等。而CBO則恰恰相反，它會根據目標SQL的相關的對象的實際數據量，實際數據分布情況的統計信息來決定其執行計劃，即意味著CBO是隨著目標SQL中所涉及的對象的統計信息的變化而變化的。這就意味著只有統計信息相對准確，則用CBO來解析目標SQL會比同等條件下的RBO來解析得到正確執行計劃的概率要高。
當然CBO並不是完美的，它的缺陷主要表現在：
1，CBO會默認目標SQL語句的WHERE條件中出現的各個列之間是獨立的，沒有關系的。
2，CBO會假設所有的目標SQL都是單獨執行的，並且互不幹擾。
3，CBO對直方圖統計信息有諸多限制。
4，CBO在解析多個表關聯的目標SQL時，可能會漏掉正確的執行計劃。
B. 如何用SQL語言實現資料庫空間容量報警
CREATE OR REPLACE PROCEDURE "P_DBSPACE_ALERT"
as
begin
insert into tsy_op_log
SELECT s_tsy_op_log.nextval,3,0,65537,sysdate,0,7,'資料庫報警 '||'最高級別 '||' 表空間'||F.TABLESPACE_NAME||'用
了'||
TO_CHAR ((T.TOTAL_SPACE - F.FREE_SPACE),'999,999.99')||',空閑'||
TO_CHAR (F.FREE_SPACE, '999,999.99') ||',空閑百分比'||
TO_CHAR ((ROUND ((F.FREE_SPACE/T.TOTAL_SPACE)*100)),'999.99')||' %,請及時增加表空間容量' PER_FREE,3,100,0,0
FROM (
SELECT TABLESPACE_NAME,
SUM (BLOCKS*(SELECT VALUE/1024 FROM V$PARAMETER
WHERE NAME = 'db_block_size')/1024
) FREE_SPACE
FROM DBA_FREE_SPACE
GROUP BY TABLESPACE_NAME
) F,
(
SELECT TABLESPACE_NAME,
SUM (BYTES/1048576) TOTAL_SPACE
FROM sys.DBA_DATA_FILES
GROUP BY TABLESPACE_NAME
) T
WHERE F.TABLESPACE_NAME = T.TABLESPACE_NAME
AND (ROUND ((F.FREE_SPACE/T.TOTAL_SPACE)*100)) < 10;
insert into tsy_op_log
SELECT s_tsy_op_log.nextval,3,0,65537,sysdate,0,7,'資料庫報警 '||'最高級別 '||owner||'用戶的'||object_type||'
'||object_name|| '無效了',3,100,0,0 FROM dba_objects WHERE status<>'VALID' and owner=SYS_CONTEXT
('USERENV','CURRENT_USER') and object_type not in('PACKAG','EPACKAGE BODY','PROCEDURE');
insert into tsy_op_log
select s_tsy_op_log.nextval,3,0,65537,sysdate,0,7,'資料庫報警 '||'最高級別 '||SYS_CONTEXT
('USERENV','CURRENT_USER')||'用戶的 索引'||' '||index_name|| '無效了',3,100,0,0 from user_indexes where
status<>'VALID' and status<> 'N/A';
commit;
end;
--建立job
--建立資料庫報警的job
BEGIN
sys.dbms_scheler.create_job(
job_name => '"TEST"."AFC_TABLESPACE_ALERT"',
job_type => 'PLSQL_BLOCK',
job_action => 'begin
P_DBSPACE_ALERT;
end;',
repeat_interval => 'FREQ=HOURLY',
start_date => to_timestamp_tz('2010-02-04 00:00:00 Asia/Shanghai', 'YYYY-MM-DD HH24:MI:SS TZR'),
job_class => 'AFC_AUTO_TASKS',
comments => 'AFC_TABLESPACE_ALERT',
auto_drop => FALSE,
enabled => FALSE);
sys.dbms_scheler.set_attribute( name => '"TEST"."AFC_TABLESPACE_ALERT"', attribute => 'job_priority', value =>
2);
sys.dbms_scheler.set_attribute( name => '"TEST"."AFC_TABLESPACE_ALERT"', attribute => 'job_weight', value =>
1);
sys.dbms_scheler.set_attribute( name => '"TEST"."AFC_TABLESPACE_ALERT"', attribute => 'restartable', value =>
TRUE);
sys.dbms_scheler.enable( '"TEST"."AFC_TABLESPACE_ALERT"' );
END;
/
C. SQL Server中所說的「臟頁」是什麼意思
SQL Server的工作原理：不能直接修改硬碟上的數據，而是先將數據從硬碟讀入到內存的data cache，然後在內存中修改（被修改過的頁稱為臟數據頁），最後再從內存回寫到硬碟。下述進程都可能將臟頁回寫到硬碟。
一、Checkpoint（檢查點）
Checkpoint會搜索整個data cache，將臟頁回寫到硬碟。
以下情況通常會觸發checkpoint：
1、運行Checkpoint 命令。
2、使用alter database往資料庫中添加了文件，或者從資料庫中刪除了文件。
3、備份資料庫。在資料庫備份之前，資料庫引擎會自動執行檢查點，以便在備份中包含對資料庫數據頁面的全部更改。
4、正常關閉SQL Server，並且不使用NOWAIT選項。
5、SQL Server預計的恢復時間超過了恢復間隔（recovery interval）。該值默認為0，即由SQL Server自動配置，一般為1分鍾。一般情況下，按最低每分鍾10MB日誌進行設計。
以下特殊情況也會觸發checkpoint：
1、當恢復模式為簡單時，如果日誌文件的空閑空間低於70%。例外的情況是：如果日誌文件是由於一個事務長時間執行而且尚未結束（意味著沒有空間可釋放）導致空閑空間低於70%，則不會觸發checkpoint。
2、當恢復模式為大容量日誌時，對資料庫做了一個大容量操作。
checkpoint對資料庫的影響：
1、當資料庫重啟時，SQL Server將從checkpoint 完成的這個時間點開始恢復，即在此之後做redo（前滾）。這種機制加速了恢復的進度。
2、當恢復模式為簡單時，checkpoint在把臟頁回寫到硬碟後，就去截斷日誌（將VLF的狀態從2改為0）。
二、Lazywriter（惰性編輯器）
SQL
Server為每一個NUMA（非一致性內存訪問）配備一個Lazywriter線程。Lazywriter被定期喚醒後，就去掃描與NUMA節點中的
data cache，檢查自由列表（free list）。如果列表的大小低於某個閥值（這個閥值取決於data
cache的總大小）意味著內存壓力，Lazywriter就去掃描data
cache，將其中一些頁標記到自由列表，表示這是空閑內存；如果這些頁中有臟頁，就回寫到硬碟。
當Lazywriter察覺到系統有內存壓力時，它會增加或減少自由列表上的數據頁，使操作系統的可用物理內存保持在4.8~5.2MB，以防止分頁。
Lazywriter自SQL Server 2005被引入。它與checkpoint的主要區別：checkpoint不會去修改自由列表。
這是一個周期運行的線程，默認情況下，每隔一秒鍾運行一次。
三、Worker Thread（工作線程）
SQL Server 啟動時，同時啟動30~40個工作線程，用於完成客戶端連接提出的各種操作請求。當客戶端連接增加時，SQL
Server會自動啟動新的工作線程。當某個工作線程空閑15分鍾，就會被關閉；當空閑內存不夠時，某些工作線程也會被關閉（x86環境）。在x86環
境，每個工作線程至少佔用0.5MB內存；在x64環境，每個工作線程至少佔用2MB內存。
當worker線程察覺內存壓力時，它會掃描data cache，把一段時間內未被訪問的數據頁添加到自由列表；如果這些頁中有臟頁，就回寫到硬碟。
D. sql server 數據表與access數據表部分欄位如何同步
Access 沒學過，orcle倒是了解一點，sql server還是很認真的學過的
sql學習心得:SQL SERVER 2005學習心得
一、資料庫設計方面
1、欄位類型。
varchar(max)\nvarchar(max)類型的引入大大的提高了編程的效率，可以使用字元串函數對CLOB類型進行操
作，這是一個亮點。但是這就引發了對varchar和char效率討論的老問題。到底如何分配varchar的數據，是否
會出現大規模的碎片？是否碎片會引發效率問題？這都是需要進一步探討的東西。
varbinary(max)代替image也讓SQL Server的欄位類型更加簡潔統一。
XML欄位類型更好的解決了XML數據的操作。XQuery確實不錯，但是個人對其沒好感。（CSDN的開發者應
該是相當的熟了！）
2、外鍵的級聯更能擴展
可能大部分的同行在設計OLTP系統的時候都不願意建立外鍵，都是通過程序來控制父子數據的完整性。但是
再開發調試階段和OLAP環境中，外鍵是可以建立的。新版本中加入了SET NULL 和 SET DEFAULT 屬性，能夠
提供能好的級聯設置。
3、索引附加欄位
這是一個不錯的新特性。雖然索引的附加欄位沒有索引鍵值效率高，但是相對映射到數據表中效率還是提高了
很多。我做過試驗，在我的實驗環境中會比映射到表中提高30%左右的效率。
4、計算欄位的持久化
原來的計算欄位其實和虛擬欄位很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了計算
欄位的持久化，這就提高了查詢的性能，但是會加重insert和update的負擔。OLTP慎用。OLAP可以大規模使
用。
5、分區表
分區表是個亮點！從分區表也能看出微軟要做大作強SQL Server的信心。資料很多，這里不詳細說。但是重點
了解的是：現在的SQL Server2005的表，都是默認為分區表的。因為它要支持滑動窗口的這個特性。這種特性
對歷史數據和實時數據的處理是很有幫助的。
但是需要注意的一點，也是我使用過程中發現的一個問題。在建立function->schema->table後，如果在現有
的分區表上建立沒有顯式聲明的聚集索引時，分區表會自動變為非分區表。這一點很讓我納悶。如果你覺得我
的非分區索引無法對起子分區，
你可以提醒我一下呀！沒有任何的提醒，直接就變成了非分區表。不知道這算不算一個bug。大家也可以試試
。
分區表效率問題肯定是大家關心的問題。在我的試驗中，如果按照分區欄位進行的查詢（過濾）效率會高於未
分區表的相同語句。但是如果按照非分區欄位進行查詢，效率會低於未分區表的相同語句。但是隨著數據量的
增大，這種成本差距會逐漸減小，趨於相等。（500萬數量級只相差10%左右）
6、CLR類型
微軟對CLR作了大篇幅的宣傳，這是因為資料庫產品終於融入.net體系中。最開始我們也是狂喜，感覺對象數
據庫的一些概念可以實現了。但是作了些試驗，發現使用CLR的存儲過程或函數在達到一定的閥值的時候，系
統性能會呈指數級下滑！這是非常危險的！只使用幾個可能沒有問題，當一旦大規模使用會造成嚴重的系統性
能問題！
其實可以做一下類比，Oracle等資料庫產品老早就支持了java編程，而且提供了java池參數作為用戶配置介面
。但是現在有哪些系統大批使用了java存儲過程？！連Oracle自己的應用都不用為什麼？！還不是性能有問題
！否則面向對象的資料庫早就實現了！
建議使用CLR的地方一般是和應用的復雜程度或操作系統環境有很高的耦合度的場景。如你想構建復雜的演算法
，並且用到了大量的指針和高級數據模型。或者是要和操作系統進行Socket通訊的場景。否則建議慎重！
7、索引視圖
索引視圖2k就有。但是2005對其效率作了一些改進但是schema.viewname的作用域真是太限制了它的應用面
。還有一大堆的環境參數和種種限制都讓人對它有點卻步。
8、語句和事務快照
語句級快照和事務級快照終於為SQL Server的並發性能帶來了突破。個人感覺語句級快照大家應該應用。事務
級快照，如果是高並發系統還要慎用。如果一個用戶總是被提示修改不成功要求重試時，會殺人的！
9、資料庫快照
原理很簡單，對要求長時間計算某一時間點的報表生成和防用戶操作錯誤很有幫助。但是比起Oracle10g的閃
回技術還是細粒度不夠。可惜！
E. mysql的bin-log壓縮閥值是多少
在row模式下，bin-log中可以不記錄執行的sql語句的上下文相關信息，僅僅需要記錄哪一條記錄被修改了，修改成什麼信樣了，所以row的日誌內容會非常清楚的記錄下每一行數據修改的細節，非常容易理解。
而且不會出現在某些特定情況下的存儲過程和function，以及trigger的調用和處罰無法被正確復制問題。
F. sql 分數欄位分段統計
//嘗試下面的sql--目測可以的
selectuid,score,t2.flagfrom[dbo].[table1]ast1
leftjoin[dbo].[table2]ast2
ont1.score>=t2.range_maxandt1.score<=t2.range_min
G. sql中怎麼給一個變數設置閾值
Sql中如何給變數賦值使用set關鍵字。例表格tt結構如圖：下面語句聲明一個@ii_test的整型變數，然後給變數賦值，並在SQL查詢中調用變數
H. sql 觸發器 阻止多條delete
instead of 觸發器(針對一次刪除多條)
create trigger club_messages_delete
on club_messages
instead of delete
as
begin
delete from club_Reply where messagesID in (select messagesID from deleted)
delete from club_messages where messagesID in (select messagesID from deleted)
end
after 觸發器(針對多條)
create trigger club_messages_delete
on club_messages
after delete
as
begin
delete from club_Reply where messagesID in (select messagesID from deleted)
end
其實根據你的設計方案,我想根本就可以不用觸發器,一條留言只對應一條回復,這樣的話可以把留言ID作為留言回復的外鍵,把刪除規則設為層疊就可以了
I. 表空間超過閥值怎麼解決
你用什麼資料庫，如果是sqlserver的話壓縮一下資料庫吧，可以清理大量的日誌