気づいたら SQL Database v12 でも、blocked_process_report によるロック競合が発生したクエリの情報が取得できるようになっていました。
クエリストアによる、クエリタイムアウトしたクエリの取得
SQL Server 2016 / SQL Database v12 で使用できるクエリストアの機能では、正常終了したクエリだけでなく、異常終了したクエリについても情報が取得されています。
異常終了したクエリから、クエリタイムアウト (コマンドタイムアウト) したクエリの情報の取得について考えてみたいと思います。
クエリストアの情報については、かなり日本語化されたものが出てきていますので、クエリ ストアがデータを収集するしくみ を一読しておくとよいかと。
Read the rest of this entry »
Active Directory モジュールのコマンドレットを使用せずにクラスターで使用するコンピューターアカウントを作成する
Active Directory の操作をする場合、最近の情報では、Active Directory モジュールのコマンドレットを使用するケースが多いかと思います。
環境によっては、AD 用のコマンドレットをインストールせずに AD の操作をする必要も出てくるかと。
クラスターを構築する場合、コンピューターアカウントの作成で、AD の操作をする必要がありますので、簡単なサンプルを。
更新プログラムの適用状況によっては、以下の対応が必要となることもありそうです。
# コンピューターアカウントの作成時点で、UserAccountControl を適切にを設定していないと、primaryGroupID が User になってしまう現象が。
Problem with Active Directory patch MS15-96?
[MS15-096] Active Directory サービスの脆弱性により、サービス拒否が起こる (2015 年 9 月 8 日)
この辺も参考に
Create Active Directory Computer Object
Read the rest of this entry »
AlwaysOn 可用性グループを特定の可用性グループに紐づけてフェールオーバーさせる
Enterprise Edition の場合は、一つの可用性グループに複数のデータベースを配置することができますので、他の DB との JOIN については、必要となる DB を特定の可用性グループにまとめればよいのですが、Standard Edition の場合は、機能の制約があるためそうはいきません。
Standard Editoin では、セカンダリレプリカを読み取り専用として使用することができませんので、以下のような配置になった場合、DB1 と DB3 のテーブルを JOIN するということができない状態となります。
そもそもとして、リスナーを経由しないアクセスを使用としているのが問題なのですが、実際の利用シーンではこのような配置になった状態で、クエリ的に JOIN をしたい要望というのは発生してしまうかと思います。
Windows Server 2016 のコンテナーに関してのドキュメント
週末に Windows Server 2016 のコンテナーを触ってみたのですが、情報が全然追えていないので、後で見るように。
最初に、Windows コンテナー を見るのがよさそうでした。
# 英語版のほうが最新化されているものもありますので、Windows Containers も。
あとは、Build and run your first Docker Windows Server container / Introducing Docker for Windows Server 2016 も見ておくとよさそうです。
Ignite でもコンテナーに関してはセッションが行われており、取り掛かりとしては以下のセッションを見ておくとよさそうでした。
Dive into the new world of Windows Server and Hyper-V Containers
Accelerate application delivery with Docker Containers and Windows Server 2016
Dockerfile のサンプルについては windows-container-samples から入手可能です。
Dokcer の Engine reference についても、Windows 対応しているようで、run のリファレンスを見ると Hyper-V コンテナーに対応していました。
Windows Server 2016 の Windows コンテナーで SQL Server 2016 Express を動作させるための情報
SQL Server 2016 Express を Windows にインスコするより早く使えるようになった。Windows Containers かなり良いのでは pic.twitter.com/dPTJBR9ocg
? しばやん (@shibayan) 2016年10月15日
で、しばやん先生が試されていますが、勉強かねて自分でも。
Storage Space Direct で SQL Server を構築してみる
昨日書いた Storage Space Direct の SQL Server を検証しようとしていて確認していたドキュメントのメモ の続きです。
ストレージ系の機能との統合としては、以下のようになっていたかと思います。
Using SQL Server in Windows 8 and later versions of Windows operating system
FIX: "Requested value ReFS was not found" error when you install SQL Server 2014 on a local drive that is ReFS formatted
Deploying SQL Server 2014 with Cluster Shared Volumes
アプリケーション データに対応するスケールアウト ファイル サーバーの概要
手順 4:スケールアウト ファイル サーバーを使用する Microsoft SQL Server の構成
| 記憶域スペース | SQL Server 2008 SP1 または、SQL Server 2012 以降 |
| クラスター共有ボリューム (CSV) | SQL Server 2014 以降 |
| ReFS | SQL Server 2014 以降 |
| スケールアウトファイルサーバー | SQL Server 2008 R2 以降 |
SQL Server 2016 では、これに Storage Space Direct が追加される形になるのでしょうね。
SQL Server 2016 now supports Windows Server 2016 Storage Spaces Direct
Storage Space Direct の SQL Server を検証しようとしていて確認していたドキュメントのメモ
Ignite でも紹介されていたのですが、SQL Server 2016 now supports Windows Server 2016 Storage Spaces Direct という構成があります。
S2D で SQL Server を使用するという構成ですが、S2D 自体、組んだことがなかったので関連しそうなドキュメントのメモを。
Read the rest of this entry »
ローリングアップグレードを使用した AlwaysOn 環境のアップグレード
Windows Server 2016 では、クラスターの環境をローリングアップグレードを使用して、OS をバージョンアップする仕組みが追加されています。
Cluster operating system rolling upgrade
AlwaysOn 可用性グループでもローリングアップグレードをする仕組みが提供されています。
AlwaysOn 可用性グループのレプリカ インスタンスのアップグレード
Windows Server 2016 が RTM した現状であれば、OS を含めてアップグレードをするケースが出てくるかもしれません。
そこで、調査がてら少し検証してみました。
Ignite の Understand how ChannelAdvisor is using SQL Server 2016 to improve their business のアップグレードについても、可用性グループのローリングアップグレードを使用しているのかと。
クエリストアから特定のクエリの情報を取得する
Ignite のセッションを見ていたところ、クエリストアの活用方法がいろいろと紹介されていて、実践的な方法がかなり勉強になりました。
SQL Server 2016 にアップグレードした際に、
- クエリストアを有効にする
- アップブレード前の互換性レベルで、テスト用のワークロードを実行
- 互換性レベル 130 に変更
- 再度、テスト用のワークロードを実行
- 実行効率が低下したクエリを確認し、必要に応じて、プランの強制を実施
という手順を行い、アップグレード後のクエリの実行効率の低下を防止するという手法についてはなるほどと思いました。
クエリストアでは、実行効率が低下したクエリや、リソースの消費量の高いクエリについては、SSMS から取得することができます。
特定のクエリの状態を取得したい場合は「追跡したクエリ」を使用することになるかと思いますが、この取得では「クエリ ID」を指定して情報の取得を行う必要があります。
特定のクエリについての情報を見たい場合のクエリ ID の特定について、少し考えてみました。