Oracle for SAP T E C H N O L O G Y U P D A T E 日本語版 NEW SAP 顧客のためのOracle Index Compression Oracle database for SAP is safe, reliable and scalable - th

Transcription

1 Oracle for SAP T E C H N O L O G Y U P D A T E 日本語版 NEW SAP 顧客のためのOracle Index Compression Oracle database for SAP is safe, reliable and scalable - the Grid enabled platform No. 18 Oracle for SAP, May

2 Oracle for SAP is safe, reliable and scalable the Grid enabled platform CONTENTS 3 ご挨拶 SAP 顧客の皆様へ 4 SAP 顧客向けの Oracle Database 11g Release 2 の展望 6 SAP 製品に対応した Oracle Database の機能に関するアップデート情報 10 大規模データベースの管理性と Oracle Index Compression 24 Oracle 10g RAC for SAP - ニュー サウス ウェールズ消防隊 26 Oracle 10g RAC for SAP Kuwait Petroleum Q8 28 Oracle RAC for SAP - National Gas Company of Trinidad and Tobago 31 SAP 認定の RAC システム構成 (Windows and Linux) 32 Oracle 10g RAC for SAP - Gottwald Port Technology GmbH 35 Oracle 10g RAC for SAP - Deutsche Telekom 37 Oracle 10g RAC for SAP - Indian Express 40 Oracle 10g RAC for SAP ASE Group 43 Oracle 10g RAC for SAP ASE DIEHL Informatik 45 Oracle 検索キー圧縮 Bauerfeind 48 Oracle Table Compression - カプコン 52 SGI と SAP on Oracle Database MTU Aero Engines 55 Oracle 10g for SAP Chevron Corporation 59 SAP on Oracle Database Consulting ALL4it 60 Oracle Advanced Customer Services for SAP 65 SAP on Oracle で役に立つリンク集

3 Oracle Database for SAP - 安全で信頼性が高く スケーラブルで SAP 顧客のために最適化された最高のデータベース 3 SAP 顧客の皆様へ オラクル コーポレーションとSAP AGは現在 共通の顧客を対象とした取り組みを進めており 長期にわたるリセラーおよび顧客サポート契約を締結しました この契約は Oracle Databaseテクノロジーへのアクセス機能を拡張し 顧客サービスの改善を図るものです Oracle Databaseは 安全で信頼性がありスケーラブルなデータベースとして 20 年以上にわたりSAP 顧客に選ばれてきました Oracle DatabaseはSAPアプリケーション向けに最適化が続けられ 世界中の中小規模から大規模に至るまで SAP 顧客の60% が 業種を問わずOracle Database 上にSAPアプリケーションをインストールしています 顧客は すべての主要なオペレーティング システム上で Oracle DatabaseとSAPアプリケーションを稼動させています この冊子では SAP on Oracle Databaseの顧客に特に利益をもたらす最も重要なテクノロジーに焦点を当てます SAP 顧客に以下のメリットを提供できるのは Oracle Databaseのみです 最高のパフォーマンスとスケーラビリティ 優れたロッキングと同時実行性 Real Application Clusters(RAC) Oracle Databaseは SMPとクラスタの両方の環境でSAP SDベンチマークを行った結果 優れた拡張性を示す世界記録を達成しました マルチバージョンの読取り一貫性とは 読込みが書込みをブロックせず 書込みも読込みをブロックしないことを意味します これは 最高のデータベース パフォーマンスを達成するための主要コンポーネントです Oracle Real Application Clusters(RAC) は SAPアプリケーションに対して ほぼリニアのスケーラビリティ ( 拡張性 ) を達成するための柔軟な機能を提供します RACを使用することにより 顧客はデータベース サーバー レイヤーの拡大または縮小を選択できるようになりました すべての RACノードはアクティブです そのため SAP 顧客が本番システムのワークロード要件を満たすために役立ちます 多くの顧客が採用しているOracle RACは すべての SAP 製品向けに認証され 誰もが利用できるクラスタ データベース ソリューションです OSに対する高い柔軟性最も広範なプラットフォームをサポート UNIX - Linux - Windows - Oracle is Oracle is Oracle すべてのオペレーティング システムでコード ベースが同じです これは すべてのハードウェア プラットフォームとオペレーティング システムで Oracleの機能やツールが同じであることを意味します 顧客は 自社の環境で最もコスト効率の良いプラットフォームを選択できます 顧客がオペレーティング システムを変更する必要がある場合 Oracleは高速で効率的なOracle-to-Oracle(O2O) 移行サービスを提供します 最高の可用性と信頼性 Real Application Clusters(RAC) Data Guard(DG) RAC for SAPは データベース サーバーが障害の単一障害点にならないようにし 様々な業種の顧客が採用するあらゆるプラットフォームで拡張されたパフォーマンスとスケーラビリティを提供しています Oracle Data Guard(DG) は Oracle RACとフラッシュバック テクノロジーを補完します 世界中の SAP 顧客によって最適な障害リカバリソリューションとして使用されています RACとData Guardを併用することにより SAPデータはハードウェア障害やデータ センターの障害から保護されます 大規模データベースに最適なサポート Oracle Databaseのディスク領域使用の効率の良さは すでに多くの人が知っています SAP 顧客にとって 飛躍的に増大し続けるデータベース サイズは非常に重要な問題です Unicodeは 今や新しいSAP 製品にとって必須な上 その移行にはデータの完全なアンロードおよびロードが要求されます オラクルの最適化により 最も高速なSAP Unicode 移行が実現されます この移行は データ転送レートが1テラバイト / 時間で行われ 完全にSAP 製品に統合されます 最大規模の数テラバイトのデータベースでも 1 回の週末で移行が完了します Oracle Databaseを使用するSAP 顧客は 追加費用なしで索引キーの圧縮機能を利用して ディスク領域を節約することもできます 膨大な しかも増え続けるデータは システム パフォーマンスに影響を与え続けます パーティショニングを実現するオラクルの様々な機能によって I/Oを削減し パフォーマンスを改善することができます HP Oracle Exadata Storage ServerへのSAPのインストールについては SAPによるOracle Database 11g Release 2の公式な出荷開始後に評価されます 最高のデータベース セキュリティ法令遵守 ( コンプライアンス ) とセキュリティの重要性は かつてないほど高まっています Oracle DatabaseのAdvanced Security Optionに含まれる Transparent Data Encryption(TDE) は ディスクへの書込み時にデータを透過的に暗号化することで 機密データを暗号化します Oracle Database Vaultは 職務分掌を実現させることにより 顧客が法令遵守の要件を満たすことを支援する製品です ( 詳細については Oracle for SAP TECHNOLOGY UPDATE No. 17を参照 ) 最高のデータベース管理性とSAPの自己管理機能 SAP DBA Cockpit SAP BR*Tools for Oracleは Oracle Automatic Workload Repository(AWR) を使用しています AWRでは ワークロードとパフォーマンスの統計情報が自動的に保存されます そのため 管理者やサポート担当者は 根本的な原因がいつ発生してもパフォーマンスの問題を分析し短時間で解決することができます この冊子では これらの機能と顧客のサクセス ストーリーを紹介します また データベース移行 パフォーマンス チューニング ヘルス チェック および内部トレーニングのワークショップを含めた SAP 顧客向けのOracle Advanced Customer Services(ACS Oracleレスキュー サービス for SAP) についても 詳細をご確認ください 詳細な技術情報は 英語版 ) または 日本語版 ) を参照ください ご意見 ご質問は SNSサイトmix.oracle.com/groups/15251にお寄せください Sincerely オラクル コーポレーション ( 米国 ) SAPアライアンス担当シニア ディレクター ゲルハルト カップラー

4 4 SAP 顧客向けの Oracle Database 11g Release 2 の展望 現在 Oracle Database 11g Release 2のテストが SAP で実施されています これまでの認定と同様 SAPでは自社製品を使用してOracle Database 11g Release 2を認定します Oracle Database 11g Release 2には SAP 顧客に大きなメリットをもたらす機能があります この章では 現在 SAPで利用を計画している機能を示します これらの機能は SAPによる Oracle Database 11g Release 2の認定後に実装される予定です Secure Files Secure Filesは 非構造化データを格納するための新しいアーキテクチャを実現し 旧バージョンのデータベースの LOBデータ型に取って代わります Secure Filesは LOBを超えるパフォーマンスとスケーラビリティを提供し ディスク領域を削減する再複製機能も提供しています オプティマイザの拡張と統計のメンテナンス Oracle Database 11g Release 2のオプティマイザは SAP BIクエリーのパフォーマンスを拡張し SAP ERP のSQLステートメント内の値の変更を高精度で認識します 特にパーティション化されたオブジェクトの統計のメンテナンスが強化され 旧バージョンのデータベースと比較して統計計算の精度と速度が大幅に改善されています 自動インターバル パーティショニングパーティション化されたオブジェクトのメンテナンスは完全に自動化され データベース サーバーが自動でパーティションを管理します OLTP 表の圧縮 Advanced Compressionオプションの一環として 表データを圧縮し ディスク領域を削減して問合せのパフォーマンスを向上させます 索引キーの圧縮と Secure File 圧縮の組合せにより Oracle Database 内のすべてのタイプのデータを圧縮して保存できます Secure File 圧縮リレーショナル表データだけでなく 非構造化データも Oracle Database 内で圧縮できます Secure File 圧縮機能はAdvanced Compression オプションに含まれます Oracle Database 11g Release 2は Secure Filesに保存されている SAP の名前付き表 索引および非構造化データが使用するすべてのデータ型を圧縮できる唯一のデータベースです オンラインでのパッチ適用オラクル独自の特許取得済みテクノロジーにより データベースの稼動中でも単一または一連のパッチが適用できます これによって データベースの停止時間が劇的に削減します オンラインからのパッチ適用は シングル インスタンスや RACの共有 Oracle HOMEインストールを SAPで利用する場合に使用できます ディクショナリのみの列追加 SAPアプリケーションで 新しい列を追加する必要がある場合 11gより前のバージョンでは 表の各列に対して更新文を生成するために 列追加アクティビティで著しく時間がかかりました Oracle Database 11g Release 2では このようなことはありません アプリケーションが列にアクセスしたときのみ 新しい列のデータが移入されます このため SAPアプリケーションから実行される列の追加は瞬時に完了し Oracle Database 11g Release 2 以前のバージョンのように 数分または数時間かかることはありません

5 SAP における Oracle 11g の展望とサポートされる 10g の機能 5 空のオブジェクトに対するセグメントの割当て Oracle Database 11g 以前のバージョンでは オブジェクトにデータが含まれていない場合も 必ず各オブジェクト ( 索引 表 パーティション ) に初期エクステントが割り当てられていました Oracle Database 11g では データがオブジェクトに挿入されるとエクステントが割り当てられますが 空のオブジェクトの場合 エクステントは割り当てられません インストール後は 多くのオブジェクトが空であるため これは SAPインストールに有益です この機能により SAPのインストール時間が短縮され 初期のディスク領域要件も大幅に少なくなりました Direct NFS Oracle Database 11gには 認証済みの NASシステムからデータベース カーネルに直接 NFSファイルシステムをマウントできる機能があります この最適化により 従来からの NFSクライアントのオーバーヘッドが回避され 認証済みの NASシステム上にある Oracle Databaseのスループットが改善されます 表領域の暗号化 Oracle Database 11gのAdvanced Security オプションには 表領域内のすべてのデータを暗号化するテクノロジーが含まれています 特に SAPシステムでは 機密データの暗号化が非常に簡単になりました

6 6 SAP 製品に対応した Oracle Database の機能に関するアップデート情報 はじめに Oracle Database 10gは エンタープライズ グリッド コンピューティング向けに設計された最初のデータベースです 低コストのコンポーネントの利用とリソースの使用率の大幅な向上により ハードウェアのコストを削減し SAPの Adaptive Computing Infrastructure というコンセプトを実現します SAP 顧客がOracle Database 10g Release 2を使用できるようになってから 10gの採用がSAP 顧客の間で急速に広がっています Oracle 10g RACは 2009 年 1 月から すべてのプラットフォームの SAPバージョン 4.6C 以降で使用できるようになりました 次に SAP 顧客が現在利用できる重要な機能の一部を示します Multiple Oracle Patch(MOPatch) ユーティリティ多数のSAPインストールを処理する場合 UNIXや Linuxプラットフォーム上のデータベース用の単一パッチのメンテナンス作業は 時間がかかり面倒です とくにデータベースのパフォーマンスについてカスタマー サポート センターに寄せられる多数の問合せから判断すると データベースはかならずしも推奨されるパッチ レベルになっていません この領域でデータベース管理者をサポートするために開発された新しいパッチ ユーティリティ MOPatchにより SAPアプリケーション用の Oracle DatabaseはSAPが認定したパッチの最新セットを必ず使用する運用がしやすくなります MOPatchの使用方法は SAP Note を参照してください ROWID 分割 SAP Unicode 移行では R3loadを使用しデータベース全体を完全にエクスポートおよびインポートする必要があります 一般的に エクスポートやインポートにかかる時間は いくつかの単一の表の大きさに左右されます とくに RFBLG COEP GLPCAなどの表は データベース内の他の表と比べることができないほど大きなサイズの表です エクスポートおよびインポートにかかる時間を短縮するには これらの表を小さく分割し 表部分ごとに単一の R3loadジョブで作業を行います ROWID 分割をしない場合は 各部分の範囲の計算に非常に時間がかかり 多くのリソースを消費します 各表部分のWHERE 句の開始ポイントとエンド ポイントの計算は 表全体または索引全体のスキャンのいずれかが必要になります そのため多くのコストがかかります 列値による WHERE 句を使用した R3loadエクスポートは 索引と表の両方のデータにアクセスする必要があります そのため この場合も多くのコストがかかります Oracle Database 用のROWID 分割テクノロジーは 索引へのアクセスと ROWID 範囲の生成を回避するため データを物理的にディスクから読み取ることができます ROWID 分割には 2つの重要な利点があります まず 範囲はわずか数秒で計算されます これは Oracleデータ ディクショナリに格納されている物理構造情報を使用するためで 数分または数時間かかる列へのWHERE 句の使用に比べ 大幅な時間短縮になります 次に 実際のR3loadエクスポートは索引を使用しません ディスクから物理的な順序でデータを読み取るため 劇的な速さで完了します 顧客環境の実績として ROWID 範囲を使用した R3loadエクスポートは 10~20 倍高速で CPU 使用率が低いことが判明しています ROWID 分割を使用した Unicode 移行は エクスポートおよびインポートで高速化を実現しました 索引キーの圧縮 B*Tree 索引をディスクやメイン メモリーに効率的に保存し ディスク領域の削減と問合せのパフォーマンスを向上させます 索引用の領域は70% までディスクに削減でき 問合せのパフォーマンスも最大で30% 向上します SAP 環境で索引圧縮機能を使用する方法は SAP Note を参照してください Instant Client Instant Clientを使用すれば 標準のOracleクライアントをインストールしたり ORACLE_HOMEを作成したりせずにアプリケーションを実行することができます SAPなどのOCIベースのアプリケーションは修正なしで動作し 使用する領域も大幅に減少します SAPの新規カーネル 4.6D_EXT2と6.40_EXT2のリリースに伴い Instant Clientは4.6C 以降のすべてのバージョンの SAPシステムで使用できます 詳細は SAP Note および を参照してください

7 SAP における Oracle 11g の展望とサポートされる 10g の機能 7 Oracle Advanced Security Network Encryption Oracle Advanced Security Network Encryption は Oracle Databaseとの双方向通信を保護する設定が容易なソリューションを提供します これには 標準ベースのネットワーク暗号化 ネイティブで堅牢な暗号化アルゴリズムと整合性アルゴリズムが使用されます NetWeaver 2004ベースのすべてのSAP 製品で ABAP Javaのアプリケーション サーバーと Oracle Databaseを結ぶネットワーク通信を暗号化できます 分析対象のオブジェクトを追跡したり 手作業で分析を実行したりする必要がありません 変更を認識する増分バックアップ新しいタイプのログ ファイルを使用して データベース内で変更されたブロックを追跡することにより RMANでは 増分バックアップ時にデータファイル全体のスキャンを回避できます スキャンされるデータ量は 変更されたデータ量に比例します Oracle Advanced Security Transparent Data Encryption(TDE) ディスクへの書込み時にデータを透過的に暗号化することで 機密データを暗号化します 表領域の名前変更表領域名が変更できます 表領域を新規作成して古い表領域からコンテンツをコピーし 古い表領域を削除するといった煩雑な手順は必要ありません この機能により たとえばディクショナリ管理表領域からローカル管理表領域への変換や 同じ名前の表領域を持つ表領域のデータベースへの追加など MCOD 環境における操作が簡単になります オンライン セグメントの縮小空き領域を持つ表や索引のセグメントをオンラインかつ同じ領域で圧縮することにより 領域の使用効率を向上させます エンド ツー エンドのアプリケーション トレース多層環境におけるパフォーマンス上の問題が簡単にデバッグできます この機能は 新しいバージョンの SAPソフトウェアでのみ使用でき 既存のバージョンでは使用できません LONG 型からLOB 型へのオンライン移行このリリースでは 多数の SAPアプリケーションで使用されている LONGおよび LONG RAWデータを持つ表を SAPのBR*SPACEユーティリティ内から LOBデータへオンラインで移行できます オプティマイザ統計情報の自動収集この機能は オブジェクトのオプティマイザ統計情報の収集を自動化します 古い統計のオブジェクトや統計情報のないオブジェクトは自動的に分析されるため 管理者は Flashback Database Flashback Database 機能は Oracle Database 全体を過去のある時点まで迅速に戻すことができます 1つの表を過去のある時点に戻すこともできます SAP 環境でこの機能を使用する方法は SAP Note を参照してください Data Pump ExportおよびImportユーティリティ Data Pump Exportユーティリティおよび Data Pump Importユーティリティは データベース間でデータとメタデータを高速バルク移動します これらのユーティリティには もとの Exportユーティリティおよび Importユーティリティと比較して 大きなメリットがあります たとえば エクスポート ジョブおよびインポート ジョブの完全な再起動機能 長時間実行されているジョブの切断と再接続機能 エクスポート ジョブが消費する領域の算出機能 ネットワークを介したエクスポート操作およびインポート操作のサポート オブジェクトとオブジェクト タイプに基づく詳細なオブジェクト選択のサポートなどです 新しい Data Pump Exportユーティリティおよび Data Pump Importユーティリティはパラレル実行が可能なため データとメタデータのロードおよびアンロードのパフォーマンスが向上します クロス プラットフォームのトランスポータブル表領域トランスポータブル表領域機能により 異なるプラットフォーム間で表領域を転送でき SAP 顧客のプラットフォーム移行がさらに容易になりました データベース全体に対するBEGIN BACKUPコマンド個別のコマンドを発行して各表領域をホット バックアップ モードに移行する必要がありません ALTER DATABASE 文を使用して すべての表領域をバックアップ モードに設定できます また BEGIN BACKUPコマンドの実行速度が高速化されました

8 8 SAP B I 7.0 の新機能 Oracle10g Real Application Clusters(RAC) ここでは SAP BIユーザーに大きなメリットをもたらす新機能について説明します すべての SAP BI 顧客は これらの機能をすぐに使用できます 表の削除および切捨ての高速化データベース バッファ キャッシュにアクセスする際のアルゴリズムが改善され 表の削除および切捨て (dropと truncate) が高速化されました 特に SAP BIで頻繁に使用する小さい表で顕著です メモリー内 Undo データベース サーバーによる短いトランザクションのブロック変更の管理方法が改善され CPUサイクルが短縮されました パーティション化されたオブジェクトのスケーラビリティの向上バッファ キャッシュ内でパーティション化されたオブジェクトのブロックを識別し これらのブロックを消去するアルゴリズムが新しくなったことで パーティション化された表や索引の削除が大幅に高速化されました SAP B Iアプリケーションでは パーティション化されたオブジェクトの削除が頻繁におこなわれるため 最大の効果が得られます 1,000 以上のパーティションを持つ表で問合せを使用しておこなったテストでは パーティショニング メタデータを共有するOracle 10gの新しい方式により SGA 内のSQLメモリー使用量が減少しました ( :52KB 10.2:11KB) つまり この表の各問合せで使用するメモリーは 5 分の1 になります ODM Connector 2.1 Oracle Data Mining Connector 2.1は Oracle Database 10g Data Miningオプションの高度なすべてのデータ マイニング アルゴリズムを活用します Oracle Data Mining Connector 2.1は Analysis Process Designerと完全に統合され BW 3.5 顧客と BI 7.0 顧客にとってセキュアでスケーラブル かつデータベース上で稼働する分析エンジンとなります Oracle Real Application Clusters(RAC) により Oracle Databaseでは クラスタリングされたサーバー上ですべてのパッケージ アプリケーションやカスタム アプリケーションを変更せずに実行できます これにより 最高レベルの可用性と最も柔軟なスケーラビリティを実現します コストを低く抑えるためには 標準化されたコモディティ製品で最高性能のシステムを構築することも可能です Oracle RAC 10g は オラクルのエンタープライズ グリッド コンピューティング アーキテクチャの基盤を提供します Oracle RACテクノロジーにより 低コストのハードウェア プラットフォームで 最も高価なSMPのメインフレームで得られる可用性とスケーラビリティを超える高品質のサービスが実現します Oracle RAC 10g は 4.6C 以降のSAP システムのすべてのプラットフォーム上で使用できます 統合クラスタウェア Oracle RAC 10g は 完全なクラスタウェア管理ソリューションを提供します このソリューションは Oracle 10g が稼働するすべてのプラットフォームで使用できる Oracle RAC 10g にとって不可欠な構成要素です クラスタウェア機能には クラスタの接続 メッセージ交換とロック クラスタ管理とリカバリ サービスのプロビジョニングを行うフレームワークなどのメカニズムが含まれます サード パーティのクラスタウェア管理ソフトウェアを購入する必要はありません ただし オラクルは 特定のプラットフォーム上で精選されたサード パーティ製のクラスタウェアも引き続きサポートします Oracle Database 10g Release 2では Oracle 以外の処理をOracle Clusterware 内の高可用性フレームワークで制御できるように 高可用性 APIが提供されます

