SQL Server

一旦被駭客擷取到webshell，駭客就知道了你的sqlserver管理員密碼，如果sqlserver再沒有經過安全設定那麼駭客很容易就提權並建立系統管理員帳號，那麼駭客就可以輕鬆的控制你的電腦了。所以一定要進行安全設定，雲棲社區網站就提供了這項服務，幫使用者安全設定。下面回到正題為大家簡單的介紹下如果建立一個新帳號。進入sqlserver的企業管理器介面，建立使用者需要兩個步驟第一步：安全性 》登入 》建立登入輸入使用者名稱 zz8love 並選擇sqlserver身分識別驗證 並設定密碼

誤區10.資料庫鏡像在故障發生後，馬上就能發現 錯誤 市面上大肆宣傳資料庫鏡像技術可以在故障發生後，立即檢測到錯誤並進行容錯移轉。 但事實並不是這樣，檢測到故障發生的速度要取決於故障的類型。 檢測故障發生的最快的情況是，鏡像中的主體執行個體崩潰，從而鏡像伺服器每秒一次的PING就無法傳回值，從而知道主體伺服器上不再有這個進程偵聽相應的TCP連接埠，這種情況下，鏡像伺服器幾乎瞬間就能發現故障。

這樣還能減少CPU快取命中失效的問題(點擊這個連結來查看CPU的緩衝是如何工作的以及MESI協議)。下面讓我們來揭穿三個有關NULL位元影像的普遍誤區。 誤區 #6a:NULL位元影像並不是任何時候都會用到 正確 就算表中不存在允許NULL的列，NULL位元影像對於資料行來說會一直存在(資料行指的是堆或是叢集索引的葉子節點)。但對於索引行來說（所謂的索引行也就是叢集索引和非叢集索引的非葉子節點以及非叢集索引的葉子節點）NULL位元影像就不是一直有效了。 下面這條語句可以有效證明這一點:

1.1.1 摘要 在開發過程中，我們不時會遇到系統效能瓶頸問題，而引起這一問題原因可以很多，有可能是代碼不夠高效、有可能是硬體或網路問題，也有可能是資料庫設計的問題。本篇博文將針對一些常用的資料庫效能調休方法進行介紹，而且，為了編寫高效的SQL代碼，我們需要掌握一些基本代碼最佳化的技巧，所以，我們將從一些基本最佳化技巧進行介紹。本文目錄代碼中的問題 資料庫效能開銷使用預存程序 使用資料庫事務 使用SqlBulkCopy 使用表參數 1.1.2 本文

複製代碼 代碼如下:--PK select * from sys.key_constraints where object_id = OBJECT_ID('TB') --FK select * from sys.foreign_keys where parent_object_id =OBJECT_ID('TB') --建立連結的伺服器 exec sp_addlinkedserver 'ITSV ', ' ', 'SQLOLEDB ', '遠程伺服器名或ip地址 ' exec

第一種是最傳統的寫法，用預存程序中的變數作為分頁的乘數 複製代碼 代碼如下: [c-sharp] view plaincopyprint?create proc p_paged1 @pageSize int,@currentPage int as select top (@pageSize) * from student where id not in (select top (@pageSize*(@currentPage-1)) id from student) go exec

在工控應用上，返回的資料經常會以二進位的形成儲存，而這些位元據又是以每4個bit表示一個十六進位的資料內容。解析的時候，往往是一個位元組（Byte）佔用8個位（bit），高位4bit 表示一個十六進位資料，低位4bit 表示一個十六進位資料。 問題描述：在SQL Server 資料庫中，如何?位元據與字串資料之間的直接轉換？ 一定會有人立馬反問我：為什麼不在程式中使用 C# 或者 JAVA 或者 C++

複製代碼 代碼如下: Create trigger tri_wk_CSVHead_History on wk_CSVHead_History --聲明一個tri_wk_CSVHead_History觸發器， instead of insert ---插入操作被代替執行下面的操作 as begin declare YB cursor --聲明一個遊標 for 　select NoteNO from inserted--這裡的NoteNO要和下面的匹配 　open YB 　　declare

文法結構： 1. Cast 文法結構：CAST ( expression AS data_type [ ( length ) ] ) 2. Convert 文法結構：CONVERT ( data_type [ ( length ) ] , expression [ , style ] ) 3. Parse 文法結構：PARSE ( string_value AS data_type [ USING culture ] ) 其中，Parse 為 Sql Server 的新特性

第一列按照goodsid局部分組，然後在分組後的記錄中按照audittime升序排序得到序號，從而顯示某商品得第幾次變遷。 第二列是取該商品的最後變遷價格newPrice，然後將該值賦到這個商品的其他行中，例如對於goodsid為1的，最後一個newprice為20，那麼對於所有goodsid為1的記錄curprice都寫為20，從而達到外面控制項分布的效果。 如下，比較正常的資料記錄： 需要增加特殊的兩列效果為：

