Microsoft PowerPoint - Platinum列伝_BackupRecovery_ ppt [互換モード]

(1)

Oracle

Direct Seminar

Oracle

Direct Seminar

【

Pl ti

列伝セミナ】

【

Platinum列伝セミナー】

Pl ti

が語る

!

Platinumが語る !

現場から学ぶバックアップ

&リカバリの極意

2010年3月30日

株式会社富士通北陸システムズ

富士通北陸システムズ(FJH)について

ORACLE MASTER Platinum AWARD 受賞！

オラクルデータベース認定資格制度オラクルデタベス認定資格制度

ORACLE MASTERの最高峰である、 ORACLE MASTER Platinum

Oracle Database 10g 資格得者数年連続国内 資格取得者数 2年連続国内ＮＯ．１ （2009/9 発表)

富士通グルプを代表するオラクルデタベスプロフ

シナル集団

富士通グループを代表するオラクルデータベースプロフェッショナル集団

独自ソリューションの提供、DBを中心としたインフラ全体の設計／構築、 製品サポート、DB関連製品開発など多方面でビジネス展開 製品サポト、DB関連製品開発など多方面でビジネス展開

(2)

講師自己紹介

氏名

齋藤拓哉（サイトウタクヤ）

ORACLE MASTER Platinum Oracle Database 10g （2008年4月取得）

業務経歴

2005年株式会社富士通北陸システムズ入社。

入社当初よりオラクル関連業務に従事。

ORACLE DATABASEバックアップリカバリ用ソフト

Recovery Manager for Oracleの開発を担当。

現在はそこで培った技術を元に、 Oracle Database

を含むインフラ全般のフィルドSEを担当している

を含むインフラ全般のフィールドSEを担当している。

取得得たも

Platinum取得で得たもの

お客様からの信頼や期待が大きくなったことを実感。

Agenda

現場から学ぶバクアプ&リカバリの極意

y

現場から学ぶバックアップ&リカバリの極意

–

バックアップ編

カバ編

–

リカバリ編

(3)

現場から学ぶバックアップ・リカバリの極意

現場から学ぶバックアップリカバリの極意

y

バックアップ編

y

推奨バックアップ構成

バクアプが必要ないフイルは？

y

バックアップが必要ないファイルは？

y

全データファイルを取得する時間がない！？

y

オンラインバックアップの影響

推奨バックアップ構成

ARCHIVEログモード＋オンラインバックアップ

ARCHIVEログモド＋オンラインバックアップ

もしくは RMAN

・システムを停止しなくてもバックアップが可能

・障害発生直前までリカバリすることが可能

・リカバリ時の選択肢（回復方法回復ポイント）が豊富

リカバリ時の選択肢（回復方法、回復ポイント）が豊富

(4)

バックアップが必要ないファイルは?

運用スケジュール上、全ファイルをバックアップする時間がない。

バク

プを省略きる

イ

は

バックアップを省略できるファイルは？

・オンラインREDOログ

オンライン

グ

ARCHIVEログモード－ログスイッチ後、アーカイブログをバックアップ NOARCHIVEログモード－ RESETLOGSで復旧可能 ※不用意なリストアにより最新デタが失われる場合も ※不用意なリストアにより最新データが失われる場合も

・ローカル管理の一時表領域

V$TEMPFILEで確認できる一時ファイルはバックアップ不要

ALTER TABLESPACE ADD TEMPFILE で復旧可能（復旧時間も早い）

・読取り専用表領域（変更時に一回のみ）

読取り専用に変更した時に、一回のみバックアップを取得しておく

全データファイルを取得する時間がない!!

全デタファイルを取得する時間がな

・１週間かけてバックアップを分散する

（アーカイブモード）

火水木金曜日日月火水木金土対象表領域A アーカイブログ表領域B アーカイブログ表領域C アーカイブログ表領域D アーカイブログ表領域E アーカイブログ表領域F アーカイブログ表領域G アーカイブログログログログログログログログデータファイル A B C B D F E G アーカイブログ ₃₅ ₃₆ ₃₇ ₃₈ ₃₉ ₄₀ ₄₁ ₄₂ ₄₃ ₄₄ ₄₅ ₄₆ ₄₇ ₄₈

・ストレージ装置の高速コピー機能

コピー命令は即時に復帰、バックアップは瞬時に完了

(5)

オンラインバックアップの影響

オンラインバックアップ時には何が起きている？

オラ

ックッ時

何

起

る

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

・データブロックへの書込みは継続

・更新される毎にデータファイルのブロックコピーを

REDOログファイルに追記

オンラインバックアップ中の内部動作

オンライン

ックアップ中の内部動作

更新SQL発行

/ /

②ブロック更新

INSERT/UPDATE/DELETE

①REDO生成

②ブロック更新

※チェンジベクタバッファキャッシュ

ブロックの変更内容

＋

※チェンジベクタ（アドレス、SCN、オペレーションなど）データファイル 38 DataFile

更新前の

ブロックコピー

REDOログ

オンライン

_{バックアップ}

ブロックコピー

※DB_BLOCK_SIZE単位 2KB/4KB/8KB/16KB/32KB オンラインバックアップ中の更新が多いと REDOログファイルへのブロックコピの

モードの場合

REDOログファイルへのブロックコピーの格納量が増加しREDOログのI/Oが増大 ※１バイトの更新でも数KB単位で REDOログファイルの書込が発生 REDOログファイルの書込が発生

(6)

REDOログファイルのI/O増加を防ぐには

REDO グファイルのI/O増加を防ぐには

・更新の少ない時間帯にバックアップを取得する

・データファイルのコピーが完了した表領域は

・デタファイルのコピが完了した表領域は

すぐにオンラインバックアップモードを解除する

ALTER TABLESPACE SYSTEM BEGIN BACKUP; !cp system01.dbf /backup

ALTER TABLESPACE SYSTEM END BACKUP; ALTER TABLESPACE UNDOTBS BEGIN BACKUP;

○ 表領域毎に

Begin/Endを実施

ALTER TABLESPACE UNDOTBS BEGIN BACKUP; !cp undotbs01.dbf /backup

ALTER TABLESPACE UNDOTBS END BACKUP; ALTER TABLESPACE SYSTEM BEGIN BACKUP; ALTER TABLESPACE UNDOTBS BEGIN BACKUP; !cp system01.dbf /backup

×

全ての表領域で

Begin/Endを実施

!cp undotbs01.dbf /backup

ALTER TABLESPACE SYSTEM END BACKUP; ALTER TABLESPACE UNDOTBS END BACKUP;

現場から学ぶバックアップ・リカバリの極意

現場から学ぶバックアップリカバリの極意

y

リカバリ編

y

リカバリの基本

y

リカバリの基本

y

ケーススタディ

– CASE.1 ASM構成のディスクグループが存在しない状態構成ィクグ存在状態でのリカバリエラー – CASE.2 ローカル管理の一時表領域のリカバリ

