一般的なDBA MS SQL Serverエラーに関する13番目の記事

まえがき

この短い記事では、エラーの概要を説明しますが、その結果は非常に具体的であり、対処しなければなりませんでした。



この記事は、これらのエラーを繰り返さないことを目的に書かれています。 そして、彼らが言うように、ネガティブな経験も経験であり、時にはポジティブよりもさらに価値があります。

間違い

1. データベースファイル（データベース）の増分
   
   
   
   ファイルの増加（データまたはトランザクションログ）は非常にリソースを集中的に使用する操作であるため、この増加をパーセンテージで設定することを意図している場合があります。 パーセンテージではなく、MB単位で表される一定の増加を設定する方が良いと多くの推奨事項が述べています。 しかし、なぜそうなのかは明らかにされていません。 MS SQL Serverは、一度に2 GBよりも2倍速く1 GBを割り当てるため、実践に基づいて、データベースファイルの成長を1 GBより大きく設定することは推奨されません。 また、32 MB未満（再度練習に基づいて）を割り当てると、遅かれ早かれデータベース自体が単にハングし始めます。 さて、データベースファイルの増分は32 MBから1024 MBに固定することにしました。 しかし、なぜデータベースファイルの増加を割合で指定することが依然として不可能なのでしょうか？ ファイルが1 MB未満になるとすぐに、DBMSはこの値を0 MBに丸め、このファイルの増加を停止します。 結果はシンプルなシステムです。 ファイルをどれだけ拡大するかを調べるには、1日あたりの分析を行うだけで十分です。各ファイルがMB単位で増加し、対応する数を32〜1024 MBの範囲で設定します。 データベースファイルの成長に関する統計情報の収集は、次のようにして取得できます 。
2. テーブルごとに多くの外部キー
   
   
   
   ほぼ数百の他のテーブルによって参照されているテーブルから少なくとも1つの行を削除するときに、プランを見ようとしたことがありますか？ ネストされたループがいくつあるか驚くでしょう。 そして、それらはすべて外部キーのチェックです。 したがって、テーブルが大きい場合（億万長者）、データを削除するテーブルの外部キーをオフにし、必要な関連データをすべて削除してから、外部キーをオンにすることをお勧めします。 状況はカスケード更新と削除の場合と同様です。 多数の外部リンク（数百）がある場合、1行削除しても長くて非常に広範なロックが発生する可能性があります。
3. たくさんの追加インデックス
   
   
   
   推奨事項では、外部キーを作成するとき、特に接続にこれらのキーを使用するときは特に、それらのインデックスを作成する必要があることがよく見られます。 インデックスが使用されていることを確認する必要があります。そうでない場合、これらの余分なインデックスはデータ変更操作を遅くするだけです。 次のクエリを使用して、インデックスの使用を確認できます。
   
   
   
   
   コード

   select DB_NAME(t.database_id) as [DBName] , SCHEMA_NAME(obj.schema_id) as [SchemaName] , OBJECT_NAME(t.object_id) as [ObjectName] , obj.Type as [ObjectType] , obj.Type_Desc as [ObjectTypeDesc] , ind.name as [IndexName] , ind.Type as IndexType , ind.Type_Desc as IndexTypeDesc , ind.Is_Unique as IndexIsUnique , ind.is_primary_key as IndexIsPK , ind.is_unique_constraint as IndexIsUniqueConstraint , t.[Database_ID] , t.[Object_ID] , t.[Index_ID] , t.Last_User_Seek , t.Last_User_Scan , t.Last_User_Lookup , t.Last_System_Seek , t.Last_System_Scan , t.Last_System_Lookup from sys.dm_db_index_usage_stats as t inner join sys.objects as obj on t.[object_id]=obj.[object_id] inner join sys.indexes as ind on t.[object_id]=ind.[object_id] and t.index_id=ind.index_id where (last_user_seek is null or last_user_seek <dateadd(year,-1,getdate())) and (last_user_scan is null or last_user_scan <dateadd(year,-1,getdate())) and (last_user_lookup is null or last_user_lookup <dateadd(year,-1,getdate())) and (last_system_seek is null or last_system_seek <dateadd(year,-1,getdate())) and (last_system_scan is null or last_system_scan <dateadd(year,-1,getdate())) and (last_system_lookup is null or last_system_lookup <dateadd(year,-1,getdate())) and t.database_id>4 and t.[object_id]>0 --  
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
   
   
   
4. 資源の無駄遣い
   
   
   
   トランザクションログとデータベースデータファイルを異なるデータキャリアに転送する必要があることが推奨事項でよく見られます。 4つ以上のSSDディスクでRAID 10を使用する場合、ファイルを相互に分離しても意味がありません。 さらに高速にするために、必要に応じて、tempdbデータベースをRAMから形成されたディスクに配置できます。 また、DBMSが提供するRAMが多すぎると、DBMSは無関係なクエリプランでメモリ全体をいっぱいにします。
5. 悪いバックアップ
   
   
   
   陳腐に聞こえるかもしれませんが、作成したバックアップを確認するだけでなく、それらをテストベンチに移動して復元する必要もあります。 そして、これらすべてを自動化し、問題のある復元と成功した復元の両方を管理者に通知する必要があります。
6. 偽りの弾力性
   
   
   
   2つ以上のサーバーのクラスターを作成する前に、データストレージシステムもフォールトトレラントであることを確認する必要があります。後者が失敗した場合、すべてのフォールトトレランスがゼロに低下するためです。
7. 簡単なチェックなしの高度な診断
   
   
   
   単純なシステムが発生した場合、多くの場合すべての問題がそこに書き込まれるため、最初にMS SQL Serverログを確認し、それから詳細に掘り下げる必要があります。 単純なチェックを実行しないことは、患者の体温を測定しないことと同じですが、すぐに複雑な診断を実施します。
8. 忘れられたテーブル
   
   
   
   テーブルは、不要な古いデータで膨張する可能性があり、別のデータベースにアーカイブするか、削除する必要があります。 また、テーブルの使用が停止する場合があります。 これを覚えておく必要があります。

これらはすべて、私が遭遇した8つの否定的な経験です。

上記のエラーを繰り返さないでください。

ソース：

» SQLドキュメント

» すべてのデータベースのテーブルとファイルの成長に関するデータを収集する自動化