9 SAP における Oracle 11g の展望とサポートされる 10g の機能 9 SAP Control(SAPCTL) Oracle Clusterwareは SAPリソースに対して Oracle リソースと同様の高可用性を提供します オラクルでは SAPの高可用性リソースを簡単に管理できる SAP Control(SAPCTL) という Oracle Clusterwareツールを開発しました SAPCTLは リソース スクリプト Oracle ClusterwareとSAPの高可用性コンポーネント間の依存性を管理する使いやすいインタフェースを提供します SAPCTLでは ABAPと Java 用のSAP Enqueue Service ABAPと Java 用のSAP Replication Service ABAPと Java 用のSAP Enqueue Serviceで使用する追加の仮想 IPアドレスを簡単に管理でき Oracleのコマンドライン ツールの機能を統合します さらに SAPCTL はメッセージ サーバーとダイアログ インスタンスにも対応します SAPCTLの導入により 6.40 以降のカーネルをベースとしたSAPシステム ( 現在 このツールを利用できるのは LinuxとAIXのみ ) では 重要なSAPサービスの管理と制御にサード パーティ製ソフトウェアは必要ありません EMC Celerra NFSサーバーの追加サポート Linuxプラットフォーム上で SAP/RACをインストールする SAP 認証済みのNetApp NFSサーバーに加え SAP 顧客はNFSを使用して EMCのNASシステム Celerraを利用できます 単一システム イメージ管理 Oracle 10g Enterprise Managerの大幅な機能拡張により クラスタ データベースのインストールを単一のシステム イメージで管理できます Enterprise Managerのクラスタ データベース ページには 複数のノードにわたるシステム ステータスが単一ビューで表示されます 必要に応じて 個別インスタンスに直接ドリルダウンすることもできます 新しいクラスタ構成検証ツールと Oracle9i から導入された診断ツールの機能拡張により 問題を回避したり 発生した問題を迅速に解決することができます Oracle Data Guardの統合による障害時リカバリ Oracle Enterprise Manager 10gでは Oracle Data Guardの管理コンポーネントである Data Guard Broker がRACに完全に統合されます Oracle RACデータベースを含む Oracle Data Guard の障害時リカバリ環境は データベースの単一インスタンスを使用している環境と同様 簡単に管理できます Oracle Database Vault Oracle Database Vaultは 法令遵守やインサイダーの脅威に対して強力な内部統制をおこないます Oracle Database Vaultを実装すれば DBAはユーザー データを調べる権限が無くなります 700カーネルベースの SAPアプリケーション (ECC 6.0 BI 7.0など ) をOracle Database 10g で実行しているすべての SAP 顧客は 2009 年 7 月末より Oracle Database Vaultを使用できるようになりました 結論 Oracle Database 10gは 変化を続けるビジネス環境に SAPを対応させるために必要なインフラを提供します 低コストのサーバーとディスクでも エンタープライズ グリッド コンピューティングを実現できる柔軟性が得られます エンタープライズ グリッド コンピューティングは SAPの Adaptive Computing Infrastructure のコンセプトを補完する概念です Oracle Database 10g は リスクの軽減というメリットをもたらすと同時に 管理コストを削減し スケーラビリティと予測可能性を高め 最高レベルの可用性を実現します

10 10 大規模データベースの管理性と Oracle Index Compression - Oracle 索引圧縮 SAP パーティショニング エンジン バックアップ テクノロジー はじめに最近まで 1テラバイト以上のサイズのデータベースは 世界広しと言えども上位 10 個だけである と言われていました 事実 一部の科学者は Proceedings of the International Conference on Very Large Databases (VLDB) などの定期刊行物に論文を発表しました インターネットではしばしば Taming the Beasts ( 猛獣を飼いならす ) についての記事を見かけましたが 誰も巨人や怪物を見たことがないように このような指摘はおとぎ話に過ぎないと思われていました ふたつめの問題は特別な問題です 大容量データの潜在的な脅威を ERPシステムの開発者が事実上無視しているため これらの環境でデータベースは扱いにくい 野獣 になりがちだということです つまり 怪物は現実のものとなり データベース管理者の悪夢も現実になります 本当にそうでしょうか 一般的な考慮事項 しかし今日の世界には 巨人や怪物が溢れています SAP 世界では 1テラバイト (1TB) のデータベースはローエンドであると見なされ 現在ハイエンドの顧客は 20~ 50テラバイトのデータベースを管理しています これらの顧客の何社かが 100テラバイトに到達するのはそう遠いことではないでしょう 意思決定 (DSS) データベースが 常に OLTPデータベースと比較して非常に大きいという定説も 最近ではなくなりました データベースが巨大になるという思いも寄らない出来事はかならず そして唯一 DSSデータベースで起こる というのが暗黙の了解でした このため 大量のデータを処理できるテクノロジーについて心配しなければならないのは DSSシステムの設計者のみで OLTP システムについては 何の問題もないというのが当然の結論でした 現在 様々な業種 ( 小売 ユーティリティなど ) の多くの SAP 顧客は 自社の SAP ERPシステムのデータベース サイズが SAP BIシステムのデータベース サイズと同じか それよりも大きいことに気が付いています また ERP システムは BIシステムのように大量のデータを処理できないことにも気が付いています 上記により 今日の SAP 顧客の多くが 2つの密接に関連する問題に直面していることを物語っています 最初の問題は一般的な問題で データベースが肥大化するスピードが以前より加速しているため データベースをコントロールできるテクノロジーやツールを緊急に必要としていることです データベース増大の理由なぜ データベースは短期間で肥大化するのでしょうか 取るに足らない質問ですが 質問の答えは誰もがよく知っています より詳細な情報がOLTPシステムに保存されるようになったためです 小売業者は文字通りビールを 1 瓶ずつ追跡し 輸送業者は小包の経路を1 つずつ追跡します Webベースの取引では 取引の詳細をすべてデータベースに保存する必要があります データベースが肥大するもう 1つの理由は 統合です 以前は独立していたローカルまたは部門のシステムが 真の単一のソースとしてのグローバルなシステムを作成するために統合されています また 企業間の買収が進み古いシステムと新しいシステムを統合する必要が生じています 規制要件により 企業は履歴データを数か月間 また場合によっては数年間もデータベースに保存することが義務づけられています 顧客は 電子メールや PDFファイルなどの非構造化データを より大量に保存する必要があります それでもやはり なぜこのデータベースは こんなに肥大するのか と自問することが大切です なぜならほとんどの場合 この質問の答えに解決のヒントが隠されているからです もし履歴データの量がその問題の中心であったならば データベース管理者は履歴データの日常

11 SAP 顧客向けの Oracle 索引圧縮 11 業務への影響を最小限にするための戦略を探すことです もし 企業の買収がその理由の中心であったならば データベース統合後でもこれまで独立していたデータを論理的に分離する方法を模索することが役立つでしょう 問題点データベースが大規模に さらに巨大になっていくと多くの企業は いずれ少なくとも次の3つの問題で苦戦し始めます 一番はっきりした問題は ディスク領域や他のハードウェア コンポーネントにかかる費用の増加です 確かにハードディスクは より安価になっていますが SAPの世界では 開発システムとテスト システムを備えた本番データベースは高可用性ソリューションであり バックアップ メディアが必要です このためほぼすべての顧客にとって データベースそのもののサイズが 1TB 増加すると 実際 8~10TBの追加ディスク容量が必要になります さらに データベース サーバー マシンにも 追加メモリーと CPUパワーが必要になるでしょう 増加するデータ量と増加する複雑なアプリケーションの数が パフォーマンスを低下させている可能性があります 最後に データベース管理者は 管理性の矛盾 と呼ばれるものに直面します データ量が増加すると メンテナンスの時間が長くなりますが 現実にはメンテナンスに使用できる時間はどんどん短くなっています それは グローバルに使用されるシステムの可用性への要求が加速しているためです ここでは 管理性という側面を中心に説明します TCO やパフォーマンスには触れないということではありません メンテナンスの時間を短くするための機能や戦略が コストの削減やパフォーマンスを向上させる場合があります しかし ここで考慮する対象は データベース管理者と管理性の矛盾への対処方法です また オラクルのデータベース テクノロジーについても説明します データベース テクノロジーは アプリケーションやストレージの設計と完全に分離させることはできません しかし 管理者が今日のデータベースに取り組むときに役立つオラクルのテクノロジーを知っておくことは 言うまでもなく有益でしょう 一般的戦略それぞれのテクノロジーを検証する前に データベース肥大化に対応する一般的な方法 つまりテクノロジー選択の方針を検討することが必要です 最も一般的なアプローチは 3 語に集約されます Buy more Hardware( より多くのハードウェアの購入 ). 費用の増加に対する苦言にもかかわらず これは今もって一般的なアプローチです 理由はアプリケーションやデータベースの再設計が必要ないという 少なくとも一番簡単な方法だからです 使い慣れたタイプのハードウェア コンポーネントをいくつか追加するだけで済みます このアプローチは 一定の限度内であれば特に問題ありません データベースにはディスク領域は必要ですし データベース サーバーにはメモリーと CPUが必要です しかし ハードウェア レイヤーのみを検討する場合 このアプローチは危険でもあります データベースのフラグメント化が進みすぎている場合や いくつかの単純な結果を検索するためにアプリケーションが大量のデータをスキャンしなければならない場合など 大量のメモリーを投入しても期待できるほど改善は見られません 2 番目のアプローチは Shrink the Database( データベースの縮小 ) は有益であるという考え方に基づいています このアプローチには 2つの主な特色があります 1 つは アーカイブ化です 定期的に 履歴データ ( まれにアクセスするか まったくアクセスしないデータ ) をデータベースからアーカイブに移動します この操作は ディスク容量を解放し データベース応答時間を一定に保ちます これによりデータベースの肥大化が減速します もう 1 つは 圧縮です この基本的な考え方は 少なくともデータの一部を よりコンパクトに保存することにより データベースのサイズを縮小することです これらの戦略は確かに役立ちますが 欠点もあります SAPの世界では SAPによってアルゴリズムとツールが提供されているため ここでアーカイブ化について多くのことを述べる必要はありませんが アーカイブ化には 特に法的ないくつかの制限があります 企業は独自で データをアーカイブする時期を決定できません いつアーカイブするかは法的な要求事項に従う必要があります また アーカイブ化には副作用もあります この副作用については オラクル テクノロジーの項で説明しますが 最も顕著で危険な副作用は データのアーカイブ

