Quantcast
Channel: Microsoft SQL Server Japan Support Team Blog
Viewing all 293 articles
Browse latest View live

FAQ: TOP に指定した数よりも結果が少ない場合にクエリの実行時間が長くなる

$
0
0


神谷 雅紀
Escalation Engineer


質問

TOP n を指定したクエリを実行した場合、WHERE 句に指定される条件によってクエリの結果行数は変わるが、結果が n 行の場合 (つまり、条件に該当する行が n 行以上ある場合) に比べて、n 行未満の場合には実行時間が長くなります。なぜですか?


クエリ条件を満たす行が TOP に指定されている行数未満の場合に実行時間が長くなる理由

クエリ条件を満たす行が TOP に指定されている行数未満である場合には、クエリ条件に該当するすべての行が処理対象になります。一方、クエリ条件に該当する行が TOP に指定されている行数以上ある場合には、クエリ条件に該当する行すべてを処理する必要はなく、TOP に指定されている行数分の結果が得られた時点で処理は終了します。そのため、結果行数が TOP に指定されている行数未満である場合は、TOP に指定されている行数以上の場合よりも実行時間が長くなります。

実際には、クエリ条件を満たす行が TOP に指定されている行数未満である場合に遅いのではなく、TOP に指定されている行数以上ある場合に処理が速いのであり、それが TOP が導入された目的です。


image


2017 年 8月 SQL Server 最新モジュール

$
0
0

2017 年 8月 9日 時点の SQL Server 最新モジュールです。

SQL Server 2005 は 2016 年 4 月 12 日に延長サポートが終了しました。長らくのご愛用ありがとうございました。

SQL Server 2008 は 2014 年 7 月 8 日にメインストリームサポートが終了しました。

サービス

パック

更新プログラム

バージョン

リリース年月

SQL Server 2016

SP1

KB 4024305 (CU4)

13.0.4446.0

2017/8

メインストリームサポート

SQL Server 2014

SP2

KB 4019094 (CU6)

12.0.5553.0

2017/8

メインストリームサポート

SQL Server 2012

SP3

KB 4025925 (CU10)

11.0.6607.3

2017/8

延長サポート

※2017年7月11日にメインストリームサポートが終了しました。

SQL Server 2008 R2

SP3

KB 3135244

10.50.6537.0

2014/9

延長サポート

※2014年7月8日にメインストリームサポートが終了しました。

SQL Server 2008

SP4

KB 3135244

10.0.6547.0

2014/10

延長サポート

※2014年7月8日にメインストリームサポートが終了しました。


RTM : Release To Manufacturing (製品出荷版)

SP : Service Pack (サービスパック)

CU : Cumulative Update (隔月リリースの累積更新プログラム)

OD : On-Demand (オンデマンドリリースの累積更新プログラム)

SQL Server の更新プログラムの詳細については、SQL Server の更新プログラムを参照して下さい。

メインストリームサポート、延長サポートについては、マイクロソフトサポートライフサイクルを参照して下さい。

[FAQ] Azure 管理ポータルのギャラリーからデプロイした Azure 仮想マシン上の SQL Server の構成変更 (ディスク拡張) について

$
0
0

 

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

今回は、Azure 管理ポータルのギャラリーからデプロイした Azure 仮想マシン上の SQL Server の構成変更 (ディスク拡張) について紹介します。

 

Azure 管理ポータルのギャラリーから 以下のイメージを選択し、デプロイした場合、以下の構成でインストールが行われます。

 

SQL Server 2012 SP3 Standard on Windows Server 2012 R2

SQL Server 2012 SP3 Enterprise on Windows Server 2012 R2

SQL Server 2014 SP2 Enterprise on Windows Server 2012 R2

SQL Server 2014 SP2 Enterprise on Windows Server 2012 R2

SQL Server 2016 SP1 Standard on Windows Server 2016

SQL Server 2016 SP1 Enterprise on Windows Server 2016

 

[構成]

SQL Server (英語版)

C ドライブ : SQL Server 関連ファイル、システム データベース

D ドライブ : テンポラリ ストレージ

F ドライブ : ユーザー データベース

 

よくお問い合わせのある質問事項を以下に記載します。

 

Q1) SQL Server (英語版) を SQL Server (日本語版) に変更することが出来るか?

A1) 可能です。 詳細は以下の ブログを参照。

 

Azure 仮想マシン上に作成した SQL Server の日本語化手順(SQL Server 2012 , 2014 対応手順)

Azure 仮想マシン上に作成した SQL Server の日本語化手順(SQL Server 2016 対応手順 )

 

Q2) 既に保持している SQL Server ライセンスを Azure 仮想マシン上の SQL Server に使用することが出来るか?

A2) 可能です。 しかしながら、ソフトウェア アシュアランス (Software Assurance) の契約が必要です。 また、Azure 管理ポータルのギャラリーから “{BYOL}” (ライセンスを持ち込む) が付いたイメージを使用して仮想マシンをデプロイする必要があります。 詳細は以下の ブログを参照。

 

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

SQL Server Azure VM の料金ガイダンス

 

# “{BYOL}” が付いた Azure 仮想マシン イメージ (抜粋)

{BYOL} SQL Server 2012 SP3 Standard on Windows Server 2012 R2

{BYOL} SQL Server 2012 SP3 Enterprise on Windows Server 2012 R2

{BYOL} SQL Server 2014 SP2 Enterprise on Windows Server 2012 R2

{BYOL} SQL Server 2014 SP2 Enterprise on Windows Server 2012 R2

{BYOL} SQL Server 2016 SP1 Standard on Windows Server 2016

{BYOL} SQL Server 2016 SP1 Enterprise on Windows Server 2016

 

Q3) 既に Azure 管理ポータルのギャラリーからデプロイした仮想マシンを、”BYOL” (ライセンスを持ち込む) に変更し、SQL Server ライセンスの課金を止めることが出来るか?

A3) 現時点において出来ません。 そのため、Azure 管理ポータルのギャラリーから “{BYOL}” (ライセンスを持ち込む) が付いたイメージを使用して仮想マシンをデプロイ後、既存の環境からデータを移行する必要があります。

 

Q4) Azure 管理ポータルのギャラリーからデプロイした仮想マシンの C ドライブを拡張することが出来るか?

A4) SQL Server 2016 のイメージのみ、C ドライブを拡張することが可能です。 SQL Server 2012 及び 2014 のイメージの場合、C ドライブを拡張することは出来ません。

 

Q5) Azure 管理ポータルのギャラリーからデプロイした仮想マシンの C ドライブに、データベース物理ファイル (.mdf/.ldf) を配置することが出来るか?

A5) 可能です。 しかしながら、仮想マシンの C ドライブには OS 関連のファイルが配置されているため、OS 動作のために最適化されています。そのため、C ドライブにデータベース物理ファイルを配置し、大量の ディスク I/O が発生することで、SQL Server 全体の処理が遅延したり、OS の処理が遅延するなどの影響を及ぼす可能性があり、弊社としては推奨していない構成となります。

 

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

Azure 仮想マシン上で SQL Server AlwaysOn 可用性グループを構築する場合の推奨事項

$
0
0

 

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

今回は、Azure 仮想マシン上で SQL Server AlwaysOn 可用性グループを構築する場合の推奨事項について紹介します。

 

Azure 仮想マシンをホストしているホスト仮想マシンでは定期的にメンテナンス作業が実施されており、ホスト仮想マシンの完全な再起動を必要としないメカニズムを使用してメンテナンス作業が行われています。

しかしながら、上記の作業の際、Azure 仮想マシンは 数十秒 から 30秒程度、一時停止状態になります。

そのため、Azure 仮想マシンの一時停止状態時間よりも、フェールオーバー クラスターの監視間隔が短い場合、フェールオーバーが発生する可能性があります。

この様な Azure プラットフォーム特有の動作に対応するため、フェールオーバークラスター、SQL Server 、さらに、アプリケーションクライアントにおけるタイムアウト値の延長をお勧めしています。

 

[推奨設定]

1) フェールオーバー クラスターのハートビート設定 (クラスタ側の設定)

SameSubnetDelay (単位:ミリ秒) * SameSubnetThreshold (単位:回数) が、30000 ミリ秒 (30 秒) 以上に設定する。

 

[例]

SameSubnetDelay = 1000

SameSubnetThreshold = 30

 

Azure 上でフェールオーバークラスターを構築する際の留意事項について

+ ハートビートの閾値の変更手順 参照

 

[機能] : クラスターサービス間の死活監視。既定値 5 秒。

[影響] : 時間内に応答がないと、応答がなかったノードはクラスターから除外され、除外されるノードがアクティブであった場合、フェールオーバーが発生する。

 

 

2) LeaseTimeout  設定 (SQL Server AlwaysOn 可用性グループ 側の設定)

LeaseTimeout 値を 30000 ミリ秒 (30 秒) 以上に設定する。

 

Lease Timeout の閾値の変更手順
----------------------------------
1) フェールオーバー クラスター マネージャーを起動します。
2) 左ペインのツリーから対象のクラスタ内の [役割] を選択します。
3) 右ペインに表示された役割の一覧から、対象の可用性グループの役割を選択します。
4) 右ペイン下の [リソース] タブを開きますs。
5) [その他のリソース] として対象の可用性グループのリソースが存在しますので、右クリックで [プロパティ] を開きます。
6) [プロパティ] 画面内 でさらに [プロパティ] タブを開き、[LeaseTimeout] の値をミリ秒単位で指定します。
7) [OK] ボタンを押下し適用します。
8) リソースを一旦オフラインにした後オンラインにし、変更を反映させます。(可用性グループがオフライン中には、データベースにアクセスできなくなります)
※LeaseTimeout の既定値は、20,000 ミリ秒(20秒)であり、最大値は 100000 ミリ秒(100秒)です。

[補足]

Lease Timeout の閾値を変更した場合、HealthCheckTimeout の閾値も変更ください。

