OceanBase logo

OceanBase

トランザクション処理、分析、AIワークロードに最適な分散データベース

プロダクト概要
デプロイを自由に

OceanBase Cloud

OceanBaseの導入とスケーリングを最適化

エンタープライズ版

自社インフラ上での運用・管理に対応

オープンソース版を試す

コミュニティ版

開発者向けオープンソース分散データベース

OceanBase seekdb

AIネイティブなオープンソースの検索データベース

顧客事例

さまざまな業界の企業による導入事例を紹介します。

さらに見る
利用シーン別

あらゆるシナリオに対応するOLTP

ハイブリッドクラウドソリューション

大容量ストレージデータベースのコスト削減

リアルタイム分析混合ワークロード

複数インスタンスの統合

ドキュメント

会社概要

OceanBaseの企業情報、パートナーシップ、そして信頼性・セキュリティへの取り組みについて紹介します。

OceanBaseについて

トラストセンター

法的情報

お問い合わせ

日本 - 日本語
International - English
中国站 - 简体中文
クラウドで始める

OceanBase

トランザクション処理、分析、AIワークロードに最適な分散データベース

プロダクト概要
デプロイを自由に

OceanBase Cloud

OceanBaseの導入とスケーリングを最適化

エンタープライズ版

自社インフラ上での運用・管理に対応

オープンソース版を試す

コミュニティ版

開発者向けオープンソース分散データベース

OceanBase seekdb

AIネイティブなオープンソースの検索データベース

顧客事例

さまざまな業界の企業による導入事例を紹介します。

さらに見る
利用シーン別

あらゆるシナリオに対応するOLTP

ハイブリッドクラウドソリューション

大容量ストレージデータベースのコスト削減

リアルタイム分析混合ワークロード

複数インスタンスの統合

OceanBaseの企業情報、パートナーシップ、そして信頼性・セキュリティへの取り組みについて紹介します。

OceanBaseについて

トラストセンター

法的情報

お問い合わせ

クラウドで始める
编组
すべての製品
    • データベース
    • アイコンOceanBaseデータベース
    • アイコンOceanBase Cloud
アイコン

OceanBaseデータベース

