EMC / Oracle ILM Solution 検証...2007/08/15 · Oracle GRID Center: [EMC / Oracle ILM...

EMC / Oracle ILM Solution 検証

Creation Date: September 25, 2007

Last Update: June 18, 2008

Version: 1.5

Oracle GRID Center: [EMC / Oracle ILM Solution 検証] 1-2

はじめに

ビジネスの成長、CPU データ処理能力の向上、様々なハードウェアデバイスの能力向上、

ソフトウェア機能の拡張や能力の向上、処理するデータの種類の増加、コンプライアンス

遵守のためのデータの蓄積など、様々な要因の元、企業のデータベースに保管されるデー

タの容量は年々増え続けています。一方で、データの増加が引き起こす課題として、保管

場所の拡大、CPU やメモリへの負荷増大によるパフォーマンスの劣化、データ管理作業時

間の増加、バックアップ容量の増加などがあげられます。

これらの問題は従来、ハードウェア・リソースの追加、人的リソースの追加によって解

消されてきました。しかし、このような対処方法では、データが増え続ける限り貴重なリ

ソースを追加し続けねばならず、莫大な費用が積み重なることになります。

これらの問題をより総合的に解決する方法として、情報ライフサイクル管理(Information

Lifecycle Management: ILM)の概念が生まれ、IT ベンダーが提唱し続けてきました。データ

ベースによる ILM は、大規模なデータをアクセス頻度により分類し、それぞれを適切なデ

ィスクへ保管します。つまり通常業務で頻繁にアクセスされる、アクティブなデータは今

まで使ってきた高パフォーマンスなディスクへ、さほどアクセスされない非アクティブな

データは安価なディスクへ保管します。この結果、アクティブなデータの容量は一定容量

に保たれ、かつ通常業務の対象の大部分はこのアクティブなデータであるため、本番運用

のパフォーマンスは高いレベルを保てます。また、企業に保管されるデータの大部分であ

る非アクティブなデータは安価なディスクへ保存されるため、時間の経過によりアクティ

ブから非アクティブへ押し出されたデータが増え続けても、安価なディスクの追加だけで

対応できます。

このホワイトペーパーでは、大規模環境におけるデータベース ILM についての導入から

運用管理、バックアップ/リカバリまでの検証結果を報告します。


謝辞

2006 年 11 月、日本オラクル株式会社は EMC ジャパン株式会社やグリッド戦略パートナ

ー各社と協業体制を確立し、企業のシステム基盤の適化を実現する次世代のビジネス・

ソリューションを構築するため、先鋭の技術を集結した「Oracle GRID Center（オラクル・

グリッド・センター）」( http://www.oracle.co.jp/solutions/grid_center/index.html )を開設しま

した。本稿は、Oracle GRID Center の趣旨にご賛同頂いたインテル株式会社、シスコシステ

ムズ株式会社のハードウェア・ソフトウェアのご提供および技術者によるご支援などの多

大なるご協力を得て作成しております。協賛企業各社およびご協力頂いた技術者に深く感

謝いたします。


目次

はじめに ............................................................................................................................................. 1-2 謝辞 ..................................................................................................................................................... 1-3 目次 ..................................................................................................................................................... 1-4 1. 検証目的 ..................................................................................................................................... 1-6 2. Oracle Database で実現する ILM ........................................................................................... 2-7

2.1. Information Lifecycle Management ( ILM )とは ................................................................................2-7 2.2. データのライフサイクルとストレージの関係 ..............................................................................2-8 2.3. Oracle Partitioning による ILM 導入 .................................................................................................2-8

3. EMC Symmetrix DMX-3 / EMC CLARiX CX3 UltraScale ご紹介................................... 3-11 3.1. Symmetrix DMX-3 ............................................................................................................................3-11 3.2. CLARiX CX3 UltraScale...................................................................................................................3-11 3.3. TimeFinder / SnapView.....................................................................................................................3-12

4. Oracle Partitioning Option ご紹介 ........................................................................................ 4-13 4.1. パーティショニングがもたらす利点 ............................................................................................4-13

4.1.1. パフォーマンスの改善 ..........................................................................................................4-13 4.1.2. 管理性の向上 ..........................................................................................................................4-13 4.1.3. 可用性の向上 ..........................................................................................................................4-14

4.2. パーティショニング方式................................................................................................................4-15 5. 表のオンライン再定義 ........................................................................................................... 5-16 6. 検証環境 ................................................................................................................................... 6-17

6.1. システム構成 ...................................................................................................................................6-17 6.2. ネットワーク構成............................................................................................................................6-19 6.3. 検証に用いた表................................................................................................................................6-20 6.4. パーティション化の方針 / ILM 運用方針....................................................................................6-21

7. 検証内容 ................................................................................................................................... 7-22 7.1. ILM 環境への移行 ...........................................................................................................................7-22 7.2. ILM 環境の運用管理 .......................................................................................................................7-22 7.3. Archive 用デバイスへのパーティション移動 ..............................................................................7-23 7.4. パーティション化の効果と ILM....................................................................................................7-24 7.5. バックアップ/リストア/リカバリ..................................................................................................7-25

8. 検証結果 ................................................................................................................................... 8-26 8.1. ILM 環境への移行 ...........................................................................................................................8-26

8.1.1. INSERT ... SELECT による移行 ............................................................................................8-26 8.1.2. オンライン再定義による移行...............................................................................................8-29 8.1.3. オンライン再定義による移行の留意点 ...............................................................................8-31 8.1.4. 総括 ..........................................................................................................................................8-33

8.2. ILM 環境の運用管理 .......................................................................................................................8-34 8.2.1. オンライン再定義によるパーティション移動 ...................................................................8-34 8.2.2. MOVE PARTITION によるパーティション移動 ................................................................8-36 8.2.3. EXCHANGE PARTITION によるパーティション切り替え ..............................................8-37 8.2.4. 総括 ..........................................................................................................................................8-39

8.3. Archive 用デバイスへのパーティション移動 ..............................................................................8-40 8.3.1. 外部表を用いた移動 ..............................................................................................................8-40


8.3.2. RMAN を用いた移動..............................................................................................................8-42 8.3.3. 総括 ..........................................................................................................................................8-43

8.4. パーティション化の効果と ILM....................................................................................................8-44 8.4.1. パーティション化の効果.......................................................................................................8-44 8.4.2. パーティション化によるストレージの性能格差縮小 .......................................................8-45 8.4.3. パーティション化の効果のまとめ.......................................................................................8-47

8.5. バックアップ/リストア/リカバリ検証環境 ..................................................................................8-48 8.6. バックアップ・サーバーの構築 ....................................................................................................8-50

8.6.1. 本番サーバー(RAC)のデバイスファイル調査 ....................................................................8-50 8.6.2. バックアップ・サーバーでのデバイスファイル作成 .......................................................8-52 8.6.3. 所有者を oracle ユーザーに変更 ...........................................................................................8-53 8.6.4. バックアップ・サーバーにインスタンス作成 ...................................................................8-53 8.6.5. 本番サーバーの制御ファイルの確認...................................................................................8-53 8.6.6. tnsnames の編集.......................................................................................................................8-54 8.6.7. RMAN カタログ作成..............................................................................................................8-54 8.6.8. バックアップ・サーバー用初期化パラメータ・ファイルの作成 ...................................8-55

8.7. バックアップ取得............................................................................................................................8-56 8.7.1. STD から BCV へデータをコピー ........................................................................................8-56 8.7.2. RMAN でバックアップ取得..................................................................................................8-58

8.8. リストア/リカバリ ..........................................................................................................................8-59 8.8.1. 新の状態までのリカバリ...................................................................................................8-59 8.8.2. Point-in-Time リカバリ...........................................................................................................8-60 8.8.3. 総括 ..........................................................................................................................................8-62

9. Appendix................................................................................................................................... 9-63 9.1. Symmetrix TimeFinder の操作方法..................................................................................................9-63 9.2. CLARiX SnapView の操作方法.......................................................................................................9-64

9.2.1. STD と BCV を同期する方法 ................................................................................................9-64 9.2.2. STD と BCV を切り離す方法 ................................................................................................9-64 9.2.3. BCV を STD にリストアする方法 ........................................................................................9-64 9.2.4. STD と BCV の状態およびその他の詳細情報調査する方法.............................................9-64

10. まとめ ................................................................................................................................. 10-65


1. 検証目的

本検証の目的は、EMC Symmetrix / CLARiX と Oracle Database 10g Release 2 の Grid 環境

と Partitioning Option を組み合わせて、統合的な ILM ソリューションを提供可能にすること

です。

ILM 環境への移行および運用手順では、環境の可用性を保った移行と、短時間の移行と

いう 2 つの観点からテストを実施しました。これは本番システムへ求められる可用性のレ

ベル、また移行および運用にかけられる時間により、複数ある中から適な移行方法を選

択できることを目的としています。

ILM の導入対象となるような環境には膨大なデータが存在するため、バックアップ/リカ

バリに要する時間、本番環境への負荷、およびバックアップ用デバイス増設のコストもデ

ータの増加に伴い増加します。本検証では、データの増加に伴いバックアップ取得および

リストアに要する時間が長時間化した場合も本番環境に影響が出ないよう、バックアッ

プ・サーバーおよびストレージの筐体内ミラーを活用しました。またバックアップ用デバ

イス増設のコストを小限にとどめるために、Recovery Manager の差分バックアップを用

い、小限のコストで複数世代のバックアップを管理できるようにしました。これら一連

の操作を行うための環境構築手順も本文書に含まれており、統合的な ILM ソリューション

の一端を担っています。


2. Oracle Database で実現する ILM

業務上の理由、法規制や指針の変更などにより、企業が保存すべきデータ量は増え続け

る一方です。それに伴い、データ増加による物的・人的コストの削減、データの保護、コ

ンプライアンス対策などが、企業の克服しなければならない課題となりました。これら課

題解決の手法として、情報をライフサイクルに合わせて効率的に保存・管理する Information

Lifecycle Management ( ILM ) が注目されています。

2.1. Information Lifecycle Management ( ILM )とは

ILM とは、データの管理及びデータに適用される全ての規則と規制を遵守するこ

となど、データ増加による課題を解決するために、プロセス、ポリシー、ソフトウェ

ア、およびハードウェアを組み合わせ、データライフサイクルの各段階で適したテク

ノロジーを使用できるように設計された概念のことです。

上図の通り、多くのデータは生成直後に頻繁にアクセスされていることが分かりま

す。データは古くなるにつれ、アクセスの頻度は大幅に減少していきます。そのため、

ほとんどの企業では、大部分のユーザーが生成されたばかりの新データにアクセス

し、ごく少数のユーザーが他のデータにアクセスしています。したがってデータは、

そのアクセス頻度に応じて分類できます。

たとえば、受発注をした顧客は、受発注のステータスを定期的に調べ、出荷された

かどうかを確認します。しかし、注文品が届くと、その注文を二度と参照しない場合


があります。また、この注文は、どの商品が注文されているかを確認するために実行

される定期的なレポートに含まれますが、いずれどのレポートにも含まれなくなり、

誰かが、このデータに関連する詳細な分析を行う場合にのみ、参照される可能性があ

ります。

2.2. データのライフサイクルとストレージの関係

データの鮮度によりアクセス頻度が異なるのであれば、それぞれのアクセス頻度に

より適なストレージも異なるはずです。たとえば、アクセスの集中する新数か月

分のアクティブなデータはパフォーマンスの良い高性能ストレージに配置し、低アク

セスなデータは低コストストレージ上へ配置する、などです。図にすると以下のよう

になります。

図中ではアクセスの集中する新データを Active、低アクセスながら更新の発生す

るデータを Less Active、履歴としてのデータであり更新がなくアクセスする人間が限

定的なデータは Historical、法制度上などの理由により長期間保存すべきデータを

Archive と位置づけました。以降の記述ではこの Active / Less Active / Historical /

Archive を用います。

2.3. Oracle Partitioning による ILM 導入

ILM 導入前の状態として、単一のストレージ層を用いている下図のようなデータ

ベースを想定します。つまり巨大な表のデータは、アクセス頻度の高い行も低い行も

混在した状態で単一のストレージ層上に格納されています。


この巨大な表をパーティション化します。Oracle Partitioning の詳細は後述しますが、

パーティション化により大きな表や索引をデータベース内部で複数の領域に分割し

て管理できる一方、ユーザーやアプリケーションからは一つの表に見えるため、デー

タがどこにあるのか意識することなく透過的にアクセスできます。また、表のオンラ

イン再定義という Oracle のメカニズムを用いれば、パーティション表への移行中も、

表の可用性を保つことができます。表のオンライン再定義についての詳細は後述しま

す。

パーティション化後は次図の通り、アクセス頻度に応じてストレージを分けた表に

なります。

パーティション化後もアクセス頻度の高い Active のパーティションは高性能スト


レージ上にあるため、低コストストレージを併用してパーティション化しても一定の

パフォーマンスを得られます。

パーティション化後は運営方針に基づき、下図のように定期的にパーティションを

下位のストレージへ移動させます。これにより、Archive 用デバイス以外のデータは

一定量に保たれ、データの増加に対しても Archive 用デバイスを増やすだけで対応で

きます。

今回の検証では用いませんでしたが、Oracle 8i からの機能である仮想プライベート

データベース（VPD）と組み合わせることにより、アクセス制御を行うこともできま

す。例えば、一般社員では新 1 年分のデータ（Active, Less Active 属性のデータ）し

かアクセスできない一方で、管理者は全てのデータへアクセスできる、というような

構成も可能です。つまり VPD により、表の各行ごとのアクセス制御が可能となるた

め、1 つのデータベース・オブジェクトを複数のユーザーで安全に共有できます。


3. EMC Symmetrix DMX-3 / EMC CLARiX CX3 UltraScale ご紹介

3.1. Symmetrix DMX-3

ストレージ業界に革命をもたらした EMC Symmetrix は、お客様のビジネスに常に

革新と先進的な機能をもたらすストレージ・フラットフォームです。信頼性が高く、

優れた可用性とコスト・パフォーマンスを備えた Symmetrix ストレージは、必要に応

じて迅速かつ容易に拡張が可能です。1990 年以降、7 万システム以上が世界中に出荷

され、あらゆる規模の組織に安定したデータ・アクセス、ビジネス継続性、大規模な

統合をもたらしています。

Symmetrix の DMX モデルから Direct Matrix Architecture（DMA)が設計・導入され

ました。DMA アーキテクチャーでは、チャネル・ダイレクタとグローバル・メモリ

とを直結する高 128 の専用データ・パスを使用しています。パフォーマンスを妨げ

るバスやスイッチは使用していないため、総システムパフォーマンスの大域幅な拡張

性が実現しました。このアーキテクチャーによって、これからの HW の向上、たと

えば CPU、メモリや他の電子部品の能力向上や、ストレージ容量の大幅な拡張には、

Symmetrix は十分に対応できます。DMX モデルがリリースされた後は、DMX-3 そし

て近 DMX-4 もリリースされ、それぞれはモデルには、前のモデルより更なる機能

の拡張やパフォーマンス改善が実施されています。

また、Symmetrix には様々な技術が実装されています。その中の一つは今回の検証

で使用されたストレージ内の高速ミラー技術 TimeFinder です。

3.2. CLARiX CX3 UltraScale

EMC CLARiX システムは、過去 15 年間以上にわたって要件の厳しいサービス・レ

ベルを満たしてきたストレージです。CLARiX システムは小規模からエンタープライ

ズまでのライン・アップを持っています。重要なデータを常時使用可能にするソリュ

ーションを2万5,000社以上の企業に提供してきました。CLARiXシステムはすべて、

実証済みの信頼性/可用性と業界トップレベルのパフォーマンスを低価格で実現し

ています。さらにすべての CLARiX システムにおいて、運用およびアップグレード

を容易に実行することができるほか、先進的なソフトウェアを幅広く利用できるため、

お客様の多様な要件を満たすことが可能です。

同じクラスには比類のない信頼性と可用性 EMC CLARiX の UltraPoint テクノロジ

ーにより、情報の可用性と安全性を常に確保する、独自の高可用性機能とデータ完全


性機能が提供されます。

インテリジェントなテクノロジー（冗長化されたデュアル・ストレージ・プロセッ

サ、ローカル/リモート・レプリケーション、ミラー・メモリ、バッテリ・バックア

ップなど）により、大の信頼性と可用性が実現します。こうしたテクノロジーは高

度な機能によってサポートされますが、その使用方法はシンプルであり、ストレージ

の信頼性と情報の可用性が常に確保されるようになります。

CLARiX にも様々な技術が実装されています。その中の一つが今回の検証で使用さ

れたストレージ内の高速ミラー技術 SnapView です。

3.3. TimeFinder / SnapView

TimeFinder ソフトウェア・ファミリは、Symmetrix DMX 筐体内でのさまざまなデ

ータ・コピー機能を提供する、業界高レベルのローカル・ストレージ・レプリケー

ション・ソリューションです。Symmetrix のハイエンド・ストレージ・アーキテクチ

ャを活用し、展開における優れた柔軟性と高度な拡張性により、お客様は運用への影

響を小限に抑えつつ、複雑なサービス・レベル要件に対応できます。も幅広く採

用されているハイエンド・ローカル・レプリケーション・ソリューションである

TimeFinder ファミリは、全世界の要求の厳しい環境に導入されており、その数は数万

件にものぼります。また、ストレージ・システム間で整合性を維持し、自動管理によ

ってストレージ機能を強化し、業界の主要アプリケーションと緊密に統合されるアプ

リケーションが TimeFinder ファミリです。

SnapView ソフトウェア・ファミリも、CLARiX 筐体内でのさまざまなデータ・コ

ピー機能を提供する、ハイ・レベルのローカル・ストレージ・レプリケーション・ソ

リューションです。EMC SnapView を使用すると、バックアップ・ウィンドウを短縮

しつつ、アプリケーションの可用性を向上させることができます。SnapView ソフト

ウェアはテスト、バックアップ/リカバリに使用可能なデータのポイント・イン・タ

イム・コピーをローカルに作成します。SnapView では、新たに追加された Consistent

Split 機能により、ローカル・レプリケーションのあらゆるニーズに対し、データの

一貫性を確実に維持できます。また、ポインタ・ベースの省ディスクスペース型スナ

ップショットと高機能でフル・ボリュームのクローンを作成する柔軟性により、運用

への影響を小限に抑えつつ、複雑なサービス・レベルに対応できます。


4. Oracle Partitioning Option ご紹介

Oracle Partitioning（Oracle 8i からの機能）を利用すると、表、索引、及び索引構成表を細

分化して、これらのデータベース・オブジェクトを詳細に管理し、アクセスすることがで

きます。また、アプリケーションの視点からは、パーティション化された表はパーティシ

ョン化されていない表と変わらず、SQL を使用してパーティション化した表にアクセスす

る場合でも一切変更する必要がありません（下図参照）。

パーティショニングは、管理性、性能、及び可用性を改善して、さまざまなアプリケー

ションに大きな利点を提供することができます。またオラクルでは、すべてのビジネス要

件に適合する総合的なパーティショニング方式を提供しているため、あらゆる場面での使

用が可能です。

Oracle Partitioning

4.1. パーティショニングがもたらす利点

4.1.1. パフォーマンスの改善

パーティション・プルーニング

対象のデータが格納されているパーティションだけにアクセスし、不要なパ

ーティションを読み飛ばすことで、効果的な性能改善が可能です。

パーティション・ワイズ結合

大きな結合を各パーティションの間で実行される小さな結合にパーティシ

ョン化し、複数表の結合性能を改善することが可能です。

4.1.2. 管理性の向上

分割統治方式

パーティション化により、管理が行いやすいように表や索引を細分化するこ

とが可能です。たとえば、表全体をバックアップする代わりに、表の単一パー

ティションだけをバックアップすることができるように、データベース全体に

大大ききなな表表やや索索引引ををデデーータタベベーースス内内部部でで複複数数のの領領域域にに分分割割ししてて管管理理すするる

通常の１つの表パーティション化された表

内部的に表を分割

ユユーーザザややアアププリリケケーーシショョンンかかららはは一一つつのの表表にに見見ええるる


渡るメンテナンス操作をパーティション単位で実行することが可能となりま

す。

ローリング・ウィンドウ方式

管理のためのパーティション化の典型的な使用方法は、データ・ウェアハウ

スにおける“ローリング・ウィンドウ”方式のロード・プロセスのサポートで

す。たとえば、月単位のパーティショニングを行った表に、新たに 1 ヶ月分の

データをロードする場合のプロセスは、単に新しいパーティションの追加のみ

で済みます。これは、全体を変更するよりはるかに効率的に実施可能です。さ

らに、データを消去する場合においては、大量のリソースを使用する DELETE

コマンドを発行するのではなく、簡単で高速なデータ・ディクショナリ操作で

あるパーティションの削除により実施可能です（下図参照）。

ローリング・ウィンドウ方式

4.1.3. 可用性の向上

パーティション単位での障害の局所化

パーティション化されたデータベース・オブジェクトは、高可用性戦略の重

要な部分であるパーティションの独立性を提供します。たとえば、表の中で 1

つのパーティションが使用できない場合でも、その他すべてのパーティション

はオンラインで使用でき、使用できないパーティションにアクセスする必要が

ない場合、パーティション表に対する問合せやトランザクションは正常に実行

されます。

月単位のパーティショニングきまったある月数分保持する

DELETEよりも高速

DROP PARTITION ADD PARTITION

データロード

表全体の構成を変更

する必要がない


4.2. パーティショニング方式

Oracle Partitioning は、個別の各種パーティションに配置されるデータの移動を制御

する、以下の 3 つの基本的なデータ分散方法を提供しています。

レンジ：パーティション・キーの値の範囲に基づいて、データが分散されま

す。たとえば、表のパーティション・キーが日付列の場合、'January2007'のパ

ーティションに、2007 年 1 月のデータを含むように指定すれば、'01-JAN-2007'

から'31-JAN-2007'の値を持つ列が含まれます。データの分散は、途切れるこ

となく連続して行われ、レンジの下限は、先行するレンジの上限によって自

動的に定義されます。

リスト：データの分散が、パーティション・キーの値のリストによって定義

されます。たとえば、表のパーティション・キーが地域列の場合、各地域に

含まれる国名を指定すれば、'North America'のパーティションには、'Canada'、

'USA '、'Mexico'の値が含まれます。また、特殊な“デフォルト”パーティシ

ョンを定義して、リストで明示的に定義されていないパーティション・キー

のすべての値を取得できます。

ハッシュ：ある行のパーティションを決定するために、ハッシュ・アルゴリ

ズムがパーティション・キーに適用されます。他の 2 つのデータ分散方法と

は異なり、データとパーティションの論理的なマッピングは行われません。

また、2 つのデータ分散方法を組み合わせて、コンポジット・パーティション化さ

れた表を定義することができます。初に、データ分散方法 1 を使用して、表のパー

ティション化を行います。次に、2 番目のデータ分散方法を使用して、各パーティシ

ョンをサブパーティションに分割します。特定のパーティションにおけるすべてのサ

ブパーティションは、データの論理的なサブセットを表しています。たとえば、レン

ジ-ハッシュでコンポジット・パーティション化される表は、初にレンジ・パーテ

ィション化され、次に、ハッシュ・パーティション化を実施することで、各レンジ・

パーティションがサブパーティション化されます。

本検証では Oracle Database 10g を用いましたが、Oracle Database 11g ではパーティ

ショニングにおいて多くの機能拡張があります。コンポジット・パーティション化に

ついても上記の組み合わせのみではありません。詳しくはホワイトペーパー「Oracle

Database 11g におけるパーティション化」をご覧下さい。


5. 表のオンライン再定義

Oracle Database には、表の可用性に影響を与えずに表の構造を変更できるメカニズムが

用意されています。このメカニズムは表のオンライン再定義（以降、「オンライン再定義」）

と呼ばれます。オンライン再定義では、表の定義を変更する従来の方法に比べて、可用性

が大幅に向上します。

オンライン再定義を用いて表の定義を変更している間も、その再定義プロセスの大部分

で、問い合わせ及び DML を使用してその表にアクセスできます。表が排他モードでロック

されるのは、そのサイズや再定義の複雑さに関係なくわずかな間のみで、ユーザーに対し

ては完全に透過的です。

表のオンライン再定義には、再定義の対象となる表が使用している領域とほぼ同等の空

き領域が必要です。新しい列を追加する場合は、より多くの領域が必要になります。

表のオンライン再定義を実行するには、Enterprise Manager のオブジェクトの再編成ウィ

ザードまたは DBMS_REDEFINITION パッケージを利用します。

DBMS_REDEFINITION パッケージの実行権限は EXECUTE_CATALOG_ROLE に付与さ

れ、実行ユーザーはこのパッケージの実行権限のほかに、次の権限が付与されていること

が必要です。

· CREATE ANY TABLE

· ALTER ANY TABLE

· DROP ANY TABLE

· LOCK ANY TABLE

· SELECT ANY TABLE

表のオンライン再定義については、以下のマニュアルに詳細な記載があるので、こちら

も合わせてご覧下さい。

Oracle Database 管理者ガイド 10g リリース 2（10.2）部品番号: B19224-02

15 表の管理


6. 検証環境

6.1. システム構成

システム構成の詳細は以下の通りです。

· データベース・サーバー

機種 NEC NX7000 rp2470-2-1

CPU PA-RISC 8700 750 MHz

2 Processors / server

メモリ 2GB

OS HP-UX 11.11 64-bit

Oracle Oracle Database 10g Enterprize Edition 10.2.0.3

Oracle Real Application Clusters 10g 10.2.0.3


· ストレージ

機種 Symmetrix DMX 1000

ハードディスク

RAID グループ構成

1.1 TB(11GB * 100 本)

1.2 FC: Raid 0/1

ソフトウェア Enginuity, TimeFinder, Solutions Enabler, PowerPath

機種 CLARiX CX3-80

ハードディスク

RAID グループ構成

100GB ATA: Raid5 (4+1)

500GB ATA: Raid5 (8+1)

ソフトウェア Flare, SnapView, Navisphere, PowerPath

機種 CUA/Centera

ハードディスク 500GB ATA

ソフトウェア Centera Universal Access

· ネットワーク・スイッチ

機種 Dell PowerConnect 2024

· スイッチング・ハブ

機種 Buffalo Giga


6.2. ネットワーク構成

ネットワーク構成は以下の通りです。

Interconnect: 100 Mbps

VIP/Public IP 100 Mbps


6.3. 検証に用いた表

本検証では、ILM 導入の初のステップとして既存の非パーティションをレンジ・

パーティション化することを想定しました。既存の非パーティション表として、本検

証では一般的なオンラインショップの受注表を想定しました。受注表を用いたのは、

受注履歴のような、時間の経過とともにデータの増える表は ILM 導入に適している

からです。

通常、表の巨大化には、パフォーマンスの劣化、表を格納しているストレージの増

設および管理のコスト、データベース・メンテナンスの作業時間の増加が伴います。

パフォーマンスの劣化を軽減するために高性能ストレージ上へ全データを格納して

いる場合、ストレージ増設のコストは莫大であり、データ増への対応として限界があ

ります。

ILM の導入により、時間の経過とともに表が巨大になったとしても、新データ

へのアクセスパフォーマンスを良い状態に保ち、かつデータ増に伴うコストを小限

に抑えることができます。これは前項で述べた Oracle Partitioning の技術により、表

データを複数のストレージ上へ分けて格納でき、かつ表を複数のパーティションに分

けられることで管理および操作が容易になるからです。

本検証が非パーティション表として想定した受注表の詳細は以下の通りです。

· ORDERITEM 表

2002 年 1 月から 2008 年 12 月までの 7 年分のデータ

ORDERKEY と LINENUMBER の複合主キー

総レコード数は約 20 億件(約 263GB)で、

全データは Symmetrix(高性能ストレージ)上

カラムは次表の通り

SHIPDATE NOT NULL DATE ORDERKEY NOT NULL NUMBER DISCOUNT NOT NULL NUMBER EXTENDEDPRICE NOT NULL NUMBER SUPPKEY NOT NULL NUMBER QUANTITY NOT NULL NUMBER RETURNFLAG CHAR(1) PARTKEY NOT NULL NUMBER LINESTATUS CHAR(1) TAX NOT NULL NUMBER COMMITDATE DATE RECEIPTDATE DATE SHIPMODE CHAR(10) LINENUMBER NOT NULL NUMBER SHIPINSTRUCT CHAR(25) COMMENT VARCHAR2(44)


6.4. パーティション化の方針 / ILM 運用方針

先述の非パーティション表を、DATE 型である SHIPDATE カラムをパーティショ

ン・キーとし、1 ヶ月単位でレンジ・パーティション化します。1 パーティションに

対し 1 表領域を割り当て、ローカル索引の各パーティションは、表の各パーティショ

ンと同じ表領域に格納します。

· 参考値：1 パーティション(1 ヶ月)サイズ…約 2700 万件(約 3.4GB)

非パーティション表をパーティション表へ移行する際、各パーティションへのアク

セス頻度に応じ、適切なストレージ上へデータを移動します。たとえば新 3 ヶ月分

のデータは頻繁にアクセスがあると想定されるため、高性能ストレージへ配置する一

方、更新することはないものの履歴として保存しておくべき 5 年前のデータは低コス

トストレージへ配置する、などです。

本検証においては下表の運用方針に基づきデータを配置しました。尚、この運用方

針は一例に過ぎず、お客様の環境やシステム要件等を考慮し、決定することを推奨し

ます。

ストレージクラス R / W 保持期間 ORDERITEM 表

対象データ

Active Read / Write ～3 ヶ月 2008.10-12 Symmetrix

Less Active Read / Write 3 ヶ月～1 年 2008.01-09

CLARiX Historical Read Only 1 年～6 年 2003.01-2007.12

Centera Archive Read Only 6 年～ 2002.01-12

表を図にすると以下のようになります。


7. 検証内容

ILM 導入から運用に至るまでに必要と想定される以下の項目について検証を行いました。

7.1. ILM 環境への移行

ILM 導入の初のステップとして、先述の ILM 運用方針に沿って既存の非パーテ

ィション表をパーティション化します。

非パーティション表をパーティション化する方法として、本検証では以下 2 つの方

法をテストしました。

1. 移行する表の表領域を READ ONLY にできる場合

システムを計画停止するなどして、パーティション表へ移行させる表の表領

域を READ ONLY にできる場合は、INSERT … SELECT による移行が便利です。

この方法では、該当の表領域を READ ONLY にしなければならない時間がある

一方で、再定義と比較すると短時間で移行作業が完了します。

2. 移行する表の表領域を READ ONLY にできない場合

システムを計画停止できないなど、パーティション表へ移行させる表の表領

域を READ ONLY にできない場合は、オンライン再定義を用いてパーティショ

ン化します。この方法では、パーティション表への移行作業中も、作業の大部

分において表に対する参照及び DML を実行可能です。また表が排他ロックさ

れるのは移行の規模や複雑さに関係なくわずかな間のみです。

7.2. ILM 環境の運用管理

ILM 導入後の運用において、時間の経過とともに古くなったパーティションを、

現在のアクセス頻度に適したストレージ上へ移動させるという操作が定期的に発生

すると考えられます。アクセス頻度の減ったデータを定期的に低コストなデバイスへ

移動させることにより、高性能ストレージ上のデータが増えすぎることを回避し、全

体のデータが増え続けたとしても下位クラスの安価なデバイスを追加することで対

処できます。

本検証においては以下 3 つの方法でパーティション移動のテストを行いました。

1. 移動させるパーティションを READ ONLY にできない場合

移動させるパーティションを READ ONLY にできない場合は、オンライン再

定義を用いてパーティションを移動します。この方法では、パーティションの

移動作業中も、移動中のパーティションの参照、及び DML 文は実行可能です。

2. 移動させるパーティションを READ ONLY にできる場合

(a) 移動させるパーティションを READ ONLY にできる場合

ALTER TABLE ... MOVE PARTITION 文によってパーティションを移動する


方法が簡単です。MOVE PARTITION 中は対象のパーティションを READ ONLY

にし、移動前後の一貫性を保つ必要があります。

(b) 移動させるパーティションを READ ONLY にできる場合

MOVE PARTITION に比べ操作が複雑ですが、移動させるパーティションを

READ ONLY にできるのであれば EXCHANGE PARTITION 文を使ってパーテ

ィションを切り替える方法も用いることができます。切り替えるための仮表へ

データを挿入中は、移動させるパーティションを READ ONLY にする必要があ

ります。

7.3. Archive 用デバイスへのパーティション移動

Archive 用デバイスへのパーティション移動も前項、ILM 環境の運用管理の一部で

すが、操作方法が大きく異なるため特記します。

Historical 用ストレージに保存する期間以上のデータは、Archive 用の安価なデバイ

スへ移動させます。本検証では運用方針に基づき、6 年間以上経過したデータについ

ては WORM（Write Once Read Many）デバイスへ移行し、コスト削減と同時にコンプ

ライアンス遵守も担保しました。

WORM デバイスへ移動するデータをパーティション表からアンロードするのか、

パーティション表の一部として扱うのか、という観点から、以下 2 つのテストを行い

ました。

1. データをパーティション表からアンロードする場合

ORACLE_DATAPUMP アクセスドライバを使用し、外部表としてパーティシ

ョンのデータをローカルディスク上のダンプファイルへアンロードします。ア

ンロードしたパーティションを削除して、ダンプファイルを WORM デバイス

へコピーします。アンロード済みのデータを参照する時は、WORM デバイス

上のダンプファイルを参照するような外部表を再作成します。

元のパーティション表の一部として、アーカイブデータを含めなくても良い

場合はこの方法が便利です。

2. パーティションの一部として移動させる場合

WORM デバイス上にあるデータも元のパーティション表の一部として参照

できるようにしたい場合は、Recovery Manager(RMAN)によりデータファイルを

ASM から抽出する方法を用います。具体的には RMAN を用いて ASM から移

行するパーティションの属す表領域のデータファイルを抽出し、生成したデー

タファイルを WORM デバイスへコピーします。その後、データファイルをリ

ネームし、表領域が WORM デバイス上のデータファイルを参照するようにし

ます。

RMAN を用いた方法では、どんなに古いデータであっても参照する際データ


の場所を意識する必要がありません。そのかわり WORM デバイス上のパーテ

ィションについてはバックアップ対象外にする必要があるため、追加の操作が

発生します。

WORM デバイス上のデータを含む SQL 文を発行する場合、デバイスの性能

によっては結果が戻るまでに時間がかかることがあります。

7.4. パーティション化の効果と ILM

ILM 環境への移行及び ILM 環境の運用により、非パーティション表の全データが

Symmetrix にあったのに対し、パーティション表は ILM 運用方針に沿って Symmetrix

と CLARiX 上にデータが配置されている状態となりました。

今回用いたような一般的な受注表では、パーティション・キーとして用いた shipdate

によって範囲を指定した参照が多いと想定されます。たとえば一定期間における売上

額の計算や、ある日付の受注発送ステータスの問い合わせなどです。したがって、非

パーティション表とパーティション表に対し、次のような索引を使わないクエリーで

実行時間を計測しました。

SQL>SELECT SUM(extendedprice * discount) AS revenue FROM orderitem WHERE shipdate >= date '2007-01-01' AND shipdate < date '2007-02-01' ;


7.5. バックアップ/リストア/リカバリ

ストレージのミラー機能と RMAN を組み合わせて、より効率的なバックアップ/

リストア/リカバリを実現します。

バックアップ/リストア/リカバリの検証を行うには、本番環境の RAC とは完全に

独立したバックアップ取得（RMAN 起動）用のサーバー（以降、バックアップ・サ

ーバー）が必要になります。本検証では、4 ノード RAC 構成だった環境を 3 ノード

RAC にし、クラスタから削除した 1 ノードをシングル DB として再構築しました。

または、4 ノード RAC 構成はそのまま残し、新たに 1 ノード追加してバックアップ・

サーバーに用いても構いません。どちらにするかは、お客様の環境やシステム要件等

を考慮し、決定することを推奨します。

1. バックアップ・サーバーの環境構築

バックアップ・サーバーを用いるための環境を構築します。パス設定、イン

スタンス作成、RMAN 設定などがここに含まれます。

2. バックアップ

ストレージのミラー機能により、バックアップ用ボリューム(以下 BCV)へ本

番データ用ボリューム(以下 STD)をコピーした後、バックアップ・サーバー上

で RMAN を起動し BCV のバックアップを取得します。バックアップ・サーバ

ーの活用により、本番環境へのバックアップによる負荷を軽減できます。

3. リストア/リカバリ

新の状態へ戻す場合は、ストレージのミラー機能を用いて BCV のデータ

を STD へリストアし、リストア開始後すぐに本番環境でリカバリも開始しま

す。BCV から STD へのリストア完了を待つことなくリカバリを開始できるた

め、ダウンタイムを軽減できます。

Point-in-Time リカバリの場合は、バックアップ保存用ディスクから BCV へ、

取得したバックアップピース RMAN を用いて戻します。その後 BCV 上へ

RMAN でリストアされたデータをストレージのミラー機能を用いて BCV から

STD へリストアします。新の状態へ戻す場合と同様、BCV から STD へのリ

ストア開始後に完了を待たずにリカバリを開始します。

なお、Archive 用デバイスのデータについては、本検証では WORM デバイス

を使用したためバックアップ対象外としました。


8. 検証結果

検証の結果、および検証で用いた具体的なコマンドを以下に記述します。

なお、本検証において用いた表およびユーザーは以下の通りです。

· ILM 環境へ移行対象の表：ORDERITEM

· ORDERITEM 表のスキーマ：SHOPMSTR

8.1. ILM 環境への移行

8.1.1. INSERT ... SELECT による移行

INSERT ... SELECT による移行の手順は以下の通りです。

(1) パーティション表のための表領域を作成

(2) 空のパーティション表を作成

(3) 非パーティション表が格納されている表領域を READ ONLY に変更

(4) 非パーティション表のデータを(2)へ挿入

(5) (2)にローカル索引作成

(6) (2)に一意キー制約を追加

(7) 非パーティション表が格納されていた表領域を READ WRITE に変更し、非

パーティション表を"削除

(8) (2)を、(6)で削除した非パーティション表の表名へリネームする

コマンドは次の通りです。

(1) パーティション表を格納するための表領域を作成します。DBA 権限のユー

ザーで行います。

SQL> CREATE TABLESPACE tbs200301 DATAFILE '+DATA_DG2' SIZE 5G; SQL> CREATE TABLESPACE tbs200302 DATAFILE '+DATA_DG2' SIZE 5G; …(中略)… SQL> CREATE TABLESPACE tbs200810 DATAFILE '+DATA_DG1' SIZE 5G; SQL> CREATE TABLESPACE tbs200811 DATAFILE '+DATA_DG1' SIZE 5G; SQL> CREATE TABLESPACE tbs200812 DATAFILE '+DATA_DG1' SIZE 5G;

作成した表領域を、オンライン再定義実行ユーザーが使用できるようにしま

す。DBA 権限のユーザーで行います。

SQL> ALTER USER SHOPMSTR QUOTA UNLIMITED ON tbs200301; SQL> ALTER USER SHOPMSTR QUOTA UNLIMITED ON tbs200302; …(中略)… SQL> ALTER USER SHOPMSTR QUOTA UNLIMITED ON tbs200810; SQL> ALTER USER SHOPMSTR QUOTA UNLIMITED ON tbs200811; SQL> ALTER USER SHOPMSTR QUOTA UNLIMITED ON tbs200812;


(2) 空のパーティション表 int_orderitem を作成します。SHOPMSTR ユーザーで

行います。作成するパーティション表の定義(列の順序、データ型など)は、非パ

ーティション表と同一でなければなりません。なお、maxvalue を指定すると、

その後の partition の追加ができなくなってしまうため指定しないで下さい。

SQL> CREATE TABLE int_orderitem( shipdate date, orderkey number NOT NULL, discount number NOT NULL, extendedprice number NOT NULL, suppkey number NOT NULL, quantity number NOT NULL, returnflag char(1), partkey number NOT NULL, linestatus CHAR(1), tax number NOT NULL, commitdate date, receiptdate date, shipmode CHAR(10), linenumber number NOT NULL, shipinstruct CHAR(25), comment VARCHAR2(44) ) PARTITION by range (shipdate) ( PARTITION testpt200201 values less than (to_date('2002-02-01','YYYY-MM-DD')) TABLESPACE tbs200201, PARTITION testpt200202 values less than (to_date('2002-03-01','YYYY-MM-DD')) TABLESPACE tbs200202, …(中略)… PARTITION testpt200810 values less than (to_date('2008-11-01','YYYY-MM-DD')) TABLESPACE tbs200810, PARTITION testpt200811 values less than (to_date('2008-12-01','YYYY-MM-DD')) TABLESPACE tbs200811, PARTITION testpt200812 values less than (to_date('2009-01-01','YYYY-MM-DD')) TABLESPACE tbs200812);

上記例では、6.4 パーティション化の方針 / ILM 運用方針に基づき、パーテ

ィション・レンジを 1 ヶ月間、またパーティション１つに対し表領域を 1 つ割

り当てていますが、これらは、お客様の環境やシステム要件等を考慮し、決定

することを推奨します。

1 パーティションに対し 1 表領域を割り当てたのは、ILM 運用管理における

パーティションの移動の際に、採用する移動方法によってはパーティションが

格納されている表領域を READ ONLY にする必要があるからです。READ

ONLY にできるのは表領域単位であるため、パーティションの移動単位で表領

域を割り当てる必要があります。

(3) 非パーティション表が格納されている表領域をREAD ONLYに変更します。

DBA 権限のユーザーで行います。この作業は(3)のデータ挿入中に、参照元であ

る非パーティション表に対し DML 文が実行されることでデータの差分が生じ

るのを防ぐために行います。下例では非パーティション表が USERS 表領域に格


納されている場合を示します。

SQL> ALTER TABLESPACE USERS READ ONLY;

(4) 非パーティション表のデータを(1)で作成した空のパーティション表へ挿入

します。SHOPMSTR ユーザーで行います。ヒント文 /*+ APPEND */ を加える

と、バッファキャッシュを使用せず直接データファイルへ書き込むダイレクト

ロードインサートが行われるため、insert にかかる時間が短縮されます。

SQL> INSERT /*+ APPEND */ INTO int_orderitem SELECT * FROM orderitem; COMMIT;

(5) パーティション表へローカル索引を作成します。SHOPMSTR ユーザーで行

います。ローカル索引を作成する際は必ずパーティション・キーを含む必要が

あります。

SQL> CREATE INDEX line_local_idx ON int_orderitem(orderkey, linenumber, shipdate) local;

(6) パーティション表に対し一意キー制約を追加します。SHOPMSTR ユーザー

で行います。本検証の非パーティション表は orderkey と linenumber の複合主キ

ーであるため、(4)で作成したローカル索引を使用し制約を追加しました。索引

を指定しない場合は、ローカル索引とは別に orderkey と linenumber のグローバ

ル索引がユーザーのデフォルト表領域に作成されます。

SQL> ALTER TABLE ORDERITEM ADD CONSTRAINT PK_LINE PRIMARY KEY (ORDERKEY,LINENUMBER) USING INDEX;

(7) 非パーティション表が格納されていた表領域を READ WRITE へ変更し、非

パーティション表を削除します。DBA 権限のユーザーで行います。

SQL> ALTER TABLESPACE USERS READ WRITE; SQL> DROP TABLE orderitem;

(8) パーティション表を、(6)で削除した非パーティション表の表名へリネーム

します。SHOPMSTR ユーザーで行います。

SQL> RENAME int_orderitem TO orderitem;

以上で INSERT ... SELECT による移行は完了です。

パラレルで実行することにより、移行中のデータ挿入、および索引の作成の時

間を短縮できることがあります。手順の(3)、(4)を実行する前に下記の ALTER

SESSION 文を SHOPMSTR ユーザーで実行します。<para>には環境に適した数値


を入力してください。

SQL> ALTER SESSION FORCE PARALLEL DML PARALLEL <para>; SQL> ALTER SESSION FORCE PARALLEL DDL PARALLEL <para>;

8.1.2. オンライン再定義による移行

オンライン再定義を行うにあたり、SHOPMSTR ユーザーに以下の権限が必要と

なります。

· DBMS_REDEFINITION パッケージの実行権限

· CREATE ANY TABLE

· ALTER ANY TABLE

· DROP ANY TABLE

· LOCK ANY TABLE

· SELECT ANY TABLE

具体的には、DBA 権限ユーザーで以下のような SQL 文を実行します。

SQL > grant execute on dbms_redefinition to shopmstr; SQL > grant create any table to shopmstr; SQL > grant alter any table to shopmstr; SQL > grant drop any table to shopmstr; SQL > grant lock any table to shopmstr; SQL > grant select any table to shopmstr;

オンライン再定義による移行の手順は以下の通りです。

(1) パーティション表のための表領域を作成

(2) 非パーティション表(元表)がオンラインで再定義可能か確認。

(3) 移行用のパーティション表(仮表)を作成。

(4) オンライン再定義を開始

(5) 仮表に対してローカル索引を作成

(6) 元表と仮表の差分を同期

(7) オンライン再定義を終了

(8) 元表を削除

コマンドは次の通りです。(1)以外は全て SHOPMSTR ユーザーで行います。

(1) パーティション表を格納するための表領域を作成します。DBA 権限のユー

ザーで行います。手順は、8.1.1 INSERT ... SELECT による移行と同じです。

(2) 非パーティション表(以降、”元表”)がオンラインで再定義可能か確認します。


SQL> BEGIN DBMS_REDEFINITION.CAN_REDEF_TABLE( UNAME => 'SHOPMSTR', TNAME => 'ORDERITEM', OPTIONS_FLAG => DBMS_REDEFINITION.CONS_USE_PK, PART_NAME => NULL); END;/

(3) 移行用のパーティション表(以降、”仮表”)を作成します。仮表の定義は元表

と同一でなければなりません。SQL 文は8.1.1 INSERT ... SELECT による移行と

同じです。

(4) オンライン再定義を開始します。本検証では元表に主キーがあるため、使

用する再定義方法のタイプを指定するパラメータの OPTION_FLAG で、主キー

（DBMS_REDEFINITION.CONS_USE_PK）を指定しています。

SQL> BEGIN DBMS_REDEFINITION.START_REDEF_TABLE( UNAME => 'SHOPMSTR', ORIG_TABLE => 'ORDERITEM', INT_TABLE => 'INT_ORDERITEM', COL_MAPPING => NULL, OPTIONS_FLAG => DBMS_REDEFINITION.CONS_USE_PK, PART_NAME => NULL); END;/

(5) 仮表に対しローカル索引を作成します。SQL 文は8.1.1 INSERT ... SELECT

による移行と同じです。

(6) (3)、(4)の実行中に生じた元表と仮表の差分を同期します。この操作は(6)の

FINISH_REDEF_TABLE を実行するまで何度行っても構いません。

SYNC_INTERIM_TABLE を実行することにより、FINISH_REDEF_TABLE を短

時間で完了できます。

SQL> BEGIN DBMS_REDEFINITION.SYNC_INTERIM_TABLE( UNAME => 'SHOPMSTR', ORIG_TABLE=> 'ORDERITEM', INT_TABLE => 'INT_ORDERITEM', PART_NAME => NULL); END;/

(7) オンライン再定義を終了します。このプロシージャによって元表と仮表の

表名がリネームされます。ディクショナリが書き換えられるわずかな間、表が

ロックされます。FINISH_REDEF_TABLE でも内部的に元表と仮表の同期が行

われています。


SQL> BEGIN DBMS_REDEFINITION.FINISH_REDEF_TABLE( UNAME => 'SHOPMSTR', ORIG_TABLE=> 'ORDERITEM', INT_TABLE => 'INT_ORDERITEM', PART_NAME => NULL); END;/

(8) 元表を削除します。元表と仮表の表名が入れ替わっているため、削除する

表の名前は(2)で作成した仮表の名前であることに注意してください。

SQL> DROP TABLE INT_ORDERITEM;

オンライン再定義による移行は以上です。

8.1.3. オンライン再定義による移行の留意点

START_REDEF_TABLE 実行後から FINISH_REDEF_TABLE 実行までの間に、オ

ンライン再定義を中断したい場合は、ABORT_REDEF_TABLE を実行します。こ

のプロシージャにより。再定義プロセスの中で作られたオブジェクトが全て削除

されます。

SQL> BEGIN DBMS_REDEFINITION.ABORT_REDEF_TABLE( UNAME => 'SHOPMSTR', ORIG_TABLE=> 'ORDERITEM', INT_TABLE => 'INT_ORDERITEM', PART_NAME => NULL); END;/

オンライン再定義の処理をパラレル化すると実行時間を短縮できる場合があり

ます。手順の(3)、(4)を実行する前に SHOPMSTR ユーザーで下記の ALTER

SESSION 文を実行します。<para>には環境に適した数値を入力してください。

SQL> ALTER SESSION FORCE PARALLEL DML PARALLEL <para>; SQL> ALTER SESSION FORCE PARALLEL DDL PARALLEL <para>;

使用するマシンのスペックによっては、大規模な表をオンライン再定義中に、

再定義する表に対して DML 文が大量に実行されると、SYNC_INTERIM_TABLE、

FINISH_REDEF_TABLE 実行中に一時表領域を大量に使う可能性があります。本検

証では 270GB の表の再定義中に 4GB 分のレコードに対し DELETE / UPDATE /

INSERT 文を実行しましたが、使用した一時表領域は 120GB から 170GB となりま

した。一時表領域が足りない場合、 SYNC_INTERIM_TABLE 、

FINISH_REDEF_TABLE の実行中にエラーとなり、オンライン再定義を完了させる

ことができません。

この場合、一時表領域を追加して FINISH_REDEF_TABLE を再度実行すれば、


オンライン再定義を終了できます。つまり abort_redef_table により再定義を中断し

て再び CAN_REDEF_TABLE からやり直す必要はありません。

オンライン再定義による移行を行う際は事前に十分な検証を行ってください。

事前検証の際、以下のような sql 文によって一時表領域の使用量を監視し、また

sar コマンド等によって CPU の使用状況を監視することをおすすめします。

set echo off set timing off set time on col name for a10 col "Size (M)" for a15 col "HWM (M)" for a15 col "HWM % " for a15 col "Using (M)" for a15 col USERNAME for a8 col TABLESPACE for a10 col CONTENTS for a10 col SQL_TEXT for a45 set lines 120 SELECT d.tablespace_name "Name", TO_CHAR(NVL(a.bytes / 1024 / 1024, 0),'99,999,990.900') "Size (M)", TO_CHAR(NVL(t.hwm, 0)/1024/1024,'99999999.999') "HWM (M)", TO_CHAR(NVL(t.hwm / a.bytes * 100, 0), '990.00') "HWM % " , TO_CHAR(NVL(t.bytes/1024/1024, 0),'99999999.999') "Using (M)", TO_CHAR(NVL(t.bytes / a.bytes * 100, 0), '990.00') "Using %" FROM sys.dba_tablespaces d, (select tablespace_name, sum(bytes) bytes from dba_temp_file group by tablespace_name) a, (select tablespace_name, sum(bytes_cached) hwm, sum(bytes_used) bytes from v$temp_extent_pool group by tablespace_name) t WHERE d.tablespace_name = a.tablespace_name(+) AND d.tablespace_name = t.tablespace_name(+) AND d.extent_management like 'LOCAL' AND d.contents like 'TEMPORARY'; SELECT S.USERNAME, S.SID, Q.SQL_TEXT, U.TABLESPACE, U.CONTENTS, U.EXTENTS, U.BLOCKS FROM V$SESSION S, V$SORT_USAGE U, V$SQL Q WHERE S.SADDR = U.SESSION_ADDR and Q.ADDRESS = S.SQL_ADDRESS AND Q.HASH_VALUE = S.SQL_HASH_VALUE;

一時表領域使用率である”Using %”が 100％になる前に領域の追加を行う（例

えば、80％を超えた時点で追加する）ことで、エラーが返ることなく処理を続け

ることができます。

一時表領域に 50GB の一時ファイルを追加する例は以下の通りです。DBA 権限

のユーザーで行います。

SQL> alter tablespace temp add datafile '+TEMP_DG' size 50g;

また他の考慮点として、START_REDEF_TABLE 中の CPU 使用率が高いことが


あげられます。今回の環境ではパラレル度 12 で START_REDEF_TABLE を行った

ところ、平均 CPU 使用率は usr:sys=50%:20%となりました。START_REDEF_TABLE

はオンライン再定義プロセス中も時間がかかる処理であり、表の規模によって

は長時間必要とする場合もあります。この対処方法として、RAC 環境であれば再

定義を行うノード間のみで処理をパラレル化し、他のノードは再定義の影響を受

けることなく通常業務による表へのアクセスを受け付ける、などがあげられます。

8.1.4. 総括

ILM を考慮したパーティション表への移行方法として、以上 2 つの方法をテス

トしました。2 つの方法の長所および考慮点は下表の通りです。

パーティション表への移行

方法長所考慮点

INSERT ... SELECT ・オンライン再定義よりも

短時間で完了・データ挿入中 DML 文を受け付

けない

オンライン再定義・移行作業の大部分におい

て DML 文を受け付ける

・実行時間が長く、プロシージャ

によっては CPU 使用率が高騰・表のサイズによっては一時表領

域を大量に消費・FINISH_REDEF_TABLE 実行中

に元表と仮表を rename するわず

かな間、表が排他ロックされる。


8.2. ILM 環境の運用管理

8.2.1. オンライン再定義によるパーティション移動

· 移動するパーティション：PT200804(2008 年 4 月分パーティション)

· 移動元表領域：TBS999999(Active)

· 移動先表領域：TBS200804(Less Active)

以上の条件を想定し、パーティションの移動を行いました。

ユーザーに対し、オンライン再定義に必要な権限を付与する必要があります。その

方法は、8.1.2 オンライン再定義による移行と同じです。

オンライン再定義によるパーティション移動の手順は以下の通りです。

(1) 移動先の表領域を作成

(2) 表がオンラインで再定義可能か確認

(3) パーティション移動用の仮表を作成

(4) オンライン再定義を開始

(5) 仮表に対して索引作成

(6) 元表と仮表の差分を同期

(7) オンライン再定義を終了

コマンドは以下の通りです。(1)以外は SHOPMSTR ユーザーで行います

(1) 移動先の表領域を作成します。DBA 権限のユーザーで行います。

SQL(sys)> CREATE TABLESPACE TBS200804 DATAFILE '+DATA_DG2' SIZE 5G;

(2) オンラインで再定義可能か確認します。

SQL>BEGIN DBMS_REDEFINITION.CAN_REDEF_TABLE( UNAME => 'SHOPMSTR', TNAME => 'ORDERITEM', OPTIONS_FLAG => DBMS_REDEFINITION.CONS_USE_PK, PART_NAME => 'PT200804'); END;/

(3) パーティション移動用の仮表を作成します。仮表は非パーティション表で

すが、データ型や列の順番など表の定義はパーティション表と同一である

必要があります。

SQL>CREATE TABLE INT_ORDERITEM (SHIPDATE DATE, ORDERKEY NUMBER NOT NULL, DISCOUNT NUMBER NOT NULL, EXTENDEDPRICE NUMBER NOT NULL, SUPPKEY NUMBER NOT NULL, QUANTITY NUMBER NOT NULL,


RETURNFLAG CHAR(1), PARTKEY NUMBER NOT NULL, LINESTATUS CHAR(1), TAX NUMBER NOT NULL, COMMITDATE DATE, RECEIPTDATE DATE, SHIPMODE CHAR(10), LINENUMBER NUMBER NOT NULL, SHIPINSTRUCT CHAR(25), COMMENT VARCHAR2(44)) TABLESPACE TBS200804;

(4) オンライン再定義を開始します。

SQL>BEGIN DBMS_REDEFINITION.START_REDEF_TABLE( UNAME => 'SHOPMSTR', ORIG_TABLE => 'ORDERITEM', INT_TABLE => 'INT_ORDERITEM', COL_MAPPING => NULL, OPTIONS_FLAG => DBMS_REDEFINITION.CONS_USE_PK, PART_NAME => 'PT200804'); END;/

(5) 仮表に対して索引作成します。

SQL> CREATE INDEX PK_INT_LINE_IDX ON INT_ORDERITEM (ORDERKEY,LINENUMBER,SHIPDATE) TABLESPACE TBS200804;

(6) 仮表と元表を同期します。

SQL> BEGIN DBMS_REDEFINITION.SYNC_INTERIM_TABLE( UNAME => 'SHOPMSTR', ORIG_TABLE => 'ORDERITEM', INT_TABLE => 'INT_ORDERITEM', PART_NAME => 'PT200804'); END;/

(7) オンライン再定義を終了します。

SQL> BEGIN DBMS_REDEFINITION.FINISH_REDEF_TABLE( UNAME => 'SHOPMSTR', ORIG_TABLE => 'ORDERITEM', INT_TABLE => 'INT_ORDERITEM', PART_NAME => 'PT200804'); END;/

(8) 仮表を削除します。


オンライン再定義によるパーティション移動は以上です。


8.2.2. MOVE PARTITION によるパーティション移動

· 対象：PT200806（2008 年 6 月分パーティション）

· 移動元表領域：TBS200806（Less Active 上）

· 移動先表領域：RO200806（Historical 上）

以上の条件を想定しパーティションの移動を行いました。手順は以下の通りです。


(2) 移動元の表領域を READ ONLY に変更

(3) MOVE PARTITION 文発行

(4) 移動元の表領域を READ WRITE に変更し、削除

コマンドは以下の通りです。

(1) 移動先の表領域を作成します。下例では、datafile 句で Historical 用ストレー

ジ上の ASM ディスクグループ DATA_DG3 を指定しています。DBA 権限の

ユーザーで行います。

SQL(sys)>CREATE TABLESPACE RO200806 DATAFILE '+DATA_DG3' SIZE 5G;

(2) 移動元の表領域を READ ONLY に変更します。これは(3)の実行中にデータ

の差分が生じるのを防ぐためです。DBA 権限のユーザーで行います。

SQL(sys)> ALTER TABLESPACE RO200806 READ ONLY;

(3) MOVE PARTITION 文を発行します。SHOPMSTR ユーザーで行います。下

例では索引の REBUILD も同時に行っています。表のパーティションの移

動に伴い、索引のパーティションも移動させる場合は UPDATE INDEXES

内で表領域を指定する必要があります。指定しない場合、索引は元あった

表領域内で REBUILD されます。

SQL> ALTER TABLE ORDERITEM MOVE PARTITION PT200806 TABLESPACE RO200806 UPDATE INDEXES (LINE_LOCAL_IDX (PARTITION PT200806 TABLESPACE RO200806) );

(4) 移動元の表領域を READ WRITE に変更し、削除します。DBA 権限のユー

ザーで行います。

SQL(sys)> ALTER TABLESPACE RO200806 READ WRITE; SQL(sys)> DROP TABLESPACE RO200806;

MOVE PARTITION によるパーティションの移動は以上です。


8.2.3. EXCHANGE PARTITION によるパーティション切り替え

EXCHANGE PARTITION は一般的にはパーティションどうしの交換に用いられ

ますが、パーティションの移動にも使えます。


· 移動元表領域：TBS200802（Less Active 上）

· 移動先表領域：RO200802（Historical 上）

以上の条件を想定し、パーティションの切り替えを行いました。手順は以下の

通りです。


(2) 移動先の表領域に仮表を作成。

(3) 移動元の表領域を READ ONLY に変更

(4) 移動するパーティションのデータを仮表へ挿入

(5) 仮表に対して索引作

(6) 仮表に一意キー制約を追加

(7) ALTER TABLE ...EXCHANGE PARTITION 文発行

(8) 移動元の表領域を READ WRITE に変更後、仮表を削除。

コマンドは以下の通りです。ALTER TABLESPACE および DROP TABLESPACE

は DBA 権限のユーザーで、それ以外は SHOPMSTR ユーザーで行います。

(1) 移動先の表領域を作成します。例ではデータファイルとして Historical 上に

作ったディスクグループ DATA_DG3 を指定しています。

SQL> CREATE TABLESPACE RO200802 DATAFILE '+DATA_DG3' SIZE 5G;

(2) 移動先の表領域に仮表を作成します。列の順序、データ型などの表定義は

パーティション表と同一にします。


SQL> CREATE TABLE INT_ORDERITEM (SHIPDATE DATE, ORDERKEY NUMBER NOT NULL, DISCOUNT NUMBER NOT NULL, EXTENDEDPRICE NUMBER NOT NULL, SUPPKEY NUMBER NOT NULL, QUANTITY NUMBER NOT NULL, RETURNFLAG CHAR(1), PARTKEY NUMBER NOT NULL, LINESTATUS CHAR(1), TAX NUMBER NOT NULL, COMMITDATE DATE, RECEIPTDATE DATE, SHIPMODE CHAR(10), LINENUMBER NUMBER NOT NULL, SHIPINSTRUCT CHAR(25), COMMENT VARCHAR2(44) ) TABLESPACE RO200802;

(3) 移動元の表領域をREAD ONLY に変更します。これは(4)でデータ挿入中に、

移動元のパーティションと仮表の間にデータの差分がないようにするため

です。

SQL> ALTER TABLESPACE TBS200802 READ ONLY;

(4) 表データを挿入します。パラレルで実行すると処理が短時間で終わること

があります。<para>では環境に応じ適切な数値を入力します。INSERT 文後

半の SELECT も parallel dml parallel <para>で指定したパラレル度<para>で実

行されます。

SQL> ALTER session force PARALLEL dml PARALLEL <para>; SQL> INSERT /*+ APPEND */ INTO INT_ORDERITEM SELECT * FROM ORDERITEM WHERE SHIPDATE >=TO_DATE('2008/02/01','YYYY-MM-DD') AND SHIPDATE < TO_DATE('2008/03/01','YYYY-MM-DD');

(5) 仮表に対して索引を作成します。パーティション表 orderitem に orderkey、

linenumber、shipdate の 3 列を用いたローカル索引があるため、例ではこの

3 列を用いて索引を作成しています。TABLESPACE 句で移動先の表領域を

指定しないと、ユーザーのデフォルト表領域に索引が作られてしまい、パ

ーティションと索引が違う表領域に格納されるので注意してください。

SQL> CREATE INDEX PK_INT_LINE ON INT_ORDERITEM(ORDERKEY,LINENUMBER,SHIPDATE) TABLESPACE RO200802;

(6) 仮表に対して一意キー制約を追加します。(5)、(6)の作業は、パーティショ

ン表に索引を作成および制約を追加したときと同じ条件にする必要があり

ます。したがって下例では、orderkey と linenumber を、ローカル索引を用


いて主キーとするよう操作しています。

SQL> ALTER TABLE INT_ORDERITEM ADD CONSTRAINT PK_LINE PRIMARY KEY(ORDERKEY,LINENUMBER) USING INDEX;

(7) EXCHANGE PARTITION 文を発行します。

SQL> ALTER TABLE ORDERITEM EXCHANGE PARTITION PT200802 WITH TABLE INT_ORDERITEM INCLUDING INDEXES WITH VALIDATION;

(8) 移動元の表領域を READ WRITE に変更します。

SQL> ALTER TABLESPACE TBS200802 READ WRITE;

(9) 仮表を削除します。


(10) 移動元の表領域を削除します。

SQL> DROP TABLESPACE RBS200802;

(11) 移動先の表領域を READ ONLY に変更します。

SQL> ALTER TABLESPACE RO200802 READ ONLY;

8.2.4. 総括

ILM の運用管理の要である、パーティションの移動方法として以上 3 つの方法

をテストしました。各方法の長所および考慮点は以下の通りです。

パーティションの移動


オンライン再定義・移行作業の大部

分において DML文を受け付ける

・実行時間が長くプロシージャによっては CPU使用率が高騰・表のサイズによっては一時表領域を大量に消費・FINISH_REDEF_TABLE 実行中に元表と仮表を

rename するわずかな間、表が排他ロックされる。

MOVE PARTITION ・操作が単純・他の方法に比べ

短時間で完了

・実行中は移動させるパーティションの表領域を

READ ONLY にする必要がある

EXCHANGE PARTITION

・事前に仮表を作

成可能である場

合、入れ替えるタ

イミングでの作

業は短時間で終

了

・実行中は移動させるパーティションの表領域を

READ ONLY にする必要がある・個々のパーティションにどのようなデータが格

納されるかを考慮して SQL 文を作成する必要が

ある

移動するパーティションの表領域を READ ONLY にできない場合はオンライン

再定義、READ ONLY にできる場合は MOVE PARTITION がおすすめです。


8.3. Archive 用デバイスへのパーティション移動

Archive 用デバイスへのパーティション移動も、前項[ILM 環境の運用管理]の一部

ですが、Historical 以上のデバイスへの移動とは操作方法が大きく異なります。

8.3.1. 外部表を用いた移動

· 対象：PT200201(2002 年 1 月分パーティション)

· 移動元表領域：RO200201(Historical 上)

以上の条件を想定し、Centera へのデータ移動を行いました。手順は下記の通り

です。

(1) DATAPUMP 用に directory オブジェクトを作成

(2) DATAPUMP を用いてデータをダンプファイルへアンロード

(3) データ抽出時に作成された外部表を削除

(4) OS コマンドで(2)で生成されたダンプファイルを Centera へコピー

(5) 移行元のパーティションを削除

(6) [データ参照時]Centera 上のダンプファイルを参照するよう外部表を作成

コマンドは以下の通りです。

(1) DATAPUMP 用に directory オブジェクトを作成し、SHOPMSTR へ権限を与

えます。DBA 権限のユーザーで行います。

・ローカルディスク上の directory…抽出用外部表の作成に使用します。

SQL> CREATE DIRECTORY EXT_LOCAL AS ’/localdisk/TEST/’;

・ Centera 上の directory…参照用外部表の作成に使用します。

SQL> CREATE DIRECTORY EXT_CENT AS ’/Centera/datapump/’;

・ SHOPMSTR へ権限付与します。

SQL> GRANT READ , WRITE ON DIRECTORY EXT_LOCAL TO SHOPMSTR; SQL> GRANT READ , WRITE ON DIRECTORY EXT_CENT TO SHOPMSTR;

(1)の作業は初に 1 度行えば、毎回行う必要はありません。したがって

2 回目以降の Centera 移行作業では、手順(2)から始めます。

以降の作業は、特に指定がなければ SHOPMSTR ユーザーで行います。

(2) DATAPUMP アクセスドライバを利用し、移行対象のデータを where 句内で

範囲指定してダンプファイルへ抽出します。この例では 2002 年 1 月のパー

ティションをダンプファイルへ抽出するので、where 句内で ”200201 以上


200202 未満” を指定しました。

SQL>CREATE table EXT_200201 ORGANIZATION EXTERNAL (type ORACLE_DATAPUMP default directory EXT_LOCAL location('ext_200201.dmp')) as SELECT /*+ FULL(orderitem) */ * FROM orderitem WHERE shipdate >= to_date('20020101','yyyymmdd') and shipdate < to_date('20020201','yyyymmdd');

(3) データ抽出時に作られた外部表を削除します。

SQL> DROP TABLE EXT_200201

(4) OS コマンドを用いて抽出したダンプファイルを Centera へコピーします。

cp -p ext_tb200201.dmp /Centera/datapump/

(5) 移行元のパーティションと表領域を削除します。表領域の削除は DBA 権限

のユーザーで行います。

SQL> alter table orderitem drop partition pt200201; SQL> drop TABLESPACE TBS200201;

(6) Centera 上のデータを参照するときは、ダンプファイルを参照する外部表を

作成します。

SQL> CREATE table EXT_TB200202_C( SHIPDATE DATE, ORDERKEY NUMBER, DISCOUNT NUMBER, EXTENDEDPRICE NUMBER, SUPPKEY NUMBER, QUANTITY NUMBER, RETURNFLAG CHAR(1), PARTKEY NUMBER, LINESTATUS CHAR(1), TAX NUMBER, COMMITDATE DATE, RECEIPTDATE DATE, SHIPMODE CHAR(10), LINENUMBER NUMBER, SHIPINSTRUCT CHAR(25), COMMENT VARCHAR2(44)) ORGANIZATION EXTERNAL( TYPE ORACLE_DATAPUMP DEFAULT DIRECTORY EXT_CENT LOCATION ('ext_tb200202.dmp'));

外部表を用いた移動は以上です。


8.3.2. RMAN を用いた移動


· 移動元表領域：RO200205（Historical 上）

(1)から(5)の作業は、全て DBA 権限のユーザーで行います。

(1) 移行元の表領域を OFFLINE にします。

SQL> ALTER TABLESPACE RO200205 offline;

(2) RMAN を用いて、データファイルを ASM からローカルディスクに抽出し

ます。

[node03]$ export ORACLE_SID=bkup [node03]$ rman target / catalog rcuser/rcuser@recov RMAN> copy datafile '+DATA_DG3/orcl/datafile/ro200205.260.626260543' to '/localdisk/TEST/ro200205.dbf';

なお、ASM データファイルのパスは、以下の SQL 文で確認できます。

SQL> select tablespace_name,file_name from dba_data_files;

(3) OS コマンドを用いて、抽出したデータファイルを Centera へコピーします。

cp -p /localdisk/TEST/ro200205.dbf /Centera/RMAN/

(4) 移行元の表領域のデータファイルをリネームします。

SQL> ALTER TABLESPACE RO200205 rename datafile '+DATA_DG3/orcl/datafile/ro200205.260.626260543' to '/Centera/RMAN/ro200205.dbf';

(5) 移行元の表領域を ONLINE にします。

SQL> ALTER TABLESPACE RO200205 online;

RMAN を用いた移動は以上です。

8.3.2.1. RMAN を用いた移動の留意点

· リネーム後の ASM データファイル

移動させる表領域を作成する際に、下例のように datafile 句でディスクグル

ープのみ指定した場合、ASM 上のデータファイルは手順 (4)の ALTER

TABLESPACE ... RENAME DATAFILE を実施した時点で削除されます。したが

って、リネーム後に手動でデータファイルを削除する必要がありません。

SQL> CREATE TABLESPACE ro200205 DATAFILE '+DATA_DG3' SIZE 5G


リネーム後もデータファイルが残ってしまっている場合は、表領域作成時に

明示的にデータファイルを指定した可能性があります。この場合は、リネーム

後に手動でデータファイルを削除する必要があります。

· 移行元の表領域を ONLINE へ変更する際のエラー

(5)で下例のようなエラーが出ることがあります。

SQL> ALTER TABLESPACE RO200205 online; ORA-01157: cannot identify/lock data file 35 - see DBWR trace file ORA-01110: data file 35: '/Centera/RMAN/tbs200205.dbf'

なお、エラー発生時は orcl のアラート・ログに下例のように出力されます。

ORA-01157: cannot identify/lock data file 35 - see DBWR trace file ORA-01110: data file 35: '/Centera/RMAN/tbs200205.dbf‘ ORA-27086: unable to lock file - already in use HP-UX Error: 13: Permission denied Additional information: 10

この場合は、chmod で該当のデータファイルの権限を変更します。

[node06]$ chmod 775 '/Centera/RMAN/tbs200205.dbf‘;

8.3.3. 総括

アーカイブデバイスへのパーティション移動方法として以上 2 つをテストしま

した。各方法の長所及び考慮点をまとめると下表の通りになります。

Archive 用デバイスへのパーティション移動


外部表・データ抽出後の移

動・管理が単純・参照用ディレクトリは全ノードから見える必要がある。・参照時は期間に応じた外部表を作成する必要がある。

RMAN ・移動後もオンライン

であるため、表定義は

そのままで参照可能

・Centera における NFS マウントは EMC でのサポート状

況確認中・Centera 上のデータを参照時はレスポンスが悪くなる。


8.4. パーティション化の効果と ILM

非パーティション表とパーティション表を対象に、パーティション表のパーティシ

ョン・キーによって範囲指定した索引を使わないクエリーの実行時間を測定し、パフ

ォーマンスを測定しました。パラレル度は 32 です。

パラレルクエリーを実行するには、以下のように初期化パラメータ instance_groups、

parallel_instance_group の設定が必要です。instance_groups は静的パラメータであるた

め、設定後はインスタンスを再起動します。

SQL> alter system set instance_groups=ig4 scope=spfile sid=orcl4; SQL> alter system set parallel_instance_group=ig4 scope=spfile sid=orcl4;

8.4.1. パーティション化の効果

以下のような、1 か月分、1 年分をスキャンするような、索引を使わない SQL

文を非パーティション表、パーティション表に対し実行しました。

なお、パーティション表において Where 句で指定した範囲は、全て Symmetrix

上にデータが存在します。非パーティション表は全データが Symmetrix 上にあり

ます。

SQL> SELECT SUM(extendedprice * discount) AS revenue FROM orderitem WHERE shipdate >= date '2008-01-01' AND shipdate < date '2008-02-01' ; SQL> SELECT SUM(extendedprice * discount) AS revenue FROM orderitem WHERE shipdate >= date '2008-01-01' AND shipdate < date '2009-01-01' ;

パーティション表に対する 1 か月分のスキャンの実行時間を 1 とした、相対値

グラフは下の通りです。


非パーティション表の結果が、1 か月分のスキャンと 1 年分のスキャンで大差

ないのは、前述の通り索引を使わないクエリーであるため、全表スキャンしてい

るからです。パーティション・プルーニング効果により、1 か月分のスキャンで

約 63 倍、1 年分で約 8.6 倍、非パーティション表とパーティション表の実行時間

に差が出ました。

以上の結果により、パーティション化の効果として、クエリーでよく範囲指定

するカラムでパーティション化すれば、パフォーマンスが大幅に改善されるとい

うことが言えます。

8.4.2. パーティション化によるストレージの性能格差縮小

アクセスの少ないデータを定期的に低コストストレージに移動させ、データ増

加に伴うコストを削減する、というのが ILM の考え方です。しかしアクセスが少

ないとはいえ、全くアクセスがないわけではありません。たとえば本検証では 3

ヶ月～1 年のデータを Less Active と位置づけていますが、半年分の売り上げや前

年同期比の計算など、Active へのアクセス頻度と比較すれば少ないものの、Less

Active 上のデータも定期的に参照される可能性はあります。その際、低コストス

トレージ上へ移動したデータだからパフォーマンスが極端に悪い、という事態に

陥ると、業務に支障をきたすかもしれません。

そこで本検証では、パーティション表が格納されている 2 つのストレージ上の


1 か月分、1 年分のデータに対し、索引を使わないようなクエリーをかけ、実行時

間を測定しました。具体的には Symmetrix 上にある 1 パーティション、12 パーテ

ィション、CLARiX 上にある 1 パーティション、12 パーティションに対しクエリ

ーを実行しました。

Symmetrix 上のデータへのクエリーは、8.4.1パーティション化の効果と同一です。

CLARiX 上のデータへのクエリーは以下の通りです。Where 句で CLARiX 上にあ

るパーティション 1 か月分、1 年分を範囲指定しています。

SQL> SELECT SUM(extendedprice * discount) AS revenue FROM orderitem WHERE shipdate >= date '2006-01-01' AND shipdate < date '2006-02-01' ; SQL> SELECT SUM(extendedprice * discount) AS revenue FROM orderitem WHERE shipdate >= date '2005-01-01' AND shipdate < date '2006-01-01' ;

Symmetrix 上にあるデータの 1 か月分のスキャン実行時間を 1 とした、相対値グ

ラフは下の通りです。

結果の通り、1 か月分のデータをスキャンする場合は Symmetrix、CLARiX で実

行時間にあまり差がありません。これはパーティション・プルーングの効果によ

り、全表スキャンとなるようなクエリーでも読み込むべきデータは少ないため、2

つのストレージの性能差が顕著には出なかったから、といえます。


1 年分スキャンする場合は Symmetrix と CLARiX に約 3.8 倍の性能差が出ていま

す。先の 1 ヶ月のスキャンと比較し 12 倍のデータ量となったため、性能差があら

われましたが、それでも CLARiX 上のデータを参照する頻度、また Symmetrix と

CLARiX の価格差を考慮すると、十分堪えうる性能差といえます。また、お客様

の環境やシステム用件により、Active または Less Active と位置づけるデータの範

囲を増減させれば、より性能差の影響を回避できる場合もあります。

8.4.3. パーティション化の効果のまとめ

以上から、ILM 導入により高性能ストレージと低コストストレージを併用して

も、表がパーティション化されているため一定のパフォーマンスが得られること

が確認できました。


8.5. バックアップ/リストア/リカバリ検証環境

ストレージのミラー機能と RMAN を組み合わせたバックアップ/リカバリ/リスト

アを行い、手順を確認ました。

上図の通り本番サーバーからは Symmetrix,CLARiX 各ストレージの本番用ボリュ

ーム(以降、STD)のみが見えており、またバックアップ・サーバーからは STD のコピ

ーが含まれるビジネス継続性ボリューム(Business Continuance Volume: 以降 BCV)と、

RMAN で取得したバックアップピース格納用のディスクのみが見えています。本番/

バックアップ・サーバー上の DB インスタンス構成は以下の通りとしました。

サーバーインスタンス名データファイル使途

本番サーバー orcl ASM 本番 DB

bkup ASM (SID:+ASM_BK) RMAN 起動用 DB バックアップ・

サーバー recov ファイルシステム RMAN リカバリカ

タログ用 DB


各 ASM ディスクグループの構成は以下の通りです。

ディスクグループ名ストレージ使途

DATA_DG1

DATA_DG2 Symmetrix

Active / Less Active のパーティション

を格納

DATA_DG3 CLARiX Historical(READ ONLY)のパーティシ

ョンを格納

UNDO_DG Symmetrix UNDO 表領域

SYS_DG Symmetrix SYSTEM,SYSAUX 表領域

ARCH_DG Symmetrix アーカイブ・ログ格納

CTL_DG Symmetrix 制御ファイル格納

REDO_DG Symmetrix オンライン redo ログ格納

TEMP_DG Symmetrix 一時表領域

以降は上図の固有名を用いて記述します。


8.6. バックアップ・サーバーの構築

BCV 上のデータファイルを RMAN でバックアップする為に、バックアップ・サー

バー側でも Oracle インスタンスを起動可能な状態に設定します。また、バックアッ

プ・サーバー上に RMAN のカタログ用インスタンスの作成及び設定も行います。

この作業は、以下 2 つのソフトウェアが本番サーバー、およびバックアップ・サー

バーに既にインストールされている状態を前提としています。

· Symmetrix 用の Solution Enabler ソフトウェア

· CLARiX 用の Navisphere Agent と Navisphere Server Utility ソフトウェア

なお、本検証環境の OS は HP-UX11.11 です。OS の種類およびバージョンによっ

てコマンドが若干異なる可能性があります。

PATH 環境変数にそれぞれのパスを追加することを推奨します。

# PATH=$PATH:/usr/symcli/bin/:/opt/Navisphere/bin # export PATH

以降の作業は本番サーバー、バックアップ・サーバーそれぞれで行います。

8.6.1. 本番サーバー(RAC)のデバイスファイル調査

8.6.1.1. Symmetrix ディスク・デバイスファイルの調査

全ての作業は root ユーザーで行います。

Symmetrix の STD デバイスの LUN 番号を sympd コマンドで表示します。

# sympd list /dev/rdsk/c45t0d1 0051 13B:1 01D:D8 2-Way Mir Grp'd RW 11500

※2 つ目の番号 0051 が /dev/dmx/rdisk01 の LUN 番号です。

この STD LUN 0051 が BCV にリンクされています。通常 STD と BCV のリ

ストは存在し、このリストを使ってバックアップ・サーバーが見られる BCV

に対して STD と同じデバイスファイルを設定します。新たに STD-BCV のリン

クを調査する場合は symbcv というコマンドを利用します。

# symbcv list |grep 0051 Not Visible 02D1 + 0 c43t0d1 0051 0 Split

※２つ目の 02D1 が BCV の LUN 番号です。

バックアップ・サーバーで、BCV 02D1 に対して STD と同じデバイスファイ


ル/dev/dmx/rdisk01 を設定します。

8.6.1.2. CLARiX ディスク・デバイスファイルの調査

CLARiX の場合は 2 つの調査方法があります。１つは CLARiX の管理ツール

Navisphere GUI上で STD と BCV のそれぞれの LUN 番号とデバイスファイルと、

STD と BCV の関連付けを調べます。

もう一つの方法は Navisphere Agent (naviseccli) と Navisphere Server Utility

(naviserverutil)コマンドを使って STD と BCV のデバイスファイル及びそれらの

関連付けを調べます。

以下は naviseccli と naviserverutil を使った例です。全ての作業は root ユーザ

ーで行います。

まず、本番環境のディスク・デバイスファイルを表示し、ASM ディスクの

デバイスファイルと、OS デバイスファイルの対応を確認します。

# ioscan -fnkC disk disk 421 0/4/0/0.97.68.19.0.0.1 sdisk CLAIMED DEVICE EMC SYMMETRIX /dev/dmx/rdisk01 /dev/dsk/c45t0d1 /dev/rdsk/c45t0d1 disk 537 0/4/0/0.111.83.19.0.0.1 sdisk CLAIMED DEVICE DG CX3-80WDR5 /dev/cxata/rdisk01 /dev/dsk/c50t0d1 /dev/rdsk/c50t0d1

※PowerPath ソフトウェアが使われている場合は複数のパスから同じディス

クが見えますが、ASM 用のデバイスファイルはその中の一つのパスに対して

のみ作ります。

ioscan の結果から、/dev/cxata/rdisk01 という共有ディスクの既存のデバイス

ファイルは /dev/rdsk/c50t0d1 であることが分かります。

Naviserverutilを使って c50t0d1のLUN番号を調べます。このコマンドにより、

CLARiX のディスクが表示されます。

# naviserverutil Device Name File System Virtual Disk SP IP Address SP 47t0d1 LUN 7 10.32.2.10 A c50t0d1 LUN 7 10.32.2.10 A

次に、naviseccli コマンドで LUN 7 に同期されている BCV を調査します。

# naviseccli -h 10.32.2.10 -User Admin -Password <password> -Scope 0 snapview –ListCloneGroup Sources: 7 CloneID: 0100000000000000 CloneLUNs: 19


このコマンドから、Lun7 に関連付けられた BCV の LUNID19 が分かります。

バックアップ・サーバーで naviserverutil を使って LUN 19 に対して

/dev/cxata/rdisk01 を設定します。

8.6.2. バックアップ・サーバーでのデバイスファイル作成

本番サーバーでのデバイスファイル調査結果を元に、バックアップ・サーバー

上へデバイスファイルを作成します。全ての作業は root ユーザーで行います。

8.6.2.1. Symmetrix の BCV に対してデバイスファイルを作成

BCV のデバイスリストを表示します。

# sympd list

/dev/rdsk/c45t0d1 02D1 13B:1 01A:DF 2-Way BCV Mir N/Asst'd RW 11500

ioscan コマンドで BCV の HW パスを調べます。

# ioscan -fnkC disk disk 389 0/4/0/0.97.68.19.1.0.1 sdisk CLAIMED DEVICE EMC SYMMETRIX /dev/dsk/c45t0d1 /dev/rdsk/c45t0d1

BCV のデバイスファイルを設定するには、上記 3 番目の HW パス

0/4/0/0.97.68.19.1.0.1 を指定して STD と同じデバイスファイル/dev/dmx/rdisk01

を作成します。

# mksf -H 0/4/0/0.97.68.19.1.0.1 -r /dev/dmx/rdisk01

8.6.2.2. CLARiX の BCV に対してデバイスファイルを作成

BCV のデバイスリストを表示します。

# naviserverutil Device Name File System Virtual Disk SP IP Address S c41t0d2 LUN 9 10.32.2.10 A c44t0d2 LUN 9 10.32.2.10 A

ioscan コマンドで BCV c44td2 または c41t0d2 の HW パスを調べます。

# ioscan -fnkC disk disk 382 0/4/0/0.111.83.19.0.0.2 sdisk CLAIMED DEVICE DGC CX3-80WDR5 /dev/dsk/c44t0d2 /dev/rdsk/c44t0d2

BCV のデバイスファイルを設定するには、 3 番目の HW パス


0/4/0/0.111.83.19.0.0.2 を指定して、 STD と同じデバイスファイル

/dev/cxata/rdisk01 を作成します。

# mksf -H 0/4/0/0.111.83.19.0.0.2 -r /dev/cxata/rdisk01

全ての該当の BCV に対して同じ作業を行います。

8.6.3. 所有者を oracle ユーザーに変更

2 の操作により、バックアップ・サーバー上に新たに作成されたデバイスファ

イルの所有者を、oracle ユーザーへ変更します。

# chmod oracle:oinstall /dev/dmx/* # chmod oracle:oinstall /dev/cxata/*

以上でデバイスファイルの作成が完了し、本番サーバーが STD を見ているのと

同一パスで、バックアップ・サーバーから BCV が見えるようになりました。

以降の作業では、バックアップ・サーバー上に ASM インスタンスおよびデー

タベース・インスタンスを作成します。

8.6.4. バックアップ・サーバーにインスタンス作成

bkup が BCV 上の ASM ディスクグループにアクセス可能なように、バックアッ

プ・サーバー上に Database Configuration Assistant（DBCA）を用いて ASM インス

タンスを作成します。Oracle ユーザーで行います。また、リカバリカタログ用 DB

の recov も DBCA を用いて作成します。bkup は BCV 上のデータ及び orcl の初期

化パラメータ・ファイルの流用により作成するため、DBCA で作成しません。

recov インスタンスに RMAN 用ユーザーrcuser を作成し、必要な権限を付与しま

す。DBA 権限のユーザーで以下を実行します。

[node03]$ export ORACLE_SID=recov [node03]$ sqlplus / as sysdba SQL> create user rcuser identified by rcuser; SQL> grant recovery_catalog_owner to rcuser;

8.6.5. 本番サーバーの制御ファイルの確認

orcl の制御ファイルは、制御ファイル用ディスクグループ(CTL_DG)を作成し、

そこへ格納します。制御ファイル用ディスクグループには、制御ファイル以外は

格納しません。制御ファイルがローカルディスク上にある場合は、以下のマニュ

アルを参照し制御ファイルの再配置を行ってください。

Oracle Database 管理者ガイド 10g リリース 2（10.2）部品番号:B19224-02

5-4 ページ制御ファイルの追加コピーの作成、名前変更および再配置


8.6.6. tnsnames の編集

バックアップ・サーバー上の$ORACLE_HOME/network/admin/tnsnames.ora に orcl、

bkup を登録します。なお、RMAN を使うために SERVER=DEDICATED とし、専

用サーバー構成にしています。

… ORCL = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = node06)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl) ) ) BKUP = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = node03)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = bkup) ) ) …

