BigQuery Connector for SAP 運用ガイド

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

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

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

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

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

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

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

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

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

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

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

  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

動的チャンクサイズ

チャンクのバイトサイズが BigQuery で許容される HTTP リクエストの最大バイトサイズを超えたためにエラーが発生した場合は、チャンクサイズを手動で小さくしてバイトサイズを縮小する必要があります。動的チャンクサイズ機能を使用すると、チャンクのバイトサイズが BigQuery で許容される HTTP リクエストの最大バイトサイズを超えたときに、自動的にチャンクサイズを減らし、BigQuery へのレプリケーションを再試行できます。動的チャンクサイズを使用すると、リクエストのバイトサイズの超過が原因で発生するほとんどのレプリケーション エラーを防ぐことができます。チャンクサイズが 1 に達していて、バイトサイズが各 HTTP リクエストのバイト数に関する BigQuery の上限を超えている場合にのみ、エラーを受信できます。

テーブルのトランザクション一の括転送構成で動的チャンクサイズを有効にするには、トランザクション /GOOG/SLT_SETTINGS を使用してチャンクサイズを有効にします。動的チャンクサイズの設定は任意です。動的チャンクサイズを有効にする方法については、以下をご覧ください。

動的チャンクサイズが有効になっている場合、BigQuery Connector for SAP で許可される最大チャンクサイズは、BigQuery の割り当て上限(50,000 レコード)内に収まります。

チャンクサイズの詳細については、部分サイズとチャンクサイズをご覧ください。

動的チャンクサイズの仕組み

動的チャンクサイズでは、初期チャンクサイズの HTTP リクエストがバイトサイズの BigQuery の上限を超えると、BigQuery Connector for SAP はチャンクサイズを小さくしてデータの送信を再試行します。BigQuery Connector for SAP は、特定のチャンクでデータが正常に転送されるか、チャンクサイズが 1 に達するまで、チャンクサイズを小さくして BigQuery へのデータの送信を再試行します。

データ転送が成功すると、そのチャンクサイズが残りのすべてのチャンクのチャンクサイズとして使用されます。SAP LT Replication Server アプリケーション ログに、各部分で成功した最終的なチャンクサイズが情報メッセージとして記録されます。

Dynamic chunking triggered. Chunk size reduced from INITIAL_CHUNK_SIZE_VALUE to FINAL_REDUCED_CHUNK_SIZE_VALUE

後続の部分と後続のレプリケーションでは、BigQuery Connector for SAP はトランザクション /GOOG/SLT_SETTINGS に構成されたチャンクサイズで BigQuery へのデータ送信を開始し、動的チャンクがトリガーされるとチャンクサイズを小さくします。

デフォルトでは、再試行のたびにチャンクサイズが 50% 縮小されます。チャンクサイズの縮小率を小さくしたり、大きくする場合は、詳細設定のパラメータを変更します。

テーブルの動的チャンクサイズが有効になっているときに、レプリケーション プロセスでチャンクサイズがどのように決まるかについて、例を挙げて説明します。この例では、SAP LT Replication Server の部分サイズが BigQuery Connector for SAP のチャンクサイズよりも大きく、トランザクション /GOOG/SLT_SETTINGS で 10,000 レコードのチャンクサイズが定義されています。BigQuery Connector for SAP は、次のように BigQuery へのレプリケーションを行います。

  1. 20,000 レコードのレプリケーションを開始すると、最初のチャンクのチャンクサイズは 10,000 レコードになります。ただし、HTTP リクエストのバイトサイズが 10 MB を超えると、BigQuery Connector for SAP はチャンクサイズを 50% 縮小し、新しいチャンクサイズは 5,000 レコードになります。

  2. BigQuery Connector for SAP は、5,000 レコードのチャンクサイズで送信を再試行します。ただし、HTTP リクエストのバイトサイズが 10 MB を超えると、BigQuery Connector for SAP はチャンクサイズをさらに 50% 縮小し、新しいチャンクサイズは 2,500 レコードになります。

  3. BigQuery Connector for SAP は、2,500 レコードのチャンクサイズで送信を再試行します。このチャンクの HTTP リクエストのバイトサイズが 10 MB より小さければ、レプリケーションは成功し、データが BigQuery に挿入されます。

  4. 各 HTTP リクエストのバイトサイズが 10 MB 未満である限り、後続のすべてのチャンクのチャンクサイズは 2,500 レコードになります。チャンクに対するその後の HTTP リクエストのバイトサイズが 10 MB を超えると、BigQuery Connector for SAP はチャンクサイズを再度縮小し、特定のチャンクのデータが正常に転送されるまで BigQuery への送信を再試行します。チャンクサイズの削減は、現在のレプリケーションの現在の部分でのみ使用されます。

