皆さん、こんにちは。 BI Data Platform サポートチームです。

今回は、Azure 管理ポータルのギャラリーからデプロイした SQL Server 2017 on Linux を含む Azure Linux 仮想マシンを使用する場合の注意点について紹介します。

SQL Server 2017 on Linux を使用するうえで スワップ領域 (Swap) を作成することが推奨されていますが、Azure 管理ポータルのギャラリーからデプロイした SQL Server 2017 on Linux を含むAzure Linux 仮想マシンの場合、デプロイ後の Linux には、スワップ領域 (Swap) が存在しないイメージが存在します。

# Free SQL Server License: SQL Server 2017 Developer on Ubuntu Server 16.04 LTS (スワップ領域が存在しない)

# Free SQL Server License: SQL Server 2017 Developer on Red Hat Enterprise Linux 7.4 (RHEL) (スワップ領域が存在する)

なお、Azure Linux 仮想マシンの場合、Windows Azure Linux Agent というプロセスが存在しており、このエージェントのコンフィグレーション ファイルの ResourceDisk.EnableSwap 及び ResourceDisk.SwapSizeMB のパラメータを変更後、OSの再起動を実施することで、スワップ領域を作成することが可能となっています。

※ Windows Azure Linux Agent の詳細は、以下の公開情報を参照

Azure Linux エージェントの理解と使用

実際に、Azure Linux 仮想マシンにスワップ領域を作成してみましょう。

上記の手順で スワップ領域が作成されることが確認できました。

なお、上記の手順で スワップ領域が作成されない場合は、/mnt/resource/swapfile にスワップ領域を手動で作成ください。

もちろん、利用するメモリの上限として MaxServerMemory の設定は、Azure 仮想マシン環境上でも是非設定して下さい。

DO’s&DONT’s #12: やった方がいいこと – max server memory を設定する

安定稼働の一助となりましたら幸いです。

※ 本Blogの内容は、2017年12月現在の内容となっております。

今後、修正予定となっている問題について、ご紹介いたします。
なお、本記事は、サポート技術情報(KB)が公開されるまでの間に本問題をご案内する意図で掲載しております。

事象

スタンバイモードでトランザクション ログのリストア時にエラー 9004 、状態6 が発生し、リストアに失敗することがあります。
ログ配布をスタンバイモードで構成している場合は、セカンダリでのリストアジョブでエラー 9004 が発生します。
(※ ログ配布を構成していない場合でも、トランザクション ログの復元時に、スタンバイモード(RESTORE LOG WITH STANDBY)を実行する場合は本事象が発生することがあります。)

ログ出力例
2017-07-29 12:05:02.68 spid65      エラー: 9004、重大度: 16、状態: 6。
2017-07-29 12:05:02.68 spid65      An error occurred while processing the log for database 'Database_name'.  If possible, restore from backup. If a backup is not available, it might be necessary to rebuild the log.

原因

製品の問題により、稀なタイミングで、スタンバイモードでトランザクション ログのリストア時に、エラー 9004、状態 6 のエラーが発生することが SQL Server 2014 以降で確認されております。

※ 現時点では、SQL Server 2014、SQL Server 2016、SQL Server 2017 の将来の更新プログラムで、修正が計画されています。

事象発生後の対処

ログ配布を一度、解除し、現在のプライマリ データベースの完全バックアップをリストアし、ログ配布を再構成します。

[参考情報]
ログ配布構成からのセカンダリ データベースの削除 (SQL Server)
ログ配布構成へのセカンダリ データベースの追加 (SQL Server)

対策

トランザクション ログの復元時に、スタンバイモード(RESTORE LOG WITH STANDBY) を利用せず、RESTORE LOG WITH NORECOVERY を利用すれば、この事象は発生しません。

また、以下により、発生頻度を抑えることが可能です。

- トランザクション ログ ファイルの初期サイズ、拡張サイズをある程度(例えば、512 MB など)大きいサイズに設定する

※ 上記内容は、2017 年 12 月現在の情報となります。

This is a temporary post that was not deleted. Please delete this manually. (19f2bafa-f040-482c-88ab-e47f29400f29 - 3bfe001a-32de-4114-a6b4-4005b770f6d7)

皆さん、こんにちは。 BI Data Platform サポートチームです。

SQL Server 2017 以降ではインストール時に tempdb の初期サイズを変更できるようになっています。
これに伴い、インストール時にある程度大きなサイズを指定してインストールを検討されるお客様もいらっしゃるかと思います。
ただ、上記の初期サイズの設定箇所では内部的なタイムアウト(20分)が設定されており、ファイルの作成に20分を超えるとインストールが失敗(Execution Timeout Expired)します。

