テナント

テナントとは、データベース内のユーザー定義オブジェクトに対して、一意の独立した名前空間を作成するデータベース・オブジェクトです。 複数のスキーマを含む追加のデータベース・オブジェクトは、他のデータベース・テナント内の類似オブジェクトとの名前の衝突を心配することなく、テナント内で定義することができます。

テナントで定義されたオブジェクトに関連する特権は、すべてそのテナント内に存在し、管理される。 さらに、テナントへのアクセスは、新しいテナントUSAGE権限によって明示的に制御され、別のレベルの制御が可能になる。

図1： Db2データベースのテナントによる名前空間の分離
利点

データベース・テナントのコンセプトを使用すれば、複数の独立したユーザー（またはアプリケーション）が同じデータベースを使用することができ、各ユーザーが使用するオブジェクト名の衝突や、オブジェクト内のデータへの不注意なアクセスを心配する必要はありません。 分離された名前空間機能は、いくつかの方法で活用できる：

  • 小規模なシングルユーザー用テストデータベースを、複数のテナントが利用する1つの共有データベースに統合することで、固定間接費を削減し、運用を簡素化。
  • 単一の共有データベース環境内で、同じアプリケーションの複数の独立したデプロイメントをインスタンス化すること。
  • 本番環境でよく見られるような独自のハードウェア構成を共有することで、本番環境に移行する前に、汚染や本番データへの不用意なアクセスのリスクなしに、アプリケーションアップデートの高度なテストを行うことができます。
  • アプリケーションやオブジェクト名を変更する必要がなく、既存のマルチテナント実装を持つ他のデータベースからの移行が容易。
制限

メリットは大きいが、データベースにテナントを導入する前に、以下の制限を考慮する必要がある：

  • クエリを実行する際には、誤って間違ったスキーマをクエリしないように、スキーマ接頭辞を含める必要があります。
  • リソースの分離がないため、テナントは同じ処理能力とストレージを共有する。 リソース共有では、すべてのテナントが同じカタログ・テーブル・スペースを共有し、データ分離はデフォルト設定ではないため、テナントはテーブルとインデックスで同じテーブル・スペースを共有できます。 また、バッファプールとCPUサイクルは、すべてのテナントで完全に共有される。
  • スキーマ接頭辞の必要性はこのリリースでも変わりません。 名前空間接頭辞は、SYSTEMテナントのテーブル、またはSYSTEMテナントと現在のテナントの両方で同じ名前のスキーマとテーブルを含める場合に必要です。
  • ユーザー定義のテナントは300件までというハードリミットがあります。
  • Datalakeテーブル名は Db2® ローカルテーブル名とは異なり、テナント内だけでなく、すべてのテナントで一意である必要があります。 詳細は Db2 Warehouseにおける Datalake テーブルの使用 」を参照してください。

SYSTEM テナント

データベースが作成されると、そのデータベースのために SYSTEM という名前のデフォルト・テナントが定義され、これは、デフォルト・データベース・カタログおよび環境に相当します。 SYSTEMテナントは永続的であり、テナント定義カタログには表示されません：SYSTEMテナントはSYSCAT.TENANTSビューに表示されません。 SYSTEM テナントには 0 (ゼロ) の固有のテナント ID が割り当てられます。 ユーザが初めてデータベースに接続すると、そのユーザの接続は自動的にデフォルトのSYSTEMテナントに関連付けられます。

ユーザ定義テナントとは異なり、SYSTEMテナントにはUSAGE権限が必要なく、データベース上のどの接続もSYSTEMテナントに関連付けることができます。

データベースのリソースと制限

ドキュメントに特に記載がない限り、他のすべてのデータベース・ファイルと出力もデータベース・リソースとみなされ、すべてのユーザー定義分離ネームスペースで共有されます。 例えば、診断ログ、トランザクション・ログ、履歴ファイルはデータベース・リソースとみなされ、データベース内のすべてのユーザー定義分離ネームスペースの情報が含まれています。 これらのリソースにアクセスするコマンドやツールは、デフォルトでこれらのネームスペースすべての情報を返す。
データベース・レベルで共有リソースに適用されるデータベースとSQLの制限は、すべてのユーザー定義分離ネームスペースに引き続き適用されます。 名前空間ごとに適用されるわけではない。

