As tabelas com otimização de memória armazenam tipos de LOB em tabelas internas.

Eu tenho uma tabela sem tipos LOB explícitos, mas quando executo uma consulta em sys.memory_optimized_tables_internal_attributes , vejo colunas varchar(255) listadas com um valor type_desc de INTERNAL OFF-ROW DATA TABLE.

SET ANSI_NULLS ON;
GO

SET QUOTED_IDENTIFIER ON;
GO

SET ANSI_PADDING ON;
GO

CREATE TABLE dbo.DERP
(
    RECORD_KEY numeric(30, 0) NOT NULL
,   COL_1 bigint NOT NULL
,   COL_2 datetime2(0) NOT NULL
,   COL_3 datetime2(0) NOT NULL
,   COL_4 varchar(20) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_5 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_6 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_7 date NULL
,   COL_8 bigint NULL
,   COL_9 char(1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_10 int NULL
,   COL_11 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_12 int NULL
,   COL_13 char(1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_14 char(1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_15 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_16 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_17 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_18 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_19 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_20 char(3) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_21 bigint NULL
,   COL_22 bigint NULL
,   COL_23 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_24 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_25 int NULL
,   COL_26 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_27 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_28 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_29 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_30 decimal(7, 4) NULL
,   COL_31 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_32 decimal(8, 4) NULL
,   COL_33 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_34 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_35 char(1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_36 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_37 int NULL
,   COL_38 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_39 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_40 char(1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_41 int NULL
,   COL_42 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_43 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_44 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_45 int NULL
,   COL_46 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_47 char(1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_48 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_49 int NULL
,   COL_50 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_51 int NULL
,   COL_52 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_53 char(1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_54 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_55 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_56 char(1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_57 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_58 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_59 char(1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_60 char(1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_61 date NULL
,   COL_62 char(2) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_63 int NULL
,   COL_64 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_65 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_66 int NULL
,   COL_67 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_68 int NULL
,   COL_69 char(1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_70 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_71 char(1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_72 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_73 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_74 char(3) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_75 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_76 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_77 char(3) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_78 char(2) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_79 varchar(255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,   COL_80 bigint NULL
,   CONSTRAINT dbo_DERP
        PRIMARY KEY NONCLUSTERED
        (
            RECORD_KEY ASC
        )
)
WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);

GO

SET ANSI_PADDING OFF;
GO

A execução da consulta a seguir gera 10 colunas (COL_58, COL_64, COL_65, COL_67, COL_70, COL_72, COL_73, COL_75, COL_76, COL_79) listadas como tabela de dados fora da linha

SELECT
    QUOTENAME(SCHEMA_NAME(o.schema_id)) + N'.' + QUOTENAME(OBJECT_NAME(moa.object_id)) AS 'table'
,   c.name AS 'column'
,   c.max_length
,   moa.type_desc
FROM
    sys.memory_optimized_tables_internal_attributes moa
    INNER JOIN
        sys.columns c
        ON moa.object_id = c.object_id
           AND moa.minor_id = c.column_id
    INNER JOIN
        sys.objects o
        ON moa.object_id = o.object_id
WHERE
    o.name = 'DERP'
ORDER BY
    1;

Presumo que essa decisão de armazenamento seja baseada no fato de essa tabela ser super ampla (quase 10.400 bytes de largura), sim?

SQL Server 2016 SP1, CU2, também conhecido como 13.0.4422.0

Entrei nos sistemas de um novo cliente e executei sp_blitz para ver o que está tremendo. Ele relata que " CPU Schedulers Offline ", que é novo para mim.

Alguns núcleos de CPU não são acessíveis ao SQL Server devido a problemas de mascaramento de afinidade ou licenciamento.

Justo, eu executo a consulta base

SELECT
    DOS.is_online
,   DOS.status
,   DOS.*
FROM
    sys.dm_os_schedulers AS DOS
ORDER BY
    1;

Isso informa que tenho 8 configurados para VISÍVEL OFFLINE, 43 para online. Que eu saiba, ninguém neste cliente teria definido intencionalmente qualquer afinidade de CPU.

Eu decidi ver se eu poderia descompactá-lo. Quando olho para a janela de propriedades, vejo 40 processadores disponíveis e nenhum deles configurado para ter afinidade.

Por que há 40 exibindo ainda 43 entradas no dm_os_schedulers onde is_online é verdadeiro também parece curioso. O cpu_id dos 8 offline são 32 a 39.

sys.configurations parece concordar com a afinidade não sendo explicitamente

name                 value  value_in_use  description
affinity I/O mask    0      0             affinity I/O mask
affinity mask        0      0             affinity mask
affinity64 I/O mask  0      0             affinity64 I/O mask
affinity64 mask      0      0             affinity64 mask

Esta não é uma Enterprise Edition, então o CAL avô não deve ser um fator aqui, mas posso fazer essa pergunta amanhã, se necessário

ProductVersion  ProductLevel  ProductUpdateLevel  Edition
11.0.5058.0     SP2           NULL                Standard Edition (64-bit)

Executando as consultas de diagnóstico de Glenn Berry, isso pode ser relevante

• Fabricante do sistema: 'Dell Inc.', Modelo do sistema: 'PowerEdge R720'.
• CPU Intel(R) Xeon(R) E5-2680 v2 @ 2,80 GHz

Então, o que dá? Sou virtualizado e não sei? Existe algum outro lugar que eu deveria procurar para determinar por que o SQL Server não pode usar algumas das CPUs?

Artigos de referência

Uma lista de artigos que li, mas claramente não compreendi bem o suficiente para responder à minha própria pergunta

• BOL sys.dm_os_schedulers
• DMV de Glenn Berry por dia
• SQLServerGeeks DMV por dia

Como posso saber se minhas instâncias do SQL Server foram corrigidas? Existe uma funcionalidade nativa que identificará se há patches disponíveis para o meu servidor? Heck, eu ainda tenho dados de versão disponíveis para mim?

Estou trabalhando em um script para portar um ambiente de um servidor para outro. Estou enfrentando um problema de chamada catalog.create_environment_variableem que recebo o erro "O tipo de dados do valor de entrada não é compatível com o tipo de dados de 'String'." saindo do proc "check_data_type_value."

O que é estranho é que, se eu deixar o script da GUI sair das variáveis, essa consulta funcionará

DECLARE @var sql_variant = N'\\myserver\ssisdata'
EXEC [catalog].[create_environment_variable]
    @variable_name = N'FolderBase'
,   @sensitive = False
,   @description = N''
,   @environment_name = N'Development'
,   @folder_name = N'POC'
,   @value = @var
,   @data_type = N'String'
GO

No entanto, essa abordagem de script não está funcionando. O trabalho braçal que fiz indica que essa mensagem de erro geralmente é resolvida usando o tipo de dados nvarchar em vez de varchar. No entanto, esse não é o caso das minhas coisas.

Linha 108 para o seguinte script. Minha suposição é que é algo instável com o sql_variant , mas não tenho ideia do que seja.

USE SSISDB;
GO

DECLARE
    @folder_id bigint
,   @folder_name nvarchar(128) = N'POC'
,   @environment_name nvarchar(128) = N'Development'
,   @environment_description nvarchar(1024)
,   @reference_id bigint
,   @variable_name nvarchar(128)
,   @data_type nvarchar(128)
,   @sensitive bit
,   @value sql_variant
,   @description nvarchar(1024);

IF NOT EXISTS
(
    SELECT * FROM catalog.folders AS F WHERE F.name = @folder_name
)
BEGIN
    EXECUTE catalog.create_folder
        @folder_name = @folder_name
    ,   @folder_id = @folder_id OUTPUT;

    PRINT CONCAT('Folder "', @folder_name, '" has been created with a folder_id of ', @folder_id)
END

IF NOT EXISTS
(
    SELECT * FROM catalog.environments AS E WHERE E.name = @environment_name 
    AND E.folder_id = (SELECT F.folder_id FROM catalog.folders AS F WHERE F.name = @folder_name)
)
BEGIN
    PRINT CONCAT('Creating environment ',  @environment_name);

    EXECUTE catalog.create_environment
        @folder_name = @folder_name
    ,   @environment_name = @environment_name
    ,   @environment_description = @environment_description;
END

DECLARE
    @EnvironmentVariables TABLE
(
    folder_name nvarchar(128)
,   environment_name nvarchar(128)
,   variable_name nvarchar(128)
,   description nvarchar(1024)
,   data_type nvarchar(128)
,   sensitive bit
,   value sql_variant
);

INSERT INTO
    @EnvironmentVariables
SELECT
    E.folder_name
,   E.environment_name
,   S.name
,   S.description
,   S.type
,   S.sensitive
,   S.value
FROM
(
    SELECT 'FolderBase','Root for ssis processing','String',CAST(0 AS bit),'\\myserver\ssisdata'
    UNION ALL SELECT 'AuditConnectionString','Conn to audit db','String',CAST(0 AS bit),'Data Source=SQLETL01;Initial Catalog=Audit;Provider=SQLNCLI11.1;Integrated Security=SSPI;Auto Translate=False;'
) AS S (name, description, type, sensitive, value)
CROSS APPLY
(
    SELECT
        E.name AS environment_name
    ,   F.name AS folder_name
    FROM
        catalog.folders AS F
        INNER JOIN
            catalog.environments AS E
            ON E.folder_id = F.folder_id
    WHERE
        F.name = @folder_name
        AND E.name = @environment_name
) E;


DECLARE Csr CURSOR FORWARD_ONLY STATIC FOR
SELECT
    EV.variable_name
,   EV.description
,   EV.data_type
,   EV.sensitive
,   EV.value
FROM
    @Environmentvariables AS EV;

OPEN Csr;
FETCH NEXT FROM Csr INTO
    @variable_name
,   @description
,   @data_type
,   @sensitive
,   @value;

WHILE @@FETCH_STATUS = 0
BEGIN

    BEGIN TRY
            -- THERE BE MONSTERS AHEAD
        -- The data type of the input value is not compatible with the data type of the 'String'. 
        EXECUTE catalog.create_environment_variable
            @variable_name = @variable_name
        ,   @sensitive = @sensitive
        ,   @description = @description
        ,   @environment_name = @environment_name
        ,   @folder_name = @folder_name
        ,   @value = @value
        ,   @data_type = @data_type
    END TRY
    BEGIN CATCH
        SELECT 
            @folder_name        AS folder_name
        ,   @environment_name   AS environment_name
        ,   @variable_name      AS variable_name
        ,   @data_type          AS data_type
        ,   @sensitive          AS sensitive
        ,   @value              AS value
        ,   @description        AS description
        ,   ERROR_NUMBER()AS error_number --returns the number of the error.
        ,   ERROR_SEVERITY() AS error_severity --returns the severity.
        ,   ERROR_STATE()AS error_state  --returns the error state number.
        ,   ERROR_PROCEDURE() AS error_procedure --returns the name of the stored procedure or trigger where the error occurred.
        ,   ERROR_LINE() AS error_line --returns the line number inside the routine that caused the error.
        ,   ERROR_MESSAGE() AS error_message; --returns the complete text of the error message. The text includes the values supplied for any substitutable parameters, such as lengths, object names, or times.

    END CATCH  

    FETCH NEXT FROM Csr INTO
        @variable_name
    ,   @description
    ,   @data_type
    ,   @sensitive
    ,   @value;
END

CLOSE Csr;
DEALLOCATE Csr;

A versão 2012 do SQL Server Integration Services, SSIS, forneceu um catálogo SSISDB que rastreia as operações de pacotes (entre outras coisas). A execução do pacote padrão para soluções usando o modelo de implantação de projeto terá o registro no SSISDB ativado.

Quando um pacote é executado, o System::ExecutionInstanceGUIDé preenchido com um valor que, se alguém estivesse usando log explícito (para sys.sysdtslog90/ sys.sysssislog), registraria todos os eventos para uma execução de pacote específica.

O que eu gostaria de saber é como vincular um ExecutionInstanceGUID a qualquer coisa no catálogo SSISDB. Como alternativa, um pacote SSIS em execução no SSISDB é privado do valor de seucatalog.executions.execution_id

Por fim, estou tentando usar a tabela de auditoria personalizada existente e vinculá-la ao histórico detalhado no catálogo SSISDB, mas não consigo encontrar o link.

Definição de problema

Nossos usuários precisam da capacidade de consultar um banco de dados que esteja atualizado. Os dados podem ficar obsoletos por até 24 horas e isso é aceitável. Qual seria a abordagem de menor custo para obter e manter um segundo banco de dados atualizado com uma cópia de produção? Existe uma abordagem que eu não estou pensando?

carga de trabalho

Temos um aplicativo de terceiros que usamos para monitorar a atividade de negociação de ações. Durante o dia, muitas pequenas mudanças ocorrem como parte de vários fluxos de trabalho (sim, essa troca era válida. Não, isso é suspeito etc.). À noite, realizamos grandes operações baseadas em conjuntos (carregamos as negociações do dia anterior).

A solução e o problema atuais

Fazemos uso de instantâneos de banco de dados . Às 22h, descartamos e recriamos o instantâneo. O processamento ETL então começa. Obviamente, isso está sobrecarregando nosso disco, mas permite que nossos usuários consultem o banco de dados sem bloqueá-lo (eles usam um front-end do Access). Eles o usam até tarde da noite e no início da manhã, para que percebam o tempo de inatividade.

O problema com essa abordagem é duplo. A primeira é que, caso o processamento noturno falhe, e isso não é muito incomum, podemos restaurar o banco de dados, o que resulta na queda do instantâneo. O outro problema é que nossos tempos de processamento estão ultrapassando nosso SLA. Estamos tentando resolver isso trabalhando com o fornecedor depois de identificar consultas mal escritas e falta de indexação. O instantâneo do banco de dados também é um culpado nessa desaceleração, conforme evidenciado pela diferença de velocidade quando está presente versus não --- chocante, eu sei.

Abordagens consideradas

Agrupamento

Tínhamos o agrupamento de banco de dados ativado, mas isso não atendia às necessidades de disponibilizar os dados e apenas complicava a vida do administrador. Desde então, foi desligado.

Replicação do SQL Server

Começamos a olhar para a replicação na semana passada. Nossa teoria é que podemos obter um segundo catálogo levantado e sincronizado com o banco de dados de produção. Antes do início do ETL, cortaremos a conexão e a reabilitaremos apenas quando o processo ETL for concluído.

O administrador começou com a replicação de instantâneo , mas está preocupado com o fato de levar vários dias de alto uso da CPU para gerar o instantâneo, bem como o consumo de disco necessário. Ele indica que parece gravar todos os dados em arquivos físicos antes de enviá-los ao assinante, portanto, nosso banco de dados de 0,6 TB custará 1,8 TB em custos de armazenamento. Além disso, se demorar vários dias para gerar um snap, ele não caberá no SLA desejado.

Depois de ler o excelente artigo, parece que o Snapshot pode ser a maneira de inicializar os assinantes, mas gostaríamos de mudar para a replicação transacional para mantê-la sincronizada depois disso. Presumo que ativar/desativar a replicação transacional não forçará uma reinicialização completa? Caso contrário, vamos explodir nossa janela de tempo

Espelhamento de banco de dados

Nosso banco de dados está em modo de recuperação TOTAL, portanto, o espelhamento de banco de dados é uma opção, mas sei ainda menos sobre isso do que a replicação. Encontrei a resposta SO que indicava "O espelhamento de banco de dados impede que os dados sejam acessados ​​diretamente, os dados espelhados só são acessíveis por meio de um instantâneo do banco de dados".

Log de envio

Parece que o envio de logs também pode ser uma opção, mas essa é outra daquelas coisas sobre as quais não sei nada. Seria uma solução de menor custo (implementação e manutenção) do que qualquer outra? Com base no comentário de Remus "O envio de log permite acesso somente leitura à cópia da réplica, mas desconectará todos os usuários ao aplicar o próximo log de backup recebido (por exemplo, a cada 15 a 30 minutos)." Não tenho certeza de quanto tempo esse tempo de inatividade se traduziria, de modo que isso poderia causar alguma angústia aos usuários.

MS Sync

Só ouvi falar sobre o uso do Sync no fim de semana passado e ainda não o investiguei. Eu odiaria introduzir uma nova tecnologia para algo com grande visibilidade como este problema, mas se for a melhor abordagem, que assim seja.

SSIS

Fazemos bastante SSIS aqui, portanto, gerar algumas centenas de pacotes SSIS para manter o secundário sincronizado é uma opção para nós, embora feia . Não sou fã de fazer isso, pois é uma grande sobrecarga de manutenção que prefiro que minha equipe não assuma.

Instantâneo "mágico" da SAN

No passado, ouvi falar de nossos administradores usando alguma tecnologia SAN para fazer backups instantâneos de discos inteiros. Talvez haja alguma mágica da EMC que possa ser usada para fazer cópias ultrarrápidas do mdf/ldf e possamos então desanexar/anexar o banco de dados de destino.

Backup e restauração

Acho que fazemos backups completos uma vez por semana, diferenciais todas as noites e tlogs a cada 15 minutos. Se os usuários pudessem conviver com a interrupção de 3 a 4 horas para a restauração completa, suponho que essa seja uma abordagem.

Restrições

Windows 2008 R2, SQL Server 2008 R2 (Enterprise Edition), VMWare v5 Enterprise Edition, armazenamento EMC SAN com unidades mapeadas para arquivos vmdk, backups de gerenciamento de commvault e 0,6 TB de dados no catálogo de origem. Este é um aplicativo de terceiros que hospedamos internamente. Modificar sua estrutura geralmente é desaprovado. Os usuários não podem ficar sem consultar o banco de dados e se recusam a ser constrangidos pela identificação proativa das tabelas que monitoram para realizar seu trabalho.

Nossos DBAs são puramente contratados no momento. Os titulares zarparam e ainda não os substituímos. Os administradores do aplicativo não são versados ​​em assuntos do SQL Server e temos uma equipe de administradores de armazenamento/VM que podem ajudar/dificultar esse esforço. As equipes de desenvolvimento não estão envolvidas no momento, mas podem ser alistadas com base na abordagem. Portanto, seria preferível uma solução mais simples de implementar e manter.

Eu, estou no lado de desenvolvimento da casa, então só posso propor abordagens e não tive que lidar com o lado administrativo das coisas. Portanto, sem tempo na sela do administrador, hesito em dizer que uma abordagem seria superior a outra --- tudo parece ótimo de acordo com os documentos. Estou totalmente disposto a seguir qualquer direção que vocês sugerirem porque, a meu ver, isso só vai me tornar mais valioso como profissional de DB. Eu tenho um carrinho de mão, mas nenhuma capa do holocausto disponível .

Perguntas relacionadas

• https://stackoverflow.com/questions/525637/what-are-the-scenarios-for-using-mirroring-log-shipping-replication-and-cluste

• https://stackoverflow.com/questions/434982/mirroring-vs-replication

• https://stackoverflow.com/questions/4303020/sync-databases-mirroring-replication-log-shipping

• https://stackoverflow.com/questions/4303020/sync-databases-mirroring-replication-log-shipping

• http://nilebride.wordpress.com/2011/07/24/log-shipping-vs-mirroring-vs-replication/

Editar% s

Para responder às perguntas de @onpnt

Aceitação de latência de dados

Atualmente, os usuários visualizam dados com até 24 horas de atraso. Os dados são atuais apenas a partir de 2200

Quantidade de alteração de dados em um determinado minuto, hora e dia Não tenho certeza de como quantificar isso. Horário comercial, talvez centenas de mudanças por hora. Processamento noturno, milhões de linhas por dia útil

Conectividade com o secundário

Rede interna, host virtual separado e armazenamento dedicado

Leia os requisitos na instância secundária

O grupo do Windows terá acesso de leitura ao secundário, todas as tabelas

Tempo de atividade da instância secundária

Não há uma definição forte de um requisito de tempo de atividade. Os usuários querem que esteja sempre disponível, mas estão dispostos a pagar por isso, provavelmente não tanto. Realisticamente, eu diria que 23 horas por dia seriam suficientes.

Alterações no esquema existente e em todos os objetos

Modificações pouco frequentes, talvez uma vez por trimestre para objetos de tabela. Talvez uma vez por mês para objetos de código.

Segurança

Sem necessidades especiais de segurança. As permissões de produção corresponderiam às permissões da cópia. Embora, pensando bem, possamos revogar o acesso de leitura dos usuários ao prod e permitir que eles leiam apenas a cópia ... Embora não seja um requisito.

@darin strait

Reverter para o instantâneo pode ser uma opção, mas acho que houve algum motivo para eles não terem feito isso. vou verificar com o administrador

@cfradenburg

Minha suposição era que usaríamos apenas uma dessas abordagens, mas é um bom ponto que as restaurações quebrariam as "outras" tecnologias de sincronização. Eles estão investigando o que fazer usando a mágica do snapshot da EMC. Como o administrador descreveu, eles tirariam um instantâneo às 19h e migrariam a imagem para a zona secundária. Isso deve ser concluído em 2200 e, em seguida, eles realizarão uma desanexação e reanexação do banco de dados secundário.

Embrulhar

29/10/2012 Avaliamos a mágica do snapshot da EMC e algumas outras opções de replicação, mas os DBAs decidiram que poderiam descobrir melhor o espelhamento. Votei positivamente nas respostas porque todas elas ajudaram e me deram muitas opções, bem como "lição de casa" para investigar.

Problema

Existe um problema conhecido com tipos de tabela definidos pelo usuário como parâmetros para sp_executesql ?

Configurar script

Este script cria uma tabela, um procedimento e um tipo de tabela definido pelo usuário (restrito somente SQL Server 2008+).

• A finalidade do heap é fornecer uma auditoria de que sim, os dados foram inseridos no procedimento. Não há restrições, nem nada que impeça a inserção de dados.
• O procedimento toma como parâmetro um tipo de tabela definido pelo usuário. Tudo o que o proc faz é inserir na tabela.
• O tipo de tabela definido pelo usuário também é muito simples, apenas uma única coluna

Eu executei o seguinte contra 11.0.1750.32 (X64) e 10.0.4064.0 (X64)Sim, eu sei que a caixa pode ser corrigida, eu não controlo isso.

-- this table record that something happened
CREATE TABLE dbo.UDTT_holder
(
    ServerName varchar(200)
,   insert_time datetime default(current_timestamp)
)
GO

-- user defined table type transport mechanism
CREATE TYPE dbo.UDTT
AS TABLE
(
    ServerName varchar(200)
)
GO

-- Stored Procedure to reproduce issue
CREATE PROCEDURE dbo.Repro
(
    @MetricData dbo.UDTT READONLY
)
AS
BEGIN
    SET NOCOUNT ON

    INSERT INTO dbo.UDTT_holder 
    (ServerName)
    SELECT MD.* FROM @MetricData MD
END
GO

Reprodução de problemas

Este script demonstra o problema e deve levar cinco segundos para ser executado. Eu crio duas instâncias de meus tipos de tabela definidos pelo usuário e, em seguida, tento dois meios diferentes de passá-los para sp_executesql O mapeamento de parâmetro na primeira invocação imita o que capturei do SQL Profiler. Em seguida, chamo o procedimento sem o wrapper sp_executesql.

SET NOCOUNT ON
DECLARE 
    @p3 dbo.UDTT
,   @MetricData dbo.UDTT
INSERT INTO @p3 VALUES(N'SQLB\SQLB')
INSERT INTO @MetricData VALUES(N'SQLC\SQLC')

-- nothing up my sleeve
SELECT * FROM dbo.UDTT_holder

SELECT CONVERT(varchar(24), current_timestamp, 121) + ' Firing sp_executesql' AS commentary
-- This does nothing
EXECUTE sp_executesql N'dbo.Repro',N'@MetricData dbo.UDTT READONLY',@MetricData=@p3
-- makes no matter if we're mapping variables
EXECUTE sp_executesql N'dbo.Repro',N'@MetricData dbo.UDTT READONLY',@MetricData

-- Five second delay
waitfor delay '00:00:05'
SELECT CONVERT(varchar(24), current_timestamp, 121) + ' Firing proc' AS commentary
-- this does
EXECUTE dbo.Repro @p3

-- Should only see the latter timestamp
SELECT * FROM dbo.UDTT_holder

GO

Resultados

Abaixo estão meus resultados. A tabela está inicialmente vazia. Eu emito a hora atual e faço as duas chamadas para sp_executesql. Aguardo 5 segundos para passar e emito o tempo atual, seguido de chamada do próprio procedimento armazenado e, finalmente, despejo a tabela de auditoria.

Como você pode ver no carimbo de data/hora, o registro para o registro B corresponde à invocação direta do procedimento armazenado. Além disso, não há nenhum registro SQLC.

ServerName                                       insert_time
------------------------------------------------------------------------

commentary
-------------------------------------------------
2012-02-02 13:09:05.973 Firing sp_executesql

commentary
-------------------------------------------------
2012-02-02 13:09:10.983 Firing proc

ServerName                                       insert_time
------------------------------------------------------------------------
SQLB\SQLB                                        2012-02-02 13:09:10.983

Derrubar roteiro

Este script remove os objetos na ordem correta (você não pode descartar o tipo antes que a referência do procedimento tenha sido removida)

-- cleanup
DROP TABLE dbo.UDTT_holder
DROP PROCEDURE dbo.Repro
DROP TYPE dbo.UDTT
GO

Por que isso importa

O código parece bobo, mas não tenho muito controle sobre o uso do sp_execute versus uma chamada "direta" para o proc. Mais acima na cadeia de chamadas, estou usando a biblioteca ADO.NET e transmitindo um TVP como fiz anteriormente . O tipo do parâmetro está definido corretamente como System.Data.SqlDbType.Structured e o CommandType está definido como System.Data.CommandType.StoredProcedure .

Filtramos índices em nosso ambiente de produção. Enquanto fazia algumas pesquisas sobre eles, me deparei com este artigo " Índices filtrados e estatísticas filtradas podem ficar seriamente desatualizados "

É um índice filtrado bastante simples com base em um valor de código de 0

CREATE NONCLUSTERED INDEX 
    [IX_InsuranceOffer_FIX_OfferCode0] 
    ON [dbo].[InsuranceOffer]
(
    [OfferId] ASC
)
WHERE ([OfferStatus]=(0))
WITH (PAD_INDEX = OFF,   STATISTICS_NORECOMPUTE = OFF
, SORT_IN_TEMPDB = OFF,  DROP_EXISTING = OFF
, ONLINE = OFF,          ALLOW_ROW_LOCKS = ON
, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]

distribuição parece

code   codeCount   code_distribution
------ ----------- -----------------
6      26186769    93.7526
0      1743401     6.2416
5      1107        0.0040
7      495         0.0018

Nossa intenção era modificar o índice existente para incluir o código 5. Com base neste artigo de ponto de inflexão , acredito que ambas as consultas devem continuar a usar o índice filtrado.

Tenho perguntas aos proprietários do sistema tentando entender a volatilidade dos códigos.

Até então, examinei sys.dm_db_index_physical_stats na tentativa de entender se nossa estratégia atual de reconstrução/reorganização de índice é suficiente para acompanhar o índice filtrado. Eu suspeito que não, mas meu fu interno é fraco.

index_level avg_fragmentation_in_percent            fragment_count       avg_fragment_size_in_pages page_count           avg_page_space_used_in_percent          record_count
----------- --------------------------------------- -------------------- -------------------------- -------------------- --------------------------------------- --------------------
0           0.6276                                  20                   143.4                      2868                 90.0984                                 1743401
1           42.8571                                 7                    1                          7                    86.0285                                 2868
2           0.0000                                  1                    1                          1                    1.4455                                  7

sys.statspara este índice mostra que foi atualizado pela última vez '2012-01-06 22:03:11.147'

Os dados acima são informações suficientes para basear uma decisão de reconstrução de índice ou eu precisaria ter métricas adicionais envolvidas? Ou, para índices filtrados, nos preocupamos com a fragmentação e devemos apenas atualizar explicitamente as estatísticas no intervalo X?

Eu reivindico a resposta "depende"

A única pergunta semi-relacionada era a contagem mínima de linhas para o índice filtrado?

SSMS 2008 R2, conectando-se a uma instância de 2008 mostra o glifo acima no SSMS Object Explorer. Nenhuma de nossas outras instâncias mostra esse ícone. Eu passei o mouse sobre ele na vã esperança de obter uma dica de ferramenta útil, mas sem sucesso.

Presumo que esteja relacionado a uma falha que tivemos no fim de semana passado. Alguém poderia fornecer uma resposta mais confiável sobre o que esse ícone significa e qualquer ação que eu deva instruir meus DBAs a tomar para esclarecê-lo?

Estamos no processo de mover os dados de uma tabela herdada (todos os campos varchar) para uma sugestão de contraparte fortemente tipada cheering

Como parte desse esforço, estamos pegando dados da tabela Entity base e despejando-os em Entity_New se todos os dados puderem ser convertidos corretamente para o tipo apropriado. Caso contrário, ele vai para uma cópia da tabela existente chamada Entity_Bad.

Temos um mecanismo de regras que validou os dados e os tipos quando, em teoria, os dados devem estar limpos, mesmo que sejam armazenados em campos de caracteres. A realidade é que estou postando aqui porque alguma coisa está errada e não consigo encontrá-la. O campo CompletionDate em Entity é varchar(46) NULL

Ambiente é

productversion  productlevel   edition
10.0.4064.0     SP2            Enterprise Edition (64-bit)

Meus scripts demonstrando o que eu estava fazendo e o que está, mas não está funcionando

SET NOCOUNT ON

DECLARE
    @startid int = 0
,   @stopid int = 796833


-------------------------------------------------------------------------------
-- Check doesn't find anything wrong with CompletionDate
-------------------------------------------------------------------------------
SELECT
    1
FROM
    [dbo].[Entity] E
    INNER JOIN
        dbo.EntityBatch_New PB
        ON E.FiscalYear = PB.FiscalYear
            AND E.HashCode = PB.HashCode
            AND E.AAKey = PB.AAKey
            AND PB.ProcessResultCode IN ('A','W','M')
WHERE
    PB.EntityBatchId BETWEEN @StartId AND @StopId
    AND
    (
        -- check
        (isDate(E.[CompletionDate]) = 0 AND E.[CompletionDate] IS NOT NULL)
        AND (isDate(E.[CompletionDate]) = 1 AND CAST(E.[CompletionDate] AS datetime) BETWEEN '1753-01-01T00:00:00.000' AND '9999-12-31T23:59:59.997')
    )

-------------------------------------------------------------------------------
-- Only row that shows as non-date is the NULL one, which is expected
-------------------------------------------------------------------------------
SELECT DISTINCT
    (E.[CompletionDate] )
,  isDate(E.[CompletionDate])
FROM
    [dbo].[Entity] E
    INNER JOIN
        dbo.EntityBatch_New PB
        ON E.FiscalYear = PB.FiscalYear
            AND E.HashCode = PB.HashCode
            AND PB.ProcessResultCode IN ('A','W','M')
    -- Ensure we aren't pulling something we have already processed
    LEFT OUTER JOIN
        [dbo].[Entity_new] N
        ON N.HashCode = E.HashCode
            AND N.FiscalYear = E.FiscalYear
                AND E.AAKey = N.AAKey
    -- Ensure we aren't pulling something we have already processed (or was bad)
    LEFT OUTER JOIN
        [dbo].[Entity_bad] BAD
        ON BAD.HashCode = E.HashCode
            AND BAD.FiscalYear = E.FiscalYear
                AND E.AAKey = BAD.AAKey
WHERE
    PB.EntityBatchId BETWEEN @StartId AND @StopId
    AND N.FiscalYear IS NULL
    AND BAD.FiscalYear IS NULL
ORDER BY 2

-------------------------------------------------------------------------------
-- Make the cast and it blows with
-- The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.
-------------------------------------------------------------------------------
SELECT DISTINCT
    (E.[CompletionDate] )
,   CAST(E.[CompletionDate] AS datetime) AS [CompletionDate]
FROM
    [dbo].[Entity] E
    INNER JOIN
        dbo.EntityBatch_New PB
        ON E.FiscalYear = PB.FiscalYear
            AND E.HashCode = PB.HashCode
            AND PB.ProcessResultCode IN ('A','W','M')
    -- Ensure we aren't pulling something we have already processed
    LEFT OUTER JOIN
        [dbo].[Entity_new] N
        ON N.HashCode = E.HashCode
            AND N.FiscalYear = E.FiscalYear
                AND E.AAKey = N.AAKey
    -- Ensure we aren't pulling something we have already processed (or was bad)
    LEFT OUTER JOIN
        [dbo].[Entity_bad] BAD
        ON BAD.HashCode = E.HashCode
            AND BAD.FiscalYear = E.FiscalYear
                AND E.AAKey = BAD.AAKey
WHERE
    PB.EntityBatchId BETWEEN @StartId AND @StopId
    AND N.FiscalYear IS NULL
    AND BAD.FiscalYear IS NULL


-------------------------------------------------------------------------------
-- Dump the values into a temporary table to slice and dice the values
-------------------------------------------------------------------------------
DECLARE @debug TABLE
(
    CompletionDate varchar(46) NULL
)
INSERT INTO
    @debug
SELECT DISTINCT
    (E.[CompletionDate] )
FROM
    [dbo].[Entity] E
    INNER JOIN
        dbo.EntityBatch_New PB
        ON E.FiscalYear = PB.FiscalYear
            AND E.HashCode = PB.HashCode
            AND PB.ProcessResultCode IN ('A','W','M')
    -- Ensure we aren't pulling something we have already processed
    LEFT OUTER JOIN
        [dbo].[Entity_new] N
        ON N.HashCode = E.HashCode
            AND N.FiscalYear = E.FiscalYear
                AND E.AAKey = N.AAKey
    -- Ensure we aren't pulling something we have already processed (or was bad)
    LEFT OUTER JOIN
        [dbo].[Entity_bad] BAD
        ON BAD.HashCode = E.HashCode
            AND BAD.FiscalYear = E.FiscalYear
                AND E.AAKey = BAD.AAKey
WHERE
    PB.EntityBatchId BETWEEN @StartId AND @StopId
    AND N.FiscalYear IS NULL
    AND BAD.FiscalYear IS NULL


-------------------------------------------------------------------------------
-- This is operating on all the same values as the failing query but magically works
-------------------------------------------------------------------------------
SELECT ALL
    CAST(E.[CompletionDate] AS datetime) AS [CompletionDate]
FROM
    @debug E



-------------------------------------------------------------------------------
-- Clearly, something is amiss when we extract the data so process each row
-- and find the culprit that way. Except this finds nothing wrong
-------------------------------------------------------------------------------
DECLARE @hash uniqueidentifier
,   @zee_date varchar(46)
,   @real_date datetime

DECLARE
    CSR CURSOR READ_ONLY
FOR
SELECT
    E.HashCode
,   E.[CompletionDate]
FROM
    [dbo].[Entity] E
    INNER JOIN
        dbo.EntityBatch_New PB
        ON E.FiscalYear = PB.FiscalYear
            AND E.HashCode = PB.HashCode
            AND PB.ProcessResultCode IN ('A','W','M')
    -- Ensure we aren't pulling something we have already processed
    LEFT OUTER JOIN
        [dbo].[Entity_new] N
        ON N.HashCode = E.HashCode
            AND N.FiscalYear = E.FiscalYear
                AND E.AAKey = N.AAKey
    -- Ensure we aren't pulling something we have already processed (or was bad)
    LEFT OUTER JOIN
        [dbo].[Entity_bad] BAD
        ON BAD.HashCode = E.HashCode
            AND BAD.FiscalYear = E.FiscalYear
                AND E.AAKey = BAD.AAKey
WHERE
    PB.EntityBatchId BETWEEN @StartId AND @StopId
    AND N.FiscalYear IS NULL
    AND BAD.FiscalYear IS NULL


OPEN CSR

FETCH NEXT FROM CSR INTO
    @hash, @zee_date

WHILE (@@fetch_status = 0)
BEGIN
    BEGIN TRY
        SELECT @real_date = cast(@zee_date AS datetime)
    END TRY
    BEGIN CATCH
        print 'In here'
        print @hash
        print @zee_date
        SELECT @hash, @zee_date
    END CATCH


    FETCH NEXT FROM CSR INTO
        @hash, @zee_date

END

CLOSE csr
DEALLOCATE csr

Depois de criticar você com a parede de código acima, aqui estão os 406 valores exclusivos nos quais as consultas acima estão operando.

DECLARE @REAL_DATES TABLE
(
    CompletionDate varchar(46) NULL
)

INSERT INTO
    @REAL_DATES 
SELECT
    NULL
UNION ALL SELECT '19000101'
UNION ALL SELECT '20100208'
UNION ALL SELECT '20100228'
UNION ALL SELECT '20100309'
UNION ALL SELECT '20100314'
UNION ALL SELECT '20100401'
UNION ALL SELECT '20100409'
UNION ALL SELECT '20100420'
UNION ALL SELECT '20100427'
UNION ALL SELECT '20100429'
UNION ALL SELECT '20100507'
UNION ALL SELECT '20100615'
UNION ALL SELECT '20100617'
UNION ALL SELECT '20100629'
UNION ALL SELECT '20100701'
UNION ALL SELECT '20100703'
UNION ALL SELECT '20100704'
UNION ALL SELECT '20100706'
UNION ALL SELECT '20100709'
UNION ALL SELECT '20100713'
UNION ALL SELECT '20100714'
UNION ALL SELECT '20100715'
UNION ALL SELECT '20100716'
UNION ALL SELECT '20100720'
UNION ALL SELECT '20100721'
UNION ALL SELECT '20100726'
UNION ALL SELECT '20100727'
UNION ALL SELECT '20100728'
UNION ALL SELECT '20100729'
UNION ALL SELECT '20100731'
UNION ALL SELECT '20100801'
UNION ALL SELECT '20100802'
UNION ALL SELECT '20100803'
UNION ALL SELECT '20100804'
UNION ALL SELECT '20100807'
UNION ALL SELECT '20100809'
UNION ALL SELECT '20100810'
UNION ALL SELECT '20100811'
UNION ALL SELECT '20100813'
UNION ALL SELECT '20100817'
UNION ALL SELECT '20100819'
UNION ALL SELECT '20100820'
UNION ALL SELECT '20100822'
UNION ALL SELECT '20100823'
UNION ALL SELECT '20100825'
UNION ALL SELECT '20100827'
UNION ALL SELECT '20100828'
UNION ALL SELECT '20100830'
UNION ALL SELECT '20100831'
UNION ALL SELECT '20100901'
UNION ALL SELECT '20100902'
UNION ALL SELECT '20100904'
UNION ALL SELECT '20100907'
UNION ALL SELECT '20100908'
UNION ALL SELECT '20100909'
UNION ALL SELECT '20100910'
UNION ALL SELECT '20100911'
UNION ALL SELECT '20100913'
UNION ALL SELECT '20100916'
UNION ALL SELECT '20100919'
UNION ALL SELECT '20100920'
UNION ALL SELECT '20100922'
UNION ALL SELECT '20100923'
UNION ALL SELECT '20100925'
UNION ALL SELECT '20100928'
UNION ALL SELECT '20101002'
UNION ALL SELECT '20101004'
UNION ALL SELECT '20101007'
UNION ALL SELECT '20101009'
UNION ALL SELECT '20101010'
UNION ALL SELECT '20101013'
UNION ALL SELECT '20101016'
UNION ALL SELECT '20101018'
UNION ALL SELECT '20101019'
UNION ALL SELECT '20101020'
UNION ALL SELECT '20101022'
UNION ALL SELECT '20101023'
UNION ALL SELECT '20101025'
UNION ALL SELECT '20101028'
UNION ALL SELECT '20101030'
UNION ALL SELECT '20101102'
UNION ALL SELECT '20101107'
UNION ALL SELECT '20101108'
UNION ALL SELECT '20101109'
UNION ALL SELECT '20101111'
UNION ALL SELECT '20101112'
UNION ALL SELECT '20101114'
UNION ALL SELECT '20101117'
UNION ALL SELECT '20101119'
UNION ALL SELECT '20101124'
UNION ALL SELECT '20101126'
UNION ALL SELECT '20101127'
UNION ALL SELECT '20101129'
UNION ALL SELECT '20101201'
UNION ALL SELECT '20101203'
UNION ALL SELECT '20101204'
UNION ALL SELECT '20101206'
UNION ALL SELECT '20101209'
UNION ALL SELECT '20101210'
UNION ALL SELECT '20101213'
UNION ALL SELECT '20101214'
UNION ALL SELECT '20101215'
UNION ALL SELECT '20101216'
UNION ALL SELECT '20101220'
UNION ALL SELECT '20101222'
UNION ALL SELECT '20101227'
UNION ALL SELECT '20101228'
UNION ALL SELECT '20101229'
UNION ALL SELECT '20101230'
UNION ALL SELECT '20110102'
UNION ALL SELECT '20110103'
UNION ALL SELECT '20110104'
UNION ALL SELECT '20110106'
UNION ALL SELECT '20110107'
UNION ALL SELECT '20110108'
UNION ALL SELECT '20110109'
UNION ALL SELECT '20110110'
UNION ALL SELECT '20110111'
UNION ALL SELECT '20110114'
UNION ALL SELECT '20110116'
UNION ALL SELECT '20110118'
UNION ALL SELECT '20110119'
UNION ALL SELECT '20110120'
UNION ALL SELECT '20110122'
UNION ALL SELECT '20110123'
UNION ALL SELECT '20110125'
UNION ALL SELECT '20110126'
UNION ALL SELECT '20110128'
UNION ALL SELECT '20110130'
UNION ALL SELECT '20110203'
UNION ALL SELECT '20110205'
UNION ALL SELECT '20110206'
UNION ALL SELECT '20110208'
UNION ALL SELECT '20110210'
UNION ALL SELECT '20110212'
UNION ALL SELECT '20110213'
UNION ALL SELECT '20110215'
UNION ALL SELECT '20110218'
UNION ALL SELECT '20110221'
UNION ALL SELECT '20110224'
UNION ALL SELECT '20110226'
UNION ALL SELECT '20110301'
UNION ALL SELECT '20110302'
UNION ALL SELECT '20110304'
UNION ALL SELECT '20110307'
UNION ALL SELECT '20110309'
UNION ALL SELECT '20110311'
UNION ALL SELECT '20110314'
UNION ALL SELECT '20110316'
UNION ALL SELECT '20110317'
UNION ALL SELECT '20110320'
UNION ALL SELECT '20110321'
UNION ALL SELECT '20110323'
UNION ALL SELECT '20110326'
UNION ALL SELECT '20110328'
UNION ALL SELECT '20110329'
UNION ALL SELECT '20110331'
UNION ALL SELECT '20110403'
UNION ALL SELECT '20110405'
UNION ALL SELECT '20110406'
UNION ALL SELECT '20110408'
UNION ALL SELECT '20110410'
UNION ALL SELECT '20110415'
UNION ALL SELECT '20110416'
UNION ALL SELECT '20110417'
UNION ALL SELECT '20110418'
UNION ALL SELECT '20110421'
UNION ALL SELECT '20110422'
UNION ALL SELECT '20110423'
UNION ALL SELECT '20110426'
UNION ALL SELECT '20110429'
UNION ALL SELECT '20110501'
UNION ALL SELECT '20110503'
UNION ALL SELECT '20110504'
UNION ALL SELECT '20110506'
UNION ALL SELECT '20110508'
UNION ALL SELECT '20110509'
UNION ALL SELECT '20110511'
UNION ALL SELECT '20110512'
UNION ALL SELECT '20110514'
UNION ALL SELECT '20110517'
UNION ALL SELECT '20110518'
UNION ALL SELECT '20110519'
UNION ALL SELECT '20110520'
UNION ALL SELECT '20110522'
UNION ALL SELECT '20110526'
UNION ALL SELECT '20110531'
UNION ALL SELECT '20110603'
UNION ALL SELECT '20110604'
UNION ALL SELECT '20110605'
UNION ALL SELECT '20110606'
UNION ALL SELECT '20110608'
UNION ALL SELECT '20110611'
UNION ALL SELECT '20110613'
UNION ALL SELECT '20110614'
UNION ALL SELECT '20110616'
UNION ALL SELECT '20110622'
UNION ALL SELECT '20110624'
UNION ALL SELECT '20110627'
UNION ALL SELECT '20110703'
UNION ALL SELECT '20110704'
UNION ALL SELECT '20110711'
UNION ALL SELECT '20110712'
UNION ALL SELECT '20110713'
UNION ALL SELECT '20110714'
UNION ALL SELECT '20110719'
UNION ALL SELECT '20110720'
UNION ALL SELECT '20110725'
UNION ALL SELECT '20110726'
UNION ALL SELECT '20110802'
UNION ALL SELECT '20110804'
UNION ALL SELECT '20110811'
UNION ALL SELECT '20090611'
UNION ALL SELECT '20091124'
UNION ALL SELECT '20100201'
UNION ALL SELECT '20100202'
UNION ALL SELECT '20100204'
UNION ALL SELECT '20100220'
UNION ALL SELECT '20100305'
UNION ALL SELECT '20100323'
UNION ALL SELECT '20100414'
UNION ALL SELECT '20100417'
UNION ALL SELECT '20100508'
UNION ALL SELECT '20100512'
UNION ALL SELECT '20100527'
UNION ALL SELECT '20100616'
UNION ALL SELECT '20100702'
UNION ALL SELECT '20100705'
UNION ALL SELECT '20100707'
UNION ALL SELECT '20100708'
UNION ALL SELECT '20100710'
UNION ALL SELECT '20100711'
UNION ALL SELECT '20100712'
UNION ALL SELECT '20100717'
UNION ALL SELECT '20100719'
UNION ALL SELECT '20100722'
UNION ALL SELECT '20100723'
UNION ALL SELECT '20100724'
UNION ALL SELECT '20100725'
UNION ALL SELECT '20100730'
UNION ALL SELECT '20100805'
UNION ALL SELECT '20100806'
UNION ALL SELECT '20100808'
UNION ALL SELECT '20100812'
UNION ALL SELECT '20100814'
UNION ALL SELECT '20100815'
UNION ALL SELECT '20100816'
UNION ALL SELECT '20100818'
UNION ALL SELECT '20100821'
UNION ALL SELECT '20100824'
UNION ALL SELECT '20100826'
UNION ALL SELECT '20100829'
UNION ALL SELECT '20100903'
UNION ALL SELECT '20100906'
UNION ALL SELECT '20100912'
UNION ALL SELECT '20100914'
UNION ALL SELECT '20100915'
UNION ALL SELECT '20100917'
UNION ALL SELECT '20100918'
UNION ALL SELECT '20100921'
UNION ALL SELECT '20100924'
UNION ALL SELECT '20100926'
UNION ALL SELECT '20100927'
UNION ALL SELECT '20100929'
UNION ALL SELECT '20100930'
UNION ALL SELECT '20101001'
UNION ALL SELECT '20101003'
UNION ALL SELECT '20101005'
UNION ALL SELECT '20101006'
UNION ALL SELECT '20101008'
UNION ALL SELECT '20101011'
UNION ALL SELECT '20101012'
UNION ALL SELECT '20101014'
UNION ALL SELECT '20101015'
UNION ALL SELECT '20101017'
UNION ALL SELECT '20101021'
UNION ALL SELECT '20101024'
UNION ALL SELECT '20101026'
UNION ALL SELECT '20101027'
UNION ALL SELECT '20101029'
UNION ALL SELECT '20101031'
UNION ALL SELECT '20101101'
UNION ALL SELECT '20101103'
UNION ALL SELECT '20101104'
UNION ALL SELECT '20101105'
UNION ALL SELECT '20101106'
UNION ALL SELECT '20101110'
UNION ALL SELECT '20101113'
UNION ALL SELECT '20101115'
UNION ALL SELECT '20101116'
UNION ALL SELECT '20101118'
UNION ALL SELECT '20101120'
UNION ALL SELECT '20101122'
UNION ALL SELECT '20101123'
UNION ALL SELECT '20101125'
UNION ALL SELECT '20101128'
UNION ALL SELECT '20101130'
UNION ALL SELECT '20101202'
UNION ALL SELECT '20101205'
UNION ALL SELECT '20101207'
UNION ALL SELECT '20101208'
UNION ALL SELECT '20101212'
UNION ALL SELECT '20101217'
UNION ALL SELECT '20101218'
UNION ALL SELECT '20101219'
UNION ALL SELECT '20101221'
UNION ALL SELECT '20101223'
UNION ALL SELECT '20101224'
UNION ALL SELECT '20101226'
UNION ALL SELECT '20101231'
UNION ALL SELECT '20110101'
UNION ALL SELECT '20110105'
UNION ALL SELECT '20110112'
UNION ALL SELECT '20110113'
UNION ALL SELECT '20110115'
UNION ALL SELECT '20110117'
UNION ALL SELECT '20110121'
UNION ALL SELECT '20110124'
UNION ALL SELECT '20110127'
UNION ALL SELECT '20110129'
UNION ALL SELECT '20110131'
UNION ALL SELECT '20110201'
UNION ALL SELECT '20110202'
UNION ALL SELECT '20110204'
UNION ALL SELECT '20110207'
UNION ALL SELECT '20110209'
UNION ALL SELECT '20110211'
UNION ALL SELECT '20110214'
UNION ALL SELECT '20110216'
UNION ALL SELECT '20110217'
UNION ALL SELECT '20110219'
UNION ALL SELECT '20110220'
UNION ALL SELECT '20110222'
UNION ALL SELECT '20110223'
UNION ALL SELECT '20110225'
UNION ALL SELECT '20110228'
UNION ALL SELECT '20110303'
UNION ALL SELECT '20110305'
UNION ALL SELECT '20110306'
UNION ALL SELECT '20110308'
UNION ALL SELECT '20110310'
UNION ALL SELECT '20110312'
UNION ALL SELECT '20110313'
UNION ALL SELECT '20110315'
UNION ALL SELECT '20110318'
UNION ALL SELECT '20110322'
UNION ALL SELECT '20110324'
UNION ALL SELECT '20110325'
UNION ALL SELECT '20110327'
UNION ALL SELECT '20110330'
UNION ALL SELECT '20110401'
UNION ALL SELECT '20110404'
UNION ALL SELECT '20110407'
UNION ALL SELECT '20110409'
UNION ALL SELECT '20110411'
UNION ALL SELECT '20110412'
UNION ALL SELECT '20110413'
UNION ALL SELECT '20110414'
UNION ALL SELECT '20110419'
UNION ALL SELECT '20110420'
UNION ALL SELECT '20110425'
UNION ALL SELECT '20110427'
UNION ALL SELECT '20110428'
UNION ALL SELECT '20110430'
UNION ALL SELECT '20110502'
UNION ALL SELECT '20110505'
UNION ALL SELECT '20110507'
UNION ALL SELECT '20110510'
UNION ALL SELECT '20110513'
UNION ALL SELECT '20110515'
UNION ALL SELECT '20110516'
UNION ALL SELECT '20110521'
UNION ALL SELECT '20110523'
UNION ALL SELECT '20110524'
UNION ALL SELECT '20110525'
UNION ALL SELECT '20110527'
UNION ALL SELECT '20110528'
UNION ALL SELECT '20110530'
UNION ALL SELECT '20110601'
UNION ALL SELECT '20110602'
UNION ALL SELECT '20110607'
UNION ALL SELECT '20110609'
UNION ALL SELECT '20110610'
UNION ALL SELECT '20110615'
UNION ALL SELECT '20110617'
UNION ALL SELECT '20110618'
UNION ALL SELECT '20110620'
UNION ALL SELECT '20110621'
UNION ALL SELECT '20110623'
UNION ALL SELECT '20110626'
UNION ALL SELECT '20110628'
UNION ALL SELECT '20110629'
UNION ALL SELECT '20110630'
UNION ALL SELECT '20110701'
UNION ALL SELECT '20110706'
UNION ALL SELECT '20110707'
UNION ALL SELECT '20110708'
UNION ALL SELECT '20110715'
UNION ALL SELECT '20110717'
UNION ALL SELECT '20110721'
UNION ALL SELECT '20110722'
UNION ALL SELECT '20110727'
UNION ALL SELECT '20110729'
UNION ALL SELECT '20110801'
UNION ALL SELECT '20110810'

SELECT 
    CAST(RD.CompletionDate AS datetime) AS casts_fine
FROm
    @REAL_DATES RD

Eu aprecio os comentários sobre SSIS ou outras abordagens, mas estamos casados ​​com a abordagem de conversão TSQL neste ponto do jogo. Se alguém puder apontar o que estou perdendo, darei seu nome ao meu primeiro filho, supondo que você não se importe em mudar seu nome para James.