tempdbの初期サイズが変更できる新機能ではありますが、それ故に大きなサイズを指定してインストールが失敗する事がないように、事例としてご紹介させて頂きます。

事象

SQL Server 2017 のインストール時に大きい tempdb のファイルサイズを指定した場合、セットアップが失敗する事がある。

//エラー画面

//Message全文

The following error has occurred:
Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

//ログ抜粋
C:\Program Files\Microsoft SQL Server\140\Setup Bootstrap\Log\yyyymmdd_hhmmss\Detail.txt

(01) 2017-10-27 11:52:39 Slp: --SafeSqlCommand: EXEC sp_SetAutoSAPasswordAndDisable
(01) 2017-10-27 11:52:39 Slp: --SafeSqlCommand: ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, SIZE = xxxx MB, FILEGROWTH = xxx MB)
(01) 2017-10-27 12:12:44 Slp: Sco: SqlException: Message:Execution Timeout Expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
:
(01) 2017-10-27 12:13:28 Slp: Configuration action failed for feature SQL_Engine_Core_Inst during timing ConfigRC and scenario ConfigRC.
(01) 2017-10-27 12:13:28 Slp: Execution Timeout Expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
(01) 2017-10-27 12:13:28 Slp: The configuration failure category of current exception is ConfigurationFailure
(01) 2017-10-27 12:13:28 Slp: Configuration action failed for feature SQL_Engine_Core_Inst during timing ConfigRC and scenario ConfigRC.
(01) 2017-10-27 12:13:28 Slp: System.Data.SqlClient.SqlException (0x80131904): Execution Timeout Expired.  The timeout period elapsed prior to completion of the operation or the server is not responding. ---> System.ComponentModel.Win32Exception (0x80004005): The wait operation timed out

原因

SQL Server 2017 の新機能でInstall 時に tempdb のデータベースファイルサイズを明示的に変更できるようになっています。

SQL Server 2017 の新機能

https://docs.microsoft.com/ja-jp/sql/sql-server/what-s-new-in-sql-server-2017

セットアップ時に、ファイルあたり 256 GB (262,144 MB) までの初期 tempdb ファイル サイズを指定できるようになりました。

インストール時にtempdbのファイルサイズとして最大で256GBのファイルサイズを指定ができますが、インストール時に大きいファイルサイズを指定した場合、256GBの領域割り当てに時間を要する可能性があります。
インストール時に指定したサイズに拡張するまでに20分以上経過する場合にはタイムアウトが発生します。この場合、SQL Server 2017 のインストールは失敗します。

対処
インストール時には tempdb のファイルサイズを変更せず、インストール後に ALTER DATABASE 文でファイルサイズの変更を行ってください。

use master
go
ALTER DATABASE tempdb modify file (NAME = tempdev, SIZE = xxx MB)
go

[参考情報]
ALTER DATABASE (TRANSACT-SQL) の File および Filegroup オプション
https://docs.microsoft.com/ja-jp/sql/t-sql/statements/alter-database-transact-sql-file-and-filegroup-options
E. ファイルを変更する

※ 本Blogの内容は、2017年11月現在の内容となっております。

ARITHABORT の設定について、既定値や変更方法、設定の確認方法をご紹介します。

ARITHABORT の詳細は、SET ARITHABORT (Transact-SQL) を参照ください。

※内容は、2018 年1月 現在の情報となります。本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

既定値

アプリケーションによって、セッションの既定値が異なります。主なアプリケーションとして、Management Studio と SQLCMDでは違いがあります。

変更方法

サーバーレベル、データベースレベル、セッションレベルでの変更が可能です。

サーバーレベル

データベースレベル

セッションレベル

設定値の確認方法

サーバーレベル、セッションレベルで設定した内容は、次のクエリで確認可能です。

参考情報: SET ARITHABORT (Transact-SQL)

データベースレベルで設定した内容は、次のいずれかのクエリで確認可能です。

参考情報: DATABASEPROPERTYEX (Transact-SQL)   sys.databases (Transact-SQL)

動作検証用サンプル

サンプルとして、データベースレベルで設定変更する場合のスクリプトです。

サンプルスクリプト

SQLCMD での実行例

SQL Server 2017 のインストールに失敗する既知の問題がありますので、ご紹介します。

※ 内容は、2018 年1月 現在の情報となります。本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

※ SQL Server Management Studio 17.4 においても再現することを確認しております。

事象

SQL Server Management Studio 17.3 (以降、SSMS 17.3 とします) がインストールされている環境に、SQL Server 2017 の下記機能をインストールしようとするとインストールが失敗します。

