Estou planejando uma reconstrução de índice, no entanto, meus logs são propensos a tamanhos enormes e exagerados.
Na verdade, eu estava inclinado a fazer uma reindexação inteligente, mas como os níveis de fragmentação são maiores que 30%, achei que deveria fazer uma reconstrução.
Meus bancos de dados usam o modelo de recuperação completa. Devo alterar o modelo de recuperação para registro em massa antes de fazer a reconstrução no final de semana, quando houver menos transações acontecendo.
O envio de logs é habilitado como uma solução de DR nesses bancos de dados.
O que você sugere se minha latência for muito alta? Existe uma solução de DR melhor que eu deveria procurar?
Acho que essa é a mesma pergunta que você acabou de postar. há alguns novos pontos que você aborda:
O modo registrado em massa não torna os logs enviados pela rede menores. Isso apenas torna a gravação no arquivo de log local menos intensiva de E/S. Uma vez que o log deve ser copiado, todas as páginas alteradas devem ser incluídas no backup. O resultado final é que seu backup de log trans será tão grande quanto.
Se você já tiver alta latência, mudar para espelhamento não mudará isso. a única maneira de distribuir a carga é: pare de reconstruir e mude para uma estratégia de reorganização de dispersão (como mencionei em sua outra pergunta).
Ou, como alguém mencionou, comece a fazer backups de log mais frequentes e envie backups de log menores com uma frequência maior.
Apenas com base no que você está nos dizendo agora. (a alta latência) Eu pessoalmente não aconselharia mudar para espelhamento. Mas a escolha entre espelhamento e envio de log deve ser baseada em muito mais itens do que apenas na latência.
Você está compactando seus backups de log? Eu recomendo que você faça isso. É uma opção disponível na Standard Edition para 2008 R2 e EE em 2008 R1. Concordo que você deve considerar mais do que apenas a latência ao decidir sobre a solução de DR.