Oracle DatabaseとSQL Server 2000の技術的比較...

Oracle DatabaseとSQL Server 2000の技術的比較: パフォーマンスの観点

オラクル・ホワイト・ペーパー 2005年 9月

Oracle Databaseと SQL Server 2000の技術的比較: パフォーマンスの観点

概要 ...................................................................................................................... 3 マルチプラットフォーム対応........................................................................... 4 同時実行性モデル .............................................................................................. 5 マルチバージョン読取り一貫性 ................................................................. 5 ロック・エスカレーションが発生しない行レベル・ロック ................. 6 アプリケーション・パッケージに対するロックの影響 ......................... 7

索引 ...................................................................................................................... 8 ビットマップ・インデックスおよびビットマップ・ジョイン・インデッ

クス................................................................................................................. 8 パーティション化 .............................................................................................. 9

Oracleのパーティション化オプション ..................................................... 9 SQL Server 2000のパーティション化オプション .................................. 10 パーティション化によるパフォーマンス上のメリット ....................... 10 グローバル索引 ..................................................................................... 10 パーティション・プルーニング ......................................................... 11 パーティション・ワイズ・ジョイン ................................................. 12

パラレル実行 .................................................................................................... 12 クラスタリング ................................................................................................ 12

Oracle Real Application Clusters .................................................................. 13 SQL Server 2000連合データベース・アーキテクチャ .......................... 13 実環境アプリケーションへの不適用性 ............................................. 15 スケーラビリティの欠如 ..................................................................... 15 1パーティション上の限定された処理能力 ...................................... 18

その他のデータ・ウェアハウス機能............................................................. 18 MERGE......................................................................................................... 18 マルチテーブル・インサート ................................................................... 19 パイプライン・テーブル・ファンクション ........................................... 19

結論 .................................................................................................................... 20


2

Oracle Corporation発行「Technical Comparison of Oracle Database vs. SQL Server 2000: Focus on Performance」の翻訳版です。

Oracle Databaseと SQL Server 2000の技術的比較: パフォーマンスを重視

概要

パフォーマンスは、全データベースの要件ですが、その要件はデータベースにア

クセスするアプリケーションの種類によって大きく異なります。

オンライン・トランザクション処理（OLTP）および eコマース・アプリケーショ

ンは、ユーザーの増加に伴って挿入または更新トランザクションが頻繁に大量

データへ同時アクセスするという特徴があります。このような環境では、高いス

ループット、各種の使用可能な索引付け戦略、および優れたデータの同時実行性

に対するサポートが必要になります。

データ・ウェアハウスは、頻繁かつ複雑なアドホック・クエリー用のデータを定

期的に大量にロードできるように設計された、非常に大きいデータベースです。

データ・ウェアハウスのデータ量、アクセス・アプリケーション数およびユーザー

数は、絶えず増大します。広範な各種のアドホック・クエリーを長期にわたり実

行できるように最適化することが必要となります。このような環境では、クエ

リー・リライト機能、効率的な索引付け機能、パーティション化戦略の幅広い選

択、およびパラレル実行に対する拡張サポートなど、適切なサポートが必要です。

Oracle Databaseは SQL Server 2000より優れたパフォーマンスを示し、各種の業界

標準および ISV固有のベンチマークで常に競合会社を凌ぐ結果をだし、データ

ベースの拡張性で業界をリードしています。

このドキュメントでは、Oracle Databaseの最新版である Oracle Database 10g Release

2と SQL Server 2000の技術的な相違点について、ベンチマークおよび実際の顧客

環境における Oracle Databaseの卓越したパフォーマンスを中心に説明します。プ

ラットフォームの可用性の違いを簡単に説明し、現代の企業クラスのリレーショ

ナル・データベース・システムで最適なパフォーマンスと拡張性（同時実行性モ

デル、索引、パーティション化、パラレル実行およびクラスタ化）の確保に使用

される一般的な方法に重点を置いて説明していきます。

そのほか、データ・ウェアハウス環境内の ETLプロセスにおけるパフォーマンス

の改善に Oracle Databaseが提供する固有な機能についてもいくつか紹介します。


3


次の表に 2つの製品の主な違いをまとめます。

機能 Oracle Database SQL Server 200011

同時実行性モデルマルチバージョン読取り一

貫性

ロック・エスカレーション

が発生しない行レベル・

ロック

共有読込みロックまたは内容

を保証しない読込み

ロック・エスカレーション

索引 Bツリー索引

索引構成表

ビットマップ索引

ビットマップ・ジョイン・

インデックス

Bツリー索引

クラスタ化索引

サポートしません


パーティション化オプ

ションレンジ、ハッシュ、リスト

およびコンボジット・パー

ティション

ローカルおよびグローバル

索引


メンバー表付きのローカル索

引のみ

パラレル実行 SELECT、INSERT、UPDATE、DELETE

SELECTのみ

クラスタ化構成 Real Application Clustersによる透過的なスケーラビリ

ティ

メンバー表および分散型パー

ティション・ビューのデー

タ・パーティショニングが必

要

追加データ・ウェアハウ

ス機能マテリアライズド・ビュー

MERGE

マルチテーブル・インサー

ト

パイプライン・テーブル・

ファンクション

索引付きビュー




表 1: 主な特徴的機能

マルチプラットフォーム対応

製品の可用性が直接パフォーマンスに結びつかない場合でも多種多様なハード

ウェアとオペレーティング・システム全体に真の移植性があれば、ユーザーはア

プリケーションの変更、再設計または再構築をせずシームレスにハードウェア・

システムをアップグレードまたは変更できます。つまり、プラットフォーム間で

の可用性により、アプリケーション・ソフトウェアへの初期投資を維持し、複数

のプラットフォームにパフォーマンスの一貫性を持たせることができます。

Oracle Databaseは、ローエンドの単一プロセッサ・サーバーから大規模対称型マ

ルチプロセッサ・マシンやマルチノード・クラスタまで、各種のハードウェアお