y

<付録>

– CASE.3 RAC構成：時刻のズレによるリカバリ失敗 – CASE.4 RAC構成：アーカイブ出力タイミングによる失敗 – CASE.5 オンラインバックアップ中の障害 – CASE.6 ファイルコピー中の起動 – CASE.7 データファイルが自動的にOFFLINEに!? – CASE.8 ACTIVE状態のREDOログが破損すると･･･バプが在バ – CASE.9 バックアップが存在しないファイルのリカバリ – CASE.10 NOARCHIVEでも完全回復が可能! – CASE.11 ORA-1578：ブロック障害が発生!

(7)

リカバリの基本

・障害発生ファイルの特定

エラーメッセージ、アラートログ等から障害発生箇所を特定する

・リストアの必要性を判断

障害の発生状況、一時表領域、読取専用表領域などを見極める障害の発生状況、時表領域、読取専用表領域などを見極める

・リカバリ方針の決定（完全/不完全）

障害の発生状況バクアプ/アカイブログの存在状況から障害の発生状況、バックアップ/アーカイブログの存在状況から完全回復か不完全回復かを決定する

リカバリ実施後の影響を考慮

・リカバリ実施後の影響を考慮

不完全回復などのリカバリを実施した後の影響を把握する（スタンバイDBの再作成など）

・リストア/リカバリ実施

バックアップをリストアしリカバリを実施する

バックアップをリストアし、リカバリを実施する

リカバリが必要なケース

リカバリが必要なケス

・SCNの不整合が発生した場合

場

※SCN（System Change[Commit] Number）

内部で変更状態を管理するタイムスタンプのようなもの REDOログ、制御ファイル、各データファイルに格納

・ファイルが破損した場合

バックアップファイルをリストアした場合、そのファイルの SCNが過去に戻るため、他のファイルとSCNの不整合が発生することになる

リカバリとはSCNの不整合を修復する作業

(8)

リカバリの基本動作

DataFile1 [SCN]

①リストア

②SCNの不整合が発生

_{⇒ リカバリが必要！}

データファイル DataFile3 DataFile2 DataFile2

障害発生

DataFile3 オンライン

リカバリルートを確立する

36 37 38 REDOログアーカイブログ

③リカバリ

31 32 35 36 37 ･･････アイグ 30

リカバリの基本動作

_④SCNの

_致

リカバリの基本動作

_{④SCNの一致}

⇒ リカバリ完了

DataFile1 [SCN]

①リストア

②SCNの不整合が発生

_{⇒ リカバリが必要！}

データファイル DataFile3 DataFile2 DataFile2 DataFile3 オンライン

リカバリルートを確立する

③リカバリ

31 32 ･･････ ₃₅ ₃₆ ₃₇ アイグ 30

(9)

リカバリ不可能な場合

DataFile1 [SCN]

Ⅰ. バックアップの欠落

バックアップデータファイル DataFile3 DataFile2 DataFile3 オンライン

このルートが寸断されると

リカバリは不可能

Ⅲ. REDOログの欠落

（未アーカイブ） 31 32 35 36 ･･････ 30

Ⅱ. アーカイブログの欠落

（未アカイブ）

CURRENT状態のREDOログが重要な理由

・運用中はチェックポイントSCNと最新SCNにギャップが存在バッファキャッシュ [SCN] 最新SCN

チェックポイントSCN

最新SCNにギャップが存在

・

チェックポイントの実行時にデタフイルのSCNが増加 [SCN] DataFile1 データファイルデータファイルのSCNが増加・データファイル＋バッファキャッシュで最新デタの整合性を保証 DataFile2 最新データの整合性を保証・バッファキャッシュが失われた場合、 REDOログからのみリカバリ可能 SCNのギャップ 37 38 オンライン REDOログ REDOログからのみリカバリ可能・完全回復には CURRENT状態のREDOログが必要 CURRENT INACTIVE CURRENT状態のREDOログが必要ログスイッチ稼動中のデータベースグイッチデータベース

(10)

RECOVERコマンドによる動作の違い

バックアップSCN

ターゲットSCN

[SCN] オンラインREDOログ

リストア

_完全回復 36 37 38 DataFile2

オンラインREDOログ _{RECOVER DATABASE}

RECOVER DATABASE 不完全回復 35 36 37 ･･････ 30 RECOVER DATABASE

USING BACKUP CONTROLFILE UNTIL CANCEL/TIME/CHANGE

アーカイブログ

RECOVERコマンドの違いによってリカバリルートが異なる

リカバリの概念（完全回復）

ターゲットSCN

バックアップSCN

DataFile1 [SCN]

①リストア

DataFile2

障害発生

DataFile3 DataFile2 データファイルオンライン DataFile3 デタファイル

②リカバリルート決定

②リカバリルト決定

RECOVER DATABASE 31 32 ･･････ ₃₅ ₃₆ ₃₇ アイグ 30

(11)

リカバリの概念（完全回復）

ターゲットSCN

バックアップSCN

[SCN]

完全回復

DataFile1

①リストア

DataFile2 _DataFile2 DataFile3 DataFile2 データファイルオンライン DataFile3 デタファイル

③リカバリ

②リカバリルート決定

②リカバリルト決定

RECOVER DATABASE 31 32 35 36 37 ･･････アイグ 30

リカバリの概念（不完全回復）

ターゲットSCN

バックアップSCN

DataFile1 [SCN] DataFile1

①リストア

DataFile2 DataFile3 DataFile2 DataFile3 DataFile3 データファイル

障害発生

デタファイル

②リカバリルート決定

RECOVER DATABASE 36 37 38 オンライン REDOログアーカイブログ

障害発

35 RECOVER DATABASE UNTIL CANCEL 31 32 ･･････ ₃₅ ₃₆ ₃₇ 30

(12)

リカバリの概念（不完全回復）

ターゲットSCN

バックアップSCN

[SCN] DataFile1 DataFile1

_{不完全回復}

①リストア

③リカバリ

DataFile2 DataFile2 DataFile3 DataFile3 データファイルデタファイル

②リカバリルート決定

RECOVER DATABASE

④RESETLOGS

38 オンライン REDOログアーカイブログ RECOVER DATABASE UNTIL CANCEL 1 31 32 35 36 37 ･･････ 30

現場から学ぶバックアップ・リカバリの極意

現場から学ぶバックアップリカバリの極意

y

リカバリ編

リカバリの基本

y

リカバリの基本

y

ケーススタディ

デ

クグ

プがな状態

カバ

–

CASE.1 ASMディスクグループがない状態でのリカバリエラー

–

CASE.2 ローカル管理の一時表領域のリカバリ