8.6.7. RMAN カタログ作成

バックアップ・サーバー上でターゲットを orcl として RMAN を起動し、recov

にカタログを作成後、orcl を recov へ登録します。なお、制御ファイル自動バック

アップは無効（デフォルト）のままにしておきます。

[node03]$ export ORACLE_SID=orcl [node03]$ rman target / catalog rcuser/rcuser@recov RMAN> create catalog; RMAN> register database;


8.6.8. バックアップ・サーバー用初期化パラメータ・ファイルの作成

orcl の初期化パラメータ・ファイルをバックアップ・サーバーへ転送します。

たとえば下例のように FTP で転送します。

SQL(orcl)> create pfile from spfile; [node06]$ cd $ORACLE_HOME/dbs [node06]$ ftp node03 ftp> ascii ftp> cd /tmp ftp> put initorcl.ora

転送した orcl の初期化パラメータ・ファイルを、bkup 用に編集します。特に以

下のパラメータに注意します。

パラメータ編集内容

cluster_database 削除

cluster_database_instances 削除

control_files 変更しない

('+CTL_DG/.../control01.ctl'のまま)

instance_name

service_names bkup に変更

background_dump_dest

user_dump_dest

core_dump_dest

バックアップ・サーバーの環境に合わせて編集。

または本番サーバーと同じ構成のディレクトリを作成。

