No momento, tenho meu servidor de produção com vários bancos de dados grandes e uso um segundo servidor SQL para fins de geração de relatórios. Eu mantenho as cópias de relatórios dos bancos de dados usando replicação transacional.
Como atualizamos recentemente para EE, desejo habilitar a compactação de dados em várias tabelas grandes no servidor de relatórios para economizar espaço em disco (atualmente não estou pronto para habilitá-la no servidor de produção)
Alguém já tentou isso e, em caso afirmativo, existem armadilhas ocultas?
As únicas armadilhas que posso ver são se a tabela for capturada novamente, a tabela replicada perderá sua compactação. Como todos os índices de relatórios adicionais também seriam perdidos, não é algo que eu faria levianamente.
Não há armadilhas reais de fazer isso. Você só precisa estar ciente de que haverá um ligeiro aumento na CPU do assinante, portanto, se você já estiver vinculado à CPU, pode não ser o melhor caminho a seguir.
Você pode considerar o uso de um script pré ou pós instantâneo para ajudar a garantir que a compactação do índice seja mantida no caso de você precisar executar outro instantâneo (e adicionar quaisquer índices adicionais necessários).
Ao executar a compactação, esteja ciente de que você provavelmente experimentará o crescimento do log de transações, da mesma forma que faria se reconstruísse qualquer outro índice. Classificar em tempdb geralmente é uma boa prática para algo assim.
Você já pensou em criar índices columnstore não clusterizados em sua assinatura.
Os índices Columnstore lhe darão o benefício de taxas de compactação massivas.
Acabei de testar isso com o SQL Server 2016 Developer Edition e ele me permitiu criar índices columnstore não clusterizados em minha assinatura.
Eu tentei algo assim antes e encontrei economias substanciais no espaço em disco.
No entanto, descobri que as consultas em que os dados precisam ser lidos do disco são mais rápidas em comparação com as tabelas não compactadas e as consultas em que os dados já estão armazenados em buffer na RAM tornaram-se mais lentas em comparação com as tabelas não compactadas.
Deixei minha investigação lá, mas dependendo da abundância relativa de RAM ou armazenamento, sugiro compactar apenas dados usados com pouca frequência, por partição ou tabela. (Mas talvez você não possa particionar tabelas facilmente, pois o particionamento também não é feito no editor.)
Tive casos em que a tabela perdeu misteriosamente sua compactação, talvez devido a algum script de reconstrução que não respeitava as configurações de compactação.