InterSystems HealthShareは病院、統合配信ネットワーク（IDN）、地域および国の医療情報交換組織（HIE）向けの医療情報プラットフォームです。HealthShareには、医療情報交換、データ集約、ワークフロー、テキスト分析、分析テクノロジーなどの機能が搭載されています。
これは InterSystems FAQ サイトの記事です。
管理ポータルの SQL 画面（管理ポータル > システムエクスプローラ > SQL）で、任意の SQL を実行した後、結果の行数などが表示されいる行の右端にある「印刷」のリンクから、CSVファイル出力を選択できます。
.png)
「クエリ印刷」画面で「ファイルにエクスポート」をチェックすると「ファイル形式」の欄が表示されます。
形式に「CSV」を指定し、出力ファイル名を指定したあと「エクスポート」ボタンをクリックすると出力できます。
注意：古いバージョンでは正しくCSV出力が行えない場合もあります。新しいバージョンをぜひご利用ください。
プログラムでCSV出力を行いたい場合は、関連記事をご参照ください。
これは InterSystems FAQ サイトの記事です。
Windows システムにインストールされた InterSystems 製品を削除するには、コントロールパネルにあるプログラムの追加と削除（Windows 10の場合は、Windows の設定からアプリを選択）を使用します。
システムに変更を加えますので、管理者権限を持ったユーザでログインして作業を行う必要があります。
1) 管理者(Administrator)でシステムにログインします。
2) システムトレイから、アンインストールを行う InterSystems 製品インスタンスのランチャーを終了します（ランチャークリック → 終了）。
3)コントロールパネルにある プログラムの追加と削除 （Windows 10の場合は、Windows の設定からアプリを選択）で
<InterSystems製品> instance [xxxx] ( xxxx にはインスタンス名が表示されています) を削除します。
例：InterSystems IRIS instance [IRIS]
4) InterSystems 製品インストールディレクトリ（既定では C:\InterSystems\<InterSystems製品> ）を Windows エクスプローラ等を使用して削除します。
これは InterSystems FAQ サイトの記事です。
%SYSTEM.License クラスのメソッド利用すると、ライセンス情報を取得できます（実行時は、$SYSTEM.License.メソッド名() と記述します）。
%SYSTEM.License クラスは、ライセンスユーティリティ用システムオブジェクトです。
ユーティリティの詳細については、添付資料をご参照ください。
（クラス詳細については、クラスリファレンス内 %SYSTEM パッケージ以下 License クラスも併せてご覧ください。）
また、ライセンス情報は、管理ポータルからも確認できます。
ライセンスキー情報：
[システム管理] > [ライセンス] 以下
ライセンス使用状況：
[システムオペレーション] > [ライセンス使用量] 以下
これは InterSystems FAQ サイトの記事です。
24時間停止しないシステムの場合、「ジャーナルファイルの削除設定」に合わせて 0時30分 に古いジャーナルファイルを削除します。
「ジャーナルファイルの削除設定」より古いジャーナルファイルが残っている原因として、オープンされたままのトランザクションが存在していることが考えられます。
その場合、トランザクション実行中プロセスを探し、トランザクションを確定させることでジャーナルファイルを削除できるようになります。
以下のサンプルは、オープンされたままのトランザクションの存在確認と、存在する場合は対象ファイル名とジャーナルレコード情報が出力されます。
（サンプルは、https://github.com/Intersystems-jp/CheckOpenTransaction からダウンロードできます）
※注意※
確認対象のジャーナルファイルサイズが大きい場合、ジャーナルファイルが多数ある場合は、実行に時間がかかるため、弊社サポートセンターまでご連絡ください。
これは InterSystems FAQ サイトの記事です。
InterSystems 製品には、テーブルのコンテンツに関する統計を収集し、クエリの最適化に役立てる「テーブルチューニング機能」があります。
設定方法は、以下のドキュメントをご参照ください。
ターミナルでは次のコマンドを実行します。
do$SYSTEM.SQL.Stats.Table.GatherTableStats("スキーマ名.テーブル名",1,1)
2021.1以前のバージョンでは以下メソッドを利用します。
Do$system.SQL.TuneTable("スキーマ名.テーブル名",1,1)
また、以下の資料もご参照ください。
1) パフォーマンス調査の基礎知識として必要なグローバル構造の解説やSQLの動作の仕組みからクエリプランの見方の解説
2) パフォーマンスチューニングの例（P13～）
3) ビットマップ・インデックスの圧縮やオプティマイザ・ヒントなど、Caché SQLのパフォーマンスを最大限に引き出すための情報について
4) パフォーマンスに困ったときにどこに着目し、どのツールで調べていくか、お客様から日々ご相談をいただくカスタマーサポートから、解決に向かうアプローチの「イロハ」をご紹介するビデオ
5) 開発者コミュティのパフォーマンス関連情報（performanceタグ）
これは InterSystems FAQ サイトの記事です。
InterSystems IRIS Business Intelligence 用メニューの Analytics（または DeepSee）を使用するためには、使用するネームスペース用ウェブアプリケーションパスを Analytics（またはDeepSee）に対応するように設定変更する必要があります。
詳細については以下のドキュメントをご参照ください。
【IRIS】
InterSystems IRIS Business Intelligence の Web アプリケーション設定について
【2015.1～2018.1】
DeepSee の Web アプリケーション設定について
これは InterSystems FAQ サイトの記事です。
※データベースファイルとは、IRIS.DAT、および、CACHE.DATのことを指します。
Caché／Ensemble 2018.1.4、IRIS 2019.1.2／2020.1.0 以降のバージョンより、データベースファイル のサイズの縮小に、データベースの「圧縮」と「未使用領域の削除」機能をあわせて使用できます。
※注意※
Caché／Ensemble 2018.1.4、IRIS 2019.1.2／2020.1.0 より前のバージョンでは、データベースの「圧縮」機能は使用できません。使用された場合、データベース破損が引き起こされる可能性があります（「未使用領域の削除」機能は利用できます）。
詳細情報は以下、弊社ウェブサイト内のページをご確認ください。
製品ニュースとアラート>警告: データベース圧縮またはデフラグ後のデータベース整合性の問題
データベースサイズ縮小手順は以下の通りです。
管理ポータル： [システムオペレーション] > [データベース] を開き、操作したいデータベース名をクリックします。
（または、画面左上の[空き容量]ボタンをクリックし、データベースの空き容量を表示します。）
① 「圧縮」ボタンにより、データベースファイルの使用していないブロックを後ろに集めます
これは InterSystems FAQ サイトの記事です。
一般的なシステム統合製品はメッセージエンジン製品を中心にビジネスプロセス管理製品、ポータル製品、ビジネスアクティビティモニタリング製品などの付随する製品を1つのパッケージ製品（スイート製品と呼ばれることも多い）として提供しています。
パッケージとして提供はしていますが、個々の構成製品は通常別々に作成されたもので、操作法、リポジトリ管理、開発手法、管理手法等が各製品バラバラでシステム統合プロジェクトを実施するに当たり、これら全ての製品に習熟するためには膨大な時間がかかります。
また各製品毎に担当者をアサインするということも考えられますが、そうすると各担当者間のコミュニケーションが必要となりプロジェクト管理の手間が増えます。
InterSystems IRIS data platform にはシステム統合に必要な全ての機能が1つの製品に含まれており、統一された操作法、一元化されたリポジトリ、1つの首尾一貫した開発/管理環境が提供されます。
従ってシステム統合プロジェクトを開始する際の敷居をかなり低くすることが可能です。
これは InterSystems FAQ サイトの記事です。
プラットフォーム別導入状況（組織ベース）は、以下の通りです。
（2020年時点）
これは InterSystems FAQ サイトの記事です。
バージョンアップ後、ルーチンを再コンパイルする必要はありませんが、バージョンアップで %SYS が上書きされるため、%SYS 内のユーザ作成 INT 形式および OBJ 形式ルーチン（*.INT,*.OBJ）が削除されますので、注意が必要です。
MAC形式（.MAC）と以下の名前の INT 形式および OBJ 形式ルーチンについては削除されません。
なお、クラス／CSP はアップグレード後にコンパイルが必要となります。
ただし、メンテナンスリリースへのアップグレードの場合は、コンパイルは不要です。詳細は、以下ドキュメントをご参照ください。
Caché／Ensemble：メンテナンス・リリースのアップグレード後のタスク
InterSystems および Intel は先日、InterSystems IRIS を「Cascade Late」としても知られる第 2 世代 Intel® Xeon® スケーラブルプロセッサおよび Intel® Optane™ DC パーシステントメモリ（DCPMM）と組み合わせて一連のベンチマークを実施しました。 さまざまなワークロード設定とサーバー構成で、Intel の最新のサーバーテクノロジーを使用した InterSystems IRIS のパフォーマンスとスケーラビリティ機能を実証するのがこのベンチマークの目的です。 このレポートには、さまざまなベンチマークの結果とともに、Intel DCPMM と InterSystems IRIS のユースケースが 3 つ示されています。
パフォーマンスとスケーリングを実証するために 2 種類のワークロードが使用されています。読み取り集中型のワークロードと書き込み集中型のワークロードです。 このように分けて実証するのは、読み取り集中型ワークロードにおけるデータベースキャッシュ効率の増加と、書き込み集中型ワークロードにおけるトランザクションジャーナルの書き込みスループットの増加のそれぞれに特化したユースケースで、Intel DCPMM の影響を示すためです。 両方のユースケースシナリオにおいて、InterSystems IRIS のスループット、スケーラビリティ、およびパフォーマンスの大幅なゲインが達成されています。
読み取り集中型ワークロードでは、4 ソケットサーバーと、合計約 1.2 TB のデータを持つデータセットを使用する大量の長期実行分析クエリが使用されました。 DCPMM を「Memory Mode」で使用した場合のベンチマーク比較では、メモリの少ない前世代の Intel E7v4 シリーズプロセッサと比べた場合、経過実行時間が大幅に短縮され、およそ 6 倍高速になりました。 E7v4 と、DCPMM を使った最新のサーバーを同じメモリサイズで比較した場合は、20% の改善が見られました。 これは、DCPMM による InterSystems IRIS データベースキャッシュ機能の向上と最新の Intel プロセッサアーキテクチャによるものです。
書き込み集中型ワークロードでは、2 ソケットサーバーと InterSystems HL7 メッセージングのベンチマークが使用されました。多数のインバウンドインターフェースで構成されており、各メッセージには複数の変換が伴い、インバウンドメッセージごとに 4 つのアウトバウンドメッセージが使用されています。 高スループットを維持する上で重要なコンポーネントの 1 つは、IRIS for Health のメッセージ耐久性保証で、その操作においては、トランザクションのジャーナル書き込みのパフォーマンスが重要となります。 「APP DIRECT」モードで DCPMM を使用して、DAX XFS でトランザクションのジャーナル用の XFS ファイルシステムを提供した場合、このベンチマークのメッセージスループットには 60% の向上が示されました。
テスト結果と構成を要約すると、DCPMM は適切に設定された InterSystems IRIS とワークロードで使用された場合にスループットを大幅に向上させることができます。 高レベルのメリットとしては、読み取り集中型ワークロードではデータベースのキャッシュ効率の向上とディスク I/O ブロック読み取りの抑制、書き込み集中型ワークロードではジャーナルの書き込みスループットの向上を得られます。
さらに、古いハードウェアを更新し、パフォーマンスとスケーリングの改善を検討しているユーザーにとって、DCPMM を備えた Cascade Lake に基づくサーバーは優れた更新パスとなります。 InterSystems のテクノロジーアーキテクトと相談しながら、既存のワークロードに推奨される構成についてのアドバイスを得ることができます。
読み取り集中型ワークロードでは、512 GiB と 2 TiB のデータベースキャッシュサイズの E7v4（Broadwell）と Intel® Optane™ DC パーシステントメモリ（DCPMM）を使用した 1 TB と 2 TB のデータベースキャッシュサイズの最新の第 2 世代 Intel® Xeon® スケーラブルプロセッサ（Cascade Lake）と比較する分析クエリベンチマークを使用しました。
より大規模なキャッシュの影響とパフォーマンスの向上を示すために、さまざまなグローバルバッファサイズで複数のワークロードを実行しました。 構成を反復するごとに、COLD と WARM で実行しています。 COLD は、データベースキャッシュにデータが事前に入力されていない場合で、 WARM は、データベースキャッシュがすでにアクティブになっており、ディスクからの物理的な読み取りを減らすために、データが入力済みである（または少なくと可能な限り入力されている）ことを示します。
古い 4 ソケット E7v4（Broadwell）ホストを DCPMM を使った 4 ソケット Cascade Lake サーバーと比較しました。 この比較が選択されたのは、InterSystems IRIS を使ってハードウェアの更新を検討している既存のお客様がパフォーマンスの向上を得られることを実証するためです。 バージョン間のソフトウェアの最適化が要因とならないように、すべてのテストには同じバージョンの InterSystems IRIS が使用されました。
ディスクパフォーマンスが比較の要因とならないように、すべてのサーバーには同一のストレージアレイにある同一のストレージが使用されています。 ワーキングセットは 1.2 TB のデータベースです。 図 1 にはこのハードウェア構成と、それぞれの 4 ソケット構成の比較が示されています。
図 1: ハードウェア構成
| サーバー #1 の構成 | サーバー #2 の構成 |
|---|---|
| プロセッサ: 4 x E7-8890 v4 @ 2.5Ghz | プロセッサ: 4 x Platinum 8280L @ 2.6Ghz |
| メモリ: 2TiB DRAM | メモリ: 3TiB DCPMM + 768GiB DRAM |
| ストレージ: 16Gbps FC all-flash SAN @ 2TiB | ストレージ: 16Gbps FC all-flash SAN @ TiB |
| DCPMM: Memory Mode のみ |
512 GiB を 1 TiB か 2 TiB のいずれかの DCPMM バッファプールサイズと比較した場合、経過実行時間に大幅な短縮が見られます（約 6 分の 1）。 さらに、2 TiB E7v4 DRAM と 2 TiB Cascade Lake DCPMM の構成を比較した場合には約 20% の改善も見られました。 バッファプールのサイズが同じであるとした場合、この 20% の増加は、ほぼ新しいプロセッサのアーキテクチャとプロセッサのコア数の増加によるものだと考えられますが、 それでも、テストされた 4 ソケット Cascade Lake にインストールされていたが 24 x 128 GiB DCPMM のみであることを考慮すると深い意義があります。DCPMM は 12 TiB までスケーリングすることが可能であり、これは E7v4 が同じ 4 ソケットサーバーのフットプリントでサポートできるメモリの約 4 倍のメモリです。
以下の図 2 に示されるグラフは、この比較の結果を示しています。 両方のグラフの y 軸は経過時間（値が小さくなるほど良）で、さまざまな構成で得た結果が比較されています。
このベンチマークのワークロードは、すべての T4 タイプのワークロードを使用した HL7v2 メッセージングワークロードです。
各システムは 128 個のインバウンドビジネスサービスと各インバウンドインターフェースに送信される 4800 件のメッセージ（インバウンドメッセージ合計 614,400 件、アウトバウンドメッセージ合計 2,457,600 件）で構成されています。
このベンチマークワークロードのスループットの単位は「1秒あたりのメッセージ数」です。 トランザクションジャーナルのスループットとレイテンシは高スループットを維持する上で重要なコンポーネントであるため、ベンチマーク実行中のジャーナルの書き込みにも関心があります（記録されています）。 IRIS for Health のメッセージ耐久性保証のパフォーマンスに直接影響を与えるため、その操作において、トランザクションジャーナルの書き込みパフォーマンスが重要となります。 ジャーナルのスループットが低下すると、アプリケーションプロセスによってジャーナルバッファの可用性が阻止されてしまいます。
書き込み集中型ワークロードでは、2 ソケットサーバーを使用することにしました。 192 GB の DRAM と 1.5 TiB の DCPMM しかないため、この構成は前述の 4 ソケット構成よりも小さくなります。 DCPMM を使用した Cascade Lake のワークロードを以前の初代 Intel® Xeon® スケーラブルプロセッサ（Skylake）サーバーに比較しました。 両サーバーには 750GiB Intel® Optane™ SSD DC P4800X ドライブがローカル接続されています。
図 3 にはこのハードウェア構成と、それぞれの 2 ソケット構成の比較が示されています。
図 3: 書き込み集中型ワークロードのハードウェア構成
| サーバー #1 の構成 | サーバー #2 の構成 |
|---|---|
| プロセッサ: 2 x Gold 6152 @ 2.1Ghz | プロセッサ: 2 x Gold 6252 @ 2.1Ghz |
| メモリ: 192GiB DRAM | メモリ: 1.5TiB DCPMM + 192GiB DRAM |
| ストレージ: 2 x 750GiB P4800X Optane SSD | ストレージ: 2 x 750GiB P4800X Optane SSD |
| DCPMM: Memory Mode ＆ App Direct モード |
テスト 1: このテストでは、図 3 のサーバー #1 構成に示される Skylake サーバーにおいて前述の**T4 ワークロード**を実行しました。 Skylake サーバーは、2010 ジャーナル書き込み/秒のジャーナルファイル書き込み速度で約 3355 件のインバウンドメッセージの持続的なスループットを示しました。
テスト 2: このテストでは、図 3 のサーバー #2 構成に示される Cascade Lake サーバーにおいて、DCPMM の Memory Mode を指定して同じワークロードを実行しました。 これは、2400 ジャーナル書き込み/秒のジャーナルファイル書き込み速度で約 4684 件のインバウンドメッセージの持続的なスループットという大幅な向上を示しました。 これは、テスト 1 に比較すると 39% の増加です。
テスト 3: このテストでは、図 3 のサーバー #2 構成に示される Cascade Lake サーバーにおいて同じワークロードを実行しましたが、今度は DCPMM を App Direct Mode に指定し、DCPMM による何らかの実行を構成せずに実行しました。 このテストの目的は、DRAM のみを使用した Cascade Lake のパフォーマンスとスループットを DCPMM と DRAM を使用した Cascade Lake に比較して測定することです。 DCPMM が使用されていない場合でもスループットは（比較的小さいとは言え）向上したという、特に驚くことでもない結果が出ました。 これは、2540 ジャーナル書き込み/秒のジャーナルファイル書き込み速度で約 4845 件のインバウンドメッセージの持続的なスループットという向上を示しました。 DCPMM は DRAM に比べてより高いレイテンシがあり、更新が大量に流入すればパフォーマンスが低下するため、予想された動作と言えます。 別の見方をすると、まったく同じサーバーで DCPMM を Memory Mode で使用する場合、書き込みの取り込みワークロードに 5% 未満の低下があることになります。 また、Skylake を Cascade Lake（DRAM のみ）に比較した場合、テスト 1 の Skylake サーバーに比べて 44% の増加が得られています。
テスト 4: このテストでは、図 3 のサーバー #2 構成に示される Cascade Lake サーバーにおいて同じワークロードを実行しましたが、今度は DCPMM を App Direct Mode に指定し、App Direct Mode をジャーナルファイルシステム用にマウントされた DAX XFS として使用して実行しました。 これは 2630/秒のジャーナルファイル書き込み速度で 1 秒あたり 5399 件のインバウンドメッセージというさらに高いスループットを示しました。 この種のワークロードでは App Direct Mode の DCPMM がより適した DCPMM の使用方法であることが示されています。 これらの結果を最初の Skylake 構成と比較すると、テスト 1 の Skylake サーバーに比べ、スループットが 60% 増加しています。
Intel® Optane™ DC パーシステントメモリを使用することで InterSystems IRIS にメリットが与えられるユースケースと構成にはいくつかあります。
このモードは、単一の InterSystems IRIS デプロイや大規模な InterSystems IRIS シャードクラスタでの膨大なデータベースキャッシュに最適です。後者の環境ではより多く（またはすべて）のデータベースをメモリにキャッシュできます。 DCPMM と DRAM の比率は最大 8:1 にすることをお勧めします。「ホットメモリ」を L4 キャッシュレイヤーとして機能する DRAM に保持する際に重要です。 これは、リソース占有やその他のメモリキャッシュラインなど、共有内部 IRIS メモリ構造において特に重要となります。
このモードは、DCPMM をトランザクションジャーナルファイルのディスクデバイスとして使用する場合に最適です。 DCPMM は Linux にマウントされた XFS ファイルシステムとしてオペレーティングシステムに表示されます。 DAX XFS を使用するメリットは、これによって PCIe バスのオーバーヘッドとファイルシステムからのダイレクトメモリアクセスが緩和されることにあります。 HL7v2 ベンチマークの結果に示されるように、書き込みレイテンシによって HL7 メッセージングのスループットは大幅に向上します。 また、ストレージには従来のディスクデバイスと同様に、再起動や電源サイクル時における永続性と耐久性が備わっています。
このユースケースでは、App Direct モードの用法がトランザクションジャーナルと書き込みイメージジャーナル（WIJ）の両方に拡張されます。 両ファイルは書き込み集中型であるため、超低レイテンシと永続性のメリットを確実に得られます。
DCPMM を Dual Mode で使用すると DCPMM のメリットが拡大し、トランザクションジャーナルや書き込みイメージジャーナルデバイスで大規模なデータベースキャッシュと超低レイテンシを実現できるようになります。 このユースケースでは、DCPMM は OS にマウントされた XFS ファイルシステムとオペレーティングシステムの RAM として表示されます。 これは、DCPMM の一定の割合を DAX XFS に割り当て、残りを Memory Mode に割り当てることで可能です。 前述のように、インストールされている DRAM はプロセッサの L4 のようなキャッシュとして機能します。
疑似 Dual Mode 寄りにユースケースモデルを拡張するために、OLTPタイプのワークロード用と分析または大規模なクエリーニーズ用に高速のインバウンドトランザクションと更新が伴うトランザクションと分析の並行ワークロード（HTAP ワークロードとしても知られています）タイプのワークロードがあり、さらに InterSystems IRIS 共有クラスタ内ではそれぞれの InterSystems IRIS ノードタイプが DCPMM のさまざまなモードで稼働しています。
この例では、グローバルバッファの大規模データベースキャッシュと、トランザクションワークロード用に DAX XFS として Dual Mode または App Direct のいずれかで実行するデータノードのメリットを得られるように、DCPMM Memory Mode で実行する大規模なクエリ/分析ワークロードを処理する InterSystems IRIS 計算ノードが追加されています。
インフラストラクチャの選択に関して言えば、InterSystems IRIS には多数のオプションが提供されています。 インフラストラクチャの要件はアプリケーション、ワークロードプロファイル、およびビジネスニーズによって決まり、これらのテクノロジーとインフラストラクチャの選択が、ビジネスにおけるアプリケーションの成功、採用、および重要性を左右します。 第 2 世代 Intel® Xeon® スケーラブルプロセッサと Intel® Optane™ DC パーシステントメモリを使用した InterSystems IRIS は、ビジネスに大きな影響を与える InterSystems IRIS ベースアプリケーションに画期的なスケーリング性能とスループット性能を与えることができます。
InterSystems IRIS と Intel DCPMM 対応サーバーには、次のようなメリットがあります。
お客様の InterSystems IRIS ベースのアプリケーションに最適なハードウェア構成についてのご相談は、InterSystems テクノロジーアーキテクトにお問い合わせください。
これは InterSystems FAQ サイトの記事です。
管理ポータル接続時に指定しているWeb サーバポートが正しい番号を指定しているかご確認ください。
Windows にクライアントツールのインストールを行っている場合は、ランチャーに登録している接続サーバの設定に問題がある場合が考えられます。
ランチャー > 優先接続サーバ > 追加／編集 で、接続先の Webサーバポートが正しく設定されているかご確認ください。
.png)
Web サーバポートが不明な場合は、インストールディレクトリにある構成ファイル（cache.cpf または iris.cpf）をテキストエディタで開き、“WebServerPort” の項目で確認できます。
例）
【IRIS2018.1～】
WebServerPort=52773
【Caché2009.x～】
WebServerPort=57772
【Caché5.1～2008.x】
WebServer=ON,57772
これは InterSystems FAQ サイトの記事です。
バージョン5.1以降、データベース単位に暗号化する仕組みが用意されています。
InterSystems data platform のデータベース暗号化は物理ブロックレベルの暗号化ですので、暗号化のオーバヘッドが非常に少なく、性能への影響が極小化されており、暗号化されている項目のインデックス化に制限等がありません。
関連記事もご参照ください。
これは InterSystems FAQ サイトの記事です。
%Persistent クラスに既定で生成される Extent クエリは、ID 順に結果セットを出力することを意図していませんので、これは、仕様通りの動きとなります。
並び順は、設定されているインデックスにより、変わることがあります。
これは InterSystems FAQ サイトの記事です。
クラス定義の Property 定義文の名称を直接変更した場合、内部的には 元のプロパティを削除し、新しいプロパティを追加 したことになります。
このため、すでにデータを格納している永続クラスのプロパティ名をエディタで直接変更した場合、元のプロパティで設定されていた値にはアクセスができなくなります（新しいデータの格納位置が割り当てられます）。
また、変更したプロパティが必須（非ヌル）に指定されていた場合、データが存在しないために参照時にエラーが発生します。
以下の図は、左画面が変更前の状態、右画面がプロパティ名を変更してコンパイルを行った状態です。
基本的に、このような操作を行う場合は、あらかじめデータをエクスポートし、データの削除を行い、クラス定義の変更を行ってから、データを再インポートする方法が安全です。
または、スタジオのメニューの クラス > リファクタ > 名前変更 を利用してプロパティ名を変更します。
（リファクタの名前変更メニューにより、クラス定義内のストレージやメソッド定義に対して、一括でプロパティ名を変更できます。）
変更対象のクラス定義を開き、修正したいプロパティ名を選択し、スタジオのメニューの クラス > リファクタ > 名前変更 を選択します。
これは InterSystems FAQ サイトの記事です。
同一システムに InterSystems 製品を複数インストールした場合、ドライバマネージャに登録される InterSystems 用の ODBCドライバは、インストールされた製品の中で最新バージョンのドライバが登録されたままとなります。
以下のレジストリエントリを変更することで、任意のドライバへ変更できます。
なお、RegFiles.bat 実行では ODBCドライバは切り替わらないのでご注意ください。
レジストリエントリは、以下の通りです。
上記エントリには、現在使用中のドライバへのパスが記録されています。
これらを、切り替える対象となるドライバが存在するパスに変更してください。
これは InterSystems FAQ サイトの記事です。
接続先クライアントのIPアドレス取得するには、以下の方法で %SYS.ProcessQuery クラスを使用します。
(a) 対象プロセス ID を指定して、ClientIPAddress プロパティ を参照します。
Set Process=##CLASS(%SYS.ProcessQuery).%OpenId("8656")
Write Process.ClientIPAddress
(b) 全てのプロセスの情報を知りたい場合は、必要な情報のみ取得する SQL クエリを作成し、クラス内で実行することができます。
例） SELECT * FROM %SYS.ProcessQuery で詳細情報を取得できます。
詳細は、以下ドキュメントをご参照ください。
%SYS.ProcessQueryについて【IRIS】
%SYS.ProcessQueryについて
これは InterSystems FAQ サイトの記事です。
管理ポータルで設定できるメモリ関連の項目は、以下の通りです。
（項目としては他にもありますが、ここでは、ほとんど設定する必要のないものについては記載していません。）
管理ポータル [ホーム] > [システム管理] > [構成] > [システム構成] > [メモリと開始設定]
古いバージョンのメニューは以下の通りです。
【バージョン5.1～2010.x】
システム管理ポータル [ホーム] > [構成] > [メモリと開始設定] の設定内容
* データベースキャッシュ用メモリ
* ルーチンキャッシュ用メモリ 【バージョン2011.1.0～】
管理ポータル [ホーム] > [システム管理] > [構成] > [追加の設定] > [メモリ詳細設定]【バージョン 5.1～2010.x】
システム管理ポータル [ホーム] > [構成] > [メモリ詳細設定] の設定内容
* 一般メモリヒープ【gmheap】
* ロックテーブル【locksiz】
* IJCバッファ【ijcbuff】
* IJCデバイス【ijcnum】※カテゴリ：IO
* 照合テーブル最大数【nlstab】
設定の詳細は以下の通りです。
2023/9/1更新 添付のPDFに古い記載がありましたので、本文内を最新情報に更新しています。添付ではなく本文をご参照ください。
これは InterSystems FAQ サイトの記事です。
ユーザーが作成したクラス定義は、クラス定義クラスの中に格納されます。
クラス定義一覧をプログラムから取得する方法として、「クラス定義クラス」を利用することができます。
メモ：クラス定義クラスとは、%Dictionary パッケージに含まれるクラス全般のことをさします。
以下サンプルコードでは、%Dictionary.ClassDefinitionQuery クラスの Summary クエリを利用してクラス定義一覧を取得しています。
これは InterSystems FAQ サイトの記事です。
InterSystems 製品を利用した REST/JSON の操作方法を、簡単なサンプルを利用して解説します。
サンプルでは、REST クライアント、HTML、ターミナルからデータ（JSON）を送信し、サーバ（InterSystems製品）で JSON 形式のデータを返す REST ディスパッチクラスを使った簡単な流れになっています。
サンプルは、https://github.com/Intersystems-jp/FAQ-REST-SimpleSample からダウンロードいただけます。
RESTディスパッチクラスとサンプルHTMLファイルが含まれています
管理ポータルからインポートします（スタジオを利用されている場合は、スタジオでもインポートできます）。
管理ポータルは http://localhost:52773/csp/sys/UtilHome.csp でアクセスできます。
※ ポート番号はお使いの環境に合わせて変更してください。
管理ポータルにアクセスできたら以下メニューでインポートを行ってください。
これは InterSystems FAQ サイトの記事です。
HL7 メッセージの送受信を行うプロダクションでは、以下３個のグローバルが非常に大きくなることがあります。
グローバルの大きさを確認する場合は、^%GSIZEユーティリティを利用します。詳細は関連トピック／記事をご参照ください。
^EnsHL7.Segment
^EnsLib.H.MessageD
^EnsLib.H.MessageI
HL7メッセージは EnsLib.HL7.Message.cls で定義されます。
^EnsLib.H.MessageD はデータを保存するグローバル、^EnsLib.H.MessageI はインデックスを保存するグローバルです。
また、HL7メッセージは多数のセグメントで構成されており、メッセージデータを含むそれらのセグメントは ^EnsHL7.Segment に保存されます。
^EnsLib.H.MessageD グローバルの値は、^EnsHL7.Segment グローバルの添え字にリンクしています。
これらメッセージ関連のグローバルの削除については、任意の保持日数を指定して手動および定期的に削除することができます。
パージ（Purge）用ユーティリティについては、以下のドキュメントをご参照ください。
関連トピック／記事
これは InterSystems FAQ サイトの記事です。
%Net.FtpSession クラスを使用して FTP サーバから、アップロード／ダウンロードする方法をご紹介します。
1. FTPサーバにイメージファイルをアップロードする
これは InterSystems FAQ サイトの記事です。
ユーザ定義エラーとして使用したいエラーコードと対応するメッセージを記述したXMLを用意します。
なお、エラーコードは負の整数で設定してください。
<?xml version="1.0" encoding="UTF-8" ?>
<MsgFile Language="ja">
<MsgDomain Domain="UserErrors">
<Message Id="-111" Name="MyError">エラーが発生しました</Message>
<Message Id="-222" Name="MyError2">エラーが発生しました２</Message>
</MsgDomain>
</MsgFile>
XML ファイルが作成できたら使用したいネームスペースにロードします。
set x=##class(%MessageDictionary).Import("error.xml")
ロード完了後、次のようなコマンドでユーザ定義エラーを取得、表示することができます。
これは InterSystems FAQ サイトの記事です。
ソースプログラムのコンパイル後に生成される *.obj のみをエクスポート／インポートすることでソースの隠蔽化を実現できます。
コマンド実行例は、EX1Sample.mac と EX2Sample.mac のコンパイルで生成される EX1Sample.obj と EX2Sample.obj をエクスポート対象に指定し、第2引数のファイルにエクスポートしています。
別ネームスペースに移動したあと、エクスポートした XML ファイルを利用してインポートを実行しています。
これは InterSystems FAQ サイトの記事です。
このエラーが発生する原因としては、アプリケーションの中で既に他のプロセスからロック対象リソースがロックされていて、何らかの理由でそのロックが解放されていないケースが考えられます。
他のプロセスがロックしている兆候がない場合は、ロックテーブルの空き領域が不足しているケースが想定されます。
その場合は、メッセージログ（コンソールログ）に LOCK TABLE FULL のメッセージが出力されます。
トランザクション処理を行なっている場合には、ロック解放の延期が影響しているケースも考えられます。
トランザクションとロック解放の延期については、以下のドキュメントをご参照下さい。
また、トランザクション中に、同一テーブルに対する大量レコードのSQL 文による更新がある場合、ロックしきい値（既定値は1000）に到達してロックエスカレーションが発生し、その結果として、テーブルロック状態になっている可能性もあります。
このように、ロックタイムアウトエラーの原因は幾つか考えられますので、まずは、管理ポータル（バージョン2010.2以前では、[システム管理ポータル]）の、ロックメニューにて、現在のロックの状態をご確認下さい。
これは InterSystems FAQ サイトの記事です。
クラスに定義されたプロパティの情報については、以下システムクラスを利用して情報を取得できます。
%Dictionary.PropertyDefinition
コード記述例は以下の通りです。
これは InterSystems FAQ サイトの記事です。
INFORMATION_SCHEMA スキーマを使用して取得できます。
INFORMATION_SCHEMA はシステム用スキーマのため、デフォルトでは管理ポータルのSQLメニューに表示されません。
表示させる方法は以下の通りです。
指定のテーブル（ISJ.Class1）に対するID、フィールド名（COLUMN_NAME）、データタイプ（DATA＿TYPE）、説明（DESCRIPTION）を取得するSQLは以下の通りです。
SELECT ID,COLUMN_NAME,DATA_TYPE,DESCRIPTION
FROM INFORMATION_SCHEMA.COLUMNS
where TABLE_SCHEMA='ISJ' AND TABLE_NAME='Class1'これは InterSystems FAQ サイトの記事です。
引数名の後ろに ... をつけることで可変の引数を渡すことができます。
ObjectScript では、配列を使って任意の数の引数を渡すことができます。
例文は以下の通りです。
例文では、メソッド実行後に確認しやすいように、グローバル変数（＝データベースに格納される変数）に引数の情報を設定しています。
Class TEST.ARGTEST1 Extends %RegisteredObject
{
ClassMethod NewMethod1(Arg... As %String) As %Boolean
{
kill ^a
merge ^a = Arg
}
}
ターミナルで実行した結果は以下の通りです。
USER>DO ##class(TEST.ARGTEST1).NewMethod1(1,2,3,4,5)
USER>ZWRITE ^a
^a=5
^a(1)=1
^a(2)=2
^a(3)=3
^a(4)=4
^a(5)=5これは InterSystems FAQ サイトの記事です。
MM/DD-hh:mm:ss:938 ( 0) 1 Failed to allocate xxxMB shared memory using large pages. Switching to small pages.
MM/DD-hh:mm:ss:938 ( 0) 0 Allocated xxxMB shared memory: yyyMB global buffers, zzzMB routine buffers
コンソールログ（cconsole.log/messages.log）に上記のようなメッセージがある場合は、Large Page でのメモリ確保に失敗して、Small Page でメモリを確保したことを示しています。
Allocated xxxMB が設定サイズと同じ場合、Small Pageでメモリ確保ができていますので、設定サイズを減らす必要はありません。
このメッセージは、起動時に十分な空きメモリが連続領域で確保されていないために発生しています。
デフォルトの設定では、WindowsOS が管理するメモリ領域の中で Large Page という領域にメモリを連続的に確保します。