#システム管理

この記事は、「プライベートWebサーバ（PWS）を使用しないバージョンの新規インストール／アップグレード：概要」の続きの記事で、コンテナ版IRISを利用する場合のWebサーバ設定例をご紹介します。（先に「概要」の記事をお読みいただくことをお勧めします。）

この記事は、「プライベートWebサーバ（PWS）を使用しないバージョンの新規インストール／アップグレード：概要」の続きの記事で、ApacheをWebサーバとする場合の設定概要をご紹介します。（先に「概要」の記事をお読みいただくことをお勧めします。）

同一サーバ上にApacheとInterSystems製品をインストールする場合、事前にApacheをインストールしておくとApacheに必要なWebゲートウェイのインストールとIRISへの接続設定をインストーラーが自動で行います。

以降の説明では、以下のインストール方法について解説します。

• 1. Apacheを事前に準備しない状態での新規インストール
• 2. Apacheを事前に準備しない状態でのアップグレード
• 3. Apacheをインストールした後の新規／アップグレードインストール
• 4. Apacheの設定

※ 図解では、InterSystems IRISを使用していますが、InterSystems製品で操作は共通です。

この記事は、「プライベートWebサーバ（PWS）を使用しないバージョンの新規インストール／アップグレード：概要」の続きの記事で、IISをWebサーバとする場合の設定概要をご紹介します。（先に「概要」の記事をお読みいただくことをお勧めします。）

同一サーバ上にIISとInterSystems製品をインストールする場合、事前にIISを有効化しておくとIISに必要なWebゲートウェイのインストールと設定をIRISのインストーラーが自動で行います。

以降の説明では、以下のインストール方法について解説します。

• 1. IISを事前に準備しない状態での新規インストール
• 2. IISを事前に準備しない状態でのアップグレード
• 3. IISをインストールした後の新規／アップグレードインストール
• 4. IISの設定

※ 図解では、InterSystems IRISを使用していますが、InterSystems製品で操作は共通です。

[背景]

InterSystems IRIS 製品には、便利なツール ^SystemPerformance (Caché / Ensemble 時代は ^pButtons と呼ばれていました) があり、データベースのパフォーマンス情報を HTML 形式で出力してくれます。 IRIS for Windows で ^SystemPerformance を実行すると、 InterSystems 独自のパフォーマンスログ mgstat と Windows パフォーマンスログの両方を含んだ HTML が生成されます。

このたび、 InterSystems IRIS® data platform、InterSystems IRIS® for Health™ および HealthShare® Health Connect のアップグレードに役立つ新しいドキュメントをご紹介します。ドキュメント 「影響度の高いアップグレード・チェックリスト」 https://docs.intersystems.com/upgrade で、任意のバージョン間でのアップグレードにおいて考慮すべき修正リスト（しかも考慮すべき修正だけ）を見ることができます。これは、ドキュメント 「非互換性リスト」 に、便利なフィルター、上位カテゴリ情報 および ＣＳＶファイルへの出力機能を追加したもので、お客さまのアップグレード作業における正確なチェックリストとしてお使いいただけます。 

これは InterSystems FAQ サイトの記事です。

データ取込み処理の性能・エラー（Lock Table Full）対策として、一般メモリヒープ（gmheap）や ロックテーブルサイズ（locksiz）のパラメータチューニングを行う場合があると思います。

実際に、現在どのくらいの一般メモリヒープが確保できているのかは、ターミナルと管理ポータルで確認することができます。

★ターミナルの場合

// 一般メモリヒープサマリ
USER>w$system.Config.SharedMemoryHeap.GetUsageSummary()
4992226,6029312,59441152

一般メモリヒープサマリは、使用量，アロケート量，構成量(bytes) で戻り値が表示されます。

使用量は、アロケートされたロックテーブルやプロセステーブルなどで実際に使用されている量になります。
アロケート量は、gmheapの領域でロックテーブルやプロセステーブルなどでアロケートされている量になります。
構成量は、gmheap(KB) ＋IRISシステム追加領域 で、これが現在の最大利用可能な量（実際の一般メモリヒープの領域の値）になります。
 

これは InterSystems FAQ サイトの記事です。
 

iris list　などのコマンドで、IRISインスタンスの情報を表示すると、下記のように、stateが「warn」となっていることがあります。

