システム管理とは、1つ以上のハードウェアおよびソフトウェアシステムの管理のことを示します。 InterSystemsシステム管理についてのドキュメント
ターミナルにライセンス期限切れの警告メッセージ（「*\* 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) 指定グローバルとデータベースについて、指定ジャーナルから、特定のアドレスまでリストアする
IRIS 2022.1 以降、現在実行中のジャーナル以外は、拡張子 z で圧縮されています。
以下のコマンドで解凍し、指定のフォルダにコピーします。
InterSystems IRIS で使用できるユーティリティの一部を一覧でご紹介します。
以下の表の各ユーティリティ名をクリックすると、ユーティリティの詳細情報をご覧いただけます。
こちらの記事 では、ヘルスモニタのセンサー値を ^%SYSMONMGR ユーティリティを使用して変更する方法をご紹介しました。
今回は、ヘルスモニターセンサー値を コマンド（プログラム）で変更する方法をご紹介します。
ヘルスモニタは、CPUUsage（CPU使用率）、DBLatency（DBからのランダム読取に要する時間）、DiskPercentFull（DBのディスク使用率）などの該当しきい値を超えた場合に、通知を生成します。
※ヘルスモニタのセンサー値（閾値）について
センサーのしきい値を超えると、IRISのシステムログ（messages.log）に以下のようなメッセージが記録されます。
これは InterSystems FAQ サイトの記事です。
InterSystems IRIS では、柔軟でユーザ拡張可能な監視ツールである「システムモニタ」をお使いいただくことが可能です。
システムモニタには、以下の3つのインスタンス監視ツールがあります。
.png)
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%という非常に高い効果が確認出来たケースもございます。
(圧縮効果はジャーナル・ファイルに記録される更新データの内容に依存します)
圧縮はミラージャーナル・ファイルに対しても行われます。
これは InterSystems FAQ サイトの記事です。
コミュニティ版は1インスタンスでの利用を想定しているため、2インスタンス以上で設定する構成は利用できません。
製品版と異なる点は以下の通りです。
最新情報は InterSystems IRIS Community Edition Limitations をご確認ください。
※上記制限事項はバージョン2022.2～の情報です。バージョン2022.1以前の制限事項は日本語ドキュメント「InterSystems IRIS Community Edition の制限」をご参照ください。
今回は、「孤立メッセージ」について説明します。
すべてのメッセージボディは、メタデータを保持するメッセージヘッダと関連付けらます。ヘッダーには、ソース構成名称、ターゲット構成名称、作成時刻、処理時刻、関連するメッセージボディ参照、セッション情報、メッセージボディのクラス名称、メッセージステータスなどの情報が格納されます。 メッセージボディに対応するヘッダーレコードが存在しない場合、そのメッセージボディは孤立メッセージボディと呼ばれます。ここでは、孤立メッセージボディの原因となる可能性があるものについて説明します。
削除タスクの設定において、BodiesToo メッセージヘッダとともにメッセージボディも削除するかどうかを指定するものです。この設定をOFFにすると、削除タスクはメッセージヘッダーのみを削除し、メッセージボディは残します。これらのメッセージボディは、参照されたヘッダが削除されることから、孤立したレコードとなります。 メッセージヘッダの削除したが、メッセージボディは残している場合、マネジメントポータルでは孤立メッ セージボディを削除する方法はありません。この場合、プログラムによってメッセージボディを削除する必要があります。
削除タスクについては、ドキュメントをご参照ください。
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=EGMG_purge#EGMG_purge_basic
Ensemble がメッセージボディを削除する際、メッセージボディのオブジェクトの値によるプロパティが削除されるとは限り ません。具体的には、他のオブジェクトを削除するのは、それらがシリアルオブジェクトであるか、子オブジェクト（関係によって定義される）である場合のみである。その他のオブジェクトについては、削除トリガーを定義するか、メッセージボディのクラスで %OnDelete() 方法を実装して、適切に削除を処理する必要があります。
OnDelete実装のサンプルコード
Class Sample.Address Extends %Persistent{
/// 所番地。
Property Street As %String(MAXLEN = 80);
/// 市名。
Property City As %String(MAXLEN = 80);
/// 2文字の州の略称。
Property State As %String(MAXLEN = 2);
/// 米国の5桁のZIP（Zone Improvement Plan）コード。
Property Zip As %String(MAXLEN = 5);
}
Class Sample.Person Extends %Persistent{
/// 本人の名前。
Property Name As %String [ Required ];
/// 本人の社会保障番号。これはパターンマッチで検証さ れます。
Property SSN As %String(PATTERN = "3N1""-""2N1""-""4N") [ Required ];
/// 本人の生年月日。
Property DOB As %Date;
/// 本人の自宅住所。
Property Home As Address;
/// 本人の勤務先住所。
Property Office As Address;
///オブジェクトを削除するためのコールバック。
ClassMethod %OnDelete(oid As %ObjectIdentity) As %Status [ Private ]{
// プロパティオブジェクトの参照を削除することです。
Set tSC = $$$OK, tThis = ##class(Sample.Person).%Open(oid)
If $ISOBJECT(tThis.Home) Set tSC = ##class(Sample.Address).%DeleteId(tThis.Home.%Id())
If $ISOBJECT(tThis.Office) Set tSC = ##class(Sample.Address).%DeleteId(tThis.Office.%Id())
Quit tSC
}
///SQL削除のコールバック/トリガー
Trigger OnDelete [ Event = DELETE ]{
// プロパティ・オブジェクトの参照を削除します。{%%ID} は削除されるレコードの ID を保持します。
Set tID={%%ID}
Set tThis = ##class(Sample.Person).%OpenId(tID)
If $ISOBJECT(tThis.Home) Do ##class(Sample.Address).%DeleteId(tThis.Home.%Id())
If $ISOBJECT(tThis.Office) Do ##class(Sample.Address).%DeleteId(tThis.Office.%Id())
Quit
}
}
メッセージが別のホストに送信/転送さ れようとしたら、Ensemble は新しいメッセージヘッダを作成し、対応するメッセージボディを関連付けます。 ビジネスサービス/プロセスで作成されたメッセージボディ/オブジェクトのインスタンスがディスク/データベースに保存され、かつプロダクション内の別のホストに送信されなかった場合、関連するヘッダーがなく、孤立メッセージボディとして残ります。ベストプラクティスは、転送されない限りメッセージボディを作成しないこと、またはオブジェクトのインスタンスの %Save() をコールしないことです (SendRequestSync/SendRequestAsync API は、メッセージをターゲット設定キューに入れる前にそれを保存します)。この方法では、メッセージボディのオブジェクトは、他のホストに送信されない限り、永続化されることはありません。
この問題の最も一般的な原因は、開発者が：
孤立メッセージは、削除タスクによって削除されません。これらのメッセージはディスクスペースを消費し、その数が増えるにつれて、ディスク使用量も増加します。ディスク使用量は、メッセージボディのデータだけでなく、これらの孤立メッセージボディレコードのインデックス／サーチテーブルのエントリも含めて使用されることになります。
孤立したメッセージの存在は、メッセージヘッダとボディを照会することで 特定することができます。各メッセージヘッダは、対応するメッセージボディを参照します。メッセージボディのオブジェクトIdの参照はヘッダのMessageBodyIdプロパティに、メッセージボディのクラス名はヘッダのMessageBodyClassNameプロパティに格納されます。
HL7 メッセージ・テーブルで孤立メッセージを見つけるためのクエリの例：
SELECT HL7.Id FROM EnsLib_HL7.Message HL7
LEFT JOIN Ens.MessageHeader hdr
ON HL7.Id=hdr.MessageBodyId
WHERE hdr.MessageBodyId IS NULL
上記のクエリは、対応するヘッダを持たないすべての HL7 メッセージを返します。このクエリは、メッセージボディのテーブル名称を置き換えるだけで、他のメッセージタイプに対するクエリに変更することができます。
マネジメントポータルでは孤立メッ セージボディを削除する方法はありません。この場合、プログラムによってメッセージボディを削除する必要があります。ENSDEMO データベースでは、Demo.Util.CleanupSet というクラスが、これを実行する方法の例を示してくれます。このルーチンは、オブジェクトのプロパティ参照も含めて深く削除します。
孤立メッセージを削除するためのルーチンがもう一つありますが、このルーチンは深い削除はしませんし、メッセージボディの削除だけを助けます。ソースをダウンロードするために、以下にgithubへのリンクを載せておきます。
https://gist.github.com/suriyasv/2ed7f2dbcfd8c79f3b9938762c17c0b5
ベストプラクティスは、
この記事が、プロダクションを構築する際にお役に立てば幸いです。また、ご不明な点などございましたら、お知らせください。ありがとうございました。
これは InterSystems FAQ サイトの記事です。
これは InterSystems FAQ サイトの記事です。
システムモニタの中の「アプリケーションモニタ」を利用することで、ユーザが定義した特定の監視対象に対してチェックを行い特定の条件に合致した場合に通知を行ったり、メッセージログ（コンソールログ）に情報を出力したり、ユーザが定義するアクションを指定できます。
＜メモ＞
アプリケーションモニタはインストールにより準備されますが、ユーザが付属のアプリケーション・モニタ・クラスを有効化するまで動作しないモニタです。
付属のアプリケーションモニタには、監査のカウントやイベント詳細を収集するもの、ディスクの容量を監視するものなどが含まれます。詳細は、以下ドキュメントをご参照ください。
【IRIS】アプリケーション・モニタのメトリック
アプリケーション・モニタのメトリック
作成手順は以下の通りです。
YASPEはYAPE(Yet Another pButtons Extractor)の後継機種です。YASPEは、メンテナンスと拡張を容易にするために、多くの内部変更を行い、一から書き直しました。
YASPEの機能は以下の通りです。
YASPEはPythonで書かれています。ソースコードはGitHubで公開されており、Dockerコンテナ用には以下で公開されています。
YASPEは、現在のOperating SystemとIRISのバージョンに重点を置いています。古いバージョンを実行してYASPEに問題がある場合、YAPEを介してパフォーマンスファイルを正常に実行するかどうかを確認することができます。問題がある場合は、遠慮なくGitHubを通じて私に連絡してください。
オプションは以下の通りです：
以下はカスタムチャートの例で、Glorefs (mgstat) とTotal CPUの使用率 (vmstat)です。
下の画像は、指定した時間へのズームを含むデフォルト画像の1つです（デフォルトは13:00-14:00）。
yaspe は、システムの概要と基本的な設定のチェックを含みます (-s)
このチェックは、システムの詳細を探すために SystemPerformance ファイルを探し回る手間を省くためのものです。以下は overview.txt の例です。
サイト名称のSystem Summary
ホストネーム : YOURHOST
インスタンス : SHADOW
オペレーティングシステム : Linux
プラットフォーム : N/A
CPUの数 : 24
プロセッサー : Intel(R) Xeon(R) Gold 6248 CPU @ 2.50GHz
メモリ : 126 GB
共有メモリ : globals 71680 MB + routines 1023 MB + gmheap 1000 MB = 73,703 MB
バージョン : Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2018.1.4 (Build 505_1U) Thu May 28 2020 10:11:16 EDT
収集日 : プロファイル実行「24hours」は、2021年11月22日16時15分00秒に開始されました。
注意：
- エラー発生時のジャーナルフリーズは使用できません。ジャーナルIOエラーが発生した場合、この期間に発生したデータベースアクティビティは復元できません。
- swappinessのパラメータは10です。データベースの場合、Linuxカーネルがメモリページをディスクにスワップする積極性を調整するために、5を推奨します。
- Hugepagesが設定されていない。パフォーマンス、メモリ効率、および共有メモリのページアウトを防ぐために、巨大なページメモリ空間を使用します。HugePagesを共有メモリ量よりはるかに大きく指定することはお勧めしません。なぜなら、未使用のメモリが他のコンポーネントで使用できなくなるからです。
- dirty_background_ratioのパラメータは10 です。InterSystems では、このパラメータを 5 に設定することを推奨しています。この設定は、pdflush がダーティページの書き込みを開始する前に、ダーティページで埋められるアクティブなメモリの最大パーセンテージです。
- dirty_ratio のパラメータは 30 です。インターシステムズでは、このパラメータを 10 に設定することを推奨しています。この設定は、タイムスライス中にプロセスがより多くの書き込みを許可される代わりに、ダーティバッファを自ら書き込むように強制される前に、ダーティページで満たすことができる総メモリの最大割合を示します。これらの変更により、Linuxのpdflushデーモンは、ストレージに大量の更新が殺到する可能性のあるキューを作成するのではなく、より頻繁にダーティページを書き出すように強制されます。
お勧め：
- 上記の注意を見直し、修正してください。。
- HugePagesを設定し、IRISのドキュメントを参照してください： https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GCI_prepare_install#GCI_memory_big_linux
- 総メモリ量は128,755MB、総メモリ量の75%は96,566MBです。
- 共有メモリ（グローバル＋ルーチン＋gmheap）は73,703MBです。(総メモリの57%)です。
- ( 73,703 MB + 5% バッファ = 77,388 MB ) のページサイズ 2048 KB の HugePages 数は、38694 です。
このホストのすべてのインスタンスは：
- >SHADOW 2018.1.4.505.1.a 56772 /cachesys
複数のインスタンス間でライセンスを共有する際に、ライセンスサーバを立ててライセンスの使用量を管理します。
IRISライセンスサーバには、ライセンスの使用量管理に加えて便利な新しい機能が追加されました。
1 は従来からのライセンスサーバの機能で、関連記事 にて機能紹介をしております。
2 はIRIS以降使用できるようになった新しい機能です。
複数のインスタンスを構成している場合、中央管理しているディレクトリに格納されているライセンスキーファイル（*.key）を各インスタンスに配布・管理するようにライセンスサーバを構成することができます。
その場合、個々のインスタンスにライセンスキー（iris.key）を配置する必要はありません。
ライセンスキーはユニークな LicenseID (※1, ※2) によって識別され、各インスタンスの起動時にロード＆有効化されます。
これは InterSystems FAQ サイトの記事です。
複数インスタンスでライセンスを共有する場合、ライセンスを統合管理するライセンスサーバの設定が必要です。
ライセンスキー(IRIS.key/cache.key)は、すべての インスタンスの <インストールディレクトリ>/mgr に配置してください。
ただし、IRIS 2021.1 以降のバージョンをお使いの場合は KeyDirectory を指定することで全てのインスタンスへのライセンスキーの配置は必要なくなります。
KeyDirectory を指定して各インスタンスにライセンスキーをロードする場合、LicenseID の設定が必要になります。
各インスタンスの開始時にローカルの iris.key ファイルが検出されない場合、LicenseID を使用してライセンスサーバにライセンスキーを要求します。
LicenseID は、管理ポータルの以下のメニューで設定します。
管理ポータル：
[システム管理] > [構成] > [追加設定] > [開始]：LicenseID
ライセンスサーバの設定は、全ての構成で同一のライセンスサーバを使用するように定義します（全ての構成で設定します）。
ライセンスサーバは、管理ポータルの以下のメニューで設定します。
以下、デプロイモード(配置モード)でプログラムを配布する方法を2つご紹介します。
① DB内のソースコードをデプロイモードでエクスポートする方法
② ソースコード用DBを用意してIRIS.datごとデプロイモードにする方法
①は、プログラムのみデプロイモードでエクスポート/インポートできるので、初回システム構築時はもちろん、プログラムの修正が発生した時などソースの一部のみエクスポートすることも可能となります。
②は、IRIS.dat ごとデプロイするので初回システム構築時に IRIS.dat のみ配置すればよく手順が単純です。
クラスがデプロイモードになると、そのクラスのメソッドとトリガのソースコードは削除されます。
クラスがデータ型クラスである場合、クエリキャッシュによって実行時にメソッド定義が必要になる可能性があるために、メソッド定義が保持されるのでご注意ください。
それぞれの方法について、詳しく説明します。
(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ソリューションが提供するスナップショット（スナップクローン、ミラークローンなど呼び方はベンダ毎に異なります）などのテクノロジを利用することで、バックアップ時のインスタンス停止時間を最短にすることができます。
操作手順概要は以下の通りです。
%SYS>set status=##class(Backup.General).ExternalFreeze()%SYS>set status=##class(Backup.General).ExternalThaw()
【ご参考】
ExternalFreeze() の処理は以下のようになります。
1. ジャーナルファイルの切り替え
2. データベースバッファ上の書き込み待ちバッファをすべてデータベースファイルに書き出す
3. ライトデーモンをサスペンド状態にする
これは InterSystems FAQ サイトの記事です。
InterSystems IRIS Data Platform（以下IRISと表記）ではマルチモデルのサポートにより、データに対して様々なアクセス手法を使用することができます。
主だったアクセス手法としてダイレクトアクセス、SQLアクセス、オブジェクトアクセスがあります。
ダイレクトアクセス は、IRISのネイティブ構造であるグローバルと呼ばれるキーバリュー型のデータに直接アクセスする方法です。
SQLアクセス は、リレーショナルデータベースシステムにアクセスするための標準言語であるSQLを使用してデータにアクセスする方法です。
オブジェクトアクセス は、オブジェクト指向言語でオブジェクトを操作するための表記法として幅広く利用されるドット記法を使用してデータにアクセスする方法です。
ダイレクトアクセスとSQLアクセスおよびオブジェクトアクセスでは、処理の抽象度が異なります。
抽象度が高くなるに伴い、内部的な処理のオーバヘッドが増加するため、単純な1スレッド単位でのアクセススピードの速さについては、ダイレクトアクセスが、SQLアクセスとオブジェクトアクセスに比較して速い場合が多いです。
しかしながら、今後SQLアクセスに関してより高速に処理できるよう様々な開発が進行中です。
これは InterSystems FAQ サイトの記事です。
クライアントからターミナルにログイン（接続）できない時、ターミナル接続を可能にするサービスが有効になっていないことが原因として考えられます。
ターミナル接続を可能にするサービスが有効になっていないことが原因として考えられます。
管理ポータル ：[ホーム] > [システム管理] > [サービス]
有効になっていない場合は、リンクをクリックしてサービス定義編集画面を開き、"サービス有効"にチェックを入れて保存します。
もう一つの原因としてはOSのファイアウォールによりターミナル接続が遮断されている場合が考えられます。
リモートでターミナル接続される場合はファイアウォールの設定を無効にしてお使い下さい。
これは InterSystems FAQ サイトの記事です。
テーブル(クラス) のデータを削除する際に %KillExtent() というメソッドを使用すると、レコードを1ずつ削除するのではなく、データを格納しているデータグローバル、インデックス定義のグローバル(ノード) をまとめて 削除することができます。
kill^ISJ.xxxD
kill^ISJ.xxxIのようにデータグローバルやインデックスグローバルをまとめて削除するのと同じような動作となります。
そのため、ジャーナルレコードへの出力は最小限になります。
使用例：
write##class(ISJ.xxx).%KillExtent()
ただし、トランザクション下で実行すると一括 Kill の場合でも保存されているレコードに応じたジャーナルレコードが生成されるのでご注意ください。
また、以下のドキュメントの注意書きにあるように、他クラス(テーブル)への参照などが含まれているクラスで実施されると整合性に問題が発生する場合がありますのでご注意ください。
こちらを必要なだけ記述したタスククラスを作成すると、タスクスケジューラから定期的に実行できます。
タスククラスの作成方法は、以下のトピックをご覧ください。
【ご参考】
サポートではこのような質問をたまに受けることがあります。何かが、または誰かが、想定以上のライセンスを使用しており、それを調べなければなりません。
調べるタイミングは2回あります。 1 つは、アプリケーションが動作しないか、ターミナル経由で接続しようとすると次のような「愛くるしい」メッセージが表示され、ライセンスが使い果たされていることに気づいたときです。
<LICENSE LIMIT EXCEEDED> メッセージ:
.png)
2 つ目のタイミングは、アプリケーションを使用できなかったことがあったという苦情をエンドユーザーから受けたときですが、問題が発生しているのを確認するには遅すぎます。 こういった場合には通例、messages.log に「License Limit exceeded xxxx times」というメッセージが確認されます。
.png)
最初のタイミングの場合は、問題が発生している状態を確認できるため、それをキャッチする方法がいくつか考えられます。
iris session <instance> -B
.png)
ライセンスをダンプ出力して調べれば、ほとんどのお客様にはサポート経由で何が起きているのかを調べる必要はありません。 お客様自身で、想定以上のライセンスを消費しているマシン、ユーザー、またはアプリケーションを特定することができます。
iris への接続方法と License クラスについての詳細は、ドキュメントをご覧ください。
問題が発生した後に確認されたために問題そのものをキャッチできない 2 つ目のタイミングにおいては、いくつかの方法があります。
レベル 2 メッセージの監視には、非常に便利な ^MONMGR（システムモニター）を使用するのが簡単です。 システムがレベル 2 の警告（ライセンス関連など）を受信すると、メールが送信されます。 警告はすぐに通知されるため、システムに接続し、システム管理ポータル（［ライセンス］セクション）やターミナル経由でライセンスの使用状況を確認することができます。
.png)
Do traceon^%SYS.LICENSE // ライセンスのトレースをオンにします。
Do traceoff^%SYS.LICENSE // ライセンスのトレースをオフにします。
先に述べたように、問題が発生した時点でそれをキャッチし、ライセンスのダンプ出力を確認できるようになれば、何がライセンスを消費しているのかを特定するのが非常に簡単になります。 何か変わったことがあればそれに対処する必要がありますが、そうでなければライセンスをさらに購入する必要があるでしょう。これについては別件ですので、WRC や営業部にご連絡ください。
iris コマンドを使用することで実行できます。
iris コマンド(iris.exe)は、＜インストールディレクトリ＞\bin にインストールされています。 書式：
iris run インスタンス名 tag^routine([parameter-list]) ネームスペース名iris run インスタンス名 ##CLASS(package.class).method([parameter-list]) ネームスペース名インスタンス名は、管理ポータル（システム管理ポータル）の右上にある [インスタンス：] に表示されている文字列です。
実行する環境に応じて一部の文字 ^ や " をエスケープする必要があります。
Windowsの場合は、以下のようなエスケープが必要となります。
例： USERネームスペースで do info^test(123,"abc") を実行します。
c:\InterSystems\IRIS\bin>iris terminal IRIS info^^test(123,\"abc\") USER
例： USERネームスペースで do ##class(Test.Class1).test(123,"abc") を実行します。
これは InterSystems FAQ サイトの記事です。
バージョン2015.2以降から、Windows上のインストール環境では、サービス・アカウントを
「Windowsコントロールパネル ＞ 管理ツール ＞ サービス ＞ InterSystems IRIS/Cache Controller for XX」
の「ローカル・システムアカウント」から Windows の任意の管理者アカウントに変更した場合に <NOTOPEN> エラー または -1 が返ります。
この状況を回復するためには、以下2つの設定をする必要があります。
1. 「Windowsコントロールパネル > 管理ツール > サービス > InterSystems IRIS/Cache Controller for XX」 のログオン設定を、「ローカルシステムアカウント」に戻す 2. irisinstall/cinstall コマンドを使用してInterSystems IRIS サービス・アカウントを変更する
2 の手順は以下になります。
Windowsコマンドプロンプトを管理者権限で起動し、以下コマンドを使用して変更します。
この設定を有効するためには、インスタンスの再起動が必要です。
皆さん、こんにちは！
職場で持ち上がった単純なリクエストで始めた個人プロジェクトを紹介したいと思います。
使用している Caché ライセンス数を調べることはできますか？
コミュニティに掲載されている他の記事を読んでみたところ、David Loveluck が投稿したぴったりの記事が見つかりました。
APM - Using the Caché History Monitor（APM - Caché 履歴モニターを使用する）
https://community.intersystems.com/post/apm-using-cach%C3%A9-history-monitor
そこで、David の記事を参考に、Caché 履歴モニターを使って、リクエストされた情報を表示して見ました。
「どのテクノロジーを使用するのか」という疑問に対し
私は CSP に決定しました。単純で強力なテクノロジーであるため、私が担当するお客様は Caché が単なる MUMPS/ターミナルではないことに気づくでしょう。
ライセンス、データベース増加状況、CSP セッションの履歴を表示するページを作成した後、「システムダッシュボードとプロセス」ページのデザインを新装することにしました。
私の Caché インスタンスではすべてうまく機能します。
でも、IRIS はどうでしょうか？
Evgeny Shvarov が投稿した以下の記事に従って、
Using Docker with your InterSystems IRIS development repository（InterSystems IRIS 開発リポジトリで Docker を使用する）
https://community.intersystems.com/post/using-docker-your-intersystems-iris-development-repository
コードを Docker 化して GitHub に配置しました。いくつかの手順を踏めば、どなたでも利用できます。
このリポジトリでコーディングを始めるには、以下を実行します。
任意のローカルディレクトリにリポジトリを Clone/git pull します。$ git clone https://github.com/diashenrique/iris-history-monitor.git
このディレクトリでターミナルを開き、以下を実行します。$ docker-compose build
プロジェクトで IRIS コンテナを実行します。$ docker-compose up -d
ブラウザを開いて、以下のアドレスに移動します。
例: http://localhost:52773/csp/irismonitor/dashboard.csp
ユーザー名 _SYSTEM を使用して、ダッシュボードとその他の機能を実行できます。
システムダッシュボードには、以下の項目が表示されます。
線グラフウィジェットには、5 秒ごとにポイントがプロットされます。
さまざまなフィルターを使用して、必要な結果を得ることができます。 また、列のヘッダーを Shift + クリックすると、複数の項目で並べ替えることもできます。データグリッドを Excel にエクスポートすることも可能です！
CSP セッションとライセンスの履歴モニターでは、情報が以下の 3 つのセクションに分かれて表示されます。
データベースの増加が表示できるのは、毎日の情報のみです。
履歴ページでは以下の機能を共通して使用できます。
_デフォルト_値は、「過去 7 日間」です。
各セクションの右上に、2 つのボタン（チャート/データテーブル）があります。
データテーブルには、グラフを作成する情報が表示されます。Excel 形式でダウンロード可能です。
Excel には、CSP で定義されたのと同じフォーマット、コンテンツ、およびグループが表示浚えます。
すべてのグラフにはズームオプションがあるため、情報をより詳細に可視化することができます。
毎時間と毎日のセクションのグラフには、平均値と最大値が表示されます。
どうぞお楽しみください！
これは、InterSystems FAQサイトの記事です。
%SYS.Namespace クラスの List クエリで取得することができます。
次のようなルーチンを作成し、ターミナルで実行してください。
1. サンプルの作成
getnsp
// ネームスペース一覧を取得する write "nsp:glo:rtn",!,!
set statement=##class(%SQL.Statement).%New()
set status=statement.%PrepareClassQuery("%SYS.Namespace","List")
set resultset=statement.%Execute()
while resultset.%Next() {
write resultset.%Get("Nsp"),!
}
quit
2. ターミナルから実行
こちらの記事でご紹介しているクラスクエリを実行する方法は、様々なケースで応用できます。
開発者のみなさん、こんにちは！
2022年3月9日開催「InterSystems Japan Virtual Summit 2022」のセッション「ミラーリングを使用した HA および DR の構成例」のアーカイブを YouTube に公開いたしました。
（プレイリストはこちら）
ミラーリングは、IRIS インスタンス間のデータベースの複製およびフェイルオーバを行う機能です。
動画では、ミラーリングを利用した高可用（HA）なシステムおよびディザスタリカバリ（DR）に対応したシステムの構成例についてご紹介します。
ぜひご参照ください。
<iframe width="521" height="293" src="https://www.youtube.com/embed/sp5wfKbqHuQ" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
【目次】
00:35 ミラーリングの概要
03:20 ミラーリングの種類と機能：フェイルオーバ・ミラー・メンバ
05:07 ミラーリングの種類と機能：非同期ミラー・メンバ
06:33 DR 非同期ミラー・メンバの昇格・降格
07:29 DR 非同期ミラー・メンバの昇格・降格の機能を利用した災害復旧での対応例
10:07 ISCAgent について
11:12 Arbiter について
13:06 ミラーリングの構成例
これは、InterSystems FAQ サイト の記事です。
1つのインスタンスで作成可能なネームスペース数の上限は、2048個になります。
ただし多数のネームスペースを使用するには、それに合わせてメモリの設定が必要になります。使用するメモリの設定については下記の関連トピックご参照ください。
管理ポータルのメモリ関連設定項目について
また1つのインスタンスに作成可能なデータベース数（リモートデータベースを含む）の上限は、15998個になります。
なおライセンスの種類によっては、作成可能な数に制限が設けられています。
詳細については、以下ドキュメントをご参照ください。
ドキュメント：ネームスペースの構成
ドキュメント：ローカル・データベースの構成