Ensemble のアップグレード

Ensemble 2007.1 以降からのアップグレード

Ensemble 2007.1 以降から Ensemble のこのリリースにアップグレードする場合は、Caché のアップグレードに関するドキュメントに説明のあるファイルが削除されるほか、以下の Ensemble ファイルも削除されます。

• ENSDEMO ネームスペースにあるすべてのユーザ・ファイル

• 通常 Ensemble 用に予約されているパッケージ内のユーザ・ファイル (CSPX、Demo、Ens、または EnsLib)

これらのネームスペース内のいずれかのファイルをカスタマイズした場合や、これらのネームスペースに新しいファイルを追加した場合は、アップグレード前にそれらのファイルを保持する必要があります。これらのファイルを保持するには、アップグレードを実行する前にエクスポートする必要があります。アップグレードが完了した後で、エクスポートしたファイルを任意のネームスペースにインポートします。

既存の Ensemble インストールを Ensemble のこのリリースにアップグレードする手順は次のとおりです。

1. 実行中のすべてのプロダクションを終了します。

2. すべてのネームスペースですべてのプロダクションの自動開始オプションを無効にします。"Ensemble の管理" の “プロダクション自動開始の管理” を参照してください。

3. アップグレード時に削除されるファイルを保持するには、それらをエクスポートしておきます。

4. Ensemble 2010.2 またはそれ以前の Ensemble でカスタムの検索テーブルを使用しており、既存の Ensemble をアップグレードする場合は、アップグレード前に ENSLIB ネームスペースでターミナルから以下のコマンドを実行して、既存のメタデータを再配置するための準備をします。

   ENSLIB>Merge ^%SYS("Ensemble","Upgrade","SearchTable","Data") = ^Ens.Config.SearchTablePropD
   
   

   

   アップグレード時に、Ensemble によってこの場所がチェックされ、元の検索テーブル・クラスが存在するネームスペースに既存のメタデータが追加されます。この処理は、該当するネームスペース内の検索テーブルのコンパイル前に実行されます。詳細は、"Ensemble リリース・ノート" の “アップグレードの互換性の問題” の章で “検索テーブルの検証の更新” を参照してください。

   アップグレード・プロセスでは、すべての検索テーブル・クラスが自動的にリコンパイルされるため、アップグレード後にコンテンツをインポートしたり、グローバルを破棄したりしないでください。アップグレード・プロセスでは、アップグレード後も検索テーブルのメタデータが正しく維持されるように確実に処理されます。また、変換後のデータの整合性も保証されます。そのため、アップグレードを実際に開始する前に、アップグレード・プロセスを十分にテストし、元のメタデータに何か問題が見つかった場合は事前に対処することを強くお勧めします。

5. 大規模なメッセージ・ウェアハウスがあり、テーブルのチューニングを実行した場合、または拡張サイズの値と選択性の値を手動で設定した場合は、新しいデフォルト値が既存のシステムに適合することを確認するか、またはアップグレード後にテーブルのチューニングを実行してください。テーブルのチューニングも、Selectivity 値の手動設定も行っていない場合は、通常、デフォルト値でパフォーマンスが向上します。

   このテーブルへのアクセスを最適化するための操作を行った場合、次の操作を実行して、アップグレード後にシステムが適切に動作することを確認してください。

   1. 現在のシステムの ExtentSize および Selectivity の各値を記録します。その方法の 1 つとして、スタジオで Ens.MessageHeaderOpens in a new tab クラスを開きます。ExtentSize と Selectivity は、コード・ウィンドウのクラス定義の末尾にリストされます。

   2. 値が新しいデフォルト値と大幅に異なる場合は、アップグレード後にテーブル・チューニングを実行するか、スタジオまたは管理ポータルで使用システムに合わせて ExtentSize および Selectivity の各値を手動で更新してください。

   Important:

   [クラスを最新状態に保つ] チェック・ボックスにチェックを付けておけば、実行中のシステムに対してテーブル・チューニングを実行できます。

   管理ポータルの システム, SQL, スキーマ, テーブル ページからのテーブル・チューニングの使用に関する詳細は、"Caché SQL 最適化ガイド" の “テーブルの最適化” の章にある “ExtentSize、Selectivity、および BlockCount” を参照してください。

6. "Caché インストール・ガイド" の “Caché のアップグレード” の説明に従って、Ensemble にアップグレードする準備を行います。

7. "Caché インストール・ガイド" で、該当するプラットフォームの章の説明に従って Ensemble をインストールします。

   • Microsoft Window への Caché のインストール

   • UNIX® および Linux への Caché のインストール

   • Macintosh への Caché のインストール

   各章では、特定のアップグレード手順について説明しています。

8. 以前の Ensemble インストールからエクスポートしたカスタム・スキーマまたはその他のプロダクション・コンポーネントやクラスがある場合は、スタジオまたは管理ポータルを使用してこれらをインポートします。必ず、各項目をエクスポートしたときと同じネームスペースにインポートしてください。

