アップグレード時の特別な考慮事項

すべてのバージョン。

このリリースでは、ほとんどの場合、$INCREMENT はデータ・ブロックの共有所有権のみで内部的に機能できます。これにより、同じブロック内に格納されているデータの同時読み取り、および同じブロック内に格納されているグローバル・ノードに対する $INCREMENT の同時実行 (ブロック内でコンペア・アンド・スワップを使用して実行される) が可能になります。アプリケーション・コードに対する $INCREMENT の意味は変わりません。

共有所有権により実行された $INCREMENT オペレーションのジャーナル・レコードが、ジャーナル・ファイルに誤った順序で表示されることがあります (^X を 100 に設定した $INCREMENT のジャーナル・レコードが、^X を 99 に設定したジャーナル・レコードよりも前に表示されるなど)。すべての $INCREMENT ジャーナル・レコードは、引き続き SET タイプを使用しますが、拡張タイプ SET ($I) または SET ($I if greater) も使用できるようになりました。 後者の値は、誤った順序で表示される可能性のある $INCREMENT オペレーションを表し、ジャーナル・レコードで取得された値がグローバル・ノードの現在の値より大きい場合にのみ、ジャーナル・リストアによって適用されます。$INCREMENT で生成されるジャーナル・レコードは予測できない点に注意してください。共有所有権を使用できるかどうかは、一部の内部条件に依存するためです。負のインクリメント値を使用する $INCREMENT は常に排他アクセスで実行され、拡張タイプ SET ($I) でジャーナリングされます。

SET レコードの値を使用してアクションを実行するカスタム・ロジックは、新しい拡張タイプ間であいまいさを解消しなければならないことがあります。ただし、それは、$INCREMENT レコードが出現する順序にロジックが左右される場合に限られます。

SYS.Journal.Record オブジェクトを使用してジャーナル・ファイルを読み取り、新しい ExtYpe および ExtTypeName プロパティにアクセスします。

%syJrnRecord.inc 内のマクロを使用してジャーナル・レコードにアクセスするカスタム・ロジックは、$INCREMENT オペレーションに対して $$$JRNINCRYP または $$$JRNINCRIGTYP を返す $$$JRNTYPE1 を使用して、拡張タイプ SET ($I) または SET ($I if greater) にアクセスできます。

すべてのバージョン。

スケジュールされているタスクの一部として InterSystems IRIS Business Intelligence キューブを構築または同期するインスタンス。

リレーションシップを持つキューブに対して %BuildCube()Opens in a new tab または %SynchronizeCube()Opens in a new tab を呼び出すと、メソッドは指定されたキューブに依存するすべてのキューブのリストを照合します。その後、メソッドは、正しい更新順序を自動的に決定して、指定されたキューブと依存キューブに対してそれぞれ更新操作を実行します。(現在、内部的には、メソッドは %BuildOneCube() と %SynchronizeOneCube() を呼び出して、個々のキューブを更新するようになっています。)

このため、これらのメソッドを呼び出して関連キューブを一度に 1 つずつ構築または同期する、このスケジュールされたタスクは、アップグレード時に不必要な重複するタスクを実行する可能性があります。

これに恒久的に対処するには ：

1. 関連キューブを確認します。どのキューブが他のキューブに依存しているか、どのキューブが依存していないかに注意してください。(依存キューブはリレーションシップのソース式を定義し、独立キューブは定義しません。)%DeepSee.CubeUtilsOpens in a new tab クラスの %GetCubeGroups() メソッドの出力をガイダンスとして参照してください。キューブに、そのキューブに依存するキューブがある場合は、出力 pCubes に pCubes(<cubeKey>, “dependents”) 配列が含まれます。この配列は、<cubeKey> で特定されたキューブが更新された後に、Business Intelligence が自動的に更新する依存キューブを特定します。

2. カスタムの更新方法を編集します。独立キューブに対する %BuildCube() または %SynchronizeCube() の呼び出しの直後に行われる、依存キューブに対する %BuildCube() または %SynchronizeCube() の呼び出しを削除します。

未完了のビジネス・プロセス・ログが多数存在するインスタンス。ビジネス・プロセス・インスタンスを表示して、未完了のビジネス・プロセス・ログが多数存在するかどうかを評価します。

