SQL題_20090805

1.磁碟櫃上有14塊73G的磁碟，  資料庫為200G  大小包括日誌檔案，如何設定磁碟（要說明這14磁碟是怎麼用的）？

這個問題應該是考察硬體知識和資料庫物理部署。

首先需要知道這些磁碟是否要用於存放資料庫備份檔案和資料庫效能（讀/寫）要求。來決定raid的級別。
1）、如果偏重於效能考慮，而且不用存放資料庫備份檔案的話，考慮使用raid0+1，這樣可使用的磁碟容量為：14*73*50%=511G。
2）、如果讀/寫效能要求不高，而且還比較摳門的話，可以考慮raid5，這樣可使用的磁碟容量為：13*73=949G。

至於如何使用應該是說資料庫物理檔案的部署。注意說出將tempdb,data  file,log  file分開存放以減少I/O競爭即可。其實現在的條帶化磁碟一般都會自動將檔案分存，人為的分佈已經越來越不重要了。

2.有兩伺服器群集，分別為node1和node2  現在要打win200系統補丁，打完後，要重新啟動，如何打補丁，不能影響使用者使用（要用群集的術語詳細說明）。

這個具體操作有點忘了。大致是：首先看哪個節點正在使用，通過節點IP（私有）訪問另一個空閒節點，為其打上補丁，然後在群集管理器中停止該節點（也可以用命令列方式），重新啟動。等到啟動完畢，將切換使用節點，為另一個節點打補丁。然後重新啟動。

3.有一個A  資料庫，分別複製到B和C    B  要求  每次資料更新  也同時更新，C  每天更新一次就行，如何制定複製策略!

這個應該考察的是複製知識。

a->b
1）、如果使用SQL  Server複製功能，那麼讓a->b使用事務性複製方式（同步複製）。
2）、如果表不多，也可以自己寫觸發器，利用linkserver+distribute  transaction。

a->c
1）、如果使用SQL  Server複製功能，那麼讓a->b使用快照複製方式，在某一時間點進行一次性複製。
2）、也可以自己寫bat，將a備份後，通過ftp傳輸備份介質，恢復c。（比較麻煩，不推薦）

4.有一個order  表，有90個欄位，20個索引，15個複合索引，其中有3個索引欄位超過10個，如何進行優化

這個問題問的比較沒水平。你不詳細說明這個表的使用方式（讀寫類的，還是幾乎是靜態表），就問人家怎麼優化？！！還不如問問索引的分佈訪問原理更好。

看得出他就想讓你說：那三個索引超過10個，B樹遍例效率很低，適當減少欄位數目。如果是SQL2005，可以將選擇性不好的欄位放在“索引附加欄位”中，以保證索引覆蓋。而且SQL  Server由於有鎖升級的毛病，可以考慮拆開表。

5.有一個資料庫200G大小，每天增加50M  允許使用者隨時訪問，制定備份策略（詳細說明）。

這種情況可以採用增量備份方式。每週日做一次全備份，週一到週六作增量備份（由於資料量較少，可以考慮每30分鐘增量備份一次）。這樣可以儘量減少效能消耗，而且如果transaction  log丟失的情況下，可以保證最多丟失30分鐘資料。

6.管理50臺資料庫，日常工作是檢查資料庫作業是否完成，你該如何完成這項檢查工作？

這個比較簡單。在每臺機器上建立linkserver，然後在DBA管理伺服器上做個分散式檢視，每次查詢該檢視，各個機器上的作業情況一目瞭然。分散式檢視寫法：

create  view  vw_job
as

select  '機器一'  as  MName,*  from  linkserver1..sysjobactivity
union  all
select  '機器二'  as  MName,*  from  linkserver2..sysjobactivity
union  all
select  '機器三'  as  MName,*  from  linkserver3..sysjobactivity
。。。

7.自定義函式和儲存過程的區別是什麼，什麼情況下只能用自定義函式，什麼情況下只能用儲存過程

這個應該是考察儲存過程編寫經驗。一般自定義函式主要用於其他sql中的呼叫，如：