Create a SQL Server database.複製代碼 代碼如下:DB_SIZE_IN_MEGABYTES = 5 strDBServerName = "." Set objSQLServer = CreateObject("SQLDMO.SQLServer") objSQLServer.LoginSecure = True

sql語句複製代碼 代碼如下:reverse(substring(reverse(Path),1,charindex('/',reverse(Path)) - 1)) SQL如何取出一個字串中最後一個特殊字元右邊的字元，例如：10*20*300，怎樣得到300？使用reverse配合charindex來實現。 reverse是把字串倒置，然後通過charindex來擷取倒置之後第一個*的位置，然後使用substring函數進行字串截取，截取後再使用reverse倒置回來即可。 以下為例子

這個問題對於規模稍微大些的項目而言，顯得尤其重要了，資料庫中如果有幾百個預存程序， 難道還一個個找不成，即使自己很瞭解業務和系統，時間長了，也難免能記得住。 如何使用SQL語句進行查詢呢？ 下面就和大家分享下SQL查詢的方法： 複製代碼 代碼如下:select distinct name from syscomments a,sysobjects b where a.id=b.id and b.xtype='p' and text like '%pro_GetSN%'

誤區 #23: 鎖定擴大的過程是由行鎖定擴大到頁鎖，再由頁鎖定擴大到表鎖錯誤    實際不是，在SQL Server 2005和之前的版本，頁鎖會直接升級到表鎖。    在SQL Server 2005或SQL Server

作業備份，不是備份資料庫，是備份作業。 我的方法是把作業匯出成檔案備份起來，因為當你伺服器維護的多了的時候很多你的作業 就很成問題，很麻煩。 最好能夠作業實現同步，這個也是第一步，儲存成檔案，之後個人設想使用powershell 來把作業同步起來 複製代碼 代碼如下: DECLARE @jobname VARCHAR(30),@category_calss_i INT ,@category_calss VARCHAR(50),@category_name VARCHAR(50)

誤區 #20:在破壞記錄備份鏈之後，需要一個完整備份來重新開始日誌鏈 錯誤 交易記錄備份會備份自前次交易記錄備份以來所有的交易記錄(如果從來沒有過記錄備份的話，那就從上一次完整備份開始)。有好幾種類型的操作會中斷交易記錄的連續性，也就是說除非重新開始新的日誌鏈，SQL Server無法再進行記錄備份。下面這幾種操作都有可能引起日誌鏈斷裂: 由完整復原模式或大容量交易記錄復原模式轉為簡單復原模式 從資料庫鏡像進行恢複 備份日誌時指定了NO_LOG 或 WITH

誤區 #18:如下多個有關FileStream的誤區全部錯誤18 a)FileStream資料可以在遠程儲存    不能，由於FileStream資料容器(指的是存放FileStream檔案的NTFS檔案夾，杜撰出來的術語)必須像資料檔案或記錄檔那樣符合本機存放區策略-也就是說，這個資料容器必須放在對於運行SQL Server的Windows

其實我之前已經有文章詳細解釋了頁校正和：How to tell if the IO subsystem is causing corruptions? 誤區 #17:幾個有關頁校正和的誤區坊間流傳的基本是錯誤的   17 a)頁校正和（Page CheckSum）在從SQL Server 2000或7.0升級上來之後自動開啟    其實不是，從舊的執行個體升級上來的資料庫不會自動開啟頁校正和，除非你顯式使用ALTER DATABASE

誤區 #16:多個關於資料的損壞和修複誤區 坊間流傳的很多版本都不正確 我已經聽過很多關於資料修複可以做什麼、不可以做什麼、什麼會導致資料損毀以及損壞是否可以自行消失。其實我已經針對這類問題寫過多篇博文，因此本篇博文可以作為“流言終結者”來做一個總結，希望你能有收穫。  首先，對於資料修複可以做什麼，不可以做什麼，我已經寫過一篇博文Misconceptions around database repair涵蓋了13個誤區—從不用DBCC

誤區 #14.清除日誌後會將相關的LSN填零初始化錯誤    當記錄檔在手動增長，自動成長和建立時都會進行填零初始化操作。但是請不要把這個過程和定期清除日誌的過程搞混。日誌截斷僅僅意味著將一個或多個VLF標記為不活動以便被重複使用。在日誌清除的過程中，並沒有任何日誌被清除或是填0。“清除日誌”和”截斷日誌”意思是一樣的，但都屬於用詞不當，因為在這個過程中日誌的大小不會有任何改變。