SQL 2008 & SQL 2008 R2 Log Shipping
無法使用WITH STANDBY來還原，因為必須將資料庫升級 。
首先強調...這不是正規的設定方式，這也是我同事測試出來可行的方法.....做個紀錄。.
主要是因為想要分擔主伺服器的資料庫查詢工作(次要資料庫可唯獨存取)。所以做了一些測試。
環境如下：
主伺服器 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 ...怎樣都不知道錯誤與失敗的原因。
曾經在看別人的文章覺得為什麼寫篇文章需要貼一堆連結，在閱讀上是很不方便的!!實際上在自己後來寫文章時發現，如果別人已經寫得又正確又好，就應該要讓這樣的文章分享給大家去閱讀(不是整份轉貼唷，那是人家的心血。)每份文章裏面都有包含作者心思，仔細閱讀可能可以發現一些基礎細節的魔鬼就在裡面。所以後來我盡量不節錄別人的文章，改用一些連結來處理(簡單的說..就是懶)，提供給自己，讓自己在某些環節不通的時候，還能去看看別人實際上的操作與細節的說明，說不能夠再次貫通觀念，也免去搜尋的時間。
水滴可成涓流，涓流可成湖泊大海。
汲取累積知識，將知識堆積成常識；將常識探究成學識；將學識簡化為知識；授人自省。