• クライアントツール SDK
• クライアントツールの旧バージョンとの互換性

ログ出力例

セットアップログには、次のようなログが記録されます。

Summary.txt

sql_tools_extensions_Cpu64_1.log

原因

先にインストールされている SSMS 17.3 の影響により、「クライアントツール SDK」 と「クライアント ツールの旧バージョンとの互換性」のインストーラーのパスが本来とは異なるパスで認識されるため、インストーラーが開けないというエラーが発生します。上記のログ出力例では、本来であれば「D:\x64\setup\sql_tools_extensions.msi」が正しいパスですが、「D:\Setup\sql_tools_extensions.msi」を探しに行っています。

対処

SQL Server 2017 のセットアップパッケージのファイル (メディア もしくは ISO) を、ローカルドライブにコピーした上で、SQL Server 2017 をインストールします。これによって、SSMS 17.3 が先にインストールされていたとしても、正常に SQL Server 2017 がインストールできます。

皆さん、こんにちは。 BI Data Platform サポートチームです。
今回は、Microsoft Flow の各利用プランにおける最大実行数についての考え方についてご案内します。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ 各プランによる違い
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

各プランにおける 1 か月あたりの最大実行数については、以下にURLに詳細があります。

Title : プラン | Microsoft Flow
URL : https://japan.flow.microsoft.com/ja-jp/pricing/?currency=JPY

Flow には大きく分けて以下の 4 つのプランがあります。

1. Flow Free
2. Flow for Office 365 and Flow for Dynamic 365
3. Flow プラン 1
4. Flow プラン 2

プランによって、最大実行数について以下の違いがあります。

<最大実行数がユーザーごとで制御されるプラン>
Flow Free : 1 ユーザーあたり 750 回 / 月

<テナント全体の最大実行数をユーザーで共有するプラン>
Flow for Office 365 : 2,000 回 × 所有ライセンス数
Flow プラン 1 : 4,500 回 × 所有ライセンス数
Flow プラン 2 : 15,000 回 × 所有ライセンス数

このように、Flow Free をご利用いただいているユーザーは 1 ユーザーあたり 750 回/月 と最大実行数が固定となりますが、Flow for Office 365 や Flow プラン 1、プラン 2 をご利用のユーザーに関しては、テナントでの最大実行数を各ユーザーで共有します。そのため、Flow を利用する人数によって、記載の最大実行数よりも多い回数を実行可能である場合があります。

テナント全体で共有するプランの場合は、その範囲内であれば 1 ユーザーあたりの制限はなく、2,000 回を超える場合でもご利用いただけることを検証にて確認しています。

例えば、テナントにて Flow for Office 365 のライセンスを 100 所有している場合は、テナント全体の所有ライセンス数が 2,000 (回) × 100 (ライセンス) = 200,000 (回) となりますが、極端な例では 2 人で 100,000 回ずつ使用することも、100 人で 2,000 回ずつ使用することも可能です。運用状況に応じてご検討ください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ プランが混在する場合について
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

テナント内にプランが混在する場合に関しては、以下のとおりとなります。

- Flow Free をご利用のユーザー : 1 ユーザーあたり 750 回/月 となります。
- Flow for Office 365 and Flow for Dynamic 365、Flow プラン 1、Flow プラン 2 をご利用のユーザー : テナント全体の最大実行数を合算し、各ユーザーにて共有します。

例)
- Office 365 Enterprise E3 を 100 ライセンス所有 (Flow for Office 365 が使用可能)
- Flow プラン 2 を 1 ライセンス所有

この場合のテナント全体の 1 か月あたりの Flow の最大実行数は、以下のとおりです。
(2000 [回] × 100 [ライセンス]) + (15000 [回] × 1 [ライセンス]) = 215,000 (回)

しかしながら、1 ユーザーライセンスあたりの、最大実行頻度については以下のとおりとなります。

[Microsoft Flow for Office 365 のライセンスが付与されているユーザー (この例の場合、最大 100 名)]
1 ユーザーライセンスあたりの最大実行頻度 5 分

[Flow プラン 2 のライセンスが付与されているユーザー (この例の場合、最大 1 名)]
1 ユーザーライセンスあたり、最大実行頻度 1 分

以上から、ユーザーにどのライセンスを付与するかによって、最大実行頻度に違いが出ることにご留意の上、ユーザーへのライセンス付与をご確認、ご計画いただきますようお願い申し上げます。

また、フロー作成時にプランの選択はできず、ユーザーに付与されたライセンスに従い実行されます。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ テナント全体での最大実行数のご確認方法
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

テナント全体での最大実行数と実行回数については、Flow の管理センターより以下の手順でご確認いただくことが可能です。

