バージョン 2.0: BigQuery Connector for SAP 運用ガイド

このガイドでは、SAP LT Replication Server 管理者、SAP データ エンジニアなどを対象に、BigQuery Connector for SAP バージョン 2.0 と 2.1 のパフォーマンス チューニングやバージョン更新などの運用タスクを実行する方法について説明します。

レプリケーションのパフォーマンス調整

レプリケーションのパフォーマンスはさまざまな要因の影響を受ける可能性があります。これらの要因はインストールごとに異なる場合があり、時間とともに変化することもあります。

以下のセクションでは、パフォーマンスに影響を与える可能性のある一般的な要因を調整する方法について説明します。

BigQuery Connector for SAP を使用したレプリケーション パフォーマンスの詳細については、パフォーマンス計画をご覧ください。

テーブルのパフォーマンス オプションを設定する

SAP LT Replication Server では、パフォーマンスに影響を与えるテーブルごとにレプリケーション オプションを指定できます。

特に、大規模なテーブルのレプリケーション パフォーマンスでは、レプリケーションでより多くの時間とリソースが必要になります。この場合、範囲を指定して、テーブルで使用可能な並列レプリケーション ジョブの最大数を増やすことができます。

一般にサイズが大きくなるテーブルとしては、MSEG、ACDOCA、MATDOC などがあります。

大規模なテーブルに並列レプリケーション ジョブを指定する場合は、任意のテーブルで許可される並列ジョブの数と、大量転送構成で許可される並列ジョブの総数のバランスをとる必要があります。組織によっては、特定のサーバーに指定できる並列レプリケーション ジョブの数が制限されている場合もあります。

テーブルのパフォーマンス オプションを設定するには:

1. SAP GUI に、SAP トランザクション LTRS を入力します。

2. [Advanced Replication Settings] 画面で、テーブルの一括転送設定の ID を指定します。

3. [Advanced Replication Settings] フォルダ階層で、[Performance Options] フォルダをクリックして、パフォーマンス オプションが定義されたテーブルを表示します。

4. 必要なテーブルがリストにない場合は、[Performance Options] フォルダを右クリックして [Add Table] を選択します。

5. テーブルの名前を指定します。

6. 必要に応じて、以下のオプションを指定します。

   • [General Performance Options] で、次の操作を行います。
     • No. of Parallel Jobs - テーブルで使用可能な並列レプリケーション ジョブの最大数を設定する場合に指定します。
     • Sequence Number - このテーブルのレプリケーションを他のテーブル レプリケーションよりも優先させる場合に指定します。
   • [Initial Load Options] で、次の操作を行います。
     • テーブルが過度に大きくならない場合は、[Reading Type] で [Reading Type 1 Range Calculation] を選択します。詳細については、パフォーマンスと LTRS の詳細レプリケーションの設定をご覧ください。
     • [Package Size] で、SAP LT Replication Server に送信されるレコードの部分のサイズを指定します（単位はバイト）。
     • 範囲を使用する読み取りタイプを選択した場合は、適切な範囲を定義します。
   • [Replication Option] で、次の操作を行います。
     • [Ranges for Logging Table] で、最も信頼できるオプションとして [No Ranges] を指定します。
     • [Specify Ranges for Manually] を選択した場合は、適切な範囲を定義します。

7. [Save] をクリックします。

ベースライン パフォーマンスのベンチマーク

このセクションでは、レプリケーションのパフォーマンスを評価できるようにするため、Google Cloud テストシステムで観測されたベースライン パフォーマンスの数値を示しています。

パフォーマンスにはさまざまな要因が影響するため、実際のパフォーマンスの数値とは異なる可能性があります。

たとえば、SAP システムが Google Cloud で実行されていない場合、ネットワーク レイテンシやアクセス トークンのオーバーヘッドなどにより、読み込みとレプリケーションの速度がベースラインよりも遅くなる可能性があります。ソーステーブルで列数が少ない場合や、スタンドアロン アーキテクチャで SAP LT Replication Server を独自のサーバーにインストールした場合は、リソースのソースシステムで SAP LT Replication Server と SAP LT Replication Server の競合が発生することはないため、速度がベースラインよりも速くなることがあります。

観測されたベースライン パフォーマンスの数値

次のパフォーマンスの数値は、テスト中に各ソースシステム タイプについて Google Cloud が観測したベースライン パフォーマンスを表します。各テストシステムで、Compute Engine VM の組み込みアーキテクチャの SAP ソースシステムに SAP LT Replication Server がインストールされています。SAP ソースシステムは、ターゲットの BigQuery データセットと同じ Google Cloud リージョンで実行されています。

テストシステムの構成については、ベースライン パフォーマンス テストのシステム構成をご覧ください。

パフォーマンスの数値を確認するには、ご使用のソースシステムのタイプをクリックしてください。

S/4HANA

• テーブル: ACDOCA
  • 3 億 4,300 万件のレコード
  • 477 列
• 初期読み込み
  • 読み込み速度: 1 時間あたり平均 3 億 5,000 万件のレコード
  • 読み込み時間: 平均 59 分
• レプリケーション
  • ソーステーブルの変動率: 1 時間あたり平均 5,000 万件のレコード
  • レプリケーションの最大速度: 1 時間あたり平均 5,000 万件のレコード

