以下のようなクエリを実行してみます。
DECLARE @tmp char(500) SELECT @tmp = Col1 FROM [dbo].TempDBTest ORDER BY Col1 DESC OPTION (MAXDOP 0) GO
この時の実行プランは以下のようになります。
実行プランからは複数のスレッドによる並列クエリとして実行されていることが確認できます。
実行中のセッションについて、この確認を実行プラン以外から確認する方法を。
Archive for the ‘SQL Server’ Category
特定のセッションで実行されているクエリが複数スレッドで実行されているかを確認
トランザクションレプリケーションの基本的な仕組み
トランザクションレプリケーションの基本的な仕組みを調べたことがなかったのでメモとして。
今回はプッシュサブスクリプションを利用しています。
レプリケーションについては、兄貴 の SQL Server replication overview や SQL Server のレプリケーション から情報を追ってみると良いかと。
Read the rest of this entry »
森?外るでみる SQL Server のデータ格納
Unicode 文字列の格納をテストする際に [森?る] を使うことがよくあるかと思います。
この文言を使って SQL Server のデータ格納を見てみようかと。
森鷗外るでみる SQL Server のデータ格納
Unicode 文字列の格納をテストする際に [森鷗る] を使うことがよくあるかと思います。
この文言を使って SQL Server のデータ格納を見てみようかと。
AlwaysOn 可用性グループをテンプレートから展開してみる
先月の Azure のアップデートで SQL Server 2014 の AlwaysOn 可用性グループの環境がポータルからテンプレート展開できるようになりました。
Microsoft Azure ポータルのギャラリーで SQL Server AlwaysOn テンプレートを提供開始
SQL Server AlwaysOn Offering in Microsoft Azure Portal Gallery
テンプレート展開の流れを軽く見てみたいと思います。
SSMS が管理データウェアハウスの判断に使用しているプロパティ
SSMS でデータコレクションの管理データウェアハウスを右クリックすると [レポート] に管理データウェアハウス用のレポートが表示されます。
SSMS が管理データウェアハウスかどうかをどのように判断しているかを小ネタとして。
データコレクションの情報の一元管理
SQL Server 2008 以降はデータコレクションの機能が追加され、サーバーの各種情報をレポートとして表示することができます。
データコレクション用データベースサイズやキャッシュされるデータ分のメモリが意外と無視できないので、運用環境に設定する場合には、データコレクション用のインスタンスを用意して使用した方がよかったりします。
データコレクションを他のインスタンスで一元管理するときに接続のユーザーで少し考慮点がありますのでメモとして。
詳細については、以下の技術文書が参考になります。
データ コレクタのアーキテクチャと処理
データ コレクタの使用
SQL Database の新しいサービスレベルのリソースのフィット状況を確認
Azure界の抱かれたい男No.1 から、Azure SQL Database introduces new near real-time performance metrics の情報を教えてもらいましたので、ちょっと見てみたいと思います。
Azure SQL Database introduces new near real-time performance metrics http://t.co/lAvN6vCAYf @Masayuki_Ozawa ムッシュ先生、出番です！
— こすもす.えび (@kamebuchi) 2014, 9月 11
AlwaysOn 可用性グループの推定データ損失時間をクエリで取得
AlwaysOn 可用性グループのダッシュボードでは、列を追加することで、プライマリレプリカとセカンダリレプリカ間のデータ損失の推定時間を取得することができます。
同期モードでプライマリ/セカンダリが起動している場合には、データ損失時間は原則として発生しませんが、非同期コミットモードを使用している / メンテナンスのためセカンダリレプリカが停止している場合などは、サーバー間でデータの更新状況に差が発生し、データ損失の可能性が出てきます。
この情報をクエリで取得するための方法をメモとして。
パーティションをスイッチした際の内部テーブルの変化を確認してみる
以前から調べようと思っていたのですが手が出せていなかったので。
SQL Server 2005 以降は Enterprise Edition でパーティショニングが使用できるようになり、アーカイブテーブルへのスイッチが瞬時に実行できるようになりました。
これにより大量のデータを格納しているテーブルに対して、効率よくデータを移動することができます。
パーティションのスイッチではよく
- ポインターのみを変更することで瞬時にデータをパージする
というようなことを聞くかと思いますが、この内部的な動作が気になったので、内部テーブルのレコードの変化を確認してみました。