#Caché

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 サイトの記事です。

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

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

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

インスタンスの開始が失敗し、コンソールログに"There exists a MISMATCH.WIJ file"が記録されている場合、何らかのシステム障害の影響でデータベースの整合性に関して問題が生じていることを示しています。

このような状況が発生した際にインスタンスの開始ができるようにするためには、以下の手順を実施します。

(1) a. インスタンスをNOSTUモードで起動
(2) b. データベースの整合性チェック

◆(2)の整合性チェックでエラーを検出しなかった場合、
　(3) d. MISMATCH.WIJ ファイルのリネーム
　(4) e. インスタンスの再起動
を実施します。

InterSystems は、より新しく優れたオプションが利用可能になったときに従来のテクノロジーの開発を中止することがあります。
ただし、それら機能は最小サポートバージョン以後の製品であれば他の機能と同等にサポートします。

InterSystems IRISのSQLの性能を評価する簡単なベンチマークテストを公開します。

また、このベンチマークプログラムで測定した過去の様々なハードウェアでのベンチマーク結果も公開します。

ハードウェアの進歩、インターシステムズの新しいテクノロジーの追加や性能改善によって、性能が劇的に変化しています。

現在のハードウェアの性能を考慮すると、少し物足りない感じが否めないですが、過去との結果の公正な比較という意味であえて、データの規模に関しては過去と同一条件でベンチマーク実施した結果となっています。

データの規模に関してはデータ件数を増やすことで変更できるようになっています。（現時点では500万件）

またこのベンチマークプログラムはインターシステムズ製品用に実装されていますが、使用しているテーブル構造は比較的シンプルなもので、また使用しているSQL文も標準的なものなので、他データベースシステムでも同じベンチマークを実施することはそんなに困難ではありません。

ベンチマークプログラムのリポジトリ

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

SQLのINSERT/UPDATE/DELETE文で大量のデータを更新する際に、高速化する方法をご紹介します。
以下の2つの手順を実行することで、更新処理のパフォーマンスを向上させることが可能です。

１．INSERT/UPDATE/DELETE時にインデックスを作成せず、あとでまとめて作成する

２．INSERT/UPDATE/DELETE時にジャーナルをOFFにする

１は、%NOINDEX キーワードを指定してインデックスの生成を後でまとめて行うことで、インデックスの構築を抑制しパフォーマンスを向上させる方法です。

クエリ実行例は、以下のようになります。

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

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

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

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

※インデックスの再構築が完了したら、必ず指定を元に戻してください。

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

VSCodeのObjectScriptエクステンションを利用してInterSystems製品に接続するときに「プライベートWebサーバ (*1)」ではなく、「Webサーバ（IISやApache）」を利用される場合、接続時に使用するREST用パスが通るようにWebサーバに仮想パスを追加する必要があります。

(*1) プライベートWebサーバとは、バージョン2023.1以前のInterSystems製品をインストールすると自動でインストールされる簡易的なApacheで、52773番ポートで管理ポータルやWebアクセスのテストにご利用いただけるWebサーバです。（本番運用環境には適さない簡易的なWebサーバです）

対象バージョン：2023.1以下のInterSystems製品

追加が必要なパス：　/api