ECC

• テーブル: MSEG
  • 2 億 300 万件のレコード
  • 188 列
• 初期読み込み
  • 読み込み速度: 1 時間あたり平均 3 億 8,500 万件のレコード
  • 読み込み時間: 平均 32 分
• レプリケーション
  • ソーステーブルの変動率: 1 時間あたり平均 5,000 万件のレコード
  • レプリケーションの最大速度: 1 時間あたり平均 6,900 万件のレコード

上のパフォーマンスの数値は、Google Cloud テスターが観測したベースラインです。

観察されたパフォーマンスを見ると、次の属性のテストシステムが良い結果を残しています。

• SAP LT Replication Server は、スタンドアロン アーキテクチャで独自の VM にインストールされている。
  • S/4HANA システムの場合、SAP LT Replication Server プロセスの独立したスケーリングにより、スタンドアロン アーキテクチャは組み込みアーキテクチャよりも初期読み込み速度が約 42% 速い。
  • ECC システムの場合、SAP LT Replication Server プロセスの独立したスケーリングにより、スタンドアロン アーキテクチャは組み込みアーキテクチャよりも初期読み込み速度が約 10% 速い。
• ソーステーブルの列数が少ない。
• レコードの全体的なバイトサイズが小さい。

パフォーマンスを向上させるために変更できるシステム属性については、以下をご覧ください。

• レプリケーションのパフォーマンス調整
• パフォーマンス計画

ベースライン パフォーマンス テスト システムの構成

このセクションで説明するテストシステムは、前のセクションの観測されたベースライン パフォーマンスの数値にあるベースライン パフォーマンスの数値を達成しています。

テストシステム（SAP ソースシステム、SAP LT Replication Server、BigQuery データセットなど）はすべて同じ Google Cloud リージョン内の Compute Engine VM で実行されています。

各システムで、サーバーとワークロードは、多くの実際の環境で見られる負荷の高いワークロードと大容量のレプリケーションをシミュレートするように設計されています。

テストシステムの属性を確認するには、ご使用のソースシステムのタイプをクリックしてください。

S/4HANA

• SAP LT Replication Server のインストール アーキテクチャ:
  • 組み込みアーキテクチャ
• ソースシステム サーバー:
  • 2 つのアプリケーション サーバー。それぞれが、次の仕様の N2 ベースの Compute Engine カスタム マシンタイプ上に配置されています。
    • vCPU: 60
    • メモリ: 324 GB
    • CPU プラットフォーム: Intel Cascade Lake
  • 次の仕様の m1-ultramem-80 Compute Engine VM 上に 1 つの SAP HANA サーバー。
    • vCPU: 80
    • メモリ: 1,900 GB
    • CPU プラットフォーム: Intel Broadwell
• ソフトウェアのバージョン:
  • S/4HANA 1909
  • SAP LT Replication Server: S/4CORE 104 SP00
• テーブルのサイズ:
  • テーブル名: ACDOCA、総勘定元帳仕訳明細データ
  • レコード数: 3 億 4,300 万件
  • 列数: 477
• 各アプリケーション サーバーの作業プロセス:
  • ダイアログ プロセス 60 個
  • バックグラウンド プロセス 220 個
• SAP LT Replication Server の読み込み設定:
  • ジョブ: 99
  • 読み取りのタイプ: 1 範囲
  • 計算: 自動範囲
• レプリケーションの設定:
  • ジョブ: 99
  • キーフィールドを使用して、ロギング テーブルの範囲を計算
  • 128 範囲

ECC

• SAP LT Replication Server のインストール アーキテクチャ:
  • 組み込みアーキテクチャ
• ソースシステム サーバー:
  • 2 つのアプリケーション サーバー。それぞれ次の仕様の n2-highmem-48 Compute Engine VM 上に配置されています。
    • vCPU: 60
    • メモリ: 348 GB
    • CPU プラットフォーム: Intel Cascade Lake
• ソフトウェアのバージョン:
  • SAP NetWeaver: 7.0 EHP2
  • SAP LT Replication Server: DMIS 2011_1_700 SP17
• テーブルのサイズ:
  • テーブル: MSEG、材料在庫管理のドキュメント
  • レコード数: 2 億 300 万件
  • 列数: 188
• 各アプリケーション サーバーの作業プロセス:
  • ダイアログ プロセス 60 個
  • バックグラウンド プロセス 100 個
• SAP LT Replication Server の読み込み設定:
  • ジョブ: 99
  • 読み取りタイプ: 5 送信者
  • キュー: 手動範囲
• レプリケーションの設定:
  • ジョブ: 99
  • ロギング テーブルの範囲: キーフィールドを使用して範囲を計算
  • 範囲数: 128

本番環境への一括転送の設定

一括転送設定を本番環境に転送するには、まず開発システムから設定をエクスポートし、本番環境システムにインポートする必要があります。

必要に応じて、一括転送の次の 3 つの設定を本番環境にインポートできます。

• LTRS トランザクションを使用してアクセスできる高度なレプリケーション設定。
• SM30 トランザクションを使用してアクセスできる /GOOG/CLIENT_KEY テーブルのクライアント キー設定。
• /GOOG/SLT_SETTINGS トランザクションを使用してアクセスできる BigQuery Connector for SAP の一括転送設定。

