備份策略配置和操作由什麼執行

⑴ 如何制定數據備份策略

制定數據備份策略要根據數據量的大小以及數據的增加速度等有很大的關系，而使用什麼樣的數據備份策略還是請專門的技術人員制定比較好，這樣不會帶來損失而且還能很好的操作，數據備份不是簡單的事情，需要軟硬體的結合，以及備份數據的多少，睿芸備份軟體根據用戶的需求可以選擇不同作用的備份軟體，並且備份軟體還能很好的操作，只需要設置好時間以及備份的數據，就能輕松的實現備份，最重要的是不會影響工作。

⑵ RMAN備份策略都有哪些

建立增量備份：
如果資料庫運行於不歸檔模式下，只能在資料庫干凈關閉的情況下 ( 以 normal 、
immediate 、 transactional 方式關閉 ) 才能進行一致性的增量備份，如果資料庫運行於歸
檔模式下，那即可以在資料庫關閉狀態進行，也可以在資料庫打開狀態進行備份。再
次說明了打開歸檔模式的優勢，歸檔日誌也就是多佔些磁碟空間，可也相當於又給數
據加了層保護。建立增量備份，實質就是一個參數 incremental level=n ，在執行 backup
命令時加上即可，例如，建立一個增量級別 0 的全庫備份：
rman> backup incremental level=0 database;
再例如，建立一個增量級別 1 的 users01.dbf 數據文件備份
rman> backup incremental level=1 tablespace system
datafile 『e:\oracle\oraback\sj_data.dbf』;
註： rman 默認創建的增量備份是 differential 方式，如果要建立 cumulative 方式的增
量備份，在執行 backup 命令時顯式指定即可，例如：
rman> backup incremental level=2 cumulative database;

建立鏡像復制：
rman 中的鏡像復制實質與通過操作系統 命令備份相同，甚至連命令的格式
都相似，只不過直接應用操作系統的 命令復制數據文件時，只是文件拷貝，而rman
的 則能夠在復制的同時，驗證數據的有效性。個人認為 rman 中的鏡像復制應用
有限，而且也體現不出 rman 的優勢，所以俺也只是大致了解了概念，沒有進行過實際
操作，感興趣的朋友可以自己做做試驗，這里就不多做介紹了）

建立冗餘備份

（

rman 提供了一種更謹慎的備份策略： plexed 方式備份，其實質即是在生成備份
集的同時，向指定位置生成指定份數 ( 最大不超過 4 份 ) 的備份集復制，以避免在災難性
事故時資料庫損壞和備份丟失的情況下導致完全崩潰，提高備份可用性。 rman 中提供
了三種方式實現 plexed 方式備份：

1) 在 rman 中執行 backup 命令時顯式指定 copies 參數。例如：
rman> backup copies 3 database;
上述命令將會在全庫備份的同時，自動生成當前備份集的 2 份拷貝到默認備份目錄。

2) 在 run ｛｝命令塊中利用 set backup copies 命令為該命令塊中所有的 backup命令設
置 plexed 方式，例如：
rman> run{
set backup copies 2;
backup device type disk format
『e:\oracle\oraback\dyk1\%u』,'e:\oracle\oraback\dyk2\%u』
tablespace users,sales;
}
上述命令將生成兩份備份集，分別存儲到 e:\oracle\oraback\dyk1 和
e:\oracle\oraback\dyk2 目錄。

3) 通過 configure ….. backup copies 命令設置預定義的備份 plexed 方式
configure … backup copies 命令格式，可以為指定設備類型設置默認備份拷貝數
量。這個配置僅適用於數據文件與歸檔重做日誌文件和備份，並且，只有在使用自動
分配的通道時才能夠使用 configure …
backup copies 命令設置的配置。例如：
rman> configure default device type to disk;
rman> configure datafile backup copies for device type disk to 2;
rman> configure archivelog backup copies for device type disk to 2;
上述命令將 disk 設置上數據文件與歸檔文件的拷備數量設置為 2 ，當再執行 backup
database 備份時，即會自動生成 2 份數據文件的備份集。

設置 rman 備份的保存策略
策略，如果資料庫非常大，並且備份執行也比較頻繁，有必要對這些備份文件的
保存制訂合理的策略。在通過 rman 創建的備份片段中，由於備份文件也是由 rman創
建和維護，所以手工刪除並不明智，並且 rman 也提供了備份保留策略，合理制訂，由
rman 自動刪除陳舊備份文件更加安全也更加方便， rman 中提供了兩種備份保留策略：
基於時間，和基於冗餘數量
為 rman 設置了備份保留策略之後， rman 會自動判斷哪些備份集或鏡像復制文件
不必再保留。這些備份文件將會被標記為 「 廢棄 (obsolete)」 ，可以通過 report obsolete
命令查看當前處於廢棄狀態的備份文件，或者通過 delete obsolete 命令刪除這些廢棄的
備份。例如：
rman> report obsolete;

rman> delete obsolete;

在執行刪除命令時有兩點需要了解：
如果被判斷為廢棄的備份是一個單獨數據文件的鏡像復制，那麼在執行 delete 命
令時將直接刪除這個鏡像復制文件；如果被判斷為廢棄的備份是一個備份集中的一部
分，則必須等到整個備份集中所有其它文件都被廢棄之後，才能刪除這個備份集。
1) 基於時間的備份保留策略。
說的簡單些，就是你希望資料庫最早能恢復到幾天前。比如將恢復時間段設置為 7，那
么 rman 所保留的備份即是可以保證你將資料庫恢復到一周內任何時刻下那些文件。設
置基於時間的備份保留策略可以通過 configure 命令，例如：
rman> configure retention policy to recovery window of n days;
註： n= 大於 0 的正整數執行該命令後， rman 將始終保留那些將資料庫恢復到 n 天前的
狀態時需要用到的備份，比如，恢復時間段被設置為 7 天，那麼各個數據文件的備

