Eu tenho um banco de dados de produção e um banco de dados de desenvolvimento em dois servidores diferentes. Ambos os bancos de dados estão sendo alimentados a partir do mesmo data warehouse em um servidor de teste. Há uma série de trabalhos SQL automatizados que executam e preenchem tabelas em um banco de dados. Os trabalhos foram copiados do Dev para o Prod, então eles também devem ser os mesmos. No entanto, Prod está crescendo muito mais rápido que Dev.
Há aproximadamente 1 bilhão de linhas de dados no banco de dados. O total de arquivos de dados no Prod é cerca de 123 GB maior. O total de arquivos de índice é cerca de 31 GB maior. Eu sou novo nisso, mas eu esperaria que os dois bancos de dados fossem bastante semelhantes em tamanho. De qualquer forma, eu esperava que o Dev tivesse algum 'lixo' extra e potencialmente fosse o banco de dados maior.
Alguma idéia de como encontrar a fonte dessa diferença de tamanho? Posso aumentar o espaço em disco no Prod, se necessário, mas me indica que pode haver um problema que precisa ser resolvido. Eu gostaria de recuperar os 153 GB, se possível.
Eu sou reconhecidamente um novato quando se trata disso, mas eu verifiquei a pasta Index em cada ambiente e ambos parecem ter um Index. Eu verifiquei as propriedades e elas parecem as mesmas também. Mais Índice também causaria um aumento no tamanho dos arquivos de dados?
Estou executando o script IndexOptimize de Ola Hallengren em Prod e Dev e esperando que esteja lidando adequadamente com qualquer fragmentação significativa. Na verdade, não migrei nenhum dado de Dev para Prod. Temos um servidor de teste que hospeda os dados. Um conjunto de SSIS e procedimentos armazenados move os dados de teste para bancos de dados no Dev. Mais tarefas e procedimentos de armazenamento do SSIS preencheram as tabelas no Dev. O SSIS e os procedimentos armazenados são promovidos de Dev para Prod e são executados no Prod de forma independente. Os trabalhos de produção acessam o mesmo servidor de teste que o Dev.
A compactação pode fazer com que você veja diferentes tamanhos de tabela e índice para os mesmos dados em duas tabelas.
Você perguntou em um comentário se há algum motivo para não aplicar a compactação. A desvantagem geral da compactação de página é que suas tabelas ocupam menos espaço e você pode colocar mais dados na memória com um custo de sobrecarga da CPU. Como regra geral, se o seu servidor tiver CPU de sobra, você também pode testar sua carga de trabalho antes e depois de aplicar a compactação para ver o que acontece. Existem até algumas cargas de trabalho que ficarão mais eficientes do ponto de vista da CPU após a aplicação da compactação. Resumindo, "depende".
Outra razão para não usar compactação é se você não estiver licenciado para isso. Seu servidor de desenvolvimento pode estar usando a edição do desenvolvedor que permite compactação de dados, mas seu servidor de produção pode estar usando a edição padrão, que não permite compactação de dados até o SQL Server 2016 SP1.