共計 5544 個字符，預計需要花費 14 分鐘才能閱讀完成。
這期內容當中丸趣 TV 小編將會給大家帶來有關 SQL Server 如何實現 Standby 的日志傳送，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
SQLSERVER 下實現熱備用可用性中日志傳送以及同步復制的方式：
1. 使用企業版的“日志傳送向導”(被集成在“數據庫維護向導”之中)
2. 通過編寫腳本，并將其作為普通的 SQL Server 代理作業來進行調度而實現
3. 使用同步復制
——————————————-
集群是一種實現高可用性的有效解決方案，有時它會適得其反。而且，它還非常昂貴。因此，數據庫管理員可使用日志轉移代替集群來提供較高的可用性。
日志轉移是這樣一種處理過程，它能將某一數據庫中的事務日志文件依次轉存到備份的數據庫中，進而為這一數據庫創建一個“近乎”熱備份。SQL Server 2000 的數據庫引擎中設置了日志轉移功能，并在其中進行處理。所以它會自動完成復原到備份服務器的進程，而不需要數據庫管理員手動操作。只有你的產品服務器操作失敗，你才需手動完成到備份服務器的復原進程。(注釋：盡管 SQL Server 7.0 和 2005 中均有日志轉移功能，但本文主要針對 SQL Server 2000。)
◆為什么要使用日志轉移?
日志轉移是一種解決高可用性的措施，并且十分有效。同樣作為高可用性的措施方案，日志轉移相對集群來說，最大的好處是它要便宜許多。這是因為，使用集群功能有硬件要求，而日志轉移則不需要。
日志轉移在數據庫與數據庫而非服務器與服務器之間進行；因此才有可能將備份數據庫存儲在你已用作其他用途的服務器上。但如果轉移失敗則有可能會出現問題，這時你可換用備份數據庫，這種選擇是可用的。日志轉移相對比較容易安裝。SQL Server 提供了非常完善的向導幫助你安裝這個進程。日志轉移允許你保存分布在不同地理位置中的冗余數據，SQL Server 的集群功能則很難做到這一點。這一特點十分出眾，因為，當你的數據中心遭到災難時，你仍能在備份服務器中將其恢復過來。而在相同的數據中心，如果你使用的是集群功能，你就會陷入麻煩。
日志轉移的另一優點是你能將備份數據庫作為報告數據庫使用，這對許多公司來說是很不錯的選擇。但如果你決定了用這個備份數據庫作報告使用，就必須注意它的局限性。使用原始數據庫中的日志時，SQL Server 要求指定唯一的通道，所以，當日志文件正在被應用時，報告則不能同時進行。
◆使用日志轉移要考慮的相關因素
在將日志轉移作為高可用性的方案來使用時，我們必須考慮以下幾點因素。由于從原始數據庫到備份數據庫有一個潛伏期，對你的公司而言，它并非一定是可行的實現高可用性的一種解決方案。潛伏期由數據庫管理員設置，時間也因需要而縮短, 但永遠不能避免。
日志轉移中沒有設置恢復功能，這就意味著在將日志轉移到備份服務器上時，這些日志都暫時不可用。因此，數據庫管理員必須在將備份數據庫放到網上前完成一系列的操作，這些步驟包括: 將已存儲在備份數據服務器上原始數據庫里的備份標簽存儲起來。一旦所有的標簽被存儲后，數據庫就必須得到恢復，然后放到網上。
一旦所有的數據庫都已放在網上，所有需要訪問數據庫的應用程序就需要改變自身的鏈接。如果你不能將應用程序盡快指向剛剛恢復的數據庫，你就前功盡棄了。
一個 SQL Server 的實例能用于監控日志轉移。這個實例可以在原始數據庫、備份數據庫或單獨的數據庫中。任何一種版本的 SQL Server 都能用于 SQL Server 監控。
注釋：數據庫登錄必須在原始數據庫與備份數據庫之間同時進行
——————————————-
操作步驟：
Log Shipping Operations Guide
Version: 1.0
Create Log Shipping.. 3
Monitor.. 9
Delete Log shipping.. 10
Role Change.. 13
Create Log Shipping
1. SQL Server 節點 1 Tonym 和 Tonym02 必須位于同一域中，并且 SQL1 和 SQL2 都要使用域賬戶啟動 SQL Server 服務和 SQLServerAgent 服務。
2. 在企業管理器中刪掉 local 連接，應用 Server Name 注冊本地服務器 Tonym，輔助服務器 Tonym02
3. 在 SQL1 服務器上新建共享文件夾 NorthwindBackupShare01，賦予啟動 SQL Server 賬戶的 Full 權限。在 SQL1 服務器上新建文件夾 ReceiveSQL2Logs，用來在進行數據庫角色轉換時接收從 SQL2 上傳送過來的日志。
在 SQL2 服務器上新建共享文件夾 NorthwindBackupShare02，賦予啟動 SQL Server 賬戶的 Full 權限。在 SQL2 服務器上新建文件夾 ReceiveSQL1Logs，用來接收數據庫 SQL1 上傳送過來的日志。
4. 設置想要應用 Log Shipping 的服務器為完全恢復模式。
5. 在 Database Maintenance Plans 上右鍵 New maintenance Plan，選擇進行 LogShipping 的數據庫，每次只允許選擇一個數據庫。
6．去掉 Back up the database as part of the maintenance plan, 保證維護計劃唯一性（推薦）
7. 指定數據庫日志備份路徑。
8．指定存放日志文件的共享文件夾。
9. 添加目的數據庫。
Server Name 為目的名稱
Transaction Log Destination Directory 填寫從 SQL1 上傳送到 SQL2 上日志文件的接收路徑.
Destination Database 選擇新建數據庫（指定數據文件，日志文件存放路徑）或者應用已存在的數據庫
Database Load State
No recovery mode：使用者將無法進行資料查詢，只供備份使用.
Standby mode：設置成只讀模式，只要不是進行日志回存的時候，都可以進行查詢。
Terminate users in database(Recommended)：在回存數據庫或是交易日志文件時，回存程序將是數據庫唯一的使用者。
Allow database to assume primary role：允許主要服務器與次要服務器之間進行角色轉換。
選擇進行角色轉換后新主要服務器的共享目錄路徑。
9．Initialize the Destination Database: 挑選最近一次的資料或是建立一份新的備份資料。對大型數據庫，使用即有備份比較有效率。但是要保證從備份之后的日志都存在于主服務器上的日志共享目錄中。
10．設定主服務器上日志備份頻率。
11．設置輔助服務器復制備份日志和加載備份日志的頻率，以及日志文件在輔助服務器上的留存時間。
12．針對日志備份及日志回存工作，設定合理的延遲時間，當超過臨界時間時，日志傳送監控程序對話框會相應一個警告信息。
13．指定監控服務器，應該指定獨立于主服務器，輔助服務器的第三臺服務器作為監控服務器，或者指定輔助服務器為監控服務器。
14．點擊 Next，指定維護計劃的名稱。Finish，開始進行 Log shipping 的創建。
Log Shipping 創建好后，和 Log Shipping 相關的信息存儲在 msdb 的 7 個表中：
Log_shipping_plans
Log_shipping_plan_databases
Log_shipping_databases
Log_shipping_plan_history
Log_shipping_monitor
Log_shipping_primaries
Log_shipping_secondaries
2. 可以在監控服務器的 management 下看到 Log shipping 備份，復制，加載等動作的狀態信息。
Delete Log shipping
1. 選擇主要服務器上的 log shipping 維護計劃, 打開屬性，選擇【Log shipping】設定頁，然后點選【Remove Log Shipping】。此動作將從次要服務器上移除 SQL Server Agent 的備份與回存工作，并清除日志傳送資料表內的所有相關資料。此外，日志傳送監控程序的相關信息也會一并被清除。然而此動作將會適當地保留主要服務器上 SQL Server Agent 的交易日志備份工作。只有在刪除數據庫維護計劃時，該工作才會被移除。假如您想從監控服務器內移除掉日志傳送監控程序，請用手動方式將 log_shipping_primaries 與 log_shipping_secondarie 這兩個資料表 (位于監控服務器的 msdb 數據庫) 的資料刪除即可。
如果您在數據庫維護計劃內設定日志傳送時，就已允許目的數據庫可以做為新的日志傳送來源數據庫。當您刪除主要服務器的維護計劃時，次要服務器上仍然會保留其數據庫維護計劃，以及交易日志文件備份工作。刪除這些項目的方式是將次要服務器上與日志傳送相關的數據庫維護計劃直接刪除。
Role Alter
1. 在主服務器上創建登陸同步 DTS 包。
2. 打開企業管理器并連接到主服務器。展開企業管理器樹至“Data Transformation Services”組，選擇“Local Packages”。右擊“Local Packages”并選擇“New Package”。從“Task”菜單選擇“16 Transfer Logins Task”。在源選擇 主服務器，目的選項卡 選擇 輔助服務器。在“Logins”選項卡，選擇傳輸與特定數據庫關聯的登陸，或者傳輸該服務器的所有登陸。（對于我們的環境推薦使用傳輸該服務器的所有登陸）
3．將 DTS 包保存在主服務器。
4．指定 DTS 同步時間（至少每周一次）。
5. 同步登陸賬戶 SID
1. bcp master..syslogins out localpath\syslogins.dat /N /S current_primary_server /U sa /P sa_password.
稍后會用到導出的 syslogins 信息.
2. 降級主要服務器. 在主服務器運行以下存儲過程。
Use master
Exec msdb..sp_change_primary_role
@db_name =‘current_primary_dbname’
@backup_log = 1,
@terminate = 1,
@final_state = 3,
@access_level = 1
3. 升級輔助服務器. 在輔助服務器運行以下存儲過程。
Use master
Exec msdb..sp_change_secondary_role
@db_name =‘current_secondary_dbname’
@do_load = 1,
@force_load = 1,
@final_state = 1,
@access_level = 1,
@terminame = 1,
@keep_replication = 0,
@stopat = null
該存儲過程會將數據庫質為單用戶模式。明明沒有任何使用者正在存取數據庫，它卻告訴我數據庫目前為使用中，解決的方式為重新執行一次該存儲過程。
4. 通知監控服務器角色已變更，在監控服務器上運行以下存儲過程。
Use master
Exec msdb..sp_change_monitor_role
@primary_server =‘current_primary_server_name’,
@secondary_server =‘current_secondary_server_name’,
@database =‘current_secondary_dbname’,
@new_source =‘new_source_directory’
5. 在次要服務器上解析登入帳號
Use master
Exec sp_resolve_logins
@dest_db =‘dbname’,
@dest_path =‘destination_path’,
@filename =‘filename’(from step 1 export)
6. 連接數據庫存取與權限。將轉移后已解析的登入帳號連結至相對應的數據庫使用者及其權限. (SQL BOOK Online 缺少此步)
Use sourcename
Exec sp_change_users_login‘update_one’,‘username’,‘LoginName’
1. 在新主要服務器的數據庫維護計劃內移除日志傳送功能。
2. 在主要服務器上刪除數據庫維護計劃。
3. 在次要服務器上刪除數據庫維護計劃。
4. 維護所有交易日志。
5. 在新主要服務器上建立一個新的數據庫維護計劃，指定新次要服務器所在，目的數據庫位置，以及交易日志之適當存放位置。
6. 重新開始新主要服務器的所有活動。
在您成功設定角色互換且建置新日志傳送配對服務器后，Enterprise Manager 的日志傳送監視器可能會告訴您新次要服務器數據庫并未與新主要服務器數據庫取得同步（out of sync）。如果“最近一次加載的交易日志”與“最近一次備份的交易日志”之間的時間差超過了 out-of-sync 設定值，您就會收到此報告。你需要把新主服務器的備份日志拷貝到新次服務器的同步備份路徑下。到最近一次的備份資料被加載之后，日志傳送監視器會回到平常無錯誤狀態。
上述就是丸趣 TV 小編為大家分享的 SQL Server 如何實現 Standby 的日志傳送了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業資訊頻道。
