わんくま同盟 東京勉強会 #36

本当に使える！！Oracle Database トラブルシューティング

日本オラクル Oracle Direct 大田

わんくま同盟 東京勉強会 #36

Databaseを運用する上で、こんなことありませんか・・・

• 「間違えて重要なデータを消してしまった！！」

• 「データファイルが壊れた！！」

• 「急に動作が遅くなった！！」

などなど、危機的なトラブルが発生したことはありませんか？

本セッションでは、現場で起きた本当に怖い話と、

それについての回避策をリアルデモでお見せします！！

わんくま同盟 東京勉強会 #36

どの障害が一番多いでしょう？

計画

外停

止コンピュータ障害

ストレージ障害

人的エラー

データ破損

サイト障害

データ障害

実は一番多いのがこれ

わんくま同盟 東京勉強会 #36

–「違うバッチ流してしまった！！」

→ バッチを流す前に データベースを迅速に戻したい。

–「改修したアプリケーションが間違ってるじゃないか！」

→ アプリケーション変更前の データベースに迅速に戻したい。

–「違うテーブルを truncate してしまった！」

→ truncateする前のデータを復旧させたい。

–「テストデータを再構築するのは工数がかかるなぁ。。。」

→ テストを実行させる前の状態に戻したい。

–「3時間前の状態に データベースを簡単に戻せれば楽なのに。。。」

→ 指定した時間に データベースを巻き戻したい。

–「3時間前のデータベースのデータを知りたい！」

→ 指定した時間の データベースのデータを参照したい。

こんなことありませんか？

わんくま同盟 東京勉強会 #36

• フラッシュバック・テクノロジーが必要とされる背景

– アプリケーション障害の40%はオペレータまたはユーザーのエラー

– ユーザーエラーの復旧は非常に困難

• フラッシュバック・テクノロジーの目的

– 人為的（ユーザー）エラーからの早急な復旧

• 貴重なデータの削除、間違ったデータの削除、間違った表の削除 など

• アプリケーションミス、誤バッチの実行

• フラッシュバック・テクノロジーの効果

– バックアップからのリカバリが不要！

–非常に簡単

–短時間で復旧

– 過去データの参照が可能！

–不正なデータ改竄に効果

もしもの時のために / フラッシュバックテクノロジー

わんくま同盟 東京勉強会 #36

もしもの時のために / フラッシュバックテクノロジー

フラッシュバック・データベース

フラッシュバック・テーブル

フラッシュバック・ドロップ

フラッシュバック・クエリ

フラッシュバック・バージョン・クエリ

フラッシュバック・トランザクション

データベース全体の復旧

DDLを含む変更の取消

テーブル単位での復旧

テーブル・ドロップ操作の取消

過去データの参照

行データ単位での変更履歴を表示

トランザクション単位での変更履歴と、そのUNDO・SQLを表示

遠い過去データの参照

コンプライアンス・監査

フラッシュバック・データ・アーカイブ

フラッシュバック用途とのマッピング

わんくま同盟 東京勉強会 #36

フラッシュバック・テクノロジーとは

フラッシュバック・テクノロジー は拡張され続けています。

○○○○--フラッシュバック・ドロップ

-

-

-

-

○

○

Oracle11g

SE/SEOne

-

○

○

○

○

○

Oracle10g

EE

○---フラッシュバック・アーカイブ

○---フラッシュバック・テーブル

○---フラッシュバック・データベース

○---フラッシュバック・トランザクション

○○--フラッシュバック・バージョンクエリ

○○○○フラッシュバック・クエリ

Oracle11g

EE

Oracle10g

SE/SEOne

Oracle9i

EE

Oracle9i

SE/SEOne

機能名

わんくま同盟 東京勉強会 #36

Order

Database

Customer

フラッシュバック・データベース

フラッシュバック・ドロップ（ゴミ箱機能）

• データが変更される

フラッシュバック・テーブル（表の中身のリカバリ）

データ・リカバリ系機能

データベース単位でのリカバリ

表単位でのドロップ操作の取消

