USER MANUALS


新しいインストール環境に対するアップグレード後の作業

設定とメタデータを Denodo Platform 9 にインストールし終わったら、以下の手順に従ってください。

使用しないモジュールについては、アップグレード後の作業を省略してください。

すべてのコンポーネントに共通する内容

Denodo Security Token サーバーへのコネクションの構成

Denodo Platform をインストールしたら (Solution Manager を除く)、ファイル <DENODO_HOME>/conf/SSOConfiguration.properties に次のプロパティを設定します。

sso.url=https://solution-manager.acme.com:19443
sso.token-enabled=true

Solution Manager の Web コンテナーで HTTPS を有効化することをお勧めします。有効化しない場合は、プロパティ sso.url のポートに 19443 ではなく 19090 を設定します。

この変更を適用するには、Denodo Platform のサーバーコンポーネントを再起動します。

Denodo Platform のコンポーネントが、Solution Manager の一部である Denodo Security Token Server にアクセスできるようにするために、この変更は必須です。

この変更を行わないと、Solution Manager では リビジョンのデプロイ や、Virtual DataPort サーバーの 監視 を行うことができません。

Denodo 7.0 では必須ではありませんでしたが、9 (および 8.0) では必須です。

本番サーバーのメモリ割り当ての確認

これが本番のインストール環境である場合、Denodo Platform と Solution Manager の各モジュールのメモリ割り当てが、以前のバージョンの割り当てと少なくとも同じであることを確認します。詳細については、ナレッジベースの記事「Denodo Admin and Development Best Practices」(https://community.denodo.com/kb/en/view/document/Denodo%20Admin%20and%20Development%20Best%20Practices) の「 Recommended settings for the JVM 」のセクションを参照してください。


Denodo 7.0 以前からアップグレードする場合 (Denodo 8.0 からアップグレードする場合ではありません)、Denodo Platform の Tomcat に割り当てるメモリ容量を増やすことを強くお勧めします。余裕を持って 2 倍にしておくとよいでしょう。これだけのメモリが必要になるのは、Denodo の REST Web サービスのメモリ使用量が 7.0 の場合より増えるからです。

これを行うには、Design Studio 9 にログインし、以下のクエリを実行します。これは、Denodo Platform の Tomcat を実行する Java 仮想マシンに渡す引数を返します。

SELECT property_value
FROM GET_PARAMETER()
WHERE input_property_name = 'java.env.DENODO_OPTS_START'
      AND input_is_web_container_property = TRUE;

このステートメントから返される値をコピーして引数 -Xmx の値を変更し、コマンド WEBCONTAINER SET 'java.env.DENODO_OPTS_START' = '<new value>'; を実行します。実行する必要があるコマンドについては、以下の例を参照してください。

Tomcat のメモリを 2GB 増やす
WEBCONTAINER SET 'java.env.DENODO_OPTS_START' = '-Xmx2g -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true -Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true';

割り当てるメモリを 4GB にする場合、 -Xmx2g の代わりに -Xmx4g を指定します (必要なギガバイト数を指定できますが、決して 16 を超えないようにすることを強くお勧めします)。

この変更を適用するには、Denodo Platform のすべてのコンポーネントを停止します。次に、 <DENODO_HOME>/bin/webcontainer_shutdown を実行して Web コンテナーが停止していることを確認し、すべてのコンポーネントを再起動します。Solution Manager のインストール環境でもこれを繰り返します。

Virtual DataPort

Design Studio から Virtual DataPort に管理者アカウントでログインして、以下の手順を実行します。

  1. データソースコネクション: データソースごとにその 1 つの基本ビューにクエリを実行して、ソースに接続できることを検証します。

    クエリがキャッシュデータベースではなくソースをヒットするように、キャッシュを無効にしたビューを実行します。

    ソースへの接続に失敗した場合、コネクションには SSL 証明書が必要であり、その証明書は <DENODO_HOME_9_0>/jre/lib/security/cacerts にインポートされている必要があった可能性があります。

    セキュア LDAP ソースへの接続に失敗した場合 (No subject alternative DNS name matching <HOSTNAME> found というエラーが考えられます)、Denodo ナレッジベースの こちらの記事 を参照してください。

  2. 1 つまたは複数のビューでパラメータ QUERYPLAN が使用されているという警告があった場合、以下を行います。

    1. コストベースのオプティマイザーを有効にする。

    2. このビューとこのビューのサブビューの統計情報を収集する。

    3. ビューのクエリプランを取得して、パラメータ「QUERYPLAN」で示されたものと同じであるかどうかを確認する。

  3. Full キャッシュモードのビューのキャッシュ: バージョン 9 のキャッシュエンジンを別のカタログ/スキーマを使用するように構成した場合、モードが full または partial - explicit loads のビューのキャッシュは空になります。したがって、これらのビューに対するクエリは 0 行を返します。これらのビューのキャッシュを読み込む Scheduler ジョブを実行するか (キャッシュがある場合)、手動で読み込む必要があります。

    これらのビューのキャッシュを手動で VQL シェルから読み込むには、以下の手順に従って実施してください。これには長い時間がかかる場合があります。その間、[VQL Shell] タブを閉じることはできません。

    1. [Retrieve all rows] チェックボックスをチェックして、[Limit displayed rows] を 1000 に設定します。

    2. 次のクエリを実行します。キャッシュを必要とするビューのキャッシュを読み込むステートメントが返されます。

      SELECT 'SELECT * FROM "' || database_name || '"."' || name || '"
          CONTEXT (''cache_preload''=''true'', ''cache_invalidate'' = ''all_rows'',
              ''cache_wait_for_load''=''true'', ''cache_return_query_results'' = ''false'');' AS query
      FROM get_views()
      WHERE view_type IN (0, 1) AND cache_status in (3, 4, 5)
      ORDER BY 1;
      

      このクエリが返した行数が 1,000 ([Limit displayed rows] の値) だった場合、結果が [Limit displayed rows] の値より多い可能性があり、すべてのビューのキャッシュを読み込むクエリを得られません。その場合、一時的にこの制限値を増やします。これを行うには、Design Studio からログアウトして「/denodo-design-studio/#/web-local-login」に移動し、[Application settings] で [Maximum number of rows displayed] を 999999 に変更します。「/denodo-design-studio」でログアウトして再ログインし、上記のクエリを再実行して、すべての行を取得します。

    3. [Copy displayed results to clipboard] をクリックします (Administration Tool で結果の 1 行をクリックして、Ctrl + A を押します)。

    4. コピーした行を VQL Shell でペーストし、[Execute] をクリックして、すべてのクエリを実行します。

      これらのクエリは、モード full または partial - explicit loads のビューのキャッシュを読み込みます。

  4. マテリアライズドテーブルの再作成: バージョン 8.0 からメタデータをインポートすると、マテリアライズドテーブルが作成されますが、それは空です。VQL ファイルに含まれているのは、データではなく、メタデータです。

    次のクエリを実行して、マテリアライズドテーブルのリストを取得します。

    SELECT database_name, name
    FROM get_views()
    WHERE input_view_type = 3;
    
  5. Kerberos 認証: バージョン 8.0 で Virtual DataPort の Kerberos 認証を有効にしていた場合、バージョン 9 でも有効になっています。

    アップグレードプロセス中に、新しい Kerberos サービスプリンシパル名 (SPN) をこのインストール環境に作成した場合、この Virtual DataPort の Kerberos 構成を開いて、SPN を変更し、新しい keytab ファイルをアップロードします。

    アップグレードの準備 」の「Kerberos」サブセクションで、新しい SPN の作成が必要となる場合について説明しています。

  6. DenodoConnect コンポーネント: Virtual DataPort 8.0 から取得する VQL ファイルには、インストールしていた DenodoConnect コンポーネントが含まれます。このファイルをインポートすると、それらの機能を Denodo 9 サーバーでも使用できるようになります。なぜなら、Denodo 7.0 と 8.0 の DenodoConnect コンポーネントは Denodo 9 と互換性があるからです。

  7. VCS: VCS を有効にしたデータベースで、変更を新しいリポジトリにプッシュします。

Denodo Platform の Tomcat に割り当てるメモリの増加

Denodo 7.0 以前からアップグレードする場合 (Denodo 8.0 からアップグレードする場合ではありません)、Denodo Platform の Tomcat に割り当てるメモリ容量を増やすことを強くお勧めします。余裕を持って 2 倍にしておくとよいでしょう。これだけのメモリが必要になるのは、Denodo の REST Web サービスのメモリ使用量が増えるからです。

これを行うには、Design Studio 9 にログインし、以下のクエリを実行します。これは、Denodo Platform の Tomcat を実行する Java 仮想マシンに渡す引数を返します。

SELECT property_value
FROM GET_PARAMETER()
WHERE input_property_name = 'java.env.DENODO_OPTS_START'
      AND input_is_web_container_property = TRUE;

このステートメントから返される値をコピーして引数 -Xmx の値を変更し、コマンド WEBCONTAINER SET 'java.env.DENODO_OPTS_START' = '<new value>'; を実行します。実行する必要があるコマンドについては、以下の例を参照してください。

Tomcat のメモリを 2GB 増やす
WEBCONTAINER SET 'java.env.DENODO_OPTS_START' = '-Xmx2g -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true -Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true';

割り当てるメモリを 4GB にする場合、 -Xmx2g の代わりに -Xmx4g を指定します (必要なギガバイト数を指定できますが、決して 16 を超えないようにすることを強くお勧めします)。

この変更を適用するには、Denodo Platform のすべてのコンポーネントを停止します。次に、 <DENODO_HOME>/bin/webcontainer_shutdown を実行して Web コンテナーが停止していることを確認し、すべてのコンポーネントを再起動します。Solution Manager のインストール環境でもこれを繰り返します。

Design Studio

Design Studio の設定領域にログインし、以下の手順に従います。

  1. 以前のバージョンの Design Studio でクエリタイムアウトの時間を長くしていた場合、Design Studio 9 でも同じように長くします。

  2. Kerberos 認証を有効にしていた場合、Design Studio 9 でも有効にする必要があります。

    メタデータを新しいバージョンのサーバーにインポートした後、以前のインストール環境が Kerberos をユーザー認証に使用するように構成されていた場合、新しいインストール環境でも同じように構成されます。

これを行う方法については、「 Design Studio の設定 」のページを参照してください。

Virtual DataPort Administration Tool

  1. 以前のバージョンの管理ツールでクエリタイムアウトの時間を長くしていた場合、新しいバージョンの管理ツールでも同じように長くします。

  2. Kerberos 認証を有効にしていた場合、管理ツールでも有効にする必要があります。

    メタデータを新しいバージョンのサーバーにインポートした後、以前のインストール環境が Kerberos をユーザー認証に使用するように構成されていた場合、新しいインストール環境でも同じように構成されます。

組み込み MPP

『組み込み MPP ガイド』の「 組み込み MPP 9 へのアップグレード 」のセクションの手順に従います。

Data Catalog

Data Catalog に管理者アカウントでログインし、以下の確認を行います。

  1. Virtual DataPort の URL の更新: [管理] > [セットアップ] > [サーバー] で、Virtual DataPort 9 の URL を入力します。

  2. Index Server の URL の更新: [管理] > [セットアップ] > [コンテンツ検索] で、正しい Index Server が構成されていることを確認します。Scheduler Index を使用している場合、Scheduler Index 9 の URL を入力します。

  3. メタデータの同期: [管理] > [VDP サーバーと同期] の順にクリックして、メタデータを同期します。

  4. 統計情報の収集の構成: 8.0 で Data Catalog の使用状況統計を定期的に収集している場合、新しいバージョンでも同じように構成します。手順については、『Data Catalog ガイド』の「 使用状況統計 」を参照してください。バージョン 9 では、このプロセスは以前のバージョンより単純になっています。

  5. Kerberos: 新しい Kerberos サービスプリンシパル名 (SPN) を Denodo のこのインストール環境に作成した場合、この Virtual DataPort の Kerberos 構成を開いて、SPN を変更し、新しい keytab ファイルをアップロードします。

Scheduler

  1. バージョン 8.0 で Scheduler に DenodoConnect プラグインをインストールしていた場合、新しいバージョン 9 用に、それらのプラグインを Denodo Support Site からダウンロードします。次に、既存のプラグインを削除し、新しいプラグインをインポートします。

  2. 新しい Kerberos サービスプリンシパル名 (SPN) を Denodo のこのインストール環境に作成した場合、Scheduler の Kerberos 構成を開いて、SPN を変更し、新しい keytab ファイルをアップロードします。

Scheduler Index

  1. インデックスファイルのコピー: ディレクトリ <DENODO_HOME_7_0>/work/arn/data/index/ の内容を <DENODO_HOME_9_0>/work/arn/data/index/ にコピーします。

  2. インデックスの構成: Scheduler Administration Tool で、[Administration] メニュー > [Index server] > [Indexes] の順にクリックします。各インデックスを編集して、インデックスを置くディレクトリを更新します。

Solution Manager

  1. モニターの有効化: 常時有効なモニターがある場合、新しいバージョンで有効にします。

  2. Kerberos 構成: Solution Manager 8.0 で Kerberos を有効にしていた場合、以下のファイルをデスクトップにコピーします。

    1. Solution Manager 7.0 用の keytab ファイル

    2. カスタム krb5 ファイル (使用している場合)

    次に、Solution Manager 9 にログインし、これらのファイルを使って Kerberos を有効にします。

    新しいバージョンが同じホストにインストールされている場合、またはクライアントアプリケーションから同じエイリアスでロードバランサーにアクセスされる場合にのみ、同じ keytab を使用できます。これは、keytab の SPN が、クライアントアプリケーションから Virtual DataPort や Data Catalog などへの接続に使用される URL のホスト名に一致する必要があるためです。一致しない場合、新しいコンピュータ用に新しい keytab を取得する必要があります。

    これは、Denodo Platform のすべてのコンポーネントで同じ keytab を使用するという一般的な想定に基づいています。

    Virtual DataPort または Scheduler では Kerberos を有効にし、Solution Manager では有効にしなかった場合、この作業を行う必要はありません。これは、バージョン 8.0 から新しいバージョンにメタデータをインポートするときに、これらの Kerberos 構成が転送されるためです。

外部アプリケーション: JDBC ドライバーと ODBC ドライバーのアップグレード

ここでは、Denodo の JDBC ドライバーまたは ODBC ドライバーを使用して Virtual DataPort に接続するクライアントアプリケーションについて説明します。

JDBC ドライバー

Denodo 8.0 からアップグレードする場合:

  • ドライバーを今すぐ更新する必要はありませんが、今後更新することをお勧めします。

  • 8.0 のドライバーは Virtual DataPort バージョン 9 に接続できます。9 のドライバーは Virtual DataPort 8.0 に接続できます。

Denodo 7.0 または 6.0 からアップグレードする場合:

  • Virtual DataPort 9 に接続するクライアントアプリケーションで、古いドライバーを Denodo 9 の新しいドライバーに置き換えます。7.0 と 6.0 の JDBC ドライバーは Virtual DataPort 9 に 接続できません 。バージョン 9 のドライバーは Virtual DataPort 7.0 または 6.0 のどちらにも接続できません。

  • お使いのアプリケーションで、Denodo への接続 URL にパラメータ「reuseRegistrySocket」がある場合、削除してください。削除しなかった場合、コネクションは失敗します。このパラメータは削除されています (詳細については、このマニュアルの「 JDBC ドライバー: reuseRegistrySockets プロパティ 」を参照してください)。

その詳細については、「 Virtual DataPort サーバーとそのクライアントとの間の下位互換性 」のページを参照してください。

Denodo 8.0 用の JDBC ドライバーは Denodo Community) から入手可能です。

ODBC ドライバー

ODBC ドライバーを今すぐ更新する必要はありませんが、今後更新することをお勧めします。その詳細については、「 Virtual DataPort サーバーとそのクライアントとの間の下位互換性 」のページを参照してください。

Add feedback