--------
確認手順
--------

1. 管理者アカウントにて、Flow にアクセスします。

2. Flow ポータルにて、画面上部ナビゲーション バー上の [設定(歯車アイコン)] - [管理センター] をクリックします。

3. 画面左カラムの [テナント] - [クォータ] をクリックします。

4. 当月分のフローの実行回数を確認します。

5. 画面右の [フロー実行の総数] をクリックすると、[クォータの詳細] として、各ライセンスに紐づいた実行回数を確認できます。

※ フローの総数の算出に関しては、所有しているライセンス数に基づきますため、明示的なユーザーへの付与の必要はございません。

例) 所有している 100 ライセンスのうち、10 ライセンスのみ付与済みで、90 ライセンスはまだ付与していないという場合でも、Flow for Office 365 プランをご利用の場合は 2000 [回] × 100 [ライセンス] = 200,000 [回] となります。

6. [テナントのすべてのデータを .csv ファイルにダウンロードする] をクリックしていただくことで、各 Flow について以下の情報が CSV ファイルとしてダウンロードできます。

<CSV ファイルとしてダウンロードできる情報>

- 名前
- 所有者
- 環境
- 環境 ID
- 状態
- 使用された実行数

実行数がどのようにカウントされているかについては、以下の公開情報をご参照ください。

Title : 課金と使用状況の測定に関する質問
URL : https://flow.microsoft.com/ja-jp/documentation/billing-questions/

--引用開始-----------------------------------------
実行と見なされるものを教えてください
自動トリガーによるか手動での開始かにかかわらず、フローはトリガーされるたびに、1 つの実行と見なされます。
--引用終了-----------------------------------------

※ 本 Blog の内容は、2018 年 1 月現在の内容となっております。

皆さん、こんにちは。 BI Data Platform サポートチームです。
今回は、読み取りスケール可用性グループをお使いいただく際の注意点についてご紹介します。

■構成手順について

読み取りスケール可用性グループについては下記の公開情報に解説があります。

読み取りスケール可用性グループ

現時点では具体的な構築または管理手順につきましては Linux を対象にした下記の公開情報のみとなっておりますが、本手順につきましては、Windows にも適用いただける手順です。

SQL Server on Linux の読み取りのスケールの可用性グループを構成します

※必要に応じて、Linux のコマンドを Windows のコマンドへ置き換える必要があります。

■フェールオーバーについて

読み取りスケール可用性グループのフェールオーバーについては下記の公開情報に記載されています。

読み取りスケール可用性グループのプライマリ レプリカをフェールオーバーする

読み取りスケール可用性グループは、読み取り専用データベースを作成することで、書き込みと読み込みのデータベースを分離し、負荷を分散させることが目的であり、高可用性を目的とした機能ではありません。
そのため、高可用性を目的とした可用性グループと異なり自動的なロールの管理は無く、プライマリー/セカンダリーの各ロールの切り替え（手動フェールオーバー）は、管理者の判断により手動で行う必要があります。

ロールを手動で明示的に切り変える必要があることは、何らかの障害回復を目的として非計画的に手動フェールオーバーを実施するときも、計画的に手動フェールオーバーを実施するときも同様になります。
上記の公開情報の 読み取りスケール可用性グループのプライマリ レプリカをフェールオーバーする  の「データを失わずに手動フェールオーバー」の項に記載がありますように、プライマリーをセカンダリーに降格させた後に、元のセカンダリーを新しいプライマリーに昇格させるという手順が必要です。

また、プライマリー側のノードがサーバー故障によりダウンした場合、必要に応じて上記の公開情報の「データの損失の強制手動フェールオーバー」を行うことになります。
強制フェールオーバーの手順には明記されておりませんが、この場合、前述の通り元のプライマリーが起動してくるときにも自動でロールの変更（セカンダリへの降格）が行われません。
そのため、一時的に両方のノードがプライマリーとして動作し更新可能な状態になります。

この場合は、管理者は、アプリケーションからのアクセスを停止するなどの運用にて元プライマリーでの更新が行われないようにし、データロスが発生しないようにする必要があります。
そして、元プライマリーが起動後、管理者が明示的に元プライマリーをセカンダリーに降格してから、同期を再開する必要があります。

なお、両方のノードがプライマリーとして更新可能な状態で動作している間、セカンダリーに降格したノードで更新された情報は、同期の一環としてロールバックされ、失われることになります。繰り返しとなりますが、データロスが発生しないようにロールの管理にご注意ください。

※ 本Blogの内容は、2018年1月現在の内容となっております。

