7 TimesTenデータベースのデータの処理

この章では、TimesTenデータベースの基本コンポーネントの詳細について説明し、SQLを使用してこれらのコンポーネントを管理する方法の簡単な例を示します。SQLの詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』を参照してください。

CまたはJavaアプリケーション内からSQLを実行する方法の詳細は、『Oracle TimesTen In-Memory Database Java開発者ガイド』のTimesTenデータの管理に関する説明または『Oracle TimesTen In-Memory Database C開発者ガイド』のTimesTenデータの管理に関する説明を参照してください。

この章の内容は次のとおりです。

• データベースの概要

• 表の理解

• ビューの理解

• マテリアライズド・ビューの理解

• 索引の理解

• 行の理解

• シノニムの理解

データベースの概要

この項では、TimesTenデータベースの主な要素および特徴について説明します。内容は次のとおりです。

• データベースのコンポーネント

• データベースのユーザーおよび所有者

• データベースの永続性

データベースのコンポーネント

TimesTenデータベースには、次の永続コンポーネントがあります。

• 表:TimesTenデータベースの主要コンポーネントは、アプリケーション・データを格納する表です。「表の理解」を参照してください。

• マテリアライズド・ビュー:1つ以上の通常のTimesTen表から選択したデータのサマリーを保持する読取り専用表です。「マテリアライズド・ビューの理解」を参照してください。

• ビュー:1つ以上のディテール表と呼ばれる表に基づく論理表です。ビュー自体にはデータは含まれていません。「ビューの理解」を参照してください。

• 索引:表の1つ以上の列に対して索引を作成すると、表へのアクセスが速くなります。「索引の理解」を参照してください。

• 行:各表は、0行以上の行で構成されています。行とは、形式が整えられた値のリストです。「行の理解」を参照してください。

• システム表:システム表にはTimesTenメタデータ（すべての表に関する表など）が含まれています。Oracle TimesTen In-Memory Databaseのシステム表および制限についてのマニュアルのシステム表に関する説明を参照してください。

また、準備済のコマンド、カーソル、ロックなどの多くの一時コンポーネントもあります。

データベースのユーザーおよび所有者

アクセス制御が有効の場合、TimesTen Data Managerはパスワードでユーザー名を認証します。TimesTen Client/Serverでも、パスワードでユーザーを認証します。アプリケーションでは、専用に1つのUIDを選択する必要があります。これは、アプリケーションの実行に使用されるログイン名が、デフォルトではデータベースの所有者になるためです。2つの異なるログイン名を使用すると、TimesTenでの正しい表の検出が困難になる可能性があります。TimesTenでは、接続文字列でUID接続属性を省略すると、現行のユーザーのログイン名が使用されます。また、すべてのユーザー名が大文字に変換されます。

ユーザーは、SYSユーザーとしてTimesTenデータベースにアクセスすることはできません。TimesTenは、UID接続属性の値または接続ユーザーのログイン名（UID接続属性の値が存在しない場合）でユーザー名を判別します。ユーザーのログイン名がSYSの場合は、ログイン名が上書きされるようにUID接続を設定します。

データベースの永続性

データベースは、作成されると、永続属性セットまたは一時属性セットのいずれかが設定されます。

• 永続データベースは、チェックポイントと呼ばれるプロシージャで自動的にディスクに保存されます。TimesTenでは、接続属性CkptFrequencyおよびCkptLogVolumeの設定に基づいて、チェックポイント処理がバックグラウンドで自動的に実行されます。また、最後のアプリケーションが切断されるときにも、データベースのチェックポイント処理が実行されます。さらに、アプリケーションでttCkptBlocking組込みプロシージャ（『Oracle TimesTen In-Memory Databaseリファレンス』を参照）を起動してチェックポイント処理を実行し、データベースをディスクに直接保存することもできます。

• 一時データベースは、ディスクに保存されません。アプリケーションが接続されていない場合、一時データベースは自動的に破棄されます。TimesTenでは、最後のアプリケーションを切断すると、ディスク・ベースのすべてのファイルが削除されます。

注意: データベースの作成後、そのデータベースの永続属性または一時属性は変更できません。

表の理解

TimesTenの表は、共通の書式または構造を持つ行で構成されています。この書式は、表の列で定義します。

次の項では、表とその列およびこれらの管理方法について説明します。

• 表の概要

• 表の処理

• 表へのエージングの実装

表の概要

この項の内容は次のとおりです。

• 列の概要

• インライン列およびアウトライン列

• デフォルトの列値

• 表名

• 表へのアクセス

• 主キー、外部キーおよび一意索引

• システム表

列の概要

表に列を作成する場合、列名の大文字と小文字は区別されます。

各列には、次の値が設定されています。

• データ型

• NULL値可能、主キーおよび外部キーのプロパティ（オプション）

• オプションのデフォルト値

列は、NOT NULLと明示的に宣言しないかぎり、NULL値可能になります。表の列がNULL値可能の場合は、その列にNULL値を保存できます。NULL値可能でない場合は、表のその列の各行にNULL以外の値を設定する必要があります。

TimesTenの列の書式は変更できません。列の追加または削除はできますが、列の定義は変更できません。列の追加または削除を実行するには、ALTER TABLE文を使用します。列の定義を変更する場合は、まずその表を破棄してから、新しい定義で表を再作成する必要があります。

インライン列およびアウトライン列

表の行のインメモリー・レイアウトは、行への高速アクセスを可能にし、無駄な領域が最小限になるように設計されています。TimesTenでは、表のVARBINARY、NVARCHARおよびVARCHARの各列がインラインまたは非インラインのいずれかに指定されます。

• インライン列は固定長です。表内のすべての固定長列の値は、行単位で保存されます。

• 非インライン列は可変長です。データ型がVARCHAR、NVARCHARまたはVARBINARYの列には、非インラインで保存されるものがあります。非インライン列は、行に近接して保存されるのではなく、行に割り当てられます。アウトライン列にアクセスする場合は、インライン列にアクセスする場合より多少時間がかかります。デフォルトでは、宣言された列の長さが128バイトを超えるVARCHAR、NVARCHARおよびVARBINARYの列は、アウトラインで保存されます。宣言された列の長さが128バイト以下の列は、インラインで保存されます。

行のインライン部分およびアウトオブライン部分の最大サイズについては、「表サイズの見積り」を参照してください。

デフォルトの列値

表の作成時に、デフォルトの列値を指定できます。指定するデフォルト値は、列のデータ型と互換性がある必要があります。列には、次のいずれかのデフォルト値を指定できます。

• NULL（すべてのデータ型の列）

• 定数値

• SYSDATE（DATE列およびTIMESTAMP列）

• USER（CHAR列）

• CURRENT_USER（CHAR列）

• SYSTEM_USER（CHAR列）

CREATE TABLE文のDEFAULT句を使用し、デフォルト値を指定しなかった場合、デフォルト値はNULLになります。『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の列定義に関する説明を参照してください。

表名

TimesTenの表は、所有者名および表名によって一意に識別されます。すべての表に所有者が存在します。デフォルトでは、表を作成したユーザーが所有者になります。TimesTenによって作成される表（システム表など）の所有者名はSYSですが、レプリケーション時に作成される場合はTTREPになります。

表を一意に参照するには、MARY.PAYROLLなどのように表の所有者名と表名をピリオド「.」で区切って指定します。所有者を指定しなかった場合、TimesTenは、コール元のユーザー名の下にある表を検索し、次にユーザー名SYSの下にある表を検索します。

名前は、文字で始まる英数字の値です。名前には、アンダースコアを使用できます。表名の長さは、最大30文字です。所有者名の長さも、最大30文字です。TimesTenでは、すべての表名、列名および所有者名が大文字で表示されます。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の名前とパラメータに関する説明を参照してください。

表へのアクセス

アプリケーションは、SQL文を介して表にアクセスします。TimesTenの問合せオプティマイザは、表に高速にアクセスする方法を自動的に選択します。アクセスの高速化には、既存の索引が使用されます。また、必要に応じて一時索引が作成されます。一時索引の自動作成および自動破棄を行うとパフォーマンスのオーバーヘッドが発生するため、パフォーマンスを向上させるには、頻繁に検索する列に対して、アプリケーションで索引を明示的に作成する必要があります。詳細は、「文のチューニングと索引の使用」を参照してください。

主キー、外部キーおよび一意索引