注: 一括転送設定を本番環境に移行する前に、QA 環境またはサンドボックス環境で設定を検証してください。

開発システムから一括転送設定をエクスポートする

SAP LT Replication Server 開発システムで、一括転送設定の各部分をエクスポートします。

1. 高度なレプリケーション設定をエクスポートします。

   1. LTRS トランザクションを実行します。
   2. 本番環境に転送する一括転送レコードを選択します。
   3. [File] プルダウン メニューから [Export All Settings] を選択します。
   4. [Export Settings] ダイアログで、宛先を選択して [Save] をクリックします。設定がローカル ワークステーションに CSV 形式の圧縮ファイルで保存されます。

2. BigQuery Connector for SAP の一括転送設定をエクスポートします。

   1. /GOOG/SLT_SETTINGS トランザクションを実行します。

      /n/GOOG/SLT_SETTINGS

   2. [Settings Table] フィールドで、[Mass Transfer] を選択します。

   3. 本番環境に転送する一括転送レコードを選択します。

   4. [Transport Mass Transfer] をクリックします。

   5. [Prompt for Workbench request] に、トランスポート リクエスト番号を入力して続行アイコンをクリックします。選択した一括転送レコードごとに、トランスポートに次のカスタム構成テーブルの設定が含まれます。

      • /GOOG/BQ_MASTR
      • /GOOG/BQ_TABLE
      • /GOOG/BQ_FIELD

   一括転送の設定は、トランスポート リクエストに保存されます。

3. トランスポート リクエストに /GOOG/CLIENT_KEY テーブルの内容を手動で追加し、クライアント キーの設定をエクスポートします。

4. ファイルをローカル ワークステーションに保存します。

一括転送設定を本番環境システムにインポートする

SAP LT Replication Server 本番環境システムで、一括転送設定の各部分をインポートします。

1. 一括転送設定用に SAP LT Replication Server レプリケーション構成を作成します。

2. 高度なレプリケーション設定をインポートします。

   1. LTRS トランザクションを実行します。
   2. 最初のステップで作成した一括転送を選択します。
   3. [File] プルダウン メニューから [Import All Settings] を選択します。
   4. [Choose File] ダイアログで、ローカル ワークステーションにある圧縮ファイルを選択し、[Open] をクリックします。これらの設定が一括転送の設定として読み込まれます。

3. 一括転送の設定を含むトランスポート リクエストをインポートします。

4. SM30 トランザクションを実行します。

5. 本番環境に必要なクライアント キー設定を更新します。

6. /GOOG/SLT_SETTINGS トランザクションを実行します。

   /n/GOOG/SLT_SETTINGS

7. [Mass Transfers] 画面に正しい一括転送が表示されていることを確認します。

8. [Mass Transfer ID] 列で、開発システムの一括転送 ID を、最初の手順で作成したレプリケーション構成の一括転送 ID に置き換えます。

9. 必要であれば、以降の [Tables] と [Fields] 設定画面で、本番環境に合わせてテーブルとフィールドのマッピングの他の値を更新します。

10. 初期読み込みまたはレプリケーションを開始して構成をテストします。初期読み込みまたはレプリケーションの開始については、以下をご覧ください。

    • SAP LT Replication Server が Compute Engine VM で実行されている場合は、レプリケーションのテスト。
    • SAP LT Replication Server が Google Cloud の外部のホストで実行されている場合は、レプリケーションのテスト。

BigQuery Connector for SAP を更新する

Google Cloud は、SAP トランスポートとして BigQuery Connector for SAP の新しいリリースを提供します。

注: BigQuery Connector for SAP のバージョン リリースの詳細については、BigQuery Connector for SAP の最新情報をご覧ください。

SAP 管理者は、次の手順で BigQuery Connector for SAP を更新できます。

1. SAP LT Replication Server で構成を無効にします。
2. 新しい SAP トランスポート リクエストをインポートします。
3. インポートとオブジェクトの有効化が完了したら、SAP LT Replication Server で構成を有効にします。

gcloud CLI を更新する

SAP LT Replication Server ホストで Google Cloud CLI を最新の状態に保つ必要があります。

gcloud CLI の管理の詳細については、gcloud CLI コンポーネントの管理をご覧ください。

モニタリング

SAP データソースからターゲット BigQuery テーブルへのデータパスに沿って、次のような複数のポイントをモニタリングできます。

• インフラストラクチャ - ネットワーク、ハードウェア、オペレーティング システム
• SAP データベース レイヤ
• SAP アプリケーション レイヤ
• BigQuery Connector for SAP
• BigQuery

以降のサブセクションでは、各ポイントをモニタリングするオプションについて説明します。

インフラストラクチャのモニタリング

Google Cloud では、ホスト VM に Ops エージェントをインストールして高度なモニタリングとロギングを行うことができます。Ops エージェントは、Google Cloud コンソールの Cloud Monitoring にデータを送信します。

詳細情報

• Ops エージェントの概要
• Cloud Monitoring の概要

Google Cloud で実行されていないシステムの場合、トランザクション ST06 などの SAP トランザクションを実行してサーバー情報を取得することもできます。