よびオペレーティング・システム上で使用可能です。Oracle Databaseは、Linux、 1 出典は次のSQL Server 2000ドキュメント: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/startsql/getstart_4fht.asp


4


Microsoftオペレーティング・システム、OS/390メインフレームをはじめとするそ

の他の各種システムなど、すべての主要な Unixプラットフォームをサポートして

います。Oracleを使用すれば、ユーザーはアプリケーションを変更または書き直

すことなく、ハードウェアとオペレーティング・システムのアップグレードが可

能です。

SQL Server 2000はマイクロソフトのオペレーティング・システムでのみ動作しま

す。ハードウェアのアップグレードを考えている顧客はこれらのシステムが動作

するプラットフォームに限定され、プラットフォーム容量よりも成長した場合は

システムの完全な交換にかかる費用の問題に直面します。

同時実行性モデル

マルチユーザー環境では、同時実行性制御によって１人のユーザーによるデータ

更新がその他のユーザーに影響しないよう保証されます。Oracleと SQL Server

2000は、同時実行性制御の実装の点で大きく異なります。次の表に主な違いをま

とめ、詳細は次のセクションで説明します。

Oracle Database SQL Server 2000

マルチバージョン読取り一貫性使用できません。

読込みロックはありません。内容を保証しない読込みを回避する読込

みロックが必要です。

内容を保証しない読込みはありません。読込みロックを使用しないと、内容を保

証しない読込みが行われます。

ロック・エスカレーションが発生しない行レ

ベル・ロックロック・エスカレーション

読取りは、書込みをブロックしません。読取りは書込みをブロックします。

書込みは、読取りをブロックしません。書込みは読取りをブロックします。

負荷状態で、デッドロックは発生しません。負荷状態でデッドロックが発生し、深刻

な問題となる可能性があります。

表 2: 同時実行性モデル

マルチバージョン読取り一貫性

マルチユーザー環境で発生する既知の現象を防止する能力は、データベースの実

装によって異なります。

• 内容を保証しない読込み、すなわち非コミット読込みは、コミットされ

ていないデータベースへの変更をトランザクションが読み込める場合に

発生します。

• 非リピータブル・リードは、トランザクションが以前に読み込んだデー

タを再び読み込んで、そのデータを他のコミット済トランザクションが

変更または削除した検出に発生します。

• ファントム・リードは、検索条件を満たす行セットを返す問合せをトラ

ンザクションが 2回実行し、第 1の問合せが返さなかった行を第 2の問

合せが取得できる（条件を満たす行のアプリケーションが挿入できたた


5


め）場合に発生します。

Oracleのマルチバージョン読取り一貫性の実装は、常に一貫性がある正確な結果

を提供します。トランザクションがデータを更新すると、元のデータ値がデータ

ベースの UNDOレコードに記録されます。Oracleは UNDOレコード内の現在の情

報を使用した表のデータの読取り一貫性ビューを構築し、あるバージョンの情報

（まだコミットされていないトランザクションの開始時と一貫性を持つ）を常に任

意のユーザーに返すことができます。SQL Server 2000など、その他のデータベー

スでは、読取り中は変更されないようにデータをロックするまたは変更されたが

コミットされていない情報の読取りまたは問合せの防止など、同時実行性問題を

避ける次善策を選択しなければなりません。

SQL Server 2000ではマルチバージョン読取り一貫性を提供していません。その

代わり、アプリケーションに各分離レベルの共有ロックを使用するか、内容を保

証しない読込みを受け入れるか、いずれかの選択が必要です。共有ロックは、同

時トランザクションによる読込みデータの変更を防止します。マイクロソフトの

ドキュメントに記載されているとおり、読込みと書込みが混在する環境で同時要

求を適切に処理するシステムの能力が制限されることは明らかです。「それにひ

きかえSQL Serverは、共有ロックを使用して、データ読取り側がコミット済みデー

タだけを見ることを保証します。これらの読取り側（リーダー）はデータの読取

りに、共有ロックを取得して解放します。これらの共有ロックは、その他の読取

りには影響しません。読取り側は書込み側が変更をコミットするのを待ってから、

レコードを読み込みます。共有ロックを維持している読取り側は、同じデータを

更新しようとする書込みもブロックします。」2

その結果、「SQL ServerではOracleよりも、多数のユーザーをサポートしているア

プリケーション用にロックを即座に解放することが重要です。」3

開発者が抱えるこの問題の代替案は、レポートの作成など集中的に読取る作業が

オンライン・トランザクション・アプリケーションを邪魔できないように別の作

業負荷環境を構築することだけです。使用するアプローチに関係なく、受け入れ

可能なデータの同時実行性と精度を得るには、SQL Server 2000の開発者は通常、

アプリケーション設計に妥協案が必要です。

Oracleでは、書込みと読取りが互いにブロックしあうことは決してありません。

Oracleの強力なマルチバージョン読取り一貫性によって、パフォーマンスを維持

した状態で適切な機能を発揮する複合ワークロード環境が実現します。

ロック・エスカレーションが発生しない行レベル・ロック

行レベル・ロックはもっとも小さな粒度のロック管理を提供します。従って、最

高の同時実行性を提供します。また、表内の行を更新するユーザーまたは処理が

その行のみをロックするので、その他すべての行は並行する処理で使用可能な状

態です。

Oracleでは、行レベル・ロックをデフォルトの同時実行性モデルとして使用し、

ロック情報を実際の行に格納します。このことで、Oracleはデータベース内の行

2 “Migrating Oracle Databases to SQL Server 2000”, SQL Server 2000 Resource kit, Chapter 7, Locking and Transaction Isolation を参照してください。 3 “Migrating Oracle Databases to SQL Server 2000”, SQL Server 2000 Resource kit, Chapter 7, Locking and Transaction Isolation を参照してください。


6


または索引エントリと同数の行レベル・ロックを持つことができ、データ同時実

