29 「夜もよか～!! オラクル勉強会 presented by アシスト ......2015/11/18 · 29...

<Insert Picture Here>

Copyright© 2014, Oracle. & K.K.Ashisuto All rights reserved.

アシスト

1

第29回「夜もよか～!! オラクル勉強会 presented by アシスト」

Oracle Database ・完璧バックアップ・リカバリ

2015年11月18日

アシスト

Copyright© 2014, Oracle. & K.K.Ashisuto All rights reserved. 2 2


Agenda

• バックアップ・リカバリとは

• バックアップ・リカバリ方法の整理

• バックアップ運用Tips

• Enterprise Manager を利用したバックアップ・リカバリ

Database

Backup

Database

アシスト



Agenda





Database

Backup

Database

アシスト


バックアップ・リカバリとは

リストア、リカバリって

何が違うの？

どんなファイルをバックアップ

する必要があるの？

リカバリの

仕組みは？

• そもそもバックアップ・リカバリって・・・？

• バックアップ・リカバリの用語の整理

• データベース内の処理の流れの整理

• 障害がおきないようにするための対策

バックアップ以外に

できる対策はあるの？

アシスト


バックアップとは

• バックアップとは

• データをコピーしておき、別の場所に保存しておくこと

• バックアップの目的

• データが壊れたり損失した場合に、複製したデータを元に戻すことで

復旧すること

• 過去のデータを別の場所に保存しておくこと

• バックアップの重要性

• 企業活動に必要な情報資産の消失を防ぐ最良の手段

• 様々な障害を想定して対策をとる必要

OSレベル、H/Wレベルの障害は防ぎきれない

アプリケーションのエラーで論理的に壊れることもある

ディスクのミラーリング機能を使っても、ミラーごと壊れる

可能性もある

アシスト


リカバリとは

• リカバリとは

• データ損失時にバックアップを使って復旧すること

• データ・リカバリ要件に即した計画の検討

• リカバリ用件の明確化

障害からの復旧にどれだけの時間をかけられるのか？

どの時点のデータに復旧すればよいのか？

全てのデータをもれなく復旧する必要があるか？

• リカバリ計画の検討

障害発生時、どのような手順で復旧することができるか

復旧するまでにどれくらいの時間がかかるか

リカバリ手順の検証

アシスト


データ復旧までの主な流れ

破損したファイルの代わりに

バックアップファイルを定位置に戻す

リストア

時間

9/8

9/15

Database Backup

Databaseを構成するファイルのコピーを保存しておく

バックアップ

バックアップ時点から後に

行われた変更ログを反映

リカバリ

データベースの復旧

＝リストア＋リカバリ

アシスト

Copyright© 2014, Oracle. & K.K.Ashisuto All rights reserved. 8

バックアップと障害復旧

UPDATE

INSERT

DELETE

データファイルの

バックアップを取得

データファイル

バックアップ

更新内容がREDO

ログに記録される

時間

アシスト


UPDATE

INSERT

DELETE

UPDATE

INSERT

DELETE

UPDATE

INSERT

DELETE

バックアップ取得後にも

データベースは更新される

更新内容がREDOログに記録される


UPDATE

INSERT

DELETE

時間


バックアップ

データファイルのバックアップには、

バックアップ以後の更新内容は含まれていない

データファイルに

障害発生

アシスト


障害が発生したデータファイルを

バックアップから書き戻す（リストア）


リストア


UPDATE

INSERT

DELETE

UPDATE

INSERT

DELETE

UPDATE

INSERT

DELETE

時間

更新履歴

（REDOログ）

UPDATE

INSERT

DELETE

時間


障害発生


バックアップ

アシスト


障害直前の状態にリカバリ完了


UPDATE

INSERT

DELETE

UPDATE

INSERT

DELETE

UPDATE

INSERT

DELETE

時間

更新履歴

（REDOログ）

UPDATE

INSERT

DELETE

時間


障害発生

リカバリ

REDOログに記録された更新履歴を再現データファイル


バックアップ

リストア

アシスト


データファイルのリカバリ


オンラインREDOログファイル

制御ファイル

DBWn

CKPT

LGWR


チェックポイント状態


更新履歴

リカバリ

Oracleインスタンス

アーカイブREDOログファイル

ARCn

オンラインREDOログと制御ファイルが障害直前の情報を保持

データファイルを

障害発生直前までの状態に復旧可能

アシスト