份必須滿足如下條件：
sysdate-(select checkpoint_time from v$datafile)>=7
任何不滿足上述條件的備份都將被 rman 廢棄並可通過 delete obsolete 命令刪除。

2) 基於冗餘數量的備份保留策略
基於冗餘數量實質即某個數據文件以各種形式（包括備份集和鏡像復制）存在的
備份的數量。如果某個數據文件的冗餘備份數量超出了指定數量， rman 將廢棄陳舊的
備份。同樣，基於數量的備份保留策略也是通過 configure 命令設置，例如：
rman> configure retention policy to recovery window of n days;
同上： n= 大於 0 的正整數
也可以設置不保留任何數據的策略
rman> configure retention policy to none;

備份優化
rman 中的備份優化 (backup optimization) 是指在備份過程中，如果滿足特定條件， rman
將自動跳過某些文件而不將它們包含在備份集中以節省時間和空間。通常滿足如下幾
個條件情況下，才能夠啟用備份優化的功能：
configure backup optimization 參數置為 on ；
執行的 backup database 或 backup archivelog 命令中帶有 all 或 like 參數。
分配的通道僅使用了一種設備類型，也就是沒有同時分配使用 sbt （磁帶）與 disk
（磁碟）的多個通道。

打開備份優化設置通過如下命令：
rman> configure backup optimization on;
在進行備份優化時， rman 是如何判斷要備份的文件是否需要被優化，這個演算法就
相當復雜，可能影響優化演算法的因素也非常多，假如某庫在上午 9 點被執行過一次全
庫備份，等下午 3 點再次執行全庫備份時，備份的文件沒有變動而且也已經被備份過
時，才會跳過這部分文件。所以理論上備份優化僅對於只讀表空間或 offline 表空間起
作用。當然對於已經備份過的 archivelog 文件，它也會跳過
3 ）基礎補充
format 字元串替代變數，使用 format 參數時可使用的各種替換變數，如下：
%c ：備份片的拷貝數 ( 從 1 開始編號 ) ；

%d ：資料庫名稱；
%d ：位於該月中的天數 (dd) ；
%m ：位於該年中的月份 (mm) ；
%f ：一個基於 dbid 唯一的名稱 , 這個格式的形式為 C-IIIIIIIIII-YYYYMMDD-QQ, 其
中 IIIIIIIIII 為該資料庫的 dbid ， YYYYMMDD 為日期， QQ 是一個 1-256 的序列；
%n ：資料庫名稱，並且會在右側用 x 字元進行填充，使其保持長度為 8 ；
%u ：是一個由備份集編號和建立時間壓縮後組成的 8 字元名稱。利用 %u 可以為每個
備份集生成一個唯一的名稱；
%p ：表示備份集中備份片段的編號，從 1 開始編號；
%u ：是 %u_%p_%c 的簡寫形式，利用它可以為每一個備份片段（即磁碟文件）生成
一個唯一名稱，這是最常用的命名方式；
%s ：備份集的號；
%t ：備份集時間戳；
%t ：年月日格式 (yyyymmdd) ； s
註：如果在 backup 命令中沒有指定 format 選項，則 rman 默認使用 %u 為備份片段命
名。

configure 配置項介紹
首先，先來查看一下當前配置，通過 show all 命令：
連接到目標資料庫 : jssweb (dbid=3391142503)
rman> show all;
正在使用目標資料庫控制文件替代恢復目錄
rman 配置參數為 :
configure retention policy to recovery window of 3 days;
configure backup optimization off; # default
configure default device type to disk; # default
configure controlfile autobackup on;
configure controlfile autobackup format for device type disk to 『e:\oracle\oraback\%f』;
configure device type disk parallelism 1; # default
configure datafile backup copies for device type disk to 1; # default
configure archivelog backup copies for device type disk to 1; # default
configure maxsetsize to unlimited; # default
configure snapshot controlfile name to 『e:\oracle\oraback\sj_data.ora』; #
default
rman>

show 命令在 rman 命令篇簡單介紹過，同時也知道後跟 #default 表示該條配置仍
然是初始的默認配置，如果想把某條更改過配置選項再置為

初始設置，用如下命令： configure … clear; 例如：
rman> configure retention policy clear;
configure retention policy to recovery window of 3 days;
上述的各項配置，在前面章節中有一些已經有所體現，以下是詳細介紹：
1)configure retention policy 配置備份保留策略

兩種保留策略設置：
基於時間：
configure retention policy to recovery window of n days;
基於冗餘數量：
configure retention policy to rendancy n;
也可以取消備份保留策略：
configure retention policy to none;
2)configure backup optimization 配置備份優化
備份優化 : 包括 off 和 on 兩個狀態
打開備份優化：
configure backup optimization on;
關閉備份優化：
configure backup optimization off;
3)configure default device type 配置 io 設備類型
rman 支持的 io 設備類型有兩種：磁碟 (disk) 和磁帶 (sbt) ，默認情況下為磁碟。
使用磁碟設備：
configure default device type to disk;
使用磁帶設置：
configure default device type to sbt;
在這里需要注意的一點是：如果 io 設備發生變化，相關配置項也需要修改。例如：
rman> configure device type disk parallelism 2;
4) configure controlfile autobackup 配置控制文件自動備份
是否自動備份，包含兩個狀態： off 和 on
打開自動備份
configure controlfile autobackup on
禁止自動備份
configure controlfile autobackup off
指定備份的控制格式和路徑。例如：
configure controlfile autobackup format for device type disk to
『e:\oracle\oraback\%f』;
在備份期間，將產生一個控制文件的快照，用於控制文件的讀一致性，這個快照可以
通過如下配置： configure snapshot controlfile name to
『e:\oracle\oraback\sj_data.ora』;