動的チャンクサイズでのパフォーマンス

動的チャンクサイズは、BigQuery へのレプリケーションのパフォーマンスに影響する可能性があります。BigQuery Connector for SAP は、チャンクごとにチャンク内のレコード数を計算し、HTTP リクエストのバイトサイズを確認します。バイトサイズが 10 MB を超える場合、BigQuery Connector for SAP はチャンクサイズを小さくし、BigQuery へのデータの送信を再試行して全体的なレプリケーション時間を短縮します。

動的チャンクサイズは特定の状況でのみ使用してください。たとえば、特定のデータレコードに理想的なチャンクサイズを構成した後でも、リクエスト サイズが BigQuery の HTTP リクエストの上限を超える可能性があり、チャンクサイズ エラーの発生を防ぎたい場合に使用します。次に例を示します。

  • フィールド内のデータのスパースに大きなばらつきがあるソーステーブル。つまり、あるレコードでは維持されるフィールドが少なく、他のレコードでは維持されるフィールドが多い場合。
  • EDID4-SDATAVARI-CLUSTIDREPOSRC-DATA など、長いテキスト フィールドを含むソーステーブル。

テストフェーズで動的チャンクサイズを使用して、本番環境の SAP システムで定義できるテーブルに理想的なチャンクサイズを特定することもできます。

チャンクサイズの構成の詳細については、以下をご覧ください。

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

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

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

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

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

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

BigQuery Connector for SAP を更新する

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

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

  1. クラスタ テーブルのレプリケーションの修正プログラムを適用した場合や、JWT ベースの認証のデフォルトのオーディエンスを設定した場合は、BigQuery Connector for SAP をバージョン 2.6 に更新する前に、修正プログラムを削除する必要があります。修正プログラムの削除の詳細については、SAP ページの拡張機能の実装の作成、編集、削除をご覧ください。
  2. SAP LT Replication Server で構成を無効にします。
  3. 新しい SAP トランスポート リクエストをインポートします。
  4. インポートとオブジェクトの有効化が完了したら、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 にデータを送信します。

詳細情報

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 エラーとログ: LTROSLG1
  • Internet Communication Manager(HTTP 呼び出しと HTTPS 呼び出し): SMICM
  • セキュリティと証明書: STRUST
  • SAP トランスポート: STMS
  • RFC 接続: SM59
  • OS コマンド: SM69
  • パッケージ チェック: SE80
  • 承認チェック: SU53
  • バックグラウンド ジョブ: SM37
  • システムログ: SM21

BigQuery のモニタリング

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

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

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

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

BigQuery Connector for SAP の設定を表示する

BigQuery Connector for SAP の一括転送設定を表示するには、SAP GUI でトランザクション /GOOG/SLT_SETT_DISP を実行します。

テーブル作成ツール

SAP の空のソーステーブルの場合、SAP SLT により BigQuery でターゲット テーブルを作成できせん。空のソーステーブルのターゲット テーブルを BigQuery データセットに作成する必要がある場合は、テーブル作成ツールを使用できます。

テーブル作成ツールを実行する手順は次のとおりです。

  1. SAP GUI で、先頭に /n が付加されたトランザクション /GOOG/CREATE_BQ_TAB を実行します。

    /n/GOOG/CREATE_BQ_TAB
  2. [BQ 設定からターゲット テーブルを作成] 画面で、次のフィールドに値を入力します。

    • 一括転送キー: SAP テーブルを含む一括転送キー。
    • SAP テーブル名: 作成する必要がある SAP テーブル名。
  3. [Execute] アイコンをクリックします。ターゲット テーブルは BigQuery データセットに作成されます。

  4. 必要に応じて、BigQuery データセットで、テーブルが正しいスキーマで作成されていることを確認します。

一括フィールド変換ツール