また、HealthCheckTimeout の閾値は、Lease Timeout の閾値よりも大きな値を指定ください。

※ HealthCheckTimeout の既定値は、30,000ミリ秒(30秒)であり、最大値は 4294967295 ミリ秒です。

 

柔軟な自動フェールオーバーポリシー - 可用性グループ

+ 正常性チェックのタイムアウトしきい値 (HealthCheckTimeout)

 

[機能] : 同一ノードのクラスターサービスと SQL Server が、「リース」と呼ばれるオブジェクトを更新する。リースが更新されれば、相手は正常、時間内に更新されなければ間は異常と判断。既定 20 秒。

[影響] : SQL Server が時間内にリースの更新が行われないと、クラスタリソース DLL は SQL Server を失敗と見なすため、クラスターにより再起動もしくはフェールオーバーが発生する。

クラスター (リソース DLL) が時間内にリースの更新を行わないと、SQL Server はスプリットブレインの可能性があるとみなし、データベースへの更新を行わせないようにする。

 

 

3) 接続タイムアウト値 (アプリケーション 側の設定)

アプリケーションで使用しているインタフェース (ODBC, System.Data.SqlClient など) の接続文字列やプロパティで、接続タイムアウト値を 30 秒以上に設定します。


[機能] : クライアントアプリケーションが SQL Server へ接続する際に、接続完了までに許容される時間。

[影響] : タイムアウトすると、SQL Server に接続できない。

 

SqlConnection.ConnectionTimeout プロパティ

接続文字列 (Entity Framework)

 

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

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

$
0
0

 

Microsoft SQL Server/Microsoft Azure SQL Database サポート

田中 真人

皆さん、こんにちは。 Microsoft SQL Server/Microsoft Azure SQL Database サポートチーム です。 日ごろから、Azure サービスをご愛顧頂き誠にありがとうございます。

今回は、日々のサポート業務において、比較的お問合せをいただくSQL Database の適切な価格レベル(DTU)を選択する指標について記載致します。

 

初めに、DTUとは何かについて記載します。既に DTU についてご存知の方は「2)適切なDTUを選択する指標」へ飛んで下さい。

 

+++++++++++++++++++++++++++++++++++++++++++

1)DTUとは

+++++++++++++++++++++++++++++++++++++++++++

DTUとは、SQL Database のデータベースの処理性能を表す単位であり、SQL Databaseにおける各サービスレベルの性能を表す為の指標の1つです。

DTUはベンチマークテストにより、弊社が独自で決めており、具体的には、各サービスレベルのCPU、メモリ、およびディスクの読み書きを組み合わせた測定に基づいて算出しております。

DTUの概要の詳細は以下サイトをご確認ください。

 

■SQL Database のオプションとパフォーマンス: 各サービス階層で使用できる内容について理解します

https://azure.microsoft.com/ja-jp/documentation/articles/sql-database-service-tiers/

--サイト内抜粋 ここから—

DTU について

データベース トランザクション ユニット (DTU) は、データベースのトランザクションという実際の測定に基づいたデータベースの相対的な能力を表す SQL Database の測定単位です。

ここでは、完全搭載条件で、オンライン トランザクション処理 (OLTP) 要求に一般的な一連の操作を実行し、1 秒間に完了可能なトランザクション数を測定しました (詳細については、「ベンチマークの概要」を参照してください)。

たとえば、DTU が 1750 である Premium P11 データベースは、DTU が 5 である Basic データベースと比べ、DTU 換算で 350 倍の計算能力を持ちます。

--サイト内抜粋 ここまで--

 

また、SQL Databaseのベンチマークテストの概要は以下サイトをご確認くださだい。

 

■Azure SQL Database ベンチマークの概要

https://azure.microsoft.com/ja-jp/documentation/articles/sql-database-benchmark-overview/

 

 

+++++++++++++++++++++++++++++++++++++++++++

2)適切なDTUを選択する指標

+++++++++++++++++++++++++++++++++++++++++++

適切な価格レベル(DTU)を選択する方法につきまして、以下3つの観点から記載します。

 

-----------------------------------------------------------------------------------------------------

2-1)新規でSQL Databaseをデプロイした際に、適切な価格レベル(DTU)を選択する指標

2-2)オンプレミスの環境から、SQL Databaseへ移行する際の、適切な価格レベル(DTU)を選択する指標

2-3) 既存のSQL Databaseのリソース不足や、取り扱うデータの量が増える見込みがある際の、適切な価格レベル(DTU)を選択する指標

-----------------------------------------------------------------------------------------------------

 

2-1)新規でSQL Databaseをデプロイした時に、適切な価格レベル(DTU)を選択する指標

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SQL Databaseのデータベースを新規で作成する際の適切な価格レベル(DTU)を選択する指標につきまして、以下サイトに詳細な記載があります。

まずは、以下の情報を参照し、用途に合ったサービスレベルをご検討下さい。

 

■Azure SQL Database で利用可能なパフォーマンスオプション

https://azure.microsoft.com/ja-jp/documentation/articles/sql-database-service-tiers/

[サービス階層の選択] の項目をご確認下さい。

--サイト内抜粋 ここから--

Basic 小規模なデータベースに最適です。通常は、一度に 1 つのアクティブな操作をサポートします。たとえば、開発やテスト、使用頻度の低い小規模なアプリケーションなどに使用するデータベースがこれに該当します。

Standard IO パフォーマンス要件が低~中程度のクラウド アプリケーションに適しています。複数の同時クエリをサポートします。たとえば、ワークグループや Web アプリケーションなどです。

Premium IO パフォーマンス要件が高く、トランザクション量が膨大な場合に合わせて設計されています。多数の同時ユーザーをサポートしています。たとえば、ミッション クリティカルなアプリケーションをサポートするデータベースなどです。

Premium RS 最高レベルの可用性の保証を必要としない I/O 集中型のワークロード向けに設計されています。例としては、高パフォーマンス ワークロードまたはデータベースがレコードのシステムではない分析ワークロードのテストが含まれます。

--サイト内抜粋 ここまで--

 

次にサイト内の [単一データベース サービス階層とパフォーマンス レベル] の項目より、「最大データベースサイズ」や「最大同時ログイン数」を確認し、利用用途に合わせたパフォーマンスレベルを選択します。

例えば、Standard S0の場合、最大データベースサイズが250GB、一度にログイン可能な数が60となっております。

これらの制限をを超えるような利用を想定されている場合は、利用用件を満たす上位のレベルで作成する必要があります。

 

サービスレベルやパフォーマンスレベルは、都度変更が可能であるため、上記を指標として、検証環境にて一度作成、検証して頂き、DTU使用率を確認しながら、最適な価格レベル(DTU)を選択して下さい。

選択した価格レベル(DTU)のDTU使用率が100パーセントに近ければ上位の価格レベル(DTU)を選択、逆に低ければ下位の価格レベル(DTU)を選択することを検討してください。

 

DTU使用率の確認方法は、Azure ポータル上から該当のデータベースを選択し、[概要] をクリックします。

概要欄にデフォルトでリソース使用率の表記があります。リソース使用率=DTU使用率です。

 

※状況によっては、[リソース使用率] の部分がDTU percentageに変更される可能性がありますが、以下の画面キャプチャで0パーセントとなっているDTU percentageの箇所を確認します。

clip_image001

 

 

2-2)オンプレミスの環境から、SQL Databaseへ移行する際の、価格レベル(DTU)を選択する指標

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

オンプレミスのSQL ServerからSQL Databaseへ移行する際に、選択する適正な価格レベル(DTU)の指標は、以下サイト内に記載の「Azure SQL Database DTU Calculator 」で確認することが出来ます。

ただし、あくまで指標となるので、十分に検証した後、本番環境にて移行の実施を検討して下さい。

 

■Azure SQL Database DTU Calculator

http://dtucalculator.azurewebsites.net/

 

[Azure SQL Database DTU Calculatorのご利用方法]

a)オンプレミスの環境から、パフォーマンスモニターで、以下パフォーマンスカウンターのパフォーマンスログを取得します。パフォーマンログの取得方法は以下に記載します。

 •Processor - % Processor Time

 •Logical Disk - Disk Reads/sec

 •Logical Disk - Disk Writes/sec

 •Database - Log Bytes Flushed/sec

 

[パフォーマンスカウンターの取得方法] ※パフォーマンスログは1時間の取得をお願い致します。

1)  [コントロール パネル] - [管理ツール] - [パフォーマンスモニター] を起動します。

2) 左ペインの [データコレクタセット] を展開します。

3) [ユーザー定義] を右クリックし、[新規作成] -> [データコレクタセット] を選択します。

4) 名前を指定し、[手動で作成する]を選択した上、[次へ] を押します。

5) [データログを作成する] + [パフォーマンスカウンター] を選択し、[次へ] を押します。

6) 追加を選択します。

7) 以下のパフォーマンスカウンタを追加します。

  •Processor - % Processor Time

  •Logical Disk - Disk Reads/sec

  •Logical Disk - Disk Writes/sec

  •Database - Log Bytes Flushed/sec

 

8) 全てのカウンタを追加した事を確認し、[OK] を押します。

9) サンプルの間隔を 3秒へ設定し、[次へ]を押します。

10) 「ルートディレクトリ」にデータの保存場所を選択し、[次へ] を選択します。

11) [保存して閉じる] を選択し [完了] を押します。

12) 左ペインの [データコレクタセット] -> [ユーザー定義] に作成したデータコレクタセットが表示されます。右クリックから、開始を選択することでカウンタの採取が開始します。

 

※ 右クリックから、停止を選択することでカウンタの採取が停止します。パフォーマンスログは1時間の取得をお願い致します。(開始から1時間後に停止)

 

13) 10) で指定されたフォルダにパーフォーマンスログファイルが作成されている事を確認してください。

 

