- 相關(guān)推薦
十個經(jīng)典的數(shù)據(jù)庫面試問題
1.磁盤柜上有14塊73G的磁盤， 數(shù)據(jù)庫為200G 大小包括日志文件，如何設(shè)置磁盤(要說明這14磁盤是怎么用的)?
這個問題應(yīng)該是考察硬件知識和數(shù)據(jù)庫物理部署。
首先需要知道這些磁盤是否要用于存放數(shù)據(jù)庫備份文件和數(shù)據(jù)庫性能(讀/寫)要求。來決定raid的級別。
1)、如果偏重于性能考慮，而且不用存放數(shù)據(jù)庫備份文件的話，考慮使用raid0+1，這樣可使用的磁盤容量為：14*73*50%=511G。
2)、如果讀/寫性能要求不高，而且還比較摳門的話，可以考慮raid5，這樣可使用的磁盤容量為：13*73=949G。
至于如何使用應(yīng)該是說數(shù)據(jù)庫物理文件的部署。注意說出將tempdb,data file,log file分開存放以減少I/O競爭即可。其實現(xiàn)在的條帶化磁盤一般都會自動將文件分存，人為的分布已經(jīng)越來越不重要了。
2.有兩服務(wù)器群集，分別為node1和node2 現(xiàn)在要打win200系統(tǒng)補丁，打完后，要重新啟動，如何打補丁，不能影響用戶使用(要用群集的術(shù)語詳細(xì)說明)。
這個具體操作有點忘了。大致是：首先看哪個節(jié)點正在使用，通過節(jié)點Ip(私有)訪問另一個空閑節(jié)點，為其打上補丁，然后在群集管理器中停止該節(jié)點(也可以用命令行方式)，重新啟動。等到啟動完畢，將切換使用節(jié)點，為另一個節(jié)點打補丁。然后重新啟動。
3.有一個A 數(shù)據(jù)庫，分別復(fù)制到B和C B 要求 每次數(shù)據(jù)更新 也同時更新，C 每天更新一次就行，如何制定復(fù)制策略!
這個應(yīng)該考察的是復(fù)制知識。
a->b
1)、如果使用SQL Server復(fù)制功能，那么讓a->b使用事務(wù)性復(fù)制方式(同步復(fù)制)。
2)、如果表不多，也可以自己寫觸發(fā)器，利用linkserver+distribute transaction。
a->c
1)、如果使用SQL Server復(fù)制功能，那么讓a->b使用快照復(fù)制方式，在某一時間點進(jìn)行一次性復(fù)制。
2)、也可以自己寫bat，將a備份后，通過ftp傳輸備份介質(zhì)，恢復(fù)c。(比較麻煩，不推薦)
4.有一個order 表，有90個字段，20個索引，15個復(fù)合索引，其中有3個索引字段超過10個，如何進(jìn)行優(yōu)化
這個問題問的比較沒水平。你不詳細(xì)說明這個表的使用方式(讀寫類的，還是幾乎是靜態(tài)表)，就問人家怎么優(yōu)化?!!還不如問問索引的分布訪問原理更好。
看得出他就想讓你說：那三個索引超過10個，B樹遍例效率很低，適當(dāng)減少字段數(shù)目。如果是SQL2005，可以將選擇性不好的字段放在“索引附加字段”中，以保證索引覆蓋。而且SQL Server由于有鎖升級的毛病，可以考慮拆開表。
5.有一個數(shù)據(jù)庫200G大小，每天增加50M 允許用戶隨時訪問，制定備份策略(詳細(xì)說明)。
這種情況可以采用增量備份方式。每周日做一次全備份，周一到周六作增量備份(由于數(shù)據(jù)量較少，可以考慮每30分鐘增量備份一次)。這樣可以盡量減少性能消耗，而且如果transaction log丟失的情況下，可以保證最多丟失30分鐘數(shù)據(jù)。
6.管理50臺數(shù)據(jù)庫，日常工作是檢查數(shù)據(jù)庫作業(yè)是否完成，你該如何完成這項檢查工作?
這個比較簡單。在每臺機(jī)器上建立linkserver，然后在DBA管理服務(wù)器上做個分布式視圖，每次查詢該視圖，各個機(jī)器上的作業(yè)情況一目了然。分布式視圖寫法：
create view vw_job
as
select 機(jī)器一\ as MName,* from linkserver1..sysjobactivity
union all
select 機(jī)器二\ as MName,* from linkserver2..sysjobactivity
union all
select 機(jī)器三\ as MName,* from linkserver3..sysjobactivity
。。。
7.自定義函數(shù)和存儲過程的區(qū)別是什么，什么情況下只能用自定義函數(shù)，什么情況下只能用存儲過程
這個應(yīng)該是考察存儲過程編寫經(jīng)驗。一般自定義函數(shù)主要用于其他sql中的調(diào)用，如：
select yourfunc(...) from table
這種情況下，一般只能通過函數(shù)實現(xiàn)。
存儲過程的功能要遠(yuǎn)遠(yuǎn)強(qiáng)于函數(shù)，例如動態(tài)執(zhí)行sql(sp_executesql)的使用和一些特殊的功能，自定義函數(shù)中是不支持的，只能用存儲過程實現(xiàn)。
8.SQL 2005 的新特性是什么 ? 與oracle 有什么區(qū)別?
SQL 2005 的新特性一般都是和Oracle學(xué)的。
下面是當(dāng)時被leimin逼著寫的，你可以做個參考：
一、數(shù)據(jù)庫設(shè)計方面
1、字段類型。
varmax)\nvarmax)類型的引入大大的提高了編程的效率，可以使用字符串函數(shù)對CLOB類型進(jìn)行操作，這是一個亮點。但是這就引發(fā)了對varchar和char效率討論的老問題。到底如何分配varchar的數(shù)據(jù)，是否會出現(xiàn)大規(guī)模的碎片?是否碎片會引發(fā)效率問題?這都是需要進(jìn)一步探討的東西。
varbinary(max)代替image也讓SQL Server的字段類型更加簡潔統(tǒng)一。
XML字段類型更好的解決了XML數(shù)據(jù)的操作。XQuery確實不錯，但是個人對其沒好感。(CSDN的開發(fā)者應(yīng)該是相當(dāng)?shù)氖炝?)
2、外鍵的級聯(lián)更能擴(kuò)展
可能大部分的同行在設(shè)計OLTp系統(tǒng)的時候都不愿意建立外鍵，都是通過程序來控制父子數(shù)據(jù)的完整性。但是再開發(fā)調(diào)試階段和OLAp環(huán)境中，外鍵是可以建立的。新版本中加入了SET NULL 和 SET DEFAULT 屬性，能夠提供能好的級聯(lián)設(shè)置。
3、索引附加字段
這是一個不錯的新特性。雖然索引的附加字段沒有索引鍵值效率高，但是相對映射到數(shù)據(jù)表中效率還是提高了很多。我做過試驗，在我的實驗環(huán)境中會比映射到表中提高30%左右的效率。
4、計算字段的持久化
原來的計算字段其實和虛擬字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了計算字段的持久化，這就提高了查詢的性能，但是會加重和update的負(fù)擔(dān)。OLTp慎用。OLAp可以大規(guī)模使用。
5、分區(qū)表
分區(qū)表是個亮點!從分區(qū)表也能看出微軟要做大作強(qiáng)SQL Server的信心。資料很多，這里不詳細(xì)說。但是重點了解的是：現(xiàn)在的SQL Server2005的表，都是默認(rèn)為分區(qū)表的。因為它要支持滑動窗口的這個特性。這種特性對歷史數(shù)據(jù)和實時數(shù)據(jù)的處理是很有幫助的。
但是需要注意的一點，也是我使用過程中發(fā)現(xiàn)的一個問題。在建立function->schema->table后，如果在現(xiàn)有的分區(qū)表上建立沒有顯式聲明的聚集索引時，分區(qū)表會自動變?yōu)榉欠謪^(qū)表。這一點很讓我納悶。如果你覺得我的非分區(qū)索引無法對起子分區(qū)，
你可以提醒我一下呀!沒有任何的提醒，直接就變成了非分區(qū)表。不知道這算不算一個bug。大家也可以試試。
分區(qū)表效率問題肯定是大家關(guān)心的問題。在我的試驗中，如果按照分區(qū)字段進(jìn)行的查詢(過濾)效率會高于未分區(qū)表的相同語句。但是如果按照非分區(qū)字段進(jìn)行查詢，效率會低于未分區(qū)表的相同語句。但是隨著數(shù)據(jù)量的增大，這種成本差距會逐漸減小，趨于相等。(500萬數(shù)量級只相差10%左右)
6、CLR類型
微軟對CLR作了大篇幅的宣傳，這是因為數(shù)據(jù)庫產(chǎn)品終于融入.net體系中。最開始我們也是狂喜，感覺對象數(shù)據(jù)庫的一些概念可以實現(xiàn)了。但是作了些試驗，發(fā)現(xiàn)使用CLR的存儲過程或函數(shù)在達(dá)到一定的閥值的時候，系統(tǒng)性能會呈指數(shù)級下滑!這是非常危險的!只使用幾個可能沒有問題，當(dāng)一旦大規(guī)模使用會造成嚴(yán)重的系統(tǒng)性能問題!
其實可以做一下類比，Oracle等數(shù)據(jù)庫產(chǎn)品老早就支持了java編程，而且提供了java池參數(shù)作為用戶配置接口。但是現(xiàn)在有哪些系統(tǒng)大批使用了java存儲過程?!連Oracle自己的應(yīng)用都不用為什么?!還不是性能有問題!否則面向?qū)ο蟮臄?shù)據(jù)庫早就實現(xiàn)了!
建議使用CLR的地方一般是和應(yīng)用的復(fù)雜程度或操作系統(tǒng)環(huán)境有很高的耦合度的場景。如你想構(gòu)建復(fù)雜的算法，并且用到了大量的指針和高級數(shù)據(jù)模型�；蛘呤且筒僮飨到y(tǒng)進(jìn)行Socket通訊的場景。否則建議慎重!
7、索引視圖
索引視圖2k就有。但是2005對其效率作了一些改進(jìn)但是schema.viewname的作用域真是太限制了它的應(yīng)用面。還有一大堆的環(huán)境參數(shù)和種種限制都讓人對它有點卻步。
8、語句和事務(wù)快照
語句級快照和事務(wù)級快照終于為SQL Server的并發(fā)性能帶來了突破。個人感覺語句級快照大家應(yīng)該應(yīng)用。事務(wù)級快照，如果是高并發(fā)系統(tǒng)還要慎用。如果一個用戶總是被提示修改不成功要求重試時，會殺人的!
9、數(shù)據(jù)庫快照
原理很簡單，對要求長時間計算某一時間點的報表生成和防用戶操作錯誤很有幫助。但是比起Oracle10g的閃回技術(shù)還是細(xì)粒度不夠。可惜!
10、Mirror
Mirror可以算是SQL Server的Data guard了。但是能不能被大伙用起來就不知道了。
二、開發(fā)方面
1、Ranking函數(shù)集
其中最有名的應(yīng)該是row_number了。這個終于解決了用臨時表生成序列號的歷史，而且SQL Server2005的row_number比Oracle的更先進(jìn)。因為它把Order by集成到了一起，不用像Oracle那樣還要用子查詢進(jìn)行封裝。但是大家注意一點。如下面的例子：
select ROW_NUMBER() OVER (order by aa)
from tbl
order by bb
會先執(zhí)行aa的排序，然后再進(jìn)行bb的排序。
可能有的朋友會抱怨集成的order by，其實如果使用ranking函數(shù),Order by是少不了的。如果擔(dān)心Order by會影響效率，可以為order by的字段建立聚集索引，查詢計劃會忽略order by 操作(因為本來就是排序的嘛)。
2、top
可以動態(tài)傳入?yún)?shù)，省卻了動態(tài)SQL的拼寫。
3、Apply
對遞歸類的樹遍歷很有幫助。
4、CTE
個人感覺這個真是太棒了!閱讀清晰，非常有時代感。
5、try/catch
代替了原來VB式的錯誤判斷。比Oracle高級不少。
6、pivot/unpivot
個人感覺沒有case直觀。而且默認(rèn)的第三字段(還可能更多)作為group by字段很容易造成新手的錯誤。
三、DBA管理方面
1、數(shù)據(jù)庫級觸發(fā)器
記得在最開始使用2k的時候就要用到這個功能，可惜2k沒有，現(xiàn)在有了作解決方案的朋友會很高興吧。
2、多加的系統(tǒng)視圖和實時系統(tǒng)信息
這些東西對DBA挑優(yōu)非常有幫助，但是感覺粒度還是不太細(xì)。
3、優(yōu)化器的改進(jìn)
一直以來個人感覺SQL Server的優(yōu)化器要比Oracle的聰明。SQL2005的更是比2k聰明了不少
【十個經(jīng)典的數(shù)據(jù)庫面試問題】相關(guān)文章：
外企面試最愛提的十個問題07-11
面試撞墻的十個細(xì)節(jié)07-11
面試的衣著問題07-11
面試的經(jīng)典問題與解答07-11
《面試》閱讀問題07-11
面試中的問題07-11
面試后的問題07-11
面試問題？？07-11
面試準(zhǔn)備問題07-11