行性は制限されません。

SQL Server 2000も、行レベル・ロックをデフォルトの同時実行性モデルとしてサ

ポートします。しかし、以前のバージョンのデータベースでは、行レベル・ロッ

クはデフォルトのロック単位として提供されなかったため、後に行レベル・ロッ

クを追加して対応していました。これにはロック構造のための別なプールの追加

が必要でした。

「実際のところ重負荷では、ロック･エス

カレーションに基づいている SQL Serverのロック・システムのパフォーマンスはよくありません。その理由は、ロッ

クの競合です。 … 数人の非定型ユーザーのみの場合は、箱

から出したままのSQL Serverの動作でも大した問題はありません。数人のユー

ザーを伴う単純なオフィス内テストまた

は配置では、これらの問題にはなかなか

直面しません。しかし数百人の同時実行

性ユーザーをデータベースに投入し、か

なりの数のDELETEと共に INSERTSとUPDATESが途切れなくちりばめられていれば、Oracleの文献を読み始め、軍資金に期待することになります。」4

ほかのメモリー構造と同様、これらのロック構造もサイズに制約があるため、デー

タベースでサポートできる最大ロック数が制限されます。ロック専用の最大メモ

リー量は、データベース用に確保されている量の 40%に限定されます。SQL Server

は各ステートメントについてロックを配置する適切なレベルを動的に決定します

が、ロックが獲得されるレベルは使用可能なメモリーには依存しません。小さい

表には表ロックが適用され、大きい表には行ロックが適用されます。ロック・エ

スカレーションにはしきい値がありますが、自動的に調整されます。SQL Server

は読込みロックに多数のロックを使用するため、しきい値に達することは珍しく

はありません。その結果、さらに多数のユーザーがアプリケーションにアクセス

するにつれてトランザクション量が増え、SQL Server 2000はメモリーの節約に行

レベル・ロックを表ロックに変更します。つまり、同時にデータにアクセスでき

るユーザー数は少なく、ユーザーには待機時間が発生することを意味します。

「さらにきめ細かなロック、たとえば行ロックは同時実行性を増しますが、多数の

行がロックされた場合に多数のロックの維持が必要なためオーバーヘッドが増え

ます。表全体のロックはその他のトランザクションによる表のどの部分へのアク

セスも制限するため、たとえば表ロックなどのきめの粗いロックは、同時実行性

の点からは費用がかかりますが、維持するロック数が少ないためオーバーヘッド

も少なくてすみます。」5

このロック・エスカレーションの結果として保持されている総ロック数は減少し

ますが、2人以上のユーザーが互いにロックされたデータを待つ可能性は大きく

増加します。こういった好ましくないデッドロックは、同時ユーザーの 1つ以上

のトランザクションを中止した結果として生じます。

Oracleでは、ロック・エスカレーションが発生しないため、Oracleユーザーはロッ

ク・エスカレーションによるデッドロックに陥ることがありません。

アプリケーション・パッケージに対するロックの影響

データベース内のロック構造は、そのデータベースを使用するすべてのアプリ

ケーションに透過的に適用されます。このようなロック構造における弱点の対処

には、前述のアプリケーション・コードの追加が必要です。

さらに重要なことは、最適ではないロック・スキームのサポートにも、簡単にア

プリケーション・パッケージの変更、またはメンテナンスができないことです。

Oracleの強力なマルチバージョン読取り一貫性モデルは、すべてのアプリケー

ションに利益をもたらすスケーラビリティを提供します。それは、SAP R/3、

PeopleSoft、Siebelおよび Oracle Applicationsをはじめとするアプリケーション・ 4 http://www.sql-server-performance.com/lock_contention_tamed_article.asp5 出典はMicrosoft SQL Serverドキュメント:Understanding Locking in SQL Server http://msdn.microsoft.com/library/default.asp?url=/library/en-us/acdata/ac_8_con_7a_7xde.asp


7


パッケージの多くが Oracle上で動作する主な理由です。

索引

索引は、データによる高速なパスの提供に作成されるデータベース構造です。索

引を使用するとディスク I/O処理が大幅に削減されるため、データ取得のパフォー

マンスが向上します。

Oracleおよび SQL Server 2000はともに、キー値の順序付けリスト（キー値が入っ

た表内の行の格納場所に対応付けられている）である従来型の Bツリー索引付け

スキームをサポートしています。

また両方とも索引構成表（マイクロソフトの用語ではクラスタ化索引）もサポー

トしています。索引構成表では、表内の行はプライマリ・キー索引のリーフ・ノー

ド内に保存されているためプライマリ・キーでの完全一致や範囲検索を含む問合

せの場合、表データに高速でアクセスできます。

さらに、Oracleはビットマップ・インデックスおよびビットマップ・ジョイン・

インデックスもサポートします。これらのインデックスは、データ・ウェアハウ

ス環境で一般的なロードおよび問合せ処理でパフォーマンスが大幅に向上します。

これらの索引については次項でさらに詳しく説明します。

ビットマップ・インデックスおよびビットマップ・ジョイン・インデッ

クス

ビットマップ・インデックスは、各キー値に対する表の行の格納場所（ROWID）

のリストではなくビットマップ（またはビット・ベクトル）を使用します。ビッ

トマップの各ビットは、表の 1つの行に対応します。表の行がキー値を含んでい

るとき、ビットがセットされます。

ビットマップ表現はROWIDのリストの場合と比べて、カーディナリティが低い

データの場合に特に多くの領域を節約できます。ビットマップ・インデックスで

は、ブール演算子を使用して異なる索引エントリのビットマップを結合します。

ビットマップ・インデックスは、WHERE句内の複数の条件に対応する索引を効率

よくマージします。すべての条件ではなく一部を満たす行には、表自体のアクセ

ス前にフィルタが適用されます。この結果、応答時間が短縮されます。検索によっ

ては大幅な応答時間の短縮が可能です6。

