Tiberoの特徴

Tibero RDBMS 5（以下、Tibero）は、マルチスレッド基盤である「TTA」(Tibero Thread Architecture)という方式を実装することにより、プロセスを生成・消滅せず、ユーザーの接続要求に即反応し、クライアントのスピーディーな接続、負荷の最小化、データの安定的な処理を保証します。データ読み取りの際、「コストベース・オプティマイザ基盤」で最適化するため、システムのCPUやメモリなどのリソースを効率的に活用することができます。

「SQL」標準に準拠し、標準インターフェースを支援しております。「ストアド・プロシージャ」 、「埋め込みSQL」、「トリガー」、「パッケージ」を支援し、便利で多様な開発環境を提供します。また、「データベース構造の変更」、「バックアップ・復旧機能」や従来の「RDBMS(Oracle)DBオブジェクト、データ」を簡単にマイグレーションできる「tbMigrator GUIツール」の提供により、効率的なシステム管理が可能です。

製品別プラットフォームの制限とライセンス

※ Tiberoの保守費用は15%固定（ライセンス費の15％）
※ 製品価格については、日本ティーマックスソフト社までお問い合わせください。

製品別機能概要

Tiberoの主な機能

パーティショニング(Partitioning)

データ量増加に伴い、それらのデータの特性に合わせ、柔軟にパーティション（レンジ、リスト、ハッシュ、コンポジット）を選択して管理することで、レスポンスの向上に加え、データベース管理のしやすさと可用性向上を実現します。パーティション化されたテーブルには、ローカルインデックスとグローバルインデックスがサポートされます。 Oracleデータベースのパーティションオプションと違い、Tiberoでは、別途のオプションライセンスなしですべてのエディションでパーティション機能を使うことができます。

データのレプリケーション (Data Replication)

現行のアクティブ・データベースにて、変更されたすべてのデータをスタンバイ・データベースに複製する機能です。つまり、ネットワークを通して変更ログ(change log)のみに転送すれば、スタンバイ・データベース側でログデータを適用する方式です。（ProSync for Tibero：別売の製品オプション）
さらに、プライマリ・データベースからスタンバイ・データベースへRedoログをトランザクション単位でコピーするTiberoスタンバイ・クラスターという機能も提供しています。スタンバイ・データベースを読み取り専用モードでオープンすることができます。

データベースのクラスタ (Database Cluster)

共用ディスク方式と独立ディスク方式（データ複製方式）の二つの異なるHAクラスタリング技術の提供により、高可用性、拡張性、高性能を実現する「TAC（Tibero Active Clustering）」機能を搭載しています。この技術により、複数のデータベースのインスタンスが共有ディスクを利用し、同じデータベースを共有できます。

分散データベースリンク (Distributed Database Link)

データベースのインスタンス別にそれぞれ異なるデータを格納する機能です。これにより、ローカル・ユーザはリモート・データベースのデータにアクセスできるようになります。ODBC、JDBC ゲートウェイにより、ネットワークを通じてOracle、DB2、MS-SQL Server、Adaptive Server Enterprise（Sybase）といった他社の製品RDBMSと連携して読み取り、書き込みすることができます。

並列クエリ処理 (Parallel Query Processing)

一つのSQLをマルチスレッドで構成されるクエリとして並列的に実行することで、大容量データ処理を高速化することができ、サーバーのリソースを最大限に活用できます。

クエリオプティマイザ (Query Optimizer)

クエリオプティマイザは、スキーマ・オブジェクトの統計情報に基づいて、様々なデータアクセスパターンを考慮して一番効率的な方法を決定します。

業界標準のサポート

標準SQL 規格に準拠するだけでなく、多くの業界標準のインターフェースを提供しています。また、JDBC, ODBC, OLE DB, CLI(Call Level Interface) 等もサポートしています。

互換性のあるストアド・オブジェクト

Oracle PL/SQL文法互換のtbPSMを提供します。そのため、Oracle用に開発されたPL/SQLのプログラムをTibero RDBMSでも利用することができます。

互換性のある埋め込み型SQL

C プログラムやCobol プログラムから、Oracle データベースにアクセスするためのプリコンパイラ文法互換のtbESQLを提供します。そのため、Oracle用に開発されたPro*C、Pro*Cobolの埋め込み型SQLのプログラムをTiberoでも利用することができます。

