Hybrid Columnar Compressionを使用してSANおよびNASのパフォーマンスを向上する方法

Art Licht著

Oracle Database 11g Release 2（11.2.0.3）のHybrid Columnar Compression機能を外部のNASストレージおよびSANストレージとともに使用して、必要となる記憶域の容量を削減し、問合せのパフォーマンスを向上させる方法について説明します。

2012年7月公開

この記事では、Oracle Database 11g Release 2（11.2.0.3）のHybrid Columnar Compression機能を、外部のNASストレージおよびSANストレージとともに使用した事例について説明し、外部ストレージとともにHybrid Columnar Compressionを使用した場合のスペースと、パフォーマンスへの影響を評価します。 また、Hybrid Columnar Compression機能を有効にして、同様のメリットを得る方法についても説明します。

この事例に使用した製品は、オラクルのSun ZFS Storage Appliance、およびSAN向けのPillar Axiomストレージ・システムです。 焦点は、スペースの節約とHybrid Columnar Compressionによる問合せのパフォーマンスに関する効果についてです。 これについての調査では、圧縮データと非圧縮データへの問合せをそれぞれ実行し、そのI/Oの違いについて分析しました。

その分析結果によれば、Hybrid Columnar Compression機能を利用することによって、必要となる記憶域スペースの削減効果は19倍となり、データベース問合せのパフォーマンスは平均6倍向上しました。

Pillar Axiomストレージ・システムとSun ZFS Storage Appliance

オラクルのPillar Axiom 600ストレージ・システムは、I/O優先順位付けを動的に管理できる統合管理機能を備えています。この機能によって、あらゆる負荷条件下で基幹アプリケーションの最適なパフォーマンスを維持できます。 Pillar Axiom 600は、Pillar Axiom Slammer（ストレージ・コントローラ）、Pillar Axiom Brick（ドライブ・エンクロージャ）、Pillar Axiom Pilot（管理プラットフォーム）という3種類のインテリジェントなハードウェア・アセンブリで構成されるモジュラー・ストレージ・プラットフォームです。データ管理機能一式が搭載されており、Oracle Database 11g Release 2 Hybrid Columnar Compression機能のサポートも含まれています。 さらに、Pillar Axiomのサービス品質機能によって、主要なアプリケーションの重要度に基づいてデータ・アクセスの優先順位付けを実行できます。

オラクルのSun ZFS Storage Applianceファミリーは、エンタープライズ・クラスのNAS機能とデータ・サービス一式が搭載された製品群です。データ・サービスには、スナップショット、クローン、レプリケーション、業界トップクラスのパフォーマンス分析、さらにネイティブ圧縮、重複排除、Oracle Database統合、Hybrid Columnar Compression機能のサポートなどが含まれます。

圧縮の概要

Oracle Databaseでは、アプリケーションを可能な限り効率的に稼働させることができるように、Database Smart Flash Cache、パーティション化、圧縮などの機能を利用して、物理ハード・ディスク・ドライブ（HDD）に対するI/Oの削減を目的とした最適化が行われてきました。

圧縮には、さまざまなレベルやタイプがあります。 OLTP表圧縮は、Oracle Database 11gのOracle Advanced Compressionオプションの一機能であり、更新頻度の高いデータの圧縮に適しています。 一方、Hybrid Columnar Compressionは、オンラインかつアクセス可能な状態を必要とする履歴/アーカイブ・データに適しています。 Oracle Advanced CompressionオプションとOLTP表圧縮の詳細は、『Advanced Compression Option with Oracle Database 11g』を参照してください。

圧縮は、必要となる記憶域容量を削減するための理想的なテクノロジーの1つです。 必要となる記憶域容量を削減するアプローチには、ほかに重複排除というアプローチもあります。 重複排除は、バックアップに同じデータが大量に含まれる場合に効果があります。全体バックアップを1週間おきに実行するような場合に、このような状況が頻繁に生じます。 重複排除は、全体バックアップを無制限の増分バックアップへ変える、効果的な手法と言えます。 ただし、OLTPデータベースのバックアップに対する重複排除の有効性については立証されていません。