データベース内の処理の流れの整理

Oracle Server

クライアント

ユーザー

プロセス

A

サーバー

プロセス

変更履歴

A→B

データベース・バッファ・キャッシュ

REDOログ・バッファ

SELECT A

FROM 表１

UPDATE 表１

A→B

データ・ファイル

・ユーザーが利用するデータ

・情報管理用のデータ（ディクショナリ）

データ

ディクショナリ

データ・ファイル制御ファイルファイル REDOログ・

A B

13

アシスト


データベース内の処理の流れの整理処理が確定（COMMIT）した場合

Oracle Server

クライアント

ユーザー

プロセス

データ・ファイル制御ファイルファイル

A

サーバー

プロセス

A→B

ログ

ライター



COMMIT

A 変更履歴

A→B B

REDOログ・ファイル

・データベースで行われた変更

履歴（DML,DDL処理）を格納

・障害からの復旧に使用




REDOログ・

14

アシスト


データベース内の処理の流れの整理チェックポイントが発生した場合

Oracle Server

クライアント

ユーザー

プロセス

データ・ファイル制御ファイルファイル

A

サーバー

プロセス

A→B

ログ

ライター



チェック

ポイント

B

DB

ライター

A

A 変更履歴

A→B B

制御ファイル

・メモリ上の変更をいつファイルに

反映したか（チェックポイント）

・他の物理ファイルの場所

REDOログ・ファイル

・データベースで行われた変更

履歴（DML,DDL処理）を格納

・障害からの復旧に使用




REDOログ・

15

アシスト


障害がおきないようにするための対策

• ファイルごとの障害対策

• 制御ファイル

• 多重化が推奨

（一つでも壊れるとデータベースは停止）

• 各ファイルを異なるディスクに配置

• REDOログ・ファイル

• 多重化が推奨

（一つでも正常なファイルがあれば

データベースは運用可能）

• 各ファイルを異なるディスクに配置

• データ・ファイル

• 定期的なバックアップの取得

• 変更ログ（REDOログ情報）の保存

制御

ファイル

REDOログ

ファイル

制御

ファイル

REDOログ

ファイル

バックアップ

アーカイブ

ログ

ファイル

2つのディスクを使った配置例

多重化したファイルは

別ディスクに配置

データ・ファバックアップは

別ディスクに配置


アシスト



Agenda

• バックアップリカバリとは



• Enterprise Manager を利用したバックアップ / リカバリ

Database

Backup

Database

アシスト


バックアップ・リカバリ方法の整理

バックアップするには

データベースを停止する

必要があるの？

どんなタイプの

障害があるの？

障害直前まで

復旧できるの？

事前の設定は

必要なの？

• バックアップ・リカバリ、その前に・・・

• 発生しうる障害のタイプ

• 障害からの復旧に必要な設定

• 代表的なバックアップ方法

• 代表的なリカバリ方法

アシスト


クライアント

UPDATE 表A

A→B；

COMMIT；

ユーザー

プロセス

Oracle Server

データ・ファイル制御ファイル REDOログ・

ファイル

A

サーバー

プロセス

A A→B

COMMIT B

DBバッファ・キャッシュ REDOログ・バッファ

A→B

COMMIT

LGWR

発生し得る障害のタイプインスタンス障害

• 原因:停電、プロセス障害などにより、データベースが異常終了

• 問題:メモリ上の変更がファイルに反映されていない可能性（不整合）

• 解決法:データベースの再起動

19

アシスト


発生し得る障害のタイプメディア障害

Oracle Server

データ・ファイル制御ファイル REDOログ・

ファイル

A A→B

COMMIT B

DBバッファ・キャッシュ REDOログ・バッファ

A→B

COMMIT

LGWR

A

バックアップ

リストア

A A

リカバリ

B

• 原因:データベースを構成するファイルの損失、破損

• 問題:データベースの停止、または特定のデータへのアクセス・エラー

（破損したファイルのタイプによって異なる）

• 解決法：バックアップからリストア＋リカバリ

20

アシスト


障害発生時の出力例

SQL> select * from emp;

select * from emp

*

行1でエラーが発生しました。:

ORA-01578:

Oracleデータ・ブロックに障害が発生しました(ファイル番号4、ブロック番号27)

ORA-01110: データファイル4:

'/u01/app/oracle/oradata/orcl/users01.dbf'

※ブロック破損時の例

アシスト


１

22

２

メディア障害からのリカバリに必要な設定

