Anscheinend verursacht meine CLR-Assembly-Funktion Deadlocks?

Unsere Anwendung muss mit einer Oracle-Datenbank oder einer Microsoft SQL Server-Datenbank gleich gut funktionieren. Um dies zu vereinfachen, haben wir eine Handvoll UDFs erstellt, um unsere Abfragesyntax zu homogenisieren. Beispielsweise hat SQL Server GETDATE () und Oracle SYSDATE. Sie erfüllen dieselbe Funktion, sind jedoch unterschiedliche Wörter. Wir haben für beide Plattformen eine Wrapper-UDF namens NOW () geschrieben, die die relevante plattformspezifische Syntax in einen gemeinsamen Funktionsnamen einschließt. Wir haben andere solche Funktionen, von denen einige im Wesentlichen nichts anderes tun, als nur zur Homogenisierung zu existieren. Leider hat dies Kosten für SQL Server. Inline-skalare UDFs beeinträchtigen die Leistung und deaktivieren die Parallelität vollständig. Als Alternative haben wir CLR-Assembly-Funktionen geschrieben, um dieselben Ziele zu erreichen. Als wir dies für einen Client bereitstellten, traten häufig Deadlocks auf. Dieser spezielle Client verwendet Replikations- und Hochverfügbarkeitstechniken und ich frage mich, ob hier irgendeine Art von Interaktion stattfindet. Ich verstehe nur nicht, wie die Einführung einer CLR-Funktion solche Probleme verursachen würde. Als Referenz habe ich die ursprüngliche skalare UDF-Definition sowie die Ersatz-CLR-Definition in C # und die SQL-Deklaration dafür aufgenommen. Ich habe auch Deadlock-XML, das ich bereitstellen kann, wenn das hilft.

Original UDF

CREATE FUNCTION [fn].[APAD]
(
    @Value VARCHAR(4000)
    , @tablename VARCHAR(4000) = NULL
    , @columnname VARCHAR(4000) = NULL
)

RETURNS VARCHAR(4000)
WITH SCHEMABINDING
AS

BEGIN
    RETURN LTRIM(RTRIM(@Value))
END
GO

CLR-Montagefunktion

[SqlFunction(IsDeterministic = true)]
public static string APAD(string value, string tableName, string columnName)
{
    return value?.Trim();
}

SQL Server-Deklaration für die CLR-Funktion

CREATE FUNCTION [fn].[APAD]
(
    @Value NVARCHAR(4000),
    @TableName NVARCHAR(4000),
    @ColumnName NVARCHAR(4000)
) RETURNS NVARCHAR(4000)
AS
EXTERNAL NAME ASI.fn.APAD
GO

Welche Version (en) von SQL Server verwenden Sie?

Ich erinnere mich an eine leichte Änderung des Verhaltens in SQL Server 2017 vor nicht allzu langer Zeit. Ich muss zurückgehen und nachsehen, ob ich herausfinden kann, wo ich es notiert habe, aber ich denke, es hat damit zu tun, dass beim Zugriff auf ein SQLCLR-Objekt eine Schemasperre initiiert wurde.

Während ich danach suche, werde ich Folgendes zu Ihrem Ansatz sagen:

1. Bitte verwenden Sie die Sql*Typen für Eingabeparameter, Rückgabetypen. Sie sollten SqlStringanstelle von verwenden string. SqlStringist einer nullbaren Zeichenfolge sehr ähnlich (Ihre value?, aber es sind andere Funktionen integriert, die SQL Server-spezifisch sind. Alle Sql*Typen haben eine ValueEigenschaft, die den erwarteten .NET-Typ SqlString.Valuezurückgibt (z. B. Rückgaben string, SqlInt32Rückgaben int, SqlDateTimeRückgaben DateTimeusw.).

2. Ich würde zunächst gegen diesen gesamten Ansatz empfehlen, ob die Deadlocks zusammenhängen oder nicht. Ich sage das, weil:

   1. Selbst wenn deterministische SQLCLR-UDFs an parallelen Plänen teilnehmen können, werden Sie höchstwahrscheinlich Leistungseinbußen bei der Emulation vereinfachter integrierter Funktionen erhalten.
   2. Die SQLCLR-API lässt dies nicht zu VARCHAR. Können Sie implizit alles für einfache Operationen in NVARCHARund dann wieder zurück konvertieren VARCHAR?
   3. Die SQLCLR-API lässt keine Überladung zu. Daher benötigen Sie möglicherweise mehrere Versionen von Funktionen, die unterschiedliche Signaturen in T-SQL und / oder PL / SQL zulassen.
   4. Ähnlich wie beim Überladen nicht zuzulassen, gibt es einen großen Unterschied zwischen NVARCHAR(4000)und NVARCHAR(MAX): Der MAXTyp (der nur einen einzigen in der Signatur enthält) lässt den SQLCLR-Aufruf doppelt so lange dauern wie keinen MAXTyp in der Signatur (ich glaube, dies gilt gilt auch für VARBINARY(MAX)vs VARBINARY(4000)). Sie müssen sich also entscheiden zwischen:
      • Verwenden Sie nur NVARCHAR(MAX), um eine vereinfachte API zu haben, aber nehmen Sie den Leistungseinbruch, wenn Sie 8000 Byte oder weniger Zeichenfolgendaten verwenden, oder
      • Erstellen von zwei Variationen für alle / die meisten / viele Zeichenfolgenfunktionen: eine mit MAXTyp und eine ohne (wenn Sie garantiert nie mehr als 8000 Byte Zeichenfolgendaten ein- oder ausgeben). Dies ist der Ansatz, den ich für die meisten Funktionen in meiner SQL # -Bibliothek gewählt habe: Es gibt eine Trim()Funktion, die wahrscheinlich einen oder mehrere MAXTypen hat, und eine Trim4k()Version, die niemals einen MAXTyp im Signatur- oder Ergebnismengenschema hat. Die "4k" -Versionen sind absolut effizienter.

   5. Sie achten nicht darauf, die Funktionalität anhand des Beispiels in der Frage zu emulieren. LTRIMund RTRIMnur Leerzeichen String.Trim()zuschneiden , während .NET Leerzeichen trimmt (mindestens Leerzeichen, Tabulatoren und Zeilenumbrüche). Zum Beispiel:

        PRINT LTRIM(RTRIM(N'      a       '));

   6. Außerdem ist mir gerade aufgefallen, dass Ihre Funktion sowohl in T-SQL als auch in C # nur einen der drei Eingabeparameter verwendet. Ist dies nur ein Proof of Concept oder ein redigierter Code?