Oracleでは、索引構成表でのビットマップ・インデックスの作成も可能なため、

データ・ウェアハウス環境において索引構成表をファクト表として使用できます。

ビットマップ・ジョイン・インデックスは、2つ以上の表の結合に関するビット

マップ・インデックスです。ビットマップ・ジョイン・インデックスを使用する

と、表の実際の結合が回避できます。または、事前に制限することにより、結合

の必要なデータ量を大幅に削減できます。問合せにビットマップ・ジョイン・イ

ンデックスを使用すると、ビット単位処理によって時間が短縮できます。

ビットマップ・ジョイン・インデックスには複数のディメンション表が含まれて

おり、単一表にビットマップ・インデックスを使用するスター型変換で必要なビッ

6オラクル・ホワイト・ペーパー『Oracle10gの主要なデータ・ウェアハウス機能: 比較パフォーマンス分析』参照。


8


ト単位処理が必要ありません。各種のスター型問合せに対するパフォーマンス測

定では、ビットマップ・ジョイン・インデックスの使用による応答時間の大幅な

短縮が示されています。

SQL Server 2000は、ビットマップ・インデックスおよびビットマップ・ジョイン・

インデックスもサポートしていません。

パーティション化

パーティション化により大規模なデータベース構造（表や索引など）を、さらに

小さく管理の容易なパーティションに分割できます。パーティション化は主に管

理の容易さと可用性を考慮した機能ですが、パフォーマンス面のメリットも多数

あります。

Oracleのパーティション化オプション

Oracle Databaseでは、異なるアプリケーション・シナリオに対応する表パーティ

ション化の方法を複数用意しています7。

• レンジ・パーティション化は、あるレンジ（範囲）の列値で行をパーティ

ションにマッピングします。レンジ・パーティション化は、特に履歴を

格納するデータベースで適しています。また、データ・ウェアハウスの

ローリング・ウィンドウ操作にも最適なパーティション化の方法です。

• ハッシュ・パーティション化は、パーティション列にハッシュ関数を使

用してデータをパーティションにストライプ化します。これは、データ

の均等分散に有効な方法です。

• リスト・パーティション化は、行のパーティションへのマッピング方法

を明示的に制御できます。このためには、各パーティションの作成時に、

パーティション列に対する値のリストを指定します。

• さらに、Oracleではレンジ-ハッシュとレンジ-リスト・コンポジット・パー

ティション化もサポートしています。

Oracleでは、次の 3種類のパーティション索引も使用できます。

• ローカル索引は、基礎となるパーティション表と同様のパーティション

化方法でパーティション化されるパーティション表に対する索引です。

ローカル索引の各パーティションが、基礎となる表の 1つのパーティショ

ンのみと 1対 1で対応します。

• パーティション化されたグローバル索引は、表とは異なるパーティショ

ン化キーでパーティション化されるパーティション表または非パーティ

ション表に対する索引です。

• パーティション化されていないグローバル索引は、非パーティション表

に対する索引と本質的には同じです。索引構造はパーティション化され

ていません。

7 Oracleのパーティション化オプションの詳細は、オラクル・ホワイト・ペーパー『Partitioning in Oracle Database 10g』参照。http://www.oracle.com/technology/products/bi/db/10g/pdf/twp_dss_partitioning_10gr1_0205.pdf


9


Oracleでは、パーティション/非パーティション索引および表の任意な組合せがで

き、パーティション表でパーティション索引と非パーティション索引の使用や、

非パーティション表でパーティション索引と非パーティション索引の使用が可能

です。

SQL Server 2000のパーティション化オプション

SQL Server 2000は、データベース業界で一般的に定義されているパーティション

化をサポートしていません。その代わり、パーティション・ビューをサポートし

ています。

パーティション・ビューは、1台または複数台のサーバーにわたる一連のメンバー

表からパーティション化されたデータを水平方向に結合し、まるで 1つの表から

のデータのように表示します。データは、パーティション列と呼ばれる列のデー

タ値の範囲に基づいてメンバー表間でパーティション化されます。各メンバー表

に関するデータ範囲は、パーティション列に指定されている CHECK制約内に定

義されます。ビューは UNION ALLを使用して、全メンバー表の SELECTを 1つ

の結果セットに組み合わせます。

SQL Server 2000は、ローカル・パーティション・ビューと分散型パーティション・

ビューを区別します。ローカル・パーティション・ビューでは、パーティション

化された表およびビューはすべて、SQL Serverの 1つのインスタンス上に存在し

ます。分散型パーティション・ビューでは、パーティション化された表の少なく

とも 1つは別の（リモートの）サーバーに存在します。分散型パーティション・

ビューについては、このドキュメントの「クラスタリング」のセクションでさら

に詳しく説明します。

パーティション化によるパフォーマンス上のメリット

本物のパーティション化機能が欠けているため、SQL Server 2000ではパフォーマ

ンスとスケーラビリティにおいて多数の重大な欠陥に苦しんでいます。

グローバル索引

グローバル索引は一般的に OLTP環境用として使用され、任意な個々のレコード

に効率的にアクセスします。パーティション化されたグローバル索引は、パーティ

ション化の度合いおよびパーティション化キーが表のパーティション化方法に依

存しないより高い柔軟性を持ちます。ここでEmployees表はdeptnoキーでパー

ティション化され、empnoキーでグローバル索引を作成およびパーティション化

できることを次の図に示します。


10


図 1: Oracleのパーティション化されたグローバル索引

SQL Server 2000のパーティション・ビューはグローバル索引をサポートしていま

せん。「パーティション」列に検索条件を指定しない問合せは、すべての表の検

索が必要です。メンバー表が別々のノードに存在するクラスタ化環境の場合、こ

の動作はパフォーマンスをさらに低下させる可能性があります（「クラスタリン

グ」の項を参照）。このサポートの欠如は、実環境 OLTPアプリケーションで使

用される SQL Server 2000の機能を大幅に制限することになります。

パーティション・プルーニング