また、重複排除は、仮想デスクトップ環境のオンライン・ストレージで、同じオペレーティング・システムから複数のコピーを作成するような場合に効果があることも分かっています。 重複排除の有効性について立証されていないのは、従来型のオンライン・アプリケーションの領域です。 この場合は、Oracle Databaseの圧縮機能の方が優れています。

データの圧縮にはさまざまな方法があります。 Oracle Database内部の圧縮には複数のタイプがあり、それぞれのタイプにさまざまなバリエーションがあります。 OLTP表圧縮は、パーティション・レベル、表レベル、表領域レベルで適用できます。 Hybrid Columnar Compressionは通常、適した表または表パーティションに適用します。 表1は、Oracle Databaseとともに使用できるデータベース対応の圧縮テクノロジーの一覧です。

Oracle Database対応のテクノロジーでは、ストレージ・システムへデータを送信する前にそのデータを圧縮できるというメリットがあります。一般的には、データ移動量の削減につながり、パフォーマンスが向上します。 また、圧縮処理がOracle Databaseに完全統合されるため、多くの場合、圧縮データに直接問合せを実行できます。

Hybrid Columnar Compressionテクノロジーは、データベース・ブロック内のデータを編成するための新しい手法です。 名前から想像できるとおり、このテクノロジーでは、行を使用した手法と列を使用した手法を組み合わせてデータを格納します。 両方の長所を併せ持ったこの混合アプローチは、列形式のストレージによる圧縮メリットを実現しながら、同時に、純粋な列形式によるパフォーマンス低下を回避します。

Hybrid Columnar Compressionは、Pillar Axiomストレージ・システムとSun ZFS Storage Applianceのいずれかがデータベース・サーバーに接続されていることをOracle Databaseで検出されると有効になります。 また、Oracle Exadataストレージ上のOracle Databaseに対しても有効になります。 Pillar Axiomストレージ・システムでは、Oracle Automatic Storage Managementを使用したFC接続およびiSCSI接続がサポートされます。 Sun ZFS Storage Applianceでは、Oracle Database 11g Direct NFS Client経由のNFS接続がサポートされます。

Oracle Automatic Storage Managementは、高パフォーマンスの統合データベース・ファイル・システム/ディスク・マネージャであり、管理者ではなくデータベースがストレージ管理を行うべきだという理念に基づいて導入された機能です。 Oracle Automatic Storage Managementを利用することで、数千個に及ぶ可能性のあるOracle Databaseファイルを管理者が直接管理する必要がなくなります。

Oracle Database 11g Direct NFS Clientは最適化されたNFSクライアントです。NASストレージ・デバイス上のNFSストレージに対する、より簡単で高速な、スケーラビリティに優れたアクセスを可能にします。 Direct NFS ClientはOracle Databaseのカーネルに直接組み込まれています。

事例研究

以降のセクションでは、実施した事例の内容、利用したアーキテクチャ、調査結果について説明します。

圧縮によるスペースの節約

一般的な小売業向けのアプリケーションのデータを使用して、表2のデータベースを作成しました。

このデータベースに必要となる総記憶域スペースは735GBでした。

Sun ZFS Storage ApplianceとPillar Axiomストレージ・システムの両方に対してデータベースのコピーを複数作成しました。これにより、それぞれのデータベースにまったく同じハードウェア・リソースが存在することになります。 実際に、Sun ZFS Storage Applianceでは2つのデータベース・コピーが同じ物理HDDに配置されており、これにより、パフォーマンス上の差異があれば、その原因はHybrid Columnar Compressionにあると言えます。

非圧縮版のデータを作成した後に、OLTP表圧縮版のデータを作成しました。 OLTP表圧縮を同じデータベース表のそれぞれに適用した結果、必要となるスペースが表3のとおりに削減されました。

このデータベースに必要となる総記憶域スペースは243GBであり、全体の記憶域スペースと比較して3倍の削減効果があります。 この削減効果は、Oracle Database 11gのAdvanced CompressionオプションによるOLTP表圧縮では一般的な水準です。一般的には2倍から4倍の圧縮率となります。