b)取得したパフォーマンスログをCSV形式へ変換します。CSV形式へ変換する方法は以下に記載します。

1)コマンドプロンプトを開き、以下コマンドを実行します。

 

C:\>relog "既存のパフォーマンスログのフルパス" -o 任意の出力先のフルパス.csv -f CSV

 

例)C:\temp 配下に変換したいパフォーマンスログファイルを配置した場合。

 

C:\>relog "C:\temp\DataCollector01.blg" -o C:\temp\DataCollector01.csv -f CSV

 

■Relog

https://technet.microsoft.com/ja-jp/library/cc771669(v=ws.10).aspx

 

2)任意の出力先に、CSV形式のパフォーマンスログファイルが作成されている事を確認してください。

 

c)上記に記載の「Azure SQL Database DTU Calculator」のサイト内の以下画面キャプチャの欄に、移行元マシンのコア数を入力し、File Uploadの参照ボタンからCSV形式に変換したパフォーマンスログファイルを選択し、「Calculate」ボタンを押下します。

clip_image003

 

d)以下の画面キャプチャのように結果が得られます。この例では、Premium-P1が適正であるという結果が出ています。

clip_image005

 

上記の例の場合、検証環境にてSQL DatabaseをPremium-P1にてデプロイし、実際に運用し、DTU使用率を確認しながら、適切な価格レベル(DTU)を選択してください。

 

 

2-3)既存のSQL Databaseのリソース不足や、取り扱うデータの量が増える見込みがある際の、適切な価格レベル(DTU)を選択する指標

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  

-リソース不足により価格レベル(DTU)の変更が必要なケースにおける適切な価格レベル(DTU)を選択する指標

既存のSQL DatabaseのデータベースのDTU使用率を確認し、100%付近まで達している場合、リソース不足の可能性があります。その場合、まずはひとつ上の価格レベル(DTU)へ変更し、再度DTU使用率を確認します。

適切なDTU使用率は、利用する環境に依存します。例えば、リソース不足によるアプリケーションの停止が一瞬でも発生すると重大な影響を及ぼす場合は、一瞬でもDTU使用率が100%を超えない価格レベル(DTU)を選択する必要があり、

これを明確にするためには、検証環境などで、実際に運用して確かめる必要があります。

 

-既存の環境ではリソース不足は発生していないが、今後取り扱うデータ量などが増え、価格レベル(DTU)の変更が必要なケースにおける適切な 価格レベル(DTU)を選択する指標

既存の環境で取り扱っているご利用方法(データ量など)と、既存の環境のDTU使用率がそのまま指標となります。

例えば、DTUが10(S0)の環境で、DTU使用率が50%の環境のサービスレベルを、DTUが倍の20(S1)のサービスレベルへ変更した場合、利用方法(データ量など)に変更がなければ、DTU使用率は25%になる見込みです。

上記を踏まえて、検証環境にて実際に運用し、適切な価格レベルを選択します。

 

運用している既存のSQL Databaseのデータベースがある場合は、検証環境にて、価格レベル(DTU)を変更しながら適切な価格レベル(DTU)を選択する事が最適な方法となります。

これは、SQL Databaseの強みの一つです。オンプレミスの環境で検証する為には、想定する範囲のCPUやメモリなどのハードを準備するコストがかかります。

SQL Databaseでは、価格レベル(DTU)を変更する事により、分単位で検証環境を構築、解体、構築を繰り返し実施する事ができます。

 

 

≪参考情報≫

Azure サービスを、検証などの為に無料で利用する方法につきまして以下に記載致します。

 

以下サイト内の「無料で始める」より無料アカウントを作成し、20,500円までAzure サービスを利用できます。

 

■無料の Azure アカウントを今すぐ作成しましょう

https://azure.microsoft.com/ja-jp/free/

 

有料サービスに切り替える操作をしない限りご料金は発生しません。

 

■Azure 無料アカウント FAQ

https://azure.microsoft.com/ja-jp/free/free-account-faq/

--サイト内抜粋--

無料アカウントで料金は発生しますか?

いいえ。このアカウントは無料です。さらに、最初の 30 日間利用できる \20,500 クレジットも提供いたします。

30 日経過した後は料金が発生しますか?

いいえ。従量課金制の Azure サブスクリプションの有料サービスに移行しない限り、料金は発生しません。Azure サブスクリプションはいつでもキャンセルすることができます。移行後であっても、無料レベルを提供する多くの Azure サービスを、料金なしで引き続きご利用いただけます。

--ここまで--

 

以上となります。ご参考になれば幸いでございます。今後のとも弊社サポート窓口をどうぞ宜しくお願い致します。

 

 

[イベント告知] 実案件お客様登壇「赤裸々に語ります」 Cognitive, SQL Data Warehouse 無償セミナー開催!9/27 (水)

$
0
0

実際に導入したお客様と、対象テクノロジーに強いパートナー企業が登壇し、「率直なところ Microsoft のソリューションを導入して、何が変わったの?」「本当のところ、導入で何か困ったのでは?」といったさながら異種格闘技戦の赤裸々な内容から語っていただくセミナーを開催します。

 

Microsoft Cognitive Services による「個客 "おもてなし"
AI
ソリューションが開くビジネス機会

日本マイクロソフト株式会社 品川本社 31F SGT:Seminar Room B

16:00-16:30  受付

16:30-16:45 Cognitive Services および Azure Data Services概要紹介: 日本マイクロソフト株式会社

16:45-17:05 店舗内顧客分析「アロバビューコーロ」の紹介:株式会社アロバ 

17:05-17:35 大正元年創業 伊勢の老舗ゑびやによるAI活用事例の紹介:
有限会社 ゑびや 専務取締役 小田島 春樹 

17:35-18:00 まとめ、QA

 

※経営企画の方にも特におすすめです。

個客分析に Cognitive が入った結果ビジネスがどう変わったか?という一見異色ながら、ビジネスの視点で「こう使うのか!」といった利用例を伊勢のゑびや様自らが語ります。

 

登録はこちら! https://aka.ms/ss_cog

 

お客様が何に困って導入を決意したか。そして何が変わったか。SI に携わる皆様にとっても興味深いところではないでしょうか。
内容の性質上、その場だけの内容ですので、録画やリピートはありません。ご質問もいただけます。ぜひ、ご参加ください。

[イベント告知] 実案件お客様登壇「赤裸々に語ります」 Cognitive, SQL Data Warehouse 無償セミナー開催!9/28 (木)

$
0
0

実際に導入したお客様と、対象テクノロジーに強いパートナー企業が登壇し、「率直なところ Microsoft のソリューションを導入して、何が変わったの?」「本当のところ、導入で何か困ったのでは?」といったさながら異種格闘技戦の赤裸々な内容から語っていただくセミナーを開催します。

 

全社で活用可能なビッグデータ分析基盤で企業競争力を高めよ
-
ゲオホールディングスの挑戦を支えるクラウドのデータ分析基盤

東京港区港南1丁目270 品川シーズンテラス3階

16:45-17:00 受付

17:00-17:30 株式会社ゲオホールディングス様 Azure 導入事例のご紹介 株式会社ゲオホールディングス 分析部 吉村 公胤

17:30-18:10 パートナーソリューション紹介株式会社ブレインパッド 安良岡史行

18:10-19:00 AI時代のクラウド データプラットフォーム Azure SQL Data Warehouse で実現するアジャイルなデータ分析基盤

日本マイクロソフト株式会社 クラウドソリューションアーキテクト 高木 英朗

 

Azure SQL Data Warehouse を採用することで、評価開始からわずか半年で運用開始に至るなど構築期間とコストの大幅な短縮を実現したゲオホールディングス担当自らが発端の課題、導入中の困りごとまで赤裸々に語ります。

 

登録はこちら! https://aka.ms/ss_dwh

 

お客様が何に困って導入を決意したか。そして何が変わったか。SI に携わる皆様にとっても興味深いところではないでしょうか。
内容の性質上、その場だけの内容ですので、録画やリピートはありません。ご質問もいただけます。ぜひ、ご参加ください。

SQL Server/Azure SQL Database で使用可能なデータの暗号化機能について

$
0
0

 

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

今回は、SQL Server/Azure SQL Database で使用可能なデータの暗号化機能について紹介します。

 

SQL Server/Azure SQL Database で使用可能なデータの暗号化機能として、以下の機能があります。

今回は、透過的なデータ暗号化(TDE : Transparent Data Encryption)について紹介します。