編集した orcl の初期化パラメータを$ORACLE_HOME/dbs/initbkup.ora にコピー

します。

[node03]$ cp /tmp/initorcl.ora $ORACLE_HOME/dbs/initbkup.ora

以上の作業によって、バックアップ・サーバーを用いてバックアップを取得す

る環境が整いました。


8.7. バックアップ取得

8.7.1. STD から BCV へデータをコピー

(1)から(6)の作業は全て root ユーザーで行います。

(1) bkup の ASM インスタンスが起動されている場合は停止します。本番サー

バーの ASM、DB は停止しません。

(2) STD と BCV を同期します。CTL_DG, REDO_DG, TEMP_DG のディスクは

同期しません。コマンドは本番サーバー、バックアップ・サーバーどちら

で実行しても構いません。コマンドはSymmetrixとCLARiXで異なります。

詳細は本文書末尾の Appendix をご参照下さい。

Symmir コマンドで指定している DATADG は、データファイルが置かれている

ASM ディスクとそれぞれの BCV をまとめたグループ名です。

[node03]# symmir -g DATADG establish –noprompt [node03]# symmir -g ARCHDG establish –noprompt

CLARiXのSTDとBCVも同期します。Naviseccli -SynCloneコマンドでSTD-BCV

の 1 ペアづつ指定します。全ての CLARiX デバイスのペアに対して同期コマンド