データベース レイヤのモニタリング

標準の SAP トランザクション コードを使用して、データベースの状態をモニタリングします。

トランザクション コード DBACOCKPIT は、データベースをモニタリングする最も一般的なトランザクションです。このトランザクションでは、エラーのトラブルシューティングに使用できる詳細なログも提供されます。

SAP HANA の場合は、SAP HANA Studio を使用して SAP HANA の操作を実行できます。SAP HANA Studio は、任意のフロントエンド マシンにインストールできます。

パフォーマンスやその他の問題をトラブルシューティングする場合は、ソース データベースで次のことを確認します。

• コストの高い SQL ステートメント
• ロック
• 読み込み履歴
• インデックス
• プロセス

アプリケーション レイヤのモニタリング

BigQuery Connector for SAP はアプリケーション レイヤで実行されるため、SAP アプリケーションのモニタリングとトラブルシューティングのツールを使用すると、BigQuery Connector for SAP のモニタリングとトラブルシューティングを行うことができます。

SAP アプリケーションのモニタリングとトラブルシューティングは、さらに次のように分類できます。

• 標準の SAP のモニタリングとトラブルシューティング
• BigQuery Connector for SAP のモニタリングとトラブルシューティング

大規模な環境では、中心となるモニタリング ツールとして SAP Solution Manager を使用できます。

次のリストにある SAP トランザクション コードを使用すると、個々の SAP アプリケーション システムの問題をモニタリングして診断できます。

• SLT 構成ステータス: LTRC
• SLT エラーとログ: LTRO と SLG1
• Internet Communication Manager（HTTP 呼び出しと HTTPS 呼び出し）: SMICM
• セキュリティと証明書: STRUST
• SAP トランスポート: STMS
• RFC 接続: SM59
• OS コマンド: SM69
• パッケージ チェック: SE80
• 承認チェック: SU53
• バックグラウンド ジョブ: SM37
• システムログ: SM21

BigQuery のモニタリング

Cloud Monitoring を使用して、BigQuery の指標を表示し、グラフとアラートを作成します。各指標には、bigquery_dataset、bigquery_project、global のいずれかのリソースタイプと一連のラベルがあります。

リソースタイプとラベルを使用して、Monitoring Query Language（MQL）でクエリを作成します。

ラベルを使用して、各指標をグループ化またはフィルタリングできます。

Monitoring の詳細については、Cloud Monitoring のドキュメントをご覧ください。

レプリケーションの検証

トランザクション /GOOG/SLT_SETTINGS を使用してターゲットの BigQuery テーブルを作成するときに、追加フィールド フラグを選択すると、レプリケーションをトリガーした各レコードの変更タイプを格納する列と、SAP LT Replication Server がレコードを含む部分を受信した時刻のタイムスタンプを格納する列がテーブル スキーマに追加されます。

変更タイプとタイムスタンプを使用すると、次のようなレコード数をクエリできます。

• 初期読み込み時に BigQuery テーブルに読み込まれるレコード数。
• BigQuery テーブルに特定の日にレプリケートされたレコード数。
• BigQuery テーブル内の一意のレコードの合計数。

これらのカウントを取得するには、Google Cloud コンソールで SQL クエリを送信して BigQuery テーブルを直接クエリします。あるいは、レプリケーション検証ツールを実行してレポートを生成し、SAP LT Replication Server の統計情報またはソーステーブルのレコード数と BigQuery のレコード数を比較します。

追加フィールド フラグの概要については、レコード変更とカウントクエリ用の追加フィールドをご覧ください。

追加フィールド フラグの指定方法については、以下をご覧ください。

• SAP LT Replication Server が Compute Engine VM で実行されている場合は、テーブル作成とその他の一般的な属性を指定するをご覧ください。
• SAP LT Replication Server が、Google Cloud の外部のホストで実行されている場合は、テーブル作成とその他の一般的な属性を指定するをご覧ください。

レコード数の SQL クエリ

Google Cloud コンソールの BigQuery の SQL エディタページで SQL クエリを実行して、BigQuery テーブルのレコード数を確認できます。

その後、BigQuery レコードの数をソーステーブルの数または SAP LT Replication Server の統計情報と比較できます。

レコード カウントに必要なテーブル設定: このセクションの SQL クエリを実行するには、レプリケーションの構成で BigQuery テーブル オプションを指定するときに、追加フィールド フラグを指定する必要があります。詳しくは、レコード変更とカウントクエリ用の追加フィールドをご覧ください。

初期読み込みモードで挿入されたレコード数をクエリする

BigQuery テーブル スキーマにオプションの operation_flag 列が含まれている場合、初期読み込みモードでテーブルに挿入されるレコードに L オペレーション フラグが設定されます。

初期読み込み時に BigQuery が受信したレコード数を取得するには、次のクエリを実行します。

SELECT COUNT(*)
  FROM
      `PROJECT.DATASET.TABLE`
  WHERE operation_flag = 'L'

レプリケーション モードで挿入されたレコード数をクエリする

BigQuery テーブル スキーマにオプションの operation_flag 列が含まれている場合、レプリケーション モードでテーブルに挿入されるレコードに、次のいずれかのオペレーション フラグが設定されます。

