SQL Server のエラーや稼働状況のログは ERRORLOG に記録されます。
通常、ERRORLOG は SSMS から開くことが多いかと思いますが、この場合 [securityadmin] のロールのメンバーである必要があります。 ![]()
SSMS から securityadmin 以外のロールのメンバーで ERRORLOG を確認するための方法をまとめてみたいと思います。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
先日、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 に移行したタイミングでパーティショニングされたテーブルを使用したいということがあるかもしれません。
そこで、非パーティションテーブルをパーティションテーブルへ切り替える方法を少しまとめてみたいと思います。
以前、クラスター化インデックスのみのテーブルで COUNT(*) をおすすめしない理由 という投稿を書きました。
クラスター化インデックスのみのテーブルに対して、件数取得をした場合、テーブルスキャンが発生し、全権取得が行われるため、非クラスター化インデックスを設定、または、sys.dm_os_partition_stats から件数を取得したほうが効率的です。
前回の投稿では、テーブルの全件数を取得していましたので、今回の投稿では、単一のテーブルに対して特定の条件にマッチする件数の取得の最適化について考えてみたいと思います。
今回は通常の行ストアを対象にしており、列ストアの場合は考え方が変わってきます。
Windows Server 2012 以降で、グループの管理されたサービスアカウント (gMSA : Group Managed Service Accounts) を使用することができるようになりました。
使ったことがなかったので、SQL Server のサービスアカウントとして使う方法をまとめてみたいと思います。
TechNet としては、
グループの管理されたサービス アカウントの概要
管理されたサービス アカウントの新機能
Getting Started with Group Managed Service Accounts
他の方が検証された内容としては、
グループ管理サービスアカウント (Always on the clock)
ADFSのクレームにSQL Serverデータベースを使う方法 (Always on the clock)
Windows Server 2012以降の“グループの”管理されたサービスアカウント(gMSAs)について (山市良のえぬなんとかわーるど)
が参考になります。
差分バックアップとログバックアップを使用した運用をする場合、起点となる完全バックアップが必要となります。
週一で完全バックアップ / 残りの曜日はフルバックアップというようなバックアップタクトがよくあるパターンかと思います。
このような運用をする場合の起点となるバックアップを自動的に取得するトリガーを作成してみたいと思います。
プロファイラや SQL トレースでも取得はできるのですが、今後のメイン機能となると思う拡張イベントを使用してスロークエリログを取得する方法を。
SQL Server は操作の方法によってデータベースのファイルに対しての I/O のサイズが変わってきます。
今回の投稿ではその確認方法を書いてみたいと思います。
# 以前書いたような記憶があったのですが、見つからなかったので。