バックアップとリカバリ

オフライン・バックアップ、オンライン・バックアップの機能が提供されます。バックアップの取り方としては、フルバックアップに加えて増分バックアップもサポートされます。さらに、様々なバックアップ/リカバリシナリオを提供するリカバリマネージャ（RMGR）というツールを備えています。

各種 開発・運用ユーティリティ

• tbSQL：SQL クライアント用ツール
• tbExport / tbImport：データ転送(移行)ツール
• tbLoader：大容量データ高速ローディングツール
• tbMigrator：他社のRDBMSのデータやオブジェクトをTiberoにマイグレーションするためのツール

データベース開発・管理ツール (tbAdmin)

tbAdminは、GUIベースの環境でデータベース開発・管理ツールです。SQL文だけではなく、DDLとトランザクション関連のSQL文を実行することができます。また、tbPSMプログラムを作成したり、実行したりすることができ、複数のSQL文とtbPSMプログラムをファイルとして作成、保存、開くことができます。特にDBAは、tbAdminを使用してTiberoを管理したり、コマンドを実行したり、モニタリングしたりすることができます。

Tiberoのアーキテクチャー

Tiberoのプロセス構造

Tibero RDBMSは、大規模なユーザーの接続に対応できるマルチプロセスとマルチスレッド基盤のアーキテクチャーを持っています。

Tibero RDBMSのプロセスは、以下の3つで構成されます。

1. リスナー(Listener)
   

   リスナーはクライアントの新規接続の要求を受けて、その要求を遊休状態のワーキング・プロセスに割り当てます。つまり、クライアントとワーキング・プロセス間の中継機能を担当します。単一のリスナーのみ起動できます。

   
   
2. ワーキング・プロセス(Working ProcessまたはForeground Process)
   

   ワーキング・プロセスは、クライアントと実際に通信し、ユーザーの要求事項を処理するプロセスです。このプロセスの数はWTHR_PROC_CNT初期化パラメータで調整でき、一旦Tibero RDBMSが起動した後は変更できません。したがって、システム環境を考慮して適切な値を設定する必要があります。Tibero RDBMSをインストールすると、基本的に1つのワーキング・プロセス内には1つのコントロール・スレッドと10のワーク・スレッドが存在します。

   
   
3. バックグラウンド・プロセス(Background Process)
   

   バックグラウンド・プロセス(Background Process)は、クライアントの接続要求を直接受けずに、ワーク・スレッドや他のバックグラウンド・プロセスが要求する時、または、決まった周期に従って動作する、主に長時間かかるディスク作業を担当する独立したプロセスです。

Tiberoのメモリ構造

Tiberoのメモリは、大きく分けてSystem MemoryとShared Memoryがあります。

1. System Memoryは、プロセスごとに独立的に使うメモリ領域です。(OracleのPGAに相当)
   

   ・ Fixed領域：Tiberoが起動する時に割り当てられるメモリ領域です。
   ・ Allocator領域：Tibero内部によって割り当てと解除が動的に管理されるメモリ領域です。

   
   
2. Shared Memoryは、すべてのプロセスが共有するメモリ領域です。(OracleのSGAに相当)
   

   ・ Fixed領域：Tibero起動後にTiberoによって用途が決まっている領域です。Buffer cache、log bufferといったコンポーネントがあります。
   ・ Share Pool領域：共有領域としてslab（固定サイズcache用途）とshp（一般用途）の要素があります。slabにはdata dictionary cache、physical plan cache。object poolといったコンポーネントがあります。

以下は、[図Tibero RDBMS 5.0 アーキテクチャー]に基づいてクライアントの新規接続要求が行われる手順です。

1. 現在遊休状態のワーキング・プロセスを見つけ、クライアントの接続要求(①)を行います。
2. この際、ファイル記述子(File descriptor)と共に割り当てられるため、クライアントはサーバーの内部動作と関係なく、最初からワーク・スレッドに接続していたかのように動作します。
3. リスナーの要求を受けたコントロール・スレッド(CTHR: control thread)は、自身に属しているワーク・スレッドの状態をチェック(②)して、現在遊休状態のワーク・スレッドにクライアントの接続を割り当て(③)ます。
4. 割り当てられたワーク・スレッドは、クライアントと認証手続きを経た後、セッションを開始(④)します。