#Caché

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

messages.logまたはcconsole.log内に記録されるCSPGatewayLatencyのメッセージは、サーバが、パフォーマンス測定のため定期的に「CSPゲートウェイにリクエストを送信して応答をもらう」ことを行っており、応答を受け取るまで一定時間以上かかったときに出る警告(応答時間の閾値）です。

その既定値は1000ミリ秒です。

WebGateway（CSPGateway）が稼働する Web サーバの負荷が高い場合に出力する場合がありますが、実際のCSPアプリケーションやREST APIの動作や応答速度に影響が見られなければ、特に問題はありません。

またこのメッセージの出力頻度を下げるためにこの閾値を変更する方法もあります。

変更方法は以下を参照ください

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

HTTPレスポンスヘッダ情報を取得したい場合、以下のような方法があります。
開発中などに、送られてきたヘッダの項目名、そのデータを確認したい場合に、是非ご活用ください。

%UnitTest framework を使用してユニットテストを構築したことがある場合、またはこれから構築しようとお考えの場合は、InterSystems Testing Manager をご覧ください。

VS Code を離れることなく、ユニットテストの閲覧、実行またはデバッグ、過去の実行結果の表示が可能になりました。

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

区切り識別子は、区切り文字で囲まれた一意の識別子です。
InterSystems SQL は、その区切り文字として二重引用符 「"」 をサポートしています。
一方、リテラル値を区切る場合は、一重引用符「'」を使用します。
例えば、下記のSQLにおいて、
①は、Nameの値が「AAA」という文字列である、という検索条件と解釈されますが、
②は、Name列 = AAA列、という結合条件と解釈されます。※実際にAAA列が無ければエラーとなります。

①

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

新しいインデックスを定義した後、インデックスの再構築が完了する前にクエリを実行するとデータが存在しているにもかかわらず「検索結果0件」や検索結果数が徐々に増えるような状況が発生します。

インデックスを永続クラス定義（またはテーブル定義）に追加しコンパイルすることで今まで使用していたクエリ実行経路が削除され、再度同じクエリを実行するタイミングで新しいインデックス定義を含めた実行経路が作成されるためです。（この時にインデックス再構築が完了していないとインデックスデータが存在しない、または不完全であるため0件や徐々に検索結果数が増えるような状況を起こします。）

これを起こさなために、新しいインデックスの再構築が終了するまでクエリオプティマイザにインデックスを使用させないように指定する方法が用意されています。

※ 2024/8/2： 2024.1以降から利用できる方法を追加しました。

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

ジャーナルファイルのサイズが大きすぎて、管理ポータルで検索やフィルタリング等できない場合、以下の2つの方法で参照することができます。

① ^JRNDUMP ユーティリティを使用する方法
② プログラムで参照する方法

============================================================

① ^JRNDUMP ユーティリティを使用する方法 例えば、グローバル参照 ^ABC を含むジャーナルファイルのすべてのレコードを選択する場合は、以下のようになります。

※以下、すべてのコマンドは %SYS ネームスペースで実行してください。

2024年10月15日をもって、MacOS での Caché および Ensemble のサポートが非推奨となります。

Caché および Ensemble 2018.1.9 のサポートは続きますが、MacOS 向けのメンテナンスバージョンは今後リリースされません。つまり、MacOS 向け製品としては、Caché および Ensemble 2018.1.9 が最後のバージョンとなる予定です。

あらためてのお知らせですが、その他のプラットフォームにおいても、Caché および Ensemble のメンテナンスバージョンは 2027年3月31日をもってリリース終了となる予定です。詳細は昨年発表の記事をご参照ください。

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

メッセージログ（messages.log）／コンソールログ(cconsole.log) に以下のようなメッセージが表示される場合があります。

このメッセージ出力は、ライトデーモンのデータベースファイルへの書き込み処理の遅延を示しています。
その原因としては、ディスクI/O負荷が高く、そのI/O要求量に対してディスク処理性能が不足していることが考えられます。

ディスクI/O負荷の原因としては以下が考えられます。

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

InterSystems製品のサーバサイドでファイル入出力を行うと、文字列はシステムで設定されたファイル入出力用文字コードに自動変換され、文字単位でREADします。

ファイルから入力する文字をバイト単位で操作するためには、自動変換を行わない無変換の状態でファイル入力を行い指定バイトずつ読みながら読んだ分だけUnicodeに手動で変換していく必要があります。

変換には$ZCONVERT()関数を使用します。（$ZCONVERT()には省略形があり$ZCVT()でも同様の操作が行えます。）

InterSystems製品のバックアップ方法の中の３つの目方法は、「並行外部バックアップ」についてです。

この方法は外部バックアップと異なり、スナップショットなどのストレージ機能がない環境に向いている方法でオンラインバックアップよりも高速にバックアップできます。（古いバージョンのInterSystems製品でも利用できるバックアップ方法です。）

ただし、バックアップやリストア手順が複雑になります。

並行外部バックアップの利用を検討される際は、事前にリストア手順についてもテスト環境などでご確認いただくことを推奨します。

開発者の皆さん、こんにちは。

この記事は、「インターシステムズ製品をバックアップする前に確認したいこと」に続く記事で、InterSystems製品のバックアップの手法の中の「外部バックアップ」の仕組みと、バックアップ・リストア手順について解説します。

まず、「外部バックアップ」とは、InterSystems製品の専用ルーチン使用せず、InterSystems製品以外のバックアップソリューションを使用してデータベースをバックアップする方法で、現時点の推奨されるバックアップ方法です。

前回、LinuxでODBC接続を行う方法 をご紹介しました。

今回は、LinuxでJDBC接続を行う方法 をご紹介します。作業は、root ユーザ で行います。

はじめに、Linuxのバージョンを確認します。

大きなサイズのデータを持つフィールドに対してインデックスを作成すると、<SUBSCRIPT>エラーとなることがあります。

これは、グローバルの添え字（サブスクリプト）のサイズには制限があり、制限を超えるとエラーとなるためです。

例えば、以下のようなインデックスの場合、

^Sample.PersonI("NameIdx"," xxx...xxx",1)       =       ""

グローバル名＋サブスクリプト部（＝の左側）が、エンコード文字数で最長 511 文字を超えるとエラーとなります（日本語の場合はもっと小さな文字数です）。

※ご参考：グローバル参照の最大長

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

クエリパフォーマンスを左右するクエリプランは、テーブルチューニングを行った結果の統計情報を元に生成されます。

ある環境で期待したプランになったけれど、他の環境では意図したプランにならない場合、（期待したプランとなる）既存環境からテーブル統計情報をエクスポートして別の環境にインポートし、同じ統計情報をもとにしたクエリプランで実行することができます。