Comments
Description
Transcript
Oracle for SAP
Oracle for SAP − Release Matrix データベース − SAP R/3 リリース・マトリックス SAP R/3 Version 3.1I, 4.0B, 4.5B, 4.6B: 8.1.7 32-bit: Intel NT/Windows2000/XP, Intel Linux, IBM AIX, HP-UX, Reliant UNIX, Solaris 8.1.7 64-bit: HP Tru64, IBM AIX, HP-UX, Reliant UNIX, Solaris 9.2 32-bit Intel NT, Windows2000/XP, Intel Linux 9.2 64-bit HP Tru64, IBM AIX 5L, HP-UX, Solaris (SUN and Fujitsu-Siemens) SAP Business Information Warehouse 3.0B: 8.1.7 32-bit: Intel NT, Windows2000/XP, Intel Linux 8.1.7 64-bit: HP Tru64, IBM AIX, HP-UX, Solaris (SUN and Fujitsu-Siemens) ® 9.2 64-bit: HP Tru64, HP-UX PA-RISC, HP-UX IA-64, IBM AIX 5L, Solaris (SUN and Fujitsu-Siemens), Windows 2003 (予定) SAP Business Information Warehouse 3.1: 「最新のOracle for SAP技術情報」 − RAC for SAPによるTCOの削減 − 9.2 32-bit: Intel NT/Windows2000/XP, Intel Linux 9.2 64-bit: HP Tru64, HP-UX PA-RISC, HP-UX IA-64, IBM AIX 5L, Solaris (SUN and Fujitsu-Siemens) , Windows 2003 (予定) ABB事例 HP Tru64TM UNIXとOracle9i Real Application Clustersが ビジネス・クリティカルなSAP®アプリケーションで利用可能に Oracle9i Real Application Clusters SAP R/3 Version 4.6C/D: SAP R/3 4.6 C/D: HP Tru64 AIX（Q3-Q4/2003） Solaris,HP-UX,Linux(Q4/2003) Windows(Q1/2004) 8.1.7 32-bit: Intel NT/Windows2000/XP, Intel Linux, IBM AIX, HP-UX, Reliant UNIX, Solaris 8.1.7 64-bit: HP Tru64, IBM AIX, HP-UX, Reliant UNIX, Solaris 9.2 32-bit Intel NT, Windows2000/XP, Intel Linux 9.2 64-bit HP Tru64, HP-UX PA-RISC, HP-UX IA-64, IBM AIX 5L, Solaris (SUN and Fujitsu-Siemens) , Windows 2003 (予定) SAP R/3 Enterprise: 8.1.7 32-bit: Intel NT, Windows2000/XP, Intel Linux 8.1.7 64-bit: HP Tru64, IBM AIX, Solaris (SUN and Fujitsu-Siemens) 9.2 32-bit Intel NT, Windows2000/XP, Intel Linux 9.2 64-bit HP Tru64, IBM AIX 5L, HP-UX, Solaris (SUN and Fujitsu-Siemens), Windows 2003 (予定) RACに関するより詳細な情報については、OSSのノート527843を参照して下さい。 Oracle デサポート・プラン: SAP R/3 メンテナンス終了: standard 12/2003 12/2003 12/2003 3/2006（予定） トレージ・エリア・ネットワーク （SAN） およびス への負担を最小限に抑えた上での発展を可能 にする電力・オートメーション技術で世界をリー タンバイ・データベースの機能が、ABBの望む 可用性を実現するために使用されています。 ドしています。ABBグループは100か国以上、 約15万人の従業員を擁し、ABBのもつ技術力 は、それぞれの分野でのグローバル・リーダー として認められています。また、送変電・配電機 器設備や制御弁などの電力事業から、塗装機 やロボット、回転機器や低電圧制御機器などの 産業分野、石油化学や金融サービスまで、さま ざまな国籍や文化的背景を持った専門的なス タッフがABBの最先端技術を提供しています。 これら多様な事業を支援するために、ABBは およそ20のSAPの本稼動システムを持ってい ます。この本稼動システムは、約10,000人の ユーザーがWorld Wideにアクセスします。ス 8.0.6 Sept. 30, 2001 8.1.7 Dec. 31, 2003 9.2 Dec. 31, 2005 (予定) 3.1I 4.0B 4.5B 4.6C ABBは公益事業と産業分野のお客様に、環境 additional support fee 12/2004 12/2004 12/2004 http://www.sap.com/partners/directories/technology.asp Reproduction allowed only with the publisher's express permission Oracle, Oracle8i, Oracle9i, Oracle Express, Discoverer, Designer, Developer, and the Oracle Logo are trademarks or registered trademarks of Oracle Corporation. Safe コンテンツ 8.1.7 32-bit: This publication is provided "as is" without warranty of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non- infringement. This publication could include technical inaccuracies or typographical errors. Changes are periodically added to the information herein; these changes will be incorporated in new editions of the publication. Oracle Corporation. may make improvements and/ or changes in the product(s) and/ or the program(s) described in this publication at any time. Oracle Corporation has intellectual property rights relating to technology described in this document. In particular, and without limitation, these intellectual property rights may include one or more patents or pending patent applications in the U. S. or other countries.No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of Oracle. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. HP Tru64TM UNIXとOracle9i Real Application Clustersが ビジネス・クリティカルなSAP®アプリケーションで利用可能に Microsoft®, WINDOWS®, NT ®, EXCEL®, Word®, PowerPoint® and SQL Server ® are registered trademarks of Microsoft Corporation. Unbreakableなアプローチ 8.1.7 64-bit: HP Tru64, IBM AIX, HP-UX, Solaris(SUN and Fujitsu-Siemens) 9.2 32-bit Intel NT, Windows2000/XP, Intel Linux IBM®, DB2®, DB2 Universal Database, OS/2 ®, Parallel Sysplex ®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix ® Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries. ORACLE® is a registered trademark of ORACLE Corporation. 9.2 64-bit HP Tru64, IBM AIX 5L, HP-UX, Solaris (SUN and Fujitsu-Siemens) ABB事例 社説 HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. JAVA® is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT ® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One. 1 Oracle9i RAC Oracle9i Real Application Clustersによる 2 Oracle9i Online Data Reorganization 9 10 Oracle9i Release2がIntel Itanium2システムに対応 IT-Energy © Copyright 2003 Oracle Corporation. All rights reserved. for Halliburton マイグレーション事例 20 4日間でDB2からOracleへ、高可用性の実現とTCOの削減 有効性 〒1 0 2 - 0 0 9 4 東 京 都 千 代 田 区 紀 尾 井 町 4 - 1 オラク ル 製 品 お問合わせ窓口 SAP BWにおけるOracle9i データ圧縮 TEL URL 0120-155-096 http://www.oracle.co.jp/contact/ 4 オラクルと富士通・シーメンス・コンピューターズ 最先端技術のコンビネーション Oracle for SAP −Release Matrix Oracle/SAPグローバル・テクノロジー・セン ターによって 随 時 更 新 、公 表 さ れ る最 新 の Oracle for SAPテクノロジーは、SAPを利用 していく上でのオラクル技術、オラクルのサー ビスが提供するもの、オラクルとSAPのリリー ス・コンビネーション、実際の顧客ストーリーな ど、オラクルのテクノロジーをより良く理解する 助けになるでしょう。 ABBにおけるSAP上でのOracle Real Application Clusters技術の実装の成功 SAP顧客ストーリー：DB2からOracleへの データベース・マイグレーション ● Oracle9 i オンライン再編成、SAP上での Oracle Internet Directory ● SAP BWにおけるOracle9iテーブル圧縮を 使ったコスト削減 ● ● Oracle Internet Directory 9.2 for SAP All trademarks and registered trademarks are the sole property of their respective owners. 本カタログの情報は、2003年7月現在のものです。実際の製品とは内容が異なる場合があります。 ＊Oracleは、Oracle Corporationの登録商標です。本文中の社名、商品名は各社の商標または登録商標です。©2003 Oracle Corporation Japan 1 Dear SAP customer UNIX®, X/Open®, OSF/1®, and Motif ® are registered trademarks of the Open Group. Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc. Dear SAP customer Reliab le SAP, R/2, R/3, mySAP, mySAP.com, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. ABBは、SAP環境をスケール・アウトすること でコストを削減すると同時に、管理性、可用性 およびスケーラビリティの実現を切望していま した。SANと組み合わせたクラスタ・サーバ ーにはさまざまな長所がありますが、高コスト であることが問題でした。また、フェイルオー バー型クラスタはロード・バランシングできま せんし、データベースの回復に時間がかかりま す。さらに、他の多くの会社がそうであるよう に、ABBはスタンバイ・サーバーのコストが妥 当なものであるかの判断には疑問を感じてい ました。障害なくシステムが動作した場合には、 パワフルで高価なマシンが何の処理もせずに、 何か月も使用されない可能性があります。 社説 は安全で、信頼性があり、 スケーラビリティも提供します。 ble ala Sc More for less ２ページに続く Oracle for SAP Imprint Oracle for SAP Global Technology Center Altrottstr. 31 69190 Walldorf, Germany Tel. ++49 (0) 62 27-83 98 - 0 Fax ++49 (0) 62 27-83 98 - 199 E-Mail: [email protected] Albrecht Haug [email protected] Internet: http://www.oracle.com/newsletters/sap SAP Business Information Warehouse 2.0B/2.1C Intel NT/Windows2000/XP, Intel Linux, ,IBM AIX, HP-UX, Solaris (SUN and Fujitsu-Siemens) ® 9.2 32-bit: Intel NT, Windows2000/XP, Intel Linux 10 12 13 Oracle9 i Real Application Clusters （以下Oracle9i RAC）は単一のデータベース を管理するような管理性とスケーラビリティお よび可用性のすべてを提供します。また、それ はTCO（総所有コスト）を減少させることを意 14 味します。S A P は O r a c l e デ ー タベ ースと Oracle9i RAC技術によってもたらされる付 加機能でSAPアプリケーションが開発、動作 20 可能であることをコミット（約束） しました。 15年にわたるオラクルとSAPテクノロジー・パー トナーシップは、Windows、UNIXおよびLinux 上で動作するSAPシステムのための最も証明さ れた安定して、信頼できて、スケーラブルなデー タベース・プラットフォームの提供により、お互い の顧客に対して大きな価値をもたらします。 ワールドワイドでのmySAP、SAP R/3および BWのインストール・ベース数39000を超え る協調作業は、 「SAP on Oracle」の顧客満足 およびテクノロジーの証明です。それだけでな く、 「SAP on Oracle」は、グローバル提携の 利点を活かしながらWalldorfとRedwood Shoresで共通の顧客への最適化されたシス テムを提供します。開発、サポートなどすべて の面において協調しながら作業しています。 オラクルの革新的なデータベース技術（例えば 行レ ベ ル ロック、パ ー ティショニン グ、R e a l Application Clusters）は、ワールドワイドに認 定およびサポートされるデータベース技術です。 もちろんSAPアプリケーションで利用可能です。 より詳細な情報は、以下のサイトをご覧下さい。 http://www.oracle.com/newsletters/sap Sincerely Gerhard Kuppler Gerhard Kuppler Director Corporate SAP Account Oracle Corporation 1ページから続く The answer その答えは、 「Oracle9 i Real Application Clusters」です。Oracle9i RACは、最も柔軟 なクラスタ・データベース・プラットフォームを提 供するために現代のハードウェアおよびソフト ウェアのクラスタリング技術を活用しています。 今まで使用されていなかったスタンバイ・システ ムを活用することで、クラスタ内のすべてのサ ーバーの処理能力を最大限に引き出します。 べてのクラスタ・サーバーから同時にアクセス することができます。これは、クラスタ化された 記憶装置の管理を単純にし、HP TruCluster サーバー・ソフトウェアは、システム管理者がク ラスタ化されたシステムを単一のサーバーと 同じくらい容易に管理することを可能にします。 それは、オペレーティング・システム環境がクラ スタ内のすべてのサーバーを共有する場合に、 単一のシステム・イメージを表現するからです。 障害に起因するダウンタイムに対応します。もし、 ディスク障害が起きればホットスペア・ディスクで Phased approach 7月24日に、HPはABBにテスト用のパイロッ ト・プラットフォームを納品。Oracle9i RACの 正確な効果を測定するために、ABBは段階的 復元が行なわれます。高い可用性を提供するた めのモデルは、Active/Activeとしてクラスタ 化されたFailover構成で、2つのファイラーが なテスト・ロードマップを決定しました。プロジ 動作するアーキテクチャを採用することです。 ェクトの第1段階はHPによって提供されるテス ト・システムに全データベース(Oracle8.1.7) をコピーすることを含んでいて、一連のベースラ イン・テストは、アップグレードの前に実行され 評 価 を 行 な い ました 。そ の 後 、A B B は 、 Oracle9 iへデータベースをアップグレードし、 The Underlying Software Oracle9i RAC Server (Node 1) Oracle9i RAC Server (Node 2) ペレーティング・システムと、特許を取得した NetApp Write Anywhere File Layout ベースライン・テストを再度実行。最終段階で Oracle9i RACにアップグレードしました。ノ Database クラスタのスケーラビリティのキーとなるの は、Oracle9i RACのノード間をクラスタ・ インターコネクトとして繋ぐHPメモリ・チャネ ルです。これにより、高速のコミュニケーショ ンおよび効率的なメッセージ送信のための広 い帯域幅と最少の待ち時間を得ることができ ます。 TM TM HP Tru64 UNIX TruCluster サーバー・ ソフトウェアはOracle9i RACの利用が認定さ れた技術のうちの1つです。クラスタ・ファイル システム(HP Tru64 UNIX TruClusterの重 要なコンポーネント)は、すべてのファイルにす First customer to run SAP on Oracle9i Real Application Clusters Oracle9i RACがSAPシステムでどのように 統合され、SAPのホスティング戦略に適合する の か 確 か めるために、A B B は、O r a c l e 9 i RACのテストを行なうことを決定しました。 ヒューレット・パッカード、オラクルおよびSAP との 綿 密 なコン サル テーションにより、H P A l p h a - S e r v e r T M プラットフォーム 上 の H P Tru64 UNIX 5.1Aクラスタで動くSAP R/3 4.6Cを実行するためのパイロット・プロジェク トが組織されました。 FTPそしてDirect Access File System (DAFS)が利用可能です。 図1：Oracle9i RACアーキテクチャ Proof-of-concept Storage:Completing the Picture ストレージ・タスクを扱うためのNetApp ファ ABBはHPプラットフォームのハードウェア・パ ここ十数年のあいだ、ほとんどのプラットフォー フォー マ ンス の 限 界 に 左 右 さ れ な い 形 で、 SAPジョブがパラレルに実行されることによ ムにおいて計算能力は18か月ごとに2倍にな り、ストレージ容量は12か月ごとに2倍になっ イラーを最適化することを可能にしました。本 質的に、NetAppストレージ技術は、ストレージ るパフォーマンス向上を実現しました。最低限 のハードウェア(1台のHP AlphaServerが必 ています。また、ネットワーク速度については 8∼9か月ごとに2倍になりました。これは、企 ーキテクチャを支援します。 要)の追加、SAPシステムの調整なしに、標準 のクラスタ・コストの数分の一の投資でリニア 業のIT基盤を構成する3つの重要要素です。 企業は今、企業を支える基幹システムのアプリ NetApp Filers なスケーラビリティ、高可用性かつ高パフォー マンスを実現するシステムの構築に成功した ケーションにおいてスケーラビリティと可用性 の要求を満たす必要があります。Oracle9 i のです。これは、4台のノードを用いてリニア RACは、データセンターに新しいレベルの可 用性、パフォーマンスおよびスケーラビリティ をもたらします。しかし、技術の十分な利益を 実現するために、企業はデータベースおよび なスケーラビリティを証明したSAPベンチマ ークによって確認されました。特に、資産の効 率的運用および既存資源の再利用に挑戦する、 競合他社に対して付加価値を創出したい会社 にとって有用です。事実、プロジェクトが成功 したABBは、現在、HP Tru64 UNIX と Oracle9i RAC上でSAP R/3で実行した最 初の顧客となっています。 Network Speed Storage Capacity Computing Power 層を単純化し、高い可用性、スケーラビリティ、 操作性を提供することで、Oracle9 i RACア NetAppは、企業に対してOracle9i RACソリュ ーションにおけるストレージ層をまとめるための 技術を提供します。NetApp製品ファミリーは、 企業データセンター用に設計されたハイエンド の装置および部門使用のための中小規模のマ シンのために設計されたシステムに至るまで、 Doubling Every 8-9 Months Doubling Every 12 Months Doubling Every 18 Months Oracle9i RAC Oracle9i Real Application Clustersによる Unbreakableなアプローチ Network Technology Executive Overview データセンターに対する要求は日々増加してい ます。高い可用性はシステム・ダウンタイムが許 されない企業にとって絶対の要件になっていま す。グローバル・ビジネスは昼も夜もなく、オン ライン・ストアや各種サービスを顧客に対して 提供する必要があります。計画停止、計画外停 止によらず、システムが利用可能でないという ことはビジネスを遂行する上でコストの面で問 題になります。この要件を受けて、多くの会社 が、Oracle9 i RACのソリューション（サーバ ー・クラスタ上でOracleデータベースを実行 することができ、システムの可用性および柔軟 性をより高いレベルで実現できる）を利用しは じめています。しかしながら、オラクル技術の 十分な利益を得るためには、クラスタ・サーバ 2 ーおよびデータベースのための能力を有する 記憶装置を必要とします。 N e t A p p ® スト レ ー ジ・テ クノ ロ ジ ー は 、 Oracle9 i RACと同様にIT環境へ高い可用 性、管理性およびスケーラビリティを提供しま す。さらに、リサーチ結果によると、従来のスト レージ・ソリューションと比較して、NetAppの ユニークなアーキテクチャおよびネットワーク 中心のストレージに対する革新的なアプローチ は、著しく低い総所有コスト（TCO）を実現する ことを示しています。つまり、Oracle9i RAC と組み合わせたNetAppのソリューションは、 急速に変化するビジネス環境の中で、高い可用 性と柔軟性を支援する、 トータルのクラスタ・ソ リューションを低コストに実現します。 (WAFL ®)です。 Data ONTAPは幅広いプロトコルをサポート し、Oracle9iではNFS、CIFS、SCSI、HTTP、 ードの追加、管理およびモニタリング・ツール の機能テストの結果は非常に印象深いもので した。 NetApp ファイラーは2つのキーとなるビルディ ング・ブロックに依存します。Data ONTAPTMオ 図2：CPU、ストレージ、ネットワークの成長力 サーバーについて将来を見据え、データ・スト レージ技術を考慮し、データ管理について考 えていく必要があります。また、可用性、パフォ ーマンスおよびスケーラビリティを高いレベル で提供するためのクラスタ・データベースをサ ポートするデータ・ストレージへのアプローチ も必要とします。さらに、コスト効果も含めて 考慮する必要があるのです。 このようなアプローチはNetAppのネットワー ク中心型のストレージ技術で実現できます。 NetAppアーキテクチャはサーバーからストレ ージ装置を分離し、既存のオープンな標準ネッ トワークを利用してNetAppファイラーを配置 します。ファイラーは、サーバーのオペレーティ ング・システムによってハンドルされる機能の 範囲内でタスクを遂行する専用ストレージ・シ ステムです。 このような特殊化により、速度と効率を備えた 広範なE-Businessアプリケーションをサポート します。なぜならば、NetApp ファイラーは、プ ラグ・アンド・プレイで展開可能で、数分でオン ライン状態にすることができるビルディング・ブ ロックとして構成されているからです。NetApp ファイラーはダウンタイムなしに小さな単位で ディスクをシステムに加えることができ、50ギ ガバイトから数テラバイトまで構成することがで きます。INPUT社による最近の報告によると、 典型的なStorage Area Network(SAN)ソリ ューションで200ギガバイトを構成するのに4 時間かかるのに対し、NetApp ファイラーを使 えば約10分で処理が終了するそうです。企業は NetAppを用いて小規模な導入から始め、ビジ ネスに応じて必要となる容量を拡張することが 可能です。NetApp ファイラーは、99.99%を 超えるデータの可用性を提供します。それらは ハードウェア機能や内蔵のRAIDによりディスク また、多数のプロトコルの同時使用も認めるの で、UNIX®、NTおよびWebベースのサーバーや クライアントからアクセスできるストレージ・イン フラストラクチュアを提供します。WAFLファイ ル・システムはダイナミックにデータ・ストレージ を拡張可能にし、ブロックレベル・チェックサム 機 能 を 備 えたデ ータ保 護 を サ ポートします。 WAFLファイル・システムは、ファイル・システム、 ボリューム・マネージャーおよびRAIDサブシス テムの機能を組込んでいるため、結果として、3 つの層のサービスがハイレベルに統合されるの です。 従来のファイル・システムと異なり、初期化など は必要ありません。ディスク上で利用可能なす べてのスペースを使用することができ、どのディ スクを使用するべきであるか決めることもでき ます。管理者は、システムに利用可能なスペース の量を迅速に修正することができるのです。 WAFLファイル・システムは、データの既存の ブロックに上書きしません。代わりに、常に新 しいブロックを書いていくのです。新しいブロッ クが作成される場合、WAFLファイル・システ ムはそのブロックの位置を示す「ポインタ」を 更新します。すなわち、ある特定の時点におけ るポインタのSnapshotTMをとるのです。ファ イル・システム上のfreezeされたバージョンは カレントもしくはアクティブなファイル・システ ムに現われる特別なサブディレクトリによって利 用を可能にし、これらのバージョンは31まで は同時に維持することができます。また、その いくつかは同時に見ることができ、アプリケー ション・サーバーが極度にデータにアクセスし 更新を行なっていても、システムからデータ管 理タスクを実行することができます。NetApp は、次のものを含むWAFLファイル・システム に基づいたいくつかのデータ管理ツールを作 成しました。 ● Snapshot ─ 迅速で透過的なオンライン･ バックアップの生成を実現して、各データ・ボ リューム毎に複数のバックアップ・データ・コピ ーを保持します。Snapshot 機能は最小限の ディスク容量しか必要とせず、サービスへのパ フォーマンスインパクトは全くありません。 ● SnapRestore® ─ データ･ボリューム全体 の状態を、指定した Snapshot に戻すこと が可能になり、ファイル・システムを即時にリ ストアできます。テラバイトのデータも、テ ープを使用せずに、数時間ではなく数分とい う短時間で回復できます。 3 ● SnapMirror ® ─ LAN (構内ネットワーク) また Oracle9i は WAN (広域ネットワーク) 上での効率的なリ モート･ミラーリングを提供します。非同期ミラ Oracle9i Online Data Reorganization ーリングを使用して、災害復旧、複製、バックア ップ、または待機系システムでのテストを行なう ことができます。 性を変更せずに新しいオブジェクトを作成する The Right Fit for Oracle9i RAC ことにより、できるかぎり既存の断片化を縮小 することです。これは、索引の再構築です。最 NetAppのネットワーク中心型のアーキテクチャ も望ましいのはオブジェクトの記憶特性の変 更により将来の断片化を回避することです。こ がファイル整理に専念することで、Oracle9 i RACから操作可能なファイル・システムを提供 れは表の再編成です。 重要なのは、管理者は断片化を縮小するべき します。NetAppのアプローチは、ストレージ 層のクラスタ化ソリューションの利点によって ですが、しかしそれがデータベース・サーバー のパフォーマンスを損なうことも考慮すべき点 オ ラ クル の ソリュー ション を 補 完し ま す。 Oracle9i RACのアプローチ＝NetAppのア です。 プローチです。 ● 高可用性 63の企業におけるオラクル環境を分析した INPUT社からの報告によれば、NetAppテ クノロジーは、99.99%以上のデータ可用 性を提供し、それはIT業界で最も高い数値 となっています。 ● 表や索引を再編成するとき、 実表がロックされ、 再編成が終わるまで、DMLオペレーション （insert, update, delete）は許可されないこ とは、多くの顧客にとって受け入れられる話で 管理性 NetAppアーキテクチャのシンプルさとデー タベース管理ツールの組み合わせはDBAと るかがシステム管理者の望むゴールの1つに なりました。 スケーラビリティ NetAppファイラーは、大企業におけるシス テムをサポートするために小さな単位で必 要に応じて拡張が可能です。IT部門にとって コスト効率の良い機能です。 ● システム要件は変化しています。数年前まで、 した。今日の基幹業務システムの多くは、デー タベースをいかに停止させず、可用性をあげ システム管理者の時間を節約します。 ● SUMMARY コスト INPUT社の報告によれば、NetAppのストレ ージ技術は、HP、EMCおよび日立などのス トレージ・ソリューションに比べて70%程度 にあたる総所有コスト（TCO）提示します。 NetAppの技術は、3つのエリアでより低い TCOを実証しました。 1.ハードウェアとソフトウェアの取得コスト 2.人や時間といった運用上のコスト 3.ダウンタイムによって失われるビジネス・ コスト このため、オラクルのデータベースは進化して います。Oracle8iおよびOracle9iは共に、デ ータ再編成によるシステム停止のインパクトを 最小限にすることをサポートする機能を取り入 れました。 ● ● Conclusion Oracle9i RACは、OLTP環境、データ・ウェア ハウスおよびインターネット・アプリケーションの ようなハイエンドのアプリケーションに効率的で 信頼でき、かつ安全なデータ管理を提供します。 Oracle9i RACオプションは、パッケージまたは カスタマイズのアプリケーションに対して簡単な 管理と単一のシステム・イメージによるスケーラビ リティと可用性を提供します。Oracle9i RACは、 多数のノードからの単一のデータベースとしてク ラスタ・システムを構成することで、ハードウェア とソフトウェアの障害に対して、アプリケーション とデータベース・ユーザーを隔離することを可能 にします。また、ハードウェア環境をスケールす ることでパフォーマンスを提供します。 NetAppの技術でOracle9i RACを稼動させる ことは、顧客が直面するITに関する問題である、 成長し続けるデータ・ボリュームとそれを管理し、 かつ安全に運用する手助けをします。NetAppの ストレージでOracle9i RACを稼動させること で全体としてTCOを低減させます。NetAppスト レージ・ソリューションはOracle9i RACに対し て、単純で、速く、中央管理によるデータの保護 と最適化されたパフォーマンスを提供します。 4 ● ● ローカル管理表領域(Oracle8i)およびマル チ・ブロック・サイズ(Oracle9 i)のサポート のような新しい機能により、表や索引の断片 化、行連鎖を回避することができます。これ により再編成が必要となる2つの主要な問題 を解決します。 Oracle8iは、索引が再編成されている状態 で実表にユーザーがアクセスを継続するこ とができる索引のオンライン再編成を導入 しました。再編成は索引に対して直接 （結合） 、 または新しいコピーを作成して（再構築）の どちらかを実行することができます。ただし、 この機能は索引構成表（Index-organized Table, IOT） に制限されていました。 Oracle9iは、オンライン再定義と呼ばれる 新しい機能を導入しました。この機能はすべ てのタイプの表をサポートします。簡単に表 のオンライン再編成を実行することができ、 管理者が表の構造および記憶特性をオンラ インで変更することを可能にします。 オラクルはSAPのための特別なソリューショ ンを提案します。特に一番興味を持たれる 機能の１つに、SAP上でのアーカイブ実行後 に必要とされる再編成の量を減らすための パーティショニング機能があります。 オラクルのオンライン・メンテナンス機能はデ ータ可用性、問い合わせ性能、レスポンス時間 およびディスク・スペースを改善します。 REASONS AND NON-REASONS FOR REORGANIZATION データベース管理者はセグメント、ブロックあ るいは行といったレベルで断片化を縮小する か回避するために再編成を考えるでしょう。再 編成に関して最低限満たすべきことは、記憶特 Segment-Level Fragmentation セグメント・レベルの断片化は、データ・セグメ ント（表）あるいは索引セグメント（索引）があ まりにも多くのエクステントから成ることから のデータファイルの中でブロックが使用か未使 用かのステータスを追うためにビットマップを るかもしれません。これについては最後の セクションで、より詳細に説明します。 使用します。単純化された内部アルゴリズムに より、ローカル管理表領域はディクショナリ管 理表領域より良いパフォーマンスを提供しま Oracle/SAPシステムでのブロックレベルの 断片化がおこる第1の理由はアーカイブです。 しかしながら、これは、各アーカイブに含まれ るすべてのセグメントが再編成されるべき、と す。さらに、管理者は、2つの非常に単純で効 率的なエクステント・サイズ管理の機能を選ぶ いう意味ではありません。次の規則が考慮さ れるべきです。 ことができます 表領域内のエクステントがすべて同じサイズ で作られるUNIFORMパラメータ。セグメン ● 最大数の制限はありません。 ブ・オペレーションに含まれる表に対応した 索引を注意深く分析するべきです。多くの論 ローカル管理表領域の導入で、セグメント・レ 理上削除された行に対応した索引の再編成 は、アーカイブ後にシステムのパフォーマン ベルの断片化の問題はなくなりました。その た め 、S A P は こ の 技 術 を 採 用 して お り、 スを保証する最も重要で効率的な手段です。 したがって、オラクルはオンライン再編成の Oracle/SAPシステムのために使用すること を推奨しています。 （OSS ノート 387946と 機能の中で、索引のオンライン再編成を第一 に実装することを目指しました。 409376を参照） 表の再編成は注意深く実行するべきです。不 利益かつ不必要な場合もあるからです。周期 発生します。 Block-Level Fragmentation 7.3より前のバージョンのOracleデータベー スでは、1つのセグメントを構築することがで きるエクステントの数が制限されていました。 値はデータ・ブロック・サイズに依存していた ので、一旦ブロック・サイズが選ばれるとエク ステント数は制限されました。限界に到達した 場合、セグメントのエクステント数を減少させ て、かつ成長を考慮に入れエクスポート、イン ポートを行なって再編成しなければなりません でした。 は索引のブロックに浪費されることを示します。 多数の挿入、削除処理の後で、未使用となった 効です。 （最後のセクションを参照） 図2b： 初回アーカイブに おける領域再利用 Row-Level Fragmentation 行が完全にデータ・ブロック内に格納できない 場合、 「行移行」あるいは「行連鎖」が生じます。 ● レコードのサイズは1ブロック内に収めるよ うにします。しかしながら、レコードが分割さ れ多数のブロックに格納される場合、パラメ ータPCTFREEの値が適当でない可能性が あります。SAPが適切なパラメータ構成を 再編成は必要ではありません。 （ 図2aを参照） 領域を再使用することができません。詳細は 表か索引かにより異なります。 ● G a j a K r i s h n a V a i d y a n a t h a（ Q u e s t Software社） はオラクル・パフォーマンス・チュ ーニングに関する、ホワイトペーパーの中で、 「すべてのオブジェクトにとってエクステント の最適の数は1です」という見解を示していま す。この話とは対照的に、彼は正確に次のこと を 述 べ て い ま す。 「 エ ク ス テ ント が これはまさにローカル管理表領域の機能その ものです。従来のディクショナリ管理表領域 はエクステントの割り当ておよび位置を記録 するためにデータ・ディクショナリを使用しま す。ローカルに管理された表領域は、Oracle 目的とした追加の手段として、表の再編成は有 的なアーカイブ実行については、アーカイブに より解放された領域が再利用されるので、表の ブロックレベルの断片化は、領域がデータまた バージョン7.3はこの制限を撤去しました。 Oracle7.3からは、セグメントを作成するか、 または修正する際にSQLステートメントのスト レージ節でMAXEXTENTS=UNLIMITEDを 指定することができます。しかしながら、場合 によっては制限をすることを決定する顧客もい ました。顧客が単に、追加を制御するメカニズ ムを望み、エクステントを管理する能力がある のであれば、何ら問題ありません。 (DB_FILE_MULTI-BLOCK_READ_COUNT* DB_BLOCK_SIZE)の倍数として分類されて いれば、1つのオブジェクトが1,000のエク ステントを持っているからといってパフォーマ ンスの問題が必ずおこるというわけではあり ません。しかも、エクステントが表領域内のさ まざまなエクステント・サイズによって、1つ のエクステントへオブジェクトを周期的に再 編成することは空き領域の断片化に関する問 題を引きおこします。これらのポイントを考え れば、理想的な領域管理とは、標準のエクス テント・サイズを定義し、 セグメント・サイズと、 その増加によって対応することです。 アーカイブに多量の削除が発生します。それ は必然的に索引のブロックレベルの断片化 に結びつくでしょう。したがって、アーカイ ト・サイズと増加によってエクステント・サイズ が動的に決定されるAUTO ALLOCATEパラ メータ。ローカル管理表領域でエクステントの レコードが表から削除される場合、対応する 索引のエントリーは必ずしも同様に削除さ れるとは限りません。特に削除オペレーショ ンが多くのレコードを含んでいる場合、 （論理 上）削除されたように対応する索引のエント リーはマークされるだけで、まだ（物理的に） 存在し、再使用することができないスペース を消費します。頻繁に索引ツリー構造を再構 成するオーバーヘッドを回避するために、こ の動作が選ばれました。多くのデータ・ブロ ックが、この状態になることで索引情報は非 効率に格納されることになります。そのため、 I/O要求が増え、メモリ消費が増加し、最後 にはパフォーマンスが低下してきます。結局、 管理者はブロックの量と使用率を改善する ために、索引を再編成しなければならないで しょう。 （図1を参照） 図2a： 周期アーカイブにおける 領域再利用 再編成によりエクステントの数を減少させたと しても、セグメントが再び増加している場合は、 追加のエクステント割り当ての作業をしなけれ ばなりません。表の再編成が考慮されるべき 2つのケースがあります。初回のアーカイブは 提供しているので、Oracle/SAPシステムで は稀にしか発生しない問題です。 ● レコードのサイズは1ブロック内にぴったり と納めるのは難しいものです。ただし、これ はパフォーマンスの問題を引きおこしませ ん。しかしながら、Oracle9iは、1つのデー タベース内に数種類のブロック・サイズを指 定できます。したがって、管理者は、標準の ブロック・サイズより大きなブロック・サイズ の表領域を作成し、その表領域へ長いレコー ドを含んでいる表を移動させることができ ます。 ONLINE INDEX REORGANIZATION 図1： 索引セグメントの ブロックレベルの断片化 ● 表での削除オペレーションは常に物理的に削 除を行ないます。削除されたレコードによっ て使用されていた領域はただちに解放され、 利用可能になります。PCTUSEDパラメー タが指定されていなければ新規の挿入オペ レーションも可能です。したがって、厳密に いえば、表でブロックレベルの断片化はあり ません。しかしながら、特別の場合にはおこ 次回以降のアーカイブよりさらに多くの領域を 解放する可能性があります。したがって、セグ メントを縮小させるために初回の再編成は有 効かもしれません。 （図2bを参照） 選択的なアーカイブはデータをより効率的に格 納する有効な手段かもしれません。したがって、 前のセクションで示したように、Oracle/SAP システムでの再編成が必要となる主な理由は アーカイブ後に生じる索引のブロックレベル の断片化です。従って、Oracle8 iがオンライ ン再編成を導入した際、まず実装したのが索引 のオンライン再編成のサポートでした。これは 2つの作業があります。索引のコピーを使って 行なうオンライン再構築と、コピーせずに場所 を取らずに作業するオンライン結合です。 これらの方法は、ユーザーが索引の再編成の 間に実表のデータにアクセスすることを保証 し、データベースの可用性を実現しています。 選択的なアーカイブによる悪影響を防ぐことを 5 Online Index Rebuild 索引のオンライン再構築は、再編成される索 引のコピーを作成します。表または行のロック TWO FOR SPEED AND STABILITY はそのオペレーションのために必要になりま せん。したがって、ユーザーは索引が作成され ている間に実表を更新し、問い合わせること を継続できます。再構築プロセスの間の実表 への変更が、同様に索引への変更を要求する 場合、オペレーション実行後に新しい索引へ内 容がマージされるジャーナル表に記録されま す。 (図3aおよび3bを参照) 図4a： SAPDBAを用いた 索引のオンライン再構築 図3a：索引のオンライン再構築（ステップ1：索引のコピー、ジャーナル表） 図4b： SAPDBAを用いた 索引のオンライン再構築 Online Index Defragmentation 索引のオンライン結合は索引のオンライン再 構築に似ています。索引を再編成して領域の利 用やパフォーマンスを改善します。主な違いは、 オンライン結合が再編成において、追加のディ スク容量を必要としないことです。したがって、 索引を再編成するための領域が充分に確保で きない場合に好んで使われます。 図3b：索引のオンライン再構築（ステップ2：新しい索引への切換え） オ ペ レ ー ション は 、S Q L コ マ ンド A L T E R INDEX<index_name>REBUILD ONLINE によって開始されます。このコマンドは古い索 引と同じ特性を備えた新しいコピーを作成す るために使用することができます。さらにエク ステント・サイズあるいは索引の配置を変更す ることもサポートします。このオンライン・オ ペレーションは並列処理もサポートし、分割さ れた索引のパーティションのうちのいくつか、 あるいはすべてを対象にすることができます。 バージョン6.10からはSAPDBAでも索引の オンライン再構築を行なうことができます。 （図4aおよび4bを参照） 特性を変更するためのオプションは索引のオ ンライン再編成で最も重要な利点です。デメ リットは、再編成のオペレーションがまだ完了 していない場合、ディスク上にオリジナルおよ び新しいコピーを格納しなければならないの で、より多くのディスク領域が必要ということ です。 オ ペレ ー ション は 、S Q Lコ マ ンド A L T E R INDEX<index_name>COALESCEによって 開始されます。オンライン再構築のように、オ ンライン結合は並列処理とパーティショニング をサポートします。 ONLINE TABLE REORGANIZATION オラクルは2つのタイプの表をサポートしま す。 「クラシック」なタイプはヒープ構成表（通常 の表） 、または単純にヒープ表と呼ばれます。 ヒープ構成表は単にレコードの無秩序のセット です。個々のレコードへの高速なアクセスのた めに探索ツリーが要求される場合、ユーザー は表に加えて索引を作成しなければならない でしょう。索引構成表は、1つのセグメント内 に表データおよび探索ツリーを組み合わせた ようなもので、Oracle8iで導入されました。 索引構成表はそれほど一般的ではありません が、オンライン再編成（索引構成表用の再編成 メカニズム）が、Oracle8iからサポートされて います。その他のすべての表に対するオンラ イン再定義は、Oracle9iから導入されました。 これらのオペレーションは、ユーザーが最適の パフォーマンスと連続的なデータアクセスの 両方の恩恵を受けることを保証します。 6 Online Table Move and Coalesce for IOT Oracle8iとOracle9iは、ユーザーが表のデ ータにアクセスし、更新をしている間、索引構 成表（IOT）が再編成することを可能にします。 IOTが基本的に完全な表データを含んでいる 索引であるという側面から、索引で利用可能 な2つのオプションを管理者が選ぶことができ るのも驚きではありません。オンラインで表 のコピーを作成しながら再編成する、または領 域を気にせずに表を結合することができます。 表のオンライン移動は、SQLコマンドALTER TABLE<iot_name>MOVE ON-LINEによっ て開始されます。それは記憶特性を変更した、 または変更のないIOTの新しいコピーを作成 するために使用することができます。オペレー ション中の表への変更はジャーナル表に記録 され、オペレーションの完了後にマージされ ます。 表のオンライン結合は、SQLコマンドALTER TABLE<iot_name>COALESCEによって開 始されます。結合のオペレーション自体がデフ ォルトでオンライン・オペレーションであるの で、ONLINE節は必要ではありません。１度に 少数のブロックをロックし、ブロックの結合が 完成すると直ちに解放します。オペレーション は探索ツリー構造を再編成し、ブロック断片化 を縮小し、結果としてストレージの使用率と問 合わせのパフォーマンスを改善します。 両方のオペレーションとも、 １つのIOT、あるい はパーティショニングされたIOTの中の１つに 対して実行することができます。 日本HPは、貴社のビジネスを強力にサポートします。 今年度もSAP AWARD OF EXCELLENCE 2003を受賞しました。 パートナ様と共により良い信頼を頂ける様、 テクノロジ支援とサポート・サービスに幅広く対応してまいります。 今後の日本HPにご期待ください。 Oracle8iへの拡張機能として、Oracle9iでは、 IOTの第2の索引および追加の索引タイプのオ Oracle Internet Directory 9.2 for SAP ンライン再編成をサポートしました。Oracle9i は、逆キー、ファンクション、キー圧縮といった 索引タイプのサポートを追加しました。 SAPは、mySAPテクノロジ・インターフェース（LDAPによるユーザー管理のためのディ レクトリ・インターフェース）内のセキュリティ・ソリューションのコンポーネントとして Oracle Internet Directory 9.2（OID）を認定しました。 Online Data Redefinition ここまでの記事から、見あたらないことはヒー プ構成表用のオンライン再編成メカニズムで す。データのオンライン再定義はこのための メカニズムを提供します。名前から連想され るように、管理者が表の構造と特性をオンライ 図5a： 時間に基づいたアーカイブは ブロックを完全に解放し、 関連するレコードの 新しいグループを 1つのブロックに挿入できる ンで再定義することを可能にします。これは次 のものを含んでいます。 ● パーティショニングされていない表をパーティ ショニングする、またはその逆 ● 索引構成表をヒープ構成表にする、またはそ ● 主キーでない列のドロップ ● 新規列の追加 ● 追加、削除の並列サポート ● パラメータ修正または新規の表領域に表を の逆 移動させること SAPの顧客はこれらすべてのオプションを利 用することは稀でしょう。しかしながら、デー タのオンライン再定義がすべての表のタイプ のオンライン・メンテナンスのために設計され た非常に強力なメカニズムであることは容易 に理解頂けると思います。ヒープ表の再編成 は容易な作業のうちの1つです。 Oracle9 i以前にも表の再定義は可能でした。 (1)export/import、または、(2)ALTER TABLE MOVE コマンドです。ダウンタイムが 発生するため、どちらの方法も大きなOLTP表 にはふさわしくありませんでした。この問題を 解決するために、Oracle9iはDBMS_REDEFINITIONパッケージを使用して、表のオンラ イン再定義を提供しました。 作業プロセスは類似しています。表の新しいコ ピーが構築されている間に、オリジナルの表 の索引がオンライン再構築されます。オリジナ ルの表は再定義の間にすべての読み取りおよ び書き込みオペレーションによってアクセス可 能です。DMLオペレーションの結果は最新版 の作成に備えて一時表に蓄えられます。一旦 新しい表が完成すれば、最新版はマージされ ます。また、オリジナルおよび新しい表の名前 はデータ・ディクショナリの中で交換されます。 このステップはDMLロックを要求します。しか しながら、切り換えのプロセスは非常に簡潔 で、表のサイズあるいは再定義の複雑さに依 存しま せ ん 。一 旦り切 換 え が 完 了 す れ ば 、 DMLはすべて新しい表に対して処理されます。 ADVANTAGES OF PARTITIONING 同じように既にブロックレベルの断片化につい てのセクション中で述べたように、解放された 領域が補充されるので、表の再編成は周期的 なアーカイブ後に必要ではありません。しかし 準が選ばれる場合、データ・ブロックが完全に 管理されます。アーカイブが実行される場合、 解放されるでしょう。後で、関連するレコード の新しいグループが挿入される場合、それら データが格納されているパーティションのみ削 除されます。しかし、他のすべてのパーティショ は1つのブロックに挿入することができます。 （図5aを参照） ン表には影響がありません。この場合、半分が 空のブロックは問題ではありません。パーティシ 追加のアーカイブ（プラントまたは原価部門の ョニングによってブロックの場所自体が分かれ ているからです。さらに、1つのパーティション ような）の使用は、恐らく部分的に空になるデ ータ・ブロックを大量に生じさせるでしょう。 表あるいは少数のパーティション表の再編成は、 表全体の再編成よりはるかに簡単で高速です。 SAPまたはサード・パーティのシステムを利用してデータを集中管理するために、ライトウ ェイト・ディレクトリ・アクセス・プロトコル（LDAP）を用いて、外部ディレクトリを使用する ことができます。これらの中央集中型のディレクトリは、ユーザー・データ、セキュリティ・シ ステム・リソースおよび配置パラメータ のような情報を含むことができます。 この認定により、 「OIDはSAPと共に使 用できますか？」あるいは、 「OIDは SAPをサポートしますか？」といった 質問にYESと答えることができます。 重要なことは、OIDとSAP AS 6.1 の統合がORACLEの機能ではなく SAPの機能で検証されたというこ とです。 そうなると、新規のレコードのグループは、1 つのブロック内に収まりきらず、2つ以上のブ ロックにまたがって格納される必要がありま す。これはもちろん厳密な意味ではブロックレ ベル断片化ではありません。しかしながら、ユ ーザーが注文の関するレコードを読む必要が あれば、2つ以上のI/Oリクエストが必要なの で、これらのレコードは非効率的に格納されて いるといえます。メモリ上にも、より多くのブ ロックが必要となるため、パフォーマンスの悪 パーティション表は、オラクル内の独立したオブ ジェクトとして扱われるので、アーカイブ実行後 に、個々のパーティション表を簡単に削除、マー ジすることができます。 さらに、個々のパーティ ション表が個別のファイルあるいは表領域の中 で作成される場合、ディスク領域をファイル・シ ステムのレベルで解放することができます。 初回の再編成（オンライン・データ再定義）は 図5b： 追加のアーカイブはブロックを 完全に解放しないため、 関連するレコードのグループは 2つ以上のブロックを またがり挿入される 化の原因となるでしょう。 （図5bを参照） この問題を解決する効率的な手段はオラクル のパーティショニングです。パーティショニン グは、特定のキーに基づいて表を分割する技 術です。例えばVBRK、VBRPおよびVBFAで す。これらの表のキーは、VBELNフィールド （あるいはそれに関連したフィールド）から成り ます。これらのフィールドを用いて、エントリー 時間をレンジ・パーティションのキーとして使 用し、分割することができます。 パーティショニングされていない表をパーティ ション表に変換するために必要です。さらに、 パーティショニングするためのキーが継続的に 変化するので、新しいパーティション表は個々 の新しい期間（例えば月ごと）において利用可 能にする必要があります。しかしながら、多く のパーティション表を前もって作成することが できるので、これは問題にはなりません。 より詳細な情報については、OSSのノート 572060を参照して下さい。 ながら、このステートメントは、アーカイブで保 管されるレコードの選択が時間に純粋に基づ く （例えば、3から6か月の間に作成されたす べてのレコード）と想定します。そのような基 8 目的はVBELN番号で振り分けたパーティショ ン領域を作成することです。したがって、各パ ーティション表は、例えば１か月といった単位で 9 オラクルと富士通・シーメンス・コンピューターズ ジェクトを開始しました。Oracle9i RACは、複 数のノードへのオペレーションに対して、可用性 最先端技術のコンビネーション とパフォーマンスを向上させることができます。 MCOD（Multiple Components in One Database） はさらに、OLTPおよびOLAP（例 オラクルと富士通・シーメンス・コンピュータ ーズは、mySAPのためのOracle9i RAC をFlexFrameを使用して評価します。 What is behind FlexFrame for mySAP? この新しいソリューションを特別に可能にする のは複数の革新的なコンポーネントの組み合 わせです。例えば、標準化されたサーバー・モ とができるのです。 ジュール、ブレード・サーバー、SAPソフトウェ アの仮想化、NetAppファイラーのSnapshot FlexFrameは、既存のmySAP環境が頻繁か つ、急速に変化しているような顧客にとって、 機能などを高可用性のために、あらかじめ構成 された状態で出荷します。運用とサービスの可 コスト・メリットの面で非常に興味深いものと なっています。さらには、R/3からmySAPへ 用性を24時間×7日で保証しながら、迅速な 拡張を保証します。さらに、mySAPランドスケ とシステムを統合・拡大したい顧客にとっては ープのためのバックアップ、クラスタリング、モ ニタリングおよびリモートアクセス用のコント 理想的な環境です。FlexFrameの目的は明白 に定義されています。柔軟さを求められつつ、 システムの停止が許されないようなビジネス ロール・ノードまで機能に含まれています。 環境において、この新しいビジネス・クリティ Oracle9i RACおよびFlexFrameの組み合わ せによるメリットは以下の通りです。 リティ、高可用性、中央管理およびモニタリン グを高度に実現している点です。mySAP環境 ● SAPシステムの最大の高可用性 ● 運用と拡張における柔軟性 と呼ばれるmySAPのためのITインフラストラ クチュア上で明瞭かつ柔軟な運用が可能にな ● 管理の単純化、特にバックアップ/リストア ります。著しいTCOの削減を実現する、ネット ワークアプライアンスおよび富士通シーメン ス・コンピューターズによる革新的な開発によ り、複雑なmySAP環境の導入および運用を容 易にします。 したがって、オラクルと富士通・シーメンス・コン ピューターズは、mySAPのためのFlexFrame のフレ ームワーク内 のブレ ード・サ ーバ ー、 Oracle9i RACおよびNetAppファイラーの組 み合わせをテストし最適化する共同の評価プロ に お け る 更 な る メリット を 得 る た め に 、 Oracle9i Release2がIntel Itanium2 システムに対応 mySAPビジネス・アプリケーションの実行にとっ て理想的です。mySAP環境では、できるだけ カルなコンピューティング・ソリューションによ り 「SAPソフトウェア・サービス・オンデマンド」 を達成することができます。FlexFrameの主 な利点はシステムのセキュリティ、スケーラビ 複雑なmySAPランドスケープは、FlexFrame Itanium 2プロセッサは、インテルによる64ビッ ト・プロセッサです。64ビットのプロセッサ・ア ーキテクチャは、Oracle9i Databaseおよび えばR/3およびBusiness Warehouse） のデ ータベースを統合して、Oracle9i RACと使用 することができます。mySAPで効率的にIT資 源を使用するためにFlexFrameを使用するこ 多くの情報が管理できるように大量のメモリが 要求されるからです。メモリ内にデータを多く 保持できれば、Oracle9 i Database上の SAPシステムでのトランザクション処理のスル ープットは向上します。Itanium 2プロセッサ IDCの調査によれば、オペレーティング・システムの市場シェアの約70%はLinux、およ びWindowsで占められています。現在のトレンドは、標準のインフラストラクチュアを選 ぶ方向です。インテルはそのためのビルディングブロックを提供しています。8、16のお よび32以上プロセッサ数に拡張できるItanium2アーキテクチャは、TPC-Cのベンチマ ークで世界トップクラスのパフォーマンスを提供します。また、クラスタでない4CPUマ シン上のOracleデータベースを使用したSAP-SDベンチマークでは、5$/tpm-cという コスト・パフォーマンスと80000tpm/cという結果を残す高度なハードウェア・アーキテ クチャであることを証明しました。サーバー統合には必ずしも大きなマシンは必要ではあ りません。インテルの32ビット環境で動作するOracle9i RACを用いれば、企業は既存 のITインフラストラクチュアを統合し、要求されるハードウェア・スペックを手に入れるこ とができます。 サーバー統合による一番の利点は、リソースの集中化とデータの統合です。Linux Xeon マルチ・プロセッサ・サーバーとOracle9i RACの組み合わせは、サーバー統合を達成す る非常によいアーキテクチャ・コンセプトです。 Werner Schueler, インテル・ヨーロッパ アライアンス・マネージャー FlexFrameとOracle9i RACを組み合わせて 使用することが重要です。 の64ビット・アーキテクチャは、mySAPアプリ ケーションとOracle9 iデータベースにおいて 大容量のデータを主メモリ上で処理することを 可能にします。現在までの32ビット・アーキテ クチャはメモリ総量が4ギガバイト以内に制限 されていました。 オラクルは、迅速に64ビット・アーキテクチャ のアドバンテージを利用し、64ビット・システム のためにデータベース・アーキテクチャを最適 化する努力をしてきました。 Oracle9i Database Release2は、さまざ まなメーカーのすべての64ビット・プラットフォ ームで利用可能です。それは、1999年に64 ビット・バージョンのR/3が、オラクルのデータ ベースで動いた驚きからみれば、たいしたこと ではありません。オラクルの64ビット技術の優 位性は、Intel Itanium 2ハードウェア上の Linux64、HP-UXおよびWindows2003に Oracle9iを供給することにより今後も継続さ れていきます。 SAPおよびオラクルの開発チーム間の綿密な 協力関係は、Oracle9i上のSAPアプリケーショ ンが非常に迅速にItanium 2システム上で動作 することを可能にしました。現在、Linux64、 HP-UXおよびWindows2003のItanium2シ ステム上で、Oracle9i Database Release2 とSAP R/3 4.6Cの組み合わせがテストされ ています。 現 在 の 計 画 で は 、O r a c l e 9 i で 動 作 する mySAP製品は、Linux64、HP-UXおよび Windows 2003のItanium2システムで 2003年の夏ごろ利用可能になる予定です。 10 IT-Energy バ ートン 社 は 、さらに S A P の B u s i n e s s Information Warehouse（BW）モジュール for Halliburton の350ギガバイトの実装をサポートするため にオラクルを利用しています。R/3およびBW の本番システムに加えて、さらにR/3本番デー Managing Massive Volumes in SAP 1919年に設立されたハリバートン社は、世 界の石油、エネルギー産業に対する製品およ びサービスを提供する企業です。ハリバートン 社は、100カ国以上で85,000人の社員が働 いています。ハリバートン社のエネルギー・サ ービス・グループ（ESG）は、石油、エネルギー 産業に製品およびサービスを提供します。ま マイグレーション事例 4日間でDB2からOracleへ、 高可用性の実現とTCOの削減 タベースの夜間コピーや、読み取り専用のレポ ートを作成するインスタンス、開発インスタン スなどさまざまなシステムがOracleデータベ ース上で動作しています。 １日は駅の売店から始まります−ヨーロッパ最大のメディア小売業者であるキオスク AGは、SAP R/3 システムのダウンタイムを減らすことが非常に重要な目標でした。 SAPシステムのパフォーマンスは1秒未満の レスポンスを要求される非常に厳しい条件に も関わらず、期末のピーク時の平均レスポンス 時間は0.5秒という非常に良い値を示してい た、KBRグループはエネルギー産業に対して、 エンジニアリング・コンストラクションのサー ます。Oracleデータベースの技術はこのレベ ルのパフォーマンスを保証するのには不可欠 ビスを提供します。 です。 1996年に、ハリバートン社は、グローバルな ERPプロジェクトを開始しました。2000年問 The Future of Halliburton, SAP, and Oracle 題を解決し、かつ、組織に縛られずにビジネ ハリバートン社の今後の挑戦は、さらにビジネ ス・プロセスを標準化するためにERPシステム としてSAPを選択しました。 ス・プロセスを単純化し、効率を改善し、コス トを低減させることです。これら追加のビジネ 1998年から1999年の間で、ハリバートン社 スの挑戦に対応するためにmySAPコンポー ネントのうちのいくつかを導入し始めました。 は、ESG全体とKBRの一部にSAP R/3のモ ジュールと新しい合理化されたビジネス・プロ しかし、当然システム・ランドスケープを複雑 にしてしまいます。 そのため、DB2からOracleへデータベースをマイグレーションするのに時間をかける ことはできませんでした。オラクルからのマイグレーション・サポートは、たった4日で Mike Perroni （ハリバートン社のERPセンター長） マイグレーションに成功するという興味深いプロジェクトを実現しました。 「私たちは、常に成長を続ける企業の総所有コ Careful testing before migration スト（TCO）を低減することができるRACのよ うなオラクルの最新技術に期待しています。 」 1月中旬、Oracleデータベースを採用すること が2つの理由で決定されました。性能面での効 果が評価されたことと、データベース、マイグ レーション・ツールおよびSAPリリースが評価 されたためです。Oracleデータベースを支持 する他の要因は、キオスクAGが既に多くのオ ラクル製品を利用していたということです。さ まざまなアプリケーションで培ったDB管理の ノウハウは無視できない会社の資産でした。 一旦決定が下されると、行動は迅速に行なわ れました。2つのテスト・プラットフォームが作ら セスを導入しました。SAPシステムおよび新 しいビジネス・プロセスは次の2年間で安定稼 動するに至り、2001年11月に、システムは S A P 4 . 6 C に アップグレ ード さ れ ました 。 2002年には初期導入の際にはなかった追加 のビジネス・ユニットも実装されました。同時 に、ハリバートン社は、購入プロセスを合理化 するためにEnterprise Buyer Professional （EBP） という電子調達システムのパイロット運 用を開始しました。 The SAP Operating Environment 結果として、オラクルのシングル・データベース 上で動作する世界で最大のSAPシステムの1 つとなりました。ハリバートン社には、世界でお よそ14,500人のSAPユーザーがいて、その 数は2003年の第14半期には約17,000人 に達すると予想されています。 ハリバートン社のSAPシステムは平均して、1 か月あたり70,000,000のトランザクション 処 理 を 扱 い 、バックグラウンド・ジョブ 数 は 120,000にのぼります。1日あたりのダイアロ グ・ステップ数は300∼350万です。ビジネス が成長し続けるとともに、これらの数は増加し 続けます。こういったSAP環境における高度な データベース要件を満たすために、ハリバート ン社はOracleデータベースを選びました。 「ハリバートン社はデータベースとしてOracle を選びました。それは私たちの要件を満たして おり、 市場に出ている唯一の安全な選択でした」 とMike Perroni（ハリバートン社のERPセン ター長）が言っています。 「 6年後に、我々の非 常に大きなシステム環境に対する唯一の安全 な選択であると考えています。 」 3テラバイトのOracleデータベースが、SAP R/3の本稼動インスタンスで動作しています が、本番データベース（1か月あたり60GBの 割合で成長している）は2003年末までに4テ ラバイト以上になると予想されています。ハリ 12 この複雑さをカバーし、かつ運用コストを削減 するためにハリバートン社は、SAP R/3およ びデータ・ウェアハウス環境で使用されるオラ クルのRACテクノロジを調査しています。今の 環境の可用性を改善させるために、より低コス トな手段としてRACの使用を検討するかもし れません。 3テラバイトの SAP/Oracle データベース 14,500人のSAPユーザー （今後17,000人へ） 1日あたり300∼350万の ダイアログ・ステップ 1か月あたり7,000万の トランザクション 1か月あたり12万の バックグラウンド・ジョブ トロント、カナダの 2拠点のHPデータセンタ （24時間×7日） 2台のSun UNIXサーバー （294CPU） 14台のNTサーバー 63テラバイトEMCストレージと 4.5テラバイトのSunストレージ SAPシステムの運用環境 Stefan Reitinger, SAPプラットフォームのマイグレーション・ プロジェクト・マネージャー キオスクAGは100万人以上の顧客に日々貢献し、1,320の小売り店を運営しています。 キオスクAGは100万人以上の顧客に日々貢 献しています。ドイツやスイスにある1,300の 小売り店を運営しています。6,000の食品ま たは食品以外の製品（キャンディーからタバコ まで）、4,000を越えるメディア製品および 5,500の書籍は、すぐに購入することができ ます。その小売り店に加えて、キオスクAGは、 さらにスーパ ー マ ー ケット の ような 店 舗 で 4,500箇所も出店しています。大量の商品は 毎日、購入、および搬送され、販売データは膨 大になります。SAPプラットフォームのマイグ レーション・プロジェクト・マネージャーおよび キオスクAGのOracleデータベース管理者で あるStefan Reitingerによれば、 「この大量 なデータは、われわれのロジスティクスとITに とって課税のようなものです。 」 といっています。 を満たしていませんでした。これは、計画者が システム変更（現在と将来のニーズに答えるた めに十分によいデータベース要件）をきちんと 考慮していたかに依存します。 「 経済的な理由 のために、私たちは、最初にDB2環境を維持 することを考えました。しかし、時間による制 約で諦めざるを得ませんでした。 」AS/400か らRS/6000までのスイッチはEBCDICから ASCIIへと新しいオペレーティング・システム およびシステム・アーキテクチャに合わせた変 更を必要としました。Oracleは、ベスト・パフォ ーマンスを提供できるデータベース・プラット フォームであるのが分かりました。日々の小売 店データが大量なので、マイグレーションのプ ロセスは、非常に厳しい時間的な制約を受ける こととなりました。 キオスクAGは、2つの商用データ処理システム を管理しています。IBM AS/400の上でパッ ケージ・ソフトは、メディア製品を管理すること をサポートします。 販売データのおよそ3分の 1であるタバコおよび非メディア製品用のSAP R/3システムはオーダー、会計、そして原価計 算をしており、もう１つのAS/400上で実行さ れていました。全体のデータ量が730ギガバ イトを超えた時、データ量がボトルネックにな りました。 キオスク・チームは、データ量の最適解を望みま した。したがって、WalldorfにあるOracle SAPコンピテンス・センターとIBMスイスで利 用可能な構成を検討しました。2000年の終わ り頃には、IBMパートナーのGate Informatic AGと協力して、RS/6000プラットフォームの 導入が実現しました。3つのステージでデータ を管理しなければならないことは、すぐに明らか になりました。SAPのマイグレーション・ツール によるデータ・エクスポート、ターゲット・プラ ットフォームでの変換、ターゲット・プラットフ ォームのOracleデータベースへのインポート です。 「オリジナルのマイグレーション時間は6 ∼14日を作業日数として想定していました。」 と、Stefanは言います。 「 誰もがそれ以上、プ ロジェクトを危険にさらそうとは思いませんで したし、より短いタイムスパンでマイグレーシ ョンが可能であると思っていませんでした。 」 Time is money 2000年の初頭、IT管理部がその問題に取り 組みました。想定よりも少ないデータおよび 低いデータ成長率を基に設計されたAS/400 システムでは、このデータ量はサポートできま せんでした。高機能記憶装置とバックアップ・ システムでさえ、必要とされるパフォーマンス れました。1つは新しいRS/6000ハードウェ ア、もう１つは、IBMのフランスにあるベンチマ ーク・センターで利用可能なコンピューターで す。Stefanによれば「テストは同時に行なわれ ました。フランスのテストは目標とされる結果 を出せなかったのですが、自社で行なわれたエ クスポートよりは良い結果で、96時間で遂行 されました。 」マイグレーション・テストの目的の １つにはデータ変換に関する問題もありました。 従って、マイグレーション・チームはさまざまな サポートを受けながら、データのインポート、 エクスポートに関する検討を行ないました。実 際のマイグレーションに先立って行なわれた、 2回目のテスト・エクスポートが52時間で終え られたことは非常に驚きでした。 2001の復活祭の時期に、すべての準備がで きていました。データ・エクスポート、変換お よびインポートから成る一連のマイグレーショ ンには、ちょうど48時間かかりました。その後、 テスト・チームは、すべてのSAP機能をチェッ クしました（さらに10時間がかかりました） 。 キオスクAGの複雑な異種混合のシステム環境 の多くのインターフェースが同時に確認され ました。マイグレーション・チームは復活祭前 の水曜に作業を開始して、土曜の夜にはシャン ペンのコルクを開けることができました。事後 処理を含めて、マイグレーションには4日かか りました。復活祭の翌日において、各部門にお いてすべてのプロセスがテストされました。ま た、スタッフが火曜の朝に復活祭の休日から仕 事に戻った時、キオスクAGのすべての部署で SAP環境は利用可能な状態になっていました。 Stefanはこうまとめています。 「このマイグレーションは私たちの最善のシナ リオでした。私たちは、この強健なバランス構 成の利点を得て、 目的のすべてを達成しました。 そのため、今後企業が成長していった場合に、 資源が原因でボトルネックが発生することは無 いでしょうし、SAPのアップグレードも容易に なると期待しています。 」 13 有効性 SAP BWにおけるOracle9i データ圧縮 Executive Overview リレーショナル・データベースに格納されたデ ータは、より多くの情報とビジネス要件にあわ せて成長します。大量のデータを維持するこ とに関連したコストの重要な部分は、ディス ク・システムのコストおよびデータを管理する 際に利用された資源のコストです。Oracle9i Database Enterprise Edition Release2 は、リレーショナル表に格納されたデータを 圧縮することにより、コストに対処するユニー クな方法を導入しています。その圧縮された データに対する問い合わせ時間は増えること なく、本質的なコスト削減を可能にします。こ のホワイトペーパーは、2002年夏にSAP、 サン・マイクロシステムズおよびオラクルに よって始められたプロジェクトから報告され たテスト結果をドキュメント化しています。 使用されるデータはSAPによって行なわれ た顧客調査の結果で得られたものでした。ま た、データの量はおよそ5.5テラバイトでし た。テスト結果は、データベース・サイズの 縮小が2テラバイト以上になる可能性を報告 しています。また、データはファクターによ り2∼3回圧縮されました。ディスク領域の 削減は、システムパフォーマンスへ影響なし で達成されました。圧縮機能のために用意し た最悪のシナリオの時でさえ、パフォーマン スは向上しました。しかしながら、この新し いOracle9iの機能を使用する顧客に一番期 待して欲しいことは、ディスク領域を削減で きることです。 Introduction リレーショナル・データベース・システムでは、 圧縮のための時間とディスク領域の間のトレ ードオフが必ずしも魅力的だとは限らなかっ たので、圧縮を利用することはありませんでし た。リレーショナル表に格納されたデータは、 通常圧縮のアルゴリズムの影響を受けます。 典型的な圧縮技術は格納容量を増加させま すが、レスポンスも犠牲にしなければなりま せん。Oracle9 i Database Enterprise Edition Release2は、大規模なデータ・ウェ アハウスで有用かつユニークな圧縮技術を 提供します。この技術により、リレーショナ ル・データのために最適化された標準とは違 う圧縮アルゴリズムにより、ディスク領域を 縮小しつつ、データに対する問い合わせの実 行には全く影響を与えません。更に、顧客は、 バックアップ・リカバリのようなデータ管理 オペレーションの改善されたパフォーマンス を体験できます。Oracle9iの圧縮技術は、圧 縮したデータがディスク領域を削減することを 保証します。 How it Works Oracle9i Database Release2は、デー タ・ブロック中の繰返しとなる値を除去する ことでデータを圧縮します。すべての行・列 14 において重複した値がある場合、ブロックへ のポインタのみが格納されます。重複した値 はすべて参照情報のみとなるわけです。圧縮 したデータ・ブロックは、規則的なデータ・ブ ロックのように見えます。データベース内の プログラムで変更は全く必要なく、通常の操 作イメージで作業ができます。ブロックのフ ォーマットや行と列へのアクセスするプログ ラム部分だけを修正する必要がありました が、修正の結果、通常のデータベース機能は すべて、圧縮データ・ブロックに対しても有効 となりました。 What can be Compressed Oracle9i Database Release2は表とマ テリアライズド・ビューに含まれるデータベ ース・オブジェクトを圧縮できます。パーティ ション表については、いくつか又はすべての パーティションに対して圧縮するか選ぶこと ができます。圧縮属性は、表領域、表あるい はパーティション表に対して宣言することが できます。圧縮が表領域レベルで宣言される 場合、その表領域内で作成された表はすべ て圧縮されます。しかし、圧縮属性を既に備 えた表領域内の表やパーティション表のため の圧縮属性を新たに変更することも可能で す。また、変更はその表やパーティション表 に入る新しいデータにあてはまります。その 結果、表やパーティション表には圧縮ブロック および規則的なブロックを含んでいるかもし れません。表が混合ブロックを含んでいるか もしれないという事実はデータ・サイズが圧 縮の結果、増加しないことを保証するために 利用されます。圧縮がブロック・サイズを増加 させる状況では、圧縮は適用されません。 データの挿入やロードの際に圧縮がかかりま す。オペレーションは以下のものを含んでい ます。 ● ダイレクトパス・ロード（SQL*Loader） ● CREATE TABLE ... AS SELECT ステー トメント ● パラレル・インサート（もしくはINSERT文 へのAPPENDヒント） データベース中の既存のデータも、ALTER TABLE...MOVEを使用して移動させること により圧縮することができます。このオペレー ションは表で排他的なロックをとり、完成する まで最新データのロードを防ぎます。これが 望ましくない場合、Oracle9iのオンライン再 定義ユーティリィティ （dbms_redefinitionと いうPL/SQLパッケージ） は、排他的なロック を無視するため、利用することができます。ま た、Oracle9i Database Release2より前 のリリースでは既に、ビットマップとBツリーと いう2つの索引、さらに索引構成表を圧縮す る機能を持っていました。 Cost and Benefit Analysis Compression Ratio 圧縮による主な利益は何といってもディスク 領域の削減です。圧縮されていないデータの サイズと圧縮したデータの比率は、しばしば 圧縮比と呼ばれます。例えば、圧縮比を2と オラクルは、異なる業界の世界の顧客データ で圧縮をテストしました。大きなデータ・ウェ アハウス用の典型的な圧縮比は2:1から4:1 までですが、より高い圧縮比も試されました。 すると、圧縮されていないデータが圧縮した データの2倍のディスク領域をとることを意 味します。 大量のデータのために高い圧縮比を達成す ることができる場合、生じる利益は絶大です。 データアクセスの形態によっては、間接的な 利点に形を変えます。例えば、アクセスが全 例えば、メジャーな電話会社のデータでは 12:1の圧縮を実現しました。 表走査を含んでいる場合、圧縮した表の方が オペレーションは速くなります。 技術で更に圧縮できる場合があります。 SAP BWのテスト・シナリオでは、主要な目 標とするオブジェクトの圧縮比率を達成しま した。オラクルの圧縮アルゴリズムは重複ブ ロックの除去で領域を圧縮しますが、追加の さらに、圧縮により大量のデータがデータベ ース・キャッシュで維持されることを可能にし 最初に、データにおけるデータ・ブロックの重 複 を 除くた めにロード 処 理 を 行 な います。 SAP BW開発チームによる実装によるハード ます。圧縮した表が索引によってアクセスさ れる場合、データベース・キャッシュ上で見つ かる可能性が増えるので、パフォーマンスが 向上するかもしれません。圧縮した表の利点 は、索引のためのよりよいクラスタリング要 因を持つ傾向があるということです。 ルをなくすために 「最も容易な」方法で圧縮機 能 の 使 用 を 可 能 にし ました 。そ の た め 、 GROUP BY節が用いられるようなサマライ ズされたデータは圧縮に対して理想的な候補 です。さらに、より大きなブロック・サイズは、 一般に良い圧縮効果があるといえます。 Cost of Compression in General 私たちのテスト環境では、ブロック・サイズは 32KBにセットしました。また、テストの間に ソート・オプションは利用しませんでした。理 オラクルのユニークな圧縮技術では、圧縮し た表にアクセスするために通常は必要とされ る高価な解凍オペレーションはありません。 データ圧縮はデータをロードする際に実行さ れます。また、圧縮するデータに関連したオ ーバーヘッドもありません。 ローリング・ウィンドウ管理を使用する場合、 データ・ウェアハウスでのロードの影響が最 小になるので、増加するはずのロード時間は 意外と少量ですむかもしれません。一旦デー タがロードされれば、圧縮した表あるいはパ ーティション表は通常のオブジェクトのように 使用することができます。データはINSERT、 UPDATEおよびDELETEコマンドを使用し て修正することができます。圧縮されていな いデータを削除する場合に比べ、圧縮したデ ータの削除は高速に実行されます。 あるケースにおいては、圧縮したデータの更 新が通常の更新よりも遅いかもしれません。 また、圧縮したデータを修正する場合、ディ スク断片化が生じるかもしれません。例えば、 行が削除される場合、削除された行によって 占領されたブロックは解放されます。しかし、 圧縮された行が解放した領域は、必ずしも物 理的に解放されるとは限りません。 由は簡単です。SAP BWの顧客サイトでこの 最適化を実装するためには、BWをロードする コードを変更することが必要になるからです。 コード変更も可能かもしれませんが、私たち は、結果がSAPの開発努力に依存することは 望みませんでした。そういったSAPの機能に よらずに、テストの結果、データが圧縮ニー ズを満たし、10 - 20%を節約することがで きたことを証明しました。 表の記憶属性は、圧縮比に影響します。例え ば大きなPCTFREEは低い圧縮比に結びつ きます。圧縮した表で頻繁な更新は発生しな いので、PCTFREEを0にセットすることは圧 縮したデータを格納するすべての表で推奨さ れます。 注：PCTFREEは、COMPRESS属性で作成 されたすべての表に対して自動的に0がセッ トされます。 Performance Impact on Loads and DML in General データの圧縮はロード（DMLステートメント） のパフォーマンスに影響をおよぼします。オ ラクルは、圧縮のパフォーマンス特性を測定 するために多くの実験をしました。 データ圧縮は、OLTPアプリケーションより データ・ウェアハウス・アプリケーションに向 いています。データ・ウェアハウスではデータ 量が大量であるため、データを再圧縮するこ とが必要でしょう。さらに、データを読み取り 専用にしたり、時系列にパーティションしたり して組織的に管理されるべきです。 圧縮のオーバーヘッドは単純なロード処理に も現れます。CPU使用率を2倍消費するか もしれません。もし、無制限のI/O帯域幅を 備えたシステム上で実行されれば、これは、 データベース層だけを考慮すれば、ロード時 間を2倍にすることかもしれません。しかし ながら、2つの事実から実際のSAP BWシ ステムで、こういったオーバーヘッドがかか らないことを通常は保証します。第１に、ロ ードはシステムのI/O性能を使い切りませ ん。ロードの際には、圧縮機能により読み書 きされなければならないデータ・ブロックの 量を減らすことができます。付加的にCPU 使用率さえも低下させるメリットがありま す。第2に、SAP BWにデータをロードする ことは複雑なデータ加工処理を含んでいま す。それ自体が単独で大量の時間を必要と します。 圧縮のオーバーヘッドは、ロード・プロセス全 体に比べて非常に小さな割合です。圧縮した 表のデータを作成するステップで、圧縮して いないシナリオと比較して、データベース上 で80%以上のオーバーヘッドを測定しまし た。ところが、SAP BWで完全なタスクを行 なうことを考えればトータルで5%未満のオ ーバーヘッドになります。したがって、SAP BWの顧客へのインパクトを評価する場合、 アプリケーション層を考慮に入れることが不 可欠です。 ノンバルクINSERTオペレーションの実行に おいて圧縮、非圧縮によるパフォーマンスに 違いはありません。理由は、従来のINSERT オペレーションが圧縮を利用しないというこ とです。パラレルのINSERTかCREATE TABLE ... AS SELECTのようなバルク INSERTオペレーションおよび、APPENDヒ ントを備えたINSERTは圧縮を利用するので 圧縮によりロード・パフォーマンスに影響が でます。 DELETEオペレーションは圧縮した表では 10%高速です。利益は圧縮した行がより小 さいという事実から得られます。処理におい て、表を掃除するような余分な作業はこのオ ペレーション中に行なわれません。 UPDATEオペレーションは主として圧縮さ れていない表のために実装された複雑な最 適化のため、圧縮した表は10-20%遅い結 果となりました。ただし、将来圧縮した表の ために新しく機能が実装される可能性はあり 得ます。 圧縮したデータ上での問い合わせは圧縮さ れて い な い デ ー タより一 般 的に高 速 です。 I/O幅の問い合わせについては、圧縮したデ ータへのアクセスが著しく速いかもしれませ ん。一方、問い合わせはバッファ・キャッシュ からそのデータをすべて得るので、圧縮され たデータは非常に有用です。 SAP BW Test Results テストは、BW 5テラバイト・プロジェクトと してSAPとサン・マイクロシステムズによっ て使用されるシステム上で行なわれました。 構成情報、ビジネス・モデルおよびワークフ ローの詳細に関するテストのレポートは次の URLにあるプロジェクト・レポート・ホワイト ペーパーで確認できます。 http://www.sun.com/solutions/thirdparty/ -sap/-collateral/index.html http://service.sap.com (section BW/Media Center) プロジェクトはWinter株式会社によって監査さ れ、要求があり次第対応する報告書を提出でき ます。テストは、72CPUおよび24のT3アレ イを備えたサン・マイクロシステムズE15000 サーバー上で行なわれました。SAP BW 3.0、 Oracle9i R2、そしてSolaris 9がソフトウェ アとして使用されています。 圧縮テストは、オリジナルのプロジェクトのほ とんどすべてのステップで行なわれました。 ただ１つの例外は、圧縮したInfoCube（ファ クト表を表わした）とPersistent Staging Area（PSA）間のデータの転送を含むステッ プでした。表レベルの圧縮フラグに加えて、 バルク・インサートか、ヒントを追加するかを 要求します。しかし、結局はInfoCubesと集 約の間のデータを転送するステップに起因し ます。このタスクは、同様のデータを備えた 同タイプのSQLステートメントおよびデータ ベース・タスクで終了します。 Loading ASCII File Data Into Persistent Staging Area (PSA) Tables Persistent Staging Area（PSA）はソー ス・シ ス テム か ら 要 求 さ れ た デ ー タ が 、 DataSourceに定義された構造によって保 存される場合、データの初期の記憶エリアの 役割をする透過表のセットです。 R/3の960個のアスキーファイルをPSA表 へロードするプロセスのために、セントラ ル・インスタンスで3つのバッチ・プロセスお よびそれぞれ4つのバッチ・プロセスが稼動 する20のアプリケーション・サーバー、つま り83のバッチ・プロセスによる処理が行なわ れ ました 。圧 縮 さ れ て い な い P S A 表 に 11,680,000,000のレコードをロードする のに45時間かかりました。それは毎時2億 6000万を越えるレコードの処理を意味しま す。1 2 0 0 万 のレコ ード を 備 え た 単 一 の InfoPackageによって要求された平均時間 は、4時間でした。ロード中の平均のCPU消 費はおよそ70%でした。また、平均ディスク 使用率はデータベース・ファイルを格納する ディスク上の10%、アスキーファイルのディ スクの95%以上でした。 15 ロード・プロセスのほとんどが、ASCIIデータ を読むことについてのI/Oでした。目標とす るPSA表で圧縮を使用することで、80の PSA表がもとは3.5テラバイトだったものの 1.1テラバイト分が圧縮されました。すべて のデータの70%がPSAのオブジェクトに格 納され、これらの保存がパフォーマンスへの 影響なしで達成されたことは非常に興味深い ことです。本番システムでは、同じタイプのデ ータがOSD表に格納されるのでPSAより大 きな圧縮特性を持つ傾向があります。顧客は このような利点を経験するべきです。 ロード実行に関して、測定可能な効力は起こ りません。私たちが、PSAとOSDの表のエ リアで領域が圧縮される可能性があるので、 圧縮していないオブジェクトから圧縮したも のまで移行する速度に関する測定をしまし た 。い くつ か の 理 由 に よ り、テ スト は 、 ALTER TABLE MOVEステートメントを使 用するという最も速い方法を使用しませんで した。しかし通常のパラレル・インサートのメ カニズムでさえ、毎秒およそ150万行の処 理能力を提供します。 90秒で1億4600万行のInfoCubeの移行 を するでしょう。テスト・シ ナリオ（ 8 0 の InfoCubeおよび80のPSA表）の大きな表 はすべて4∼5時間で移行しました。この速 度を達成することが私たちのテストで重要 で、72のSparc III CPUは使いきられてい ました。そして500MB/秒のランダム読み取 り/書き込みを行ないました。 Creating Indexes on the Persistent Staging Area (PSA) Tables P S A へ の ロ ード を 高 速 に 行 なうた め に 、 PSA表の索引はドロップ後に再作成されま す。PSAからキューブへデータをロードする 際に索引が必要です。また、ディスク・ソート を回避するためにソート・エリア・サイズは 10∼70MB、次に索引生成のために増加さ れた10の並列プロセスがあります。 圧縮されていないPSA表の索引すべての作 成は、ほぼ15時間かかりました。圧縮した PSA表の索引生成は10時間と、さらに速い 結果でした。このステップの性能はオリジナ ルの測定よりも改善しました。また、圧縮し たPSA表は圧縮されていないものより4時 間高速に作成されました。 Creating Database Statistics on the Persistent Staging Area (PSA) Tables したがって、PSA表のデータベース統計は 10の異なるPSA表に10の並列のジョブを 16 使用して作成されました。表が圧縮されてい なかった時、PSA表統計をすべて作成するた めにほ ぼ 1 9 時 間 か かりました 。圧 縮した PSA表の構造上の同じタスクは7時間だけで 上の800の索引の作成は、ほぼ同じ量の時 間がかかりました。私たちが索引構造のため に圧縮機能を使用しなかったことに注意して ください。通常、顧客のサイトでは、索引の は、CPUパワーをすべて使用する場合、ソー ス・データを圧縮しない場合のCPUオーバー ヘッドに比べてネガティブに作用します。 すみます。このタスクのI/Oは、圧縮したオブ ジェクトをサポートする大きな意味について 説明することができます。圧縮したオブジェ クトがオリジナルのサイズの約1/3だけであ ると心に留めておいてください。 非常によいバッファ・ヒット率を得るようにす べきで、この領域を無視することができます。 この過程の中で面白いポイントは、集約のレ ベルによって領域削減の可能性を調査したテ ストでした。集約は、データベースの視点か ら見て正常な表でありますが、容易に圧縮す る こ と が で き ま す。圧 縮 比 の 可 能 性 が InfoCubeの1つとほとんど同じだったという 点は面白いことです。 Loading Data from PSA Tables into InfoCubes and ODS Objects 5TBのデータ・ウェアハウス作成の次のステッ プは対応するInfoCubeおよびODSオブジェ クトの中へのPSA表のデータのロードでし た。InfoCubeにPSA表からデータをロード することは、フラット・ファイルからPSA表へデ ータをロードするよりCPUを要するので圧縮 機能が非常に効果的です。セントラル・インス タンスは3つのバッチ・プロセスを実行するた めにセットアップされ、25のアプリケーショ ン・サーバーが、それぞれ4つのバッチ・プロ セスを実行したので、合計103のバッチ・プ ロセスで処理が行なわれた事になります。 この過程では、1152のロード・リクエストが 処理されます。80のInfoCubeから12ずつ のリクエストと、4つのODSオブジェクトか ら48ずつのリクエストが出されるためです。 合計では、140億を超えるレコードがデー タ・ターゲットに書かれ、このステップは65 時 間 か かりました 。平 均 処 理 能 力 は 毎 時 214,677,532のレコードでした。また、単 一のリクエストのための平均処理時間は約5 時間でした。ロードする過程において平均 94%のCPU利用率および30%のディスク I/Oが確認されました。 圧縮したPSA表の使用はこのステップに影響 を及ぼしませんでした。 既に言及していますが、複雑なアプリケーシ ョン・コードを変更する必要がある場合でも、 それを選択しませんでした。しかしながら、デ ータベース・タスクに関して、InfoCube表か ら集約表までデータを転送する場合、私たち は同様のステップを行なっています。データ ベース・レベルでのスローダウンだけで、ア プリケーションにおいては1%未満のレベル での影響ですむことがわかりました。 Creating Indexes on the InfoCubes PSA表のロードの場合、InfoCube表の索引 はロード前にすべてドロップされました。80 の圧縮されていないInfoCube（1つのキュー ブ当たり8つの索引）の索引をすべて再作成 するのに約3時間を必要としました。最高32 個の索引は、並列のアプリケーション・ジョブ （4∼6つの並列のオラクル・シャドウ・プロセ ス）で生成されました。圧縮したInfoCubeの Generating Database Statistics of InfoCubes 集約が作成される場合、オラクル・オプティ マイザがデータへの最良のアクセス・パスを 選ぶために、InfoCubeの上で直接実行され るクエリだけでなく、マスター・データの表に 最新の統計を持っていることは重要です。し たがって、完全なオラクル・データベース・ス キーマはこの時点で分析されます。すべての 適切なデータ・ベース統計の生成や分析に は、およそ6時間かかりました。 多かれ少なかれ全体のデータベースの分析 がI/Oに集約的なタスクだったので、圧縮した 表の使用はこのステップに非常に有効でし た。また、60％程度のデータ・ブロックを読 むだけですむことはプロセスの動作を高速に します。したがって、およそ4時間短縮されま した。 注意：私たちのテスト環境はI/Oにボトルネッ クが現れる傾向にありました。したがって、4 つから8つのCPUだけでBWを実行する顧客 は、改善がシステムおよび統計に依存してい るのに気づかないかもしれません。 Creating Aggregates and their Indexes 集約は、劇的にクエリーの実行時間を改善し ます。InfoCubeのために定義された問い合 1つの典型的な大きな集約（/BIC/E100966） の数字によると、圧縮後に66016のブロック が31214まで圧縮されました。集約のレベル で圧縮の可能性を調査することは、より大きな InfoCubeおよびPSA/OSDの表で行なった 圧縮のテストとは異なった意味があります。集 約はウェアハウスのディスクの小さな割合でし かなく、ディスク領域を削減するわけではありま せん。 集約の圧縮の調査で面白いのは、顧客がこれ らの表のほとんどでレポートを作成するだろ うという事実です。また、集約がよりSGA上 の良いバッファ・ヒット率に貢献すると考えら れます。集約のために倍近い圧縮比、バッフ ァ・ヒット率の改善、問い合わせレベルでのパ フォーマンスの向上が得られます。 SAP BWでは、集約がInfoCubeと技術的に 同じ方法で格納されます。表の索引に関する 考察は、集約に同様に当てはまります。したが って、集約の索引はロード前にドロップされ、 集約をロードした後に再作成されます。圧縮 されていない集約上の索引を作成するのに必 要な時間は約1時間でした。圧縮された場合 も同様の実行時間が測定されました。 わせに基づいて、レスポンスを改善するため に10の集約が各キューブのために設計され ました。 User Queries 集約は並列で作成されました。最高で5つの 集約が同時に作成されました。しかしながら、 Oracleデータベースのレベルでは12の並列 処理であり、各集約について、12のプロセス が、InfoCubeファクト表から集約表にデータ SAPは、典型的なシステムで期待される問い 合わせのタイプと量に関する情報を集めるた めに顧客調査を行なってくれました。しかし ながら、テストの他のフェーズと異なり、問い を同時に読み書きしていました。 圧縮されていないInfoCubeからデータを読 むとき、800の集約の生成は約14時間かか りました。圧縮したInfocubeからソース・デ ータを集める作業は、わずか3％の実行時間 の増加ですみました。このステップに性能差 は、構築されなければならなかった集約の種 類に極度に依存しました。 集約がソース・データを要約しない場合、こ のステップはI/Oに敏感な傾向があります。し たがって、圧縮は有利だといえます。他方で このテストは「実際の世界シナリオ」と一致す るた めに、最 も 困 難 な も の を 選 び ました 。 合わせ結果が一般的な有効性が認められる レベルに達することができませんでした。 既に言及している通り、テストを生成すること は容易です。圧縮はデータベース・バッファ・ キャッシュの中で改善されたバッファ・ヒット 率を提供します。これらのシナリオは現実的 なものでしたが、私たちの定義した目標とは わずかに異なっていました。大多数の顧客の 問い合わせというシナリオをシミュレートす ることは不可能だったので、圧縮オプションを 使用する場合に最悪のシナリオを想定するこ とにもっとも興味を持っていました。 ブロックがすべてバッファ・キャッシュに既に ロードされているので、I/Oの減少が圧縮に より達成できない環境であるべきです。驚い たことに、このテストは圧縮した表のための 明瞭なメリットを示しました。さらに、圧縮が メモリのみに影響するようにすることが可能 でした。 テスト環境を使用し、全表走査を使用して、 InfoCubeのデータすべてにアクセスしなけ ればならない問い合わせは、圧縮されていな いInfoCube表で11秒で終了しました。バッ ファ・キャッシュ・ヒット率は100%でした。ま た、並列のプロセスは72のCPUすべてを使 用しました。 トを縮小します。また、実行時間の性能を落 とすことなく実現しています。典型的な圧縮 アルゴリズムを利用すれば、それはトレード オフの関係になるはずです。 テストの結果、パフォーマンスのアドバンテ ージがあることを証明できしました。データ ベース・サイズは、5テラバイトから2テラバ イト未満に減らされました。また、全体の実 行時間の性能はおよそ10%短縮されまし た。しかしながら、パフォーマンスの影響は データ保存の領域が正確に見積もれないの と同様に一般化することができません。 こういった結果が特定のシステム環境に依存 することはご理解頂けると思いますが、顧客 同じ条件下で、圧縮したInfoCubeの問い合 わせは約8秒でした。以前に完了したテスト （現実的なI/Oロードを使用した）結果、圧縮 の環境によってはパフォーマンスが低下して しまうかもしれません。 を使用するとパフォーマンスは予想通りに改 善されました。 実際の顧客シナリオでは、通常は極限の状況 にいるかもしれませんので、バッファ・ヒット率 が改善されればパフォーマンスはいくらか向 上するでしょう。従って、このプロジェクトは、 表セグメントのためにOracle9i Relesase2 とその圧縮オプションを使用するSAP BW顧 圧縮されていないInfoCubeでの全表走査の 実行時間は、圧縮したシナリオよりほぼ2倍と なりました。31秒は17秒といった具合です。 索引を用いた問い合わせのテストも行なわれ ました 。圧 縮 さ れて い な い 場 合 の 目 標 が 313秒であるInfoCubeのI/Oは、圧縮した ターゲット上で同じ問い合わせを実行すると 254秒でした。 問い合わせにおいてはより良いバッファ・ヒッ ト率を仮定することができますが、本質的に 良いクラスタリング・ファクターは圧縮した表 客が、パフォーマンスとデータ量の削減に価 値を見出すべきだと結論づけています。 データ圧縮は、データ・ウェアハウスの問い合 わせとメンテナンスのタスクに有効です。顧 客はいくつかのパフォーマンスの改善を期待 することができます。しかし、主な目標は、デ ータを保存するためのディスクの削減を目標 に掲げるべきです。 の索引には有効です。 Conclusion ディスクのコストはSAP BWのような大きな データ・ウェアハウスを構築、維持していく上 で大部分を占めます。Oracle9i Database Release2は、データの圧縮によりこのコス 17