y <付録>録 – CASE.3 RAC構成：時刻のズレによるリカバリ失敗 – CASE.4 RAC構成：アーカイブ出力タイミングによる失敗 – CASE 5CASE.5 オンラインバックアップ中の障害オンラインバックアップ中の障害 – CASE.6 ファイルコピー中の起動 – CASE.7 データファイルが自動的にOFFLINEに!? CASE 8 ACTIVE状態のREDOログが破損すると･･･ – CASE.8 ACTIVE状態のREDOログが破損すると･･･ – CASE.9 バックアップが存在しないファイルのリカバリ – CASE.10 NOARCHIVEでも完全回復が可能! CASE 11 ORA 1578 ブロック障害が発生! – CASE.11 ORA-1578：ブロック障害が発生!

(13)

Oracle ASM（

Automatic Storage Management

）とは

Oracle ASM（

Automatic Storage Management

）とは

y

Oracle データベースファイルを管理するための

ボリューム・マネージャ

y

ASMによる利点

・可用性の向上

：ミラーリングの機能を実装

パフォマンスの向上

・パフォーマンスの向上

：ストライピングの機能を実装

管理の容易性の向上

・管理の容易性の向上

：DISK配置を意識しないデータベースの作成が可能

Oracle ASM（

Automatic Storage Management

）とは

Oracle ASM（

Automatic Storage Management

）とは

y

ASMではディスク・グループ管理用のインスタン

を

成す

があ

スを作成する必要がある

データベースインスタンス

ASM用インスタンス

データベースインスタンス

ASM用インスタンス

ディスクを使用する

ディスクを管理する

ディスク・グループ1

ディスク・グループ2

(14)

＜CASE.１ ASM構成のディスクグループが存在

しない状態でのリカバリエラー＞

＜事象＞

ASM構成でのデータベースでファイル破損が発生。

発生事例：

☆☆☆

データベースリカバリを試みたが、「ORA-19870」等のエラーにより、

リカバリが失敗してしまった。

＜原因＞

①ASMインスタンスが未起動でディスク・グループが認識できない。

もしくは

②ASMディスクグループ自体が破壊されたため、

RMANにより取得したバックアップファイルのリストア先が見つからない。

CASE.1

ASMディスクグループがない状態での

CASE.1

ASMディスクグルプがない状態での

リストアエラー

制御ファイルリストア開始制御ファイルリストア開始

RMAN> restore controlfile; :

ORA-19870: error reading backup

/ora01/arch_log/ctl/backupset/backup_ctl.2vkh5dmh_1_1 ORA-19504: failed to create file "+DG_REDO/ora01/control01.ctl"

ORA-17502: ksfdcre:3 Failed to create file +DG_REDO/ora01/control01.ctl ORA-15001: diskgroup "DG_REDO" does not exist or is not mounted ORA-15077: could not locate ASM instance serving a required diskgroup failover to previous backup

(15)

CASE.1

ASMディスクグループがない状態での

CASE.1

ASMディスクグルプがない状態での

リストアエラー

＜対処方法＞

ASMインスタンスの起動状態を確認し、停止していれば起動する。

ASMインスタンスの状態確認 $ crs stat t $ crs_stat –t 名前型ター...ト状態ホスト ---ora....ra01.db application OFFLINE OFFLINE

ora....11.inst application OFFLINE OFFLINE ora....11.inst application OFFLINE OFFLINE ora....12.inst application OFFLINE OFFLINE

ora....SM1.asm application OFFLINE OFFLINE

ora....1P.lsnr application ONLINE ONLINE racsv1 ora....n1p.gsd application ONLINE ONLINE racsv1 1 li ti ONLINE ONLINE 1 ora....n1p.ons application ONLINE ONLINE racsv1 ora....n1p.vip application ONLINE ONLINE racsv1

ora....SM2.asm application OFFLINE OFFLINE

ora....2P.lsnr application ONLINE ONLINE racsv2 ora....n2p.gsd application ONLINE ONLINE racsv2 ora....n2p.gsd application ONLINE ONLINE racsv2 ora....n2p.ons application ONLINE ONLINE racsv2 ora....n2p.vip application ONLINE ONLINE racsv2

ASMインスタンスの起動

$ srvctl start asm -n racsv1

CASE.1

ASMディスクグループがない状態での

CASE.1

ASMディスクグルプがない状態での

リストアエラー

ASMインスタンスの起動してもリストアに失敗する場合 ASMインスタンスの起動してもリストアに失敗する場合 ⇒ASMディスクグループ自体が破損しています。

この場合、ASMディスクグループを再作成します。

この場合、ASMディスクグルプを再作成します。

ASMディスクグループの再作成 $ export ORACLE_SID=+ASM1

$ sqlplus / as sysdba ←ASMインスタンスに接続

$ q p y 接続

SQL> create diskgroup DG_CTL external redundancy disk '/dev/raw/raw4'; ディスク・グループが作成されました。

リストア実行

RMAN> restore controlfile; ：が restoreが完了しました(完了時間: 2009/10/08-16:26:47) ★注意★ デスクグルプ破損時に備えてデスクグルプ作成ンドは予め準備ディスクグループ破損時に備えて、ディスクグループ作成コマンドは予め準備

(16)

＜CASE ２ロカル管理の

時表領域のリカバリ＞

＜CASE.２ローカル管理の一時表領域のリカバリ＞

＜事象＞

発生事例：

☆☆

データベースは正常にオープンするがアラートログには「ORA-01110」等

が出力されている。

また、大量ソート処理がエラーとなる。

＜原因＞

ローカル管理の一時表領域に障害が発生しています。

ローカル管理の一時表領域の障害の場合、データベースは正常に

起動できるため、ディスクソートを行うような処理をしない限り、通常は

破損に気づくことがない

破損に気づくことがない。

CASE ２ロカル管理の

時表領域のリカバリ

CASE.２ローカル管理の一時表領域のリカバリ

＜出力エラー例（alert.log)＞

Errors in file /oralog/db/log/bdump/xxxx lgwr 17890.trc:/ g/ / g/ p/ _ g _ ORA-01110: ???????1025: '/oradata/db/dbf/temp01.dbf'

:

＜データディクショナリビューの検索エラー例＞

SQL> select * from dba_temp_files; :

ORA-01187: cannot read from file 1025 because it failed verification tests ORA-01110: data file 1025: '/psc/goge/db/dbf/temp01 dbf'

ORA 01110: data file 1025: /psc/goge/db/dbf/temp01.dbf

＜対処＞

リストア/リカバリは必要ありません！！

＜対処＞

テンポラリファイルの再作成を行う。

テンポラリファイルの再作成

SQL> alter database tempfile '/oradata/db/dbf/temp01 dbf' drop; SQL> alter database tempfile /oradata/db/dbf/temp01.dbf drop; データベースが変更されました。

SQL> alter tablespace TEMP add tempfile '/oradata/db/dbf/temp01.dbf' size 1024M reuse ;

reuse ;

(17)