5)configure device type 設置並行備份
rman 支持並行備份與恢復，也可以在配置中指定默認的並行程度。例如：
configure device type disk parallelism 2;
指定在以後備份與恢復中，將採用並行度為 2 ，同時開啟 2 個通道進行備份與恢復，
當然也可以在 run 中指定通道來決定備份與恢復的並行程度。並行的數目決定了開啟
通道的個數。如果指定了通道配置，將採用指定的通道，如果沒有指定通道，將採用
默認通道配置。默認情況下，自動分配通道的並行度為 1 ，如果你通過設置 parallelism
設置了並行通道為 2 ，那麼在 run 塊中，它會默認使用 2 條並行通道 ; 如果在 run命令
塊中指定數個 allocate channel ，那麼 rman 在執行備份命令時會以設置的 channel 為准，
而不管 configure 中配置了多個並行通道。需要注意的是，在 backup 命令中有一個

filesperset 參數，該參數是指 rman 建立的每個備份集中所能包含的備份片段 ( 即磁碟文
件 ) 的最大數，該參數默認值為 64 ；如果在執行 backup 命令時沒有指定該參數值，那
么 rman 會僅使用第一個通道來執行備份，其它通道將處於空閑狀態。關於通道數與
filesperset 值之間也有一個大小關系，即 filesperset 值不要小於設定通道數。

6) 設置備份文件冗餘度
configure datafile backup copies

如下：
rman> run{
set backup copies 2;
backup device type disk format
『e:\oracle\oraback\dyk1\%u』,'e:\oracle\oraback\dyk2\%u』
tablespace users,sales;
}

7)configure maxsetsize 配置備份集的最大尺寸
該配置限制通道上備份集的最大尺寸。單位支持 bytes,k,m,g 。默認值是 unlimited。

8) rman 備份相關的動態性能表
v$archived_log ：本視圖包含了所有歸檔重做日誌文件的創建情況，備份情況以及其
他信息。
v$backup_corruption ：這個視圖顯示了 rman 在哪些備份集中發現了損壞的數據壞。
在你使用 backup validate 命令對備份集進行檢查時如果發現了損壞的數據塊， rman
將在這個視圖中寫入記錄。
v$_corruptio ：本視圖顯示了哪些鏡像復制備份文件已經被損壞。
v$backup_datafile ：本視圖通常用來獲取每個數據文件中非空白數據塊的數量，從
而幫助你創建出大小基本相等的備份集。另外，在視圖中也包含了數據文件中損壞的
數據塊的信息。
v$backup_redolog ：本視圖顯示了在現有的備份集中飲食有哪些歸檔重做日誌文件。
v$backup_set ：本視圖顯示了已經創建的備份集的信息。
v$backup_piect ：本視圖顯示了已經創建的備份片段的信息。
可以通過如下 sql 語句獲得正在進行的鏡像復制操作的狀態信息：
select sid,
serial#,
context,
sofar,
totalwork,
round(sofar / totalwork * 100, 2) 「% complete」
from v$session_longops
where opname like 『rman:%』
and opname not like 『rman:aggregate%』
通過如下 sql 獲得 rman 用來完成備份操作的服務進程的 sid 與 spid 信息：
select sid,spid,client_info from v$process p,v$session s where p.addr=s.paddr and
client_info like 『%id=rman%』

rman 通道
上次基礎知識講提到了通道， rman 通道實質是一個到存儲設備的數據流。就像城市交
通道路，多建幾個環路對於緩解交通是有意義的。在 rman 中可以通過手動方式或自動
方式分配通道。
1) 手工分配通道
在執行 backup 、 restore 、 delete 等需要進行磁碟 i/o 操作的命令時，可以將它們與 allocate
channel 命令放在一個 run 的命令塊中，利用 allocate channel 為它們分配通道。例如：
run{
allocate channel ch1 device type disk format 『e:\oracle\oraback\%u』;
backup datafile 『e:\oracle\oradata\oradb1\sj_data.ora』;
}
需要注意的是， rman 中執行的每一條 backup 、 delete 等命令都至少要求使用一個通道，
通道數決定了這些操作執行的並行度。

⑶ SVN的操作說明以及備份策略

