NetWorker：NMM 19.x SQL AlwaysOnバックアップが応答しなくなり、サーバーのCPUが増加します

NetWorkerサーバーを18.xから19.xにアップグレードしたときに、いくつかの問題が発生しました。
NMM(NetWorker Module for Microsoft)を使用したSQL Server AlwaysOn可用性グループ データベースのバックアップでは、次の現象が発生します。

• AlwaysOnバックアップが応答しません。実際、「nsrsqlsv」はsavefsによって起動されますが、データの保存は開始されません。
• クラスター クライアントを介したAlwaysOn(AOAG)SQL Serverバックアップに影響する
• 同じAlwaysOnクラスター内のスタンドアロンSQL Serverインスタンスのデータベース バックアップでは、SQLデータベースのバックアップに問題はありません。
• NetWorkerサーバーでCPUの深刻なスパイクが発生しています。これにより、実行中の他のバックアップ ジョブのパフォーマンスが大幅に低下する可能性があります。

セットアップの複数の要因がこの動作を引き起こす可能性があり、原因は複数の単一要因に起因する可能性があります。
要因には以下が含まれます。

1. アップグレード：NetWorkerサーバーが最近アップグレードされました。アップグレード前は、ジョブは正常でした。一例では、サーバーが18.xから19.2にアップグレードされ、SQL NetWorkerクライアントとNMMもアップグレードされました。
2. メディア データベース レコード: サーバー分析では、セーブセットのないクライアントが多数見つかったり、一部のセーブセットのメディア データベース レコードに一貫性がなくなったりすることがあります。これらのセーブセットは、影響を受けるSQLクライアントと関連している場合と関連していない場合があります。
3. 次のようなさまざまな方法によるメディア データベースのクリーンアップ nsrim -X -V volumeは、問題を解決しません。
4. クライアントインデックス: クラスター クライアントの実際のクライアント ファイル インデックスが破損している可能性があります。この最後の手順では、クライアント ファイル インデックスの名前を変更する必要がある場合があります。

AlwaysOn用のSQLクラスター クライアントは、MSSQL#AAG:
Example MSSQL#ALWAYS_ON_GROUP_NAME

SQLクラスター クライアントに対して実行中のバックアップ ジョブがない場合は、次の手順を実行します。

• クラスター クライアントのクライアント ファイル インデックスの名前を変更します。
• たとえば、「/nsr/index/CLUSTER_CLIENT_NAME」の名前を「/nsr/index/CLUSTER_CLIENT_NAME.suspect」に変更します。
• SQL AlwaysOnクラスター クライアントの新しいバックアップを実行します。
• 新しいインデックスが生成され、バックアップが正常に実行されます。