Instance 'IRIS'   (default)
    directory:    /usr/irissys
    versionid:    2022.1.1.374.0
    datadir:      /usr/irissys
    conf file:    iris.cpf  (SuperServer port = 1972, WebServer = 52773)
    status:       running, since Wed Jan 25 15:05:32 2023
    state:        warn
    product:      InterSystems IRISHealth

これは、直近のシステムログ(messages.log/cconsole.log)にエラーが記録されたことによるもので、InterSystems製品を再起動した場合、もしくは、一定時間エラーが無ければ、「ok」になります。
※元になったエラーの原因については、messages.logを確認してください。

弊社FAQサイトや開発者コミュニティには、ライセンスに関する記事を数多く掲載しています。

こちらの記事では、上記記事でご紹介している様々な機能をTipsとして使い、実際にライセンス使用量の推移を調査する方法をご紹介します。

１．ライセンス使用状況をスポットで確認する方法（今現在の使用状況）

２．ある一定期間のライセンス使用状況を継続して監視する方法
 

１．ライセンス使用状況をスポットで確認する方法（今現在の使用状況）

現在のライセンス使用量は管理ポータルで確認できます。
[システムオペレーション] > [ライセンス使用量] 

※各項目の意味は以下の記事を参照してください。
管理ポータルのライセンス使用量のページに表示される値の意味
 

具体的にどのようなユーザがライセンスを消費しているのかは、「ユーザ毎の使用」で見られますが、こちらはローカルのサーバのインスタンスのみの情報となります。
リモート接続しているインスタンスへのユーザ毎の使用情報は、リモートのサーバ上のインスタンスで確認する必要があります。

また、現在のライセンス使用状況は ライセンスユーティリティ（%SYSTEM.License クラスのメソッド）を使用してコマンドでファイル出力することも可能です。

以下の記事の添付ファイルに、使用例を掲載しております。
使用中のライセンス情報を取得する方法
 

Caché と InterSystems IRIS データベースの整合性は、システム障害から完全に保護されてはいますが、物理ストレージデバイスが保管しているデータは、デバイスの障害によって破損してしまいます。  そのため、多くのサイトでは、データベースの整合性チェックを定期的に実行するように選択しており、特に特定のバックアップが災害時に信頼できるかどうかを検証するためにバックアップが行われています。  システム管理者がストレージの破損を伴う災害に対応するために、整合性チェックも緊急に必要となる場合もあります。  整合性チェックはチェックされているグローバルの各ブロック（すでにバッファーにない場合）を、グローバル構造で指示された順序で読み取る必要があります。 これには膨大な時間がかかりますが、整合性チェックは、ストレージサブシステムが維持できる限り高速に読み取ることができます。  一部の状況においては、できる限り迅速に結果を取得するために、そのように実行することが望ましい場合がありますが、  他の状況においては、ストレージサブシステムの帯域幅の過剰な消費を避けるために、整合性チェックをより保守的に行う必要があります。 

攻撃への対応計画

ターミナルにライセンス期限切れの警告メッセージ（「*\* Warning: This Cache license will expire in 3 days **」）が表示されており、そのメッセージを表示したくない場合は、以下のコマンドを実行すると、メッセージの表示を無効（または有効）にできます。

Do ExpirationMessageOff^%SYS.LICENSE - Disable

Do ExpirationMessageOn^%SYS.LICENSE - Enable

プロセスの単位の詳細情報（使用メモリサイズ、ユーザ名、実行ルーチンなど）は管理ポータルで確認できますが、それらをコマンドで取得する方法をご紹介します。 

管理ポータル：
[システムオペレーション] > [プロセス]  （プロセス毎の）詳細リンク 

%SYS.ProcessQuery クラスを使用して、以下のように行います。

USER>setx=##class(%SYS.ProcessQuery).%OpenId(<PID>)   // 自プロセスの場合は <PID> = $JOB
USER>writex.MemoryUsed
188
USER>writex.UserName
UnknownUser
USER>writex.ClientIPAddress
127.0.0.1
USER>zwritex// 全てのプロパティを確認したいとき
：

Embedded Python で呼び出したい場合は以下のようにします。

これは InterSystems FAQ サイトの記事です。

IRISではジャーナルファイルが自動的に圧縮される仕組みが導入されています。

ジャーナルファイルの圧縮機能について詳しくは、別の記事「ジャーナル圧縮機能について」をご参照ください。