表単位でのリカバリ

フラッシュバック・テクノロジーとは

わんくま同盟 東京勉強会 #36

データ・リカバリ系機能

DEMO

もしもの時のために / フラッシュバックテクノロジー

わんくま同盟 東京勉強会 #36

Tx 1

Tx 2

Tx 3フラッシュバック・クエリ

フラッシュバック・データ・アーカイブ

フラッシュバック・バージョン・クエリ

フラッシュバック・トランザクション

現在

過去の表データを表示

トランザクション単位での変更履歴

行データ単位での変更履歴

• データの変更はない

過去データ参照系機能

フラッシュバック・テクノロジーとは

わんくま同盟 東京勉強会 #36

過去データ参照系機能

DEMO

もしもの時のために / フラッシュバックテクノロジー

わんくま同盟 東京勉強会 #36

Databaseを運用する上で、こんなことありませんか・・・

• 「間違えて重要なデータを消してしまった！！」

• 「データファイルが壊れた！！」

• 「急に動作が遅くなった！！」

わんくま同盟 東京勉強会 #36

次に多い障害はどれでしょう？

計画

外停

止コンピュータ障害

ストレージ障害

人的エラー

データ破損

サイト障害

データ障害

二番目に多いのがこれ

わんくま同盟 東京勉強会 #36

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

• 障害発生時のダウンタイム

– 障害解析: ダウンタイムの大部分

– 修復処理: ダウンタイムの一部

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

– 障害の早期検出: 損害を最小限に

– 障害原因及び対処を提示: 原因究明、解析時間を最小化

修復に要した時間

障害解析に要した時間

総ダウンタイム

ダウンタイムを最小化

わんくま同盟 東京勉強会 #36

RMAN

Enterprise Manager

インターフェース

データ・リカバリ・アドバイザ実際の手順

ヘルス･モニター

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

③障害情報の表示、修復アドバイスの提示

①DBの状態をチェック

ADR

②ADRに障害

を登録

データベース

ヘルス・チェック

④修復の実行

わんくま同盟 東京勉強会 #36

「リカバリの実行」への画面遷移

わんくま同盟 東京勉強会 #36

リカバリの実行

わんくま同盟 東京勉強会 #36

障害の表示および管理

わんくま同盟 東京勉強会 #36

リカバリ・アドバイス

わんくま同盟 東京勉強会 #36

リカバリ・アドバイスの確認

わんくま同盟 東京勉強会 #36

リカバリ・ジョブの発行

わんくま同盟 東京勉強会 #36

ジョブ・アクティビティリカバリ・ジョブの作成

わんくま同盟 東京勉強会 #36

ジョブ・アクティビティリカバリ・ジョブの完了（ステータスが「成功」の作成済みジョブ）

わんくま同盟 東京勉強会 #36

Databaseを運用する上で、こんなことありませんか・・・

• 「間違えて重要なデータを消してしまった！！」

• 「データファイルが壊れた！！」

• 「急に動作が遅くなった！！」

わんくま同盟 東京勉強会 #36

データベースの自動診断

• データベース自身による稼動情報の収集と自己診断

これまでの稼動監視 DBA がデータベースを監視し、知識と

経験から最適な設定を判断する必要がある

DBA がデータベースを監視し、知識と

経験から最適な設定を判断する必要がある

DBA

・V$.....・DBA_.....

ログ、トレース

STATSPACK OSレベルの情報

Oracle Database 10g以降

ADDM

Oracle 自身がデータベースを監視 / 診断

Oracle 自身がデータベースを監視 / 診断

AWR

診断結果の表示

DBA はOracle のアドバイスを受け入れるかを判断

DBA はOracle のアドバイスを受け入れるかを判断

わんくま同盟 東京勉強会 #36

アドバイザ機能

システムのライフサイクル

SQLチューニング・アドバイザ

SQLアクセス・アドバイザ

UNDOアドバイザ

セグメント・アドバイザ

メモリー・アドバイザ

複数のSQLのアクセス・パスを診断