を実行します。

[node03]# naviseccli -h 10.32.2.10 -User Admin -Password <password> -Scope 0 snapview -SyncClone -name CX_RO -CloneID 0200000000000000 –o [node03]# naviseccli -h 10.32.2.10 -User Admin -Password <password> -Scope 0 snapview -SyncClone -name CX_RW -CloneID 0200000000000000 -o

(3) 現在使用中のオンライン redoログファイルの redo情報をアーカイブログフ

ァイルに書き出します。DBA 権限のユーザーで実行します。

SQL(orcl)> ALTER SYSTEM ARCHIVE LOG CURRENT;

(4) 同期が完了したら、orcl で BEGIN BACKUP を実行します。DBA 権限のユ

ーザーで実行します。

SQL(orcl)> ALTER DATABASE BEGIN BACKUP;

(5) STD と BCV を切り離します。この段階では、データファイルが格納され

ているディスク（ARCH_DG, CTL_DG,REDO_DG, TEMP_DG 以外のディス

ク）を切り離します。この作業により、STD と BCV の切り離し対象ディ

スクが完全に同期されます。


コマンドは本番サーバー、バックアップ・サーバーどちらで実行しても

構いません。コマンドは Symmetrix と CLARiX で異なります。Symmetrix

と CLARiX のコマンドの詳細は、本文書末尾の Appendix をご参照下さい。

