SQL Serverのメンテナンスの提案？

Question

オンライン写真のコミュニティを運営していますが、サイトがデータベースアクセスをクロールしているようで、タイムアウトが発生することがあります。

私は、SQLクエリの作成とテーブルの設計にかなり満足していると思いますが、決してDBAではありません...したがって問題です。

背景：

1. サイトとSQLサーバーがリモートホストで実行されています。 Visual StudioからASP.NETコードを更新し、SQL Server Mgmtを介してSQLを更新します。 Studio Express。サーバーに物理的にアクセスできません。

2. すべてのストアドプロシージャ（すべて取得したと思う）はトランザクションにラップされています。

3. 現在、メインテーブルは9400レコードのみです。このテーブルに毎晩12個の新しいレコードを追加します。

4. このメインテーブルには、他の複数のテーブルのデータを1つのビューにまとめるビューがあります。

5. セカンダリテーブルは小さなレコードですが、より多くのレコードがあります。 1つに70,000、もう1つに115,000。これらは、＃3のアイテムに対するコメントと評価レコードです。

6. インデックスは、最も必要なフィールドにあります。そして、大きなテーブルで統計を自動再計算するように設定しました。

サイトが停止したとき、トランザクションログをクリアし、統計を更新し、メインビューを再構築し、ストアドプロシージャを再構築してコメントを取得するコードを実行すると、速度が戻ります。ただし、これは手動で行う必要があります。

残念なことに、ユーザーはこれらの問題に不満を抱き、参加者が減っていきます。

だから私の質問は...リモート環境で、SQLデータベースを最高の状態に維持するためのメンテナンスプランを設定およびスケジュールする最良の方法は何ですか？

どうもありがとう！ KLK

Answer 1

メンテナンスタスクをメンテナンスプランとして設定する必要はありません。

実行したいメンテナンスタスク、インデックスの再構築、統計の更新などを実行するストアドプロシージャを簡単に作成します。

次に、ストアドプロシージャを呼び出すジョブを作成します。ジョブは、希望するスケジュールで実行するように構成できます。

ジョブを作成するには、sp_add_jobプロシージャを使用します。

スケジュールを作成するには、sp_add_scheduleプロシージャを使用します。

詳しく説明した内容が明確で理解しやすいものであることを願っていますが、さらにサポートが必要な場合はお気軽にご連絡ください。

乾杯、ジョン

Answer 2

私の腸は、あなたが何か間違ったことをしていると言います。毎晩サーバーを再起動しない限り、一部のシステムが稼働し続けることができないという話のように聞こえます：-）

クエリに問題があります。行の数はほとんどの場合パフォーマンスに関係なく、データベースは非常に小さくなります。私はSQLサーバーにあまり詳しくありませんが、かなり便利なクエリ分析ツールがあると思います。また、遅いクエリを記録する方法があると思います。

インデックスが欠落しているようです。正しいインデックスを追加したと思うかもしれませんが、使用されていることを確認するまで、それは重要ではありません。あなたは正しいものを持っていると思うかもしれませんが、クエリはそうでないことを示唆しています。

最初に、クエリを記録する方法を見つけます。オッズは、インデックスが修正するシーケンシャルスキャンを実行しているキラーがいると非常に良いです。

第二に、代わりにそれを殺している小さなクエリがたくさんあるかもしれません。たとえば、「ユーザー」がいる場合があります; user_idからユーザー名を検索するたびにデータベースにヒットするオブジェクト。データベースに100回クエリを実行しているスポットを探して、キャッシュに置き換えます。リクエストの最後に消去されるプライベート変数に過ぎません。

一番下の行は、SQL Serverで誤って設定されたものではないかと疑っています。つまり、システムが停止するために毎晩サーバーを再起動する必要がある場合、システムまたはコードを非難しますか？ここでも同じように... SQL Serverが提供するツールを学びましょう。かなり洗練されていると思います：-）

それはすべて、あなたが何か間違ったことをしていることを受け入れたら、そのプロセスを楽しんでください。私にとっては、遅いデータベースクエリを最適化することは楽しいことではありません。 10秒のランタイムでクエリを取得し、適切に配置された単一のインデックスを使用して、50ミリ秒のランタイムでクエリに変換できることは驚くべきことです。