さらに、2つの実際のCOPAクエリーを使用するテストを実行しま した。このテストでは何ら作為的なことは行いませんでしたが、
実行時間は大きく加速し、50秒と1.5秒、72秒と2.5秒という結果 でした。
Oracle Database In-Memoryを使用すると、大量のデータを驚 異的な速さで選択して統合できます。つまり、実装はわずかな 作業で完了します。これは実行時間の短縮を意味し、ビレロイ&
ボッホにとって特に重要でした。
「わずかな作業で実装可能」、これがOracle Database In-Mem-oryの使用に期待する一番の理由です。結果として、必要だった のは次の項目のみでした。
• 既存のハードウェア、オペレーティング・システム、仮想化テクノ ロジの使用
• Oracle 11gからOracle 12cへのデータベースのアップグレード
• 少数のデータベース・パラメータの使用によるDatabase In-memoryのアクティブ化
• In-Memory用の表のアクティブ化
• 表またはデータベースの移行なし
• SAPアプリケーション・コードへの適応なし
少ない資源要件で多くの利点
ビレロイ&ボッホは、パフォーマンスの大幅な向上を期待してい ましたが、向上は予想を上回り、実に見事でした。同時に、Oracle Database In-Memoryテクノロジの隠れた可能性が徐々に明ら かになっていくようでした。
迅速な実装とテストのパフォーマンスは申し分のない説得力で す。このテクノロジの使用が有利と思われるもう1つのプラス面 は、メモリーの追加で対応できるため、ハードウェアを新たに購 入する必要がないことです。In-Memoryテクノロジを使用して、
すべての表をデータベース化することは適切ではありません。目 的に応じて使用する表のみにOracle Database In-Memoryを 有効化します。そうすることで表は小さくなります。また、純粋な1 組のクエリーを実行するだけの表を作成することもできます。こ の場合、Oracle In-Memoryの列指向のストレージは必要ありま せん。
列指向のストレージは、既存のインフラストラクチャ、および仮 想環境ですぐに使用できますが、既存のデータベースまたは SAPアプリケーション内の特殊な適応または変更も必要なく、ご くわずかな作業で管理できます。これまでの長い経験から、Ora-cleデータベースのアップグレードに伴うリスクが最小限であるこ とは周知の事実です。
図: Oracle Database In-Memoryのパフォーマンス
図: Oracle Database In-MemoryのCOPAクエリーのパフォーマンス
• Oracle Database In-Memoryによる、レポート実行 時間の大幅な向上
• 数倍の向上
• わずかな実装作業
• 既存ハードウェアに実装
• アプリケーションの変更なし
• データ移行が不要
• すべてのOracleデータべース機能をそのまま使用
Flat CubesとOracleで享受できるSAP NetWeaver BWのさらなる 進化
SAPは、SAP HANAの立ち上げと同時にHANA-Optimized Info-Cubesを開発しましたが、列指向のIn-Memoryテクノロジでしか 使用できません。ファクト表とディメンション表を構成する既存の InfoCubesの「スノーフレーク」データ・モデルは、フラット表に移 行されました。
同様のテクノロジは、2016年後半以降、Oracleデータベース、
およびキーワード「Flat Cube on SAP BW on Oracle」の下の In-Memoryオプションとともに、SAP NetWaver BWのすべて の顧客に提供されています（SAP Note: 2335159を参照してく ださい）。既存のInfoCubesは、必要に応じて、SAP標準プログラ ムRSANAORAを使用して変換されます。InfoCube（E表、F表、お よび関連するディメンション表）は、再パーティション化された フォーマットで、1つのフラット表として作成されています。
ビレロイ&ボッホは、2016年中期のOracle In-Memoryテクノロ ジの本番への導入に続き、2016年末から2017年初旬にかけて 実行した別のテストで、SAP NetWeaver BWのInfoCubesの一 部をFlat Cubesに変換しました。
1億1000万のデータセットを含むInfoCube（7GBは索引）はサ イズが13GBで、変換プロセスの所要時間は1時間42分でした が、変換後のFlat Cubeのサイズは7.2GB、索引は0.3GBになり ました。予想されていたレスポンス時間も改善され、さらにスト レージ内のデータベースのサイズも縮小されました。
OracleのFlat Cubeによるパフォーマンスの飛躍的な向上 Flat Cubesの変換により、以前のIn-Memoryソリューションの 実行時間は100秒から飛躍的に改善されました。Flat Cubeと In-Memoryによって、20秒までに短縮されたのです。それだけで はありません。ロードが約30%加速し、さらに統合が不要になり BWモデリングが簡素化されました。これはすべてFlat Cubeの使 用によるメリットです。
図: Flat Cubeの再パーティション化とアクティブ化
オラクルでは、Flat Cubesに変換する場合はSAP NetWeaver バージョン7.40 SP16の使用を推奨しています。現状SAPでは、
トランザクションの（計画可能な）InfoCubesまたは意味的に パーティション化されたオブジェクト（SPO）を変換することは不 可能ですが、SAPは変換を可能にすることを2017年に計画して います。
テストのサマリー
Oracle Database In-Memoryを使用することで、ビレロイ&ボッ ホはSAP用に何年も信頼し使用してきた現在のOracleデータ ベースを別のデータベース・システムと交換する必要はありませ ん。ビレロイ&ボッホは、SAP CRMシステムだけではなく、本番の SAP NetWeaver BWでもOracle Database In-Memoryを上手 に活用しています。
投資に見合ったOracle Database In-Memoryテクノロジの作業 量と妥当なコストは、すぐに次のメリットとして表に現れました。
• レポートのクエリー時間が大幅にスピードアップ
• レポート作成で優れた効果を発揮する分析オプション
ここでも、OracleデータベースはSAP環境のデータベースの長期 的な安定要素としての地位を証明し、非常に速く、ほんの少しの 作業で実装できる技術革新を提供します。
図: 実行時間の比較
「Oracle 12cとOracle Database In-Memo-ryに基づくテストで、PoCは、パフォーマンス の向上という点で、驚く結果を出しました。ま た、BIでは、1度作成したSAPアプリケーション を一切変更せずに、Oracle Database In-Me-moryで使用できるという事実が特にすばらし いですね。さらに、In-Memoryで処理するSAP BW表と処理しないSAP BW表を簡単に選別 できます。」
HARALD WOLF氏
ビレロイ&ボッホ、ビジネス・インテリジェンス 担当、上級顧問
ボッシュ・グループは、テクノロジとサービス分野で世界をリード するグローバル・サプライヤです。2015年12月31日時点で、雇 用する従業員は全世界でおよそ375,000人になります。2015年 の売上高は706億ユーロを計上しています。同社の事業は、モビ リシティ・ソリューション、産業技術、消費財、エネルギーおよび 建築技術の4つの事業部門に分類されます。ボッシュ・グループ は、世界60か国以上に展開されるRobert Bosch GmbHおよび 約440の子会社と関連会社で構成され、販売およびサービス代 理店を加えると、ボッシュの世界的な製造、販売のネットワーク は約150か国に及びます。この会社の成長の基盤は、その革新 力にあります。ボッシュの世界中の118拠点では、55,800人の従 業員が研究開発に携わっつています。ボッシュ・グループは、コ ネクテッドライフに向けたイノベーションの提供を戦略的目標に 定め、革新的で人々を夢中にさせる製品とサービスで、世界中の 人々の生活を向上させます。手短に言うと、ボッシュが作り出す のは、Invented for life（生活を豊かにするテクノロジ）です。
Bosch GmbHは、マーケットのリーダーとしても、革新的な企業 としてもよく知られた存在で、「Invented for life」をキャッチフ レーズにしています。この言葉は、生活の向上、コネクテッドライ フのイノベーションを提供するという経営目標の本質を明確に 示しています。
ボッシュは、SAPを稼働するデータベースのベンダーとしてのオ ラクルに10年来の信頼を寄せています。Oracleデータベース は、ボッシュのインフラストラクチャの中核的な要素で、重要な 基盤です。Oracleデータベースは、併用された様々なSAPのアプ リケーションの中にあっても独立して運用され、事業の多角化 に成功を収めたこのグループの多様なニーズに最適な対応を しています。
ボッシュのIT部門は、1,500人以上のIT専門家とプロセス・エキ スパートで構成され、新しいOracle Database 12cの機能とオ プションも早い時期から、IT部門の手によって存分に検証され ています。2015年半ばは、Oracle Database In-Memoryの機 能と利点が中心でした。
「SAPを使用する上で、最適化を実行する際に、Oracle Database In-Memoryがどれほど役に立つか知りたかったのです。これは、
OLAPとOLTPのアプリケーションの両方に当てはまりました。す ぐに私たちは、特にSAP CRMの使用で、自分たちが利益を得る 立場にあることを認識しました。」とIT運用組織のプロジェクトマ ネージャ兼データベース・エキスパートは説明しています。
ボッシュのITチームは、社内およびオラクルによるソリューション のシナリオとユース・ケースを検討しました。その結果、SAP BW Analyticsと併用した場合にOracle Database In-Memoryが大 きな利点を提供することが分かりました。
しかし、ボッシュにとって一層重要だったことは、特にSAP CRM の場合、OLTPシステムで達成される計画的で優先度の高い最 適化が、Oracle 12cのOracle Database In-Memoryでも可能で あるという事実でした。実際、これが最も差し迫った問題でした。
ボッシュのITチームは、SAP CRM / OLTPを使用する際に、レベ ルが若干落ちるパフォーマンスを容易に排除できる、手ごろな価 格のソリューションを必要としていました。まさにそのための正し い選択が、Oracle 12cのOracle Database In-Memoryでした。
2次インデックスの課題
このCRMのユース・ケースでは、確実に問題視される、2次イン デックスと定期的な作成が必要な特別なオーダーメイドのイン デックスが課題でした。ボッシュによると、「ユーザーがSAP CRM 機能を特化させて集中して使用した場合、特定のCRMオブジェ クトおよび表に、追加のインデックスを継続して作成しする必要 があります。これが、私たちの各使用の要件に従ってシステムを 使用する唯一の方法でした。ただし、この方法では特にCRMの 検索オプションや検索の可用性を100%活用することは不可能 でした。このような検索オプションが、必ずしも追加のインデック スでサポートされているとは限らないからです。そのために、一 部のアプリケーションの機能は、タイムアウトすることだけしかで きません。」
時間の経過に伴い、約80の追加的なインデックスが作成され蓄 積されていました。これは、メンテナンスの必要性、パフォーマン ス関連のチューニング、コストのかかるリソースの使用という結 果になりました。また、これらのインデックスがラージ・オブジェク トであったため、十分なストレージ容量の確保も必要でした。
SAPアプリケーションを既存のままで、Oracle Database In-Memoryによりビジネス・プロセスの加速、
コスト削減を実現したBosch GmbH