共有およびプライベート・システム・カタログ

テナントが定義されると、そのテナントには、データベースとその中で定義されたオブジェクトに関する情報を格納する一意のシステム・カタログ・テーブルのセットが与えられます。 これらのオブジェクトの中には、すべてのテナントがデータベース全体で使用するグローバルオブジェクトとみなされるものもある。 その他は、ローカルなオブジェクトとみなされ、そのオブジェクトが定義されている個々のテナントだけが知っている。 システムカタログテーブルの構成は、共有システムカタログテーブルとプライベートシステムカタログテーブルの概念を導入することで、オブジェクト定義のこの分割を反映している。

すべてのテナントが利用可能な、グローバルに知られているデータベース・リソースとみなされるオブジェクトのセットは、すべてのテナントが使用する共有カタログ・テーブルのセットに格納されます。 これらのオブジェクトには次のものがあります。

  • 監査オブジェクトとポリシー
  • バッファー・プール
  • グループ
  • ロール
  • ストレージの定義
  • 表スペース
  • テナント
  • Users
  • WLMオブジェクト

これらのオブジェクトの定義は、すべてのテナントが共有するシステム・カタログ・テーブルに格納される。 これらのカタログ・テーブルで定義されたオブジェクトは、（ユーザーがこれらのカタログにアクセスするために必要な権限を持っている限り）すべてのテナントのユーザーに表示され、これらのリソースに対するすべてのアクションと参照は、同じ定義セットに対して動作します。 これらのカタログは共有カタログ・テーブルと呼ばれる。

特定のテナント内でのみ利用可能なオブジェクトには、以下のようなものがある：

  • 別名
  • 制約
  • Data types
  • 索引
  • モジュール
  • パッケージ
  • ルーチン
  • スキーマ
  • シーケンス
  • 表
  • トリガー
  • 変数

これらのオブジェクトの定義は、個々のテナントごとに固有のシステム・カタログ・テーブルに保持され、他のテナントが使用することはない。 これらのカタログ・テーブルはプライベート・カタログ・テーブルと呼ばれる。

グローバル・データベース・オブジェクト

システムカタログで定義され、すべてのテナントが利用できるオブジェクトは、グローバルオブジェクトと呼ばれます。 共有カタログ・テーブルで定義されたすべてのオブジェクトは、すべてのテナントが見ることができ、利用可能であるため、事実上のグローバル・オブジェクトである。

グローバルオブジェクトのもう一つのセットは、データベースが作成された際に Db2 によって定義されたデータベースオブジェクトのセットによって表されます。 これらのオブジェクトは、データベース作成時にシステム・カタログで定義されたさまざまなルーチン、ビュー、モジュールなどである。 これらのオブジェクトの定義は、デフォルトのSYSTEMテナントのプライベート・システム・カタログにあるが、これらはDb2の一般的な体験と機能の基本である。

グローバル・データベース・オブジェクトの集合は、以下の集合として定義される：

  • SYSTEMテナントの予約済みスキーマで定義されている、パッケージを含むすべてのデータベース・オブジェクト。
  • NULLIDスキーマのSYSTEMテナントで、予約パッケージ名を使用して定義されるパッケージ。

予約済みスキーマの詳細については、予約済みスキーマ名と予約語を参照してください。 予約パッケージの詳細については、トピック「識別子」の「予約パッケージ名」を参照のこと。

すべてのテナント・ユーザーが同じエクスペリエンスを得られるように、Db2は Db2によって作成されたオブジェクトを暗黙のグローバル・オブジェクトとして扱い、すべてのテナントで利用できるようにする。 SYSTEMテナント以外の各テナントのカタログ・テーブルには明示的に存在しませんが、SQLコンパイラやその他の処理でオブジェクトを解決する際に、これらのオブジェクトが自動的に含まれます。 そのため、すべてのテナントが平等に利用できる。

例えば、"SELECT * FROMSYSCAT.TABLES"ステートメントがコンパイルされると、カタログ・ビューは現在のテナントのプライベート・カタログ・テーブルに解決されます。 同じステートメントをSYSTEMテナントでコンパイルすると、SYSTEMテナントに格納されているデータベース全体のカタログ・テーブルに解決されます。

