8

他の誰かが以下に説明されているものと同様の問題に遭遇しましたか?

Powershell を使用して SQL Server 2012 dacpac データベース アップグレードを展開する際に問題が発生しています。詳細は次のとおりです。

SQL Server 2012用に構築されたdacpacファイルであり、管理者としてログインしたときにコマンドラインからPowershellを実行して、SQL Server 2012データベースに適用しようとしています。

"4" 個の引数を指定して "Deploy" を呼び出し中に例外が発生しました: "ドメインの ID を特定できません"。At ... so.ps1:17 char:8 + $d.Deploy($dp, $TargetDatabase,$true,$DeployOptions)

編集されたスクリプト (ログとリテラルが変更されています) は次のとおりです。

   [System.Reflection.Assembly]::LoadFrom("C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\Microsoft.SqlServer.Dac.dll") | Out-Null

   $d = new-object Microsoft.SqlServer.Dac.DacServices ("... Connection string ...")

   $TargetDatabase = "databasename"
   $fullDacPacPath = "c:\temp\...\databasename.dacpac"

   # Load dacpac from file & deploy to database named pubsnew
   $dp = [Microsoft.SqlServer.Dac.DacPackage]::Load($fullDacPacPath)
   $DeployOptions = new-object Microsoft.SqlServer.Dac.DacDeployOptions
   $DeployOptions.IncludeCompositeObjects = $true
   $DeployOptions.IgnoreFileSize = $false
   $DeployOptions.IgnoreFilegroupPlacement = $false
   $DeployOptions.IgnoreFileAndLogFilePath = $false     
   $DeployOptions.AllowIncompatiblePlatform = $true  

   $d.Deploy($dp, $TargetDatabase,$true,$DeployOptions)

ここにいくつかのサポート情報があります:

  1. Dac フレームワークのバージョンは 11.1 です
  2. コマンドラインで実行すると、スクリプトはエラーをスローします
    。Powershell -file databaseupgrade.ps1
    ですが、Powershell 統合スクリプト環境で実行した場合はそうではありません
  3. 同様のスクリプトは、他の dacpac のコマンド ラインから機能します。

Web での調査によると、dacpac のサイズに関係している可能性があります。機能するものはすべて、機能しないものよりも小さく、このリンクには、失敗した dacpac のファイル サイズが 1.3 MB を超える数値が記載されています。これが問題であることを誰かが確認できる場合は、解決策も提案できますか?

更新 次のスクリプトは同じ動作を示します。コマンドラインからではなくPS Ideで動作します。 

[Reflection.Assembly]::LoadWithPartialName("System.IO.IsolatedStorage")

$f =   [System.IO.IsolatedStorage.IsolatedStorageFile]::GetMachineStoreForDomain();
Write-Host($f.AvailableFreeSpace);
4

3 に答える 3

7

ここでのこの問題 (少なくとも私たちの場合) は、実際には dacpac が複数のファイル グループを使用するデータベースで動作している場合に発生すると考えています。展開の比較を行うとき、私の仮説は、さまざまなファイルに IsolatedStorage を利用しているということです。

上記のリンクは役に立ちましたが、 Tim Lewisによるそのブログの最後のコメントほどのエントリではありませんでした。彼のコードを変更して、ネイティブの powershell で動作するようにしました。これを SMO アセンブリ ロードの上に配置すると、この問題が修正されます。

$replacementEvidence = New-Object System.Security.Policy.Evidence $replacementEvidence.AddHost((New-Object System.Security.Policy.Zone ([Security.SecurityZone]::MyComputer))) $currentAppDomain = [System.Threading.Thread]::GetDomain() $securityIdentityField = $currentAppDomain.GetType().GetField("_SecurityIdentity", ([System.Reflection.BindingFlags]::Instance -bOr [System.Reflection.BindingFlags]::NonPublic)) $securityIdentityField.SetValue($currentAppDomain,$replacementEvidence)

于 2015-08-28T22:38:17.387 に答える
0

数日経っているので、適切な説明が来るとは思いません。この状況に陥った他の人のための回避策として、これを投稿します。かなり簡単に入手できる Microsoft コマンド ライン プログラム SqlPackage.exe があります。dacpac をサイレントにデプロイし、Powershell で実行でき、必要なすべてのオプションをサポートするパラメーターを備えています。Dac サービス アセンブリの代わりにこれを直接使用すると、ドメインの問題は発生しません。

于 2014-01-16T09:17:31.010 に答える