未完了のビジネス・プロセス・ログは自動的には削除されないため、インスタンスに未完了のビジネス・プロセスが多数存在する可能性があります。アップグレード・プロセス中に、これらのログのストレージはアップグレードされます。未完了のビジネス・プロセスが多数ある場合、アップグレードが遅くなり、失敗する可能性があります。

この問題に対処するには、アップグレードする前に、未完了のビジネス・プロセスを削除します。未完了のビジネス・プロセスも削除されるように、[完了したセッションのみ削除]([整合性を保持]) 設定を無効にしてください。ビジネス・プロセスは、以下のようなコマンドを実行することで (pDaysToKeep を整数に設定)、メッセージのパージ API を使用して削除できます。

Set tSC=##class(Ens.BusinessProcess).Purge(.tDeletedCount,pDaysToKeep,0)

2022.1.5 以前。

Windows 上で実行されているインスタンス。

irisstop.exe ファイルがアップグレード時に削除されます。このファイルがないと、内部の手段を使用して InterSystems IRIS インスタンスを停止することはできません。例えば、iris stop コマンドは機能しません。

この問題に恒久的に対処するには ：

1. irisstop.exe ファイルのコピーを取得します。これを行うには、アップグレードする前にインスタンスからファイルをコピーするのが最も簡単です。

   • irisstop.exe ファイルは、2019.1 以降の任意のインスタンスからコピーできます。

   • 適切なインスタンスがない場合は、IRIS (バージョン 2024.2 を含む) の一時インスタンスをインストールして、そこから irisstop.exe ファイルをコピーできます。

   • 既定では、このファイルは <install-dir>/InterSystems/<instance-name>/bin/ にあります。

2. 通常どおりに、アップグレードを進めます。

3. アップグレード後、irisstop.exe ファイルのコピーをアップグレードしたインスタンスに追加します。

4. アップグレードしたインスタンスで、ファイル <install-dir>/InterSystems/<instance-name>/bin/iristray.exe を実行します。

5. アップグレードしたインスタンスで InterSystems IRIS ランチャー・メニューを開いて、[終了] をクリックします。

6. Windows の [スタート] メニューで、アプリケーション [Launcher [<instance-name>]] をクリックし、インスタンスを起動します。

上記の手順を実行する前に、[サービス] Windows 管理ツールを使用して、InterSystems IRIS インスタンスを手動で停止できます。[サービス] を開き、[InterSystems IRIS Controller for <instance-name>] サービスを右クリックして、[停止] をクリックします。

2022.1.1 以前。

MAXLEN="" のプロパティを含む既存のクラスがある環境。

既存のクラスに MAXLEN="" のプロパティが含まれる場合、そのクラスに基づくテーブルに対する SQL クエリは、アップグレード後にエラーを返します。

影響を受けるクラスをリコンパイルします。

2022.1.1 ～ 2021.1.0

外部言語ゲートウェイ構成がすべて削除された環境。

アップグレード・プロセス中に検証エラーが発生することがあります。

これらのエラーを防ぐには、任意のポート番号を持つローカル・ゲートウェイを指すリモート･タイプの単一ゲートウェイ構成を追加します。例えば、[サーバ名 / IPアドレス] を 127.0.0.1、[ポート] を 1 に設定し、ForUpgrade という名前を付けることができます。この操作はアップグレード前の任意の時点で実行でき、通常のシステム･オペレーションに影響を与えません。この構成は、アップグレードの完了後に削除できます。

2019.2 以前。

2019.2 以前のリリースの永続的な %SYS を使用している環境。

このリリースでは、ディストリビューション・コンテナに非 root の既定ユーザがあります。これにより、コンテナのセキュリティが向上します。このバージョンの InterSystems IRIS を実行する前に、ホストの永続的なディレクトリ内の一部のファイル所有権を変更する必要があります。このような変更を行わない場合、InterSystems IRIS の起動時にコンテナでエラーが発生します。

関連するファイル所有権の変更に関する手順は、担当のインターシステムズ・セールス・エンジニアまたはインターシステムズのサポート窓口Opens in a new tabにお問い合わせください。