• I: レコードがソーステーブルに挿入された。
• D: レコードがソーステーブルから削除された。
• U: レコードがソーステーブルで更新された。

レプリケーション モードで BigQuery が受信したレコード数を取得するには、次のクエリを実行します。

SELECT COUNT(*)
  FROM
      `PROJECT.DATASET.TABLE`
  WHERE operation_flag = 'I' | 'D' | 'U'

BigQuery テーブル内のレコードの合計数をクエリする

BigQuery テーブル スキーマにオプションの recordstamp 列が含まれている場合、テーブルに挿入されるレコードに対応する recordstamp フィールドに、SAP LT Replication Server から BigQuery にレコードが送信された時間を示すタイムスタンプが設定されます。

ソーステーブルのレコードの合計数と比較するために、BigQuery テーブルのレコードの合計数を取得するには、recordstamp フィールドと is_deleted フィールドを使用して、ソーステーブルから削除されていない BigQuery テーブル内の一意のレコード数をカウントします。

レコードのクエリ時にソーステーブルが更新されていたり、レプリケーションの実行中であった場合、ソーステーブルとターゲット テーブルでレコード数が一致しないことがあります。

BigQuery ターゲット テーブル内の現在の一意のレコード数を取得するには、次のクエリを実行します。

SELECT COUNT(*)
  FROM (
    SELECT
      *,
      ROW_NUMBER() OVER (PARTITION BY KEY_FIELD_1, ..., KEY_FIELD_N ORDER BY recordstamp DESC) row_num
    FROM
      `PROJECT.DATASET.TABLE` )
  WHERE row_num = 1 AND is_deleted = false

Replication Validation ツール

このセクションでは、Replication Validation ツールの概要と使い方について説明します。

レコード カウントに必要なテーブル設定: Replication Validation ツールを使用するには、レプリケーションの構成で BigQuery テーブル オプションを指定するときに、追加フィールド フラグを指定する必要があります。詳しくは、レコード変更とカウントクエリ用の追加フィールドをご覧ください。

Replication Validation ツールは、SAP LT Replication Server の統計情報またはソーステーブルのレコード数と BigQuery テーブルのレコード数を比較できるレポートを生成します。数が完全に一致しない場合、赤い丸の付いたフラグが表示されます。

BigQuery でレコードをカウントするには、前のセクションのレコード数を調べる SQL クエリで示した SQL クエリを使用します。

Replication Validation ツールを定期的に実行して、SAP LT Replication Server と BigQuery Connector for SAP が期待どおりにレコードを BigQuery にレプリケートしていることを確認します。

レプリケーション検証ツールを実行するには、SAP GUI でカスタム トランザクション /n に続けて /GOOG/REPLIC_VALID を入力します。詳細な手順については、以下をご覧ください。

• SAP LT Replication Server が Compute Engine VM で実行されている場合は、Replication Validation ツールの実行。
• SAP LT Replication Server が Google Cloud の外部のホストで実行されている場合は、Replication Validation ツールの実行。

レプリケーション検証レポート

Replication Validation ツールでは、次の検証レポートを生成できます。

• 初期読み込み数: 読み込みモードで SAP LT Replication Server によって送信されたレコード数と、BigQuery に読み込まれたレコード数の比較。
• レプリケーション数: 指定した日付に SAP LT Replication Server がレプリケーション モードで送信したレコード数と、指定した BigQuery に挿入されたレコード数の比較。
• 現在の数: その時点でソーステーブル内にあるレコード数と BigQuery 内の一意のレコード数の比較。

各レポートを個別に生成することも、ツールの実行時に [All Checks] を選択して一度に 3 つすべてのレポートを生成することもできます。

レプリケーション検証レポートの表示

レポートを生成したら、Replication Validation ツールのインターフェースの [Processing Options] セクションで [Display Report] ラジオボタンを選択して、レポートを表示できます。

レポートで Replication Validation ツールによって表示される情報は、レポートの種類によってわずかに異なります。

すべてのレポートには次のタイプの情報が含まれています。

• SAP LT Replication Server の統計情報とソーステーブルのレコード数。
• ターゲット BigQuery テーブルのレコード数。
• 2 つの数値の差。この差は、ソースレコードの数から BigQuery のレコード数を引いた値になります。正の値は、すべてのソースレコードが BigQuery に取り込まれたわけではなく、問題が存在する可能性を示しています。
• ソースレコード数の割合として表示される両者の差。
• ソースカウントとターゲット カウントが等しいか同課を示すインジケーター。

レコード数の不一致

Replication Validation ツールでは、レポートごとにステータス フィールドが表示されます。

ステータス フィールドに緑の四角が表示されている場合、ソースレコード数が BigQuery のターゲット レコード数と一致していることを意味します。

ステータス フィールドに赤い丸が表示されている場合は、レコード数が等しくないことを表しています。

レコード数が一致していなくても、必ずしも問題とは限りません。次のインジケーターは、潜在的な問題を示しています。

• 「現在の数」を報告するレポートの場合、値の不一致は問題です。

• 初期読み取り数またはレプリケーション数の場合、正の値は潜在的な問題があることを示します。

  相対的に、小さい負の値の場合、問題はありません。接続が一時的に中断すると、SAP LT Replication Server がデータを再送信できなくなる、などのイベントが発生した場合、ターゲット BigQuery テーブル内のレコード数が、ソースレコード数よりわずかに多くなることがあります。

