SQL Server管理リスト

実際の大規模なデータベースを運用してみると

周期的な維持管理をする必要性を感じるようになる。

一般的なユーザーが感じる最大の部分は、バックアップであり、DBAの場合

統計の更新、データベースの圧縮などである。

これについて詳しく調べてみよう

1。バックアップ

 バックアップの種類は、完全復旧に基づいている場合

 Full + Log OR

 Full + Deferential + Logがある。

 筆者の場合、継続して蓄積するデータの量とバックアップの負荷を減らすために

 1日に一度Deferential、3時間に一回ずつLog、点検時にFull Backupをする方法を取っている。

 実際にこのサイクルは、非常に個人的な部分とサービスされているデータのトランザクション量や

 点検期間などを考慮して設計する必要がある。

 そして多くの人々が排除している部分があります。つまりsystem databaseのバックアップです。

 masterなどジャトジヌンませんが、重要なシステムコンポーネントが変動したデータベースをバックアップしていない場合は、

 ひょっとしてmasterデータベースが飛んで行った時に巨大な（？）作業をするようになることがあります。

 頻繁のバックアップはお勧めしませんが、多くの変更などがあった場合、定期的にバックアップする方法です。

2。データベースを圧縮する

 頻繁トランザクションが発生した大規模なデータベースで、初期データベースのスペースを確保し、

 インクリメント、maxガプドゥンウル設定する上で非常に注意を払う必要があります。

 万が一、初期容量を100MBに取っておいて10％増とした例を挙げてみよう

 しかし、時間100MB以上のデータがたまったと仮定すると、データベース領域を増やす作業に

 により、サーバーにかなりの負荷がかかるだろう。

 データベースの圧縮をする上でも重要な部分である。

 縮小後にどれだけのスペースを維持しているか、またどれだけの容量をオペレーティングシステムに戻すか

 この部分をよく考慮ハヨソ維持管理をするのが重要である。

 *データベースの圧縮を定期的にしなければ、実際のデータは、1000 rowがスペースは100000 row

 以上のスペースを占めていることもある。

3。統計の更新＆Re-Build index

 専門的なDBAがなく、開発者がデータベースの管理をしている場合に最も多くのミスをしている部分である。

 もし一つの掲示板を設計したしましょう​​。

 最初はテストのために、約100社のデータを入れてみ単に "ジャルドゥェネ〜"して越えていった。

 しかし、それこそ単純に100以上のデータがある場合はうまくいったのだった。

 統計情報の更新をしなければDBMSはずっと掲示板では、100個のデータのみを持っていると判断して

 これに伴う実行計画（scan）で行う。

 もし統計情報の更新がされていない状況で、100万個以上のデータがたまっていたらどうなるか？

 掲示板のアクセス、リフラッシュあたり100万個を、フルテーブルスキャンの結果をもたらすことができる。

 インデックスリビルドゥヌン多くの更新や削除の操作が行われ荷物として断片化が行われ、

 これを解決するために、インデックスを新規作成すると理解してください。

 同様に、最初はすごく高速なパフォーマンスを見せてくれたクエリが時間がたつほどの更新と削除された

 断片化インデックスをタムエドかかわらず、すべてのデータのスキャンと違いない性能を示すことができる。

4。 SP Re-Compile

 ストアード·プロシージャーを主に使用する環境であれば考慮しなければならない。

 どのようなこれらは統計を勉強して、 "ああ統計情報の更新したので、うまくいくよ"

 沸騰クエリにすると、優れたパフォーマンスを見せるが、実際に使用されているSPは、そうでない場合があります。

 SPは、すでにコンパイルされているため、実行計画もコンパイルされた時点で、

 同じ実行計画が維持される。しかし、データが溜まって統計が更新された時点で、

 SPをコンパイルしてくれなければ、以前の実行計画を何度も再利用する。

 再コンパイルの構文は、sp_recompile "テーブル名"である。

 sys.tablesを参照してすべてのテーブルに対応するSPを再コンパイルするSPを作成して使用することを

 推薦する。