推薦：解決SQL Server無法打開用戶默認數(shù)據(jù)庫的問題
無法打開用戶默認數(shù)據(jù)庫，登錄失敗,這是SQL Server使用者熟悉的問題之一。在使用企業(yè)管理器、查詢分析器、各類工具和應(yīng)用軟件的時候，只要關(guān)系到連接SQL Server數(shù)據(jù)庫的時候，都有可能會碰到此問題,引起此錯誤發(fā)生的原因比較多,下面我們就來詳細分析引起此問

　　10、分布式分區(qū)視圖可用于實現(xiàn)數(shù)據(jù)庫服務(wù)器聯(lián)合體。聯(lián)合體是一組分開管理的服務(wù)器，但它們相互協(xié)作分擔(dān)系統(tǒng)的處理負荷。這種通過分區(qū)數(shù)據(jù)形成數(shù)據(jù)庫服務(wù)器聯(lián)合體的機制能夠擴大一組服務(wù)器，以支持大型的多層 Web 站點的處理需要。有關(guān)更多信息，參見設(shè)計聯(lián)合數(shù)據(jù)庫服務(wù)器。（參照SQL幫助文件’分區(qū)視圖’）
　　
　　a、在實現(xiàn)分區(qū)視圖之前，必須先水平分區(qū)表
　　
　　b、在創(chuàng)建成員表后，在每個成員服務(wù)器上定義一個分布式分區(qū)視圖，并且每個視圖具有相同的名稱。這樣，引用分布式分區(qū)視圖名的查詢可以在任何一個成員服務(wù)器上運行。系統(tǒng)操作如同每個成員服務(wù)器上都有一個原始表的復(fù)本一樣，但其實每個服務(wù)器上只有一個成員表和一個分布式分區(qū)視圖。數(shù)據(jù)的位置對應(yīng)用程序是透明的。
　　
　　11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收縮數(shù)據(jù)和日志 DBCC SHRINKDB,DBCC SHRINKFILE. 設(shè)置自動收縮日志.對于大的數(shù)據(jù)庫不要設(shè)置數(shù)據(jù)庫自動增長，它會降低服務(wù)器的性能。在T-sql的寫法上有很大的講究，下面列出常見的要點：首先，DBMS處理查詢計劃的過程是這樣的：
　　
　　1、 查詢語句的詞法、語法檢查
　　
　　2、 將語句提交給DBMS的查詢優(yōu)化器
　　
　　3、 優(yōu)化器做代數(shù)優(yōu)化和存取路徑的優(yōu)化
　　
　　4、 由預(yù)編譯模塊生成查詢規(guī)劃
　　
　　5、 然后在合適的時間提交給系統(tǒng)處理執(zhí)行
　　
　　6、 最后將執(zhí)行結(jié)果返回給用戶其次，看一下SQL SERVER的數(shù)據(jù)存放的結(jié)構(gòu)：一個頁面的大小為8K(8060)字節(jié)，8個頁面為一個盤區(qū)，按照B樹存放。
　　
　　12、Commit和rollback的區(qū)別 Rollback:回滾所有的事物。 Commit:提交當前的事物. 沒有必要在動態(tài)SQL里寫事物，如果要寫請寫在外面如： begin tran exec(@s) commit trans 或者將動態(tài)SQL 寫成函數(shù)或者存儲過程。
　　
　　13、在查詢Select語句中用Where字句限制返回的行數(shù),避免表掃描,如果返回不必要的數(shù)據(jù)，浪費了服務(wù)器的I/O資源，加重了網(wǎng)絡(luò)的負擔(dān)降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯(lián)接訪問表,后果嚴重。
　　
　　14、SQL的注釋申明對執(zhí)行沒有任何影響
　　15、盡可能不使用光標，它占用大量的資源。如果需要row-by-row地執(zhí)行，盡量采用非光標技術(shù),如：在客戶端循環(huán)，用臨時表，Table變量，用子查詢，用Case語句等等。游標可以按照它所支持的提取選項進行分類： 只進 必須按照從第一行到最后一行的順序提取行。FETCH NEXT 是唯一允許的提取操作,也是默認方式�？蓾L動性可以在游標中任何地方隨機提取任意行。游標的技術(shù)在SQL2000下變得功能很強大，他的目的是支持循環(huán)。有四個并發(fā)選項 READ_ONLY：不允許通過游標定位更新(Update)，且在組成結(jié)果集的行中沒有鎖。 OPTIMISTIC WITH valueS:樂觀并發(fā)控制是事務(wù)控制理論的一個標準部分。樂觀并發(fā)控制用于這樣的情形，即在打開游標及更新行的間隔中，只有很小的機會讓第二個用戶更新某一行。當某個游標以此選項打開時，沒有鎖控制其中的行，這將有助于最大化其處理能力。如果用戶試圖修改某一行，則此行的當前值會與最后一次提取此行時獲取的值進行比較。如果任何值發(fā)生改變，則服務(wù)器就會知道其他人已更新了此行，并會返回一個錯誤。如果值是一樣的，服務(wù)器就執(zhí)行修改。選擇這個并發(fā)選項 OPTIMISTIC WITH ROW VERSIONING:此樂觀并發(fā)控制選項基于行版本控制。使用行版本控制，其中的表必須具有某種版本標識符，服務(wù)器可用它來確定該行在讀入游標后是否有所更改。在 SQL Server 中，這個性能由 timestamp 數(shù)據(jù)類型提供，它是一個二進制數(shù)字，表示數(shù)據(jù)庫中更改的相對順序。每個數(shù)據(jù)庫都有一個全局當前時間戳值：@@DBTS。每次以任何方式更改帶有 timestamp 列的行時，SQL Server 先在時間戳列中存儲當前的 @@DBTS 值，然后增加 @@DBTS 的值。如果某 個表具有 timestamp 列，則時間戳?xí)�被記到行��。服�?wù)器就可以比較某行的當前時間戳值和上次提取時所存儲的時間戳值，從而確定該行是否已更新。服務(wù)器不必比較所有列的值，只需比較 timestamp 列即可。如果應(yīng)用程序?qū)�沒有 timestamp 列的表要求基于行版本控制的樂觀并發(fā)，則游標默認為基于數(shù)值的樂觀并發(fā)控制。 SCROLL LOCKS 這個選項實現(xiàn)悲觀并發(fā)控制。在悲觀并發(fā)控制中，在把數(shù)據(jù)庫的行讀入游標結(jié)果集時，應(yīng)用程序?qū)⒃噲D鎖定數(shù)據(jù)庫行。在使用服務(wù)器游標時，將行讀入游標時會在其上放置一個更新鎖。如果在事務(wù)內(nèi)打開游標，則該事務(wù)更新鎖將一直保持到事務(wù)被提交或回滾；當提取下一行時，將除去游標鎖。如果在事務(wù)外打開游標，則提取下一行時，鎖就被丟棄。因此，每當用戶需要完全的悲觀并發(fā)控制時，游標都應(yīng)在事務(wù)內(nèi)打開。更新鎖將阻止任何其它任務(wù)獲取更新鎖或排它鎖，從而阻止其它任務(wù)更新該行。然而，更新鎖并不阻止共享鎖，所以它不會阻止其它任務(wù)讀取行，除非第二個任務(wù)也在要求帶更新鎖的讀取。滾動鎖根據(jù)在游標定義的 Select 語句中指定的鎖提示，這些游標并發(fā)選項可以生成滾動鎖。滾動鎖在提取時在每行上獲取，并保持到下次提取或者游標關(guān)閉，以先發(fā)生者為準。下次提取時，服務(wù)器為新提取中的行獲取滾動鎖，并釋放上次提取中行的滾動鎖。滾動鎖獨立于事務(wù)鎖，并可以保持到一個提交或回滾操作之后。如果提交時關(guān)閉游標的選項為關(guān)，則 COMMIT 語句并不關(guān)閉任何打開的游標，而且滾動鎖被保留到提交之后，以維護對所提取數(shù)據(jù)的隔離。所獲取滾動鎖的類型取決于游標并發(fā)選項和游標 Select 語句中的鎖提示。鎖提示 只讀 樂觀數(shù)值 樂觀行版本控制 鎖定無提示 未鎖定 未鎖定 未鎖定 更新 NOLOCK 未鎖定 未鎖定未鎖定 未鎖定 HOLDLOCK 共享 共享 共享 更新 UPDLOCK 錯誤 更新 更新 更新 TABLOCKX 錯誤 未鎖定 未鎖定更新其它 未鎖定 未鎖定 未鎖定 更新 *指定 NOLOCK 提示將使指定了該提示的表在游標內(nèi)是只讀的。
　　
　　16、用Profiler來跟蹤查詢，得到查詢所需的時間，找出SQL的問題所在;用索引優(yōu)化器優(yōu)化索引
　　

分享：揭秘優(yōu)化SQL Server數(shù)據(jù)庫查詢的方法
文中，abigale代表查詢字符串，ada代表數(shù)據(jù)表名，alice代表字段名。 技巧一： 問題類型：ACCESS數(shù)據(jù)庫字段中含有日文片假名或其它不明字符時查詢會提示內(nèi)存溢出。 解決方法：修改查詢語句 sql=select * from ada where alice like '%abigale%' 改為 sql=