カウントが一致していない場合は、レポートを再実行し、一時的な問題ではないことを確認してください。レコード数の不一致は、ツールがレポートを生成した時点でのレプリケーション処理が原因で発生する可能性があります。

ソーステーブルが非常に大きい場合や、初期読み込みまたはレプリケーション用に SAP LT Replication Server でフィルタが設定されているテーブルの場合、Replication Validation ツールによって必要なレコードがすべてカウントされていない可能性があります。これらのレコード数は一致している必要があります。

検証チェックのスケジューリング

SAP バックグラウンド ジョブ機能を使用して、一定の間隔で自動的に実行されるように Replication Validation ツールをスケジューリングできます。

BigQuery フィールド マップを CSV ファイルで編集する

以降のセクションでは、データ エンジニアまたは BigQuery 管理者が SAP LT Replication Server にアクセスせずにターゲット フィールド値を編集できるように、デフォルトのフィールド マッピングをエクスポートする方法について説明します。

デフォルトのフィールド マッピングを含むスプレッドシートまたはテキスト ファイルを作成する

SAP LT Replication Server の外部で編集するための CSV ファイルを作成するには:

1. /GOOG/SLT_SETTINGS トランザクションを実行します。

2. [SLT Settings Maintenance] 画面で、次の値を指定します。

   • [Settings Table] フィールドで、フィールドを指定します。
   • [Mass Transfer Key] フィールドに、更新する一括転送の ID を指定します。
   • すべてのテーブルのすべてのフィールドで作業する場合は、[Table Name] フィールドを空白のままにします。特定のテーブルで作業する場合はテーブル名を指定します。
   • その他のフィールドは空欄のままにします。

3. [Execute] アイコンをクリックします。[BigQuery Settings Maintenance -Fields] 画面が表示されます。

4. [BigQuery Settings Maintenance - Fields] 画面で、列見出しを右クリックしてプルダウン メニューから [Hide] を選択して、次のリストを除くすべての列を非表示にします。

   • SAP テーブル名
   • SAP フィールド名
   • 外部データ要素
   • 外部フィールド名
   • フィールドの説明

5. 残りの 5 つの列が表示されたら、エクスポート アイコンをクリックします。

6. [Export] メニューから、次のいずれかのオプションを選択します。

   • スプレッドシート
   • ローカル ファイルファイルのコンテンツを CSV 形式に変換しやすくするため、ファイルをタブ区切りテキストの形式で保存することをおすすめします。

7. チェックマーク アイコンをクリックして、デフォルトのフィールド マッピングを保存します。

スプレッドシートまたはテキスト ファイルを CSV 形式に変換する

カスタム トランザクション /GOOG/SLT_SETTINGS を使用して編集済みのフィールド マッピングをアップロードするには、フィールド マッピングが CSV 形式である必要があります。

スプレッドシートを使用している場合は、ファイルをアップロードする前にスプレッドシートを CSV ファイルとして保存してください。

タブ区切りや他の形式のローカル ファイルを使用している場合は、CSV 形式に準拠するようにファイルを変更する必要があります。

次に例を示します。

SAP Table,SAP Field Name,External Data Element,External Field Name,Field Description
SAP_TABLE_NAME,SAP_FIELD_NAME1,BIGQUERY_DATA_TYPE,BIGQUERY_FIELD_NAME1,BIGQUERY_FIELD_DESCRIPTION1
SAP_TABLE_NAME,SAP_FIELD_NAME2,BIGQUERY_DATA_TYPE,BIGQUERY_FIELD_NAME2,BIGQUERY_FIELD_DESCRIPTION2
SAP_TABLE_NAME,SAP_FIELD_NAME3,BIGQUERY_DATA_TYPE,BIGQUERY_FIELD_NAME3,BIGQUERY_FIELD_DESCRIPTION3

CSV ファイルをアップロードする

編集した CSV ファイルをアップロードするには:

1. /GOOG/SLT_SETTINGS トランザクションを実行します。

2. [SLT Settings Maintenance] 画面で、次の値を指定します。

   • [Settings Table] フィールドで、フィールドを指定します。
   • [Mass Transfer Key] フィールドに、更新する一括転送の ID を指定します。
   • [Upload from file] チェックボックスをオンにします。

3. [Execute] アイコンをクリックします。[Select File to Upload] ダイアログが開きます。

4. [Select File to Upload] ダイアログで、編集されたフィールド値を含む CSV ファイルを選択します。

5. [Open] をクリックします。

6. セキュリティ警告が表示されたら、[Allow] をクリックします。ファイルが読み込まれ、変更した値が [BigQuery Settings Retention - Fields] 画面の該当する行に表示されます。

7. 保存アイコンをクリックします。

8. 値が適用されていることを確認するには、CSV ファイル内の値と SAP LT Replication Server によって表示される値を比較します。

ソースデータのエラーの処理

BigQuery streaming API は、BigQuery Connector for SAP からレコードのチャンクを受信すると、BigQuery テーブルにレコードを挿入する前にデータエラーをチェックします。

