Ignite でも紹介されていたのですが、SQL Server 2016 now supports Windows Server 2016 Storage Spaces Direct という構成があります。
S2D で SQL Server を使用するという構成ですが、S2D 自体、組んだことがなかったので関連しそうなドキュメントのメモを。
Read the rest of this entry »
Author Archive
Storage Space Direct の SQL Server を検証しようとしていて確認していたドキュメントのメモ
ローリングアップグレードを使用した 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 の特定について、少し考えてみました。
マルチドメインクラスターで AlwaysOn 可用性グループ
以前、TP３ で Azure 上でワークグループクラスターを構築し、その上に CTP 2.4 のAlwaysOn を構築してみる という投稿を書きました。
そういえば、ワークグループクラスターは構築したことはありますが、マルチドメインクラスターは構築したことがなかったかなと思い、軽く検証してみました。
ワークグループクラスター / マルチドメインクラスターに関しては、以下の情報が公開されているものとなるかと思います。
Workgroup and Multi-domain clusters in Windows Server 2016
What’s new in failover clustering: #04 Workgroup and multi-domain clusters
What’s new in Failover Clustering in Windows Server 2016 が OS 側のドキュメントになるかと思いますが、ここからのリンクも結局は上記のブログなんですよね。。。
Ignite 2016 の SQL Server のデータベースエンジン関連のセッション
Ignite 2016 のセッションですが、Microsoft Ignite On-Demand で動画が公開されてています。
とりあえず、SQL Server のデータベースエンジン関連のセッションを流し見しているのですが、エンジン回りで関連しそうなセッションの紹介を。
最近、英語が苦手なのが致命的に響いてきていて、ひさしになんとかしてもらわないと生きていくのがつらいです…。
スライドについても公開されていて、 Ignite 2016 Slidedeck and Video downloader で一括でダウンロードできるようです。
Azure の ILB で複数のリスナー構成を実際に試してみる
昨日 Multiple VIPs for internal Load Balancer GA !! という投稿を書きましたが、実際に Azure 上に構築されている AlwaysOn 可用性グループで複数リスナーを構築してみました。
Azure 上に AlwaysOn AG 構成を構築する際のリスナーについて の内容が把握できていれば、設定はスムーズにできるかと。
Multiple VIPs for internal Load Balancer GA !!
我らが ブチザッキ兄さん が Cloud Platform Release Announcements for September 26, 2016 を見つけられ、その中に、
Multiple VIPs for internal Load Balancer | GA
という記述がありました。
Preview していたのかも気づかなかったのですが、私的にはいきなり GA でしたw
このリリースは、SQL Server on Azure VM のシナリオにも影響してきます。
Multiple VIPs for internal Load Balancer | GA
Azure Multiple VIP support for Azure internal Load Balancer is now generally available.
Multiple VIP support for Azure internal Load Balancer deployed via Azure Resource Manager allows customers to deploy more efficient, more scalable environments. ? frontend port reuse across the multiple VIPs ? option for DSR (“FloatingIP”) allows for backend port reuse SQL AlwaysOn Multiple Listener scenario documentation is available and released as Preview. The AzureCAT team is supporting SAP Multi-SID scenario. Multi-SID configuration enables consolidation of multiple SAP instances into two cluster nodes.
This cuts down the number of operating system images, server or VMs you have to manage.
- Multiple VIPs on load balancer documentation
- SQL AlwaysOn with multiple listeners documentation
Windows Server 2016 が GA したので関連ドキュメントを探してみる
タイトルの通りですが、Ignite で Windows Server 2016 が GA したので、後で見る用の関連ドキュメントのメモ
Announcing the launch of Windows Server 2016
Windows Server Evaluations
System Center Evaluations
SQL Server 2016 における TF1117 と TF1118
SQL Server 2016 では、tempdb に関しては TF1117 / 1118 がで有効になっており、ユーザーデータベースに関しては、データベースレベルの構成で設定ができるようになりました。
これについては、SQL Server 2016: Changes in default behavior for autogrow and allocations for tempdb and user databases でも紹介されています。
スタートアップスクリプトが完了するまでログインを待機させる
スタートアップスクリプトが完了するまでログインを待機させる荒い方法を。