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

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

$
0
0

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

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

 

サービス
パック

更新プログラム

バージョン

リリース年月

SQL Server 2016

RTM KB 3182270 (CU2)

13.0.2164.0

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

SQL Server 2014

SP2

KB 3178925 (CU1)

12.0.5511.0

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

SQL Server 2012

SP3

KB 3180915 (CU5)

11.0.6544.0

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

SQL Server 2008 R2

SP3

無し

10.50.6000.0

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

SQL Server 2008

SP4

無し

10.0.6000.0

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

 

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

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

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


[SSRS] 例外の詳細: ‘3’の InvalidArgument=Value は ‘SelectedIndex’に対して有効ではありません。

$
0
0

SQL Server Developer Support Team

米内 満

 

こんにちは!
今日は、Windows Server 2008 をご利用のお客様において確認できました稀な事象についてご紹介いたします。

 

[事象]

SQL Server Reporting Services 構成マネージャーから、任意のインスタンスに接続後、[サービスアカウント] ページを選択するとエラーが発生します。

 

参考画像 A

clip_image002

 

エラー

パネルの切り替え中にエラーが発生しました。WMI プロパティの取得中に発生したエラーが原因である可能性があります。例外の詳細:

‘3’ の InvalidArgument=Value は ‘SelectedIndex’ に対して有効ではありません。

パラメータ名: SelectedIndex

 

参考画像 B

clip_image003

 

[発生条件]

以下の条件により発生する事象となります。

Windows Server 2008 + SQL Server 2012 以降

Reporting Services のインストール時に、Reporting Services のサービス アカウントを Local Service に設定する

 

[要因]

Reporting Services 2012は、仮想アカウント (後述参照) が利用可能であることを前提としております。

しかしながら、Windows Server 2008 には仮想アカウントが存在しないため、サービスアカウント情報を表示させるドロップダウン リストのインデックス(仮想アカウントがある前提で並べられています) が不正となり、エラーとなります。

Windows Server 2008 R2 以降では仮想アカウントが存在するため、本エラーは発生しません。

 

■仮想アカウントについて

Windows Server 2008 R2 および Windows 7 の仮想アカウントは、サービスの管理を簡単にするために次の機能を提供する、管理されたローカル アカウントです。 仮想アカウントは自動的に管理され、ドメイン環境でネットワークにアクセスすることができます。

 

詳細につきましては、下記をご参考下さい。

Windows サービス アカウントと権限の構成

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

 

[対処策]

事前予防策

Reporting Services をインストールする際、Reporting Services のサービス アカウントに既定の Network Service もしくは、ドメイン ユーザー アカウントを利用します。

 

事後対処策

直接インストールした Reporting Services のサービス アカウントを Local Service から Local System に変更します。

 

<詳細手順>

1. [スタート]-[コントロール パネル]-[管理ツール]-[サービス] にて事象が発生する SQL Server Reporting Services (任意のインスタンス) を確認します。

 

SA3

 

2. 該当のサービスにて、右クリック [プロパティ] をクリックし、表示されたプロパティ画面で [ログオン] タブをクリックします。

3. “ログオン” をローカル システム アカウントに設定し、OK をします。

 

clip_image005

 

4. サービスアカウントを変更した Reporting Services サービスを再起動します※ 再起動されるまでは反映されません。

5. Reporting Services 構成マネージャーを起動し、サービスアカウントがエラーなく確認できるか確認します。

 

[補足事項]

ローカル アカウントを利用する場合には、本事象に関わらず注意点があります。

 

詳細については、下記公開情報の”ローカル アカウントの使用に関する注意点″ の項目をご参照ください。

 

レポート サーバー サービス アカウントの構成 (SSRS 構成マネージャー)

https://msdn.microsoft.com/ja-jp/library/ms160340.aspx

 

以上です。参考になりましたら、幸いです。

2016 年 10 月 SQL Server 最新モジュール

$
0
0

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

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

サービス
パック

更新プログラム

バージョン

リリース年月

SQL Server 2016

RTM KB 3182270 (CU2)

13.0.2164.0

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

SQL Server 2014

SP2

KB 3188778 (CU2)

12.0.5522.0

2016/10
メインストリームサポート

SQL Server 2012

SP3

KB 3180915 (CU5)

11.0.6544.0

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

SQL Server 2008 R2

SP3

無し

10.50.6000.0

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

SQL Server 2008

SP4

無し

10.0.6000.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 における分散トランザクション 1

$
0
0

 

神谷 雅紀
Escalation Engineer

 

 

分散トランザクション

分散トランザクションとは、複数のリソースマネージャーで実行されるトランザクションを、ひとつのトランザクションとして実行するトランザクションです。

 

image

 

 

リソースマネージャー

リソースマネージャー (RM) とは、トランザクションによって更新されるデータを管理しているコンポーネントです。通常は、SQL Server や Oracle などのデータベース管理システムです。

 

トランザクションマネージャー

トランザクションマネージャー (TM) とは、トランザクションを管理し、各リソースマネージャーに対してトランザクションに関する指示を出すソフトウェアコンポーネントです。SQL Server は、トランザクションマネージャーとして、Microsoft Distributed Transaction Coordinator (分散トランザクションコーディネーター / MS DTC) を使用します。

 

SQL Server における分散トランザクション実行時のソフトウェア構成

SQL Server やアプリケーションは、MS DTC Proxy を使用して MS DTC とのやり取りを行います。

最も一般的な形は次の図のように、それぞれの Windows で動作している MS DTC を使用して分散トランザクションを実行します。

尚、通常リソースマネージャは複数 (上図のように右側のサーバーが複数ある構成) になりますが、以下の図は簡略化のためにリソースマネージャをひとつとしています。

 

image

 

ローカル MS DTC を使用するように構成されている Windows では、使用する MS DTC をアプリケーションコードの中で指定し、Windows の設定を上書きすることができます。アプリケーションによって明示的に指定されていない場合やリモート MS DTC を使用するように構成された Windows では、その設定に従います。設定は、[コンピューターの管理]  – [コンポーネントサービス] – [マイコンピューター] の [プロパティ] で行います。

 

image

 

この設定を変更することで、リモート MS DTC を使用するように構成することも可能です。

リモート MS DTC を使用する構成が有効な場合については、SQLCATのブログを参照してください。

https://blogs.msdn.microsoft.com/sqlcat/2010/05/11/resolving-dtc-related-waits-and-tuning-scalability-of-dtc/

 

 

image

 

分散トランザクションの流れ

1) SQL Server と MS DTC 間の接続確立

SQL Server は、起動時または最初に分散トランザクションが実行された時に、MS DTC Proxy を通じて MS DTC に接続します。この時、自分自身のインスタンスを識別するための固有のリソースマネージャー ID を渡します。AlwaysOn 可用性グループが DTC_SUPPORT = PER_DB に設定されている場合は、各プライマリーレプリカごとに固有のリソースマネージャ ID を渡します。

MS DTC とのセッションが確立すると、MS DTC の情報を取得します。その中には MS DTC が動作しているコンピューターの名前も含まれます。

 

image

 

このような初期化処理が終わると、Errorlog には以下のようなエントリが記録されます。

 

2016-10-19 17:05:32.37 spid116     Initializing Microsoft Distributed Transaction Coordinator (MS DTC) resource manager [df796691-315b-4dd2-9acd-11ad222e1e58] for server instance Server1\SQL16. This is an informational message only. No user action is required.

 

– MS DTC への接続は DtcGetTransactionManager を呼び出すことで行います。
– MS DTC の情報の取得は、
ITransactionImportWhereabouts::GetWhereabouts で行います。

 

2) アプリケーションと MS DTC 間の接続確立

アプリケーションも MS DTC Proxy を通じて MS DTC に接続します。

 

3) アプリケーションによるトランザクションの開始

アプリケーションは、MS DTC に対して、トランザクションの開始を通知します。

 

image

 

– トランザクションの開始は、ITransactionDispenser::BeginTransaction を呼び出すことで行います。
– アプリケーションは、開始されたトランザクションを表す ITransaction オブジェクトを受け取ります。

 

4) アプリケーションによる SQL Server 側 MS DTC 情報の取得

アプリケーションは、ODBC, OLEDB, ADO.NET などを使用して SQL Server との接続を確立し、その接続を通じて SQL Server 側 MS DTC の情報を取得します。SQL Server がアプリケーションに渡す情報は、1) で取得した MS DTC の情報です。