まとめ

y

ARCHIVEモード＋オンラインバックアップ/RMAN

SCNの不整合を修復するためにリカバリが必要

y

SCNの不整合を修復するためにリカバリが必要

y

障害状況を把握しリストア/リカバリの必要性を判断

y

バックアップから、アーカイブログ、オンラインREDO

を経由するリカバリルートを確立する

リカバリ成功の鍵となるのは

リカバリ成功の鍵となるのは．．．

・バックアップファイル、アーカイブログの管理

適切なカバ手

選択実行

・適切なリカバリ手順の選択/実行

さいごに

ＦＪＨでは、お客様のご要望にかなう様々なソリューションを

ご用意しています。

オラクルのことなら、すべてご相談ください！

オラクルの

なら、す

て相談くださ

<主な提供ソリューション> トタリシデザタリカバリリシ ・トータルDBソリューション ・ディザスタリカバリ・ソリューション・バックアップリカバリ・ソリューション・ブレード・ソリューション ・DBマイグレーション for Oracle ・DBセキュリティ・ソリューション ・RACソリューションRACソリュ ション ・RDBORDBO etc…etc…

株式会社富士通北陸システムズ

データベースソリューション事業本部

URL : http://jp.fujitsu.com/group/fjh/services/p jp j g p j mailto : [email protected]

(18)

現場から学ぶバックアップ・リカバリの極意

現場から学ぶバックアップリカバリの極意

y

リカバリ編

リカバリの基本

y

リカバリの基本

y

ケーススタディ

構成デグプが存在な状態 – CASE.1 ASM構成のディスクグループが存在しない状態 – でのリカバリエラー – CASE.2 ローカル管理の一時表領域のリカバリ付録 y <付録> – CASE.3 RAC構成：時刻のズレによるリカバリ失敗 – CASE.4 RAC構成：アーカイブ出力タイミングによる失敗 CASE 5 オンラインバックアップ中の障害 – CASE.5 オンラインバックアップ中の障害 – CASE.6 ファイルコピー中の起動 – CASE.7 データファイルが自動的にOFFLINEに!? CASE 8 ACTIVE状態のREDOログが破損すると･･･ – CASE.8 ACTIVE状態のREDOログが破損すると･･･ – CASE.9 バックアップが存在しないファイルのリカバリ – CASE.10 NOARCHIVEでも完全回復が可能! – CASE 11 ORA-1578：ブロック障害が発生! – CASE.11 ORA 1578：ブロック障害が発生!

(19)

＜CASE ３時刻のズレによるリカバリ失敗＞

＜CASE.３時刻のズレによるリカバリ失敗＞

＜事象＞

発生事例：

☆☆☆

RAC構成でのデータベースで重要なテーブルを削除してしまった。

対象テーブルが削除される前の時間を指定してリカバリを試みたが、

「ORA-01547」等のエラーにより、リカバリが失敗。

＜原因＞

RACを構成するノード間で時刻同期が取れていなかったこと。

時間指定でのデータベースリカバリを行う際は、必ず全サーバで時刻同期

が取れている状態で実施する必要がある。

CASE.３時刻のズレによるリカバリ失敗

時刻のズレによるリカ

リ失敗

時間指定リカバリ開始

RMAN> run {

RMAN> set until time '2009/09/30-09:00:00';/ / RMAN> restore database;

RMAN> crosscheck archivelog all;

RMAN> recover database delete archivelog , check readonly; RMAN> sql 'alter database open resetlogs';

RMAN> sql alter database open resetlogs ; RMAN> }

:

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA 01195: online backup of file 1 needs more recovery to be consistent

ORA-01195: online backup of file 1 needs more recovery to be consistent ORA-01110: data file 1: '/dev/raw/raw126'

エラー発生！どうすればいいの？

ラ発

うすれば

＜対処方法＞

リカバリエラー発生時はログ順序番号を指定したリカバリを再実行

リカバリエラ発生時は、ログ順序番号を指定したリカバリを再実行

RAC環境でのバックアップリカバリは、NTPサーバを利用する等で

全ノードの時刻同期が取れている状態で運用を行いましょう

(20)

＜CASE ４アカイブ出力タイミングによる失敗＞

＜CASE.４アーカイブ出力タイミングによる失敗＞

＜事象＞

発生事例：

☆☆☆

RAC構成でのデータベースで全障害が発生。

カレントREDOログも破壊されているため、アーカイブログ出力時点までの

ログ順序番号指定でリカバリを実施したが、必要なログが見つからない旨

のエラーで失敗。

＜原因＞

各

ド

グにおける

カイブ出力タイミグ

ずれを

RACの各スレッドのREDOログにおけるアーカイブ出力タイミングのずれを

考慮したリカバリポイント(ログ順序番号)を指定してなかった。

現場から学ぶバックアップ・リカバリの極意

現場から学ぶバックアップリカバリの極意

y

リカバリ編

リカバリの基本

y

リカバリの基本

y

ケーススタディ

(21)

CASE.４アーカイブ出力タイミングによる失敗

アカイブ出力タイミングによる失敗

リストア/リカバリ開始

RMAN> run {

RMAN> set until logseq 30 thread 1;q RMAN> restore database;

RMAN> recover database delete archivelog , check readonly; RMAN> }

･･･

RMAN-03002: failure of recover command at 09/30/2009 09:28:33

RMAN-06054: media recovery requesting unknown log: thread 2 seq 30 lowscn 1342039

エラ発生！なんで？

エラー発生！なんで？

リカバリポイント

27

28

29

30 時間

×

破損

スレッド１

_×

破損

27

28

29

30 _×

_破損

スレッド２

スレッド1/ｱｰｶｲﾌﾞ29までリカバリするには、スレッド2/ｱｰｶｲﾌﾞ30のログが一部必要!!

カレントREDO アーカイブREDO

CASE.４アーカイブ出力タイミングによる失敗

＜対処＞

発生したエラで出力されているメッセジを確認し正しいスレッド番号

C S

アカイブ出力タイミングによる失敗

発生したエラーで出力されているメッセージを確認し、正しいスレッド番号

とログ順序番号で再度リカバリを再実行。

出力エラーメッセージ

RMAN-06054: media recovery requesting unknown log: thread 2 seq 30 lowscn 1342039

リストア/リカバリ実行

RMAN> run {

RMAN> set until logseq 30 thread 2; RMAN> restore database;

RMAN> recover database delete archivelog , check readonly; RMAN> }

エラーメッセージ通りに指定

}

･･･

メディア・リカバリが完了しました。経過時間: 00:02:02 recoverが完了しました(完了時間: 20090930093733) recoverが完了しました(完了時間 20090930093733)

(22)

現場から学ぶバックアップ・リカバリの極意

現場から学ぶバックアップリカバリの極意

y

リカバリ編

リカバリの基本

y

リカバリの基本

y

ケーススタディ