パーティション・プルーニングは、必要なデータを含むパーティションにのみ操

作できます。クエリー・オプティマイザは、SQL文の FROM句とWHERE句を分

析して、必要のないパーティションを排除します。つまり操作が必要なデータの

入っていないパーティションを検索対象から除外します。この方法により、ディ

スクから取得されるデータ量が大幅に削減し、処理時間が短縮されるため、問合

せのパフォーマンスとリソースの使用率が向上します。それは、データ・ウェア

ハウス環境にとっては不可欠なパフォーマンス機能です。

Oracleはパーティション・プルーニングを完全に実装し、対象にはコンポジット・

パーティション化されたオブジェクトも含みます。パーティション・プルーニン

グはさらに索引アクセス（グローバルまたはローカル）とも組み合わせて使用で

きます。索引と表が別の列に基づいてパーティション化された場合、基礎になる

表のパーティションを排除できなくても、Oracleは必要のない索引パーティショ

ンを排除します。

SQL Server 2000は、パーティション化された表およびビューがすべて SQL Server

の同じインスタンスに存在するとき、ローカル・パーティション・ビューと共に

基本的なパーティション・プルーニングを実施します。メンバー表の作成時にパー

ティション列で CHECK制約が使用された場合、クエリー・オプティマイザはそ

の行を含むメンバー表を判断し、これらの表に対する検索を制限します。ただし、


11


このテクニックをグローバル索引や複合パーティション化（サポートされていな

い）との組合せはできないため、全体的なパフォーマンスの効率が限定されます。

分散型パーティション・ビュー付きのパーティション・プルーニングは制限が非

常に厳しく、スケーラビリティの欠如に苦しんでいます。これについては、この

ドキュメントの「クラスタリング」のセクションで詳しく説明します。

パーティション・ワイズ・ジョイン

Oracleでは、パーティション化を通じて複数の表を結合するパフォーマンスも向

上します。これはパーティション・ワイズ・ジョインという方法です。パーティ

ション・ワイズ・ジョインは、2つの表が結合され、その両方が結合キーに基づ

いたパーティション化の場合に適用できます。パーティション・ワイズ・ジョイ

ンは、各パーティション間での大きな結合を小さい結合に分割するため、結合全

体の終了までの時間が短縮されます。これは、シリアル実行とパラレル実行の両

方のパフォーマンスを大幅に向上します。SQL Server 2000は、パーティション・

ワイズ・ジョインをサポートしていません。

パラレル実行

SQLのパラレル実行は、大量データを伴う操作のパフォーマンスを大幅に向上さ

せます。意志決定支援システムやデータ・ウェアハウスに代表される大規模デー

タベースに対する大量データの操作時の応答時間短縮に役立ちます。

Oracleは、パーティション化および非パーティション化データベース・オブジェク

トの両方へのアクセスに、INSERT、UPDATE、DELETEおよびMERGE8文を同時

に実行します。

SQL Server 2000では、INSERT、UPDATEおよび DELETE文はシリアル実行され

ます（MERGEはサポートされていません）。

クラスタリング

クラスタは、独立したサーバーまたはノードのグループです。プライベート・ネッ

トワーク（クラスタ・インターコネクトと呼ばれる）によって接続され、1つの

システムとして共に動作します。個々の大型サーバーの機能を超える負荷の処理

にクラスタを使用すれば、単一ノード・システムによって課せられた制限を超え

るアプリケーションを拡大できます。

需要の増加にあわせて、新しいノードを追加するだけで完全かつ透過的なスケー

ラビリティが得られる、クラスタ化構成に真のサポートを提供しているのは、

Oracleだけです。マイクロソフトのドキュメントには「SQL Server 2000はこの種

のクラスタリングをサポートしていない」9と記載されています。その代わり、ス

ケーラビリティを得るためには、ユーザーは連合データベースを使用しなければ

なりません。次項では、2つのアーキテクチャの違いとパフォーマンスおよびス

ケーラビリティへの影響についてさらに詳しく説明します。 8 MERGE文についてはこのドキュメントの「その他のデータ・ウェアハウス機能」のセクションで後述します。 9 出典: SQL Server 2000 ドキュメント、SQL Server Architecture、Federated SQL Server 2000 Servers http://msdn.microsoft.com/library/default.asp?url=/library/en-us/architec/8_ar_cs_4fw3.asp


12


Oracle Real Application Clusters

Real Application Clusters（RAC）は、ハードウェア・クラスタをサポートする Oracle

Databaseオプションです。

Oracle Real Application Clustersは共有ディスク・アプローチを使用します。共有

ディスク・データベース・アーキテクチャでは、データベース・ファイルは論理

的にすべてのデータにアクセスする各インスタンスにより疎結合されたシステム

のノード間で共有されます。

Oracle Real Application Clustersは、特許取得済の Cache Fusion™アーキテクチャを

使用します。このテクノロジは、クラスタ内でのすべてのノードが相互接続され

たキャッシュを使用することで、どのような種類のアプリケーション（OLTP、

DSS、パッケージ・アプリケーション）にもデータベース要求を満たすことがで

きます。これで、ローカル・キャッシュでも他のキャッシュでも問合せ要求を満

たすことができます。ローカル・ノードは必要なブロックを他のクラスタ・ノー

ドのデータベース・キャッシュから直接取得できるため、更新処理でのディスク

書込み処理と読込み処理の同期が必要ありません。Oracleの Cache Fusion™は、必

要なデータ・ブロックをリモート・ノード・キャッシュからローカル・キャッシュ

へ直接送る待機時間の少ないクラスタ・インターコネクト・プロトコルを展開し

ます。Cache Fusionは、ノード間同期のクリティカル・パスから低速のディスク

処理を削除します。時間のかかるディスク・アクセスは、必要なデータがどの

キャッシュにもない場合、および更新トランザクションがコミットされディスク

書き込み保証を必要とする場合にのみ行われます。この実装は、データベース・

