Início / dba / Perguntas / 33541
Accepted
cja
Asked: 2013-01-26 05:02:48 +0800 CST

Como manter o histórico de revisões de procedimento armazenado do SQL Server

  • 772

Nota: não estou perguntando sobre o controle de versão completo.

Existe alguma maneira automática de manter um histórico de procedimentos armazenados no SQL Server.

Semelhante à forma como o Google Docs mantém automaticamente um histórico de versões de documentos e a Wikipedia mantém automaticamente um histórico de versões de artigos.

Não quero que os usuários atualizando procedimentos armazenados também tenham que manter um repositório de procedimentos armazenados. Isso é muito trabalho e as pessoas não vão fazer isso.

Espero que isso seja algo que eu possa ativar no SQL Server ...

(E por procedimentos armazenados realmente quero dizer funções, gatilhos, etc. Basicamente tudo em Programabilidade.)

Postei em https://stackoverflow.com/questions/14522224/how-to-keep-history-of-sql-server-stored-procedure-revisions primeiro porque suspeito que obteria mais visualizações lá.

sql-server stored-procedures

2 respostas

  1. Best Answer

    Embora eu concorde totalmente que o controle de origem é a maneira correta de fazer isso, também entendo que nem todos os ambientes são disciplinados o suficiente para depender apenas disso (se for o caso), e que às vezes as alterações precisam ser feitas diretamente para manter o aplicativo executando, salve um cliente, o que você tem.

    Você pode usar um gatilho DDL para manter todas as revisões em uma tabela em um banco de dados separado (e, claro, fazer backup desse banco de dados com frequência). Supondo que você tenha um banco de dados utilitário:

    USE Utility;
GO


CREATE TABLE dbo.ProcedureChanges
(
    EventDate    DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    EventType    NVARCHAR(100),
    EventDDL     NVARCHAR(MAX),
    DatabaseName NVARCHAR(255),
    SchemaName   NVARCHAR(255),
    ObjectName   NVARCHAR(255),
    HostName     NVARCHAR(255),
    IPAddress    VARCHAR(32),
    ProgramName  NVARCHAR(255),
    LoginName    NVARCHAR(255)
);

    Agora em seu banco de dados, primeiro vamos pegar o que chamaremos de "controle inicial" - a versão atual dos procedimentos armazenados:

    USE YourDB;
GO

INSERT Utility.dbo.ProcedureChanges
(
    EventType,
    EventDDL,
    DatabaseName,
    SchemaName,
    ObjectName
)
SELECT
    N'Initial control',
    OBJECT_DEFINITION([object_id]),
    DB_NAME(),
    OBJECT_SCHEMA_NAME([object_id]),
    OBJECT_NAME([object_id])
FROM
    sys.procedures;

    Agora, para capturar as alterações subsequentes, adicione um gatilho DDL ao banco de dados:

    USE YourDB;
GO

CREATE TRIGGER CaptureStoredProcedureChanges
    ON DATABASE
    FOR CREATE_PROCEDURE, ALTER_PROCEDURE, DROP_PROCEDURE
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @EventData XML = EVENTDATA(), @ip VARCHAR(32);

    SELECT @ip = client_net_address
        FROM sys.dm_exec_connections
        WHERE session_id = @@SPID;

    INSERT Utility.dbo.ProcedureChanges
    (
        EventType,
        EventDDL,
        SchemaName,
        ObjectName,
        DatabaseName,
        HostName,
        IPAddress,
        ProgramName,
        LoginName
    )
    SELECT
        @EventData.value('(/EVENT_INSTANCE/EventType)[1]',   'NVARCHAR(100)'), 
        @EventData.value('(/EVENT_INSTANCE/TSQLCommand)[1]', 'NVARCHAR(MAX)'),
        @EventData.value('(/EVENT_INSTANCE/SchemaName)[1]',  'NVARCHAR(255)'), 
        @EventData.value('(/EVENT_INSTANCE/ObjectName)[1]',  'NVARCHAR(255)'),
        DB_NAME(), HOST_NAME(), @ip, PROGRAM_NAME(), SUSER_SNAME();
END
GO

    Com o tempo, será fácil ver e comparar as alterações nos procedimentos, observar os novos procedimentos serem adicionados ao sistema, ver os procedimentos serem descartados e ter uma boa ideia de com quem falar sobre qualquer um desses eventos.

    Mais informações aqui:

    http://www.mssqltips.com/sqlservertip/2085/sql-server-ddl-triggers-to-track-all-database-changes/

    • 31

  2. Eu não acho que exista uma maneira de manter automaticamente seu código-fonte SQL sob controle de versão. Quero dizer, com ferramentas nativas do SQL Server. Eu acho que você pode acabar usando git ou svn, mas a melhor solução para mim foi comprar o controle de origem da Red Gate para manter bancos de dados (e procedimentos armazenados) sob controle de versão.

    • 2

relate perguntas