開発のあいまに

SQLServerで、特定のスキーマの、インデックス一覧を抽出するSQL

「UserDb1」データベースにある、「UserShema2」スキーマに紐付くインデックスのみ抽出する、サンプルSQL。

Declare @dbid int 
Select @dbid = db_id('UserDb1') 

select a.schema_id, b.name, [Table Name], indes_name from ( 
 SELECT  o.schema_id as schema_id, OBJECT_NAME(i.[object_id]) AS [Table Name] ,i.name as indes_name, o.create_date, o.modify_date
 FROM sys.indexes AS i
 INNER JOIN sys.objects AS o ON i.[object_id] = o.[object_id]
 AND o.[type] = 'U'
) as a 
 inner join sys.schemas b
    on a.schema_id = b.schema_id 
  and b.name      = 'UserShema2'

 

【関連記事】
チューニングアドバイザーによる、インデックスと統計情報の抽出と追加
テーブルの統計情報を、週次で更新
ストアドとファンクションを、日次のジョブで毎朝リコンパイル
IISと関連サービスを、日次で毎朝再起動。
IISと関連サービスからのDB処理が、極端に遅くなるストアド、ファンクションは、使用するインデックスをヒント文で固定する
SQLServerで、IISからのDB処理だけが遅い場合は、ストアドをリコンパイルする
SQLServer 2005 インデックス チューニング ライフサイクル
6ヶ月以上使われていないインデックスを抽出するSQL

SQLServer2008で、差分バックアップを使って、DBを復元する際の手順メモ

Restore Full backup
1.Open the Restore Database window in Microsoft SQL Server Management Studio
2.Ensure the To database field is filled in with the name you want.
3.Choose From device as the Source for restore.
4.Choose the full backup file you want to restore. In most cases this is the most recent full backup file.
5.Click the Options page on the left navigation.
6.Choose Leave the database non-operational, and do not roll back uncommitted transactions. Additional transaction logs can be restored.(RESTORE WITH NORECOVERY). This is the most important step!!!

Restore Differential backup
1.Open the Restore Database window in Microsoft SQL Server Management Studio
2.Ensure the To database field is filled in with the name you want. The same that you specified in step 2 for the Restore Full backup
3.Choose From device as the Source for restore.
4.Choose the differential backup file you want to restore. In most cases this is the most recent differential backup file.
5.Click the Options page on the left navigation.
6.Choose the default: Leave the database ready to use by rolling back uncommitted transactions. Additional transaction logs cannot be restored.(RESTORE WITH RECOVERY) Make sure to choose this if you want to use your database after the restore.

http://justgeeks.blogspot.jp/2009/03/log-or-differential-backup-cannot-be.html

 

 

SQLServer 2005 インデックス チューニング ライフサイクル

１、コーディングされているSelect文を全て、Management Studio のクエリエディタに貼り付ける。

２、ツールバーの「データベース エンジン チューニング アドバイザでのクエリの分析」アイコンをクリックして、「データベース エンジン チューニング アドバイザ」画面を開く。

 

３、「データベース エンジン チューニング アドバイザ」画面では、クエリエディタに記入したSQLのチューニング設定が初期値として入力済みになっている。

４、必要であれば「チューニング オプション」の内容を変更。

５、ツールバーにある「分析の開始」アイコンをクリックして開始。

６、分析対象のデータベースサイズが小さ過ぎたり、大き過ぎたりすると、「ワークロードを使用しています」タスクでエラーになる。その場合は、「チューニング オプション　⇒　詳細設定オプション　⇒　推奨インデックス用の最大領域を定義する」にチェックを付け、実際のＤＢサイズを入力し、再度「分析の開始」アイコンをクリック。

７、分析結果として登録した方が良いインデックスが、「推奨インデックス」にリストアップされるので、全てのインデックスと統計情報を、クエリエディタ画面で実行する。

８、インデックスと統計情報を追加したら、その対象となったテーブルに、sp_recompile を実行する。

InsertやUpdateが遅くならないようにインデックスを張らない方が良いものはないか気になりますが、実験した結果では、推奨される全てのインデックスを張った場合、InsertやUpdateは少し遅くなりますが、Select文は圧倒的に速くなり、トランザクション全体の処理時間が改善するので、何も考えずに全て適用してしまうのが一番です。

ただ、テラバイトクラスのDBの場合は、1つのインデックスを追加しただけで、100GB消費することは有りますので、ディスク容量は考慮した方が良いです。

また、不要なインデックスが増えないように、6ヶ月以上使われていないインデックスを抽出するSQLを定期的に実施た方が良いです。

それと、インデックスと統計情報を追加しても、ストアドが古い実行プランをキャッシュしたままになっている事がありますので、SQLServerで、IISからのDB処理だけが遅い場合は、ストアドをリコンパイルする こともにも、注意が必要です。

 

【関連記事】
チューニングアドバイザーによる、インデックスと統計情報の抽出と追加
テーブルの統計情報を、週次で更新
ストアドとファンクションを、日次のジョブで毎朝リコンパイル
IISと関連サービスを、日次で毎朝再起動。
IISと関連サービスからのDB処理が、極端に遅くなるストアド、ファンクションは、使用するインデックスをヒント文で固定する
SQLServerで、IISからのDB処理だけが遅い場合は、ストアドをリコンパイルする
SQLServer 2005 インデックス チューニング ライフサイクル
6ヶ月以上使われていないインデックスを抽出するSQL