TimesTenの表の作成者は、1つ以上の列を主キーに指定して、それらの列で重複値が拒否されるように設定できます。主キーの列は、NULL値可能にできません。1つの表に設定可能な主キーは1つのみです。TimesTenは、主キーに対して範囲索引を自動的に作成して、主キーに一意性を適用し、主キーを介した高速アクセスを保証します。索引の詳細は、「索引の理解」を参照してください。行を挿入すると、範囲索引をハッシュ索引に変更する場合を除き、主キー列を変更できなくなります。

1つの表に設定可能な主キーは1つのみですが、一意索引を使用すると、一意性に関するプロパティを表に追加できます。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』のCREATE INDEXに関する説明を参照してください。

注意: 主キーの列はNULL値可能にできませんが、一意索引をNULL値可能な列に作成することはできます。

また、表には、別の表の行に対応する行を持つ1つ以上の外部キーを設定できます。外部キーは、他方の表の主キーまたは一意に索引付けされた列に関連付けられています。外部キーは、参照先列に対して範囲索引を使用します。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』のCREATE TABLEに関する説明を参照してください。

システム表

TimesTenのデータベースには、アプリケーションで作成された表のみでなく、システム表も含まれています。システム表には、TimesTenメタデータ（データベース内のすべての表および索引の定義など）およびその他の情報（オプティマイザ計画など）が保存されています。アプリケーションでは、ユーザー表の場合と同様にシステム表を問い合せることができます。アプリケーションでは、システム表の更新はできません。TimesTenのシステム表については、Oracle TimesTen In-Memory Databaseのシステム表および制限についてのマニュアルの「システム表」の章を参照してください。

注意: TimesTenのシステム表の書式は、リリースによって異なる場合があります。32ビット版と64ビット版のTimesTenでは、この書式が異なります。

表の処理

表の作成、破棄または管理を行う処理を実行するには、適切な権限を持っている必要があります。権限の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「SQL文」の章で、すべてのSQL文の構文とともに説明されています。

この項の内容は次のとおりです。

• 表の作成

• 表の破棄

• 表サイズの見積り

表の作成

表を作成するには、SQL文CREATE TABLEを使用します。SQL文の構文については、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』を参照してください。TimesTenでは、表名が大文字に変換されます。

例7-1 表の作成

次のSQL文によって、2つの異なるデータ型のCustIdおよびCustNameという2つの列を持つNameIDという表が作成されます。

CREATE TABLE NameID (CustId TT_INTEGER, CustName VARCHAR2(50));

例7-2 ハッシュ索引を持つ表の作成

この例では、CustId、CustName、Addr、ZipおよびRegion列を持つCustomerという表が作成されます。CustId列が主キーに指定されます。これによって、表内の行はCustId値で一意に識別されます（「主キー、外部キーおよび一意索引」を参照）。UNIQUE HASH ON custId PAGES値は、ハッシュ索引にはページが30含まれていることを示しています。この数値は、表のハッシュ索引に割り当てるバケットの数の決定に使用されます。バケット数は、（PAGES×256）/ 20です。したがって、ハッシュ索引に割り当てられるバケットの数は384（（30×256）/ 20 = 384）となります。

CREATE TABLE Customer
(custId NUMBER NOT NULL PRIMARY KEY,
custName CHAR(100) NOT NULL,
Addr CHAR(100),
Zip NUMBER,
Region CHAR(10))
UNIQUE HASH ON (custId) PAGES = 30;

表の破棄

TimesTen表を破棄するには、SQL文DROP TABLEをコールします。

例7-3 表の破棄

次の例では、表NameIDが破棄されます。

DROP TABLE NameID;

表サイズの見積り

TimesTenデータベースのサイズの増加は、最初の接続時に行うことができます。データベースのサイズを変更する必要をなくすには、データベースの最終的なサイズを少なく見積もらないようにする必要があります。データベースのサイズの見積りには、ユーティリティttSizeを使用します。

表へのエージングの実装

