4

編集：ハングしていないことを示すように更新されました。AGES がかかるだけです。

dacpac を使用して既存の SQL Server データベースを更新しようとしています。

以下の (簡略化された) 例を使用して、新しい SQL サーバー データベースを 30 秒で作成できます。私が抱えている問題は、同じ dacpac を使用して手順を再実行する (つまり、新たに作成するのではなく、既存のデータベースを更新する) のに 20 分かかることです。

時差が予想される場合、このようなものですか？redgate の SqlCompare を包括的に使用してきたので、私はこの時間が許せないと感じています。

deploy メソッドの 3 番目のパラメーターは UpgradeExisting で、これを true に設定しています - これですべての作業が必要ですか、それとも何か不足していますか??

void Deploy(string TargetConnectionString, string TargetDatabaseName, string pathToSourceDACPAC)
{

    DacServices dacServices = new DacServices(TargetConnectionString);

    //Set up message and progress handlers
    dacServices.Message += new EventHandler<DacMessageEventArgs>(dbServices_Message);
    dacServices.ProgressChanged += new EventHandler<DacProgressEventArgs>(dbServices_ProgressChanged);

    //Load the DACPAC
    DacPackage dacpac = DacPackage.Load(pathToSourceDACPAC);

    //Set Deployment Options
    DacDeployOptions dacOptions = new DacDeployOptions();
    dacOptions.AllowIncompatiblePlatform = true;

    //Deploy the dacpac
    dacServices.Deploy(dacpac, TargetDatabaseName, true, dacOptions);

}

//Event handlers...
void dbServices_Message(object sender, DacMessageEventArgs e)
{
    OutputThis("DAC Message", e.Message.ToString());
}

void dbServices_ProgressChanged(object sender, DacProgressEventArgs e)
{
    OutputThis(e.Status.ToString(), e.Message.ToString());
}

NB、プログラムは dacServices.Deploy 行のイーサに消えます..

4

4 に答える 4

7

OK、デバッガー (VS2012) を実行している間、ばかげた時間が経験されました。コンパイル後の時間は、メモリ DacSchemaModelStorageType を選択した場合は 25 秒程度、ファイル DacSchemaModelStorageType を選択した場合は 45 秒程度でした。

これは、デバッグがwhatsitの苦痛であることを意味しているだけだと思います!

于 2013-05-14T14:44:59.127 に答える
2

デバッガーの下で非常に遅いと感じた場合、多くの警告がありますか?

警告は通常、使用する antlr パーサーによって生成され、パーサーは非常にコストのかかる例外をスローします。

警告を修正すると、ビルド時間が短縮されます。

エド

于 2014-12-02T23:59:04.563 に答える
2

同じ問題がありました.dacpac deploys は、テストの実行中は正常に実行されますが、テストのデバッグ中は実行が非常に遅くなります。

私の場合、dacpac には、いくつかのテスト データをデータベースにシードする一連の .sql スクリプトが含まれていました。これらのスクリプトの 1 つは SSMS から自動生成されたため、次のような 40,000 行の長さでした。

INSERT [dbo].[Resource] ([CategoryId], [StoreCode], [LocaleCode], [ResourceName], [ResourceText]) VALUES (1, N'AU', N'en-AU', N'AD', N'Andorra')
GO
INSERT [dbo].[Resource] ([CategoryId], [StoreCode], [LocaleCode], [ResourceName], [ResourceText]) VALUES (1, N'AU', N'en-AU', N'AE', N'United Arab Emirates')
GO
INSERT [dbo].[Resource] ([CategoryId], [StoreCode], [LocaleCode], [ResourceName], [ResourceText]) VALUES (1, N'AU', N'en-AU', N'AF', N'Afghanistan')

など、40,000 行、つまり 20,000 INSERTANDGOステートメントの場合。デバッグ中に dbo.Resource テーブルにクエリを実行すると、スクリプトが問題を引き起こしていることがわかりました。そのテーブルの行数がまだ増加しているため、問題のスクリプトの実行が遅いことがわかりました。

いくつかのメモ帳++マクロを使用してそのスクリプトを書き直して、ステートメントを減らし、それぞれにINSERT1000行を挿入しました。INSERT

INSERT [dbo].[Resource] ([CategoryId], [StoreCode], [LocaleCode], [ResourceName], [ResourceText]) VALUES 
(1, N'AU', N'en-AU', N'AD', N'Andorra'),
(1, N'AU', N'en-AU', N'AE', N'United Arab Emirates'),
(1, N'AU', N'en-AU', N'AF', N'Afghanistan'),
... 
GO

そしてそれは問題を修正しました。

于 2016-06-16T12:26:57.720 に答える