SQL Server

通過介面設計上是能手工操作的，無法達到我批量修改幾千台伺服器。 因為此了一個指令碼來批量執行。 環境：redgate + mssql 2008 r2 以下代碼根據自己的業務稍做修改即使用。 複製代碼 代碼如下: --允許對系統資料表進行更新 exec sp_configure 'allow updates',1 reconfigure with override GO --取消識別欄位標記 update syscolumns set colstat = 0 where id =

第一種方法： 複製代碼 代碼如下: /* 建立連結的伺服器 */ exec sp_addlinkedserver 'srv_lnk','','sqloledb','條碼資料庫IP地址' exec sp_addlinkedsrvlogin 'srv_lnk','false',null,'使用者名稱','密碼' go /* 查詢樣本 */ SELECT A.ListCode FROM srv_lnk.條碼資料庫名.dbo.ME_ListCode A, IM_BarLend B WHERE

本文給出一條 SQL 陳述式用於展示在同一名伺服器上，不同的資料庫間查詢，注意當前串連使用者要對兩個庫都有許可權SQL Server 中 SQL 陳述式中對象的完整運算式是： [DatabaseServer].[DatabaseName].[DatabaseSchema].[DatabaseObject] 本文給出一條 SQL 陳述式用於展示在同一名伺服器上，不同的資料庫間查詢，注意當前串連使用者要對兩個庫都有許可權。 複製代碼 代碼如下: select * from CfteaDb1.dbo.

一、什麼是索引 減少磁碟I/O和邏輯讀次數的最佳方法之一就是使用【索引】 索引允許SQL Server在表中尋找資料而不需要掃描整個表。 1.1、索引的好處： 當表沒有叢集索引時，成為【堆或堆表】 【堆】是一堆未加工的資料，以行標識符作為指向儲存位置的指標。表資料沒有順序，也不能搜尋，除非逐行遍曆。這個過程稱為【掃描】。當存在叢集索引時，非叢集索引的指標由叢集索引所定義的值組成，所以叢集索引變得非常重要。

誤區 #7:一個資料庫可以存在多個鏡像 錯誤 這個誤區就有點老生常談了。每一個主體伺服器只允許一個鏡像伺服器。如果你希望存在多個主體伺服器的副本，那麼請使用交易記錄傳送，交易記錄傳送允許針對每一個主體存在多個輔助執行個體。 使用交易記錄傳送的一個優點是允許其中一個或多個次要伺服器存在延遲還原備份。這也是就是說對主體伺服器進行記錄備份(無論你喜歡與否，這幾種高可用性技術各自有各自的術語): 資料庫鏡像:主體伺服器-鏡像伺服器 交易記錄傳送:主要伺服器-次要伺服器 複製:發行伺服器-訂閱伺服器

    理解SQL Server對於記憶體的管理是對於SQL Server問題處理和效能調優的基本，本篇文章講述SQL Server對於記憶體管理的記憶體原理。二級儲存(secondary storage)    

通過《SQL Server Database Backup和還原認識和總結（一）》，相信您對資料備份和還原有了一個更深入的認識，在上文中我沒有對交易記錄做剖析，在此推薦宋沄劍的文章，對交易記錄做了比較詳細的講解：http://www.jb51.net/article/31038.htm。本文將針對上文繼續進行資料備份和還原講解，主要講解備份與還原的一些關鍵選項。 Database Backup選項

可能許多同學對SQL Server的備份與還原有一些瞭解，也可能經常使用備份與還原功能，我相信除DBA之外我們大部分開發員隊伍對備份與還原只使用最基礎的功能，對它也只有一個大概的認識，如果對它有更深入的認識，瞭解它更全面的功能豈不是更好，到用時會得心應手。因為經常有中小型客戶公司管理員對資料庫不瞭解或掌握不牢，會請我們技術人員出馬找回丟失的資料或硬體損壞移動資料的現象，或其它情況的發生。 首先從資料庫【復原模式】說起，因為資料庫如果復原模式設定不正確，會導致資料無法還原。 SQL Server

1. 次序函數與PARTITION BY 複製代碼 代碼如下: --所有資料 SELECT * FROM dbo.student AS a INNER JOIN dbo.ScoreTB AS b ON a.Id = b.stuid WHERE scorename = '語文' ------------------------------------------- --ROW_NUMBER() 的使用 產生列從1開始依次增加 ------------------------------------