Symmetrix: (全てのデータディスクのペアとコントロール・ファイルの

ディスクを同時に切り離します)

[node03]# symmir -g DATADG split -consistent –noprompt

CLARiX: (全てのペアを同時に切り離します)

[node03]# naviseccli -h 10.32.2.10 -User Admin -Password <password> -Scope 0 Snapview -ConsistentFractureClones -CloneGroupNameCloneID CX_RO 0200000000000000 CX_RW

(6) orcl で END BACKUP を実行後、バックアップモード中に生成された redo

情報をアーカイブログファイルに書き出します。DBA 権限のユーザーで実

行します。

SQL(orcl)> ALTER DATABASE END BACKUP; SQL(orcl)> ALTER SYSTEM ARCHIVE LOG CURRENT;

(7) 2 つの制御ファイルのバックアップを ARCH_DG 上に作成します。DBA 権

限のユーザーで行います。1 つはバックアップで、もう 1 つは RMAN でバ

ックアップを取得する際の mount 時に使用する為のものです。

SQL(orcl)> ALTER DATABASE BACKUP CONTROLFILE TO '+ARCH_DG/.../control_bkup.ctl' reuse; SQL(orcl)> ALTER DATABASE BACKUP CONTROLFILE TO '+ARCH_DG/.../control_rman.ctl' reuse;

