【IT168技術】死鎖如何跟蹤;阻塞如何跟蹤和查找;發現有問題的語句後，如何進行處理;用Profile做跟蹤時，一般我們需要跟蹤哪些事件;
dbcc traceon(1204) 可以開打跟蹤死鎖的標記，sqlserver2005新增了1222跟蹤標誌，就是格式更詳細，死鎖的信息會記錄在errlog文件裡，順便說下errlog一共有errlog，errlog1~errlog6共7個文件，關於這些可以看看books online，如果覺得books online太乏味，可以看看徐海蔚的《Microsoft SQLServer企業級平臺管理實踐》;
相對來說，阻塞的問題比死鎖要嚴重，死鎖只是犧牲部分進程，阻塞的話會導致整個系統癱瘓，阻塞的定位我有一篇專門的博客介紹：sqlserver阻塞定位
要跟蹤死鎖的話，當然是選擇「鎖」事件，不過我一般用profiler都是做性能調優的，選 常規——》模板名——》SQLProfileTuning 就ok了，死鎖很少跟蹤，因為我們的sqlserver降低了事務隔離級別，基本不會產生死鎖，有的話也在可接受的範圍內，都是凌晨運行作業時產生的，也不會太多。
Windows日誌主要有哪幾種，SQLServer日誌一般保留幾個，什麼情況下會產生新的SQL日誌;資料庫日誌恢復模式有哪幾種，區別是什麼;資料庫日誌突然變得很大，而且你無法收縮，可能的原因是什麼，怎麼查找原因，分別將如何處理;
windows的日誌可以自己看iis就明白了，我一般只看應用程式，一次發現asp.net拋出的錯誤和異常，解決之;sqlserver的日誌一般保留7個，errlog，errlog1~errlog6，每次資料庫重啟都會產生新的日誌，新的日誌命名為errlog，舊的日誌也會跟著改名，之前老的errlog改為errlog1，老的errlog1 改成 errlog2，直到 errlog5 改成 errlog6， 之前的errlog6會被刪除，所以如果資料庫出錯千萬不要盲目充能更新啟動，可以先看看錯誤日誌，多次重啟之後可能就丟失了最原始的錯誤信息;
應該是資料庫恢復模式吧，簡單，大容量，完全;用哪個要視情況而定，不重要的業務可以用簡單，重要業務就要用完整;
完整模式支持最完善的備份和還原方案，可以還原到某個時間點，簡單模式只能還原到該備份裡面的數據，無法還原到時間點，大容量模式一般只在需要進行批量數據導入的時候才使用;
日誌突然很大而且無法收縮，其實有很多種可能，不過不管是哪一種可能，都離不開一個現象，有一個更新(insert，update)動作工作正在執行，而且短時間內不會停止，既然短時間內不會停止，那麼我們就應該想到master.dbo.sysprocesses這個表，可以通過 select spid from master.dbo.sysprocesses where open_tran > 0 查看當前運行時間比較長的進程，看看到底有什麼動作，我們還可以通過 dbcc inputbuffer(@spid) 找到語句;
分區表和分區視圖是什麼概念，一般是在什麼情況下使用，有啥好處;
答：先說分區視圖，這個在sql2000就已經支持，他其實還是一個視圖;
分區表是sql2005新提供的功能，邏輯上他就是一個表，物理上它可以把數據保存在多個磁碟，以此提高io，提高並發量;
2005下應該都是用分區表了，數據量龐大的時候可以按分區函數把數據分開，對於查詢性能有很大的提升，不過我無論如何都認為太大的表不好，2000下我一般都是分表的，比如歷史表，或者按自己業務需求制定分表方案。
如何比較兩個同結構的表數據的差異;如果表損壞了，如何修復;如何在備份文件有問題的情況下儘量還原數據;如何將一個表的Identity屬性歸零;
要比較兩個表所有欄位的值，光通過sqlserver可能實現不了，可能需要藉助第3方工具，但如果數據量很大，什麼工具都很難完美實現，提出這個問題，應該是想找到部分丟失的數據，如果是這樣，我一般是通過找到出問題的那段時間開始，把那之後的數據比較一下，然後通過join 把數據update成想要的;
如果表壞了，有個dbcc checktable的命令，不過我至今沒遇到過;
一般備份文件有問題，但是可以還原成功，不過會報些錯誤，可能導致資料庫不穩定，可以嘗試dbcc checkdb命令，之後再新建一個庫，把數據導入新庫中;
identity屬性的問題，delete並不會歸零，因為在結構中還保存了最大值，truncate table就可以
CheckPoint和LazyWriter區別;DDL Trigger 和 DML Trigger有啥用，區別是啥;
在sqlserver2000隻有checkpoint，lazywriter 是 sql2005以後加入的，可以簡單認為他們是sqlserver系統內部的進程;
checkpoint 需要達到一定條件才會觸發，觸發之後會強制把髒頁寫入磁碟;
lazywriter 是每隔一段時間啟動一次，然後檢查free list，看看是否低於某個閥值，如果低於這個閥值，他就幹活，把髒頁數據放入free list，同時寫入磁碟;
可以打一個形象的比喻：lazywriter是個懶漢，他每隔一會兒就睡(定時啟動)，睡醒了就看看自己的錢包(free list)，如果他認為錢包的錢少了，他就拿錢(髒頁放入free list)幹活(髒頁寫入磁碟)，checkpoint是一個很賣力的夥計，只有有事情通知他一聲，他立馬一聲不吭的把把活幹完(髒頁寫入磁碟)，不會在乎自己的錢包(free list);
DDL Trigger是針對結構的觸發器，比如新建表，修改表，刪除表;
DML Trgger是針對數據的觸發器，比如insert，delete，update表數據;
Mirroring 和Logshipping 的區別和使用場景;SQLServer的Mirroring與Oracle的哪像技術比較接近，它們的區別是啥;
Mirroring，即資料庫鏡像，一般用作高可用性的故障轉移集群，需要 主伺服器，鏡像伺服器，見證伺服器3臺，當見證伺服器檢測到主伺服器出現故障時，會自動把資料庫連接指向鏡像服。實現的基本流程如下，用戶訪問主庫，並提交數據，主庫會把日誌傳送到鏡像伺服器，做鏡像的時候也有些麻煩,必須首先保證主庫和鏡像庫數據一致才能建立鏡像關係，所以如果你的主庫時刻在產生數據，那鏡像做起來估計就費神了;其實我還有個疑問，要是見證伺服器掛了怎麼辦，ms貌似沒給出方案;
LogShipping，即日誌傳送，也有主庫-輔助庫，沒有見證庫了，他定時把事務日誌傳送到輔助庫，其實就是不斷做back log 和 restore 的操作，他有個缺陷，輔助庫每次restore都需要斷開所有連接，所以輔助庫並不適合讓用戶訪問，這個方案都是可以作為容災備份的一個方案，當主庫出現故障的時候，馬上手工切換到輔助庫即可恢復。
相比之下我覺得logshipping更合適一些，做的時候沒有那麼多條件限制;
對Oracle不了解，所以無法比較;
Mirroring的搭建步驟，Mirroring三種模式區別，Mirroring 中同步和異步的原理和要求，搭建了Mirroring後，需要對資料庫日誌做什麼處理;
這個搭建步驟還是查資料比較可靠。
三種模式，高安全(帶自動故障轉移)同步傳輸 ，高安全(不帶自動故障轉移)同步傳輸，高性能，異步傳輸數據，同步就是主庫要等待鏡像庫的回應消息才會提交事務，異步就是不等待回應消息就已經提交日誌，因為等待消息需要時間，所以不等待性能會更高，但不是很安全，鏡像資料庫的數據有可能和主庫的數據不一致。
需要對資料庫日誌做什麼處理?沒看懂這句;
Replication配置和使用場景;Replication有哪幾種模式;PUSH和PULL有啥區別;搭建Replication後會產生一個什麼庫;報錯時用什麼來查看報錯的具體語句，清理掉某個庫的Replication使用什麼語句，查看同步鏈信息主要通過哪些表;
配置的步驟足夠寫一篇博客，大概的步驟如下：1. 標識分發伺服器;2. 在此分發伺服器上創建分發資料庫;3. 啟用將使用此分發伺服器的發布伺服器;4. 啟用發布資料庫;5. 啟用將接收發布數據的訂閱伺服器;其實裡面很多細節要注意，可以google得到不錯的教程，然後手動操作一遍就知道了，沒什麼難度。
場景：一般都是作為數據同步用;有推和拉模式，分發代理程序在分發伺服器上運行即推，在訂閱伺服器上運行即拉;
會產生一個distribution庫;
報錯的話，一般監視器裡面都有優紅X的，如果覺得這樣看太麻煩，可以直接查 distribution庫的dbo.MSdistribution_history表，所有分發相關的信息都保存在了distrition庫;
清理replication看似簡單，其實還分很多情況的，比如push，pull模式，還是日誌，快照，合併模式，因這些不同，都需要執行不同的系統存儲過程，既然ms給我們提供的好用的企業管理器，我們大可以用他來簡化我們的工作，如果一定要腳本，那就找吧，系統存儲過程一般以 sp_ 打頭，清楚一般包含 "del","drop","remove" 等關鍵字，比如我通過 select * from master..sysobjects
where xtype = 'p' and name like '%repl%' and name like '%remove%'，sql2000下可以查到相關的過程和用法;說實話誰也不能保證自己什麼都會，不會應該保證在遇到問題的時候能馬上找到解決的辦法，這比死記硬背答案要來的有效些;
在distribution.dbo.MSarticles 可以查看同步鏈;
Replication發布端的表能truncate嗎，為什麼;Replication Identity列如何處理、缺失欄位錯誤如何處理、主鍵衝突錯誤如何處理、如何跳過指定的錯誤、訂閱端表被刪除了如何處理、大規模改動數據如何處理;某條同步鏈因為其中的某個表一次性改動數據很大造成同步鏈的嚴重延時，要求儘快恢復同步鏈，如何處理。
不能truncate，具體見我的另外一篇：DBA之問：Replication發布端的表能truncate嗎，為什麼;
發布的時候默認情況下，目標表不會建立identity欄位，也的確不該建立;
缺失欄位這種情況不應該發生，如果發生了是技術人員的操作失敗，如果此列不許發布，去掉就可以了，如果要在發布之後再對列進行添加或者刪除，可以參考 sp_repladdcolumn , sp_repldropcolumn 這兩個系統存儲過程;
主鍵衝突，首先忽略，然後再檢查兩個表數據量是否一樣，發生這種問題可能是有技術人員違規在訂閱庫上修改了表，這是不被允許的，訂閱庫的庫只適合做查詢用，不應該人為手動更新;
訂閱端表被刪除，這樣監視器是會提示錯誤的，應該重新初始化數據;
不建議同事進行大規模的數據改動，因為這會導致同步太頻繁，而沒一個同步動作都需要等待發布端伺服器的確認，如果生產資料庫需要不斷的等待確認，那等於降低了並發量，如果等待隊列和時間都太長有可能導致資料庫太慢而停止服務，我們遇到過類似情況。
SSB(Service Broker)使用場景，如何創建，都會創建些什麼對象，有啥優缺點，主要通過什麼方式實現不同伺服器之間的消息傳遞;可以通過哪些方式排錯;
這是sql2005以後新增的功能，一直用的2000，對這個還沒認真研究過，只知道可以用來做分布式的數據同步，而且是異步實現的。
後語： 這中間的10題比之前的10題難度提高了不少，有些問題在這之前我只是用他們來幹活，並沒具體研究他們怎麼幹活的，通過這10題我對sqlserver的了解又加深了一步，而且很多問題，都是抱著追究本質的態度。在這些題目裡面，有些是sqlserver2005新增的功能，因為本人實在沒用過，所以不敢妄給答案，以免誤人子弟。知識無限，能力有限，文中難免存在不對的地方，本人秉承著相互交流的態度，也很樂意和從事sqlserver工作的兄弟們交流。
SQL Server DBA十個基礎經典例題解答：http://www.cnblogs.com/gezifeiyang/archive/2011/11/19/2255546.html