This is a temporary post that was not deleted. Please delete this manually. (8b5fc52b-1e82-48a4-9cb1-4d52cd836072 - 3bfe001a-32de-4114-a6b4-4005b770f6d7)

みなさん、こんにちは。 BI Data Platform サポートチームの川瀬です。

Machine Learning Studio は Azure サブスクリプションが不要な Free プランと Azure サブスクリプションが必要な Standerd プランがございますが、 今回は主に Azure サブスクリプションをお持ちの Standerd プランをご利用のお客様を対象に、 Machine Learning Studio ワークスペースの管理アカウントについて案内します。

■ Machine Learning Studio ワークスペースの管理アカウントとAzure ポータル上の [アクセス制御（IAM）] について

Azure のリソースは ポータル上の [アクセス制御（IAM）] にて、管理アカウントの管理が可能となっておりますが、Machine Learning Studio ワークスペースの管理アカウントは、Azure ポータルの [アクセス制御（IAM）]  とは連動しておらず、個別で管理されています。

<Machine Learning Studio の管理者アカウント確認画面>

＜Azure ポータルでの [アクセス制御（IAM）]  画面＞

＜ご参考情報＞

ロールベースのアクセス制御を使用して Azure サブスクリプション リソースへのアクセスを管理する

https://docs.microsoft.com/ja-jp/azure/active-directory/role-based-access-control-configure

＃アクセス制御（IAM）についての公開ドキュメントとなります。

具体的には、 Machine Learning Studio ワークスペースを作成した管理アカウントは、ワークスペースの 所有者 として自動的に追加されますが、 それ以外の例えば Azure サブスクリプションの 「所有者」 や「共同作成者」 は自動的に追加されません。

そのため、そのままの状態では、Machine Learning Studio ワークスペースを作成したアカウントだけが 所有者の 権限をもち、それ以外のアカウントでは作成された Machine Learning Studio ワークスペース へのアクセスや操作をすることができません。

Machine Learning Studio ワークスペースを作成者以外のアカウンントで操作、管理されたい場合は Machine Learning Studioから[ワークスペースの共有] 機能にて、ご指定のアカウントに対して共有設定を行っていただく必要がございます。

Machine Learning Studio  からの [ワークスペースの共有] 方法については、こちらの公開ドキュメントにて、画像つきでご案内しておりますので、ここでは割愛いたします。

＜ご参考情報＞

Azure Machine Learning Studio Studio ワークスペースの作成と共有

https://docs.microsoft.com/ja-jp/azure/machine-learning/studio/create-workspace

＃「Azure Machine Learning Studio ワークスペースの共有] の項目をご参照ください

■Machine Learning Studio ワークスペースの管理アカウントと IAM の管理アカウントができること

Machine Learning Studio ワークスペースの管理アカウントと IAM の管理アカウントで可能なことを以下にご案内します。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Machine Learning Studio ワークスペースの管理アカウントができること
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Machine Learning Studio ワークスペースの管理アカウントには、以下の 2 つの種別があり、

それぞれでできることが異なります。

・ユーザー ：ワークスペース内の実験やデータセットの作成、表示、変更、削除を行うことができます。
・所有者 ： ワークスペース ユーザーの招待と削除、ユーザーが実行できる操作の登録を行うことができます。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Azure サブスクリプションの 「所有者」アカウントができること
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

・ワークスペースの作成：作成したワークスペースの管理者アカウントに自動的に登録されます。

・ワークスペースの削除：削除対象のワークスペースの所有者アカウントでなくても削除が可能です。

■なぜ、個別の管理となっているのか

Machine Learning Studio ワークスペースの管理アカウントは、Azure ポータルの [アクセス制御（IAM）] と連動されておらず、 個別で管理されている理由としては、Machine Learning Studio のポータルと Azure ポータルが現時点で統合されていないことが理由として挙げられます。

2018年2月の時点では、統合予定についての詳細は未定となっておりますが、ご案内できる情報が得られましたら当ブログにてご紹介させていただきますので、時々覗きに来ていただけると幸いです。

皆さん、こんにちは。 BI Data Platform サポートチームです。

今回は、Linux 版 クライアントツール (sqlcmd, bcp) で使用できないオプションについて紹介します。

SQL Server 2017 on Linux  では、SQL Server 2017 on Windows と同様に、クライアント ツール (sqlcmd, bcp) をインストールし、使用することが可能です。

     Sqlcmd および bcp、SQL Server コマンド ライン ツールを Linux にインストールします。

しかしながら、Windows 版の クライアント ツール (sqlcmd, bcp) では使用可能なオプションも、Linux 版の クライアント ツール (sqlcmd, bcp) では使用できないオプションが存在します。

