sqlserver資料庫快照
資料庫快照是MSSQL2005的新功能，僅在 Microsoft SQL Server 2005 Enterprise Edition 中可用。而且SQL Server Management Studio 不支持創建資料庫快照，創建快照的唯一方式是使用 Transact-SQL。
資料庫快照是資料庫（稱為「源資料庫」）的只讀靜態視圖。在創建時，每個資料庫快照在事務上都與源資料庫一致。在創建資料庫快照時，源資料庫通常會有打開的事務。在快照可以使用之前，打開的事務會回滾以使資料庫快照在事務上取得一致。
客戶端可以查詢資料庫快照，這對於基於創建快照時的數據編寫報表是很有用的。而且，如果以後源資料庫損壞了，便可以將源資料庫恢復到它在創建快照時的狀態。
創建資料庫快照可以：
·<!--[if !supportLists]--><!--[endif]-->維護歷史數據以生成報表。可以通過快照訪問特定時間點的數據。例如，您可以在給定時間段（例如，財務季度）要結束的時候創建資料庫快照以便日後製作報表。然後便可以在快照上運行期間要結束時創建的報表。
·<!--[if !supportLists]-->將查詢實施在資料庫的快照上，可以釋放主體資料庫上的資源。
·<!--[if !supportLists]-->加快恢復操作效率，使用快照將資料庫恢復到生成快照時的狀態比從備份還原快得多；但是，此後您無法對數據進行前滾操作。根據磁碟資源，可以每 24 小時創建 6 到 12 個滾動快照。每創建一個新的快照，就刪除最早的快照。如果要恢復，可以將資料庫恢復到在錯誤發生的前一時刻的快照。或者，也可以利用快照中的信息，手動重新創建刪除的表或其他丟失的數據。例如，可以將快照中的數據大容量復制到資料庫中，然後手動將數據合並回資料庫中。
但是只要存在資料庫快照，快照的源資料庫就存在以下限制：
·<!--[if !supportLists]-->必須在與源資料庫相同的伺服器實例上創建資料庫快照。
·<!--[if !supportLists]--> <!--[endif]-->資料庫快照捕獲開始創建快照的時間點，去掉所有未提交的事務。未提交的事務將在創建資料庫快照期間回滾，因為資料庫引擎 將對快照執行恢復操作（資料庫中的事務不受影響）。
·<!--[if !supportLists]-->當將源資料庫中更新的頁強制壓入快照時，如果快照用盡磁碟空間或者遇到某些錯誤，則該快照將成為可疑快照並且必須將其刪除。有關詳細信息，請參閱刪除資料庫快照。
·<!--[if !supportLists]-->快照為只讀。
·<!--[if !supportLists]--> <!--[endif]-->禁止對 model 資料庫、master 資料庫和 tempdb 資料庫創建快照。
·<!--[if !supportLists]--> <!--[endif]-->不能更改資料庫快照文件的任何規范。
·<!--[if !supportLists]--><!--[endif]-->不能從快照中刪除文件。
·<!--[if !supportLists]-->不能備份或還原快照。
·<!--[if !supportLists]-->不能附加或分離快照。
·<!--[if !supportLists]-->不能在 FAT32 文件系統或 RAW 分區中創建快照。
·<!--[if !supportLists]--> <!--[endif]-->資料庫快照不支持全文索引，不能從源資料庫傳播全文目錄。
·<!--[if !supportLists]-->資料庫快照將繼承快照創建時其源資料庫的安全約束。由於快照是只讀的，因此無法更改繼承的許可權，對源資料庫的更改許可權將不反映在現有快照中。
·<!--[if !supportLists]-->快照始終反映創建該快照時的文件組狀態：在線文件組將保持在線狀態，離線文件組將保持離線狀態。有關詳細信息，請參閱本主題後面的「含有離線文件組的資料庫快照」。
·<!--[if !supportLists]-->如果源資料庫的狀態為 RECOVERY_PENDING，可能無法訪問其資料庫快照。但是，當解決了源資料庫的問題之後，快照將再次變成可用快照。
·<!--[if !supportLists]-->只讀文件組和壓縮文件組不支持恢復。嘗試恢復到這兩類文件組將失敗。有關恢復的詳細信息，請參閱恢復到資料庫快照。
㈡ sqlserver資料庫實時同步是選快照發布還是事務發布
1. SQLSERVER伺服器上面安裝oracle客戶端，配置服務命名(假設為 test)
2. 在SQLSERVER伺服器上面建立鏈接伺服器，腳本如下
SQL code?
SQL code-- Adding linked server:
exec sp_addlinkedserver @server = 'test' ,
@srvproct = 'ORACLE',
@provider = 'MSDAORA',
@datasrc = 'test'
-- Adding linked server login:
exec sp_addlinkedsrvlogin @useself='false ', @rmtsrvname = 'test',
@rmtuser = 'user', --資料庫用戶
@rmtpassword = 'password' --密碼
3. 建立一個作業，通過作業調度存儲過程，存儲過程使用類似的語句將oracle的數據插入到sqlserver表中
SQL code?
insert into sqlserver表 select * from test..oracle表名
4. 如果要球ORACLE數據是實時增加的，並且ORACLE記錄上有遞增的欄位，可以在SQLSERVER上面建立一個表記錄上次插入的id，然後下次可以從上次的ID+1開始繼續插入
SQL code?
insert into sqlserver表 select * from test..oracle表名 where id>@id
5. 防止sqlserver同步的時候oracle仍在不斷的插入，每次要取一個結束ID
SQL code?
select @endid=max(id) from test..oracle表名.
㈢ SQLServer資料庫中如何保持數據一致性
根據實現策略的不同，主要有快照復制、事務復制、合並復制等三種類型。這三種復制類型，各有各的特點，分別適用於不同的場合。一般來說，在考慮採用哪種復制類型比較合適的時候，主要考慮的是性能與數據同步的時間間復制是SQLServer資料庫中保持數據一致性的一種手段。根據實現策略的不同，主要有快照復制、事務復制、合並復制等三種類型。這三種復制類型，各有各的特點，分別適用於不同的場合。一般來說，在考慮採用哪種復制類型比較合適的時候，主要考慮的是性能與數據同步的時間間隔。那麼在什麼情形下比較適用快照復制呢?筆者就跟大家來討論一下這個話題。 為了在恰當的時候採用快照復制，資料庫管理員首先需要知道快照復制的特點。快照復制是指將數據以特定時刻的瞬時狀態轉發，而不堅實對數據的更新。在發生同步時，將生成完整的快照並將其發送到訂閱伺服器。簡單的說，快照復制就是每隔一段時間發生數據同步操作。而不是發布伺服器的數據一有更新就出發這個快照復制。顯然這種快照復制的數據同步性稍微差一點。在訂閱伺服器與發布伺服器之間有一段時間會存在數據不一致的情況。但是這可以在很大程度上提高訂閱伺服器與發布伺服器的性能。這就好像汽車運輸。採用快照復制的話可以將一個集裝箱裝滿後在送貨，而不是有多少送多少。掌握這個資料庫復快照復制的具體特點之後，資料庫管理員就可以來考慮在什麼情況下，採用快照復制更加的合理。 一、數據更改比較少的系統中。 快照復制與其他復制相比最主要的缺陷就是資料庫中的數據無法及時同發布伺服器一致。為此如果發布伺服器中的內容很少更改的話，顯然此時採用快照復制是比較合理的。此時採用快照復制的話，不僅數據一致性延遲的負面效應會越來越不明顯，同時可以提高發布伺服器與訂閱伺服器的性能。如在實際工作中，經常會遇到這樣的客戶。如一家企業在各地都有辦事處或者銷售機構，就像肯德基一樣，各地的產品價格基本上都是相同的，不怎麼會更改。即使更改的話，各地也是統一調整。由於此時產品價格表更改的比較少，那麼在企業總部的資料庫服務與各地的訂閱伺服器之間，採用快照復制的形式就會比較合適。其實類似的情況有很多。如不少的服裝企業，像李寧、耐克等等，他們不僅自己生產，而且在各地又有自己的銷售辦事處。在價格方面也是統一的。在這種情況下，採用快照復制往往能夠提高資料庫復制的性能，同時又不影響其使用。 二、在某個時段內會出現數據大量的更改。 需要補充說明的一點是，上面說到的數據不怎麼發生更改，指的是數據的延續性更改。如在一年中，每天或者每個小時更改的數據都比較平均。此時採用快照復制不怎麼合適。但是如果數據的更改集中在一個時段內。而其他時間中資料庫的內容不會有多大的更改。此時採用快照復制是可行的。如一些決策性系統，往往在起初導入數據的時候，需要進行大量的更改。而等到數據導入完畢，在大家對數據進行分析時，則資料庫中的內容基本上保持不變。在這種情況下，筆者認為只要數據的更新集中在一個固定的時段，此時採用快照復制仍然是可行的。 再如上面這個KFC或者服裝企業的案例中，如果市場部門維護一個產品的價格，而且這些價格往往在一個固定的時間進行幾次更新。如在換季的時候會進行一些促銷。此時資料庫管理員可以在數據更新完畢後立即執行復制完成的數據快照。所以，以數據更新來判斷是否適合採用快照復制，標准並不是數據的更新量。像上面提到的分析決策系統，其起初的數據更新量可能比有些資料庫系統幾年的數據更新量都要大。筆者認為，主要是根據數據更新的頻率來進行判斷。如果數據更新的比較頻繁，那麼即使數據更新的數據不多，像那種細水長流似的更新，則不適合採用快照復制。而那些井噴似的數據更新，所有的更新都集中在一個固定的時刻，那麼此時採用快照復制是比較合理的。 三、在一段時間內是否允許具有相對發布伺服器已過時的數據副本? 現在不少超市也已經連鎖了，如世紀聯華等等。為了提高利潤，增加市場的份額，這些超市紛紛推出了沖值卡，即消費者先將一定金額的人民幣打入到沖值卡中。然後每次消費完成後從卡中扣費。但前些天經常有新聞報道，說一個客戶的消費卡在一家聯華超市掛失了。但是撿到這張卡的人仍然可以在其他的聯華超市中消費。為此消費者就想不明白了，為什麼掛失了的消費卡仍然可以在其他超市中消費?掛失後的損失該由誰來承擔呢?其實這就使超市在不適當的時候採用了快照復制所造成的。由於採用快照復制，在各個聯華超市的資料庫之間數據無法在短時間內取得一致。如有些商戶說掛失當日之內的損失他們不承擔，這就說明他們可能是每天下班後進行一次快照復制。一般情況下這不會有問題。但是像遇到消費卡被偷了等情況，就會遇到類似的問題了。 所以，在考慮是否適合採用快照復制的時候，還需要考慮在一段時間內是否允許具有相對發布伺服器來說已過時的數據副本。如果不允許的話，那麼就不允許採用這個快照復制。如果允許的話，那麼資料庫管理員就需要評估這段時間最長是多少。如果是24個小時，那麼就需要每隔24小時進行一次快照復制。但是需要注意的是，如果時間的間隔比較短，如才允許十分鍾的數據延遲，那麼採用快照復制就沒有必要了。此時採用事務復制或則和合並復制可能更加的合適。 四、復制少量的數據。 快照復制跟其他復制類型相比，還有一個比較顯著的特點，即當發生數據同步時，將生成完整的快照並將其從發布伺服器傳送到訂閱伺服器。這是一個什麼概念呢?如訂閱伺服器中有10G的數據，而在一個快照復制的周期內，只有1M的數據發生了更改。此時發生快照復制的話，資料庫系統會將10G的數據都傳送到訂閱伺服器上。此時更改的數據只有1M，卻需要在網路上傳送10G的數據流量，顯然會對企業的網路產生比較大的壓力。由於在發布伺服器上快照復制的連續開銷低於事務復制的開銷，一次資料庫系統不會啟用跟蹤增量更改。但是像這種情況，如果要復制的數據量非常的大，而平時的更新又不多。此時資料庫系統要生成和應用快照，就將耗用大量的資源，包括網路資源和伺服器資源。所以說，當發布伺服器中的數據比較多時，採用快照復制不怎麼合適。因為此時網路傳輸反而會成為其最重大的瓶頸資源。相反若能夠採取細水長流的事務復制策略，那麼對於企業網路性能的影響就會小的多，甚至可以忽略不計。 所以在採用快照復制的時候，資料庫管理員一定要明白，快照復制會傳送整個資料庫對象。從而在快照復制傳輸過程中會侵蝕大量的網路帶寬，從而明顯的降低企業網路的性能，甚至導致網路擁塞。有時候為了保障快照能夠准確、迅速的傳遞到其他的訂閱伺服器，還不得不採用VPN等技術來保障傳輸的准確性。為此，筆者認為只有發布伺服器的資料庫並不是很大的情況下，才適合採用快照復制。否則的話，採用快照復制是得不償失。 從以上的分析中，可以得到一個結論。在考慮採用快照復制是否合適時，往往不能夠採用一個指標來判斷。而需要考慮多個因素，如資料庫的大小、數據更新的頻率、允許數據延遲的時間等等因素來進行判斷。最後在數據的一致性與資料庫的性能之間取得一個均衡。說實話，對於大部分資料庫管理員來說，要做出一個抉擇，確實有困難。因為這沒有固定的指標可以拿來參考。如資料庫容量小於多少時該採用快照復制。任何一個資料庫管理專家都不能夠下這個結論。所以在掌握影響其選擇的相關因素外，就要依靠資料庫管理員的經驗了。在遇到類似的選擇題時，往往經驗可以幫助管理員迅速解決問題。最後需要提醒的是，無論最終採取了什麼方案，最好能夠持續跟蹤一段時間，看看自己的選擇是否合理。
㈣ SQLServerManagementStudio裡面的資料庫快照的定義是什麼
簡單地說
㈤ SQLSERVER 2008 在資料庫復制時無法啟動快照代理，是什麼問題
試試用管理員許可權打開sqlserver
㈥ sqlserver with snapshot 有什麼作用
資料庫快照為你現有的資料庫創建了一個資料庫的殼，然後無論何時當數據頁被修改的時候，改變也同時被寫入稀疏文件(sparse file)當中。當人們獲取數據的時候，數據中沒有變化的部分是從原始資料庫中得到的，而改變的部分則是從稀疏文件中獲得。
稀疏文件和資料庫快照
當資料庫快照被創建的時候，第一次的創建是十分迅速的。因為實際上只是創建了一個用來記錄被修改文件的殼。隨著時間的推移，文件不斷的被修改，這些修改頁都將被寫進稀疏文件。你的主資料庫中修改的文件越多，就有越多的文件被寫入稀疏文件。因此，有越來越多的磁碟空間被用來保存你的主資料庫和快照的資料庫，也增加了你伺服器的磁碟輸入輸出的次數。
稀疏文件被寫入大小為64KB的分組塊當中。每一個分組塊增量能包含8個大小為8KB的數據頁。所以，每次在你的主資料庫中有任何的數據改變，都會先把數據頁拷貝到稀疏文件當中，然後再將主資料庫中文件的變化寫入稀疏文件。一旦數據頁被寫入稀疏文件，他們就不再需要被寫出來。因為頁面的全部內容被保護起來，讓其處於當快照建立時的狀態。
為了實現優化磁碟並消除磁碟沖突，在主資料庫以外的獨立的驅動器和陣列中創建稀疏文件是一個明知之舉。原因有二：
其一，當快照被建立的時候，沒有數據被寫入稀疏文件。從快照進行的所有的數據訪問實際上都是在主資料庫文件當中的。隨著時間的推移，你會通過在不同的陣列和磁碟上從主文件資料庫讀取未被修改過的文件和從稀疏文件讀取修改過的數據的方法來減少輸入輸出的負擔。
其二，根據你資料庫數據的易變動性和數據變化的數量，你可以通過將在主資料庫的讀取工作和稀疏文件的寫入工作分離來減少輸入輸出的瓶頸大小。
使用資料庫快照
在這里你一定要記住的事情就是，你的查詢請求訪問的依然是你的主資料庫。當初始的快照被建立的時候，其實僅建立了一個空的殼子。所有的數據請求都是在主資料庫文件中被完成的。隨著時間的流逝和文件不斷地被修改，就有一些數據請求從初始的資料庫文件中分離出來指向了稀疏文件。所以，盡管看上去它是一個獨立的資料庫，那些根本的數據仍然是源於主資料庫。
鑒於此，你需要確定不要試圖去進行你日常活動范圍以外的查詢。這樣說吧，你創建了一個快照，接著你進行了讀寫的操作，並對每個人做了記錄。當那些記錄被執行查詢操作時，他們仍然繼續影響著主資料庫。所以你要保證任何新的活動都不會影響主數據的活動。
另外，你需要記住到底有哪些數據是被寫入稀疏文件里的，而不是認為所有可能的數據都被寫進了稀疏文件。基本上，當快照被創立時，主資料庫的大小就是快照稀疏文件的潛在大小。如果稀疏文件中的數據量已經達到甚至超過資料庫的一半時，也許再創造一個資料庫的完整拷貝來取代現有的快照是一個更好的主意。
綜上所述，我認為，資料庫快照是一個非常新的功能。我也希望在SQL Server2005的所有版本，而不僅僅在企業版和開發版中可以應用這個功能。有一個沒有討論的地方就是我們沒有討論有關對資料庫鏡像使用快照。其實，無論是鏡像還是原資料庫，快照都給了你最好的方法。因為鏡像是離線的，你並不能訪問那些數據，所以說無論是鏡像還是原資料庫，它都給了你最好的方法。花一些時間去理解快照是如何應用於你的環境中的，並且確認你監視著維護快照的影響以及通過快照進行的數據存儲。
㈦ 如何創建資料庫快照
任何能創建資料庫的用戶都可以創建資料庫快照。創建快照的唯一方式是使用 Transact-SQL。 注意：有關命名資料庫快照、設置創建資料庫快照的時間和限制資料庫快照成員的注意事項，請參閱創建資料庫快照。 創建資料庫快照 根據源資料庫的當前大小，確保有足夠的磁碟空間存放資料庫快照。資料庫快照的最大大小為創建快照時源資料庫的大小。 使用 AS SNAPSHOT OF 子句對文件執行 CREATE DATABASE 語句。創建快照需要指定源資料庫的每個資料庫文件的邏輯名稱。有關創建資料庫快照的語法的正式說明，請參閱 CREATE DATABASE (Transact-SQL)。 注意：創建資料庫快照時，CREATE DATABASE 語句中不允許有日誌文件、離線文件、還原文件和不起作用的文件。 示例本節包含創建資料庫快照的示例。 A. 對 AdventureWorks 資料庫創建快照此示例對AdventureWorks 資料庫創建資料庫快照。快照名稱 AdventureWorks_dbss_1800 及其稀疏文件的名稱 AdventureWorks_data_1800.ss 指明了創建時間 6 P.M.（1800 小時）。 復制代碼CREATE DATABASE AdventureWorks_dbss1800 ON( NAME = AdventureWorks_Data, FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Data\AdventureWorks_data_1800.ss' )AS SNAPSHOT OF AdventureWorks;GO注意：示例中隨意使用了擴展名 .ss。 B. 對 Sales 資料庫創建快照此示例對Sales資料庫創建資料庫快照 sales_snapshot1200 。
㈧ 如何利用SQL Server資料庫快照形成報表
在SQL Server 2005中，它的另外一個強大的新特點是資料庫快照。資料庫快照是一個資料庫的只讀副本，它是資料庫所有數據的映射，由快照被執行的時間點來決定它的內容。
這些資料庫快照在報表方面是非常有價值，因為在快照資料庫中或者在原資料庫中，對於任何查詢而言沒有鎖就將被執行。快照也可以使用在災難恢復中，因為你可以將現有的數據恢復到現有的快照中，或者還可以在有害數據操作聲明的事件中存儲個別必要的表和數據。
資料庫快照是如何工作的?
可以使用典型的資料庫命令CREATE DATABASE語句來生成一個資料庫快照，在聲明中有一個源資料庫快照的附加說明。當快照被建立時，同時生成一個稀疏文件。這個文件（只能使用在NTFS卷中）在初始化的時候並沒有磁碟空間分配給它——盡管你可能在WINDOWS資源管理器中看到了文件的大小，它會看上去與原始的源資料庫文件的大小相同。對磁碟來說其實這個文件的大小接近於零。
資料庫快照在初始化時讀的數據文件是來自於源資料庫的。當源資料庫的數據發生變化時，數據引擎就會將原始數據從源資料庫拷貝到快照資料庫中。這個技術確保快照資料庫只反映快照被執行時數據的狀態。當SELECT命令被用來發布反對資料庫快照時，不管數據頁的讀取是否被定位在源資料庫數據文件中還是在快照資料庫數據文件中都是沒有鎖被發布的。因為在只讀資料庫快照中是沒有鎖被發布，資料庫快照對於報表解決方案是一個重要的解決方案。
一個快照的實例
現在，讓我們來看看資料庫快照在SQL Server 2005中是如何工作的。為此，首先我需要一個源資料庫作為快照的來源。下面的腳本將創建一個源資料庫：
以下為引用的內容：
USE master
GO
IF EXISTS(SELECT name from sysdatabases where [name] = 'SourceDatabase')
DROP DATABASE SourceDatabase
GO
CREATE DATABASE SourceDatabaseON PRIMARY
(
NAME = SourceDatabase_Data,
FILENAME = 'C:SQLServerSourceDatabase_Data.mdf'
) LOG ON
(
NAME = SourceDatabase_Log,
FILENAME = 'C:SQLServerSourceDatabase_Log.ldf'
)
GO
注意這里產品區域的大小。我定義它的大小為CHAR（150）來強調數據文件的增長級數，這樣在我接下來的實例中將更容易解釋清楚快照是如何工作的。
現在既然我已經有了一個源資料庫，現在我裝載一些數據來擴展數據文件的大小位。如此，使用列表1中的腳本來創建銷售歷史表。
以下為引用的內容：
USE SourceDatabase
GO
IF OBJECT_ID('SalesHistory')>0 DROP TABLE SalesHistory
GO
CREATE TABLE SalesHistory
( SaleID INT IDENTITY(1,1),
Proct CHAR(150), SaleDate DATETIME,
SalePrice MONEY
)
DECLARE @i INT
SET @i = 1
WHILE (@i <=10000)
BEGIN INSERT INTO SalesHistory (Proct, SaleDate, SalePrice)
VALUES ('Computer', DATEADD(mm, @i, '3/11/1919'),
DATEPART(ms, GETDATE()) + (@i + 57) )
INSERT INTO SalesHistory (Proct, SaleDate, SalePrice)
VALUES ('BigScreen', DATEADD(mm, @i, '3/11/1927'),
DATEPART(ms, GETDATE()) + (@i + 13) )
INSERT INTO SalesHistory (Proct, SaleDate, SalePrice)
VALUES ('PoolTable', DATEADD(mm, @i, '3/11/1908'),
DATEPART(ms, GETDATE()) + (@i + 29) )
SET @i = @i + 1
END
GO
㈨ sqlserver snapshot快照怎麼用jdbc獲取
資料庫快照為你現有的資料庫創建了一個資料庫的殼，然後無論何時當數據頁被修改的時候，改變也同時被寫入稀疏文件(sparse file)當中
㈩ SQLServer 資料庫中如何保持數據一致性
為了在恰當的時候採用快照復制，資料庫管理員首先需要知道快照復制的特點。快照復制是指將數據以特定時刻的瞬時狀態轉發，而不堅實對數據的更新。在發生同步時，將生成完整的快照並將其發送到訂閱伺服器。簡單的說，快照復制就是每隔一段時間發生數據同步操作。而不是發布伺服器的數據一有更新就出發這個快照復制。顯然這種快照復制的數據同步性稍微差一點。在訂閱伺服器與發布伺服器之間有一段時間會存在數據不一致的情況。但是這可以在很大程度上提高訂閱伺服器與發布伺服器的性能。這就好像汽車運輸。採用快照復制的話可以將一個集裝箱裝滿後在送貨，而不是有多少送多少。掌握這個資料庫復快照復制的具體特點之後，資料庫管理員就可以來考慮在什麼情況下，採用快照復制更加的合理。 一、數據更改比較少的系統中。 快照復制與其他復制相比最主要的缺陷就是資料庫中的數據無法及時同發布伺服器一致。為此如果發布伺服器中的內容很少更改的話，顯然此時採用快照復制是比較合理的。此時採用快照復制的話，不僅數據一致性延遲的負面效應會越來越不明顯，同時可以提高發布伺服器與訂閱伺服器的性能。如在實際工作中，經常會遇到這樣的客戶。如一家企業在各地都有辦事處或者銷售機構，就像肯德基一樣，各地的產品價格基本上都是相同的，不怎麼會更改。即使更改的話，各地也是統一調整。由於此時產品價格表更改的比較少，那麼在企業總部的資料庫服務與各地的訂閱伺服器之間，採用快照復制的形式就會比較合適。其實類似的情況有很多。如不少的服裝企業，像李寧、耐克等等，他們不僅自己生產，而且在各地又有自己的銷售辦事處。在價格方面也是統一的。在這種情況下，採用快照復制往往能夠提高資料庫復制的性能，同時又不影響其使用。 二、在某個時段內會出現數據大量的更改。 需要補充說明的一點是，上面說到的數據不怎麼發生更改，指的是數據的延續性更改。如在一年中，每天或者每個小時更改的數據都比較平均。此時採用快照復制不怎麼合適。但是如果數據的更改集中在一個時段內。而其他時間中資料庫的內容不會有多大的更改。此時採用快照復制是可行的。如一些決策性系統，往往在起初導入數據的時候，需要進行大量的更改。而等到數據導入完畢，在大家對數據進行分析時，則資料庫中的內容基本上保持不變。在這種情況下，筆者認為只要數據的更新集中在一個固定的時段，此時採用快照復制仍然是可行的。 再如上面這個KFC或者服裝企業的案例中，如果市場部門維護一個產品的價格，而且這些價格往往在一個固定的時間進行幾次更新。如在換季的時候會進行一些促銷。此時資料庫管理員可以在數據更新完畢後立即執行復制完成的數據快照。所以，以數據更新來判斷是否適合採用快照復制，標准並不是數據的更新量。像上面提到的分析決策系統，其起初的數據更新量可能比有些資料庫系統幾年的數據更新量都要大。筆者認為，主要是根據數據更新的頻率來進行判斷。如果數據更新的比較頻繁，那麼即使數據更新的數據不多，像那種細水長流似的更新，則不適合採用快照復制。而那些井噴似的數據更新，所有的更新都集中在一個固定的時刻，那麼此時採用快照復制是比較合理的。 三、在一段時間內是否允許具有相對發布伺服器已過時的數據副本? 現在不少超市也已經連鎖了，如世紀聯華等等。為了提高利潤，增加市場的份額，這些超市紛紛推出了沖值卡，即消費者先將一定金額的人民幣打入到沖值卡中。然後每次消費完成後從卡中扣費。但前些天經常有新聞報道，說一個客戶的消費卡在一家聯華超市掛失了。但是撿到這張卡的人仍然可以在其他的聯華超市中消費。為此消費者就想不明白了，為什麼掛失了的消費卡仍然可以在其他超市中消費?掛失後的損失該由誰來承擔呢?其實這就使超市在不適當的時候採用了快照復制所造成的。由於採用快照復制，在各個聯華超市的資料庫之間數據無法在短時間內取得一致。如有些商戶說掛失當日之內的損失他們不承擔，這就說明他們可能是每天下班後進行一次快照復制。一般情況下這不會有問題。但是像遇到消費卡被偷了等情況，就會遇到類似的問題了。 所以，在考慮是否適合採用快照復制的時候，還需要考慮在一段時間內是否允許具有相對發布伺服器來說已過時的數據副本。如果不允許的話，那麼就不允許採用這個快照復制。如果允許的話，那麼資料庫管理員就需要評估這段時間最長是多少。如果是24個小時，那麼就需要每隔24小時進行一次快照復制。但是需要注意的是，如果時間的間隔比較短，如才允許十分鍾的數據延遲，那麼採用快照復制就沒有必要了。此時採用事務復制或則和合並復制可能更加的合適。 四、復制少量的數據。 快照復制跟其他復制類型相比，還有一個比較顯著的特點，即當發生數據同步時，將生成完整的快照並將其從發布伺服器傳送到訂閱伺服器。這是一個什麼概念呢?如訂閱伺服器中有10G的數據，而在一個快照復制的周期內，只有1M的數據發生了更改。此時發生快照復制的話，資料庫系統會將10G的數據都傳送到訂閱伺服器上。此時更改的數據只有1M，卻需要在網路上傳送10G的數據流量，顯然會對企業的網路產生比較大的壓力。由於在發布伺服器上快照復制的連續開銷低於事務復制的開銷，一次資料庫系統不會啟用跟蹤增量更改。但是像這種情況，如果要復制的數據量非常的大，而平時的更新又不多。此時資料庫系統要生成和應用快照，就將耗用大量的資源，包括網路資源和伺服器資源。所以說，當發布伺服器中的數據比較多時，採用快照復制不怎麼合適。因為此時網路傳輸反而會成為其最重大的瓶頸資源。相反若能夠採取細水長流的事務復制策略，那麼對於企業網路性能的影響就會小的多，甚至可以忽略不計。 所以在採用快照復制的時候，資料庫管理員一定要明白，快照復制會傳送整個資料庫對象。從而在快照復制傳輸過程中會侵蝕大量的網路帶寬，從而明顯的降低企業網路的性能，甚至導致網路擁塞。有時候為了保障快照能夠准確、迅速的傳遞到其他的訂閱伺服器，還不得不採用VPN等技術來保障傳輸的准確性。為此，筆者認為只有發布伺服器的資料庫並不是很大的情況下，才適合採用快照復制。否則的話，採用快照復制是得不償失。 從以上的分析中，可以得到一個結論。在考慮採用快照復制是否合適時，往往不能夠採用一個指標來判斷。而需要考慮多個因素，如資料庫的大小、數據更新的頻率、允許數據延遲的時間等等因素來進行判斷。最後在數據的一致性與資料庫的性能之間取得一個均衡。說實話，對於大部分資料庫管理員來說，要做出一個抉擇，確實有困難。因為這沒有固定的指標可以拿來參考。如資料庫容量小於多少時該採用快照復制。任何一個資料庫管理專家都不能夠下這個結論。所以在掌握影響其選擇的相關因素外，就要依靠資料庫管理員的經驗了。在遇到類似的選擇題時，往往經驗可以幫助管理員迅速解決問題。最後需要提醒的是，無論最終採取了什麼方案，最好能夠持續跟蹤一段時間，看看自己的選擇是否合理。