この時、SQL Server でトレースを採取していると、DTCTransaction\Get address トレースイベントおよび dtc_transaction\Get address 拡張イベントが生成されます。

 

image

 

5) アプリケーションによる SQL Server 側 MS DTC へのトランザクションエクスポート

アプリケーションは、SQL Server 側 MS DTC にトランザクションをエクスポートするようにアプリケーション側 MS DTC に指示します。加えて、トランザクションオブジェクトの cookie を取得し、SQL Server との接続を通じて、それを SQL Server に渡します。

 

image

 

– アプリケーションによるトランザクションのエクスポートは、ITransactionExportFactory::Create によって ITransactionExport を取得し、ITransactionExport::Export によって行います。
– cookie の取得は、ITransactionExport::GetTransactionCookie により行います。

 

6) SQL Server のトランザクションへの参加

SQL Server は、cookie を受け取ると、その cookie を使用して、トランザクションをインポートし、トランザクションに参加します。

この時、Enlisting in a DTC transaction, Propagate Transaction イベントが生成されます。

 

image

 

– トランザクションのインポートは、ITransactionImport::Import によって行います。
– トランザクションへの参加は、
IResourceManager::Enlist によって行います。Enlist には SQL Server により実装されている callback インターフェース ITransactionResourceAsync が渡されます。
– sys.dm_tran_active_transactions の transaction_uow に示される Unit Of Work (UOW) は
ITransaction::GetTransactionInfo によって取得される XACTTRANSINFO に含まれています。

 

6) アプリケーションによるデータ更新

アプリケーションは、開始したトランザクション内でデータ更新等のトランザクションを実行します。

 

7) トランザクションのコミット (2 フェーズコミット)

7-1) アプリケーションは、アプリケーション側 MS DTC に対して、トランザクションのコミットを要求します。

7-2) アプリケーション側 MS DTC は、SQL Server 側 MS DTC に対して、トランザクションのコミットの準備を要求し、その要求は SQL Server に対しても行われます。(フェーズ 1)

この時、Preparing Transaction イベントが生成されます。

 

image

 

– アプリケーションは、トランザクションをコミットするために ITransaction::Commit を呼び出します。

 

7-3) SQL Server がコミットの準備を完了すると、SQL Server は SQL Server 側 MS DTC に対してコミットの準備が完了したことを通知し、その通知はアプリケーション側 MS DTC にも通知されます。

 

image

 

7-4) 準備完了通知を受け取ったアプリケーション側 MS DTC は、SQL Server 側 MS DTC に対してトランザクションのコミットを要求し、その要求は SQL Server に対しても行われます。(フェーズ 2)

この時、Transaction is committing イベントが生成されます。

 

7-5) SQL Server でのコミットが完了すると、その完了が SQL Server 側 MS DTC に通知され、それはアプリケーション側 MS DTC にも通知されます。

– MS DTC は、SQL Server の ITransactionResourceAsync::PrepareRequest および ITransactionResourceAsync::CommitRequest を呼び出すことで、SQL Server に準備およびコミットを要求します。
– 準備、コミットの完了は、それぞれ
ITransactionEnlistmentAsync::PrepareRequestDone
ITransactionEnlistmentAsync::CommitRequestDone によって MS DTC に通知します。

 

7-6) アプリケーション側 MS DTC から アプリケーションに対して、コミットの完了が通知されます。

 

以上が分散トランザクションが開始されてから終了するまでの流れです。

 

次回以降で、トランザクションのロールバック、MS DTC が停止や再起動した場合、SQL Server が停止や再起動した場合、フェールオーバークラスター環境、可用性グループ環境などを取り上げる予定です。

 

 

 

 

 

 

 

 

 

 

Microsoft Flow/PowerApps (Dynamics 365)の非表示について

$
0
0

こんにちは。SQL Server サポートチームです。

マイクロソフトの新たなサービスとして、Microsoft Flow と PowerAppsが最近リリースされました。すでにご購入されている契約に Flow やPowerApps のライセンスが含まれる場合には、これらのサービスが自動的に Office 365 のポータルやアプリケーションランチャーに表示されています。(Dynamics 365 も含む)
こちらについては以下の設定を行うことで非表示にすることができます。こちらが少しでも参考になれば幸いです。

 

Q1. PowerApps と Flow のアイコンを非表示したい(ポータル/アプリランチャー)。どうすればよいか?

A1. ユーザーからライセンスをはく奪すると、ポータル、アプリランチャーからアイコンが消えます。ただ、アプリランチャーの非表示には時間がかかる場合があります。その場合は、一旦サインアウトいただき、再度サインインをお願い致します。

 

[詳細手順]

1. Office 365 Admin Portal “https://portal.office.com/adminportal/home#/homepage/” に接続します。

2. 左のナビゲーションバーにある [ユーザー] – [アクティブなユーザー] をダブルクリックし、PowerApps と フロー のアイコンを非表示したいユーザーをダブルクリックします。

clip_image001

 

3. ライセンスの管理画面が表示されるので、製品ライセンスの 編集 をクリックします。

clip_image002

 

4. Office 365 の左側を展開して Office 365 向けフローと PowerApps を確認後、それぞれのライセンスを OFF にします。

clip_image003

 

5. 無償版を利用した場合は、 Microsoft Power Apps & Flow が表示されているので、ライセンスを OFF にします。

その後、保存ボタンをクリックします。

clip_image004

 

 

+ 参考情報(英語表記となります)

PowerApps in your organization Q&A

https://powerapps.microsoft.com/en-us/tutorials/signup-question-and-answer/

———————-

How do I remove PowerApps for users that already signed up?

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

The How do users sign up for PowerApps section (in this topic) outlines the two possible ways that users can sign up for PowerApps. A separate step is required to remove users that already signed up through each flow.

If a user signed up for PowerApps through sign up flow Option 1 (in which the user goes to powerapps.microsoft.com and then selects Sign up free) but you no longer want them to have access to PowerApps, you can remove the PowerApps license for that user:

1.Go to the Office 365 Admin Portal.

2.In the left navigation bar, select Users, and then select Active Users.

3.Find the user you want to remove the license for, and then select their name.

4.On the user details page, select Licenses in the left navigation bar.

5.Clear Microsoft PowerApps, and then select Save.

If any users signed up for PowerApps through Option 2 (in which the user goes to powerapps.microsoft.com and selects Sign In) but you no longer want them to have access to PowerApps, file a support request.

———————-

 

Q2. 多くのユーザーに対して一括で PowerApps と Flow のアイコンを非表示したい(ポータル/アプリランチャー)。どうすればよいか?

A2. PowerShell を利用して、テナントに登録したユーザーに対し一括でPowerApps と Flow のライセンスを無効にし、アイコンを非表示にすることができます。

 

詳細手順
========

Office365向けフロー、Office365向け PowerApps を Powershell を利用して一括で制御する方法は下記の通りです。

この操作を実施することで、ポータル/アプリランチャーから、Office365向けフロー、Office365向け PowerApps のアイコンが非表示になります。

また、 Office365向けフロー、Office365向け PowerApps のライセンスがテナント全体で OFF になります。

ご利用のプランにより、ライセンス名、サービスプランが異なりますので、ご注意ください(下記の「プラン毎のライセンス名/サービスプラン名一覧」に情報を纏めましたので、ご参考ください)。

事前準備

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

こちらの手順について、すでに最新の Azure Active Directory PowerShell がインストールされている場合は、飛ばしていただいて問題ございません。

PowerShell のコマンドレット実行にあたって、以下が事前に実行されている事が必要でございます。

Microsoft Online Services Sign-In Assistant for IT Professionals RTW のインストール

Azure Active Directory Module for Windows PowerShell (64 ビットバージョン) のインストール

下記の Microsoft ダウンロード センターから、各種ツールをインストールします。OS に合わせて、32 bit 用か、64 bit 用 (推奨) をお選びください。

タイトル : IT プロフェッショナル 用 Microsoft Online Services サインイン アシスタント RTW

アドレス : https://www.microsoft.com/ja-jp/download/details.aspx?id=41950


タイトル : Windows PowerShell 用の Azure Active Directory モジュール (64 ビット版)

アドレス : http://go.microsoft.com/fwlink/p/?linkid=236297


タイトル : Windows PowerShell 用の Azure Active Directory モジュール (32 ビット版)

アドレス : http://go.microsoft.com/fwlink/p/?linkid=236298

Power Shell のご利用におきましては、32 ビット バージョンのサポートがすでに終了しておりますことから、64 ビット バージョンのご利用を推奨いたします。


<参考情報>