循環してREDOログを

上書き REDOログファイル

１

２

３

ノー・アーカイブ･ログモード

循環して

上書き

REDOログファイル

１

３

アーカイブ・ REDOログファイル

アーカイブ･ログモード

循環して

上書き

４

ログ順序番号

４

53 ５

２

REDOログを

上書き前に

アーカイブする

３

• 障害直前の状態まで復旧するためにはREDOログ情報が必要

• ARCHIVE LOG モード＝障害直前までの復旧が可能（リカバリ）

• NO ARCHIVE LOG モード（デフォルト）

＝バックアップを取得した時点までしか復旧できない（リストア）

アシスト


• アーカイブログモードが適している場合

• データを失うことが許されない

• 過去のある時点へ戻すようなリカバリが必要となる可能性がある

• データベースを停止することが出来ない（オンラインバックアップ）

• ノーアーカイブログモードでも問題ない場合

• データを失っても構わない

• データを失ってもアーカイブ適用以外の手段で復旧可能

データベース運用モード選択のポイント

アシスト


アーカイブ・ログの設定アーカイブ・ログの有効化とログの出力先の設定

24

アーカイブ・ログの設定

ARCHIVE LOGモードの有効化と

ログの出力先（最大10か所）指定可能

アシスト


Oracle Databaseのデータのバックアップ

• 論理バックアップ

• データのみを抽出し、障害時にデータを再ロードする方法

• Data Pumpユーティリティ

• 物理バックアップ

• ユーザー管理バックアップ

• OSコマンド＋SQLコマンド

• Recovery Manager （RMAN）

• Oracleインスタンスの仕組みでファイルにアクセス

アシスト


• オフライン（一貫性）バックアップ

• データベースを正常に停止した状態でバックアップを取得

• すべてのファイルをリストアした場合、リストア直後に

データベースをオープンできる

• オンライン（非一貫性）バックアップ

• データベースを運用しながら（停止せずに）バックアップを取得

• リストア後にリカバリ操作をする必要がある

• ARCHIVE LOG MODE運用時のみ

代表的なバックアップ方法オンライン・バックアップオフライン・バックアップ

Backup

Backup

アシスト


• NO ARCHIVE LOGモードの場合

• バックアップ時点までのリカバリ

• ARCHIVE LOG モードの場合

• 完全リカバリ

• すべての変更履歴を適用し、障害直前の状態まで復旧

• 不完全リカバリ

• 途中までの変更履歴を適用し、最新の状態まで戻さない状態で復旧

• アーカイブ・ログ・ファイルやREDOログ・ファイルに障害があり、

ログの適用ができない場合

• 誤操作を取り消すために、データベース全体を過去の状態に

戻したいとき

代表的なリカバリ方法ログ・モードによるリカバリ方法の違い

27

アシスト


ノー・アーカイブ・ログモードでの復旧作業

バックアップ

本番DB

②データファイルリストア

①障害発生

障害発生時までの全ての更新履歴情報がないので、バックアップ時点のデータまでしかリカバリできない

DataFile

REDO

9月8日 9月15日

アシスト


アーカイブ・ログモードでの復旧作業（完全リカバリ）

③アーカイブ適用


④REDOログファイル適用

①障害発生

障害直前の状態まで復旧可能

DataFile Arch1 Arch2 Arch3 Arch4 Arch5

REDO

バックアップ

本番DB

9月8日 9月15日

アシスト


アーカイブ・ログモードでの復旧作業（不完全リカバリ）

③アーカイブ適用


①障害発生

途中までの変更履歴を適用し、

最新の状態には戻さない状態で復旧

DataFile Arch1 Arch2 Arch3 Arch4 Arch5

REDO

バックアップ

本番DB

9月8日 9月15日

アシスト



Agenda




• Enterprise Manager を利用したバックアップ / リカバリ

Database

Backup

Database

アシスト


• バックアップのスケジュールは？

• どのようなタイプのバックアップを取るか？

• どこにバックアップデータを保存するのか？

• 保存ポリシーはどのように設定しますか？

バックアップ運用Tips

どのようなバックアップ

スケジュールがいいの？

どんな場合に、

どんなバックアップ方法が

最適なの？

バックアップはいつまで

保存しておく必要が

あるの？

アシスト


バックアップ取得のタイミング

リカバリを

単純化!!

• 定期バックアップ：業務的な要求により事前に決定 • 日次バックアップ