キャッシュの作業セットを効果的に拡張しディスク I/O処理を減らすことで、デー

タベース処理をスピードアップします。

Oracle内で Cache Fusionを利用すると、パフォーマンス・コストはほとんど無し

で Oracle Real Application Clustersが提供するスケーラビリティを簡単に活用でき

ます。顧客は需要の増大に応じて、データベース層を水平方向に拡大できます。

Oracle内に Cache Fusionを完全実装すると、ディスク・ベースのキャッシュ調整

に伴う待ち時間が排除されるため、今ではクラスタを意識することなくアプリ

ケーションが効率よくスケーリングできます。

さらにクラスタ負荷分散機能により、クラスタ・ノード間で多数のユーザー接続

を自動的かつ透過的に分散させ、全体的なクラスタ処理能力を最適に使用できま

す。

SQL Server 2000連合データベース・アーキテクチャ

分散型パーティション・ビューは、連合データベース・サーバーの実装に使用で

きます10。連合は個々に管理されますが、協力してシステムの処理負荷を共有する

サーバーのグループです。

連合データベースの場合、データは異なるサーバー間に分割されます。ユーザー

が正常に連合データベースに接続すると、1台のサーバーに接続されます。別の

サーバーに存在するデータをユーザーが要求すると、ローカル・サーバーに保存

されているデータの検索よりも時間を要します。

10のオラクル・ホワイト・ペーパー『データベース・アーキテクチャ連合型対クラスタ型』参照。http://otndnld.oracle.co.jp/products/iserver/oracle9i/pdf/federatedvsclustered_j.pdf


13


マイクロソフトのドキュメントは、問合せのリモート実行の回避を推奨していま

す。

「ヒット率の非常に高いデータベースがある場合は、そのデータベースや表を分散

したくないかもしれません。

…

SQL文のほとんどを必要な大部分のデータとともにメンバー・サーバーへの直接

の転送を推奨します。その結果、分散という設計上の本質が最小限に抑えられま

す。

…

データを複数のサーバーに分散すると、リモート・サーバーに対する問合せがパ

フォーマンスへの打撃となります。特定の問合せが作用するデータについての

ベースラインを得るため、OLTP環境で実施される問合せの種類については分析が

必要です。分散問合せの実行では、ある程度のオーバーヘッドが生じますが、こ

のオーバーヘッドが表分散のメリットを上回る場合もあります。11

これは、特に独自な仕様の大規模アプリケーションの場合、不可能なタスクとな

ります。これについては SQL Server 2000についての著書の 1つで認められていま

す。

「この機能セットにより、複数のサーバーにわたって、ビューを水平方向へのパー

ティション表の区分化が可能になります。この機能により、SQL Server 2000は、

12クラスタ構成 Compaqシステムで 1分当たり 262,243トランザクション（tpmC）

という新しい Transaction Processing Performance Council（TPC）TPC-C ベンチマー

クを記録しました。

残念なことに現在の設計には重大な制約があり、簡単に実装できません。12

このため、開発者と管理者はこの発生を回避するため独自なシステムの構築が必

要となります。データベース・サーバー連合の構築に、管理者と開発者は次の作

業が必要です13。

1. SQL Server 2000のインスタンスを実行している個々のメンバー・サー

バーにデータベースを 1つずつ作成します。

2. ほとんどの関連データが 1つのメンバー・サーバーに配置されるよう、

元のデータベース内の個々の表をパーティション化します。これには、

すべてのメンバー・データベースにわたるデータを各種の表に分散する

ための以下のような異なる分散方法が必要になります。いくつかの表を

パーティション化する、各メンバー・データベース内にその他の表の完

全なコピーを作成する、および元のサーバーに手を付けていない表をい

くつか残す。

3. SQL文が必要とするデータのほとんどを保存しているメンバー・サーバー

にアプリケーションから各 SQL文を送信できる、ビジネス・サービス層

に組み込めるデータ転送規則を考えます。

この実施プロセスには明らかにアプリケーション・ロジックとデータベース・レ 11 出典: SQL Server 2000 ドキュメント、Distributed Partitioned Views Recommendations 12 p.42, Microsoft SQL Server 2000, A Guide to Enhancements and New Features, Rahul Sharma, Addison Wesley 13 出典: SQL Server 2000ドキュメント： SQL Server Architecture, Partitioning data


14


イアウトの両方に対する卓越した知識と深い理解が必要になります。既存のアプ

リケーションをスケーリング・アウトするとき、データベース管理者はパーティ

ション化に適した表および全サーバーに複製を作成する表の識別が必要です。こ

のプロセスは、パーティションに基づくパーティション・キーを正しく選択され

ていると仮定しています。次に、開発者は SQL文の処理に必要なデータの全部ま

たはほとんどを含むメンバー・サーバーに各 SQL文が確実に転送されるように、

これらのアプリケーションのビジネス・ロジックの大部分を再設計する必要があ

ります。

これらの回避方法の最終結果として、SQL Server 2000の連合データベース設計は

特定なアプリケーションに限定されています。

「分散型パーティション・ビュー」、…はデータ・ウェアハウス・アプリケーショ

ンの場合には便利ですが、現在の機能ではOLTPアプリケーション実施の成功には

多数の課題が残されています。」14

2つの製品に採用されているアーキテクチャの違いは、パフォーマンスとスケー

ラビリティに多数の影響を及ぼします。

実環境アプリケーションへの不適用性

ポピュラーな OLTPアプリケーション・スイート（Oracle eBusiness Suite、SAPま

たは PeopleSoft）は非常に多くの表を持ちます。前述のとおり、SQL Server 2000

の連合データベースでは、ある程度のスケーラビリティを得るには、すべての表

をすべてのノード上にパーティション化するまたは複製を作成する必要がありま

す。これらのアプリケーションをこのような環境に移植することは、非常に複雑

で高価なプロセスになります。

アプリケーションのスケール・アウトを考慮すると、連合データベース・アーキ