Azure AD (Office 365) の管理のための Windows PowerShell の導入に関しては以下のページでご案内しておりますのでご参考いただければ幸いでございます。


タイトル : Windows PowerShell による Azure AD の管理

アドレス : https://msdn.microsoft.com/ja-jp/library/azure/jj151815.aspx


—–以下抜粋—–

2014 年 10 月 20 日をもって、Azure Active Directory Module for Windows PowerShell (32 ビット バージョン) は廃止されます。32 ビット版のサポートはこれ以上行われず、Azure Active Directory Module の今後の更新は 64 ビット版についてのみリリースされます。将来のサポートと互換性のため、64 ビット版をインストールすることを強くお勧めします。

——————-


ライセンスの一括削除方法

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

ラインセンスの一括削除方法は下記の通りです。

下記では Enterprise E3 のプランにおける一括削除方法をご案内しております。

1. 管理者として Powershell を起動します。

2. 資格情報を入力します。

下記のコマンドを入力します。

$credential = Get-Credential

1). Windows PowerShell 資格情報の要求ダイアログボックスが表示されます。

O365 管理者のユーザー名とパスワードを入力します。

clip_image002


2). 意図したユーザーで資格情報が入力されているか確認します(省略可能な手順です)。

下記のコマンドを入力することで確認できます。

$credential

3). MsOnline サービスに先ほど入力した資格情報を引き渡します。

下記を入力します。

Import-Module MsOnline

Connect-MsolService -Credential $credential

4). アクセス先のドメインを確認します。

下記を入力し、目的のドメインであるか確認します。

Get-MsolDomain

3. ライセンスを確認します。

現在のテナントで有効となっているラインセンスを確認します。

下記を入力します。

Get-MsolAccountSku

例えば下記のような結果が返された場合、ライセンスとして「ENTERPRISEPACK」(= Enterprise E3)を利用していることを確認できます。

後ほどの手順で利用するので、ドメイン名から記録しておきます(下記では o365xxxx:ENTERPRISEPACK が該当します)。

clip_image004

4. サービスプランを確認します。

現在のテナントで利用しているサービスプランを確認します。

下記を入力します。

#結果が返されるまでに、少し時間がかかる可能性があります。

例えば、下記のような結果が返されます。

Enterprise E3 においては、 FLOW_O365_P2 が Office365向けフロー、POWERAPPS_O365_P2 が Office365向け PowerApps のサービスとなります。

Office365向けフロー、Office365向け PowerApps のサービスプラン名は、ご利用のライセンスにより異なります。

clip_image006


参考情報

————

E3 のみのサービスプランを確認したい場合、下記のコマンドを実行することでフィルタした内容で確認が取れます。

下記を入力します。

$SStatus = Get-MsolAccountSku | where {$_.SkuPartNumber -eq “ENTERPRISEPACK”}

$SStatus.ServiceStatus

例えば、下記のような結果が返されます。

clip_image008


5. Office365向けフロー、Office365向け PowerApps のライセンス を一括で削除します。

上記で確認したライセンス名とサービスプラン名をもとに、ライセンスオプションを作成し、全てのユーザーに適用します。

下記のコマンドを環境に合わせて実行します。

$LO = New-MsolLicenseOptions -AccountSkuId “<上記手順 3 で確認したドメイン名:ライセンス名>” -DisabledPlans ” Office365向けフローのサービスプラン名”, “Office365向け PowerApps のサービスプラン名”

Get-MsolUser -All | where {$_.isLicensed -eq $true} | Set-MsolUserLicense -LicenseOptions $LO

例えば、上記の情報では、下記のようなコマンドとなります。

$LO = New-MsolLicenseOptions -AccountSkuId “o365xxxx:ENTERPRISEPACK” -DisabledPlans “FLOW_O365_P2”, “POWERAPPS_O365_P2”

Get-MsolUser -All | where {$_.isLicensed -eq $true} | Set-MsolUserLicense -LicenseOptions $LO

6. ライセンスが OFF となり、ポータル/アプリランチャーから、Office365向けフロー、Office365向け PowerApps のアイコンが非表示となっているか確認します。

表示が変わらない場合、サインアウト/サインインを実施して表示に変化があるかご確認ください。

プラン毎のライセンス名/サービスプラン名一覧

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

上記コマンドで確認するライセンス名、サービスプラン名は、プラン毎に異なります。

それぞれのプランにおける一覧を下記に纏めておりますので、コマンド実行結果の確認、並びに、コマンド生成時にご参考になれば幸いです。

プラン

ライセンス名

サービスプラン

 
   

Office365向けフロー

Office365向け PowerApps

Enterprise E1

STANDARDPACK

FLOW_O365_P1

POWERAPPS_O365_P1

Enterprise E3

ENTERPRISEPACK

FLOW_O365_P2

POWERAPPS_O365_P2

Enterprise E5

ENTERPRISEPREMIUM

FLOW_O365_P3

POWERAPPS_O365_P3

Windows 8 以降の MSXML2.DOMDocument の使用方法

$
0
0

皆さん、こんにちは。 BI データプラットフォームサポートチームです。
SQL Server を中心にサポートを提供していますが、データアクセスなどのテクノロジーなども対応していますので、今回は Microsoft XML Core Services (MSXML) を扱いたいと思います。

はじめに

MSXML は OS や Office などに同梱されている XML のパーサー機能です。
実ファイルとしては、DLL の形でSystem32 ディレクトリ (32bit モード用のモジュールは SysWOW64) に格納されています。
OS に同梱されており、基本的に追加インストールが不要なため、本 DLL を Office のマクロ機能などでご活用されている方も多くいらっしゃるかと思います。
最近、そういったユーザー様から、Windows 10 に移行した後から、MSXML 機能を使用するマクロが使えなくなったなどのお問い合わせを頂くことがあるため本ブログ記事にて詳細を説明したいと思います。

事象

Windows 7 環境などで問題なく稼働していた MSXML 機能を使うアプリケーション/マクロなどを、Windows 8 以降の環境で動作させようとすると下記のエラーが発生し、動作させることが出来ません。

コンパイルエラー: ユーザー定義型は定義されていません

例えば Word や Excel のマクロの参照設定で “Microsoft XML, v6.0″ を次のように選択し、マクロコード内で MSXML2.DOMDocument 型を使用している場合に本事象が発生します。
msxml6_pic1

原因

本事象の原因は、Windows 8 以降の MSXML (msxml6.dll) に MSXML2.DOMDocument型が存在しないことが原因です。
MSXML2.DOMDocument 型は、Windows 7 環境までは DLL に含まれていましたが、Windows 8 以降では含まれていません。
これは、MSXML2.DOMDocument 型は MSXML 3.0 が持つMSXML バージョンに依存しない動作を実現するための機能であり、MSXML 4.0 以降本機能は廃止されています。
英語ドキュメント、および、日本語機械翻訳しかないため少しわかりにくいですが、下記のドキュメントに記載があります。

 

What’s New in MSXML
https://msdn.microsoft.com/en-us/library/ms753751.aspx (英語原文)
https://msdn.microsoft.com/ja-jp/library/ms753751.aspx (日本語機械翻訳)

What’s New in MSXML 4.0

Version-Independent ProgIDs Removed

Version-independent ProgIDs were available in MSMXL and earlier releases and appeared such as the following when used in JScript code:

var xmldoc = CreateActiveXObject(“MSXML2.DOMDocument”)

or in Visual Basic code as:

Dim xmldoc As New MSXML2.DOMDocument

These types of version-independent ProgIDs are now removed with MSXML 4.0 and later versions.
This guarantees that MSXML 4.0 and later versions of MSXML will not interfere with any versions of MSXML (2.0, 2.6, or 3.0) previously installed.
If you use the previous examples in your code, you will not instantiate the MSXML 4.0 DOM, but instead the prior replace-mode versions of the MSXML parser (MSXML 3.0 or earlier depending on the version of Windows or other installed applications on the system that use MSXML).

If you want to use MSXML 4.0, you must create a DOMDocument object in JScript like this:

var xmldoc = CreateActiveXObject(“MSXML2.DOMDocument.4.0”)

Accordingly, for C++ and Microsoft Visual Basic you will create “MSXML2.DOMDocument40”.
Similar changes will be necessary with all other MSXML objects in order to use the MSXML 4.0 version.

 

対処策