構成デグプが存在な状態 – CASE.1 ASM構成のディスクグループが存在しない状態 – でのリカバリエラー – CASE.2 ローカル管理の一時表領域のリカバリ付録 y <付録> – CASE.3 RAC構成：時刻のズレによるリカバリ失敗 – CASE.4 RAC構成：アーカイブ出力タイミングによる失敗 CASE 5 オンラインバックアップ中の障害 – CASE.5 オンラインバックアップ中の障害 – CASE.6 ファイルコピー中の起動 – CASE.7 データファイルが自動的にOFFLINEに!? CASE 8 ACTIVE状態のREDOログが破損すると･･･ – CASE.8 ACTIVE状態のREDOログが破損すると･･･ – CASE.9 バックアップが存在しないファイルのリカバリ – CASE.10 NOARCHIVEでも完全回復が可能! – CASE 11 ORA-1578：ブロック障害が発生!

– CASE.11 ORA 1578：ブロック障害が発生!

＜CASE ５オンラインバックアップ中の障害＞

＜CASE.５オンラインバックアップ中の障害＞

＜事象＞

発生事例：

☆☆☆

夜間のオンラインバックアップ実行中にCPU障害によりマシンが停止した。

CPU交換後、OSは起動したがOracle起動時にORA-1113が発生。

＜原因＞

オンラインバックアップ中は、対象データファイルヘッダのチェックポイント

SCNが固定される

他のデータファイルとSCNの不整合が発生しているため、リカバリが必要

と判断され「ORA-1113：メディアリカバリが必要です」が発生する

(23)

CASE.５オンラインバックアップ中の障害

オンラインバックアップ開始

SQL> ALTER TABLESPACE USERS BEGIN BACKUP;

★インスタンスダウン（ハード障害、shutdown abort等） Oracle起動 SQL> STARTUP SQL> STARTUP ･･･データベースがマウントされました。 ORA-01113: ファイル5はメディア・リカバリが必要です ORA-01110: データ・ファイル5: ‘E:¥ORACLE¥ORADATA¥TARGET¥USERS01 DBF' ORA 01110: デタファイル5: E:¥ORACLE¥ORADATA¥TARGET¥USERS01.DBF チェックポイントSCN確認 SQL> SELECT FILE#,STATUS,RECOVER,FUZZY,CHECKPOINT_CHANGE# 2 FROM V$DATAFILE HEADER;

2 FROM V$DATAFILE_HEADER;

FILE# STATUS REC FUZ CHECKPOINT_CHANGE# --- --- --- --- ---･･･

リストア/リカバリは

必要なの？？

･･･ 3 ONLINE NO YES 180715 4 ONLINE NO YES 180715

SCNの

5 ONLINE NO YES 180658

★不整合

要

CASE.５オンラインバックアップ中の障害

リストア/リカバリは必要ありません！！

＜対処＞

バックアップモドを確認し ALTER DATABASE END BACKUPを実行する

バックアップモードを確認し ALTER DATABASE END BACKUPを実行する。

バックアップモード確認

SQL> SELECT * FROM V$BACKUP;

FILE# STATUS CHANGE# TIME FILE# STATUS CHANGE# TIME

--- --- --- ---･･･ 5 ACTIVE 180658 2007-11-11 15:50:35

バクアプモド解除バックアップモード解除

SQL> ALTER DATABASE DATAFILE 5 END BACKUP; または

SQL> ALTER DATABASE END BACKUP; （9i～)

バックアップモード再確認

FILE# STATUS CHANGE# TIME

--- --- --- ---･･･ 5 NOT ACTIVE 180658 2007-11-11 15:50:35

データベース起動

SQL> ALTER DATABASE OPEN

recover databaseでも回復可能だが、アーカイブログの適用が必要になり

(24)

現場から学ぶバックアップ・リカバリの極意

現場から学ぶバックアップリカバリの極意

y

リカバリ編

リカバリの基本

y

リカバリの基本

y

ケーススタディ

＜CASE ６ファイルコピ中の起動（Windows）＞

＜CASE.６ファイルコピー中の起動（Windows）＞

＜事象＞

オ

イバク

プ実行中

ジ

り

が起動され

発生事例：

☆☆☆

オフラインバックアップ実行中にスケジューラによりOracleが起動されて

しまった。オープンは出来たが運用中にORA-1122、ORA-1208が発生し

アクセス不可能になった。再起動を行うとORA-1113が発生。

＜原因＞

Windowsのファイルコピー(COPY、XCOPY等)は対象ファイルのコピー中

に書込み不可のロックをかける

Oracleも起動時にファイルにロックをかけようとするがアクセス拒否され、

最終的に他のデータファイルとSCNのギャップが発生する

(25)

CASE.６ファイルコピー中の起動（Windows）

CASE.６ファイルコピ中の起動（Windows）

ファイルコピー開始

C:¥> COPY E:¥ORACLE¥ORADATA¥TARGET¥SYSTEM01.DBF F:¥BACKUP

ファイルコピー中にOracle起動 SQL> STARTUP ･･･データベースがマウントされました。デタベスがマウントされました。データベースがオープンされました。アラートログ確認

ORA 01110: data file 1: E:¥ORACLE¥ORADATA¥TARGET¥SYSTEM01 DBF' ORA-01110: data file 1: E:¥ORACLE¥ORADATA¥TARGET¥SYSTEM01.DBF ORA-01114: IO error writing block to file 1 (block # 1)

ORA-27072: skgfdisp: I/O error

OSD-04008: WriteFile()エラーファイルへの書込みができません OSD 04008: WriteFile()エラー。ファイルへの書込みができません。 O/S-Error: (OS 5) アクセスが拒否されました。 ★SYSTEM表領域の場合インスタンスダウン（チェックポイント実行時) ★SYSTEM表領域の場合インスタンスダウン（チェックポイント実行時) ★ユーザ表領域の場合Oracleが自動的にファイルをオフラインに

CASE.６ファイルコピー中の起動（Windows）

CASE.６ファイルコピ中の起動（Windows）

Oracle再起動 SQL> STARTUP ･･･データベースがマウントされました。 ORA-01113: ファイル1はメディア・リカバリが必要です ORA-01110: データ・ファイル1: ‘E:¥ORACLE¥ORADATA¥TARGET¥SYSTEM01.DBF' チェックポイントSCN確認 SQL> SELECT FILE#,STATUS,RECOVER,FUZZY,CHECKPOINT_CHANGE# 2 FROM V$DATAFILE_HEADER;

FILE# STATUS REC FUZ CHECKPOINT CHANGE# FILE# STATUS REC FUZ CHECKPOINT_CHANGE# --- --- --- --- ---1 ONLINE YES NO 203980

★SCNの不整合

2 ONLINE NO YES 203981 2 ONLINE NO YES 203981 3 ONLINE NO YES 203981