• 週次バックアップ

• 月次バックアップ

• メンテナンス作業前 • 大規模なバッチ処理の前後

• バージョンアップ/パッチの適用

• データベースの構造が変わった場合には必ず取得 • 表領域やデータ・ファイルの追加

• REDOログ、制御ファイルの構成変更（多重化など）

• アーカイブ・ログ・モード変更時

アシスト


システム要件・リカバリ要件

• 障害発生時にどのくらいの時間でリカバリが必要か

• 障害発生後のリカバリでどこまで戻す必要があるか

• 普段、システムを止められる時期があるか

• 普段、システム負荷の低い時間帯はあるか・・・

定期的なバックアップ計画について

どのくらいの頻度で

バックアップを取得していくか？

バックアップ対象

バックアップモード

DB運用モード

バックアップ事前設定バックアップのスケジュール

…

アシスト


バックアップのスケジュール定期バックアップ頻度の決定

Arch1 Arch2 REDO Arch3 Arch20 Arch21


1週間前

2日前

バックアップ

バックアップバックアップ

3日前 1日前

バックアップ

・・・・・・

高頻度な全体バックアップバックアップ負荷は高いが、リカバリ時間が短い

システム負荷は低いが、リカバリ時間が長い低頻度な全体バックアップ

アシスト


バックアップタイプ増分バックアップタイプ

～増分バックアップのメリット～

• バックアップ・ファイルのサイズの削減が可能


2日前


3日前 1日前

バックアップ

全体バックアップ

増分バックアップ


2日前

バックアップ


3日前 1日前


アシスト


データベースのファイル群

Change Tracking File （データブロック単位で追

跡）

データベースファイル全体を読み込んで変更された領域のみをバックアップ

・・・・・・・・・・・・・・・・

バックアップ・ファイルサイズの縮小

バックアップ時間短縮→それほど効果はありませんでした


アシスト


データベースのファイル群

変更があった領域のみを読み込んでバックアップ

・・・・・・・・・・・・・・・・

チェンジ・トラッキング・ファイル（データブロック単位で追跡）

バックアップ時間も

大幅に短縮 !!

Oracle Database10g以降 : 高速増分バックアップ

アシスト


100 200 300 400 500 600

0

5

10

15

20

25

30

35

40

45

50

時間（分）

更新量（MB）

高速増分バックアップ

全体バックアップ

Oracle Database10g以降：高速増分バックアップ

18分の1!

※数値は検証結果に任意の定数を掛けたものです

アシスト


バックアップ取得方法の詳細設定定期バックアップの効率化のための設定

40

増分バックアップ・前回のバックアップアップ以降に変更されたブロックのみをバックアップ対象とすることで、サイズを小さくできる・「ブロック変更トラッキングを有効化」にチェックをすることで、バックアップ時間の短縮が可能

日月火水

アシスト


バックアップデータの保存先

• テープ • 長所：・データ容量が大きい・メディアの容量当たりの単価が安い

• 短所：・ディスクに比べると低速・定期的なクリーニングが必要

・追加の設定作業が発生

• ハードディスク • 長所：・高速なバックアップ・劣化が少ない

• 短所：・可搬性の点が低い

フラッシュ・リカバリ領域（10g以降）

• バックアップ関連ファイルを置くための領域

• フラッシュ・リカバリ領域に保存されたバックアップは、必要に応じて

自動的に削除(上書き)される

アシスト


バックアップの取得場所

バックアップ取得場所の指定

デフォルトはフラッシュ・リカバリ領域

アシスト


フラッシュ・リカバリ領域の設定バックアップ関連のファイルのデフォルト格納先の設定

43

フラッシュ・リカバリ領域

バックアップ関連ファイルを置く

ための領域（10g）

（バックアップ・アーカイブなど）

場所とサイズを指定

アシスト


バックアップの保存方針の設定保存方針設定例


2世代


3世代 1世代

バックアップ

• バックアップの保存方針 • 例）2世代保存の場合

削除可能

9/1 9/3

•保存期間を過ぎたバックアップは、一括削除可能

•フラッシュリカバリ領域に保存した場合は、保存期間を過ぎたものは領域不足時に自動的に上書きされる

9/2

アシスト


保存ポリシーの設定

45

保存ポリシーバックアップの保存期間を設定し、期間を過ぎたものは一括削除することも可能

アーカイブ・ログ・ファイルアーカイブ・ログ・ファイル

