章XII、データベースのバックアップとリカバリ

概要：
1、バックアップおよび回復の概念理解
のメカニズムSQL Serverのバックアップおよびリカバリ理解するために2を
Oracleのバックアップとリカバリのメカニズムのための3を

コンセプト最初のバックアップとリカバリ

1.1、バックアップデータベース

データバックアップの理由：

　　防ぎ、データの損失問題がある場合（ストレージメディア障害、ユーザー操作するエラー、サーバーの障害、ウイルス、自然災害）は、バックアップから復元することができます

　　これは、データを転送する方法です。（別のサーバーにデータベースをコピーするには、データベースミラーリング、ファイルのアーカイブとディザスタリカバリを設定します）

2.2、データベースを復元

　　データベースを復元システムに障害が発生したときにデータベースを参照し、プロセスの正確な、一貫性のある状態にデータベースを復元するバックアップ・コピーを使用します。
二つのタイプ：メディア・リカバリの
　　　　　非メディア障害の回復の

SQL Serverのバックアップと復旧メカニズムII

2.1リカバリモード

　　属性データベースは、基本的な行動データベースのバックアップを制御し、操作を復元するために、リカバリモードです。

　　リカバリモードでは、バックアップと復元のプログラムの種類を決定します。バックアップの種類は、データベースのバックアップの内容を決定します。

三のリカバリーモード：

単純復旧モード
完全復旧モデル
一括ログ復旧モデル

単純復旧モード

　　このモードは簡単には、トランザクション・ログをバックアップしません、取引の大半を記録します。記録された情報システムのクラッシュ、データベースのバックアップ後にデータの一貫性を保証または復元するだけ。

完全復旧モデル

　　このモードでは、すべての取引の完全な記録であると背中まで、それらをすべてのトランザクションログレコードを保持します

一括ログ復旧モデル

　　（このようなインデックスとバルクロードを作成するなど）、ほとんどのバルク・オペレーション、その他の事項の完全な記録を記録するには、このモードで簡単に。一括ログ復旧モデルは、一般的に完全復旧モデルの大容量の操作に使用パフォーマンスのサプリメントを向上させます。

2.2、バックアップ内容とタイミング

バックアップ

　　ユーザデータベース

　　システムデータベース

バックアップ時間

　　データベース：変更した後のバックアップ

　　ユーザデータベース：定期的なバックアップ

これらの操作の後、すぐにバックアップします。

　　データベースを作成した後、またはバルク・ロード・データの後。
　　インデックスを作成した後。
　　操作のトランザクションログクリーンアップ実行した後。
　　バルクデータ操作を実行した後。

2.3、SQL Serverのバックアップメカニズム

2.3.1、バックアップデバイス

　　SQL Serverは、データベースのバックアップをバックアップデバイスと呼ばれて配置されます。

　　テープまたはディスクにデータベースのバックアップをサポートしています。

バックアップデバイスの種類：

　　永久的なバックアップデバイス：バックアップの前に確立する必要があります。

　　一時的なバックアップデバイス：なし直接物理的なファイルのバックアップデータベースのバックアップ時には、事前に確立。

システムストアドプロシージャを使用してバックアップ・デバイスを作成

、DEVICE_TYPEはデバイスタイプを表し、値は、ディスクとテープであってもよいです。LOGICAL_NAMEは、デバイスの論理名を表します。physical_nameは、デバイスの実際の名前を表します。

sp_addumpdevice 
　　[ @devtype = ] 'device_type' ,
　　[ @logicalname = ] 'logical_name' ,
　　[ @physicalname = ] 'physical_name‘

例：
　　\ Dump1.bak：MYDISKDUMPというディスクバックアップデバイスを作成し、物理名はDです。

　EXEC sp_addumpdevice 'disk', 'mydiskdump', 'D:\dump1.bak'

2.3.2バックアップの種類

1）データベースのバックアップ

　　データベースの完全バックアップ

　　差分データベースのバックアップ

2）ファイルのバックアップ

　　ファイルのバックアップ

　　差分ファイルのバックアップ

3）トランザクションログのバックアップ

（また、完全なダンプと呼ばれる）データベースの完全バックアップ