(8) ARCH_DG のペアを切り離します。

[node03]# symmir -g ARCHDG split -consistent -noprompt

以上で STD から BCV へのコピーは完了しました。


8.7.2. RMAN でバックアップ取得

(1) bkup の初期化パラメータ・ファイルを8.7.1 (7)で作成した bkup の mount 用

の制御ファイルを使うよう編集します。

[node03]$ vi $ORACLE_HOME/dbs/initbkup.ora #control_files='+CTL_DG/.../control01.ctl' control_files='+ARCH_DG/.../control_rman.ctl'

(2) バックアップ・サーバー上の ASM を起動し、bkup をマウントします。DBA

権限のユーザーで行います。

[node03]$ export ORACLE_SID=+ASM_BK [node03]$ sqlplus / as sysdba SQL(+ASM_BK)> startup [node03]$ export ORACLE_SID=bkup [node03]$ sqlplus / as sysdba SQL(bkup)> startup mount

(3) バックアップ・サーバー上でターゲットを bkupとしRMANを起動します。

[node03]$ export ORACLE_SID=bkup [node03]$ rman target / catalog rcuser/rcuser@recov

(4) バックアップを取得します。

allocate channel <任意の channel_id> format ‘<任意のパス>’ で複数のディレ

クトリまたはファイルを指定することにより、バックアップを並列化でき