１世代２世代

今日１日前 2日前 3日前 4日前

アシスト


ホット・バックアップはなぜ難しい？

• ファイルサーバー

• ファイル単位で置き換わる

• データベース

• ファイルが部分的に、かつ頻繁に更新される

ファイルのコピー中にも、コピー元のファイル内容が更新される

考慮点が増えるかわりに、DBMSは障害直前（バックアップ時刻より未来）の状態までリカバリする仕組みがある

アシスト


時間

ファイルコピー開始ファイルコピー終了

A A A A

A

コピー元ファイル

バックアップファイル

（コピー先）

コピーはファイルの先頭から

A

A A

B B

コピー後にもブロックが

更新される

？

B

B

A A B

A A ？

A B 1ブロック内の前半と後半が

異なる可能性がある

B

ファイル更新

更新され続けるファイルのコピーホットバックアップはなぜ難しい？

アシスト


ホット・バックアップ

• ファイルのバックアップ（コピー）中にも、ファイルの内容が書き換えられる

• DBMSは専用のホットバックアップツールが付属している

• DBMSがファイルにアクセスする仕組みを使ってバックアップ

• Oracle Database はRecovery Manager (RMAN)

• Oracle Databaseは特殊な機能を備えている

• OSのファイル・コピー・コマンドでホット・バックアップ可能

• ホット・バックアップ・モード（ユーザー管理バックアップ）

• よく BEGIN BACKUP / END BACKUP と呼ばれているもの

アシスト


ユーザー管理バックアップとRMAN

Oracle

インスタンス

OS

RMAN

oracle


（コピー元）


（コピー先）

oracle

Oracleサーバー・プロセス

dd

OS


（コピー元）


（コピー先）

OSのファイルコピー・プロセス

Recovery Manager ユーザー管理バックアップ

Oracleインスタンスの仕組みを使ってファイルを読む

Oracleインスタンスが関知しない

（ホット・バックアップ・モード使用）

アシスト


データベースのホット・バックアップ

• 制御ファイル • OSファイル・コピー・コマンド不可

• Oracleインスタンスでのスナップショット生成

• または制御ファイル再作成スクリプトの生成

• オンラインREDOログファイル • OSファイル・コピー・コマンド不可

• アーカイブREDOログファイルをバックアップ

• データファイル • ホット･バックアップ･モード

• RMAN

つまり、RMANでもユーザー管理バックアップでも、Oracle

インスタンスを経由しなければならない。

Oracleインスタンスが生成し

たファイルをコピー（バックアップ）する。

Oracleインスタンス管轄外で取得できる

ホット・バックアップはデータファイルのみ

アシスト


制御ファイルのバックアップユーザー管理バックアップ

SQL> ALTER DATABASE BACKUP CONTROLFILE TO バックアップファイル名

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE

方法1. 制御ファイルのバイナリ・スナップショットの取得

方法2. 現在のデータベース構成に合わせたCREATE CONTROLFILE文の生成

生成されたトレースファイル名がアラートファイルに記録される

Sun Apr 27 20:02:36 2008

ALTER DATABASE BACKUP CONTROLFILE TO TRACE

Backup controlfile written to trace file

/u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_2115.trc

Completed: ALTER DATABASE BACKUP CONTROLFILE TO TRACE

・・・

STARTUP NOMOUNT

CREATE CONTROLFILE REUSE ・・・

トレースファイルの内容はCREATE CONTROLFILE文とリカバリ手順

アシスト


REDOログのバックアップ

LGWR ログライター

プロセス

オンラインREDOログ・ファイル

CURRENT

固定長、個定数のファイルに循環書き込み

･･･

アーカイブREDOログ・ファイル

･･･

LGWR

CURRENT

ARCn

アーカイバプロセス

CURRENTが1つ進む

現在の（CURRENT）オンラインREDOログ・データを今すぐアーカイブにコピーしたい場合

ALTER SYSTEM ARCHIVE LOG CURRENT

アシスト


データファイルをコピー

ホット・バックアップ･モードデータファイルのユーザー管理バックアップ

時間

データブロック REDOログ

更新が発生した行のみREDOに記録

通常モード

※Oracle Database 10g Release 1からは ALTER DATABASE BEGIN BACKUP

によってデータベース全体（すべてのデータファイル）をホット･バックアップ･モードにすることも可能になっている。ストレージ機能を想定しての機能拡張。

該当表領域のデータファイル・ヘッダを通常モードに移行