select  yourfunc(...)  from  table

這種情況下，一般只能通過函式實現。

儲存過程的功能要遠遠強於函式，例如動態執行sql（sp_executesql）的使用和一些特殊的功能，自定義函式中是不支援的，只能用儲存過程實現。

8.SQL  2005  的新特性是什麼  ？    與oracle  有什麼區別？

SQL  2005  的新特性一般都是和Oracle學的。

下面是當時被leimin逼著寫的，你可以做個參考：

一、資料庫設計方面
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的閃回技術還是細粒度不夠。可惜！

10、Mirror
Mirror可以算是SQL  Server的Data  guard了。但是能不能被大夥用起來就不知道了。

二、開發方面

1、Ranking函式集
其中最有名的應該是row_number了。這個終於解決了用臨時表生成序列號的歷史，而且SQL  Server2005的row_number比Oracle的更先進。因為它把Order  by整合到了一起，不用像Oracle那樣還要用子查詢進行封裝。但是大家注意一點。如下面的例子：

select  ROW_NUMBER()  OVER  (order  by  aa)
from  tbl
order  by  bb

會先執行aa的排序，然後再進行bb的排序。

可能有的朋友會抱怨整合的order  by，其實如果使用ranking函式,Order  by是少不了的。如果擔心Order  by會影響效率，可以為order  by的欄位建立聚集索引，查詢計劃會忽略order  by  操作（因為本來就是排序的嘛）。

2、top
可以動態傳入引數，省卻了動態SQL的拼寫。

3、Apply
對遞迴類的樹遍歷很有幫助。

4、CTE
個人感覺這個真是太棒了！閱讀清晰，非常有時代感。

5、try/catch
代替了原來VB式的錯誤判斷。比Oracle高階不少。

6、pivot/unpivot
個人感覺沒有case直觀。而且預設的第三欄位（還可能更多）作為group  by欄位很容易造成新手的錯誤。

三、DBA管理方面

1、資料庫級觸發器
記得在最開始使用2k的時候就要用到這個功能，可惜2k沒有，現在有了作解決方案的朋友會很高興吧。

2、多加的系統檢視和實時系統資訊

這些東西對DBA挑優非常有幫助，但是感覺粒度還是不太細。

3、優化器的改進
一直以來個人感覺SQL  Server的優化器要比Oracle的聰明。SQL2005的更是比2k聰明瞭不少。（有次作試驗發現有的語句在200萬級時還比50萬級的相同語句要快show_text的一些提示沒有找到解釋。一直在奇怪。）
論壇例子：
http://community.csdn.net/Expert/topic/4543/4543718.xml?temp=.405987

4、profiler的新事件觀察
這一點很好的加強了profiler的功能。但是提到profiler提醒大家注意一點。windows2003要安裝sp1補丁才能啟動profiler。否則點選沒有反應。

5、sqlcmd

習慣敲命令列的朋友可能會爽一些。但是功能有限。適合機器跑不動SQL  Server  Management  Studio的朋友使用。

四、遺憾

1、登陸的控制
始終遺憾SQL  Server的登陸無法分配CPU/記憶體佔用等指標數。如果你的SQL  Server給別人分配了一個只可以讀幾個表的許可權，而這個傢伙瘋狂的死迴圈進行連線查詢，會給你的系統帶來很大的負擔。而SQL  Server如果能像Oracle一樣可以為登陸分配如：5%的cpu，10%的記憶體。就可以解決這個漏洞。

2、資料庫物理框架沒有變動
undo和redo都放在資料庫得transaction中，個人感覺是個敗筆。如果說我們在設計資料庫的時候考慮分多個資料庫，可能能在一定程度上避免I/O效率問題。但是同樣會為索引檢視等應用帶來麻煩。看看行級和事務級的快照資料放在tempdb中，就能感覺到目前架構的尷尬。

3、還是沒有邏輯備份
備份方面可能還是一個老大難的問題。不能單獨備份幾個表總是感覺不爽。靈活備份的問題不知道什麼時候才能解決。

4、SSIS(DTS)太複雜了

