web-dev-qa-db-ja.com

在宅勤務時にtSQLtを使用してPREEMPTIVE_OS_AUTHORIZATIONOPSを取得するのはなぜですか？

TSQLt単体テストを含むSSDTプロジェクトがあります。

これを公開してすべてのテストを実行した後（デプロイ後のスクリプトから）、（localdbとSQL Server開発者エディションの両方に対して）問題があることにいつも気づきました。

パブリッシュは無期限に停止し、最終的にはビジュアルスタジオを終了する必要があります。

待機タイプはPREEMPTIVE_OS_AUTHORIZATIONOPSで、これを待機しているステートメントの例（sys.dm_exec_sql_textから）は次のとおりです。

(@r BIT OUTPUT)
SELECT @r = CASE
              WHEN I.Version = I.ClrVersion THEN 1
              ELSE 0
            END
FROM   tSQLt.Info() AS I;

私もこれを再現して

SELECT tSQLt.Private::Info()

これは簡単な方法です

public static SqlString Info()
{
  return (SqlString) Assembly.GetExecutingAssembly().GetName().Version.ToString();
}

ドメインコントローラーにアクセスして、何らかの権限またはその他の権限があることを確認しようとしていると思います。これは他のCLRアセンブリでは得られないので、これはTSQLTがSAFE_ACCESSアセンブリではない（権限セットはEXTERNAL_ACCESSである）と関係があるのではないかと疑っています。

ここで何が起こっているのか、そしてこれを修正し、これに遭遇することなく会社のネットワークから切断された状態で作業する方法を知っている人はいますか？

sql-serversql-clrwait-typestsqlt
6
Martin Smith

常にドメインに接続する予定がない場合は、それが開発インスタンスであるため、db所有者をドメインアカウントからローカルアカウントまたはSQLアカウントに変更します。

この素晴らしいブログをチェックしてください：

http://andreas-wolter.com/en/where-is-that-preemptive-wait-coming-from/

ブログ投稿を要約すると：

  • ドメインユーザーとしてdb所有者がいると、チケット要求を許可するkerberosチケットが発生します（つまり、sqlはdb所有者であるドメインアカウントを使用して認証し、kerberosには、sqlがdb所有者を偽装できるチケット許可チケットがあります）。
  • ドメインコントローラーへの待ち時間が長い（またはこの場合の接続に問題がある）場合、これらの呼び出しは遅くなります
  • SQLは呼び出しを10分間キャッシュするため、断続的に表示される場合があります

ed

5
Ed Elliott

多くのテストを行った後（詳細は関連する ディスカッション で確認できます）、ぶら下がりを発生させるために必要な要素を絞り込みましたが、最終的には何がぶら下がりの原因ではないのですか？自体。