■ 透過的なデータ暗号化(TDE : Transparent Data Encryption
■ 暗号化関数
■ Always Encrypted

 

透過的なデータ暗号化(以下 TDE)では、データベース物理ファイル (データ、ログ) を暗号化する機能となり、SQL Server、Azure SQL Database で使用可能です。

TDE では、データベース物理ファイル (データ、ログ) の暗号化/暗号化解除をオンラインで設定することが可能であり、暗号化には、データベース暗号化キー (以下 DEK) が使用されています。

DEK は、システム データベース master に保存されている証明書を使用して保護された対象キー もしくは、拡張キー管理 (EKM) モジュールに格納される非対称キー であり、データベース物理ファイルの Boot page (ブート ページ) に保存されます。

 

[TDE を使用するメリット]

本機能は、法律、規制、およびさまざまな業界で確立されているガイドラインの多くに準拠し、ソフトウェア開発者は、既存のアプリケーションを変更することなく、AES 及び 3DES 暗号化アルゴリズムを使用して、データの暗号化を行うことができます。

 

[TDE を使用するデメリット]

本機能を使用するうえで、一部 制限事項 があります。

※ 詳細は、以下の公開情報を参照ください。

 

透過的なデータ暗号化 (TDE)

+ 制限

 

[TDE を作成するために必要な権限]

データベースに対する CONTROL 権限、及び データベース暗号化キーを暗号化している 証明書 もしくは、非対称キーに対する VIEW DEFINITION 権限

 

[補足]

Azure SQL Database 上のデータベースに対して、TDE を有効化する方法については、以下の公開情報を参照ください。

Azure SQL Database での Transparent Data Encryption

 

[参考情報]

別の SQL Server への TDE で保護されたデータベースの移動

EKM を使用して TDE を有効にします。

 

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


2017 年 9月 SQL Server 最新モジュール

$
0
0

2017 年 9月 19日 時点の SQL Server 最新モジュールです。

SQL Server 2005 は 2016 年 4 月 12 日に延長サポートが終了しました。長らくのご愛用ありがとうございました。
SQL Server 2008 は 2014 年 7 月 8 日にメインストリームサポートが終了しました。
SQL Server 2012 は 2017 年 7 月 11 日にメインストリームサポートが終了しました。

サービス
パック

更新プログラム

バージョン

リリース年月

SQL Server 2016

SP1

KB 4040714 (CU5)

13.0.4451.0

2017/9
メインストリームサポート

SQL Server 2014

SP2

KB 4032541 (CU7)

12.0.5556.0

2017/8
メインストリームサポート

SQL Server 2012

SP3

KB 4025925 (CU10)

11.0.6607.3

2017/8
延長サポート
※2017年7月11日にメインストリームサポートが終了しました。

SQL Server 2008 R2

SP3

KB 3135244

10.50.6537.0

2014/9
延長サポート
※2014年7月8日にメインストリームサポートが終了しました。

SQL Server 2008

SP4

KB 3135244

10.0.6547.0

2014/10
延長サポート
※2014年7月8日にメインストリームサポートが終了しました。

 

RTM : Release To Manufacturing (製品出荷版)
SP : Service Pack (サービスパック)
CU : Cumulative Update (隔月リリースの累積更新プログラム)
OD : On-Demand (オンデマンドリリースの累積更新プログラム)

SQL Server の更新プログラムの詳細については、SQL Server の更新プログラムを参照して下さい。

メインストリームサポート、延長サポートについては、マイクロソフトサポートライフサイクルを参照して下さい。

イベントログに SQL Server 関連のパフォーマンス ライブラリで 警告 2003 が発生した場合の対処方法について

$
0
0

 

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

今回は、イベントログに SQL Server 関連のパフォーマンス ライブラリで 警告 2003 が発生した場合の対処方法について紹介します。

 

Microsoft-Windows-Perflib: 警告: 2003:

"MSSQLSERVER" サービスのパフォーマンス ライブラリ "perf-MSSQLSERVER-sqlctr**.*.****.*.dll" の構成情報が、レジストリに保存されている信頼されたパフォーマンスライブラリの情報に一致しませんでした。このライブラリの関数は信頼されているものとして処理されません。

 

[原因]

SQL Server のパフォーマンス ライブラリ "perf-MSSQLSERVER-sqlctr**.*.****.*.dll" のファイル作成時刻やファイルサイズが、レジストリに格納されている情報と一致していない場合に発生します。

 

[影響]

パフォーマンス モニター/データ コレクター より、SQL Server 関連のパフォーマンス カウンタ情報の採取に失敗する可能性があります。

 

[対処方法]

SQL Server のパフォーマンス ライブラリ を再登録することで、警告 2003 は解消します。

 

# SQL Server のパフォーマンス ライブラリ を再登録手順

※ 本手順は SQL Server 2016 の手順を紹介していますが、SQL Server 2005 から 最新の SQL Server まで実施する作業は同じです。

1) パフォーマンス モニター/データ コレクター より、SQL Server 関連のパフォーマンス カウンタ情報を採取している場合は、採取を停止します。

2) コマンド プロンプトを “管理者として実行” より起動します。

3) SQL Server のパフォーマンス ライブラリ が配置されているパスに カレント ディレクトリ を移動します。

※ SQL Server のインストールパスが既定のパスと異なる場合は、正しいパスに変更します。

 

# SQL Server 2016 (既定のインスタンスの場合)

> cd C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Binn

 

# SQL Server 2016 (名前付きインスタンスの場合)

> cd C:\Program Files\Microsoft SQL Server\MSSQL13.<名前付きインスタンス名>\MSSQL\Binn

 

4) SQL Server 関連のカウンタを削除するため、以下のコマンドを実行します。

 

# SQL Server 2016 (既定のインスタンスの場合)

> unlodctr MSSQLServer

 

# SQL Server 2016 (名前付きインスタンスの場合)

> unlodctr MSSQL$<名前付きインスタンス名>

 

# コマンド実行例 : SQL Server 2016 名前付きインスタンス “S2K16” の場合

C:\Program Files\Microsoft SQL Server\MSSQL13.S2K16\MSSQL\Binn>unlodctr MSSQL$S2K16

MSSQL$S2K16 のカウンター名と説明を削除しています
言語 009 のテキストを更新しています
言語 011 のテキストを更新しています

 

5) 以下のコマンドを実行し、SQL Server のパフォーマンス ライブラリ を再登録します。

 

# SQL Server 2016 (既定のインスタンスの場合)

> lodctr perf-MSSQLSERVERsqlctr.ini

 

# SQL Server 2016 (名前付きインスタンスの場合)

> lodctr perf-MSSQL$<名前付きインスタンス名>sqlctr.ini

 

# コマンド実行例 : SQL Server 2016 名前付きインスタンス “S2K16” の場合

C:\Program Files\Microsoft SQL Server\MSSQL13.S2K16\MSSQL\Binn>lodctr perf-MSSQL$S2K16sqlctr.ini

 

6) SQL Server のサービスを再起動後、イベントログ (アプリケーション) に 警告 2003 が出力されていないことを確認します。

 

 

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

HowTo: Management Studio を使ってトランザクションログファイル (ldf) のサイズを小さくする方法

$
0
0


神谷 雅紀

Escalation Engineer


「ログファイルが大きくなってディスク領域を圧迫し始めているので、ファイルサイズを小さくしたい」という内容の問合わせは今でも多く寄せられます。今回は、SQL Server Management Studio GUI を使って、トランザクションログファイルのサイズを小さくする手順を紹介します。

ここに記載した方法で、トランザクションログファイルのサイズを小さくしたいという状況のほとんどに対応可能だと思います。

ここに記載した方法でトランザクションログファイルのサイズを小さくできない場合は、おそらく、トランザクションログファイルのサイズを小さくする前に、レプリケーションやミラーリングのトラブルシューティングなどが必要になるでしょう。


ステップ 1 : データベースの復旧モデルを確認する

復旧モデルが「単純」かそれ以外かによって、以降の手順が違ってきますので、まず最初に、データベースの復旧モデルを確認します。

手順

復旧モデルを確認するために、データベースのプロパティを表示します。データベースのプロパティは、オブジェクトエクスプローラでデータベース名を右クリックし、「プロパティ」をクリックすることで表示できます。

dbprop

表示されたダイアログボックスの左ペインで「オプション」を選択すると、右ペインに「復旧モデル」が表示されます。復旧モデルは、「単純」「完全」「一括ログ」のいずれかです。

dbprop2


ステップ 2 : トランザクションログをバックアップする

トランザクションログは、データベースファイルへの更新履歴ですので、データベースに対して更新を行うたびにトランザクションログファイルには履歴データが記録され、何もしなければ、トランザクションログファイル内の履歴データはどんどん増えていきます。

復旧モデルが「単純」の場合は、トランザクションログファイル内のデータ量が一定量を超えると、SQL Server がファイルの中身を消し、ファイル内に空き領域を作り、空いた領域は再利用されます。

一方、復旧モデルが「完全」または「一括ログ」に設定されている場合は、過去に一度でもデータベースの完全バックアップ (データベースフルバックアップ) を取得していると、SQL Server はファイルの中身を消すことはしませんので、トランザクションログファイル内のデータは、バックアップしなければ削除されません。

このステップ 2 は、復旧モデルが「完全」または「一括ログ」の場合のみ行います。「単純」の場合は、次のステップ 3 に進みます。

手順

データベースを右クリックし、「タスク」 -  「バックアップ」をクリックします。

backup

「バックアップの種類」として「トランザクションログ」を選びます。もし、復旧モデルが「単純」に設定されている場合は、「トランザクションログ」は選択できません。

「バックアップセットの有効期限」は既定のまま、「バックアップ先」は、バックアップデータを書き込むファイル名を指定します。「ディスク」を指定して、「追加」でファイル名を指定して下さい。そのサーバーにテープデバイスがある場合には、「テープ」を選んでも構いません。

最後に「OK」を押すと、バックアップが開始されます。

logbackup


復旧モデルが「完全」または「一括ログ」であっても、データベースの完全バックアップが一度も取得されていない場合、トランザクションログのバックアップは以下のエラーで失敗します。


メッセージ 4214、レベル 16、状態 1

現在、データベースのバックアップが存在しないので、BACKUP LOG を実行できません。


復旧モデルが「完全」または「一括ログ」であっても、データベースの完全バックアップが一度も取得されていない場合は、トランザクションログは自動的に切り捨てられていますので、このステップを実行せずにステップ 3 に進むことができます。

バックアップファイルの出力先にバックアップデータを保持できるだけの十分な容量がない場合


バックアップファイルの出力先にすべてのバックアップデータを保持できるだけの容量がない場合、バックアップは失敗します。この場合、トランザクションログの切り捨ては行われません。バックアップファイルの出力先に十分な容量が確保できない場合は、データベースの復旧モデルを一時的に「完全」や「一括ログ」から「単純」に変更することで、ステップ 2 をスキップしてステップ 3 に進むことができるようになります。

ステップ 3 に進む前に CHECKPOINT が実行される必要がありますので、復旧モデル変更後は、データベースに対して CHECKPOINT が実行されるだけの量の更新が行われるのをしばらく待つか、明示的に CHECKPOINT を実行する必要があります。明示的な CHECKPOINT の実行方法は、本投稿内の「CHECKPOINT が実行されていない場合」を参照して下さい。