BigQuery Connector for SAP は、ほとんどのフィールドで BigQuery のデータ型を自動的に提案しますが、フィールドを手動でマッピングすることが必要な場合があります。データ型を手動で各フィールドに割り当てる代わりに、一括フィールド変換ツールを使用して、/GOOG/SLT_SETTINGS トランザクションのフィールド マッピング画面ですべてのフィールドのデータ型割り当てをマッピングできます。一括フィールド変換ツールは、テーブルのすべてのフィールド マッピングを BigQuery の STRING 型に変換します。

テーブルがすでに複製されている場合や、LTRC トランザクションで初期読み込みのために追加されている場合は、それらのテーブルに一括フィールド変換ツールを使用しないでください。スキーマの不一致の問題が発生する可能性があります。このツールは、初期読み込みまたはレプリケーションが開始されていない SAP テーブルにのみ使用できます。

一括フィールド変換ツールを実行する手順は次のとおりです。

  1. SAP GUI で、先頭に /n が付加されたトランザクション /GOOG/MASS_CNVT_FMAP を実行します。

    /n/GOOG/MASS_CNVT_FMAP
  2. [一括フィールド変換] 画面で、次のフィールドに値を入力します。

    • 一括転送キー: SAP テーブルを含む一括転送キー。
    • SAP テーブル名: すべてのフィールド マッピングを STRING 型に変換する必要がある SAP テーブル名。
  3. [Execute] アイコンをクリックします。選択したテーブルのすべてのフィールド マッピングが STRING 型に変換されます。

負荷シミュレーション ツール

このセクションでは、負荷シミュレーション ツールの概要と機能について説明します。

負荷シミュレーション ツールは、BigQuery Connector for SAP のサポートツールで、BigQuery への SAP データのレプリケーションをシミュレートできます。このツールは、Google Cloud が BigQuery Connector for SAP 用に提供するトランスポートの一部です。負荷シミュレーション ツールでは、BigQuery Connector for SAP のビジネス アドイン(BAdI)を直接呼び出し、ソース SAP データを BigQuery にレプリケートします。負荷シミュレーション ツールは基盤となる SLT フレームワークを使用しないため、SLT トリガーに影響をありません。本番環境のデータ レプリケーションに負荷シミュレーション ツールを使用しないでください。

負荷シミュレーション ツールを使用すると、レプリケーション パフォーマンスを評価し、潜在的な問題や問題の根本原因を特定できます。また、BigQuery Connector for SAP で BigQuery から SAP に実際にデータをレプリケートする前に、これらの問題を解決できます。

負荷シミュレーション ツールの一般的なユースケースは次のとおりです。

  • ネットワーク接続、認可、認証の問題を再現してトラブルシューティングを行います。
  • 問題のトラブルシューティングを行うため、BigQuery API 呼び出しの詳細なログを生成します。
  • Cloud カスタマーケアからトラブルシューティングのサポートを受ける場合は、負荷シミュレーション ツールを実行して、そのログをカスタマーケア チームに提供してください。
  • レプリケーション プロセスの各ステップに要した時間を提供して、パフォーマンス指標を測定します。
  • 組み込みアーキテクチャの SAP LT Replication Server の場合は、SAP テーブルに最適なチャンクサイズを決定します。

カスタム トランザクション /GOOG/SLT_SETTINGS を使用して作成した負荷シミュレーション ツールで、サンプルの転送構成を使用します。負荷シミュレーション ツールに本番環境のデータセットと BigQuery テーブルを使用しないでください。

SAP LT Replication Server が組み込みアーキテクチャ内にある場合は、標準の SAP テーブル(MARAT001 など)を使用して負荷シミュレーション ツールを実行します。

SAP LT Replication Server がスタンドアロン アーキテクチャの場合は、Google Cloud が BigQuery Connector for SAP を使用して提供するサンプル テーブル /GOOG/TEST_REPL で負荷シミュレーション ツールを実行します。負荷シミュレーション ツールは、リモート システムからのソーステーブルの読み取りをサポートしていません。

Google Cloud 上の SAP データソースのアーキテクチャの詳細については、インストール アーキテクチャをご覧ください。

前提条件

負荷シミュレーション ツールを実行する前に、次の前提条件を満たしていることを確認してください。

負荷シミュレーション ツールの実行方法

