SQL Server には内部の待ち事象を確認するための 3 種類のテーブルが存在しています。
今回の投稿ではこのテーブルについて少しまとめておきたいと思います。
Archive for the ‘SQL Server’ tag
SQL Server の内部の待ち事象を確認する 3 種類のテーブル
SQL Server 2014 releases April 1 !!
いつ出るのだろうと思っていた SQL Server 2014 のリリースですが GA が4/1 となったようです。
SQL Server 2014 releases April 1
SQL Server 2014 の Books Online も徐々にプレビューが外れ RTM 対応されているようです。
SQL Server 2014 オンライン ブック
SQL Server 2014 の各エディションがサポートする機能 などは CTP の時から変更されています。
Standard Edition で利用可能なメモリサイズが 128GB に拡張、バッファ プール拡張が使用可能というような CTP ではStandard Edition で使えなかった機能などが使えるというような情報に変わっています。
最近、あまり SQL Server 2014 を触れていないのでぼちぼち触っていかないとですね。
DBCC WRITEPAGE を使用したダイレクトなページの書き換え
通常は使う機会はないのですが、DB が破損した場合のテストをしたい場合などに便利ですので書いてみたいと思います。
本番環境では絶対に使わないほうがよいと思います。
詳細については DBCC WRITEPAGE: an introduction の記事がとても参考になります。
securityadmin ロール以外のメンバーで ERRORLOG を参照する
SQL Server のエラーや稼働状況のログは ERRORLOG に記録されます。
通常、ERRORLOG は SSMS から開くことが多いかと思いますが、この場合 [securityadmin] のロールのメンバーである必要があります。 
SSMS から securityadmin 以外のロールのメンバーで ERRORLOG を確認するための方法をまとめてみたいと思います。
SQL Server で Windows Azure Datacenter Log Shipper の構成を作成してみる
先日、Geo-DR for SQL Server on Windows Azure Infrastructure Services using Log Shipping というドキュメントが公開されました。
この構成ですが、Windows Azure のインフラストラクチャを使用して、ログ配布による DR 構成を作成するというものです。
構成の概略としては、以下のようになります。
SQL Server Agent を使用して、定期的にバックアップを AZCopy で BLOB に保存し、そこからリストアすることで、ログ配布構成をとるというものになります。
この構成を作るための手順を見ていきたいと思います。
今回は、SQL Server 2012 SP1 CU 8 (評価版) を使用しており、オンプレミスの SQL Server がソースデータベース、Windows Azure 上の VM に構築された SQL Server が配信先のデータベースとなるように構成します。
非パーティションテーブルからパーティションテーブルへの切り替え
SQL Server 2005 移行の Enterprise Edition ではパーティションテーブルの利用が可能となりました。
パーティ初認ぐされたテーブルを使用することで大規模テーブルの大量データをアーカイブ、インデックスの一部メンテナンス、データのレンジによって使用するディスクを分散させる (パーティションをファイルグループで分けた場合) というようなことが可能となります。
SQL Server では SQL Server の評価版から製品版への移行 に記載しているような形でエディションを変更することができます。
エディション変更が可能なマトリックスは サポートされているバージョンとエディションのアップグレード に記載されており、Standard から Enterprise への変更も可能です。
Enterprise Edition に移行したタイミングでパーティショニングされたテーブルを使用したいということがあるかもしれません。
そこで、非パーティションテーブルをパーティションテーブルへ切り替える方法を少しまとめてみたいと思います。
クエリベースでデータベース単位のバックアップ世代を管理
SQL Server のメンテナンスプランでは、[メンテナンス クリーンアップ タスク] を使用することで、バックアップの世代を管理することができます。 
このタスクですがファイル名またはファイルの拡張子に基づいての削除となるため、特定のデータベースのバックアップを削除するということは難しいです。
バックアップの拡張子にデータベース名を付与 (<バックアップ名>.<データベース名>.bak) して、拡張子を <データベース名>.bak のものを削除対象とすればある程度は制御できるのですが。
今回の投稿では、クエリベースでデータベースのバックアップ世代を管理する方法をまとめてみたいと思います。
検索条件を指定した件数取得の最適化について考えてみる
以前、クラスター化インデックスのみのテーブルで COUNT(*) をおすすめしない理由 という投稿を書きました。
クラスター化インデックスのみのテーブルに対して、件数取得をした場合、テーブルスキャンが発生し、全権取得が行われるため、非クラスター化インデックスを設定、または、sys.dm_os_partition_stats から件数を取得したほうが効率的です。
前回の投稿では、テーブルの全件数を取得していましたので、今回の投稿では、単一のテーブルに対して特定の条件にマッチする件数の取得の最適化について考えてみたいと思います。
今回は通常の行ストアを対象にしており、列ストアの場合は考え方が変わってきます。
SQL Server 2012 の SSMS 向けカスタムレポートを作成
gMSA を使用して SQL Server をインストール
Windows Server 2012 以降で、グループの管理されたサービスアカウント (gMSA : Group Managed Service Accounts) を使用することができるようになりました。
使ったことがなかったので、SQL Server のサービスアカウントとして使う方法をまとめてみたいと思います。
TecｈNet としては、
グループの管理されたサービス アカウントの概要
管理されたサービス アカウントの新機能
Getting Started with Group Managed Service Accounts
他の方が検証された内容としては、
グループ管理サービスアカウント (Always on the clock)
ADFSのクレームにSQL Serverデータベースを使う方法 (Always on the clock)
Windows Server 2012以降の“グループの”管理されたサービスアカウント(gMSAs)について (山市良のえぬなんとかわーるど)
が参考になります。