　　トランザクション・ログ・セクション（あなたが全体のバックアップをリストアできるように）を含むデータベース全体までのフルバックアップ背中、。バックアップが完了代表するデータベースの完全バックアップ。

これは、ベースラインを復元することです
情報のバックアップ・データ・ファイル、データベース・オブジェクトとデータ
活動は、バックアップ、バックアップ中に発生しました
トランザクションログのバックアップはに提出されていません

差分データベースバックアップ（とも呼ばれる差分ダンプ）

最後のフルバックアップ以降に変更されたデータのバックアップ

活動は、バックアップ差分バックアップ中に発生しました

トランザクションログのバックアップはに提出されていません

フルバックアップよりも時間保存

基準点として、前のフルバックアップ（違いが標準になります）。

あなたは差分バックアップを復元する前に、まず最新のフルバックアップ、差分バックアップをリストアしてから、最新のフルバックアップに基づいてそれを復元する必要があります。

ファイルのバックアップ

　　あなたは、それぞれ、データベース内のファイルをバックアップおよびリストアすることができます。使用ファイルのバックアップユーザーは、それによって回復の速度を向上させる、データベースの残りの部分を復元することなく、唯一の破損したファイルを復元することができます

差分ファイルのバックアップ

　　あなたは、ファイルのフルバックアップファイルまたはグループを作成した後、このフルバックアップに基づく差分バックアップのシリーズを作成することができます。

　　最後のバックアップファイルから差分ファイルのバックアップのみキャプチャデータは、以降に変更します。

トランザクションログのバックアップ

　　最後のログバックアップのログ以降のバックアップ

バックアップが完了した後、ログを切り捨てるために、

　　唯一の完全復旧モデルまたは一括ログ復旧モデルのトランザクションログのバックアップ

トランザクションログのバックアップの三種類：

　　バックアップ純粋な、バルクログのバックアップ、ログバックアップの終了をログに記録します。

2.3.3、一般的に使用されるバックアップ戦略

フルバックアップ
フルバックアップ+ログのバックアップ
フルバックアップ+差分バックアップ+ログのバックアップ

フルバックアップ
　、データベース内のデータのためにはあまり大きくないが、データは、状況は非常に頻繁に変化はありません。

　フル・バックアップは、一般的におき、数日または数週間後に行うことができます。

　回数は、データベースのデータを変更する非常に頻繁ではないですが、また許容データ損失の一定額とき、あなただけの完全なバックアップ戦略を選択することができます。

　バックアップデータとログを含むフルバックアップ、。

フル・バックアップの例

　　火曜日夜11時00システム上でその失敗を想定し、データベースは0:00月曜日の夜の状態に復元することができます。

　　フルバックアップ戦略を使用して、あなたはまた、（1台のサーバー上でバックアップ用とし、別のサーバー上でそれを復元する）別のサーバーに1台のサーバー上のデータベースをコピーすることができ、データベースは、両方のサーバで同一です。

フルバックアップ+ログのバックアップ

　あまりにも多くのデータが欠落していないが、多くの場合、（時間が比較的長いので、フルバックアップ）フルバックアップを実行したくない場合は、フルバックアップの途中でいくつかのログバックアップを追加することができます。

　例えば、午前0:00に毎日数時間ごとに一度フルバックアップとログバックアップ。

+ログのフルバックアップの典型的な

フルバックアップ+差分バックアップ+ログのバックアップ

　フルバックアップの途中でいくつかの差分バックアップを追加し、フルバックアップと差分バックアップとログバックアップ戦略は、真ん中の差分バックアップは、いくつかのログバックアップを追加します。

　例えば0:00日曜日に、毎週のフルバックアップ、午前0時00分、その後、毎日差分バックアップ一度、および2つの差分バックアップの間にいくつかのログのバックアップを追加します。

　この戦略の利点は、より速い速度よりもそのバックアップとリカバリであり、システムが故障したときに、失われたデータは比較的小さいです。

+ +完全な差分ログバックアップの例

2.3.4、バックアップ

使用SQL Serverの管理プラットフォーム
T-SQLステートメントを使用して