ALTER TABLESPACE 表領域名 END BACKUP データブロック REDOログ

データブロック全体をREDOに記録

ホット・バックアップ・モード

該当表領域のデータブロックを書き戻す（チェックポイント）

該当データファイル・ヘッダのチェックポイントSCNを固定

ALTER TABLESPACE 表領域名 BEGIN BACKUP

バックアップされたデータファイル

のチェックポイントSCN

アシスト


スプリット・ミラーとスナップショットストレージ機能で過去イメージを取得する

ミラー

最新イメージ

最新イメージ過去イメージ

ミラー解除

スプリット・ミラースナップショット

最新イメージ

最新イメージ過去イメージ

スナップショット取得

通常運用時通常運用時

アシスト


ストレージ機能が分割する要素データファイルとストレージの間の層も考える

論理ボリューム

ファイルシステム

表／索引

表領域


スプリット・ミラー/スナップショットは

ストレージ・ボリューム（LU）を分割する

Oracleのホット･バックアップ･モードはデ

ータファイルのスナップショットを可能にする

ストレージ上にある論理ボリュームとファイルシステムも分割される

論理ボリューム・マネージャ・ソフトウェアやファイルシステム上にデータベースを構成している場合、安全を見てコールド・バックアップで運用されることが多い。

⇒ ファイルシステム/論理ボリュームもオフラインにしていることが多い（かもしれない）

アシスト


ファイル構造

Oracle構造

従来のディスク管理

Automatic Storage Management

• Oracleデータベース専用のボリューム・マネージャ兼ファイルシステムとして機能する

• ストレージ機能を使用したホット・バックアップ可能



表／索引

表領域


ASM

ASMのディスク管理

表／索引

表領域




各ストレージ・ベンダーとのベスト・プラクティスを公開

http://www.oracle.com/technology/global/jp/products/database/asm/index.html

http://www.oracle.com/technology/products/database/asm/index.html

アシスト


ストレージ機能でホット・バックアップユーザー管理バックアップでI/O無停止バックアップ

時間

BEGIN BACKUP

END BACKUP

ホットバックアップモード

ファイルコピーコマンドでホットバックアップ

バックアップ

時間

BEGIN BACKUP

END BACKUP

ホットバックアップモード

バックアップ

データベース本体のファイルとは無関係に、ミラーやスナップショットからデータファイルのバックアップを取得

ストレージ機能でホットバックアップ

スプリット / スナップショット

アシスト


バックアップ / リストアの単位ストレージ機能が分割する単位を考える

• RMAN / ユーザー管理バックアップ

• ファイル単位でバックアップすることを暗黙的に想定

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

データベースミラー/スナップショット

• ストレージ機能でのバックアップ • ストレージ・ボリューム単位

• 再同期もストレージ・ボリューム単位

アシスト


リカバリ不能になるケース

ストレージ機能で

コールド・バックアップ

（オンラインREDOかつ、またはアーカイブREDO込み）

時間

時刻 A

REDO （時刻 A）

datafile 1 （時刻 A）


REDO （時刻 A）



リストア（ミラー再同期） REDO （時刻 A）



REDO （時刻 A）



データベースミラー / スナップショット

時刻 B

datafile 1が破損

REDO （時刻 B）

datafile 1 （時刻 B）

datafile 2 （時刻 B）

REDOデータ消失

REDOが格納されているボリュームを上書きするとリカバリ不能に！

データベース稼動中

アシスト


スプリット / スナップショットのグループを分ける REDOを上書きリストアしない

オンラインREDO

制御ファイル

アーカイブREDO


データベースミラー / スナップショット

再同期すると、スプリット後のアーカイブREDOを失う

ファイルとして取り出す

再同期すると、正常ファイルも上書きされる

⇒ リカバリが増える

ファイルとして取り出すことも検討する

アシスト


ストレージ機能を使用したバックアップ

• Oracleはホット・バックアップ・モードがあるため、I/O無停止でバックアップすることも可能

• 更新トランザクションをブロックさせない無停止バックアップ

• Oracleはハイエンド・ストレージの機能を活かせるDBMS

• リストア / リカバリできるようにバックアップ設計を行うこと

• なんでもボリューム再同期が使用できるとは限らない

ASMとの組み合わせの、各ストレージ・ベンダーとのベスト・プラクティスを公開

http://www.oracle.com/technology/global/jp/products/database/asm/index.html