ます。例では 2 つのディレクトリを指定し、増分バックアップのレベル 0

を取得しています。

今回は制御ファイルのバックアップ取得を省略していますが、8.7.1 (7)で作

成した制御ファイル（'+ARCH_DG/.../control_bkup.ctl'）も以下のコマンドに

含めることで可能となります。

RMAN> run { allocate channel d1 device type disk format '/BACKUP-TO-DISK1/RMAN-INC_LV0-1/%U'; allocate channel d2 device type disk format '/BACKUP-TO-DISK1/RMAN-INC_LV0-2/%U'; backup incremental level 0 database plus archivelog; }

以上でバックアップ取得は完了です。


8.8. リストア/リカバリ

本検証では、DATA_DG1、DATA_DG2、DATA_DG3、UNDO_DG、SYS_DG に対

する以下 2 つのリカバリ方法をテストしました。

・新の状態までリカバリ

・ Point-in-Time リカバリ

8.8.1. 新の状態までのリカバリ

1. orcl, bkup 両方の ASM インスタンス、DB インスタンスを停止します。

[node06]$ srvctl stop database -d orcl [node06]$ srvctl stop asm -n node06 [node06]$ srvctl stop asm -n node05 [node06]$ srvctl stop asm -n node04 [node03]$ sqlplus sys/oracle@bkup as sysdba SQL (bkup)> shutdown; [node03]$ export ORACLE_SID=+ASM_BK [node03]$ sqlplus / as sysdba SQL (+ASM_BK)> shutdown;

