Alterando o uso de GETDATE () em todo o banco de dados

Preciso migrar um banco de dados local do SQL Server 2017 para um banco de dados SQL do Azure e estou enfrentando alguns desafios, pois há algumas limitações a serem enfrentadas.

Em particular, como um banco de dados SQL do Azure funciona apenas no horário UTC (sem fuso horário) e precisamos do horário local, precisamos alterar o uso de GETDATE() qualquer lugar no banco de dados, o que provou ser mais trabalhoso do que eu esperava.

Criei uma função definida pelo usuário para obter a hora local que funciona corretamente para o meu fuso horário:

CREATE FUNCTION [dbo].[getlocaldate]()
RETURNS datetime
AS
BEGIN
    DECLARE @D datetimeoffset;
    SET @D = CONVERT(datetimeoffset, SYSDATETIMEOFFSET()) AT TIME ZONE 'Pacific SA Standard Time';
    RETURN(CONVERT(datetime,@D));
END

O problema com o qual estou tendo problemas é realmente mudar GETDATE()com essa função em todas as visualizações, procedimentos armazenados, colunas computadas, valores padrão, outras restrições etc.

Qual seria a melhor maneira de implementar essa mudança?

Estamos na pré-visualização pública de Instâncias gerenciadas . Ele ainda tem o mesmo problema e GETDATE(), portanto, não ajuda com esse problema. Mover para o Azure é um requisito. Esse banco de dados é usado (e será usado) sempre neste fuso horário.

1. Use a ferramenta SQL Server para exportar a definição de objetos de banco de dados para um arquivo SQL que deve incluir: tabelas, visualizações, gatilhos, SPs, funções e assim por diante

2. Edite o arquivo SQL (faça um backup primeiro) usando qualquer editor de texto que permita localizar o texto "GETDATE()"e substituí-lo por"[dbo].[getlocaldate]()"

3. Execute o arquivo SQL editado no SQL do Azure para criar seus objetos de banco de dados ...

4. Execute a migração de dados.

Aqui você tem uma referência da documentação do azure: Gerando scripts para o SQL Azure

Qual seria a melhor maneira de implementar essa mudança?

Eu trabalharia o contrário. Converta todos os seus carimbos de data e hora no banco de dados para UTC e use apenas o UTC e siga o fluxo. Se você precisar de um carimbo de data e hora em um tz diferente, poderá criar uma coluna gerada usando AT TIME ZONE(como você fez acima) que renderiza o carimbo de data e hora na TZ especificada (para o aplicativo). Mas, seriamente, consideraria apenas ter o UTC retornado ao aplicativo e escrever essa lógica - a lógica de exibição - no aplicativo.

Em vez de exportar, editar manualmente e executar novamente, você pode tentar fazer o trabalho diretamente no banco de dados com algo como:

DECLARE C CURSOR FOR
        SELECT sm.definition, so.type
        FROM   sys.objects so
        JOIN   sys.all_sql_modules sm ON sm.object_id = so.object_id
        WHERE  so.type IN ('P', 'V')
        ORDER BY so.name
DECLARE @SQL NVARCHAR(MAX), @ojtype NVARCHAR(MAX)
OPEN C
FETCH NEXT FROM C INTO @SQL, @ojtype
WHILE @@FETCH_STATUS = 0 BEGIN
    IF @objtype = 'P' SET @SQL = REPLACE(@SQL, 'CREATE PROCEDURE', 'ALTER PROCEDURE') 
    IF @objtype = 'V' SET @SQL = REPLACE(@SQL, 'CREATE VIEW'     , 'ALTER VIEW'     ) 
    SET @SQL = REPLACE(@SQL, 'GETDATE()', '[dbo].[getlocaldate]()') 
    --PRINT @SQL
    EXEC (@SQL)
    FETCH NEXT FROM C INTO @SQL, @ojtype
END
CLOSE C
DEALLOCATE C