2.1 文件檢出
安裝TortoiseSVN後，SVN會跟Windows的資源管理器完美集成。點擊右鍵，我們可以在菜單欄中選擇「SVN檢出」選項，輸入要檢出代碼的文件庫的URL地址，我們就可以檢出該URL地址下的文件庫的文件。默認情況下是檢出最新版本的代碼，如果需要，我們可以通過瀏覽日誌，根據日誌來找出想要的版本，然後在「版本」選項中指定相應版本就可以檢出相關代碼了 。
之後，對於同一個項目的主幹開發，我們都在這個檢出的代碼文件目錄下操作，而不是每一次提交或更新都重新檢出一次。
2.2 文件添加
我們在本地創建的文件(包括目錄)不會受SVN的控制，為了讓其接受SVN的控制必須將其添加到文件庫中。對於團隊其他成員需要的文件，如代碼文件、某些模塊的.a文件（由於某些需要，該模塊代碼不公開），我們必須讓它們接受SVN的控制，並且保持最新的版本。
2.3 文件刪除
當我們需要刪除無用的文件(包括目錄)時，不能使用Windows的資源管理工具，而必須使用SVN本身的刪除文件功能。這樣該文件被刪除後，其所有修改歷史仍然保存在SVN伺服器中，以後仍然可以獲得該文件的修改歷史。
2.4 文件改名
當我們需要對文件(包括目錄)進行改名的時，不能使用Windows的資源管理工具，而必須使用SVN本身的文件改名功能。這樣該文件被改名後，其改名前的所有修改歷史仍然保存在SVN伺服器中，保持連續的修改信息。
2.5 文件更新
其他團隊成員提交到SVN上的改動不會自動更新到你的本地拷貝中來，我們需要通過更新文件操作來獲取其他成員對項目文件所做的修改。SVN更新文件操作會把文件庫里的文件與本地文件進行合並，從而達到了同時保留其他成員的修改及本地的修改的目的。如果無法自動合並則會發生沖突，需要使用文件比較工具進行手工合並，合並完成後才能提交已解決沖突的文件。沖突的詳細解決方法見第三章——沖突解決。
在團隊開發時，更新是一件很重要的工作，可以保持團隊成員之間的工作內容一致，因此要注意經常更新自己的工作拷貝，以保證自己能夠獲得最新的修改內容。
2.6 改動提交
我們對文件(包括目錄)所做的一切改動，包括添加、刪除、修改文件都必須提交到SVN伺服器文件庫中才能正式生效，之後團隊的其他成員才可以獲取你所作的修改。
提交是很重要的一項操作，要求做到：
 提交代碼之前一定要保證修改後的代碼能編譯通過，不能提交編譯不通過的代碼。
 比較修改前及修改後的代碼，把調試信息或其他不相關的信息去掉，再次確保提交的代碼是正確的並且提交的是需要提交的文件。
 不要等到修改了很多代碼才提交，而是相關小功能完成時就應該提交一次。這樣以後發現問題時就很容易撤銷有問題的代碼——因為撤銷只能針對一次提交，所以在一次提交里涉及過多的功能是不推薦的。
 提交時必須填寫log信息，說明這次提交增加了什麼功能或者修正了什麼bug。這些信息有助於自己和其他團隊成員了解整個項目的歷史。當出現問題時也方便定位到對應的版本代碼，所以log信息必須足夠詳細。
 事務性提交。也就是說提交要麼成功，要麼全部失敗——即提交出現錯誤時會自動回滾，實際上沒有提交任何東西。出現錯誤時，解決錯誤，再次提交上次提交的全部內容即可。
3. 沖突解決
沖突的解決是我們使用SVN過程中的一個棘手問題，所以獨立一節來談論。
3.1 沖突的產生
沖突發生在多個成員同時對同一個文件進行修改的情形下。即當有其他成員已經提交了修改，而自己在本地拷貝中也對該文件進行了修改，而且修改的是同一個地方，那麼在進行本地文件的更新時，SVN會不知道該選擇那個修改（SVN上的修改還是本地的修改）來進行合並，所以沖突就產生了。
舉例說，假如受SVN控制的文件Day.txt在SVN伺服器上的當前內容如下：
圖表 3 Day.txt文件在本地的修改
我們可以看到，在文本的第一行，SVN上及本地都做了修改。這樣當在本地進行更新（提交之前必須先更新），SVN合並時就不知道monday後面到底該是work還是sleep，所以沖突就產生了。
而第三、五行是各自進行了修改，並沒有沖突，所以這兩行可以順利合並，合並後可以看到所有人所做的修改。
3.2 沖突的解決
沖突發生後，SVN會在本地保存該文件的不同修改版本，見下圖藍色圖標：

圖表 4 Day.txt文件的不同版本
 Day.txt.r35是版本35的Day.txt文件（本地拷貝最新版本）
 Day.txt.r37是版本37的Day.txt文件（SVN上最新版本）
 Day.txt.mine的是本地修改後的Day.txt文件
 Day.txt文件中包含了合並後的內容
3.2.1 簡單沖突解決
對於簡單的內容沖突，我們可以直接在合並後的文件上修改。在上例中，我們打開Day.txt文件，可以看到SVN合並後的內容：

圖表 5 Day.txt合並後內容
我們看到沒有沖突的修改：(play basketball)及（meeting）順利地合並了，而沖突的部分出現了一些標記。其中標記
<<<<<<< .mine
=======
之間包含的是本地修改的沖突部分的內容，即monday(work)。而標記
=======
>>>>>>> .r37
之間包含的是版本37（SVN上最新版本）該部分內容，即monday(sleep)。
不失一般性，假如我們現在要保留的內容是monday(work)，那麼我們只要把標記及monday(sleep)部分內容去掉即可：

圖表 6 Day.txt解決沖突後內容
確保修改正確後，把Day.txt文件設置為「已解決的」。

圖表 7 Day.txt標記為已解決
之後，後綴為mine,r35,r37文件全部消失，僅保留已解決沖突的Day.txt文件，提交到SVN即可。
3.2.2 復雜沖突解決
對於文件內容復雜的文件，上述的解決方法容易漏掉一些要修改的部分，解決起來也耗時耗力。這時要通過SVN提供的工具來解決。
選擇SVN功能「編輯沖突」，打開沖突編輯工具:

圖表 8 沖突編輯工具
上半部分的兩個內容欄分別顯示的是版本37的內容及本地修改的內容。
下半部分的內容欄顯示的是合並後的內容。
每個內容欄左邊的標記清楚地標識了該文件做了那些修改。
文件沖突的部分用紅色顯眼地表示了出來。在合並欄，點擊沖突部分，點擊右鍵，我們可以選擇用哪個內容（SVN上最新內容或者本地修改內容）來解決沖突部分，也可以選擇兩個內容都使用，同時選擇它們出現的先後順序。
逐一解決各個沖突。確保所有沖突都解決後，保存文件，並標記為「已解決」的，退出該工具即完成沖突的解決。
4. 加鎖策略
事實上，解決沖突還有一種方法，那就是「嚴格加鎖」。
「嚴格加鎖」要求在編輯文件之前必須先對文件加鎖，然後才能進行編輯。此時團隊其他成員不能對該文件進行編輯，即保證了同一時刻只有一個人在編輯該文件，因此避免了沖突的出現。
那麼，什麼類型的文件我們應該採取「嚴格加鎖」呢？
 Excel、圖片等不可合並的文件，我們必須對其「嚴格加鎖」。「嚴格加鎖」的文件都標記為「可讀」的，即不可編輯。要編輯這些「嚴格加鎖」的文件，必須先對其加鎖，加鎖後文件更改為「可讀可寫」。編輯完這類文件後要第一時間提交。提交完成時，SVN會自動解開任何你擁有的鎖 。
 文本文件，比如程序代碼，SVN通常可以為我們合並改動，無須「嚴格加鎖」。對於一些大家都頻繁改動的重要源代碼文件，可能會引起大量沖突，我們也不推薦「嚴格加鎖」，因為加鎖會導致大家持續得走來走去去詢問加鎖情況。正確做法是把文件分成數個邏輯單元，大家都修改各自的單元，減少合並時的沖突。