例えば、CachéからIRISへ移行された後に、念のためIRISで更新されたデータを手動でCachéにも反映させたいことばある場合に、IRISのジャーナルファイルをCachéにリストアすることができます。

手順は以下の通りです。

(手順1) IRISのジャーナルファイル（YYYYMMDD.nnnz） ファイルを解凍する
(手順2,3) 解凍した ジャーナルファイルを Cachéに転送してリストアする

リストアの方法として、以下の2パタンをご紹介

(A) 指定グローバルとデータベースについて、指定ジャーナルから、全エントリをリストア
(B) 指定グローバルとデータベースについて、指定ジャーナルから、特定のアドレスまでリストアする

(A) 指定グローバルとデータベースについて、指定ジャーナルから、全エントリをリストア

(手順1) IRISサーバ上で以下のコマンドにより、ジャーナルを解凍する

IRIS 2022.1 以降、現在実行中のジャーナル以外は、拡張子 z で圧縮されています。

以下のコマンドで解凍し、指定のフォルダにコピーします。

InterSystems IRIS で使用できるユーティリティの一部を一覧でご紹介します。

以下の表の各ユーティリティ名をクリックすると、ユーティリティの詳細情報をご覧いただけます。

こちらの記事 では、ヘルスモニタのセンサー値を ^%SYSMONMGR ユーティリティを使用して変更する方法をご紹介しました。
今回は、ヘルスモニターセンサー値を コマンド（プログラム）で変更する方法をご紹介します。

ヘルスモニタは、CPUUsage（CPU使用率）、DBLatency（DBからのランダム読取に要する時間）、DiskPercentFull（DBのディスク使用率）などの該当しきい値を超えた場合に、通知を生成します。
※ヘルスモニタのセンサー値（閾値）について

センサーのしきい値を超えると、IRISのシステムログ（messages.log）に以下のようなメッセージが記録されます。

これは InterSystems FAQ サイトの記事です。

InterSystems IRIS では、柔軟でユーザ拡張可能な監視ツールである「システムモニタ」をお使いいただくことが可能です。

システムモニタには、以下の3つのインスタンス監視ツールがあります。

• システムモニタ：システムの状態およびリソースを監視・固定パラメータに基づいて通知 (アラートおよび警告) を生成
• ヘルスモニタ：主要なシステムメトリックおよびユーザ定義メトリックをサンプリング＆ユーザ変更可能パラメータおよび規定の通常値と比較し、該当しきい値を超えた場合に通知を生成
  ※ヘルスモニタは既定では無効となっています。
  　起動するには、^%SYSMONMGR を使用してヘルスモニタを有効にする必要があります。
  　ただし、システムモニタのサブスクライバクラスは、ヘルスモニタが有効でなくても動作します。
• アプリケーションモニタ：重要なシステムメトリックをサンプリング＆ユーザが作成したアラート定義を使用して評価

messages.logに、以下のようなログが記録される場合があります。

[SYSTEM MONITOR] DBLatency(c:\xxx\) Warning: DBLatency = 1510 ( Warnvalue is 1000).
※このメッセージの意味については こちらの記事 をご覧ください。

これは InterSystems FAQ サイトの記事です。

以下の状態の時、ReadOnlyでマウントされます。

• データベースの構成設定「読み込み専用でマウント」にチェックをつけている
• データベースマウント時「読み込み専用」のチェックをつけている
• ミラー構成を使用していないのにデータベースにミラー属性がついている
  • 詳細は「ミラー・データベースがミラー構成削除後に読み取り専用でマウントされる」をご参照ください。
• データベースファイルが存在するディレクトリを全体をコピーし、そのディレクトリに対してデータベースを作成したとき
  • 詳細は「データベースファイルが存在するフォルダ全体をコピーしたとき、コピーしたデータベースファイルがマウントできません。」をご参照ください

これは、InterSystems FAQサイトの記事です。
管理ポータルの監査メニューを使用する場合、ユーザに監査データベースの閲覧のみを許可するということはできません。
管理ポータルから監査データベースを閲覧する場合は、そのユーザに、
・%Admin_Secure：U（監査以外にもセキュリティ関連の操作が可能となる）
・%DB_IRISAUDIT：RW（監査データベースへの読み込み／書き込み権限）
等のリソースへの権限が必要になりますが、これを与えることにより、監査データベースの閲覧以外の操作も可能となってしまいます。