Hybrid Columnar CompressionのQuery High圧縮レベルを同じデータベース表のそれぞれに適用した結果、必要となるスペースが表4のとおりに削減されました。

このデータベースに必要となる総記憶域スペースは38GBであり、全体の記憶域スペースと比較して19倍の削減効果があります。 この削減効果は、一般的なQuery High圧縮よりもやや高い水準です。一般的には6倍から10倍の圧縮率となります。

ストレージ・アレイ内のデータも圧縮可能です。 ストレージ・アレイでデータを圧縮する場合、アプリケーションやデータベースには、データの圧縮は認識されません。圧縮はアプリケーションにとって透過的に行われます。

ストレージ・アレイベースの圧縮では、圧縮されたデータを展開してから、データをサーバーに転送する必要があります。 さまざまなストレージ・システムで、複数の圧縮アルゴリズムが採用されています。 このテストでは、CPU使用率が低いという理由で、Sun ZFS Storage Appliance LZJB圧縮を選択しました。 LZJBは可逆圧縮アルゴリズムです。 LZJBには、Lempel-Ziv圧縮アルゴリズム・ファミリーに属しているLZRW1アルゴリズムに対する多くの改善点が含まれています。

図1は、Sun ZFS Storage Applianceの圧縮設定を示したスクリーンショットです。 データに対する問合せを実行するためには、圧縮されたデータを展開してデータベース・サーバーに転送する必要があります。

図1. Sun ZFS Storage ApplianceアレイベースのLZJB圧縮

このデータベースに必要となる総記憶域スペースは143GBでした。 OLTP表圧縮によって圧縮されたデータベースに対してLZJBを使用した場合、表5に示すとおり、サイズは131GBまで削減されました。

Advanced CompressionオプションやHybrid Columnar CompressionなどのOracle Database対応の圧縮テクノロジーを利用する場合は、ネイティブの圧縮形式で、圧縮されたデータをストレージとサーバー間で転送できます。 データが圧縮された状態がディスク上で維持されるだけではなく、Database Smart Flash Cacheの内部、ネットワーク上、データベース・サーバーのバッファ・キャッシュ内部、さらにはOracle Recovery Manager（Oracle RMAN）によるバックアップ実行中、Oracle Active Data Guardによるログ・シッピングの実行中にも維持されます。

Advanced CompressionオプションおよびHybrid Columnar Compressionは、Oracle Database Enterprise Editionの固有機能です。 Sun ZFS Storage ApplianceのLZJBなどのアレイ圧縮では、あらゆるアプリケーション環境での利用がサポートされます。

圧縮技法によって節約されるスペースは、圧縮される個々のデータ、およびデータセットのサイズによって変わります。 このテストでは、小売業の取引データ、レジのレシート、その他の小売業環境に特有のデータで構成される、小売業で使用されたデータを小容量使用しました。 NAS（Sun ZFS Storage Appliance）とSAN（Pillar Axiomストレージ・システム）の両方の環境で、Hybrid Columnar Compressionによるスペースの節約効果は同じ19倍になりました。

事例研究の一環として、OLTP圧縮およびQuery High圧縮を適用したそれぞれの表に対して、Oracle Advanced Compression Advisorを実行しました。 すべてのインスタンスで、Oracle Advanced Compression Advisorによる予測の正確性は95%を超えていました。 Oracle Advanced Compression Advisorはあらゆるタイプのストレージに対して実行できます。 詳細は、"Oracle Advanced Compression Advisorの実行"を参照してください。

問合せのパフォーマンス

問合せのパフォーマンスに対するHybrid Columnar Compressionの効果を評価するために、2種類の環境を構築しました。 1つはNAS環境で、ストレージはDirect NFS Client経由でサーバーに接続されています。 制限されたI/O環境でのHybrid Columnar Compressionの効果を評価する目的のために、I/O帯域幅が制限された小規模な環境を意図的に構築しました。 この環境では、1GbEを使用した小規模な単一トレイのSun ZFS Storage Applianceを使用しました。

