資料庫伺服器的災難恢復一般如何操作

❶ oracle資料庫數據刪除後如何恢復

Oracle DBA神器：PRM災難恢復工具，Schema級別數據恢復。PRM For Oracle Database – schema級別oracle資料庫數據恢復特性 ，PRM即ParnassusData Recovery Manager是企業級別Oracle資料庫災難恢復工具。PRM可以在無備份的情況下恢復被truncated掉的表，也可以恢復無法打開的Oracle資料庫(Alter Database Open失敗)中的數據。 PRM是圖形化增強版的Oracle DUL工具，同時具備很多Oracle DUL不具備的特性

❷ 怎麼恢復mysql資料庫怎麼恢復數據

簡單情況下：進入原來mysql安裝路徑下的data文件夾下，找到相應的庫和ibdata1，進行，就可回復原來的數據。
復雜情況下：
從另一台機上把MySQL資料庫的mysql文件夾拷貝到本地機上，目的是恢復本地機對數據的訪問和操作。經過如下幾種情況的操作。
1. 在本地重裝MySQL（安裝目錄D:\Program Files\MySQL\MySQL Server 5.0），直接把mysql文件夾拷貝至D:\Program Files\MySQL\MySQL Server 5.0\。結果，失敗：資料庫連接錯誤。
2. 卸載後重裝MySQL，將D:\Program Files\MySQL\MySQL Server 5.0\下的數據備份，只把mysql\data文件夾全部內容拷貝到D:\Program Files\MySQL\MySQL Server 5.0\data下。結果，失敗：資料庫連接錯誤。將備份的數據還完覆蓋。結果，失敗，還是連接不上資料庫。
3. 卸載後重裝MySQL，將mysql\data文件夾里的cf1,last文件夾（這兩個是原來MySQL里的資料庫）拷貝進D:\Program Files\MySQL\MySQL Server 5.0\data。連接成功，在Navicat for MySQL里看到資料庫cf1和last，但是不能訪問，因為數據全為零。明白了原來data里以資料庫命名的文件存儲的是資料庫的表結構，不是元數據。下一步，把data文件夾里的ibdata1文件（3.4G大，明顯存儲了元數據）拷貝到D:\Program Files\MySQL\MySQL Server 5.0\data里，代替原來的ibdata1文件。重啟電腦，打開Navicat for MySQL，連接成功，數據可以訪問操作。
至此，操作終於成功。其實當初在那台機上把數據導出來，而不是現在直接把文件夾mysql復制過來會更容易恢復。但那台機已經重裝了系統，也就是說MySQL失效了。

❸ 怎麼修復資料庫 修復資料庫壞塊方法