テクチャが簡単に選択できるソリューションではないことをマイクロソフトも認

めています。

「分散型パーティション・ビューの実施は、環境の全体的な管理と操作に多数の複

雑な問題をもたらす可能性があります。現在、環境の改善にこのスケーリング・

アウトの実施が必要な企業の割合は、非常にわずかです。15」

これとは対照的に、Oracle Real Application Clustersは完全なアプリケーション互換

性を提供しています。クラスタリング環境用に特別な調整を必要とせず、あらゆ

る種類のアプリケーションがスケールできます。移行は透過的です。既存のアプ

リケーションに対する特別な再設計やコード変更は必要ありません。明示的なア

プリケーション・セグメンテーションもデータ・パーティション化も同様です。

スケーラビリティの欠如

共通するデータ・ディクショナリおよびグローバル索引のサポートもなく、連合

データベース・サーバーが独立したデータベースから構成されているという事実

は、パフォーマンスとスケーラビリティにいくつかの不利な状態をもたらします。

最初に、パーティション・ビューを参照し、パーティション列に検索条件を指定

する非常に簡単で一般的な問合せを検討します。文の処理に必要なすべてのデー

14 p.232, Microsoft SQL Server 2000, A Guide to Enhancements and New Features, Rahul Sharma, Addison Wesley 15 出典: SQL Server 2000 ドキュメント、Distributed Partitioned Views Recommendations


15


タが問合せの転送先のメンバー・サーバーに含まれていない場合、問合せはその

他のメンバー・サーバーへの伝播が必要です。クエリー・プロセッサはこの伝播

を要求するデータを含むメンバー・サーバーのみに限定することで16、このプロセ

スを最適化しますが、これらのリモート・サーバーに対する問合せはパフォーマ

ンスに打撃を与えます。問合せを実行するメンバー・サーバーの数が増えると、

パフォーマンスとスケーラビリティは悪化します。マイクロソフトのドキュメン

トでは次のように述べられています。「分散問合せの実行では、ある程度のオー

バーヘッドが生じますが、このことが表分散のメリットを上回る場合もありま

す。」17

パーティション・ビューを参照する問合せがパーティション・キーを指定してい

ないとき、スケーラビリティはさらに悪化します。これはまた非常に一般的なケー

スともいえます。異なる基準で効率よくレコードを見つける機能は、OLTPデー

タベースの基本的要件の 1つです。この理由から、多くの OLTPシステムは大き

な表で多数の索引を持ちます。オラクル社が社内で使用している E-Business Suite

は、その大きな表のほとんどに 1ダース以上の索引を持ちます。

SQL Server 2000はグローバル索引（つまり複数のパーティション境界にわたる索

引）をサポートしないため、このような問合せは連合データベースを構成してい

るすべてのノードにブロードキャストをする必要があります。連合システム内の

ノード数が多ければ多いほど、パフォーマンスに悪影響を与えます。次の例では、

Customer表を 4つの異なるノードに存在する 4つのメンバー表にパーティショ

ン化（区分化）して連合データベースが構築されています。パーティション化は

Customer_IDキーに基づきます。顧客名に基づく単純な問合せでも、クラスタ

の 4つのメンバー・サーバーに伝播が必要なため、問合せの全体的パフォーマン

スに深刻な影響を及ぼします。

16 出典: SQL Server 2000 ドキュメント、Resolving Distributed Partitioned Views 17 出典: SQL Server 2000 ドキュメント、Distributed Partitioned Views Recommendations


16


図 2: SQL Server 2000連合データベースによるクエリー・ブロードキャスト

Oracleにはこのような制限はありません。

クラスタ内のすべてのノードは単一のデータベースに同等にアクセスできます。

問合せ実行中のノードは、SQL文で参照されている表への完全なアクセス権を持

ちます。問合せは、クラスタ内のその他のノードに伝播が必要ありません。これ

は前述した両方の場合に該当します。パーティション・プルーニングは、制約な

しに透過的に動作します。Customers表が Customer_IDキーに基づいてパー

ティション化され、問合せが同じキーに基づく場合、問合せを満たすデータを含

むパーティションのみがアクセスされます。

そして Oracleはグローバル索引を完全にサポートしています。Oracle Real

Application Clusters上で前述の 2つ目のケースに類似したアプリケーションを実行

すると、Customer_Nameキーに基づいて定義されているグローバル索引（パー

ティション化された、またはされていない）を活用し、パフォーマンスへの影響

なく直接正しいパーティションにアクセスします。これを次の図に示します。


17


図 3: Oracle RACによる問合せ実行

1パーティション上の限定された処理能力

SQL Serverの場合、パーティションを所有するノードのみがそのパーティション

の読込みに貢献できます。処理能力は表が属するノードの処理能力によって常に

制限されます。

Oracleにはこのような制限がありません。Oracleではすべてのノードからパラレ

ル実行などのシステムの処理能力すべてを活用でき、必要な際にひとつのパー

ティションのみを検索します。

その他のデータ・ウェアハウス機能

Oracleはデータ・ウェアハウス環境、特に抽出、変換およびロード（ETL）処理

に役立つ固有な機能をいくつか提供します。これらのフェーズでは、各種の方法

によってソース・データをアクセスし、処理およびデータ・ウェアハウスにロー

ドします。

MERGE

MERGE文は新しい SQL文で、表とビューの必要な行を更新または挿入します。

これにより、アプリケーション文の数が減少しアプリケーションの複雑性が緩和

されます。この文は、2つ以上の処理を組み合わせる便利な方法で、複数の INSERT

および UPDATE DML文を使用する必要がありません。

MERGE文は、ある表から行の選択し、別の表に更新または挿入する場合に使用

できます。こうした処理は、オンライン・システムから受信した新規データによ

る表の定期的なリフレッシュを必要とする多数のデータ・ウェアハウス・アプリ

ケーションで頻繁に使用されます。この新規データはウェアハウス表の既存の行