リストアは必要なの？？

(26)

CASE ６ファイルコピー中の起動（Windows）

CASE.６ファイルコピ中の起動（Windows）

リストアは必要ありません！！

＜対処＞

オンラインREDOログを確認し RECOVER DATABASEを実行する

オンラインREDOログを確認し RECOVER DATABASEを実行する。

オンラインREDOログの最小SCN

SQL> SELECT MIN(FIRST_CHANGE#) FROM V$LOG; MIN(FIRST CHANGE#) MIN(FIRST_CHANGE#) ---180713 ＜ ORA-1113が発生するファイルのSCN(

203980

)

カバ実行（な）

オ

グ

カバ

能

リカバリ実行（リストアなし） SQL> RECOVER DATABASE; メディア・リカバリが完了しました。

オンラインREDOログのみでリカバリ可能

チェックポイントSCN確認

FILE# STATUS REC FUZ CHECKPOINT_CHANGE# --- --- --- ---

---1 ONLINE NO NO 205710

SCNが一致

1 ONLINE NO NO 205710

SCNが

致

2 ONLINE NO NO 205710

データベース起動

SQL> ALTER DATABASE OPEN;

現場から学ぶバックアップ・リカバリの極意

現場から学ぶバックアップリカバリの極意

y

リカバリ編

リカバリの基本

y

リカバリの基本

y

ケーススタディ

(27)

データファイルが自動的にOFFLINEに!?

デタファイルが自動的にOFFLINEに!?

＜CASE.７ OracleがファイルをOFFLINEに＞

＜事象＞

データファイルが破損したためリストア後、RECOVER DATABASEを実行し、

発生事例：

☆☆

データベースは起動出来たが ORA-376（

ファイルを読み込むことはできません。

）が

発生し、テーブルにアクセスできない。

原因

＜原因＞

Oracleがデータファイルを自動的にOFFLINEに設定したため。

OFFLINEのデタフイルは RECOVER DATABASE マンドでは復旧する

OFFLINEのデータファイルは、RECOVER DATABASEコマンドでは復旧する

ことができない。

また、オープン時にもOFFLINEファイルの整合性チェックは行わないため、

エラ出力もされない

エラー出力もされない。

CASE.７ OracleがファイルをOFFLINEに

＜出力エラー例（alert.log)＞

ORA-01171:

datafile 5 going offline

due to error advancing checkpoint ORA-01116: error in opening database file 5

ORA-01110: data file 5: 'E:¥ORACLE¥ORADATA¥TARGET¥USERS01.DBF' ORA-27041: unable to open file

OSD-04002: ファイルをオープンできません

O/S-Error: (OS 21) デバイスの準備ができていません。 KCF: write/open error block=0x15 online=1 file=2

E:¥ORACLE¥ORADATA¥TARGET¥UNDOTBS01.DBF

error=27072 txt: ‘OSD-04008: WriteFile()に失敗しました。ファイルへの書込みができません O/S-Error: (OS 33) プロセスはファイルにアクセスできません。

別のプロセスがファイルの部をロックしています ‘ 別のプロセスがファイルの一部をロックしています。

Automatic datafile offline

due to write error on file 2: E:¥ORACLE¥ORADATA¥TARGET¥UNDOTBS01.DBF

(28)

CASE.７ OracleがファイルをOFFLINEに

＜対処＞

RECOVER DATABASEを実行する前にデータファイルをONLINEにする

RECOVER DATABASEを実行する前に、デタファイルをONLINEにする。

Oracle起動

SQL> STARTUP MOUNT ･･･

データベースがマウントされました。

データファイルヘッダのSTATUS確認

SQL> SELECT FILE# STATUS RECOVER FUZZY CHECKPOINT CHANGE# SQL> SELECT FILE#,STATUS,RECOVER,FUZZY,CHECKPOINT_CHANGE#

2 FROM V$DATAFILE_HEADER;

FILE# STATUS REC FUZ CHECKPOINT_CHANGE# --- --- --- --- ---1 ONLINE NO YES ---197092

2 OFFLINE YES 195533

★

OFFLINE状態

5 OFFLINE YES 195533

★

CASE.７ OracleがファイルをOFFLINEに

データファイルのONLINE

SQL> ALTER DATABASE DATAFILE 2,5 ONLINE;Q > , データベースが変更されました。

データファイルヘッダのSTATUS確認

FILE# STATUS REC FUZ CHECKPOINT CHANGE# FILE# STATUS REC FUZ CHECKPOINT_CHANGE# --- --- --- --- ---1 ONLINE NO YES ---197092

2 ONLINE YES 195533

★

ONLINE状態

4 ONLINE NO YES 197092 5 ONLINE YES 195533

★

リカバリ実行リカバリ実行 SQL> RECOVER DATABASE; メディア・リカバリが完了しました。デタベ起動データベース起動

SQL> ALTER DATABASE OPEN; データベースが変更されました。

(29)

現場から学ぶバックアップ・リカバリの極意

現場から学ぶバックアップリカバリの極意

y

リカバリ編

リカバリの基本

y

リカバリの基本

y

ケーススタディ

ACTIVE状態のREDOログが破損すると･･･

ACTIVE状態のREDO グが破損すると

＜CASE.８ ACTIVE状態のREDOログが破損＞

＜事象＞

CURRENTではないオンラインREDOログが破損した。

発生事例：

☆

リカバリ手順として、CURRENT以外のREDOログの場合は再作成

（ALTER DATABASE CLEAR LOGFILE）で復旧できると聞いていたが、

「ORA-1624: クラッシュ・リカバリに必要です。」が発生し復旧できない。

＜原因＞

破損したオンラインREDOログがACTIVE状態のため

ACTIVE状態のREDOログは、CURRENTではないがクリアすることは

できない

(30)

ACTIVE状態のREDOログ

チェックポイントSCN

・ログスイッチ時にはデータファイルの SCNは増加しない（Oracle 8i ～） [SCN] DataFile1 データファイル（ゼロプライオリティチェックポイント）・チェックポイントが完了していないグは状態 DataFile2 REDOログはACTIVE状態・ACTIVEなREDOログはクリアできない（CURRENTと同じ扱い） 37 38 オンライン REDOログ（CURRENTと同じ扱い）・ACTIVE状態でもアーカイブログは作成されている（CURRENTと異なる点） 37 38 REDOログ CURRENT ACTIVE 作成されている（CURRENTと異なる点）・ACTIVEなREDOログが破損した場合不完全回復(RESETLOGS)が必要ログスイッチ不完全回復(RESETLOGS)が必要ログスイッチ 37 アーカイブログ稼動中のデータベース

37 データベース

CASE.８ ACTIVE状態のREDOログが破損

CASE.８ ACTIVE状態のREDO グが破損

ターゲットSCN

バックアップSCN

DataFile1 [SCN]

①リストア