é claro estendendo-o para lidar com funções, gatilhos e assim por diante também.

Existem algumas ressalvas:

• Você pode precisar ser um pouco mais inteligente e lidar com espaços em branco diferentes / extras entre CREATEe PROCEDURE/ VIEW/ <other>. Ao invés do REPLACEpara que você pode preferir deixar em vez disso o CREATEno lugar e executar um DROPprimeiro, mas esta riscos deixando sys.dependse amigos fora dos eixos, onde ALTERnão podem, também, se ALTERfalhar, você pelo menos tem o objeto existente ainda no lugar onde, com DROP+ CREATEvocê pode não.

• Se você codificar algum cheiro "inteligente", como modificar seu próprio esquema com TSQL ad-hoc, será necessário garantir que a pesquisa e a substituição de CREATE-> ALTERnão interfiram nisso.

• Você desejará testar a regressão do (s) aplicativo (s) inteiro (s) após a operação, independentemente de usar o cursor ou exportar + editar + executar métodos.

Eu usei esse método para fazer atualizações semelhantes em todo o esquema no passado. É um pouco complicado, e parece muito feio, mas às vezes é a maneira mais fácil / rápida.

Padrões e outras restrições também podem ser modificados da mesma forma, embora apenas possam ser eliminados e recriados em vez de alterados. Algo como:

DECLARE C CURSOR FOR
        SELECT AlterDefaultSQL = 'ALTER TABLE [' +st.name+ '] DROP CONSTRAINT [' + si.name + '];'
                               + CHAR(10)
                               + 'ALTER TABLE [' +st.name+ '] ADD CONSTRAINT [' + si.name + '] DEFAULT '+REPLACE(si.definition, 'GETDATE()', '[dbo].[getlocaldate]()')+' FOR '+sc.name+';'
        FROM   sys.tables st
        JOIN   sys.default_constraints si ON si.parent_object_id = st.object_id
        JOIN   sys.columns sc ON sc.default_object_id = si.object_id
DECLARE @SQL NVARCHAR(MAX)
OPEN C
FETCH NEXT FROM C INTO @SQL
WHILE @@FETCH_STATUS = 0 BEGIN
    --PRINT @SQL
    EXEC (@SQL)
    FETCH NEXT FROM C INTO @SQL
END
CLOSE C
DEALLOCATE C

Um pouco mais divertido com o qual você pode precisar lidar: se você estiver particionando com o tempo, essas partes também precisarão ser alteradas. Embora o particionamento no horário mais granularmente do que o dia seja raro, você pode ter problemas em que DATETIMEs são interpretados pela função de particionamento como sendo o dia anterior ou o próximo, dependendo do fuso horário, deixando suas partições desalinhadas com as consultas habituais.

Eu realmente gosto da resposta de David e votei nisso por uma maneira programática de fazer as coisas.

Mas você pode tentar isso hoje para uma execução de teste no Azure via SSMS:

Clique com o botão direito do mouse em seu banco de dados -> Tarefas -> Gerar scripts.

[História anterior], tivemos um DBA júnior que atualizou todos os nossos ambientes de teste para o SQL 2008 R2 enquanto nossos ambientes de produção estavam no SQL 2008. É uma mudança que me faz estremecer até hoje. Para migrar para a produção, a partir do teste, tivemos que gerar scripts dentro do SQL, usando gerar scripts, e nas opções avançadas usamos a opção 'Tipo de dados para script: esquema e dados' para gerar um arquivo de texto massivo. Conseguimos mover com êxito nossos bancos de dados R2 de teste para nossos servidores herdados do SQL 2008 - onde uma restauração de banco de dados para uma versão inferior não teria funcionado. Usamos o sqlcmd para inserir o arquivo grande - pois os arquivos geralmente eram grandes demais para o buffer de texto do SSMS.

O que estou dizendo aqui é que essa opção provavelmente funcionaria para você também. Você só precisará executar uma etapa adicional e pesquisar e substituir getdate () por [dbo] .getlocaldate no arquivo de texto gerado. (Eu colocaria sua função no banco de dados antes da migração).

