1

2

3

システムの煩雑化

業務アプリケーション毎にシステム・リソースを構築してあることが多く見受けられます。この構成が採用される主な要因として、業務アプリケーションで問題が発生した際の問題切り分けが容易であることや、ハイエンドなリソースが比較的に安価で手に入るようになったことがあると考えられます。

4

5

リソースが増加することによる懸念点

「リソース維持のコストが肥大化」、「リソースの有効活用が出来ていない」、「監視範囲が広がることによる、運用コストの肥大化」など様々な問題があります。この問題点を解決するためにデータベース層を統合することを検討しますが、様々な要因により実際に統合することが困難な場合があります。

6

データベース統合の問題

統合時のコスト高、システム要件の違いなど様々な要因で実際にデータベース統合を実施することが困難となる場合があります。

7

統合コストの肥大化

データベース統合を実施するまでに、統合対象のシステム調査にてデータモデル見直しなどがあり、統合後のシステムテストなどで当初の想定以上のコストがかかる場合があります。このような要因により、当初想定していたコストを上回るような投資が必要になる場合があります。

8

システム要件の違い

各システムの稼働時間が異なり、なおかつ、システム・メンテナンスなどでシステム停止が必要になる場合、今まで対象システム単体の調整で出来ていたことが他業務との調整が必要になり、柔軟なシステム・メンテナンスが難しくなります。

9

セキュリティ・ポリシー違い

セキュリティ・ポリシーが正しく定義されているシステムと、考慮されていないシステムが存在する場合、これらのシステムを統合することは困難です。例えば、統合対象のアプリケーションが、システム権限が過剰に付与されたデータベース・ユーザを利用している場合、そのままデータベース統合をしてしまうと他のシステムのデータも漏洩の危険にさらされます。

10

Oracle Database 11g Release 2で容易に実現するサーバー・リソース統合

今までご紹介した問題は、データベース自体を統合する際に発生した問題点の一例になります。このような問題を回避するためにサーバー・リソースの統合を検討します。サーバー・リソース統合は仮想化技術を利用することでも実現することができますが、Oracle Database 11g Release 2 の新機能を利用することでも物理的なサーバー・リソースを容易に統合することが出来ます。

11

12

リソース統合による効果

データベース自体の統合になると、統合対象システムに対する調査などで想定より時間がかかることや、業務要件違いによる設計見直しなどで予想以上に工数が肥大化する場合があります。リソース統合であれば、データベース自体を統合するわけではありませんので業務システムに対しての調査などで想定以上に工数が肥大化するようなことはほとんどないと考えます。

13

Oracle Database 11g Release 2 で一元化のシステム構成

データベース・リソース以外にもアプリケーションサーバー・リソースに対してもOracle Clusterware 配下で管理することが可能になります。

14

プライベートクラウド化

リソースを共有し、業務システムのまとまった社内サイトを構成する形にすることが出来ます。特定業務に依存させることのないリソース群を構築することで、システムメンテナンスやリソース増強が容易になると考えます。

15

効果的な運用

サーバー統合することにより、全体のＩＴコストを下げることは魅力的ですが、それに伴う移行作業を考えると、簡単には踏み切れないということはありませんか。また、複数のシステムを1つのインフラに統合することにより、複雑化しかえって運用コストがあがることを心配されてはいませんか。

ここからは、11g R2の新機能を織り交ぜつつ、Enterprise Managerによるそれらの問題点の解決策をご紹介します。

16

移行コストの削減

移行の際に、もっとも工数がかかりやすく、また、見積りが難しいテスト・フェーズにおける有効な解決方法をいくつか紹介します。

17

データベース・リプレイ

ビジネスに不可欠な大規模アプリケーションは複雑で、非常に多様なトランザクションが発行されています。データベース・リプレイではこれらのトランザクションを時系列にキャプチャし、新しいデータベースでリプレイすることができます。

キャプチャ機能のみ、過去のバージョンのデータベースにバックポートすることができるため、11ｇ R2に移行した場合のシミュレーションを容易に行うことが出来ます。

データベース・リプレイではエラーや結果件数、パフォーマンスの相違点を検証し比較レポートを作成します。ただし、パフォーマンスについてはワークロード全体のデータベース時間での比較のため、個々のSQL文についての比較を行いたい場合には、SQLパフォーマンス・アナライ較のため、個 の Q 文に ての比較を行 た 場合には、 Q フォ ン アナライザを使用します。

18

データベース・リプレイ新機能

11ｇ R2では、データベース・リプレイにおいて、いくつかの機能強化が行われました。

前バージョンでは、専用サーバー構成のみサポートしていましたが、11g R2では共有サーバーやOracle Streamsのワークロードのキャプチャ・リプレイもサポートされます。

キャプチャしたワークロードにフィルター処理を行ったり、同じワークロードに対しての異なるリプレイの比較をグラフィカルなレポートとして表示することが出来ます。

また、リプレイ時にSCNでシーケンシャルにリプレイするだけでなく、各オブジェクトごとの処理

順序のみを満たすように指定をしたり、パラメータで負荷を上げることにより、キャプチャ時よりスケールアップをしたリプレイを行うことが可能になりましたスケールアップをしたリプレイを行うことが可能になりました。

