可用性グループを構築する場合、複数のサーバーを用意していましたが、クラスターレス可用性グループであれば、Docker のコンテナーを二つ用意すれば構成をとれるのではないだろうかと思って試してみました。
とりあえず、組めるかどうかを試したので、手動での対応の連続です…。
Read the rest of this entry »
SQL Server on Linux の Docker 版を使って、1 サーバーでクラスターレス可用性グループを組んでみる
SQL Data Warehouse で Replicated Table が Public Preview でサポートされたようです
今日、この話題になって、「そういえばどうなったんだろう」と思って調べてみたところ How can we improve Microsoft Azure SQL Data Warehouse ? で「COMPLETED」となり、Public Preview として実装が行われたようです。
SQL DW のベースになった PDW では、初期から実装されていたかと思いますが、SQL DW でもついに来ましたね。
- 超並列処理 (MPP) 用の分散データと分散テーブル
- Azure SQL Data Warehouse でレプリケート テーブルを使用するための設計ガイダンス
- sys.pdw_replicated_table_cache_state (Transact-SQL)
- CREATE TABLE (Azure SQL Data Warehouse)
- CREATE TABLE AS SELECT (Azure SQL Data Warehouse)
サイズについては2GB 程度が推奨となるようですが、各コンピュートノードに近い位置にデータが分散された形でテーブルが配置されるような分散方法が可能になります。
Replicated Table を使用することで、各コンピュートノードにテーブルが配置されるようになるため、テーブルの結合時のデータの移動のコストを抑えることができるようになります。
マスター関連のテーブルで効果的に動作する感じですかね。
データの変更が頻繁に発生するものや、コンピュートノードの数を頻繁に変更するような場合には、情報の再構築のオーバーヘッドが発生するようですので、必要になるかはきちんと検討する必要があるかとは思いますが。
SQL Database で再開可能なオンラインインデックス再構築が Public Preview で利用可能となりました
Resumable Online Index Rebuild is in public preview for Azure SQL DB でアナウンスされていますが、SQL Database で、SQL Server 2017 で実装される再開可能なオンラインインデックス再構築が、Public Preview ではありますが利用可能となりました。 Read the rest of this entry »
SQL Server 2017 RC1 が公開されました
MS のブログでアナウンスされていますが、SQL Server 2017 の最初のリリース候補版となる SQL Server 2017 RC1 が公開されました。
SQL Database の長期保存バックアップで使用した Recovery Service が削除できない場合の対応方法
SQL Database の 長期保存バックアップ は、 Recovery Service 上に取得されます。
この Recovery Service を削除しようとした際に、ポータル上の内容ではすべての設定やコンテナーが存在していない状態でも、削除がエラーになることがあります。
この場合、Azure RecoveryServiceVault can’t be removed? の対応をすると削除ができるようになります。
$vault = Get-AzureRmRecoveryServicesVault -Name "VaultName" Set-AzureRmRecoveryServicesVaultContext -Vault $vault $container = Get-AzureRmRecoveryServicesBackupContainer -ContainerType AzureSQL -FriendlyName $vault.Name $item = Get-AzureRmRecoveryServicesBackupItem -Container $container -WorkloadType AzureSQLDatabase $availableBackups = Get-AzureRmRecoveryServicesBackupRecoveryPoint -Item $item $availableBackups $containers = Get-AzureRmRecoveryServicesBackupContainer -ContainerType AzureSQL -FriendlyName $vault.Name ForEach ($container in $containers) { $items = Get-AzureRmRecoveryServicesBackupItem -container $container -WorkloadType AzureSQLDatabase ForEach ($item in $items) { Disable-AzureRmRecoveryServicesBackupProtection -item $item -RemoveRecoveryPoints -ea SilentlyContinue } Unregister-AzureRmRecoveryServicesBackupContainer -Container $container } Remove-AzureRmRecoveryServicesVault -Vault $vault
長期保存バックアップで使用しているサイズについても、ポータルから確認できる使用サイズに含まれているようなのですが、この領域を削除するための方法が、現時点のポータルからは用意されていないため、PowerShell を使用して、長期保存バックアップのコンテナーを明示的に削除する必要があるようですね。
これで削除を行えば、Recovery Service 自体も削除できるようになります。
Data Sync 2.0 が Azure Portal から設定できるようになりました
Migrating to Azure SQL Data Sync 2.0 で、2017/7/1 から、Data Sync の設定は Azure Portal からのみになるという記載があったことを思い出し、今どういう状態になっているんだろうと思って、確認をしたところ SQL Database に「別のデータベースに同期」という設定が増えていました。
![]()
先月の段階で、英語版のドキュメントについては、Data Sync 2.0 対応されていたんですね。
Getting Started with Azure SQL Data Sync (Preview)
制限等については次のドキュメントから確認することができます。
Sync data across multiple cloud and on-premises databases with SQL Data Sync
Read the rest of this entry »
SQLCAT から SQL Server on Linux のモニタリングツールが公開されました
sys.dm_os_wait_stats先週の話になりますが SQLCAT (SQL Server Customer Advisory Team) から、SQL Server on Linux のモニタリングツールが公開されましたので、少しまとめておきたいと思います。
How the SQLCAT Customer Lab is Monitoring SQL on Linux
今回公開されたツールは SQL Server on Linux の稼働状況を以下のような UI で確認することができるツールとなっています。
![]()
![]()
![]()
Read the rest of this entry »
SQL Database で互換性レベル 140 がパブリックプレビューとなりました
Public Preview of Compatibility Level 140 for Azure SQL Database でアナウンスされていますが、SQL Database で互換性レベル 140 がパブリックプレビューとなっています。
少し前から設定できていた気がしなくもないのですが、正式にパブリックプレビューになったのは今回のタイミングなんですね。
Read the rest of this entry »
Azure Stack TP3 のストレージアカウントと SQL Server の連携を試してみる
Azure Stack ではストレージアカウントも作成できますので、このストレージアカウントと SQL Server の連携機能についても少し試してみました。
Azure Stack のストレージアカウントの作成については、次のような設定となっています。
![]()
Read the rest of this entry »
Azure Stack TP3 の SQL Hosting Server / SQL Databases の構成を把握する
Azure Stack TP3 の環境を、SQL Server resource provider adapter がインストールされている状態で、お借りすることができたので、TP3 時点の Azure Stack では、どのような構成で、SQL Server を使用することができるのかをまとめてみたいと思います。
SQL Server 向けのリソースプロバイダー (以降、SQL RP) については、次の情報から確認することができます。
Use SQL databases on Azure Stack
本投稿は、Azure Stack も SQLRP もどちらも Preview の内容ですので、今後変更があるかもしれないということはご了承ください。
また、管理用のポータルで構成を把握するための検証をしているため、エンドユーザーに利用する場合の方法については本投稿では基本的に触れていません。
大事なことを書いておくと、この? SQL RP で提供される SQL Server のデータベースは、
The resource provider does not support all the database management capabilities of Azure SQL Database. For example, elastic database pools and the ability to scale database performance aren’t supported.
となっていることです。
Azure では「SQL Database」として、PaaS 型の DB が提供されており、Azure Stack では、この SQL RP により提供される DB が Azure Stack 版の SQL Server の PaaS 型 DB に相当すると思うのですが、この二つの機能は大きく異なっています。
SQL Database は、SQL Server のデータベースエンジンと同等のものを使用していますが、Azure に適応された形でカスタマイズがされている「SQL Server のデータベースエンジンを使用している Azure に適応したものとして開発が行われたデータベース」です。
たいして、Azure Stack の SRP 提供されるデータベースは「製品版 (Box 版) の SQL Server を使用して SQL Server 内のデータベースを切り出した形て提供をする」ものとなっています。
そのため、SQL RP で使用する SQL Server の管理や、構成などについてもすべて、Azure Stack の提供側で考慮する必要があり、ドキュメントにも書かれているように、Elastic Pool や、データベース単位のパフォーマンスの制御機能といったものは標準の仕組みとして、現時点のプレビューの段階では提供されていません。
SQL Server のリソースガバナーと組み合わせた形で今後提供されるかもしれませんが、現時点の実装では、次のようなことは、リソース提供側で考慮する必要があります。
- サーバーの管理 (バックアップを含めた運用)
- 冗長構成 (AlwaysOn 可用性グループ等を利用した、SQL Hosting Service のサーバーの構築)
- データベース毎のリソース制御 (CPU / メモリ / ディスク I/O)
(データベースのサイズの制御は、Azure Stack 側で実施できます) - tempdb の利用状況 (複数のデータベースは同一の tempdb を使用します)
SQL RP による提供される SQL Database の構成の全体がいようとしては、次の図のような感じでしょうか。
![]()
Read the rest of this entry »