MSXML2.DOMDocument ではなく、MSXML2.DOMDocument60 のように明示的にバージョンを指定するよう、アプリケーションやマクロを改修します。
これは、OS (Windows 10 環境や Windows 7 環境など) や MSXML を使用するアプリケーションの種類に関わらず、MSXML 6.0 を使用する環境/アプリケーションで同様です。

 

参考情報

What’s New in MSXML
https://msdn.microsoft.com/en-us/library/ms753751.aspx (英語原文)
https://msdn.microsoft.com/ja-jp/library/ms753751.aspx (日本語翻訳)

Installing and Redistributing MSXML
https://msdn.microsoft.com/en-us/library/cc507432.aspx (英語原文)
https://msdn.microsoft.com/ja-jp/library/cc507432.aspx (日本語翻訳)

List of Microsoft XML parser (MSXML) versions
https://support.microsoft.com/en-us/kb/269238 (英語原文)
https://support.microsoft.com/ja-jp/kb/269238 (日本語翻訳)

2016 年 11 月 SQL Server 最新モジュール

$
0
0

2016 年 11月 18日 時点の SQL Server 最新モジュールです。

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

サービス
パック

更新プログラム

バージョン

リリース年月

SQL Server 2016

SP1

無し

13.0.4001.0

2016/11
メインストリームサポート

SQL Server 2014

SP2

KB 3188778 (CU2)

12.0.5522.0

2016/10
メインストリームサポート

SQL Server 2012

SP3

KB 3194992 (CU6)

11.0.6567.0

2016/11
メインストリームサポート

SQL Server 2008 R2

SP3

無し

10.50.6000.0

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

SQL Server 2008

SP4

無し

10.0.6000.0

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

 

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

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

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

番外: Microsoft Flow/PowerApps (Dynamics 365)の非表示について

$
0
0

こんにちは。SQL Server サポートチームです。

マイクロソフトの新たなサービスとして、Microsoft Flow と PowerApps が最近リリースされました。すでにご購入されている契約に Flow やPowerApps のライセンスが含まれる場合には、これらのサービスが自動的に Office 365 のポータルやアプリケーションランチャーに表示されています。(Dynamics 365 も含む)

 

こちらを一括で非表示にする方法については、下記ブログでご紹介させていただいております。

 

Microsoft Flow/PowerApps (Dynamics 365)の非表示について

https://blogs.msdn.microsoft.com/jpsql/2016/11/21/microsoft-flowpowerapps-%E3%81%AE%E9%9D%9E%E8%A1%A8%E7%A4%BA%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/

 

先のブログに関連し CSV ファイルにユーザー情報を出力して、特定のユーザーのみのライセンスを制御したいとお問合せをいただくことがございましたので、ご参考までにご案内いたします。

例えば、Enterprise E3 や E5 プランなど複数のご契約があるテナントの場合、以下のように CSV ファイルを用いて各プランごとのユーザー情報を CSV ファイルに出力し、Office365向けフロー、Office365向け PowerApps のライセンス を一括で制御することができます。

 

Azure Active Directory PowerShell をご利用いただく際のご留意点

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

1. 本ブログでご案内する内容はあくまで参考情報となります。

2. 本ブログの内容を実行いただくにあたり、環境固有に対するトラブルシュートについてはサポートいたしておりません。

3. 本ブログをご参考いただきライセンスを削除いただく場合は、事前にライセンス名をご確認いただいた上で実行してください。

 

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

◆ 1. 指定したライセンスが付与されたユーザー一覧の CSV ファイルを出力する

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

 

【コマンドレット】

Get-MsolUser -All | ForEach-Object {$upn=$_.UserPrincipalName; $dpn =$_.DisplayName; $_.Licenses | ForEach-Object {if($_.AccountSkuId -eq “ドメイン名:ライセンス名”){$upn+”,”+$dpn}}}|select @{n=”UserPrincipalName”; e={$upn}}, @{n=”DisplayName”; e={$dpn}} | Export-Csv -Encoding UTF8 “<ファイルの保存先のパス>”

【実行例】 以下の実行例では E3 プランが割り当たったユーザーを出力します

Get-MsolUser -All | ForEach-Object {$upn=$_.UserPrincipalName; $dpn =$_.DisplayName; $_.Licenses | ForEach-Object {if($_.AccountSkuId -eq “o365xxxx:ENTERPRISEPACK”){$upn+”,”+$dpn}}}|select @{n=”UserPrincipalName”; e={$upn}}, @{n=”DisplayName”; e={$dpn}} | Export-Csv -Encoding UTF8 “C:\temp\Userlist.csv” -NoTypeInformation

 

【出力例】

UserPrincipalName                  DisplayName

User01@o365xxxx.onmicrosoft.com ユーザー1

User02@o365xxxx.onmicrosoft.com ユーザー2

User03@o365xxxx.onmicrosoft.com ユーザー3

 

※ ライセンスを付け替えるユーザーのみを残して保存を行なっていただきます。

※ ネットワークに負荷が生じる恐れがございますので、作成する 1 つの CSV ファイルでは、1000 ユーザー以内で作成いただくことをおすすめいたします。

 

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

◆ 2. ライセンスオプションの作成

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

 

以下のコマンドレットにてライセンスから一部のプランを除外をする、ライセンスオプションを作成します。

以下の例では Enterprise E3 から [Microsoft Power Apps]、[Flow] を無効化する手順をご案内させていただきます。

【コマンドレット】

$<任意のライセンスオプション名> = New-MsolLicenseOptions -AccountSkuId <ドメイン名 : ライセンス名> -DisabledPlans <機能を無効化する ServicePlan>

 

【実行例】

$MY365Sku = New-MsolLicenseOptions -AccountSkuId o365xxxx:ENTERPRISEPACK -DisabledPlans FLOW_O365_P2,POWERAPPS_O365_P2

※ コマンドレットの実行結果は表示されません。

※ ライセンスオプションの付与は、現在のライセンス割り当てをすべて上書きする動作となります。

※ 上記コマンドレットは、ライセンスオプションを変数として一時的に保存するものとなりますため、PowerShell ウィンドウを閉じると、作成した情報が消滅します。

そのため、カスタマイズされたライセンスオプションは、作成後ウィンドウを閉じる前にご利用くださいますようお願い申し上げます。

 

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

◆ 3. 複数ユーザーに一括でライセンスオプションを付与する

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

 

CSV ファイルを利用して、対象のユーザーに上記手順 ◆ 2. で作成したライセンスオプションを割り当てます。

【コマンドレット】

Import-CSV “<ファイル名を含んだ保存先のパス>” | foreach { Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -LicenseOptions $<作成したライセンスオプション名> }

【実行例】

Import-CSV “C:\temp\Userlist.csv” | foreach { Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -LicenseOptions $MY365Sku }

 

以上です。参考になりましたら、幸いです。


Azure Data Catalog の登録ツールは 64 bit OSでのみ起動します

$
0
0

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

Azure Data Catalog とは?

日々データが増え、データがあることは知っているが何処にデータがあるか分からず、周りの人に来てみたり、フォルダにあるドキュメントを探ったり、もしくは Azure の Portal サイトにアクセスして Azure SQL Database の接続文字列を確認するなど、データを探すことに時間を費やすことはないでしょうか?

その問題を解決するサービスが Azure Data Catalog です。

Azure Data Catalog を利用すれば、様々な情報を一つにまとめることができ、情報を探す事よりもデータを分析する事に時間を費やすことが出来ます。

例えば、よく利用する Excel Online のシートの URL や、Azure SQL DWH の接続文字列、SQL Server や Oracle データベースの接続先の情報や、SQL Server Reporting Services のレポートの URL など様々な情報を管理し、特定のユーザーと共有し管理することができます。

+ 参考情報
Data Catalog
https://azure.microsoft.com/ja-jp/services/data-catalog/

データの登録と注意点

では、そのような解析対象のデータを Azure Data Catalog に対して登録するにはどの様にすればよいのでしょうか。

Azure Data Catalog では、現在、次の2つの方法を提供しています。

– 専用のアプリケーションを利用する (アプリケーションを起動)

– ブラウザー上から直接登録する (手動エントリの作成)

前者の専用のアプリケーションを利用することで、ブラウザーから登録する手順に比べて、GUI が充実しており簡単に登録が可能です。

ただ、64 bit アプリケーションとして開発されているため、32 bit OS 上で動作させることができません。

32 bit OS を利用してる場合、アプリケーションを起動すると以下のようなエラーが発生し登録ツールを利用することができません。その場合は、ブラウザー上から実行するか 64 bit OS を用意し実行しましょう。

image

image