プライベート・カタログ・テーブルを表すビューのSYSCATビュー定義も、この一貫した操作性を維持するために修正されました。 各テナントで定義されているローカル・オブジェクトに加えて、影響を受けるビューは、クエリ時にこれらの暗黙のグローバル・オブジェクトも返します。 オブジェクトを識別するために、オブジェクトが定義されているテナントの名前が、ビュー出力のTENANTNAME列として表示されます。 暗黙のグローバル・オブジェクトはSYSTEMテナント名を返し、すべてのローカル・オブジェクトは現在のテナント名を返します。

テナント内の名前解決

オブジェクトがテナントで参照されると、通常の名前解決プロセスが実行され、必要に応じてテナントに関連するシステム・カタログ・テーブルにアクセスして参照を解決します。 テナントがSYSTEMテナントではなく、オブジェクトスキーマがDb2によって予約されたスキーマの1つである場合、Db2は暗黙的にSYSTEMテナントのカタログテーブルにアクセスし、Db2によって提供されたオブジェクトセットから一致するオブジェクト定義を探します。

テナント内のモニタリング

管理ルーチン（および依存するビュー）の動作は、2つの異なるクラスに分けられる：

  • 個々のデータ・オブジェクトに関する情報をレポートするルーチンは、その出力を現在のテナントに存在するオブジェクトのみに制限します。
  • その他のインターフェースは、データベース全体の全テナントの出力を返す。.

現時点では、イベント・モニターはSYSTEMテナントでのみ定義されていますが、これらのイベント・モニターは、各イベントのソースを識別するための適切なテナント情報を持つすべてのテナントからのイベントをキャプチャします。

テナント統合とデータベース・セキュリティ

テナントは、認証、監査、暗号化の分野で、Db2データベースが提供する基礎的なセキュリティインフラストラクチャに依存している。

Db2の認証IDは、プライマリ（ユーザー）とセカンダリ（グループ、ロール）の両方が、データベース（およびインスタンス）レベルで検証・管理される。 ロールはデフォルトのSYSTEMカタログでのみ定義され、ロール定義カタログ・テーブルの内容はすべてのテナントで共有されます。 信頼されたコンテキストの定義も同様に扱われる。

監査ポリシーとアクションはデータベース・レベルでのみ定義でき、デフォルトのSYSTEMカタログにのみ存在します。 監査はデータベース活動であり、テナント全体のすべての活動を包含する。 監査ポリシーを特定のテナントにスコープすることも、プライベート・テナント・カタログで定義されたオブジェクトに監査ポリシーを定義することもできません。

トランスポート・レイヤー・セキュリティ（TLS）とネイティブ暗号化の両方の暗号化は、データベース・レベルで定義され、実行される。 テナントレベルの設定オプションはない。

LBACコンポーネントおよびポリシー・テーブルは、SYSTEMレベルで定義され、すべてのテナントで共有される。 RCACの定義はプライベート・カタログにあり、各テナントに固有である。

ユーザー定義の隔離された名前空間内での認可

ユーザー定義の分離された名前空間内の権限は、さまざまなレベルでユーザーが利用できる権限と特権の組み合わせによって決定される。

許可レベル 説明
データベース すべてのユーザ定義孤立ネームスペースにわたるすべてのオブジェクトに適用される。
テナント 特定のユーザー定義孤立名前空間で定義されたオブジェクトにのみ適用される
スキーマ 特定のスキーマで定義されたオブジェクトに適用される
Object 特定のオブジェクトにのみ適用される。

データベース・レベルまたは分離ネームスペース・レベルで付与された権限または特権は、SYSTEMテナントのカタログ・テーブルに記録されます。 スキーマまたはオブジェクト・レベルで付与された権限または特権は、そのスキーマまたはオブジェクトが定義されているユーザ定義の分離ネームスペースのシステム・カタログ・テーブルに記録される。

別の分離ネームスペースにあるオブジェクトにアクセスする場合、そのアクセスに対する認可は、アクセスが試みられたネームスペースではなく、オブジェクトが定義されている分離ネームスペースの認可情報を使用してチェックされます。