負荷シミュレーション ツールの実行手順は次のとおりです。

  1. SAP GUI で、/n で始まる /GOOG/LOAD_SIMULATE トランザクションを入力します。

    /n/GOOG/LOAD_SIMULATE
  2. [Execute] アイコンをクリックします。[SLT Load Simulation] 画面が表示されます。

  3. [Processing Options] で、[Execute Simulation] オプションが選択されていることを確認します。

  4. [Selection Options] セクションで、次の仕様を入力します。

    • [Google Cloud Partner] フィールドのプルダウン メニューから、[BigQuery] を選択します。
    • [Mass Transfer Key] フィールドに、一括転送構成の一括転送キーを入力します。

      負荷シミュレーション ツールでサンプルの一括転送構成を使用します。本番環境データセットと BigQuery テーブルは使用しないでください。

    • [Table Name] フィールドに、サンプルの一括転送構成で指定したソース SAP テーブルの名前を入力します。

    • 必要に応じて、[WHERE Condition] フィールドにソーステーブルからのデータ選択条件を入力します。

      255 文字以内で指定できます。たとえば、SAP テーブル MARA に負荷シミュレーション ツールを実行し、特定の範囲からマテリアル番号を選択する必要がある場合は、[Where Condition] に MATNR GE '000000000400000001' AND MATNR LE '000000000600000001' のような値を指定します。

    • [Cycle Count] フィールドに、負荷シミュレーション ツールで実行する処理サイクルの数を入力します。

      これは、シミュレーション レポートを複数のサイクルで実行する方法を比較する際に役立ちます。この値は 1 よりも大きくする必要があります。

    • [Record Count per cycle] フィールドに、各処理サイクルで BigQuery に送信するレコード数を入力します。この値は 1 よりも大きくする必要があります。

    • [Portion size] フィールドに、SAP LT Replication Server が各部分で BigQuery Connector for SAP の BAdI に送信する [Records Count per cycle] のレコード数を入力します。

    • 必要に応じて、1 つ以上のフラグを選択します。

      • Exact Records Count: [Record Count per cycle] フィールドで指定されたレコード数とまったく同じ数のレコードが、各処理サイクルで BigQuery に送信されます。テーブルに十分なレコードがない場合、負荷シミュレーション ツールは既存のレコードを複製し、必要なレコード数を確保します。これらのレコードは、BigQuery にデータを挿入するためにのみ複製されます。ソーステーブルには挿入されません。

      • Use SLT Target Structure: SLT ロギング テーブルの構造を使用してソーステーブルのフィールドを取得します。このフラグが設定されていない場合、フィールドはソーステーブルから直接読み取られ、ターゲット構造が生成されます。SAP LT Replication Server のデータフローの詳細については、データフローの詳細なアーキテクチャ ビューをご覧ください。

      • Detailed Log: BigQuery Connector for SAP のすべての定義済みメソッドに対してログレコードが作成されます。このフラグが設定されていない場合、重要なメソッドのみがログに記録されます。

      • Clear Previous Results: 同じ一括転送と SAP テーブルに対して以前に生成されたログレコードをクリアします。このフラグが設定されていない場合、ログは以前の結果に追加されます。

  5. 負荷シミュレーション ツールを実行するには、[Execute] アイコンをクリックします。

  6. 負荷シミュレーションが完了したら、[Processing Options] セクションで [Display Report] ラジオボタンを選択します。

  7. [Selection Options] セクションで、次の仕様を入力します。

    • [Google Cloud Partner] フィールドのプルダウン メニューから、[BigQuery] を選択します。
    • [Mass Transfer Key] フィールドに、サンプルの一括転送構成の一括転送キーを入力します。
    • [Table Name] フィールドに、ソース SAP テーブルの名前を入力します。
    • 負荷シミュレーションの実行日ごとにレポートを表示したい場合は、[Report Date] フィールドに期間を指定します。
    • 最後に実行したレポートと現在のレポートを表示したい場合は、[Last Execution Only] フラグを選択します。
  8. レポートを表示するには、[Execute] アイコンをクリックします。

次の表に、シミュレーション レポートに表示される列を示します。