19

SQLパフォーマンス・アナライザ

SQLパフォーマンス・アナライザは、ワークロードで実行されるSQL文をSQL Tuning Set(STS)としてまとめ、初期化パラメータ等のシステム変更の前後において、ＳＴＳ全体と、個々のSQLごとに、経過時間、CPU時間、バッファ取得数、物理アクセス数等の比較を行いレポート化します。

9iや10g等の過去のバージョンのデータベースでキャプチャしたSQL文を比較することも可能です。

20

SQLパフォーマンス・アナライザ新機能

11ｇ R2では、SQLパフォーマンス・アナライザにおいて、いくつかの機能強化が行われました。

強化点の1つ目は、9i、10ｇ等過去のバージョンのデータベースで収集したSQL文をテストするためのGUIのワークフローが追加されたことです。(前バージョンでは、PL/ＳＱＬのＡＰＩでのみ可能でした。)

21

SQLパフォーマンス・アナライザ新機能

SQLパフォーマンス・アナライザの機能強化点の2つ目は弊社のExadataのシミュレーションを追加したことです。

スライドの例では、同じSQL文でもExadata Storage Server上では、SMART SCAN (TABLE ACCESS STORAGE FULL) が実行され、78%のパフォーマンス改善のシミュレーション結果が得られています。

22

データ・マスキング新機能

データ・マスキングは、データベースに格納されたデータを、データ型、制約といったリレーショナル・データベースとしての整合性を保ったまま、無意味なデータに置き換える機能です。

固定文字列、ランダム文字列、リストから選択、値のシャッフルなど、さまざまな置換フォーマットを組み合わせて定義することが出来ます。

置換は即時、またはジョブとしてスケジュールされた時間に実行されます。マスクの定義は保存が可能で、一度マスクの定義を行えば、同じ置換処理を何度も実行することが可能です。また、各種定義情報はファイルに書き出し可能なため、同じ置換処理を別のデータベースで実行することも可能です。とも可能です。

11ｇ R2より、設定をEnterprise Manager Database Controlから行うことが可能になりました。

23

ポリシー管理

Enterprise Managerでは、セキュリティ、構成管理、ストレージ等のOracle社が用意したベスト・プラクティスを元に、システムの評価を自動的に行い、違反報告をグラフィカルに行います。

データベースに関するセキュリティ・ポリシー・ルールの例

・リスナー・ロギングの有効化

・内部表、管理パッケージへのアクセス権

・パスワードの変更

・監査ファイル・ディレクトリのアクセス権

24

25

運用コストの削減

複数のシステムを1つのインフラに統合する際、それぞれを個別に監視/運用をしていては安定稼動およびリソースの有効利用をすることはできません。Enterprise Manager Database Controlを使用することによって、同一クラスタ上のターゲットを一元管理することが出来、アラートやパフォーマンス問題の監視および問題の可視化が容易に可能です。

26

ASM領域監視

11g R2より、Enterprise Manager Database Controlに「クラスタ」タブが追加されました。

このタブでは、同一クラスタ上の各ターゲットのアラートの一覧確認や、インターコネクトなどのパフォーマンス情報等を見ることが出来ます。また、サーバー・プールやリソースの管理も「クラスタ」タブからのドリルダウンで行えます。

「ターゲット」サブ・タブより各ターゲットのホームページに移動可能です。たとえば、ASMインスタンスに移動すると、各ディスク・グループの領域使用量や、ACFSのマウント情報などを確認することが出来ます。

27

事前監視

表領域の使用率、アーカイブ領域使用率、共有プール空き領域、あるいは秒毎のトランザクション数やＲＥＤＯ生成量等スループットの評価に関する統計値など、安定運用のためには定期的に確認しておくべき様々な統計情報、メトリック値が存在します。Oracle Databaseでは、10ｇ以降データベースや、データベース・インスタンス、リスナー等のターゲットの種類ごと必要なビルトイン・メトリックを多く用意しています。これらのメトリックに対し、警告/クリティカルの2段階で

しきい値を設定し、しきい値に到達した場合アラートを生成します。アラート・メッセージはEnterprise Managerの画面に表示するだけでなく、メールでの通知やSNMP通知による他監視システムとの連携も可能です。

28

NEW

パフォーマンス監視

「パフォーマンス」タブでは、対象データベースの負荷状況、待機時間、セッション数など様々なパフォーマンス情報をグラフィカルに確認することができます。

クラスタ・データベースでは、クラスタ全体の情報を見ることができ、そこから各ノードの情報にドリルダウンできます。

例えば、ある1時点でレスポンスの悪化が見られた場合、その時間帯に負荷の高かったセッションやSQL文の実行統計や実行計画を確認できます。

また、11g R2より、該当SQLの直近の実行時統計の詳細を確認し、html形式のレポートとして保存や メール配信することもできます保存や、メール配信することもできます。

29

自動化されたパッチ適用

Enterprise Manager Database Contorolより、Oracleパッチおよびパッチ・セットのステージングおよび適用をウィザードで容易に行うことが出来ます。

ビルトイン・デプロイメント・プロシージャを利用し、Oracle RACデータベースのローリング・パッチ適用も自動的に行うことが出来ます。

30

31

32