特定のSQL文の内容、実行計画を診断

UNDOの保存期間やUNDO表領域をアドバイス

縮小すべきセグメントをアドバイス

PGA、SGAのサイズ変更をアドバイス

データベース全体の診断

ADDM

開発（SQL文作成）

単体テスト 統合テスト リリース 運用 領域管理

システム性能維持

開発者の作業 データベース管理者の作業

データベースへのアクセスの最適化

領域の使用方法の最適化

Tuning Pack

わんくま同盟 東京勉強会 #36

Automatic Database Diagnostic Monitor ( ADDM )によるアドバイス

• ボトルネックを特定し、解決方法を推奨します

SQLSQLチューニングチューニングののアドバイザアドバイザを実行を実行

EE

+Diag

パラメータパラメータの変更の変更

わんくま同盟 東京勉強会 #36

ADDM診断レポート例ボトルネック切り分け

チューニングアドバイス

EE

+Diag

わんくま同盟 東京勉強会 #36

SQLチューニング・アドバイザ

• 特定のSQL文の内容、実行計画を診断

• アドバイスの内容– SQL文の修正方法

• WHERE句の条件の指定方法など

– 必要な索引の作成

– SQLプロファイルの作成

※SQLプロファイル– ヒントの集合のようなもので、任意のSQL文の実行計画を生成

– SQL文を書き換えることなくパフォーマンスを向上させるどのSQLに問題があるかを自動的に診断。アプリケーションを書き換えずに、効率のよいSQL実行に変更

TunEE Diag＋

わんくま同盟 東京勉強会 #36

オンライン・セグメント縮小HWMと全件検索

•Oracleは全件検索時、テーブル全体ではなくHigh Water Mark (HWM)

まで走査します。

• INSERT / DELETEが頻繁に発生するテーブルでは必要に応じた

メンテナンスが必要です。

• メリット： テーブルの大きさに対してデータ量が少ない場合、高速に検索できる

• デメリット： 大量削除などでHWM以前の空きが多い場合、実レコード数に比較して時間がかかる

使用領域 未使用領域

HWM

使用領域

走査範囲

未使用領域 未使用領域

使用領域 未使用領域

HWM

走査範囲

わんくま同盟 東京勉強会 #36

オンライン・セグメント縮小HWMを下げる方法

• 対象となる表に（業務的に）アクセスさせない状態で実施：1. 論理バックアップユーティリティ（EMP/IMP） ＋ 元表削除（DROP）

2. CREATE AS SELECT ＋ 元表削除（DROP） ＋ RENAME

3. CREATE AS SELECT ＋ TRUNCATE ＋ INSERT SELECT

4. 表領域の移動 （ALTER TABLE <表名> MOVE TABLESPACE <表領域名>） （8i ～）

• オンライン・セグメント縮小 （10gR1～）

– 業務でテーブルを利用中でもセグメント縮小可能

① ②

データの移動 ＨＷＭの移動

③

領域の解放

alter table <表名> enable row movement;

alter table <表名> shrink space (cascade);

わんくま同盟 東京勉強会 #36

オンライン・セグメント縮小セグメント・アドバイザ

自動セグメント・アドバイザは10gR2～

わんくま同盟 東京勉強会 #36

メモリアドバイザ

• 最適なメモリ量の割り当て（バッファ・キャッシュ・サイズ）

バッファ・キャッシュに必要なサイズ確認

わんくま同盟 東京勉強会 #36

自動メモリー管理（11g）

MEMORY_MAX_TARGET

MEMORY_TARGET

OSメモリー

O/S Memory

SGA

PGA

O/S Memory

SGA

PGA

O/S Memory

SGA

PGA

自動チューニング ALTER SYSTEM SET MEMORY_TARGET=....

わんくま同盟 東京勉強会 #36

もしものトラブルが起きても・・・・

• 「間違えて重要なデータを消してしまった！！」

• 「データファイルが壊れた！！」

• 「急に動作が遅くなった！！」

もう大丈夫ですね！！ Oracleって簡単で安心でしょう？