尚、この方法では、トランザクションログを使用したデータベース復旧はできなくなります。そのため、復旧モデルを「単純」に変更する前に、データベースへの書き込みを行わない状態にし、データベースの完全バックアップを取得することをお勧めします。これにより、一連の作業中に不測の事態が発生したとしても、作業開始前の状態までは確実に戻れるようになります。


ステップ 3 : トランザクションログファイルのサイズを小さくする

バックアップにより、トランザクションログファイルの中身を消したとしても、ファイル自体のサイズは小さくなりません。

ファイル内に空きがなくなれば、データを書き込むために再びファイルサイズを大きくしなければなりません。当然、ファイルサイズを変更するためには、メモリも CPU も使いますし、ある程度は時間もかかります。そのため、パフォーマンスの観点からは、トランザクションログファイルには、常に空き領域がある状態を保つ方が理想的です。ディスクの空き領域の問題などにより、ファイルを小さくしなければならない場合は、可能な限り小さくするというよりも、ある程度の余裕を持ったサイズにした方がいいでしょう。

手順

データベースを右クリックし、「タスク」、「圧縮」、「ファイル」の順にクリックします。

shrink

「ファイルの種類」は「ログ」、「ファイル名」は、大きくなってしまったトランザクションログファイルの論理名、「圧縮アクション」として「未使用領域の解放前にページを再構成する」を選択し、ファイルサイズの目標となるサイズを MB 単位で指定します。このサイズは目標サイズであるため、必ずしも、そのサイズまで小さくできるとは限りません。

shrink_setting


この手順を実施してもトランザクションログファイルが小さくならない場合

これら 3 ステップを実施することで、トランザクションログファイルのサイズは小さくできるはずですが、小さくならない場合は、ステップ 1 ~ 3 をもう一度繰り返してみて下さい。

もし、それでも小さくならない場合は、そのほとんどは、以下のいずれかが原因です。(これ以外にも原因となるものはありますが、それらは長時間存在し続けるものではないため、通常、上の手順を繰り返し行えば必ずファイルは小さくなります。)

  • 実行中のトランザクションがある場合
  • トランザクションレプリケーションが構成されていて、まだ配布されていないトランザクションがある場合
  • データベースミラーリングが構成されていて、まだ配信されていないトランザクションがある場合
  • sync with backup オプションが ON に設定されているディストリビューションデータベースのバックアップが行われていない場合
  • CHECKPOINT が実行されていない場合


実行中のトランザクションがある場合

実行中のトランザクションの有無は、GUI ではなく DBCC OPENTRAN コマンドにより確認します。

確認手順

[新しいクエリ] ボタン、もしくは、[ファイル] メニューの [新規作成] – [クエリを現在の接続で実行] から、Management Studio のクエリウィンドウを開き、以下を実行します。




DBCC OPENTRAN(‘データベース名’)




例 : DBCC OPENTRAN('AdventureWorks')

以下は、実行中のトランザクションがない場合の DBCC OPENTRAN 実行結果の例です。この場合、トランザクションログファイルが小さくならない原因は、実行中のトランザクションがあるからではありません。他の原因を確認する必要があります。

開かれたアクティブなトランザクションがありません。

以下は、実行中のトランザクションがある場合の DBCC OPENTRAN 実行結果の例です。この場合、トランザクションログファイルが小さくならない原因は、実行中のトランザクションがあ���からです。トランザクションログファイルを小さくするためには、このトランザクションを終了した後に、ステップ 1 ~ 3 を実行する必要があります。

データベース 'AdventureWorks' のトランザクション情報。

最も古いアクティブなトランザクション:

SPID (サーバー プロセス ID): 51

UID (ユーザー ID) : -1

名前 : user_transaction

LSN : (43:2238:2)

開始時刻 : 12 12 2011 7:43:41:553PM

SID : 0x0105000000000005150000005d28f57fd53ad8354354e02a481c0000

上で確認した SPID を使って以下のクエリを実行すると、このトランザクションを実行しているクライアントプロセスが実行されているマシン名やプログラム名、ログインユーザ名、PID 等を確認することができます。




select * from sys.dm_exec_sessions where session_id=上で確認した spid




例 : select * from sys.dm_exec_sessions where session_id=51


対処方法

実行中のままになっているトランザクションの実行元マシン、アプリケーション名、PID などを確認できたら、そのアプリケーションがなぜトランザクションをずっと実行中のままなのかを確認しましょう。それが、正常と考えられる状況であれば、そのまま放置し、アプリケーションが処理を完了するのを待ちます。それが異常と考えられる状況であれば、アプリケーションを終了することで、トランザクションも終了させます。

もし、トランザクションを実行しているアプリケーションに対する操作ができないような場合には、以下を実行することで、SQL Server 側からこのトランザクションを強制的に終了させることも可能です。ただし、これを行うと、アプリケーション側ではエラーを受け取り、トランザクションはロールバックされます。

手順

オブジェクトエクスプローラで対象 SQL Server インスタンスを右クリックし、「利用状況モニタ」を起動します。

processes

上で確認した SPID を右クリックし、「強制終了」をクリックします。

kill

もう一度 DBCC OPENTRAN を実行して実行中のトランザクションがなくなっていることを確認後、再度ステップ 1 ~ 3 を実行します。


トランザクションレプリケーションが構成されていて、まだ配布されていないトランザクションがある場合

確認手順

[新しいクエリ] ボタン、もしくは、[ファイル] メニューの [新規作成] – [クエリを現在の接続で実行] から、Management Studio のクエリウィンドウを開き、以下を実行します。




DBCC OPENTRAN(‘データベース名’)




例 : DBCC OPENTRAN('AdventureWorks')

以下は、トランザクションレプリケーションの未配布トランザクションがない場合の、DBCC OPENTRAN 実行結果の例です。この場合、トランザクションログファイルが小さくならない原因は、トランザクションレプリケーションの未配布トランザクションがあるからではありません。

開かれたアクティブなトランザクションがありません。

以下は、トランザクションレプリケーションの未配布トランザクションがある場合の、DBCC OPENTRAN 実行結果の例です。この場合、トランザクションログファイルが小さくならない原因は、トランザクションレプリケーションの未配布トランザクションがあるからです。トランザクションログファイルを小さくするためには、この未配布トランザクショントランザクションを配布した後に、ステップ 1 ~ 3 を実行する必要があります。

データベース 'AdventureWorks' のトランザクション情報。

レプリケートされたトランザクション情報:

配布された最も古い LSN : (39:46:1)

配布されなかった最も古い LSN : (39:47:1)

ここで言う「配布 (distribution/distribute)」とは、ログリーダーエージェントが、パブリケーションデータベースのトランザクションログからトランザクションログを読み取り、読み取ったトランザクションの内容をディストリビューションデータベースに格納することです。

対処方法

配布されていないトランザクションがパブリケーションデータベースにある場合、それは、ログリーダーが正しく動いていない、もしくは、動けていないことが原因です。トランザクションログファイル内の未配布トランザクションを配布してトランザクションログファイルのサイズを小さくするためには、ログリーダーが動かない原因を排除して、レプリケーションを再開することが必要です。

手順

レプリケーションの状態を確認するために、[レプリケーション] を右クリックし、「レプリケーションモニタ」を起動して、レプリケーションの状態を確認してみましょう。

repl

レプリケーションモニタでエラーが確認できる場合、「サブスクリプション ウォッチリスト」内の行をダブルクリックして、エラーの詳細が確認できます。

replmon

suberror

発生している可能性のあるエラーはいろいろとあるので、ここではその解決方法までは伝えられませんが、発生しているエラーの原因を特定して、その原因を排除し、レプリケーションを再開した後にステップ 1 ~ 3 を実行すれば、トランザクションログファイルのサイズを小さくすることができます。


データベースミラーリングまたは可用性グループが構成されていて、まだ配信されていないトランザクションがある場合

データベースミラーリングと AlwaysOn 可用性グループもトランザクションレプリケーションと同様にトランザクションログをベースとした機能です。プリンシパルサーバー/プライマリレプリカからミラーサーバー/セカンダリレプリカへのトランザクション配信が行えなくなると、配信が可能になった時に配信を再開できるように、プリンシパルサーバー/プライマリレプリカ上のトランザクションログは、バックアップをしても削除されなくなります。この場合は、配信を再開することが、トランザクションログファイルのサイズを小さくするために必要なことです。


確認手順

データベースミラーリングおよび可用性グループの状態は、Management Studio のオブジェクトエクスプローラで確認することができます。以下は、データベースミラーリングの場合の例です。

dbm

上の画像のように、「同期済み」となっている場合には、トランザクションログファイルが小さくならない原因は、ミラーリングや可用性グループではありません。

それ以外の場合、ミラーリングや可用性グループが原因である可能性があります。


対処方法

「同期中」である場合は、しばらく待った後、再度ミラーリングの状態を確認して下さい。

「接続解除」である場合は、ミラーサーバーが起動しているかどうかを確認して下さい。起動していない場合は、起動して下さい。

起動している状態でも「接続解除」になっている場合は、ping により、ネットワーク接続に問題がないかどうかを確認して下さい。ping が通る場合は、プリンシパルサーバー上で Management Studio や sqlcmd.exe から、ミラーサーバーとなっている SQL Server へ接続できるかどうか確認して下さい。これらのテストに失敗する場合は、名前解決を含むネットワークの問題やファイアウォールの設定の問題である可能性があるため、ネットワークやファイアウォールの設定を見直して下さい。

プリンシパル上の Management Studio や sqlcmd を用いてミラーサーバーに接続できる場合、プリンシパルサーバー上の SQL Server Errorlog (SQL Server 2008 R2 既定インスタンスの場合 C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log 下の Errorlog ファイル) を参照し、エラーの原因を突き止める必要があります。

ミラーリングの状態が「同期済み」となれば、ステップ 1 ~ 3 を実行することで、トランザクションログファイルのサイズを小さくすることができます。