各クライアントツールで使用できないオプションの詳細については、以下の公開情報で公開しています。

sqlcmd による接続  (利用できないオプション 参照)

bcp による接続  (利用できないオプション 参照)

※ 本Blogの内容は、2018年2月現在の内容となっております。

SQL Server Management Studio GUI を使用してディストリビューションを構成しようとした時に次のエラーが発生することがあります。

このエラーは、大文字小文字を区別する照合順序 (名前に CS, BIN, BIN2 を含む照合順序) がサーバー照合順序 (master データベースの照合順序) として設定されており、かつ、sys.servers カタログビューに登録されているローカルサーバ名が小文字を含む場合に発生します。

対処方法

sys.servers に登録されているローカルサーバー名を大文字に統一します。その後、ディストリビューションの構成を含むレプリケーションの構成を行います。

適用対象

20018/2/15 時点

SQL Server 2008 : 該当
SQL Server 2008 R2 : 該当
SQL Server 2012 : 未確認
SQL Server 2014 : 未確認
SQL Server 2016 : 該当
SQL Server 2017 : 未確認

高原 伸城

Support Escalation Engineer

皆さん、こんにちは。 BI Data Platform サポートチームの 高原 です。

今回は、Azure 仮想マシン上にインストールする SQL Server のライセンスに関するお問い合わせ窓口 を紹介します。

Azure 仮想マシン上にインストールする SQL Server のライセンスに関するお問い合わせを 技術サポート窓口 にお問い合わせをいただくことがありますが、ライセンスに関するお問い合わせを承る専門の窓口があります。

Azure 仮想マシン上にインストールする SQL Server のライセンスに関する内容については、Clould Direct にお問い合わせ下さい。

Cloud Direct

https://www.microsoft.com/ja-jp/cloud-platform/Cloud-Direct

[参考情報]

既存の SQL Server ライセンスを使用し、Azure 仮想マシン上に SQL Server をインストールするためには。

[FAQ] Azure 管理ポータルのギャラリーからデプロイした Azure 仮想マシン上の SQL Server に対する構成変更 について

※ 本Blogの内容は、2018年2月現在の内容となっております。

高原 伸城

Support Escalation Engineer

皆さん、こんにちは。 BI Data Platform サポートチームの 高原 です。

今回は、元号／和暦 の変更に伴う SQL Server、Azure SQL Database、SQL Data Warehouse への影響について紹介します。

上記の表の通り、元号／和暦 の変更に伴い、SQL Server、Azure SQL Database、SQL Data Warehouse に影響をおよぼすことはありません。

SQL Server には元号／和暦という概念がなく、また、元号／和暦を格納するための特別なデータ型 及び 元号／和暦に関する関数も存在しません。

そのため、SQL Server、Azure SQL Database、SQL Data Warehouse に影響はありません。

※ 本Blogの内容は、2018年2月現在の内容となっております。

みなさん、こんにちは。 BI Data Platform サポートチームの川瀬です。

こちらの記事では、Cosmos DB のアカウント名の命名規則についてご案内いたします。

■ Cosmos DB のアカウント名の命名規則

使用可能な文字列：小文字、数字

長さ：3 から 31文字

Cosmos DB の命名規則は上記の通りです。

使用可能な文字列が他の Azure リソースに比べて限られていることにご注意ください。

<2018/03/20 時点の補足情報>

また、Azure ポータル上では、使用できない文字列を Cosmos DB のアカウントとして入力した時に、以下のようなメッセージが表示されますが、”-" （ハイフン）はご利用いただけませんので、ご注意ください。

上記の Azure ポータルの表示につきましては、ご利用いただくお客様の混乱の元となりますので、現在上記メッセージから”-"（ハイフン）の表示を削除するように、サポートセンターから米国の担当部署に依頼中の状況です。

修正まで今しばらくお待ちください。

神谷 雅紀
Escalation Engineer

SQL Server データベースエンジンプロセス (プロセス名 sqlservr.exe) のプロセスダンプを採取する方法です。SQL Server 製品に付属の sqldumper.exe を使用することで、デバッガ等を追加インストールすることなく、かつ、データベースのデータを含まない形のダンプの採取が可能です。

手順1

How to use Powershell script to generate a dump file の Code details をクリックし、Powershell ソースコードをファイル名  SQLDumpHelper.ps1 ファイルとして、プロセスダンプ採取の対象となるSQL Serverが実行されているサーバーに保存します。

How to use the Sqldumper.exe utility to generate a dump file in SQL Server
https://support.microsoft.com/en-us/help/917825/how-to-use-the-sqldumper-exe-utility-to-generate-a-dump-file-in-sql-se