一. 建庫,建表,加約束. 1.1建庫 複製代碼 代碼如下: use master go if exists (select * from sysdatabases where name='MyDatabase')—判斷master資料庫sysdatagbases表中是否存在將要建立的資料庫名 drop database MyDatabase—如果sysdatabases表中存在該資料庫名,則將它刪除 go exec xp_cmdshell ‘md

在本文中，我將說明如何用SQL Server的工具來最佳化資料庫索引的使用，本文還涉及到有關索引的一般性知識。 　　 　　關於索引的常識 　　 　　影響到資料庫效能的最大因素就是索引。由於該問題的複雜性，我只可能簡單的談談這個問題，不過關於這方面的問題，目前有好幾本不錯的書籍可供你參閱。我在這裡只討論兩種SQL

每次談到SQL Server的高可用，很多的DBA，特別是SQL Server DBA心裡一痛：因為大家都認為SQL Server無法或者很難實現SQL Server。也有很多的DBA朋友腦袋一拍，給出答案“高可用不就是微軟的那幾個技術嗎，如Replication, Failover Clustering”… 1.難道SQL Server在高可用上面就顯得這麼的無力嗎？ 回答：不是的，其實SQL Server很給力。 2.為什麼很多人總是抱怨SQL Server中高可用很難實現呢？

在查詢語句中使用 NOLOCK 和 READPAST 處理一個資料庫死結的異常時候，其中一個建議就是使用 NOLOCK 或者 READPAST 。有關 NOLOCK 和 READPAST的一些技術知識點： 對於非銀行等嚴格要求事務的行業，搜尋記錄中出現或者不出現某條記錄，都是在可容忍範圍內，所以碰到死結，應該首先考慮，我們商務邏輯是否能容忍出現或者不出現某些記錄，而不是尋求對雙方都加鎖條件下如何解鎖的問題。 NOLOCK 和 READPAST

[sql] -- ===================【建立預存程序】===================== USE [Message] GO /****** Object: StoredProcedure [dbo].[讀取外部資料庫查詢] Script Date: 10/24/2012 05:39:16 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO -- ================================

在設計主鍵的時候往往需要考慮以下幾點： 1.無意義性：此處無意義是從使用者的角度來定義的。這種無意義在一定程度上也會減少資料庫的資訊冗餘。常常有人稱呼主鍵為內部標識，為什麼會這樣稱呼，原因之一在於“內部”，所謂內部從某種程度上來說就是指表記錄，從大的範圍來說就是資料庫，如果你在設計的時候選擇了對使用者來說有意義的資訊來作為主鍵，那麼遲早會面對使用者提出對這塊資訊進行更新的需求，那麼你就違背了它應有的靜態。

Display SQL Server Version Information Description Display SQL Server Version Information. Supported Platforms SQL Server 2000  Yes Script Code strDBServerName = "." Set 

簡介資料庫快照集      資料庫快照集，正如其名稱所示那樣，是資料庫在某一時間點的視圖。是SQL Server在2005之後的版本引入的特性。快照的應用情境比較多，但快照設計最開始的目的是為了報表格服務。比如我需要出2011的資產負債表，這需要資料保持在2011年12月31日零點時的狀態，則利用快照可以實現這一點。快照還可以和鏡像結合來達到讀寫分離的目的。下面我們來看什麼是快照。什麼是快照    資料庫快照集是

誤區 #19:Truncate表的操作不會被記錄到日誌 錯誤 在使用者表中的操作都會被記錄到日誌。在SQL Server中唯一不會被記錄到日誌的操作是TempDB中的資料列版本設定。 Truncate

資料庫複寫： 簡單來說，資料庫複寫就是由兩台伺服器，主伺服器和備份伺服器，主伺服器修改後，備份伺服器自動修改。 複製的模式有兩種：推送模式和請求模式，推送模式是主伺服器修改後，自動發給備份伺服器，請求模式是，備份伺服器自動去請求，個人開始也比較重視去測試兩個模式的差別，但是測試發現，其實兩個模式差別不是很大，在當今的伺服器配置中，沒必要考慮這麼多，雖然會有一些差別，但是可在可以忽略的範圍之內，建議直接選擇推送模式，因為配置起來相對簡單

誤區 #12:TempDB的檔案數和需要和CPU數目保持一致錯誤    哎，由於上述誤區是微軟“官方”的建議，並且還有大量博文堅持這個觀點，這個誤區已經是老生常談。    但讓人困惑的是SQL CAT團隊給出的建議就是1：1，但這個建議是源自擴充方面的原理來說,而不是一個通用法則。因為他們所面對的大型客戶資料量伺服器和IO子系統都是大部分人沒有機會遇到的。