9. Ensemble のアップグレード後、定義済みのすべてのオブジェクトをリコンパイルする必要があります。そのための 1 つの方法は、カスタム・コードを含むネームスペース内の全オブジェクトをリコンパイルすることです。ネームスペースにあるすべてのオブジェクトをリコンパイルするには、ターミナル・ウィンドウを開き、以下のコマンドを実行します。

    ZN "namespace"
    DO $system.OBJ.CompileAll("u")

   

   このメソッドは、指定されたネームスペースで、クラス・ディクショナリのアップグレードとコンパイルの両方を実行します。

   $SYSTEM.OBJ.CompileAllNamespaces() メソッドを使用して、すべてのネームスペースをリコンパイルすることも可能ですが、HealthShare インストールのアップグレード時にはこれを実行しないでください。HealthShare で使用するネームスペースはリコンパイルしないでください。

   Important:

   クラスとスキーマのコンパイルは、それらを使用する DTL または BPL をコンパイルする前に実行する必要があります。複合アプリケーションでは、その他の依存性も考慮しなければならない場合があります。

   $SYSTEM.OBJ.CompileAll() の使用を推奨するうえで、コンパイル対象のアイテム間の依存性について、すべての情報がアイテムの宣言内に完全に含まれていることを前提としています。この情報は、DependsOn および CompileAfter などのコンパイラ・キーワードを含めることで設定できます。または、コードをコンパイルするルーチンを作成して、特にスキーマとドメイン固有の言語に関連して、コンパイラが認識できない依存性を考慮されるようにすることができます。

10. Emsenble のアップグレード処理では、アップグレードに関する重要な情報がログ・ファイルに報告されます。アップグレード後、Ensemble インスタンスの \mgr サブディレクトリにある ensinstall.log ファイルの内容を確認し、アップグレードの結果を確認します。

11. 以前のインストール環境で、Java ゲートウェイ、またはいずれかの Caché 言語バインディングを使用してプロキシ・クラスを生成していた場合、該当するドキュメントの指示に従って、ここでそのクラスを再生成します。

    • Java ゲートウェイの使用法

    • "Caché 言語バインディング" セット内のその他のドキュメント

12. 一部の旧リリースでは、プロダクションを自動的に開始するために、またはプロダクションの開始時にコードを自動的に実行するために、このコードを Caché ユーザ開始ルーチン ^%ZSTART に挿入していました。現在はこのコードは他の場所に属している必要があります。したがって、すべての Ensemble 関連コードをユーザ開始ルーチン ^%ZSTART から削除してください。以下の交換メカニズムを使用します。

    • プロダクションを自動的に開始するには、カスタム・コードではなく、Ensemble のプロダクション自動開始オプションを使用します。詳細は、"Ensemble の管理" の “プロダクション自動開始の管理” を参照してください。

    • プロダクションの起動時に実行するコードを特定します。プロダクション・クラス内の OnStart() コールバック・メソッドを上書きして、その中にそのコードを配置します。

    • プロダクションの起動時に特定のビジネス・ホストに対して機能するように設計されたコードを特定します。対応するビジネス・サービス・クラス、ビジネス・プロセス・クラス、またはビジネス・オペレーション・クラス内の OnProductionStart() コールバック・メソッドを上書きして、その中にそのコードを配置します。

    これらのコールバック・メソッドに関する情報は、"Ensemble プロダクションの開発" の “あまり一般的ではないタスク” を参照してください。

13. 必要に応じて、プロダクション自動開始オプションを再度有効にします。"Ensemble の管理" の “プロダクション自動開始の管理” を参照してください。

Ensemble 4.0 または 4.0.1 からのアップグレード

Ensemble 4.0 または 4.0.1 から Ensemble の最新リリースにアップグレードする手順は、それ以降のバージョンからアップグレードする手順と同じですが、考慮を必要とする点がいくつかあります。以下の列があります。

• アップグレード手順で、HL7 カスタム・スキーマ定義 (*.HL7) はすべて削除されます。

  Caution:

  これらのファイルを保持するには、アップグレードを実行する前にエクスポートする必要があります。アップグレードが完了した後で、エクスポートしたファイルを任意のネームスペースにインポートします。

• Ensemble 対応の各ネームスペースに対し、ターミナル・セッションから以下のコマンドを実行します。

   ZN "nextEnsembleNamespace"
   DO ##class(Ens.MessageHeader).%PurgeIndices()
   DO ##class(Ens.MessageHeader).%BuildIndices()
   DO ##class(EnsLib.HL7.Message).%PurgeIndices()
   DO ##class(EnsLib.HL7.Message).%BuildIndices()
   DO ##class(EnsLib.HL7.Message).%BuildIndices(($LB("Extent")))

  

  これらのコマンドは、ENSDEMO ネームスペース、ENSEMBLE ネームスペース、およびユーザ定義のすべての Ensemble 対応ネームスペースで必要です。

Ensemble ミラー・メンバのアップグレード