以上、Azure Data Catalog の紹介と、アプリケーションの起動時の注意点をお伝えしました。お役に立てたら幸いです。

2016 年 12 月 SQL Server 最新モジュール

$
0
0

2016 年 12月 29日 時点の SQL Server 最新モジュールです。

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

サービス
パック

更新プログラム

バージョン

リリース年月

SQL Server 2016

SP1

無し

13.0.4001.0

2016/11
メインストリームサポート

SQL Server 2014

SP2

KB 3204388 (CU3)

12.0.5538.0

2016/12
メインストリームサポート

SQL Server 2012

SP3

KB 3194992 (CU6)

11.0.6567.0

2016/11
メインストリームサポート

SQL Server 2008 R2

SP3

無し

10.50.6000.0

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

SQL Server 2008

SP4

無し

10.0.6000.0

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

 

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

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

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

Troubleshooting Connectivitiy #8 –エラー番号からわかる接続失敗原因 :エラー26

$
0
0

 

高橋 理香
SQL Developer Support Escalation Engineer

みなさん、こんにちは。
このシリーズの前回のポストから2年半以上経過してしまいましたが、まだ書きたいこともあり、終了はしていません!今回は接続時のエラーのうち、特徴的なエラーである
エラー番号 26 と出力されている場合のトラブルシューティングについて紹介したいと思います。

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)

エラー 26 の主な原因

SQL Server Browser サービスへの問い合わせが失敗した場合に発生するエラーです。

接続時に SQL Server Browser サービスを使用する仕組みについては、トピック “SQL Server Browser サービス” に説明がありますが、簡単に図解すると次のようになります。


SQLBrowser

この過程の ⑦ に到達する前に何かしら問題があった場合に返されるエラーが 26 のエラーです。そのため、主な原因は以下の通りです。

  • SQL Server Browser サービスが開始されていない。
  • ファイアウォールやルーター等で UDP ポート 1434 がブロックされている。
  • 接続文字列に指定された接続先の名前解決に失敗した。
  • SQL Server Browser サービスが現在のインスタンスや待ち受けプロトコルの情報を取得できない。
    (レジストリへのアクセス権限、不適切なレジストリ設定等)

なお、既定インスタンスは TCP/IP プロトコルでは TCP ポート 1433 で待ち受けるものであると既定で判断されるため、既定インスタンスへの接続時には SQL Server Browser サービスへのアクセスは行われません。そのため、名前付きインスタンスへの接続として処理されている場合においてのみ発生するエラーです。

エラー 26 発生時にまずは確認すること!

原因はともかく、接続を成功させることを目標とする場合には SQL Server Browser サービスへを利用しない接続手法を選択することがエラー 26 への対処となります。SQL Server Browser サービスを利用するのは接続先の SQL Server インスタンスの待ち受けプロトコルや待ち受けポート番号やパイプ名がわからない場合ですので、あらかじめサーバー側のそれらの情報さえ入手できれば、次のような方法で SQL Server Browser サービスを利用せずに SQL Server インスタンスに接続することができます。

  • 接続文字列中に接続に使用するプロトコルや待ち受けのポート番号やパイプ名を明示的に指定する。
  • 接続に使用するプロトコルや待ち受けのポート番号やパイプ名を指定した別名を作成し、接続文字列ではこの別名を使用する。

参考: Troubleshooting Connectivity #5 – セッション確立までの動作 – “名前付きインスタンスへの接続で SQL Server Browser サービスは必須か” のセクション参照

上記のような対処を採用できない (たとえばアプリケーションで使用される接続文字列の変更がすぐには行えないなど) 場合には、次の順番で設定等の不足の確認や対処を行います。

  1. SQL Server Browser サービス起動状態の確認

    サービスが起動していなければ名前付きインスタンスの待ち受けプロトコルやポート番号の情報は接続処理で自動的に得ることはできません。そのため、SQL Server 構成マネージャーで SQL Server Browser サービスの稼動状態を確認し、停止している場合にはそれを起動します。
    SQLBrowser_service
  2. SQL Server 稼動環境のファイアウォール設定や通信経路上のルーター等における通信許可/拒否設定の確認

    SQL Server サービスへの問い合わせでは UDP ポート 1434 が使用されるため、ファイアウォールやルーターでこの UDP 1434 との通信がブロックされている場合には名前付きインスタンスの待ち受けプロトコルやポート番号の情報は自動的に得ることはできません。そのため、UDP ポート 1434 の通信が可能となるようファイアウォールやルーター等の設定を変更することが対処となります。
  3. 名前解決可否の確認SQL Server Browser サービスは起動しており、UDP ポート 1434 へのアクセスも可能であるはずであるにも関わらずエラーが発生する場合、名前解決に問題があって想定の SQL Server Browser サービスへの問い合わせが行われていない可能性があります。この場合にはまず最初に以下の切り分けを行います。以下の方法で成功する場合には、DNS の登録、もしくは、DNS への問い合わせに問題がないか確認し、その対処を行います。(nslookup コマンドで想定通り名前解決されているか確認するとよいでしょう。)
    • 接続文字列中の接続先にホスト名の代わりに IP アドレスを指定する。
    • Hosts ファイルに接続先の名前に対して正しい IP アドレスを指定する。
  4. ローカルマシンからの接続、別のリモートマシンからの同じ接続先への接続試行可否の確認SQL Server Browser サービスは起動状態、UDP ポート 1434 へのアクセス可能、名前解決にも問題がないにも関わらずエラーが発生する場合、SQL Server Browser サービスが何らかの要因でリクエストへの応答を返せていないことが原因となっている可能性があります。この場合、SQL Server Browser サービスへのアクセスが必要となるような接続はどのマシンからも失敗することが想定されます。この場合には詳細な調査が必要となりますので、後述の 「調査のために採取する情報」に記載の情報の収集の上、サポートへの問い合わせを検討ください。

調査のために採取する情報

エラー発生確認後の切り分け状況によりますが、原因箇所の特定を進めるにおいて必要となる情報の種類や採取手順は次の通りです。

A. 採取する情報の種類

  • BID トレース
  • ネットワーク トレース
  • PortQry コマンド実行結果
  • ping や nslookup コマンド実行結果
  • レジストリ [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server] 配下の情報
  • システム情報
  • イベント ログ
  • SQL Server エラーログ

B. 採取手順

B-1. 事前準備

<PortQry ツールの入手、配置>
あらかじめ PortQry ツールをダウンロードし、アプリケーション稼動環境と SQL Server 稼動環境にコピーしておきます。

  1. PortQry ツールを以下のサイトから任意のマシンにダウンロードします。
    PortQry Command Line Port Scanner Version 2.0
  2. SQL Server 稼動環境にダウンロードした PortQryV2.exe (自己解凍書庫形式) をのちに本ツールを実行する環境にコピーします。
  3. PortQryV2.exe をダブルクリックで実行し、展開先のパスを指定して [Unzip] します。

<BID トレース採取の各種設定>
SQL Server 稼動環境とアプリケーション稼動環境の両方で採取するため、両マシンにてそれぞれ準備を行います。
必要となる準備作業は、以下のブログに記載の 2-1 に記載の手順です。
HowTo: BID トレース – データアクセス アプリケーションのトレースを採取する

上記手順の 2-1-5 では、対象とする ETW プロバイダを以下の通り選択します。

  • SQL Server 稼動環境: SQLBROWSER.1
  • アプリケーション稼動環境: SQL Server への接続に使用するプロバイダ (*)

(*) たとえば .NET Framework のアプリケーションで System.Data.SqlClient を使用している場合や Management Studio で接続検証を行っている場合には System.Data.1 と System.Data.SNI.1 を選択します。

B-2. 事象発生時情報採取開始

<SQL Server 稼動環境での作業>

  1. 管理者権限のあるユーザーで Windows にログインします。
  2. SQL Server Browser サービスを停止します。
  3. BID トレース採取を開始します。
    以下のブログの手順 2-2 に記載の手順を実行します。
    HowTo: BID トレース – データアクセス アプリケーションのトレースを採取する
  4. SQL Server Browser サービスを起動します。
  5. 以下のコマンドでネットワーク トレース採取を開始します。
    netsh trace start capture=yes tracefile=<出力先パス>

 

<アプリケーション実行環境での作業>

  1. 管理者権限のあるユーザーで Windows にログインします。
  2. BID トレースの採取を開始します。(SQL Server 稼動環境と同様にブログの 2-2 の手順を実行します。)
  3. ネットワーク トレース採取を開始します。(SQL Server 稼動環境と同様のコマンドを実行します。)
  4. エラーを再現させます。