sync with backup オプションが ON に設定されているディストリビューションデータベースのバックアップが行われていない場合

ディストリビューションデータベースの sync with backup オプションが有効になっている場合、トランザクションレプリケーションのパブリケーションデータベースでは、トランザクションログバックアップを行ったとしても、ディストリビューションデータベースのフルデータベースバックアップが完了するまではトランザクションログは切り捨てられません。

対処方法

ディストリビューションデータベースのフルデータベースバックアップを行います。ディストリビューションデータベースのフルデータベースバックアップ完了後、パブリケーションデータベースのトランザクションログバックアップを行います。




スナップショット レプリケーションおよびトランザクション レプリケーションのバックアップと復元の方式


http://msdn.microsoft.com/ja-jp/library/ms152560.aspx



CHECKPOINT が実行されていない場合

確認手順

これが原因になることはほとんどありませんが、復旧モデルが「単純」で上のステップ 1、3 を実行してもトランザクションログファイルサイズが小さくならない場合は、CHECKPOINT が実行されていないために、トランザクションログが切り捨てられていない可能性があります。

この状況に該当しているかどうかを判断するためには、sys.databases カタログビューの log_reuse_wait_desc を確認します。CHECKPOINT または XTP_CHECKPOINT となっている場合には、該当しています。

select name, log_reuse_wait_desc from sys.databases

なお、インメモリ OLTP (メモリ最適化ファイルグループ) 機能を使用している場合には、パフォーマンスの観点から、最後の CHECKPOINT 以降に生成されたトランザクションログが 1.5GB 以上になるまでは自動的には CHECKPOINT は実行されないようになっています。そのため、インメモリ OLTP を使用していないデータベースに比べて、トランザクションログファイルの使用量が多くなる場合があります。この動作に起因して CHECKPOINT が自動的に実行されていない場合であっても、以下の方法で明示的に CHECKPOINT を実行すれば、トランザクションログは切り捨てられます。


対処方法

Management Studio のクエリウィンドウを開き、トランザクションログファイルのサイズを小さくしたいデータベースに変更した後に、CHECKPOINT コマンドを実行して下さい。

以下の例は、AdventureWorks データベースのトランザクションログファイルを小さくしたい場合に実行する CHECKPOINT コマンドの実行例です。

対象データベースを選択し、そのデータベース上で実行することがポイントです。

checkpoint

その後、ステップ 3 を再実行して下さい。


更新日 更新内容 更新者
2011/12/20 新規 神谷
2013/07/30 sync with backup に関する記述を追加 神谷
2015/11/11 「バックアップファイルの出力先にバックアップデータを保持できるだけの十分な容量がない場合」を追加 神谷
2017/09/29 インメモリ OLTP、 可用性グループに関する記載を追加 神谷

SQL Server AlwaysOn フェールオーバー クラスター インスタンス 環境に .NET Framework 4.6 をインストール後、メンテナンスプラン から SQL Server への接続に失敗する

$
0
0

 

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

今回は、SQL Server AlwaysOn フェールオーバー クラスター インスタンス 環境に .NET Framework 4.6 をインストール後、メンテナンスプラン から SQL Server への接続に失敗する問題について紹介します。

 

SQL Server AlwaysOn フェールオーバー クラスター インスタンス環境 (以下 SQL Server AlwaysOn FCI) で、かつ、名前付きインスタンスをインストールした環境に、.NET Framework 4.6 をインストールすると、メンテンナンス プラン 及び syspolicy_purge_history ジョブ から 該当の名前付きインスタンスに接続しようとした際に、以下のエラーにより、接続に失敗するという現象が発生します。

この問題は、スタンドアローン環境 及び SQL Server AlwaysOn フェールオーバー クラスター インスタンス環境で、かつ、既定のインスタンス では発生しません。

 

[メンテナンス プラン エラー例]

Error: ****-**-** **:**:**.**     Code: 0xC0024104     Source: Shrink Database Task Description: The Execute method on the task returned error code 0x80131904 (A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)).

 

[syspolicy_purge_history ジョブ エラー例]

ジョブ ステップは、PowerShell スクリプトの 2 行目でエラーを受け取りました。
対応する行は '(Get-Item SQLSERVER:\SQLPolicy\****\***$a).EraseSystemHealthPhantomRecords()' です。
スクリプトを修正し、ジョブのスケジュールを設定し直してください。
PowerShell によって返されたエラー情報: 'サーバー  に接続できませんでした。
SQL Server への接続を確立しているときにネットワーク関連またはインスタンス固有のエラーが発生しました。
サーバーが見つからないかアクセスできません。
インスタンス名が正しいこと、および SQL Server が リモート接続を許可するように構成されていることを確認してください。
(provider: SQL Network Interfaces error: 26 - 指定されたサーバーまたはインスタンスの位置を特定しているときにエラーが発生しました)  '.

 

[原因]

技術情報 3078663 の .NET Framework 4.6 の問題により、メンテナンスプラン 及び syspolicy_purge_history ジョブから、SQL Server AlwaysOn FCI 上の名前付きインスタンスへの接続の際、接続先インスタンス名の正常性チェックが行われますが、本チェックが成功しないために発生します。

 

Add Connection dialog box doesn't load server names in the drop-down list after you apply the .NET Framework 4.6

 

[対処方法]

以下の何れかの対処方法を実施します。

A) .NET Framework 4.6.1 以降にアップデートします。

B) 明示的に名前付きインスタンスがリッスンしているポートを指定し、該当インスタンスに接続します。

 

以下にそれぞれの対処方法の詳細を記載します。

 

A) .NET Framework 4.6.1 以降にアップデートします。

---------------------------------------------------------

技術情報 3078663 の現象は、.NET Framework 4.6.1 で修正されています。 そのため、.NET Framework 4.6.1 以降にアップデートすることで、本現象を改善することができます。

 

B) 名前付きインスタンスがリッスンしているTCPポートを明示的に指定し、該当インスタンスに接続します。

---------------------------------------------------------

SQL Serer へ接続する際、明示的に名前付きインスタンスがリッスンしているポートを指定することで、問題が発生する接続先インスタンス名の正常性チェックが行われなくなるため、有効な対処方法となります。

なお、名前付きインスタンスの場合、インスタンス起動時に、該当インスタンスをリッスンするポートが動的に決定されます。

そのため、本現象の対処として、名前付きインスタンスでリッスンされるTCPポートを固定した後、固定化したポートで毎回接続が行われるように別名を作成することを推奨します。

 

特定の TCP ポートで受信待ちするようにサーバーを構成する方法 (SQL Server 構成マネージャー)

 

[例] 名前付きインスタンスのリッスンポートを “50001” に変更する場合

image

 

クライアントが使用するサーバーの別名の作成または削除 (SQL Server 構成マネージャー)

※ [別名] と [サーバー] に「<サーバー名>\<インスタンス名>」を記載し、[プロトコル] は「TCP/IP」を選択し、[ポート番号] にポートを記載します。

 

[例] 名前付きインスタンスの別名で接続ポートを “50001” に指定する場合

image

 

[補足]

SQL Server Management Studioで SQL Server AlwaysOn FCI 名前付きインスタンスに接続する際、FQDN でサーバー名を指定し、接続した状態でメンテナンス プランを作成した場合においても、今回の現象を解消することが可能です。

また、syspolicy_purge_history ジョブ の場合においても、該当ジョブのステップ “Erase Phantom System Health Records” の “ESCAPE_NONE(SRVR))$a” を FQDN名で指定 (例: “FCI.ad.com\Instance1”)  することにより、今回の現象を解消することが可能です。

しかしながら、上記に記載した 対処方法 A、B を実施することを推奨しています。

 

# syspolicy_purge_history ジョブ : ステップ “Erase Phantom System Health Records”

image

 

 

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

SQL Server 2017 のインストール時に tempdb のサイズを大きくしすぎるとExecution Timeout Expiredエラーになる事がある

$
0
0


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

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

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

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

//エラー画面

clip_image001

//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の内容は、201711月現在の内容となっております

Azure 仮想マシン上に作成した SQL Server の日本語化手順(Windows OS 版 SQL Server 2017 対応手順)

$
0
0

 

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

今回は、Azure 管理ポータルのギャラリーからデプロイした Azure 仮想マシン上に作成した SQL Server 2017 (Windows OS 版) の日本語化手順 について紹介します。

 

Azure 管理ポータルのギャラリーから、SQL Server を含む Azure 仮想マシンのイメージをデプロイすることが可能ですが、該当イメージに含まれている SQL Server は英語版となります。

SQL Server データベース エンジンの実行可能ファイルは全言語共通であるため、英語版 SQL Server でも、日本語を挿入可能なデータ型 (Unicode 型など) をテーブル列として追加することで、日本語データの格納、取り出し、また、検索を実施することが可能です。

しかしながら、管理ツールのインターフェースを日本語にする必要がある場合は、以下の手順を実施することで、日本語化することが可能です。

 

◆ SQL Server 2012 、2014  および 2016 の日本語化手順は以下の ブログ をご確認ください。

 Azure 仮想マシン上に作成した SQL Server の日本語化手順(SQL Server 2012 , 2014 対応手順)

 Azure 仮想マシン上に作成した SQL Server の日本語化手順(SQL Server 2016 対応手順 )

※ 本ブログの内容 (リンク先などを含む) は、作成日時点のものであり、予告なく変更される場合があります。

 

[注意]

SQL Server を日本語化するには、SQL Server のアンインストール、再インストール作業が必要になります。

しかしながら、SQL Server IaaS Agent 拡張機能は、既定でインストールされている英語の SQL Server でのみで動作する機能であり、SQL Server を日本語化すると動作しなくなります。

そのため、SQL Server を日本語化後、SQL Server の自動修正機能、自動バックアップ機能や、Azure Key Vault 統合の機能に関して、ポータルから設定できなくなる点にご注意ください。

 