DataFile2 DataFile3 DataFile2 データファイル

障害発生

オンライン DataFile3 デタファイル

障害発生

②リカバリルート決定

31 32 ･･････ ₃₅ ₃₆ ₃₇ アイグ 30

(31)

CASE.８ ACTIVE状態のREDOログが破損

CASE.８ ACTIVE状態のREDO グが破損

ターゲットSCN

バックアップSCN

[SCN]

不完全回復

（デタ損失なし） DataFile1

①リストア

DataFile2 _DataFile2 （データ損失なし） DataFile3 DataFile2 データファイルオンライン DataFile3 デタファイル

③リカバリ

④RESETLOGS

②リカバリルート決定

31 32 35 36 37 ･･････アイグ 30

CASE.８ ACTIVE状態のREDOログが破損

CASE.８ ACTIVE状態のREDO グが破損

＜対処＞

不完全回復ベースでアーカイブログ CURRENTのREDOログを適用する

不完全回復ベスで、アカイブログ、CURRENTのREDOログを適用する。

データファイル２のリストア CP … Oracle起動 SQL> STARTUP MOUNT ･･･デタベがウされまたデータベースがマウントされました。オンラインREDOログのSTATUS確認

SQL> SELECT GROUP#, SEQUENCE#, ARCHIVED, STATUS FROM V$LOG; GROUP# SEQUENCE# ARC STATUS

--- --- ---

---1 ---17 YES ACTIVE ★破損★破損 2 18 NO CURRENT

(32)

CASE.８ ACTIVE状態のREDOログが破損

CASE.８ ACTIVE状態のREDO グが破損

不完全回復実行

SQL> RECOVER DATABASE UNTIL CANCEL

アーカイブ適用(ACTIVE状態のREDOに対応)

ORA-00289:

検討すべきログ

ファイル

検討すべきログ・ファイル

:E:¥ORACLE¥ADMIN¥TARGET¥ARCHIVE¥TARGET_00017.ARC

ORA-00280: 変更198817 (スレッド1)は順序番号17に存在します。

E:¥ORACLE¥ADMIN¥TARGET¥ARCHIVE¥TARGET 00017.ARC ← <入力>

E ¥ORACLE¥ADMIN¥TARGET¥ARCHIVE¥TARGET_00017.ARC

<入力>

CURRENT REDOログの適用

ORA-00289:

検討すべきログ

ファイル

検討すべきログ・ファイル

:E:¥ORACLE¥ADMIN¥TARGET¥ARCHIVE¥TARGET_00018.ARC

ORA-00280: 変更232695 (スレッド1)は順序番号18に存在します。

E:¥ORACLE¥ORADATA¥TARGET¥REDO02.LOG ← <入力>

入力

データベース起動(RESETLOGS)

SQL> ALTER DATABASE OPEN RESETLOGS;

現場から学ぶバックアップ・リカバリの極意

現場から学ぶバックアップリカバリの極意

y

リカバリ編

リカバリの基本

y

リカバリの基本

y

ケーススタディ

(33)

バックアップが存在しないファイルのリカバリ

ックアップが存在しなファイルのリカ

リ

＜CASE.９ファイルのバックアップがない!!＞

＜事象＞

システムが稼動して一年後、表領域/データファイルを追加したが、

発生事例：

☆

運用中にデータファイルが破損してしまった。リカバリを実施しようと

したが、追加したデータファイルのバックアップが存在していなかった。

原因

＜原因＞

・バックアップファイルも破損してしまった

バクアプツルやバクアプ用シルスクリプトの修正を忘れて

・バックアップツールやバックアップ用シェルスクリプトの修正を忘れて

いた

リカバリは不可能なの？？

リ

不可能な

CASE.９ファイルのバックアップがない!!

C S ９ファイルの

ックアップがない

リカバリ可能な場合があります！！

＜対処＞

CREATE DATAFILEで空のファイルを作成しアカイブログを適用する

CREATE DATAFILEで空のファイルを作成し、アーカイブログを適用する。

データファイル破損

ORA-01122: database file 6 failed verification check

ORA 01110: d t fil 6: 'E:¥ORACLE¥ORADATA¥TARGET¥USERS201 DBF' ORA-01110: data file 6: E:¥ORACLE¥ORADATA¥TARGET¥USERS201.DBF

★リストアしようと思ったがデータファイルのバックアップがない！！表領域をオフライン

表領域をオフライン

SQL> ALTER TABLESPACE USERS2 OFFLINE IMMEDIATE;

空のデータファイルを再作成

SQL> ALTER DATABASE CREATE DATAFILE 6 SQL> ALTER DATABASE CREATE DATAFILE 6

AS 'E:¥ORACLE¥ORADATA¥TARGET¥USERS201.DBF';

元ファイル作成時の情報

SQL> SELECT FILE#,CHANGE#,TIME FROM V$RECOVER_FILE; FILE# CHANGE# TIME

--- --- ---6 198744 2007-11-17 19:53:21

(34)

CASE.９ファイルのバックアップがない!!

C S ９ファイルの

ックアップがない

リカバリ可能な場合があります！！

リカバリに必要なアーカイブログの確認

リカバリに必要なアカイブグの確認

SQL> SELECT ARCHIVE_NAME FROM V$RECOVERY_LOG; ARCHIVE_NAME ---E:¥ORACLE¥ADMIN¥TARGET¥ARCHIVE¥TARGET 00006 ARC E:¥ORACLE¥ADMIN¥TARGET¥ARCHIVE¥TARGET_00006.ARC E:¥ORACLE¥ADMIN¥TARGET¥ARCHIVE¥TARGET_00007.ARC E:¥ORACLE¥ADMIN¥TARGET¥ARCHIVE¥TARGET_00008.ARC …

表示されたアーカイブ

リカバリ実施

SQL> RECOVER TABLESPACE USERS2; … ログが適用されました

表示されたアカイブ

が全て存在していれ

ばリカバリが可能！

ログが適用されました。メディア・リカバリが完了しました。表領域をオンライン

SQL> ALTER TABLESPACE USERS2 ONLINE; SQL> ALTER TABLESPACE USERS2 ONLINE;

現場から学ぶバックアップ・リカバリの極意

現場から学ぶバックアップリカバリの極意

y

リカバリ編

リカバリの基本

y

リカバリの基本

y

ケーススタディ

(35)

NOARCHIVEでも完全回復が可能!

＜CASE.１０ NOARCHIVEモードの完全回復＞

＜事象＞

NOARCHIVEモードで運用中にデータファイルの破損が発生した。

発生事例：

☆

出来れば最新データを復旧したい。

＜対処＞

ドもあきらめな

NOARCHIVEモードでもあきらめない

バックアップ取得タイミングとオンラインREDOログの状態によっては、

・NOARCHIVEはアーカイブログが出力されないだけ

・オンラインREDOログでリカバリルートが確立出来れば

