SIOS TECHNOLOGY CORP.

SAP HANA リソース階層のテスト

テストシナリオ

SAP HANA Recovery Kitの動作を理解するには、次のテストを実行してください。テストを実行する前に、次の前提条件を満たす必要があります。

  • LifeKeeper およびSAP HANA データベースは、SIOS および SAP が提供するインストール手順に従ってインストールおよび設定する必要があります。
  • SAP HANA システムレプリケーションは、有効なレプリケーションモード (sync、syncmem、または async) および操作モード (delta_datashipping、logreplay、または logreplay_readaccess) のいずれかを使用して登録された、クラスター内のすべてのサーバーで有効かつアクティブである必要があります。 詳細については、SAP HANA システムレプリケーションの構成 を参照してください。
  • SAP HANA データベースに関連付けられた切り替え可能なIPアドレスを LifeKeeper IP リソースで管理する場合、IPリソースに対する SAP HANA リソースの依存関係が存在する必要があります。詳細については、 SAP HANA リソース階層の作成 のステップ 7 を参照してください。

テストケース

高可用性 SAP HANAクラスターを運用環境に配置する前に、一般的な障害と復旧のシナリオを十分にテストしておくことが非常に重要です。このページに記載されているテストケースは、高可用性 SAP HANA クラスターデプロイの包括的なテスト計画を開発する際の出発点として使用することを目的としています。以下のサンプル値は、全体を通して使用されます。

Primary Server Host Name node1
Standby Server Host Name node2/node3/node4
SAP SID SPS
SAP HANA Database Instance HDB00
SAP HANA LifeKeeper Resource Tag Name HANA-SPS_HDB00
HANA System Replication Primary Site Name SiteA
HANA System Replication Secondary Site Name SiteB/SiteC/SiteD
HANA System Replication Mode sync
HANA System Replication Operation Mode logreplay

テスト時には、これらのサンプル値をテストを実行する環境に適合させる必要があります。

手動のスイッチオーバー

このセクションのテストケースでは、手動スイッチオーバーを正常に実行できることを確認します。


手動スイッチオーバーテスト
説明
SAP HANA リソース階層は、プライマリーノードからスタンバイ サーバーに手動で切り替えることができます。
前提条件
このテストを実行する前に、次の条件が満たされていることを確認してください。

  • 全サーバー（ノード 1 とセカンダリーノード）が稼働しており、
  • SAP HANA リソース階層は、ノード 1 では In-Service (ISP)、ノード 2 では Out-of-Service (OSU) で、
  • HANA システムのレプリケーションは同期しています。
テストステップ
  1. 次のいずれかの方法を使用して、ノード 2でSAP HANAリソース階層を In-Service にします。

    1. LifeKeeper GUIで、ノード 2の HANA-SPS_HDB 00 リソースを右クリックし、コンテキストメニューから 「In Service …」 を選択します。表示される確認ダイアログで、 「In Service」 をクリックしてスイッチオーバープロセスを開始します。

    2. ノード 2のターミナルウィンドウから、lkadmin グループ権限を持つユーザー(例えば、root ユーザとして)として次のコマンドを実行します。

      [root@node2 ~]# sudo /opt/LifeKeeper/bin/lkcli resource restore --tag HANA-SPS_HDB00