B-3. 事象発生時情報採取終了

<アプリケーション実行環境での作業>

  1. 以下のコマンドでネットワーク トレース採取を停止します。
    netsh trace stop
  2. BID トレースの採取を停止します。先のブログの 2-3 を実行します。

<SQL Server 稼動環境での作業>

  1. ネットワーク トレース採取を停止します。実行するコマンドはアプリケーション実行環境と同じコマンドです。
  2. BID トレースの採取を停止します。アプリケーション実行環境と同様に先のブログの 2-3 を実行します。

B-4. 調査用情報の収集

<SQL Server 稼働環境での情報収集>

  1. コマンド プロンプトを開き、PortQry を配置したフォルダに移動してから以下のコマンドを実行し、出力先に指定したファイルを収集します。
    portqry -n <SQL Server 稼動環境のホスト名> -e 1434 -p UDP -l <出力先ファイルパス>
    portqry -n <SQL Server 稼動環境の IP アドレス> -e 1434 -p UDP -l <出力先ファイルパス>
  2. 以下のブログを参考に、イベント ログ、および、SQL Server エラーログを収集します。
    [SQL Troubleshooting] 第1回 : Tips – SQL Server エラーログとイベント ログを採取する (SQL 2000 ~ 2014) Ver 2.0
  3. 以下のコマンドでシステム情報をファイルに出力し、そのファイルを収集します。
    msinfo32 /report <システム情報出力ファイルパス>
  4. レジストリ エディタ (regedit.exe) を起動し、以下のキー配下の情報をファイルにエクスポートします。[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server]
  5. 先に採取した BID トレースをブログの 2-4 の手順で変換し、元の .etl ファイルと変換後の .csv ファイルを収集します。
  6. 先に採取したネットワーク トレースを収集します。

<アプリケーション実行環境での情報収集>

  1. コマンド プロンプトを開き、以下のコマンドを実行した結果をテキストファイルに保存、もしくは、スクリーンショットを取得します。
    ping <ホスト名>
    ping -a <IP アドレス>
    nslookup <IP アドレス>
    nslookup <ホスト名>

  2. コマンド プロンプトを開き、PortQry を配置したフォルダに移動してから以下のコマンドを実行し、出力先に指定したファイルを収集します。
    portqry -n <SQL Server 稼動環境のホスト名> -e 1434 -p UDP -l <出力先ファイルパス>
    portqry -n <SQL Server 稼動環境の IP アドレス> -e 1434 -p UDP -l <出力先ファイルパス>

 

過去の Troubleshooting Connectivity シリーズはこちら。

 Troubleshooting Connectivity #1 – SQL Server への接続clip_image001

 Troubleshooting Connectivity #2 – エラー情報からわかる失敗原因

 Troubleshooting Connectivity #3 – 予期しない接続切断

 Troubleshooting Connectivity #4 – 接続エラーの調査方法

 Troubleshooting Connectivity #5 – セッション確立までの動作

 Troubleshooting Connectivity #6 – 接続タイムアウトは悪なのか?

 Troubleshooting Connectivity #7 – 接続タイムアウトエラーまでの時間は?

 

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

$
0
0

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

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

サービス
パック

更新プログラム

バージョン

リリース年月

SQL Server 2016

SP1

KB 3208177 (CU1)

13.0.4411.0

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

SQL Server 2014

SP2

KB 3204388 (CU3)

12.0.5538.0

2016/12
メインストリームサポート

SQL Server 2012

SP3

KB 3205051 (CU7)

11.0.6579.0

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

SQL Server 2008 R2

SP3

無し

10.50.6000.0

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

SQL Server 2008

SP4

無し

10.0.6000.0

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

 

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

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

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

[Azure Data Factory] パイプラインの推奨設定 –リトライ

$
0
0

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

– Azure Data Factory とは?

SQL Server では、データを移行を行う際 SQL Server Integration Services (SSIS) を利用することで、CSV ファイルのデータを SQL Server へコピーすることや、データ加工後の移行ができました。

これを Azure のクラウドで実現したものが Azure Data Factory となります。

Azure Data Factory を利用すれば、例えばローカルにある CSV ファイルや SQL Server にあるデータを Azure SQL Database や Blob Storage にコピーしたり、データ変更後の移行ができます。

サポートされる移行元のデータは、ローカルのファイル、On-Premise の SQL Server や Oracle のデータ、Azure 上の SQL Database や Data Lake Store のデータなどさまざまで、それらを Azure 上の SQL Database, BLOB Storage や DocumentDB などへのデータ移行もしくはデータ変換し保存することができます。詳細は クラウドによるデータ統合サービスである Azure Data Factory サービスの概要 を参照ください。

– Azure Data Factory で行われる処理とは?

Azure Data Factory で行われる処理はアクティビティと呼ばれ、主に 2 種類あります。一つは、データをコピーするコピーアクティビティ。もう一つは、データを変換もしくは分析する、データ変換アクティビティです。

これらのアクティビティは、Azure Data Factory で設定する JSON 形式の パイプラインで指定できます。

– コピーアクティビティの参考情報  コピー アクティビティを使用したデータの移動

– データ変換アクティビティの参考情報  Azure Data Factory でデータを変換する

 

– パイプラインの推奨設定 – リトライ

Azure Data Factory は Azure クラウドの Web のサービスであるため、高可用性を実現しているサービスではあるものの、データセンター側でのサーバーの障害によるフェールーバー(サーバーの切り替え)や、ネットワークの問題による瞬断などが発生します。

そのため、上記の問題を回避するため、パイプラインの activities の項目にある policy にてリトライの設定を行います。詳細は Azure Data Factory のパイプラインとアクティビティ を参照ください。リトライの設定例は以下となります。

(例) スライス (パイプラインで指定した間隔) のデータ処理が失敗した場合、最初に 3 回リトライを行い (“retry”: 3)、それでも失敗する場合は 25 分待って (“longRetryInterval”: “00:25:00”)、2回目のロングリトライ (“longRetry”: 2) により、3 回のリトライが実施される設定の例です。

 

“policy”: {
“timeout”: “01:00:00”,
“delay”: “00:07:00”,
“concurrency”: 1,
“executionPriorityOrder”: “NewestFirst”,
“retry”: 3,
“longRetry”: 2,
“longRetryInterval”: “00:25:00”
},

 

上記の設定で意図的にスライスのデータ処理を失敗させました。この状態を Azure Portal サイトの “監視と管理(プレビュー)” で確認すると以下のようになります。

15 分毎にスライスを実行するスケジュールが設定されていますが、7分の遅延 (“delay”: “00:07:00”) 後 2/21 9:22 AM にスライスが開始されています。その後 3 回リトライを行い (“retry”: 3)、それでも失敗する場合は 25 分待って (“longRetryInterval”: “00:25:00”)、2/21 9:47 AM に 2 回目のロングリトライ (“longRetry”: 2) により、3 回のリトライが実施されていることが分かります。

 

image

 

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

以上、Azure Data Factory の紹介と、パイプラインのリトライの設定についてお伝えしました。お役に立てたら幸いです。

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

$
0
0

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

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

サービス
パック

更新プログラム

バージョン

リリース年月

SQL Server 2016

SP1

KB 3208177 (CU1)

13.0.4411.0

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

SQL Server 2014

SP2

KB 4010394 (CU4)

12.0.5540.0

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

SQL Server 2012

SP3

KB 3205051 (CU7)

11.0.6579.0

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

SQL Server 2008 R2

SP3

無し

10.50.6000.0

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

SQL Server 2008

SP4

無し

10.0.6000.0

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

 

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

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

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

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

$
0
0

 

 

SQL Server/Microsoft Azure SQL Database サポート

田中 真人

皆さん、こんにちは。 Microsoft SQL Server/Microsoft Azure SQL Database サポートチーム です。

日ごろから、SQL Database をご愛顧頂き誠にありがとうございます。

 

今回は、日々のサポート業務において、比較的お問合せをいただく事象についてご紹介させていただきます。

SQL Database の DTU使用率が突然上がり、SQL Database に接続できない、クエリが失敗した、確認するとCPU使用率が100%に達していた。どのように対応すればよいか確認したい。というお問合せを頂く事があります。

この場合、CPU のリソース不足により要求が失敗している事が考えられるのですが、皆様はそのような経験はございますでしょうか。

 

リソース不足の原因は、一般的にその時実行されているクエリに原因があります。その為、CPUがリソース不足になった原因となっているクエリを特定し、クエリのチューニングを実施する事が一般的な対処法となります。