例えば、ユーザ定義の孤立名前空間TENANTA内のクエリが、その孤立名前空間内のユーザ定義テーブル'MYSCHEMA.T1と、SYSTEMテナントで定義された'Db2提供'SYSPROC.MON_GET_CONNECTIONテーブル関数の両方を参照する場合、これらのオブジェクトの権限チェックはこの方法で解決されます：
MYSCHEMA.T1
このテーブルにアクセスする際の権限チェックは、関連するデータベース権限と、TENANTA 隔離ネームスペース内の関連する権限カタログを使用することで解決されます。 この関数にアクセスするために必要なテーブル権限は、テナンタの分離ネームスペース内で付与する必要があります。
SYSPROC.MON_GET_CONNECTION

Db2テーブル機能を実行するための権限チェックは、関連するデータベース権限と、SYSTEMテナント内の関連する権限カタログを使用することで解決される。 この機能にアクセスするために必要なテーブル権限は、SYSTEMテナント内で付与される必要があります

ワークロード管理

名前空間による分離の中で実行されるすべての作業は、名前空間による分離なしに、システムに設定された通常のデータベース作業負荷管理に参加する。 名前空間に対して異なるワークロード構成が必要な場合、ワークロードオブジェクトの TENANT 接続属性を使用して、特定の名前空間に関連する接続を別のワークロードオブジェクトに分離することができ、希望するワークロード構成をそのワークロードオブジェクトまたはワークロードが関連するサービスクラスに適用することができる。

ユーザー定義の孤立ネームスペース内でのSQL動作

SQL 文の性質によって、Db2ユーザー定義孤立名前空間内での動作が決まります。
動的 SQL ステートメント
各孤立ネームスペースはそれに関連付けられた独自のカタログ・テーブル・セットを持つため、孤立ネームスペース内で準備された動的 SQL も一意であり、したがって異なるユーザ定義の孤立ネームスペース間で共有することはできず、同じ孤立ネームスペースに関連付けられた接続内でのみ共有できます。 動的SQL文は、エントリが共有されないように、パッケージ・キャッシュに配置されるときにテナントIDで修飾されます。 この動作の結果の1つは、異なるテナント・オブジェクトが同じ動的SQL文を実行していても、パッケージ・キャッシュにそれぞれ独自のエントリが必要になることです。
静的 SQL ステートメント
静的 SQL 文とその親パッケージは、各孤立ネームスペースに関連付けられたシステム・カタログにロー カル・オブジェクトとして格納されます。 Db2 によってグローバルオブジェクトとして登録されたパッケージは別として、 孤立した名前空間間でパッケージを共有することはできない。
インクリメンタル バインド ステートメント
インクリメンタル・バインド文であるスタティックSQL文は、実行時に参照が解決される。 これらのステートメントは、それを参照する各孤立ネームスペース内で、その孤立ネームスペースに関連するカタログを使用して一意に解決される。 これは、インクリメンタル・バインド・ステートメントが、それを参照する孤立した名前空間ごとに独立して解決されることを意味する。
予約パッケージ
システムが使用するために、特定のパッケージ名セットが明示的に予約されています。 これらのオブジェクトは、SYSTEMテナントでのみ定義されるグローバル・データベース・オブジェクトとみなされます。 既定のSYSTEMテナント以外の分離ネームスペースで、予約名を持つユーザー定義パッケージをバインドすると、バインドに失敗しました(SQLCODE -4004)。 予約名を使用し、デフォルトのSYSTEMテナント以外の分離ネームスペースにバインドされているシステム提供パッケージの場合、システムはSYSTEMテナント内でパッケージを透過的にバインドします。

制約事項

現在、分離されたネームスペース環境ではまだ利用できないデータベース機能がいくつかある。 適切な場合、これらの機能が使用されると、サポートがまだ存在しないことを示すSQL0270N(SQLSTATE 42997) メッセージが返されます。

孤立した名前空間ではまだサポートされていない主要な機能がいくつかある：

  • テナント固有のイベントモニター。 イベント・モニタはSYSTEMテナントでのみ作成でき、これらのイベント・モニタはすべての分離されたネームスペースからイベントを収集します。
  • フェデレーション
  • Text Search
  • 使用リスト

データベース・スキーマのトランスポートなど、一部のツールやユーティリティも、分離された名前空間内で使用できるようにまだ更新されていない。