オンライン

グでリカ

リルトが確立出来れば

完全回復が可能！

CASE １０ NOARCHIVEモードの完全回復

ターゲットSCN

バックアップSCN

CASE.１０ NOARCHIVEモドの完全回復

DataFile1 [SCN]

①リストア

_DataFile1 DataFile2 DataFile2

障害発生

通常はアーカイブログがないため

オイ DataFile3 データファイル

リカバリルート確立不可能

36 37 38 オンライン REDOログブグ･･････アーカイブログ

(36)

CASE １０ NOARCHIVEモードの完全回復

ターゲットSCN

バックアップSCN

CASE.１０ NOARCHIVEモドの完全回復

DataFile1 [SCN]

①リストア

完全回復

バックアップを取得してから

障害発生までの期間が短い場合

DataFile1 DataFile2 DataFile2

障害発生

完全回復

障害発生までの期間が短い場合

オンラインREDOログがあれば

リカバリルートが確立できる！

36 37 38 オンライン REDOログブグ･･････アーカイブログ

CASE １０ NOARCHIVEモードの完全回復

ターゲットSCN

バックアップSCN

CASE.１０ NOARCHIVEモドの完全回復

DataFile1 [SCN]

完全回復

①リストア

オンラインREDOログのサイズが大きい

_{または、グループ数が多い場合}

_DataFile1 DataFile2

障害発生

完全回復

DataFile2

または、グルプ数が多い場合

オンラインREDOログがあれば

リカバリルートが確立できる！

30 ₃₈ オンライン REDOログブグ 31 32 ･･････ 35 36 37 ･･････アーカイブログ

(37)

現場から学ぶバックアップ・リカバリの極意

現場から学ぶバックアップリカバリの極意

y

リカバリ編

リカバリの基本

y

リカバリの基本

y

ケーススタディ

ORA-1578：ブロック障害が発生!

＜CASE.１１ ORA-1578:ブロック障害＞

＜事象＞

運用中にORA-1578:ブロック障害が発生し特定のデータにアクセスが

発生事例：

☆ ☆ ☆

できなくなってしまった。

＜原因＞

ブ

ク構造

妥

性

ク失敗たため

Oracleブロック構造の妥当性チェックに失敗したため

メモリ破損、ディスク破損に伴い発生する場合がある

＜対処＞

・オブジェクトを再作成し、ExportデータのImportやSQL*Loaderで修復

・破損ブロックをスキップ（一部データはロスト）

バックアップファイルからリカバリ

・バックアップファイルからリカバリ

リカバリはどうすればよい？？

(38)

CASE １１ ORA-1578：ブロック障害

CASE.１１ ORA 1578：ブロック障害

バックアップSCN

①データファイル

リストア

通常のバックアップ構成

DataFile2

ブロック障害

DataFile2

リストア

オンライン

③リカバリ

36 37 38 アーカイブログ

②リカバリルート決定

REDOログ 31 32 35 36 37 ･･････アイグ

CASE １１ ORA-1578：ブロック障害

CASE.１１ ORA 1578：ブロック障害

バックアップSCN

①特定ブロック

のみリストア

RMANのBMR : 9i /10g EE

（Block Media Recoverｙ）

DataFile2

ブロック

メディア

のみリストア

メディア

リカバリ

②リカバリルト決定

オンライン

③リカバリ（対象ブロック）

36 37 38 アーカイブログ

②リカバリルート決定

（対象ブロック関連）

REDOログ 31 32 ･･････ ₃₅ ₃₆ ₃₇ アイグ

Microsoft PowerPoint - Platinum列伝_BackupRecovery_ ppt [互換モード]

Oracle

Direct Seminar

Oracle

Direct Seminar

【

Pl ti

列伝セミナ 】

【

Platinum列伝セミナー】

Pl ti

が語る

!

Platinumが語る !

現場から学ぶバックアップ

&リカバリの極意

2010年3月30日

株式会社富士通北陸システムズ

富士通北陸システムズ(FJH)について

富士通北陸システムズ(FJH)について

富士通グル プを代表するオラクルデ タベ スプロフ

シ ナル集団

富士通グループを代表するオラクルデータベースプロフェッショナル集団

講師自己紹介

講師自己紹介

氏名

齋藤 拓哉（サイトウ タクヤ）

業務経歴

業務経歴

2005年 株式会社富士通北陸システムズ入社。

入社当初よりオラクル関連業務に従事。

ORACLE DATABASEバックアップリカバリ用ソフト

ORACLE DATABASEバックアップリカバリ用ソフト

Recovery Manager for Oracleの開発を担当。

現在はそこで培った技術を元に、 Oracle Database

を含むインフラ全般のフィ ルドSEを担当している

を含むインフラ全般のフィールドSEを担当している。

取得 得たも

Platinum取得で得たもの

お客様からの信頼や期待が大きくなったことを実感。

Agenda

Agenda

現場から学ぶバ クア プ&リカバリの極意

y

現場から学ぶバックアップ&リカバリの極意

バックアップ編

カバ 編

リカバリ編

現場から学ぶバックアップ・リカバリの極意

現場から学ぶバックアップ リカバリの極意

y

バックアップ編

バックアップ編

y

推奨バックアップ構成

バ クア プが必要ないフ イルは？

y

バックアップが必要ないファイルは？

y

全データファイルを取得する時間がない！？

y

オンラインバックアップの影響

推奨バックアップ構成

推奨バックアップ構成

ARCHIVEログモード ＋ オンラインバックアップ

ARCHIVEログモ ド ＋ オンラインバックアップ

もしくは RMAN

・システムを停止しなくてもバックアップが可能

・障害発生直前までリカバリすることが可能

・リカバリ時の選択肢（回復方法 回復ポイント）が豊富

リカバリ時の選択肢（回復方法、回復ポイント）が豊富

バックアップが必要ないファイルは?

バックアップが必要ないファイルは?

運用スケジュール上、全ファイルをバックアップする時間がない。

バ ク

プを省略 きる

イ

は

バックアップを省略できるファイルは？

・オンラインREDOログ

列伝セミナ】

富士通グルプを代表するオラクルデタベスプロフ

シナル集団

齋藤拓哉（サイトウタクヤ）

2005年株式会社富士通北陸システムズ入社。

を含むインフラ全般のフィルドSEを担当している

取得得たも

現場から学ぶバクアプ&リカバリの極意

カバ編

現場から学ぶバックアップリカバリの極意

バクアプが必要ないフイルは？

ARCHIVEログモード＋オンラインバックアップ

ARCHIVEログモド＋オンラインバックアップ

・リカバリ時の選択肢（回復方法回復ポイント）が豊富

バク

プを省略きる

全デタファイルを取得する時間がな

オラ

ックッ時

_{バックアップ}

・デタファイルのコピが完了した表領域は

現場から学ぶバックアップリカバリの極意