SAP Business Information Warehouse向けのOracle

Oracle_for_SAPのコピー 04.5.28 0:55 PM ページ1
Oracle for SAP Release Matrix
Oracle for SAP Release Matrix
SAP R/3 Version 3.1 I, 4.0 B, 4.5 B, 4.6 B:
SAP NetWeaver’04:
8.1.7 32-bit:
Intel NT/Windows2000/XP, Intel Linux,
IBM AIX, HP-UX PA, Reliant UNIX, Solaris
8.1.7 64-bit:
HP Tru64, IBM AIX, HP-UX PA-RISC,
Reliant UNIX, Solaris
9.2 32-bit:
Intel NT, Windows2000/XP, Intel Linux
9.2 64-bit:
HP Tru64, IBM AIX 5.1, HP-UX PA-RISC,
Reliant UNIX, 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 PA-RISC/IA-64,
Solaris (SUN and Fujitsu-Siemens), Windows2003
8.1.7 32-bit:
Intel NT/Windows2000/XP, Intel Linux,
IBM AIX, HP-UXPA-RISC, Reliant UNIX, Solaris
8.1.7 64-bit:
HP Tru64, IBM AIX, HP-UX PA-RISC,
Reliant UNIX, Solaris
9.2 32-bit:
Intel NT, Windows2000/XP, Intel Linux
9.2 64-bit:
HP Tru64, HP-UX PA-RISC/IA-64, IBM AIX 5L,
Solaris United Linux, (SUN and Fujitsu-Siemens),
Windows2003
SAP R/3 Enterprise 4.7:
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 PA-RISC/IA-64,
Solaris, (SUN and Fujitsu-Siemens),
United Linux, Windows2003
SAP Business Information Warehouse 2.0B/2.1C:
8.1.7 32-bit:
Intel NT/Windows2000/XP, Intel Linux, IBM AIX,
HP-UX PA-RISC, Solaris (SUN and Fujitsu-Siemens)
8.1.7 64-bit:
HP Tru64, IBM AIX, HP-UX PA-RISC, 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 PA-RISC/IA-64,
Solaris (SUN and Fujitsu-Siemens), Windows2003
SAP Business Information Warehouse 3.0B/3.1C:
8.1.7 32-bit:
Intel NT, Windows2000/XP, Intel Linux
8.1.7 64-bit:
HP Tru64, IBM AIX, HP-UX PA-RISC, 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 PA-RISC/IA-64,
Solaris (SUN and Fujitsu-Siemens), Windows2003
Oracle9i Real Application Clusters
SAP R/3 4.6 C/D or R/3 Enterprise 4.7:
HP Tru64 (Ramp Up, up to 10 customers)
IBM AIX (Ramp Up, up to 10 customers)
Imprint
SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow,
WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP
Logo and mySAP are trademarks or registered trademarks of SAP AG in Germany
and in several other countries all over the world.
Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server®
are registered trademarks of Microsoft Corporation.
IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®,
AIX®, S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM
Corporation. INFORMIX®-OnLine for SAP and Informix® Dynamic ServerTM are
registered trademarks of Informix Software Incorporated.
UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.
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.
All other products mentioned are trademarks or registered trademarks of their
respective companies.
本カタログの情報は、2004年6月現在のものです。実際の製品とは内容が異なる場合があります。＊Oracleは、Oracle Corporationの登録商標です。本文中の社名、商品名は各社の商標または登録商標です。© 2004 Oracle Corporation Japan
代理店名
〒1 0 2 -0 0 9 4 東京都千代田区紀尾井町4-1
オラクル製品
お問合わせ窓口
TEL
URL
0120-155-096
http://www.oracle.co.jp/contact/
2004-00-00 SE00（OSE00000）
No. 13 Oracle for SAP, April 2004
®
Oracle SAP
for
SAP R/3 Version 4.6C/D:
safe,
reliable
and
scalable
T
E
C
H
N
O
L
O
G
Y
U
P
D
A
T
E
Oracle_for_SAP 04.5.28 0:29 PM ページ2
2
3
Oracle_for_SAP 04.5.28 0:29 PM ページ4
mySAP.com partner
EDITORIAL
SAP®導入企業様へ
Content
Oracleは、1988年からSAPの開発プラットフォームとしてデータベースを提供しており、SAPを導入されてい
るお客様に15年以上もの間、シェアNo.１という形でご支持をいただいております。今後も、SAPのお客様に、
ごあいさつ
安全で、信頼性の高い、拡張性のあるデータベースをご提供してゆくことをお約束いたします。
Oracle9i Real Application Clusters (RAC)は、SAPシステムにおける、高い可用性と拡張性、TCOの削
減をお約束いたします。また、コスト削減に対する強いご要望に対しまして、グリッド・テクノロジーという新しい
テクノロジーでお応えします。
Oracle 10gは、SAPのお客様にさらなる利益をご提供できる予定です。ご期待ください。
オラクルコーポレーション
SAPアライアンスディレクター
ゲルハルトカップラー
日本のSAP導入企業様へ
日本オラクルは、オラクルコーポレーションと同様に、SAPジャパンとSAP製品を導入される企業様の満足度
向上のため、2002年10月よりアライアンスを開始させていただきました。お陰様で、2003年度はSAPを導
入されるお客様に一番のご支持をいただくことができ、その結果、SAPプラットフォームでのデータベース・シェ
アNo.1（SAP Customer Installation Share 54.1%:Souce SAP Japan）
を獲得することができました。
4
〈成功事例〉セコム株式会社／セコム情報システム株式会社
−Microsoft® SQLTM ServerをOracle9i Databaseでリプレース
6
〈成功事例〉LAUFEN
−SAP® R/3® プラットフォームのマイグレーションを2日間で完了
6
SAP環境におけるデータベース・アップグレードの重要性
9
Oracle Database 10g for mySAPTM
10
Colgate-Palmolive CompanyのSAP BW on Oracle
15
SAP NetWeaverTMとOracle Real Application Cluster（RAC）
16
〈成功事例〉Pollmeier Massivholz Gmbh
−製材工場の利益拡大
Microsoft SQL ServerからOracleへのマイグレーションに成功
18
〈成功事例〉B.Braun Melsungen
−IBM® DB2®をOracle9iにリプレース
19
今後は、SAPを導入される企業様の大幅なコスト削減を実現するOracle9i Real Application Clusters、ス
トレージコストを削減するBWでのデータ圧縮、運用コストを削減するOracle 10gの新機能など、他社には真
似できないソリューションを提供させていただきます。
日本オラクル株式会社
クロスインダストリー本部
オラクル推進部部長
島田淳
Oracleデータベース管理用のSAP BR*Tools
21
SAP Business Information Warehouse向けのOracleテクノロジー
22
Oracle9i Real Application Cluster（RAC）for SAP−FAQ
28
日本オラクル＠常駐隊
31
Oracle for SAP Release Matrix
32
SAPを導入予定／導入済み企業様データベースお問い合わせ窓口
日本オラクル株式会社
SAP アライアンス担当長谷（はせ）
E-mail：[email protected]
SAP アライアンス技術担当岩崎（いわさき） E-mail：[email protected]
4
5
Oracle_for_SAP 04.5.28 0:29 PM ページ6
mySAP.com partner
SECOM
CUSTOMERSUCCESS
セコム株式会社／セコム情報システム株式会社
− SQL ServerをOracle9i Databaseでリプレース
Oracle9i Databaseによるリプレースで、大
規模人事管理システムの可用性、性能が劇的に
向上、安定稼動により大幅に運用コストを削減
セコムでは、人事管理システムが抱えていた可用性の問題を解消
するとともに、将来を見据えた拡張性に富むシステムを実現するた
め、システムの全面的なリプレースを決断。新システムのデータベー
スを社内の他システムで安定した運用実績を誇るO r a c l e 9 i
Databaseへとプラットフォームを変更した。稼働後のシステムでは
きわめて高度な可用性が実現されるとともに、性能面でも劇的な
進化をとげ、運用コストをはじめとするTCOの削減に大きな成果を
Oracle9 i DatabaseによるSQL Serverのリプ
レースを実施
●マイグレーション後のセコムの人事管理システム構成図
アプリケーション・サーバー×2、セントラルインスタンス・サーバー、データベース・サーバーの構成でOSとして
Sun Solaris V480が稼働、各システムの上でSAP R/3 Enterpriseが動作している。
支社・営業所
本社
イントラネット
警備保障を中心としたセキュリティサービスのリーディングカンパ
ニーであるセコム。同社では、人事管理システムのマイグレーション
を実施し、去る2003年10月より稼働を開始させた。システムの構築
データセンター
には、同社の情報システム構築・保守全般を担当するグループ企業
であるセコム情報システムがあたった。セコムの人事管理システム
は、1999年1月にそれまでの汎用機ベースのシステムからUNIXおよ
びOracle7 Databaseのプラットフォーム上にSAP R/3を稼働させ
SAP R/3
アプリケーション・サーバー
Sun Fire V480（Solaris）
SAP R/3 Enterprise
SAP R/3
アプリケーション・サーバー
Sun Fire V480（Solaris）
SAP R/3 Enterprise
SAP R/3
データベース・サーバー
Sun Fire V480（Solaris）
Oracle9i
SAP R/3
セントラルインスタンス・サーバー
Sun Fire V480（Solaris）
SAP R/3 Enterprise
るかたちでオープン化されている。その後、2000年10月には、サー
バー環境をIAサーバーに変更するとともに、OSとしてWindows NT
上げている。
事業部
Server 4.0、データベースにSQL Server 7.0を採用して大幅なリ
ニューアルを実施した。こうしたシステムの変遷のなかで、同社の人
事管理業務は従来のタイムカードなど紙媒体をベースとしたものか
ら、Webブラウザ上での勤怠報告などをはじめ、プロセス全体の
（レガシーシステム）
電子化が実現された。さらに、月次で実施される社員約2万人につ
いての給与計算のバッチ処理に要する時間も短縮されるなど、着
セコム情報システム
サービス本部
テクノロジーセンター
課長
原隆一氏
実に業務のIT化を推進してきた。そして、今回3度目の大規模なシス
テムの変更となったわけだが、その直接のきっかけは、SAP R/3の
保守契約期間の満了とそのバージョンアップに伴うシステム全体
の見直しだった。そこで、まず問題となったのがシステムの可用性で
も大きな魅力でした。さらにセコム情報システム社内にはORACLE
ユーザープロフィール
ある。
MASTERの有資格者も多く、人的リソースの有効活用ということも
セコム株式会社
Oracle9iの重要な選択のポイント」
（原氏）
だったという。
本社：〒150-0001
Oracle9iの圧倒的な信頼性がシステムの安定稼動を実現
資本金：663億円
（2003年9月30日現在）
「旧システムではクラスタの機能の不具合が起きており、予想外の
ダウンタイムが発生し、業務にも少なからぬ影響をおよぼしていま
した」
とセコム情報システムサービス本部テクノロジーセンターの原
隆一氏は当時の状況を説明する。そのほか、システムが連続稼働
を続けると不安定になって処理が遅延するという問題も発生してお
セコム情報システム
サービス本部
テクノロジーセンター
リーダー
島川一樹氏
り、それを安定させるための計画停止を含めて、運用負荷が増大し
ている状況だった。一方、このような可用性の問題とは別に、将来
的なシステムを見据えた場合の課題もあった。セコム情報システム
サービス本部テクノロジーセンターの島川一樹氏は「旧システム導
入時点では、給与計算のバッチ処理の時間も短縮され、とくに問
題となる点はありませんでした。しかし、今回は5年といった長期的
なシステムのライフサイクルを考えており、システムのアップグレード
により可能な限り高度な性能を追求しようと考えました」
と打ち明け
る。同社では、こうした旧システムにおける、障害、計画停止に伴う
業務の中断と、対応に要する運用上のコストの増大という問題を
セコム情報システム
サービス本部
テクノロジーセンター
馬場敏光氏
解消し、今後の長期的なビジョンに立ったシステム構築を目指すた
め、再度、システムの基盤であるOS、データベースのリプレースを
行なうことを決定した。そこで、データベースとして選択されたのが
Oracle9iだった。島川氏は
「Oracleデータベースについては、従来、
このシステムでも利用してきたという経緯があり、また社内の他のシ
ステムでも採用しているため、その圧倒的な安定性は実績として理
解していました」
と採用のポイントを語る。さらに「システムの長期的
な展望に立ったときの拡張性の高さやSAP R/3との親和性の高さ
6
東京都渋谷区神宮前1-5-1
以上のような経緯を経て、稼働を開始した今回の人事管理システム
従業員数：11,779名
（2003年9月30日現在）
だが、稼働後の状況について原氏は「前システムで苦労した可用性
主な事業概要：警備保障を中心としたセキュリティサービス事業を
の問題もすべて解消され、きわめて安定した稼働を続けています」
中核に据える。現在では「社会システム産業」のコンセプトのもと、
と胸を張る。これにより、これまで障害対応や平時の運用に要して
セキュリティシステムの普及を通じて構築してきた日本最大級の情
いた付加的なコストが大幅に削減されたことはいうまでもない。また
報通信ネットワークをベースに情報、メディカル、教育、損害保険、
性能に関しても、給与計算のバッチ処理において16並列処理が可
地理情報サービスなど広範な分野へ事業を拡大している。
能となり、最短35分での完了を実現するなど、同社が最終的な目
URL：http://www.secom.co.jp/
標として掲げていた1時間を軽くクリアしている。さらに、こうした
Oracle9iそのものがもたらした成果に加えて、セコム情報システム
セコム情報システム株式会社
サービス本部テクノロジーセンターの馬場敏光氏は「オラクルの場
所在地：〒150-0001
合、運用に際してのサポートが実に行き届いています。とくに必要な
情報がナレッジベースで公開されていることは、オラクル製品を選
東京都渋谷区神宮前1-5-1 セコム本社ビル5F
資本金：3.5億円
択したことの大きなアドバンテージだと考えます」
と評価する。現在、
従業員数：406名
（2003年6月1日現在）
セコム社内ではこの人事システムをはじめ数々の業務システムが何
主な事業概要： 1984年7月、セコムの情報システム部門を中心に
百台というサーバー群の上で稼働している状況だ。これらの分散さ
ネットワークとコンピュータのシステムインテグレーターとして設立。セ
れたシステムをTCOの観点から、いかに論理的に統合していくかが
コムグループのシステム構築・運用を中心に、受託開発、ビジネス
今後の同社の課題である。
「そうした統合に向けて、全システムの
ITインフラの構築、CRM、eコマース、セキュリティ、ナレッジマネジ
データベースをOracleで統一していく方向で検討中です」
と原氏。
メントシステムなどの分野で幅広いサービスを提供する。
まさにOracleデータベースはセコムの将来的なシステム展望の中心
URL：http://www.secom-sis.co.jp/sishp/
に据えられているのである。
7
Oracle_for_SAP 04.5.28 0:29 PM ページ8
LAUFEN
CUSTOMERSUCCESS
SAP R/3プラットフォームのマイグレーションを
2日間で完了
新規システムへのインポートのさらなるテストや微調整を重点的に行
月曜日の朝には、すべての部門がSAP環境を本格的に使用できま
ないました。本番のマイグレーションが始まったときには緊張した空気
した。もちろん、週末にあらゆるプロセスおよびワークフローをすべ
が流れましたが、エクスポート・テストはわずか8時間で完了しました。
ての部門の観点から検証しましたが、Jacques Nieuwland氏は「マ
2003年6月6日金曜日、その瞬間がついにやってきました。エクス
イグレーション作業は考えうる最高のシナリオだった」
と認めていま
LAUFENは、バスルーム用セラミック製品の世界有数のメーカーで
両方をEBCDICからASCIIに変更する必要もあったからです。
」最終
ポート、データ転送、およびインポートを含む物理的なマイグレー
す。
「現在でも、わが社は堅牢なバランスのとれた構成から利益を
す。バスルーム用セラミック製品の開発、製造、販売を手がける
的には、Oracleが目前の課題に最適なパフォーマンスの高いデー
ションが20時間で実現したのです。その後、テスト・チームはさらに
得ています。そればかりか、わが社は目標を達成することができまし
LAUFENは、バスルーム文化の発展に大きく貢献しています。同社
タベース・プラットフォームであるという結論に達しました。しかし、同
数時間かけてSAP機能の動作チェックを行ないました。同時に、異
た。リソースのボトルネックが解消しましたし、さらなる成長に向けて、
は、バスルームで過ごす時間が特別な時となるような高品質の製
社の日常業務に支障が出ないよう、マイグレーション作業を短時間
種環境のさまざまなインタフェースが入念に検査されました。マイグ
また次回のSAPアップグレードに向けて、準備は万端です。
」
品を顧客に提供することに誇りを持っています。
で実行することが求められました。これらの前提条件によって、使用
可能なマイグレーション・ツールの選択肢はすでに狭められていまし
企業情報 ─ LAUFEN Switzerland
た。同社が直面する問題はもう1つありました。歴史的な経緯から、
LAUFENのサニタリー・ウェア部門は、サニタリー市場の多くの部門
既存のSAP R/3環境がLatin2エンコード
（東欧文字）
で設定されて
でヨーロッパ第1位、世界第2位のシェアを占めるROCA Groupの
いたことです。そのため、SAP Multiple Display Multiple
一員です。ROCAとLAUFENは、互いに独立したさまざまな組織、
Processing
（MDMP）
コード・ページ機能を使用できるように、エク
ブランド、製品、および販売チャネルを有しています。
スポート時にLatin2からLatin1に変換する必要がありました。
LAUFENのサニタリー・ウェア部門は、30か国以上に3,500名のス
決定を迅速化するために、LAUFENはEAST AGに助言を求め、大
タッフを擁しています。スイス、オーストリア、ブルガリア、チェコ共和
量のデータを処理できる構成を特定しました。ROCAチームとの協
国に位置する6箇所の生産工場では、1年間に合計450万個のセ
力の下、2002年末にはWindows 2000プラットフォームによる将来
ラミック部品が製造されます。800社以上の顧客が年間1億8,000
的な構成が描き出されました。特筆すべきは、一枚岩のようなアプ
万ユーロの売上をもたらします。
ローチを捨て、モジュール方式のスケーラブルなマルチコンピュー
ROCA Groupの従業員数は、世界中の80か国以上で合計
タ・ソリューションを採用した、新しい構成であることです。まもなく、
16,000名を数えます。スペイン、ポルトガル、ポーランド、チェコ共和
データ全体を3段階のプロセスで処理する必要があることが明らか
国、オーストリア、スイス、イタリア、米国、ドミニカ共和国、ペルー、
になりました。そのプロセスとは、まずSAP認定のマイグレーション・
ブラジル、アルゼンチン、モロッコ、トルコ、中国、タイの各国で合
ツールを使ってデータをエクスポートし、エクスポートされたデータを
計2,200万個のセラミック部品が毎年生産されます。年間売上は16
ターゲット・プラットフォームに転送した後、ターゲット・プラットフォー
億ユーロに達します。
ム上のOracleデータベースにデータをインポートするというもので
LAUFEN Switzerlandでは、企業データの処理に2つのシステムを
す。
「マイグレーション期間は2∼3日と設定されました」
とJacques
使用しています。給与計算と管理業務は、独自のソフトウェアを
Nieuwland氏は振り返ります。
「本当のところ、このような大まかな
レーション作業における追加作業はほとんど発生せず、土曜日の夕
方には、マイグレーション・チームがようやくコンソールから離れ、緊
張の連続だった2日間の成果をシャンパンで祝うことができました。
[email protected]
http://www.east-ag.ch
SAP環境におけるデータベース・アップグレードの重要性
なぜデータベース・アップグレードが必要か？
（9.2.0）
にアップグレードという手順になります。SAPに特化した
SAP環境におけるデータベース・アップグレードの重要性は、
注意事項に関しては、各R/3カーネル、各DBバージョンにおいて
SAPアプリケーションを利用しているユーザーに広く知られていま
SAPノートをご覧ください。また、事前作業としてデータベースの
す。しかし、実際にアップグレードを行なう場合には、SAPランド
バックアップも非常に重要な作業となります。
スケープの全システムに段階的にアップグレードを実施し、かつ
アプリケーション担当者と連携したシステムの稼動確認が必要な
〈作業内容〉
ため、
「安定稼動しているシステムにわざわざ手を入れる必要があ
データベースのアップグレードという観点からいえば、新規のデー
るのか？」
と二の足を踏んでしまうユーザーがほとんどであるとい
タベース・ソフトウェアのインストールとアップグレード処理の２つで
うのが実情です。
作業は終了となります。オペレーティング・システムの変更などをし
SAP社もオラクル社も当然のことながら、アップグレードの難しさ
ない場合には、インポート・エクスポートなどの処理を伴いません
は認識しています。しかし、オラクル社はデータベース・アップグ
ので非常に短時間で処理が終了します。たとえば、Oracle8iから
レードを容易に実行するためのアップグレード用ツールを用意し
Oracle9iへのアップグレードでいえば、DBUA（Database
使ってIBM AS/400サーバーで実行されます。情報管理、受注処理、
日数を定めるのは誰も望んでいませんでしたし、まったく経験のない
財務会計、および原価計算はSAP R/3システムで実行されます。こ
ているので、データベース・アップグレードの作業は比較的スムー
Upgrade Assistant）
というツールを実行することで作業は終了
ことでした。
」それ以上の期間にわたってR/3 ERP環境の使えない
ズに行なえます。特に最新バージョンのデータベースは、運用関
します。詳しいアップグレード手順は、SAP社から取り寄せたメ
のシステムは、マイグレーション・プロジェクトが開始されるまで2台
状態で業務を行なえばLAUFENが相当の損害を被る可能性が
ディアに同梱されるマニュアルか、SAPサービスマーケットプレイス
のAS/400サーバーで稼働していました。管理対象データのサイズ
連やパフォーマンスの改善、処理能力の向上に効果のある新機
あったため、リスクは多大でした。週の初めにはSAP R/3が稼働し
能や、既存機能の大幅な改善が実装されています。たとえば、
からダウンロードできるドキュメントをご参照ください。
は合計で120GBを超えていました。
ている必要がありました。
Oracle8iからの新機能であるローカル管理表領域の機能を使用
時は金なり
マイグレーション前の総合的なテスト
の問題が解消されます。もし再編成が必要となった場合は、オン
データベースの切替えが終われば、初期化パラメータの調整と接
12月半ば、LAUFENはWindows 2000の採用を決定しました。
ラインで再編成可能な機能も実装されています。また、Oracle9i
続定義の変更で作業は終了します。切替え後に、SAPアプリ
からの新機能である自動UNDO管理の機能を利用すれば、
ケーションの動作確認や、運用・監視ツール、周辺システムとの
ORA-1555「スナップショットが古すぎます」のエラーに起因する
連携確認を行なえば作業終了となります。すべての作業後に、
ロールバック・セグメントの設計や管理、運用の手間・コストが削
データベースのバックアップを行なうことも忘れずに行なってくだ
減できます。このように、現在抱えている問題に対処するために
さい。
LAUFENのITマネージャは、2002年の冬にはすでにマイグレーショ
ンを検討し始めていました。既存のAS/400システムにはトランザク
すれば表や索引の断片化や行連鎖など再編成の要因となる２つ
ション量の増加に対応できる十分なリソースがなかったからです。シ
ステムはもともと、はるかに少ない量のデータを想定して構成されて
Oracleデータベース・プラットフォームを選択したのは、時間の制約
おり、特にデータ量がもっと遅いペースで増加すると見込んでいた
があったからだけではなく、データベースやマイグレーション・ツール、
のです。予定されていたSAP R/3 4.0Bから4.7 Enterpriseへの
SAPリリースなどのコンポーネントを組み合せたときに保証される
アップグレードは、
2倍のリソースが必要になることが想定されました。
Oracleデータベース・エンジンのパフォーマンスをできるだけ早く利
さらに、LAUFENはDB2/400 EBCDICからDB2/400 ASCIIへの
用したかったからでもあります。
パッチ提供などが行なえることも大きな利点です。
この決定が下された後、マイグレーション・プロジェクトがただちに発
データベース・アップグレード手順
これは、データ量がさらに80%増加することを意味します。こうした
事情から将来が保証されたデータベース・システムとハードウェアの
実装という問題が、システム変更という観点から検討されました。
「わ
が社では当初、コスト効率の理由からDB2環境を維持しようと考え
ていました」
とJacques Nieuwland氏は語り、その理由を次のよう
に説明しています。
「AS/400からWindows 2000にマイグレーション
する場合、オペレーティング・システムとシステム・アーキテクチャの
〈事後作業〉
もアップグレードは有効です。万が一問題が起こった際に、サ
ポートされているバージョンをお使いであれば早急な障害対応や
データベース・マイグレーション
（ASCII移行）
を余儀なくされました。
8
Technology AG
〈まとめ〉
SAPアプリケーションのアップグレードに比べて簡単に行なえる
Oracleデータベースのアップグレードについて、SAPシステムを運
足し、既存のAS/400マシンや新しいIntelハードウェアなどの内部リ
ソースを使ってテストが実施されました。
「試験システムでの最初のエ
クスポート・テストはうまく行き、1回のエクスポート実行がわずか14時
〈注意事項〉
用していく中の作業の一環として捉えていただきたいと考えてい
ます。新技術への対応であったり、問題対処における体制を整え
SAP環境では各バージョンを段階的にアップグレードする必要が
る意味であったり、アップグレードは非常に重要なステップです
あります。もし、お使いのデータベースがOracle8（8.0.6）
であれ
ので、SAPランドスケープをうまく活用しながら、実施することを推
ば、一度Oracle8i（8.1.7）
にアップグレードした後で、Oracle9i
奨します。
間で完了しました」
とJacques Nieuwland氏は述べています。その
後、EAST AGのマイグレーション・チームがエクスポート・プロセスと
9
Oracle_for_SAP 04.5.28 0:30 PM ページ10
Oracle Database10g
for mySAP
Oracle Database 10g for mySAP
Guard Brokerの管理コンポーネントは、完全にRACに統合されま
した。Oracle RACデータベースを含むData Guardによる障害回
この機能は、スタンバイ・データベースに送信されるREDOデータの改
復環境は、シングル・インスタンスのデータベースと同様に容易に管
ざんを防ぎ、Data Guard環境のセキュリティを強化します。Oracle
理することができます。
Database 10gのAdvanced Securityオプションを使用すれば、プラ
ここでは、あらゆるタイプのSAPアプリケーションにおいてOracle
1.3 高速な表のDropとTruncate
Database 10gを使用することでSAPの顧客が得られる技術的な
これら2つのオペレーションは、データベース・バッファ・キャッシュに
メリットをご紹介します。Oracle Database 10gは、管理コストを縮
アクセスする際に改善されたアルゴリズムを使用することで高速に
2.4 クラスタの検証と診断ツールの改善
ます。しかしながら、SAP社がAdvanced Securityオプションを認定
小し、すべてのタイプのワークロードに高いパフォーマンスを提供し、
実行できるようになります。SAP BWによって使用される小さな表に
Oracle Database 10gは、新しいクラスタ構成検証ツールが導入
しない限り、この機能はSAPシステムには適用できません。
さらに新しい高可用性の機能を提供することを目指して開発されま
対して特に役立ちます。
され、Oracle9i Databaseリリースで導入された診断ツールが改善
した。
Oracle Database 10gは、SAPの高度なコンピューティング・インフ
1.4 メモリー内での取消し
ラストラクチュアの概念を支え、低コストなコンポーネントの選択、
短いトランザクションによるブロックの変更は、より細かいCPUサイクル
リソース利用の最大化などハードウェア・コストを低減させるエン
に基づくデータベース・サーバー処理によって効率的に管理されます。
タープライズ・グリッドの実現のために設計された最初のデータベー
スです。前バージョンまでのOracleデータベース同様、SAPに認定
イマリ−スタンバイ間の通信を暗号化し、安全性を高めることができ
されています。これらのツールを組み合せて使用することで、問題の
3.6 拡張されたオンライン再定義
発生を回避し、発生した問題を迅速に解決できます。
多くのSAPアプリケーションにおいて未だ使用されているLONGと
LONG RAWデータを備えたテーブルを、SAPのBRSPACEユーティ
2.5 パフォーマンス改善
リィティを用いてオンラインでLOBデータに移行することができます。
Oracle RAC 10gは、Oracle Real Application Clustersのいくつ
1.5 分割されたオブジェクトに対するスケーラビリティの改善
かの新しい最適化機能によって、多くのアプリケーションのパフォー
3.7 データベース機能の使用状況の追跡
された時点でOracle Database 10gの機能はすべてのタイプの
分割
（パーティショニング）
された表および索引を削除
（Drop）
するこ
マンスが改善します。これには、メッセージ通信量、メモリー使用量
このリリースのデータベースでは、さまざまなデータベース機能の使
SAPアプリケーションにおいて利用可能になります。
とは、バッファ・キャッシュ内の分割された対象となるオブジェクトの
および他のリソース使用を削減する最適化機能が含まれます。さら
用状況
（構成時、実行時、あるいはその両方）
を自動的に追跡しま
SAPによるOracle Database 10gの認定は2005年初頭に計画さ
ブロックを識別し、削除することです。このオペレーションは、新しい
に、動的ファイルとキャッシュ・アフィニティによって、ワークロードを
す。これによって、ユーザーは機能の使用状況を収集して将来の評
れていますので、認定終了後に、Oracle Database 10gの新機能
アルゴリズムを使用することにより高速に実行されるようになります。
インスタンス間で移動する際のパフォーマンスが改善します。
価に役立てることができます。
がSAP環境に続々と採用されることになります。
分割されたオブジェクトの削除は、SAP BWにおいて頻繁に用いら
3. サーバー管理
3.8 アプリケーションのエンド・トゥ・エンド追跡
れるオペレーションなので、SAP BWで特に役立つ機能です。
1. パフォーマンスおよびスケーラビリティ
今回のリリースの主要で価値ある目的の1つに管理・維持コストの
Oracle Database 10gは、対応するすべてのハードウェアにおいて、
2. Real Application Clusters
（RAC）
の拡張
データベースをより速く実行するために最適化されています。現在、
SAPアプリケーションにおけるRACの使用はOracle9i Release2
データベースはファイバ、大容量メモリーまたはNon Uniform
で開始されました。Oracle RAC 10gは、大規模なクラスタにおい
Memory Access
（NUMA）
を使用する能力を持っています。ファイバ
て管理者が多くのノードに対して、
「サービス」
としてアプリケーション
削減があげられます。この目的を実現するための機能の多くは、
データベース・プラットフォーム全体にとって新しい技術および方法
論を組込みます。
はスレッドより速いコンテキスト・スイッチを提供し、データベースの実
のワークロードを構成、管理、監視することを可能にする新しいサー
3.1 バックアップ圧縮
行スケジュールを管理します。したがって、これらの新機能によりデータ
ビス・フレームワークを導入しました。この新しいフレームワークは、
ディスク領域が十分でない場合、または使用するメディア管理ソフト
ベースのパフォーマンスとスループットを改善します。ラージ・ページは、
与えられたサービスのためパフォーマンスを監視し、管理するだけで
ウェアが圧縮機能をサポートしていない場合は、Recovery Manager
特にメモリー依存のデータベース・アプリケーションにおいてパフォー
なく、継続して提供する方法の管理も可能にします。
（RMAN）
を使用してRMAN バックアップ・セットを圧縮できます。
マンスを向上させます。SAPアプリケーションの場合、バッファ・キャッ
シュサイズが数ギガバイトを超えることもあるので特に効果的です。
2.1 統合されたクラスタウェア管理
3.2 増分バックアップの更新
Oracle Database 10gは自動的にNUMAハードウェアを検知し、効
Oracle RAC 10gは、クラスタウェア管理の完全なソリューションが
Recovery Manager
（RMAN）
の増分バックアップをデータ・ファイ
率的にNUMAノードを利用することにより、データベース処理を
Oracle Real Application Clustersの統合コンポーネントとして提
ルのイメージ・バックアップに適用できるようになりましたこれによっ
NUMAに最適化することができます。さらに、64ビットWindows固有
供され、Oracle Database が稼動するすべてのプラットフォームで
て、適用するログの数が少なくなるためリカバリ時間が短縮します。
に拡張されました。SAPシステムの処理能力は、以下の新しいパ
使用できます。このクラスタウェア機能には、クラスタの接続性、
また、データベース全体を常にバックアップする必要がないため、
フォーマンスおよびスケーラビリティ機能により改善されます:
メッセージとロック、クラスタの制御とリカバリ、およびサービス・プ
データベースのバックアップに要する時間も短縮します。
ロビジョニング・フレームワークのメカニズムが含まれています。
1.1 高速なInfinibandネットワークのサポート
サード・パーティ製のクラスタウェア管理ソフトウェアは必要ありませ
3.3 データベース全体に対するBegin Backupコマンド
Oracle protocol supportでは、InfiniBandの高速ネットワークに関
んが、Oracleでは、特定のプラットフォームでのサード・パーティ製
表領域をホット・バックアップ・モードに設定するとき、表領域ごとに
する業界標準のSockets Direct Protocol
（SDP）
をサポートするよう
クラスタウェア製品の使用を引き続きサポートします。
個別にコマンドを発行する必要がなくなりました。A L T E R
になりました。SDPプロトコルは、クライアント／サーバー接続および
DATABASE文を使用して、すべての表領域をバックアップ・モード
サーバー／サーバー接続
（SAPアプリケーションとOracleデータベース
2.2 単一システム・イメージ管理
の間、あるいはRAC構成における2つのインスタンスの間）
のパフォー
Oracle Enterprise Manager 10gは、クラスタ・データベースの配
マンスを高速化する高速通信プロトコルです。SDPを使用すると、ア
置を単一のシステム・イメージを使用して管理できるように大幅に拡
プリケーションでは、ほとんどのメッセージ負荷がネットワーク・インタ
張されました。Oracle Enterprise Managerの「 Cluster
3.4 変更に対応した増分バックアップ
フェース・カード上にかかるため、CPUは他のタスクに集中できます。
Database」ページでは、複数ノードにわたるシステムの状態が1つ
新しいタイプのログ・ファイルを使用してデータベース内で変更され
のイメージで表示されます。また、必要に応じて、このイメージから各
たブロックを追跡すると、Recovery Manager（RMAN）
は増分
インスタンスに直接ドリルダウンすることもできます。
バックアップ時にデータ・ファイル全体をスキャンする必要がなくな
1.2 ビットマップ索引のパフォーマンスと領域管理の拡張
大量の単一行データ操作言語
（DML）
操作が発生した場合のビッ
10
3.5 安全なREDO転送
に設定できるようになりました。また、BEGIN BACKUP コマンドの
実行速度が以前より速くなりました。
ります。かわりに、スキャンするデータ量は変更したデータ量に比例
トマップ索引のパフォーマンスが向上し、断片化がほとんどなくなり
2.3 障害時リカバリのためのData Guard統合
ました。この拡張は、SAP BWにおいて特に重要です。
Oracle Enterprise Manager 10gで、Oracle Data Guard 、Data
します。
この機能によって、多層環境におけるパフォーマンスの問題のデ
バックが簡素化されます。既存のSAPバージョンではなく、最新の
SAPバージョンで利用可能になる予定です。
3.9 SYSAUX 表領域
この新しいシステム所有の表領域は、SYSTEM表領域に常駐しな
いすべての補助データベース・メタデータの一元化した格納場所を
提供します。
3.10 サーバー生成アラート
このリリースのデータベースでは、問題が予測される場合やユー
ザーが選択したメトリックが定義済のしきい値を超えている場合、ア
ラートと通知が先行して管理者に送信されます。
3.11 自動ワークロード・リポジトリ
新しい埋込みリポジトリは完全に自己管理でき、ワークロード情報
とパフォーマンス関連の統計を取得するため、管理コストを削減で
きます。データベースでは、リポジトリに格納された情報をすべての
自己管理アクティビティに使用します。
3.12 データベース時間モデルの拡張
この機能によって、解析、実行、入出力などの内部操作に費やす
時間をデータベースで追跡できるようになりました。この情報は、
データベースで自己チューニングを判断し、パフォーマンスの問題の
診断を容易にするために使用されます。
3.13 待機モデルの拡張
待機モデルの拡張によって、パフォーマンスの診断が容易になりま
す。待機しているセッションの判別、各セッションの待機数と待機時
間に関する履歴の保持、および動的パフォーマンス・ビューでの
SQL 文の待機統計のメンテナンスが可能になります。
11
Oracle_for_SAP 04.5.28 0:30 PM ページ12
Oracle Database10g
for mySAP
4. サーバー構成
最も重要な機能はAutomatic Storage Managementです。これ
Managerの新しいHTMLインタフェースは、不正なSQLを検出する
のに役立ち、チューニングが容易になります。
このリリースでは、Oracleデータベースのフットプリント全体が大幅
は、垂直に統合されたボリューム・マネージャであり、Oracleデータ・
に削減されています。旧バージョンからのアップグレードを行なう
ファイル用に作成されたファイル・システムでもあります。この他に、表
ユーザーには新しい簡単なアップグレード機能が提供されており、
領域の名前変更および複数デフォルト一時表領域の2つの機能が
6.3 自動データベース診断モニター
あり、データベース記憶域の管理を簡素化するのに役立ちます。
この機能によって、データベースはパフォーマンスを自己分析できま
Oracleデータベースのアップグレードに必要な手順が大幅に減少
しました。最初のリリースでは、最適なデータベースを簡単に構成
ラメータ
（バッファ・キャッシュ、共有プール）
が自動的に構成されます。
これによって、データベース構成が簡素化され、使用可能なメモ
リーが最も効率的に使用されるため、パフォーマンスが向上します。
す。データベースでは、潜在的なボトルネックを識別して自動的に修
7. アプリケーション・チューニング
できます。管理者が認識する必要があるのは、環境の構成とチュー
5.1 Automatic Storage Management（ASM）
正するか、または管理者にソリューションを提示できます。この機能
このリリースでは、手動によるSQLチューニング作業を最小化する
ニングで使用する少数の基本的な初期化パラメータのみです。
Automatic Storage Managementは、データ・ファイル、制御ファ
はデータベース・カーネル内部に組み込まれているため、外部ツー
ための新しいツールが導入されました。これらのツールは、SQLパ
データベースの構成に関連する他のタスクは、ほとんど削除または
イルおよびログ・ファイルの最適なレイアウト設定を自動化および
ルは必要ありません。
自動化されています。
ク間で自動的に分散され、データベース記憶域は、記憶域構成が
6.4 REDO ログ・ファイルのサイジング・アドバイザ
4.1 データベースのインストールの簡素化
変更されるたびに再調整されます。また、この機能ではデータベー
頻繁なチェックポイントによる過剰なディスクI/Oを回避するために、こ
データベースのインストール・プロセスが機能拡張されたため、イン
ス・ファイルのミラー化によって、冗長性も提供されます。ASMは、
の機能によってREDOログ・ファイルの最適なサイズが提案されます。
ストール時間が短縮され、システム・リソースの要件
（CPU、メモリー
特に低コストなサーバーおよびディスクを使用するために設計されま
およびディスク領域）
およびインストールCDの数が減少しました。
した。しかしながら、S A PによるA S M のサポートは、O r a c l e
4.2 Oracle Real Application Clustersサービスの自動構成
ん。ASMは、SAP製品の新バージョンで採用される予定です。一
DBCAを使用して、Oracle Real Application Clusters環境を自動
度、ASMの認定がおりさえすれば、過去バージョンのSAP製品でも
的に構成できるようになりました。
ASMが利用可能となります。
5.2 表領域の名前変更
Oracle Universal Installer
（OUI）
は、Oracle Real Application
表領域の名前を変更できるようになりました。従来のように、新規
Clustersの統合されたクラスタウェアと関連コンポーネントを自動的
表領域を作成し、古い表領域から内容をコピーして古い表領域を
にインストールして起動します。
削除する必要はありません。この機能によって、たとえば、ディクショ
ナリ管理表領域をローカル管理表領域に移行したり、同じ名前の
4.4 初期化パラメータの簡素化
表領域がすでに含まれているデータベースに表領域をトランスポー
初期化パラメータは、基本と拡張の2つのグループに分類されまし
トしたりすることが容易になります。
た。データベースで妥当なパフォーマンスを得るには、ほとんどの場
合、基本パラメータ
（20∼25）
を設定してチューニングすれば十分で
6. インスタンス・チューニング
す。まれに、最適なパフォーマンスを得るために、拡張パラメータの
自動化されたインスタンス・チューニング機能によって、管理者の業
変更が必要になる場合があります。
務が大幅に簡素化されます。Oracleデータベースで使用可能な組
込みのリソース管理が拡張され、CPUの使用割当てが追加されま
4.5 デフォルトのユーザー表領域
した。これによって、管理者は、あらゆる種類のリソース割当てに対
データベースの作成では、ユーザーが作成したすべての永続オブ
して最適な操作手順を簡単に設定できます。また、この機能によっ
ジェクトを格納するデフォルトの表領域を指定できます。これによっ
て、主要なビジネス操作の応答時間を容易に予測できるようになり
て、SYSTEM表領域を使用する必要がなくなります。
ました。さらに、リソース使用グループを識別する新しい方法によっ
て、既存のアプリケーションではアプリケーションを変更せずにこれ
4.6 簡単なアップグレード
らの機能を利用できます。このリリースでは、チェックポイント・
データベースとインストール済コンポーネントのアップグレードに必要
チューニングの自動化もサポートされ、I/O使用が低い時間を利用
な手順が削減されたため、データベースのアップグレード・プロセス
してチェックポイントを進めるため、可用性が改善されます。
が大幅に簡素化されました。
4.7 アップグレード情報ツール
6.1 Oracle Enterprise Managerの新しいパフォーマン
ス概要グラフ
この新しいツールは、データベースを正常にアップグレードするため
拡張されたOracle Enterprise ManagerのHTMLインタフェースに
に、既存のデータベースでいくつかの予備チェック
（たとえば、十分
よって、データベースのパフォーマンスに関連するすべての統計に対
な領域はあるか、不要な初期化パラメータはないか、など）
を実行し、
する一元化されたアクセス・ポイントが提供され、完全な監視と診断
データベースのアップグレードに要する時間を予測します。
が容易になります。
5. 記憶域管理
効率的にするための変更を提案します。
7.1 SQL Tuning Advisor
このツールはデータベース・サーバーのエンジンに組み込まれてお
6.5 セグメント・アドバイザ
り、ユーザーがSQLをチューニングすることを可能にします。SQLも
セグメント・アドバイザは、オブジェクト内の領域断片化のレベルに
しくはワークロードを分析して、どのようにチューニングすべきかアド
応じて、オブジェクトを新規のオンライン縮小操作の対象にするかど
バイスします。
うかをアドバイスします。このアドバイザは、セグメント数に関する過
去の増加傾向もレポートします。この情報は非常に有益で、容量計
画に役立ちます。
4.3 統合されたクラスタウェアの自動インストール
フォーマンスを最適化するために作成できる新しい索引やマテリア
ライズド・ビューについて管理者にアドバイスし、既存の索引をより
簡素化します。データベース・ファイルは使用可能なすべてのディス
Database 10gが認定された初期段階では利用可能ではありませ
12
ズムを使用して、システム・グローバル領域
（SGA）
のメモリー関連パ
7.2 SQL Access Advisorの拡張
SQL Access Advisorはワークロード・リポジトリと統合されており、
格納されたワークロード・オブジェクトを利用して、データベース環境
6.6 オンライン・セグメント縮小
の分析を単純化します。
この機能によって、空き領域があるセグメント
（表、索引）
がオンライ
ンで適切に縮小されるため、領域使用の効率が向上します。この
7.3 SQL Access Advisor
機能は、SAP提供のBRSPACEツールでは当初サポートされません
SQL Access Advisorは、SQL文の実行に関連するパフォーマン
が、新バージョンで機能追加される予定です。
スの問題を識別して解決を支援する専門的なシステムで、作成、削
6.7 自動チェックポイント・チューニング
るレポートあるいはZで始まるデータベース・オブジェクトのような標
Oracleデータベースではチェックポイントを自己チューニングできるよう
準のSAP製品へのカスタマイズ部分でのみ利用できます。
除または維持する索引を提案します。SAP環境では、ZやYで始ま
になり、通常のスループットに影響を与えずにリカバリ時間を短縮でき
ます。チェックポイント関連のパラメータを設定する必要はありません。
7.4 自動オプティマイザ統計収集
この機能によって、オブジェクトのオプティマイザ統計収集が自動化
6.8 自動UNDO 保存チューニング
されます。古い統計があるか、または統計がないすべてのデータベー
この機能は、初期化パラメータUNDO_RETENTIONを自動的に
ス・オブジェクトに関する統計が自動的に収集され、収集された統計
チューニングし、ロールバック・セグメントへのUNDO情報の保存を
は定期的にスケジュールされたメンテナンス・ジョブでメンテナンス
制御します。自動UNDO保存チューニング機能によって、データベー
されます。統計収集の自動化によって、問い合わせオプティマイザ
ス・サーバーは、UNDO表領域に割当て済の領域に指定されたシス
管理に関する多くの手動タスクが不要になり、統計が古いために実
テム・アクティビティの変更とともに、ユーザー問い合わせのUNDO
行計画が不十分になる可能性が大幅に減ります。
要件の変更を最適に調整できます。これによって、管理者は、パラ
メータUNDO_RETENTIONを継続的にチューニングする必要がな
9. 可用性
くなります。
SAPを利用する顧客にとって、データの可用性は重要な要件です。
このリリースでは、あらゆる種類の人的エラーに対応するためにデー
6.9 UNDOアドバイザ
タベースの機能が拡張され、データベースやアプリケーションの
このアドバイザは、U N D O 表領域のサイズ変更、および
アップグレードの実装に要する時間を短縮するための機能がサ
UNDO_RETENTIONの適切な設定についてデータベース管理者
ポートされています。
にアドバイスします。これによって、
「スナップショットが古すぎます。
」
というエラーを回避でき、フラッシュバック問い合わせ機能を使用し
9.1プラットフォーム間のトランスポータブル表領域
ている場合にUNDO表領域のサイズを適切に設定できます。
トランスポータブル表領域機能によって、異なるプラットフォーム間
で表領域をトランスポートできるようになりました。この機能により
このリリースでは、データベース記憶域の管理を簡素化および自動
6.2 Oracle Enterprise Managerを使用したSQLレポー
トの改善
6.10 自動共有メモリー・チューニング
化し、柔軟な管理を行なうための機能がいくつか追加されました。
トップレベルSQLも含めて、SQL分析を行なうOracle Enterprise
自動共有メモリー・チューニングでは、自己チューニングのアルゴリ
SAP顧客はプラットフォーム・マイグレーションを高速に行なえます。
13
Oracle_for_SAP 04.5.28 0:30 PM ページ14
COLGATE
CUSTOMERSUCCESS
Data Pump Export Utility およびImport Utilityによって、データ
ありません。
9.4.4 Flashback Table
ベース間でのデータとメタデータのバルク移動が大幅に迅速化さ
SQLにFLASHBACK TABLE文が導入されました。この文を使用
れます。これらのユーティリティには、元のユーティリティに比べて重
すると、前の時点の状態に表を迅速にリカバリでき、バックアップを
要な利点がいくつかあります。たとえば、エクスポートとインポート・
リストアする必要はありません。
9.2 Data Pump Export and Import Utilities
ジョブの完全な再起動、長時間実行されるジョブからの分離と再連
Colgate-Palmolive CompanyのSAP BW on Oracle
Colgate-Palmolive Companyは、オーラル・ケア、パーソナル・ケ
が7倍も向上するという結果がすぐに得られました。Weekes氏は、
ア、住居用および衣類用洗剤、ペット・フードといった製品のトッ
このようなパフォーマンス向上を達成できた主な要因として、Oracle
プ・ブランドを有する、世界規模の家庭用品メーカーです。同社は
のローカル管理表領域やパラレル問い合わせといった機能のほか、
結、エクスポート・ジョブで使用する領域の予測、ネットワーク上の
9.4.5 Flashback Versions Query
200か国以上に営業拠点を持ち、2002年には93億ドルの売上を
Oracle9iで導入された自動領域管理やPGAメモリー管理などの機
エクスポートとインポート操作に対するサポート、オブジェクトとオブ
データベースに格納されたUNDOデータを使用して、1行以上の行
達成しました。Colgate-Palmoliveは、消費者の新たな好みに合っ
能の使用を挙げています。
ジェクト型に基づくファイングレイン化されたオブジェクトの選択に対
への変更と、変更に関するすべてのメタデータを表示できるように
た画期的な新製品を迅速に開発、発売することにより、過去10年
するサポートなどがあります。この機能は、将来的にSAP管理ツー
なりました。
で売上と収益を大幅に伸ばしています。
ルに統合されます。
Colgateがこのような急速なビジネス拡大を持続できる大きな要因
9.4.6 Flashback Drop
となっているのは、絶え間ない業績向上への努力です。Colgateで
1. ウェアハウスのデータが増加した主な原因は何ですか?
データ増加の主な原因は、日々の業務量の増加です。
9.3 パラレル実行のData Pump ExportとData Pump
Import
誤って削除した表をリストアできるようになりました。SQL*PLUSの
は、全社的な重要業績評価指標
（KPI）
を定め、これを利用して、ビ
内では、PURGEおよびFLASHBACK BEFORE DROPコマンド
ジネスの駆動力を組織全体の日常的な営業活動に結び付けてい
Data Pumpの新しいExporおよびImport Utilityはパラレルで実
を使用して、消去するか元に戻すのに利用可能なオブジェクトを見
ます。SAPのBusiness Information Warehouse
（BW）
製品を
行できるため、データやメタデータのロードとアンロードでのパ
ることができるSHOW RECYCLEBIN [original_name]コマンドが
ベースとした全社規模のデータ・ウェアハウスは、組織のあらゆるレ
フォーマンスが向上します。
有効です。
ベルで一貫性をもってKPIを評価、報告するために使用されていま
量、ストレージのベンダーと製品について教えてください。
す。BWは、レポート作成および分析用の一元的なインフラストラク
24のCPU、60GBのメイン・メモリー、および8TBのディスク・スト
9.4 Flashback Any Error
9.4.7 Flashback Transaction Query
チャを提供し、販売や流通の情報、在庫やプロセスの管理、財務
レージを備えたIBM p Series 690を使用しています。ストレー
このリリースでは、データベースのフラッシュバック機能が拡張され
Oracle Flashback Transaction Queryが導入され、データベース
や人事のデータをすべて統合します。BWを使用するのは、部門マ
ジ・サブシステムはIBM ESS Model 800です。
ました。バッチ・ジョブが2回連続して実行されるなど重大なエラー
への変更をトランザクション・レベルで検証できます。これによって、
ネージャ、社内スタッフ、子会社、およびサプライ・チェーンの最適
が発生した場合、データベース管理者は、フラッシュバック操作を要
問題を診断し、分析を実行してトランザクションを監査できます。
求して、データベース全体をエラー発生前の状態に迅速にリカバリ
できるため、バックアップのリストアやPoint-in-Timeリカバリは不
要です。このリリースのOracle Databaseでは、データベース・レベ
ルでのフラッシュバック操作に加えて、表全体のフラッシュバックも
可能です。同様に、ユーザーが誤って削除した表のリカバリも可能
になりました。従来のOracle Flashback Query機能も改善されて
います。最新バージョンのBR*Toolsに対してフラッシュバック機能
の統合が予定されています。
まとめ
Oracle Database 10gは、SAPランドスケープにおいて変化の激
しいビジネス環境により速く反応するために必要なインフラストラク
チュアを提供します。Oracle Database 10gは、低コストのサー
バーおよびディスクを利用するエンタープライズ・グリッド・コン
ピューティングを実行するために必要な柔軟性を提供します。エン
タープライズ・グリッド・コンピューティングのデザインは、SAPのコン
セプトであるアダプティブ・コンピューティング・インフラストラクチュ
9.4.1 Flashback Database
アの概念と一致します。Oracle Database 10gは、より低い管理コ
SQLにFlashback Database文が導入されました。この文を使用
スト、より高いスケーラビリティ、予測能力、および高可用性の機能
すると、ある時点からのすべての変更を取り消して、データベースを
を有し、リスクの少ない環境を提供します。
化とビジネス・インテリジェンス・アプリケーションの提供を目的とし
2. 同時使用率をどのように予想していますか?
同時使用率は今後、急激に増加すると予想しています。
3. 現在使用中のハードウェアとOSプラットフォーム、ストレージの容
4. 最近、サブジェクト・エリアや新規アプリケーションをウェアハウス
たパートナーです。
に追加しましたか? 今後、サブジェクト・エリアやアプリケーション
現在、SAP BWはOracle 9.2をベースとしており、AIX 5.1と60GB
の追加は計画されていますか?
のメイン・メモリーを搭載した24プロセッサのIBM p690 Regatta
はい、新しい情報を常に追加しています。
上で稼働しています。Oracle 9.2データベースは1.9TBの生データ
を含み、その合計サイズは3.8TBです。Oracle 9.2データベースで
5. データベース・スキーマの概要を教えてください。表の数、属性の
は、SAP R/3の業務システム、財務、販売、製造など複数の異な
数、最大の表のサイズは? 3NF
（第三正規形）
または非正規化の
るソースのデータが統合されています。BWはインフォキューブと呼
レベルを使用していますか? n方向結合は使用していますか? サ
ばれる構造を通じてマルチディメンション
（多次元）機能を提供し
ブジェクト・エリア内の相互依存性のレベルは? 全社的なデータ
ます。Colgateのデータ・ウェアハウスには、100万行から1億
の活用方法を説明してください。
9,000万行まで幅広いサイズのインフォキューブが90個含まれてい
データベース・スキーマは複数のスノーフレーク・スキーマで構成
ます。さらに、900を超える計算済の集約も含まれています。イン
され、各スキーマが2つの大規模なファクト表を持ちます。このス
フォキューブと集約はデータベース内の1,000,000を超えるパー
キーマはインフォキューブと呼ばれ、3NFを使用しています。
前の時点の状態に迅速に戻すことができます。バックアップをリス
ティションに格納されているため、データベース構造は世界で最も
表の数: 21.000
トアする必要がないため、この操作は迅速に実行されます。した
複雑なものの1つとなっています。集約を使用すると、業務マネー
属性の数: 380.000
がって、データ破損や人的エラーの後の停止時間が大幅に短くなり
ジャがその日の売上速報、在庫レベル、顧客実績などの業績測定
最大の表: 1億9,000万行、50GB
ます。
基準を素早く確認できます。BWシステムは、世界中の6,200ユー
n方向結合を使用しているか: 使用している。最大30の表結合
ザーにサービスを提供し、1日に通常14,200件のナビゲーション・
9.4.2 Flashback Reinstitution
この機能は、failover後のプライマリ・データベース再構成に必要
な時間を縮小します。そのため、障害の後により高速にシステムを
回復できます。スタンバイ・データベースとの同期は、プライマリ・
データベースをロールバックするために発行したSQLステートメント
Flashback Databaseを使用すると同時に行なわれます。
9.4.3 Flashback Standby Database
この機能はスタンバイ・データベースに対してスイッチオーバーまたは
フェイルオーバーする時間を改善します。あるエラーがプライマリに
生じて、スタンバイに伝播した場合、スタンバイ・データベースをロー
ルバックすることができるので、ログ適用について考慮する必要が
14
ステップを処理しています。Colgateは2002年に複数のデータ・
6. これまでの経験から、Colgate-Palmoliveの要件への対応につ
ウェアハウスを1つのデータ・ウェアハウスに統合し、一元的な全社
いて見たOracleの長所と限界をどのように評価しますか? 最も
規模のレポート作成および分析機能を実装しました。その結果、
有効であると実証された機能は何ですか? Oracle9iの機能のう
最大のBW実装の1つに数えられるシステムが生まれ、Colgateの
ち、Colgate-Palmoliveにとって最も重要な機能は何ですか?
ITスタッフはいくつものスケーラビリティの課題に直面することとな
Oracle9iによってパフォーマンスと機能がどのように向上しました
りました。Colgateのテクニカル・エグゼクティブであるDeighton
か? Oracle9iの総合評価はどのようになりますか?
Weekes氏によると、スケーラビリティの課題は、多数のデータ
OracleはColgate-Palmoliveの要件を満たしており、Colgate
ベース・パーティションおよびセグメント、そしてパーティション・オブ
のIT分野の鍵を握る製品の1つです。
ジェクトに対する広範な削除および作成操作が原因で発生したも
最も有効な機能:
のでした。
- ローカル管理表領域
システム・ベンダーの協力を得てパフォーマンス分析とチューニング
- 一時表領域
作業を実施したところ、統合BWシステムの全体的なパフォーマンス
- パーティショニング
15
Oracle_for_SAP 04.5.28 0:30 PM ページ16
SAP NetWeaver
and Oracle RAC
SAP NetWeaver
and Oracle RAC
- ビットマップ索引
- 表と索引のレンジ・パーティショニング
- パラレル問い合わせ
- ビットマップ索引
- 64ビットのサポート
- B*ツリーからビットマップへの索引変換
SAP NetWeaverは、現在のIT投資を活用し、将来のクロスエ
的なシングル・インスタンスのように見えるため、同じ保守ツールと
Oracle9iの新機能:
- スター型変換の最適化
ンタープライズ・プロセスの土台を築きます。SAP NetWeaver
保守方法が使用できます。標準のバックアップおよびリカバリ操作
自動PGAメモリー管理
- CBOヒストグラム
はSAP xAppsおよびmySAP Business Suiteソリューションの
はすべてRACに対して透過的に機能します。また、SQL操作は、
Oracle9iの総合評価:
- パラレル問い合わせ、パラレルCBO統計生成、パラレル索
基盤となります。さらに、エンタープライズ・アプリケーションを
データ定義言語や整合性制約も含め、RACでも標準的なOracle
Webサービスやオープン・テクノロジーと組み合せて真のアダプ
データベースでも変わりません。
ティブ・ビジネスを可能にするエンタープライズ・サービス・アーキ
Oracle RACでは、データベースが使用可能かつオンラインの間に、
テクチャも実現します。
幅広い保守操作を実行できます。管理者は、データベース操作を
高速かつ堅牢で使いやすいデータベースです。大量のデータに
引作成
対応した拡張が可能であり、管理性も向上しています。
7. Colgate-Palmoliveではマテリアライズド・ビューをどのように利
- UNRECOVERABLE指定での索引作成
複合アプリケーション開発: SAP xAppsの高速開発環境である
8. 現在のワークロード・ミックスについて説明してください。非定型
管理できます。アプリケーションや管理者にはデータベースが標準
中断することなく、索引の作成、データのパーティション再作成、基
用していますか? 分析関数やその他の高度なDSS機能について
問い合わせをどの程度使用していますか? 非定型問い合わせの
Oracle RAC
はどうですか? ビットマップ索引や並列性、パーティショニングは
複雑さは?
Oracle Real Application Clusters
（RAC）
はSAPアプリケーショ
えます。
どのように利用していますか?
非定型問い合わせが80∼90%を占めます。非定型問い合わせ
ンに対して、クラスタ・サーバーでの高可用性を実現し、低コストの
サーバーが停止した場合は、高速の自動フェイルオーバーがユー
は非常に複雑で、最大30方向の表結合を必要とします。
ハードウェアを使用した透過的フェイルオーバーとシームレスなス
ザーに代わって実行されるため、保守作業が単純化されます。この
ケーラビリティを可能にします。基礎となるデータベースは、アプリ
自動フェイルオーバー機能により、データベース・アクセスの復旧に
出典: Winter Corporation
ケーションには1つのインスタンスのように見えます。データ整合性
必要とされる複雑な操作を行なう必要がなくなります。
Field Experience with large-scale Data Warehousing on Oracle
（2003）
制約も含め、すべてのデータベース操作および関数をシングル・
SAPでは集約と呼ばれる独自のオブジェクトが定義されるため、
マテリアライズド・ビューは使用していません。
高度なDSS機能:
- ハッシュ結合
データベース・インスタンスの場合とまったく同様に使用できます。こ
- Upsert/Mergeコマンド
SAP NetWeaverとOracle Real Application Clusters（RAC）
礎となるスキーマの変更、バルク・データ・ロードの実行などを行な
すべてを統合
の透過性により、企業はオンライン・トランザクション処理
（OLTP）
、
Sunは、Oracle RACを使用して、コスト効率がよくスケーラブルな高
データ・ウェアハウス、パッケージ・アプリケーションなどあらゆるタイ
可用性環境でSAPソリューションを提供します。SAP NetWeaver
プのアプリケーションにOracle RACを使用できます。
は、サービスに基づいた全社規模のビジネス・ソリューションの設計
図を提供します。このビジネス・ソリューションは適応性と柔軟性に
低コストのスケーラビリティ
優れたオープンなもので、総所有コスト
（TCO）
の削減に役立ちます。
はじめに
Application Clusters上で実行することにより、前述の機能がス
Oracle RACは水平的スケーラビリティの原則に基づいて設計され
既存のエンタープライズ・アプリケーションをベースにアプリケー
情報テクノロジーは、事実上あらゆるビジネスの不可欠な部分です。
ケーラビリティと可用性でさらに強化されます。そのため、SAPユー
ており、データベース・ワークロード全体を多数の小規模サーバーに
ションを作成し、企業とそのパートナーおよび顧客のコミュニティ全
成功した企業は、情報システムを使って仕入先の管理、製品の製
ザーはビジネスクリティカルなアプリケーションに対応できるピーク・
分散します。要求の増大に合わせてサーバーがクラスタに追加され
体で利用して、既存のシステムの価値を高めることができます。SAP
造、従業員関係の促進、および顧客とのやり取りを行なっています。
パフォーマンスと柔軟性を備えた、低コストの高可用性環境を利用
ますが、このプロセスはユーザーとアプリケーションの両方に対して
アプリケーションは、Oracle RACと組み合わせることで、新規ユー
情報システムは非常に重要であるため、ビジネスクリティカルなアプ
できます。
透過的に行なわれます。Oracle RACでは共有ストレージ・クラス
ザーやアプリケーション・ロードに合わせた拡張が可能になり、新た
タ・アーキテクチャが採用されており、アーキテクチャ内のすべての
なレベルの可用性が生み出されます。
リケーションには可用性、柔軟性、およびスケーラビリティに重点を
置いたコスト効率のよいオペレーティング・プラットフォームが求めら
SAP NetWeaver
ノードが同時かつ均等に1つの共通データベースにアクセスできま
れます。
主要企業がSAP NetWeaver環境を使ってアプリケーションやシス
す。データの追加、編集、削除はどのノードも行なえます。データ
SAPは世界をリードするビジネス・ソフトウェア・ソリューションのサプ
テムを運用しているのは、SAP NetWeaverでは既存のシステムや
ベースが1つというのは、レプリケーションやセグメント化の問題が
ライヤです。成功した企業の多くは、SAP製品を使って顧客やパート
ソフトウェアを活用してIT投資からさらに利益を得ることができるか
発生せず、SQL要求の所有権やリダイレクションという概念も存在
すみます。小規模なシステムから始めて、必要に応じてコンピュー
ナーとの関係を改善し、業務の合理化を図り、サプライ・チェーン全
らです。企業は、フロント・オフィス・デスクトップをさまざまなアプリ
しないことを意味します。すべてのノードが均等に、任意のトランザ
ティング・リソースを追加できます。
般での大幅な効率化を達成しています。企業がSAPアプリケーショ
ケーション、データベース、レガシー・システム、およびインターネット
クションを直接処理できます。
ンやサービスへの依存度を高めるにつれて、ITインフラストラクチャに
ベースの情報によって提供される情報やプロセスと結び付けること
対する要求も増大します。ユーザーは次のような機能を求めています。
で、ビジネスの新たな価値を引き出すことができます。S A P
固有の高可用性
NetWeaverは、ビジネス・インテリジェンス、ビジネス・プロセス管
Oracle RACでは、クラスタ内の各ノードがデータベース・タスクや
可用性の向上: 24×7の環境では、ダウンタイムはたとえそれが
理、ソリューションのライフサイクル管理、カスタム・アプリケーショ
リソースに対して同等のアクセス権と権限を持ちます。ロード・バラ
保守のためであっても、ますます容認されなくなってきています。
ンといった重要なアプリケーションやサービスのインフラストラク
ンシング機能により、障害が発生したノードのクライアントはクラス
ス・リソースにアクセスできます。障害発生時には、データベース
敏捷性の向上: ITリソースを追加して新たな要求、あるいは要求
チャです。SAP NetWeaverのポータルベースのインフラストラク
タ内の別のノードに自動的にリダイレクトされます。残ったノードは、
要求が自動的にリダイレクトされます。適切に設計されていれば、
の変化に対応し、既存のシステムやアプリケーションを再利用す
チャは、次の機能を備えています。
引き続きデータベースにアクセスする一方で、障害が発生したノード
保守や障害が原因でデータベースが停止することはほとんどあり
の共有遷移ログを調整します。データベースは停止しないため、手
ません。
●
●
ることで、
ビジネスにおけるあらゆる機会を最大限に活用できます。
●
マスター・データ管理: 異種IT環境のビジネス・ネットワーク全体
●
で情報の整合性を高めます。
インテグレーション・ブローカ: さまざまなソースやベンダーのアプ
●
す。また、単一障害を減らせば、サポートおよび保守コストを最小
リケーション・コンポーネント間でXML/SOAPベースの通信を可
限に抑えながら、稼働時間を最大化することができます。
能にします。
SAP NetWeaverは、既存のITリソースを新たな需要やサービスに
統合するための優れたプラットフォームを提供します。Oracle Real
主な機能
●
●
コストの削減: 低コストのサーバー・ハードウェアを使用すれば、
設備投資を削減し、投資利益率を最大限に高めることができま
16
びストレージは、クラスタ全体の環境の中で1つのエンティティとして
●
顧客は、高価なコンピューティング・リソースを余分に購入せずに
Oracle RACは、ユーザーやアプリケーションにはシングル・イン
スタンスのように見えるため、通常クラスタに付随する管理上の
問題を回避できます。
●
可用性が最大限に高まり、すべてのノードがすべてのデータベー
動で再起動とリカバリを行なうか、あるいはスタンバイ・サーバーへ
の自動フェイルオーバーを行なうだけのわずかな時間で、データベー
スの機能を完全かつ最新の状態に戻すことができます。
管理作業の単純化
SAPソリューションで用いられるコンポーネントの数を増やすと、保
マルチチャネル・アクセス: ユーザーは音声、モバイル、無線などの
守の負担が増大する可能性がありますが、Oracle RACの機能は
テクノロジーを利用してエンタープライズ・システムに接続できます。
保守負担の可能性を最小限に抑えます。リソース、サーバー、およ
●
17
Oracle_for_SAP 04.5.28 0:30 PM ページ18
POLLMEIER
CUSTOMERSUCCESS
Pollmeier
Migration
to Oracle
社は、Oracle/SAPパートナーシップの開始当初から培われた膨大
製材工場の利益拡大
なナレッジ・ベースを基に利益を生み出しています。
SAPを支えるデータベースとしてMS SQLからOracleへのマイグレーションに成功
「わが社は、Oracleシステム上で稼働する最初のSAPが発表されて
からずっと最前線に立っています。最初のケースもわが社がパイ
ドイツのブナ材市場は依然として長期的な不況の只中にあります。
広い意味での機械類については、Pollmeierは2つの製材工場お
ロット・インストールを行ないました。わが社には豊富な経験がある
しかし、ブナ材の分野で市場をリードするPollmeier Massivholz
よび関連する機械工場の生産設備を徐々に最適化することで、自
ため、別の選択肢はまったくといっていいほどなかったのです。
」
GmbHは、危機的状況からは程遠く、国際レベルでの事業拡大に
社のコア・コンピテンシーに焦点を絞りました。そのため、同社はIT
Data Process GmbHのビジネス・ソリューション担当バイス・プレ
成功しました。
環境の再編成を外部パートナーにアウトソーシングしたいと考え、
ジデントのLothar Heyde氏はこのように述べています。
カッセルに拠点を置くITサービス・プロバイダのData Process
「わが社の顧客は、プロジェクトの成果としてパフォーマンスが大幅
作業現場にとどまらない標準化
GmbHを選びました。2002年、ついにマイグレーション・プロジェク
に向上し、Oracleデータベースの幅広いセキュリティ機能が得られ
Pollmeierが顧客と仕入先を対象に多額のコスト削減を進める上
トを開始することができました。
たことにとても満足していました。
」
で鍵となるのは単位原価です。同社は垂直方向の生産範囲を拡
正しいパートナーが見つかったことはすぐに明らかになりました。
大することで、加工製品の品質を高め、顧客の製材コストを大幅に
Data Process GmbHは、古くから岩塩採掘に関わってきた持ち株
削減してきました。顧客要件の綿密な分析が功を奏し、Pollmeier
会社、K+S Groupの100%子会社でありながら、IT関連業務の分
は最適なポートフォリオに的を定めた選択を行なうことができていま
野で数多くの類似性を発見したのです。
将来の変化に対応できるスケーラブルなITインフラストラクチャ
す。こうした初期投資は、金銭的な利益を生むだけではなく、
Data Process GmbHの ITコンサルタントであるThomas
Pollmeierとその顧客が共に競争力を高めることができるという点
Strecker氏は、Pollmeierのシステム統合プロジェクトにおける重要
B. Braun MelsungenがDB2をOracle9iにリプレース
でメリットがあります。同社の単位原価は、通常の製造業者の単位
な要素について、次のように述べています。
「特に、Pollmeierの継
原価を最大30%下回っています。
続的な国際化と絶え間ない成長に関していえば、データベースの可
用性、スケーラビリティ、そして信頼性は絶対に妥協できませんで
自然資源のデジタル化
した。
」
市場、プロセス、
トランザクション、情報の流れとスピードのすべ
および企業間でプロセスの同期を取ることができ、その結果、顧客
てが変化しています。これは、特に公的保険制度についていえ
指向の有効な方法で迅速に対応することが可能になります。
ることです。したがって、絶え間ない開発の推進とさまざまな画期
B.Braunは、サプライ・チェーンにおける企業の枠を超えた包括的
Pollmeierは何年か前からドイツの木材業界が陥っている永久的な
「環境が均一化されたことで業務の効率が非常に高まったのはい
的製品によって世界市場に確固たる地位を築いてきた家族経
なプロセス最適化を通じ、倉庫の数と在庫を同時に大幅に削減す
危機を脱するべく、着実に努力を重ねてきましたが、IT部門で使用
うまでもありませんが、わが社の顧客にとってはデータベース保守
営企業B. Braun Melsungen AGは、よりダイナミックな次元
ることを目指しています。B. Braunでは、改革は製品のみにとどまら
するMS Windowsベースのシステムがすぐに容量制限に達してしま
のサービス料金が安くなったこともメリットです」
とStrecker氏は語
で物事を考え、計画しています。このような背景から、B. Braun
ず、プロセスやメソッド、ITインフラストラクチャのサポートもその対
いました。
ります。
は2001年の春、世界中に分散したITインフラストラクチャを統
象となります。
「わが社が絶え間ない成長を続けるために必要とされるスケーラビ
リティとパフォーマンスの要件は、MS SQLシステムでは満たされな
いことがわかりました。
」
合して、より将来を見据えたものとすることを決定しました。方向
全面的な統合
性の見直しの主要な成果の1つとして、IBM OS/390メインフ
PollmeierはSAPへのマイグレーションを2000年に開始し、
まずHR、
レームがAIXプラットフォームに、IBMのデータベースDB2が
SD、FI、MMの各モジュールを導入しました。
Oracle9iにリプレースされました。
Pollmeier GmbHのITマネージャ、Ralf Sch o ne氏は次のように説
新しいITインフラストラクチャは、日常業務に影響を与えることなく、
明しています。
「わが社の社員数は25名から130名に増え、工場に
数週間のうちに別の環境にインストール、実装されました。WAN接
ヘルス・ビジネス
おける垂直方向の生産範囲も大幅に拡大しました。最終的には外
続の確立、SAPルーターのインストール、および新しい強力なハー
160年以上前に創立された家族経営企業であるB. Braun
部ITパートナーの助言に従い、できるだけ早くOracleとSAPにマイ
ドウェアの調達および設定が完了すると、SAP R/3はごく短期間
Melsungen AGは現在、国際的な医療品市場でのグローバル・
グレーションするという決定を下しました。
」
のうちにテスト・システムにマイグレーションされました。Pollmeierと
プレイヤーとなっています。このグループ企業は顧客の近くに事業
Data Processのマイグレーション・チームは、この段階でSAP環境
所を構え、約50か国に28,000名の従業員を配しています。また、
に問題が発生すると予測していましたが、実際には問題は何も起こ
病院用備品、薬局や開業医、手術医学や医療技術など、医療の
りませんでした。IXOSアーカイブのインストールの際には問題点が
さまざまな診療分野で幅広い製品やサービスを提供しています。
いくつか発生しましたが、有能なサポート・スタッフのおかげで、その
B. Braunが力を注いでいるのは、1つのソースからあらゆるサービ
原因となった特別な問題と共にすぐに解決しました。D a t a
スを提供することです。たとえば、医療品、薬品、およびサービス
ProcessはKaba BenzigとIXOSのパートナーでもあるため、両社
は麻酔、手術、透析といった分野ごと、あるいは医療部門ごとに1
の協力を得ることができたのです。
つにまとめられ、プロセス指向のシステム・ソリューションを形成し
テスト・システムのインストールが成功し、アーカイブ・データがマイグ
ています。
レーションされ、APOシステムが設定された3週間後、R/3の本番環
境がついに何の問題もなくマイグレーションされました。マイグレー
付加価値チェーンの一元化
ション・プロジェクトが完了した時点で、アプリケーション保守は
B. Braunはこのような包括的サービス戦略を、特に同じく包括的な
PollmeierのITチームの手に返されました。
付加価値チェーンを通じてサポートしています。ほとんどの企業が、
サプライ・チェーンを分割して製造の範囲を次々と狭めていく傾向
18
結論
にある中で、B. Braunは付加価値チェーンの一元化を非常に重要
Data Processは現在、40社以上のさまざまなクライアントから
視しています。このような戦略をグループ全体で掲げることにより、
Oracle/SAPの管理をアウトソーシングされて請け負っています。同
B. Braunは他社よりもスムーズかつ効果的にグループ内の各企業
ITインフラストラクチャのテストを実施
グループ全体でビジネス・プロセスを統合し、エンドツーエンドでサ
プライ・チェーンを最適化するという目的から、B. Braunでは2年前
にITインフラストラクチャのテストを実施し、重要な点を整理しなお
しました。まず、SAP R/2からクライアント/サーバー・システムである
SAP R/3への変更が決定されました。当時のプラットフォームは、
OS/390オペレーティング・システムとDB2データベースを搭載した
IBMメインフレームでした。
B. Braunは、コスト削減を図るためにメインフレームをUNIXシステ
ムにリプレースすべきかどうか自問しました。詳細な調査の結果、同
社はメインフレームを使い続ける理由はなく、UNIXシステムでもすべ
ての要求を満たすことができるという結論に達しました。そこで選ば
れたのは、AIX/HACMPオペレーティング・システムを搭載したIBM
pSeriesサーバーでした。
データベースの問題
それと同時に、データベースの問題も解決しなければなりませんで
した。AIXに変更しようというときにIBMのDB2データベースを使い
続けることは可能だったのでしょうか? 結局のところ、最大7000の
SAPユーザーをサポートする必要がありました。このような問題が持
ち上がると、ユーザーは、SAPとIBMは戦略的提携関係にあるもの
の、すべてのSAP R/3アプリケーションのうち70%以上がOracle
上で稼働しているという事実に必ず気付きます。何千もの同時ユー
ザーが数テラバイトのデータベースにアクセスする最大規模のSAP
19
Oracle_for_SAP 04.5.28 0:30 PM ページ20
B. BRAUN
CUSTOMERSUCCESS
B. BRAUN
CUSTOMERSUCCESS
生産システムは、Oracleだけを使用して稼働しています。たとえば、
機能制限、異なるコード・ベース、異なる開発方針が関係していま
4%増加しています。このレポートは、同じ期間にIBMのDB2がシェ
近頃SAPはmySAP Business Information Warehouseに関する
す。そのため、SAPもR/3ソフトウェア用に3種類の異なるDB2イン
アを4%落としたことも示しています。AMRのアナリストはレポートの
調査結果を発表しました。20,000ユーザーが5TBのデータベースに
タフェースを開発しました。
中で、その理由の1つを「景気の下落に直面したときに、大企業の
アクセスするという状況のシミュレーションに使用されたのは
20年以上前から移植性の代名詞となっているOracleは、あらゆる
多くは社内の効率アップとコスト削減に専念するからだ」
とまとめ
Oracle9iでした。
ハードウェアおよびオペレーティング・システム向けに1つのソリュー
ています。
徹底的なテストと調査の結果、B. Braun Melsungen AGのCIOで
ションを提供しています。対象となるハードウェアは対称型マルチプ
B. Braunも、Oracleに決定する際には戦略的な側面だけに注目せ
あるKarl-Heinz L o w氏は、Oracleを採用するのは当然と考えるよ
ロセッサ・システムやメインフレーム、クラスタ、新しいブレード・テク
ず、効率性とコストから得られるメリットも視野に入れました。しかし、
うになりました。
「IBMは、AIX/DB2がこの規模で利用されている事
ノロジなど、オペレーティング・システムはSolaris、HP-UX、Tru64、
B. BraunはAMRが引用した「景気の下落」
とは異なる立場を取っ
例を示すことができなかったのです。しかし、Oracle9iが、わが社の
AIX、Windows、Linux、z/OS、BS2000などです。Oracleは常に
ています。たとえば、他社が人員を削減するようなときに、B. Braun
規模のSAP R/3インストールに対応できる容量とパフォーマンスだ
同じ無制限のインフラストラクチャ・ソフトウェアです。そのため、大
はメルスンゲンのスタッフとの間で勤務地を保障する契約を結び、
けではなく、それ以上の要求に応えるスケーラビリティも備えている
幅なコスト削減、投資の保護、および将来的なセキュリティの確保
同社創立以来最大額となる1億5000万ユーロをメルスンゲンの新
ことはすぐに明らかになりました。
」
が可能になります。
しい製薬工場に投資することを決定しました。
Karl-Heinz L o w氏にとって、パフォーマンスとスケーラビリティは重
要な要件でした。
「市場の変化に対してオープンでいたいと考えるIT
プラットフォームの統合
担当者は、サプライ・チェーンに無駄のない協同ビジネス・モデル、
Oracleに決定する際、B.BraunではITの複雑さを低減し、グループ
グローバル・プレゼンスと新規販売チャネル、E-Businessと拡大を
全体でシステムを統合することも重要視しました。Oracleのスケー
続けるサービスなどを実現するために、ITインフラストラクチャ
（特に
ラビリティと移植性は、特にこの目的に合致しています。90年代の
全社的データ管理）
を統合すると同時に、ユーザーとトランザクショ
企業買収、グローバル化、拡大、および分散化の波が原因で、多
ンの数の増加やコンテンツの多様化、そして柔軟性の向上に順応
くの企業のITソリューションには、IT自体が非常に複雑になる
（コン
しなければなりません。ここで、データベースは中心的な役割を果た
ピュータ・センターの増加、データベースの多様化、ITスタッフの増
顧客向けの新しい管理ツール・セットを完成させました。この新しい
します。データベースはアプリケーション・システムの効率性と将来
加）
だけではなく、ビジネス全体の複雑さも大幅に増すという傾向が
ツールはS A P D B Aに代わるものです。S A P D B Aは引き続き
に影響を与え続けるため、データベースの決定はわが社の戦略を
多々見られました。最終的には、情報の寸断、ソリューションの孤立、
Oracle9iで使用できますが、開発対象から外されています。した
左右する決定でした。
」
プロセス・チェーンの複雑化、組織インタフェースの過多といった結
がって、SAPDBAのかわりにBR*Toolsを使用することを強くお薦め
Oracleデータベース管理用のSAP BR*Tools
SAPはWAS 6.40でのBRSPACEのリリースをもって、Oracle/SAP
BR*TOOLS: 他のBRプログラムを呼び出すためのメニューを表
●
示します。
BRGUI: JavaベースのGUIとして機能し、BR*Toolsのフロントエ
●
ンド表示プログラムの役割を果たします。
果がもたらされました。
します。BR*Toolsは、統一されたメニュー駆動型のユーザー・イン
これらのツールの詳しい使用方法は、http://service.sap.com/dbaora/
マイグレーション
2000年にB. BraunのIT責任者の職を引き継いだKarl-Heinz
タフェースを提供します。グラフィカル・インタフェース
（図を参照）
の
の次の場所に掲載されています。
B. Braunはサーバー・プラットフォームをリプレースし、少人数の
L o w氏は、IT部門が著しく分散化していることに気付きました。グ
ほか、キャラクタベースのインタフェースも用意されています。
チームを編成してSAP R/3アプリケーションをOS/390版DB2から
ループ内には、約 2 0 種類の異なるS A PインストールとD B 2、
さらに、BR*ToolsではMCOD構成のサポート、Oracle9i RACの
Oracle/AIXへと短期間でマイグレーションしました。現在、R/3の実
Informix、Oracle、SQL Serverなどのデータベース・システムが存
サポート、自動障害時リカバリ、オンライン表再編成（前号の
装が世界各地で順次進められており、それと同時に、分散していた
在していたのです。B. Braunでは、断固とした統合戦略により、複
『Oracle for SAP Technology Update』4∼8ページを参照）
など、
コンピュータ・センターも統合されつつあります。2002年夏には、最
雑さの低減、コンピュータ・センターの統合、コスト構造の再定義、
大幅な機能強化が行なわれています。このツール・セットは次のコ
初のコンピュータ・センターがツットリンゲンからメルスンゲンに移さ
およびデータベース操作の単純化を行なう予定です。Oracleの導
ンポーネントで構成されます。
れました。
入に伴い、データベース担当スタッフの数はDB2の時代の半数に
SAPは通常、データベース変更の際のマイグレーション作業をサ
削減できました。
ポートし、マイグレーション・プロセスを標準化します。マイグレーショ
ソフトウェア開発も、きわめて簡単に低コストかつ短期間で行なえ
ン作業はプロジェクト計画から始まりますが、この計画はSAPサ
るようになる予定です。全社的に統一されたOracleインフラストラ
ポートの承認を受けなければなりません。そのほか、認定を受けた
クチャのおかげで、開発システムと標準はグループ全体でそれぞれ1
SAPマイグレーション・ベンダーの要請、所定のマイグレーション・
つしか存在しません。B. Braunは検査済の環境で開発作業を行
ツールの使用、テストおよび管理プロセスといった措置により、
なっているため、これは重要なポイントです。統合によるコスト削減
データベースのマイグレーションは迅速に、また顧客がリスクを負う
と同時に、グループ全体でデータ、プロセス、およびサプライ・
ことなく完了します。このプロセスは、過去2年間にドイツ企業で実
チェーンの統一化を図ることができます。
- Media Library
- General
- Backup and Recovery
- Space Management.
BRBACKUP: データベースのデータ・ファイル、制御ファイル、お
●
よびオンラインREDOログ・ファイルをバックアップします。
BRARCHIVE: オフラインREDOログ・ファイルをバックアップし
●
ます。
BRRESTORE: データ・ファイル、制御ファイル、およびREDOロ
●
グ・ファイルをリストアします。
BRRECOVER: データベース・ファイルをリカバリし、プロファイ
●
ルおよびログ・ファイルをリストアします。
施された数多くのマイグレーション作業の中で実証済です。
移植性
Oracleデータベース ─ 最も一般的なERPアプリ
ケーション用プラットフォーム
Oracleに有利な側面がもう1つありました。それは移植性です。
Oracleに関するB.Braunの決定が正しいことは、AMRのアナリス
Karl-Heinz L o w氏は次のように述べています。
「OS/390版DB2が
トによる調査で強調されており、OracleがERP
（ERP＝エンタープ
AIX版DB2と同じではないことに我々は驚きました。R/3をOS/390
ライズ・リソース・プランニング）
環境のデータベース市場に占める
版DB2環境からAIX版DB2環境に移植するのは、DB2からOracle
シェアは、高い水準で着実な伸びを見せています。2002年春に発
次エクステントの適合、ログとDBA表のクリーンアップなど、デー
にマイグレーションするよりも高価だったのです。
」実際、IBMのDB2
表された『The Enterprise Application Spending Report:
タベース管理タスクを実行します。バックアップ中にデータベース
には少なくとも3種類の異なる製品、異なるアーキテクチャ、異なる
2002-2006』
という調査によると、ERP市場におけるOracleデータ
を監視するヘルプ・ツールとしても機能します。
BRSPACE: データベース・インスタンス、領域
（表領域、
ファイル）
、
●
およびセグメント
（表、索引）
を管理します。索引と表の再編成も
行ないます。
●
BRCONNECT: 統計の更新、データベース・システムのチェック、
ベースのシェアは2000年から2001年にかけて50%から54%へと
20
21
Oracle_for_SAP 04.5.28 0:30 PM ページ22
Oracle for SAP BW
Oracle for SAP BW
ます。Oracleのユニークなパラレル・アーキテクチャを利用すると、
SAP Business Information Warehouse向けの
Oracleテクノロジー
は、問い合わせの複雑さ、問い合わせに指定された表のサイズ、
2月1日∼28日
ハードウェア構成、およびシステムにおける現在のアクティビ
データ・ウェアハウス用のOracleデータベース ─
絶え間ない革新の証
ウェアハウスがデータベースに求めるものは、OLTP
（オンライン・ト
ランザクション処理）
システムが求めるものとはまったく異なっていま
Oracle 7.3
● ハッシ
ュ結合
● ビッ
トマップ索引
● パラレル・
オプティマイザ
● パーテ
ィション・ビュー
● インスタンス
・アフィニティ: ファンクション・シッピング
● パラレルUNION ALL
● 非同期先読取り
● ヒス
トグラム
● アンチ結合
す。OLTPシステムでは、どちらかといえば小規模なトランザクション
が大量に処理されます。ここで「小規模」
といっているのは、データ
ベース・オブジェクトの数や関係するデータの量、そして読取り操作
における結果サイズのことです。ウェアハウス・システムではOLAP
（オンライン分析処理）
機能が利用される場合があります。このタイ
プのシステムでは、ユーザーやトランザクションの数がどちらかとい
えば少なくなります。ただし、この場合のトランザクションは、関係す
るデータベース・オブジェクトの数や処理されるデータの量、結果
セットのサイズの点で非常に大規模であることがほとんどです。
Oracle 8.0
● パーテ
ィショニングされた表および索引
● パーテ
ィション・プルーニング
● パラレル索引スキャン
● パラレル挿入、
更新、削除
● パラレル・
ビットマップ・スター・クエリー
● パラレルANALYZE
● パラレル制約の有効化
O r a c l eはデータ・ウェアハウス全般、特にS A P のB u s i n e s s
Information Warehouse
（SAP BW）
で最も広く採用されている
データベースです。これは、Oracleがデータ・ウェアハウスの中核的
な要件であるパフォーマンス、スケーラビリティ、管理性を備えてい
るためです。Oracleの優位性は、ベンチマークやアナリストの証言、
顧客体験によって確認されています。その例として、よく知られた
5TBのショーケースと、Oracleを利用した大規模データ・ウェアハウ
スについてのWinter Corporationの調査が挙げられます。
Oracle8i
● サマリー管理
● 新しいパーテ
ィショニング手法
● リソース
・マネージャ
● 進捗モニター
● 動的パラレル問い合わせ
● サーバーベースの分析関数
● トランスポータブル表領域
● ファンクシ
ョン索引
● パーテ
ィション・ワイズ結合
2002年、SAPとSunは20,000ユーザーが5TBを超えるデータに
対して1時間当たり数十万件の操作を実行するのと同等の負荷
に耐えるSAP BWシステムを構築し、そのテストに成功しました。
この困難なプロジェクトのためにSAPとSunが選んだデータベー
スはOracle9iでした。
2003年、Winter Corporationは『Field Eperience with
●
1月1日∼31日
Large-Scale Data Warehousing on Oracle』
というホワイト・
ペーパーを発表しました。これは、ベンチマークやラボ・テストで
Oracle9i
● リス
ト・パーティショニング
● コンポジッ
ト・レンジによるリスト・パーティショニング
● ビッ
トマップ結合索引
● 動的共有メモリー管理
● SQL実行メモリーのセルフチューニング
● 自動UNDO管理
● 拡張統計収集
● Oracle9i OLAP
● 圧縮データ
・セグメント
はなく、実際の顧客体験をベースとしているという点で、特に興
味深いものです。その中で取り上げられた例の1つが、最大の
BW実装の1つに数えられるColgate-Palmolive Companyの
SAP BWシステムです。システムのサイズと複雑さにもかかわらず、
「ColgateはOracleが最も高速でスケーラビリティに優れ、堅牢
で使いやすいと知りました。
」
この記事では、Oracle9iの主要なデータ・ウェアハウス機能が説明
されています。その一部はOracle8iやOracle8、Oracle7ですでに
使用可能でした
（囲み部分を参照）
。しかし、どの機能も他のデータ
ハッシュ
関数
4月1日∼30日
5月1日∼31日
い合わせを実行する際の基本的なパフォーマンス機能です。
6月1日∼30日
ビットマップ索引: Oracleデータ・ウェアハウスで最も一般的な索
●
3月1日∼31日
ントに選択されます。パラレル処理は、大量のデータに対して問
図1a: レンジ・パーティショニング
図1b: ハッシュ・パーティショニング
引のタイプはビットマップ索引です。オラクル社が特許を持つ圧縮
手法により、ビットマップ索引は非常に小さくなります。通常は、B*
値1
ツリー索引の数十分の1の大きさです。この圧縮手法には、顧客
値2
が同じサイズの記憶領域を使って、同じ額の保守コストで、より多
値3
範囲内の
キー
値4
使用すると、より多くのキー列に索引を作成できるため、ユーザー
値5
が問い合わせを実行する際のパフォーマンスが向上します。
値6
スター・クエリーの最適化: データ・ウェアハウスでよく使用される
●
1月1日∼31日
値リスト
くの索引を作成できるというメリットがあります。ビットマップ索引を
図1c: リスト・パーティショニング
2月1日∼28日
図1d: コンポジット・パーティショニング
問い合わせのタイプはスター・クエリーです。オラクル社では、こ
の一般的なビジネス問い合わせに対応するため、専用のテクノロ
「分断攻略」手法です。パラレル処理とは、1つの操作に複数の
ジーを開発しました。Oracleは、ビットマップ索引と高度な問い
CPUリソースを適用する機能です。Oracleでは、パラレル処理機
合わせ最適化の画期的な応用例であるスター型変換テクノロ
能によって、システムのCPU能力をフルに活用することができます。
ジーを利用して、スター・クエリーをサポートします。この実証済の
スケーラビリティにとって重要なのは、これら2つの機能を組み合わ
テクノロジーは、Oracle8およびOracle8iを使用する顧客によっ
せることです。Enterprise EditionのオプションとしてOracle8で初
て広く採用されています。
めて導入されたOracle Partitioningは、大規模な表や索引の管理
自動メモリー管理: 従来、システム・グローバル領域
（SGA）
のコン
性、可用性、および問い合わせパフォーマンスの大幅な向上を可
●
ポーネントを拡張または縮小する際には、管理者がOracleインス
タンスを停止する必要がありました。Oracle9iでは、バッファ・
キャッシュと共有プールの動的なサイズ変更を可能にする動的メ
モリー管理機能が導入されています。さらに、プライベート・メモ
リーの割り当てを制御する初期化パラメータのセルフチューニン
能にします。Oracleには幅広いパーティショニング・オプションが用
意されています。
パーティショニング・オプション
Oracle9i Databaseには、さまざまな状況でより適切に利用できるよ
う設計された、いくつかのパーティショニング手法が用意されています。
グ機能により、SQL実行用の作業メモリー
（ソート領域など）
を透
過的に管理することも可能です。
●
レンジ・パーティショニング: 各パーティションに設定したパーティ
ション・キー値の範囲に基づいて、データがパーティションにマッ
●
データ格納: ビジネスに必要とされる情報が増えるにつれて、リ
プされます。最も一般的なタイプのパーティショニングであり、通
レーショナル・データベースに格納されるデータも増加します。大
常は日付などを使用します。レンジ・パーティショニングは、デー
量のデータの保守に伴うコストの大部分は、ディスク・システムの
タ・ウェアハウスでのローリング・ウィンドウ操作をサポートするの
コストと、データの管理に利用されるリソースです。Oracle9iでは、
に最適なパーティショニング手法でもあります。Oracleをベース
リレーショナル表に格納されるデータを圧縮することでこのコスト
とした標準的なSAP BWでは、PSAとファクト表がレンジ・パー
に対処するユニークな方法が導入されています。圧縮されたデー
ティショニングされます
（Eファクト表は時間で、Fファクト表はバッ
タに対して問い合わせを行なう場合でも、所要時間への悪影響
チIDでパーティショニングされます）
。
はほとんどありません。
●
ハッシュ・パーティショニング: 指定したパーティショニング・キーに
パーティショニング
適用されるハッシュ・アルゴリズムに基づいて、データがパーティ
ベース・システムと比べてユニークであり、Oracleが最大規模の
かな管理およびアクセスが可能になります。Oracleでは、さまざ
データ・ウェアハウスにとって、スケーラビリティの向上が最も難しい
ションにマップされます。ハッシュ・アルゴリズムにより、行が複数
SAP BWシステムさえもサポートできる理由をよく表しています。
まなパーティショニング手法によってあらゆるビジネス要件に対応
ケースの1つは大量のデータをサポートする場合です。一般的に、
のパーティションに均等に分散されるため、パーティションのサイ
できます。さらに、パーティションニングはSQL文からみて完全に
データ・ウェアハウスは企業内の最大のデータベースであるため、
ズは、ほぼ同一になります。ハッシュ・パーティショニングは、デー
透過的に実行されるため、ほとんどすべてのアプリケーションに
データ管理が重要な要件となります。大量のデータをサポートする
タを複数のデバイスに均等に分散する際に最適な方法です。
適用可能です。
際に必要となる重要な機能として、パーティショニングとパラレル処
データが履歴データではなく、論理的なレンジ・パーティション・プ
理の2つが挙げられます。パーティショニングとは、きわめて大量の
ルーニングが有利になるような列や列リストが明らかでない場合
データに対する操作を小規模な操作に分割する機能です。パー
には、レンジ・パーティショニングにかわる優れた方法でもありま
ティショニングは基本的に、大規模な表や索引を管理するための
す。ただし、ローリング・ウィンドウはサポートしていません。
パーティショニング: Oracle9i Enterprise Editionのオプションで
●
あるOracle Partitioningは、多種多様なアプリケーションの管
理性、パフォーマンス、および可用性を強化します。パーティショ
ンニングを利用すると、表、索引、および索引構成表を小さな単
位に分割できるため、これらのデータベース・オブジェクトのきめ細
22
範囲内の
キー
ティ・レベルに基づいて、各問い合わせの並列度がインテリジェ
概要
●
あらゆる問い合わせを任意の並列度で実行できます。Oracleで
●
パラレル処理: パラレル処理とは、1つのSQLコマンドの実行時
に複数のCPUおよび入出力リソースを適用できることを意味し
23
Oracle_for_SAP 04.5.28 0:30 PM ページ24
Oracle for SAP BW
Oracle for SAP BW
リスト・パーティショニング: レンジ・パーティショニングを補完する
ニングされている場合に適用できます。パーティション・ワイズ結合
りあてます。すべての作業単位が処理されるまで、これが繰り返され
機能です。レンジ・パーティショニングは、連続したドメインで表を
では、大規模な結合が小規模な結合に分割されて、各パーティショ
ます。パラレル実行サーバーはパラレル実行コーディネータに結果
セグメント化する場合に便利です
（ほとんどの場合、表を時間で
ンの間で実行されるため、結合操作全体が短時間で完了します。
を送り返し、コーディネータはそれぞれの結果を目的の全表スキャン
レンジ・パーティショニングし、1か月に1つ、または1週間に1つの
その結果、シリアル実行、パラレル実行のどちらでも大幅なパ
の形にまとめます。
レンジ・パーティションといったように、ある範囲の値に対する
フォーマンス向上が実現します。
Oracleのパラレル問い合わせアーキテクチャは、並列度を問い合
●
データを各レンジ・パーティションに含めます）
。これとは逆に、リ
ビットマップ索引
わせごとに動的に決定できる点がユニークです。基礎となる表の
スト・パーティショニングは個々のドメインで表をセグメント化する
可用性向上のためのパーティショニング
パーティショニング手法によって並列度が1つに決められてしまう他
場合に便利です。リスト・パーティショニング手法では、各パー
データベース・オブジェクトをパーティショニングすると、各パーティ
のデータベース・アーキテクチャとは異なり、Oracleの問い合わせ
＜Blue: 1000100100010010100＞
ティションが個々の値のリストに対応します。
ションを独立させることができます。このパーティションの独立という
パラレル処理は、表のサイズやCPUの数、アクセスされるファイル
＜Green: 0001010000010010000＞
特性は、高可用性戦略の重要な部分を占めます。たとえば、パー
の数、その他の可変要素に基づいて、インテリジェントに決定され
＜Yellow: 0010001000001000010＞
ティショニングされた表の中のあるパーティションが使用できなくて
ます。したがって、パフォーマンスを高めるために管理性を犠牲にす
も、その表の他のパーティションはすべてオンラインかつ使用可能
る必要はありません。Oracle管理者は、可用性と管理性の面から、
なままです。したがって、アプリケーションはこのパーティショニング
それぞれのビジネス要件に最も適したデータ・パーティショニング手
された表に対して問い合わせやトランザクションを引き続き実行で
法を自由に選択できます。Oracleのパラレル・アーキテクチャは、問
き、
使用できないパーティションにアクセスする必要がない場合には、
い合わせパフォーマンスのスケーラブルな活用を透過的に実現しま
さらに、Oracleはレンジ−ハッシュとレンジ−リストのコンポジッ
●
ト・パーティショニング（パーティショニングの組み合わせ）
をサ
ポートしています。
管理性向上のためのパーティショニング
パーティショニングを行なうと、保守操作を表の一部に限定できま
す。たとえば、データベース管理者は表全体をバックアップするかわ
りに、表のパーティションを1つだけバックアップすることができます。
データベース・オブジェクト全体にわたる保守操作の場合、パーティ
ションごとに操作を実行することで、保守プロセスを管理しやすい
単位に分割できます。
管理性向上のためにパーティショニングを使用するのは、一般的に、
データ・ウェアハウスでローリング・ウィンドウ方式のロード・プロセス
をサポートする場合です。週に一度、DBAが新しいデータを表に
ロードする場合について考えてみましょう。この表をレンジ・パーティ
それらのデータベース操作が正常に行なわれます。
すが、データのパーティショニングやマルチノード・ハードウェア・アー
Customer
CREATE BITMAP INDEX cust sales_bji
ON Sales(Customer.state)
れている場合でも、複数のプロセッサやノードにワークロードを分散
WHERE Sales.cust_id ＝ Customer.cust_id；
るのではなく、多数のプロセスで処理の一部を同時に実行するよ
できます。
うにタスクを分割するという考え方です。Oracleでは、1つの文の
パラレル処理は、マルチプロセッサ・ハードウェアでの問い合わせ
実行に必要な処理を複数のプロセス間で分割することにより、プ
応答時間を短縮するのに非常に適した方法です。ただし、問い合
ロセスを1つだけ使用する場合よりも高速に文を実行できます。パ
わせをパラレルに実行すると、使用されるリソースの総量はシリアル
ラレル実行は、大量のデータへのアクセスが発生するさまざまな操
実行の場合よりもわずかに多くなります。そのため、リソースの競合
作で有効です。特に、次の処理のパフォーマンスが向上します。
が発生するような負荷の高いシステムでは、問い合わせをパラレル
集計とコピー
ワークロードは時間とともに変化するため、固定された並列度を利
統計収集
用するのは望ましくありません。Oracleでは、問い合わせの並列度
●
めて使用可能なリソースを活用すべきです。したがって、システムの
タをパージする場合も同様に、パーティションを1つ削除するだけで
バルク挿入、更新、および削除
●
ります。一方、負荷の低いシステムでは、問い合わせの並列度を高
るよりもはるかに効率的です。パーティショニングされた表からデー
大規模な索引の作成
●
化したり、並列度を上げすぎたりすると、逆効果になる可能性があ
が他のパーティションを変更する必要がないため、表全体を変更す
問い合わせ
●
を自動的に調整し、ワークロードの増加に合わせて並列度を抑える
すみます。これは、DELETEコマンドを発行すると大量のリソースを
ことで、リソースの競合を防止します。ワークロードが減少した場合
使って削除対象のすべてのデータにアクセスしなければならないの
は、並列度が再度高められます。
コーディネータ
FROM Sales, Customer
SELECT SUM(SALE.DOLLAR_AMOUNT
FROM Sales, Customer
WHERE Sales.cust_id ＝ Customer.cust_id
AND CUSTOMER.STATE ＝‘ California ’
；
図4: ビットマップ結合索引
ビットマップ索引のサイズは索引付けされた表データのサイズの数
分の1にすぎません。
ビットマップ索引を使用することで最大のメリットが得られるのは、
列のカーディナリティが低い場合、つまり列の固有値の数が表の行
数に比べて少ない場合です。ある列の固有値の数が表の行数の
1%に満たない場合や、ある列で同じ値が100回を超えて繰り返さ
SQL
PE
PE
PE
PE
パフォーマンス向上のためのパーティショニング
コーディネータ
フォーマンスを高めるための最も単純かつ重要な方法です。多くの
場合、パーティション・プルーニングを利用すると問い合わせパ
PE
PE
結果
注文の履歴レコードを含むORDERS表にアクセスし、ORDERS表
が週別にパーティショニングされている場合について考えてみましょ
う。1週間分の注文を要求する問い合わせでは、ORDERS表の
Sales
パラレル実行というのは、1つのプロセスですべての処理を実行す
けですみます。パーティションを1つだけ追加するのであれば、DBA
フォーマンスが桁違いに向上します。たとえば、アプリケーションが
図3: 永続ビットマップ索引
パラレル実行により、サーバーは1つのパーティションがアクセスさ
●
パーティション・プルーニングは、パーティショニングを利用してパ
＜Red: 0100000011000001001＞
パラレル実行
にすれば、ロード・プロセスでは新しいパーティションを追加するだ
に比べて、負荷が小さく簡単なデータ・ディクショナリ操作です。
キービットマップ
キテクチャの制限を受けません。Oracleの動的なパーティション内
ショニングして、各パーティションに1週間分のデータが含まれるよう
図2: パラレル問い合わせの実行
パーティションが1つだけアクセスされます。ORDERS表に2年分の
履歴データが含まれている場合には、問い合わせでアクセスされる
図2は、複数のパラレル実行サーバー
（PE）
が表のスキャンを実行
パーティションの数は104個ではなく1つです。したがって、この問い
する様子を示しています。表は複数の作業単位に動的に分割され
合わせはパーティション・プルーニングを利用するだけで、100倍も
（動的パーティショニング）
、それぞれの作業単位が1つのパラレル
高速化される可能性があるといえます。
実行サーバーによって読み取られます。作業単位と実行サーバーと
パーティション・ワイズ結合と呼ばれる手法を使用すると、複数表結
のマッピングは静的なものではなく、実行時に決定されます。実行
合のパフォーマンスも高めることができます。パーティション・ワイズ
サーバーが作業単位の行の読取りを終えると、作業単位がまだ
結合は、2つの表が結合され、どちらの表も結合キーでパーティショ
残っていれば、コーディネータが別の作業単位を実行サーバーに割
ビットマップ索引
れる場合、その列はビットマップ索引の候補となります。
索引の目的は、表の特定のキー値を含む行へのポインタを提供す
ANDおよびOR演算で結合された複数の条件を評価する際には、
ることです。通常の
（B*ツリー）
索引では、各キーの行IDのリストを
ビットマップ索引がきわめて有効です。Oracleの問い合わせオプ
そのキーの値を持つ行に対応させて格納することで、この目的を達
ティマイザは、WHERE句のAND、OR、およびNOT条件に対応す
成します。各キー値は、格納される行IDごとに繰り返し格納されます。
る索引を組み合せたビットマップ操作の複雑なツリーを含む実行計
ビットマップ索引では、行IDのリストではなく、各キー値のビットマッ
画を生成できます。ビットマップに対するこれらのブール演算は非常
プが使用されます。
に高速であるため、ビットマップ演算を大幅に利用できる問い合わ
ビットマップ内の各ビットは1つの行IDに対応しています。ビットが設
せはパフォーマンスが非常に高いのが一般的です。
定されている場合、対応する行IDを持つ行にキー値が含まれてい
ることを意味します。マッピング関数によってビット位置が実際の行
IDに変換されるため、ビットマップ索引は異なる表現を内部的に使
用するものの、通常の索引と同じ機能を提供します。
ビットマップ索引は、データ量と非定型問い合わせの数が多く、同
時トランザクションの数が少ないデータ・ウェアハウス・アプリケー
ションで威力を発揮します。従来のB*ツリー索引を使って大規模な
表を完全に索引付けすると、表データよりも索引の方が何倍も大
きいために、膨大な領域を占有してしまう可能性があります。通常、
24
表
動的ビットマップ索引と永続ビットマップ索引
オラクル社が特許を持つ画期的なビットマップ索引は、データ・ウェ
アハウス・アプリケーションをはじめとして幅広く使用されています。
他のデータベース・ベンダーが動的ビットマップ索引しか提供してい
ないのに対し、オラクル社は永続ビットマップ索引もサポートしてい
ます。永続ビットマップ索引とは、索引の圧縮されたビットマップ表
現がデータベースに格納される索引構造のことです。これに対して、
動的ビットマップ索引では問い合わせ処理中にデータベース内の
25
Oracle_for_SAP 04.5.28 0:30 PM ページ26
Oracle for SAP BW
Oracle for SAP BW
B*ツリー索引構造がビットマップ構造に変換されます。
スター型変換を理解するには、例を使って説明するのが一番です。
自動メモリー管理
者はSORT_AREA_SIZE、HASH_AREA_SIZE、BITMAP
動的ビットマップ索引では、Oracleの永続ビットマップ索引と同じ
2001年第3四半期の飲料の売上合計を州別に返す、次の問い合
メモリーは重要なシステム・リソースです。メモリーへのアクセスは
_MERGE_AREA_SIZE、CREATE_BITMAP _AREA_SIZEなど
問い合わせパフォーマンスは得られません。動的ビットマップ索引を
わせについて考えてみましょう。ファクト表はSALESです。時間ディ
ディスクのデータへのアクセスよりも何倍も高速であるため、最適な
のパラメータの値を手動で調整する必要が無くなりました。
スター型変換方式
（次の項を参照）
で使用してスター・クエリーを実
メンションは、DAYとQUARTERの2つの表で構成されていることか
システム・パフォーマンスを得るためにはメモリーを有効に使用する
Oracle9iのセルフチューニング機能には、作業領域サイズをチューニ
行できますが、動的ビットマップ索引は依然としてB*ツリー索引を
ら、スノーフレーク・ディメンションです。
必要があります。したがって、管理者はメモリー関連パラメータを
ングして、前述の初期化パラメータの最適な値を決定できるという以
チューニングすることで、システム・パフォーマンスを最大限に高め、
外にもさまざまな効果があります。Oracle9iでは、メモリー使用量を
システム・メモリーをできる限り効率的に使用しようと常に努力して
実行時に動的に変更できるようにメモリー消費アルゴリズム
（ソート、
います。Oracle9iではチューニング・プロセスの大半が自動化され
ハッシュ結合など）
が修正されており、システム・メモリーの使用を最
ているため、管理者はインスタンスのメモリー構成を動的に変更
適化し、システム・パフォーマンスを最大限に高めることが可能です。
できます。以下の機能は、システム・パフォーマンスの向上、メモ
また、Oracle9iでは現在のワークロードの処理に必要な総PGAサイ
リー使用の最適化、および保守ダウンタイムの短縮を実現します。
ズを管理者が決定できます。V$PGA_TARGET_ ADVICEビューに
動的共有メモリー管理
実行操作のパフォーマンスに与える影響をシミュレートした予測が格
Oracleのシステム・グローバル領域
（SGA）
は、すべての実行スレッ
納されています。この予測は、ワークロード履歴を使用し、PGA_
ドがアクセスできる共有メモリー領域です。Oracle9iでは、管理者
AGRREGATE_TARGETのさまざまな設定に対してシステム・パ
がインスタンスを停止せずにSGA構成を変更することで、Oracleイ
フォーマンスをシミュレートすることで生成されます。
ンスタンスのメモリーの追加や削除を簡単に行なえるようになって
自動チューニング・モードは、新たに導入された初期化パラメータで
います。そのため、SGAコンポーネントのサイズを決定する初期化
あるPGA_AGGREGATE_TARGETとWORKAREA_SIZE_
パラメータ
（SHARED_POOL_SIZE、DB_CACHE_SIZE、
POLICYの2つを使ってアクティブにします。PGA_AGGREGATE_
LARGE_POOL_SIZEなど）
は、Oracle9iではすべて動的に設定さ
TARGETパラメータは、DBAがプライベート・メモリーの総消費量を
れます。サポートされているOSプラットフォームであれば、DBAがオ
指定の値に制限するようOracleインスタンスに指示するために使用
ペレーティング・システムでの物理メモリーの使用状況に合わせて、
します。一方、WORKAREA_SIZE_ POLICYパラメータを
「auto」
ベースとしているため、はるかにサイズの大きなB*ツリー索引にアク
セスする際、相当の入出力コストが発生します。
ビットマップ結合索引
オラクル社では、Oracle 7.3以降、B*ツリー索引に加えて永続ビッ
トマップ索引をサポートしてきました。ビットマップ索引は、Oracle
7.3以降のどのリリースでもバージョンアップのたびに強化されてい
ます。Oracle9iでの主な強化点は、表のビットマップ索引を別の表
の列に基づいて作成する機能です。このタイプの索引はビットマッ
SELECT STORE.STATE, SUM(SALES.AMOUNT)
FROM SALES, DAY, QUARTER, PRODUCT, STORE
WHERE SALES.DAY_ID = DAY.DAY_ID AND
DAY.QUARTER_ID = QUARTER.QUARTER_ID
AND SALES.PRODUCT_ID = PRODUCT.PRODUCT_ID
AND SALES.STORE_ID = STORE.STORE_ID
AND PRODUCT.PRODUCT_CATEGORY = 'BEVERAGES'
AND QUARTER.QUARTER_NAME = '2001Q3'
GROUP BY STORE.STATE;
プ結合索引と呼ばれます。ビットマップ結合索引は1つまたは複数
の列の索引であり、異なる表の列を結合できます。ビットマップ結合
索引では、事前に計算された結合結果がきわめて効率的な方法で
具体化されます。ビットマップ結合索引を使用する場合、制限をあ
らかじめ実行しておくことで、実際の表の結合を回避することや、結
合対象データの量を大幅に削減することができます。
データ・ウェアハウスでは、1つ以上のディメンション表
（SAP BWの
次元表）
の1つ以上の列で、スター・スキーマまたはスノーフレーク・
スキーマのファクト表に対して、ビットマップ結合索引を作成するの
が一般的です。さまざまなスター・クエリーに対して行なわれたパ
フォーマンス測定では、問い合わせでビットマップ結合索引を使用
すると応答時間が大幅に短縮されることが実証されています。
変換後の問い合わせは次のようになります。
SELECT STORE.STATE, SUM(SALES.AMOUNT)
FROM SALES, STORE
WHERE SALES.STORE_ID = STORE.STORE_ID
AND SALES.DAY_ID IN
(SELECT DAY.DAY_ID FROM DAY, QUARTER
WHERE DAY.QUARTER_ID = QUARTER.QUARTER_ID
AND QUARTER.QUARTER_NAME = '2001Q3')
AND SALES.PRODUCT_ID IN
(SELECT PRODUCT.PRODUCT_ID FROM PRODUCT
WHERE PRODUCT.PRODUCT_CATEGORY = 'BEVERAGES')
GROUP BY STORE.STATE;
スター・クエリーの最適化
変換後のSQLでは、この問い合わせが2つの主要フェーズに分けて
スター・スキーマは、データ・マートやデータ・ウェアハウスで広く使用
効果的に処理されます。最初のフェーズでは、ビットマップ索引を使っ
されるデータ・モデリング方式です。スター・スキーマには通常、トラ
て、必要なすべての行がファクト表から取り出されます。この場合、
ンザクション・データを格納する非常に大規模な表
（ファクト表）
が1
ファクト表にはDAY_IDとPRODUCT_IDのビットマップ索引を使って
つ以上と、記述データを格納する小規模な参照表
（ディメンション表）
アクセスします。これは、DAY_IDとPRODUCT_IDが副問い合わせ
が多数含まれています。Oracleは、問い合わせをスター・スキーマ
の条件で用いられる2つの列であるためです。
に対して評価するためのスター型変換という手法をサポートしていま
問い合わせの2番目のフェーズ（後戻り結合フェーズ）
では、ディメン
す。この手法では、基のSQLに新しい副問い合わせを追加する変
ション表が最初のフェーズのデータ・セットに戻って結合されます。この
換が適用され、スター問い合わせのパフォーマンスが向上します。
問い合わせでは、ディメンション表の列のうちSTORE.STATEだけが
この新しい副問い合わせにより、ビットマップ索引を使ってファクト
選択リストに指定されているため、結合する必要がある表はSTORE表
表にアクセスする際の効率が非常に高まります。
だけです。問い合わせの最初のフェーズにPRODUCT、DAY、およ
びQUARTERを含む副問い合わせが存在することから、2番目の
フェーズでこれらの表を結合する必要はなくなり、問い合わせオプティ
ディメンション2
ディメンション1
マイザによって不要な結合がインテリジェントに除外されます。
スター型変換はコストベースの問い合わせ変換です。特定のディメ
ビット
マップ
ビット
マップ
ンションで副問い合わせを使用した場合にコストに勝る効果が得ら
れるかどうか、またリライトされた問い合わせが基の問い合わせより
ファクト表
ビット
マップ
ディメンション3
ビットマップ
AND
適切であるかどうかの判断は、オプティマイザによるコスト見積もり
に基づいて行われます。
ビット
マップ
このスター・クエリー実行手法は、オラクル社が特許を持つユニー
ディメンション4
クなテクノロジーです。他ベンダーもスター・クエリー用の同様の問
い合わせ変換機能を用意していますが、変換後の問い合わせで静
的ビットマップ索引を使用し、さらに後戻り結合をインテリジェントに
図5: スター型結合
26
除外する機能を提供しているベンダーは他にありません。
は、PGA_AGGREGATE_TARGETパラメータの値の増減が長時間
Oracleの仮想アドレス空間を変更することも可能です。
または「manual」に設定すると、自動チューニング・モードを有効化
管理者は、ALTER SYSTEMコマンドを使って、動的SGAに対して
または無効化することができます。
次の処理を実行できます。
●
SGAコンポーネント
（バッファ・キャッシュ、共有プール、ラージ・
プール）
のサイズを増やす。
●
データ格納: 圧縮済データ・セグメント
これまで、市販のリレーショナル・データベース・システムでは、リレー
ショナル表に格納されたデータに対して圧縮手法が用いられていま
SGAコンポーネントのサイズをOracleの既定最小値まで減らし
せんでした。圧縮した場合の時間と領域のトレードオフが必ずしも
て、SGAを小さくする。
魅力的ではなかったというのがその理由です。一般的な圧縮手法
では、領域は節約されても、問い合わせの応答時間が大幅に延び
動的SGAには数々のメリットがあります。たとえば、他のSGAコン
るというデメリットが伴います。
ポーネント
（共有プールなど）
のメモリー所要量が増加した場合、
バッファ・キャッシュのメモリーを解放して、そのSGAコンポーネントに
渡すことができます。逆に、バッファ・キャッシュ・ヒット率が低い場合
は、ラージ・プールや共有プールといった他のSGAコンポーネントの
Oracleブロック（未圧縮）
Oracleブロック（圧縮済）
ブロック・ヘッダー
ブロック・ヘッダー
1 10025 500000 300000
10025 500000 300000
メモリーを減らして、バッファ・キャッシュのサイズを増やすことができ
2 10025 500000 300000
310000 320000 500001
ます。また、システム・ハードウェアの変更やOSリソース・マネージャ
3 10025 500000 310000
1
1
2
3
2
1
2
3
4 10025 500000 310000
3
1
2
4
4
1
2
4
5 10025 500000 320000
5
1
2
5
6
1
2
5
6 10025 500000 320000
7
1
6
3
8
1
6
3
7 10025 500001 300000
9
1
6
4 10
1
6
4
8 10025 500001 300000
11
1
6
5
の割りあての変更によってOracleで使用できるメモリー量が変化し
た場合にも対応できます。
SQL実行メモリーのセルフチューニング
9 10025 500001 310000
DSS環境でよく見られる複雑な結合またはソート操作を実行する問
10 10025 500001 310000
い合わせは、処理中のデータをソートする際に大量のメモリーを消
11 10025 500001 320000
費します。Oracle9iでは、セルフチューニングを自動的に実行する
ことで、そのようなSQL実行メモリーをできる限り効率的に使用し、
システム・パフォーマンスを最適化することができます。チューニン
グ・プロセスの目標は、現在の状況に適応して、システム負荷に関
係なくリソースを効率的に利用することです。このモードでは、シス
テム・パフォーマンスが最大になるように、セッションによって割りあ
てられたすべての作業領域が自動的にチューニングされます。管理
図6: 圧縮済データ・セグメント: 仕組み
Oracle9iリリース2 Enterprise Editionでは、大規模なデータ・ウェ
アハウスにとって非常に魅力的な、ユニークな圧縮手法が導入され
ました。この圧縮手法はリレーショナル・データ用に最適化されてい
るため、標準的な圧縮アルゴリズムと比べるとディスク領域の削減
27
Oracle_for_SAP 04.5.28 0:31 PM ページ28
Oracle for SAP BW
Oracle9i RAC
率がきわめて高く、また圧縮済のデータに対する問い合わせのパ
決してありません。
フォーマンスにはほとんど悪影響を与えません。さらに、大量のデー
タにアクセスする問い合わせには非常によい影響を与えます。その
スケーラビリティ: SAPのアプリケーションは3層アーキテクチャを
いたるまでさまざまなハードウェアを必要に応じて追加または削
Oracle9i Release 2では、データベース・ブロック内の重複値を排除
ベースとしています。データはデータベース・サーバーに格納され、
除することが可能なOracle9i RACは、グリッド・コンピューティン
することで、データを圧縮します。データベース・ブロックに格納された
アプリケーション機能はアプリケーション・サーバーで実行されま
グのコンセプトに最適です。
上、顧客はバックアップやリカバリといったデータ管理操作のパ
圧縮済データは自己完結型です。つまり、あるブロックの未圧縮デー
す。ユーザーのデバイスはただ表示機能を実行するだけです。こ
フォーマンスが向上したことを実感できます。Oracle9iの圧縮手法
タを再作成するのに必要な情報は、すべてそのブロックの中に含まれ
のアーキテクチャは、アプリケーション層でのスケーラビリティを
Oracle9i RACでは自動ワークロード分散が可能ですか?
を利用すれば、圧縮済データが未圧縮データより大きくなることは
ています。ブロック内のすべての行および列の中の重複値は、ブロッ
提供します。これは、SAPが複数のアプリケーション・サーバー・
はい。ただし、この機能は常に使用するとは限りません。Oracle9i
クの先頭にあるそのブロックのシンボル表に一度だけ格納されます。
インスタンスをまたがったアプリケーション・ワークロードの分散を
RACをSAPのMCODとともに使用しており、Oracleインスタンスの
再度出現した値は、すべてシンボル表への短い参照に置き換えられ
サポートしているため、複数のアプリケーション・サーバー・マシン
1つをR/3ワークロード用に、別のインスタンスをCRMワークロード
ます。圧縮済のデータベース・ブロックは、先頭にシンボル表があるこ
で実行できるからです。ただし、データベース・サーバーは1台しか
用に、さらに他のインスタンスをBWワークロード用にといった具合
とを除けば、通常のデータベース・ブロックとほとんど同じです。
必要としないため、SAPのアーキテクチャはデータベース層では
に最適に処理できるように構成している場合、あるいはオンライン・
Oracle9i Release 2で圧縮可能なデータベース・オブジェクトは、
それほどスケーラブルではありません。したがって、これまで、アプ
トランザクションとバッチ・ジョブを分けるために2つのインスタンス
表とマテリアライズド・ビューです。パーティショニングされた表の場
リケーション・サーバーのワークロードが増加している場合に既存
を使用している場合には、自動ワークロード分散を行なうとシステム
合、一部のパーティションを圧縮するか、すべてのパーティションを
のマシンを大規模なものにリプレースする
（スケールアップ）
か、同
のコンセプト自体が損なわれます。一方、非常によく似たワークロー
圧縮するかを選択できます。圧縮属性は、表領域、表、表のパー
様のサイズおよび能力のマシンを追加する
（スケールアウト）
かは、
ドに対して複数のOracleインスタンスを使用している場合は、自動
ティションのいずれかに対して宣言できます。
顧客の選択に任されていました。一方、データベース層ではス
ワークロード分散が有効となるでしょう。
圧縮の主なメリットは領域を節約できることです。通常、未圧縮デー
ケールアップ戦略しか選択肢がありませんでした。Oracle9i
タと圧縮済データのサイズの比率は圧縮率と呼ばれます。たとえば、
RACはこのような状況を変えたのです。アプリケーションにとって、
圧縮率2は未圧縮データが圧縮済データの2倍のディスク領域を占
Oracle9i RACは1台のデータベース・サーバーとまったく同じよう
有することを示します。オラクル社では、さまざまな業界から実際の顧
に見えますが、実際には複数のOracle9i RACインスタンスが複
客を何社か選び、そのデータを使って圧縮のテストを行ないました。
数のマシンで稼働しています。いい換えれば、Oracle9i RACは、
大規模なデータ・ウェアハウス表における一般的な圧縮率は2:1∼
SAPアプリケーション層で常に利用できたスケーラビリティ・オプ
4:1です。これより高い圧縮率も測定されています。
ションのすべてをデータベース層にもたらします。
Original
Compressed
3.5TB
(45GB each)
1.1TB
(14GB each)
-60%
80 × Cube
1TB
(13GB each)
480GB
(6GB each)
-54%
800 × Aggregate
2GB
1GB
-50%
Space Type
80 × PSA
Space
図7a: 圧縮済データ・セグメント: テスト結果（領域）
Space Type
Orig.
FTS Queries
with 100％ buffer hits
11sec
FTS Queries
with 0％ buffer hits
31sec
Index Access Queries
with I/O
313sec
Compr.
Throughput
8sec
17sec
254sec
+38％
+82％
+23％
●
SAP BWのテスト・シナリオで主要ターゲット・オブジェクトを圧縮した
●
ところ、何も手を加えない状態で約3:1の圧縮率が得られました。こ
のテスト・ケースの詳細は、前号の
『Oracle for SAP Technology
図7b: 圧縮済データ・セグメント: テスト結果（スループット）
セスが使用するいくつかのメモリー構造
（特にSGA）
です。
ることをデータベース・サーバー・インスタンスに要求するため、さ
まざまな方法でデータベース・サーバー・インスタンスを構成しな
ければなりません。Oracle9i RACは、MCODで必要とされるシ
28
Oracle9i RAC for SAPの顧客はどのようなメリッ
トを得ることができますか?
●
高可用性: データベース・サーバー・マシンが1台しかなく、その上
標準的なOracleでは、データベースとインスタンスが1対1の関係に
でOracleインスタンスが1つ稼働している場合、このマシンがク
あることが必要です。1つのデータベースに対して2つのインスタンス
ラッシュするとデータベースにアクセスできなくなります。フェイル
が同時にアクセスすることも、1つのインスタンスを2つの異なるデー
オーバー・クラスタが1つの場合に、Oracleインスタンスが稼働し
タベースに同時に接続することもできません。このルールは、1つの
ているマシンがクラッシュすると、フェイルオーバー・マシンでイン
データベースに関連するワークロード全体を1つのデータベース・
スタンスが再稼働するまでにかなりの時間がかかります。これに
サーバー・マシンで実行しなければならないことを意味しています。
対して、Oracle9i RACを使用すれば複数の異なるマシンで複数
Oracle9i Real Application Clusters
（RAC）
はこの制約を排除し
のインスタンスを稼働させることができます。したがって、1台のマ
ます。RACを使用すると、複数のマシンで実行されている複数の
シンがクラッシュしても、使用できなくなったインスタンスに接続し
Oracleインスタンスが同じOracleデータベースにアクセスできます。
ていたユーザーは使用可能な他のインスタンスに再接続できるた
いい換えれば、Oracleの顧客はデータベース・サーバーのワーク
め、損害は発生しません。
トウェア・パッチを関係するすべてのノードに段階的に適用すること
追加や削除もシステムを停止することなく行なえます。
難しくなります。各mySAPコンポーネントがそれぞれまったく異な
ロードを分割して、複数のマシンに分散できるのです。
大きく分けて4つのメリットがあります。
モードで
（異なる保守レベルで）
実行できるため、データベース・ソフ
が可能です。さらに、既存のOracle9i RACシステムからのノードの
データを1つの共通データベースに格納できます。このオプション
標準的なOracle Database Serverは、データベースとインスタンス
ベース・サーバー・マシンで実行される一連のプロセス、およびプロ
しています。Oracle9i RACインスタンスは任意の期間にわたり混合
は異なるmySAPコンポーネント
（R/3、CRM、BW）
で作成した
Update』
の14-17ページを参照してください。
Oracle9i Real Application Clusters
（RAC）
for
SAP ─ FAQ
ディスクに格納された一連のファイルです。インスタンスとは、データ
ウンタイム・パッチと呼ばれる処理を実行できるテクノロジーを提供
Database）
というのはSAPのインストール・オプションです。顧客
ようになりますが、データベース・サーバー・インスタンスの構成は
という2つの主要コンポーネントで構成されます。データベースとは、
はい。オラクル社は、ローリング・パッチ・アップグレードやゼロ・ダ
MCODサポート: MCOD（Multiple Components in One
を使用すると、一貫したバックアップとリカバリが簡単に行なえる
Oracle9i Real Application Clustersとは何ですか?
Oracle9i RACでは計画外停止のみ防止できるのですか?
それとも計画停止も最小限に抑えることができますか?
●
話題に上るのはほとんどが技術的な内容ですが、そう
いったことには興味がありません。私が目的としている
のはコスト削減です。Oracle9i RACはコスト削減に
も役立ちますか?
もちろんです。技術面での次にあげるメリットは、コスト削減に直接
結びつきます。
●
高可用性は第一に、企業がミッションクリティカルなシステムの停
ングル・データベース方式を採用しながらも、多様性を持つ
止による金銭的損害を受けないことを意味します。また、異なる
mySAPコンポーネントに必要な、構成の異なる複数のOracleイ
ノードに複数のインスタンスが存在するということは、サポートに
ンスタンスの使用が可能であることから、MCODと併用するのに
費やすコストを削減できることを意味します。なぜなら、インスタ
非常に適しています。
ンスの1つが停止しても3つが引き続き稼働していれば、インスタ
ンスの1つが停止してサービス全体が停止してしまうという状況ほ
アダプティブ・コンピューティング／グリッド・コンピューティング:
ど重大ではないためです。
今日のITインフラストラクチャでは、独立したコンピューティン
グ・リソースが特定のアプリケーションに永久的に割り当てられ
●
スケーラビリティは、ワークロードが増加している場合に、市販さ
ます。このようなリソースは、ピーク・ワークロードに合わせてサ
れている中で最大のマシンを購入し既存マシンをリプレースする
イズ設定する必要がありますが、ピーク・ワークロードは数時間
必要が必ずしもないことを意味します。大規模マシンを1台購入
しか続かないため、大量のリソースが長時間にわたってアイドル
するかわりに小規模マシンを4台購入し
（大幅なコスト削減につな
状態となります。現在、ほとんどの人はITインフラストラクチャが
がります）
、長期にわたって使用することができます
（さらにコスト
今後変化していくと考えています。コンピューティング・ユニット
が削減されます。
）
。
やストレージ・ユニット、制御メカニズムなどがプールされ、管理
●
者は実行する必要のある作業にこれらのユニットを割りあてて、
ワークロードが変化するたびに割りあてを素早く変更できるよう
になるでしょう。Oracleインスタンスを必要に応じて開始または
停止でき、小規模なブレードから大規模かつ強力なサーバーに
アダプティブ/グリッド・コンピューティングは、リソースの使用を効
率化することにより、既存のアプリケーションに使用するリソース
を削減したり、既存のリソースでより多くのアプリケーションを実
行したりできることを意味します。
29
Oracle_for_SAP 04.5.28 2:33 PM ページ30
Oracle9i RAC
オラクル社からは、Oracle9i RACを使用すると大規
模で高価なコンピュータではなく小規模で安価なコン
ピュータを購入できるのでコスト削減に役立つ、という
説明を何度も受けています。これは、わが社のIT戦略が
大規模なサーバー・マシンをベースとしている場合は
RACを検討しても意味がないということでしょうか?
いいえ。大規模マシンを使用している場合でも、高可用性に関連
Oracle9i RACはアプリケーションに対して透過的で
ある、つまりRACベースのデータベース・サーバーにア
クセスするためにアプリケーションを変更する必要はな
いという話が以前オラクル社からありました。しかし、
SAPソフトウェアが一般にRACで使用できるようにな
るまではSAPソフトウェアを変更する必要があるとも聞
きました。どちらが正しいのでしょうか?
したメリット
（計画外停止や計画停止の減少など）
はすべてあてはま
どちらも正しいです。Oracle9i RACはSAPアプリケーションととも
ります。RACを使用すれば、ワークロード分散も強化されるため、既
に透過的に使用できます。このことは、2002年という早い時期に
存のリソースをさらに効果的に活用できます。
SAPのコードを1行も変更せずに問題なく実施された一連のSAP標
日本オラクル＠SAP常駐隊
日本オラクル株式会社では、2003年夏からSAPジャパン株式会社
ワールドワイドな24時間サポートの実現
に社員を派遣し、お客様により良いサービスをご提供するという
このSAPジャパンにおける日本オラクルの協調サポートは、グロー
ミッションのもとSAPジャパン株式会社のグローバルサポートとコラ
バルでは11年も前から始まっています。一番最初に発足したのはド
ボレーションサポートを行なっています。今回この協調サポートでど
イツオラクルによる協調サポートで、SAP本社のあるドイツ、ワルド
んなことを行なっているのかを簡単にご紹介します。
ルフを拠点として開始されました。その後USオラクルによる協調サ
ポートがUSカリフォルニア、フォスターシティを拠点として開始され、
オラクル社によるSAPシステムサポートは強固なものになっていきま
準ベンチマークで実証されました。しかし、SAPはアプリケーション
Oracle9i RACが2年後には誰も覚えていないような
単なる短期的マーケティング・イニシアチブではないとい
うことは、どうしたらわかりますか?このテクノロジーに
時間と経費を注ぎ込む意味が本当にあるのでしょうか?
Oracle9iに続くメジャー・リリースはOracle 10gと呼ばれます。
「g」
は、
グリッド・コンピューティングがこの新リリースの焦点であることを示
した。しかし、2拠点のみで24時間サポートを実施することは困難で
だけを出荷しているわけではありません。SAPソフトウェアには管理
したので、昨年3拠点目が日本を拠点として発足しました。日本オラ
ツールも含まれており、その中にSAPDBAやBR*Toolsといった
クルの協調サポートは日本を含むアジア全域＊2をカバーしています。
データベース管理ツールがあります。これらのツールは、RAC対応と
これにより、今まではドイツの通常作業時間になるまで待たなけれ
するために部分的な変更が必要になります。
ばならなかった緊急性の高い問題も、アジアの通常作業時間帯に
対応することが可能になり、よりスピーディなサポートを展開できる
使用しているプラットフォーム向けのOracle9i RAC
for SAPのステータスを調べるにはどうしたらよいで
しょうか?
ようになりました。もちろん、日本の夜間時間帯に発生した緊急度
略を継続し、進化させたものです。したがって、このテクノロジーが
現在のステータスと今後の計画の概要は、OSSノート527843に記
ポートチームメンバーによって従来通りカバーされています。
消滅することはなく、むしろ中心となっていきます。
載されています。詳細については、日本オラクルまたは各ハードウェ
しています。Oracle 10gで実現されるグリッド・コンピューティングは、
Oracle9i RACで導入されたワークロード分散とリソース利用の戦
の高いオラクルに関する問題はドイツ、アメリカのオラクル社協調サ
今後のよりよいサポートを目指して
ア・ベンダまでお問い合わせください。
Oracle9i RACからシングルインスタンス・システムに
戻す方法はありますか?
グローバルでは、長年蓄積されたノウハウを生かして、SAPシステム
におけるオラクル製品のよりよい使用方法をお客様に直接ご提供
はい。シングルインスタンス・システムからOracle9i RACシステム
するサービスを行なっています。＊3このサービスでは、オラクル上で
にアップグレードしても、データベースでは何も変更されません。
SAPシステム精通したスタッフが常駐
したがって、いつでもシングルインスタンス・システムに戻すことが
通常「協調サポート」
と聞くと、他社製品スタッフへの自社製品のス
できます。
キルトランスファーのみを指すことが多く、実際に他社に常駐し、さ
らにサポート組織に属して積極的に問題解決にあたるケースはあま
Oracle9i RACはSAPの認定を受けていますか?
り聞きません。実際にサポート組織に属してサポートするには、自社
SAPでは、Oracle9i RAC単体への認定は行なっていません。
製品の知識のみならず他社製品の知識が必要になるからです。し
RACはベンダー固有のソフトウェアやハードウェアへの依存度が高
かし、日本オラクルは社員をSAPサポート組織へ常駐させることに
いため、各プラットフォーム
（ハードウェア/ソフトウェア・スタック）
と
より、本当の意味での協調サポートを実現しました。現在行なって
Oracle9i RACの組み合わせごとに認定する必要があります。
いる協調サポートでは、SAPスタッフへのオラクルスキルトランス
●
なったり、システムにパフォーマンスが悪い箇所があった場合にSAP
システム下におけるオラクル製品の観点からチューニングを行なった
り、トラブル発生時のより安全でスピーディな復旧方法と準備のア
ドバイス等を行なっています。今後日本オラクルでも、このサービス
を提供していく予定です。オラクル社によるSAPシステムの協調サ
ポートは、グローバルなチームとして今後も発展を続けていきますの
で、今後の展開にどうぞご期待ください。
ン株式会社のサポートスタッフと共にSAPサポート組織に属し、
＊1：SAPジャパンのグローバルサポートは2レベルで構成されており、そのうち上位レベルにあ
たるデベロプメントサポートのオラクル製品に関するコンポーネントを日本オラクル社が担当
しています。
技術的検証フェーズでは、事前に定義された一連のラボ・テスト
SAPシステムのサポートを行なっています。お客様からSAPサポート
＊２：SAPにおけるアジア地域の定義に準拠します。
を実施します。認定対象のプラットフォームですべてのテストに合
に寄せられる多くのオラクル製品に関する質問のうち、難易度の高
＊３：Oracle Advansed Product Service
（APS）
格する必要があります。テストの一部は、スケーラビリティの実証
＊1
いものがオラクル社のサポートチームにあがってきます。
そこで本当
を目的としたベンチマークです。
にオラクル固有の問題なのかが切り分けられ、オラクル固有の問題
認定プロセスは次の3つのフェーズで構成されます。
●
ファーのみならず、実際に茅場町に3名の社員が常駐。SAPジャパ
稼動するSAPシステムをより良いものにするためのアドバイスを行
2番目のフェーズでは、ラボから1∼2社のパイロット顧客へ、また
テスト・システムから実際のシステムへとテクノロジーが移植されま
が発生した場合、オラクル社のノウハウを駆使しスピーディに問題
解決を行なう手助けができるようになりました。
す。テスト内容は顧客が定義します。このフェーズは、顧客が本
稼働を始めると決定した時点で終了します。
●
Ramp Upフェーズでは、より多くの顧客がOracle9i RAC for
SAPを使用できますが、顧客の数には依然として制限を設けてい
ます。これは、少しでも異なる環境で、異なる期待を持ってテクノ
ロジーが使用される場合には、通常以上のサポートが必要にな
ると予測しているためです。Ramp Uoフェーズの後は、一般出荷
としてすべての顧客が使用可能になります。
30
31

Download Report