手順2

Windows キー + Q を押下し、Windows Powershell と入力します。検索結果の中の Windows Powershell を右クリックし、「管理者として実行」(Run as administrator) をクリックします。

手順3

Powershell コンソールで cd コマンドにより SQLDumpHelper.ps1 を保存したフォルダーに移動します。

例: C:\temp\SQLDumpHelper.ps1 として保存した場合
cd C:\temp

手順4

Powershell コンソールに .\SQLDumpHelper.ps1 と入力し、Enter を押下します。

手順5

プロセスダンプ採取対象の SQL Server プロセスの PID を入力します。

手順6

採取するダンプのタイプを入力します。各ダンプに含まれるメモリ領域やファイルの目安は以下の通りです。

※ 採取時間やファイルサイズはあくまでも目安です。書き出し先のディスク性能や書き出すデータ量 (メモリサイズ) などに依存して大きく変動します。

手順7

出力先フォルダーを指定します。

手順8

複数回採取する場合は、Y を入力後、採取回数と採取間隔を指定します。

正常にダンプが生成されると、コンソールに生成されたダンプファイルのファイル名が表示され、ダンプファイル SQLDmprNNNN.mdmp (NNNN は数字) とログファイル SQLDUMPER_ERRORLOG.log が手順 7 で指定したフォルダーに生成さています。

高原 伸城

Support Escalation Engineer

皆さん、こんにちは。 BI Data Platform サポートチームの 高原 です。

今回は、SQL Server プロダクトキーの変更手順について紹介します。

SQL Server をインストールする際、プロダクト キー (Product Key) の入力画面より、プロダクト キーを入力する必要があります。

しかしながら、SQL Server のインストールが完了後、別の環境に使用する予定の プロダクト キー を誤って使用してしまったなど、プロダクト キーを変更したい状況があるかもしれません。

SQL Server では、同じエディション (例えば SQL Server 2017 Standard Edition から SQL Server 2017 Standard Edition など)  へのエディションのアップグレードが可能です。

そのため、エディションのアップグレードを実施することで、プロダクト キーを変更することが出来ます。

エディション アップグレードの詳細な手順は、以下の公開情報を参照ください。

SQL Server の別のエディションへのアップグレード (セットアップ)

[補足]

既存の環境でどの プロダクト キーが使用されて SQL Server がインストールされているかを確認する方法はありません。そのため、誤ったプロダクト キーが使用されている可能性が疑われる際には、エディションのアップグレードを実施することを検討ください。一般的に、エディションのアップグレードではSQL Server 内部で保持されているエディションの情報を更新するのみとなるため、処理に時間を要することはありません。

ボリューム ライセンスの管理者の場合、VLSC (Volume Licensing Service Center) サイト にサインインすることで、使用可能なプロダクトキー情報を参照できます。

[参考情報]

サポートされるバージョンとエディションのアップグレード

SQL Server 2016 の各エディションとサポートされている機能

sys.dm_db_persisted_sku_features (Transact-SQL)

※ 本Blogの内容は、2018年4月現在の内容となっております。

高原 伸城

Support Escalation Engineer

皆さん、こんにちは。 BI Data Platform サポートチームの 高原 です。

今回は、Azure Database for MySQL でよくある質問事項について紹介します。

Q1)  2018年4月に GA (General Availability) となったが、Preview 期間に作成したデータベースに対して、何らかのアップデート作業は必要となるか？

A1)  Preview 期間に作成したデータベースは、特にアップデート作業を実施することなく、そのまま使用することが可能です。

Q2)  手動で フェールオーバー を実施することは可能か？

A2) 出来ません。しかしながら、Azure Database for MySQL のデータベースが配置されたノードで何らかの障害が検知された場合、自動的にフェールオーバーが行われます。

Azure Database for MySQL での高可用性の概念

+ 高可用性

Q3)  Azure 仮想マシン上から、仮想ネットワーク サービスのエンドポイント経由で、接続することは可能か？

A3) 現時点において、仮想ネットワーク サービスのエンドポイント経由で Azure Database for MySQL に接続することは出来ません。

仮想ネットワーク サービスのエンドポイント

※ 本Blogの内容は、2018年4月現在の内容となっております。

高原 伸城

Support Escalation Engineer

皆さん、こんにちは。 BI Data Platform サポートチームの 高原 です。

今回は、Azure Database for PostgreSQL でよくある質問事項について紹介します。

Q1)  2018年4月に GA (General Availability) となったが、Preview 期間に作成したデータベースに対して、何らかのアップデート作業は必要となるか？