一括転送設定で次のフラグを指定することで、BigQuery API と BigQuery Connector for SAP がデータエラーを検出したときのレスポンスを制御できます。

• Skip Invalid Records（SKIP）フラグ。
• Break at First Error Flag（BREAK）フラグ。

SKIP フラグ。

SKIP フラグを指定した場合、BigQuery API がレコードのチャンクを受信して、データエラーのあるレコードを検出すると、BigQuery API は、エラーを含むレコードを破棄またはスキップし、チャンクの残りのレコードを BigQuery テーブルに挿入します。

SKIP フラグを指定しなかった場合、BigQuery はデータエラーのあるレコードを検出すると、BigQuery テーブルにそのレコードを挿入せずチャンク全体を破棄します。これはデフォルトの動作です。

SKIP フラグの指定は、開発環境と QA 環境には最適ですが、本番環境での使用はおすすめしません。

レプリケーションを構成するときに、/GOOG/SLT_SETTINGS トランザクションで SKIP フラグを指定できます。仕様は /GOOG/BQ_MASTR 構成テーブルに格納されます。

SKIP 仕様と BREAK 仕様の相互作用については、SKIP と BREAK の相互作用のマトリックス テーブルをご覧ください。

BREAK フラグ。

BREAK フラグを指定した場合、レコード内でデータエラーが見つかったことを BigQuery API から通知されると、BigQuery Connector for SAP は BigQuery へのレコードの送信を停止し、レプリケーション ジョブを終了します。

BREAK フラグを指定しなかった場合、レコード内でデータエラーが検出されたことを BigQuery から通知されると、BigQuery Connector for SAP は、次のチャンクを BigQuery に送信してレコード送信を継続し、レプリケーション ジョブを続行します。これはデフォルトの動作です。

本番環境では BREAK フラグを指定することをおすすめします。

レプリケーションを構成するときに、//GOOG/SLT_SETTINGS トランザクションで BREAK フラグを指定できます。仕様は /GOOG/BQ_MASTR 構成テーブルに格納されます。

BREAK 仕様と SKIP 仕様の相互作用については、BREAK と SKIP の相互作用のマトリックス テーブルをご覧ください。

SKIP と BREAK の相互査証のマトリックス テーブル

BigQuery Connector for SAP は、次の方法でデータエラーを処理するように構成できます。

SKIP フラグ	BREAK フラグ	動作
FALSE	TRUE	BigQuery は、現在のチャンクのレコードを BigQuery テーブルに挿入せずに、現在のレコード チャンクを破棄します。 BigQuery Connector for SAP は、現在の部分からレコードのチャンクを送信しなくなり、SAP LT Replication Server にレプリケーション ジョブの終了を指示します。 これは推奨の設定です。
FALSE	FALSE	BigQuery は、現在のチャンクのレコードを BigQuery テーブルに挿入せずに、現在のレコード チャンクを破棄します。 BigQuery Connector for SAP は、レコードの現在の部分から残りのレコード チャンクを送信して、レプリケーション ジョブの終了を SAP LT Replication Server に指示します。 これがデフォルトです。
TRUE	TRUE	BigQuery は、エラーを含むレコードのみを破棄し、現在のチャンクの残りのレコードを BigQuery テーブルに挿入します。 BigQuery Connector for SAP は、現在の部分からレコードのチャンクをそれ以上送信せず、次の部分を取得します。BigQuery Connector for SAP は、レプリケーション ジョブの終了を SAP LT Replication Server に指示しません。
TRUE	FALSE	BigQuery は、エラーを含むレコードのみを破棄し、現在のチャンクの残りのレコードを BigQuery テーブルに挿入します。 BigQuery Connector for SAP は、現在の部分から残りのレコード チャンクを送信し、次の部分を取得します。BigQuery Connector for SAP は、レプリケーション ジョブの終了を SAP LT Replication Server に指示しません。

テーブル構造を変更する

このセクションでは、既存の LTRC レプリケーションが進行中である SAP ソーステーブル構造を変更する方法について説明します。

ソーステーブルに列を追加する

ソーステーブルに新しい列を追加するには、次の手順を行います。

1. ソーステーブルに新しい列を追加します。この手順の結果、レプリケーションのステータスが Load/Replication blocked に変わります。

2. SLT システムで、トランザクション LTRC を使用して、レプリケーションのステータスをリセットします。レプリケーションのステータスのリセット方法に関する SAP の情報については、SAP Note 2204955 - SLT table is in status 'Load /Replication blocked をご覧ください。

3. ソーステーブルのエントリを追加、更新、削除します。

4. BigQuery でレプリケーションの結果を検証します。

ソーステーブルから列を削除する

ソーステーブルから既存の列を削除するには、次の手順を行います。

1. SLT システムで、トランザクション LTRC を使用してレプリケーションを一時停止します。

2. ソーステーブルから列を削除します。この手順の結果、既存の SLT トリガーが削除されるか、整合性のない状態に変更されます。

3. BigQuery で、対象の BigQuery テーブルから列を削除します。既存のテーブルから列を削除する手順については、BigQuery のドキュメントをご覧ください。

4. SLT システムで、トランザクション LTRC を使用してレプリケーションを再開します。

