验证T-SQL存储过程的可靠方法

我们正在从SQL Server 2005升级到2008。在2005实例中，几乎每个数据库都设置为2000兼容模式，但我们现在跳到了2008。我们的测试已经完成，但我们学到的是，我们需要加快测试速度

我发现了一些存储过程，它们要么从丢失的表中选择数据，要么尝试按不存在的列排序

包装SQL以在SET PARSEONLY ON中创建过程，并在try/catch中捕获错误，只捕获ORDER BY中的无效列。从缺少的表中选择数据的过程没有发现错误。然而，SSMS2008的intellisense确实发现了这个问题，但我仍然可以继续并成功地运行该过程的ALTER脚本，而不会引起它的抱怨

那么，为什么我甚至可以创建一个在运行时失败的过程呢？有没有比我尝试过的更好的工具

我发现的第一个工具不是很有用：，但它发现的问题比我在SqlServerCentral上发现的脚本要少，后者发现了无效的列引用

-------------------------------------------------------------------------
-- Check Syntax of Database Objects
-- Copyrighted work.  Free to use as a tool to check your own code or in 
--  any software not sold. All other uses require written permission.
-------------------------------------------------------------------------
-- Turn on ParseOnly so that we don't actually execute anything.
SET PARSEONLY ON 
GO

-- Create a table to iterate through
declare @ObjectList table (ID_NUM int NOT NULL IDENTITY (1, 1), OBJ_NAME varchar(255), OBJ_TYPE char(2))

-- Get a list of most of the scriptable objects in the DB.
insert into @ObjectList (OBJ_NAME, OBJ_TYPE)
SELECT   name, type
FROM     sysobjects WHERE type in ('P', 'FN', 'IF', 'TF', 'TR', 'V')
order by type, name

-- Var to hold the SQL that we will be syntax checking
declare @SQLToCheckSyntaxFor varchar(max)
-- Var to hold the name of the object we are currently checking
declare @ObjectName varchar(255)
-- Var to hold the type of the object we are currently checking
declare @ObjectType char(2)
-- Var to indicate our current location in iterating through the list of objects
declare @IDNum int
-- Var to indicate the max number of objects we need to iterate through
declare @MaxIDNum int
-- Set the inital value and max value
select  @IDNum = Min(ID_NUM), @MaxIDNum = Max(ID_NUM)
from    @ObjectList