監査データベースの閲覧のみを許可したい場合には、管理ポータルの監査メニューは使用せず、外部ツール等からSQLで監査テーブルを参照するようにします。
このとき、ユーザに必要な権限は以下の通りです。※他の権限は与えないようにします。
・IRISAUDITデータベースへのRW権限 ⇒ %DB_IRISAUDITロールの付与
・%SYS.AuditテーブルへのSelect権限
 

１．新規ロールの作成
必要な2つの権限のみを含むロールを作成します。

（1）新規作成
システム管理>セキュリティ>[新規ロール作成]＞名前入力＞[保存]

↓
（2）作成したロールに%DB_IRISAUDITロールを割り当てる
ロールの定義編集>Assigned Toタブ>%DB_IRISAUDITを選択して[割り当てる]

2022.1 及び 2021.2 から 新たにジャーナルファイルの自動圧縮機能がサポートされました。
この機能によって、わずかなCPUコストでジャーナルファイルが占有するDisk容量を大幅に削減する事が可能になります。
実際のお客様環境でジャーナル・ファイルの圧縮率85%という非常に高い効果が確認出来たケースもございます。
(圧縮効果はジャーナル・ファイルに記録される更新データの内容に依存します)
圧縮はミラージャーナル・ファイルに対しても行われます。

動作メカニズム

1. 現在書き込み対象となっている “アクティブ” なジャーナル・ファイルのサイズが規定サイズに達し、ジャーナル・ファイルの切替が発生すると、それ以降に発生するジャーナル・レコードは新しいジャーナル・ファイルへ書き込まれるようになります。   




2. 今迄書き込み対象となっていたジャーナル・ファイルはこれ以降は書き込みされない、”非アクティブ”、すなわち、更新のない静的なファイルとなった為、システム・プロセスによりジャーナル圧縮処理が開始されます。   




3. 圧縮が完了すると、圧縮前の非アクティブな元のジャーナル・ファイルは削除されます。 そして圧縮されたジャーナル・ファイルはファイル名の末尾に “z” が付加されます。

これは InterSystems FAQ サイトの記事です。

コミュニティ版は1インスタンスでの利用を想定しているため、2インスタンス以上で設定する構成は利用できません。

製品版と異なる点は以下の通りです。

• 組込みのライセンスキーを利用しているため、別のライセンスキーを適用できません。
• 同時接続 8ユーザまで利用できますがキーには期限があります。
  • キーの期限を迎えた場合は、コミュニティ版の新バージョンに切り替えることで新しいキーが適用されます。
• ミラーリング、ECP、シャーディング、InterSystems APIマネージャ（IAM）を利用できません。
• データベースのサイズに制限があります（10GB）。
• インストール環境のCPU数に制限があります（20コア）。

最新情報は InterSystems IRIS Community Edition Limitations をご確認ください。
※上記制限事項はバージョン2022.2～の情報です。バージョン2022.1以前の制限事項は日本語ドキュメント「InterSystems IRIS Community Edition の制限」をご参照ください。

今回は、「孤立メッセージ」について説明します。

孤立メッセージとは何ですか？

すべてのメッセージボディは、メタデータを保持するメッセージヘッダと関連付けらます。ヘッダーには、ソース構成名称、ターゲット構成名称、作成時刻、処理時刻、関連するメッセージボディ参照、セッション情報、メッセージボディのクラス名称、メッセージステータスなどの情報が格納されます。 メッセージボディに対応するヘッダーレコードが存在しない場合、そのメッセージボディは孤立メッセージボディと呼ばれます。ここでは、孤立メッセージボディの原因となる可能性があるものについて説明します。

ヘッダーのみを削除する場合

削除タスクの設定において、BodiesToo メッセージヘッダとともにメッセージボディも削除するかどうかを指定するものです。この設定をOFFにすると、削除タスクはメッセージヘッダーのみを削除し、メッセージボディは残します。これらのメッセージボディは、参照されたヘッダが削除されることから、孤立したレコードとなります。 メッセージヘッダの削除したが、メッセージボディは残している場合、マネジメントポータルでは孤立メッ セージボディを削除する方法はありません。この場合、プログラムによってメッセージボディを削除する必要があります。

削除タスクについては、ドキュメントをご参照ください。

これは InterSystems FAQ サイトの記事です。

これは InterSystems FAQ サイトの記事です。