名前 説明
Transfer Key 一括転送構成の一括転送キー。
SAP Table BigQuery にレプリケートされている SAP テーブルの名前。
Execution Start Timestamp BigQuery Connector for SAP メソッドの実行が開始された時刻。
Completion Timestamp BigQuery Connector for SAP メソッドの実行が完了した時刻。
Job Number 完了した実行ごとに一意のジョブ番号。負荷シミュレーション ツールが実行されるたびに自動的に生成されます。
Cycle Numb レポートが生成される処理サイクルのシーケンス番号。シミュレーションの入力で指定されたサイクルごとのレコード数がサイクルごとに BigQuery に転送されます。
Portion Numb 部分のシーケンス番号。シミュレーションの入力で指定されたサイクルごとのレコード数は、指定された部分のサイズに基づいて分割されます。BigQuery Connector for SAP の BAdI が各部分で呼び出されます。
Class Name BigQuery Connector for SAP メソッドのクラス名。
Method Name BigQuery Connector for SAP メソッドの名前。BigQuery Connector for SAP によって呼び出されるメソッドは順番に記録されます。シミュレーションの入力で詳細ログフラグが選択されている場合、すべてのメソッドがログに記録されます。それ以外の場合は、重要なメソッドのみがログに記録されます。
Invoked by Method 現在の BigQuery Connector for SAP メソッドを呼び出した最後のメソッド。
Duration BigQuery Connector for SAP メソッドの実行にかかった合計時間。
Recs Count BigQuery Connector for SAP メソッドに渡されるレコード数。これは、レコードが渡されるメソッドにのみ表示されます。
URI Method HTTP メソッドの名前(ABAP メソッドが BigQuery API 呼び出しを行う場合)。
URI String HTTP URL(ABAP メソッドが BigQuery API 呼び出しを行う場合)。
Token Source 負荷シミュレーション ツールで使用されている認証トークンのソース。これは、/GOOG/CLIENT_KEY テーブルでトークンのキャッシュ保存が有効になっている場合にのみ適用されます。可能な値は次のとおりです。
  • A: 特定のプロセスの静的属性値。
  • M: 複数のプロセスで共有されるメモリの共有メモリ値。
  • L: メモリロックのある新しい値。メモリロックがあり、キャッシュ内のトークンを読み取ることができない場合に、新しいトークンが生成されます。
  • N: メモリロックなしの新しい値。トークンが期限切れになるかメモリ内に見つからない場合に、新しいトークンが生成されます。
Expiration Time 認証トークンの有効期限。
これは、/GOOG/CLIENT_KEY テーブルでトークンのキャッシュ保存が有効になっている場合にのみ適用されます。
Token Value 負荷シミュレーション ツールで BigQuery へのアクセスに使用する認証トークンの値。
Return code メソッド実行の戻りコード。可能な値は次のとおりです。
Error Text エラーのタイトル(ある場合)。
Error Description エラーの詳細情報。
Payload size BigQuery Insert API への HTTP ペイロード サイズ。メソッドの実行でエラーが発生し、ペイロード サイズが 10 MB を超える場合は、チャンクサイズを調整してペイロード サイズを減らすことができます。
Information text BigQuery Connector for SAP の BAdI が生成する関連情報。たとえば、動的チャンクがトリガーされると、Dynamic chunking triggered. Chunk size reduced from INITIAL_CHUNK_SIZE_VALUE to FINAL_REDUCED_CHUNK_SIZE_VALUE という情報メッセージが表示されます。
Status メソッドの実行ステータス。メソッドの実行が失敗した場合は、BigQuery Connector for SAP トラブルシューティング ガイドで問題を解決してください。

シミュレーション ツールのスケジューリング

SAP LT Replication Server でバックグラウンド ジョブとして自動的に実行されるように、プログラム名 /GOOG/R_LOAD_SIMULATION を使用して負荷シミュレーション ツールをスケジューリングできます。バックグラウンド ジョブのスケジューリングの詳細については、バックグラウンド ジョブのスケジューリングをご覧ください。

レプリケーションの検証

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

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

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

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

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

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

レコード数の SQL クエリ

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

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

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

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 ツールは、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 を入力します。詳細な手順については、以下をご覧ください。

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

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

  • 初期読み込み数: 読み込みモードで SAP LT Replication Server によって送信されたレコード数と、BigQuery に読み込まれたレコード数の比較。
  • レプリケーション数: 指定した日付に SAP LT Replication Server がレプリケーション モードで送信したレコード数と、指定した BigQuery に挿入されたレコード数の比較。
  • 現在の数: その時点でソーステーブル内にあるレコード数と BigQuery 内の一意のレコード数の比較。ソーステーブルの現在のカウントは、32 ビット整数の上限(-2,147,483,648~2,147,483,647)を超える数値を表示できません。

各レポートを個別に生成することも、ツールの実行時に [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 RecordsSKIP)フラグ。
  • Break at First Error FlagBREAK)フラグ。

