Tôi hiểu câu hỏi của bạn là 'khi tôi thực hiện thay đổi giản đồ, tôi muốn xác thực tất cả các thủ tục mà chúng vẫn thực thi chính xác với lược đồ mới'. I E. nếu bạn thả một cột được tham chiếu trong SELECT trong một thủ tục, thì bạn muốn cột đó được gắn cờ vì nó yêu cầu thay đổi. Vì vậy, cụ thể là tôi không hiểu câu hỏi của bạn là 'Tôi muốn thủ tục biên dịch lại trong lần thực thi tiếp theo', vì công việc đó được công cụ xử lý cho bạn, công cụ này sẽ phát hiện thay đổi phiên bản siêu dữ liệu liên quan đến bất kỳ thay đổi lược đồ nào và loại bỏ kế hoạch thực thi được lưu trong bộ nhớ cache.
Quan sát đầu tiên của tôi là những gì bạn mô tả trong câu hỏi của mình thường là công việc của một KIỂM TRA và bạn nên có một bước QA trong quy trình triển khai của mình để xác thực 'bản dựng' mới. Giải pháp tốt nhất mà bạn có thể có là triển khai một tập hợp đơn vị thử nghiệm tối thiểu, ít nhất, lặp lại qua tất cả các thủ tục được lưu trữ của bạn và xác thực việc thực thi của mỗi thứ về tính đúng đắn, trong một triển khai thử nghiệm. Điều đó sẽ giúp loại bỏ hầu hết mọi điều bất ngờ, ít nhất là loại bỏ chúng ở những nơi mà nó gây tổn hại (trong quá trình sản xuất hoặc tại trang web của khách hàng).
Lựa chọn tốt nhất tiếp theo của bạn là dựa vào các công cụ phát triển của bạn để theo dõi những phụ thuộc này. Phiên bản CSDL Visual Studio Database 2008 cung cấp chức năng độc lập như vậy và nó sẽ đảm nhận việc xác thực bất kỳ thay đổi nào bạn thực hiện trong giản đồ.
Và cuối cùng tùy chọn cuối cùng của bạn là làm điều gì đó tương tự như những gì KM đã đề xuất:tự động lặp lại tất cả các thủ tục của bạn tùy thuộc vào đối tượng được sửa đổi (và tất cả các thủ tục tùy thuộc vào các đối tượng phụ thuộc, v.v. một cách đệ quy). Sẽ không đủ để đánh dấu các thủ tục để biên dịch lại, những gì bạn thực sự cần là chạy QUY TRÌNH ALTER để kích hoạt phân tích cú pháp đối với văn bản của nó và xác nhận lược đồ (mọi thứ hơi khác trong T-SQL so với ngôn ngữ thông thường của bạn chu trình biên dịch / thực thi, mỗi lần 'biên dịch' chỉ xảy ra khi thủ tục thực sự được thực thi). Bạn có thể bắt đầu bằng cách lặp lại qua hệ thống sys.sql_dependencies
để tìm tất cả các phụ thuộc của đối tượng đã thay đổi của bạn, đồng thời tìm 'định nghĩa mô-đun' của các phụ thuộc từ 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
Sau đó, bạn có thể chạy qua các 'mô-đun' phụ thuộc và tạo lại chúng (tức là thả chúng và chạy mã trong 'định nghĩa'). Lưu ý rằng 'mô-đun' chung chung hơn một thủ tục được lưu trữ và cũng bao gồm các chế độ xem, trình kích hoạt, chức năng, quy tắc, mặc định và bộ lọc sao chép. Các 'mô-đun' được mã hóa sẽ không có định nghĩa sẵn có và để hoàn toàn chính xác, bạn cũng phải tính đến các cài đặt khác nhau được ghi lại trong sys.sql_modules (ansi nulls, liên kết lược đồ, thực thi dưới dạng mệnh đề, v.v.).
Nếu bạn sử dụng SQL ynamic, điều đó không thể được xác minh. Nó sẽ không bị sys.sql_dependencies nắm bắt , cũng không phải nó sẽ được xác thực bằng cách 'tạo lại' mô-đun.
Nhìn chung, tôi nghĩ rằng tùy chọn tốt nhất của bạn, với một lợi nhuận lớn, là triển khai xác thực kiểm tra đơn vị.