データベース内の1つ以上の表に対してエージング・ポリシーを定義できます。エージング・ポリシーとは、エージングのタイプ、属性および状態（(ONまたはOFF）のことです。使用状況ベースまたは時間ベースのいずれかのタイプのエージング・ポリシーを指定できます。使用状況ベースのエージングでは、指定したデータベースの使用範囲内の最低使用頻度（LRU）のデータが削除されます。時間ベースのエージングでは、指定したデータ存続期間およびエージング・プロセスの頻度に基づいてデータが削除されます。使用状況ベースと時間ベースの両方のエージングを同じデータベースに定義することはできますが、特定の表に対して定義できるエージング・タイプは1つのみです。

CREATE TABLE文を使用して、新しい表のエージング・ポリシーを定義できます。既存の表にエージング・ポリシーが定義されていない場合は、ALTER TABLE文を使用してその表にエージング・ポリシーを追加できます。エージング・ポリシーは、エージング・ポリシーを破棄したり、新しいエージング・ポリシーを追加することによって変更できます。

次のタイプの表にはエージングを指定できません。

• グローバル一時表

• マテリアライズド・ビューのディテール表

キャッシュ・グループにエージングを実装することもできます。『Oracle In-Memory Database Cacheユーザーズ・ガイド』のキャッシュ・グループへのエージングの実装に関する説明を参照してください。

この項の内容は次のとおりです。

• 使用状況ベースのエージング

• 時間ベースのエージング

• エージングおよび外部キー

• エージング開始のスケジュール

• エージング開始のスケジュール

使用状況ベースのエージング

使用状況ベースのエージングを使用すると、最低使用頻度（LRU）のデータを削除することによって、データベースで使用されるメモリーの量を、指定したしきい値の範囲内で管理できます。

CREATE TABLE文のAGING LRU句を使用して、新しい表のLRUエージングを定義します。エージングの状態がONの場合、エージングは自動的に開始されます。

ttAgingLRUConfig組込みプロシージャを使用して、LRUエージング属性を指定します。属性値は、LRUエージング・ポリシーが含まれているデータベース内のすべての表に適用されます。ttAgingLRUConfig組込みプロシージャをコールしない場合は、属性のデフォルト値が使用されます。

注意: 属性を変更する場合、ttAgingLRUConfig組込みプロシージャを使用するにはユーザーにADMIN権限が必要です。既存の属性を表示する場合、権限は必要ありません。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の組込みプロシージャに関する説明を参照してください。

次の表に、LRUエージング属性の概要を示します。

LRUエージング属性	説明
LowUsageThreshhold	LRUエージングが非アクティブになるデータベースPermSizeの割合（%）。
HighUsageThreshhold	LRUエージングがアクティブになるデータベースPermSizeの割合（%）。
AgingCycle	エージング・サイクルの間隔（分）。

LRUエージング・ポリシーの定義後、AgingCycleに対して新しい値を設定すると、エージングは、その時点での時間および新しいサイクル時間に基づいて実行されます。たとえば、元のエージング・サイクルが15分で、LRUエージングが10分前に実行された場合、エージングは、5分後に再度実行されることになります。ただし、AgingCycleパラメータを30分に変更すると、AgingCycleで変更した値を使用してttAgingLRUConfigプロシージャをコールした時点から30分後にエージングが行われます。

最後のエージング・サイクル以降に行へのアクセスまたは行の参照を行った場合、その行はLRUエージングの対象ではなくなります。行は、次のいずれかの条件に当てはまる場合にアクセスまたは参照されたとみなされます。

• 行がSELECT文の結果セットを作成するために使用された。

• 行に、更新フラグまたは削除フラグが設定されている。

• 行がINSERT SELECT文の結果セットを作成するために使用された。

ALTER TABLE文を使用して、次のタスクを実行できます。

• ALTER TABLE文をSET AGING {ON|OFF}句とともに使用して、エージング・ポリシーが定義されている表のエージングの状態を有効または無効にします。

• ALTER TABLE文をADD AGING LRU [ON|OFF]句とともに使用して、LRUエージング・ポリシーを既存の表に追加します。

• ALTER TABLE文をDROP AGING句とともに使用して、表のエージングを破棄します。

エージングの開始をスケジュールするには、ttAgingScheduleNow組込みプロシージャを使用します。詳細は、「エージング開始のスケジュール」を参照してください。

表のエージングをLRUから時間ベースに変更するには、まず、DROP AGING句とともにALTER TABLE文を使用して表のエージングを破棄します。次に、ADD AGING USE句とともにALTER TABLE文を使用して時間ベースのエージングを追加します。

注意: LRUエージングを破棄するか、またはコマンドで参照される表にLRUエージングを追加すると、TimesTenによって、コンパイルされているコマンドが無効とマークされます。これらのコマンドは、再コンパイルする必要があります。

時間ベースのエージング

時間ベースのエージングでは、指定したデータ存続期間およびエージング・プロセスの頻度に基づいてデータが表から削除されます。CREATE TABLE文のAGING USE句を使用して、新しい表の時間ベースのエージング・ポリシーを指定します。ALTER TABLE文のADD AGING USE句を使用して、既存の表に時間ベースのエージング・ポリシーを追加します。

AGING USE句には、ColumnName引数があります。ColumnNameは、時間ベースのエージングで使用される列の名前です。これをタイムスタンプ列と呼びます。タイムスタンプ列は次のように定義されます。

• ORA_TIMESTAMP、TT_TIMESTAMP、ORA_DATEまたはTT_DATEデータ型

• NOT NULL

使用しているアプリケーションによって、タイムスタンプ列の値が更新されます。いくつかの行でこの列の値が不明な場合に、それらの行がエージングされないようにするには、その列のデフォルト値を大きい値に定義します。タイムスタンプ列に索引を作成すると、エージング・プロセスのパフォーマンスを向上できます。

注意: 列を追加または変更してNOT NULLに定義することはできないため、既存の表で列を追加または変更した後で、その列をタイムスタンプ列として使用することはできません。

時間ベースのエージング・ポリシーが含まれている表からタイムスタンプ列を破棄することはできません。

タイムスタンプ列のデータ型がORA_TIMESTAMP、TT_TIMESTAMPまたはORA_DATEある場合は、CREATE TABLE文のLIFETIME句に、日、時間または分単位で存続期間を指定できます。タイムスタンプ列のデータ型がTT_DATEである場合は、日単位で存続期間を指定します。

タイムスタンプ列の値は、SYSDATEから引かれます。結果は、指定した単位（分、時間、日）を使用して切り捨てられ、指定したLIFETIME値と比較されます。結果がLIFETIME値より大きい場合、その行はエージングの候補となります。

CYCLE句を使用して、システムで行を確認し、指定した存続期間を超えたデータを削除する頻度を指定します。CYCLEを指定しない場合、エージングは5分ごとに行われます。CYCLEに0（ゼロ）を指定した場合、エージングは継続して行われます。エージングは、状態がONの場合、自動的に開始されます。

ALTER TABLE文を使用して、次のタスクを実行します。

• SET AGING {ON|OFF}句を使用して、時間ベースのエージング・ポリシーが含まれている表のエージングの状態を有効または無効にします。

• SET AGING CYCLE句を使用して、時間ベースのエージング・ポリシーが含まれている表のエージング・サイクルを変更します。

• SET AGING LIFETIME句を使用して、存続期間を変更します。

• ADD AGING USE句を使用して、エージング・ポリシーが含まれていない既存の表に時間ベースのエージングを追加します。

• DROP AGING句を使用して、表のエージングを破棄します。

エージングの開始をスケジュールするには、ttAgingScheduleNow組込みプロシージャを使用します。詳細は、「エージング開始のスケジュール」を参照してください。

表のエージング・ポリシーを時間ベースのエージングからLRUエージングに変更するには、まず、表の時間ベースのエージングを破棄します。次に、ADD AGING LRU句とともにALTER TABLE文を使用して、LRUエージングを追加します。

エージングおよび外部キー

外部キーによって関連付けられている表には、同じエージング・ポリシーを設定する必要があります。

LRUエージングが有効になっている間に子表内の行にアクセスした場合は、親行または子行のいずれも削除されません。

時間ベースのエージングが有効になっている場合に親表内の行がエージング・アウトの候補になると、親行およびそのすべての子が削除されます。

表でON DELETE CASCADEが有効になっている場合、この設定は無視されます。

エージング開始のスケジュール

ttAgingScheduleNow組込みプロシージャを使用してエージング・プロセスをスケジュールします。エージング・プロセスは、すでに実行中のエージング・プロセスが存在しないかぎり、このプロシージャをコールするとすぐに開始されます。存在する場合は、そのエージング・プロセスが完了した後で開始されます。

ttAgingScheduleNowをコールすると、状態がONまたはOFFのいずれであるかに関係なく、エージング・プロセスが開始されます。

ttAgingScheduleNowをコールしてもエージングの状態は変わらないため、これをコールした結果としてエージング・プロセスは1回のみ開始されます。ttAgingScheduleNowのコール時にエージングの状態がOFFの場合、エージング・プロセスは開始されますが、プロセスの完了後、エージングは継続されません。エージングを継続するには、ttAgingScheduleNowを再度コールするか、またはエージングの状態をONに変更する必要があります。

エージングの状態がすでにONに設定されている場合は、ttAgingScheduleNowがコールされた時間に基づいて、ttAgingScheduleNowによってエージング・サイクルがリセットされます。

SET AGING OFF句とともにALTER TABLE文を使用してエージングを無効にすると、外部でエージングを制御できます。その後、ttAgingScheduleNowを使用して、目的の時間にエージングを開始します。

ttAgingScheduleNowを使用して、このプロシージャのコール時に個々の表の名前を指定することによって、表のエージングを開始またはリセットします。表名を指定しない場合は、ttAgingScheduleNowによって、エージングが定義されているデータベース内のすべての表のエージングが開始またはリセットされます。

エージングおよびレプリケーション

アクティブなスタンバイ・ペアの場合は、アクティブなマスター・データベースにエージングを実装します。エージングの結果として行われる削除は、スタンバイ・マスター・データベースおよび読取り専用サブスクライバにレプリケートされます。スタンバイ・マスター・データベースに対してフェイルオーバーが行われると、エージングは、ロールがACTIVEに変更された後でそのデータベースに対して有効になります。

他のすべてのタイプのレプリケーション・スキームの場合は、ノードごとに個別にエージングを実装します。エージング・ポリシーは、すべてのノードで同じである必要があります。

ホット・スタンバイとして使用されるマルチマスター・レプリケーション・スキームにLRUエージングを実装すると、LRUエージングで予期しない結果が発生する可能性があります。エージングがローカルで行われるため、フェイルオーバー後に必要なデータの一部が失われる場合があります。

ビューの理解

ビューとは、1つ以上の表に基づく論理表です。ビュー自体にはデータは含まれていません。マテリアライズド・ビュー（ディテール表の計算済データを実際に含む）と区別するために非マテリアライズド・ビューと呼ばれる場合もあります。ビューを直接更新することはできませんが、ディテール表のデータへの変更はビューに即時反映されます。

ビューまたはマテリアライズド・ビューのいずれを作成するかを決めるには、計算コストを検討します。マテリアライズド・ビューの場合は、マテリアライズド・ビュー内のデータに対して計算を行う必要があるため、ディテール表を更新するユーザーにコストがかかります。非マテリアライズド・ビューの場合、問合せ時に計算を行う必要があるため、ビューを問い合わせる接続にコストがかかります。

ビューの作成、破棄または管理を行う処理を実行するには、適切な権限を持っている必要があります。権限の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「SQL文」の章で、すべてのSQL文の構文とともに説明されています。

この項の内容は次のとおりです。

• ビューの作成

• ビューの破棄

• ビューおよびディテール表に対する制限

ビューの作成

ビューを作成するには、SQL文CREATE VIEWを使用します。SQL文の構文については、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「SQL文」の章を参照してください。

CREATE VIEW ViewName AS SelectQuery;

これによって、ビューで使用される列がディテール表から選択されます。

たとえば、表t1からビューを作成します。

CREATE VIEW v1 AS SELECT * FROM t1;

次に、表t1に対する集計問合せからビューを作成します。

CREATE VIEW v1 (max1) AS SELECT max(x1) FROM t1;

CREATE VIEW文でのSELECT問合せ

マテリアライズド・ビューの内容の定義に使用するSELECT問合せは、トップ・レベルのSQL SELECT文（『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「SQL文」の章を参照）に類似していますが、次の制限があります。

• ビュー定義内のSELECT *問合せは、ビュー作成時に拡張されます。ビューが作成された後に追加された列は、ビューに反映されません。

• ビューを作成するSELECT文で、次の句は使用できません。

• DISTINCT

• FIRST

• ORDER BY

• 引数

• 一時表

• SELECT構文のリストの各式には、一意の名前が必要です。列の別名が定義されていないかぎり、単純にその列の名前が使用されます。ROWIDは式とみなされるため、別名が必要です。

• SELECT FOR UPDATEまたはSELECT FOR INSERT文はビューに対しては使用できません。

• 特定のTimesTen問合せ制限は、非マテリアライズド・ビューの作成時に確認されません。これらの制限に違反しているビューの作成が可能な場合がありますが、その後、実行した文でこのビューが参照されると、エラーが戻されます。

ビューの破棄

DROP VIEW文で、指定したビューが破棄されます。

次の文では、CustOrderビューが破棄されます。

DROP VIEW CustOrder;

ビューおよびディテール表に対する制限

ビューには、次の制限があります。

• ビューが SELECT文のFROM句で参照されると、ビューの名前は、その定義によって解析時に導出表に置き換えられます。導出表がないと、ビューのすべての句を元のSELECT内の同じ句にマージして適切な問合せにすることができない場合は、この導出表の内容がマテリアライズ化されます。たとえば、ビューと参照しているSELECTの両方で集計が指定されている場合、ビューは、その結果がSELECTの他の表と結合される前にマテリアライズ化されます。

• ビューは、DROP TABLE文では破棄できません。DROP VIEW文を使用する必要があります。

• ビューは、ALTER TABLE文では変更できません。

• ビューの参照は、ディテール表の破棄または変更が原因で失敗する可能性があります。

マテリアライズド・ビューの理解

次の項では、マテリアライズド・ビューとその管理方法について説明します。

• マテリアライズド・ビューの概要

• マテリアライズド・ビューの処理

マテリアライズド・ビューの概要

マテリアライズド・ビューとは、1つ以上の通常のTimesTen表から選択したデータのサマリーを保持する読取り専用表です。マテリアライズド・ビューの結果セットを作成するために問い合される通常のTimesTen表は、ディテール表と呼ばれます。

注意: マテリアライズド・ビューは、キャッシュ・テーブルではサポートされません。

図7-1に、ディテール表から作成されたマテリアライズド・ビューを示します。アプリケーションで、ディテール表の更新およびマテリアライズド・ビューからのデータの選択を行うことができます。

図7-1 マテリアライズド・ビュー

「図7-1 マテリアライズド・ビュー」の説明

マテリアライズド・ビューは、マテリアライズド・ビューの結果セットの更新方法に基づいて、次の2つのタイプに分けられます。

• 同期マテリアライズド・ビュー

• 非同期マテリアライズド・ビュー

また、各タイプのマテリアライズド・ビューを使用する状況の詳細は、「同期マテリアライズド・ビューまたは非同期マテリアライズド・ビューを使用する状況」を参照してください。

同期マテリアライズド・ビュー

同期マテリアライズド・ビューでは、デフォルトで、ディテール表のトランザクション時に、ディテール表の結果セット・データが更新されます。ディテール表でデータが更新されるたびに、結果セットが更新されます。このため、同期マテリアライズド・ビューとディテール表が非同期になることはありません。ただし、パフォーマンスに影響を与える可能性があります。1つのトランザクション（ユーザー・トランザクション）で、ディテール表と同期マテリアライズド・ビューの両方の更新が実行されます。

非同期マテリアライズド・ビュー

このマテリアライズド・ビューは、作成時にデータが移入され、ディテール表との同期がとられます。ディテール表が更新されても、非同期マテリアライズド・ビューはすぐには更新されません。対応するディテール表と非同期になる可能性は常にあります。非同期マテリアライズド・ビューでは、パフォーマンスが優先されるため、結果セットの更新が延期されます。結果セットをリフレッシュするタイミングおよび方法、およびリフレッシュをユーザーが手動で行うか、または事前構成した間隔で自動で行うかは、ユーザーが決定します。非同期マテリアライズド・ビューは、ディテール表を更新するユーザー・トランザクションではリフレッシュされず、常に非同期マテリアライズド・ビュー自体のトランザクションでリフレッシュされます。このため、ユーザー・トランザクションが非同期マテリアライズド・ビューの更新でブロックされることはありません。

非同期リフレッシュには、次のいずれかのリフレッシュ方式を使用できます。

• FAST: 前回の更新以降の増分変更のみが更新されます。

• COMPLETE: 全体リフレッシュが実行されます。

FASTリフレッシュを使用するには、マテリアライズド・ビュー・ログを作成し、非同期マテリアライズド・ビューによって使用される各ディテール表について、遅延増分トランザクションを管理する必要があります。すべての遅延トランザクションを管理するために各ディテール表に必要なマテリアライズド・ビュー・ログは1つのみです。1つのディテール表が複数のFAST非同期マテリアライズド・ビューに含まれている場合でも1つのみです。

マテリアライズド・ビューまたはマテリアライズド・ビュー・ログが関連付けられているディテール表は、破棄できません。

注意: XLAを非同期マテリアライズド・ビューと組み合せて使用する場合は、DDL文の実行順序を保持できません。通常、表に対する変更を追跡するためのXLAメカニズムと、マテリアライズド・ビューに対する変更を追跡するXLAメカニズムとの間に、処理上の違いはありません。ただし、非同期マテリアライズド・ビューの場合、非同期ビューに関するXLA通知の順序が、関連付けられているディテール表に関する順序、または非同期ビューに関する順序と同じとはかぎらないことに注意してください。たとえば、ディテール表に対する挿入が2つある場合、非同期マテリアライズド・ビューでは、これらの2つが逆の順序で実行される可能性があります。また、更新が、削除してから挿入として処理されたり、複数の挿入や複数の削除など、複数の処理が組み合される可能性があります。処理の順序を保持する必要があるアプリケーションでは、非同期マテリアライズド・ビューを使用しないでください。

同期マテリアライズド・ビューまたは非同期マテリアライズド・ビューを使用する状況

次の項では、同期または非同期マテリアライズド・ビューを使用する状況のガイドラインについて説明します。

• 結合および集計関数によるスーパー・ロック

• マテリアライズド・ビューの最新度

• オーバーヘッド・コスト

結合および集計関数によるスーパー・ロック

同期マテリアライズド・ビューに結合があるか、または集計関数が使用されている場合、スーパー・ロックが生じます。たとえば、1000行から1つの平均を集計する同期マテリアライズド・ビューを持つ1つの表があるとします。同期マテリアライズド・ビューのディテール表のある行を更新すると、その行は、そのトランザクションが終わるまでロックされます。その行を更新しようとする他のトランザクションはすべてブロックされ、そのトランザクションがコミットされるまで待機します。

また、その表には同期マテリアライズド・ビューがあるため、このマテリアライズド・ビューも更新されます。このマテリアライズド・ビューに含まれる1つの行がロックされ、変更を反映するために更新されます。一方、元表には、マテリアライズド・ビューの同じ行に集計される行が他にも999あります。元表のその他の999行も、実質的にロックされます。これは、これらの行のいずれかを更新しようとするとブロックされ、マテリアライズド・ビューの行のロックが取得できるまで待機することになるためです。このような状態は、スーパー・ロックと呼ばれます。

同様の影響は結合の場合にも生じます。5つの表を結合する同期マテリアライズド・ビューがあり、その5つのいずれかの表の行を更新すると、更新対象の表に結合されているその他4つの表のすべての行に対してスーパー・ロックが発生します。

結合と集計関数を組み合せて使用した場合、同期マテリアライズド・ビューでの問題がさらに大きくなります。ただし、COMPLETEリフレッシュを使用する非同期マテリアライズド・ビューの場合、スーパー・ロックが発生する可能性が低くなります。その理由は、COMPLETEリフレッシュを使用する非同期マテリアライズド・ビュー行では、ロックが保持されるのはリフレッシュ・プロセス中のみであるためです。同期マテリアライズド・ビューのスーパー・ロックは、更新トランザクションがコミットされるまで保持されます。したがって、短時間のトランザクションの場合、同期マテリアライズド・ビューのスーパー・ロックは問題になりません。一方、長時間のトランザクションの場合は、COMPLETEリフレッシュを使用する非同期マテリアライズド・ビューを使用して、スーパー・ロックの影響を最小限に抑えます。

マテリアライズド・ビューの最新度

同期マテリアライズド・ビューは常に新しい状態に保持されており、最新のデータを戻します。非同期マテリアライズド・ビューの場合、前回の更新以降、次回のリフレッシュまで、データが最新ではなくなる可能性があります。常に最新のデータが必要な場合は、同期マテリアライズド・ビューを使用してください。アプリケーションで最新データが必要でない場合は、非同期の使用を検討できます。

たとえば、それぞれ異なる一連の分析問合せを実行するとします。この場合、非同期マテリアライズド・ビューを使用すると、問合せ間の違いによる差異と新規データまたは更新データによる差異を切り分けることができます。

オーバーヘッド・コスト

ユーザー・トランザクションではディテール表が更新されますが、非同期マテリアライズド・ビューは更新されません。非同期マテリアライズド・ビューのリフレッシュは、常に、独立したトランザクションとして実行されます。つまり、ユーザーは他のトランザクションを自由に実行できます。一方、同期マテリアライズド・ビューの場合は、1つのトランザクションがディテール表と任意の同期マテリアライズド・ビューの両方の更新を実行するため、パフォーマンスに影響を与えます。

FASTリフレッシュを使用する非同期マテリアライズド・ビューの非同期マテリアライズド・ビュー・ログにはオーバーヘッドが伴いますが、一般的に同期マテリアライズド・ビューの更新コストのオーバーヘッドより大きくありません。このことは、特に非同期マテリアライズド・ビューが結合によって複雑になっている場合に当てはまります。COMPLETEリフレッシュを使用する非同期マテリアライズド・ビューの場合、ディテール表の更新に伴うオーバーヘッドはありません。

非同期マテリアライズド・ビューのメンテナンス・コストは、遅延されることができます。非同期マテリアライズド・ビュー・ログのコストは、同期マテリアライズド・ビューの増分メンテナンスに比べてコストがかかりません。その理由は、非同期マテリアライズド・ビュー・ログでは単純な挿入が実行されるのに対して、同期マテリアライズド・ビューのメンテナンスではマテリアライズド・ビューと結合の差分を計算し、その結果を更新処理で適用する必要があるためです。更新は、挿入より高コストになります。同期マテリアライズド・ビューの構造が単純になると、このコストの差は縮まります。

マテリアライズド・ビューの処理

この項の内容は次のとおりです。

• マテリアライズド・ビューの作成

• マテリアライズド・ビューまたはマテリアライズド・ビュー・ログの破棄

• マテリアライズド・ビューおよびディテール表に対する制限

• マテリアライズド・ビューによるパフォーマンスへの影響

マテリアライズド・ビューの作成

マテリアライズド・ビューを作成するには、SQL文CREATE MATERIALIZED VIEWを使用します。

注意: マテリアライズド・ビューを作成するには、適切な権限を持っている必要があります。権限の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「SQL文」の章で、SQLの構文とともに説明されています。 所有者が、マテリアライズド・ビューが作成されるディテール表に対する権限を取り消すと、そのマテリアライズド・ビューは無効になります。詳細は、「マテリアライズド・ビューのオブジェクト権限」を参照してください。

マテリアライズド・ビューの作成時に、「主キー、外部キーおよび一意索引」の表の場合と同様の方法で、主キーおよびハッシュ表のサイズを指定できます。

マテリアライズド・ビューの例では、次の2つの表を使用します。

CREATE TABLE customer(custId int not null,
  custName char(100) not null,
  Addr char(100),
  Zip int,
  Region char(10),
  PRIMARY KEY (custId));

CREATE TABLE bookOrder(orderId int not null,
  custId int not null,
  book char(100),
  PRIMARY KEY (orderId),
  FOREIGN KEY (custId) REFERENCES Customer(custId));

次の項では、マテリアライズド・ビューの作成の詳細および例を示します。

• 同期マテリアライズド・ビューの作成

• 非同期マテリアライズド・ビューの作成

• CREATE MATERIALIZED VIEW文でのSELECT問合せ

同期マテリアライズド・ビューの作成

同期マテリアライズド・ビューは、ディテール表が更新されるたびに自動的に更新されます。同期マテリアライズド・ビューは、CREATE MATERIALIZED VIEW文を使用して作成できます。

次のように入力すると、SampleMVという同期マテリアライズド・ビューが作成されます。このマテリアライズド・ビューによって、前述のcustomerおよびbookOrderディテール表の選択した列から結果セットが生成されます。

CREATE MATERIALIZED VIEW SampleMV AS
 SELECT customer.custId, custName, orderId, book
 FROM customer, bookOrder
 WHERE customer.custId=bookOrder.custId;

非同期マテリアライズド・ビューの作成

非同期マテリアライズド・ビューは、そのマテリアライズド・ビューの作成時に構成したリフレッシュ方式およびリフレッシュ間隔に従って更新されます。

非同期マテリアライズド・ビューを作成する場合はREFRESH句を使用し、少なくとも次のいずれか1つを指定します。

• リフレッシュ方式: 非同期マテリアライズド・ビューの場合は、リフレッシュ方式としてFASTとCOMPLETEのいずれかを指定します。FASTは増分リフレッシュを示します。COMPLETEは全体リフレッシュを示します。省略した場合、リフレッシュ方式はデフォルトで完全になります。FASTを指定する場合は、マテリアライズド・ビューに関連付けられている各ディテール表に対して非同期マテリアライズド・ビュー・ログを作成する必要があります。

  
  

  注意: FASTリフレッシュでは、集計関数および外部結合はサポートされていません。

  
  

• リフレッシュ間隔:

  • 手動更新: リフレッシュ間隔が指定されていない場合は、デフォルトで手動更新になります。その場合は、REFRESH MATERIALIZED VIEW文を使用してビューを手動でリフレッシュできます。この文の詳細は、この項の最後を参照してください。

  • コミットのたびにリフレッシュを指定: NUMTODSINTERVL()を指定せずにNEXT SYSDATEを指定すると、ディテール表を更新するユーザー・トランザクションがコミットされるたびに、リフレッシュが実行されます。このリフレッシュは、常に、別個のトランザクションとして実行されます。ユーザー・トランザクションはリフレッシュの完了を待機しません。コミットのたびにリフレッシュするオプションは、高速リフレッシュ方式の場合にのみサポートされます。

  • 間隔の指定: NEXT SYSDATE + NUMTODSINTERVAL(IntegerLiteral,IntervalUnit)句を使用すると、指定した間隔で非同期マテリアライズド・ビューが更新されます。このオプションは、FASTとCOMPLETEの両方のリフレッシュ方式でサポートされます。

    この句は、指定した間隔でマテリアライズド・ビューがリフレッシュされることを指定します。IntegerLiteralは整数である必要があります。IntervalUnitは、'DAY'、'HOUR'、'MINUTE'、'SECOND'のいずれかの値である必要があります。

    次回のリフレッシュ時刻を決めるため、最後に行われたリフレッシュの時刻が保存されます。前回のリフレッシュ以降に、非同期マテリアライズド・ビューのディテール表のいずれにも変更がなかった場合、リフレッシュはスキップされます。構成済のリフレッシュ間隔を変更するには、非同期マテリアライズド・ビューを破棄して再作成する必要があります。

高速リフレッシュ方式を使用する場合、遅延されたトランザクションはマテリアライズド・ビュー・ログに保存されます。このため、非同期マテリアライズド・ビューを作成する前に、高速リフレッシュを使用する非同期マテリアライズド・ビューに含まれる各ディテール表に対して、マテリアライズド・ビュー・ログを作成する必要があります。ディテール表が、高速リフレッシュを使用する複数の非同期マテリアライズド・ビューによって使用される場合であっても、各ディテール表で持つことができるマテリアライズド・ビューは1つのみです。非同期マテリアライズド・ビューで参照されるすべての列は、対応する非同期マテリアライズド・ビュー・ログに含まれている必要があります。1つのディテール表に対して、高速リフレッシュの非同期マテリアライズド・ビューが2つ以上作成されている場合は、そのディテール表に対して作成された複数の非同期マテリアライズド・ビューで使用されるすべての列が、非同期マテリアライズド・ビュー・ログに含まれていることを確認してください。

次の例では、高速リフレッシュを使用する非同期マテリアライズド・ビューを作成します。このビューでは、作成後、1時間ごとに遅延トランザクションが更新されます。まず、ディテール表customerおよびbookOrderそれぞれにマテリアライズド・ビュー・ログを作成します。次の文は、customerとbookOrderに対して、FASTリフレッシュ用に遅延トランザクションを追跡するためのマテリアライズド・ビュー・ログを作成します。customerのマテリアライズド・ビュー・ログは、次のように主キーと顧客名を追跡します。

CREATE MATERIALIZED VIEW LOG ON customer WITH PRIMARY KEY (custName);

注意: CREATE MATERIALIZED VIEW LOG構文では、WITH PRIMARY KEYを指定した場合、またはPRIMARY KEYまたはROWIDのいずれも指定しなかった場合に、主キーが含められます。マテリアライズド・ビュー・ログに含める主キー以外の列は、すべてカッコ付きの列のリストで指定する必要があります。

bookorder表のマテリアライズド・ビュー・ログは、主キーのorderIdとcustId列およびbook列を追跡します。

CREATE MATERIALIZED VIEW LOG ON bookOrder WITH (custId, book);

ディテール表customerとbookOrderの両方にマテリアライズド・ビュー・ログを作成した後、非同期マテリアライズド・ビューを作成できます。非同期マテリアライズド・ビューには、すべてのディテール表についてROWIDと主キー列のいずれかを含める必要があります。

次の例では、customerおよびbookOrderディテール表の選択された列から結果セットを生成する、SampleAMVという非同期マテリアライズド・ビューを作成します。この文では、作成時点から1時間ごとに遅延トランザクションを更新するFASTリフレッシュを指定しています。

CREATE MATERIALIZED VIEW SampleAMV 
 REFRESH 
     FAST 
     NEXT SYSDATE + NUMTODSINTERVAL(1, 'HOUR')
 AS SELECT customer.custId, custName, orderId, book
 FROM customer, bookOrder
 WHERE customer.custId=bookOrder.custId;

マテリアライズド・ビューを手動でリフレッシュする場合は、REFRESH MATERIALIZED VIEW文を実行します。マテリアライズド・ビューは、REFRESH間隔が指定されていても、いつでも手動でリフレッシュできます。たとえば、ディテール表に複数の更新が発生した場合、次の文を使用してSampleAMVマテリアライズド・ビューを手動でリフレッシュできます。

REFRESH MATERIALIZED VIEW SampleAMV;

CREATE MATERIALIZED VIEW文でのSELECT問合せ

マテリアライズド・ビューの内容の定義に使用するSELECT問合せは、トップ・レベルのSQL SELECT文（『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「SQL文」の章を参照）に類似していますが、次の制限があります。

• GROUP BY GroupColumnList内のすべての列がSelectListに含まれている必要があります。

• SUMおよびCOUNTは使用できますが、これらを使用した式（AVGなど）は使用できません。

• マテリアライズド・ビューを作成するSELECT文で、次の句は使用できません。

  • DISTINCT

  • FIRST

  • HAVING

  • ORDER BY

  • UNION

  • UNION ALL

  • MINUS

  • INTERSECT

  • JOIN

  • ユーザー・ファンクション: USER、CURRENT_USERおよびSESSION_USER

  • 副問合せ

  • NEXTVALおよびCURRVAL

  • 導出表および結合表

• SelectListの各式には、一意の名前が必要です。列の別名が定義されていないかぎり、単純にその列の名前が使用されます。ROWIDは式とみなされるため、別名が必要です。

• 自己結合が可能です。自己結合とは、同じ表同士の結合のことです。この表は、FROM句で複数回使用します。結合条件で列名を修飾する表の別名をその後に続けます。

同期マテリアライズド・ビュー、または完全リフレッシュを使用する非同期マテリアライズド・ビューの場合、SELECT文に関して次の要件があります。

• グループを増分更新できるように、集計ビューのSelectListにCOUNT(*)が含まれている必要があります。たとえば、グループのカウントが0（ゼロ）になった場合は、そのグループを削除する必要があります。

• OUTER JOINは使用できますが、SELECTリストは、OUTER JOINに指定した各内部表に1つ以上のNULL値可能でない列を投影する必要があります。マテリアライズド・ビューの定義でのSELECTのOUTER JOIN構文は、トップ・レベルのSELECTの場合と同じです。SELECT文に対する制限が適用されます。マテリアライズド・ビューの外部結合を指定するには、(+)記号を使用する必要があります。

高速リフレッシュを使用する非同期マテリアライズド・ビューの場合、SELECT文に関して次の要件があります。

• 集計関数はサポートされません。

• 外部結合はサポートされません。

• SELECTリストには、含まれているすべてのディテール表のROWIDまたは主キー列が含まれている必要があります。

マテリアライズド・ビューまたはマテリアライズド・ビュー・ログの破棄

マテリアライズド・ビューを破棄するには、DROP VIEW文を実行します。

次の文では、マテリアライズド・ビューsampleMVが破棄されます。

DROP VIEW sampleMV;

表を参照している非同期マテリアライズド・ビューがない場合、その表のマテリアライズド・ビュー・ログを破棄できます。たとえば、マテリアライズド・ビューsampleAMVを破棄した場合、次の文を実行すると、関連付けられているマテリアライズド・ビュー・ログが破棄されます。

DROP MATERIALIZED VIEW LOG ON customer;
DROP MATERIALIZED VIEW LOG ON bookOrder;

SQL文の構文については、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「SQL文」の章を参照してください。

マテリアライズド・ビュー・ログに関連付けられている表の特定

マテリアライズド・ビュー・ログは、TimesTenのシステム表ではMVLOG$_detailTableIdという名前の表になります。detailTableIdは、作成された表の表IDです。表IDと表名は、どちらもSYS.TABLESに記録されます。たとえば、マテリアライズド・ビュー・ログのファイル名がMVLOG$_507244の場合、次のようにしてSYS.TABLESの表IDが507244の行から、表名を取得できます。

select tblname from sys.tables where tblid = 507244;
< T1 >
1 row found.

マテリアライズド・ビューおよびディテール表に対する制限

マテリアライズド・ビューは、読取り専用表であるため、直接には更新できません。つまり、レプリケーション、XLAまたはキャッシュ・エージェントによるINSERT文、DELETE文またはUPDATE文でマテリアライズド・ビューを更新することはできません。

たとえば、マテリアライズド・ビューの行を更新しようとすると、次のエラーが戻されます。

805: Update view table directly has not been implemented

マテリアライズド・ビューのその他の実装についてよく理解している読者にとっては一般的ですが、TimesTenのビューには、次の特性があります。

• ディテール表はレプリケートできますが、マテリアライズド・ビューはレプリケートできません。

• マテリアライズド・ビューおよびそのディテール表のいずれも、キャッシュ・グループの一部にはできません。

• また、マテリアライズド・ビューに対して参照索引は定義できません。

• マテリアライズド・ビューを破棄するには、DROP VIEW文を使用する必要があります。

• マテリアライズド・ビューを変更することはできません。DROP VIEW 文で破棄してから、CREATE MATERIALIZED VIEW文で新しいマテリアライズド・ビューを作成する必要があります。

• マテリアライズド・ビューは、アプリケーションで明示的に作成する必要があります。TimesTenの問合せオプティマイザに、マテリアライズド・ビューを自動的に作成する機能はありません。

• TimesTenの問合せオプティマイザが、ディテール表に対する問合せをリライトしてマテリアライズド・ビューを参照することはありません。マテリアライズド・ビューを使用する場合は、アプリケーションの問合せでビューを直接参照する必要があります。

• マテリアライズド・ビューの作成に使用するSQLにはいくつかの制限があります。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』のCREATE MATERIALIZED VIEWに関する説明を参照してください。

マテリアライズド・ビューによるパフォーマンスへの影響

次の項では、各タイプのマテリアライズド・ビューのパフォーマンスへの影響について説明します。

• 非同期マテリアライズド・ビューの場合のパフォーマンス管理

• 同期マテリアライズド・ビューの場合のパフォーマンス管理

非同期マテリアライズド・ビューの場合のパフォーマンス管理

パフォーマンス管理のために、マテリアライズド・ビューのリフレッシュを最適な時間まで遅延できます。マテリアライズド・ビュー・ログ、ディテール表およびマテリアライズド・ビューの行は、リフレッシュ中にロックされることがあります。ディテール表を更新するユーザー・トランザクションが、このロックによって妨げられる場合、ユーザーはリフレッシュ間隔を調整できます。パフォーマンスが最優先され、非同期マテリアライズド・ビューとディテール表の非同期化を容認できる場合は、システム負荷が低い時間にリフレッシュが実行されるようにリフレッシュ間隔を設定します。

• FASTリフレッシュでは、マテリアライズド・ビュー・ログに取得された変更内容に基づいて、マテリアライズド・ビューが増分更新されます。このリフレッシュにかかる時間は、マテリアライズド・ビュー・ログに取得された変更の数およびCREATE MATERIALIZED VIEW文で使用されているSELECT文の複雑さによって異なります。リフレッシュが実行されるたびに、マテリアライズド・ビュー・ログの処理済の行は削除されます。

  リフレッシュのパフォーマンスを向上させるため、ディテール表、マテリアライズド・ビュー・ログ表およびマテリアライズド・ビューの表統計を定期的に更新してください。ビューに結合が含まれている場合は、いずれかのディテール表に行を挿入する前に表統計を更新します。表統計は、ttOptEstimateStats組込みプロシージャを使用して更新できます。

• 完全リフレッシュは、作成時のマテリアライズド・ビューの初期ロードに似ています。このリフレッシュにかかる時間は、ディテール表の行数によって異なります。

同期マテリアライズド・ビューの場合のパフォーマンス管理

UPDATEおよびINSERTで更新処理を行う場合、更新する表をマテリアライズド・ビューで参照していると、パフォーマンスに影響することがあります。パフォーマンスへの影響は、次のような多数の要因に応じて異なります。

• マテリアライズド・ビューの性質: ディテール表の数、外部結合または集計の使用の有無。

• ディテール表およびマテリアライズド・ビューに存在する索引のタイプ。

• 変更の影響を受けるマテリアライズド・ビュー行の数。

ビューは、問合せ結果の最新の永続コピーです。ビューを最新の状態に維持するには、ビューのディテール表の変更時に、TimesTenでビュー・メンテナンスを実行する必要があります。たとえば、表T1、T2およびT3から選択するVというビューがある場合、T1への挿入、T2への更新、T3からの削除などを実行すると常に、TimesTenでビュー・メンテナンスが実行されます。

ビュー・メンテナンスの実行には、通常のデータベース処理と同様に適切な索引が必要です。索引がない場合、ビュー・メンテナンスのパフォーマンスは低くなります。

ディテール表に対する更新文、挿入文、削除文のすべての処理には実行計画が存在します（「TimesTen問合せオプティマイザ」を参照）。たとえば、T1の行を更新する場合、実行計画の第1段階でビューVを更新した後、第2段階でT1を更新します。

ビュー・メンテナンスを高速に行うには、次の手順を実行して、ディテール表を更新するすべての処理の計画を評価する必要があります。

1. ディテール表に対して頻繁に実行される更新文や削除文でのすべてのWHERE句を調べます。索引キーを使用する句に注目してください。たとえば、次の処理が、アプリケーションの処理時間の95%を占めているとします。

   UPDATE T1 set A=A+1 WHERE K1=? AND K2=?
   DELETE FROMT2 WHERE K3=?
   

   この場合、注目するキーは（K1、K2）およびK3です。

2. ビューでこれらのすべてのキー列が選択されていることを確認します。この例では、K1、K2およびK3がビューで選択されている必要があります。

3. これらの各キーに対して、ビューの索引を作成します。この例では、（V.K1、V.K2）に対する索引およびV.K3に対する索引の2つの索引がビューに必要です。これらの索引が一意である必要はありません。この例では、ビューの列の名前は表の列の名前と同じですが、別の名前を指定することもできます。

この方法では、ディテール表を更新すると、対応するビューの更新にWHERE句が使用されます。これによって、メンテナンスは1つのバッチで行われ、パフォーマンスが向上します。

ただし、前述の方法を使用できない場合があります。たとえば、アプリケーションにディテール表を更新するメソッドが多数存在することがあります。その場合、アプリケーションがビューで非常に多数の項目を選択したり、ビューに対して非常に多数の索引を作成することになり、予想以上の領域と処理能力が使用される可能性があります。次に示す別の方法を行います。

1. ビューのFROM句に指定されている各表（ディテール表）で、UPDATE文、INSERT文およびCREATE VIEW文によって頻繁に変更されている表を確認します。たとえば、ビューのFROM句に表T1、T2、T3、T4およびT5があり、その中でT2とT3のみが頻繁に変更されているとします。

2. ビューでこれらの表のrowidが選択されることを確認してください。この例では、T2.rowidとT3.rowidがビューで選択されている必要があります。

3. これらの各rowid列に対してビューの索引を作成します。この例では、列の名前はT2rowidおよびT3rowidで、索引はV.T2rowidおよびV.T3rowidに対して作成されます。

この方法では、バッチ単位ではなく、行単位でビュー・メンテナンスが行われます。ただし、ビューとそのディテール表の間で行が非常に効率的に照合されるため、メンテナンスが高速になります。通常、最初の方法ほど高速ではありませんが、有効な方法です。

索引の理解

索引は、表の検索のパフォーマンスを大幅に向上させる補助的なデータ構造です。問合せオプティマイザで問合せの実行を高速化するために使用されます。問合せオプティマイザの詳細は、「TimesTen問合せオプティマイザ」を参照してください。

索引は、一意なものとして指定できます。つまり、表の各行で、索引を設定した列に一意の値を指定できます。一意索引は、NULL値可能の列に対しても作成できます。SQL標準に従って、複数のNULL値を一意索引に指定できます。

TimesTenでは、データ値をソートする場合、NULL値はNULL以外のすべての値より大きい値とみなされます。NULL値の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』を参照してください。

索引の作成、破棄または変更を行う処理を実行するには、適切な権限を持っている必要があります。権限の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「SQL文」の章で、すべてのSQL文の構文とともに説明されています。

次の項では、索引の管理方法について説明します。

• 索引タイプの概要

• 索引の作成

• 索引の変更

• 索引の破棄

• 索引サイズの見積り

索引タイプの概要

TimesTenでは、表への高速アクセスが可能になる次の3つのタイプの索引があります。

• ハッシュ索引: ハッシュ索引は、1つ以上の列で完全一致する行を検索する場合に有効です。ハッシュ索引は、一致検索を実行する場合に有効です。現在、TimesTenでは、1つの表に対して1つのみのハッシュ索引がサポートされています。ハッシュ索引は、UNIQUE HASHオプションを使用して作成します。このオプションは、表の主キーを構成する列に対して指定します。

  ハッシュ索引の自動作成の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』のCREATE TABLEに関する説明の項を参照してください。表の作成時にハッシュ索引を作成する方法の例については、例7-2を参照してください。

• 範囲索引: 範囲索引は、特定の範囲内の列値を持つ行を検索する場合に有効です。範囲索引は、表の1つ以上の列に対して作成できます。1つの表につき最大32の範囲索引を作成できます。

  範囲索引と等価結合は一致検索および範囲検索（以上、以下など）で使用できます。あるフィールドに主キーを設定してFIELD > 10かどうかを確認する場合、主キー索引では検索が効率的に行われません。この場合は、別の索引の方が効率的です。

  範囲索引の作成方法の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』のCREATE INDEXに関する説明の項を参照してください。

  
  

  注意: 完全一致検索の場合、ハッシュ索引は範囲索引よりも高速になりますが、範囲索引より多くの領域が必要となります。範囲指定の検索の場合、ハッシュ索引は使用できません。

  
  

• ビットマップ索引: ビットマップ索引は、カーディナリティの低い列のデータを検索および取得する場合に有効です。つまり、これらの列は、使用可能な数個の一意の値のみを持つことができます。ビットマップ索引では、ある行の一意の値に関する情報がビットマップにエンコードされます。ビットマップの各ビットは、表の行に対応しています。ビットマップ索引は、一意の値があまり多くない列に対して使用します。このような列には、性別として2つの値のうちの1つを記録する列などが該当します。

  ビットマップ索引を使用すると、ANDおよびOR演算子で連結した複数の条件を複数の列に対して指定する、複雑な問合せのパフォーマンスが向上します。

  ビットマップ索引の作成方法などの詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』のCREATE INDEXに関する説明を参照してください。

注意: または、データに高速にアクセスするために、ROWIDによる検索を実行することもできます。ROWIDの詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』を参照してください。

索引の作成

索引を作成するには、SQL文CREATE INDEXを実行します。TimesTenでは、索引名は大文字に変換されます。

索引には所有者が存在します。索引の所有者は、基礎となる表を作成したユーザーです。TimesTenによって作成される索引（システム表の索引など）のユーザー名はSYSですが、レプリケーション時に作成される場合はTTREPになります。

例7-4 索引の作成

表NameIDの列CustIDに対して索引IxIDを作成します。

CREATE INDEX IxID ON NameID (CustID);

CREATE TABLEにUNIQUE HASH ON句を使用するか、主キーを作成して、ハッシュ索引を作成することもできます。ただし、TimesTenでは、問合せの実行を高速化する問合せの処理中に一時ハッシュ索引または一時範囲索引が自動的に作成されます。

索引の変更

ALTER TABLE文のUSE HASH INDEXを使用して、範囲索引をハッシュ索引に変更できます。

索引の破棄

索引を一意に参照するには、アプリケーションで所有者および名前の両方を指定する必要があります。アプリケーションで所有者を指定しなかった場合、TimesTenは、コール元のユーザー名の下にある索引を検索し、次にユーザー名SYSの下にある索引を検索します。

例7-5 索引の破棄

次の例では、IxIDという索引を破棄します。

DROP INDEX IxID;

TimesTen索引を破棄するには、SQL文DROP INDEXを実行します。表を破棄すると、その表のすべての索引が自動的に破棄されます。

索引サイズの見積り

TimesTenデータベースのサイズの増加は、最初の接続時に行うことができます。データベースのサイズを変更する必要をなくすには、データベースの最終的なサイズを少なく見積もらないようにする必要があります。データベースのサイズの見積りには、ユーティリティttSizeを使用します。

行の理解

行は、TimesTenデータを保存するために使用されます。TimesTenでは、行内のフィールドに対して次に示すいくつかのデータ型がサポートされています。

• 1バイト、2バイト、4バイト、8バイトの整数

• 4バイトおよび8バイトの浮動小数点数

• ASCIIおよびUnicodeの固定長または可変長の文字列

• 固定長および可変長のバイナリ・データ

• 固定長の固定小数点数

• hh:mm:ss [AM|am|PM|pm]で表現した時間

• yyyy-mm-ddで表現した日付

• yyyy-mm-dd hh:mm:ssで表現したタイムスタンプ

これらのデータ型の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』のデータ型に関する項を参照してください。

行の挿入または削除を行う処理を実行するには、適切な権限を持っている必要があります。権限の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「SQL文」の章で、すべてのSQL文の構文とともに説明されています。

次の項では、行の管理方法について説明します。

• 行の挿入

• 行の削除

行の挿入

行を挿入するには、INSERTまたはINSERT SELECTを実行します。また、ttBulkCpユーティリティ使用することもできます。

例7-6 行の表への挿入

表NameIDに行を挿入するには、次の文を入力します。

INSERT INTO NameID VALUES(23125, 'John Smith';

注意: 表に複数の行を挿入する場合は、コードに準備済のコマンドおよびパラメータを使用するとより効率的です。バルク・ロードの終了後、索引を作成してください。

行の削除

行を削除するには、DELETE文を実行します。

例7-7 行の削除

次の例では、名前が文字「S」で始まるすべての行を表NameIDから削除します。

DELETE FROM NameID WHERE CustName LIKE 'S%';

シノニムの理解

シノニムとは、データベース・オブジェクトの別名のことです。シノニムは、オブジェクトの名前や所有者を隠すために使用できるため、セキュリティや利便性を目的として頻繁に使用されます。また、シノニムでSQL文を簡略化できます。シノニムによって独立性が実現するため、シノニムがどのオブジェクトを参照するかにかかわらず、変更なしでアプリケーションの動作が可能になります。シノニムはDML文の他、一部のDDLやIMDBキャッシュ文で使用できます。

シノニムは、次の2つのクラスに分類されます。

• プライベート・シノニム: プライベート・シノニムは、特定のユーザーが所有し、特定のユーザーのスキーマ内に存在します。プライベート・シノニムは、表名、ビュー名、順序名など他のオブジェクト名すべてと同じネームスペースを共有します。したがって、プライベート・シノニムの名前は、同じスキーマ内の表名やビュー名と同じにすることはできません。

• パブリック・シノニム: パブリック・シノニムは、すべてのユーザーが所有され、データベースの各ユーザーからアクセスできます。パブリック・シノニムには、すべてのユーザーがアクセスでき、どのユーザー・スキーマにも属しません。したがって、パブリック・シノニムの名前は、プライベート・シノニム名や表名と同じにすることができます。

シノニムを作成して使用するには、適切な権限を持っている必要があります。権限の詳細は、「シノニムのオブジェクト権限」を参照してください。

シノニムを作成した後は、次のビューを使用して表示できます。

• SYS.ALL_SYNONYMS: 現行のユーザーがアクセスできるシノニムを表示します。

• SYS.DBA_SYNONYMS: データベース内のすべてのシノニムを表示します。

• SYS.USER_SYNONYMS: 現行のユーザーが所有しているシノニムを表示します。

これらのビューの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』を参照してください。

シノニムの作成

シノニムは、CREATE SYNONYM文を使用して作成します。既存のシノニム廃棄せずに定義を変更するには、CREATE OR REPLACE SYNONYM文を使用します。CREATE SYNONYMおよびCREATE OR REPLACE SYNONYM文では、シノニム名およびシノニムが作成されるスキーマ名を指定します。スキーマを省略すると、シノニムはユーザーのスキーマに作成されます。ただし、パブリック・シノニムを作成する場合、スキーマ名はPUBLICネームスペースで定義されるため、指定しません。

CREATE SYNONYMまたはCREATE OR REPLACE SYNONYM文を実行するには、適切な権限を持っている必要があります（「シノニムのオブジェクト権限」を参照）。

• シノニムのオブジェクト・タイプ: CREATE SYNONYMおよびCREATE OR REPLACE SYNONYM文では、特定のオブジェクトの別名を定義します。オブジェクト・タイプは、表、ビュー、シノニム、順序、PL/SQLストアド・プロシージャ、PL/SQL関数、PL/SQLパッケージ、マテリアライズド・ビューまたはキャッシュ・グループのいずれかです。

  
  

  注意: サポートされていないオブジェクト・タイプのシノニムを作成しても、そのシノニムは使用できない可能性があります。

  
  

• ネーミングについての考慮事項: プライベート・シノニムは、表名など他のすべてのオブジェクト名と同じネームスペースを共有します。したがって、プライベート・シノニムの名前は、同じスキーマ内の表名や他のオブジェクト名と同じにすることはできません。

  パブリック・シノニムには、すべてのユーザーがアクセスでき、特定のスキーマには属しません。したがって、パブリック・シノニムの名前は、プライベート・シノニム名や他のオブジェクト名と同じにすることができます。ただし、SYSスキーマのオブジェクトと同じ名前を持つパブリック・シノニムは作成できません。

次の例では、jobs表に対するプライベート・シノニムsynjobsを作成します。jobs表とsynjobsシノニムの両方にSELECT文を実行して、synjobsから選択することとjobs表から選択することが同じ結果になることを示します。最後に、作成したプライベート・シノニムを表示するため、例ではSYS.USER_SYNONYMS表に対してSELECT文を実行しています。

Command> CREATE SYNONYM synjobs FOR jobs;
Synonym created.

Command> SELECT FIRST 2 * FROM jobs;
< AC_ACCOUNT, Public Accountant, 4200, 9000 >
< AC_MGR, Accounting Manager, 8200, 16000 >
2 rows found.
Command> SELECT FIRST 2 * FROM synjobs;
< AC_ACCOUNT, Public Accountant, 4200, 9000 >
< AC_MGR, Accounting Manager, 8200, 16000 >
2 rows found.

Command> SELECT * FROM sys.user_synonyms;
< SYNJOBS, TTUSER, JOBS, <NULL> >
1 row found.

シノニムの作成および置換の詳細、例および規則については、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』のCREATE SYNONYMに関する説明を参照してください。

シノニムの削除

DROP SYNONYM文を使用して、データベースから既存のシノニムを削除します。ユーザーが所有するすべてのオブジェクト（シノニムを含む）を削除しないかぎり、そのユーザーを削除することはできません。

次の例では、パブリック・シノニムpubempを削除しています。

DROP PUBLIC SYNONYM pubemp;
Synonym dropped.

パブリック・シノニム、または他のユーザー・スキーマ内のプライベート・シノニムを削除するには、適切な権限が必要です。シノニムの作成および置換の詳細、例および規則については、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』のDROP SYNONYMに関する説明の項を参照してください。

シノニムが原因のSQL問合せの無効化または再コンパイル

シノニムまたはオブジェクトが新規作成または削除されると、一部のSQL問合せやDDL文の中が無効化されたり、再コンパイルされる場合があります。SQL問合せおよびDDL文の無効化や再コンパイルの動作を次に示します。

1. パブリック・シノニムに依存するすべてのSQL問合せは、次のいずれかのオブジェクトと同じ名前のプライベート・シノニムが作成されると無効化されます。

   • プライベート・シノニム

   • 表

   • ビュー

   • 順序

   • マテリアライズド・ビュー

   • キャッシュ・グループ

   • プロシージャ、関数、パッケージを含むPL/SQLオブジェクト

2. プライベート・オブジェクトまたはスキーマ・オブジェクトに依存するすべてのSQL問合せは、プライベート・オブジェクトまたはスキーマ・オブジェクトが削除されると無効化されます。