それぞれのデータベースを、Sun ZFS Storage Appliance内の同じHDDセット上に配置しました。 すべてのHDDは、同じSun ZFS Storage Applianceプール間でストライプ化され、RAID-Z1として構成しました。 また、すべてのデータベースを同じ物理サーバー（4ソケットのIntel Nehalemシステム）上にホストしました。 各データベースは、専用のクローン化された仮想マシン（Oracle VM 3.0）にあり、それぞれに同じ構成パラメータ（DRAM、CPU、SGAなど）を指定しました。 サーバーは1GbEでSun ZFS Storage Applianceに接続されています。 ハードウェア構成の詳細は、付録Aを参照してください。

パフォーマンス上の効果を評価するために、6つの問合せを作成しました。それぞれの問合せについては付録Bに記載されています。 それぞれの問合せは、複雑度や、I/O型か計算型かという点に違いがあります。 注意すべきこととして、I/O待ちがまったく発生しないような非常に大規模なストレージ・システムを構築する、つまりCPUが制限されたアーキテクチャを構築すること自体は可能です。 これには、数多くのドライブやフラッシュ・ストレージで構成され、場合によっては複数のアレイも使用する、大規模で高価なシステムが必要となります。 Hybrid Columnar Compressionではストレージを大幅に効率化できるため、ストレージやアレイを追加する必要性を低減します。

Sun ZFS Storage Applianceのパフォーマンス監視ソフトウェアの画面には、高いキャッシュ・ヒット率および低いディスク使用率が表示されました。これは、正常なストレージ・システムの典型的な状態です。 図2に示すとおり、ディスクのアクティビティは平均10%未満の使用率となりました。

図2. ディスクのアクティビティ

図3では、キャッシュ・ヒット率が非常に高い数値を示しています。その数値は90%を超え、アクセス回数は1秒あたり1,100回をやや超えていました。1秒あたり1,100回のアクセスというのは、1秒あたり100MBをやや超えるデータ量に相当します。これはギガビット・イーサネットの限界値です。

図3. キャッシュ・ヒット率

この事例におけるパフォーマンスの制限要因は、ギガビット接続にありました。 これが原因となり、非圧縮データに対する問合せのパフォーマンスはI/Oによって低下していました。表6のとおり、データベース自動ワークロード・リポジトリ（AWR）レポートのスナップショットには、大量のI/O待ちが記録されています。

さらに、同じ問合せのセットを、Hybrid Columnar Compressionによって圧縮された表に対して実行しました。これらの表は、同じSun ZFS Storage Applianceの8台の7,200RPMドライブに格納しています。 表7は、同じ実行時間のデータベースAWRレポートを示したものです。

I/O待ち時間がなくなりました。 Sun ZFS Storage Applianceの分析で、ストレージ・システムへのI/Oリクエストが大幅に削減されているのがわかりました。 非圧縮表に対して問合せを実行した場合、平均で1秒あたり約1,100回のI/Oアクセスがありました。一方、Hybrid Columnar Compressionのデータに対する問合せでは、I/Oリクエストが1秒あたり約375回まで削減されました。

I/Oの削減の結果、平均ロードが大幅に減少し、より短い時間でより多くの処理をCPUで実行できるようになりました。 図4では、1秒あたりのキャッシュ・アクセスが、1,100回超から375回にまで減少しています。

図4. 1秒あたりのキャッシュ・アクセス

Sun ZFS Storage Applianceに対しては、3種類の問合せを実行しました。それぞれの問合せは、複雑度や、必要となるI/Oの量と処理量に違いがあります。 表8に、3種類の問合せの結果を示します。

すべてのケースで、Hybrid Columnar Compressionデータに対する問合せの方が、非圧縮データに対する問合せよりも速いことがわかります。 問合せの実行速度は平均して7倍になりました。