実施例1
　DUI「学生」データベース管理は、（バックアップ・デバイスが作成されると仮定して）バックアップ装置MyBK_1にフルバックアップ、バックアップを行いました。

  BACKUP DATABASE students 
   TO MyBK_1

例2

　「パブ」データベースは、バックアップデバイスMyBK_1にフルバックアップ、バックアップを行い、バックアップデバイス上の既存のコンテンツを上書きするために。

  BACKUP DATABASE pubs 
   TO  MyBK_1 WITH INIT

例3

　トランザクションログのバックアップを行うための「パブ」の場合、および追加の背面とMyBKLog1バックアップデバイスまで。

 　BACKUP LOG pubs TO MyBKLog1

2.3.4、SQL Serverの回復メカニズム

SQL Serverのサポート（復元）以下のレベルでのデータ復旧：

　　データベース（完全なデータベースのリストア）

　　データファイル（ファイルの復元）

秩序を回復

最新のフルバックアップを復元します。
最新の差分バックアップ（もしあれば）を復元し、
　　自己の差分バックアップの後（順序に従ってバックアップ）すべてのログのバックアップを復元します。
データベースを復元します。

削減を達成

使用SQL Serverの管理プラットフォーム

使用T-SQLステートメント

例では、
　pubsデータベースに対して完全バックアップとバックアップデバイスMyBK_1へのバックアップであることを前提とし、バックアップ装置はpubsデータベースの唯一のフルバックアップを含むと仮定する。そして、pubsデータベースステートメントを復元することです：

 　RESTORE DATABASE pubs 
 　FROM MyBK_1

RESTORE DATABASE Students 

 FROM MyBK_2 

  WITH FILE=1,  

RESTORE DATABASE Students 

  FROM MyBK_2 

  WITH FILE=2, NORECOVERY 

RESTORE LOG Students 

  FROM MyBKLog1

第III章Oracleのバックアップとリカバリのメカニズム

1、Oracleデータベースの論理バックアップとリカバリ

Oracleデータベースの障害の一般的なタイプ：

自動回復プロセスのための内部メカニズム：

SQL文のエラー

プロセスが失敗しました

失敗の例

ネットワーク障害

バックアップデータの復元の使用：

ユーザー・エラー

メディア障害

論理バックアップ：

　　これは、ファイルシステムに格納された特殊または汎用ファイルフォーマットの手段によってデータベースにデータを変換することをいいます。
ツール：

EXP / IMP
EXPDP / IMPDP

2、Oracleデータベースのバックアップと復元物理

物理的なバックアップ：

　　これは、実装の物理的なバックアップ・データ・ファイルを参照します。

物理的なバックアップ管理：

ユーザー管理バックアップ
マネージャ（RMAN）のバックアップを復元
サードパーティ製のバックアップソフトウェア

データベースの回復

二つのプロセス：

バックアップデータからのフルバックアップファイルを見つけ、回復プロセスの完全なファイル：復元します。
回復：変更ログおよびデータファイル、データファイルのリカバリプロセスの増分バックアップは、指定した時点に適用されます。

説明する例

1、（　　）只记录自上次完整数据库备份后发生更改的数据。
答案：差异备份

2、事务日志用于保存（　　）
A．程序运行过程
B．程序的执行结果
C．对数据的更新操作
D．数据操作
答案：C

3、现有SQL Server 2008数据库服务器，其中的一个数据库占用80GB空间，另有一台用于备份的计算机，该机器上有4个大小均为50GB的硬盘分区。若要将此数据库完全备份到该计算机上，则（　　）
A．不能实现，因为每个分区上的空间都不够80GB
B．可以先建立一个备份设备，这个设备分别在4个分区上各占用20GB空间，然后再用此设备备份数据库
C．可以先在每个分区上分别建立一个备份设备，指定每个设备的大小均为20GB，并建立一个包含这4个备份设备的备份媒体集，最后再用此备份媒体集备份数据库
D．可以先在每个分区上分别建立一个不用指定大小的备份设备，然后将数据库同时备份到这4个备份设备上
答案：C