5. 標簽&分支
一個項目最初存放的目錄我們稱之為主幹(trunk)。下面我們討論除了主幹之外其他存放項目的目錄——標簽(tag)和分支(branch)。
5.1 標簽（tag）
版本號可以區分多次的代碼修改，我們可以使用版本號來檢出需要的代碼，但對於重要版本的代碼，如第三版發布代碼，我們不希望記住r37這樣的數字。這時，我們就可以通過創建標簽來對SVN中這個發布版本的文件的這個時刻的狀態創建一個「快照」，以後就可以通過這個標簽名字來檢出第三發布版本的代碼。
標簽其實是當前項目文件的簡單拷貝，保存在標簽所在的目錄下。創建標簽也是挺簡單的，不過要注意：
 標簽的名字一定要有描述性，可以僅憑名字就知道為什麼要創建標簽。
 不能過多地使用標簽，只有在重要時刻或者發布版本時才可以創建標簽。
 標簽是項目文件在某個時刻的狀態，不能對其進行修改 。
5.2 分支（branch）
分支跟標簽一樣，也是當前項目文件的簡單拷貝，保存在分支所在的目錄下。
分支跟標簽的根本區別在於，標簽不能對其進行修改，而分支就是為了某種目的的修改而建立的。在檢出代碼時檢出指定分支即可，分支的操作跟主幹上的操作完全相同。
5.2.1 何時創建
遇到下述情況，我們可以通過創建分支來解決問題：
 發布分支
當我們快要發布一個版本了，一個開發小團隊要為這次發布做好准備，比如說修改一些收尾的bug。這時他們需要的是項目的穩定性，而同時我們還有其他團隊要開發預計下次發布才會添加進去的功能，顯然他們不能在同一份代碼上工作，因此我們需要從主幹中建立出一個發布分支，發布團隊都從這個發布分支檢出及提交代碼。當程序被發布之後，這個分支依然是活動的。這樣，如果客戶報告了一些bug，團隊會在這個發布分支中修正它們並視情況合並到主幹中去。
 試驗分支
當我們需要對項目做大范圍的改動，並且這改動對系統的其餘部分有深遠的影響，而我們又不能保證這次改動一定能成功的時候就可以建立試驗分支。如果試驗失敗了，可以廢棄這個分支；成功了我們只要把分支的改動合並到主幹代碼中去就可以了。
其他情況，我們不建議創建分支，更不推薦在分支上創建分支，因為分支過多，合並時的沖突將會是一種難於解決的災難。
5.2.2 合並分支
我們在分支上所修正的bug很可能在主幹上或者其他分支上也存在，因為它們往往來自同一份代碼，所以我們在分支上所做的改動有必要合並到主幹或者其他分支中去。
對於簡單的bug，一次提交就能解決問題的，那麼我們只要記住提交新版本號，然後使用新版本號把改動合並到其他的受影響的主幹及分支中去就可以了。
對於復雜的bug，可能需要多個開發者花幾天的時間提交多次才能修好。這時光用版本號來記住修改的內容就有點勉為其難了。因此，我們可以使用標簽來標記我們修正過程的開始和結束，然後使用這些標簽幫助我們把修正的代碼合並到主幹和其他分支中去。整個過程如下：
① 給分支打個標簽，標記bug修改開始。
② 測試重現bug，修正代碼讓新測試通過。
③ 提交你的改動到SVN上。
④ 重復步驟2、3，直到確定bug已經修正。
⑤ 再給分支打個標簽，標記bug修正結束。
⑥ 使用兩個標簽來把修正的代碼合並到所有其他受影響的主幹和分支上。
6. 注意事項
經常更新
 由於文件可能有多個人修改，應該經常更新你的工作拷貝中的文件，這樣能降低發生沖突的可能性。
測試提交
 提交前先在本地進行測試。不允許將有錯誤的文件提交到SVN伺服器上。
填寫備注
 提交時一定要寫備註：備注有助於其他人（包括三個月後的你自己）理解你對文件所做的修改。
整體提交
 提交文件時注意要提交一項改動所對應的所有文件，不要一次提交一個文件或者一次提交修改了很多功能的一堆文件。
發布標簽
 對於每一個發布的版本都要建立標簽：當用戶告訴你發生某個問題時，你可以迅速地追蹤到問題是在哪個版本引入的 。

附：測試自動化小組SVN使用指導原則
1. Project的構建
Project在SVN伺服器上的目錄架構如下：

