0

最新の DACPAC ( http://msdn.microsoft.com/en-us/library/ee634742.aspxから取得) を使用して SQL Azure インスタンスをアップグレードする PowerShell スクリプトを作成しました。

PowerShell スクリプトを実行したときに経験したことは、実行に一貫して約 30 分かかることです。スクリプトは、実行から戻るのを待つためにほぼ 30 分間アイドル状態に$dacstore.IncrementalUpgrade($dacName, $dacType, $upgradeProperties)なり、PowerShell コンソール ウィンドウには何も出力されません。30 分の終わりになって初めて、インクリメンタル アップデートがコンソール メッセージを吐き出し始め、アップグレードが行われていることを知らせます (基本的に、スクリプトが最終的に生き返るまで 30 分間ハングしたように見え、スクリプトはこれを一貫して実行します)。毎回）。

通常、IncrementalUpgrade が完了するまでにこれほど時間がかかりますか?また、30 分間の非アクティブ/待機期間があるはずですか?

Azure ネットワークの外部にあるローカル マシンから PowerShell スクリプトを実行していることに注意してください。

これについてご意見をお寄せいただきありがとうございます。継続的インテグレーションのビルドにそれほど時間がかからないように、この増分アップグレード プロセスを 30 分未満に大幅に短縮できることを願っています。

4

1 に答える 1

0

Microsoft サポートによると、これは既知の問題であり、SQL Server 2012 (コード名 Denali) で修正される予定です。Microsoft サポートからの詳細は次のとおりです。

SSMS 2008 または PowerShell を使用して SqlAzure の DAC を更新すると非常に遅いという既知の問題があります。SQLServer 2008 は、すべての列と小さなオブジェクトに対してクエリを実行する古い抽出エンジンを利用します。この方法は、オンプレミス サーバーでうまく機能し、SQLServer 2008 の当初の設計目標を満たしています。ただし、SqlAzure データベースを管理する場合、クエリをインターネット経由で転送する必要があるため、ネットワーク遅延により、特にネットワークが良好でない場合、古い抽出が非効率になります。

SQL 製品チームはこの問題を認識しており、それを修正する新しい抽出エンジンを設計しました。新しいエンジンは、SQL Server 2012 (コード名 Denali) に統合されています。残念ながら、エンジンの動作の一部が SQL Server 2008 に重大な変更をもたらす可能性があります。別のアプローチを試みていますが、SQL Server 2008 に新しいエンジンを適用する際に回帰障壁を緩和することはできません。これまでのところ、SQLServer 2008 のホットフィックスとしての新しい抽出エンジン。これは、現在のオンプレミスのユーザーと運用に影響を与えます。

継続的インテグレーション (CI) プロセスを使用して PowerShell スクリプトを設計した方法の詳細については、こちらを参照してください。

于 2011-11-17T15:32:24.947 に答える