修復資料庫壞塊
dbv
你也可以用dbv工具看一下你現在其他的數據文件有沒有還有壞塊的
dbv file='yourfilename'
恢復方法：
當Oracle資料庫出現壞塊時，Oracle會在警告日誌文件（alert_SID.log）中記錄壞塊的信息：
ORA-01578: ORACLE data block corrupted (file # 7, block # )
ORA-01110: data file : '/oracle1/oradata/V920/oradata/V816/users01.dbf'
其中，＜AFN＞代表壞塊所在數據文件的絕對文件號，代表壞塊是數據文件上的第幾個數據塊
出現這種情況時，應該首先檢查是否是硬體及操作系統上的故障導致Oracle資料庫出現壞塊。在排除了資料庫以外的原因後，再對發生壞塊的資料庫對象進行處理。
1．確定發生壞塊的資料庫對象
SELECT tablespace_name,
segment_type,
owner,
segment_name
FROM dba_extents
WHERE file_id =
AND between block_id AND block_id+blocks-1;
2．決定修復方法
如果發生壞塊的對象是一個索引，那麼可以直接把索引DROP掉後，再根據表裡的記錄進行重建；
如果發生壞塊的表的記錄可以根據其它表的記錄生成的話，那麼可以直接把這個表DROP掉後重建；
如果有資料庫的備份，則恢復資料庫的方法來進行修復；
如果表裡的記錄沒有其它辦法恢復，那麼壞塊上的記錄就丟失了，只能把表中其它數據壞上的記錄取出來，然後對這個表進行重建。
3．用Oracle提供的DBMS_REPAIR包標記出壞塊
exec DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('','');
4．使用Create table as select命令將表中其它塊上的記錄保存到另一張表上
create table corrupt_table_bak
as
select * from corrupt_table;
5．用DROP TABLE命令刪除有壞塊的表
drop table corrupt_table;
6．用alter table rename命令恢復原來的表
alter table corrupt_table_bak
rename to corrupt_table;
7．如果表上存在索引，則要重建表上的索引
PART2
2014.7.22研究恢復資料庫壞塊：
Oracle調用標准C的系統函數，對數據塊進行讀寫操作，因此，壞塊是有可能由以下幾種原因產生：
硬體的I/O錯誤
操作系統的I/O錯誤或緩沖問題
內存或paging問題
磁碟修復工具
一個數據文件的一部分正在被覆蓋
Oracle試圖訪問一個未被格式化的系統塊失敗
數據文件部分溢出
Oracle或者操作系統的bug
遇到「ORA-01578:ORACLE data block corrupted」錯誤
處理方法：1.rman的recover命令可以在資料庫保持open狀態下只恢復受損的數據塊
2.如果沒有備份，萬不得已之下也可以採用DBMS_REPAIR包的存儲過程將受損壞塊隔離，同時盡可能地挽救部分數據。
rman backup命令也是檢查壞數據塊的好工具 一旦讀取ORA-19566 即可有問題
此時可用backup validate tablespace user觀察詳細的信息，可查看到壞塊數與跟蹤文件
grep『corrupt』/u01/app/oracle/diag/rdbms/br/br/trace/**.trc
恢復數據塊：rman》recover datafile 5 block 203；
批量恢復受損的數據塊：recover corruption list;
數據塊壞塊一號壞塊，需要做：
run{
sql 'alter database datafile 5 offline';
restore datafile 5;
recover datafile 5;
sql'alter database datafile 5 online'
}
使用exp/imp恢復
在這種情況下肯定會造成數據的丟失，在這種情況下應採取將數據導出然後重建表再進行導入的方法，來盡量恢復損壞數據塊中的數據，但是在有壞塊的情況下是不允許導出的，如下命令：Exp test/test file=t.dmp tables=t;
導出命令在執行中會報ORA-01578錯誤，在這錯誤提示中會提示那個文件號的文件以及這個文件中的哪個塊被損壞，如：ORA—01578：ORACLE 數據塊損壞（文件號 4，塊號 35）
針對以上的提示首先查詢那些對象被損壞：
Select tablespace_name,segment_type,owner,segment_name From dba_extents Where file_id=4 and 35 between block_id and block_id+blocks-1;
如果被損壞的塊是索引，通常可以通過索引重建來解決，如果損壞的是數據（segment_type為table），那麼通過設置如下內部事件使得Exp操作跳過壞塊。
Alter session set events=』10231 trace name context forever,level 10』;
然後重新執行導出命令，導出相關的表，然後執行Drop Table命令刪除相關表，之後重建表最後導入數據。
使用DBMS_REPAIR恢復
用DBMS_REPAIR當然也會丟失數據。這里不做詳細的介紹，有興趣的可以查看oracle的在線文
3、使用dbms_repair包進行壞塊處理
1）首先建立repair_table,用於存放dbms_repair.check_object檢測出來的壞塊信息
SQL> declare
2begin
3dbms_repair.admin_tables
4(table_name => 'REPAIR_TABLE',--表名
5table_type => dbms_repair.repair_table,
6action => dbms_repair.create_action,
7tablespace => 'USERS');--用於指定該表存放的表空間
8end;
9/
PL/SQL 過程已成功完成。
SQL> col owner format a10
SQL> col object_name format a20
SQL> col object_type format a20
SQL> select owner, object_name, object_type
2from dba_objects
3where object_name like '%REPAIR_TABLE';
OWNEROBJECT_NAMEOBJECT_TYPE
---------- -------------------- --------------------
SYSREPAIR_TABLETABLE
SYSDBA_REPAIR_TABLEVIEW
Oracle自動創建了一個DBA_REPAIR_TABLE視圖。
2）使用dbms_repair.check_object進行壞塊檢測
SQL> set serveroutput on size 100000;
SQL> declare
2rpr_count int;
3begin
4rpr_count := 0;
5dbms_repair.check_object(
6schema_name => 'SYS',--指定對象模式，也就是對象的所有者
7object_name => 'TEST',--指定對象名，也就是表名
8repair_table_name => 'REPAIR_TABLE',
9corrupt_count => rpr_count);
10dbms_output.put_line('repair block count: '
11||to_char(rpr_count));
12end;
13/
repair block count: 4
PL/SQL 過程已成功完成。
SQL> select object_name, block_id, corrupt_type, marked_corrupt,
2corrupt_description, repair_description
3from repair_table;
OBJECT_NAMEBLOCK_ID CORRUPT_TYPE MARKED_COR
-------------------- ---------- ------------ ----------
CORRUPT_DESCRIPTION
-------------------------------------------------------------------------------
REPAIR_DESCRIPTION
-------------------------------------------------------------------------------
TEST196148 TRUE
mark block software corrupt
TEST206148 TRUE
mark block software corrupt
TEST236148 TRUE
mark block software corrupt
TEST316148 TRUE
mark block software corrupt
通過運行dbms_repair.check_object，將壞塊信息存放到了repair_table表中，其中有個欄位marked_corrupt，用於標識該塊是否被標識為壞塊，當被標識為true時，即該塊被標識為壞塊。其中這一步跟oracle文檔中的描述有點進入，根據oracle文檔，當執行完dbms_repair.check_object時，並不會進行壞塊標識，也就是marked_corrupt列的值應該為false，而只有當執行dbms_repair.fix_corrupt_blocks過程後才會進行壞塊標識。
3）使用dbms_repair.fix_corrupt_blocks進行壞塊標識
SQL> declare
2fix_block_count int;
3begin
4fix_block_count := 0;
5dbms_repair.fix_corrupt_blocks (
6schema_name => 'SYS',
7object_name => 'TEST',
8object_type => dbms_repair.table_object,
9repair_table_name => 'REPAIR_TABLE',
10fix_count => fix_block_count);
11dbms_output.put_line('fix blocks count: ' ||
12to_char(fix_block_count));
13end;
14/
fix blocks count: 0
PL/SQL 過程已成功完成。
我們可以見到到fix blocks count=0，即在上一步進行check_object時已經進行了壞塊標識了，這一步其實可以省略。（不過沒有測試過！）

❹ 災難恢復的虛擬化災難恢復

通過允許虛擬機在物理伺服器之間進行無縫遷移，虛擬化提供了革命性的災難恢復計劃。 在構建一個遠程VMware災難恢復站點之前，有許多問題需要考慮。
清查現有的基礎設施。在徹底理清一個主要數據中心的資產之前，不能對其進行復制。
了解應用程序和它們的依存關系。明確哪些應用程序需要抵抗災難的能力。要考慮到（主站點和備份站點）存儲和網路架構之間任何潛在的差異，確保程序即使在不同的環境下，也能夠按照預期實現把故障轉移到備份站點。
建立恢復點目標（RPO）和恢復時間目標(RTO)。 如果數據每小時復制到第二數據中心，當災難發生時，有可能最多丟失之間59分59秒的數據。如果這樣是可接受的，不會嚴重地影響業務，那麼PTO可以設定為一個小時。
為用戶服務。終端用戶也許不能夠訪問運行維護的所有的伺服器和應用程序。要考慮怎樣替換用戶們的桌面和應用程序，明確他們怎樣進行遠程訪問。 選取數據中心地址。一條可承擔到主數據中心的高速連接是選擇災難恢復中心需要考慮的關鍵的幾個因素之一。
獲取、安裝和准備硬體。
安裝和配置vSphere。
選擇工具。
實施復制。初始化數據的復制將是最大規模的數據傳輸，隨後的對發生改變的塊進行復制將會小很多，但是復制數據的大小會依據應用程序中數據量改變的大小而定。復制的數據的大小也會依據復制的間隔（由RPO決定）而變化。 硬體獨立：基於物理系統的災難恢復解決方案都需要將相同的硬體保留到恢復站點，或必須經過很多復雜耗時的步驟在新的或不同的硬體上重建伺服器操作系統。有時候碰巧恢復伺服器就是同一個硬體模型，但是包含了最新硬碟控制器固件，會導致伺服器鏡像延遲。虛擬化使硬體從操作系統中抽象化，而且使操作系統中使用的設備驅動器統一化，不管是何種底層硬體模型，所有虛擬機都使用一個共同的驅動集。這樣，在新伺服器上安裝伺服器鏡像時就省了很多設備驅動對應的麻煩，大大減少了恢復時間和配置錯誤的風險。
虛擬機磁碟格式文件：虛擬機將其子操作系統、應用、存儲和配置（如IP地址）存放在一個文件里。這個文件——虛擬機磁碟格式（VMDK）或虛擬硬碟（VHD）文件，包含了整個操作系統環境以便能進行簡單的虛擬機裝載和保存。這個文件不僅包含了操作系統鏡像和應用編碼，還描述了虛擬機所需的配置，其中包括虛擬處理器、內存和設備。這個簡單的可移動文件包含了組成伺服器所需的一切信息、伺服器環境描述、實際碼和數據。從虛擬機磁碟文件啟動虛擬機時系統會自動迅速設置所有參數。在災難恢復站點進行恢復會變得很簡單，只需啟動VMHD或VHD。
物理工具到虛擬工具：虛擬機解決方案需要利用管理工具來創建、啟動、停止和保存虛擬機鏡像。為了方便創建虛擬機，有很多工具可以幫助分析物理伺服器和從伺服器創建VMDK或VHD。從物理系統創建的VMDK或VHD文件可以很快地部署到恢復站點。
硬體再利用：恢復站點的虛擬機硬體不必閑置在那裡等著災難發生，它也可以用作開發、測試或其它用途。當發生災難時，關閉用於測試或開發的虛擬機，然後啟動生產虛擬機，這個過程只需幾秒鍾即可完成。 由於用戶對於伺服器虛擬化技術接受程度不斷提高，業界有一種對於所謂的「萬能的高可用策略」的需求。雖然這種做法可以在一定程度上通過集群故障遷移技術實現簡化數據保護的步驟，但並不是所有的數據保護都支持這種做法。
首先，即使當前關於伺服器虛擬化部署最樂觀的預測成為現實，到2016年也仍然有21%的X86平台的關鍵業務（產生收入的高性能事務處理程序）運行在高達75%的沒有使用任何虛擬化技術的物理伺服器上。所以，針對虛擬化和非虛擬化的不同伺服器採用不同的策略是很有必要的。
在採用了 x86 虛擬化技術的工作負載中，一些虛擬機（VMs）和它們對應的數據盤（表現為VMDK 和 VHD 文件）相比其他虛機和數據盤次要一些。在沒有使用虛擬化技術的環境中存在很多不同的虛擬程序，但並不是所有的應用程序都是關鍵業務相關。傳統的伺服器環境中，一些應用程序和虛擬機被頻繁使用，也有一些使用的不是那麼頻繁，這些現實情況都影響著數據備份和數據復制的頻率和策略。

❺ 如何應對內存資料庫的恢復

【Oracle資料庫】內存資料庫的恢復與傳統資料庫的恢復不同，因為你要在一個相當「兇悍的」架構中設計恢復。盡管並不需要頻繁地用到它，但因為使用內存資料庫就是為了追求速度，你還是得對災難恢復進行保險設計。為恢復提速也蘊藏了一個商業價值。我之前從事過這樣的一項工作：早上收報告，而後得等到第二天才會更新。如果我們一天能收到五到十次的更新，那就能很好地管理公司的年鑒了。
對於內存資料庫來說，應該確保盡可能少的寫入佔用永久存儲。提供直接的光纖通道埠，同時確保SSD或PCIe快閃記憶體卡的最佳狀態用以保證低延遲。保證重要的性能冗餘且將網路交換機數量降到最低。
大多數內存資料庫都是預先設置好的設備。它包含一些動態的RAM容量，可能還會帶些快閃記憶體，同時，方方面面通過軟體被安排地頭頭是道。當你使用一台預先設計好的設備時，先在欠載的情況下測試它。測試它的吞吐量及在一年中最壞情況下的災難恢復。然後告訴大夥兒災難恢復的時間並確認該速度用於企業業務已是富富有餘。你不希望最終結果或者一些關鍵性業務它無法正常恢復。你在內存資料庫上花了大把的錢，並對其寄予厚望。
在如何恢復和放置數據方面，SAPHANA和其他的內存資料庫變得越來越智能，它們對吞吐量進行優化並盡可能地為恢復提速。它們能夠避免讓系統宕機。最壞的情況就是I/O失效讓整個內存系統出現故障。採用捷徑帶來了沖擊，沒有仔細思考如何優化恢復速度結果造成了運行中斷。

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

尊敬的用戶您好：
常見的數據備份與恢復方法有以下幾種：
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，電信活動可以直接通過營業廳查詢。