SVN上的項目文件：
1. 必須保證Trunk上的代碼是最新的！定期對Trunk上的代碼進行更新，各小組可根據各自實際情況自己把握
2. Tag是根據項目需要所打的標簽，每一個發布的版本都要打Tag，主要是方便有需要時可以直接根據Tag返回到之前的狀態，以便於分析、測試；Tag中必須包含相應的release文件及當時編譯或發布時的源代碼，必須有相關的文檔註明項目背景、發布情況等。
3. Branch文件夾可以用作備份用，可以用個人名字命名文件夾；此外，Branch分支主要用來進行短暫或者探索性的開發使用，最終的軟體版本必須更新、合並到Trunk主幹上。
4. 關於同一項目組開發環境的建議：同一項目組成員的開發環境最好一致，軟體安裝路徑和Project文件存放路徑最好一致。
2. 版本號
關於版本號命名規則：主版本號.子版本號.修正版本號
1. 項目初版本時，版本號為0.1.0；
2. 當項目在進行了局部修改或 bug 修正時，主版本號和子版本號都不變，修正版本號加 1；
3. 當項目在原有的基礎上增加了部分功能時，主版本號不變，子版本號加 1，修正版本號復位為 0；
4. 當項目在進行了重大修改或局部修正累積較多，而導致項目整體發生全局變化時，主版本號加 1，子版本號和修正版本號復位為0；
5. 編譯版本號一般是編譯器在編譯過程中自動生成的，我們只定義其格式，如果編譯器不能自動生成，人手添加，數值代表為當前的系統時間。
例子：V1.0.1 Build090305 Rel111123
其它版本使用規則：
1. α（alphal）內部測試版
此版本表示該軟體僅僅是一個初步完成品，只在組內內部交流，該版本軟體的 bug 較多，限內部測試使用。
例子：V0.1.1 Build090305 alphal1
2. β（beta）外部測試版
該版本相對於α版已有了很大的改進，經過組內的測試，消除了嚴重的錯誤，但還是存在著一些缺陷，需要經過大規模測試來進一步消除。
例子：V0.1.2 Build090305 beta1
3. demo 演示版
僅限評審或講解時做介紹使用。
例子：V0.1.3 Build090305 demo1
4. release 最終版
該版本意味「最終釋放版」，在出了一系列的測試版之後，終歸會有一個正式版本，一般情況下，release不會以單詞形式出現在軟體封面上，取而代之的是符號 (Rel) 。release版本發布時，必須將待發布的軟體和相應版本更新記錄打包在一起發出。
例子：V1.0.1 Build090305 Rel111123
3. 許可權限制
如果項目本身需要對項目組成員作不同的許可權控制，可以考慮維護兩個工程：一個工程裡面有相應的源文件，一個則只有編譯後的文件。
4. 模塊的版本維護
1. 文件一般不需要版本，但要有詳細的更新歷史記錄；
2. 模塊可以以版本來維護，具體可以不同的文件夾區分。

⑷ 備份舊計算機中的用戶文件和配置信息的具體操作方法

1、系統備份文件（如*.gho文件）部分是可以直接拷到其它電腦上使用的，如果其它電腦的配件和備份電腦的配置是完全一樣的，那麼這個備份文件安裝完就可以使用，無需再進行任何操作和設置。系統和原備份電腦是一模一樣的。 2、電腦配置不一樣，但架構平台相同的，如INTEL平台，舊架構的備份文件不能用在新架構的電腦上，會藍屏。高版本的備份文件則可以用在低版本的電腦上，不過安裝後，要先進入安全模式，卸載有差別配件的驅動，再相應本機電腦，安裝正確的驅動。 3、如果架構平台不相同，如INTEL平台的備份文件用在AMD平台上，或反之，都是不行的。 4、如果用一定的電腦基礎，備份文件前，先用專門的封裝軟體，先將原系統進行封裝後，再進行備份的備份文件，則可以在任何配置不同，架構新舊不同和架構平台不同的電腦上進行安裝。（就象賣的GHOST版本系統安裝光碟中的文件）

⑸ 什麼是備份策略

什麼是備份
所謂備份，就是把資料庫復制到轉儲設備的過程。其中，轉儲設備是指用於放置資料庫拷貝的磁帶或磁碟。通常也將存放於轉儲設備中的資料庫的拷貝稱為原資料庫的備份或轉儲。如下圖所示：

ORACLE資料庫的備份分為物理備份和邏輯備份兩種。物理備份是將實際組成資料庫的操作系統文件從一處拷貝到另一處的備份過程，通常是從磁碟到磁帶。可以使用 Oracle 的恢復管理器（Recovery Manager，RMAN）或操作系統命令進行資料庫的物理備份。邏輯備份是利用SQL語言從資料庫中抽取數據並存於二進制文件的過程。Oracle提供的邏輯備份工具是 EXP。

資料庫邏輯備份是物理備份的補充。

根據在物理備份時資料庫的狀態，可以將備份分為一致性備份（consistent backup）和不一致性備份（inconsistent backup）兩種：

一致性備份：一致性備份是當資料庫的所有可讀寫的資料庫文件和控制文件具有相同的系統改變號（SCN），並且數據文件不包含當前 SCN 之外的任何改變。在做資料庫檢查點時，Oracle 使所有的控制文件和數據文件一致。對於只讀表空間和離線的表空間，Oracle 也認為它們是一致的。使資料庫處於一致狀態的唯一方法是資料庫正常關閉（用shutdown normal 或 shutdown immediate 命令關閉）。因此，只有在以下條件下的備份是一致性備份：
資料庫正常關閉（用shutdown normal 或 shutdown immediate 命令關閉）。
不一致性備份：不一致備份是當資料庫的可讀寫的資料庫文件和控制文件的系統改變號（SCN）在不一致條件下的備份。對於一個 7*24 工作的資料庫來說，由於不可能關機，而資料庫數據是不斷改變的，因此只能進行不一致備份。在 SCN 號不一致的條件下，資料庫必須通過應用重做日誌使 SCN 一致的情況下才能啟動。因此，如果進行不一致備份，資料庫必須設為歸檔狀態，並對重做日誌歸檔才有意義。在以下條件下的備份是不一致性備份：
資料庫處於打開狀態。
資料庫處於關閉狀態，但是用非正常手段關閉的。例如，資料庫是通過 shutdown abort 或機器掉電等等方法關閉的。

什麼是恢復
所謂恢復，就是把資料庫由存在故障的狀態轉變為無故障狀態的過程。根據出現故障的原因，恢復分為兩種類型：