5. SLT システムで、SLT トリガーを再作成します。SLT トリガーを再作成する方法に関する SAP の詳細な情報については、SAP Note 2254376 - SLT trigger(s) in an inconsistent state をご覧ください。

6. レプリケーションのステータスが Load /Replication blocked の場合は、トランザクション LTRC を使用してレプリケーションのステータスをリセットします。レプリケーションのステータスのリセット方法に関する SAP の情報については、SAP Note 2204955 - SLT table is in status 'Load /Replication blocked をご覧ください。

7. 古いログがあれば削除します。

8. ソーステーブルのエントリを追加、更新、削除します。

9. BigQuery でレプリケーションの結果を検証します。

既存の列のデータ型を変更する

SAP ソーステーブルで既存の列のデータ型を変更する場合は、データ型をターゲット BigQuery テーブルと互換性のあるデータ型に変更するのか、互換性のないデータ型に変更するのかによって、特定の手順を行う必要があります。

既存の列の既存のデータ型と新しいデータ型が、ターゲット BigQuery テーブルの同じデータ型にマッピングされる場合、データ型はターゲット BigQuery テーブルのデータ型と互換性があります。たとえば、列のデータ型が、ソーステーブルで INT1 から INT2 に変更される場合、両方のデータ型は、ターゲット BigQuery テーブルのデータ型 INTEGER と互換性があります。

BigQuery Connector for SAP でのデータ型のマッピングの詳細については、データ型のマッピングをご覧ください。

データ型を互換性のあるデータ型に変更する

既存の列のデータ型を互換性のあるデータ型に変更するには、次の手順を行います。

1. データ型をソースシステムの互換性のあるデータ型に変更します。この手順の結果、既存の SLT トリガーが削除されるか、整合性のない状態に変更されます。

2. SLT システムで、SLT トリガーを再作成します。SLT トリガーを再作成する方法に関する SAP の詳細な情報については、SAP Note 2254376 - SLT trigger(s) in an inconsistent state をご覧ください。

3. レプリケーションのステータスが Load /Replication blocked の場合は、トランザクション LTRC を使用してレプリケーションのステータスをリセットします。レプリケーションのステータスのリセット方法に関する SAP の情報については、SAP Note 2204955 - SLT table is in status 'Load /Replication blocked をご覧ください。

4. 古いログがあれば削除します。

5. ソーステーブルのエントリを追加、更新、削除します。

6. BigQuery でレプリケーションの結果を検証します。

データ型を互換性のないデータ型に変更する

既存の列のデータ型を互換性のないデータ型に変更するには、次の手順を行います。

1. SLT システムで、トランザクション LTRC を使用してレプリケーションを停止します。
2. BigQuery でターゲット テーブルを削除します。
3. ソースシステムのデータ型を変更します。
4. SLT システムで、トランザクション LTRC を使用してレプリケーションを開始します。

注: レプリケーションを停止してレプリケーションを開始する手順によって、レコードが BigQuery に再読み込みされます。

拡張の終了

BigQuery Connector for SAP には、コード内に ABAP デベロッパーがコードを挿入してカスタム機能を追加できる拡張ポイントがいくつかあります。

次の表に、拡張ポイントがサポートする関数、メソッド、拡張ポイントを含むクラスを示します。

関数	クラス	メソッド	スポット	オプション
外部フィールド名、データ型など、フィールドのマッピングを更新します。	/GOOG/CL_IUUC_REPL_RUNTIME	CREATE_FLD_MAPPINGS	/GOOG/ES_IUUC_REPL_RUNTIME	/GOOG/UPDATE_FIELD_MAPPING
フィールドを追加または削除して、フィールド テーブルのマッピングを更新します。	/GOOG/CL_IUUC_REPL_RUNTIME	CREATE_FLD_MAPPINGS	/GOOG/ES_IUUC_REPL_RUNTIME	/GOOG/UPDATE_FIELD_MAPPINGS
ターゲット フィールドに変換する前にソース フィールドの値を変更します。	/GOOG/CL_IUUC_REPL_RUNTIME_BQ	FILL_TARGET_RECORDS	/GOOG/ES_IUUC_REPL_RUNTIME_BQ	/GOOG/CHANGE_SOURCE_FIELD
ソース フィールドをターゲット テーブルのターゲット フィールドに変換した後、ターゲット フィールドの値を変更します。	/GOOG/CL_IUUC_REPL_RUNTIME_BQ	FILL_TARGET_RECORDS	/GOOG/ES_IUUC_REPL_RUNTIME_BQ	/GOOG/FILL_TARGET_FIELD
ソーステーブルからターゲット テーブルへの変換時に、ソーステーブルに存在しないフィールドをターゲット テーブルに追加します。	/GOOG/CL_IUUC_REPL_RUNTIME_BQ	FILL_TARGET_RECORDS	/GOOG/ES_IUUC_REPL_RUNTIME_BQ	/GOOG/FILL_EXTRA_FIELD
BigQuery テーブルを作成する前に、BigQuery スキーマ フィールドを準備します。	/GOOG/CL_GCP_CLIENT_BQ	PREP_BQ_TABLE_SCHEMA	/GOOG/ES_GCP_CLIENT_BQ	/GOOG/PREPARE_SCHEMA_FIELD