SKIP フラグ。

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

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

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

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

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

BREAK フラグ。

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

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

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

レプリケーションを構成するときに、//GOOG/SLT_SETTINGS トランザクションで BREAK フラグを指定できます。新しい一括転送鍵を作成すると、BREAK フラグがデフォルトで有効になります。

仕様は /GOOG/BQ_MASTR 構成テーブルに保存されます。

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

SKIPBREAK の相互査証のマトリックス テーブル

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 は、現在の部分から残りのレコード チャンクを送信し、次の部分を取得します。BigQuery Connector for SAP は、レプリケーション ジョブの終了を SAP LT Replication Server に指示しません。

これがデフォルトです。

TRUE TRUE

BigQuery は、エラーを含むレコードのみを破棄し、現在のチャンクの残りのレコードを BigQuery テーブルに挿入します。

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 Connector for SAP: pro などのテーブル構造の変更を処理するをご覧ください。

拡張出口

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
HTTP エラーの場合は、問題のトラブルシューティングのため、BigQuery API への HTTP 呼び出しの後にロギングデータを収集します。 /GOOG/CL_GCP_CLIENT_BQ_SLT INSERT_TABLEDATA /GOOG/ES_GCP_CLIENT_BQ_SLT /GOOG/LOG_INSERT_ERROR

詳細設定

必要に応じて、BigQuery Connector for SAP の詳細設定を変更できます。詳細設定パラメータの変更は、包括的な分析を実施し、新しい値によるパフォーマンスへの影響を確認したうえで行うことをおすすめします。BigQuery Connector for SAP の詳細設定の変更によって発生したエラーやパフォーマンス上の問題については、ユーザー側の責任で対処する必要があります。

BigQuery Connector for SAP の詳細設定はシステムレベルで適用され、すべての一括転送キーで共通です。詳細設定パラメータが変更されていない場合、BigQuery Connector for SAP はデフォルトの設定で動作します。

詳細設定パラメータの変更手順は次のとおりです。

  1. SAP GUI で、/n で始まる /GOOG/SLT_SETTINGS トランザクションを入力します。

    /n/GOOG/SLT_SETTINGS
  2. /GOOG/SLT_SETTINGS トランザクションの起動画面の [Settings Table] プルダウン メニューから [Parameters] を選択します。

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

  4. [Insert Row] アイコンをクリックします。

  5. 表示された行で、次の設定を指定します。

    1. [Parameter Name] フィールドに、パラメータの名前を入力します。パラメータの説明は自動的に入力されます。
    2. [Parameter Value] フィールドに値を入力します。

      詳細設定パラメータの詳細については、詳細設定パラメータをご覧ください。

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

    詳細設定がレコードとして /GOOG/BQ_PARAM 構成テーブルに保存されます。[Changed By]、[Changed On]、[Changed At] の各フィールドには、値が自動的に挿入されます。

詳細設定パラメータ

次の表に、BigQuery Connector for SAP の詳細設定パラメータを示します。

パラメータ名 説明 デフォルト値 有効な値
CHUNK_SIZE_DEF これは、BigQuery Connector for SAP がサポートするデフォルトのチャンクサイズです。
設定でチャンクサイズが指定されていない場合、デフォルトのチャンクサイズが使用されます。
10,000 値は BigQuery の割り当て上限の範囲内でなければなりません。
PERC_REDUC_DEF チャンクサイズの縮小率。
動的チャンクサイズが有効になっている場合、理想的なチャンクサイズに達し、チャンク内のデータが BigQuery に正常に転送されるまで、この割合でチャックサイズが縮小されます。
50 値は 1~99 にする必要があります。
CMD_EXEC_TRIES Google Cloud で実行されていない SAP システムで、トランザクション SM69 で作成したオペレーティング システム コマンドが Google Cloud からアクセス トークンを取得できない場合、これは BigQuery Connector for SAP がトークンの取得を再試行する回数になります。 5 このパラメータに割り当てることができる最小値は 1 です。少なくとも 1 回再試行するには、値 2 を設定します。このパラメータの最大値は、トークンの取得の再試行がレプリケーション パフォーマンスに与える影響を分析した後で設定する必要があります。
CMD_SECS_DEFLT トークンのキャッシュ保存を有効にした場合に、キャッシュ内のトークンが期限切れになるまでの秒数。 3500 値は 1~3599 にする必要があります。