想定される結果
  1. SAP HANA リソース階層は、ノード 1 で正常に Out-of-Service になりました。 このプロセス中に、データベースはノード 1 で停止され、依存リソース (該当する場合は関連付けられた仮想 IP アドレスなど) もノード 1 で削除されます。

  2. SAP HANAリソース階層は、ノード 2で正常に In-Service になりました。このプロセス中に、次の操作を行います。
    1. 依存リソース(関連する仮想IPリソースなど (該当する場合)は、ノード 2 で In-Service になります。
    2. ノード 2 で実行中のデータベースインスタンスは、HANA システムレプリケーションのプライマリーレプリケーションロールに昇格されます。
    3. ノード 1 のデータベースインスタンスは、適切な HSR パラメーター (サイト名「SiteA」、レプリケーションモード「sync」、操作モード「logreplay」など) を使用して、HANA システムレプリケーションのセカンダリーレプリケーションサイトとして登録されます。
    4. データベースインスタンスが ノード 1 で起動されます。

注記: ノード 1でのデータベースの登録と再起動のプロセスには、数分かかる場合があります。このプロセスが完了すると、LifeKeeper GUIはノード 1 上のHANA-SPS_HDB 00リソースの状態を 「Standby-In Sync」 として表示します。

ハンドシェイクテイクオーバーテスト
注記: このテストケースは、LifeKeeper v9.5.2以降が必要です。
説明
SAP HANA のリソース階層は、SAP HANA の「Takeover with Handshake」機能を使用して、プライマリーノードからスタンバイノードに手動で切り替えることができます。
前提条件
このテストを実行する前に、次のことを確認してください。

  • 両方のサーバー (ノード 1 とノード 2) が稼働しており、
  • SAP HANA リソース階層は、ノード 1 では In-Service (ISP)、ノード 2 では Out-of-Service (OSU) で、
  • HANA システムのレプリケーションは同期している。
テストステップ
  1. 次のいずれかの方法を使用して、ノード 2 で SAP HANA リソース階層を In-Service にします。

    1. LifeKeeper GUI で、ノード 2 の HANA-SPS_HDB00 リソースを右クリックし、コンテキストメニューから [In Service – Takeover with Handshake…] を選択します。 表示される確認ダイアログで、[Perform Takeover] をクリックしてスイッチオーバープロセスを開始します。

    2. ノード 1 または ノード 2 のいずれかのターミナルウィンドウから、lkadmin グループ権限を持つユーザーとして (たとえば、root ユーザーとして) 次のコマンドを実行します。

      # sudo /opt/LifeKeeper/bin/lkcli resource config hana --tag HANA-SPS_HDB00 --takeover_with_handshake node2
想定される結果
  1. SAP HANA リソース階層は、ノード 1 で正常に Out-of-Service になります。 このプロセス中、データベースはノード 1 で停止されませんが、依存リソース (該当する場合は関連付けられた仮想 IP アドレスなど) はノード 1 で削除されます。

  2. SAP HANA リソース階層は、ノード 2 正常に In-Service になりました。このプロセス中に、次の操作を行います。
    1. 依存するリソース（関連する仮想IPリソースなど、該当する場合）は、ノード 2 上で In-Service 化されます。
    2. ノード 2 上の稼働中のデータベースインスタンスは、HANA システムレプリケーションのプライマリーレプリケーションの役割に昇格します。HSR のテイクオーバープロセス中、ノード 1 上のデータベースインスタンスは中断されます。
    3. ノード 1 の中断されたデータベースインスタンスが停止されます。
    4. ノード 1 のデータベースインスタンスは、適切な HSR パラメーター (サイト名「SiteA」、レプリケーションモード「sync」、操作モード「logreplay」など) を使用して、HANA システムレプリケーションのセカンダリーレプリケーションサイトとして登録されます。
    5. ノード 1 でデータベースインスタンスを起動します。

注記: ノード 1 のデータベースの停止、登録、再起動のプロセスには数分かかる場合があります。このプロセスが完了すると、LifeKeeper の GUI にはノード 1 の HANA-SPS_HDB00 リソースの状態が「Standby – In Sync」と表示されるようになります。

グレイスフルシャットダウン

このセクションのテストケースでは、各サーバーが正常に再起動されたときの SAP HANA リソース階層の予想される動作を検証します。


プライマリーノードリブートテスト
説明
プライマリーノードが正常に再起動されると、SAP HANA リソース階層は期待通りに動作します。
前提条件
このテストを実行する前に、次のことを確認してください。

  • 両方のサーバー (ノード 1 とノード 2) が稼働しており、
  • SAP HANA リソース階層は、ノード 1 では In-Service (ISP)、ノード 2 では Out-of-Service (OSU) で、
  • HANA システムのレプリケーションは同期している。
テストステップ
  1. グレイスフルリブート ノード 1:

    [root@node1 ~]# reboot now
想定される結果
  1. ノード1 がシャットダウンしている間
    1. SAP HANA リソース階層は、ノード1 で正常に Out-of-Service になりました。 このプロセス中に、データベースはノード 1 で停止され、依存リソース (該当する場合は関連付けられた仮想 IP アドレスなど) もノード 1 で削除されます。
    2. [node1 で「Switchover on Shutdown」が有効になっている場合] SAP HANAリソース階層は、ノード 2で正常に In-Service になりました。このプロセス中に、次の操作を行います。
      1. 依存するリソース (該当する場合は関連付けられた仮想 IP リソースなど) は、ノード 2 で In-Service になります。
      2. ノード 2 で実行中のデータベースインスタンスは、HANA システムレプリケーションのプライマリーレプリケーションロールに昇格されます。 ノード 1 がシャットダウンされたため、HANA システムのレプリケーションは現在非アクティブです。

  2. ノード 1 がオンラインに戻った後:
    1. [ノード 1 で「Switchover on Shutdown」が無効になっている場合] SAP HANAリソース階層は、ノード 1で自動的に In-Service に戻ります。このプロセス中に、次の操作を行います。
      1. 依存するリソース (該当する場合は関連付けられた仮想 IP リソースなど) は、ノード 1 で In-Service になります。
      2. ノード 1 のデータベースインスタンスが開始され、HANA システムレプリケーションが ノード 2 のセカンダリーレプリケーションサイトに再開されます。
    2. [ノード 1 で「Switchover on Shutdown」が有効になっている場合] SAP HANA リソース階層は、ノード 2 で In-Service のままです。
      1. ノード 1 がオンラインに戻った後の ノード 2での最初の quickCheck サイクル中に、SAP HANA Recovery Kit によって、データベースインスタンスが ノード 1で実行されていないことが検出され、“remoteregisterdb“イベントが発生します。
      2. 「remoteregisterdb」イベントスクリプトは、適切な HSR パラメーター (サイト名「SiteA」、レプリケーションモード「sync」、操作モード「logreplay」など) を使用してノード 1 をセカンダリー HANA システムレプリケーションサイトとして登録し、ノード 1 でデータベースインスタンスを起動します。

        注意： ノード 1 でデータベースを登録して再起動するプロセスには、数分かかる場合があります。 このプロセスが完了すると、LifeKeeper GUI はノード 1 の HANA-SPS_HDB00 リソースの状態を「Standby – In Sync」として表示します。

スタンバイノードリブートテスト
説明
スタンバイノードが正常に再起動されると、SAP HANA リソース階層は期待通りに動作します。
前提条件
このテストを実行する前に、次のことを確認してください。

  • 両方のサーバー (ノード 1 とノード 2) が稼働しており、
  • SAP HANA リソース階層は、ノード 1 では In-Service (ISP)、ノード 2 では Out-of-Service (OSU) で、
  • HANA システムのレプリケーションは同期している。
テストステップ
  1. グレイスフルリブート　ノード 2

    [root@node2 ~]# reboot now
想定される結果
  1. ノード 2 がシャットダウンしている間、データベースインスタンスは ノード 2 で停止します。 ノード 2 が再起動し、セカンダリーデータベースインスタンスが再起動されるまで、HANA システムレプリケーションは非アクティブになります。

  2. ノード 2 がオンラインに戻った後
    1. ノード 2 がオンラインに戻った後の ノード 1 での最初の quickCheck サイクル中に、SAP HANA Recovery Kit はデータベースインスタンスが ノード 2 で実行されていないことを検出し、「remoteregisterdb」イベントを発生させます。
    2. 「remoteregisterdb」イベント スクリプトは、ノード 2 でデータベースインスタンスを開始します。

注記: ノード 2 でデータベースを再起動するプロセスには、数分かかる場合があります。 このプロセスが完了すると、LifeKeeper GUI は ノード 2 の HANA-SPS_HDB00 リソースの状態を「Standby – In Sync」として表示します。

マシンフェイルオーバー

このセクションのテストケースでは、プライマリーノードが強制的に再起動されたときの SAP HANA リソース階層の予想される動作を検証します。


マシンフェイルオーバーテスト
説明
プライマリーノードが強制的に再起動されると、SAP HANA リソース階層が期待通りに動作します。
前提条件
このテストを実行する前に、次のことを確認してください。

  • 両方のサーバー (ノード 1 とノード 2) が稼働しており、
  • SAP HANA リソース階層は、ノード 1 では In-Service (ISP)、ノード 2 では Out-of-Service (OSU) で、
  • HANA システムのレプリケーションは同期している。
テストステップ
  1. ノード 1 を強制的に再起動します。

    [root@node1 ~]# echo b > /proc/sysrq-trigger
想定される結果
  1. ノード 2のLifeKeeperが ノード 1がダウンしていることを検出すると(正確な時間は 「LifeKeeper ハートビートの調整」 に使用される値によって異なります。)、SAP HANAリソース階層が ノード 2で正常に In-Service になります。このプロセス中に、次の操作を行います。
    1. 依存するリソース (該当する場合は関連付けられた仮想 IP リソースなど) は、ノード 2 で In-Service になります。
    2. ノード 2 で実行中のデータベースインスタンスは、HANA システムレプリケーションのプライマリーレプリケーションロールに昇格されます。 ノード 1 がシャットダウンされたため、HANA システムのレプリケーションは現在非アクティブです。

  2. ノード 1 がオンラインに戻った後、SAP HANA リソース階層は ノード 2 で In-Service のままになります。
    1. ノード 1 がオンラインに戻った後の ノード 2 での最初の quickCheck サイクル中に、SAP HANA Recovery Kit はデータベースインスタンスが ノード 1 で実行されていないことを検出し、「remoteregisterdb」イベントを発生させます。
    2. 「remoteregisterdb」イベント スクリプトは、適切な HSR パラメーター (サイト名「SiteA」、レプリケーションモード「sync」、操作モード「logreplay」など) を使用してノード 1 をセカンダリー HANA システムレプリケーションサイトとして登録し、ノード 1 でデータベースインスタンスを起動します。

      注意：ノード 1 でデータベースを登録して再起動するプロセスには、数分かかる場合があります。 このプロセスが完了すると、LifeKeeper GUI はノード 1 の HANA-SPS_HDB00 リソースの状態を「Standby – In Sync」として表示します。

SAP ホストエージェントの障害

このセクションのテストケースは、サポートする SAP Host Agent 関連のプロセスが各サーバーで失敗した場合に、SAP HANA リソース階層に期待される動作を検証します。


プライマリーノード SAP ホスト実行障害テスト
説明
プライマリーノードで saphostexec プロセスが強制終了されると、SAP HANA リソース階層は期待通りに動作します。
前提条件
このテストを実行する前に、次のことを確認してください。

  • 両方のサーバー (ノード 1 とノード 2) が稼働しており、
  • SAP HANA リソース階層は、ノード 1 では In-Service (ISP)、ノード 2 では Out-of-Service (OSU) で、
  • HANA システムのレプリケーションは同期している。
テストステップ
ノード 1 で saphostexec プロセスを停止します。


[root@node1 ~]# /usr/sap/hostctrl/exe/saphostexec -stop
想定される結果
  1. 次の quickCheck 間隔で、SAP HANA Recovery Kit は saphostexec プロセスが ノード 1 で実行されていないことを検出し、「recover」イベントを起動して再起動します。
  2. 「recover」イベントスクリプトは、ノード 1 で saphostexec プロセスを再起動します。

スタンバイノード SAP Host Exec 障害テスト
説明
saphostexec プロセスがスタンバイノードで強制終了されると、SAP HANA リソース階層は期待通りに動作します。
前提条件
このテストを実行する前に、次のことを確認してください。

  • 両方のサーバー (ノード 1 とノード 2) が稼働しており、
  • SAP HANA リソース階層は、ノード 1 では In-Service (ISP)、ノード 2 では Out-of-Service (OSU) で、
  • HANA システムのレプリケーションは同期している。
テストステップ
  1. ノード 2 で saphostexec プロセスを停止します。

    [root@node2 ~]# /usr/sap/hostctrl/exe/saphostexec -stop
想定される結果
  1. 次の quickCheck 間隔で、SAP HANA Recovery Kit は saphostexec プロセスが ノード 2 で実行されていないことを検出し、「remoteregisterdb」イベントを起動して再起動します。
  2. 「remoteregisterdb」イベントスクリプトは、ノード 2 で saphostexec プロセスを再起動します。

プライマリーノード SAP OS Collector 障害テスト
説明
saposcol プロセスがプライマリーノードで強制終了された場合、SAP HANA リソース階層は期待通りに動作します。
前提条件
このテストを実行する前に、次のことを確認してください。

  • 両方のサーバー (ノード 1 とノード 2) が稼働しており、
  • SAP HANA リソース階層は、ノード 1 では In-Service (ISP)、ノード 2 では Out-of-Service (OSU) で、
  • HANA システムのレプリケーションは同期している。
テストステップ
ノード 1 で saposcol プロセスを停止します。

[root@node1 ~]# /usr/sap/hostctrl/exe/saposcol -k
想定される結果
  1. 次の quickCheck 間隔で、SAP HANA Recovery Kit は saposcol プロセスが ノード 1 で実行されていないことを検出し、「recover」イベントを起動して再起動します。
  2. 「recover」イベント スクリプトは、ノード 1 で saposcol プロセスを再起動します。

スタンバイノード SAP OS Collector 障害テスト
説明
saposcol プロセスがスタンバイノードで強制終了されると、SAP HANA リソース階層は期待通りに動作します。
前提条件
このテストを実行する前に、次のことを確認してください。

  • 両方のサーバー (ノード 1 とノード 2) が稼働しており、
  • SAP HANA リソース階層は、ノード 1 では In-Service (ISP)、ノード 2 では Out-of-Service (OSU) で、
  • HANA システムのレプリケーションは同期している。
テストステップ
ノード 2 で saposcol プロセスを停止します。

[root@node2 ~]# /usr/sap/hostctrl/exe/saposcol -k
想定される結果
  1. 次の quickCheck 間隔中に、SAP HANA Recovery Kit は saposcol プロセスが ノード 2 で実行されていないことを検出し、「remoteregisterdb」イベントを起動して再起動します。
  2. 「remoteregisterdb」イベントスクリプトは、ノード 2 で saposcol プロセスを再起動します。

データベース障害

このセクションのテストケースでは、保護された HANA データベースインスタンス内のプロセスが失敗した場合の SAP HANA リソース階層の予想される動作を検証します。

注意：

  • これらのテストの実行中にデータベースインスタンスが正常に停止した場合 (たとえば、HDB stop コマンドを使用)、データベースを正常に停止するバックグラウンドプロセスが SAP HANA Recovery Kit のプロセスと競合する可能性があります。 データベースをローカルで再起動しようとすると、SAP HANA リソース階層のフェイルオーバーが発生する可能性があります。 このため、HDB kill-9 コマンドなどを使用して、オペレーティングシステムレベルでデータベースプロセスを強制的かつ即時に強制終了することにより、HDB インスタンスのクラッシュをシミュレートすることをお勧めします。詳細については 「SAP HANA – 既知の問題と制限」 を参照してください。

プライマリーノード データベースインスタンス障害テスト
説明
プライマリーノードで HDB インスタンスプロセスが強制終了された場合、SAP HANA リソース階層は期待通りに動作します。
前提条件
このテストを実行する前に、次のことを確認してください。

  • 両方のサーバー (ノード 1 とノード 2) が稼働しており、
  • SAP HANA リソース階層は、ノード 1 では In-Service (ISP)、ノード 2 では Out-of-Service (OSU) で、
  • HANA システムのレプリケーションは同期している。
テストステップ
HANA 管理ユーザーとして (<sid>adm)、ノード 1 の HDB インスタンスプロセスを (オペレーティングシステムレベルで) 強制終了します。

[root@node1 ~]# su – spsadm -c “HDB kill-9”
想定される結果
  1. [ノード 1 の HANA-SPS_HDB00 リソースに対してローカルリカバリが有効になっている場合] SAP HANA Recovery Kit が障害を検出し、ノード 1 でデータベースインスタンスを再起動します。
    1. 次の quickCheck の間隔で、SAP HANA Recovery Kit は ノード 1上でHDB インスタンスプロセスが実行されていないことを検出し、それらを再起動するために「recover」イベントを発生させます。
    2. 「recover」イベントスクリプトは、ノード 1 で HDB インスタンスプロセスを再起動します。

  2. [ノード 1 の HANA-SPS_HDB00 リソースのローカルリカバリが無効になっている場合] LifeKeeper は、SAP HANA リソース階層の ノード 2 へのフェイルオーバーをただちに開始します。
    1. SAP HANA リソース階層は、ノード 1 で正常に Out-of-Service になりました。 この処理中に、依存リソース (該当する場合は関連付けられた仮想 IP アドレスなど) が ノード 1 で削除されます。
    2. SAP HANAリソース階層は、ノード 2で正常に In-Service になりました。この処理中に、次の操作を行います。
      1. 依存するリソース (該当する場合は関連付けられた仮想 IP リソースなど) は、ノード 2 で In-Service になります。
      2. ノード 2 で実行中のデータベースインスタンスは、HANA システムレプリケーションのプライマリーレプリケーションロールに昇格されます。
      3. ノード 1 のデータベースインスタンスは、適切な HSR パラメーター (サイト名「SiteA」、レプリケーションモード「sync」、操作モード「logreplay」など) を使用して、HANA システムレプリケーションのセカンダリーレプリケーションサイトとして登録されます。
      4. データベースインスタンスが ノード 1 で開始されます。

        注意：ノード 1 でデータベースを登録して再起動する処理には、数分かかる場合があります。 この処理が完了すると、LifeKeeper GUI はノード 1 の HANA-SPS_HDB00 リソースの状態を「Standby – In Sync」として表示します。

スタンバイノード データベースインスタンス 障害テスト
説明
スタンバイノードで HDB インスタンスプロセスが強制終了された場合、SAP HANA リソース階層は期待通りに動作します。
前提条件
このテストを実行する前に、次のことを確認してください。

  • 両方のサーバー (ノード 1 とノード 2) が稼働しており、
  • SAP HANA リソース階層は、ノード 1 では In-Service (ISP)、ノード 2 では Out-of-Service (OSU) で、
  • HANA システムのレプリケーションは同期している。
テストステップ
HANA 管理ユーザー (<sid>adm) として、ノード 2 の HDB インスタンスプロセスを (オペレーティングシステムレベルで) 強制終了します。

[root@node2 ~]# su – spsadm -c “HDB kill-9”
想定される結果
  1. 次の quickCheck 間隔で、SAP HANA Recovery Kit は HDB インスタンスプロセスが ノード 2 で実行されなくなったことを検出し、「remoteregisterdb」イベントを起動して再起動します。
  2. 「remoteregisterdb」イベント スクリプトは、ノード 2 で HDB インスタンスプロセスを再起動します。

付録: 便利な SAP HANA 管理コマンド

SAP HANA 環境のステータスは、SAP が提供するダッシュボード (HANA Studio や HANA Cockpit など) を介して監視できますが、テスト中に次のコマンドも役立つ場合があります。 全体を通して、<sid> は保護された SAP HANA データベース インストールの小文字の SAP SID を示し、<InstNum> は保護された HDB インスタンスのインスタンス番号を示します (たとえば、インスタンス HDB00、<InstNum> は 00)。

コマンド 説明
su – <sid>adm -c “sapcontrol -nr <InstNum> -function StopService” HDB インスタンスの sapstartsrv プロセスを停止します。
su – <sid>adm -c “sapcontrol -nr <InstNum> -function StartService <SID>” HDB インスタンスの sapstartsrv プロセスを開始します。
su – <sid>adm -c “sapcontrol -nr <InstNum> -function GetProcessList” HDB インスタンスプロセスの現在のステータスを表示します。
su – <sid>adm -c “HDB stop” HDB インスタンスを正常に停止します。
su – <sid>adm -c “HDB kill-9” HDB インスタンスプロセスを強制終了します。
su – <sid>adm -c “HDB start” HDB インスタンスを開始します。
su – <sid>adm -c “hdbnsutil -sr_state” ローカルサーバーで HANA システムのレプリケーション状態を確認します。
su – <sid>adm -c “python /hana/shared/<SID>/HDB<InstNum>/exe/python_support/systemReplicationStatus.py” 現在の HANA システムのレプリケーションステータスを確認します。 このコマンドは、プライマリー HANA システムレプリケーションサイトであるサーバーで実行する必要があります。
su – <sid>adm -c “hdbsql -n <HANA virtual hostname> -i <InstNum> -u SYSTEM -p <SYSTEM user password> -d <SID> ‘\s’” 関連する仮想ホスト名を介して <SID> テナントデータベースへの接続をテストします。
/usr/sap/hostctrl/exe/saphostexec -status saphostexec のステータスを確認してください。
/usr/sap/hostctrl/exe/saphostexec -stop saphostexec を停止します。
/usr/sap/hostctrl/exe/saphostexec -restart saphostexec を再起動します。
/usr/sap/hostctrl/exe/saposcol -s saposcol のステータスを確認してください。
/usr/sap/hostctrl/exe/saposcol -k saposcol を停止します。
/usr/sap/hostctrl/exe/saposcol -l saposcol を開始します。
top -U <sid>adm
ps -ef | grep <sid>adm 		<sid>adm ユーザーが所有するプロセスの情報を表示します。

フィードバック

お役に立ちましたか?

はい いいえ
お役に立ちましたか
理由をお聞かせください
フィードバックありがとうございました

このトピックへフィードバック

送信