SQL  Server的異構移植功能個人感覺最好了。（如果對比過SQL  Server的連結伺服器和Oracle的透明閘道器的朋友會發現SQL  Server的sp_addlinkedserver(openquery)異構資料庫系列比Oracle真是強太多了。）
以前的DTS輕盈簡單。但是現在的SSIS雖然功能強大了很多，但是總是讓人感覺太麻煩。看看論壇中詢問SSIS的貼子就知道。做的功能太強大了，往往會有很多使用者不會用了。

與oracle  有什麼區別？

這個問題相當變態！不同點我能給他講一天！首先名字就不一樣嘛！！  ：）

9.DBA  的品質應該有哪些，你有哪些，  有什麼欠缺的？

略

10。如果想配置SQL  Mail  應該在伺服器安裝哪些軟體！

需要哪些軟體？安個outlook  express就可以了。sql  server提供介面儲存過程，非常簡單。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－

首先從資料庫設計人員角度來看：

1、SQL  Server2005之前是不支援分割槽表的，所以要在設計系統時考慮今後資料量大以後的資料轉移問題。
2、對於樹表設計來說，SQL  Server由於沒有start  with  ...  connect  by這樣的查詢方式，最好在設計表時除了ID、ParentID外，再加入TreePath欄位，以避免遞迴迴圈。
3、由於SQL  Server有鎖升級的毛病，頻繁DML的表最好減少欄位數量，以減少鎖升級帶來的阻塞！
4、在設計資料庫物理分佈的時侯，由於SQL  Server每個資料庫都有自己的Transaction  Log（其中包含Undo和Redo資訊），為了減輕Transaction  Log的I/O爭用，可以考慮多資料庫（使用聚集索引檢視Clustered  View的除外）。而Oracle是資料庫和例項一一對應的（RAC除外），多個表空間使用公用Undo  segement和redo  file。
5、SQL  Server的索引只有cluster  index和nocluster  index，而Oracle有Btree  index\bitmap  index\function  index等。
6、SQL  Server的最基本儲存結構是頁(8K)，而Oracle最基本的是block可以根據OLTP和DSS的應用不同（後者可以選擇大一點，利於查詢效率），選擇2K-32K不同block大小。
7、SQL  Server的結構是例項->多個資料庫->表、儲存過程...。Oracle的是資料庫=例項（RAC是多個例項對應一個資料庫儲存）->schema（使用者）表空間  ->表、儲存過程...。

先寫這些。。。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

1.磁碟櫃上有14塊73G的磁碟，  資料庫為200G  大小包括日誌檔案，如何設定磁碟（要說明這14磁碟是怎麼用的）？
答:可以做成
          a.  磁碟比較充裕，做RAID10  ,就是14塊硬碟分一半，2個7塊做Raid0,容量：7*73G=511G，然後把它們組成Raid1,最後容量(14/2)*73G=511G.  RAID10  優點，資料一次需要寫入兩個區塊，讀的時候可以從任意一個比較快的地方讀取，效率很高，缺點成本較高。
          b.Raid5,  13塊硬碟做Raid5,1塊做熱冗餘；  容量:  (14-2)*73G=876G,  Raid5優點，穩定係數高,價效比高。
          c.Raid51,7塊硬碟做Raid5,另7塊也做Raid5,再把這2個Raid5做成Raid1,容量:  (14/2-1)*73G=438G,優點:比RAID10更穩定,效率和RAID10相當.

2.有兩伺服器群集，分別為node1和node2  現在要打win200系統補丁，打完後，要重新啟動，如何打補丁，不能影響使用者使用（要用群集的術語詳細說明）。
答:
      a.假設node1聯機並控制資源,那麼先給node2  先打補丁,重起node2,這時聯機並控制資源情況不會改變,不影響客戶服務.
      b.等node2  重起補丁完畢,手工把node1的服務和資源切換到node2,使node2處於聯機狀態,然後給node1打補丁,重起補丁完畢,再把node2的服務和資源切換後node1正常運作.

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7899089/viewspace-611364/，如需轉載，請註明出處，否則將追究法律責任。