データI/Oにおける負荷も同様の事が言えます。

 

そこで今回は、SQL Database に負荷をかけているクエリの特定方法について紹介します。

 

SQL Database に負荷をかけているクエリは、クエリ ストアという機能を使用して特定する事ができます。

クエリ ストアのご利用方法につきまして、以下の順に記載致します。

 

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

1)クエリ ストア機能のご利用について

2)負荷をかけているクエリの特定方法

3)クエリ特定後の対応について

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

1)クエリ ストア機能のご利用について

——————————————————————

クエリ ストア機能のご利用には SQL Server 2016 以上のバージョンの Management Studioが必要です。

インストールされていない場合は、以下サイトよりSQL Server Management Studio 2016をインストールして下さい。

 

■SQL Server Management Studio (SSMS) のダウンロード

https://msdn.microsoft.com/ja-jp/library/mt238290.aspx

※上記サイト内の「使用できる言語」から、ご利用環境に即した言語を選択頂き、ダウンロード下さい。

なお、本ブログでは、日本語版でのご紹介となります。

 

 

2)負荷をかけているクエリの特定方法

——————————————————————

2-1)SSMS を起動し、該当のデータベースへ接続し、以下の画面キャプチャ通りに「クエリ ストア」→「全体のリソース消費量」を展開します。

image

<図1. クエリ ストア>

 

2-2)画面右上の「構成」ボタンを押下し、確認する項目と期間を選択します。ここではCPUを例にあげ記載します。データI/Oを確認する場合は「物理読み取り」を選択するなど、状況に合わせて選択してください。

image

<図2. リソース全体の消費量>

 

image

<図3. グラフの表示>

 

2-3)CPU使用率の高かった日時の棒グラフを選択します。

clip_image004

<図4. リソース全体の消費量>

 

2-4)ここで、CPU使用率の高かったクエリを特定する事ができます。以下のサンプル画面では、クエリ159のCPU使用率が高い事がわかります。データI/O(物理読み取りを選択)の場合も確認の仕方は同様です。

clip_image005

<図4. CPU時間>

 

補足)クエリ ストアは既定で有効ですが、無効の場合は、以下のクエリを実行する事で有効にできます。

 

–クエリのサンプル–

ALTER DATABASE データベース名 SET QUERY_STORE = ON;

——————————

 

クエリ ストアの概要につきましては、以下サイトに詳細な記載がございます。ご参考ください。

 

■クエリのストアを使用した、パフォーマンスの監視

https://msdn.microsoft.com/library/dn817826.aspx

 

 

3)クエリ特定後の対応について

——————————————————————

負荷をかけているクエリを特定する事ができましたら、該当クエリの負荷が高い原因を調査、チューニングしていきます。

一般的にはまず、該当時間帯だけイレギュラーに実行されていなかったか、本来流れるはずではないクエリが流れていなかったかなど、調査します。

そのような特殊な状況でなければ、該当のクエリのチューニングや、データ量削減等を検討します。

 

クエリのチューニングを実施しても事象が解消されない場合は、選択されているサービスレベルが適切ではない可能性がございますので、サービスレベルを1つ上にあげて運用頂く事をご検討ください。

 

SQL Database 側で実施されているような、お心当たりのないクエリが原因となっていた場合は、実行日時と該当のクエリ情報を添えて、弊社サポート窓口までお問い合わせください。

 

[参考情報]

一般的なクエリのチューニング方法につきまして、以下サイトに詳細な記載がございます。ご参考ください。

 

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

https://blogs.msdn.microsoft.com/jpsql/2016/04/20/microsoft-azure-sql-database-%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9-%E3%83%81%E3%83%A5%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0-%E7%AC%AC%EF%BC%91%E5%9B%9E/

補足)クエリのチューニングは、Premier サポートにてご支援が可能でございます。必要に応じてご利用頂く事をご検討ください。


Troubleshooting Connectivity #9 –ローカル接続でネットワーク エラーとはこれいかに?

$
0
0

 

高橋 理香

SQL Developer Support Escalation Engineer

みなさん、こんにちは。

皆さんの疑問にお答えするブログを書きたいと思い早数年、今回は時々お問い合わせされる方が声にされる「SQL Server が稼動している環境上のほかのアプリケーションやツールから接続した場合にもネットワーク エラーが発生するのはなぜ?」について、その接続の仕組みなどを説明したいと思います。

前提: ローカル接続でトランスポートネットワークエラーが発生する事象について疑問があるとはどういうこと?

まず、以下の2つの図を比べてみましょう。

image

図1 ではクライアント マシン CLIENT01 上の SQL Server Management Studio (以降、SSMS) から物理的にネットワークの回線を介してリモート マシン SERVER01 上で動作する SQL Server に接続するイメージです。接続でエラーが発生するということは、接続のリクエストとその完了の通信経路上で遅延や障害があった場合に生ずるため、図1 のパターンにおいてネットワークに起因した問題があればネットワーク通信におけるエラーが返される可能性があるということは容易に想像できますね。

それでは図2 はいかがでしょう。サーバー マシン SERVER01 上で SSMS を起動し、同じ SERVER01 上で動作する SQL Server に接続するイメージです。この場合、物理ネットワーク回線を介さないはずです。それにもかかわらずネットワーク層のエラーが発生することがある、これが「ローカル接続なのにネットワーク エラーが発生するのはなぜ?」という疑問です。

実際にどちらの構成であっても次のようにネットワークに問題があるようにも見えるエラーが発生します。

SERVER01 に接続できません。 ADDITIONAL INFORMATION:

SQL Server への接続を確立しているときにネットワーク関連またはインスタンス固有のエラーが発生しました。サーバーが見つからないかアクセスできません。インスタンス名が正しいこと、および SQL Server がリモート接続を許可するように構成されていることを確認してください。 (provider: TCP Provider, error: 0 – リモート コンピューターによりネットワーク接続が拒否されました。) (Microsoft SQL Server、エラー: 1225)

リモート コンピューターによりネットワーク接続が拒否されました。

SQL Server への接続の仕組み

SSMS 等のアプリケーションやツールから SQL Server までにはどのように接続のリクエストが処理されるのでしょうか。Troubleshooting Connectivity #1 で説明したように、SQL Server に接続する場合には最初に OS レベルのセッションを確立する必要があります。たとえば TCP/IP プロトコルを使った接続の場合には、TCP/IP のセッションを確立します。そこで、SSMS から SQL Server に TCP/IP セッションを確立する仕組みを例にあげてみましょう。

SSMS は主に .NET Framework で開発されたアプリケーションであり、最初のダイアログにおける接続では内部的に .NET Framework Data Provider for SQL Server (System.Data.SqlClient) を使用しています。System.Data.SqlClient では SQL Server との通信を行う処理を SQL Server Network Interface (SNI) 層で管理しており、この SNI 層では OS レベルのセッションの確立やログイン処理などを Windows OS で利用可能な Windows Sockets (Winsock 関数) を利用して実現しています。たとえばダイアログからの接続時には SqlConnection.Open というメソッドを呼び出しますが、このメソッドが呼ばれると SNI 層では Winsock の connect 関数を呼び出すことになります。そして、SNI 層ではこの connect 関数の結果を踏まえ、次のログイン処理へ進むか、エラーとして処理するかなどの判断、および、必要な処理を行います。

では、「SSMS から TCP/IP プロトコルを使用して SQL Server に接続する」という動作に関して、リモート接続時とローカル接続時で違いはあるのでしょうか。

基本的な違いはありません。接続先がリモートであってもローカルであっても、SNI 層では Winsock 関数を呼び出し、接続処理を行います。正確には、SNI 層では接続に使用するプロトコルを選択する機能も持つため、接続先がローカルの場合には特にプロトコル指定がない限り共有メモリ プロトコルを使用するなど、接続先がローカルかリモートかの判別は行っています (*)。しかし、それでも Winsock 関数を呼び出す点に違いはありません。そのため、Winsock 関数による通信上の問題があると判断される限り、それはネットワーク層におけるエラーとして扱われます。これがローカルでもネットワーク関連のエラーがあるとメッセージとして表面化する理由です。

なお、上記動作は ODBC ドライバーや OLE DB プロバイダーでも同様です。MDAC や Windows DAC に含まれる ODBC ドライバー等では SNI ではなく、ネットワーク ライブラリと呼ばれていましたが、基本的に同様の仕組みとなっています。

// (*) 補足 – クラスタ環境のローカル接続