*******************************************

A. SQL Server IaaS Agent 拡張機能のアンインストール

B. SQL Server と関連コンポーネントのアンインストール

C. OSのロケール設定を日本語に変更

D. 日本語のSQL Server 2017 Evaluation Editionを使用して、日本語版のSQL Server をインストール

*******************************************

 

A. SQL Server IaaS Agent 拡張機能のアンインストール

===============================

1. Azure 仮想マシンのメニュー一覧から、[拡張機能] を選択します。

2.一覧から SQL IaaS Extension を確認し、右端 [・・・] を選択し、アンインストールを選択します。

clip_image001

<図1 SQL Server IaaS Agent 拡張機能のアンインストール>

 

 

B. SQL Server と関連コンポーネントのアンインストール

==============================================================

以下のURLに従い、既存の英語版SQL Server をアンインストールします。

 

◆SQL Server の既存のインスタンスのアンインストール (セットアップ)

https://msdn.microsoft.com/ja-jp/library/ms143412(v=sql.140).aspx

※ [Microsoft SQL Server 2016 (64bit)] を [Microsoft SQL Server 2017 (64bit)] に読み替えて参照下さい。

--サイト内、一部抜粋--

1. アンインストール プロセスを開始するには、コントロール パネルで [プログラムと機能] をクリックします。

2. [Microsoft SQL Server 2016(64bit)] を右クリックし、[アンインストール] を選択します。次に、[削除] をクリックします。これにより、SQL Server インストール ウィザードが起動します。セットアップ サポート ルールが実行され、コンピューターの構成が確認されます。続行するには、[次へ] をクリックします。

3. [インスタンスの選択] ページのドロップダウンボックスを使用して、削除する SQL Server インスタンスを指定するか、SQL Server の共有機能と管理ツールだけを削除するオプションを指定します。続行するには、[次へ] をクリックします。

4. [機能の選択] ページで、指定した SQL Server インスタンスから削除する機能を指定します。削除ルールが実行され、操作を正常に完了できることが確認されます。

5. [削除の準備完了] ページで、アンインストールされるコンポーネントおよび機能の一覧を確認します。 [削除] をクリックしてアンインストールを開始します。

6. 最後の SQL Server インスタンスをアンインストールした直後は、SQL Server に関連付けられたその他のプログラムがまだ [プログラムと機能] のプログラムの一覧に表示されています。ただし、[プログラムと機能] を閉じ、次に [プログラムと機能] を開いたときには、プログラムの一覧は更新され、実際にインストールされているプログラムのみが表示されます。

--------------------

 

上記と同様の手順にて、プログラムと機能より、 「Data Tier Application Framework」 と 「Microsoft Visual Studio 2015 Shell (Isolated)」 のアンインストールを同様に実施します。

なお、「Microsoft Visual Studio 2015 Shell (Isolated)」は [Change] - Visual Studio の ポップアップ ウィンドウの表示 - [Unistall] - [Yes] で削除できます。

clip_image002

<図2.プログラムと機能>

 

 

C. OSのロケール設定を日本語に変更

============================================

日本語版SQL Server を英語版OSにインストールする場合、事前にOSの言語設定を変更する必要があります。

具体的には以下の設定です。

・オペレーティング システムのユーザー インターフェイス設定

・オペレーティング システムのユーザー ロケール設定

・システム ロケール設定

 

以下のURLよりダウンロードできるドキュメントにOS日本語化のスクリーンショット付き手順があります。必要に応じて参照下さい。

 

◆Microsoft Azure SQL Server の活用(IaaS 環境における設定や運用のベストプラクティス)

http://www.microsoft.com/click/services/Redirect2.ashx?CR_EAC=300173769

+ [3.2 OS の日本語化] の章を確認します。

以下URLでも紹介されております。 こちらも必要に応じて確認下さい。

◆SQL Server のローカル言語版

https://docs.microsoft.com/ja-jp/sql/sql-server/install/local-language-versions-in-sql-server

 

 

D. 日本語のSQL Server 2017 Evaluation Editionを使用して、日本語版のSQL Server をインストール

==================================================================================================

OSの言語設定を日本語に変更後、日本語のSQL Server 2017 Evaluation Editionをインストールします。

この際、ギャラリーの英語版SQL Server に同梱されているSQL Server のプロダクトキーを、日本語版SQL Server のインストール時に設定下さい。

 

1. 下記URLより、Azure 仮想マシン上に日本語版のSQL Server 2017 をダウンロードします。

 

◆評価版のダウンロード: Microsoft SQL Server 2017 RTM

https://www.microsoft.com/ja-jp/evalcenter/evaluate-sql-server-2017-rtm

ダウンロードする際に、インストールの種類は [メディアのダウンロード] を選択します。

clip_image003

<図3.インストールの種類>

 

[言語の選択] から [日本語] を選択し、パッケージの種類を [ISO] にし、ダウンロードをします。

clip_image004

<図4.SQL Server インストーラーのダウンロードを指定する>

 

clip_image005

<図5.メディアのダウンロード>

 

ダウンロード後には、該当ISOファイルをマウントし、DVDドライブに読み込ませます。

2.Azure 仮想マシン上で C:\SQLServerFull\x64\DefaultSetup.ini を開きます。

3. PIDに指定されているプロダクトキーを確認します。

// DefaultSetup.ini

********************

;SQL Server 2017 Configuration File

[OPTIONS]

PID=”XXXXX-XXXXX-XXXXX-XXXXX-XXXXX”

********************

※ XXXXXの部分が実際のプロダクトキーになります。

4. 日本語版の SQL Server 2017 のインストールを開始します。この際、[プロダクト キー] ページで、該当プロダクトキーを入力することで、Edition を Evaluation から変更できます。

clip_image006

<図6.プロダクトキーの入力>

 

SQL Server 2017  のインストールについての詳細は以下サイト内を必要に応じて確認下さい。

 

◆ SQL Server をインストールウィザードからインストールする (セットアップ)

https://docs.microsoft.com/ja-jp/sql/database-engine/install-windows/install-sql-server-from-the-installation-wizard-setup

 

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

[Microsoft Flow] 日本語を含むファイル名をメールで通知する場合、文字化けが発生する場合の対処方法について (SharePoint)

$
0
0

 

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

今回は、SharePoint で以下のようなトリガーが発生後、ファイル名をメールで送信するフローを作成した場合、ファイル名に日本語が含まれていると文字化けが発生する現象を対処する方法について紹介します。

 

SharePoint – When a file is created in a folder
SharePoint – When a file is created or modified in a folder

 

[問題]

SharePoint 上の特定のフォルダ内にファイルが作成されたことをトリガーとし、メールで作成されたファイル名を送信するという以下のようなフローを作成すると、ファイル名に日本語が含まれている場合、メールの本文に出力されるファイル名が文字化けします。

image

 

# 文字化け発生例

image

 

[対処方法]

SharePoint 上の特定のフォルダ内にファイルが作成されたことをトリガーとして設定後、アクション “Get file metadata” でファイル識別子 “File identifier” を追加した上で、アクション “電子メールの送信” でメールの本文に “Name” を指定します。

 

image

 

# 文字化け解消例

image

 

[補足]

本ブログでは、日本語を含むファイル名をメールで通知する例を紹介していますが、Twitter や Yammer へ投稿する場合にも、同じ対処を実施する必要があります。

 

 

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


[Microsoft Flow] 作成したフローを別環境に移行する方法について

$
0
0

 

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

今回は、作成したフローを別環境に移行する方法について紹介します。

 

[移行手順]

作成したフローを別環境に移行する方法として、作成したフローをパッケージ(zip形式)としてエクスポート後、移行先の環境で作成したパッケージをインポートすることで可能です。

現時点において、一括で作成したフローを別環境に移行する方法はないため、個別に作成したフローを移行する必要があります。

 

詳細な移行手順を以下で紹介します。

 

1) 移行元 Microsoft Flow のサイトから マイ フロー に移動します。

2) 移行対象のフローを選択し、エクスポート – パッケージ (.zip) を選択します。

 

image

 

3) エクスポート パッケージ 画面で、必要項目を入力後、[エクスポート] を選択し、任意のパスに保存します。

 

image

 

4) 移行先 Microsoft Flow のサイトから マイ フロー に移動します。

5) [インポート] を選択し、3) でエクスポートしたフローのパッケージ(.zip)をロードします。

6) パッケージにのインポート 画面で、必要項目を設定後、[インポート] を選択し、移行元のフローを移行先にインポートします。

 

image

 

image

 

7) 移行先 Microsoft Flow のサイト の マイ フロー 上に、インポートしたフローが存在することを確認します。

 

image

 

 

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

Office 365 のご契約におけるサポート範囲について

$
0
0

 

いつも Office 365 をご利用いただきありがとうございます。
本日は、Office 365 サポート (特に Microsoft Flow 並びに PowerApps) をご利用されているみなさまへ、サポートのご案内を申し上げます。


2016 年 11 月よりスタートしました Microsoft Flow 並びに PowerApps につきまして、Microsoft Flow は、Microsoft Office SharePoint Designer 、PowerApps は InfoPath の後継の位置づけとして登場しました。


Microsoft Office SharePoint Designer、並びに、 InfoPath は、お問い合わせの内容がお客様のご要望に沿ったご支援が必要となることから、Office 365 の無償サポートにおけるサポートは範囲外となり、 時間単位課金制のプレミアサポートでのお問合せを頂いておりました。


Premier サポート - Microsoft Services
https://www.microsoft.com/ja-jp/services/premier.aspx


Office 365 の Microsoft Flow 並びに PowerApps についても、Microsoft Office SharePoint Designer、並びに、 InfoPath の後継の位置づけとなりますため、基本的なサポート範囲の考え方は、同等となります。
サポートをご利用いただくお客様より、この点について明文化してほしいというご要望の声を数多く頂いている状況でございますので、本記事を公開致しました次第です。


