Gespeicherte Prozesse neu kompilieren?

Ich verstehe Ihre Frage so:"Wenn ich eine Schemaänderung vornehme, möchte ich alle Prozeduren validieren, die sie mit dem neuen Schema noch korrekt ausführen". Dh. Wenn Sie eine Spalte löschen, auf die in einem SELECT in einer Prozedur verwiesen wird, möchten Sie, dass sie gekennzeichnet wird, da sie Änderungen erfordert. Daher verstehe ich Ihre Frage nicht als "Ich möchte, dass die Prozedur bei der nächsten Ausführung neu kompiliert wird", da diese Aufgabe von der Engine für Sie erledigt wird, die die mit jeder Schemaänderung verbundene Änderung der Metadatenversion erkennt und die vorhandene verwirft zwischengespeicherte Ausführungspläne.

Meine erste Beobachtung ist, dass das, was Sie in Ihrer Frage beschreiben, normalerweise die Aufgabe eines TESTS ist und Sie sollten einen QA-Schritt in Ihrem Bereitstellungsprozess haben, der den neuen „Build“ validiert. Die beste Lösung, die Sie haben könnten, besteht darin, einen minimalen Satz von Komponententests zu implementieren, die zumindest alle Ihre gespeicherten Prozeduren durchlaufen und die Ausführung validieren von jedem auf Korrektheit, in einer Testbereitstellung. Das würde so ziemlich alle Überraschungen eliminieren, zumindest dort, wo es weh tut (in der Produktion oder beim Kunden).

Ihre nächstbeste Option besteht darin, sich auf Ihre Entwicklungstools zu verlassen, um diese Abhängigkeiten zu verfolgen. Der Visual Studio Database 2008 Database Edition bietet solche Funktionalität sofort einsatzbereit und kümmert sich um die Validierung aller Änderungen, die Sie am Schema vornehmen.

Und schließlich ist Ihre letzte Option, etwas Ähnliches zu tun, was KM vorgeschlagen hat:Automatisieren Sie eine Iteration durch alle Ihre Prozeduren in Abhängigkeit vom geänderten Objekt (und alle Prozeduren in Abhängigkeit von den abhängigen und so weiter und so fort rekursiv). Es reicht nicht aus, die Prozeduren für die Neukompilierung zu markieren, was Sie wirklich brauchen, ist die ALTER PROCEDURE auszuführen, um eine Analyse des Textes und eine Validierung des Schemas auszulösen (in T-SQL sind die Dinge etwas anders als in Ihrer üblichen Sprache Kompilierungs-/Ausführungszyklus, die 'Kompilierung' an sich findet nur statt, wenn die Prozedur tatsächlich ausgeführt wird). Sie können beginnen, indem Sie das sys.sql_dependencies um alle Abhängigkeiten Ihres geänderten Objekts zu finden, und finden Sie auch die 'Moduldefinition' der Abhängigkeiten von sys.sql_modules :

with cte_dep as (
   select object_id
      from sys.sql_dependencies
    where referenced_major_id = object_id('<your altered object name>') 
    union all
    select d.object_id
    from sys.sql_dependencies d
        join cte_dep r on d.referenced_major_id = r.object_id
    )
, cte_distinct as (
    select distinct object_id
        from cte_dep)
select object_name(c.object_id)
    , c.object_id 
    , m.definition
    from cte_distinct c
    join sys.sql_modules m on c.object_id = m.object_id

Sie können dann die abhängigen 'Module' durchlaufen und neu erstellen (dh sie löschen und den Code in der 'Definition' ausführen). Beachten Sie, dass ein „Modul“ allgemeiner ist als eine gespeicherte Prozedur und auch Ansichten, Trigger, Funktionen, Regeln, Standardwerte und Replikationsfilter abdeckt. Verschlüsselte „Module“ verfügen nicht über die verfügbare Definition, und um absolut korrekt zu sein, müssen Sie auch die verschiedenen Einstellungen berücksichtigen, die in sys.sql_modules erfasst sind (ANSI-Nullen, Schemabindung, als Klauseln ausführen usw.).

Wenn Sie dynamisches SQL verwenden, kann dies nicht überprüft werden. Es wird nicht von sys.sql_dependencies erfasst , noch wird es durch 'Neuerstellung' des Moduls validiert.

Insgesamt denke ich, dass Ihre mit Abstand beste Option die Implementierung der Unit-Tests-Validierung ist.