-- Begin iteration
while @IDNum <= @MaxIDNum
begin
  -- Load per iteration values here
  select  @ObjectName = OBJ_NAME, @ObjectType = OBJ_TYPE
  from    @ObjectList
  where   ID_NUM = @IDNum 

  -- Get the text of the db Object (ie create script for the sproc)
  SELECT @SQLToCheckSyntaxFor = OBJECT_DEFINITION(OBJECT_ID(@ObjectName, @ObjectType))

  begin try
    -- Run the create script (remember that PARSEONLY has been turned on)
    EXECUTE(@SQLToCheckSyntaxFor)
  end try
  begin catch
    -- See if the object name is the same in the script and the catalog (kind of a special error)
    if (ERROR_PROCEDURE() <> @ObjectName)
    begin
      print 'Error in ' + @ObjectName
      print '  The Name in the script is ' + ERROR_PROCEDURE()+ '. (They don''t match)'
    end
    -- If the error is just that this already exists then  we don't want to report that.
    else if (ERROR_MESSAGE() <> 'There is already an object named ''' + ERROR_PROCEDURE() + ''' in the database.')
    begin
      -- Report the error that we got.
      print 'Error in ' + ERROR_PROCEDURE()
      print '  ERROR TEXT: ' + ERROR_MESSAGE() 
    end
  end catch

  -- Setup to iterate to the next item in the table
  select  @IDNum = case
            when Min(ID_NUM) is NULL then @IDNum + 1
            else Min(ID_NUM)
          end  
  from    @ObjectList
  where   ID_NUM > @IDNum

end
-- Turn the ParseOnly back off.
SET PARSEONLY OFF 
GO

---

我喜欢使用显示估计执行计划。它合理地突出显示了许多错误，而无需真正运行程序。

您可以选择不同的方式。首先，SQL SERVER 2008支持存储过程的DB inclusive dependencies中存在的依赖项，请参见和。您可以使用sys.sql_表达式_依赖项和sys.dm_sql_引用的_实体来查看和验证这些实体

但验证所有存储过程最简单的方法如下：

SELECT OBJECT_NAME(referencing_id) AS referencing_entity_name 
    ,referenced_server_name AS server_name
    ,referenced_database_name AS database_name
    ,referenced_schema_name AS schema_name
    , referenced_entity_name
FROM sys.sql_expression_dependencies 
WHERE referencing_id = OBJECT_ID(N'spMyStoredProcedure');

导出所有存储过程 删除旧的现有存储过程 导入刚导出的存储过程。 如果升级DB，则不会验证现有存储过程，但如果创建新存储过程，则会验证该过程。所以，在导出和导出所有存储过程之后，您将收到所有已报告的现有错误

您还可以使用如下代码查看和导出存储过程的代码

SELECT definition
FROM sys.sql_modules
WHERE object_id = (OBJECT_ID(N'spMyStoredProcedure'))

更新：要查看存储过程SPMyStoredProcess引用的表和视图等对象，可以使用以下命令：

SELECT OBJECT_NAME(referencing_id) AS referencing_entity_name 
    ,referenced_server_name AS server_name
    ,referenced_database_name AS database_name
    ,referenced_schema_name AS schema_name
    , referenced_entity_name
FROM sys.sql_expression_dependencies 
WHERE referencing_id = OBJECT_ID(N'spMyStoredProcedure');

更新2：在对我的回答的评论中，Martin Smith建议使用sys.sp_refreshsqlmodule，而不是重新创建存储过程。那么代码呢

SELECT 'EXEC sys.sp_refreshsqlmodule ''' + OBJECT_SCHEMA_NAME(object_id) +
              '.' + name + '''' FROM sys.objects WHERE type in (N'P', N'PC')

您将收到一个脚本，该脚本可用于验证存储过程的依赖关系。AdventureWorks2008的输出将如以下示例所示：

EXEC sys.sp_refreshsqlmodule 'dbo.uspGetManagerEmployees'
EXEC sys.sp_refreshsqlmodule 'dbo.uspGetWhereUsedProductID'
EXEC sys.sp_refreshsqlmodule 'dbo.uspPrintError'
EXEC sys.sp_refreshsqlmodule 'HumanResources.uspUpdateEmployeeHireInfo'
EXEC sys.sp_refreshsqlmodule 'dbo.uspLogError'
EXEC sys.sp_refreshsqlmodule 'HumanResources.uspUpdateEmployeeLogin'
EXEC sys.sp_refreshsqlmodule 'HumanResources.uspUpdateEmployeePersonalInfo'
EXEC sys.sp_refreshsqlmodule 'dbo.uspSearchCandidateResumes'
EXEC sys.sp_refreshsqlmodule 'dbo.uspGetBillOfMaterials'
EXEC sys.sp_refreshsqlmodule 'dbo.uspGetEmployeeManagers'

---

我在以前的一个项目中遇到了同样的问题，并在SQL2005上写了一篇文章，后来又写了一篇实现相同功能的文章。

当我遇到这个问题时，我感兴趣的是找到一种安全、无创、快速的技术来验证语法和对象表、列引用

-------------------------------------------------------------------------
-- Check Syntax of Database Objects
-- Copyrighted work.  Free to use as a tool to check your own code or in 
--  any software not sold. All other uses require written permission.
-------------------------------------------------------------------------
-- Turn on ParseOnly so that we don't actually execute anything.
SET PARSEONLY ON 
GO

-- Create a table to iterate through
declare @ObjectList table (ID_NUM int NOT NULL IDENTITY (1, 1), OBJ_NAME varchar(255), OBJ_TYPE char(2))

-- Get a list of most of the scriptable objects in the DB.
insert into @ObjectList (OBJ_NAME, OBJ_TYPE)
SELECT   name, type
FROM     sysobjects WHERE type in ('P', 'FN', 'IF', 'TF', 'TR', 'V')
order by type, name

-- Var to hold the SQL that we will be syntax checking
declare @SQLToCheckSyntaxFor varchar(max)
-- Var to hold the name of the object we are currently checking
declare @ObjectName varchar(255)
-- Var to hold the type of the object we are currently checking
declare @ObjectType char(2)
-- Var to indicate our current location in iterating through the list of objects
declare @IDNum int
-- Var to indicate the max number of objects we need to iterate through
declare @MaxIDNum int
-- Set the inital value and max value
select  @IDNum = Min(ID_NUM), @MaxIDNum = Max(ID_NUM)
from    @ObjectList

-- Begin iteration
while @IDNum <= @MaxIDNum
begin
  -- Load per iteration values here
  select  @ObjectName = OBJ_NAME, @ObjectType = OBJ_TYPE
  from    @ObjectList
  where   ID_NUM = @IDNum 

  -- Get the text of the db Object (ie create script for the sproc)
  SELECT @SQLToCheckSyntaxFor = OBJECT_DEFINITION(OBJECT_ID(@ObjectName, @ObjectType))

  begin try
    -- Run the create script (remember that PARSEONLY has been turned on)
    EXECUTE(@SQLToCheckSyntaxFor)
  end try
  begin catch
    -- See if the object name is the same in the script and the catalog (kind of a special error)
    if (ERROR_PROCEDURE() <> @ObjectName)
    begin
      print 'Error in ' + @ObjectName
      print '  The Name in the script is ' + ERROR_PROCEDURE()+ '. (They don''t match)'
    end
    -- If the error is just that this already exists then  we don't want to report that.
    else if (ERROR_MESSAGE() <> 'There is already an object named ''' + ERROR_PROCEDURE() + ''' in the database.')
    begin
      -- Report the error that we got.
      print 'Error in ' + ERROR_PROCEDURE()
      print '  ERROR TEXT: ' + ERROR_MESSAGE() 
    end
  end catch

  -- Setup to iterate to the next item in the table
  select  @IDNum = case
            when Min(ID_NUM) is NULL then @IDNum + 1
            else Min(ID_NUM)
          end  
  from    @ObjectList
  where   ID_NUM > @IDNum

end
-- Turn the ParseOnly back off.
SET PARSEONLY OFF 
GO

虽然我同意实际执行每个存储过程可能会遇到比编译它们更多的问题，但必须谨慎使用前一种方法。也就是说，您需要知道，实际上，执行每个存储过程是安全的，例如，它是否会擦除某些表？。正如devio在回答中所建议的那样，可以通过在事务中包装执行并回滚它来解决这个安全问题，这样就不会有永久性的更改。不过，这种方法可能需要相当长的时间，这取决于您正在处理的数据量

问题中的代码和Oleg答案的第一部分都建议重新实例化每个存储过程，因为该操作会重新编译过程并进行语法验证。但是这种方法是侵入性的，对于私有测试系统来说是可以的，但是可能会干扰其他开发人员在大量使用的测试系统上的工作

我偶然看到了这篇文章，它提供了一个.NET解决方案，但更吸引我的是ddblue的底部。这种方法获取每个存储过程的文本，将create关键字转换为alter以便对其进行编译，然后编译过程。这会准确地报告任何错误的表和列引用。代码运行了，但由于create/alter转换步骤，我很快遇到了一些问题

从create到alter的转换查找由单个空格分隔的create和PROC。在现实世界中，可能有空格或制表符，也可能有一个或多个。我添加了一个嵌套替换序列，感谢Jeff Moden！将所有此类引用转换为单个空间，使转换按原始设计进行。然后，由于这需要在使用原始sm.definition表达式的地方使用，因此我添加了一个公共表表达式，以避免大量、难看的代码重复。下面是我的代码更新版本：

DECLARE @Schema NVARCHAR(100),
    @Name NVARCHAR(100),
    @Type NVARCHAR(100),
    @Definition NVARCHAR(MAX),
    @CheckSQL NVARCHAR(MAX)

DECLARE crRoutines CURSOR FOR
WITH System_CTE ( schema_name, object_name, type_desc, type, definition, orig_definition)
AS -- Define the CTE query.
( SELECT    OBJECT_SCHEMA_NAME(sm.object_id) ,
            OBJECT_NAME(sm.object_id) ,
            o.type_desc ,
            o.type,
            REPLACE(REPLACE(REPLACE(LTRIM(RTRIM(REPLACE(sm.definition, char(9), ' '))), '  ', ' ' + CHAR(7)), CHAR(7) + ' ', ''), CHAR(7), '') [definition],
            sm.definition [orig_definition]
  FROM      sys.sql_modules (NOLOCK) AS sm
            JOIN sys.objects (NOLOCK) AS o ON sm.object_id = o.object_id
  -- add a WHERE clause here as indicated if you want to test on a subset before running the whole list.
  --WHERE     OBJECT_NAME(sm.object_id) LIKE 'xyz%'
)
-- Define the outer query referencing the CTE name.
SELECT  schema_name ,
        object_name ,
        type_desc ,
        CASE WHEN type_desc = 'SQL_STORED_PROCEDURE'
             THEN STUFF(definition, CHARINDEX('CREATE PROC', definition), 11, 'ALTER PROC')
             WHEN type_desc LIKE '%FUNCTION%'
             THEN STUFF(definition, CHARINDEX('CREATE FUNC', definition), 11, 'ALTER FUNC')
             WHEN type = 'VIEW'
             THEN STUFF(definition, CHARINDEX('CREATE VIEW', definition), 11, 'ALTER VIEW')
             WHEN type = 'SQL_TRIGGER'
             THEN STUFF(definition, CHARINDEX('CREATE TRIG', definition), 11, 'ALTER TRIG')
        END
FROM    System_CTE
ORDER BY 1 , 2;

OPEN crRoutines

FETCH NEXT FROM crRoutines INTO @Schema, @Name, @Type, @Definition

WHILE @@FETCH_STATUS = 0 
    BEGIN
        IF LEN(@Definition) > 0
            BEGIN
                -- Uncomment to see every object checked.
                -- RAISERROR ('Checking %s...', 0, 1, @Name) WITH NOWAIT
                BEGIN TRY
                    SET PARSEONLY ON ;
                    EXEC ( @Definition ) ;
                    SET PARSEONLY OFF ;
                END TRY
                BEGIN CATCH
                    PRINT @Type + ': ' + @Schema + '.' + @Name
                    PRINT ERROR_MESSAGE() 
                END CATCH
            END
        ELSE
            BEGIN
                RAISERROR ('Skipping %s...', 0, 1, @Name) WITH NOWAIT
            END
        FETCH NEXT FROM crRoutines INTO @Schema, @Name, @Type, @Definition
    END

CLOSE crRoutines
DEALLOCATE crRoutines

---

以下是对我有效的方法：

-- Based on comment from http://blogs.msdn.com/b/askjay/archive/2012/07/22/finding-missing-dependencies.aspx
-- Check also http://technet.microsoft.com/en-us/library/bb677315(v=sql.110).aspx

select o.type, o.name, ed.referenced_entity_name, ed.is_caller_dependent
from sys.sql_expression_dependencies ed
join sys.objects o on ed.referencing_id = o.object_id
where ed.referenced_id is null

您应该获得SP缺少的所有依赖项，从而解决后期绑定的问题

例外：is_caller_dependent=1并不一定意味着依赖关系已断开。只是 表示在运行时解析依赖关系，因为未指定引用对象的架构。例如，可以避免在另一个SP中指定被引用对象的架构

---

在我第一次提出这个问题九年后，我发现了一个由微软自己构建的惊人工具，它不仅可以可靠地验证SQL Server版本之间的存储过程兼容性，而且还可以验证所有其他内部方面。它被重命名过几次，但他们现在称之为：

Microsoft®数据迁移助手v4.2 Data Migration Assistant DMA通过检测可能影响新版本SQL Server上数据库功能的兼容性问题，使您能够升级到现代数据平台。它建议为您的目标环境改进性能和可靠性。它不仅允许您将模式和数据，还允许将未包含的对象从源服务器移动到目标服务器

上面使用EXEC sys.sp_refreshsqlmodule的答案是一个很好的开始，但我们在2008 R2上运行它时遇到了一个主要问题：任何使用sp_rename重命名的存储过程或函数，而不是在运行刷新过程后还原为其先前定义的拖放/创建模式，因为内部元数据不会以新名称刷新。这是一个在SQLServer2012中修复的已知错误，但我们在之后的恢复中度过了愉快的一天。一种解决方法，future readers，是在刷新引发错误时发出回滚

---

不管怎么说，时代变了，新的工具出现了，而且在这方面也有很好的工具，因此，这个答案的添加很晚。

也许通过运行自动回归测试，你会发现什么被破坏了，并且能够在存储过程级别上跟踪它。你也可以尝试设置NOEXEC并执行每个存储过程，但我发现这也不会得到很多错误。EXEC sys.sp_refreshsqlmodule捕获某些错误部分成功。我发现的唯一可靠的方法是运行一个工具来实际执行每个存储过程，表值函数为每个参数传递NULL，然后回滚它并记录任何故障。从每个视图中进行选择显然，这取决于您的过程有多耗时，以及它们的确切性质，这将工作得有多好。@John-HA！自动回归测试。。。不适用于这些数据库。近两年来，我们一直在努力清理客户的烂摊子！虽然我同意，这是一条路要走，但我们没有时间开发测试。嗨！您是否使用存储过程的导出/导入或sys.sp_refreshsqlmodule进行了测试请参见我的答案？它与您的数据库一起工作吗？在DBA站点上查看。您可以使用sys.procedures而不是sys.views。除了编写数据库过程、函数、视图和将CREATE更改为ALTER之外，这还有什么好处吗？或者运行EXEC sys.sp_refreshsqlmodule？我本以为这会更好，因为你们不依赖于创造顺序。我不尝试，但我的方法很简单。在SQLServerManagementStudio中，您可以生成一个存储过程的脚本，也可以为数据库编写完整的脚本。因此，单击几次之后，可以生成包含所有存储过程的脚本。只需删除所有存储过程并在其中创建即可。@Martin在我看来你是对的。EXEC sys.sp_refreshsqlmodule'spmyStoredProcess'将优化我的建议。将它与sp_MSforeachtable一起使用将非常有效。我们最终采取了“发现问题就解决问题”的方法，这是我最不想做的事情，因为我们没有时间创建一个彻底的解决方案。不过，这个答案似乎是处理这个问题的一个非常好的方式，因此我将接受它作为一个答案。我希望我能很快尝试一下：看起来很聪明。当我不在工作时，我会尝试一下。但是，这段代码中有几个小错误。在外部查询中的CASE语句中，最后两个CASE应该以WHEN type_desc=开始，而不是WHEN type=。我使用了它，尽管它确实产生了一些误报。例如，如果存储过程引用了另一个数据库中的对象，它会认为存在错误的引用。此外，它还将系统存储过程识别为问题。例如，我们的一些存储过程中使用了sp_send_dbmail，并将其标记为错误引用。尽管如此，我还是为分享这一点而感到荣幸。这将我所有的操作都标记为误报。他们都有is_dimensional=1，所以这似乎是一个额外的过滤器。