實例恢復。這種恢復是Oracle實例出現失敗後，Oracle自動進行的恢復。
介質恢復。這種恢復是當存放資料庫的介質出現故障時所做的恢復。本書後面提到的恢復都是指介質恢復。
裝載（restore）物理備份與恢復（Recover）物理備份是介質恢復的手段。裝載是將備份考回到磁碟，恢復是利用重做日誌（物理備份的一部分）修改考回到磁碟的數據文件（物理備份的另一部分），從而恢復資料庫的過程。如下圖所示：

根據資料庫的恢復程度，將恢復方法分為兩種類型：

完全恢復：將資料庫恢復到資料庫失敗時資料庫的狀態。這種恢復是通過裝載資料庫備份和並應用全部的重做日誌做到的。
不完全恢復：將資料庫恢復到資料庫失敗前的某一時刻資料庫的狀態。這種恢復是通過裝載資料庫備份和並應用部分的重做日誌做到的。進行不完全恢復後必須在啟動資料庫時用 resetlogs 選項重設聯機重做日誌。
例如，在上午10：00，由於磁碟損壞導致資料庫中止使用。現在使用兩種方法進行資料庫的恢復，第一種方法使資料庫可以正常使用，且使恢復後與損壞時（10：00）資料庫中的數據相同，那麼第一種恢復方法就屬於完全恢復類型；第二種方法能使資料庫正常使用，但只能使恢復後與損壞前（例如9：00）資料庫中的數據相同，沒能恢復資料庫到失敗時（10:00）資料庫的狀態，那麼第二種恢復方法就屬於不完全恢復類型。

事實上，如果資料庫備份是一致性的備份，則裝載後的資料庫即可使用，從而也可以不用重做日誌恢復到資料庫備份時的點。這也是一種不完全恢復。

備份與恢復的關系
備份一個ORACLE資料庫，類似於買醫療保險——在遇到疾病之前不會意識到它的重要性，獲得保險金的數量取決於保險單的種類。同理，隨著製作備份的種類和頻繁程度的不同，資料庫發生故障後其恢復的可行性、難度與所花費的時間也不同。

資料庫故障是指資料庫運行過程中影響資料庫正常使用的特殊事件。資料庫故障有許多類型，最嚴重的是介質失敗（如磁碟損壞），這種故障如不能恢復將導致資料庫中數據的丟失。資料庫故障類型有：

語句失敗。
用戶進程失敗。
實例失敗。
用戶或應用錯誤操作。這類錯誤可能是意外地刪除了表中的數據等錯誤操作。
介質失敗。如硬碟失敗，硬碟中的數據丟失。
自然災害。如地震、洪水等。
由於故障類型的不同，恢復資料庫的方法也不同。通過裝載備份來恢復資料庫既是常用的恢復手段，也是恢復介質失敗故障的主要方法。

備份與恢復要考慮的問題
備份與恢復要考慮以下的三個問題：

備份與恢復策略要考慮的商業、操作、及技術問題
災難恢復計劃的組成
測試備份與恢復策略的重要性
能夠進行什麼樣的恢復依賴於有什麼樣的備份。作為 DBA，有責任從以下三個方面維護資料庫的可恢復性：

使資料庫的失效次數減到最少，從而使資料庫保持最大的可用性；
當資料庫不可避免地失效後，要使恢復時間減到最少，從而使恢復的效率達到最高；
當資料庫失效後，要確保盡量少的數據丟失或根本不丟失，從而使數據具有最大的可恢復性。
備份與恢復策略要考慮的商業、操作、及技術問題
作為 DBA，首先需要了解企業是如何使用資料庫系統的，以及企業對資料庫的可用性，恢復性能，和數據的可恢復性以及恢復時間的要求。然後，DBA 需要使企業的管理人員了解維護這樣的資料庫的可用性的代價有多大。做到這點的最好方法是評估恢復需要的花費，以及丟失數據給企業帶來的損失。

在代價被評估後，就可以進行備份與恢復的討論了。此時，要定義資料庫總體的可用性需求，並根據各項工作對資料庫可用性的影響程度來定義工作重點的次序。例如，如果資料庫需要 7*24 的可用性，那麼其重要性就高於其它任何工作，其它任何需要關機才能做的工作就不能做。

另外，資料庫變化的情況也是備份與恢復策略需要考慮的一個因素。例如，如果數據不斷改變，有新數據或數據文件加入，或表結構有大的變化，則應該經常備份；反之，如果數據是靜態的或只讀的，則備份一次即可。無論如何，應遵從這樣一個原則，如果懷疑資料庫的可恢復性，就應該備份。

災難恢復計劃的組成
針對災難恢復，必須回答下述問題：

系統可能出現什麼樣的災難恢復情況？
如果出現數據丟失，災難恢復情況是怎樣的？
系統中數據的易變程度如何？
如果出現問題，系統需要多快的速度恢復？
在各種情況下恢復策略的代價，以及相應的花時間重新錄入數據的代價?
對這些問題的回答組成了災難恢復計劃。

計算機是易壞的。主板上的晶元、主板電路、內存、電源等任何一項不能正常工作，都會導致計算機系統不能正常工作。當然，這些損壞可以修復，不會導致應用和數據的損壞。但是，如果計算機的硬碟損壞，將會導致數據丟失，此時必須用備份恢復數據。

災難恢復的最重要步驟是設計充足頻率的硬碟備份過程。備份過程應該滿足系統要求的可恢復性。例如，如果資料庫可有較長的關機時間，則可以每周進行一次冷備份，並歸檔重做日誌；但是，如果資料庫只有極少的關機時間，則只能從硬體的角度來考慮備份與恢復的問題，例如使用硬碟鏡像或雙機系統。選擇備份策略的依據是：丟是數據的代價與確保數據不丟失的代價之比。

果每天都能備份當然會很理想，但要考慮其現實性。企業都在想辦法降低維護成本，現實的方案才可能被採用。只要仔細計劃，並想辦法達到資料庫可用性的底線，花少量的錢進行成功的備份與恢復也是可能的。

