炎龍牙

首先強調...這不是正規的設定方式，這也是我同事測試出來可行的方法.....做個紀錄。.

主要是因為想要分擔主伺服器的資料庫查詢工作(次要資料庫可唯獨存取)。所以做了一些測試。

環境如下：

主伺服器 SQL 2008

次要伺服器 SQL 2008 R2

期初在建立Log Shipping ，順順的使用精靈，就完成了建置工作，建置方式可以參考：VITO の 學習筆記 Log Shipping，CaryHsu - 學無止盡 Log Shipping 幾位前輩的紀錄，非常詳細。

就在都設定完畢後，執行後出現了以下錯誤訊息!!!! 

無法使用WITH STANDBY來還原 因為必須將資料庫升級 。請重新發出不包含WITH STANDBY的RESTORE。

這樣就不能利用唯讀存取了@@........查找了資料，意外發現....原來的主要伺服器與次要伺服器版本不同.....

一個是SQL 2008 (10.0.5500) 一個是SQL 2008 R2( 10.50.4000) 。

原本以為已經GG了...強人我同事，突然說：【既然可以RESTORE，只是不能將DB還原成待命狀態，那我再做一備份然後再還原就好了..】

當場覺得怎麼可能，於是又去看了一些MSDN文章與前輩的說明，VITO の 學習筆記 資料庫還原 。就在這當下，強人同事說，可以正常運作了..除了ALERT是失敗的以外。

詢問了一下設定方式。(因為不是我實作的，所以沒有截圖....)

方式如下：

1.使用精靈建立Log Shipping ，使用第三種建置模式(次要資料庫已經初始化)，

2.停用精靈建立的作業排程( 主伺服器的BACKUP、次要伺服器的COPY、RESTORE 作業，還有ALERT)

3.將主要伺服器DB做一次完整備份，還原到次要伺服器。

4.將次要伺服器DB在做一次備份。

5.改用語法進行還原(使用次要伺服器的備份檔案)，在還原時加上 STANDBY

RESTORE DATABASE [DB] FROM  DISK = N'D:\db.bak' WITH  FILE = 1,  
MOVE N'db' TO N'd:\sqldata\db.mdf',  
MOVE N'db_log' TO N'd:\sqldata\db_1.ldf',  
STANDBY = N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\ROLLBACK_UNDO_db.BAK',  
NOUNLOAD,  STATS = 10

這時，待命還原資料庫就建置完成。

6.啟用精靈建立的作業排程( 主伺服器的BACKUP、次要伺服器的COPY、RESTORE 作業)，

7.檢查紀錄，完成。

 

提醒：這不是正規的方式，如果原來的主伺服器另外還有安排備份的動作，在做完這個備份動作後，原先的Log Shipping就會因為LSN 的變動導致Log的還原失敗。

TechNet 跟MSDN真是我們的好朋友...紀錄序號簡介，記錄序號和還原計畫，若要實際了解一下序號的排列與對應關係，可以利用以下語法取檢查資料備份時LSN的資料

SELECT [backup_set_id],[backup_set_uuid],[media_set_id],[software_vendor_id]
      ,[name],[description],[user_name],[software_major_version]
	  ,[software_minor_version],[software_build_version],[time_zone]
	  ,[first_lsn],[last_lsn],[checkpoint_lsn],[database_backup_lsn]
	  ,[database_creation_date],[backup_start_date],[backup_finish_date]
	  ,[type],[backup_size],[database_name],[server_name]
	  ,[machine_name],[unicode_locale],[unicode_compare_style]
	  ,[collation_name],[first_recovery_fork_guid],[last_recovery_fork_guid]
	  ,[fork_point_lsn],[database_guid],[family_guid],[differential_base_lsn]
	  ,[differential_base_guid],[compressed_backup_size]
  FROM [msdb].[dbo].[backupset]

詳細的欄位資料說明，請參閱TechNet backupset (Transact-SQL)

2016/07/12 事件補充

這樣的方式在經過實測幾天之後，出現了很特殊的問題，就是會有部分檔案再還原時，再次出現【無法使用WITH STANDBY來還原 】的錯誤訊息。導致還原失敗

根據Log Shipping 上的LSN的連續性，在還原時不能跳過其中任何一個Log檔案，要逐一還原，可是當我們將該檔案移除，直接用下一個Log檔案做還原，Log Shipping又再次恢復正常。

這表示(我們的環境已經錯亂??)還是資料在備份時出現了錯誤?還是網路傳輸時導致檔案的毀損無法讀取??....................原因待查!!!

2016/07/15 事件補充

經過幾天的測試，最後發現，Log Shipping 還原的過程中雖然都沒有報錯，但是實際上這樣的操作，資料是一點都沒有寫到待命的資料庫裏面。

也就是說，系統在執行還原時，並沒有檢查出問題，實際上Agent Job 在執行時是使用 Power Shell 去執行，能通過執行，就算是執行完成了(這是一種頭過身就過的概念嗎??)

等到實際上使用SSMS進行資料還原工作，卻又因為LSN的錯誤導致資料還原失敗。

結論：此方法不可行...........................(希望耐心看完文章的人..不要打我!!!!)

 

最後提醒自己，在看紀錄檔時，不要看前面的燈號!!!! 例如下圖，他是顯示綠燈!!但是實際上記錄錯誤的訊息內容，是存在在這一筆資料裡面。

如果直接去看X ...怎樣都不知道錯誤與失敗的原因。

 

曾經在看別人的文章覺得為什麼寫篇文章需要貼一堆連結，在閱讀上是很不方便的!!實際上在自己後來寫文章時發現，如果別人已經寫得又正確又好，就應該要讓這樣的文章分享給大家去閱讀(不是整份轉貼唷，那是人家的心血。)每份文章裏面都有包含作者心思，仔細閱讀可能可以發現一些基礎細節的魔鬼就在裡面。所以後來我盡量不節錄別人的文章，改用一些連結來處理(簡單的說..就是懶)，提供給自己，讓自己在某些環節不通的時候，還能去看看別人實際上的操作與細節的說明，說不能夠再次貫通觀念，也免去搜尋的時間。

水滴可成涓流，涓流可成湖泊大海。
汲取累積知識，將知識堆積成常識；將常識探究成學識；將學識簡化為知識；授人自省。