2. BCV から STD へリストアします。BCV から STD へデータを戻す（コピー

する）ことを、リストアといいます。このとき、制御ファイル(CTL_DG)、

オンライン redo(REDO_DG)、アーカイブ・ログ(ARCH_DG)のディスクグ

ループをリストアしません。

以下の例ではデータベース全体をリストアします。BCV を使ってリスト

アする場合は、壊れた表や表領域が保存されている ASM ディスクグループ

単位でリストアできます。

Symmetrix:

[node03]$ symmir -g DATADG restore -noprompt

CLARiX:

[node03]$ naviseccli -h 10.32.2.10 -User Admin -Password <password> -Scope 0 snapview -ReverseSyncClone -name CX_RO -CloneID 0200000000000000 -o

[node03]$ naviseccli -h 10.32.2.10 -User Admin -Password <password> -Scope 0 snapview -ReverseSyncClone -name CX_RW -CloneID 0200000000000000 -o


3. orcl の ASM インスタンスを起動、DB インスタンスをマウントし、新時

点までリカバリします。RAC 環境の場合、1 つのデータベースに複数のイ

ンスタンスからアクセスしているため、1 つのノードでのみリカバリを行

えば他のノードでリカバリを行う必要はありません。また、上記の２つの

リストアコマンドを発行した直後から、本番サーバーでリカバリを開始で

きます。BCV から STD へのデータのコピーが完了するのを待つ必要がな

いため、ダウンタイムを軽減できます。この例では node06 からリカバリを

行っています。

[node06]$ srvctl start asm -n node06 [node06]$ export ORACLE_SID=orcl [node06]$ sqlplus / as sysdba SQL (orcl)> startup mount SQL (orcl)> recover database;

4. BCV から STD へのリストアが完了したら切り離しを行います。

Symmetrix

[node03]$ symmir -g DATADG split -consistent -noprompt

CLARiX

[node03]$ naviseccli -h 10.32.2.10 -User Admin -Password <password> -Scope 0 Snapview -ConsistentFractureClones -CloneGroupNameCloneID CX_RO 0200000000000000 CX_RW 0200000000000000 -o

以上で新の状態までのリカバリは完了です。

8.8.2. Point-in-Time リカバリ

1. バックアップ・サーバー上でターゲットを bkupとしRMANを起動します。

[node03]$ export ORACLE_SID=bkup [node03]$ rman target / catalog rcuser/rcuser@recov

2. リストアを行います。バックアップ取得時と同じく、allocate channel 句に

よって処理を並列化できます。until time ではどの時点までのリカバリを行

うのか指定します。


RMAN> run { allocate channel d1 device type disk; allocate channel d2 device type disk; restore database check readonly until time="to_date('2007/08/15 00:00:00','YYYY-MM-DD hh24:mi:ss')"; }

RMAN でリストアしたデータを、BCV から STD へリストアします。この

とき、制御ファイル(CTL_DG)、オンライン redo(REDO_DG)、アーカイブ・

ログ(ARCH_DG)のディスクグループはリストアしません。

以下の例はデータベース全体をリストアするケースです。

Symmetrix:

[node03]$ symmir -g DATADG restore -noprompt

CLARiX:

[node03]$ naviseccli -h 10.32.2.10 -User Admin -Password <password> -Scope 0 snapview -ReverseSyncClone -name CX_RO -CloneID 0200000000000000 -o

[node03]$ naviseccli -h 10.32.2.10 -User Admin -Password <password> -Scope 0 snapview -ReverseSyncClone -name CX_RW -CloneID 0200000000000000 -o

3. orcl の ASM インスタンスを起動、DB インスタンスをマウントし、Point-in-

Time リカバリします。RAC 環境の場合、1 つのデータベースに複数のイン

スタンスからアクセスしているため、1 つのノードでのみリカバリを行え

ば他のノードでリカバリを行う必要はありません。新の状態までのリカ

バリと同じく、リカバリは Symmetrix と CLARiX のリストア作業が開始さ

れた時点で実行できます。BCV から STD へ完全にデータがコピーされた

ことを待つ必要がないため、ダウンタイムを軽減できます。

特定の時刻までリカバリする場合、一重引用符で区切った書式

（ 'YYYY-MM-DD:HH24:MI:SS'）で時刻を指定します。次の文では、

2007/08/15 00:00:00 まで Point-in-Time リカバリします。

[node06]$ srvctl start asm -n node06 [node06]$ export ORACLE_SID=orcl [node06]$ sqlplus / as sysdba SQL (orcl)> startup mountl; SQL (orcl)> RECOVER DATABASE UNTIL TIME '2007-08-15:00:00:00';


4. Point-in-Time リカバリ後はオンライン・ログをリセットする必要がありま

す。たとえば、次のように入力します。

SQL (orcl)> ALTER DATABASE OPEN RESETLOGS;

5. BCV から STD へのリストアが完了したら切り離しを行います。

Symmetrix

[node03]$ symmir -g DATADG split -consistent -noprompt

CLARiX

[node03]$ naviseccli -h 10.32.2.10 -User Admin -Password <password> -Scope 0 Snapview -ConsistentFractureClones -CloneGroupNameCloneID CX_RO 0200000000000000 CX_RW 0200000000000000 -o

以上で Point-in Time リカバリは完了です

8.8.3. 総括

以上の検証によりストレージのミラー機能、RMAN を用いたバックアップ/リカ

バリの手順を確認できました。ストレージのミラー機能により切り離した BCV を、

RMAN を用いず dd 等でコピーして複数世代管理するというバックアップ方法も

考えられますが、毎回データベースのフルバックアップに近い容量のバックアッ

プデバイスを消費することになります。一方で本番環境にて RMAN を用いてバッ

クアップを取得すると、増分バックアップによりバックアップデバイスの消費を

抑えられますが、データ増加に伴うバックアップ取得時間の長時間化およびバッ

クアップ取得による本番環境への負荷を考慮したバックアップ計画を立てる必要

があります。本検証のようにストレージのミラー機能と RMAN を組み合わせるこ

とで、双方の長所を生かしたバックアップ/リカバリが可能になるといえます。


9. Appendix

9.1. Symmetrix TimeFinder の操作方法

TimeFinder はホストから Solutions Enabler ソフトウェアを使って操作します。

TimeFinder 用のコマンドは symmir です。操作方法の例を下記します。実行ユーザー

は root です。

まず、デバイスグループ作成します。デバイスグループに同時に操作したい全ての

STD と BCV を登録します。

[node03]$ symdg create DATADG [node03]$ symdg create ARCHDG

デバイスグループに STD と BCV を追加します。デバイスグループに指定する番号

はホストが使っているディスクボリュームの Symmetrix 内の LUN ID です。

[node03]$ symld -g DATADG add dev 0050 [node03]$ symbcv -g DATADG associate dev 02D0

全てのデータの ASM DG の STD ボリュームとそれぞれの BCV を追加します。

[node03]$ symld -g ARCHDG add dev 00EA [node03]$ symbcv -g ARCHDG associate dev 033F

全てのアーカイブの ASM DG の STD ボリュームとそれぞれの BCV を追加します。

TimeFinder の同期コマンド

[node03]$ symmir -g DATADG establish –noprompt [node03]$ symmir -g ARCHDG establish -noprompt

TimeFinder の切り離しコマンド

[node03]$ symmir -g DATADG split -consistent –noprompt [node03]$ symmir -g ARCHDG split -consistent -noprompt

(ASM の rebalancing が行われていない状態で、かつ Oracle begin backup と併用する

場合は、-consistent の代わりに -instant オプションも利用できます。)

TimeFinder のリストアコマンド（BCV のデータを STD にリストアする）

[node03]$ symmir -g DATADG restore –noprompt [node03]$ symmir -g ARCHDG restore –noprompt


9.2. CLARiX SnapView の操作方法

SnapView の操作は Navisphere GUI または naviseccli コマンドで行います。以下は

naviseccli で操作する例を記入します。Naviseccli は IP 経由で CLARiX にコマンドを

送信します。Naviseccli には CLARiX にアクセスするためのユーザーとパスワード、

コマンドの範囲（今回は SnapView）コマンドのアクション、クローン名とクローン

ID をパラメータと指定して実行します。実行ユーザーは root です。

9.2.1. STD と BCV を同期する方法

(各ペアに対して実行します)

# naviseccli -h <CX_IP_addr> -User Admin -Password <password> -Scope 0 snapview ¥ -SyncClone -Name CX_RW -CloneID 0200000000000000 –o # naviseccli -h <CX_IP_addr> -User Admin -Password <password> -Scope 0 snapview ¥ -SyncClone -Name CX_RO -CloneID 0200000000000000 -o

9.2.2. STD と BCV を切り離す方法

(複数のペアを同時に切り離すには全てのペアを指定し、-ConsistentFractureClones

オプションを使用します)

# naviseccli -h <CX_IP_addr> -User Admin -Password <password -Scope 0 snapview ¥ -ConsistentFractureClones -CloneGroupNameCloneID ¥ CX_RO 0200000000000000 CX_RW 0200000000000000 -o

9.2.3. BCV を STD にリストアする方法

# naviseccli -h <CX_IP_addr> -User Admin -Password <password> -Scope 0 snapview ¥ -ReverseSyncClone -Name CX_RW -CloneID 0200000000000000 -o # naviseccli -h <CX_IP_addr> -User Admin -Password <password> -Scope 0 snapview ¥ -ReverseSyncClone -Name CX_RO -CloneID 0200000000000000 -o

9.2.4. STD と BCV の状態およびその他の詳細情報調査する方法

# naviseccli -h <CX_IP_addr> -User Admin -Password <password> -Scope 0 snapview ¥ -ListCloneGroup -Name CX_RW

# naviseccli -h <CX_IP_addr> -User Admin -Password <password> -Scope 0 snapview ¥ -ListCloneGroup -Name CX_RO


10. まとめ

本検証により、EMC Symmetrix / CLARiX と Oracle Database 10g Release 2 の Grid 環境と

Partitioning Option を組み合わせることで、ILM 導入から運用、バックアップ/リカバリに至

るまでの統合的な ILM ソリューションが提供可能であることを確認できました。

ILM 導入および運用の方法は複数あり、環境に求められる可用性のレベル、もしくは作

業にかけられる時間によってそれぞれを選択することができます。またストレージのミラ

ー機能と RMAN の組み合わせによって、バックアップ/リカバリによる本番環境への負荷

削減、バックアップデバイスの節約が可能であることも確かめられました。


日本オラクル株式会社

〒102-0094 東京都千代田区紀尾井町4-1

ニューオータニガーデンコート

EMCジャパン株式会社

〒163-0466 東京都新宿区西新宿2-1-1

新宿三井ビル 55 階

Copyright © 2007 Oracle Corporation Japan. All Rights Reserved.

Copyright © 2007 EMC Japan K.K. All Rights Reserved.

無断転載を禁ず

このドキュメントは単に情報として提供され、内容は予告なしに変更される場合があり

ます。このドキュメントに誤りが無いことの保証や、商品性又は特定目的への適合性の黙

示的な保証や条件を含め明示的又は黙示的な保証や条件は一切無いものとします。日本オ

ラクル株式会社は、このドキュメントについていかなる責任も負いません。また、このド

キュメントによって直接又は間接にいかなる契約上の義務も負うものではありません。こ

のドキュメントを形式、手段（電子的又は機械的）、目的に関係なく、日本オラクル株式

会社の書面による事前の承諾なく、複製又は転載することはできません。

Oracle、JD Edwards、PeopleSoft、及び Siebel は、米国オラクル・コーポレーション及びそ

の子会社、関連会社の登録商標です。その他の名称は、各社の商標または登録商標で

す。

EMC / Oracle ILM Solution 検証...2007/08/15 · Oracle GRID Center: [EMC / Oracle ILM...

Documents

Transcript of EMC / Oracle ILM Solution 検証...2007/08/15 · Oracle GRID Center: [EMC / Oracle ILM...