今後、弊社サポートをご利用いただくにあたっての判断基準となれば幸いです。
なお、弊社にてお問合せをお受付した結果、Office 365 の無償サポートご契約では十分なご支援ができない内容につきましては、弊社サポートエンジニアよりプレミアサポートのご案内を差し上げます。
お問わせの内容が無償サポート範囲内かプレミアサポート相当かの判断が難しい案件などの場合は、気軽にお問い合わせください。


============================================================
■ Microsoft Flow 並びにPowerApps における Office365 無償サポートのご支援範囲について

============================================================

Microsoft Flow 並びにPowerApps における Office 365 の基本的なご支援内容は、一般的なトラブルシューティング (公開情報、事例の調査)、基本的な操作のご案内となります。
下記のような内容はプレミアサポートの利用をご検討ください。


1. Microsoft Flow 並びに PowerApps のご要望に応じた作成方法について、弊社テンプレートに用意されておらず、事例や公開情報にない場合のお問合せ
2. ご要望の方法における実現の可否のお問合せ
3. エラーに基づく原因究明のお問合せ
4. 仕様確認のお問合せ
5. お客様の環境のみで発生する環境固有の問題

など


例を挙げますと、公開された資料に基づく PowerApps の利用方法をご案内することは、本ご契約にて可能でございます。
しかしながら、「PowerApps で、SharePoint のデータを利用して、会社のユーザーが棚卸ができるようなアプリを作成したい」といったようなご要望の場合、プレミアサポートにてご支援を提供しております。
同様に、基本的にお客様にて作成されているアプリやフローにて発生するエラーについても、 Office365 無償サポートにてご支援可能な範囲は、公開情報や事例を基にした対処方法の調査となります。
従いまして、公開情報や事例を基にした対処方法は調査済みである場合などは、プレミアサービスの利用をご検討ください。なお、原因調査をご要望頂いた場合、Office 365 の基本サポートでは、原因追及の調査は致しておりませんため、時間単位課金制のプレミアサポートにて改めてお問合せください。


クラウドサポートについては下記もご参考になるかと存じますので、ご一読下さい。


クラウドサポートをご利用いただく際の留意点
https://answers.microsoft.com/ja-jp/msoffice/forum/msoffice_o365admin-mso_other-mso_o365b/%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%82%B5/76135b84-3412-451f-b7e3-dfe7ec957e61


以上となりますが、弊社としましては、ご契約に沿った最大限のご支援を継続させて頂きます。
度重ねてのご案内となりますが、お問合せ内容について、お客様にてご判断がつかない場合は、弊社サポートにお気軽にお問合せ下さい。弊社にてお問合せ内容に即した窓口をご案内させて頂くとともに最大限のご支援をさせて頂きます。
今後とも弊社製品並びにサポートをご愛顧のほど、よろしくお願い申し上げます。


============================================================
■ 参考情報

============================================================

<はじめて Microsoft Flow / PowerApps をご利用される方>


Microsoft Flow のガイド付き学習
https://docs.microsoft.com/ja-jp/flow/guided-learning/


PowerApps の概要
https://powerapps.microsoft.com/ja-jp/tutorials/getting-started/


PowerApps のガイド学習
https://powerapps.microsoft.com/ja-jp/guided-learning/


現在、ご要望に沿った作成方法における日本語の公開情報が少なくご不便をお掛けしております。
今後、公開情報やブログによる参考情報の拡充に努めてまいります。



※ 本Blogの内容は、2017年11月現在の内容となっております。今後予告なく変更される可能性がございます事、ご了承下さいますようお願い致します。

[Azure Stream Analytics] TRY_CAST の利用

$
0
0

BI Data Platform (SQL Server) Support Team 山崎実久

Azure Stream Analytics のジョブを実行中、SQL Database への出力が行われず、以下のようにデータ型変換の警告が表示される場合があります。

cve11 (002)   cve10 (002)

Warning の抜粋
---------------------
Encountered error trying to write 1 event(s): Cannot convert from property 'c2' of type 'System.String' to column 'c2' of type 'System.DateTime
---------------------

Azure Stream Analytics では、”Error Policy” が既定の “Retry” に設定されている場合、出力になんらかのエラーが出ると、job をリトライし続けます。その結果、何度も入力のデータを参照することになり、Input Events は上昇し、リソースの利用状況を表す SU % Utilization もそれに伴い上昇します。最終的にリソースを使い切り、ジョブが停止することがあります。

不正な入力データが発生しない対処を行うのが一番ですが、このデータ型変換エラーが発生するような入力が来た場合もエラーを回避し出力を行うために、以下のように Azure Stream Analytics のクエリに TRY_CAST の関数を追加する対応をとることができます。

TRY_CAST() を利用することで、CAST のエラーをハンドリングすることができます。TRY_CAST() では、キャストが成功した場合は指定されたデータ型にキャスト値を返します。それ以外の場合は NULL を返します。

(例)
---------------------
SELECT
    c1,
    TRY_CAST(c2 as datetime) as c2
INTO
    [sqldbout]
FROM
    [blobin]
---------------------


+ 参考情報
TRY_CAST (Azure Stream Analytics)
https://msdn.microsoft.com/library/en-us/Mt643735.aspx

 

※ 本ブログの内容は、2017年12月時点の情報です。

以上、お役に立てたら幸いです。

SQL Server アップグレードパスについて

$
0
0

皆さん、こんにちは。 BI Data Platform サポートチームです。今回は SQL Server のアップグレードパスについてご紹介いたします。

アップグレードパスにつきましては、弊社では以下のような技術情報を公開いたしております。(下記の技術情報は SQL Server 2016 へのアップグレードパスに関する情報です。)

 

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

URL      : https://docs.microsoft.com/ja-jp/sql/database-engine/install-windows/supported-version-and-edition-upgrades

 

上述の公開情報は、同一サーバーにおけるアップグレードパス (インプレース アップグレード) に関し記載しているものであり、別サーバーへのデータベース移行によるアップグレード (マイグレーション) の場合には該当いたしません。

例えば、上述の公開情報によるインプレース アップグレードでは、SQL Server 2014 Standard Edition から SQL Server 2016 Express Edition はサポートされていないアップグレードパスである為、アップグレードを実施した場合には失敗します。一方、マイグレーションによるアップグレードの場合には、上述の公開情報には該当しない為、SQL Server 2014 Standard edition から別のサーバーの SQL Server 2016 Express Edition へのデータ移行によるアップグレードは成功いたします。

つまり、マイグレーションによるアップグレードの場合には、上述の公開情報のパスを意識する必要はなく、下位のエディションにもアップグレードが可能となります。また、公開情報にあるアップグレード元のサービスパックの適用条件も考慮する必要はありません。

ただし、移行先となる SQL Server のエディションによる制限 (例えば、Express Edition の場合では 1 データベースに対し、最大 10 GB の容量制限) には該当いたしますので、移行先の SQL Server のエディションが移行元より下位の場合には特に注意が必要です。また、一度上位のバージョンにアップグレードしたデータベースは、下位のバージョン環境にリストアする事ができません。

なお、上記の類似内容は以下にご案内する自習書に記載がございますので、併せてご確認いただけると幸いに存じます。

 

タイトル : SQL Server 2016 実践シリーズ No.1

URL      : http://download.microsoft.com/download/F/7/1/F71B2DD9-D68F-4F50-92B5-3BC4688FACC8/SQL13_Adv01_Upgrade.pdf

項目 : 移行可能なデータベース

 

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

 

Power BI のサポート範囲について

$
0
0

こんにちは。

Power BI Service Power BI Desktop をご利用のお客様が弊社にお問い合わせいただく際に、ご利用いただけるサポートサービスがいくつかございます。

適切なサービスをご利用いただくことで、より効果的にサポートの提供が可能となるため、この場を借りて事前にそれぞれのサービスについて、ご説明いたします。

それぞれのサービスが提供するサポート内容についてご理解いただき、ご選択いただければ幸いです。

 

はじめに

Power BI のサポートは、ご利用のライセンスに基づきます。各ライセンスでのサポート範囲は下記のとおりです。

 

Power BI 無料ライセンス 

Power BI 無料ライセンスをご利用のお客様は、フォーラムなどの英語のみのコミュニティサポートを受けることができます。コミュニティサポートですので、ご質問に対して回答するのは弊社エンジニアではなく、同じくコミュニティをご利用されている他のユーザーになります。

 

Power BI Pro ライセンス

Power BI Pro ライセンスをご利用のお客様は、インストール・セットアップ、基本操作方法のご支援に加え、公開情報を基本に一般的なトラブルの解決などに関する対処方法を一問一答形式で、弊社の専任エンジニアがサポートします。

 

Power BI のライセンスにてサポートされる範囲は以上となります。無償サポート範囲内のため、サポートを受ける料金は発生いたしません。

なお、 Power BI Pro の無償のお問い合わせの対応範囲、並びに、上位サポートのプレミアサービスでのご支援内容については、下記の記事を公開しておりますので、合わせてご参照ください。

 

Office 365 のご契約におけるサポート範囲について

https://blogs.msdn.microsoft.com/jpsql/2017/11/30/office365support/

 

有償プロフェッショナルサポート契約

Power BI Pro ライセンスを購入せず、専任サポートエンジニアの支援をご要望頂きます場合、並びに、Power BI Report Server の試用版の支援をご要望いただきます場合は、弊社有償プロフェッショナルサポート契約をご契約いただくことでオンデマンドでご支援が可能です。

有償サポートにつきましては、下記をご参照ください。

#プレミアサポート契約をお持ちのお客様は、プレミアサポート契約を利用してお問い合わせいただくことも可能です。

 

プロフェッショナル サポート

https://www.microsoft.com/ja-jp/services/professional.aspx

 

本コンテンツが、今後、弊社サポートをご利用いただく際の参考になれば幸いです。

 

Viewing all 293 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>