12 12 化によるデータベースのフラグメント化です 圧縮の場合も同様です オラクルには 最も包括的な圧縮機能のセットを提供しているという自負があります しかし データベース ベンダーの中には 肥大するデータベースの唯一の対応方法が圧縮で データベース全体を単純に圧縮することが洗練された領域管理戦略だと顧客に信じ込ませようとするベンダーもいます そして 顧客がその巨人をともかく締め続けられれば おそらくデータベースは小さくなります しかしここで忠告します 現実を直視せよと 圧縮には代償があります 適切に使用された場合は パフォーマンスに若干のオーバーヘッドが生じます 不適切に使用された場合は パフォーマンスに深刻な影響が生じます さらに データベースの肥大化は圧縮では止められません 単に肥大する速度が遅くなるだけです 圧縮神話を信じて 別の戦略を探すことをしなかった場合 2 ~3 年後には問題が再発し そのとき事態はもっと悪化しています この弱点に対する追加の戦略は 有名な言葉に要約できます Divide and Conquer( 分割統治 ) です 重要な要素は 管理するエンティティを単純に個別の単位にする考えをやめることです そのかわり 論理構造を探し実装して使用します 1 個のデータベース 1 個の表 1 個の索引 そして 1 個のアプリケーションでさえも 個別のブロックではありません 注意して見れば これらはすでに内部構造を提供しているか 少なくとも構造を実装するチャンスを提供します このような構造には 独立して取り扱うことができる より小さな部分に分割可能であるという利点があります データベース ( 表 索引 ) を圧縮すべきでしょうか それとも圧縮しないままにした方が良いでしょうか データを安価なディスクに保存すべきでしょうか より高価なディスクに保存すべきでしょうか 毎日データをバックアップすべきでしょうか これらの疑問 ( これだけではありません ) に共通する特徴は 疑問の焦点が絞られていないため 納得のいく答えができないことです 次のように自問することで より的確な答えが得られるでしょう データベース ( 表 索引 ) のどの部分を圧縮すべきでしょうか データのどの部分を安価なディスクに保存し どの部分を高価なディスクに保存すべきでしょうか データベースのどの部分を毎日バックアップすべきでしょうか 照 ) 独立したいくつかの 情報の島 がひとつに統合されたグローバル データベースは 特に企業管理の面でユーザーにとって大きな利点があります グローバル データベースは 真の単一ソースであるため重要な疑問に対する有意義な答えを提供してくれます もちろん データベース管理者は すでに述べたように管理性の矛盾という欠点にもすぐ気が付くでしょう しかし 肥大したデータベースが脅威になり データベース サイズが管理者にとって問題になるのは すでにプロジェクトも最終段階で統合が完了し 真の単一ソース が 単一の構造化も分割もされていないブロック である場合だけです データベースが構造化され 独立して管理できる仮想単位が確立されると 管理性の矛盾は解消します これが目標であれば 仮想構造が以前と同じ物理構造であるか 完全に異なる構造であるかは問題になりません データベースの構造化は データベースの爆発的な肥大 管理性の矛盾 管理者の悪夢といったデータベースのあらゆる問題を解決する源になります ここでいうデータベースの構造化とは 物理的なデータベース部分の作成を意味しているわけではありません シェアード ナッシング アーキテクチャではなく 仮想構造の実装です これは 分割されずに残ったデータベース内の複数の仮想構造の組合せであってもかまいません データベースの構造化は テクノロジーや機能ではなく概念です そして Oracle Databaseが提供するいくつかのテクノロジーや機能の基礎でもあります 中でも表や索引のパーティション化は 最も代表的なひとつでしょう この機能を使用して大規模データベースを扱うときに役立つオラクル テクノロジーを最初に説明する理由は ここにあります 図 1 データベースの進化 統合されていないローカル データベース 構造化されていない統合データベース 統合プロジェクトの結果として 非常に巨大になったデータベースの場合は 危険な点が特に明確です ( 図 1 参 3. 構造化された統合データベース

13 SAP 顧客向けの Oracle 索引圧縮 13 表と索引のパーティション化 パーティション化 - 仕組みパーティション化の基本的な考え方は 非常に単純です 1つ ( または複数 ) の列のある値に基づいた1つの 表 の行をグループとし 各グループを 副表 として格納します この定義には 3つの注釈が必要です 前述の説明でわざわざ表をかぎ括弧で囲いましたが これは Oracleが表のパーティション化の他に 索引のパーティション化もサポートしているためです このため データベース設計者は行または索引 ( リーフ ) ブロック内のエンティティを 1 つの表にグループ化し 結果を パーティション と呼ばれる仮想サブセットとして格納できます 言うまでもなく 必要なときに表または索引は 1 つのオブジェクトとしてアクセスできます アプリケーションのニーズに応じて 表の索引をパーティション化する ( ローカル索引 ) ことも パーティション化しないままに保つ ( グローバル索引 ) こともできます 通常のSAPシステムでは表に複数の索引が存在する場合がありますが これらの一部をローカルとし 一部をグローバルにすることができます 1つまたは複数の列内の 値に基づいて 行をグループ化することは 非常に一般的なパーティション化方法です オラクルは この作業を正確に行うための戦略を多数提供します SAP 環境で最も重要な戦略は リスト パーティション化とレンジ パーティション化です リスト パーティション化を実装するためには 各値 ( たとえば 国 地域 ) を明示的に示す値リストを作成する必要があります レンジ パーティション化を実装するためには 開始と終了 ( たとえば January 1-31 February 1-28など ) を指定して範囲を定義する必要があります Oracle Partitioningの利点パーティション化は ユーザーと管理者の両方に利点があります ユーザーにとっての主な利点は パフォーマンスの向上です ( ユーザーが快適であるため 管理者にとっても利点となります ) このパフォーマンス向上の技術的な根拠は パーティション プルーニング と呼ばれます たとえば 月でパーティション化された表と この表に基づいた月別レポートを生成するアプリケーションがあるとします リクエストを受信すると Oracle Databaseは考慮対象のすべてのパーティションの中から必要なデータが単一パーティション内にあることを認識し このパーティションのみをスキャンします これにより I/O メモリー使用率およびCPUのワークロードが大幅に減少し 顧客のパフォーマンスは 5 倍 10 倍 あるいはそれ以上向上します 週別レポートを生成する必要がある場合でも 表パーティションとローカル ( つまりパーティション化された ) 索引の組合せにより 同様の結果が得られます これは スキャンする必要のある索引パーティションは パーティション化されていない索引より はるかに小さいからです 管理者にとってパーティション化は パーティションを独立して個別に管理できるという大きな利点があります 表が 90% の履歴データと 10% のアクティブ データで構成され その履歴データとアクティブ データがパーティション化で分離されている場合 毎日のバックアップや再編成などの管理手順をアクティブ データのパーティションに限定して実行できます これにより 不要なワークロードだけではなく これらの作業時間も減らすことができます さらに パーティションは個別に またオンラインで作成 削除またはマージできます そのため メンテナンスの停止時間は増加しません 企業全体にとっての大きな利点は コストを削減できることです アクティブ データと履歴データが分離されていれば アクセス回数がすくない履歴データをより低速なディスク つまり安価なディスクに移動できます さらに 圧縮などのテクノロジーを追加で利用し 必要なディスク領域の量を一層削減することができます ( 図 2 参照 ) この時 圧縮を選択的に使用して最適な結果を得ることができます たとえば 履歴パーティションを圧縮して ディスク領域を節約する一方で アクティブ パーティションは圧縮せずに CPUのオーバーヘッドを回避します

14 14 図 2 - データベースの領域管理 手順 1 : 非構造化単位としてのオブジェクト 手順 2 : データの分析 手順 3 : レンジ パーティション化の実装 手順 4 : 異なる種類のディスクの使用 SAP 製品向けのOracle Partitioning SAPはすでに何年も前から 特に表と索引をパーティション化するとパフォーマンスが向上する利点に気が付いていました このため SAPはOracle PartitioningをSAP ERPのような OLTPシステムの他に SAP BIシステムでもサポートしています 手順 5 : 履歴パーティションの圧縮 しかし これらには違いがあります SAP BIの場合 Oracle Partitioningはサポートされているだけでなく 実装もされています これは どの表をどういう方法でパーティション化するかという疑問にSAPが答えを出していることを意味します このパーティション機能は インストール

15 SAP 顧客向けの Oracle 索引圧縮 15 と設定プロセス中に実装され SAPが提供するパーティション管理ツールで利用できます パーティション化する表と方法が決まっているため すべての SAP BIシステムで同じように実行できます これに対して SAP ERPの場合はサポートのみで SAPが提供するデフォルトの実装はありません この理由は明白ですが ERPの場合 パーティション化する表や方法が顧客やシステムによって異なるからです しかし SAP ERPでは データベースのサイズが そして 30TB( さらにそれ以上 ) になっており データの 90% が多くの巨大な表に格納されています このため SAP ERPデータベースでは緊急にソリューションが必要です 過去 2 年間に開発されたソリューションは 2つの部分で構成されています 1つは オラクルが提供するパーティショニングで もう 1つはSAPが提供する管理インタフェースです オラクルが提供するSAP ERP 向けのパーティション化 SAP ERPシステムの一部であるデータベースに Oracle Partitioningを実装するには 次の 2つの質問に答える必要があります パーティション化によって最も恩恵を受ける表 ( および索引 ) はどれでしょうか さらに これらの表や索引をどのようにパーティション化すればよいでしょうか 最初の質問は 比較的簡単です 一般的に 最も大きい表とこれらの表に定義されている索引が最も大きい恩恵を受けます 従って 必要となるのは簡単な表サイズの分析のみです さらに 過去の実装プロジェクトの経験から 何万もの表を考慮する必要はなく限定的な候補のセット (30~40 個の表 ) で十分であることがわかっています Oracle PartitioningをSAP ERPシステムに実装するときの問題は 適切なパーティション キーを見つけることです ほぼすべてのレンジ パーティション化では 範囲定義に使用可能な時間ベースの列が存在する必要があります ( 詳細は オラクル ホワイト ペーパー Partitioning for SAP R/3. A Guide for Planning and Setup of Oracle Partitioning in SAP R/3 Systems( 日本語版の提供は2009 年末予定 ) を参照してください ) パーティション化対象のいくつかの表にはこの列が含まれていますが ほとんどの表には含まれていません そのために 利用できる他の時間関連の情報を探す必要があります 幸いにも このような種類の情報は存在します 法的要件に準拠するために いくつかの種類のドキュメントには 必ず昇順の番号を途切れずに付けることが義務付けられています SAPではNRIVと呼ばれる特別な表を使用します この表が 使用可能な番号を管理し ソリューションのキーになります パーティション化対象のすべての表にはタイム スタンプ列がなくても 資料 注文書 またはドキュメントのいずれかに対応する番号がかならずあります これは NRIVベースの番号ジェネレータによって提供されています この番号はn+1という形式で 番号 nの後に生成されるため 間接的な時間情報としてパーティション化に使用できます これが手順 1です もちろん この時間情報とタイム スタンプとでは違いがあります NRIVベースの番号ジェネレータは 連続的で構造化されていない番号のストリームを生成しますが 実時間のタイム スタンプには年や月など 事前定義された副単位が付けられます 事前定義された副単位は パーティション化の条件 ( 年 月などで表をパーティション化する ) として使用できるため この違いは重要です 手順 2の作業で NRIVを利用してパーティション化する表を分析する必要があります たとえば 表を月でパーティション化するとします この表に対して毎月平均 100,000 個のNRIV ベースの異なる番号が生成される場合 単純に 各パーティションを 100,000 個のレコードに対するパーティション スキーマとして実装します これで この表は 月 でパーティション化されます SAPパーティショニング エンジンここまでの話を難しいと思いますか? 難しい話ではありますが 複雑な分析とメンテナンスの作業を自動化できるという利点があります オラクルはプロジェクトの初期フェーズで Oracle Database 独自のテクノロジー ( 主にPL/ SQLプロシージャ ) に基づいたツールのセットを開発しました このツールは いくつかの顧客で問題なく動作しました これはコンサルティングベースのソリューションで 非標準のSAP 要件には役立ちましたが 標準環境には必要ありませんでした より多くの顧客が前述の革新的な方法を利用できるように SAPはオラクルが提供する概念を基に独自のソリューションを開発しました

16 16 この SAPのソリューションは SAPパーティショニング エンジンという名前で SAPシステムに完全に統合されています 次の 3つの主要な部分があります まず第一番目はトランザクションです このトランザクションはパーティション化されていない表をパーティション化された表に変換するために使用されます このトランザクションは組込み機能であり 既知のSAP 表のリストとこれらの表のパーティションキー 及びパーティション サイズの自動調整が含まれています このリストは SAP 標準テーブルの大部分と サイズが大きくなる傾向のある一部の表を網羅しています また このトランザクションでは特別な目的のためにユーザーの要件に合せパーティション化のプロパティを調整できる高度な拡張機能が用意されています この最初のステップでは まず 事前定義されたルールのセットに基づいて表が分析され その後この表の適切なパーティション レイアウトや正しい索引定義を作成するための DDL 文が生成されます 最終的に表を変換するためには brspace ユーティリティを使用できます 新しいコマンドライン オプションを使用することで brspaceはこの DDL 文をデータベースからフェッチし これによりオンライン再編成を実行することで 既存の表をパーティション化された表に変換します また brspaceは 新しくパーティション化された表の正しい統計を管理します 表のパーティション化後 新規作成された行に対応するために 必要に応じて新しいパーティションを作成する必要があります これはソリューションの 2 番目の部分で 自動化されています この SAPトランザクションは 表内の現在のデータ量と 表のパーティション化の現在のステータスを比較します 必要に応じて 新しい表データを格納するために オンラインで空のパーティションが新規作成されます この操作は 非常に高速で任意の時点で実行できます また実行中の SAPシステムに影響を与えることはありません このトランザクションは SAPの実行中でも実行できます SAPパーティショニング エンジンを使用することで Oracleのプログラミング知識がないSAP 顧客でも Oracle Partitioningテクノロジーを活用できます また パーティション化できる表が事前定義されているため 経験の少ない Oracleユーザーも この革新的なアプローチの恩恵を受けることができます 表および索引の圧縮ストレージの効率性爆発的に肥大化するデータベースをどのように管理するかという質問に 一部のデータベース ベンダーは即座に圧縮テクノロジーを説明するでしょう 圧縮を最初の考慮事項にしてはならない理由と最初に構造化データベースの実装が必要なことについては すでに説明しましたが これを完全に考慮し ディスク容量の最も効率的な使用に役立つ新しいテクノロジーに興味があっても 圧縮技術や圧縮率などのトピックには飛びつかないことです そのかわりに ストレージの効率性という総合的な見方をしてください 圧縮 は必ず管理者の介入が必要であるというのが 圧縮技術に対する現在の認識です 管理者は 圧縮するかどうかを決定します 圧縮が必要な場合は 圧縮に使用するオブジェクトを決定し実装する必要があります この定義を受け入れた場合 ストレージの効率性と圧縮では実際に大きな違いがあります それはデータベース システムが 暗黙的な圧縮 と呼ばれたテクノロジーを提供できるかという違いです 暗黙的な圧縮 は データの格納に最小限のディスク容量を使用することを確実にするテクノロジーです このテクノロジーはデフォルトでオンになっているため 自動で実行されています 表がアーカイブ化されると 最も古いパーティションに格納された行の数が減ります SAPパーティショニング エンジンのトランザクションでは これらのパーティションの中の使用されない領域が解放されます 領域解放は 最も古いパーティションに対してマージ操作を実行します その結果 残りの行を含む小さな1 つのパーティションと表領域で大量の空き領域ができます 新しいパーティションは この空き領域を使用して作成されます

17 SAP 顧客向けの Oracle 索引圧縮 17 この違いを簡単な例で明確にしましょう D1( ベンダー X が提供するソフトウェアをベースとする ) とD2( ベンダー Y が提供するソフトウェアをベースとする ) という 2つのデータベースに まったく同一のデータをロードしたとします 暗黙的な圧縮 機能の違いにより このデータを格納するために D1では1,000GBのディスク容量が必要で D2では1,500GBのディスク容量が必要です 必要なディスク容量を低減するために 最初のロード後に圧縮が使用され D1は2.5 倍 (60%) 圧縮でき D2は3 倍 (67%) 圧縮できるとします この場合 D1では最終的なサイズは 400GBになり D2では最終的なサイズは 500GBになります これは 次のことを意味します 圧縮率はD2の方が高いのですが 全体的なストレージの効率性はD1の方が優れています 現実的な予想に立った設定 Oracle( または他のデータベース ) が提供する圧縮技術を詳細に検討する前に 考慮すべき2 番目のトピックがあります 圧縮 について書かれた多くの記事がありますが その中にはデータの圧縮で実現できることを過大評価しているものがあります ほんの少し実状に目を向けることは 現実的な予想に立った設定をするために大切な事です まず 圧縮はデータベース レベルではなく オブジェクト レベル ( 個別の表や索引など ) に対してアクティブ化されるということに気付くことが重要です オブジェクトを圧縮することで ディスク容量を Xパーセント節約できる と言われたら オブジェクト レベルか データベース レベルか問い返すことが必要です Oracle 10gには 最も包括的な 暗黙的な圧縮 機能のセットが組み込まれ 新しいバージョンごとに新機能が追加されています 最も重要な機能を次に示します 数値の可変長表示 ( 固定長のかわり ) 可変長文字列の最も効率的な表示 可変長 Unicodeの表示 (UTF-16のかわりに UTF-8) 高圧縮されたビットマップ索引結果として Oracleでは他のデータベースと比較して 例で使用した同一のデータの格納に ( 暗黙的な ) 圧縮を使用しなくても最大で40% 少ないディスク容量で済みます しかしそれだけでは 急速に肥大するOracle Database の管理者には役に立ちません そして その状態は刻々と悪化している可能性があります 次に 多くの本番の圧縮テストでは データベースの単純なコピーが使用されます しかし 誰もが知っていますが データベースはライフ タイムの間に 削除などの操作でディスクが断片化し徐々に効率が悪くなります ディスク容量は 単純なデータベースの再編成により 20~30% を節約できます これらは データベース全体 を圧縮することで 40~50% のディスク容量を節約できると言われたときのために留意しておいてください 3 番目に データベース全体を圧縮したいと思う管理者はいません この作業は 数万もの表を圧縮するために手間がかかるだけではなく すべての表や索引は非常に小さく効率的に圧縮できないため 無駄な努力に終わります 大部分の顧客は 大きい表を 10 個 20 個 50 個 または100 個と選択し その表に定義されている索引も一緒に圧縮します 最後になりましたが一番大事なことです データベース は大量の異なるデータです したがって データベースそのもの を圧縮する方法はありません 広い意味で データベースは索引データと表データから構成され 表データは順番に構造化データ ( 数値 文字列 ) と非構造化データ (LONG LOB) に分けられます 現在 圧縮が利用可能なすべてのデータベースにおいて これら 3 種類のデータに対する個別の圧縮アルゴリズムがあり その各圧縮アルゴリズムからは異なる圧縮結果が得られます 大まかな見積りですが SAP ERP システムの一部であ

18 18 るOracle Databaseでは 割り当てられたディスク領域の 33% を索引データ 55% を構造化データ 12% を非構造化表データがそれぞれ使用します この例は極端ですが すべてのオブジェクトを圧縮し オブジェクト レベルの圧縮率が平均 70% であるとした場合 データベース レベルでは 最大で索引データの圧縮で23% 構造化表データの圧縮で39% 非構造化表データの圧縮で8% 節約できます また より現実的な例では最大のオブジェクト ( または割り当てられたディスク領域の80%) を圧縮し 平均圧縮率が60% だとした場合 現実的な目標は索引データで15% 構造化データで 25% 非構造化表データで 5% になります 索引キーの圧縮 Oracleの索引キー圧縮を使用すると B*Tree 索引 ( ビットマップ索引は不可 ) のリーフ ブロック内の繰返し値を より短いトークンに置き換えられます 索引が元表の1つの単一列に定義されていれば 繰返し値 が意味するものは明確であるため 圧縮された索引の作成は簡単です しかし 複数の列に索引が定義されている場合はやや複雑になります たとえば 表 T の5つの列 (C1 C2 C3 C4 C5) に索引が定義されているとします 繰返し値は C1のみ C1+C2 C1+C2+C3 C1+C2+C3+C4 または C1+C2+C3+C4+C5で検索することができます ディスク容量の達成可能な節約率は これら 5つの選択肢で異なることは明らかです さらに悪いことに より多くの列を対象にしてもより多くのディスク容量を節約できるという保証はありません これまでの経験から 最適な状態は中間位であることが多いようです ( 図 3 参照 よりわかりやすくするためにすべての値の長さを同じにしました ) これは 次のことを意味します 圧縮に適した索引を見つける必要があるのは データベース管理者だけではありません SAP 環境では ごく一般的に複数の列に索引が定義されています この場合は 列の値を繰返し値の検索に使用する先頭部分 ( 接頭辞 ) と圧縮しない残りの部分 ( 接尾辞 ) に分ける方法を決める必要があります オラクルはこの作業のために 最もディスク容量を節約するように接頭辞 / 接尾辞の比率を計算するツール (IND_ COMP) を提供しています は 簡単で効率的なだけでなく Oracle Database 10g から Oracle Database 11gにアップグレードする際に アルゴリズムや内部ストレージ構造の大きな変更が必要ありません そのため それまで行った作業が無駄になりません データ圧縮表の列内の構造化データ ( 数値 文字列 ) を圧縮する場合 3つの手順が必要になります 圧縮の候補となる値 - 繰返し値を見つける これらの候補値のリストを作成し それぞれに番号を付ける ( シンボル表の作成 ) 繰返し値の各出現を適切な数値に置き換える 数値は元の値よりはるかに短いため このアプローチで 70% 近いディスク容量を節約できます これは一般的アプローチで 標準と言っても良いかもしれません Oracle 実装で固有なのは 単一ブロックごとにシンボル表が作成され格納されることです より正確に表現すると 表 ( セグメント ) ごとのシンボル表は 1 つのみではありません 異なる小さな多数のシンボル表がそれぞれ単一ブロック内のデータから作成され 特定のブロックに格納されます Oracleはグローバルなシンボル表を使用せず多数のローカルなシンボル表を使用します つまり 分割統治です ( 図 4を参照 ) このアプローチは グローバルなシンボル表によるアプローチより 優れた点があります 個々のシンボル表は 少数のエントリで構成されています したがって 圧縮されていない値のポインタとして使用される数値が非常に少なくなります さらに 圧縮できる値の全体数を制限する必要もありません SAP 環境でOracle Databaseを圧縮する場合 最初に使用する機能として索引キー圧縮をお薦めします これ

19 SAP 顧客向けの Oracle 索引圧縮 19 図 3 - Oracle 索引キー圧縮 手順 1 : 圧縮されていない索引 手順 2 : 圧縮された索引 ( 接頭辞 = 1) 手順 3 : 圧縮された索引 ( 接頭辞 = 2) 手順 4 : 圧縮された索引 ( 接頭辞 = 3) 手順 5 : 圧縮された索引 ( 接頭辞 = 4) 手順 6 : 圧縮された索引 ( 接頭辞 = 5)

20 20 ユーザーがレコードを読み取る場合は 圧縮済みの値を解凍する必要があります ( ポインタは元の値に置き換えられます ) Oracle Databaseの実装では この操作に必要なすべてのデータは 1つの単一ブロックに配置されます 他社のように グローバルなシンボル表を使用した場合 ブロックは少なくとも 2つ必要になります したがって Oracle Databaseのアプローチでは少ない I/Oで済み パフォーマンスが向上します グローバルなシンボル表は静的です いったん作成すると変更されません ただし 表に挿入される値は変更されます たとえば シンボル表が3 月末に作成されたとします この場合 シンボル表内の January February および March は圧縮できます しかし April と May は圧縮できません つまり 時間の経過に伴い圧縮率が低下します ただし データベース管理者がシンボル表を再作成した場合は このかぎりではありません しかし ここでも Oracle Databaseの方が有利であることは明白です 個別のブロックごとにローカルな圧縮ディクショナリが作成されるため Oracleは4 月に作成されたすべてのブロックに値 April を含めます 管理者の介入は不要です したがって Oracleはより柔軟で管理作業が少ないアプローチを選択しているといえます 多数のローカルなシンボル表の欠点は より多くのディスク容量が必要になることです しかし 変更された値を自動で適用するOracleのデータ圧縮アルゴリズムの機能は この欠点を補って余りあることを顧客の経験が物語っています Oracle Database 10gのデータ圧縮は DSSシステムの履歴データ用に設計されました したがって データ圧縮はバッチ ロードに役立ちますが シングル レコードの挿入や更新には使用できません その結果 Oracle Database 10gのデータ圧縮はSAP BIシステムのみで SAP ERPなどの OLTPシステムでは使用できませんでした このため Oracle Database 11gでは 完全に新しいアルゴリズムが採用されました ユーザーが挿入した圧縮されていない形式のデータは 非同期に バックグラウンド プロセスで圧縮されます これらのプロセスでは データの挿入が単一行でもバッチ ロードでも区別されません また Oracle Database 11gは 非構造化データの圧縮もサポートしています しかし これらの新機能は このドキュメントの最初のセクションで説明した一般的なデータ管理に対するルールを無視するものではありません Oracle Database 11gにアップグレードすると あらゆる種類のシステムのすべての表を圧縮できますが これだけでは名案でもベスト プラクティスでもありません なぜなら Oracle Database 11g の能力は 組織化されていない 巨大なデータを大量に処理するためにあるのではなく 賢明な領域管理やデータ管理の戦略の確立のためにあるからです バックアップとリカバリデータベース保護の主要な要件 VLDBのバックアップとリカバリで対応する必要のある大きな問題を次に示します 納得できる時間枠内でバックアップ / リカバリする方法 アプリケーションまたはビジネス オブジェクト レベルでリカバリする方法 無停止環境でデータを保護する方法 データの保護 / 障害リカバリにかかるソフトウェア インフラストラクチャ および運用のコストを管理する方法バックアップとリカバリは データベースに特有のトピックではありません 最適で全体を包括するソリューションには 適切なデータベース ストレージとバックアップ メディアの選択も不可欠ですが 最も効率的な Oracle Databaseのバックアップ機能とリカバリ機能を選択することも重要です Oracle Recovery Manager Recovery Manager(RMAN) は Oracle Databaseクライアントで バックアップとリカバリのタスクを実行し バックアップ戦略の管理を自動化します これにより データベース ファイルのバックアップ リストアおよびリカバリが簡素化されます RMANは データを損失から保護するためにバックアップまたはリストアの前後に 基本構成のすべてのデータベース プロシージャを処理します RMAN は 異なるホスト上のオペレーティング システムにまたがるバックアップ タスクの共通インタフェースを提供し バックアップ / リカバリのデータ ストリームのパラレル化 バックアップ ファイルの保存方針 およびすべてのバックアップの詳細な履歴など ユーザー管理メソッドでは得られない機能を提供します

21 SAP 顧客向けの Oracle 索引圧縮 21 図 4 - 構造化された表データの圧縮 シンボル表 データ ブロック データ ブロック データ ブロック 実装オプション 1: データ セグメント ( 表 ) ごとに 1 つのグローバルなシンボル表が専用ブロックに格納される シンボル表 データ ブロック データ ブロック データ ブロック 実装オプション 2: それぞれ単一ブロックから作成された多数のローカルなシンボル表が その特定ブロックに格納される

22 22 RMANは SAPが提供するBRBACKUP BRARCHIVE BRRESTOREおよび BRRECOVERなどのデータベース管理ツールと統合されています BR*Toolsのバージョンとパッチ レベルによっては 新しい RMAN 機能を統合して セキュリティ 柔軟性および安全性を改善できます Oracle Recovery Managerは Oracle Database 専用に設計されているため RDBMSと統合できます したがって RMANは他のリストア / リカバリ管理ツールに優る 次のような利点があります 物理的および論理的なデータベース破損の検出 : 他のバックアップ ツールと比較して RMANを使用しているユーザーが経験できる利点は バックアップ中のデータファイル破損のチェックです データベース ブロックの論理的および物理的エラーは 自動的に認識されます 増分バックアップ : RMANによるデータファイルのバックアップは 全体バックアップまたは増分バックアップのいずれかです [ 全体バックアップ ] は ファイル内の使用されたすべてのブロックを対象にします 全データファイルのバックアップがイメージ コピーとして作成された場合 ファイル コンテンツ全体がそのまま再現されます [ 増分バックアップ ] は 特定の時点以降に変更されたブロックのイメージがキャプチャされます この特定の時点とは 通常は前回 全体バックアップまたは増分バックアップが行われた時点です ブロック チェンジ トラッキングを使用した高速増分バックアップ : 増分バックアップは Oracle 8からサポートされています 他の増分ソリューションと同様に キーポイントは 何が変更されたか を見つける方法です 以前のバージョンでは 変更されたブロックの判別にすべてのデータファイルをチェックする必要がありましたが Oracle Database 10g 以降 ブロック チェンジ トラッキングが使用されています 増分バックアップで使用するRMANのブロック チェンジ トラッキング機能は ブロック チェンジ トラッキング ファイル (BCTF) に記録された変更済みのブロックを利用します このファイルは非常に小さく ( ブロック アドレスのビットマップ表現のみ ) ファイルサイズはデータベースのサイズと有効化されている REDOスレッドの数に比例します チェンジ トラッキングが有効な場合 RMANはBCTFを使用して増分バックアップが必要な変更済みのブロックを識別します データファイル内のすべてのブロックをスキャンする必要はありません バックアップ サイズの軽減 :1 度も変更されたことがない未フォーマットのデータベース ブロックは RMANが作成するバックアップには含まれません これにより 純粋なデータファイル コピーより バックアップ ファイルのサイズが小さくなります この形式の圧縮は 未使用ブロックの圧縮と呼ばれます REDOログ情報の軽減 :RMANを使用してオンライン バックアップを実行しているときは BEGIN/END BACKUPコマンドは必要ありません RMANは他のすべてのOracleシャドウ プロセスのように データファイルからデータ ブロックを読み取るため データ ブロックのコピーを REDOログ バッファに置く必要がありません アーカイブ ログとバックアップの圧縮 :RMANは バイナリ圧縮形式でバックアップ セットを書き込むため バックアップ セットのサイズが小さくなります 圧縮されたバックアップ セットを使用することで ストレージ領域が節約できるだけではなく ネットワークを介したバックアップのネットワーク帯域幅も節約できます (SAP Notes および を参照 ) バックアップの検証 : データベースのバックアップを続けるうちに 時にはバックアップ自体もエラーとは無縁ではないことに驚かされるのではないでしょうか ( ネットワーク テープ デバイス バックアップ ソフトウェアのバグなど ) バックアップの有効性を確保しバックアップをリストアとして使用できるようにするには 時々バックアップを検証する必要があります RMANでは BACKUP VALIDATEコマンドを使用して バックアップの検証チェックを実行できます Oracleフラッシュバック テクノロジー多くの調査によれば アプリケーションの機能停止の40% は オペレータまたはユーザーのエラーが原因です 人間は 間違いを犯します しかし このエラーの回避は非常に難しく事前の計画や正しいテクノロジーを使用しなかった場合 リカバリが困難です このエラーは 論理的な データの破損や ITインフラストラクチャの1つ以上のコンポーネントが機能停止する原因になります 個別のコンポーネントの故障を修正することは比較的簡単ですが 重要なデータを間違って削除するなど 論理的なデータの破損の検出や修正作業は時間がかかり 業務の生産性に大きな損失を与えます 重要なデータを間違って削除した 違うデータや表を削除したといったことが ユーザーによる一番多いエラーです

23 SAP 顧客向けの Oracle 索引圧縮 23 フラッシュバック データベースは 過去のある時点まで Oracle Databaseを迅速に戻し 論理的なデータの破損やユーザー エラーが原因の問題を修正します フラッシュバック データベースは データベースの 巻戻しボタン と言えるでしょう これは ユーザーがデータベースのバックアップをリストアしていなくても データベースのポイント イン タイム リカバリを提供します データベース バックアップをテープからリストアする必要がないため データベースのポイント イン タイム リカバリが高速におこなえます フラッシュバック データベース機能は RMANと SQL*Plusの両方から FLASHBACK DATABASEコマンドを使用してアクセスできますが その効果は標準的なポイント イン タイム リカバリと同じです この機能を使用することで データベースを過去の最新の時点の状態に戻します フラッシュバック データベース機能を有効にすると 次のようなメリットがあります バックアップのリストアに必要な時間を削減できます 壊滅的な問題でデータベースが停止すると 企業の業務も停止し何百万ドルもの損失が発生します スタンバイ データベースの REDO Apply 遅延を削減します フラッシュバック データベースは Data Guardとシームレスに統合されています スタンバイ データベースは 即座に任意の時点まで簡単にフラッシュバックができるため REDO Applyによる遅延は発生しません 詳細は SAP Notes および を参照してください Oracle Data Guard Oracle Data Guardは 複数のスタンバイ データベースの作成 メンテナンス 監視ができます 企業のデータを故障 災害 エラー 破損などから保護します スタンバイ データベースは 本番データベースの同期化されたコピーとして保存されます スタンバイ データベースは 本番データ センターの場所とは別の障害時リカバリ サイトに配置することができます また同じ都市 キャンパスまたはビルに配置することもできます 計画停止または計画外停止によって本番データベースが利用できなくなると Data Guardはスタンバイ データベースを本番ロールに切り替え 機能停止に伴うダウンタイムを最小限に押さえ あらゆるデータ損失を防止します Data Guard for SAPが活躍する代表的な2つのクリティカルな例を示します プライマリ データベースがクラッシュ SAPアプリケーション インスタンスなど他のコンポーネントはすべて問題がない この場合は 簡単に SAPアプリケーション サーバーをオープンなスタンバイ データベースとの接続に切り替えることができます また 保護モードによっては データ変更の適用を待つ必要がありません SAPインスタンスのフェイルオーバーは 事前に準備された指定のSAPプロファイルを使用して円滑に行われます また データベース サーバーの仮想 IPアドレスを使用すると さらに迅速に行うことができます データベースと SAPアプリケーションがオフライン データ センター全体が停止 スタンバイ データベースを同期していない場合は同期化を完了させます スタンバイ データベースを含め事前に準備された SAPシステムを起動します スタンバイ データベースは フラッシュバック データベースの機能を用いることで 一旦読取り / 書込みデータベースとしてテスト トレーニング またはレポート作業に使用したデータベースを巻き戻すことが可能です テスト等の作業が完了した後 データベースを元の状態に巻き戻し 作業前のように潜在的な障害に対するリカバリ サイトとして使用することができます RMANやフラッシュバック データベースと同様に Oracleのスタンバイ データベース機能は SAPが提供する管理ツールと統合できます オフライン REDOログ ファイルをプライマリ インスタンスからスタンバイ インスタンスに転送する場合に SAP ツールの BRARCHIVEを使用するというシナリオも考えられます プライマリ データベース ( 本番データベース システム ) のバックアップが必要ないということが スタンバイ データベースの一番の利点です そのかわりに スタンバイ データベースを使用してスタンバイ データベースのデータファイルをバックアップします データベース バックアップは どのような場合でもプライマリ データベース インスタンスのホストの負荷を増加させません スタンバイ データベースでは本番の操作をしないため すべてのホスト リソースをデータベース バックアップに使用できます SAPツールの BRBACKUP は スタンバイ データベースでデータをバックアップするときに役立ちます

24 24 Oracle RAC により 私たちの要件はすべて実装できました Oracle のおかげで 非常に快適かつ安全な環境に なりました ROSS BARRATT 氏 NSWFBのビジネス インテリジェンス マネージャ ORACLE 10g REAL APPLICATION CLUSTERS (RAC) FOR SAP: ニュー サウス ウェールズ消防隊にとって不可欠で信頼できる基盤 高い安定性 パフォーマンスを向上させ SAP の TCO を最小限に抑える ニュー サウス ウェールズ消防隊 オラクル社の製品およびサービス : Oracle RAC EE Oracle Database 10g Oracle Clusterware(OCFS/ 共有 Oracleホーム ) Oracle Data Guard Oracle RMAN Oracleサポート ニュー サウス ウェールズ消防隊 (NSWFB) は 約 3,900 人のフルタイムの消防士 3,300 人のパートタイムの消防士 5,500 人のボランティア メンバーからなるオーストラリアで最大の消防隊で Oracle Real Application Clusters(RAC) でSAPを使用しています Oracleのデータベース クラスタ テクノロジーは NSWFBにはいくつかの大きなメリットをもたらしました ニュー サウス ウェールズ州は オーストラリアの南東沿岸にあり 全面積は800,640 平方キロメートルになります これは 英国の3 倍の広さです ニュー サウス ウェールズは オーストラリアの経済にとって最も重要な州です 沿岸の都市シドニーは この地域の重要な産業の中心の1つで 州内に340 箇所の消防署を展開するニュー サウス ウェールズ消防隊の統括管理オフィスがあります NSWFBに所属する数千人のフルタイムとパートタイムの消防士は 火災 レスキュー 危険物による緊急事態などの事件に対応し 他の政府機関と連携して 低木地帯の火災 洪水 地震またはテロリストによる攻撃などの事件にも対応します 2009 年の初めから 2010 年の終わりまでに 新しい ITシステムとソリューションが徐々に実用化されます すでに IT の近代化は大きく進歩を遂げています 私たちの IT 環境とインフラストラクチャの一部は 1990 年代からのもので もはやその当時とは異なる今日の要件を満たしていません 一部の分野では すでに新しい ITソリューションを活用しています と NSWFBのビジネス インテリジェンス マネージャの Ross Barratt 氏は述べています いくつかの重要なマイルストーンは すでに管理業務で実現され これらは組織の運営支援部門が提供しています これには SAP ERPアプリケーション システムの実装が含まれ Financials(FI) Human Capital Management(HR) および SAP Netweaver Business WarehouseとOracle Databaseまたは Oracle RACが使用されています ニュー サウス ウェールズ消防隊の IT 戦略は OracleをEnterprise Content Managementシステムとして使用することを計画しています 1 日 24 時間活動するニュー サウス ウェールズ州の機関 NSWFBの組織にとって 情報テクノロジーを含めたテクノロジーが重要な役割を果たします このテクノロジーは 救命作業を行うために緊急時のコミュニケーションと情報共有に利用されるだけではなく 700 台近い消防車のメンテナンスと管理 人員の配置 財務および人的資源などの管理にも利用されます 活動内容の基礎 ニュー サウス ウェールズ消防隊では 2008 年以来 将来を見据えた新しい ITの方向性を取り入れています

25 ニュー サウス ウェールズ消防隊の Oracle 10g RAC for SAP 25 円滑なRACの実装 SAPを使用する場合 データベースの重要な役割を無視することはできません 1 日の業務の終わりに データベースはあらゆる SAPシステムの重要な構成要素であることがわかります と Barratt 氏は強調します 概念の計画段階に考慮した主要な問題は SAPとともに使用するデータベースの安定性 安全性 コスト効率性でした これらが Oracle RACを選択した主な理由です Oracle Databaseのクラスタ テクノロジーで達成されたことを鑑みると NSWFBの決定は的を得たものであったと言って間違いありません Oracle RACにより 私たちの要件はすべて実装できました NSWFBがOracle RACと併せて最初に使用したアプリケーションは SAP ソリューションの Finance(FI) とNetweaver Business Warehouse(BI) でした Oracle RAC( EE) は EMC Clariionストレージ システムと Novell 社製のオペレーティング システム Suse Linux Enterprise Server(SLES10) とともに Dell R900サーバー (4 個のコア CPUを持つ双方向サーバー ) の3ノード クラスタに実装されました Barrett 氏は Oracle RACの導入は非常に円滑に進行し 6 週間しかかかりませんでした と説明しています 付加価値 - もし や しかし の排除 Oracle Real Application Clusterを使用することは 1 つのパッケージで複数のメリットがあり 現実的な付加価値をもたらします また Barratt 氏はOracle RACの導入により SAP ITインフラストラクチャのコストも最小限に抑えられ 結果的に所有コスト (TCO) の総額も削減できたという事実もメリットとして挙げています 私たちのインフラストラクチャのコストは 他のアプローチと比較して非常に低いものです たとえば システム全体を拡張したい場合でも サーバーを交換する必要はありません RAC 環境を使用して 柔軟かつ安全に環境を拡張できます と Barrat 氏は述べています この点でも NSWFBはOracle RACでエンタープライズ グリッドを設定し使用するという選択でメリットを得ています NSWFBでは グリッド コンピューティングと呼ばれるシステムを複合ワークロードとして設定しました SAP BI などのデータベースが同一クラスタ内で稼動しています RACを使用し続けるプランを確定 Oracle RACを使用することで NSWFBは現在および将来の課題に取り組む準備が十分整っています そして こうして達成できたことを Oracle RACを導入したことで 安定を得られた と表現しています IT 戦略によれば 将来のNSWFBのデータベース プラットフォームは Oracle Real Application Clustersが適しています これは 常に非常に高い安定性と最適なシステム パフォーマンスを確保することに重点が置かれています Oracle RACの導入は非常に円滑に進行し 6 週間しかかかりませんでした Ross Barratt 氏 NSWFBのビジネス インテリジェンス マネージャ まず スタッフは SAPを使用するシステムが非常に安定していることに満足しました 何らかの理由でデータベース クラスタ内のノードが故障すると そのノードのジョブはシステムを中断することなく 別のノードに引き継がれます NSWFBはOracle RACに加えて 障害およびリカバリ管理のために Oracle Data Guardも使用しています これにより プライマリ システム環境に障害が発生した場合などに 保存されているデータを効率的にバックアップできます リカバリ管理は Oracleソリューションの RMANを使用しています また Barratt 氏は次の点にも満足しています Oracle RACは 私たちの給与支払いプロセスを高速化することにも役立ちました 給与支払いの作業には時間がかかりますが 今では数分で終わります

26 26 我々は Oracle RAC を SAP と組み合せて使うことを決定しました SAP ERP アップグレードと新しい IT インフラスト ラクチャは 計画を実現するために必要な機会を提供してくれます Oracle RAC を使用することで私たちは より柔 軟になりました コストを削減し パフォーマンスを向上させ SAP の高可用性を最適化できました FAUSTO CAPELLETTI Direction IT & Innovations - IT Operations, SAP CCC テクニカル コーディネータ Kuwait Petroleum Q8, Italia SpA Kuwait Petroleum Q8 は SAP ERP アップグレードと Oracle Real Application Clusters(RAC) を組み合せて使用 業種 : KUWAIT Petroleum S.p.A 社の社外のダウンストリーム ( 精製およびマーケティング ) 活動 従業員 : 約 4700 人 ( 全社 ) オラクル社の製品およびサービス : Oracle Database 10g Oracle Real Application Clusters (RAC)10.2 Oracle Clusterware SAPCTL/ Control Utility Oracle サポート 主なメリット : より柔軟かつスケーラブルな SAP の活用 SAPの安定性/ 高可用性の向上 パフォーマンスの向上 新しいテクノロジーによる拡張の基盤 広範囲のIT 近代化イタリアをドライブすると マルチカラーの帆が 2つ描かれたQ8のロゴをよく目にします Kuwait Petroleum Italia (Kupit) は Kuwait Petroleum International(KPI) のイタリア支社で クウェート国外で Kuwait Petroleum Corporationのダウンストリーム活動をコーディネイトする従業員 4,700 人の国際企業です Q8ブランドを掲げたガソリンスタンドを 2,750 箇所以上運営し 650 人以上を雇用するKupit は 国際的なグループ企業内で特に重要な業務を担当しています インストールされた SAPは一部の既存アプリケーションを含め 企業全体で使用されています 最近の主なエレメントは SAP ERP 6.0(IS Oil 使用 ) と SAP NetWeaver Business Intelligence 7.0です チームと SAP CCCテクニカル コーディネータの Fausto Capelletti 氏にとって 2007 年は企業のIT 史における重要な節目でした 合計 3つの新しい ITの方向性が取り入れられ 成功裏に実装されたのです 3つの方向性は すべてSAPシステムとの関連で考える必要があり 企業にとって様々なメリットが得られる最適化を意味します まず 標準サーバー (Dell) とLinux Red Hatオペレーティング システムを基礎に Unixシステム ランドスケープをLinuxシステムに交換し 次に SAP R/3をSAP ERP 6.0に SAP BW 3.1をSAP NetWeaver Business Intelligence 7.0に移行します さらに 現在 Q8はOracle Real Application Clustersとともに新しい SAPアプリケーションを使用しています Fausto Capelletti 氏が説明するように 最新のバージョンとテクノロジーを使用することは 継続的な改善を意味し この改善は様々な形をとります 初期段階に新しい手法を取り入れ さらに発展させることで早い時期にメリットが得られます SAP 環境では 関連するコンポーネントや要素すべてを考慮し 継続的な改善プロセスに集中することが必要です Oracle RACを使用して得る最高の経験 Kuwait PetroleumがOracle RACとSAP ERP 6.0 アップグレードの組合せを選択したのは偶然ではありません Kuwait Petroleumでは すでに Oracle Real Application Clustersと SAP 以外の既存アプリケーション (Oracle Databaseを基礎にした CRMまたはデータ ウェアハウス ) とで 非常に良好な経験がありました SAPを使用した場合でも Oracle RACのメリットを享受できるようにしようと思いました 明白な答えは Oracle RACと SAP ERPアップグレードを使用することでした と ITエキスパートの Capellettiは述べています 数年前にSAPのデータベースを Infomixから Oracle Database に切り替えて以来 オラクルは Kuwait Petroleumの戦略的 ITパートナーです

27 Kuwait Petroleum の Oracle 10g RAC for SAP 27 Oracle RACの導入は テストも含め約 3ヶ月で完了しました SAPと ミラノ ( イタリア ) に基盤を置くオラクル パートナーの TechEdgeが協力し ウォルドルフ ( ドイツ ) にあるオラクルの Global Technology Center for SAPの支援を得て このプロジェクトは計画された時間内に実装されました Kuwait Petroleumの計画では 2ノードのRACクラスタ (SAPの高可用性を得るために Oracle Clusterwareをベースにした Oracle Clusterware SAPCTL) 内で 2X4 AMD Opteron CPU( それぞれ 32GBのRAMを装備 ) を使用する Dell 社製ハードウェアが稼動します ストレージ システムは NetApp 社製です どちらのシステムも Oracle RAC 上でSAP ERP(ECC 6.0と業種別ソリューション IS Oil) とSAP NetWeaver Business Intelligence 7.0を実行します データベース (Oracle 10.2) は それぞれサイズが 1TBを超えます 合計で SAPユーザーは 1,100 人を超え アプリケーションは 複数の言語で使用されます Kuwait Petroleumでは 11 月から Oracle RACがR/3および BW 後継バージョンとともに実行されています 将来にも対応できる安定した基礎 SAPを使用した場合でも Oracle RACのメリットを享受できるようにしようと思いました 明白な答えは Oracle RACを SAP ERPアップグレードと組み合せて使用することでした Fausto Capelletti 氏 Direction IT & Innovations - IT Operations, SAP CCC Oracle RACを実装することで Kuwait Petroleum はあらゆる種類の向上を見込めるポジションに達しました SAPアプリケーションの可用性をさらに改善できるだけではありません 現在は SAPアプリケーションを標準サーバーと Linuxオペレーティング システムとともに使用しています 2つのデータベース インスタンスのうち 1つに障害が発生しても もう 1つがそのタスクを引き継ぎます Oracle Real Application Clusters に変換することにより より大きな柔軟性とスケーラビリティを得ることができ パフォーマンスが向上し 将来を見据えたテクノロジーを活用できます と ITコーディネイタの Capelletti 氏は述べ さらにこう付け加えました Oracle RACは 費用便益をもたらし総所有コストを削減します Kuwait Petroleumは中期的には Oracle RACと他の SAPアプリケーションを組み合せて使用することを計画しています 全体として Kuwait Petroleumは新しいハードウェア展望 SAP ERPアップグレード Oracle RACという大掛かりな 3 段階の変更を見事に成し遂げました 新しい IT 環境は 必要なときに拡張可能な将来にも対応した安定性のある基礎を提供しています また Kuwait Petroleum は グローバルな石油産業にとってメリットのある最新の機能とテクノロジーを活用しています

28 28 Oracle Real Application Clusters を選択した大きな理由の 1 つは 私たちが Oracle プラットフォームに慣れ親 しんでおり その経験からこのプラットフォームには高い信頼性があることを知っているからです ANDRE EDWARDS 氏マネージャ 情報管理サービス National Gas Company of Trinidad and Tobago Limited National Gas Company of Trinidad and Tobago Limited は 信頼性とスケーラビリティを向上させつつインフラストラクチャを簡素化 National Gas Company of Trinidad and Tobago Limited Point Lisas Industrial Estate コウバ トリニダード トバゴ共和国 業種 : 天然ガス 年間収益 : 1 億 7,400 万米ドル 従業員 : 750 人 オラクル社の製品およびサービス : Oracle Database Oracle Real Application Clusters 主なメリット : 信頼性が高く スケーラブルで柔軟なIT 環境を構築 Linuxで稼動するSAPアプリケーションで信頼性の高いパフォーマンスを得られる 即時性があり完全なフェイルオーバーを確保する ハードウェアとメンテナンスのコスト削減 毎年 トリニダード トバゴ共和国から採掘される石油と天然ガスは 国の GDPの34% 以上に寄与し 2007 年度で27 億米ドルにのぼります 1975 年 トリニダード トバゴ政府はNational Gas Company of Trinidad and Tobago Limited(NGC) を設立しました その業務は 国の財源として国内の天然ガス資源の獲得 輸送 および販売です 事業開始から 30 年経った 2005 年 NGCは非効率的なソフトウェア アプリケーションの影響が出始めたため 処理能力を追加することで臨時に対応しました データ インフラストラクチャを精査するために コアとなる Enterprise Resource Planning(ERP) アプリケーションをアップグレードすることを決定し IT 機能を大幅に簡素化 信頼性とスケーラビリティを高めることに主眼を置きました Andre Edwards 氏は 私たちは 高い可用性とスケーラブルな環境を必要としていました と述べています また 環境を拡張可能にしておき 必要なとき以外は処理能力を追加したくありませんでした ITインフラストラクチャ変更の方向性を決定するにあたって 簡素化という方針が示されました 同時に オープン ソースの Linuxオペレーティング システム Oracle Database ERPアプリケーションの新しい SAPスイートという NGCが望むコンポーネントをシステムに短期間で実装する簡単な方法はありませんでした その解決策は Oracle Real Application Clusters(RAC) をベースにした環境を構築することでした ハードウェアではなくノード他のあらゆるエネルギー供給者と同様に NGCは消費量の周期的な拡張と縮小に対応する必要がありました さらに NGCは基本業務である天然ガスの獲得 販売 輸送から業務を大幅に拡大していました 今日の NGCは ガス パイプライン 工場用地 ガス生産 港湾インフラストラクチャ 液状天然ガス 液化天然ガス (LNG) の経営と 戦略的投資を行う多角的なグループ企業です

29 NGC における Oracle RAC for SAP 29 NGCは これらの変動と増加に対応するために より多くのコンピュータ装置を購入したため IT 環境が非常に複雑になっていました そのため 2006 年にNGCはOracle R A C のエンタープライズ グリッド コンピューティング テクノロジーを使用して IT 操作の合理化を決定しました Oracle Databaseのオプションである Oracle RACは 従来型の共有ディスク アプローチの限界を打ち破った共有キャッシュ テクノロジーを使用するクラスタ データベースです Oracle RACの代替は 3つの個別のデータベースの管理 バックアップの管理 スケジュールのバックアップ 3 つの別個のデータベースのあらゆるパフォーマンス コード測定のパッチ作業を行うはずでした と Edwards 氏は述べています 現在 私たちが手にしている環境に比較できる環境はありません これは 基本的に1つのデータベースで 5つのノードに対応しています より良い障害時計画カリブ海諸島の熱帯性低気圧は あらゆる業務にとって予測できない脅威です NGCにとって システム障害はガス供給サービスの中断を意味し 市民と企業に不便を強いることになり経済的にも大きな損害を与えます NGC では ソリューションを評価する際にフェイルオーバー機能は重要な要素でした Oracleを検討していくうちに Oracleには障害時リカバリという点で 私たちに役立つ機能があることがわかりました と Edwards 氏は説明しました Oracle RACの障害検出およびリカバリ システムは ノード間の負荷分散を利用するため シングル ポイント障害を排除します シングル ポイント障害がなければ 1 つのノードの障害が他のノードのプロセス トランザクション機能に影響を与えることはありません データベースは 障害が発生していない残りのインスタンスで継続して利用できるため 損失や停止時間を回避できます またNGCは 定期的なサービス停止期間中に負荷分散を利用することも希望していました Edwards 氏は 利用中に本番データベースのシャットダウンをおこなうことは 常に我々の心配の種でした と説明しています Oracle RACには 5つのノードがあるため テストしてみたところ何の問題も起きませんでした OracleとSAP は 問題なく稼働し続けていました 可用性に影響を与えずにノードを停止できることが 私たちにとって重要なので す と Edwards 氏は付け加えました Oracleを選択した理由 NGCのプロジェクトは複雑でした NGCが導入を望んでいたのは 新しい SAPアプリケーションを含めて 複数のベンダーのアプリケーションとシステムを組み合せたアーキテクチャの構築でした より高いレベルで 将来的に複雑になるのではなくシンプルで安定し標準化されたスケーラブルなアーキテクチャを希望していました Edwards 氏によれば これらの目的を満たす唯一のソリューションが Oracle RACでした 私たちの意図は あらゆるミッション クリティカルな用途にOracle Databaseを活用することで 標準化された環境を作り上げることでした と Edwards 氏は説明しました これらの重要なアプリケーションの一部は SAPでしょう 今後 アプリケーションが組織全体で使用されることに留意する必要がありました したがって これらの可用性と信頼性を確かなものにしなければならなかったのです 最終的に NGCは成長が加速するたびに 製図板やシステム製造業者に戻らなければならない状態を望んでいませんでした 私たちは 冗長性や高可用性があり 信頼できる環境を提供するソリューションを望んでいました 将来 より多くの処理能力が必要になったときに いつでも短期間かつ低コストで拡張できるように スケーラブルなソリューションを求めていました OracleのReal Application Clustersを使用すると 必要に応じて拡張できます 事前に大量の追加機器を購入しておかなくても 必要な時に追加機器を購入するだけで済みます Andre Edwards 氏マネージャ 情報管理サービス

30 30 Oracle RACを使用してから これまでより簡単に既存の環境を管理できるようになったと思います Andre Edwards 氏マネージャ 情報管理サービス 実装プロセス 5つのノードを持つ NGCのOracle RAC 環境は 2006 年 1 月に開始され夏に完了しました 約 600のユーザーが使用するこの環境には Dell OptiPlexデスクトップと SAPアプリケーション用の Microsoft Windowsおよびデータベース用の Red Hat Linuxを実行する Dell PowerEdgeサーバーが含まれています National Gas Company of Trinidad and Tobago Limitedからのアドバイス 新しいシステムに投資する前に グリッド コンピューティング テクノロジーなど 新しいテクノロジーをビジネス ニーズに取り入れることができるか検討すると良いでしょう このようなテクノロジーにより 後で不要になるハードウェアを大量に購入する必要がありません 一般リリースには Oracle-SAP-Dell-Linux 構成はなかったため NGCで実装の成功はすべての関係者の協力にかかっていました プロセスと環境の認証という点で Oracleと SAPはともに広い範囲に渡って私たちの役に立ってくれました と Edwards 氏は述べています 最初は いくらかの懸念がありましたが パートナーと作業を進めるうちに すべての懸案事項を解決できました NGCは 最初の実装が困難であったとしていますが それに続く Oracle-RACの2ノードによるミラー システムの実装には 2 週間しかかかりませんでした 基本的に 何をすべきかがわかっていたので 簡単でした と Edwards 氏は説明しました 使用されない過剰なテクノロジーを購入するより 必要に応じて拡張できるインフラストラクチャに投資します ある構成を使用できないからといって その構成を実現できないとはかぎりません 私たちの経験から 望みの製品を入手でき それらを併用できることがわかりました トリニダード トバゴ政府は 1975 年 8 月にNational Gas Company of Trinidad and Tobago Limited(NGC) を設立しました NGCは ガス パイプライン 港湾インフラストラクチャ 工場用地 石油およびガスの製造 LNGおよび液状天然ガスの運営と戦略投資を行う多角的なグループ企業です Edwards 氏によれば Oracle RACを配置したことで NGCはアーキテクチャを簡素化するという目的を達成しました 基本的に 現在 5つのコンピューティング ノード上に1つのデータベースがあります Edwards 氏はさらに続けて Oracle RACを使用してから これまでより簡単に既存の環境を管理できるようになったと思います と述べています

31 SAP 認定の Oracle RAC システム構成 31 SAP 認定の Oracle RAC システム構成 Windows Linux で構成が異なります 詳細は SAP Note をご覧ください Microsoft Windows における一般出荷構成 Red Hat または SuSE Linux における一般出荷構成 Oracle RAC 10.2 on Windows x86, x86_64 and IA64 Oracle Database OCFS (Oracle Clusterware ソフトウェアに組込み ) Windows 2003 Release 2 EE, Service Pack 2 SAP Enqueue Replication の Microsoft Cluster Services による保護 (SAP Central Instance と RAC instance は同一筐体へ配置可能 ) iscsi は最大 4 ノード サポート対象外 : インターコネクト用のクロスケーブル構成 Infiniband ASM RAW デバイス Oracle RAC 10.2 on Linux x86, x86-64, IA64, Power RHEL4, RHEL5, SLES9, SLES10 Oracle Database OCFS 以上 ( データベース Oracle ソフトウェア SAP ソフトウェア用 ) OCFS2 1.4.x SLES 10 Support Package 2 または RHEL 5.2 EMC Celerra NFS ( データベース Oracle ソフトウェア SAP ソフトウェア用 ) NetAppliance NFS ( データベース Oracle ソフトウェア SAP ソフトウェア用 ) SAP Enqueue Replication の Oracle Clusterware による保護 (2 ノード構成の場合 SAP Central Instance と RAC Instance は同一筐体へ配置可能 ) SAP Enqueue Replication の HP Service Guard による保護 ( 最低 4 ノード必要 SAP Central Instance と RAC Instance は同一筐体へ配置不可 ) サポート対象外 : iscsi FireWire インターコネクト用のクロスケーブル構成 InfiniBand Red Hat GFS Veritas CFS ASM RAWデバイス IBM GPFS

32 32 Gottawald Port Technology GmbH の SAP on Oracle 10g RAC Gottwald Port Technology GmbH 本部 : デュッセルドルフ 業種 : 港湾およびインターモーダル出荷テクノロジー ハードウェアおよびソフトウェア 売上高 : 3 億 2,550 万ユーロ 従業員 : 800 人 発明の精神でグローバル マーケットに対応デュッセルドルフ ( ドイツ ) に本部を置く Gottwald Port Technology GmbHは Demag Cranes AGの支社で港湾用クレーンと港湾自動化テクノロジーのサプライヤです 可動港湾クレーンを発明し コンテナ荷役の自動化の先導役になった Gottwald Port Technology GmbHは 90カ国以上に顧客がいます 2007/2008 会計年度の生産高は 3 億 2,550 万ユーロで 従業員は約 800 人です 世界中で約 1,300 台に及ぶ可動港湾クレーン装置が設置されており Gottwald Port Technology GmbHはこの市場で世界を主導しています 可動港湾クレーンと同様に Gottwald Port Technology GmbHは璧岸クレーンとクレーン船も開発し Gottwald 社のポートフォリオには 無人搬送車 (AGV) 自動スタッククレーン (ASC) および様々な構台が含まれています あらゆるレベルでの体系的なアプローチ Gottwald Port Technology GmbHは プランニング シミュレーション 試運転 日常業務の制御など 港湾自動化の取り組み全般にわたるシステム サプライヤとして世界市場で名声を博しています I Tレベルでは 適切なハードウェアとソフトウェアを含めたシステム ソリューション ならびに港湾施設における円滑な自動操作を確保するための個別対応のナビゲーションおよび管理ソフトウェア ソリューションも提供しています 製品の範囲は ターミナルの計画 設計 容量評価を行うための最新のシミュレーション テクノロジーとエミュレーション テクノロジーにまで及びます これらにより 計画投資に先だって将来のターミナルの構造と性能をリアルに描くことができ 投資決定を検証できます Gottwald Port Technology GmbHは 企業の中心的業務である 海や内陸部の港湾における機械や大規模プロジェクトの物流ソリューションの開発に加え ビジネス管理問題に必要な重要性を付加し 最先端のソフトウェア ソリューションによって論理的に相互接続する方法を提供します 自社製品に付加する技術設計の高い基準 性能と信頼性も 組織内のERPシステムに反映されています 信頼性の高いHPハードウェア プラットフォームにOracle Databaseと SAPエキスパートを組み合せることにより 業務管理の観点から持続性が得られます

33 Gottwald の Oracle 10g RAC for SAP 33 システム ランドスケープ :2007 年の初期状況 次に 私たちはクラスタ テクノロジーが高可用性を意味するだけではなく スケーラビリティも意味することを理解しました 考え得るかぎり 私たちのシステム ランドスケープに大きな利益をもたらすのは RACです スケーラビリティによって得られる柔軟性と将来への対応性 Gottwald Port Technology GmbHは ERPにおいてはクラスタとして設計された開発システム 統合システム および生産システムという 3つのレベルによる一般的なシステム ランドスケープを持っています Gottwald Port Technology GmbHでは 1996 年から SAP on Oracle Databaseを実行する HP Unix 環境に取り組んでいます 古くなったハードウェアは使用しながら新世代のハードウェアに順次交換していましたが Gottwald Port Technology GmbHでは 従来型のクラスタを使用するデータベースで高可用性を実現するという目的を十分に達成できませんでした 特に Demag Cranes AGに提出する月次報告書の作成といった重要なタイミングでは システムの停滞は損失につながりかねない状況でした ハードウェアのメンテナンス契約の期限が 2007 年春までであるのを契機に Andreas Rogge 氏が率いる ITチームは状況分析を行いました その結果 SAP 上の高可用性データベースを使用して 完全にフェイルセーフなシステム ランドスケープに移行する最適な方法は Oracle RACを使用することであると判明しました オラクル社と状況をじっくり話し合うまで バッチ ジョブの実行時やダイアログ プロセスの許容できない応答時間などで 改善の余地があることに気が付きませんでした と 情報技術部門のSAP BasisのITマネージャ Andreas Rogge 氏は2007 年当時の状況を振り返って述べています この分析は ソフトウェアの選択に影響を与えただけでなく ハードウェア戦略の変更も招きました システム ランドスケープの一般的な構造では 以前にも増して Intel ベースの Linuxシステムが計画的に組み込まれることが多くなりました 包括的なコスト / 利益の分析から Oracle RACとDELL PowerEdge 2950プロセッサの組合せが 多大な利益を生むことがわかりました 十分に考慮した結果 関連するコストと複雑さの点から HP-UXと RAC または HP-UXと SGクラスタを使用したソリューションが投入されました Andreas Rogge 氏 SAP Basis の IT マネージャ

34 34 システム ランドスケープ :2008 年の目標状況 エキスパートとパートナーシップの組合せ 2008 年の初め Andreas Rogge 氏は一般オブジェクトの実装 特に SAP ERPシステムを移行するために探していたエキスパート プロジェクトのパートナーを見つけました Rogge 氏と彼が率いるチームは ミュンヘンをベースにした IS4IT 形式のNetApp Switched Metro Cluster 上でOracle RACと SAP ERPを稼動させる環境に必要な知識を持つ熟練したパートナーを見つけました このパートナーは すでにミュンヘンのクリニカル センターで同様のプロジェクトの実装を成功させていました 2008 年 5 月初め 認定パートナーのもとに DELLハードウェアが届けられ プロジェクトは具体化し始めました 6 月中頃にはプロジェクトが進行中で 開発システムが移行されテスト フェーズが成功裏に完了しました 実際の統合システム移行に先駆け 本番システムのプロジェクトの複雑さを評価するために 統合システムがコピーされました 本番システムの移行に最適な日として 以前から 2008 年 8 月の第 1 週と第 2 週の週末が選択されていました SAPシステムのサービス契約期限に合せた選択でした さらに 月次報告書をDemag Cranes AGに提出する関係で システムの停止時間は許されませんでした 嬉しい驚き 2008 年 12 月 移行の結果はまだ最終的に数値化できる状態ではありませんでした しかし Andreas Rogge 氏は 達成される結果の分析は結果そのものが語る と信じていました ハードウェアによって実現できることが 突然増えたことに驚きました 現在は HP-UX 環境で稼働させていたハードウェアより もっと多くのハードウェアを稼動させています さもなければ システムの停滞を繰り返しながら稼動させていたことでしょう CPU 負荷という点で 現在の私たちのシステムはオーバーロードというよりアンダーロードと言えるでしょう また その他にも様々な点が改善され IT 部門が正しい戦略決定を行ったことを示しています 以前は 2~3 秒かかっていたダイアログの応答時間が90% 低減され 現在は300マイクロ秒未満です バックアップの実行時間も一部で90% 削減されましたが バックアップの実行に必要な合計時間は ほぼ同じです データベースの高可用性という点では フェイルオーバー テストで確認されているようなエラーは発生しません 全体的に ITランドスケープの新しい柔軟性 信頼性およびパフォーマンスは期待をはるかに超え コストも大幅に削減できました

35 35 Deutsche Telekom における SAP on Oracle 10g RAC Computerwoche(IDG) の翻訳 Wolfman Herrmann 訳 2008 年 8 月 18 日 出典 : Deutsche Telekomはコア アプリケーションを Linux に移動ボン ( ドイツ ) に基盤を置く電気通信業界の巨人は Linuxオープン ソース オペレーティング システムが実行されている Intelサーバーに 世界最大級の SAPインストールの 1つである収益管理システムを移行しました Deutsche Telekomは 自社内のITサービス プロバイダである T-Systemsを通じて Linuxプラットフォームをより多くの基幹業務アプリケーションに使用しています 私たちは プロセスのより多くの部分をできるかぎり自動化し 工業化する戦略を推進しています と 会計システムの操作および技術インフラストラクチャを担当する Christoph Böhm 氏は説明します Linuxを使用すると 完全にメーカーに依存することがなくなり 最短のコースでこの目標を達成できます 2005 年のLinux 移行計画 2005 年 Deutsche Telekomは 会計アプリケーション システムの全体的な概念を作成し この移行を開始しました IT 戦略の主要な問題点は 次のとおりです - Linuxに移行できるシステムと移行時期 - Linuxが完全にサポートされていないため Unix 派生製品で実行しつづける必要のあるシステムの特定 Böhm 氏は 現在使用しているシステムの 3 分の1は まだLinuxに対応していないことが明らかになりました と述べています これが 特別なアプリケーションの実態でした ( How Linux is pushing out the Unix system も参照 ) SUSE Linuxで稼動するIntelサーバー Deutsche Telekomは 収益管理をオープン ソースのオペレーティング システムに移行することで 企業戦略の節目を迎えました これを達成するために Deutsche TelekomはSAPソフトウェア RM-CA(SAP Revenue Management - Contract Accounting) を使用しています サーバー プラットフォームは SUSE Linuxと Oracle 10g RACデータベースを実行する x86 Fujitsu - Siemensコンピュータが提供しています 収益管理とほぼすべての企業顧客は ドイツの通信会社から請求されます 唯一の例外は 特別なコスト センター構造を持つ主要法人の顧客で これらは別のシステムに割り当てられています 会計システムは 約 4,000 万件の得意先顧客に対して年間約 5 億件の支払いトランザクションを処理します

36 36 Deutsche Telekom の SAP on RAC に関する Computerwoche(IDG) の記事 他のすべてのアプリケーションは オープン ソースのオペレーティング システムに移行しましたが このプロセスは進行中です 最大の移行プロジェクトの 1つは 収益管理でした 2001 年から2004 年の間に ITチームは以前分散していた 15 個のシステムを単一のプラットフォームに統合しました プロセスの一部として Deutsche Telekom は15 個のUNIXベースのハードウェア プラットフォームを Sun Microsystems 社製のSPARC 4+ プロセッサ 130 個で構成された高パフォーマンス クラスタに交換しました Böhm 氏は次のように説明します このプラットフォームは 莫大な償却費用がかかりました 私たちは古いUNIX 環境の償却期間を終了させ 切り替えた T-Systemは 動的な使用率ベースのホスティング コンセプトを実現させました この場合 動的とは ITサービス プロバイダが実際の使用率に基づいて処理能力とメモリーに課金することを意味します Deutsche Telekomは これが経費削減につながったと言います また Deutsche Telekomは T-Systemによってバッチ プロセスを 20% 高速化できたと公式に発表しています Böhm 氏は Linuxの処理能力により 収益管理段階の処理が20% から40% 高速化されました と述べています SAPを同時に使用する 5,000のユーザーに対して 約 2 秒強の平均応答時間を達成しました UnixからLinuxへの主なステップ ITマネージャが述べているように 移行プロジェクトにまったく問題がなかったわけではありません ホスティング プロバイダが Deutsche Telekomの収益管理システムレベルのアプリケーションを Linuxプラットフォームに移行するときには 大変勉強になりました 結局のところ 慣れ親しんだ UNIXシステムに比べてより小さな Linuxシステムで十分運用されているわけです T-Systemsは実稼働を開始しました 企業内の ITサービス プロバイダによると この 動的サービス の 60% 以上がLinuxシステム上で運用されています しかし Deutsche Telekomのテクニカル エキスパートでさえ 1 点だけ再考する必要がありました 2007 年の初頭 ビジネス プロセス ロジックをテストしました Böhm 氏は次のように説明しています 多数のプロセス段階を改善するために 計画的なシステム切替えを採用しました 現在 このビジネス プロセスは 最適化する前に必要だったリソースの約 40% しか必要としていません Deutsche TelekomのITの歴史かつての端末ごとの SAPインストールは Deutsche TelekomのITの歴史を物語ります 1990 年代の初め Deutsche Telekomはドイツの各地域を結び IBMのUNIXである AIXを実行する15 個の SAP 会計システムのネットワークを構築しました 当時の IT 担当者は これはその時点のハードウェアに十分なスケーラビリティがなかった結果であると説明しています しかし 顧客の移動や移転などによる頻繁なデータ統合は 許容範囲を超えるコストがかかりました 長年の間に必要となった様々な変更により メンテナンス費用も増大しました

37 37 私たちが優先したかったのは 画一性 標準化および操作の互換性を確保しつつ 将来もテクノロジーやベンダーの制限を受けることなく 迅速に成長するためのIT 基盤を構築することでした TRID B BORDOLOI 氏 CIO Indian Express Group SAP on Oracle10g RAC:Indian Express は Red Hat ソリューションを選択して レガシー インフラストラクチャについて将来を見据えたプラットフォームに変換 Indian Express Group 背景 Indian Express Groupは インドで最も知られたメディア企業で 数々の有名な出版物を発行しています このグループは 優れた調査報道を推進し Journalism of Courage( 勇気の報道 ) というスローガンを掲げている The Indian Expressを所有しています また インド経済に焦点を当てた経済新聞 Financial Express マラーティー語の日刊新聞 Loksatta ヒンディー語の日刊新聞 Jansatta インドのエンターテインメント業界を対象としたタブロイド紙の Screen も所有しています 目的インドのメディア業界は 非常に競争が激しく 変化する消費者の要求と技術的な発展に応じて絶え間なく変化し続けています 2004 年後半には Indian Express Groupでさえ ジャーナリズムに新しい基準を確立しようと ITインフラストラクチャをコスト効率良く拡大することに取り組んでいました 全国紙の新聞として Indian Express Groupは国内の 19 箇所以上に拠点があり 品質に妥協することなく出版物を迅速に発行できる堅固なITインフラストラクチャを必要としていました 競走で優位に立つために グループは長年に渡って様々なソフトウェアとハードウェアを配置し てきたため 情報の分散化 多数のPoint-to-Pointインタフェース 一貫性のないビジネス プロセスが問題になっていました Indian Express Groupのバックボーンである LAN サーバーでは クライアント ライセンス数に制限のある Novell Netware 3.12 OSが使用され メッセージ配信には.cc:Mail 8.2を使用していました 即時性が極めて重要な業界において これらのアプリケーションは グループの敏捷さに影響を与えていただけではなく 複雑でメンテナンスにコストがかかっていました コスト効率良く既存のニーズを満たすだけではなく 将来に必要な信頼性を得るために グループがソリューションを評価する必要があるのは明白でした 私たちが優先したかったのは 画一性 標準化 および操作の互換性を確保しつつ 将来もテクノロジーやベンダーの制限を受けることなく 迅速に成長するための IT 基盤を構築することでした と Indian Express Group のCIO Tridib Bordoloi 氏は説明しています 業種 : メディア 地域 : インド 目的 : 既存のレガシー インフラストラクチャを将来を見据えたソリューションに変換することは 既存の投資を保護しながら グループがコスト効率の改善を促進する土台を築くことになります 移行パス : Novell Netware 3.12 OSからRed Hat Enterprise Linux 5へ ソフトウェア : Oracle Database 10gとReal Application Clustersを使用する Red Hat Enterprise Linux 5 ハードウェア : Dell PowerEdge サーバー シリーズ 64ビット Intel Xeonプロセッサ 利点 : Red Hat Enterprise Linux 5の実装は Indian Expressに高可用性の安全で信頼性の高いプラットフォームを提供しました ベンダーに依存しないこのプラットフォームは ハードウェアの追加投資がなく高いコスト効率で拡張できます

38 38 Indian Express Group の Oracle 10g RAC for SAP Indian Express Groupは 常にメディアの自由という価値を支え続けています それはまるで オープンな精神が オープン ソースを支えているようなものです Tridib Bordoloi CIO Indian Express Group ソリューション将来の成長に貢献する正しいインフラストラクチャを評価する際 考慮すべき 4つの事柄がありました メディア業界では 停止時間を許されません このため 高可用性は不可欠な要件です 私たちは TCO 将来への即応能力および拡張性という点からもプラットフォームを評価しました と Bordoloi 氏は述べています 最終的に チームがファイル サーバーとプリント サーバーを効率的に運用している Red Hat Enterprise Linux に習熟していたことから 迅速な決断が下されました 実際 グループの ITチームのほぼすべてのメンバーが Red Hat Enterprise Linuxの使用と実装のトレーニングを受けていました Indian Express Groupは Linuxを中心に一連の現代化を主導することを計画しました ビジネス プロセスを合理化し完全にコントロールして 国内全体で情報の透明性を達成するために Red Hat Enterprise Linux 5 上で稼動するSAP を実装しました Indian Express Groupは 素材管理 メディア広告管理 会計および管理 メディアの販売および配布を行うために 4つのSAP モジュールをインストールしました Red Hat Enterprise Linux 5を選択することは疑いの余地がありませんでした 将来を見据えたプラットフォームを構築するための要件すべてを満たすからです 私たちは オープン スタンダードを支持します また 単一ベンダーの制約も受けたくありませんでした Red Hatは 必要に応じて 別のハードウェア プラットフォームに変更できる柔軟性があります と Bordoloi 氏は述べています さらに SAPはRed Hat Enterprise Linux 5を認定しています そのため Red Hatソリューションと SAPのすべてのモジュールとが完全な互換性を持つために必要なすべての条件が満たされています 利点使いやすく 既存の投資を保護し ハードウェアに追加投資せずにコスト効率良く拡張できる Red Hat Enterprise Linux 5により Indian Express Groupは テクノロジーの制約を受けずにビジネス目標に向かって前進できるようになりました 国内の他の新聞と同様 組織で場所を問わずに円滑に記事とページを転送できることは極めて重要です 現在 これは代理店への供給を含めて ワークフロー全体により実現されています 結果として印刷の品質を落とさずに 最新の号外ニュースに対応できるゆとりも生まれます 高可用性と信頼性についても Red Hat Enterprise Linux 5は サード パーティ製のソリューションを追加購入することでクラスタ化や仮想化などの機能にも手が届きます と Bordoloi 氏は説明しています Indian Express Groupは Oracle Real Application Clusters(RAC)10g をデータベースとし Red Hat Enterprise Linux 5をプラットフォームとして使用しています この組合せにより グループの柔軟性が向上し 運用コストを大幅に削減できます たとえば 現在の Indian Express Groupでは 動的にノード ストレージまたは CPUを設定して コストを抑え使用率を改善できます コスト 柔軟性 信頼性を兼ね備えたR e d H a t Enterprise Linux 5は本当に 私たちの期待以上でした 現在ある他のソリューションと比較し TCOを非常に低く抑えることができます それ以上に重要なのは 毎日のように新しい脆弱性や脅威に直面している他のプラットフォームとは異なり Security-Enhanced Linux (SELinux) 機能を使用した Red Hatのセキュリティ機能が 私たちに安心をもたらしてくれたことです と Bordoloi 氏は述べました

39 39 Indian Express Groupについてさらに何が特別かと言うと このグループがオープン ソース テクノロジーの使用という流行を作り出したことです メール サーバー ファイル サーバー SAP さらに企業のWebサイトに至るまで Indian Express Groupはバックエンドに Red Hat Enterprise Linuxを使用しています 賞賛の言葉は これで終わりません Indian Express Groupは 地域で最も早く SAP on RACを使い始めたユーザーなのです と Bordoloi 氏は述べています Bordoloi 氏は Indian Express Groupは 社会を前向きに変革できる品質の高い記事を発行する最前線であり続けてきました 最新のNetwork Worldテストでは 同一ハードウェア上の Windows 2008より 12% 消費電力が少ないことが明らかになり Red Hat Enterprise Linux が最もエコロジーなオペレーティング システム (Greenest Operating System) として選ばれたときに 私たちは良い選択をしたことと 住みやすい世界にするために 小さな貢献ができたことを喜びました と説明しました Indian Express Groupは 4C Plusによって開発されたNewsWrap 編集システムを実装することで ( 一昔前のfoxpro/DOSレガシーから脱却 ) インド全域のすべての出版物の編集業務を合理化しました この統合システムは 編集業務のすべてを網羅した完全なワークフローです これは 支局や代理店など あらゆるソースからの供給物を取り込み 使用する広告ページ企画があらかじめ準備された QuarkXpressの関連ページに情報を流し込み編集作業を行います Layout-Xは 所定の日に編集が予定されている広告をピックアップして 広告ダミー ( ページ企画 ) を動的に作成します Layout-Xが提案したページ企画の仕上げでは 手作業で修正が行われることもあります ページ公開の締切りごとに ページ企画を編集できます 緊急にページ企画が変更された場合は ページ更新のオンライン通知が編集ユーザーに送信されます 最終的に広告を配置する位置がピックアップされ SAP IS/MAMでは 広告請求の更新が行われます 広告ページ企画は やはり 4C plus 社製のLayout-X ページ企画システムを使用します Layout-Xは SAP IS/MAMおよび NewsWrapとシームレスに統合されています 前述のユーティリティは 両方とも Oracle 10gをデータベースとし RHEL 5xをプラットフォームとして使用しています

40 40 Oracle Database10gとOracle Real Application Clustersをベースにした新しいシステム アーキテクチャは パフォーマンスと信頼性が一体化されています ユーザーの反応も良好で 顧客サービスを拡大し続けることができます 広報担当者 ASE GROUP ASE Group は 新しいシステム アーキテクチャに変更し パフォーマンスとサービス品質を向上 ASE Group カオシュン 台湾 業種 : ハイ テクノロジー 歳入 : 3 億 300 万米ドル 従業員 : 13,000 人 Oracleの製品およびサービス : Oracle Database Oracle Real Application Clusters 主なメリット : 二次機器の利益拡大を含めた ハードウェア リソースの使用拡充 システムの可用性に影響を与えずに 新しいハードウェア ノードをシームレスに追加できる可能性を獲得 オンライン アーカイブとデータ再編成により ITの管理 メンテナンス 運用にかかるワークロードを低減 ASE Groupは 半導体の製造検査および組立てサービスの独立系世界最大手プロバイダです ASE Group のソリューションには 総合的な回路試験プログラムの設計 フロントエンドのエンジニアリング試験 ウェハー プローブ ウェハー バンプ 回路基板の設計および供給 ウェハー レベル パッケージ フリップ チップ システムインパッケージ 最終試験と設計製造サービスが含まれます ASE Groupのグローバルなデプロイ能力は 競合他社を押え大きく優位に立っています この組織の主力企業であるASE Kaohsiungは 台湾で第 2の都市に工場を持ち その収益はグループ全体の60% 以上を占めています 2007 年 ASE KaohsiungはOracle Database 10gと Oracle Real Application Clusters(RAC) を基盤にした新しいデータベースを実装し 企業リソース計画の配置をサポートし一連のシステム問題を解決しました この中には パフォーマンス上のボトルネックと ファイル アーカイブ化の問題がありました 高可用性ハードウェア アーキテクチャから Oracle RACへの移行により パフォーマンスと管理機能が向上し 工場の投資収益が増加しました ASE Groupの広報担当者は 次のように述べています Oracle Database 10g とOracle RACをベースにした新しいシステム アーキテクチャは パフォーマンスと信頼性が一体化されています ユーザーの反応も良好で 顧客サービスを拡大し続けることができます 売上成長が要求するITパフォーマンスの向上 ASE Groupは 世界中に展開しています 台湾の施設には カオシュン工場と 半導体の総合的な製造サービスを提供するチュンリーでの事業が含まれます ASE Groupは 単一サプライ チェーンから統合サービスを提供することで 競合他社との差別化を図っています フロントエンドの試験と設計 ウェハー プローブ パッケージ設計 回路基板の設計と製造 パッケージ サービス 製造試験 およびシステム組立てを提供することで ASE Groupは顧客の処理期間の短縮 製品の高い収益と信頼性の確保に貢献しています このパフォーマンスにより売上は著しく伸びましたが 出荷要件の複雑さも増加しました ASE Groupが製造する各ロットは規格品ではありません そのため各顧客の指示や要件に基づいて 個別に梱包する必要があります

41 ASE Taiwan の Oracle 10g RAC for SAP 41 ASEのカオシュン工場は ほぼ年中無休で製品を出荷しています 出荷ごとに 工場の企業リソース計画システムの会計および他の関連コンポーネントで一連のプロセスが開始されます しかし データ アーカイブの不備やボトルネックによって頻繁に低下するパフォーマンスなど 一連の問題は生成されるデータ量が原因でした かつて ASE Kaohsiungの情報テクノロジー スタッフは 本番システムを中断しないようにサーバーをオフラインにし手動でファイル作業を再編成しなければなりませんでした Oracle Database 10gにより オンラインでのファイル アーカイブが可能になり スタッフのワークロードが低減されました ASE Kaohsiungは サーバー ハードウェアを拡張して急増する需要に対応する方法が 企業にとって財務の大きな負担になることに気が付きました 企業リソース計画システムとデータベースは 本番サーバーとバックアップ サーバーにまたがる高可用性アーキテクチャで実行されています アクティブ / パッシブなクラスタとして稼働するこの2ノードのシステムでは バックアップ サーバーがオンラインに保たれていますが アプリケーションやサービスをエンド ユーザーに提供していません 2004 年に初めて企業リソース計画システムを実装した際に ASE Kaohsiungはシステム管理用にOracle Databaseをインストールしました しかし 元のアーキテクチャはデータの急増に対応できなかったため ASE Kaohsiungはデータベースと企業リソース計画システムの両方で 包括的にアップグレードすることを選択しました ASE Kaohsiungは 必要なハードウェアを購入し企業リソース計画システムの最新バージョンと Oracle Database 10gおよび Oracle RACをインストールしました データベースのメンテナンスと運用の強化 ASE Kaohsiungは Oracle RACならびに Oracle Database 10gの新しい技術的フレームワークと機能の柔軟性によって得られるパフォーマンスの改善に着手しました 新しいデータベースで改善された管理およびオンライン機能により 私たちのデータベース管理のワークロードが低減されました と広報担当者は述べています システム アップグレードとアーキテクチャの変更プロジェクトの最も熱心な支援者であったユーザーは 改善されたパフォーマンスと応答時間の恩恵を受けています Oracle Database 10gと Oracle RACで構築された新しい環境は このミッションを首尾よく果たしました と広報担当者は述べています Oracleを選択した理由 ASEは 2007 年 1 月にアップグレード プロジェクトを開始しました このプロジェクトでは 企業リソース計画システム データベースのアップグレードと Oracle RACの実装が行われ7 月末に完了しました この新システムは 8 月 1 日に運用を開始しました ASEがOracle Database 10gを選択した理由は 業務の鍵となるプラットフォームとして Oracle Databaseには定評があるためです また Oracle Databaseは 市場最高のシェアを持つ業界を主導するブランドです これらの要素により ASEは競合他社のソリューションは一切評価せずに決定を下しました 広報担当者は Oracle RACは完成された製品で 一連の主要機能を提供してくれます と述べています 現在 Oracle Database 10gとOracle RACをインストールしているのは ASE Kaohsiungのみで ASEの他の業務部門はまだ独自のシステムを使用しています Oracle RACの卓越したパフォーマンスを基盤として 私たちは他の業務でもこの環境を再現したいと思っています と広報担当者は述べています Oracle Database 10gと Oracle RACをベースにした私たちの新システムは パフォーマンスと信頼性が結合されたものになりました 広報担当者 ASE Group

42 42 ASE Taiwan の Oracle 10g RAC for SAP 実装プロセス ASE Kaohsiungは プロジェクトの一環として事前に6ヶ月かけ概念実証を行い 最高のシステム パフォーマンスを得るための方法を特定しました この工場では オラクルの支援を受けながら 最大の投資回収率を得る方法を追求しました 新しい環境は 2007 年 8 月 1 日に稼働を開始 Oracle RACは 元の高可用性環境に見事に置き換わり 工場はハードウェア リソースを十分に引き出すことができるようになりました 古い高可用性アーキテクチャでは 2つのサーバーを購入しても 片方は本番用 もう一方は待機用として控えていました と広報担当者は説明しています Oracle RACを実装してからは 両方のシステムが同時に実行されるため 両方のシステムの可能性を有効に使用できます 最も重要なことは パフォーマンスが改善されたことです ASE Kaohsiungは Oracle RACのスケーラビリティも歓迎しています 情報テクノロジー マネージャは クラスタにハードウェア ノードを追加して システムの可用性を低下させることなく リソースを増加できます OracleのRAC ソフトウェアの機能により 複数のハードウェア プラットフォームがサポートされただけではなく ASE Kaohsiung の選択肢も拡大しました ASE Kaohsiungは ASE Groupの半導体製造テストおよび組立てを専門とする主力事業です ASE Kaohsiungの工場には グループの R&Dセンターがあり ワールドクラスの組立て ウェハー バンプ および試験サービスを行っています ASE Kaohsiungは 回路基板の設計と製造能力を含めた 完全なターンキー サービスを提供します

43 43 驚くほど短期間で実装し 安定性とスケーラビリティが向上し 以前より少ない労力と時間でSAPリリースをアップグレードできるようになりました 全体的に最高の結果が得られました ZORAN STRLJIC DIEHL Informatik GmbHのプロジェクト マネージャ兼 SAP Basisチーム リーダー DIEHL Informatik の Windows で稼動する SAP と Oracle Ral Application Clusters(RAC) プロファイル :DIEHL Informatik AG 情報および通信システムのコンサルタントと運営を行う企業として DIEHL InformatikはDiehlグループ内の他の企業や外部の製造業 商業 サービスなどの企業を支援しています DIEHL Informatikでは 85 人のスタッフ メンバーが働き 企業コンサルタント 情報管理システム 企業システム (SAP ) E-Businessシステム 電子アーカイブ システム P C システム インターネット / イントラネット サービス システム統合 システム移行および運用 電気通信 I Tセキュリティ トレーニングおよびハードウェア / ソフトウェア配布などの分野を取り扱っています Webサイトは Diehlグループは ニュルンベルクに基盤を置いています この国際的なテクノロジー企業は 金属 制御 防衛 および航空システムの 4 部門で編成されています 従業員は約 11,000 人で 年間取引高は2 億 2,000 万ユーロです 直面した問題内部的 外部的なSAPシステムのアップグレードとメンテナンスにかかる労力が大きいことから この管理作業を長期的に効率良く最適化する方法を探し始めました まず いくつかの SAPシステムの管理の複雑さを排除するために SAP MCOD(Multiple Components in One Database) を導入しました これにより 複数の SAP Basisシステムのデータを物理的に単一の Oracle Databaseに格納できるようになりました しかし このアプローチでは データベース サーバーに障害が発生したと きに 複数のSAPシステムを使用できなくなる危険がありました そこで DIEHL InformatikはMCODアーキテクチャの可用性を高める方法を探し始めました また DIEHL Informatikは将来に備えて設備を増強し さらにシステムのスケーラビリティ パフォーマンス および一般的な安定性を改善したいと考えていました 従来型の高可用性の概念では 一般的に複数のサーバーを重複させる必要があるため 管理作業が複雑になり エラーが発生しがちでした DIEHL Informatik は これを望んでいませんでした かわりに Oracle Databaseに満足している顧客として 自社の要件に理想的なソリューションを Oracle RAC(Real Application Clusters) に見出したのです 単刀直入に言えば Oracle RACを使用することでより高い安定性と容易な管理が実現しました また 複数のデータベース ノードの負荷分散は スケーラビリティを大幅に向上させました Diehl Informatikは 既存の管理チームでこれまでより多くのシステムを管理できるようになりました これがどのようにして実現されたか説明しましょう DIEHL Informatik 業種 / ビジネス分野 : Diehlグループのメンバーで 情報および通信システムのコンサルタントと運営を行う企業です 従業員 : DIEHL Informatikで85 人 Diehlグループでは11,000 人 Oracle 製品 : Oracle RAC Oracle Database RAC 上での MCOD 構成 得られたメリット : 安定性の向上 より少ないサーバーで より大きなスケーラビリティ 低減された管理作業 リリース アップデートにかかる時間の短縮 システムの拡張性の向上 将来も保証されるシステム SAP: SAP Business Suite(ECC6.0) SAP BI SAP CRM NetWeaver 2004s MCOD Solution Manager インフラストラクチャ : FSC PRIMERGY BX620S4(Intel Quad-Core) MS Windows Server 2003 NetApp iscsiクラスタ

44 44 DIEHL Informatik の Oracle 10g RAC は 2008 年 7 月以降から システムが 円滑かつ非常に安定して 稼動していることを確認しています Oracle RACは私たちに期待以上の結果をもたらし 私たちの持続性と競争力の両方を向上させてくれました Zoran Strljic Diehl Informatik GmbHのプロジェクト マネージャ兼 SAP Basisチーム リーダー 一石二鳥以上の効果このソリューションのアプローチは 次のとおりです 防衛部門では SAP BIとSAP CRMでUnicodeを使用するSAP Business Suiteの拡張を準備するために 中規模のSAP ERPシステム (ECC ユーザー Oracle Database 10g MS Windows Server 2003) が必要でした Oracle RACの導入目的は この SAP MCODシステムの安定性を高めることでした しかし IT は新しいデータ センターへの移転と同時に 既存の古いマルチサーバー ランドスケープは Fujitsu Siemens C o m p u t e r s 社製の新しい強力なP R I M E R G Y BX620S4 Intel quad-coreブレード サーバーに変更されました このストレージ ランドスケープには SCSIイーサネットを使用した最新のNetApp FAS3070クラスタが用意されました SAPのアップグレード Oracle RACの導入 インフラストラクチャの更新など同時に多くの変更が行われました しかし Diehl InformatikのSAP Basisのチーム リーダー兼プロジェクト マネージャの Zoran Strljic 氏は まったく心配していませんでした 入念な準備と LNW-Soft GmbHのLenard Buday 氏という熟練した RAC/SAP 実装パートナーにより このチームは 2つのOracle RAC データベース ノードに 4つのインスタンスを持つ SAP 本番システムをわずか 8 週間足らずで実装しました これには すべてのテスト システムと本番システムの SAPリリースのアップデート作業と システムを新しいサーバーに移動させる作業も含まれていました 全体的に 比較的短期間で完了しました 現在 Fischer 氏率いる管理チーム 現在までの経験と得られたメリット RACのみを実装するためにかかった時間 ( つまり SAP リリースとハードウェア インフラストラクチャ サーバー アップデートを含まない ) を考慮に入れると この作業には 6 週間しかかかっていません これは 予想より短く作業の途中で問題が発生することもありませんでした Oracle RACにより得られた副次的効果として 日常業務の安定性が大きく改善されたことがわかっています このような効果には 突出したレベルのスケーラビリティも含まれます このため 負荷要件が増加すると 他のデータベース ノードを迅速かつ簡単に追加できます SAPインスタンスの割当ても柔軟で 特定のOracle RACデータベース ノードに対する MCOD 領域およびプロセスも改善されました そして忘れてはならないのは 安定性を増すために使用してきた従来の方法と比較して 管理作業が少なくなりました このシステムを新しいハードウェアと組み合せたことで アップグレードにかかる時間も短縮されました 節約できた時間で 管理チームは経費と生産性の主要要素である SAPシステムを今まで以上にサポートできるようになりました これは SAPのエンド ユーザーが以前より高速かつ高い信頼性で 新しい機能を使用できるようになったということです 大きなメリットを経験した結果 DIEHL Informatikでは SCM APO( このケースでは Livecacheなしの Oracle Database) および独自エンジンを使用する PLMなど 他のSAPアプリケーションを Oracle RACに実装することを検討しています 向上した持続性 Diehl InformatikのSAPチームは 全体的に Oracle RACの持続性が向上し より迅速かつ柔軟に新しい問題に対応できるようになったと報告しています 結果として 企業の新しい目標をコスト効率良く 高い信頼性で支援を動的に提供できるようになりました

45 45 Oracleの索引キー圧縮は 最小限の労力で効果的なデータベースの最適化が実現できる素晴らしい方法です Oracle/SAP Global Technology Centerからのプロフェッショナル サポートが 非常に短期間で将来の拡張を視野に入れた私たちのプロジェクト実現に力を貸してくれました すべての面で期待通りでした ALEXANDER KÄFERLEIN Bauerfeind AGのData Centre/SAP Basisマネージャ 動くことは人生だ - Bauerfeind における Oracle 索引キー圧縮 プロファイル :Bauerfeind AG Bauerfeind AGは 圧縮靴下 サポーター 整形器具 矯正用インソール 義肢などの医療補助具を製造する 業界リーダーの 1 社です また 関連計測システムも供給しています ドイツで 1929 年に設立された中規模の同族会社で 従業員は約 1,800 人 ドイツに 3 箇所 ヨーロッパ 中東 および米国に15 箇所の支社があります この企業のモットーの 動くことは人生である は 地域および海外のスポーツに対する強い関わりを示しています 世界中のトップ アスリートが Bauerfeind 社の高品質な製品を信頼しています 2008 年 ヨーロッパで最も成功しているステア レーサーは 世界で最も高いビルの 1つ Taipei 101の2,046 段の階段を登るレースで優勝しました このとき 彼は医療用圧縮靴下を着用していました この企業は 2001 年からドイツのオリンピック チームの公式サプライヤを務め 関連業務としての整形外科サービスも北京オリンピックに同行しました Bauerfeind 社の製品は 高品質の医療用品販売店で販売されているため 誰でもがトップ アスリートの愛用する製品を購入できます 伝統と革新の融合 Bauerfeindには 革新という伝統があります この企業の知識と経験は 1999 年に開設された Innovation Centerでの患者やアスリート達との協業から得られ そこから新製品の開発や改善のアイディアが生まれました IT 部門は ITはビジネスを駆動する というモットーで Bauerfeind 社の製品が市場で成功するために大きな役割を果たしました 絶え間ない成長は結果として 複数のサイトと異なる IT システムの運用という問題を生み出しました 2002 年 Bauerfeind AGの設立を機会に Zeulenrodaの中央サイトで標準 SAP ERPソリューションを使用して統合することを決定しました 現在 ほぼすべてのモジュール (GTS CRM Mobile Sales および BI) が40 以上のシステムで稼働しています すぐに Bauerfeindは IBM AIXインフラストラクチャだけでなく Oracle Databaseを企業の主要な標準とすることのメリットを確信しました 成長管理言うまでもなく 国際的に成功をおさめた中規模の企業では 絶え間ないデータの増加を経験します 2008 年には 最大規模の Oracle Databaseで管理するデータ量が2TB 前後になりました これは決して巨大ではありませんが ( 一部の企業では20TBを管理し そのデータは増え続けています ) 週におよそ 2GBずつデータが増加し バックアップとリカバリに非常に時間がかかるようになりました そこで Data Centre/SAP Basisマネージャの Alexander Käferlein 氏と彼のチームは最適化を検討 Bauerfeind AG + Projekt 業種 : 医療補助具の製造業者 ( 整形器具をサポートする圧縮靴下 矯正用インソールおよび靴 人口装具の部品および素材 ) 従業員 : 1800 人 ( 全世界 ) Oracle 製品 : Oracle Database 索引キー圧縮前のサイズは2TB 主なメリット : データベース サイズを 15% 削減 索引を50% 削減 高品質 2 週間という短期間で実装 将来の拡張性を確保 Oracleがサポートするプロフェッショナル プロジェクト SAP: 40のセントラル システム ERP (ECC6.0) Internet Sales 5.0 CRM 4.0 NetWeaver 2004s BI 7.0 CO GTS すべてのモジュールがアクティブ インフラストラクチャ : IBM Power 5 / JS22 Blade Power6 AIX 5.3 TL7 / 6.1 SP2 LPAR s uncapped

46 46 Bauerfeind 社の Oracle 索引キー圧縮 Oracleの索引キー圧縮は 最小限の労力で効果的なデータベースの最適化が実現できる素晴らしい方法です Alexander Käferlein Bauerfeind AGのData Centre/ SAP Basisマネージャ し始めました このチームは 計画されている Unicodeへの切替えを前に エクスポート / インポート時間を最小限に抑えるために よりスリムなデータベースを必要としていました バックアップのソリューションはすぐに見つかりました パラレル化を改善することで バックアップ時間を11 時間から4.5 時間に削減できました しかし リカバリにはまだ 8 時間以上かかります この時間を最小限に抑える必要があります SDN(SAP Developer Network) の支援とウォルドルフの SAP/Oracle Technology Centerの有益なアドバイスにより 答えはすぐに見つかりました それは Oracleの索引キー圧縮です Oracle 索引キー圧縮 - 最適化の方法 Oracleが提供するのは データベース表の最適化だけではありません Oracle8 以降は Linux/UNIX/ Windowsオペレーティング システムで索引キー圧縮を提供しています 名前が示すように このプロセスには索引エントリ ( 索引ブロック ) から重複する値を削除するプロセスが含まれます これは ディスク領域を節約し パフォーマンスを改善するための重要な方法です ( この冊子の18ページを参照してください ) このプロセスは メンテナンス要件がなく完全に透過的です 通常 SAP 環境では索引は表サイズの約 50~60% データベース全体の30~40% になります そのため 合計サイズを 20~30% 削減できます 索引の場合は 最大 75% まで削減が可能です これは 検討する価値があります たとえば 10TBのデータベースでは最高 3TBまで削減できることになります これはディスク容量 バックアップ アップデートおよびリカバリ すべての点で大きなメリットがあります 短時間での実装と明らかなメリット Oracleの索引キー圧縮の認定と有用性について SAP からアドバイスを受けた後 2008 年 2 月から ERP BIおよび CRMシステムの最も大きいデータベースのパイロット プロジェクトが開始されました 通常 SAPは新しい機能を初めて使用する顧客には パイロット プロジェクトの手順を指定します 100 以上の顧客からの確実な経験をもとに SAPはGAステータス ( 一般出荷 ) としています Bauerfeindのパイロット プロジェクト中も ウォルドルフにあるOracle/SAP 開発チームと電話や電子メールで直接連絡 ( 電話や電子メール ) を取り合いました Oracle/ SAP 開発チームは 顧客固有の要件とシステム ランドスケープに簡単に適用できる 事前定義されたスクリプトを提供しました オラクルは レポートの最適化と確認を支援しましたが 現場ではそれ以上のアドバイスやサービスは必要ありませんでした Alexander Käferlein 氏によれば 有用なヒントやリアルタイムで提供される迅速な応答など Oracleは最高のサポートを提供しました このプロジェクトは わずか 2 週間で問題なく完了しました プロジェクトを通し 費やした労力は得られたメリットと比較して最小限でした 結果 2008 年の開始時点 :SAP ERPの最大データベースは約 2TB 3 4 個のCPUが割り当てられており リカバリ時間は 8 時間でした

47 47 圧縮に適した約 400 個の 索引候補 を選択し スクリプトを起動すると 平均して約 40~50% 索引を圧縮できました これには データベースを 2TBから1.7TB つまり 300GB=15% 縮小する ( 表を参照 ) 効果がありました DBTABLOG(120GB) やCOEP(47GB) などの表は 索引圧縮の良い例です DBTABLOGの索引部分は 23GB/17GBから15GB/6GBに縮小しました これは 35~65% の削減になります COEPの場合 索引は 8GB/6GBから 2GB/1GBに削減されました これは 75~ 84% の削減になります さらに AIX LPAR 仮想化のCPUロードは 2 分の1CPU に軽減されました これらの有意義な結果は 日常業務 システム全体の管理容易性 応答時間 領域要件 バックアップとリカバリにかかる時間などでプラスの効果がありました 最も恩恵を受けたのは システムに接続された支社や工場の日常的な国際間のビジネスです Oracleとの将来 Oracle 索引キー圧縮を使用し 確かな経験と実益を短時間で手に入れた Alexander Käferleinのチームは 特にSAP BIと2008 年末に予定していた SAPのUnicode への変換で このテクノロジーをより大規模に使用することを決定しました 2009 年 Bauerfeindではシステム全体の高可用性をさらに改善するために 別の革新的なOracle Databaseオプションを導入する計画を立てています それは Oracle RACです Oracle Databaseのファースト クラスの機能 品質 サポートで 計画している Oracle RACの稼動も必ず成功することでしょう 例 SAP ERP 索引圧縮前圧縮後削減率 DBTABLOG COEP A 23GB 15GB 35% B 17GB 6GB 65% A 8GB 2GB 75% B 6GB 1GB 84%

48 48 データ セグメント圧縮によるストレージ コストの削減 信頼性を重視し Oracle9i Database を採用 Capcom Co., Ltd. 水野和人氏株式会社カプコン IT 統括情報システム室 SAP BW 活用による データ量の増大解決のためにデータ セグメント圧縮により 平均 40% 削減家庭用ゲームソフトの開発 販売を中核事業として成長を続ける株式会社カプコンでは 基幹システムとして SAP R/3を導入 さらに SAP BWを活用し さまざまなデータを分析し経営に反映させている そして それらのシステムを支えるデータベースとして Oracle9i Databaseを採用している 今回は Oracle9i Database 採用の経緯から SAP BW 利用時に必ず直面するであろう課題と その解決手段 さらに今後の展望などについて 同社 IT 統括情報システム室システムインフラチーム長水野和人氏にお話を伺った 信頼性重視でOracle9i Databaseを採用カプコンでは基幹システムとして SAP R/3を採用し Windowsサーバ上で利用している SAP R/3 のデータベースとして採用しているのが Oracle9i Databaseだ 最近の流れとして SAP R/3を Windows 上で使うケースでは データベースは SQL Serverを採用するケースも少なくない カプコンが Oracle Databaseを採用する理由について 水野氏は次のように語る 私自身データベースの選択にはこだわりを持っています それは 基幹システムのような信頼性が求められるシステムについては データベースにも相応の性能が必要だということです SAP R/3の場合も データベースにはいくつかの選択肢がありますが 信頼性や細かな設定が可能なチューニング性などを考えると 安心できるのは Oracle9i Databaseということになりますね カプコンでは以前 基幹システムを旧システムから新システムへ移行した際に データベースを Oracle DatabaseからSQL Serverへ移行することも検討したという 社内から管理が楽だという意見があったためである しかし 基幹システムという用途を考えた場合 やはり前述の通り データベースにもサーバと同様の信頼性を求めることとなり 最終的にはOracle Databaseを利用し続けることを選択した 当時の経緯について 水野氏は次のように振り返る 確かに一般的には WindowsサーバにはSQL Serverという図式があるように思います 基幹システム (UNIXサーバ) にはOracle Database 基幹ほどの信頼性が必要ではないシステム (Windowsサーバ) にはSQL Server という意味も持っているのではないでしょうか しかし 昨今はWindowsサーバの信頼性 可用性が向上したことから 基幹システムを Windowsサーバで構築することが当たり前になりました 基幹システムであっても プラットフォームが Windowsということで データベースに SQL Serverを選んでしまいがちですが これはUNIXとWindowsの役割分担がはっきりしていた過去の記憶を引きずっているように思えます プラットフォームが問題なのではなく その用途が問題なのです そこで たとえ WindowsサーバであってもSAP R/3 つまり基幹システムを動かす以上は データベースとしての信頼性を重視し Oracle Database の利用を継続する決断をしたというわけです

49 カプコンの BW データ圧縮 49 SAP BW 運用でストレージ容量が課題にカプコンではビジネスインテリジェンスツールとして SAP BWを2003 年に導入し 主に管理会計 経営管理などに活用しているほか シェアや人気商品の地域差の分析などマーケティングにも活用している こちらもWindowsサーバ上で動いており データベースとして Oracle9i Databaseを採用しているが 利用を進めるに従い データのストレージ容量が問題となってきた もちろん SAP BWのようなビジネスインテリジェンスツールを使う以上 分析対象のデータは増大し いつかストレージ容量の問題が出てくることは当初からわかっていた そのため 導入時点では 1 年後をめどにストレージ容量を見直すことを織り込み まずは 250GBのストレージ領域をSAP BW 用に確保していた そして導入から1 年が経った頃 当初の予想どおりのデータ増大に対応するため ストレージ増設を検討することとなった しかし カプコンはストレージの増設を選択しなかった 確かに以前にくらべ 最近はストレージ価格が下落し ずいぶん導入しやすくなりました でも だからと言ってストレージを増設すればそれで良いのだろうかという疑念が残りました やはり基幹システムで利用するデータである以上 データのバックアップは欠かせません つまり ストレージが増え データがさらに増えると そうした運用フェーズでの手間 バックアップ用テープのコストは間違いなく増大します いくら導入コストが安くなったとはいえ ストレージの増設は長い目で見て慎重に行うべきであろうという結論に達したのです データ増大に対処するために データ セグメント圧縮 機能を利用それではカプコンは一体どのようにしてデータ増大の問題を解決したのだろうか 実はカプコンがストレージ増設を検討していた頃 日本オラクルから Oracle9i Databaseの機能の一つである データ セグメント圧縮 いわゆるデータ圧縮を行ってはどうかということが提案されていた それはデータを圧縮することで データ容量を減らし ストレージをより効率的に利用することで データ増大に対応しようという ストレージの増設とはまったく異なるアプローチによる解決手法であった 水野氏は期待と不安 入り交じる気持ちでこの提案を聞いたという 私の固定観念かもしれませんが 圧縮 を行うと データ容量という部分では当然メリットがあるものの CPUに負荷をかけることになり レスポンスが低下するだろうと思っていたのです しかし詳しい説明を聞くと Oracle9i Databaseのデータ セグメント圧縮機能はOracle9i Database 内で完結するためCPUに負荷をかけることがなく 使い方によってはレスポンスの向上も見込めるということでした この話を聞いて 技術者としてとても好奇心がくすぐられましたね その後カプコン社内でもデータ圧縮の採用が認可され 実際に圧縮作業が行われることとなった 圧縮作業を行う上でポイントになってくるのは どのデータを どの程度圧縮するかということだ この部分のチューニング具合で レスポンスに差が出てくる そこで 圧縮の基本的な部分については日本オラクルが検証を行い 開発サーバ 評価サーバ 本番サーバの3 台を用意し さまざまな圧縮パターンを試してみることとなった これらの作業についてはサーバメーカーの日本 HPからのサポートもあり 非常にスムーズに進み 最終的には1ヵ月程度で運用を開始することができた データ圧縮の結果 データ容量は約 60% にさまざまな検証を行った結果 カプコンでの SAP BW 運用には 上位 5テーブルのみ圧縮するという対応がもっとも効果的であることがわかった そして その圧縮により 全体のデータ容量は約 60% となり 40% 分のストレージが開放されたのだ 実際はこれ以上に圧縮が可能なデータもあったものの 運用上あまり意味のない部分の圧縮は見送られた そして現在 さすがに導入から4 年が経ったこともあり 現在のストレージ容量は400GBまで増加している しかし 導入後のデータ増加の推移を見る限り 仮にデータ圧縮を行っていなかったとしたら 現在テラバイトクラスのストレージが必要になっていたことも予想されるそうだ こうした結果を踏まえ水野氏は圧縮機能の導入について このように感じている 結果的にストレージの増設を行ったものの 400GBで済んでいるということは データ圧縮が非常に効果的だったということだと思います またユーザからも特にレスポンスが低下したという話しもなく 非常に満足しています SAP Oracle Databaseのバージョンアップを予定カプコンでは現在 SAP R3からSAP ECC SAP BWからSAP BI 7.0へのバージョンアップを予定している さらに同じタイミングでデータベースも現行の Oracle9i DatabaseからOracle Database 10gへ

50 50 移行する予定だ そして まずはこれらの移行を滞りなく完了させることと 移行後もこれまで同様にデータ圧縮を行っていくことが 現在もっとも重要なミッションとなっている またこれとは別に 何らかのカタチでディザスタリカバリ環境を構築していきたいとも考えているそうだ 今後日本オラクルに期待することとして 水野氏は次のように述べている 今回のデータ セグメント圧縮機能もそうですが Oracle Databaseの良さのひとつに したい と思った時に 多くの場合それを実現する機能が用意されているという点があります 手さえ動かせば いかようにもチューニングすることができるのです ただし そうした機能がなかなか紹介されていないように感じます ぜひそうした情報を 提案や 宣伝といったカタチで提供してもらえればと思います また 経営層にも理解しやすい 例えば 管理が楽になる というだけでなく その結果管理コストがこれだけ削減できるといったところまで踏み込んだ情報であると嬉しいですね

51 51

52 52 SGIプラットフォームは 私たちにとって技術的なITアプリケーションに最高のプラットフォームであることがすでに証明されています 独自のプラットフォームと比較し大量のデータが集中する環境でも 高速な実行と高い安定性を持つこのプラットフォームは 私たちのビジネス分野の非常に複雑な要件を満たす柔軟さがあります NORBERT DIEHL MTU Aero EnginesのITテクノロジー部門の責任者 SGI と SAP on Oracle Database により MTU Aero Engines 向けに最適化された IT インフラストラクチャは 変化し成長し続ける世界市場の要件を満たす MTU Aero Engines 10 年以上前から MTU Aero Enginesは複雑な技術面のIT 業務に SGI サーバーを使用していました 最近 MTUは製造計画に使用している SAP コンポーネントと SAP Advanced Planning & Optimization-SAP APOを既存のLinux OSベースの SGI Altix サーバー プラットフォームに移行することで データベース環境をさらに最適化しました その結果 SAP APOに必要とされる高リソース要件を満たしたまま これまでのアーキテクチャと比較して 20% 以上の運用コストを削減できました 現在 MTUは SGIの潜在能力をさらに SAPソリューションに活用するために SGI Altixプラットフォームに追加のSAPコンポーネントを統合することを計画しています MTUは データベース システムに Oracle Database 10gを使用しています それは 特に BWの要件に必要な安定性とパフォーマンスが不可欠だからです エンタープライズ マーケットの要件を満たす科学分野の高パフォーマンスな計算用に設計された SGI Altixサーバーは MTUなどの企業顧客からのニーズが高くその配置が増えています 私たちは国際的な展開をしています SGIプラットフォームにより 変化し成長し続ける世界市場の要求に応える ITインフラストラクチャを採用できます と MTU の技術部門 ITマネージャの Norbert Diehl 氏は説明しています 私たちの ITシステムは 毎日膨大な数のトランザクション を処理し 複雑なモニタリング レポート および分析作業ができる能力とスケーラビリティが要求されます SGIは 私たちのように国際的な企業の要件を満たすために必要なパフォーマンスを与えてくれます 段階的な移行 MTUは 2005 年中頃にSAP APOプロジェクトに着手しました プロジェクトの管理に MTU ITテクノロジー サービス プロバイダの T-Systems SGIのエキスパートが集められチームが結成されました このチームの共同作業により わずか 6か月で新しいシステムの設計と実装が完了しました プロジェクトの最初の段階で チームはすでに MTUで使用されていた 3 台のSGI Altix 3450サーバーをアップグレードしました 新しい S A Pアプリケーション用にサーバーを最適化するための構成は 1 台目のサーバーをSAP APOコンポーネントのライブ操作に使用し 2 台目を品質管理と開発用に変更し 3 台目を並行で運用される ホット スタンバイ システムとして配置しました 比較的新しいハードウェア プラットフォームをリサイクルすることで これらの寿命を4~5 年延ばすことができました と Norbert Diehl 氏は述べています このリサイクルだけで 15~30% のコスト削減になりました

53 MTU Aero Engines における SGI と SAP on Oracle 53 SGI Altix 3450サーバーでの Oracle Databaseのテストは問題なく完了し SAP APOコンポーネントのインストールも完了しました さらにテストされ本番システムと並行で運用が開始されました 次に このチームはシステムの高可用性機能を設定およびテストし ユーザー数を限定して新しい ITインフラストラクチャにアクセスできるようにしました 2006 年 11 月には SAP APOの全機能が使用可能になりました 現在 MTUでは約 150 人の従業員がSGI Altix 450サーバーの SAP APOを使用しています テスト段階のすばらしい結果 S G Iコンピュータ テクノロジーがパフォーマンスと可用性の最大化で力を発揮するのは 非常に大規模な SAP on Oracle Databaseであることは テスト段階ですぐに明らかになりました SGIプラットフォームは 私たちにとって技術的な ITアプリケーションに最高のプラットフォームであることがすでに証明されています と Diehl 氏は述べています 独自のプラットフォームと比較し大量のデータが集中する環境でも 高速な実行と高い安定性を持つこのプラットフォームは 私たちのビジネス分野の非常に複雑な要件を満たす柔軟さがあります SAPと SGIを組み合せたソリューションは 運用開始からすばらしい結果を出しました 非常に高速なデータ転送の推進 SGI Altixサーバーは 高パフォーマンス NUMAflex 接続と Itanium プロセッサで実行され グローバルに共有されているメモリー アーキテクチャとオープン ソースのLinuxオペレーティング システムの組合せです NUMAflexは ノード間でシステム メモリーをグローバルに共有できる独自な設計です その結果 データ レコード は各プロセッサで処理されないため 小さいグラグメントに分割する必要がありません かわりに 1つの均一なアドレス可能メモリー領域があり システム環境内のすべてのプロセッサは この領域で一緒にデータを処理します これは 従来のクラスタより 200 倍高速にデータを転送できることを意味します これにより 非常に複雑な計算問題でもレコード タイムで解決できます このグローバルな共有メモリーというアプローチにより SGI Altixプラットフォームはアプリケーションに高レベルなパフォーマンス スケーラビリティ 可用性を提供しつつ リアルタイムで複雑なデータ レコードにアクセスできます そのため レコードの管理とメンテナンスが容易になりました また グローバルにアクセス可能なメモリーは 企業の総所有コスト (TCO) の削減や 投資利益率 (ROI) の最大化を可能にしました SGIテクノロジーとスケーラビリティの高い Linuxオペレーティング システムを組み合せることで さらにコストを削減できます オープン ソースの Linuxプラットフォームの使用は 既存のITリソースの統合をより効率的にし 新しいテクノロジーの実装をより簡単にします 企業は変化するビジネス要件に応じて IT 戦略を柔軟に調整できます SAP on Oracle Databaseの良好なパートナーシップ動的に拡張できる計算プラットフォームが必要な世界中のSAPの企業顧客は MTUと同様に SGIサーバーを選択しています SGIとSAPは ともにアップグレードが簡単で強力かつ可用性の高いテクノロジーをユーザーに提供します この 2つの企業は包括的なテクノロジーを提供しています このテクノロジーは顧客が変化する市場の要求に対応し より収益性の高い より高速で組織だった作業ができるようにします Altixサーバーは 企業顧客に対し SAP on Oracle Database システムのパフォーマンス 高可用性 および安定性を確保し 動的に拡張できる強力なコンピュータを提供します Norbert Diehl MTU Aero EnginesのITテクノロジー部門の責任者

54 54 SGIとSAPは ともにオープン ソース テクノロジーに対応しています オープン ソース テクノロジーは クローズドなオペレーティング システムと比較すると ITコストを直接的 間接的に大幅に削減できます SGIは SAP LinuxLabの長年のメンバーです SAP LinuxLabでは SAPはパートナーとの共同作業で 企業顧客に Linuxの最高のパフォーマンスと機能を提供します SAP 認定により SGI Altix 企業顧客はLinux OSベースのサーバー ラインのメリットを活用し 最も高度なSAPシステム ランドスケープを運用することもできます SGIは SAP LinuxLabの重要なハードウェア パートナーです と SAP LinuxLabの開発マネージャである Helge Deller 氏は述べています Altixサーバーは 企業顧客に対し SAPシステムのパフォーマンス 高可用性 および安定性を確保し 動的に拡張できる強力なコンピュータを提供します Linuxを選択したMTU MTUは オープン ソース テクノロジーのメリットをさらに活用することを計画しています 技術的なアプリケーションの移行が成功した結果 MTUは他の業務 ITシステムのハードウェア プラットフォームも Linux OSベースに変更し 他の SAPコンポーネントを SGI Altixサーバーに移行することを計画しています 私たちの最初の大きなSAP 移行プロジェクトにより Linuxを企業の市場に展開できることがわかりました と MTUのITサービス テクノロジー (FIS) の Friedemann Ost 博士は述べています さらに博士は SGIはLinuxの標準プラットフォームを使用し 私たちのSAPプロセスを価値連鎖全体に統合できるようにしてくれました と付け加えました これにより 企業環境に高パフォーマンス システムを提供し エンジニアリングと企業の分野間でノウハウを統合できます そして 私たちのシステム ランドスケープの品質を大幅に改善できます MTU Aero Engines ドイツのミュンヘンに本社がある MTU Aero Enginesは あらゆる推進力と出力カテゴリの商業用および軍事用の航空エンジンと定置式産業用ガス タービンを開発 製造 販売しています また MTUは軍事分野でも大きな役割を果たしています Bundeswehrの主要産業パートナーであるドイツ国軍に対して ドイツ防衛軍が操縦する航空機のほぼ全機種の航空エンジンを供給しています MTUは すべての主要地域と市場に支社を展開する国際的な企業で 世界中で6,700 人の従業員が働いています Webサイトは Linux OS ベースの SAP-APO アーキテクチャ

55 55 私たちの最大の挑戦は 成長する ERPデータとシステムに対応することでした 私たちには パフォーマンスの改善も必要でしたが サーバーの統合も必要でした そのため データ センターを再構築できませんでした HP- UX 11iを実行するHP Integrityプラットフォームにより 大規模な移行や業務を停止することなくこれら両方を実 現できました PAUL BRODY システム アナリスト Chevron Corporation 国際的なエネルギー業界のリーダー企業が急速な成長に対応して ERP を投入 米国で業界 2 番目のエネルギー企業は 管理コストを削減しつつ Oracle Database 上で稼動する SAP プラットフォームのパフォーマンスと容量を 3 倍にした Chevron Corporation 業種 : 石油とガス 大規模石油企業 - 巨大データベース Chevron Corporation( は 米国で業界 2 番目の総合エネルギー企業で 世界でも最大規模の企業の1 社です 本社をカリフォルニアのサン ラモンに置く Chevronは 59,000 人以上の従業員が働き 180ヶ国で事業を展開しています 急速に成長しているエネルギー企業のリーダー Chevronは 石油と天然ガス業界のあらゆる分野でその業務をグローバルに展開しています 調査および製造業務の アップストリーム と精製 マーケティングおよび輸送業務の ダウンストリーム のデータは莫大な量になります 石油業界には ITが不可欠です と Chevronのシステム アナリストの Paul Brody 氏は述べています Chevronエンタープライズ全体のあらゆる情報を統合するのは SAP R/ 3 複数のマルチテラバイト Oracle Database および 4テラバイトのビジネス ウェアハウスをベースにしたグローバルな ERPシステムです HPサービスから積極的なサポートを受け 活力があるインフラストラクチャは パーセントの可用性を維持し 数千のユーザーはビジネス クリティカルな情報にいつでも簡単にアクセスできます テラバイト単位の成長 Chevronは 統合や買収などによって グローバルな拡大とビジネスの急速な成長路線を進めてきました 拡大は アプリケーションとユーザーの急速な増加とともに 分析 管理するデータ ストリームも増大させることになりました これらのデータのソースは 自動化されたウェル モニター 耐震解析 販売拠点のガス ステーション システムなどです この肥大化に取り組み 将来の肥大化に対応するERP インフラストラクチャの拡張を主導するBrody 氏は 私たちのOracleリポジトリは それぞれ毎年 1テラバイト以上増加します と説明しています Chevronは 可能なかぎり最も混乱が少なく最もコスト効率の高い方法で より高いパフォーマンスとより多くの容量を達成したいと考えています 目標 : より柔軟でコスト効率の高いERP インフラストラクチャの実装は 世界の急速な発展 統合 買収に対応できるようにします アプローチ : 複数拠点にあった50のSAPインスタンスをひとつのデータセンター上のHP Integrity サーバー (HP- UX 11i v2 Oracle DB) に統合 IT の改善点 : 新しいサーバーにより ERP インフラストラクチャのパフォーマンスと容量が 3 倍になる 新しい設置面積はスペースが 3 分の 2 になる SLA を超える一貫した % の可用性 ビジネス上のメリット : ビジネス インテリジェンスに対する より高速な適用とアクセスにより 生産性と意思決定が改善される よりスケーラブルでありながら合理化されたプラットフォームは 企業成長をサポートし 統合や買収によるデータの統合を容易にする サーバー統合により 管理 運用 およびフロアスペースのコストが削減でき より戦略的な指導力で人員とリソースを移動できる

56 56 Chevron における SAP on Oracle Database と HP 処理のために夜中まで仕事をするのが当たり前でした 現在は 毎月通常の勤務時間内に処理を完了することができます 長年に渡ってHPは偉大なパートナーです HPサービスとは密接な関係を保っています 毎月 ミーティングで環境の変化を再検討しています Steve Wilson 技術設計者 Chevron Corporation グローバルなSAPインスタンスの統合 ChevronはHPと協働し HP-UX 11i v2オペレーティング システムを実行するHP Integrityサーバーに グローバルな ERPオペレーションを統合しました 統合サーバーにより 物理的にホスティングしている世界中のシステムを単一のデータ センターと共通プラットフォームに統合できました と Brody 氏は述べています 新しいプラットフォームは マルチテラバイトの Oracle DatabaseとERP 用の50 個以上のSAPインスタンスだけでなく Chevronの中核機能である財務 HR 開発 品質管理などをホスティングします H Pのミッション クリティカルとプロアクティブ サービスを採用したことで ChevronのITチームは一貫して ERP インフラストラクチャで パーセントの可用性を達成しました 3 倍になったパフォーマンス Brody 氏は 統合プラットフォームにより 即座にパフォーマンスが 3 倍になりました と述べています 3 時間かかっていた作業が1 時間で終わります 時には それより短い時間で終わることもあります より高速にビジネス インテリジェンスを検索 共有 使用できることにより 世界中のChevronの従業員は 自身の才能 時間および企業の資産をより有効に活用できるようなりました たとえば会計グループは これまで月次 重要なのはプロセッサの速度だけではありません 高速なバス I/O 速度 および低いメモリー待機時間などを含むHPが提供するパッケージ全体です と Chevronの ERPプロジェクトで技術設計を担当する Steve Wilson 氏は説明しています 私たちは 大きな I/Oパイプと高速なバスが必要な巨大データベースを運用しているのです Oracleは 統合サーバーでより高速に動作します また H P はより高いパフォーマンスとより低いメモリー待機時間を引き続き提供してくれます と Wilson 氏は続けて述べています ウェアハウスをテラバイトに拡張したため Dual-Core Intel Itanium 2プロセッサが搭載されたこの統合サーバーは 私たちのハイエンドに適しています より多くの作業を - より少ないコストで多数のサーバーを統合しプラットフォームを簡素化することは 管理システムを簡単にしてコスト削減も実現します 私たちは エンド ユーザーが経験するパフォーマンスを改善し信頼性を向上させ 多数の追加システムをサポートしましたが これによってコストが増えることはありませんでした と Brody 氏は述べています 私たちのサポート チームは 数と設備投資の均衡を保ち続けることができます さらに Wilson 氏は次のように付け加えています 新しい統合サーバーは 古いシステムの設置面積の3 分の1に収まりました 既存のスペースを より有効活用できます 収支の面で Brody 氏は この新しい ITインフラストラクチャを運用するために より多くの経費を会社に要求する必要はありませんでした と説明しました

57 % の可用性 Chevronでは ERPアプリケーションとデータのパフォーマンスと管理容易性を向上させつつ これらのビジネス クリティカルなリソースの確実なセキュリティと可用性も必要でした 2 時間で統合システムに移行 HPおよびSAPのエンジニアとの共同作業により ChevronのITチームは グローバルな ERP 環境をPA- RISCベースの HP 9000サーバーから64ビットの HP Integrityプラットフォームに転送しました これらは 大きく重要な資産です これらは 私たちの企業全体の情報を統合しています 停止させるわけにはいきません と Brody 氏は述べています ChevronのITチームが HP-UX 11i v2 環境に組み込まれている信頼性と効率性を活用し HP OpenView 管理ソフトウェアと HP Mission Critical and Proactive Servicesを採用したことで SLAの可用性は常に パーセントを達成しています HPは HP-UX 11i UNIX オペレーティング環境のデータ互換性と共通リリースを HP 9000と統合プラットフォームの両方に提供するため 統合サーバーへの転送ではデータ移行が必要ありませんでした HP-UX 11i v2と HP Integrityサーバーのプラットフォームにより Chevronのグローバルな ERPインフラストラクチャは 急速に増大するデータおよび操作にコスト効率良く対応できます 私たちは HPサービスと密接な関係を保っています 私たちは毎月ミーティングで環境の変化を再検討しています と Wilson 氏は説明しています HPは セキュリティとシステム管理を自動化するツールを使用して HP-UX 11iオペレーティング システムの拡張を続けています たとえば HP-UXのIPフィルタ機能を多数使用して サーバーに接続できるポート番号とIPアドレスを制限しました 私たちは HP OpenView 管理ソフトウェアの周りに モニタリング インフラストラクチャを構築しました Wilson 氏は続けて 次のように説明しています これは 事前定義した測定基準を外れて正しく設定されていないコンポーネントや機能があった場合に SAPシステム管理者に警告を出します OpenViewは エンド ユーザーに影響を与える前に 何度も対応すべき問題に関する警告を出してくれました また Wilson 氏は HPによって Chevron 固有のスクリプトとプロセスが HP OpenViewシステムに組み込まれたことを付け加えています プライマリ アプリケーション Enterprise Resource Planning プライマリ ハードウェア HP Integrity rx4640サーバープライマリ ソフトウェア HP-UX 11i v2オペレーティング システム HP OpenView v7.1 管理ソリューション HP OpenView Storage Area Manager SAP R/3 Oracle Database バージョン , および サービス HPビジネス インフラストラクチャ サポート HP ミッション クリティカルおよびプロアクティブ サービス Brody 氏は このプロセスは 週末の2 時間で終わり 業務の停止時間も発生しませんでした と述べています Brody 氏は データのエクスポートやコードの書直しは必要ありませんでした そして トランジションは ユーザーに透過的でした ユーザーが気付いたのは 処理速度が3 倍になったことだけです と続けて説明しています

58 58 Chevron における SAP on Oracle Database と HP 生産性コラボレーション ChevronのITチームは HP との密接な作業で 来るべきもの の傾向を理解し 方向付けを行いました Chevron は Integrityサーバーにインストールされた OracleおよびSAPのソフトウェアのベータテストに参加し 人員 プロセス テクノロジーなどの ITリソースの生産性を向上する新しい方法について HPエンジニアと HPサービス コンサルタントと協力して取り組んでいます 10 年前から 私たちは HPが製造した最大のサーバーを使用し始めました と Wilson 氏は説明しています 現在は 多数のユーザーのサポートに より小型の Integrityシステムを稼動しています これは十分強力です HPの製品とサービスは 常に原価目標を含めた私たちの要件の先を見通しています SAP 仮想パーティションまた Wilson 氏はHP-UX 11iベースの Integrityサーバーが 要件の変更に対応できる各種のサイズで展開されていることにも満足しています ITの要件は いつも予測できるわけではありません 企業の買収が突然行われかもしれません そして唐突に 他社の全データをビジネス ウェアハウスに入れる必要が生じることもあります それぞれのIntegrityサーバーはモジュラー環境で 様々な方法で構成できます Wilson 氏は続けて次のように説明しています メモリー ディスク ドライブ およびCPUは すべてシステム間で簡単に交換できます HP-UX 11i v2の仮想化機能については 複数のSAPアプリケーションの専用環境を コスト効率良くすべて単一のサーバー上で維持できます と Wilson 氏は付け加えました 成長の後押し Chevronにとっては ビジネスの新たなニーズに対応するために 効率的かつ効果的にITを拡大することが重要でした HPとHP のIntegrityサーバーとの協働で 私たちはコスト面での競争力を維持しつつ 拡大を達成しました 私たちは 単一のサーバーの容量の50% を使用して 複数のSAPインスタンスと Oracle Databaseを稼働させています このため 成長に対応できる余地は十分にあります と Wilson 氏は説明しています さらに Integrityアーキテクチャは 他の 64ビット x86 ベースのプラットフォームで達成できる限界をはるかに超えた拡張が可能です と Wilson 氏は付け加えています Chevronは ERP 環境を業務と同様に動的なビジネス資産に変換させました 順応性があるインフラストラクチャは 従来より大きなデータ ストリームに合せて円滑にコスト効率良く対応できます Brody 氏は次のように述べて締めくくりました 将来の展望として まだこれから大きな成長を見込んでいます この Integrityプラットフォームと HPが作り出す他の資産は 将来の成長に役立ち 楽にコスト管理をしながら必要な信頼性とパフォーマンスを提供するだろうと確信しています

59 All4it Group 59 All4it は Oracle Database 上の SAP ERP で得られるソリューションに提案の焦点を当てた 戦略と変換 :All4it の戦略的 IT 有効化のプロフェッショナル達は 企業の投資を最適化し性能を変換して そこからより大きなビジネス価値を得ることを支援しました All4itは数人のシニア コンサルタントにより 1997 年に創業され コンサルティング テクノロジー およびアウトソーシングなど SAP 用 Oracle Databaseを中心とした高付加価値テクノロジーの顧問サービスを提供しています 企業レベルの大規模プロジェクトを通じて 現在のAll4it は物理的インフラストラクチャから情報システムのビジネス境界まで 一連の垂直型サービスを提供しています 特に All4itは巨大データベースとインフラストラクチャ SAPを使用するプロジェクトをサポートし 顧客のコア ビジネスの強化につながるこの市場に注目してきました All4itは実際 SAP ERPおよび BIサポートのルールに準拠して 多くの ECC/Oracle Database 移行や 新しいOracle 機能 (RAC パーティション化 Unicodeマイグレーション 環境の分割 / 結合 キー索引圧縮 フラッシュバック Data Guard Database Vault) の主要な実装を成功させています Oracle DatabaseやSAPとAll4itのパートナーシップには歴史があります まず All4itの従業員たちの原点がスタートでした 次に Oracleが提供するテクノロジーを活用して 恒常的に顧客のニーズにもっと対応したいという気持ちに引き継がれていきました 最近では スポーツ用品の流通リーダーである Decathlonは 2007 年の革新によりSAP 賞を受賞しました All4itとの共同作業で行われたECC5.0の移行に対する受賞です 今日 戦略パートナーの一環として Oracleは エンドツーエンド プロジェクトの管理能力が要求される際に All4itを選択します All4itは現実に Oracle for SAP Organizationのプログラムに投資しています Global Technology CenterのRACベータ テスト プログラムは 永続的なベスト プラクティスとされています 昨年秋のイベントである Palais des Congres (FSC- Future IT) にFujitsu-Siemensが参加しましたが All4itはRAC 10g/SAP ECC6を実装して FlexFrame for SAP Solutionの機能をデモンストレーションしました 要約すると All4itの成功は次の主要な推進力の上に築かれています - 顧客の調査と設計のアップストリーム フェーズの問題を理解している - プロジェクトのモニタリングと管理 - 最高のテクノロジー 連合 実装 スキルの提案 - IBM HPなど 製造業者が提供するテクノロジーの統合予算の軽減を目的とした操作のアウトソーシングによる最適化の提案 All4it Group 業種 : コンサルティングとアウトソーシング 場所 : ルクセンブルグ ベルギー フランス 年間収益 : 1 億 2,500 万ユーロ 従業員 : 135 人

60 60 Oracle Advanced Customer Services for SAP SAP 環境向けのデータベース サービス Oracle DatabaseとSAP 中規模からハイエンドまでのすべての SAP 顧客の3 分の 2 以上は 信頼して Oracle Databaseにデータを預けています 世界中の10,000 箇所に散らばった約 200 万人の登録ユーザーは Oracle Databaseがもたらす SAP 環境での最高のテクノロジーとパフォーマンスに期待を寄せています この卓越したパフォーマンス レベルは SAPと Oracle Databaseの長年にわたる強力なパートナーシップの必然的な結果です しかし SAPとOracle Databaseの提携は データベース テクノロジーの統合のみではありません 顧客のサポートと満足度は 現在も続くパートナーシップから生まれる具体的な日々のメリットです この特別なレベルの顧客サポートが実現したのは SAP が恒常的なOracleサポート スタッフを要求した結果です このグループには 開発レベル サポート キューが配属され 広範囲なアクティビティやセミクリティカルからクリティカルな 本番停止 状況まで 各種の問題に対し即時に支援を提供します SAPサポートと Oracleのサービス グループは SAPに的を絞ったこの顧客サポート チームをコーディネイトしスタッフを配属するために作成されました ウォルドルフ ( ドイツ ) パロ アルト ( 米国 ) 東京( 日本 ) を拠点にしたワールドワイドなサービス グループで あらゆる角度から SAP 運用を支援します より具体的な作業の範囲は 肥大化するデータ量の管理 パフォーマンス最適化 高可用性ソリューションの設定 安全なインタフェースを介した SAPシステムと他の Oracle Database 間のデータ交換などです SAPを使用した統合サポートの他に 多くの顧客は Oracleサポートを直接依頼することを選択し SAP- Oracle 構成環境からより高いパフォーマンスを得るために役立てます これらのサービスは OracleのAdvanced Customer Services(ACS) 組織から利用できます Advanced Customer Servicesのエキスパートは 世界中の顧客固有のサービスを直接提供して すべての Oracleシステムのパフォーマンスを最大に引き出し 生産性を向上させます 最近 Oracle Advanced Customer Servicesは SAP 環境でOracle Databaseを使用する顧客向けに 固有のサービスのポートフォリオを形式化しました SAPは Oracleとパートナーシップを組んで作業することで 品質システムのサポートを提供します しかし 私たちの共通の顧客の多くは Oracleの性能を最大限に活用するためにデータベース環境に対するより高いレベルのサポートを求めています 私たちの年間サービスは サポートを次のレベルに押し上げます と Oracle Advanced Customer Servicesの副社長である Larry Abramson 氏は説明しています このサービスは 年間の運用サポート 対象をカスタマイズしたエンゲージメント オンサイトのテクニカル スキル ワークショップという 3つのレベルで提供されます SAP 環境向けのAdvanced Customer Services Database Servicesは すべて Oracleサポートのエキスパートによって提供されます このエキスパート達は 全体的なシステムのパフォーマンス 安定性およびリカバリの可能性に寄与するオラクル テクノロジーを最大限に利用する力があります Oracle Advanced Customer ServicesはSAP と協力して 20 年以上 Oracle Databaseで運用される SAPソリューションを提供してきたパートナーシップの経験を活用します 顧客のビジネスにカスタマイズされたOracle with SAP のエキスパート ガイド SAP 環境のデータベース サービスは 3つのレベルの年間サービスを提供していますが これは 顧客固有の要件に合ったサービスと組み合せることができます

61 Oracle Advanced Customer Services for SAP 61 Advanced Support Assistance - これは 単一の連絡先を通じてサービス要求を円滑に促進します 担当の Service Delivery Manager(SDM) は 有意義なアクション計画に沿った正しい人員配置と組織により より効率的で効果的に問題を解決します Business Critical Assistance - 積極的なアドバイスや顧客固有の運用やプロジェクトに合せてカスタマイズした支援と サービス要求のソリューションを組み合せます 担当の SDMは 顧客のバックグラウンド機能と IT 目標を開発するエンジニアのチームをコーディネイトし 各プロジェクトが成功するように支援します Solution Support Center - 最も包括的なサービスを提供します 固有の環境 運用やプロジェクトをよく理解したエンジニアだけのチームが担当します この専門的なエンジニアのチームは 重要なサービス要求と評価や根本原因の分析など 一連の積極的なサービスの支援を提供します 専用のアクセス ホットラインを使用します 選択したレベルに応じて Oracle Advanced Customer は SAPに習熟したService Delivery Manager (SDM) の専門的なエキスパートを派遣し Oracleサポートの中心として役立つサポート プロセスを提供します SDMは 顧客と一緒に主要ビジネス要件の識別 サポート プロセスの調整 年間サポート計画 共同計画情報の文書化を含めた年間サポート計画を作成すると同時に 既存のSAPサポート モデル機能を組み込みます 担当 SDMの役割の1つは high または very high (SAPの重大度レベル ) 問題解決アクティビティおよびエスカレーションを処理することです また SDMはサービス要求に複数の関連インシデントがある場合や共通の問題や現象に結び付ける動作パターンがある場合 または個別の問題の標準エスカレーション プロセスが顧客固有のビジネス ニーズに対応しない場合にエキスパートによるガイドを提供します 担当 SDMは サポート アナリストや SAP 環境のスペシャリストなどのエキスパートで強化されたチームを活用します SDMはそれぞれ担当する地域の言語を話します また 顧客固有のビジネスおよび ITの内容を理解し その内容をエスカレーションに適用して問題を確認し効率的に解決します 担当 SDMは状況に応じて サービス要求を迅速に適切な方法で解決するために踏み込んだ対応もします また SDMは四半期ごとの正式なレビューで ベスト プラクティス スタンダードに対するパフォーマンスを評価します 顧客のビジネス計画と技術計画について話し合いエスカレーションを予測して回避し Oracleリレーションシップから最大限の価値を引き出す方法を提供します SAP Aware Service Delivery オラクルのサービス計画を使用している SAP 顧客は ダイレクトなリレーションシップを通してより迅速にオラクルにアクセスできます Oracle Database ソフトウェアから 機能 安定性 可用性を最大限に引き出すには Oracleと Oracle with SAPの両方の専門知識が必要です これは SAPアプリケーションと Oracle Database ソフトウェア間で複雑な相互運用性の要素があるためです Advanced Customer Servicesは パッチ作業やシステム構成の変更を行うための Oracleおよび SAPの情報を解析するプロセスを合理化することで 顧客のITスタッフの生産性向上に役立ちます 顧客は 固有の環境やバージョンを対象とした推奨事項に焦点を当てることができます 標準的なSAPのインストールの場合 利用できないOracle 機能もあるため Oracle Advanced Customer Servicesは SAP 認定構成を維持しながら常時新しい機能を利用できるように支援します

62 62 Oracle/SAP 指向のワークショップと取り組み ITスタッフの能力を高め SAP 環境のOracle Database の最適化を確かにするためにワークショップが作られ SAPアプリケーションと Oracle Databaseの相互運用に関する専門家が担当します SAPとの長年にわたる技術的パートナーシップに基づいて オラクルは次のテクニカル スキル ワークショップを提供します - Fundamentals of Oracle database for SAP ERP (Level I) - Oracle Advanced Performance Tuning for SAP ERP(Level II) - Oracle Expert for SAP(Level III) - Oracle database 10g for SAP Environments - Oracle database Administration for SAP Business Warehouse - Oracle Real Application Clusters for SAP - SAP ERP ABAP Tuning with Oracle database Platform さらに価値を高めるために これらのテクニカル スキル ワークショップは 顧客固有の状況や目標に合せて変更 拡張できます 顧客固有のテクニカル スキル ワークショップは可用性を基本に計画されますが 適用される地域は限定されることがあります 多くの顧客は アップグレード 移行および他のインフラストラクチャへの変更の際に より多くの経験や専門知識が必要なことに気が付きます オラクルは このような支援を提供するため支援サービスのレベルに応じて作業明細書を作成します 支援サービスは オラクルの SAPエンジニアから個別の支援が必要な顧客向けのサポート アドバイス サービスです このサービスは SAPのアプリケーション システム ツール プロシージャ そして最も重要な SAPを使用するOracle Databaseに関して熟練した Oracleエンジニアを派遣します 顧客を担当する Oracle エンジニアが 事前に指定した期間 顧客との合意の上で SAPアプリケーション環境で稼動するOracleソフトウェアを効率的に操作および管理するサポート サービスを実施します 最も一般的には 次のような取り組みがあります - データベースの計画および構成 - データベースのヘルス チェック - データベースのパーティション化 - SAP ERP 管理概念 - 概念の再検討と証明 - ホット スタンバイ /Data Guardの実装 - バックアップ / リストア / リカバリ - RACセットアップ支援 - H W 移行 O 2 O / プロバイダとしての O r a c l e Advanced Customer Services - HW 移行支援 O2O パッケージ - アドバイスおよび支援としての Oracle Advanced Customer Services - データベースの移行支援 R3LOAD - データベースの再編成 SAP 環境のAdvanced Customer Servicesを利用することで オラクルの分野別のエキスパート ITプロフェッショナルや開発者と良好な関係を築き Oracle 環境の価値を最大限に引き出すことができます 次に いくつかの取り組みのタイプを説明します SAPシステムのデータベースの計画および構成 SAPプロジェクトの開始時 ほとんどのアクティビティは主にアプリケーションの設計と実装に充てられます この期間は データベースを将来のニーズに合せて最適かつ柔軟に構成し 確実な構成や設計を実現する上で非常に重要です 不適切な構成は 運用上の効率や管理の点で余計な努力が必要になります データベースの準備および構成には SAPプロジェクトの初期段階で適切なリソースを選択し 現在のベスト プラクティスと設計目標に留意することをお薦めします

63 Oracle Advanced Customer Services for SAP 63 データベースのヘルス チェック / パフォーマンス分析すべての SAP 顧客にとって パフォーマンスは SAPシステムの導入と運用を成功させる重要なポイントの 1つです オラクルの熟練したスタッフは Oracle Databaseの詳細な知識があるだけでなく SAP 環境における Oracleの複雑さも熟知しています したがって このようなスタッフがパフォーマンス問題を分析しソリューションの提供をします たとえば これらのソリューションには索引設計 パラメータ最適化 ABAP 最適化 オペレーティング システム パラメータの適用などの分野があります また オラクルのスタッフは各 SAPソリューション固有の機能にも対応できます SAP ERPまたは BI/BWシステムのパフォーマンス問題の発生する形は様々です それを解決するソリューションのアプローチも多種多様です 高可用性 / バックアップ概念 SAPシステムの可用性の低下は ほぼすべての顧客で深刻な問題 ( 物流や財務 ) になります ミッション クリティカルな環境で 不意の停止時間が発生する危険性をできるだけ押さえるために IT 組織はフェイルオーバーやリカバリの可能性を積極的に計画しておく必要があります ただし この領域には多様なアプローチがあり それぞれに利点と欠点があります ( ハードウェア クラスタ ミラー技術 スタンバイ データベース RAC Data Guardなど ) Oracle ACSは 顧客に最適なアプローチ戦略をアドバイスし 選択したソリューションを実装する間も支援をおこたりません SAP 向けのOracle RACの対応オラクルは Real Application Clusters (RAC) オプションを提供します このオプションを使用して 個別のサーバー ( ノード ) のデータベース インスタンスを分散できます これにより Oracle Database システムの高可用性の点で新しい可能性が提供され システム リソースのディメンション化においてより高い柔軟性が得られます ( スケーラビリティ ) オラクルは 顧客のSAP 環境で RACが使用できるようにプロフェッショナルなサービスで支援します これらのサービスには ワークショップ 計画立案および RACソフトウェアの実装が含まれます Suiteインストールを Oracle 以外のデータベースから Oracleに移行する企業を支援することができます この移行サービスが顧客から高く評価されている理由の 1つは DBAの観点で変更に習熟していることです Oracle Advanced Customer Servicesの支援を受け 顧客のスタッフは移行計画を実施でき 新しいデータベース操作を習得できます OracleからOracleへのデータベース移行 (O2O) - SAPシステムの非常に高速で円滑なデータベース移行 異機種環境のデータベース移行標準ツールでは転送時間が48 時間以上になるため オラクルは O2O 移行サービスを提供しています サービスのセット プロシージャおよびツールを基盤として Oracle ACSでは非常に短時間でプロセスを完了できます 通常 これは 1 時間あたり 100~150GBの速度で実行されます つまり これまで使用していた標準ツールでは処理できなかった方法でシステムを移行できます このオラクル テクノロジーがベースのサービス セットは SAP ERP とBI/BWシステムの移行をサポートします この高度な移行アプローチを使用したシステムは 完全にSAPのサポート対応要件を満たします SAP 顧客向けのOracleパーティショニング Oracleパーティショニングは Oracle Database 10g Enterprise Editionのオプションです 技術レベルでは Oracleパーティショニングにより データベース内の表および索引はより小さい部分に分割されます Oracleでは値の範囲で表を パーティション化 できるため たとえば 2009 年 1 月 1 日から 2009 年 1 月 31 日までのデータは このデータ独自のパーティションに常駐します Oracleは値リストで表をパーティション化することもできます たとえば 北アメリカのデータを 1 つのパーティションにし ヨーロッパのデータを別のパーティションにすることができます 大規模データベースの管理には パーティション化が不可欠です SAP 向けのデータベース移行サービスすべてのSAP ERP 実装の多くは Oracle Database で実行されています Oracle Advanced Customer Services for SAPグループは データベース移行に関してSAPから認定されています そのため SAP Business

64 64 Oracle Advanced Customer Services for SAP 大規模データベースのパーティションを行うときに 肥大は基本的な問題になります Oracleパーティショニングでは データベース内の大きな表 特に肥大した表に 分割統治 技術を使用できます 現在のデータベースが来年はその 2 倍に肥大したからと言って エンド ユーザーはアプリケーションの実行速度が半減することを受け入れません それだけでなく データベースの完全メンテナンスやバッチ処理に使用される時間が 2 倍に増えても許されません ITマネージャがハードウェア予算を倍にしてくれるわけでもありません パーティション化は 一貫したパフォーマンスを維持しながら 非常に大きいデータセットに合せてデータベースを増減できる機能で ハードウェア リソースや管理作業が極度に増加することはありません Oracleパーティショニングは コア データベース エンジンに組み込まれ Oracle の管理ツールがサポートしています SAPアプリケーションから見ると パーティション化は完全に透過的です パーティショニングを使用するために アプリケーションや SQL 文を変更する必要はありません SAPのパーティション機能は SAPリリース 4.6C(SAP Note 参照 ) SAPカーネル 6.20からサポートされています 詳細と Coop Switzerlandのパーティション化の成功例は Oracle Database 11gの準備 SAP AGは Oracle Database 11g Release 1をスキップし Oracle Database 11g Release 2を認定します これは Oracle Database 10gが拡張サポート サイクルに入る少なくとも 12 箇月前になります OracleとSAPは Oracle Database 11gのサポート対応性の改良とテスト統合を行うため Oracle Advanced Customer Servicesは このアップグレード アクティビティのサービス提供準備を継続します Oracle Advanced Customer Servicesは Oracle Database バージョン間のアップグレード計画の準備に関して顧客のスタッフを支援します Oracle Advanced Customer Servicesは SAPとの継続的なサポートとパートナーシップを通じて または顧客のIT 組織から直接 SAP 環境の複雑さを熟知した個別サービスを提供します 詳細は下記にお問合せください SAP 環境におけるOracle Advanced Customer Servicesは 日本では Oracleレスキュー サービス for SAP の別称で ご提供しています ヨーロッパ 中東およびアフリカ Michael.Weick@oracle.com 北アメリカ Kumar.Allamraju@oracle.com アジア 太平洋 Sam.Viola@oracle.com 日本 Eisuke.Sekiguchi@oracle.com ラテン アメリカ Rene.Barrera@oracle.com