SQL - V4.4.2

    OceanBase ロゴ

    AI時代を支える分散データベース

    日本 - 日本語
    International - English
    中国站 - 简体中文
    プロダクト
    OceanBase Cloudエンタープライズ版コミュニティ版OceanBase seekdb
    会社概要
    OceanBaseについてトラストセンター法的情報お問い合わせ
    公式アカウント
    ConnpassXQiitaLumaGitHub

    © OceanBase 2026. All rights reserved

    クラウドサービス契約個人情報保護ポリシーセキュリティ
    お問い合わせ
    ドキュメントフィードバック
    1. ホーム
    2. OceanBaseデータベース
    3. SQL
    4. V4.4.2
    アイコンOceanBaseデータベース
    SQL - V 4.4.2
    データベース
    • OceanBaseデータベース
    • OceanBase Cloud
    SQL
    KV
    • V 4.4.2
    • V 4.3.5

    バックアップ・リストアのパフォーマンスチューニング

    最終更新日:2026-06-15 02:31:30  更新
    シェア
    このページの内容
    パフォーマンスチューニングの手法
    リソース設定関連
    クラスタレベル構成パラメータ sys_bkgd_net_percentage
    リソースマネージャーによるリソース分離
    データバックアップ関連
    ログアーカイブ関連
    物理復元関連
    テーブルレベル復元関連
    物理復元補助テナント段階
    テナント間テーブルインポート段階
    関連ドキュメント

    折りたたみ

    シェア

    パフォーマンスチューニングの手法

    理想的には、バックアップ・リストアのパフォーマンスは、データの分散状況(パーティション数とサイズ)およびハードウェア(CPU、ディスク、ネットワーク)の性能にのみ制限されるべきです。しかし、デフォルト設定では、ハードウェアの性能を十分に活用できない場合があります。そのため、OceanBaseデータベースは、リソース分離戦略および以下の構成パラメータを提供し、バックアップ・リストアのパフォーマンスチューニングを行います。

    • ネットワーク設定:構成パラメータ sys_bkgd_net_percentage は、バックグラウンドシステムタスク(バックアップ・リストアタスクを含む)が使用できる総ネットワーク帯域幅の割合を制限します。sys_bkgd_net_percentage を適切な値に設定することで、フロントエンド業務に影響を与えることなく、バックアップ・リストアタスクがネットワーク帯域幅リソースを最大限に活用できます。

    • CPU・I/O設定:同時に、OceanBaseデータベースは、異なるタイプのタスクのCPU・I/O使用量を制限するためのResource Managerリソース分離メカニズムも提供しています。バックアップ・リストアタスクにリソース分離を設定した場合は、実際のリソースとビジネス要件に基づいて上限を設定し、バックアップ・リストアタスクのCPUおよびI/O使用量がボトルネックに達するのを防ぎます。

    • その他の設定:CPU、I/O、およびネットワークリソースが十分であることを確保した上で、関連する構成パラメータ(ha_low_thread_score、log_archive_concurrency、log_restore_concurrency、ha_high_thread_score など)を設定することで、バックアップ・リストアタスクの並列度を向上させ、さらにパフォーマンスを高めることができます。

    リソース設定関連

    クラスタレベル構成パラメータ sys_bkgd_net_percentage

    構成パラメータ sys_bkgd_net_percentage は、バックグラウンドシステムタスクが使用できるネットワーク帯域幅の割合を設定します。デフォルト値はマシンのNIC速度の60%です。帯域幅が満杯の場合、業務リクエストに影響を与えない範囲で、構成パラメータ sys_bkgd_net_percentage の値を適宜引き上げることができます。

    設定が成功した後、以下の方法でログを確認できます:

    1. admin ユーザーでOBServerノードが配置されているマシンにログインします。

    2. OceanBaseデータベースソフトウェアのインストールディレクトリに移動します。

      以下では、OceanBaseデータベースソフトウェアのインストールパスが /home/admin/oceanbase/ である例を示します。操作時は実際の環境に準じてください。

      [admin@xxx /]$ cd /home/admin/oceanbase
      
    3. 以下のコマンドを実行して、NIC速度を確認します。

      [admin@xxx oceanbase]$ grep -E 'print band limit|succeed to init_bandwidth_throttle' log/observer.log*
      

      ここで、observer.log はクラスタ起動時のobserverログです。

      例えば、クエリ結果は次のとおりです:

      log/observer.log.20210811100806:[2021-08-11 10:06:32.934433] INFO  [SERVER] ob_server.cpp:1783 [76957] [0] [Y0-0000000000000000] [lt=4] [dc=0] succeed to init_bandwidth_throttle(sys_bkgd_net_percentage_=60,ethernet_speed_=1310720000,rate=786432000)
      log/observer.log.20210811100806:[2021-08-1110:07:42.351813] INFO  [COMMON] utility.cpp:1487 [77169][418] [Y9FA64586E9E-0005C93F15DAE715] [lt=11] [dc=0] print band limit(comment= in , copy_KB=0, sleep_ms_sum=0, speed_KB_per_s=0, total_sleep_ms=0,total__bytes=531, rate_KB/s=786432,print_interval_ms=69417)
      

      最初のクエリ結果では、sys_bkgd_net_percentage_=60 はバックグラウンドシステムタスクが使用できるネットワーク帯域幅がマシンのNIC速度の60%であることを示しています。network_speed=1310720000 は、OceanBaseデータベースが認識したマシンのNICの最大速度が1310720000 B/sであることを示しています。rate=786432000 は、制限後の最大速度が786432000 B/sであり、rate = network_speed * sys_bkgd_net_percentage であることを示しています。

      2番目のクエリ結果では、rate_KB/s=786432 は、OceanBaseデータベースが認識した制限後の最大速度(rate)が786432 KB/sであることを示しています。

    OceanBaseデータベースが認識したNIC速度が不正確な場合があるため、ログを確認した後、OceanBaseデータベースが認識した速度が実際の速度と一致しない場合は、NIC速度の確認 を参照して修正することができます。

    修正後、ビュー V$OB_NIC_INFO を確認することで、修正後のNIC速度が有効になっているかどうかを確認できます。

    リソースマネージャーによるリソース分離

    リソースマネージャーは、OceanBaseデータベースのリソース分離メカニズムであり、関数レベルのリソース分離を通じて、CPU、IOPS、ネットワーク帯域幅など、異なるバックグラウンドタスクのリソース上限を設定できます。リソース分離の詳細については、リソース分離の概要を参照してください。

    関数レベルのリソース分離において、バックアップ・リストア関連のバックグラウンドタスクは以下のとおりです:

    • ha_high:レプリケーション、Rebuild、復元などの高優先順位・高信頼性タスク。
    • ha_mid:移行タスクなどの中優先順位・高信頼性タスク。
    • ha_low:バックアップやバックアップクリーンアップなどの低優先順位・高信頼性タスク。

    ビューDBA_OB_RSRC_DIRECTIVESを使用して、現在のテナントに設定されたリソース分離計画を確認できます。クエリ結果が空の場合、テナントにリソース分離計画が設定されていないことを意味します。バックグラウンドタスクに対応するレコードが検索された場合、まずCPU、I/O、ネットワーク帯域幅などがボトルネックに達しており、かつリソース分離の制限と一致しているかどうか確認してください。一致していることを確認した上で、フロントエンド業務に影響を与えない範囲で、適宜リソース分離計画を変更することを推奨します。リソース計画の変更手順の詳細については、リソース管理計画の更新(MySQLモード)およびリソース管理計画の更新(Oracleモード)を参照してください。

    バックアップ・リストアの性能テストを実行する際には、リソース分離計画を設定することは推奨されません。

    データバックアップ関連

    パラメータ
    説明
    デフォルト値
    設定の説明
    ha_low_thread_score テナントレベルのパラメータで、データバックアップの並列数を制御します。 0、デフォルトの並列数は2を意味します 小規模テナント(テナントCPU ≤ 4C)はデフォルト値に設定することを推奨します。大規模テナントは、まず10に設定し、バックアップ速度が遅すぎる場合は必要に応じて値を2倍に調整できます。バックアップ・リストアの性能テストを実行する際は、最大値の100に直接設定することを推奨します。

    ログアーカイブ関連

    パラメータ
    説明
    デフォルト値
    設定の説明
    log_archive_concurrency テナントレベルのパラメータで、ログアーカイブの並列数を制御します。 0、現在のバージョンでは、テナントの MAX_CPU に基づいて以下の適応ルールでアーカイブワーカースレッド数を計算します。
    • テナントの MAX_CPU <= 8 の場合、アーカイブスレッド数 = MAX_CPU となります。
    • 8 < テナントの MAX_CPU < 32 の場合、アーカイブスレッド数 = テナントの MAX_CPU / 2 となり、最小値は 8 です。
    • テナントの MAX_CPU >= 32 の場合、アーカイブスレッド数 = テナントの MAX_CPU / 4 となり、最小値は 16 です。
    大規模および小規模なテナントは、どちらもデフォルト値を維持し、適応ルールに従ってワーカースレッド数を計算することを推奨します。

    物理復元関連

    パラメータ
    説明
    デフォルト値
    設定の説明
    log_restore_concurrency テナントレベルの構成パラメータで、ログ復元の並列数を制御します。 0、テナントの MAX_CPU のコア数を並列数とすることを表します この構成パラメータの値を大きくすると、ワーカースレッドが増加するだけでなく、メモリリソースの消費も増加します。デフォルト値の0に設定し、復元速度が遅い場合にのみ、マシンの実際のリソースに応じて適切に値を大きくすることを推奨します。
    ha_high_thread_score テナントレベルの構成パラメータで、データ復元の並列数を制御します。 0、デフォルトの並列数は8を表します 性能テスト時はデフォルト値の使用を推奨します。バックアップ・リストアの性能テストを実行する場合は、最大値の100に調整することを推奨します。
    _restore_idle_time クラスタレベルの非表示構成パラメータで、RS復元のスケジューリング間隔を制御します。 1m、1分を表します 10秒に調整した場合、データ復元にかかる時間は数十秒から2分程度短縮されます。高い性能要件を持つ小規模テナント(テナントCPU ≤ 4C)に対して調整することを推奨します。そうでない場合は、効果は顕著ではありません。

    テーブルレベル復元関連

    物理復元補助テナント段階

    テーブルレベル復元関連ビューの紹介 のビューから、このタスクに関連する一時的な補助テナント名を取得します。補助テナント名はデフォルトで AUX をプレフィックスとして付加されて識別されます。

    テーブルレベル復元における物理復元補助テナント段階は、物理復元と一致します。この段階に関連するパフォーマンスチューニングについては、本ドキュメントの 物理復元関連 の内容を参照して調整してください。

    テナント間テーブルインポート段階

    パラメータ
    説明
    デフォルト値
    設定の説明
    ddl_thread_score テナントレベルの構成パラメータで、テナントが配置されているOBServerノード上のテーブルレベル復元スレッドプールの容量を制御します。 0、デフォルトのテーブルレベル復元スレッドプールの容量は2を意味します
    • 小規模テナント(テナントCPU ≤ 4C)は4に設定することを推奨します。
    • 大規模テナントは最初に8に設定し、復元速度が遅い場合は、テーブルレベル復元の並列パラメータrecover_table_concurrencyとrecover_table_dopの設定状況およびテナントの実際のリソース状況に応じて、必要に応じて値を2倍に調整します。

      単一テーブルの復元に必要な最大並列スレッド数 = パーティション数 × recover_table_dop。例えば、あるテーブルが4つのパーティションを持ち、かつrecover_table_dop=2の場合、必要な並列スレッド数は4×2=8です。

      同時に、複数テーブルの復元に必要な最大並列スレッド数は、各テーブルの復元に必要な最大並列スレッド数の合計です。例:2つのテーブルを復元する必要があり、テーブル1が4つのパーティション、テーブル2が8つのパーティションを持ち、かつrecover_table_dop=2の場合、必要な最大並列スレッド数は4×2+8×2=24です。

    recover_table_concurrency テナントレベルの構成パラメータで、複数テーブルの並列復元の並列度を制御し、同時にクロステナントテーブルエクスポートを実行できるテーブル数を設定します。 0、デフォルトでは1つのテーブルがクロステナントテーブルエクスポートを実行できることを意味します デフォルト値0に統一して設定することを推奨します。また:
    • 複数のテーブルを復元するシナリオで、復元速度が遅い場合は、テナントの実際のリソース状況に応じて値を2倍に増やしてください。
    • 多数の小規模テーブルを復元するシナリオでは、一般的に8または16に設定することを推奨します。

    注意

    クロステナントテーブルエクスポートは大量の一時ストレージ空間とメモリリソースを消費するため、テナントのリソース状況を踏まえて適切に値を大きく設定することを推奨します。そのうち、一時ストレージ空間の消費はインデックス再構築段階で発生し、テーブルのデータ量が非常に大きい場合、大量の一時空間を消費する可能性があります。一時空間の消費が多すぎると、クエリの失敗、トランザクションのロールバック、サービスの利用不能などの問題が発生する可能性があります。

    recover_table_dop テナントレベルの構成パラメータで、単一テーブルの復元の並列度を制御します。 0、デフォルトの並列度は1を意味します 8または16に統一して設定することを推奨します。これでほとんどのシナリオ要件を満たせます。

    復元するテーブルがデータ量の多い非パーティションテーブルである場合、または復元するテーブルにデータ量の多いパーティションが存在する場合、パーティションのデータ量に応じてrecover_table_dopの値を2倍に調整することを推奨します。

    関連ドキュメント

    • NIC速度の確認

    • テナント内リソース分離の設定(MySQLモード)

    • テナント内リソース分離の設定(Oracleモード)

    • リソース管理計画の更新(MySQLモード)

    • リソース管理計画の更新(Oracleモード)

    前のトピック

    テーブルレベル復元関連ビューの紹介
    最後

    次のトピック

    バックアップパスとアーカイブパスのソース側設定例
    次
    このページの内容
    パフォーマンスチューニングの手法
    リソース設定関連
    クラスタレベル構成パラメータ sys_bkgd_net_percentage
    リソースマネージャーによるリソース分離
    データバックアップ関連
    ログアーカイブ関連
    物理復元関連
    テーブルレベル復元関連
    物理復元補助テナント段階
    テナント間テーブルインポート段階
    関連ドキュメント