web-dev-qa-db-ja.com

CHECKDBエラー後にダンプします

2ノードミラーと顧客の要件に少し問題があります。

毎晩01:30から03:00までメンテナンスウィンドウがあり、その中でrebuild/reorgとcheckdb（physical_only）を実行する必要があります。マーフィーが発生した場合、両方のジョブが同じインデックス/テーブルで実行され、SQL Serverは（ミニ）ダンプを作成します。ダンプが原因で、プリンシパルが設定されたタイムアウト期間内に応答せず、ミラーの役割が変更され、アプリの問題が発生します。

夜間に90分のウィンドウがあり、顧客/ PFEはこのウィンドウで両方のジョブを実行することを望んでいます。 DBCCは約80分間実行され、再構築/再編成は約30分間実行されます。

それらのマーフィーモーメントを回避するため、またはそのダンプを回避するための提案はありますか？

  • 古いAxaptaインストールDBサイズで使用されるSQLServer 2012 SP3 CU7
  • 900GB-1TB（SSD上のデータファイル）

Ola Hallengrenによるインデックスのメンテナンス：

EXECUTE dbo.IndexOptimize @Databases = 'PROD',
@FragmentationLow = NULL,
@FragmentationMedium = NULL,
@FragmentationHigh = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 50,
@FragmentationLevel2 = 80,
@SortInTempdb = 'Y',
@MaxDOP = 0,
@LogToTable = 'Y',
@TimeLimit = 3600

DBCC CHECKDBオラハレングレンからもPhysical_onlyオプション。

これらの再構築/再編成を毎晩実行する「実際の」必要があるかどうかはわかりませんが、顧客からそうするように言われました（MSFT PFEによっても提案されています）。

メンテナンスウィンドウの拡大についてお客様と連絡を取り合っていますが、他に提案やヒントがあるかどうか知りたいです。

実際のDBCC CHECKDBエラーメッセージは次のとおりです。

DBCC CHECKDB（XXXX）WITH all_errormsgs、no_infomsgs、physical_onlyがユーザー名によって実行され、2つのエラーが見つかり、0のエラーが修復されました。
テーブルエラー：オブジェクトID 111391516、インデックスID 2、パーティションID 720 57595795734528、割り当てユニットID 72057595826864128（タイプ行内データ）、ページ（7：14130686）。
テスト（IS_OFF（BUF_IOERR、p BUF-> bstat））が失敗しました。
値は133129と-4です

sql-serversql-server-2014jobsdbcc-checkdbindex-maintenance
2
Björn Peters

これらのインデックスがFlash/SSDに保存されている場合のインデックスの最適化は、ほとんど意味がありません。インデックスの再作成の頻度を大幅に減らすことをお勧めします。インデックスの断片化の影響を軽減するためのページ密度とフィルファクターについては、Paulの ここで回答 を参照してください。

一方、統計を更新すると、クエリオプティマイザに重要な手がかりが得られます。特定のデータベースでauto-update-statsが無効になっている場合は、夜間のジョブを介して統計を更新していることを確認してください。

破損がRPOに悪影響を与えないように、できるだけ頻繁にDBCC CHECKDBを実行するようにしてください。 DBCCCHECKDBを非実稼働インスタンスにオフロードすることを検討してください。これは、非実稼働インスタンスへの自動バックアップと復元、およびその非実稼働インスタンスでDBCCCHECKDBを自動的に実行することで構成されます。 DBCC CHECKDBを実行するマシンは実稼働データを処理するため、ライセンスを取得する必要がありますが、Microsoftの担当者に確認してください。

SQL Serverがメモリダンプを作成している場合は、SQL Serverの問題を示しており、Microsoftテクニカルサポートに通知する必要があります。問題を解決するための修正プログラムが利用可能であるか、に関するアドバイスが提供されている可能性があります。その問題を解決する方法。問題は確かに修正が必要なバグである可能性があります。

2
Max Vernon

コミュニティウィキの回答 ：

SQL Serverがクラッシュしている場合、それは欠陥であり、Microsoftでサポートインシデントを開いて修正できるようにする必要があります。運が良ければ、すでに修正されています。

Axaptaを使用すると、多数のインデックスを無効化または削除できる場合があります。製品には多数のインデックスが付属していますが、アプリケーションの特定のコンポーネントが使用されていない場合、一部のインデックスは使用されない場合があります。インデックスが少ない=インデックスの再作成が速くなります。

もう1つのオプションは、ジョブにロジックを追加して、もう1つのジョブが終了するまで待機してから開始することです。

または、インデックスのメンテナンスをスキップして、統計を更新するだけです。 Checkdbははるかに重要です。

フラッシュストレージでのインデックスの再作成は、技術的な観点からは無意味ですが、それを理解していない人がパフォーマンスの問題について不満を言っている場合の障壁を取り除きます。たとえば、開発者やレベル1のテクニカルサポート担当者は、パフォーマンスの問題について断片化されたインデックスのせいにすることがよくあります。インデックスが断片化されていないことを示すことができれば、トラブルシューティングプロセスをすばやく進めることができます。それ以外の場合は、パフォーマンスの問題を引き起こす断片化されたインデックスに関する10,000件のブログ投稿が適用されない理由を説明する必要があります。

CheckDBは通常、トランザクション的に整合性のあるデータベースのデータベーススナップショットコピーで実行されます。つまり、2つのワークロード（checkdbとrebuilds）は、物理リソースをめぐって競合する場合を除いて、相互に影響を与えるべきではありません。

CheckDBがエラーを返している場合、それは問題です。一般に、CheckDBヒット本当に悪いエラーの場合、メモリダンプが発生します。

エラーはIOエラー（BUF_IOERROR == true）だから私はあなたのディスクサブシステムをチェックし、メンテナンスを見ないでしょう。ディスクサブシステムがハードヒット時にIOエラーをスローする場合-それはかなり大きな問題が必要です修正する必要があります。そうしないと、checkdb/indexのメンテナンスを行わずにこれに遭遇します。

0
user126897

私は顧客の決定であなたに戻ってきたいです...そしてこれに対する全体の「解決策」。

お客様は、自分の「ETL」ジョブを改善して、メンテナンスウィンドウを拡張できるようにしました...現在、両方のジョブを1つで実行しています（2番目のステップ）。最初の（より重要な）ステップはDBCC CHECKDBであり、2番目はインデックスの保守です。

完全な実行時間は1:50から1:57の間で、メンテナンスウィンドウに完全に収まります。

ご協力ありがとうございました！

0
Björn Peters