システムモニタの中の「アプリケーションモニタ」を利用することで、ユーザが定義した特定の監視対象に対してチェックを行い特定の条件に合致した場合に通知を行ったり、メッセージログ（コンソールログ）に情報を出力したり、ユーザが定義するアクションを指定できます。

＜メモ＞
アプリケーションモニタはインストールにより準備されますが、ユーザが付属のアプリケーション・モニタ・クラスを有効化するまで動作しないモニタです。
付属のアプリケーションモニタには、監査のカウントやイベント詳細を収集するもの、ディスクの容量を監視するものなどが含まれます。

詳細は、以下ドキュメントをご参照ください。
【IRIS】アプリケーション・モニタのメトリック
アプリケーション・モニタのメトリック

作成手順は以下の通りです。

1. %SYSネームスペースにアプリケーションモニタ用クラスを作成する
2. 作成した1のクラスを、システムモニタのアプリケーションモニタ有効化メニューで有効化する
3. 収集のインターバルを設定する（秒単位）
4. システムモニタを再起動する

YASPEはYAPE(Yet Another pButtons Extractor)の後継機種です。YASPEは、メンテナンスと拡張を容易にするために、多くの内部変更を行い、一から書き直しました。

YASPEの機能は以下の通りです。

• 「InterSystems Caché pButtons」 および 「InterSystems IRIS SystemPerformance」 ファイルを解析してグラフ化し、オペレーティング・システムおよび IRIS のメトリックを迅速にパフォーマンス解析します。
• アドホックチャートを作成したり、「Pretty Performance」オプションでOperating SystemとIRISの指標を組み合わせたチャートを作成することで、より深く掘り下げることが可能です。
• 「System Overview」 オプションを使用すると、システムの詳細や一般的な設定オプションについて SystemPerformance ファイルを検索する手間を省くことができます。

YASPEはPythonで書かれています。ソースコードはGitHubで公開されており、Dockerコンテナ用には以下で公開されています。

• https://github.com/murrayo/yaspe

複数のインスタンス間でライセンスを共有する際に、ライセンスサーバを立ててライセンスの使用量を管理します。
IRISライセンスサーバには、ライセンスの使用量管理に加えて便利な新しい機能が追加されました。

1 は従来からのライセンスサーバの機能で、関連記事 にて機能紹介をしております。

2 はIRIS以降使用できるようになった新しい機能です。

複数のインスタンスを構成している場合、中央管理しているディレクトリに格納されているライセンスキーファイル（*.key）を各インスタンスに配布・管理するようにライセンスサーバを構成することができます。
その場合、個々のインスタンスにライセンスキー（iris.key）を配置する必要はありません。
ライセンスキーはユニークな LicenseID (※1, ※2) によって識別され、各インスタンスの起動時にロード＆有効化されます。

これは InterSystems FAQ サイトの記事です。
 

複数インスタンスでライセンスを共有する場合、ライセンスを統合管理するライセンスサーバの設定が必要です。

1. ライセンスサーバの構成

1) ライセンスキーの配置

ライセンスキー(IRIS.key/cache.key)は、すべての インスタンスの  <インストールディレクトリ>/mgr に配置してください。

ただし、IRIS 2021.1 以降のバージョンをお使いの場合は KeyDirectory を指定することで全てのインスタンスへのライセンスキーの配置は必要なくなります。

KeyDirectory を指定して各インスタンスにライセンスキーをロードする場合、LicenseID の設定が必要になります。
各インスタンスの開始時にローカルの iris.key ファイルが検出されない場合、LicenseID を使用してライセンスサーバにライセンスキーを要求します。
LicenseID  は、管理ポータルの以下のメニューで設定します。

管理ポータル：
　[システム管理] > [構成] > [追加設定] > [開始]：LicenseID

2) ライセンスサーバの設定

ライセンスサーバの設定は、全ての構成で同一のライセンスサーバを使用するように定義します（全ての構成で設定します）。
ライセンスサーバは、管理ポータルの以下のメニューで設定します。

以下、デプロイモード(配置モード)でプログラムを配布する方法を2つご紹介します。

① DB内のソースコードをデプロイモードでエクスポートする方法

② ソースコード用DBを用意してIRIS.datごとデプロイモードにする方法

①は、プログラムのみデプロイモードでエクスポート/インポートできるので、初回システム構築時はもちろん、プログラムの修正が発生した時などソースの一部のみエクスポートすることも可能となります。
②は、IRIS.dat ごとデプロイするので初回システム構築時に IRIS.dat のみ配置すればよく手順が単純です。