接続先がローカルかリモートかは接続文字列に指定した接続先サーバー名が現在そのプロセスが動作しているホスト名と同一かどうかによって判断しています。SNI 層では同一であると判断した場合に共有プロトコルを優先的に使用し、接続試行します。クラスタ環境の場合には、接続先はクラスタ名\インスタンス名となり、稼動ノード名とは異なるため、ローカルであるとは判断されません。そのため、ローカル接続でも TCP/IP もしくは名前付きパイプが使用されます。

ローカル接続失敗の一般的な原因

基本的には Troubleshooting Connectivity #2 で説明した主な原因と同一です。ただし、ローカル接続の OS レベルのセッション確立においてはネットワーク インターフェース カード (NIC) の外に通信が及ぶことはない (*) ため、ネットワーク負荷などの物理ネットワーク回線に関する要因が除外されます。

過去のお問い合わせでローカル接続失敗の要因として多いのはやはりサーバーの高負荷ですが、このような負荷が高い場合においては、同一マシン上で動作するプロセスの優先度に差がある (sqlservr.exe が高でアプリケーション プロセスが通常、もしくは、sqlservr.exe は通常でアプリケーション プロセスが低) 場合において、優先度により CPU をすぐに利用できずに待たされることで、接続のリクエストに遅延が生じ、タイムアウトするというケースがあります。負荷が高い場合にバッチ処理で接続タイムアウトが発生するようなケースがあったら、優先度の設定を確認してみてはいかがでしょう。

 

// (*) 補足 – ローカル接続での NIC 外への通信

セッション確立後のログイン認証においては、Windows 認証のために Active Directory への問い合わせが必要となります。Windows 認証の場合に接続タイムアウト エラーが発生し、SQL Server 認証では発生しない場合には、ネットワーク通信遅延が疑われます。SQL Server のセキュリティ設定で SQL Server 認証を許容している場合には切り分けとして試してみるとよいでしょう。

 

 

ローカル接続におけるネットワーク関連エラーについて参考になりましたでしょうか。少しでもイメージいただけたならうれしいです。

過去の Troubleshooting Connectivity シリーズはこちら。 Troubleshooting Connectivity #1 – SQL Server への接続

Troubleshooting Connectivity #2 – エラー情報からわかる失敗原因

Troubleshooting Connectivity #3 – 予期しない接続切断

Troubleshooting Connectivity #4 – 接続エラーの調査方法

Troubleshooting Connectivity #5 – セッション確立までの動作

Troubleshooting Connectivity #6 – 接続タイムアウトは悪なのか?

Troubleshooting Connectivity #7 – 接続タイムアウトエラーまでの時間は?

Troubleshooting Connectivity #8 – エラー番号からわかる接続失敗原因:エラー 26

clip_image001

Temporary Post Used For Theme Detection (9a2fa729-1009-4cd4-ac72-f50c4a4484cc – 3bfe001a-32de-4114-a6b4-4005b770f6d7)

$
0
0

This is a temporary post that was not deleted. Please delete this manually. (2cd9f617-6b19-4ec1-8558-26c3284bba3d – 3bfe001a-32de-4114-a6b4-4005b770f6d7)

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

$
0
0

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

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

サービス
パック

更新プログラム

バージョン

リリース年月

SQL Server 2016

SP1

KB 4013106 (CU2)

13.0.4422.0

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

SQL Server 2014

SP2

KB 4010394 (CU4)

12.0.5540.0

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

SQL Server 2012

SP3

KB 4013104 (CU8)

11.0.6594.0

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

SQL Server 2008 R2

SP3

無し

10.50.6000.0

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

SQL Server 2008

SP4

無し

10.0.6000.0

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

 

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

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

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

[Azure Data Factory] “監視と管理”から確認出来る Activity Windows のログ保持期間

$
0
0

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

前回の ADF (Azure Data Factory) の blog – [Azure Data Factory] パイプラインの推奨設定 – リトライ で、スライスの処理の失敗を確認する際、Azure Portal サイトにある、データ ファクトリ の “監視と管理(プレビュー)”  (下記スクリーンショットの赤枠)  を利用しました。この “監視と管理(プレビュー)” の Activity Windows のログの保持期間について、サポートによくお問い合わせがきます。、この blog ではログの保持期間についてお伝えします。

image

 

“監視と管理(プレビュー)” の Activity Windows のログの保持期間は、45日となります。ログに関わるパイプラインが削除された場合は、45日の経過にかかわらず、ログは削除されます。

 

一方、以下のデータセットの項目で参照できる、スライスの実行ログは、該当のデータセットが削除されるまでログが保持されます。古いログを参照する必要がある場合は、こちらのデータセットからスライスの実行ログをご確認ください。

 

image

 

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

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

異種データベースレプリケーションがサポートする Oracle Database バージョンについて

$
0
0

 

今回は異種データベースレプリケーションでサポートされる RDBMS とバージョンについてご案内させて頂きます。

弊社側にお寄せいただく異種データベースレプリケーションのお問い合わせの多くは相手が Oracle Database のものになります。

その為、本文書では Oracle Database を中心に紹介いたしますが、原則的に確認方法は他の RDBMS も同様です。

この機能自体は非推奨機能ではありますが、対 Oracle Database に関してどのバージョンが現在のサポータブルなのかがわかりにくい為、本文書で補足いたします。

 

異種パブリケーションの廃止について

Microsoft SQL Server 2012 がリリースされたタイミングで異種データベースレプリケーションは廃止される事が決定しております。

本文書がターゲットとしている Oracle Database と SQL Server を同期させる Oracle Publisher や Oracle Subscriber もその対象であり、以下の様に将来の廃止予定機能として公開されております。

 

異種データベースレプリケーション

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

SQL Server 2012 は、トランザクション レプリケーションとスナップショット レプリケーションに対する次の異種シナリオをサポートします。

・Oracle から SQL Server へのデータのパブリッシュ

・SQL Server から SQL Server 以外のサブスクライバーへのデータのパブリッシュ

SQL Server 以外のサブスクライバーへの異種レプリケーションは推奨されません。  Oracle パブリッシングは推奨されません。

データを移動するには、変更データキャプチャと SSIS を使用してソリューションを作成します。

—-

注意

—-

この機能は、将来のバージョンの Microsoft SQL Server では削除される予定です。

新しい開発作業では、この機能の使用を避け、現在この機能を使用しているアプリケーションは修正するようにしてください。

ただし、将来的に廃止される事が明記されているものの、現時点(2017年3月時点)ではこの機能自体はまだ残されています。

その為、SQL Server がサポートしている RDBMS のバージョンの範囲内でご利用を頂く事は可能です。

 

サポート対象となる Oracle Database バージョンについて

上記説明だけをみるとどの Oracle Database バージョンがサポートされるのか、と疑問に思われる事かと思います。

その答えはシステムデータベース内に存在しています。異種データベースレプリケーションがサポート対象とする RDBMS とそのバージョンは msdb 内のシステムテーブルである MSdbms に登録されています。

このリストに合致する RDBMS及び該当バージョンのみがサポート対象となります。以下は SQL Server 2016 上で MSdbms を検索した結果です。

※このクエリの結果は SQL Server 2012 及び SQL Server 2014 も同様です。

clip_image002

上記の結果より、Microsoft SQL Server(現時点のメインストリームサポート期間中の 2012/2014/2016) がサポートしている Oracle Database は Oracle Database 11g までが対象となります。

つまり、現時点(2017年3月時点)で最新のリリースであるOracle Database 12c はその対象になっておらず、サポートされていません。

その為、Oracle Database 12c を接続する異種レプリケーション構成下で起こった問題は不具合の修正や機能の追加は行われません。

 

異種データベースレプリケーションに代わる機能

異種データベースレプリケーションが廃止された将来のリリースでは SQL Server Integration Services を使い、スナップショットレプリケーションの様なデータフローを作成するか、Change Data Capture Service for Oracle by Attunity (CDC for Oracle) の機能をご利用ください。

 

[参考情報]

Change Data Capture Service for Oracle by Attunity

https://docs.microsoft.com/en-us/sql/integration-services/change-data-capture/change-data-capture-service-for-oracle-by-attunity

なお、上記文書通り、CDC for Oracle がサポートする Oracle Database は 2017年3月時点では以下のものをサポートしています。

こちらは Classic Install(マルチテナントではない) 制限付きではありますが、 Oracle Database 12cをサポートします。

 

2017年4月時点

Viewing all 293 articles
Browse latest View live


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