Antes de criptografar um banco de dados, faça um backup da chave mestra e do certificado e armazene offline. Não espere até aplicar a TDE para fazer isso. Também armazene as senhas em um cofre de senhas e deixe claro quais senhas estão relacionadas a qual objeto; você realmente não quer perder o controle deles.
O impacto que a TDE tem no banco de dados depende inteiramente da carga de trabalho envolvida: apliquei recentemente a TDE em um data warehouse e o impacto no desempenho na carga noturna não foi nada, o que sugere que o processo não estava vinculado à CPU. No entanto, isso pode não ser verdade para o seu banco de dados. Portanto, se você pode testar a carga de trabalho em um ambiente de desenvolvimento primeiro, faça-o.
Não são apenas os dados nos arquivos criptografados: o TDE também criptografa o tempDB; portanto, se você tiver outros bancos de dados que usam muito o TempDB, poderá observar um impacto no desempenho. Os backups e instantâneos também são criptografados.
Considere também se esse banco de dados precisa ser restaurado para outros ambientes (por exemplo, teste ou UAT). Você precisará restaurar o certificado usado para criptografar o banco de dados nesses outros servidores. Isso pode não parecer muito de um problema, mas se você não tiver uma empresa ou desenvolvedor em nenhum desses ambientes, isso poderá se tornar caro. Uma alternativa para aplicar a TDE em todo o ambiente é restaurar o banco de dados em uma instância intermediária que é empresa / desenvolvedor e embaralhar os dados confidenciais ou descartar a criptografia e criar um novo backup para ser restaurado em outros ambientes. Esta segunda opção provavelmente não é a mais sensata, mas é sempre uma opção ...
Ao ativar o TDE, existem dois bloqueios aplicados ao banco de dados: um bloqueio compartilhado e um bloqueio de atualização. O TechNet declara isso totalmente:
Quando a TDE está ativada (ou desativada), o banco de dados é marcado como criptografado na exibição do catálogo sys.databases e o estado DEK é definido como Criptografia em Andamento. O servidor inicia um encadeamento em segundo plano (chamado verificação ou verificação de criptografia) que verifica todos os arquivos do banco de dados e os criptografa (ou descriptografa-os se você estiver desativando o TDE). Enquanto o DDL é executado, um bloqueio de atualização é executado no banco de dados. A verificação de criptografia, que é executada de forma assíncrona no DDL, leva um bloqueio compartilhado. Todas as operações normais que não entram em conflito com esses bloqueios podem continuar. As operações excluídas incluem modificar a estrutura do arquivo e desanexar o banco de dados. Enquanto as gravações normais do banco de dados no disco do buffer pool são criptografadas, as gravações do arquivo de log podem não ser. A verificação também força uma sobreposição para o arquivo de log virtual (VLF) para garantir que futuras gravações no log sejam criptografadas.
Minha experiência foi em data warehouses que eram pouco usados durante o dia e muito usados durante a noite, então pude aplicar a TDE com o mínimo de interrupção durante o dia. Se você estiver criptografando um OLTP em produção, é melhor agendá-lo durante uma janela de manutenção para minimizar problemas.
Editar: Também no ponto de compactação; embora seja verdade que a TDE afeta a compactação de backup, ela não afeta a compactação de linha / página / columnstore. Portanto, se você quiser equilibrar a perda de compactação dos backups, poderá compactar objetos no banco de dados. Novamente, dependendo da sua carga de trabalho, você pode / não pode implementar a compactação no banco de dados, porque isso sobrecarregará ainda mais a CPU. Há um excelente artigo do TechNet sobre implementação de compactação: https://technet.microsoft.com/en-us/library/dd894051%28v=sql.100%29.aspx