この節では、Ensemble ミラー構成をアップグレードするための手順を説明します。標準の Caché アップグレード手順を理解している必要があります。ミラー上での Ensemble の実行に関する一般的な情報は、"Caché 高可用性ガイド" の “ミラーリングにおける Ensemble の考慮事項” を参照してください。アップグレード手順の詳細は、"Caché インストール・ガイド" の “ミラーリングを使用した最小ダウンタイムのアップグレード” を参照してください。

ミラーを含むあらゆるアップグレードには、次の 2 種類の変更が関連します。

1. すべてのミラー・メンバ上で発生する変更 (CACHELIB および ENSLIB 内のライブラリ・コードの置換など)。

2. バックアップ・ミラー・メンバ上ではデータベース・アクセスは読み取り専用であるために、(プライマリ・フェイルオーバー・メンバ上で) 1 回だけ発生する、ミラー・データに影響を与える変更。

Ensemble のアップグレード・コードではこの区別が重視され、アップグレード中には両方の種類の変更を行う必要がある場合があります。重要な点として、Ensemble のアップグレード・コードは Ensemble 対応ネームスペースへのアップグレードをネームスペース単位で実行し、各ネームスペースにミラー・データが含まれているかどうかをチェックすることに留意してください。ネームスペースに何らかのミラー・データが含まれている場合、上記の “1 回だけ” 発生する手順が、プライマリ・フェイルオーバー・メンバ上でのアップグレード・コードの実行時にそのネームスペースに対してのみ適用されます。そのため、ネームスペースがアップグレードされているかどうかを判断するために Ensemble が使用するデータをミラー・メンバ間で共有する必要があります。

以下の各節では、このデータの詳細について示すとともに、ミラー構成の Ensemble インスタンスをアップグレードするための手順と重要な問題について説明します。

• 重要なミラー・グローバル・データ

• ミラーの考慮事項

• ミラーのアップグレードの実行

重要なミラー・グローバル・データ

共有が必要なアップグレード・データがある最も重要な場所は、各ネームスペース内の ^Ens.Mirror グローバルです。ここにはミラー・データが格納されています。^Ens.Mirror グローバルは、そのネームスペースに対して実行する必要があるアップグレード手順はどれか判断するために使用されます。そのため、ミラー・データを含む各ネームスペースについて、ミラー・データベースにこのグローバルが確実に含まれていなければなりません。より具体的に説明すると、ミラー・データを含む各ネームスペースについて、そのネームスペース内の ^Ens.Mirror グローバルをミラー・データベースにマッピングすることによって、そのネームスペースのアップグレード・プロセスで “1 回だけ” 実行する手順が完了しているかどうかをミラーの両方のメンバが判断できるようにする必要があります。

また、ミラー・データを含む各ネームスペースのミラー・データベースに ^Ens.AutoStart グローバルをマッピングする必要もあります。^Ens.AutoStart グローバルは、スタートアップ後に自動的に起動させる Ensemble プロダクションの名前を指定します。通常、このような自動起動はミラー・メンバ間で同じにするのが妥当です。

上記の 2 つのディレクティブの意味は、例で示すと理解しやすくなるかもしれません。ある Ensemble ネームスペースで、DATA1 および DATA2 という 2 つのユーザ・データベースが使用されているとします。(このネームスペースには ENSLIB へのマッピングも含まれていますが、これは Ensemble によって処理されます)。DATA2 はミラー・データベースですが、DATA1 はミラーリングされていません。この場合、^Ens.AutoStart と ^Ens.Mirror の両方をミラー・データベース DATA2 に明示的にマッピングし、両方のミラー・メンバがグローバルのコンテンツを認識できるようにする必要があります。

アップグレードの開始前に、両方のインスタンスでミラー・データを含むネームスペースに対してプロダクションの自動起動を無効にします。推奨されているとおり、特定のネームスペースに関して、^Ens.AutoStart グローバルが 2 つのインスタンス間でミラーリングされている場合、この手順を実行する必要があるのはプライマリ・ミラー・メンバ上だけです。ミラーリングされていない場合は、両方のフェイルオーバー・メンバ上でこの手順を実行します。これは Ensemble の標準のアップグレード手順に沿っており、アップグレードが実行されている間、あらゆるプロダクションの起動を防止します。

Note:

以下の各コマンドを使用して、指定した NAMESPACE について 2 つの重要なグローバルが正しくマッピングされているか特定できます。

  Write ##class(SYS.Database).%OpenId($P(##class(%SYS.Namespace).GetGlobalDest
        ("NAMESPACE","Ens.Mirror"),"^",2)).Mirrored
  Write ##class(SYS.Database).%OpenId($P(##class(%SYS.Namespace).GetGlobalDest
        ("NAMESPACE","Ens.AutoStart"),"^",2)).Mirrored

Important:

この場合は、システム全体の構成開始設定である EnsembleAutoStart を使用して自動開始をオフにしないでください。この設定は CPF ファイルに含まれており、ミラーリングされていないからです。代わりに、ネームスペースごとに自動開始を無効にします。