次に調査した環境は、FCが配置された高パフォーマンス環境です。 I/O性能を大幅に高めるためにSAN環境をセットアップしました。 8台の7,200RPMドライブの代わりに、48台のFC 15,000RPMドライブを搭載したPillar Axiomストレージ・システムを使用しました。 ストレージは、4Gb FCを使用してサーバーに接続しました。 FC LUNがサーバーに提示され、Oracle Automatic Storage Managementにインポートされました。 このSAN環境の帯域幅（4Gb）は、前述のNAS環境（1Gb）の4倍あります。 ディスク構成は両方とも、シングルパリティRAIDです。

表9に、3種類の問合せの結果を示します。

このようにI/O性能の高い環境でも、表10のとおりCPUでI/O待ちが発生しました。

すべてのケースで、Hybrid Columnar Compressionの表に対する問合せの方が、非圧縮データに対する問合せよりも速いことがわかりました。平均で4.5倍の速度です。 このケースでも、I/O待ちがなくなりました。

iowaitによる計測の結果、非圧縮データに対して実行した場合にCPUでのI/O待ちが発生するような問合せでは、Hybrid Columnar Compressionの効果がもっとも顕著に表れます。必要となるI/Oの量が圧縮によって削減されるからです。 たとえば、問合せ5を圧縮データに対して実行した場合に必要となる物理読取り回数は450万回でした。一方、同じ問合せをHybrid Columnar Compressionで圧縮されたデータに対して実行した場合は、必要となる物理読取り回数は137,000回のみでした（autotraceによる計測）。 問合せ5で読取られた表の大きさは、非圧縮データの場合は35GBです。一方、Hybrid Columnar CompressionのQuery Highで圧縮されたデータの場合は約1.08GBをやや上回るサイズでした。 この表サイズの削減効果は32倍です。 問合せの実行による物理I/Oは、4,503,701から137,416に削減されています。物理I/Oの削減効果も32倍あります。

アーキテクチャ例

Hybrid Columnar Compressionは通常、問合せ専用のデータや履歴データに使用します。 OLTP表圧縮は、トランザクション型の読取り/書込みデータに使用でき、通常は2倍～4倍程度のスペースの節約効果があります。 また、Hybrid Columnar Compressionでは通常、10倍～50倍のスペースの節約効果があります。

このテスト環境では、OLTP表圧縮のスペースの節約効果は3倍あり、Hybrid Columnar Compressionの場合は、複数の表にわたるスペースの節約効果が19倍に上りました。 それぞれの圧縮タイプによって、ユースケースは異なります。 両方の圧縮タイプを適切に使用した場合に、もっとも大きな効果を得ることができます。

図5に示すとおり、データベースのパーティション化を使用して、日付を基準として表をセグメント分割できます。次に、2011年と2012年のパーティション内にあるトランザクション・データにOLTP表圧縮を適用できます。この2011年と2012年のパーティションは、任意のストレージ・デバイスに配置できます。 さらに、履歴データにはHybrid Columnar Compressionを適用できます。

図5. データベースのパーティション化による表のセグメント分割

データベースが50TBのサイズで、前述の事例と同様の圧縮率であるとします。この場合、履歴データに対してHybrid Columnar Compressionのみを適用することで、ストレージ容量が50TBから15TBに削減されます。

このように表のサイズが削減されることには他のメリットもあります。Oracle DatabaseのOracle RMAN、Oracle Active Data Guard、Database Smart Flash Cacheなどの機能が、Hybrid Columnar Compressionで圧縮されたデータに対して動作することになるからです。 その結果、データ転送量が減少するため、バックアップやリストアの実行速度が向上します。

Oracle Advanced Compression Advisorの実行

既存の環境でHybrid Columnar Compressionを使用することによる効果を評価するためには、Oracle Advanced Compression Advisorを実行し、潜在的な圧縮効果を確認します。Oracle Advanced Compression Advisorは、Oracle Database 11gに標準的に搭載されています。

Hybrid Columnar Compressionには、 Query High、Query Low、Archive High、Archive Lowという4つのレベルがあります。 Oracle Advanced Compression Advisorは、この4つのレベルすべてに実行できます。