クラスがデプロイモードになると、そのクラスのメソッドとトリガのソースコードは削除されます。
クラスがデータ型クラスである場合、クエリキャッシュによって実行時にメソッド定義が必要になる可能性があるために、メソッド定義が保持されるのでご注意ください。
 

それぞれの方法について、詳しく説明します。
 

① DB内のソースコードをデプロイモードでエクスポートする方法

(1) 開発環境：Hidden属性をオンにして保存し、Deployモードでエクスポートします。
　  ※こちらの操作は、移行先環境で行うことも可能です。必要に応じて設定するようにしてください。

Caché/Ensemble 時代からご使用のお客様にはなじみの機能だと思いますが、IRISには「システムがインスタンスのメッセージログ／messages.log（Cachéの場合は コンソールログ／cconsole.log) を監視し、ログ・レベル2(重大なエラー) 以上 のアラートを受け取るとメールを送信する」ログ・モニター機能があります。
この機能を使用すると、アラートログ （alerts.log）へのログ書き込み管理のほかに、メールを送信することもできます。

メール送信の設定は、^MONMGR ユーティリティを使用して簡単に行えます。

以下に、サンプルをご案内します。

これは InterSystems FAQ サイトの記事です。

Question:

InterSystems IRIS は 2フェーズコミットをサポートしていますか？

Answer:

サポートしていません。

2フェーズコミットはデータベースシステムがサポートしているだけでは十分ではなく、アプリケーションサーバ等の各実装が定めている2フェーズコミットのプロトコルを駆使して、アプリケーションを構築する必要があります。

また関連するシステムの全てのコンポーネントが対応している必要がある、ロングトランザクションには向いていないなど、現実に実装する局面では様々な制約事項があります。

2フェーズコミットは、技術面、設計および実装面、コスト面、性能面などハードルが非常に高いため、実際には限られた領域での利用に留まっています。

これは InterSystems FAQ サイトの記事です。
外部バックアップ機能と、SANソリューションが提供するスナップショット（スナップクローン、ミラークローンなど呼び方はベンダ毎に異なります）などのテクノロジを利用することで、バックアップ時のインスタンス停止時間を最短にすることができます。

操作手順概要は以下の通りです。

1. 外部バックアップ用ユーティリティを利用して、データベースファイルへの書き込みを一時中断します(%SYSネームスペースで実行します)。

   %SYS>set status=##class(Backup.General).ExternalFreeze()

2. 外部のスナップショットユーティリティを使用して、ファイルシステムのスナップショットを作成します。    
3. データベースファイルへの書き込みを再開するため、外部バックアップ用ユーティリティを使用します。
   

   %SYS>set status=##class(Backup.General).ExternalThaw()

4. バックアップメディアにスナップショットをコピーします。

【ご参考】
ExternalFreeze() の処理は以下のようになります。

 1.  ジャーナルファイルの切り替え
 2.  データベースバッファ上の書き込み待ちバッファをすべてデータベースファイルに書き出す
 3.  ライトデーモンをサスペンド状態にする

これは InterSystems FAQ サイトの記事です。
InterSystems IRIS Data Platform（以下IRISと表記）ではマルチモデルのサポートにより、データに対して様々なアクセス手法を使用することができます。

主だったアクセス手法としてダイレクトアクセス、SQLアクセス、オブジェクトアクセスがあります。
 

ダイレクトアクセス は、IRISのネイティブ構造であるグローバルと呼ばれるキーバリュー型のデータに直接アクセスする方法です。

SQLアクセス は、リレーショナルデータベースシステムにアクセスするための標準言語であるSQLを使用してデータにアクセスする方法です。

オブジェクトアクセス は、オブジェクト指向言語でオブジェクトを操作するための表記法として幅広く利用されるドット記法を使用してデータにアクセスする方法です。

ダイレクトアクセスとSQLアクセスおよびオブジェクトアクセスでは、処理の抽象度が異なります。

抽象度が高くなるに伴い、内部的な処理のオーバヘッドが増加するため、単純な1スレッド単位でのアクセススピードの速さについては、ダイレクトアクセスが、SQLアクセスとオブジェクトアクセスに比較して速い場合が多いです。

しかしながら、今後SQLアクセスに関してより高速に処理できるよう様々な開発が進行中です。