DBA 還應以服務協議的形式制訂一個可恢復性與可用性的標准文件。該文件應成為討論DBA 服務，以及服務是否能達到預期標準的依據。這樣做可使所有相關人員對同樣的預期有潛在的危機感。

測試備份與恢復策略的重要性
備份與恢復策略必須經測試無誤後才可使用。如果進行了備份，但不知道該備份是否支持希望的恢復目標則與根本沒有備份沒有兩樣。

恢復策略也要考慮慮對環境的依賴性。例如，假如機器的硬碟失效了，供貨商能在多長時間內提供一個新的硬碟；在機器需要重新啟動時，能找到操作系統管理員嗎？

另外一個需要考慮的問題是資料庫是否能經受自然的破壞。應在與計算機不同的地方再存儲一份備份介質，以免出現自然災害時主機與備份一起遭到破壞。

最後需要考慮的問題是萬一DBA 出現了問題怎麼辦？後備的DBA能否執行備份策略？他或她能找到支持用的文檔嗎？這些文檔存在嗎？

沒有比花了大精力指定了好的計劃，但沒有測試其有效性而使其付諸東流的了。一個好的計劃還應容納人為錯誤，特別是用於開發的系統。理想的測試計劃應包括以下內容：

一系列的測試例子及其狀態描述；
測試結果是否成功的標准；
解決這些狀態的步驟。
只有在上述情況測試成功的前提下，DBA 才應該考慮把備份

⑹ 常見的3種備份策略是什麼

備份策略指確定需備份的內容、備份時間及備份方式。常見的備份策略有完全備份、增量備份、差異備份三種類型。作以簡單介紹：
1、完全備份(Full Backup)：
每次對數據進行完整的備份。當發生數據丟失的災難情況時，完全備份無需依賴其他信息，即可實現100%數據恢復，其恢復時間最短且操作最方便；
2、增量備份(Incremental Backup)：
只有那些在上次完全備份或者增量備份後被修改了的文件才會被備份。優點是備份數據量小，需要的時間短，缺點是恢復的時候需要依賴之前的備份記錄，出問題的風險較大；
3、差異備份(Differential Backup)：
備份那些自從上次完全備份之後被修改過的文件。因此從差異備份中恢復數據的時間較短，因為只需要兩份數據——最後一次完全備份和最後一次差異備份，缺點是每次備份需要的時間較長。

⑺ 一個完整的數據備份及恢復方案應包括那些

尊敬的用戶您好：
常見的數據備份與恢復方法有以下幾種：
1.數據備份：數據備份(Backup)是指將計算機硬碟上的原始數據（程序）復制到可移動媒體(Removable Media)上，如磁碟、磁帶、光碟等，在出現數據丟失或系統災難時將復制在可移動媒體上的數據恢復到硬碟上，從而保護計算機的系統數據和應用數據。
2.數據恢復：數據恢復(Recover)是數據備份的逆過程，即將備份的數據恢復到硬碟上的操
作。
3.數據歸檔：數據歸檔(Archive)將硬碟數據復制到可移動媒體上，與數據備份不同的是，數據歸檔在完成復制工作後將原始數據從硬碟上刪除，釋放硬碟空間。數據歸檔一般是對與年度或某一項目相關的數據進行操作，在一年結束或某一項目完成時將其相關數據存到可移動媒體上，以備日後查詢和統計，同時釋放寶貴的硬碟空間。
3.歸檔恢復：歸檔恢復(Retrieve)是數據歸檔的逆操作，將歸檔數據寫回到硬碟上。
4.在線備份：在線備份(On-line backup)是指對正在運行的資料庫或應用進行備份，通常對打開的資料庫和應用是禁止備份操作的，然而現在的有些計算機應用系統要求24小時運轉(如銀行的ATM業務)，因此要求數據存儲管理軟體能夠對在線的資料庫和應用進行備份。
5.離線備份：離線備份(Off-line backup)指在資料庫SHUTDOWN或應用關閉後對其數據進行備份，離線
備份通常採用全備份。
6.全備份：全備份(Full backup)是備份策略的一種。執行數據全部備份操作。
7.增量備份：增量備份(Incremental backup)相對全備份而言，是備份策略的一種，只備份上一次備份後數據的改變數。
8.並行技術：並行技術(Parallelism)是指將不同的數據源同時備份/恢復到同一個備份設備/硬碟上。並行技術是考察數據存儲管理軟體性能的一個重要參數，有些廠商的軟體只能支持並行備份，而有的廠商則可以實現並行地備份及恢復；並且，真正有效的並行技術將可以充分利用備份設備的備份速度(帶寬)，實現大數據量有限時間備份。
9.數據克隆：數據克隆(Clone)是實現災難恢復的一種重要手段，通過將原始數據同時備份到兩份可移動媒體上，將其中一份備份數據(Clone)轉移到地理位置不同的辦公室存放，在計算機系統發生重大災難如火災，系統連接的
備份設備和備份數據都被損壞的情況下，將重要數據在另一套系統上恢復，保障業務的正常運行。所有數據存儲管理軟體都提供克隆功能。

中國電信提供最優質的網路通訊服務，老友換新機，網齡抵現金，百兆寬頻免費體驗，超清電視iTV，電信活動可以直接通過營業廳查詢。

⑻ 資料庫備份的方法和策略是怎樣的

不知道你是用的那種資料庫
可能不通的資料庫用的方法有差異吧
一般可以採用增量差異備份
其實呢,要指定符合自己實際的備份策略
不能盲目的意味照搬網上的方法
一般有0級備份,一級增量備份,二級增量備份等
一般周末做個0級備份,星期一至星期三做個二級增量備份,星期四做個1級增量備份周五-周六再做個2級增量備份,網上有很多這樣的說法,現實中這種策略也是比較好的