T E C H N O L O G Y U P D A T E
Oracle SAP
for
•
Oracle Database 12c –
クラウド対応のシンプルな世界初のデータベース•
Oracle Database In-Memory –
リアルタイム・エンタープライズの実現•
Flat Cubes for SAP BW –
データ・モデリングの簡素化とデータ・ロードの加速•
Information Lifecycle Management –
実証済みのパフォーマンスの利点•
Hybrid Columnar Compression –
I/O減少で最高レベルのデータ圧縮•
Oracle Multitenant – Pluggable Databases –
統合の簡素化•
Oracle Database Vault –
既存アプリケーションのセキュリティの強化SAPアプリケーションの実行を改善する完全なITデータベースとインフラ・スタックの提供
No. 26 Oracle for SAP, May 2017 www.oracle.com/sap
オラクルは、データベース、ビジネス・ソフトウェア、オペレーティング・システム、サーバー、スト レージなど、世界で最も完全でオープンな、統合されたテクノロジ・スタックを提供します。オラクル のテクノロジがSAPアプリケーションの動作を向上させます。
オラクルとSAP SEの関係は、共通の顧客の利益を共通の課題とし、長年に渡り受け継がれてき た共同開発と確かな未来の上に築き上げられています。
SAPがSAP Business SuiteとSAP BWのサポートを続ける限り、オラクルも支援し続けます。SAP は、SAP NetWeaver 7.4 SP08でCore Data ServicesなどのOracle Databaseプラットフォームの新 しい技術（SAP Note 1951491）やOracle Database 12c In-Memory（SAP Note 2178980）、SAP BW optimized InfoCubes/Flat Cubesといった、オラクルの強みを生かした技術革新を導入し始 めています。
SAPユーザー・グループが実施した最新の市場調査によると（2017年2月）*、 • 現在、S/4 HANAを実稼働しているのは、ドイツ語圏のSAP顧客のわずか2パーセント • 50パーセントの顧客にとって、S4は従来のERPシステムの代替ではない
• S/4 HANAを主要なSAPプラットフォームとして2020年に実行を計画しているのは、SAP顧客のわずか3分の1つまり、SAP顧客の大多数は、 依然としてSAP NetWeaverスタックの使用を継続し、SAP Business Suiteを主要なERPプラットフォームとしてリレーショナル・データベース に対して使用しています。 両社は、29年以上にわたり多くの共通の顧客サービスへの取り組みを続け、長年のリセラーおよび顧客サポート契約を更新したばかりで す。この契約は、Oracle Databaseテクノロジへのアクセス機能を拡張し、グローバル・レベルの顧客サービスを提供します。オラクルの製品戦 略は、ITインフラストラクチャ全体に柔軟性と選択肢を提供します。中規模から大規模のSAPシステムを運用する、あらゆる業種のSAPの企業 顧客の大多数が、自社のアプリケーションをOracle Databaseに委ねています。 私たちのたゆまぬ技術革新に対する取り組みは、Oracle Databaseとデータベース・オプションを選択するSAP顧客にとって計り知れないメ リットです。そこには、なぜOracle DatabaseがSAPアプリケーションの実行で最も採用されるか説明できる差別化要因のうち、明確な8つの要 因を見つけることができます。最高のパフォーマンスとスケーラビリティ、配置柔軟性、可用性、信頼性、障害時リカバリ、セキュリティ、管理性、 自己管理機能。この8つの要因が、大規模データベースのサポート、データベース統合のサポート、ハードウェアとソフトウェアの統合を実現し ています。これによりSAP顧客のすべてが、Oracle Databaseの特性および機能の利点を活用し、SAPの導入を最適化できるようになりました。 Oracle Database 12cおよび次のオプションはSAPより認定およびサポートされます。
- Oracle Database In-Memory
- Information Lifecycle Management（ILM: 情報ライフサイクル管理）/Automatic Data Optimization （ADO: 自動データ最適化） - Hybrid Columnar Compression （HCC） for Oracle Exadata、およびOracle SuperClusterとILMの併用
- Oracle Multitenantのオプション
Oracle Exadata Database Machineは、すべてのSAPデータベースおよびSAP以外のデータベースをプライベート・データベース・クラウ ド環境に統合し、SAP ECC 6.0でのオンライン・トランザクション処理やSAP BW 7.0以降のデータ・ウェアハウスなどのあらゆるデータベース・ ワークロードのために、プライベート環境のOracle Database Cloudを実行できる最高のパフォーマンスと高可用性のプラットフォームを提供 します。Exadata Database Machineは、最大規模の最重要データベース・ワークロードに即座に対応し、通常の運用ではアプリケーションを 10倍以上の速度で実行します。そのため、多くのSAP顧客がこのマシンを配置しています。
Oracle SuperClusterは、新しいSPARCプロセッサの演算能力、Oracle Solaris 11のパフォーマンスとスケーラビリティ、Oracle Exadataス トレージの最適化されたデータベース・パフォーマンス、さらに6.40以降のSAPカーネルの最適化された実行時間で統合する最初の汎用エ ンジニアド・システムです。 Oracle MiniClusterは、エンタープライズ・データベースおよびアプリケーションの実行を目的とした、極めて簡素で効率の良いエンジニア ド・システムです。しかもセキュリティに妥協をしません。 オラクルは、SPARC M7/M8およびS7サーバーのポートフォリオの完全リフレッシュと拡張により、エンタープライズ・コンピューティングの経 済性を再定義し、最高の価格/パフォーマンスで業界最大の価値を提供します。最近更新されたSPARCとSolarisのロードマップは、2021年以 降も継続します。 *https://www.dsag.de/news/dsag-investitionsumfrage-2017-relevanz-der-business-suite-ungebrochen
Oracle Exalogic Elastic Cloudは、Oracle Exadata Databaseマシンと組み合せることで、実質的に無制限のスケーラビリティ、卓越したパ フォーマンス、今まで想像もできなかった管理の簡素化をSAPアプリケーションおよびSAP以外のアプリケーションに提供します。
Oracle Private Cloud Appliance（OPCA）は、データベースおよびアプリケーションの仮想プラットフォームとして使用する一体化されたイ ンフラのイントール、デプロイ、管理方法を画期的に簡素化するエンジニアド・システムです。
Oracle Database Applianceは、世界で最も利用されているOracle Databaseを単一システムで活用する新しい方法です。配置も管理も非 常に簡単です。これはソフトウェア、サーバー、ストレージ、高可用性、ネットワークの完全なパッケージで、簡素化を目的に設計されています。 つまり、配置、メンテナンス、およびデータベース・ワークロードのサポートを簡素化することにより、時間と費用を節約します。
Oracle Linux 7は、SAPインフラ・コンピューティング・ニーズに応えるOracleの最新のLinuxバージョンです。高速で信頼性が高い上、SAP 環境のOracle Databaseのために最適化されています。SAPに対する最高のパフォーマンスの実現、顧客への最新の技術の提供、データ整合 性、より強固なセキュリティ、アプリケーション稼働時間を改善します。
Oracle VM Server for x86は、無償のサーバー仮想化ソリューションで、SAPおよび他のエンタープライズを容易に配置、管理、サポートし ます。
Oracle IaaS （Infrastructure as a Service） Cloud（SAP認定を取得）は、価格面でも、セキュリティとパフォーマンスの面でも魅力のある Enterprise Cloudプラットフォームです。SAP顧客は、オンプレミス、クラウド、またはプライベート/パブリック/混合クラウドでのSAPインフラス トラクチャの実行を選択できます。
ドイツ、ワルドルフのSAP SEのOracle開発チームは、継続してSAP開発者と連携し、SAP顧客が常に最新の最適化されたOracleテクノロジ、 確実なパフォーマンス、信頼性および技術革新にアクセスできるようにしています。
Oracle for SAP Service & Supportチームが提供するAdvanced Customer Services（ACS）には、Assisted Services Engagements（ITイ ンフラの分析/拡張およびSAP Readiness Service）を含め、ヘルス・チェック、ワークショップ、データベース移行、パフォーマンス、チューニング およびACS Oracle Solaris Services for SAP Environmentsなどがあります。
詳細、この冊子およびバックナンバーについては、次のサイトを参照してください。www.oracle.co.jp/sap ご意見、ご質問は、次のアドレス宛にお寄せください。saponoracle_jp@oracle.com Sincerely, ゲルハルト・カップラー SAPアプライアンス担当副社長 Oracle Corporation ORACLE CORPORATIONの2016年度のGAAPに従った収益は370億米ドルに達し、顧客数は420,000社になります。製品別顧客数 は、Oracle Databaseが310,000社、Oracle Fusion Middlewareが110,000社、Oracleアプリケーションが8,000社、エンジニアド・シ ステムが6,000社になります。またパートナー企業は全世界で25,000社を超えます。開発者とエンジニア40,000名、サポート担当者 16,000名、コンサルティング専門担当18,000名を含む、総数135,000名以上の従業員がともに働き、毎年、110か国から310万人以 上の学生をインターンとして雇用しています。
4
C O N T E N T
2-3 5 18 37 40 44 46 48 49 55 58 60 62 64 68 70 73 75 77 80 83 85 89 93 ご挨拶 SAP顧客の皆様へOracle Database 12c for SAP: アプリケーションを最適化する最新のデータベース・テクノロジとサポート SAP顧客向けのOracle Databaseのオプションとパック製品
Oracle Database In-Memory at KIVBF - Huge SAP BW performance increase Oracle Database In-Memory and Flat-Cubes at Villeroy & Boch
Oracle Database In-Memory at Bosch GmbH SAP BI with Oracle Database In-Memory at DB Austria Oracle Database In-Memory Toolkit for SAP BW Why Oracle Database and Engineered Systems for SAP? Oracle Exadata Database Machine at Swiss Post Oracle Exadata Database Machine at Granarolo Oracle Exadata Database Machine at Wumart
Oracle Exadata Database Machine helps AmerisourceBergen run its business at peak levels with SAP Oracle Exadata Database Machine at Nagase
Oracle Database 12c and Database In-Memory at LION Indonesian energy group opts for Oracle SuperCluster Oracle Private Cloud Appliance at Secure-24
Oracle Exadata Database Machine at Utkonos online hypermarket Mission Critical Support Services for SAP Customers
Oracle SuperCluster M7 for SAP Customers High Availability for SAP Resources by SAPCTL
Engineered for innovation, efficiency and simplicity: Oracle Engineered Systems for SAP Oracle Bare Metal Cloud
5
ORACLE DATABASE 12c for SAP:
アプリケーションを最適化する最新のデータベース・テクノロジとサポート
根拠が弱すぎたからです。そこでSAPは、SAPアプリケーションで HANAの優れた機能を使用できるように、アプリケーションの最 適化プロジェクトに着手しました。 ただし、「HANAの優れた機能」は、「HANAだけの機能」ではあり ません。HANAにできることは、Oracle Databaseにとって当たり 前の機能です。最近、こうした経緯から、SAPアプリケーションの 機能とOracle Databaseとの統合の必要性が一層明白となりま した。 現在、Oracle Databaseで稼働するSAP戦略を支える2本の柱は 明らかに重要です。オラクルが主要な新しいデータベース機能 をリリースするたびに、SAPが提供するインストール、管理およ び監視ツールに加えて、新しい機能をSAPのアーキテクチャに組 み入れる開発努力が必要になります。SAPが新しいアプリケー ションの最適化をリリースするたびに、Oracle Databaseテクノロ ジと統合する同様の開発努力が必要になります。 オラクルは、Oracle DatabaseとSAPアプリケーションとの間の緊 密な統合の価値を認識しています。データベース機能の総合的 なセットの提供、Core Data ServicesやOracle Optimized Flat Cubesなど、現在サポートされている特殊なHANAの最適化が、 2本の柱に継続的して取り組もうとしているオラクルの姿勢を明 白に示しています。戦略とロードマップ 統合戦略
当初から、Oracle Databaseで稼働するSAP - Oracle Database for SAP - の戦略は2つの柱を基本としていました。最初の柱は、 Oracle Databsaseの機能とSAP環境の統合、2番目の柱は、SAP アプリケーションの機能とOracleデータベースの統合です。 Oracle Databaseの機能とSAP環境の統合の必要性は、これまで にも何度も問題にされてきました。特にオラクルが、SAPアーキテ クチャに対応しない新しいデータベースの機能をリリースする たびに、その必要性は明白になりました。多くの顧客が決して忘 れないのが、Real Application Clusters（RAC）をSAPアーキテ クチャに統合するプロジェクトです。SAP Appliation Serverイン スタンスは複数あるとが誰もが思いこんでいましたが、実際には Database Serverインスタンスは1つでした。 これは、過去のことではありません。SAPの顧客にOracle Mul-titenantを提供する現在の計画は、RAC同様の論理構造の大改 革です。RAC認定のときと同じようにかなりの忍耐が必要になる でしょう。 一方で、SAPアプリケーションの機能をOracle Databaseと統合 する必要性は、ほとんど認識されていませんでした。R/3やBWな どの標準的なSAPアプリケーションは、Oracle Database上で開 発されてきましたが、IBM DB2およびMicrosoft SQL Serverの サポートを開始したときに、SAPはサポートするすべてのデータ ベースで使用できる機能に限定する最小公倍数的な戦略に転 換したのです。そのために、Oracle Databaseへの対応も同じで、 特殊な機能はほとんど認められませんでした。 SAPの独自のデータベースHANAが戦略を転換するきっかけで したが、すぐにSAPはこの戦略を中断し、アプリケーションを変 更する必要があることに気が付きました。SAPアプリケーション が、HANAも他のすべてのデータベースと何ら変わらないとして 処理する限り、HANAの実装が顧客の利点になるという説得の
認定およびサポートのロードマップ Oracle Database 11g Oracle Database 11g（11.2.0.4）の標準的なメンテナンスは 2015年1月31日に終了し、延長サポート・フェーズは、3年間限 定で2015年2月現在、開始されています。オラクルは、Oracle Databaseバージョン11.2.0.4について、2018年12月31日まで、 追加費用なしで延長サポートを提供します。（詳細は、SAP Note 2098258を参照してください。） Oracle Database 12c（12.1） オラクルとSAPは、共通の顧客が不利益を被らないよう、認定プ ロセスを複数のフェーズに分割することにしました。公開を複数 の段階に分けることにより、Oracle Database12cをできる限り早 く消費者に提供し、Oracle Database 11gとの十分な重複を保 証することが可能になります。 • フェーズ1は、ベーシック認定と呼ばれ、2015年3月に終了して います。以前、Oracle Database 11gで使用可能だったすべて の機能とオプションに加えて、完全に透過的、または最小限の 統合作業のみで完了する複数のOracle Database 12cの機能 が含まれています。 • 2015年の6月に完了したフェーズ2では、主要なOracle Data-base 12cの新しいオプションのOracle DataData-base In-Memory が初めて紹介されました。
• 2015年12月に完了したフェーズ3では、Oracle Database 12c Advanced Compressionに含まれる新しい情報ライフ サイクル管理機能（ILM）とOracle ExadataおよびOracle Su-perCluster上でのロー（行）レベルのロック機能を持つHybrid Columnar Compression（HCC）が追加されました。 • 2017年2月に完了したフェーズ4では、SAP顧客にOracle Multitenantを提供しました。このオプションでは、複数のデー タベースを1つのコンテナ・データベースに統合できます。この データベース・アーキテクチャはこれまでにない発想で、相当 数のOracle/SAP統合作業の要求が発生すると思われます。 Oracle Database 12c（12.2） Oracle Database 12.2には、独自のマルチテナント・アーキテク チャおよびインメモリー・データベース・テクノロジーの強化機能 が含まれ、SAP顧客に優れた統合、パフォーマンス、信頼性、およ びすべてのSAPワークロードに対するセキュリティを提供します。 2017年末までには、Oracle Database 12.2がSAPアプリケー ションで使用可能になる予定です。 アプリケーションの最適化 理論的には、SAPアプリケーションの最適化に対するオラクルの サポートの実績は、Oracle Database 12cの認定プロセスとは まったく別のプロジェクトとして進行していますが、一部のケー スでは、Oracle Database 12cの特定の機能が必要になる場合 もあります。
• SAP NetWeaver 7.40（SP 05）とともにリリースされたSAP Core Data Servicesは、Oracle Database 11gおよびOracle Database 12cでサポートされています。特別な機能もオプションも必要あ りません（SAP Note 1951491を参照してください）。 • データ・モデルの最適化では、一般的に大きなディスク領域が 必要になります。そのため、表圧縮は必須ではありませんが推 奨されています。データベースでは、255以上の列を含む表は 珍しくありません。Oracle Database 12cは、これらの表をすべ て圧縮できる唯一のバージョンです。
• Flat Cubes for SAP BWは、Oracle Database 12cとOracle Database In-Memoryでのみ使用できます。
SAPアプリケーション最適化のサポート
Oracle Database 12cの主要な新機能、Active Data Guard Far Syncにより、顧客は大規模な遠距離WAN全体で高パフォーマ ンス（非同期データ・シッピングの特徴）とデータ消失ゼロ（同期 データ・シッピングの特徴）を組み合わせることができます。詳細 は、26ページの「Oracle Databaseオプションとパック製品による SAP向けデータ管理インフラストラクチャの実装」のData Guard とActive Data Guardのセクションを参照してください。 Oracle Recovery Manager（RMAN）は、Oracle Databaseの効 率的なバックアップとリカバリのために包括的な基礎を提供しま す。バックアップおよびリカバリの実行中に、サーバーと密接に連 動し、ブロック・レベルで破損を検出します。RMANは、バックアッ プ中にファイル多重化とバックアップ・セット圧縮を使用して、パ フォーマンスおよび領域の使用量を最適化します。またRMANは、 サード・パーティ製のメディア管理製品のみでなく、Oracle Secure Backupとも一体化してテープ・バックアップを管理します。 Cross Platform Backup and Restoreにより、全体バックアップ・ セットおよび増分バックアップ・セットを使用して、プラットフォー ム間でデータを転送できます。バックアップ・セットを使用してク ロス・プラットフォーム・バックアップを実行する場合、移動先デー タベースは、Oracle 12cまたはそれ以降であることが必要です。 新たに追加された機能は、プラットフォーム移行を簡素化し、ソー ス・データーベースの読取り専用停止時間を最小限にします。 RMANは現在、Oracle Databaseのバックアップを実行する最も 一般的なツールですが、他の一般的なバックアップとして、デー タベース内の全ファイルのストレージ・スナップショットを作成す る方法があります。スナップショットを別のサーバー（本番データ べースを実行するサーバー以外）にマウントし、データをテープ などの3番目のストレージにコピーし、この方法で、バックアップ 処理を本番サーバーからオフロードします。
Storage Snapshot Optimizationを使用すると、データベース のストレージ・スナップショットの取得にサード・パーティのテク ノロジが使用できます。この場合、データベースをBACKUPモー ドにする必要はありません。
基礎認定の機能
Oracle Database 11gでSAPアプリケーションを実行する顧客 は、圧縮機能を複数の中から選択することができます。索引キー の圧縮および圧縮型索引の構成表（IOTs）は標準的なデータ ベース機能です。
構造化データのOLTP圧縮、および非構造化データのSecure-File圧縮は、Oracle Database 11g Advanced Compressionに より提供されます。
Oracle Database 12c Advanced Compressionには、多数の新 機能が搭載されています。最も重要なのは、情報ライフサイクル 管理（認定フェーズ2）に関連する機能ですが、Advanced Com-pression機能の一部は、ベーシック認定の一部として使用され ています（フェーズ1）。
Advanced Index Compressionは、新しい形の索引圧縮です。 Advanced Index Compressionを使用して索引を作成または再 構築すると、これまでと同様に索引への効率的なアクセスが提供 される一方で、一意の索引および一意でない索引のサイズが縮 小します。Advanced Index Compressionは、既存のIndex Key Compressionに適さない索引も含め、サポートされるすべての 索引で効果的に機能します。
Advanced Network Compressionは、送信元で圧縮したデータ を受信側で解凍し、ネットワーク・トラフィックの削減に使用する ことができます。Advanced Network Compressionにより、大規 模データを送信する時間を短縮し、SQL問合せの応答をより高 速にし、帯域幅を節約します（SAP Note 2138262を参照してく ださい）。
スタンバイ・データベースの設定に必要な機能であるData Guardは、Oracle Database Enterprise Editionに含まれていま す。Active Data Guardは、追加のオプションです。このオプショ ンはOracle Database 11gで、自動ブロック修復、高速増分バッ クアップなどの追加機能を提供しています。
Oracle Database 12cを使用すると、データベースをバックアッ プ・モードに設定せずに取得したストレージ・スナップショットを 1つの手順でリカバリできます。スナップショットをいつ取得した かにかかわらず追加の手順はありません。 これまでExadataでは、ACFSがサポートされていませんでした。 ACFSは、グリッド・インフラストラクチャ・バージョン12.1.0.2以 降、Exadataでもサポートされるようになりました。SAP環境では、 これをSAP共有ファイル・システム（/sapmntなど）に使用できま す。ただし、これは、ASMでデータベースを実行する代替手段で はありません。Oracle Databaseは、Exadata Storageノードを使 用するASM上に構成されている必要があり、この構成でのみサ ポートされます。
Oracle Grid Infrastructureの高可用性ネットワーク・ファイル・ス トレージ（HANFS）は、NFS V2/V3の共有パスの中断しないサー ビスを提供します。これは、高可用性仮想IP（HAVIP）上に共有す るNFSを公開し、Oracle ClusterwareエージェントによりHAVIP とNFSエクスポートを常時オンラインにすることで実現します。 クラスタ・ノードに障害が発生すると、HAVIPおよびNFSエクス ポートが、存続しているノードに自動的に移行されます。 SQL文のUNIONおよびUNION ALL演算子は、2つ以上の分岐 （たとえば、サブクエリー）を接続します: <branch1> UNION <branch2>。従来、このタイプのクエリーでは、分岐は順番に実 行されます。つまり、一定の時点で1つの分岐のみが実行され、 その後に次の分岐が継続します。Oracle Database 12cには、 UnionおよびUnion All分岐の同時実行が導入され、1組のパラ レル・サーバーで1つの分岐を実行し、他のパラレル・サーバー のセットで別の分岐を同時に実行することができます。分岐を並 列化する機能は、文の実行を高速にし、SAP BWのパフォーマン スが向上します。
Online Move Partition: Oracle Database 12c以降、ALTER TABLE … MOVE PARTITION操作は、非ブロック化オンライ ンDDLコマンドとして機能し、DML操作は、移動されたパーティ ションで引き続き操作が続行されます。また、パーティションの移 動と同時にグローバル検索も保持されるため、手動で索引を再 構築する必要がなくなりました。
Move Datafile Online: Oracle Database 12c以前のデータファ イルの移動は、常にオフラインで実行する必要があり、停止時間 を最小限にするテクニックはあったものの、停止時間を完全にな くすことはできませんでした。Oracle Database 12cでは、機能強 化されたALTER DATABASEコマンドにより、データファイルの移 動をオンラインで実行することができます。 索引構成表の再構築: 索引構成表は、Bツリー索引として保存 されるため、挿入、更新、削除の結果、断片化する場合がありま す。ただし、ALTER TABLE … MOVE ONLINE文を使用して索 引構成表を再構築すると、断片化を最小限に抑えることができ ます。詳細は、SAP Note1856270および2087004を参照して ください。
Microsoft Windowsに実装されたOracle Database 12cでは、 Oracleホーム・ユーザーの使用がサポートされ、インストール時 に指定できます。Oracleホーム・ユーザーは、管理者以外の権限 の低いアカウントを使用したOracle Serviceのホストでのセキュ リティ強化を目的に導入されています。Oracleホーム・ユーザー には、Windows組込みアカウントまたは標準のWindowsユー ザー・アカウント（管理者アカウント以外）を指定できます。このア カウントは、OracleホームのWindowsサービスの実行に使用さ れます。詳細は、SAP Note 1915302を参照してください。
ベーシック認定とアプリケーションの最適化
Oracle Database 11gでは、列数が255以上の表の場合、構造 化表データの圧縮（OLTP圧縮）はサポートされません。Oracle Database 12c Advanced Compressionでは、255列の制限がな くなり、ベーシック認定後、顧客は制限のない表圧縮を利用でき ます。 これは微々たる改善に過ぎないように見えますが、ほとんどの SAPシステムでは、255列以上の表はごく一般的です。 特に興味深い例が、SAP Note 1835008および1892354で取 り上げられています。SAPにより実装した複数のアプリケーショ ンの最適化は、クラスタ表として従来通りに実装されている表 が非クラスタ化された場合以外に実行できません。これらのク ラスタ表のデータは、通常SAPの圧縮方式で保存されますが、 この表を透過的な表に変換すると、かなり大きなサイズになり ます。さらに、非クラスタ化された表の中には、列数が255を超 えるものがあります。Oracle Database 11g Advanced Com-pressionでは、それらの表のサイズを削減することができま せんでした。Oracle Database 12c Advanced Compression Optionを使用すると、大きな表のデータを圧縮し管理すること ができます。
Core Data Services
最小公倍数的な戦略を断念し、HANAを念頭に置いてアプリ ケーションを最適化するというSAPの決定に、多くの人はオラク ルにとっての脅威だと感じたかもしれません。確かにSAPの世 界では、HANAはOracle Databaseのライバルです。しかし、SAP の新しいアプリケーションの最適化は、オラクルの顧客だけでな く、オラクルの従業員からも好意的に受け止められています。そ の理由をSAP Core Data Services（CDS）を例に説明しましょう。 Core Data Services導入の背景には、次のような疑問が渦巻い ています。データベースとは何か。データベースに何ができるの か。データベースでは何ができないのか。 この質問に対し、昔から次のように言われてきました。「データ ベースは単なるデータの入れ物だ。」「恒久的にデータを保存 するだけのコンテナにすぎない。」データを使用する場合は、 データをアプリケーション・サーバーに転送しなければなりま せん。なぜならば、「頭脳」はアプリケーション・サーバーにある からです。 従来からこの概念に基づく、SAPアプリケーションの短所は明 白です。それぞれ異なった通貨で表示された100万の値を合計 する場合、100万個の値は、データベース・サーバーからアプリ ケーション・サーバーに転送されますが、計算が終わると破棄さ れます。この方法によって発生するネットワーク・トラフィックは、 パフォーマンス低下の原因になります。 25年以上前に、Oracle Databaseの開発者はふと次のようなこ とを考えました。合計をデータベース・サーバーで計算できない だろうか、そうなればこの上なく便利な上、パフォーマンスが大 幅に改善されるのではないか。そして、彼らは、「データベースと は何ぞや」という質問にまったく違う答えを出しました。「データ ベースは単なるデータ保管箱ではない。」データベースは、デー タを保存できるだけではなく、プロシージャを保存して、データ を使用したプロシージャも実行できるはずです。元はと言えば、 プロシージャはアプリケーション・サーバーで実行されるアプリ ケーションの一部のコードの断片に過ぎませんでしたが、今で はデータベース・サーバーに移動されています。アプリケーショ ンは、アプリケーション・サーバーで稼働する層とデータベース・ サーバーで稼働する層に分割されています。つまり、データベー ス・サーバーもアプリケーション層であるのです。 ここで、オラクルの開発者はそう考えただけでなく、実際にデータ ベース・プロシージャの保存と実行ができる新しいデータベース を構築しました。それが、1992年にリリースされたOracle 7です。
その当時、Oracle Databaseは、アプリケーション層として使用 できる唯一のデータベースで、ストアド・プロシージャは、最小公 倍数的な機能のサブセットの一部ではありませんでした。そのた め、SAPはその使用を認めませんでした。 しかし、SAPは20年後にHANAのプロモーションを開始したとき に、自分達のアプリケーションが、新しいHANAのインメモリー・ データベース・アーキテクチャの最大の敵であることに気が付き ました。データベースが単なるデータ・ストアであり、アプリケー ションのみができる効率的な計算結果をネットワーク経由で転 送する必要があると考える限り、インメモリー・データベースのす べての潜在的な利点を積極的に破壊します。この時点で、SAPは 最小公倍数的な戦略とこれに対応する「データ・ストアには処理 能力がない」という従来の概念を捨てなければならないことを 悟りました。 このインサイトの結果として、SAPは、「プッシュダウン」戦略を導 入します。この戦略では、データ処理集中型算出を必要とする コードをアプリケーション層からデータベース層にプッシュダウ ンします。これを実現するために、データベースに保存されたプ ロシージャをABAPコードで（暗黙的または明示的に）呼び出す ことができる、まったく新しいプログラミング・モデルが開発され ました。さらにSAPは、Core Data Services（CDS）と呼ばれる標 準的なプロシージャのライブラリも定義し、新しい戦略による混 乱にも対処しています。SAPは、このライブラリをHANA以外のス トアド・プロシージャをサポートできるデータベースで使用する ことにも同意しました。
Oracle 7のリリースからSAP Core Data Servicesのリリースまでの 20年間は、オラクルの顧客と従業員のため息の歴史そのもので す。SAPのプッシュダウン戦略によって得られるパフォーマンス向 上は、SAPのかたくなな戦略がなければ20年前にも実現可能でし たが、20年経ってしまったとは言え、機を逸してはいません。
Oracle Database In-Memory
Oracle Database 12cにはDatabase In-Memoryオプションが含 まれていますが、これは、インメモリー・データベースではありま せん。インメモリー・データベースのサポーターは、データベース はディスクではなく、完全にメモリーに保存する必要があり、すべ てのデータはカラム（列型）フォーマットで保存する必要があると 思い込んでいますが、データの永続化やOLTPアプリケーション によるデータ操作など様々な理由で、サポーターが考える純粋な インメモリー・データベースは不可能です。そのため、当初の概 念に対応しないコンポーネントと機能が、HANAのようなインメ モリー・データベースに黙々と追加されていきました。オラクルの 戦略は、これとは対照的です。整合性がある場合、データはイン メモリー・カラム・ストアに入力できます。それ以外の場合、デー タは以前と同じ方法で保存され処理されます。Oracle Database In-Memoryの概念に関する詳細は、記事「Oracle Databaseオプ ションとパック製品によるSAP向けデータ管理インフラストラク チャの実装」、特に35ページの「Oracle Database In-Memory」 および23ページの「まとめ」の各項を参照してください。
2015年6月にOracle Database In-Memoryは、SAPに認定 されています。競合他社が提供する類似のオプションとは異 なり、Oracle Database In-Memoryの使用は、SAP Business Warehouse（SAP BW）に制限されません。代表的なOLTPアプ リケーションなど、SAP NetWeaverをベースとするすべてのSAP アプリケーションでサポートされます。ただし、Oracle Database In-Memoryを使用することは、常に最善ではありません。このオ プションは、特定の問題または一定の問題のセットに対するソ リューションで、すべての問題に対して万能であるわけではあり ません。パフォーマンスの改善が期待できない場合もあります。 そればかりか使用方法を間違うと、純粋なインメモリー・データ ベースでさえも、システム・パフォーマンスを低下させる可能性 があります。したがって、カラム（列型）ストアにロードされている データからメリットを得ることができるSAPアプリケーションは、 慎重に選択する必要があります。
アプリケーションの慎重な選別や表への配慮を考えると、SAP環 境でのOracle Database In-Memoryの実装は難しいと思われる かもしれませんが、早期に導入した顧客からは一貫して、Oracle Database In-Memory for SAPはすばやく簡単に実装できると いう意見が聞かれます。これは、直感に反しているようですが、簡 単に説明できます。 第1に、顧客の多くは、完了に時間を必要とする問合せやジョブ をすでに認識し、関連する表がどれであるかを知っています。こ のようなケースでは、適切なSAPアプリケーションおよび表の選 択は、特別難しくありません。
第2に、Oracle Database In-Memoryの実装を特定の問題に対 するソリューションとしてではなく、全体的なアプローチとして 選ぶ顧客に対して、オラクルは、In-Memory Advisorを提供して います。これは、特定のシステムのワークロードを分析し、使用 可能なメモリー量に応じて、表をカラム・ストアに入力すること を推奨するウィザードです。（この方法では、「Oracle Database In-Memoryを使用するには、どれぐらいのメモリーが必要です か」という質問をする必要はありません。逆に、メモリー量をOra-cleに示すと、Advisorが最も効率的な方法で使用できるメモリー 量をアドバイスします。） 第3に、いったん関連する表を確定すると、すべてが簡単にすば やく処理されます。ALTER TABLE XXX INMEMORY文は、カラ ム・ストアで使用する必要がある表データを宣言します。この文 を発行すると、それ以外の処理はすべてバックグラウンドで自動 的に行われます。
最後に、HANAなどのインメモリー・データベースへの移行と異 なり、Oracle Database In-Memoryの実装に大改革は必要あり ません。ハードウェア、オペレーティング・システム、データベース の何もかもが新しくなくてはいけないということはありません。 顧客は引き続き、既存のインフラストラクチャを使用できます。 Oracle Database In-Memoryについて管理者が知る必要のあ ることは、数時間で学ぶことができます。
Flat Cubes
2015年6月にOracle Database In-Memory for SAPの認定が 発表されたとき、発表文には、2、3の制限事項が含まれていまし た。特に、標準の索引または集約を削除しないことが強く推奨さ れていたのです。これにはかなりの落胆の声があがりました。オ ラクルの基本方針では、ベース・テーブルがカラム・ストアに入力 される場合、索引は不要であり、削除できるからです。 この記事で説明する他のすべてのケースと同様に、このケース でもSAPおよびオラクルのテクノロジの統合を担当するOracle/ SAP開発チームは、SAPの学習曲線に従うことが必要であるとし ました。Oracle Database In-Memory for SAP（このケースでは SAP BW）が認定された直後の状況は、SAP BWのHANAへの導 入プロジェクトの初期段階とほとんど同じです。 制限事項に対する失望は、従来のSAP BWデータ・モデルがイ ンメモリー・データベースの新しい概念に対応しないというSAP の経験に重なります。この項で説明するFlat Cubesは、SAPが HANAのために設計した新しいデータ・モデルを反映していま す。通常、Business Warehouseにロードするデータは大きなレ コードがほとんどです。たとえば、会社名、郵便番号、市、番地は、 1つのレコードの中で、同様の輸送業者の詳細、注文番号、発注 日、送り状番号などの少なくとも数十の他のデータ項目と結合さ れます。データ・ウェアハウスが普及し始めたころは、データべ-スはディスク・ベースのみで、ディスクは高価な商品でした。その ため、特定の会社が1000の項目を送信する場合は1000回、特 定の輸送会社が100,000回出荷した場合は100,000回発生す る会社または輸送会社の詳細のような冗長なデータでディスク 領域を浪費することは、受け入れがたいことでした。そこでデー タベース設計者は、スター・スキーマという設計を提案しました。 スター・スキーマでは、同じグループに属するデータのサブセット （すべての顧客の詳細、すべての輸送業者の詳細など）を、ディ メンション表と呼ばれる独立した表に移動させます。 残りのデータ、およびディメンション表の関連するエントリをポイ ントするIDはファクト表に保存されます。
従来の「スター」（=拡張スノーフレーク）スキーマ このように分割しても、すべてのケースにとって十分な対応がで きませんでした。たとえば、郵便番号、都市名、通りの一定の組合 せは、CARRIER表だけではなく、CUSTOMERS表でも複数回発 生する可能性があります。同じ分割操作を再び適用すると、追加 的な表が作成され、ファクト表ではなくディメンション表に結合さ れます。これが、スノーフレーク・スキーマと呼ばれる、より複雑で ある反面、（ディスク領域の観点から）より効率的な設計につなが りました。SAP BWのようなハイエンド・データ・ウェアハウスは、 ディテール表にもう1つのレベルが追加されるため、拡張スノー フレーク・スキーマに依存します。 複雑なアーキテクチャは、従来のディスク・ベースのリレーショ ナル・データベースの要件を満たすために、データ・モデルを最 適化する目的で設計されました。ただし、メモリーが主役になる 新しいデ－タベースでは、要件がまったく異なります。メモリー に焦点を合せるという点では、SAP HANAとOracle Database In-Memoryの間に違いはありません。
そのため、SAPは、HANA Optimized InfoCubesと呼ばれる、 HANAで稼働するSAP BWのために新しいデータ・モデルを設計 しました。 次に示すHANA-Optimized InfoCubesの説明は、シンプルです が、いささか突飛です。ディスクが主体のデータベース用にSAP BWのデータ・モデルを最適化するプロセスが、フラットで大きい レコードから拡張スター・スキーマを導き出したとしたならば、メ モリー主体のデータベースのデータ・モデルを最適化するプロ セスは、拡張スター・スキーマからフラットで大きなレコードに戻 すことです。 ただし、完全に戻すのではありません。HAHA-Optimized Info-Cubesでは、ファクト表（実際は、EおよびFファクト表）とディメン ション表（詳細の第1レベル）が1つの表に結合されます。レベル2 および3の小さい表（特性、属性および階層）は残ります。この変更 は、パフォーマンスと管理性を大きく改善するために十分です。
新しいフラット・キューブの設計 新しいデータ・モデルでは、以前のデータ・モデルの主な短所 が取り除かれますが、長所は残ります。多数の表に分散するた めに、受信する大きなレコードを分割する必要がなくなり、デー タのロードが高速化します。従来の索引も不要になるため、ここ でもデータのロードが高速化します。表を結合する後処理もな いため、問合せの処理も高速化します。拡張スノーフレーク・ス キーマ誕生のきっかけは、フラット・データ・モデルの短所である 冗長データが占有するディスク要領とメモリー要件でしたが、メ モリー内のデータやディスクのデータに使用できる高度な圧縮 機能の提供で、今ではまったく問題ではありません。 この新しいデータ・モデルがHANA以外のデータベースで使用 できるようになると、「HANA-Optimized InfoCubes」は、適切な 名前とは言えません。「SAP BW Flat InfoCubes for Oracle」ま たは「SAP BW Flat Cubes for Oracle」は名前が異なるだけで、 まったく同じデータ・モデルです。カラム・ストア外部のフラット・ キューブは、整合性に乏しいため、Oracle Database 12cおよび Oracle Database In-Memoryが必要です。
Oracle Database向けのFlat Cubeは、2016年6月以降、広く使 用できるようになりました。詳細は、SAP Note 2335159を参照 してください。
遅延圧縮と情報ライフサイクル管理
Oracle Database 12c Advanced Compressionの新機能の一
部については、「ベーシック認定の機能」および「ベーシック認定 とアプリケーションの最適化」の項で説明しています。ただし、 ベーシック認定に含まれなかったために、次の2つの主要な新 機能が欠落しています。2015年12月には、これらの新機能も SAP環境向けに認定されました。ヒート・マップと自動データ最 適化（ADO）。この2つの機能の背景となる基本的な概念は、記事 「Oracle Databaseオプションとパック製品によるSAP向けデー タ管理インフラストラクチャの実装」で説明しています（特に、21 ページのAdvanced Compression（Oracle Database 12c）を参 照してください）。したがって、ここでは、SAP固有の実装の詳細に ついて簡単に説明します。
Oracle Database 12c Advanced Compressionにより、顧客は 現在の（ホット）データと履歴（コールド）データを区別できます。
ただし、「ホット」と「コールド」という用語の意味が明確ではあり
ません。したがって、定義する必要があります。 ALTER TABLE <table_name> ILM ADD POLICY <action>
AFTER <n> DAYS OF NO MODIFICATION;
このSQLの3行目が質問に答えます。新しいデータは「ホット」であ ると見なされています。データは、一定の期間（30、60、90日）変 更されていない場合、「コールド」と見なされ、顧客が「ウォーム」 のような中間のレベルを定義していないものと仮定されます。し かし考えてみると、これまでに回答が得られたのは、「データは、 いつコールドになりますか」の質問のみで、次のことは分かって いません。「データがクールダウンすると、どうなりますか。」一体 何が起こるのでしょうか。これは、2番目の行で定義します。
ALTER TABLE <table_name> ILM ADD POLICY ROW STORE COMPRESS ADVANCED ROW
AFTER 40 DAYS OF NO MODIFICATION;
この例では、（特にこの表では）ホット・データはまったく圧縮され
ないと仮定されています。（a）40日間変更されないデータをコー
ルドであると見なし、（b）Oracle Database 12c Advanced Com-pressionが提供する表圧縮アルゴリズムを使用して、コールド・ データを圧縮する必要があるとシステムに知らせます。 データが40日間変更されていないことを、私たち、そしてシステ ムはどうやって知るのでしょう。この情報を提供するのは、ヒー ト・マップの仕事です。ヒート・マップは、変更とクエリーのタイム スタンプを行レベルおよびセグメント・レベルで自動的に追跡 し、データのアクセス状況から詳細な見通しを提供します。自動 データ最適化（ADO）は、ヒート・マップで収集された情報に基づ いたユーザー定義のポリシー（例としてここで使用しているよう なポリシー）に従い、データを自動的に移動および圧縮します。 今までは、ILMポリシーの定義にALTER TABLE文が使用されて いました。何万もの表を処理する必要のあるSAPシステムでは、 このアプローチは不便です。そのため、BR*Tools（BRSPACE）で は、Oracle Databaseが提供する異なったオプションが使用され ます。
ALTER TABLESPACE TSX DEFAULT ILM ADD POLICY ROW STORE COMPRESS ADVANCED ROW
この例では、各表に特別なポリシーを定義しませんが、表領域レ ベルでデフォルトのポリシーを定義します。表に個別のポリシー が伴わない限り、デフォルトのポリシーは、この表領域で作成さ れるすべての表に適用されます。
ExadataやSuperClusterなど、Oracle Engineered Systemで Oracle Database 12cを実行している顧客は、アーカイブ化の 代替として、履歴データのために設計された圧縮アルゴリズムの セットであるHybrid Columnar Compressionからメリットを得る ことができます。Hybrid Columnar Compressionは、Advanced Compressionが2～3倍のデータを圧縮するのに対し、10～15 倍のデータを容易に圧縮できます。 この状況で、私たちは40日間変更されていないデータを「ウォー ム」と呼び、「コールド」という用語は、より長い期間（たとえば、6 か月または12か月）変更されていないデータの定義に使用しま す。以前のポリシーは、圧縮層1（ウォーム・データ用）のために保 持し、圧縮層2（コールド・データ用）として追加のポリシーを加え ます。
Hybrid Columnar Compressionは、各ブロックではなく、完全な パーティションを圧縮するため、パーティション化されていない 表とパーティション化されている表を別の表領域に分離します。 ALTER TABLESPACE TSY DEFAULT ILM ADD POLICY ROW STORE COMPRESS ADVANCED SEGMENT
AFTER 40 DAYS OF NO MODIFICATION;
ALTER TABLESPACE TSY DEFAULT ILM ADD POLICY COLUMN STORE COMPRESS FOR QUERY LOW ROW LEVEL LOCKING SEGMENT
AFTER 6 MONTHS OF NO MODIFICATION;
Oracle Multitenant
Oracle Database 12cの新しいオプション、Oracle Multitenant は、統合、プロビジョニング、アップグレードを簡素化し、顧客 のITコストを削減します。このオプションをサポートする新しい アーキテクチャにより、マルチテナント・コンテナ・データベース （CDB）は、多くのプラガブル・データベース（PDB）を格納でき ます（記事「Oracle Databaseオプションとパック製品によるSAP 向けデータ管理インフラストラクチャの実装」、特に27ページの 「Oracle Multitenant」の項を参照してください）。 Oracle Multitenantを使用して、複数の既存のデータベースを PDBに変換し、1つのCDBに統合することができます、PDBは自 己完結型で完全に機能するOracle Databaseです。アプリケー ションという点では何も変わっていませんが、このアーキテク チャの導入にはアプリケーションの変更が必要ありません。この 点は重要です。アプリケーションの観点から見ると、PDBはデー タべースですが、実利的な観点から見ると、CDBはデータべース です。
CDBは、単一の統合された動作環境を意味します。1組のバックグラ ウンド・プロセス、およびすべてのPDBとCDBが共有する、1つの共 有メモリー領域（SGA）があります。このアーキテクチャにより、オー バーヘッドのレプリケーションが排除されるため、使用可能なリ ソースを効率的に使用できます。これは、サーバーごとにより多くの アプリケーションを統合できるため、資産経費（CapEx）を最小限に できることを意味します（図11a-eを参照してください）。運用の点で は、すべての統合されたPDBをまとめて管理し、運用費（OpEx）を大 幅に削減することができます。これは、バックアップ、高可用性の構 成、パッチとアップグレードの適用などに当てはまります。 CapExとOpExの削減は、Oracle Multitenantがクラウド・コン ピューティングに対する期待にこたえた結果の一部です。 Oracle Multitenantは、次世代のデータベース・クラウドのアー キテクチャで、真のスケールメリットを提供します。データベー スを格納するVMの高価なモデルは、プラガブル・データベース （PDB）に置き換えられました。PDB自体のコストはごくわずか です。そのため、各SAPシステムのPDBのコストは、PDBの実作業 に還元されます。 2017年2月現在、Oracle DatabaseでSAPを稼働するすべての 顧客は、Oracle Multitenantをごく普通に利用できます。Oracle Multitenantのアーキテクチャは、SAP NetWeaverベースのす べてのアプリケーションに使用できますが、同じコンテナ・データ ベース内のSAP OLAP（BW）およびSAP OLTP（ERP、CRM、...）シ ステムの組合せはサポートされていません。 データベース管理者は、次のツール・サポートを利用できます。 • バージョン1.0 SP 19以降、SWPMはコンテナ・データベース （CDB）とプラガブル・データベース（PDB）の作成をサポー トします。SWPMは、BR*Toolsを使用して、作成されたデータ ベースの互換性（ディレクトリ・パス、ファイル名など）を保証す るために、これらのタスクに使用する必要があります。詳細は、 SAP Note 2336881を参照してください。 • 通常、顧客は新しいデータベースを作成せず、既存の単独の （CDB以外の）データベースをプラガブル・データベースに変 換します。SAP Note 2335850では、サポートされた変換の手 順を紹介しています。 • バージョン7.40、パッチ24以降、BR*ToolsはOracle Mul-titenantをサポートします。新しい構成パラメータ、コマンド、 およびコマンドのオプションを使用して、管理者は使い慣れた BRCONNECT、BRSPACE, BRBACKUP/ BRARCHIVEまたは BRRESTORE/BRRECOVERコマンドで開始される演算のター ゲット・データベースを指定できます。
DB: 概要: バージョンのサポート
1174136 Oracle: End of Support Dates
2428722 Oracle 12.1 Extended Support Free of Charge Until July 31, 2019 2098258 Oracle 11.2 Extended Support Free of Charge Until December 31, 2018
DB: 機能: 概要
105047 Oracle Database 12c Advanced Compression for SAP Systems 1914631 Oracle 12c: Conversion of Compressed Tables
2133079 Oracle 12c: Problem during SAP Upgrade with Compressed Tables 2138262 BR*Tools Support for Oracle ADO/ILM
2157904 Using Oracle Database 12c Automatic Data Optimization 2166836 Oracle 12c: Problem during SAP Upgrade with Compressed Tables 2254836 BR*Tools Support for Oracle ADO/ILM
2254866 Using Oracle Database 12c Automatic Data Optimization 2255992 R3load and R3szchk: New Oracle Feature for Database ILM Policy 2258061 Enhancements for ADO/ILM for Table Conversions or System Copy 2384534 LOB Conversion & Table Compression with BRSPACE 7.40
DB: オプション: In-Memory
2178980 Using Oracle Database In-Memory with SAP NetWeaver based Products 2137032 DBA Cockpit: Monitor for In-Memory Feature
2189163 Oracle Database In-Memory Advisor for SAP 2335159 Flat Cubes for SAP BW on Oracle DB
2351252 Oracle Database 12c In-Memory Toolkit for SAP BW
DB : オプション: Multitenant
2333995 BR*Tools Support for Oracle Multitenant Database
2335850 Transformation of Existing Standalone Database into Pluggable Database 2336881 Using Oracle Multitenant with SAP NetWeaver-based Products
DB : オプション: Database Vault
2218115 Oracle Database Vault 12c
Oracle Database 12cに関連するSAP Note
DB : インストールおよびアップグレード
1915299 Troubleshooting Software Installation for 12.1.0.2 1915301 Database Software 12.1.0.2 Installation on Unix 1915302 Database Software 12.1.0.2 Installation on Windows 1915315 Database Upgrade Scripts for 12.1.0.2
1915317 Migrating to Software Owner ‚oracle‘
1915323 OS User Concept for Oracle Database 12c Release 1 2064206 Database Upgrade to 12.1.0.2 with Grid Infrastructure
DB : パッチ
1915313 Current Patch Set for Oracle Database 12c Release 1 (12.1) 1915316 Database: Patches for 12.1.0.2
2145572 Grid Infrastructure: Patches for 12.1.0.2
DB : インスタンスの構成
1888485 Database Parameters 12.1.0.2
DB : Admin: BR*Tools
2087004 BR*Tools Support for Oracle Database 12c
エンジニアド・システム
2145628 Exadata/SuperCluster: Patches for 12.1.0.2 2145651 Oracle Database Appliance: Patches for 12.1.0.2 2290084 SAP Software and Oracle Database Appliance Version 12.1 2388511 Oracle Database Appliance (ODA) X6-2 Systems for SAP
Oracle Databaseオプションとパック製品によるSAP向けデータ管理インフラストラクチャの実装
図1: Oracle Database Enterprise Edition、Databaseオプション（認定済み、必須、または認定済み、オプション） およびEnterprise Managerパック製品（認定済み、必須、または認定済み、オプション）。 SAP環境のオプションとパック製品 ここでは、SAP顧客向けのデータベースのオプションと管理パッ ク製品を紹介します。純粋なOracle DatabaseとSAP用のOracle Databaseは、いくつかの相違点があります。 • 認定されたオプションでも、一部の機能の使用が許可されて いない場合があります。ここでは概要のみを説明しています。 詳細は、SAP Note 105047を参照してください。 • SAPのデータ・モデルまたはアプリケーションの独特な設計 により、Oracle Databaseオプションまたは管理パック製品が 必要な場合があります。たとえば、Oracle Database上のSAP Business Warehouse（BW）にはOracle Partitioningが必要 です。
• オラクルの基本方針では、オプションまたはパック製品のラ イセンスは個別に供与されていますが、SAP（ASFU）より購入 されたOracle Database Enterprise Editionライセンスの場 合、付属するオプションとパック製品（しかし、すべてがサポー トされているわけではありません）は個別ライセンスではな くEditionのライセンスに含まれています。詳細は、SAP Note 740897を参照してください。 概要 データベースのエディション Oracle Databaseには、様々な開発と配置のシナリオに適した 5つのエディションがありますが、SAP環境で認定およびサポー トされているのは、Oracle Database Enterprise Editionのみ です。SAPアプリケーションの要求は非常に厳しく、Oracle Da-tabase Enterprise Editionが提供するエンタープライズ・コン ピューティング機能なしに、アプリケーションを効果的に実行す ることはできません。 データベースのオプションと管理パック また、オラクルは複数のデータベース・オプション、管理パック 製品、特定の目的に特化したOracle Databaseの機能を拡張す る他の製品も提供します。それらは、ディスク領域の効率的な使 用、パフォーマンスとスケーラビリティ、高可用性、セキュリティと コンプライアンス、データウェアハウス、ビッグ・データ、管理性の 分野で、Oracle Database Enterprise Editionの性能を拡張し、 顧客固有またはアプリケーション固有の要件を満たしています。
前述したすべての問題の共通点は、データベース内の表はデ フォルト（および定義上）で、順序付けされていないレコードの セットであるという事実です。物理的な順序は保証されません。 これに対し、ユーザー、アプリケーション、またはDBAの観点から 見ると、このようなデータのセットには特定のサブセットを含む 可能性があり、これらのサブセットは他のサブセットから分離さ れる必要があります。Oracle Partitioningは、できる限り関連す るデータを物理的にまとめたサブセットの実装を可能にします。 構造とインフラストラクチャ 前述したように、データベース・オプションは、ディスク領域の効 率的な使用、パフォーマンスとスケーラビリティ、高可用性、セ キュリティとコンプライアンス、データウェアハウス、ビッグ・デー タ、管理性の分野で、Oracle Database Enterprise Editionの性 能を拡張しますが、ここでは、構造の実装に役立つデータベー ス・オプションという点を中心に説明します。1つの単一なデー タベースのデータ量が増大する場合、また様々なソースからの データの統合やOracle Multitenantなどによる独立した複数の データベースをデータ管理インフラストラクチャに統合する場 合などで、必ず大量の非構造化データを管理できなくなるとき が訪れます。そのために、統合の差別化が必要です。またはイン フラストラクチャに構造が必要です。 表および索引のパーティション化 課題: 現在、ディスク上のデータの量や配布が問題になる 状況が増加しています。 （a）表データの特定のサブセットにアクセスする単一問 合せや複雑なバッチ・ジョブの完了に長時間必要です。 （b）多数の索引を更新しなければならないため、データの ロード（SAP BW）が遅い、またはロード時間を短縮するた めに索引が削除され再構築されます。これにより、ユーザー の問合せの速度が遅くなります。 （c）データのアーカイブ化の結果、データベースが極度に 断片化されます。 （d）顧客は、情報ファイルサイクル管理を実装することを 望んでいます（この記事のOracle DB 12cのセクションを参 照してください）。 価値提案: Oracle Partitioningでは、表と索引をより小さ いユニット（パーティションと呼ばれる）に分割し、すべての データを適切なユニットに強制的に保存します。 パーティションは、個別に、独立してアクセスおよび管理が できます。したがって （a）問合せが、関連するすべてのデータを1つの単一パー ティションで見つけることができ、他のすべてのパーティ ションを無視（「パーティション・プルーニング」）できること が理想です。これにより、実行時間を大幅に短縮できます。 （b）パーティション表に定義されている索引もパーティショ ン化されている場合、各索引のパーティションを削除および 再構築することができても、索引以外のすべてのパーティ ションは、そのまま残ります。 （c）データのアーカイブ戦略は、パーティション構造をベー スにすることができます。これにより、ディスク領域の断片化 を回避できます。 （d）パーティション化は、情報ライフサイクル管理の基盤技 術の1つです。 認定/サポート: Oracle Partitioningは、すべてのSAP NetWeaverアプリケーションに対して認定されています。 バージョン: Oracle Database 11g、Oracle Database 12c 実装: パーティション化（レンジ・パーティション化）は、Oracle 上のSAP BWではデフォルトで構成され使用されます。SAP OLTPシステムでは、SAP Partitioning Engine（データの アーカイブ化の問題を処理）を使用して、またはSAP向け Oracle ACSにより実装できます。
取る必要があります。メモリーの観点 - すべてのユーザーが1つ の色のレコードを使用する場合も、8つのブロックすべてをデー タベース・メモリーに完全にキャッシュする必要があります。さら にパフォーマンスの観点 - 過剰なI/Oは、確実にパフォーマンス を低下させます。データベース管理の観点 - 同色のレコードのサ ブセットを個別に管理できません。ILMの観点 - ホット・データと コールド・データを分離できません。など様々な場面で問題があ ります。 対照的に右側に示す状況は最適と言えるでしょう。同じ色のすべ てのレコードが1つのデータベース・ブロックに保存されていま す。左の状況と同じようにデータベースのあらゆる観点からの評 価はどうなるでしょうか。I/Oの観点 - 1つの色のレコードすべて に対する問合せに、読み取る必要があるのは1つのブロックのみ です。メモリーの観点 - すべてのユーザーが1つの色のレコード を使用する場合も、データベース・メモリーへのキャッシュが必 要なのは1つのブロックのみです。さらにパフォーマンスの観点 - I/Oの減少は、パフォーマンスを著しく向上させます。データベー ス管理の観点 - 同色のレコードのサブセットを個別に管理でき ません。ILMの観点 - ホット・データとコールド・データを分離で きます。など良いことずくめです。 このスライドで表示したレコード数とブロック数を掛けましょう。 パーティションは、同色のレコードを含むすべてのブロックのサ ブセットです。 図2は、関連するデータをできる限り一緒にまとめて保存にする ことがなぜ良いのか、その理由をわかりやすく説明しています。 ここでは、レコードで満たされたデータベース・ブロックを示し ています。異なった色は、月や場所などの条件を表しています。 データにアクセスするアプリケーションは、同じ色のレコードす べての取得を試みようとします。 このような場合、左側に示す状況が想像できる最悪のケースで す。各データベース・ブロックに、各色のレコードが必ず1つ含ま れています。つまり、同じ色のレコードのサブセットが、すべての ブロックに分散されている状態です。これはデータベースのあら ゆる観点から最悪の状況と言えるでしょう。I/Oの観点 - 1つの色 のレコードすべてに対する問合せは、8つのブロック全部を読み 図2: 表パーティション - 関連するデータのサブセットをできる限り一緒に 物理的に保存
Advanced Compression（Oracle Database 11g）
課題: 今日、データベースのサイズと将来の肥大化が問題
になるケースが増えています。この問題には、次の側面が含 まれます。ストレージのコスト、性能保証（SLA）、合理的な 期間内のデータベースのクローニングとバックアップ。 価値提案: Oracle Advanced Compressionは、表データ の保存に異なる形式を使用し、Oracle Database Enter-prise Editionに付属する他の圧縮テクノロジ（索引キーの 圧縮）とともに、データベースのサイズを50%以上縮小しま す。Advanced Compressionは、それだけのために開発さ れました。その意味で、これがAdvanced Compressionの 利点の本質です。ソース・データベースのフットプリントが 小さい場合、バックアップやコピーなどの時間が短縮され ます。 Advanced Compressionを使用するユーザーの付加的な 利点として、パフォーマンスが向上する可能性があります。 パフォーマンスの向上がAdvanced Compressionの本質 的な目的ではないことから「付加的」としました。したがっ て現実にあり得ますが、実現の保証はされていません。 認定/サポート: Oracle Advanced Compressionは、すべ てのSAP NetWeaverアプリケーションに対して認証され、 実装はSAPによりサポートされています。 実装: SAP固有の要件を認識するツールBRSPACEがSAP により提供され、SAP環境へのAdvanced Compressionの 実装は簡単です。詳細は、SAP Note 1431296を参照して ください。