Oracle Advanced Compression Advisorの詳細は、Oracle Advanced Compression AdvisorのWebサイトを参照してください。

Hybrid Columnar Compressionの有効化

以降のセクションでは、Oracle DatabaseのHybrid Columnar Compression機能を有効にし、Sun ZFS Storage ApplianceおよびAxiom Pillarストレージ・システムとともに使用する方法について説明します。

Hybrid Columnar Compressionを有効にする方法（Sun ZFS Storage Applianceの場合）

1. Oracle Database 11g Release 2.03にアップグレードします。
   
   

   support.oracle.comのMy Oracle Support Note 10404530を参照してください（登録が必要です）。

2. support.oracle.comで、パッチ13041324を検索し、ダウンロードして適用します。
3. Oracle Databaseサーバーに1つ以上のZFSシェアをマウントします。
   
   

   ZFSシェアをNFSマウントする場合のfstabエントリの例は次のとおりです。 Direct NFS（dNFS）を使用する場合は、データベースではrsizeパラメータとwsizeパラメータが必要に応じて設定されます。

   <アプライアンスのIPアドレス>:<アプライアンスの共有マウント・ポイント> nfs 
   nfsvers=3,proto=tcp,hard,intr,rsize=<バイト数>,wsize=<バイト数>
   

4. ユーザーoracleとして、次の手順に従って、Oracle Databaseサーバー上でdNFSを有効にします。
   
   
   1. $ORACLE_HOME/libディレクトリに移動します。
   2. シンボリック・リンクlibodm11.soを削除します。
      
      

      rm -f libodm11.so
      

   3. dNFS共有ライブラリをポイントする新しいシンボリック・リンクを作成します。
      
      

      ln -s libnfsodm11.so libodm11.so
      

5. データベースを起動します。

Hybrid Columnar Compressionを有効にする方法（Axiom Pillarストレージ・システムの場合）

1. データベースを起動します。
2. データベースの互換性に関する属性の値を11.2.0.3.0に設定します。
   
   

   [Oracle @ myhost] $ sqlplus / as sysasm      
   
   SQL> alter system set compatible='11.2.0.3.0' scope=spfile sid='*';  
   SQL> alter diskgroup data_hcc set attribute 'compatible.asm'='11.2.0.3.0';   
   SQL> alter diskgroup data_hcc set attribute 'compatible.rdbms'='11.2.0.3.0';
   

3. storage.type属性の値をAXIOMに設定します。
   
   

   SQL> alter diskgroup data_hcc set attribute 'storage.type'='AXIOM';  
   

注： ディスク・グループがPillar Axiomストレージであるかどうかを確認する方法は次のとおりです。 Pillar Axiom以外のストレージに対してこのコマンドを実行した場合、次のようなエラー・メッセージが表示されます。

ORA-15287: 互換性のないディスクのため、ディスク・グループ属性storage.typeを設定できませんでした  
ORA-15285: ディスク'/dev/mapper/XXXXXXXX'は、ディスク・グループ属性storage.typeに違反しています

結論

圧縮テクノロジーは、スペースを節約しパフォーマンスを向上できるテクノロジーであり、データの格納と管理にかかるコストを削減できます。 圧縮テクノロジーについては、 節約されるスペースのサイズ、およびそのスペースの節約によるパフォーマンスへの影響の2点を考慮する必要があります。

この記事で説明したテストでは、アレイベースの圧縮では、スペースを節約できましたが、問合せのパフォーマンスは向上しませんでした。原因は、データベースに転送される圧縮されたデータを展開する必要があることです。 データベース対応のHybrid Columnar Compressionでは、データ転送のためにデータを展開する必要はありません。

小売業のデータ・スキーマを使用した今回のテストでは、Oracle Database 11g Release 2のHybrid Columnar Compression機能によって、情報の格納に必要となる容量の削減効果が19倍となり、問合せのパフォーマンスは6倍近くに向上しました。

参考情報

• 『Advanced Compression Option with Oracle Database 11g』
• LZRW1アルゴリズム
• 圧縮アルゴリズムのLempel-Zivファミリー
• Oracle Advanced Compression AdvisorのWebサイト