(Eu nunca quis ser proficiente nesse curativo de restauração de banco de dados, mas por um tempo tornou-se uma maneira defacto de fazer as coisas. E funcionou sempre.)

Se você escolher esta rota, certifique-se de selecionar o botão Avançado e todas as opções necessárias (leia cada uma) para passar do banco de dados antigo para o novo - como os padrões mencionados. Mas faça alguns testes no Azure. Aposto que você descobrirá que essa é uma solução que funciona - com um mínimo de esforço.

Altere dinamicamente todos os proc e udf para alterar o valor

    DECLARE @Text   NVARCHAR(max), 
        @spname NVARCHAR(max), 
        @Type   CHAR(5), 
        @Sql    NVARCHAR(max) 
DECLARE @getobject CURSOR 

SET @getobject = CURSOR 
FOR SELECT sc.text, 
           so.NAME, 
           so.type 
    FROM   sys.syscomments sc 
           INNER JOIN sysobjects so 
                   ON sc.id = so.id 
    WHERE  sc.[text] LIKE '%getdate()%' 

--and type in('P','FN') 
OPEN @getobject 

FETCH next FROM @getobject INTO @Text, @spname, @Type 

WHILE @@FETCH_STATUS = 0 
  BEGIN 
      IF ( @Type = 'P' 
            OR @Type = 'FN' ) 
        SET @Text = Replace(@Text, 'getdate', 'dbo.getlocaldate') 

      SET @Text = Replace(@Text, 'create', 'alter') 

      EXECUTE Sp_executesql 
        @Text 

      PRINT @Text 

      --,@spname,@Type 
      FETCH next FROM @getobject INTO @Text, @spname, @Type 
  END 

CLOSE @getobject 

DEALLOCATE @getobject  

    CREATE PROCEDURE [dbo].[Testproc1] 
AS 
    SET nocount ON; 

  BEGIN 
      DECLARE @CurDate DATETIME = Getdate() 
  END

Observe que os sysobjects comentados digitam a condição da coluna. Meu script alterará apenas proc e UDF.

Este script irá alterar tudo o Default Constraintque contémGetDate()

    DECLARE @TableName      VARCHAR(300), 
        @constraintName VARCHAR(300), 
        @colName        VARCHAR(300), 
        @Sql            NVARCHAR(max) 
DECLARE @getobject CURSOR 

SET @getobject = CURSOR 
FOR SELECT ds.NAME, 
           sc.NAME AS colName, 
           so.NAME AS Tablename 
    --,ds.definition 
    FROM   sys.default_constraints ds 
           INNER JOIN sys.columns sc 
                   ON ds.object_id = sc.default_object_id 
           INNER JOIN sys.objects so 
                   ON so.object_id = ds.parent_object_id 
    WHERE  definition LIKE '%getdate()%' 

OPEN @getobject 

FETCH next FROM @getobject INTO @constraintName, @colName, @TableName 

WHILE @@FETCH_STATUS = 0 
  BEGIN 
      SET @Sql = 'ALTER TABLE ' + @TableName 
                 + ' DROP CONSTRAINT ' + @constraintName + '; ' 
                 + Char(13) + Char(10) + '           ' + Char(13) + Char(10) + '' 
      SET @Sql = @Sql + ' ALTER TABLE ' + @TableName 
                 + ' ADD CONSTRAINT ' + @constraintName 
                 + '          DEFAULT dbo.GetLocaledate() FOR ' 
                 + @colName + ';' + Char(13) + Char(10) + '          ' + Char(13) 
                 + Char(10) + '' 

      PRINT @Sql 

      EXECUTE sys.Sp_executesql 
        @Sql 

      --,@spname,@Type 
      FETCH next FROM @getobject INTO @constraintName, @colName, @TableName 
  END 

