この記事では、DBAの間違いを確認します。その結果は非常に認識可能であり、私は対処しなければなりませんでした。
この記事の目的は、ユーザーがこれらの間違いを繰り返さないようにすることです。時には、悪い経験は良い経験よりもさらに価値があります。
- データベースファイルの増分の割合
データベースのファイルの増加は非常にリソースを消費する操作であるため、この増加をパーセンテージで設定することは良い考えのように思われるかもしれません。多くのガイドラインで、パーセントではなくMB単位で固定増分を設定することが推奨されていることに同意します。しかし、彼らは理由を説明していません。慣例に基づいて、データベースファイルの増分を1 GBを超えて設定することはお勧めしません。これは、MS SQLServerが一度に2GBではなく1GBを2回割り当てるためです。
また、32MB未満を割り当てる場合、遅かれ早かれ、データベースは単に遅くなります。したがって、データベースファイルに32〜1024MBの固定増分を設定することをお勧めします。しかし、データベースファイルの増分をパーセンテージで指定できないのはなぜですか？ファイルが1MB未満になるとすぐに、DBMSはこの値を0 MBに丸め、このファイルの増加を停止します。その結果、システムがダウンしています。ファイルを増やす必要がある量を見つけるには、毎日分析を実行して、各ファイルがMB単位でどれだけ増加するかを確認し、32〜1024MBの範囲で適切な数を設定します。データベースファイルの増加に関する統計は、次の方法で収集できます。 - テーブルには多くの外部キーがあります
ほぼ数百の他のテーブルによって参照されているテーブルから少なくとも1つの行を削除するときに、計画を確認しようとしたことがありますか？ネストされたループがいくつあるかを知って驚かれることでしょう。それらはすべて外部キーチェックです。そのため、テーブルが大きい場合（100万レコードを超える場合）、データが削除されるテーブルの外部キーを無効にすることをお勧めします。次に、必要な関連データをすべて削除する必要があります。その後、外部キーを有効にします。同様の状況は、カスケード更新と削除で発生します。外部リンクが多数（数百）ある場合は、1行でも削除すると、長くて非常に広範囲にわたるブロックが発生する可能性があります。 - 多くの不要なインデックス
多くの場合、ガイドラインでは、外部キーを作成するときに、特にこれらのキーを結合に使用するときに、インデックスを作成する必要があることがわかります。インデックスが使用されていることを確認する必要があります。そうでない場合、これらの不要なインデックスはデータ変更操作の速度を低下させるだけです。これを確認するには、次のクエリを使用します：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 -- system databases are excluded
- リソースの非効率的な使用
多くの場合、トランザクションログとデータベースファイルを異なるストレージデバイスに保存することをお勧めします。 4つ以上のSSDディスクでRAID10を使用する場合、ファイルを相互に分離しても意味がありません。より高速にするために、必要に応じて、tempdbデータベースをRAMから分割されたディスクに保存できます。また、DBMSに提供されるRAMの量が多すぎると、DBMSはすべてのメモリを無関係なクエリプランでいっぱいにします。 - 不正なバックアップ
作成したバックアップを確認するだけでなく、テストスタンドに移動して復元する必要があります。これはすべて自動化する必要があり、問題のあるリカバリと成功したリカバリの両方を管理者に通知します。 - 不良耐性
2つ以上のサーバーのクラスターを作成する前に、データストレージシステムもフェイルトレラントであることを確認する必要があります。後者が失敗した場合、全体の失敗許容度はゼロに減少します。 - 複雑 簡単なチェックなしで診断
システムのダウンタイムがある場合は、最初にMS SQL Serverのログを確認してから、さらに深く掘り下げる必要があります。最初に簡単なチェックを行ってから、複雑な診断に進む必要があります。 - 失われたテーブル
テーブルは、別のデータベースにアーカイブするか削除する必要がある不要なデータで拡張できます。また、テーブルは使用できなくなります。
これらは私が遭遇した状況です。したがって、上記の間違いを繰り返さないことをお勧めします。
データベースを管理する際の経験やそのような間違いを共有したい場合は、遠慮なくお知らせください。喜んで話し合います。