http://www.oracle.com/technology/products/database/asm/index.html

アシスト


バックアップのオフロード Data Guard フィジカル・スタンバイ

SQL発行 SQL結果

REDO転送

プライマリ・データベーススタンバイ・データベース

Oracleクライアント

（アプリケーションサーバー）

リカバリ

フィジカル・スタンバイからバックアップ取得可能

それをプライマリ・データベースにリストア可能

バックアップ

RMAN

プライマリ・データベースに影響を与えずにバックアップを取得する

アシスト


Agenda


• バックアップ/リカバリ基礎知識



Database

Backup

Database

アシスト


Enterprise Managerを使ったバックアップ・リカバリ

• バックアップ・リカバリのための事前設定

• アーカイブ・ログの設定

• バックアップの取得場所の設定

• バックアップ取得方法

• バックアップの保存期間の設定

• バックアップの実行例

• リカバリの実行例

Enterprise Managerで

簡単に操作！

済

アシスト


バックアップの取得 Enterprise Managerからのバックアップ取得

アシスト


バックアップの取得カスタマイズ・バックアップのバックアップ設定画面

バックアップ・モード

オンラインorオフライン

オンラインバックアップはARCHIVE LOGモード

運用時のみ可能

アシスト


バックアップの取得バックアップ取得場所の確認

バックアップ先

バックアップのタイミングで事前設定

アシスト


バックアップの取得バックアップ・スケジュールの設定

スケジュール 1回のみのバックアップもスケジューリング設定も可能

アシスト


バックアップの取得バックアップ取得の確認画面

アシスト


バックアップの取得バックアップ進捗状況の確認画面

進捗状況バックアップがどこまで進んでいるか、確認可能

アシスト


バックアップの取得取得済バックアップの確認画面

取得済みバックアップバックアップファイルのステータス不要なバックアップの削除手動で取得したバックアップの登録

アシスト


データ・リカバリ・アドバイザ復旧のアドバイスを提示

• 障害復旧

1. 障害の診断

2. 復旧手順の検討

3. 復旧操作

• データ・リカバリ・アドバイザ

• 障害の診断を行う

• 復旧手順を構成する

修復に要した時間

障害解析に要した時間

総ダウンタイム

ダウンタイムを最小化

人間が考えている時間

リストア/リカバリの時間

Oracle Database 11g Release 1 から

アシスト


データ・リカバリ・アドバイザ復旧のアドバイスを提示

1. データベースの障害リストを参照

2. 障害に対するアドバイスを取得

3. 自動修復の実行

RMAN> list failure;

RMAN> advise failure;

RMAN> repair failure;

修復スクリプト: d:¥oracle¥diag¥rdbms¥orcl ¥orcl¥hm¥reco_803716847.hm

修復スクリプトの内容:

restore database;

recover database;

alter database open;

修復スクリプトを実行しています

・・・・

メディア・リカバリを開始しています

メディア・リカバリが完了しました。経過時間:

00:00:03

recoverが完了しました(完了時間: 08-12-19)

データベースがオープンしました。

障害の修復が完了しました

1. 障害13595を解決するために、Oracleサポート・サービスに連絡してください: データファイル4:

'D:¥ORACLE¥ORADATA¥ORCL¥USERS01.DBF'は破損しています

2. 意図せずにファイルD:¥ORACLE¥ORADATA¥ORCL¥SYSTEM01.DBFの名前の変更または移動が行われていた場合リストアします

アシスト


データ・リカバリ・アドバイザ Oracle Enterprise Managerからも使用可能

アシスト


障害の検知と復旧障害の検知

データベースが停止した場合起動時にエラーメッセージで通知「リカバリの実行」ボタンからリカバリ

データベースが稼動中である場合「サポート・ワークベンチ」画面に障害情報が出力

アシスト


障害の検知と復旧障害情報の詳細表示

障害の状況と影響が表示障害にあったファイルの名前が表示対応方法のアドバイスを得ることもできる

アシスト


障害の検知と復旧リカバリ・アドバイザによる復旧アドバイス

アシスト


障害の検知と復旧リカバリ完了画面の確認

・・・・

リカバリのログ「リカバリ完了」メッセージを確認

アシスト



まとめ


バックアップ：データのコピー

リカバリ：データの復旧


アーカイブログモード/ノーアーカイブログモード

オンライン/オフラインバックアップ


増分バックアップ：バックアップファイルサイズの削減