4、在SQL Server 2008中，设某日上午10点对DB1数据库进行了一次完整备份，在上午11点时DB1数据库突然因硬件故障造成部分数据损坏，但该数据库的日志文件没有遭到破坏。为了尽可能减少数据丢失，下列操作中最可行的是（　　）
A．首先对DB1进行一次完整备份，然后再恢复数据库
B．首先对DB1进行一次差异备份，然后再恢复数据库
C．首先对DB1进行一次结尾日志备份，然后再恢复数据库
D．首先清空日志文件内容，然后再恢复数据库
答案：C

5、在SQL Server 2008中，master是一个非常重要的系统数据库，如果master损坏将会对系统造成严重后果，因此系统管理员应该对master进行备份。SQL Server 2008对数据库提供的备份有（　　）
Ⅰ.完全备份　　Ⅱ.差异备份　　Ⅲ.日志备份
A．仅Ⅰ            B．仅Ⅰ和Ⅲ
C．仅Ⅰ和Ⅱ          D．全部
答案：C

6、下列关于日志备份的说法中，错误的是（　　）
A．日志备份仅备份日志，不备份数据
B．日志备份的执行效率通常比差异备份和完整备份高
C．第一次对数据库进行的备份可以是日志备份
D．日志备份的时间间隔通常比差异备份短
答案：C

7、某网上商城因为业务发展，原有的系统不能很好的满足需要，因此采用了一套新的经营管理系统，此系统使用SQL Server 2008数据库管理系统。此系统上线运行前，需将商场原有的数据导入到新系统中。原有系统使用SQL Server 2000，数据结构与新系统不完全一致。因此需要把数据从SQL Server 2000导入到SQL 
Server 2008中，为了保证数据一致性，数据导入过程中要求暂停业务且必须在3小时内完成。
（1）在原有数据导入新系统的过程中，实施人员发现原有数据量很大，导入数据需要四小时，业务无法接受。经分析某工程师认为，数据导入过程中的数据库I/O很高，但导入数据的程序本身对系统资源占用率很低。该工程师建议将数据导入过程中的数据恢复模式从"完整"模式改为"简单"模式以提高数据导入速度；而另一位工程师则认为此方法未必能提高数据导入速度，而且还可能导致数据丢失，不建议使用此方法。
请分析此方法是否能够提高数据导入速度并给出理由，
同时分析此操作的数据丢失风险。（5分）
（2）在成功导入历史数据后，此系统顺利上线运行。在上线运行的第一周，发现数据库服务器的CPU使用率很高，达到近90%，高峰期间达到100%，且系统内存占用率达到90%，但系统I/O很轻。业务人员反应系统操作速度很慢。为了提高系统运行速度。在不修改应用程序的前提下，两位工程师提出了不同的解决办法：
Ⅰ．为服务器增加2颗CPU，缓解CPU使用率很高的问题；
Ⅱ．为服务器增加一倍内存，缓解内存使用率很高的问题。
　　考虑成本，现阶段只能按照一种方案实施。请指出在现有情况下，哪种方案更合理并给出理由。（5分）

【解题思路】
（1）SQL Server 2008的数据恢复模式有三种：
①简单恢复模式，②完整恢复模式，③大容量日志恢复模式。
　　在数据导入过程中，所有的业务都是暂停的，因此可以采用简单恢复模式提高数据导入速度。且只在数据导入的过程中暂时的修改恢复模式，因此数据并不会丢失。
（2）提高数据库性能的方法一般是从外部环境、调整内存分配、调整磁盘I/O、调整竞争资源等几方面着手来改变数据库的参数。SQL Server 2008采用将数据缓冲在内存的方式，因此在数据库系统运行的过程中会占用一定的内存，又因为I/O并不存在问题，说明内存尚满足需求。CPU使用率很高，表明CPU的计算能力不足，应该增加CPU的数量。

【参考答案】
（1）此方法能够提高数据导入速度。
　　原因：此系统I/O很高，修改恢复模式后，系统最大限度减少日志开销，可提高导入速度。
　　由于仅在数据导入过程中修改恢复模式，所以并无数据丢失风险。
（2）第一种方案比较合理。原因：SQL Server 2008采用将数据缓冲在内存的方式，因此内存的使用率比较高是正常情况，且现阶段I/O并不存在问题，表明内存满足需求。此阶段CPU使用率很高，表明CPU计算资源不足，因此增加CPU数量对解决问题有效。