Storage performance best practices and considerations for Azure SQL DB Managed Instance (General Purpose) で、Managed Instance (MI) の General Purpose (汎用目的) のストレージのベストプラクティスが公開されました。
Archive for the ‘Managed Instance’ tag
SQL Server 関連の情報 (2018/7/18)
SQL Server 周りでいろいろと情報が公開されていたので、後で見るためにちょっとまとめておきたいと思います。 Read the rest of this entry »
SQL Database Managed Instance の Azure のリソース構成とネットワーク接続についてまとめてみる
本投稿は 2018/4 時点の Public Preview の内容です。
一般提供開始時には変更されている可能性があります。
今回の内容は公式のドキュメントから外れて、自分で調査した際の内容のまとめです。
# リソース構成はポータルから見たものですので、ドキュメントから外れていないと思いますが。
SQL Database Managed Instance と SQL Server / SQL Database の比較
本投稿は 2018/4 時点の Public Preview の内容です。
一般提供開始時には変更されている可能性があります。
SQL Database Managed Instance と Azure の SQL Server ベースのサービスを比較してみた際にまとめたものを投稿しておきたいと思います。
機能差異については、次のドキュメントから追うことになるかと。
比較結果は、利用者によっていろいろな観点があるかと思いますので、今回の比較はあくまでも「私個人が調べた結果での比較」となっていますのでご了承ください。
(MI はプレビューのサービスですので、この投稿に書いてある内容も、時期によっては古いですのでご承知おきください)
SQL Database Managed Instance に Database Migratoin Service を使用してデータベースの移行を実施する
本投稿は 2018/4 時点の Public Preview の内容です。
一般提供開始時には変更されている可能性があります。
今までの投稿では、手動で SQL Database Managed Instance (MI) に、データベースの移行を実施していました。
Azure には、データベースの移行を実施するためのサービスとして、Azure Database Migration Service (DMS) というサービスが、投稿を書いている時点ではプレビューの状態ではありますが利用することができるようになっています。
現状、対応しているパターンとしては、次の 2 パターンとなっており、MI についても、DMS を使用してマイグレーションできるようになっています。
- SQL Server -> Azure SQL Database
- SQL Server -> Azure SQL Database Managed Instance
本投稿では、Azure のサービスを使用した Migration について見ていきたいと思います。
SQL Database Managed Instance のネイティブバックアップの取得について
本投稿は 2018/4 時点の Public Preview の内容です。
一般提供開始時には変更されている可能性があります。
前回の投稿では、SQL Server のネイティブバックアップのリストアについて書きました。
SQL Database Managed Instance (MI) は、SQL Server のネイティブバックアップをリストアできるだけでなく、MI からネイティブバックアップを取得することができるようになっています。
今回は MI のネイティブバックアップの取得について見ていきます。
SQL Database Managed Instance のネイティブバックアップのリストアについて
本投稿は 2018/4 時点の Public Preview の内容です。
一般提供開始時には変更されている可能性があります。
SQL Database Managed Instance (MI) の大きな特徴の一つとして「ネイティブバックアップのリストア」をする機能があります。
ネイティブバックアップとは、オンプレミスの SQL Server で取得されているバックアップのことを指します。
従来から提供されている PaaS 型の SQL Server ベースの RDBMS である「Azure SQL Database」「Azure SQL Data Warehouse」では、ネイティブバックアップのリストアはサポートされていませんでした。
そのため、SQL Server のデータベースを移行しようとした場合、
- スキーマ / データをエクスポートしたものをベースにして移行を検討
- BACPAC ファイルで移行
というような手法をとる必要がありました。
しかし、大規模なデータベースの場合、これらの方法は効率的ではありませんし、何回も移行をするという作業には適していませんでした。
この辺がネックになり、PaaS ではなく、IaaS の「SQL Server on Azure VM」を採用したというケースもあるのではないでしょうか。
このような現状に対して「SQL Database Managed Instance」は、オンプレミスの SQL Server のバックアップをリストア可能にしています。
これにより、PaaS で提供されているデータベースへの「リフト & シフト」を容易にしているというのが特徴としてあります。
リストア可能なデータベースは「ユーザーデータベース」のみとなっており、システムデータベースはリストアすることができません。
そのため、ログインや SQL Server Agent のジョブの情報についてはスクリプトでの移行を検討する必要があります。
それでは、ユーザーデータベースのリストアを、どのように実施するのか、流れを見ていきましょう。
SQL Database Managed Instance の初期の照合順序について
本投稿は 2018/4 時点の Public Preview の内容です。
一般提供開始時には変更されている可能性があります。
SQL Database Managed Instance (MI) の作成時の UI は下の画像のようにシンプルな構成となっています。
SQL Database を使用されている方だと、ピンとくるかもしれませんが、「照合順序」の設定が存在していません。
本投稿では、MI の照合順序について触れてみたいと思います。
SQL Database Managed Instance のユーザーデータベース構成について
本投稿は 2018/4 時点の Public Preview の内容です。
一般提供開始時には変更されている可能性があります。
SQL Database Managed Instance (MI) は、インスタンスタイプのマネージドサービスのため、ユーザーが自由にデータベースを作成することが可能です。
しかし、単純にデータベースを作成すれば、インスタンスで最大限の性能を引き出すことができるかというと、汎用目的のサービス階層については、そういうわけではありません。
MI に適したデータベースの構成というものについては意識をしておく必要があります。
本投稿ではそれらについてまとめていきたいと思います。
(本投稿の内容は、「汎用目的 (汎用サービス階層) の場合」となります。ビジネスクリティカルについては本投稿とは異なる傾向になるかと思います。)
SQL Database Managed Instance を配置する仮想ネットワークの構成について
本投稿は 2018/4 時点の Public Preview の内容です。
一般提供開始時には変更されている可能性があります。
SQL Database Managed Instance (MI) について色々と情報を発信していきたいと思います。
最初のポイントとしては MI を配置する仮想ネットワークについて、まとめてみたいかと。