ＥＭによるバックアップファイル管理

Enterprise Managerを利用した

バックアップ・リカバリ実行例

アシスト

80


お知らせ

アシスト


Oracleの実績 Oracleのサポート

年間売上約80億円（国内トップクラス）

お取引き企業数 8,000社以上（国内トップクラス）

サポート契約継続率 90%以上

過去3年のサポート切替実績 1,200件以上

【Oracle販売実績】

Oracle Award受賞

[DODAI] Platform Solution Award

【過去受賞歴】

パートナー別販売実績第1位

Excellent Partner受賞（9年連続 9回）

Best Partner賞

Support of The Year賞

Show case of the Year賞

Oracle Real Application Clusters部門

Best Area Performance of the Year賞

Oracle Database 11g Award賞

KUDOS for Oracle Support Partners賞

【ACSP認定】高レベルサポート認定企業

【Oracle受賞歴】

1987年、アシストグループとして株式会社オラクルを設立し、国内で

最初にOracleのライセンス販売、サポートの提供をはじめました。

誠実にお客様の声に耳を傾け、真心を持ってお答えするという姿勢と、

万全のサポート体制でお客様の期待に答え続け、多くのお客様より厚く

ご支持を頂けております。

【歴史】

○ マルチベンダー対応アシストではすべてのＯＳで実機を用意し、構築スキルを蓄え、

検証環境を整えております。

24時間365日、約200名のOracle専属技術者に

よる全国サポート体制 (国内最大級)‏

過去3年（年間平均）の対応状況

サポート件数約10,000件/年

フィールド対応件数約400件/年

顧客満足度約90%

○ 信頼のフィールドサポートサポートセンターで解決できない問題は、Oracle専任技術

者が直接お客様のもとをお伺いし、解決にあたります。

81

アシストのOracleビジネスのご紹介

アシスト


受賞内容

・ Oracle Excellence Award Specialized Partner of the Year：Special – Japan

・ Oracle Excellence Award Specialized Partner of the Year：Support – Japan

Oracle Database の分野で2賞受賞！

82

http://www.oracle.com/partners/ja/partner-with-oracle/market-and-sell/opn-awards/excellence-awards-

ja/index.html

http://www.ashisuto.co.jp/news/release/1196669_1675.html

http://www.oracle.com/partners/ja/partner-with-oracle/market-and-sell/opn-awards/excellence-awards-ja/index.html















http://www.ashisuto.co.jp/news/release/1196669_1675.html

アシスト


豊富な支援実績

西日本支社のみで約25名のOracle専門部隊がお客さまの課題

解決にあたり、年間100件を超える技術支援を実施しております。

さまざまな課題やご要望に対して、柔軟かつ高品質なサービスを

ご提供することが可能です。

A社(卸売業)　 RHEL/10g R2基幹系システム

再構築

Real Application Clusters、

バックアップ/リカバリ、データ移行

B社(陸運業) Win/10g R2業務系システム

再構築

Oracle Fail Safe、データ移行、

バックアップ/リカバリ

C社(電気・ガス業) AIX/10g R2基幹系システム

再構築HA、バックアップ/リカバリ、教育

D社(電気機器)　 Win/11g R1情報系システム

構築Single、DB設計、チューニング

E社(証券業) RHEL/9i R2 災対サイト構築 Data Guard、バックアップ/リカバリ

F社(情報・通信) HP-UX/10g R2情報系システム

再構築

Real Application Clusters、

バックアップ/リカバリ、

パーティション設計

G社(電気機器)　 AIX/10g R2基幹系システム

再構築

パーティション設計、

バックアップ/リカバリ

技術支援サービスメニュー

技術支援の一例

導入作業

バージョンアップ作業

データベース移行

Oracle データベース設計/実装

バックアップ/リカバリ運用設計

バックアップ/リカバリ検証

データベース診断

監視設計

SQL チューニング

パーティショニング設計

Real Application Clusters（RAC ）環境構築

Data Guard 環境構築

その他技術支援（オンサイト技術支援）

各種オンサイト教育

83

アシストの支援実績


アシスト

84

ご清聴ありがとうございました。

株式会社アシスト


アシスト

85

以上の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

Oracle、PeopleSoft、JD Edwards、及びSiebelは、米国オラクル・コーポレーション及びその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標の可能性があります。

29 「夜もよか～!! オラクル勉強会 presented by アシスト ......2015/11/18 · 29...

Documents