18


を変更する場合や新規の行を挿入する場合があります。一般にMERGE文はこれ

らの状況を解決します。

MERGEでは実行が最適化されスキャンおよび結合操作が減少するため、同じ

DML文シーケンスでの場合と比較してパフォーマンスが著しく改善します。18

SQL Server 2000はMERGE文と同等の分をサポートしません。MERGE文がない

と、これらの処理は一文の INSERT文および UPDATE文でのみ表現できません。

このアプローチはパフォーマンスおよび活用性の不足に左右されます。

マルチテーブル・インサート

マルチテーブル・インサートでは単一の SQL文を使用してデータを複数の表に挿

入できます。これは、各表に別々な複数の SQL文を使用するより効率的です。

この機能は、データが 1つ以上の業務系データ・ソースから複数のターゲット表

に送信されるデータ・ウェアハウス・システムに非常に有効です。マルチテーブ

ル・インサートは、単一DML文として、行を複数の表に挿入する INSERT...SELECT

文の有効範囲を拡大します。

この新機能によって、実行が最適化されソース・データのスキャン処理が減少す

るため、パフォーマンスが著しく改善19します。一時表での実体化は必要ありませ

ん。ソース・データは、複数文を使用する場合のように各ターゲット表に 1回ず

つスキャンするのではなく、処理全体に対して 1回スキャンされます。

マルチテーブル・インサートによって、SQLはデータ変換および条件付き処理で

さらに有益となり、多量データの高速ロードと変換を実現します。

SQL Server 2000はマルチテーブル・インサートをサポートしません。そのため、

同様の処理は複数の INSERT文としてのみの表現でき、ソース・データ上で多数

のスキャン操作が必要となります。

パイプライン・テーブル・ファンクション

テーブル・ファンクションは、PL/SQL、Javaまたは Cで作成された関数です。入

力引数としてカーソルの受付け、または一連の行の受取りおよび一連の行の出力

として生成します。

Oracleでのテーブル・ファンクションは、セット全体の構築が完了まで待ってか

ら戻す代わりに、作成と同時に以降の SQL処理用に結果の行または行サブセット

を増分して戻すことで、結果がパイプライン化できます。

Oracleはまたテーブル・ファンクションのパラレル実行もサポートしているため、

一連の入力行をパラレル関数の複数のインスタンスに分担させることができます。

テーブル・ファンクションのパイプライン化とパラレル実行は、多数のアプリケー

ションのパフォーマンスとスケーラビリティの改善に役立ちます。データ・ウェ

アハウス環境では、OLTPシステムからのデータの抽出によりデータ・ウェアハ

ウスを構築する ETL（Extraction-Transformation- Load）プロセスでテーブル・ファ

ンクションを使用できます。抽出されたデータは、一連の変換を経てデータ・ウェ

18オラクル・ホワイト・ペーパー『DSS環境におけるOracle9i のパフォーマンスと拡張性』http://otndnld.oracle.co.jp/products/iserver/oracle9i/pdf/dss_enviroment_9i.pdf19オラクル・ホワイト・ペーパー『DSS環境におけるOracle9i のパフォーマンスと拡張性』http://otndnld.oracle.co.jp/products/iserver/oracle9i/pdf/dss_enviroment_9i.pdf


19


アハウスにロードされます。Oracleではテーブル・ファンクションで変換をパイ

プライン化し、パラレルに実行できます。そのため中間ステージング表で各変換

を実体化するコストが回避できます。プロセス全体がさらに効率よくスケーラブ

ルに、そして中断されません。

SQL Server 2000はパイプライン・テーブル・ファンクションをサポートしません。

結論

IDC社のレポート『Worldwide RDBMS 2004 Vendor Shares: Preliminary Results for

the Top 5 Vendors Show a Solid Boost (March 2005, IDC #32969)』によると、Oracle

は、世界におけるリレーショナル・データベースおよびオブジェクト・リレーショ

ナル・データベースの管理システムのソフトウェア市場において、あらゆる面で

先駆者であり続けている。このような優位は、E-Business、OLTPおよびウェアハ

ウス・アプリケーションをはじめとするもっとも厳しい環境の要件を満たすだけ

でなく、さらにそれを越えた機能であると解釈されます。

Oracleの固有な機能は何年にも渡る技術革新をもとに構築され、あらゆる種類の

アプリケーションに極めて優れた水準のパフォーマンスとスケーリングを与える

ことで、今後も Oracleのリーダーシップを拡大します。


20


Oracle Databaseと SQL Server 2000の技術的比較: パフォーマンスの観点 2005年 9月著者: Hervé Lejeune 寄稿者: Vineet Buch、Sandra Cheevers、Rick Greenwald Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファックス: +1.650.506.7200 www.oracle.com オラクル社は、インターネット上での活動を強化するソフトウェアを提供します。 Oracleはオラクル社の登録商標です。このガイドで使用されているさまざまな製品名およびサービス名には、オラクル社の商標が含まれています。その他のすべての製品名およびサービス名は、各社の商標です。 Copyright © 2005 Oracle Corporation All rights reserved. 無断転載を禁ずこの文書はあくまで参考資料であり、掲載されている情報は予告なしに変更されることがあります。オラクル社は、本ドキュメントの無謬性を保証しません。また、本ドキュメントは、法律で明示的または暗黙的に記載されているかどうかに関係なく、商

品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証または条件に制約されません。オラクル社は、本書の内容に関していか

なる保証もいたしません。また、本書により、契約上の直接的および間接的義務も発生しません。本書は、事前の書面による許可を得ることなく、電子的

または機械的に、いかなる形態または手段によっても複製または伝送することはできません。 Oracleは米国 Oracle Corporationおよび関連会社の登録商標です。他の製品名は、それぞれの所有者の商標です。

Oracle DatabaseとSQL Server 2000の技術的比較...

Documents

Transcript of Oracle DatabaseとSQL Server 2000の技術的比較...