A1)  Preview 期間に作成したデータベースは、特にアップデート作業を実施することなく、そのまま使用することが可能です。

Q2)  手動で フェールオーバー を実施することは可能か？

A2) 出来ません。しかしながら、Azure Database for PostgreSQL のデータベースが配置されたノードで何らかの障害が検知された場合、自動的にフェールオーバーが行われます。

Azure Database for PostgreSQL での高可用性の概念

+ 高可用性

Q3)  Azure 仮想マシン上から、仮想ネットワーク サービスのエンドポイント経由で、接続することは可能か？

A3) 現時点において、仮想ネットワーク サービスのエンドポイント経由で Azure Database for PostgreSQL に接続することは出来ません。

仮想ネットワーク サービスのエンドポイント

※ 本Blogの内容は、2018年4月現在の内容となっております。

高原 伸城

Support Escalation Engineer

皆さん、こんにちは。 BI Data Platform サポートチームの 高原 です。

今回は、Azure SQL Database でよくある質問事項について紹介します。

Q1)  アプリケーション から Azure SQL Database への接続が数十秒間行えない現象が発生したが、データセンター側で何らかの問題が発生していたのか知りたい。

A1) 長期間(数分間)、継続的にアプリケーション から Azure SQL Database への接続が行えない状況が発生していない限り、データセンター側の問題ではありません。 Azure SQL Database では 高可用性を維持するため、定期的に リコンフィグレーション (Reconfiguration) を行っており、リコンフィグレーションの間、数十秒間、一時的に アプリケーション から Azure SQL Database への接続が行えない状況が発生する可能性があります。 詳細は、以下の公開情報を参照。

[SQL Database] Reconfiguration (リコンフィグレーション) は悪ではない。

Q2)  Azure SQL Database を使用したシステムを構築するうえで、何か考慮すべき内容があれば知りたい。

Q2) Azure SQL Database では、高可用性を維持するため、定期的に リコンフィグレーション (Reconfiguration) が実行されたり、また、ネットワークの問題により アプリケーション から Azure SQL Database へ確立されている接続が遮断される可能性があるため、アプリケーション側でリトライロジックを実装することを推奨しています。詳細は、以下の公開情報を参照。

[SQL Database] アプリケーション作成における推奨事項について (Microsoft Azure SQL Database)

SQL Database アプリケーションの開発の概要

Q3)  アプリケーション から Azure SQL Database への接続が、接続タイムアウトで失敗する現象を改善する方法を知りたい。

Q3) Azure SQL Database へ接続するアプリケーション側で接続タイムアウト値を延ばすことにより、接続タイムアウトが発生する現象を軽減させることができます。詳細は、以下の公開情報を参照。

[SQL Database] 接続タイムアウトの発生を改善したい

Q4)  Azure SQL Database の DTU が 100 % 近い値を推移し、クエリがコマンドタイムアウトで失敗する現象を改善する方法について知りたい。

Q4) アプリケーション側でコマンドタイムアウト値を延ばす、インデックスの統計情報を更新する、強制的に実行プランをリコンパイルする、もしくは、使用しているデータベースの DTU (価格レベル) を変更するなどの方法が一般的に有効です。詳細は、以下の公開情報を参照。

Microsoft Azure SQL Database パフォーマンス チューニング (第１回)

[Azure SQL Database] DTU使用率が100％になった時にやるべき事

Azure SQL Databaseの適切な価格レベル(DTU)を選択する指標について

Q5)  Azure SQL Database サーバー名 (******.database.windows.net) に紐づく ゲートウェイ IP アドレス は変更される可能性があるか、また、固定化する方法は存在するか知りたい。

Q5) ゲートウェイ IP アドレス は変更される可能性がありますが、頻繁に変更されることはありません。また、仮に変更されたとしても、管理者宛にメールで通知が行われます。残念ながら ゲートウェイ IP アドレスを固定化することは出来ません。なお、現在 ゲートウェイ として使用されている IP アドレス、および、データセンターで使用される IP アドレスの範囲については公開されています。詳細は、以下の公開情報を参照。

Azure SQL Database ゲートウェイ IP アドレス

Microsoft Azure Datacenter IP Ranges

Q6) アプリケーションからAzure SQL Database への確立された接続すべてを強制的にクローズさせる方法があれば知りたい。

Q6) データベースの DTU (価格レベル) が変更されるタイミングで、対象となっているデータベースに接続しているセッションがすべてクローズされます。 そのため、アプリケーションが接続しているデータベースの DTU (価格レベル) を変更することで、アプリケーションから確立されている接続をすべて強制的にクローズさせることが可能です。

※ 本Blogの内容は、2018年4月 現在の内容となっております。