① sqlserver鎖表機制
這個問題要具體分析：
第一，事務隔離級別基本兩種模式，一種是阻塞式（read committed，repeatable read，serializable）
，一種是非阻塞式(read uncommitted,snapshot)。
默認是read committed，這種情況一般在更新表的時候，如果不使用hint 提示，基本是先對表添加IX鎖，級別不算高，基本和其他鎖兼容，但是repeatable read，serializable 事務隔離級別就會先對表添加IX鎖，然後向X鎖轉化，而X鎖和大多數鎖都不兼容，容易發生表阻塞。
第二種隔離級別不會有以上問題，但是又引入了其它的問題。
以上是一種情況。
另外一種就是 鎖升級，一個鎖是96B內存，如果太多，sqlserver就會升級為表鎖，一般是5000以上行級鎖就升級為一個表X鎖。
所以適當的文件分組和表分區 是有必要的。
其次就是資源互相引用導致事務長時間不能釋放，導致真正的死鎖，不過SQL2005以後，這種情況發生的概率很低。
留個問題你自己去想。
兩個SQL，兩個連接，同時執行。
update A set A.NAME=xxx where A.id=55
update A set A.NAME=xxx where A.id=56, 如果 56 不存在你說會發生什麼情況呢？
② 揭秘SQL Server 2014有哪些新特性
1、內存資料庫
在傳統的資料庫表中，由於磁碟的物理結構限制，表和索引的結構為B-Tree，這就使得該類索引在大並發的OLTP環境中顯得非常乏力，雖然有很多辦法來解決這類問題，比如說樂觀並發控制，應用程序緩存，分布式等。但成本依然會略高。而隨著這些年硬體的發展，現在伺服器擁有幾百G內存並不罕見，此外由於NUMA架構的成熟，也消除了多CPU訪問內存的瓶頸問題，因此內存資料庫得以出現。
內存的學名叫做RandomAccess Memory（RAM），因此如其特性一樣，是隨機訪問的，因此對於內存，對應的數據結構也會是Hash-Index，而並發的隔離方式也對應的變成了MVCC，因此內存資料庫可以在同樣的硬體資源下，Handle更多的並發和請求，並且不會被鎖阻塞，而SQLServer 2014集成了這個強大的功能，並不像Oracle的TimesTen需要額外付費，因此結合SSDAS Buffer Pool特性，所產生的效果將會非常值得期待。
SQLServer內存資料庫的表現形式
在SQL Server的Hekaton引擎由兩部分組成：內存優化表和本地編譯存儲過程。雖然Hekaton集成進了關系資料庫引擎，但訪問他們的方法對於客戶端是透明的，這也意味著從客戶端應用程序的角度來看，並不會知道Hekaton引擎的存在。如圖1所示。
圖8.內存優化表+本地編譯存儲過程
因此不難看出，內存優化表+本地編譯存儲過程有接近幾十倍的性能提升。
③ Oracle資料庫和Sql server資料庫各有什麼優缺點
1.Oracle跨平台，SQL
Server只能運行在Windows上，而Windows能夠安裝的硬體是有限的，如Sun的Sparc伺服器不能安裝Windows，一些大型機、小型機也只能裝UNIX，在這些高端機器上就只能跑Oracle了，這註定了Oracle就是高端資料庫，而SQL
Server呢，中低端。
2.Oracle真正實現了行級鎖，SQL
Server也宣稱實現了行級鎖，但你實際去試，如果不加索引，其實是不行的。
3.Oracle因為有多版本數據的技術，讀寫操作不會相互等待，雖然SQL
Server
2005學習Oracle增加了snapshot機制，從而也引進了多版本數據（MySQL也有多版本數據機制，不能說一定是學習Oracle），但是實際效果感覺就是2個版本的數據，隔離級別為read
committed時候，讀寫不再相互等待，但是把隔離設置為Serializable還是會產生讀寫相互等待。
4.Oracle的事務日誌歸檔相當方便，而SQL
Server要用事務日誌備份來實現，而且還要配置自動作業，啟動agent服務。
5.Oracle的數據字典豐富，使得DBA容易判斷資料庫的各種情況，雖然SQL
Server
2005學習了Oracle的數據字典的特點，但從數量及方便程度上還是相差太多。個人感覺這是Oracle最人性化的地方。
6.Oracle的PL/SQL比SQL
Server的T-SQL功能強大很多。
7.Oracle的觸發器比SQL
Server的種類多幾種。
8.oracle的備份恢復原理相當簡單明了，備份就在操作系統上拷貝數據文件好了，恢復呢，再拷貝回來，數據是舊的，不怕，應用重做日誌好了。SQLServer呢，雖然原理在本質上還是這些，但操作起來麻煩多了，麻煩到讓你體會不到其本質。
9.Oracle資料庫啟動可以有多個階段，使得DBA可以在不同的情況下，通過啟動到特定的階段解決一些特殊問題，而SQLServer只要服務一啟動，所有資料庫就都打開了。
10．SQLServer給人的感覺是簡單易用，但是我要說，如果你繼續向前走，就會發現SQLServer的體系結構相當復雜（注意我這里是說的復雜），大體還是沿襲的Sybase的體系結構，這種復雜結構，估計很難有根本性的改變，而Oracle呢，時間越長你越會覺得其體系結構嚴謹，雖然開始會感覺很難。我的一個比喻，SQLServer是傻瓜相機（就是那些一兩千的小數碼），Oracle是單反相機（40D，5D，D300），如果你是入門者，那用傻瓜相機好了，在各種環境下拍攝，基本都過得去，用單反，光圈、快門都要自己設定，反倒不如傻瓜相機的效果，如果你是高手了，那傻瓜相機就很難得心應手了。
11．Oracle的書籍一般都比較深，隨便一說就是一大批，EpertOracle、PracticalOracle8i、Cost－basedOracle，SQLServer呢，恐怕只有那套InsideSQLServer了，雖然SQLServer的書籍數量比Oracle的多的多（特別是在國內），但多數都是stepbystep的入門書。
12.對比SQL＊Plus與sqlcmd（或2000的osql，6.5的isql），sqlcmd的功能是太簡陋，差得太多了。
13.SQLServer的最大優點就是和Windows結合緊密，易用，但是要注意事情都是兩面的，這些優點可能導致其致命的缺點，例如易用，使得搞SQLServer的人可以不求甚解，有時候不求甚解是沒問題的，但是有時候不求甚解可能會造成災難，特別是對搞資料庫的人來說。不好意思，本來要說SQLServer的優點呢，最後也成了缺點了。
④ sqlserver snapshot快照怎麼用jdbc獲取
資料庫快照為你現有的資料庫創建了一個資料庫的殼，然後無論何時當數據頁被修改的時候，改變也同時被寫入稀疏文件(sparse file)當中
⑤ sqlserver 復制新增需要同步的對象一定要重新發布么
把屬性 allow_anonymous 和 immediate_sync 改為false ,然後重新做snapshot,這樣snapshot只會對新增加(異動)article升效...建議你先在test環境測試後再去proction.
⑥ sqlserver 並發問題
從來沒有真正的同時寫入
使用事務一個一個寫入吧，不報錯就成了，
還有，寫操作速度很快的，完全不用糾結等待的時間
⑦ 如何查看sqlserver的啟動/停止日誌
您好，很高興為您解答。
預設情況下，在Program FilesMicrosoft SQL ServerMSSQLLog目錄下。最近的錯誤日誌名稱是ERRORLOG,如果停止並重啟SQL Server，舊的日誌將被壓縮和新建一個文件。此外，也可以通過DBCC ERRORLOG 命令或者sp_cycle_errorlog 系統存儲過程回收錯誤日誌。
[@more@]
以下是一些沒有寫在文檔中但是眾所周知的系統存儲過程，這些存儲過程可以從SQL Server自身讀取錯誤日誌。
exec xp_enumerrorlogs 1 will list SQL Engine errorlog file numbers
exec xp_readerrorlog <errorlognumber>, 1 will return the content of the requested Engine errorlog file.
exec xp_enumerrorlogs 2 will list the Agent error log file numbers
exec xp_readerrorlog <errorlognumber>, 2 will return the content of the requested Agent error log file.
舉例：
exec xp_enumerrorlogs 2
存檔# 日期 日誌文件大小(位元組)
1 08/06/2012 10:52 11399188
2 07/13/2012 00:58 1048
3 07/13/2012 00:55 1048
4 07/13/2012 00:55 12682508
5 06/16/2012 09:53 12869230
6 05/20/2012 05:38 10492
7 05/20/2012 05:25 11766
8 05/20/2012 05:08 10012278
9 04/29/2012 00:41 15371150
0 08/08/2012 11:30 939606
exec xp_readerrorlog 1, 2
時間 錯誤級別 內容
2012-07-13 01:07:03.0 3 [393] 正在等待 SQL Server 恢復資料庫...
2012-07-13 01:18:29.0 3 [100] Microsoft SQLServerAgent 版本 9.00.1399.06 (內部版本號 x86 unicode 零售): 進程 ID 1996
2012-07-13 01:18:29.0 3 [101] SQL Server SVCTAG-4GCYY2X 版本 9.00.1399 (連接限制: 0)
2012-07-13 01:18:29.0 3 [102] SQL Server ODBC 驅動程序版本 9.00.1399
2012-07-13 01:18:29.0 3 [103] 驅動程序使用的 NetLib 是 DBNETLIB.DLL；本地主機伺服器是
2012-07-13 01:18:29.0 3 [310] 檢測到 8 個處理器和 4096 MB RAM
2012-07-13 01:18:29.0 3 [339] 本地計算機是 SVCTAG-4GCYY2X，運行的是 Windows NT 5.2 (3790) Service Pack 2
2012-07-13 01:18:29.0 3 [431] 正在填充子系統緩存...
2012-07-13 01:18:36.0 3 [432] 子系統緩存中有 11 個子系統
2012-07-13 01:18:36.0 3 [124] 已成功載入子系統「TSQL」(最大並發數: 160)
2012-07-13 01:18:37.0 3 [124] 已成功載入子系統「ActiveScripting」(最大並發數: 80)
2012-07-13 01:18:37.0 3 [124] 已成功載入子系統「CmdExec」(最大並發數: 80)
2012-07-13 01:18:38.0 3 [124] 已成功載入子系統「Snapshot」(最大並發數: 800)
2012-07-13 01:18:38.0 3 [124] 已成功載入子系統「LogReader」(最大並發數: 200)
~ O(∩_∩)O~
⑧ SQLServer快照功能以及其查詢如何操作
SQLServer資料庫的快照只能通過SQL語句創建，以msdb資料庫為例進行說明：
1、執行以下代碼，看看MSDB資料庫有多少數據文件
EXEC SP_HELPDB msdb
查詢結果是完全一樣的。
（如有幫助，請採納，謝謝）
⑨ sqlserver with snapshot 有什麼作用
資料庫快照為你現有的資料庫創建了一個資料庫的殼，然後無論何時當數據頁被修改的時候，改變也同時被寫入稀疏文件(sparse file)當中。當人們獲取數據的時候，數據中沒有變化的部分是從原始資料庫中得到的，而改變的部分則是從稀疏文件中獲得。
稀疏文件和資料庫快照
當資料庫快照被創建的時候，第一次的創建是十分迅速的。因為實際上只是創建了一個用來記錄被修改文件的殼。隨著時間的推移，文件不斷的被修改，這些修改頁都將被寫進稀疏文件。你的主資料庫中修改的文件越多，就有越多的文件被寫入稀疏文件。因此，有越來越多的磁碟空間被用來保存你的主資料庫和快照的資料庫，也增加了你伺服器的磁碟輸入輸出的次數。
稀疏文件被寫入大小為64KB的分組塊當中。每一個分組塊增量能包含8個大小為8KB的數據頁。所以，每次在你的主資料庫中有任何的數據改變，都會先把數據頁拷貝到稀疏文件當中，然後再將主資料庫中文件的變化寫入稀疏文件。一旦數據頁被寫入稀疏文件，他們就不再需要被寫出來。因為頁面的全部內容被保護起來，讓其處於當快照建立時的狀態。
為了實現優化磁碟並消除磁碟沖突，在主資料庫以外的獨立的驅動器和陣列中創建稀疏文件是一個明知之舉。原因有二：
其一，當快照被建立的時候，沒有數據被寫入稀疏文件。從快照進行的所有的數據訪問實際上都是在主資料庫文件當中的。隨著時間的推移，你會通過在不同的陣列和磁碟上從主文件資料庫讀取未被修改過的文件和從稀疏文件讀取修改過的數據的方法來減少輸入輸出的負擔。
其二，根據你資料庫數據的易變動性和數據變化的數量，你可以通過將在主資料庫的讀取工作和稀疏文件的寫入工作分離來減少輸入輸出的瓶頸大小。
使用資料庫快照
在這里你一定要記住的事情就是，你的查詢請求訪問的依然是你的主資料庫。當初始的快照被建立的時候，其實僅建立了一個空的殼子。所有的數據請求都是在主資料庫文件中被完成的。隨著時間的流逝和文件不斷地被修改，就有一些數據請求從初始的資料庫文件中分離出來指向了稀疏文件。所以，盡管看上去它是一個獨立的資料庫，那些根本的數據仍然是源於主資料庫。
鑒於此，你需要確定不要試圖去進行你日常活動范圍以外的查詢。這樣說吧，你創建了一個快照，接著你進行了讀寫的操作，並對每個人做了記錄。當那些記錄被執行查詢操作時，他們仍然繼續影響著主資料庫。所以你要保證任何新的活動都不會影響主數據的活動。
另外，你需要記住到底有哪些數據是被寫入稀疏文件里的，而不是認為所有可能的數據都被寫進了稀疏文件。基本上，當快照被創立時，主資料庫的大小就是快照稀疏文件的潛在大小。如果稀疏文件中的數據量已經達到甚至超過資料庫的一半時，也許再創造一個資料庫的完整拷貝來取代現有的快照是一個更好的主意。
綜上所述，我認為，資料庫快照是一個非常新的功能。我也希望在SQL Server2005的所有版本，而不僅僅在企業版和開發版中可以應用這個功能。有一個沒有討論的地方就是我們沒有討論有關對資料庫鏡像使用快照。其實，無論是鏡像還是原資料庫，快照都給了你最好的方法。因為鏡像是離線的，你並不能訪問那些數據，所以說無論是鏡像還是原資料庫，它都給了你最好的方法。花一些時間去理解快照是如何應用於你的環境中的，並且確認你監視著維護快照的影響以及通過快照進行的數據存儲。