CLOSE @getobject 

DEALLOCATE @getobject   

Promovi a resposta de Evan Carrolls, pois acho que essa é a melhor solução. Não consegui convencer meus colegas de que eles deveriam alterar muito código C #; portanto, tive que usar o código que David Spillett escreveu. Corrigi alguns problemas com UDFs, SQL dinâmico e esquemas (nem todos os códigos usam "dbo.") Como este:

DECLARE C CURSOR LOCAL STATIC FOR
        SELECT sm.definition, so.type
        FROM   sys.objects so
        JOIN   sys.all_sql_modules sm ON sm.object_id = so.object_id
        WHERE  so.type IN ('P', 'V')
        AND CHARINDEX('getdate()', sm.definition) > 0
        ORDER BY so.name

DECLARE @SQL NVARCHAR(MAX), @objtype NVARCHAR(MAX)
OPEN C
WHILE 1=1 BEGIN
    FETCH NEXT FROM C INTO @SQL, @objtype
    IF @@FETCH_STATUS <> 0 BREAK

    IF @objtype = 'P' SET @SQL = REPLACE(@SQL, 'CREATE PROCEDURE', 'ALTER PROCEDURE') 
    IF @objtype = 'P' SET @SQL = REPLACE(@SQL, 'CREATE   PROCEDURE', 'ALTER PROCEDURE') /* when you write "create or alter proc" */
    IF @objtype = 'V' SET @SQL = REPLACE(@SQL, 'CREATE VIEW'     , 'ALTER VIEW'     ) 
    IF CHARINDEX('getdate())''', @sql) > 0 BEGIN  /* when dynamic SQL is used */
        IF CHARINDEX('utl.getdate())''', @sql) = 0 SET @SQL = REPLACE(@SQL, 'GETDATE()', 'utl.getdate()') 
    end
    ELSE begin
        SET @SQL = REPLACE(@SQL, 'GETDATE()', 'CONVERT(DATETIME, CONVERT(datetimeoffset,  SYSDATETIME()) AT TIME ZONE ''Central Europe Standard Time'')') 
    end
    EXEC dbo.LongPrint @String = @sql    
    EXEC (@SQL)
END
CLOSE C
DEALLOCATE C

e as restrições padrão como esta:

DECLARE C CURSOR LOCAL STATIC FOR
        SELECT AlterDefaultSQL = 'ALTER TABLE [' +sch.name+ '].[' +st.name+ '] DROP CONSTRAINT [' + si.name + '];'
                               + CHAR(10)
                               + 'ALTER TABLE [' +sch.name+ '].[' +st.name+ '] ADD CONSTRAINT [' + si.name + '] DEFAULT '+REPLACE(si.definition, 'GETDATE()', 'CONVERT(DATETIME, CONVERT(datetimeoffset,  SYSDATETIME()) AT TIME ZONE ''Central Europe Standard Time'')')+' FOR '+sc.name+';'
        FROM   sys.tables st
        JOIN   sys.default_constraints si ON si.parent_object_id = st.object_id
        JOIN   sys.columns sc ON sc.default_object_id = si.object_id
        INNER JOIN sys.schemas sch ON sch.schema_id = st.schema_id
        WHERE CHARINDEX('getdate()', si.definition) > 0
        ORDER BY st.name, sc.name

DECLARE @SQL NVARCHAR(MAX)
OPEN C
WHILE 1=1 BEGIN
    FETCH NEXT FROM C INTO @SQL
    IF @@FETCH_STATUS <> 0 BREAK

    EXEC dbo.LongPrint @String = @sql  
    EXEC (@SQL)
    FETCH NEXT FROM C INTO @SQL
END
CLOSE C
DEALLOCATE C

UDFs
A sugestão de usar um UDF que retorne a data e a hora de hoje parece bom, mas acho que ainda existem problemas de desempenho suficientes com os UDFs, por isso escolhi usar a solução AT TIME ZONE muito longa e feia.