SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
SQL Server 2008 以降はデータコレクションの機能が追加され、サーバーの各種情報をレポートとして表示することができます。
データコレクション用データベースサイズやキャッシュされるデータ分のメモリが意外と無視できないので、運用環境に設定する場合には、データコレクション用のインスタンスを用意して使用した方がよかったりします。
データコレクションを他のインスタンスで一元管理するときに接続のユーザーで少し考慮点がありますのでメモとして。
詳細については、以下の技術文書が参考になります。
データ コレクタのアーキテクチャと処理
データ コレクタの使用
AlwaysOn 可用性グループのダッシュボードでは、列を追加することで、プライマリレプリカとセカンダリレプリカ間のデータ損失の推定時間を取得することができます。
同期モードでプライマリ/セカンダリが起動している場合には、データ損失時間は原則として発生しませんが、非同期コミットモードを使用している / メンテナンスのためセカンダリレプリカが停止している場合などは、サーバー間でデータの更新状況に差が発生し、データ損失の可能性が出てきます。
この情報をクエリで取得するための方法をメモとして。
以前から調べようと思っていたのですが手が出せていなかったので。
SQL Server 2005 以降は Enterprise Edition でパーティショニングが使用できるようになり、アーカイブテーブルへのスイッチが瞬時に実行できるようになりました。
これにより大量のデータを格納しているテーブルに対して、効率よくデータを移動することができます。
パーティションのスイッチではよく
というようなことを聞くかと思いますが、この内部的な動作が気になったので、内部テーブルのレコードの変化を確認してみました。
ちょっとしたメモですが特定の操作を含むクエリ情報の取得のパターンをいくつか。
それっぽい情報は取れていると思いますが、XML の操作あまりわかっていません…。
そのうち 修羅イバーさんか 修羅イバーブログ で取り上げてくれると信じています。
XML の操作については Basic SQL Server XML Querying / Manipulating XML Data in SQL Server が参考になりました。
ストアド プロシージャの自動実行
Azure の仮想マシン上で実行している SQL Server のような環境で Max Server Memory を設定しておりスケールアップをする際に、搭載されているメモリを元に自動的に Max Server Memory を設定することで、スケールアップ時の Max Server Memory の変更を意識しないでもよいかなと思ってサンプルを作ってみました。
ストアドプロシージャの自動実行については ストアド プロシージャの自動実行 を参考にしていただければと思います。
SQL Server のデータベースのリストア検証をするためにデータベースを破損させる必要のあることがあります。
データベースを意図的に破損させる方法について軽く書いてみたいと思います。
CU や SP ではなく、2014/8 のセキュリティ修正プログラムとして SQL Server の修正プログラムが提供されています。
GDR / QFE が出るのは久しぶりな気がしますね。
2014 年 8 月のマイクロソフト セキュリティ情報の概要
Microsoft Security Bulletin MS14-044 – Important
これらの Update は Windows Update 経由でも適用されますので、SQL Server をインストールされている環境で Windows Update をする場合には、GDR または QFE がダウンロードされてきますので意識しておいた方がよろしいかと.
# 使用している SQL Server のマイナーバージョンによって GDR or QFE のどちらを適用するかが違ってくるようです。
SQL Server でアドホッククエリを頻繁に実行している場合、類似クエリが複数キャッシュされている状態となり、メモリを効率よく使用していない状態となることがあります。
今回の投稿では類似クエリの調査について少しまとめてみたいと思います。
詳細について クエリおよびクエリ プラン ハッシュを使用した類似クエリの検索およびチューニング を。
SQL Server 2012 以降では AlwaysOn 可用性グループが実装され、これによりデータベースミラーリングは将来のバージョンの SQL Server では削除予定の機能となりました。
データベース ミラーリング (SQL Server)
ただし、AlwaysOn については Enterprise Edition/ Active Directory が必要となるため、
の構成で、ミラーリングを組まざるを得ないこともあるかと思います。
Azure の仮想マシン (Azure VM / VIrtual Machine) でデータベースミラーリングを組む方法としては チュートリアル:Azure で高可用性を実現するデータベース ミラーリング があります。
このチュートリアルでは証明書を使用したエンドポイントへの接続を行っていますが、証明書を使用した場合は、
How to replace expired certificates used in database mirroring
SQL Yoga : Certificate Expired, Mirroring Stopped
データベース ミラーリング エンドポイントで発信接続に証明書を使用できるようにする (Transact-SQL)
に記載されているように証明書の有効期限を意識する必要があるかと思います。
# デフォルトでは 1 年で有効期限が切れるかと。
証明書を使用しないエンドポイントへの接続としては
し、エンドポイント間の接続を行う方法があるかと思います。
こちらはチュートリアルには記載されていない方法となりますが、実際の環境ではこちらで運用されていることが多いかと。
組み方にもよるかもしれませんが、Azure の仮想マシン上に SQL Server 2014 をインストールした環境で同一のユーザー名 / パスワードで起動している SQL Server 間でミラーリングを組む際に試行錯誤する箇所があったのでメモとして。
以前、クラスター化インデックスのみのテーブルで COUNT(*) をおすすめしない理由 という投稿を書きました。
クラスター化インデックスのみが設定されているテーブルに対しての COUNT(*) はテーブルスキャンが発生してしまうため、非クラスター化インデックスを設定して、非クラスター化インデックススキャンまたは、sys.dm_db_partition_stats を使用してテーブル全体の件数 (概算件数) を取得するという内容です。
この投稿はテーブル全体の件数を取得する際の方法でしたので、今回の投稿では WHERE で条件を絞った場合の件数取得について少し考えてみようかと。