Chris J's questions

Estou pesquisando sobre criptografia de banco de dados e, embora o TDE pareça fazer exatamente o que diz na lata, parece não haver informações sobre como configurá-lo em um Cluster SQL de failover da Microsoft ou se há alguma advertência sobre criptografia em um ambiente de cluster (além daqueles listados no MSDN ).

Tentando destilar as informações que tenho (principalmente daqui e daqui, mas de outros googles aleatórios), acho que a resposta é que não preciso fazer nada e simplesmente funciona. A chave mestra e o certificado estão no banco de dados mestre e o DMK está no banco de dados do usuário, portanto, em uma situação de failover, tudo existe nos arquivos MDF para o nó de failover executar (em vez de quaisquer chaves ocultas no registro que precisariam para ser sincronizado entre nós).

O problema é que não há nada que afirme isso explicitamente (ou falhei completamente em ler a sentença que o diz), então estou apenas buscando esclarecimentos de que não estou perdendo algo óbvio, que nada de especial precisa ser configurado e "simplesmente funciona".

Existe uma prática recomendada para saber se uma chave estrangeira entre tabelas deve ser vinculada a uma chave natural ou a uma chave substituta? A única discussão que realmente encontrei (a menos que meu google-fu esteja faltando) é a resposta de Jack Douglas a esta pergunta , e seu raciocínio parece sólido para mim. Estou ciente da discussão além de que as regras mudam, mas isso seria algo que precisaria ser considerado em qualquer situação.

O principal motivo para perguntar é que tenho um aplicativo legado que faz uso de FKs com chaves naturais, mas há um forte impulso dos desenvolvedores para mudar para um OR/M (NHibernate em nosso caso), e um fork já produziu alguns quebrando as alterações, então estou procurando colocá-los de volta nos trilhos usando a chave natural ou mover o aplicativo herdado para usar chaves substitutas para o FK. Meu instinto diz para restaurar o FK original, mas sinceramente não tenho certeza se esse é realmente o caminho certo a seguir.

A maioria de nossas tabelas já possui uma chave substituta e uma chave natural já definidas (por meio de restrição exclusiva e PK), portanto, adicionar colunas extras não é um problema para nós neste caso. Estamos usando o SQL Server 2008, mas espero que seja genérico o suficiente para qualquer banco de dados.

Alguém é capaz de explicar algum comportamento que estou vendo com o SQL Profiler? Tomando os dois lotes a seguir:

exec sp_executesql N'
    declare @t table (
        x int
    )

    insert into @t (x) select top 10 number from dbo.gennumbers

    select * from @t
    union
    select * from @t
'

exec sp_executesql N'
    select top 10 number from dbo.gennumbers
    union
    select top 10 number from dbo.gennumbers
'

(isso é uma simplificação de algumas refatorações que estou fazendo; na realidade, a tabela temporária é preenchida por meio de um CTE que é reutilizado na consulta final, mitigando assim a quantidade de trabalho duplicado que o SQL Server precisa fazer ao armazenar os dados em cache).

Neste exemplo, GenNumbers é simplesmente uma tabela de números com uma única coluna que contém apenas uma sequência sequencial de números - nada de especial.

No profiler, estou obtendo os seguintes resultados:

Lote 1, com a tabela temporária:

Leituras de dados de texto do evento
SP:StmtCompleted INSERT INTO(...) 27
SP:StmtCompleted SELECT * FROM ... 6
SQL:StmtCompleted exec sp_executesql 170

Lote 2, um golpe direto:

Leituras de dados de texto do evento
SP:StmtCompleted SELECT TOP 10 * ... 6
SQL: StmtCompleted exec sp_executesql 6

O que estou tentando entender é a anomalia da contagem final de leitura no arquivo SQL:StmtCompleted. Eu esperava que o total de leituras fosse igual à soma de todas as leituras que ocorrem no lote, mas não parece ser o caso no lote 1 - na verdade, é significativamente maior. Enquanto o lote 2, que faz uma única seleção, leituras finais == leituras reais.

Não há nada óbvio no plano de execução para ver para onde está indo esse tempo extra, mas talvez eu não esteja capturando a coisa certa - alguém tem alguma opinião sobre o que realmente está acontecendo? Estou me perguntando se preciso me preocupar com as 100 leituras extras que o SQL Server está "me dando", visto que essa contagem de leitura é cinco ou seis vezes maior do que a contagem real de leitura.

Presumo que seja algo relacionado ao SQL que precisa manter informações sobre a tabela temporária, mas não está claro exatamente o quê. Qualquer luz derramada seria útil.

O SQL Server tem alguma maneira simples de buscar métricas sobre quantos (e possivelmente qual tipo) de bloqueios uma determinada consulta obteve durante sua execução?

Justificativa...
Estou no processo de reescrever um procedimento armazenado bastante desagradável que faz uso intenso de cursores. Uma solução baseada em conjunto é possível e, como resultado, tenho três versões dela: a original, uma versão baseada em conjunto com vars de tabela e uma versão baseada em conjunto puramente baseada em CTE. Estou obtendo boas métricas para a solução baseada em CTE, mas devido ao tamanho e à complexidade da consulta criada pela versão CTE, tenho receio de lançá-la até que eu tenha feito o máximo de diligência possível sobre ela.

Agora percebo que os bloqueios que o SQL remove são aqueles que ele acha que precisa remover em um determinado momento e, em um servidor de produção carregado, pode se comportar de maneira diferente, mas espero que isso me dê uma sensação de como vai se comportar.

Atualmente, estou usando o profiler e mantendo as transações abertas para que eu possa executar sp_lock, mas queria saber se estou perdendo um truque no SQL Server 2008.

Como alternativa, estou tentando me convencer de que o criador de perfil que retorna um grande número de leituras ao inserir em uma variável de tabela está bem (para um determinado valor de ok), mas não me convenci. A solução CTE tem metade das leituras da versão table-var, e a alta contagem de leituras da versão table-var parece ser puramente devido às inserções. Em termos de duração, tanto o CTE quanto o table var um são aproximadamente os mesmos, dando tempos de execução aproximadamente 150-200% mais rápidos do que a abordagem baseada em cursor.