web-dev-qa-db-ja.com

DBCC CHECKDB中にBUFを割り当てることができませんでした

UPDATE 9/12/19-ステータスの更新については、以下の私のコメントを参照してください。

私が理解できないような問題で誰かが私を助けてくれるかどうかを確認するために書いています。これはおかしなことになるので、私はできる限り多くの重要な情報をリストアップするつもりですが、何か見逃した場合はお知らせください。必要な情報を提供させていただきます。あなたが喜んでいるかどうかを支援するには？

私が経験している症状は、メンテナンスプランのタスクの1つとしてVLDB（約1TB）に対して実行するとdbcc checkdbがロックアップし、エラーログに次のエラーが報告されることです：BUFsの割り当てに失敗しました：FAIL_BUFFER_ALLOCATION 7（時々 8）次に、物理メモリと仮想メモリに関するエラーグラフがメモリチャート（私が説明できる最良の方法。添付のスクリーンショットを参照）で一杯になります。

これがシナリオです。現在、OLDSERVERから移行する前に、NEWSERVERのテストを開始しています。すべてがOLDSERVERで期待どおりに機能しています。問題は、毎晩のメンテナンスプランルーチン中にPRODインスタンスのNEWSERVERで発生しています。インスタンスに複数のdbが存在しますが、関係するのはDB1です。 DB1は、2つのデータファイルと1つのログファイルで構成されています。 OLDSERVERでは、.mdf（519 GB）はH：にあり、.ndf（200 GB）はE：にあり、.ldf（313 GB）はD：にあります。 NEWSERVERでは、両方のデータファイルがE：にあり、ログファイルはD：にあります。注：2つのデータファイルまたはその場所を含むデータベースの構成、またはいずれかのサーバーのセットアップ/構成には関与していません。

OLDSERVERでは、メンテナンスプラン（データベースの整合性チェックタスク、フルデータベースバックアップ、およびメンテナンスクリーンアップタスクで構成され、DB1に対してのみ実行されるように構成されています）は問題なく夜間に完了します。 NEWSERVERでは、メンテナンスプラン（まったく同じ方法でセットアップされます）が完了することもありますが、ほとんどがカタツムリのクロールに遅くなり（またはカタツムリよりも遅いものを見つけます）、最終的に[データベースの整合性の確認]タスクで失敗します。

DBCC CHECKDBを手動で実行できますが、非常にタイムリーに完了する場合もありますが、手動で実行した場合でも同じ動作が見られる場合があります。これらの設定のいずれかが直接適用可能かどうかはわかりませんが、メモリ内のページのロックをオンとオフの両方でオンにして試してみました。違いはありません。また、インスタントファイルの初期化をオンとオフの両方で試してみました。

ここでは、NEWSERVERと呼ぶ物理サーバーの詳細を示します。

  • OS：Windows Server 2016 Standard-6.3（14393）
  • プロセッサ数：32
  • メモリ：384 GB（382 GB使用可能）
  • ドライブ（で構成されたすべてのSSD）：OS（C :) -181 GBから243 GBを解放|ログ（D :)-117 GBは488 GBから無料|データ（E :)-2.86 TB無料3.81 TB |バックアップ（F :)-1.44 TB無料1.9 TB
  • SQL Server 2016 Standard-SP2 CU3（13.0.5216.0）
  • インスタンス数：4（PROD、DEV、TEST、TRAIN）
  • インスタンスあたりの最大メモリ構成：PROD（131072 MB）| DEV（65536 MB）|テスト（65536 MB）|電車（32768 MB）

ここでは、OLDSERVERと呼ぶ物理サーバーの詳細を示します。

  • OS：Windows Server 2016 Standard-6.3（14393）
  • プロセッサー数：24
  • メモリ：384 GB
  • ドライブ（スピンドル＆SSDミックス）：OS（C：SSD）-163 GBで249 GBの空き|ログ（D：15,000スピンドル）-197 GB（557 GBから無料）| ProdData（E：SSD）-865 GBから604 GB無料|バックアップ（F：10kスピンドル）-1.46 TB 2.18の空き容量TB | NonProdData（G：SSD）-1.08の空き容量591 GB TB | ProdData2（H：SSD）-743 GBから231 GB無料
  • SQL Server 2016 Standard-SP2 CU2（13.0.5153.0）
  • インスタンスの数：5（PROD、DEV、TEST、TRAIN、PROD2）
  • インスタンスあたりの最大メモリ構成：PROD（131072 MB）| DEV（65536 MB）|テスト（65536 MB）|電車（32768 MB）| PROD2（32768 MB）

添付されているのは、エラーログの最初の（ほぼ50）行です（必要に応じて追加で提供できます。 enter image description here

ヘルプやアイデアは大歓迎です！

sql-serversql-server-2016dbcc-checkdb
4
TattooedDBA

さて、この問題についてMicrosoftと数か月作業した結果、DBCC CHECKDBとVLDBの「既知の問題」であり、SQL 2016 SP3で修正が行われることが判明しました。問題がSQL 2017に存在するかどうかを尋ねたところ、問題は存在しており、サービスパックでもリリースされる可能性が高いとのことでした。サービスパックをもうやっていないと思っていたので、それは興味深いものでしたが、サービスパックで実行しなければならない可能性のある十分に大きな問題であると彼女は言いました。

1
TattooedDBA

[〜＃〜] oldserver [〜＃〜]データからはわかりませんが、[〜＃〜] newserver [〜＃〜]には少なくとも2つのNUMAノードがありますが、[〜＃〜] oldserver [ 〜＃〜]には複数のNUMAノードまたは単一のノードがあります。

今のところ、[〜＃〜] olderserver [〜＃〜]にNUMAノードが1つしかなかったとすると、 SQL Server 2016 SP2 CU5で修正された既知の問題が発生しましたが、現在SQL server 2016 SP2 CU3を使用しています。

https://support.Microsoft.com/en-us/help/4470916/fix-out-of-memory-error-occurs-when-database-node-memory-kb-drops-belo

「メモリ不足」エラーは、データベースNodeメモリ（KB）がターゲットサイズの2％未満になると発生し、ノード上のデータベースページを破棄して空きページを取得できなくなります。 。

MEMORYSTATUSの出力を見ると、少なくともNUMA Node 0。

少なくとも、SP2 CU5を適用して、再度ロードを実行します。

3
Sean Gallardy