謝辞

この記事は、Maury Edmondsの協力なしには書き終えることはできませんでした。 Edmondsは現在、Oracle Solution Centerのシステム・エンジニアとして働いており、仮想化テクノロジー、技術デモの開発、顧客の概念実証のサポートを専門としています。 彼は、この記事の調査で使用したすべてのテスト環境の構築に貢献してくれました。

著者について

Art Lichtは、北米にあるOracle Solution CenterのChief Architectです。 ArtはSun Microsystemsの買収にともないオラクルの一員となりました。Sun Microsystemsでは優秀なエンジニアとして従事し、North American StorageグループのChief Technologistも務めました。 ストレージ関連のベスト・プラクティスや設計手法に関する多数の書籍の著者であり、さまざまな大規模異機種SAN環境のアーキテクトでもあります。 業界最大のOracle Databaseの実装およびSAPの実装を担当するチームを率いています。

付録A—ハードウェア構成

付録B—問合せ

オラクルのPillar Axiomストレージ・システムまたはオラクルのSun ZFS Storage ApplianceにHybrid Columnar Compressionを実行することによって実現するパフォーマンスに近づけるには、サード・パーティ製のハードウェアの規模を大幅に拡大する必要があるだろうと、オラクルのチームは評価しています。 データベースのI/O待ちの原因となる要因は複数あるため（たとえば、ネットワークやCPU使用率）、現時点では、必要となる追加分のサード・パーティ製ハードウェアについて明示することは現実的ではありません。

問合せ1

select count(distinct(t.trx_nbr))
from
 DWB_RTL_SLS_RETRN_LINE_ITEM li
,DWB_RTL_TRX t
,DWR_SKU_ITEM p
,DWR_ORG_BSNS_UNIT s
where
li.trx_nbr = t.trx_nbr
and li.day_key = t.day_key and li.sku_item_key = p.sku_item_key and t.bsns_unit_key = s.org_bsns_unit_key
and li.actn_cd = 'Sale' 
and t.day_key = 20080905
and p.sku_item_desc = 'Chili Sauce' 
and s.state in ('AZ', 'CA', 'NM', 'TX') 

問合せ2

select count (*) from DWB_RTL_SLS_RETRN_LINE_ITEM

問合せ3

column c format 999,999,999,999
set echo on
set timing on

select count(trx_nbr) c
from
 DWB_RTL_SLS_RETRN_LINE_ITEM li

問合せ4

select to_char(cast(li.end_dt_time_stamp as date), 'YYYYMMDD') ,li.actn_cd
,count(distinct(t.trx_nbr))
from
 DWB_RTL_SLS_RETRN_LINE_ITEM li
,DWB_RTL_TRX t
,DWR_SKU_ITEM p
,DWR_ORG_BSNS_UNIT s
where
-- Joins 
    li.trx_nbr = t.trx_nbr
and li.day_key = t.day_key
and li.sku_item_key = p.sku_item_key
and t.bsns_unit_key = s.org_bsns_unit_key
-- Filters
and t.day_key between 20080905 and 20080907 
and p.sku_item_desc = 'Chili Sauce' 
and s.state in ('AZ', 'CA', 'NM', 'TX') group by  to_char(cast(li.end_dt_time_stamp as date), 
'YYYYMMDD') ,li.actn_cd order by 1, 2

問合せ5

select state, count(*)
from dwb_rtl_trx t, dwr_org_bsns_unit b
where t.bsns_unit_key = b.org_bsns_unit_key
group by state

問合せ6

select state, count(*), sum(qty)
from dwb_rtl_trx t, dwr_org_bsns_unit b, dwb_rtl_sls_retrn_line_item l
where t.bsns_unit_key = b.org_bsns_unit_key
and l.trx_nbr = t.trx_nbr
and l.day_key = t.day_key
and t.day_key = 20080907
group by state;

オラクルのすべてのテクノロジーに関するシステム管理関連のコンテンツについては、OTN SystemsのFacebookとTwitterをフォローして確認してください。