私たちが今知っていること：

  1. VPNに接続されていない場合、ハングはまったくありません。これは、OSがドメインコントローラーにアクセスして検証を実行できないため、キャッシュされた資格情報にフォールバックすることが原因であると考えています。
  2. テストが正常に実行された場合（つまり、VPNにが接続されていない場合）、VPNに接続でき、テストは引き続き実行されます。これは、SQL ServerやOSレベルでの権限がキャッシュされていることを示唆しています。キャッシュがどこで発生しているかについてはまだ明確ではありませんが、少なくとも、アクセス許可が読み込まれたアセンブリでキャッシュされることを除外できました（これは、アプリドメインをアンロードしてからテストを再実行することで行いました） VPNが接続されていて、ハングしませんでした）。
  3. ある程度の時間が経過した後（または、テストで取得したことが原因で現在のように見えます）、VPNがまだ接続されていて、アプリドメインがアンロードされている場合は、テストを再度実行すると、プロセスがハングします。 @Edの回答に投稿されたリンクは、テストで見られた約10分のキャッシュタイムアウトを確認しているようです。
  4. プロセスがハングしたときは、Windowsのセキュリティ情報を取得するための一連の外部呼び出し中です（Martinがディスカッションで投稿したスタックトレースを確認できます： https://chat.stackexchange.com/transcript/message/40428311＃40428311 —「（全文を表示）」リンクをクリックして、_sqllang.dll!FVerifyAssemblyPermsForSids_）を探します
  5. アセンブリがSAFE：に設定されている場合
    1. 確認する権限がないため、Info() TVFへの最初の呼び出しは成功します。
    2. ただし、 tSQLt.Private_Init ストアドプロシージャは常にtSQLtCLRアセンブリを_EXTERNAL_ACCESS_としてマークしようとしますが、その場合（非対称キーにがないと仮定して）インストール済み）：
      1. TRUSTWORTHYがOFFでない場合、InitがTRUSTWORTHYではなく、非対称キーがないため、ONプロシージャでの_tSQLt.EnableExternalAccess_プロシージャの呼び出しは、「EXTERNAL_ACCESSまたはUNSAFE ...の許可なし」エラーで失敗します。それでも、OSから何も必要としないメタデータ操作であるため、ハングアップしません。これは_ISECManager::FIsAssemblyAuthorized_の呼び出しである必要があります。これは、上記のFVerifyAssemblyPermsForSidsステップの1つ前のステップです。
      2. TRUSTWORTHYがONの場合、Initプロシージャでの_tSQLt.EnableExternalAccess_プロシージャへの呼び出しは、次の理由でハングします。したがって、_ALTER Assembly tSQLtCLR WITH PERMISSION_SET = EXTERNAL_ACCESS;_ステートメントでハングします。
  6. アセンブリが_EXTERNAL_ACCESS_に設定されている場合：
    1. TRUSTWORTHYがOFFの場合、InitプロシージャでのInfo() TVFの呼び出しは、権限がないため失敗します。これは、上記でTRUSTWORTHYがOFFであったときに見られた問題と同じです。エラーメッセージは異なりますが、これは、カスタムエラーメッセージがある_TRY...CATCH_構文にクエリがあるためです（_tSQLt.EnableExternalAccess_への呼び出しも_TRY...CATCH_構文内にありますが、その呼び出しは、CATCHブロックのエラーメッセージを上書きしません。
    2. TRUSTWORTHYがONの場合、InitプロシージャでのInfo() TVFへの呼び出しは、OSに到達してドメインコントローラーからSIDアクセス許可情報を取得するときにハングします。

理解するために残っているもの：

  1. キャッシングはどこで、どのくらいの期間行われますか？アプリドメインをアンロードしており、SQL Serverベースの認証キャッシュをDBCC FREESYSTEMCACHE('ALL') WITH MARK_IN_USE_FOR_REMOVAL;から解放している可能性があります。ただし、一貫性のある再現可能な期間はまだ見つかっていません。これまでのところ、約9分であるようです。
  2. VPNが接続され、アセンブリがメモリに読み込まれ、すべてが機能している場合、ハングは再び発生しますか？
  3. データベースに_TRUSTWORTHY OFF_があった場合、これは発生しますか？これは、ハング状態が再び発生するまで待機してから_EXEC tSQLt.InstallExternalAccessKey_を実行することでテストできます。次に、_TRUSTWORTHY OFF_を設定して、再試行してください。
    非対称キーと署名ベースのログインを使用することは、_TRUSTWORTHY ON_に依存するよりも間違いなく優れているため、それに切り替えて_TRUSTWORTHY OFF_を使用することをお勧めします。
  4. 最後に、なぜそれがまったくハングするのですか？また、他のプロセスはSQL Serverの外部でハングしますか？または、これはSQL Serverに固有の問題ですか？ @Sean Gallardy（ディスカッション内）は次のことを提案しました：

    操作に非常に時間がかかる理由は、DCへの接続や情報（グループなど）の取得に問題があるようです。私の推測では、この情報を検索するために1つのインターフェース（インターネット）がどういうわけか選択されているという説明によると、ネットワーキングが一致しません。これは決して完了しません。

3
Solomon Rutzky