Início / dba / Perguntas / 57253
Accepted
IT researcher
Asked: 2014-01-22 21:57:31 +0800 CST

Crescimento automático, redução e desempenho do banco de dados

  • 772

Eu já fiz algumas perguntas sobre Autogrowth e Shrink. Mas tenho algumas dúvidas relacionadas a isso.

  1. Eu tenho um banco de dados que cresce cerca de 300 MB todos os meses. Então, é melhor definir Autogrowth de 300 MB para ele? Agora 10 MB está definido.

  2. Eu tenho tantos bancos de dados pequenos que realmente têm dados de cerca de 50 MB. Mas seu tamanho físico é de cerca de 900 MB. (Portanto, 850 é espaço livre). Eu não reduzi este banco de dados. Como se eu o reduzisse novamente quando os dados são adicionados, o crescimento automático ocorre. Mas adicionar dados a esse banco de dados é raro. Portanto, acho que não crescerá mais de 200 MB no próximo ano.

    Então devo encolher o banco de dados? Se eu mantiver como está? Isso deve causar algum problema de desempenho? Ou ter mais espaço livre (mais de 90%) no banco de dados causará algum problema? Acho que a maioria das pessoas acha que ter um tamanho físico grande causará problemas de desempenho. Então é verdade ou não?

  3. O limite de tamanho do banco de dados do SQL Server 2008 R2 Express é de 10 GB. Então, é o tamanho físico dos arquivos mdf e ldf juntos? Porque preciso considerar isso se devo reduzir o banco de dados a qualquer momento.

sql-server sql-server-2008-r2

2 respostas

  1. Best Answer

    1. Sim, escolher um tamanho de crescimento automático que garanta a minimização ou eliminação do número de eventos de crescimento durante o ciclo de negócios é o ideal. Atrevo-me a dizer que se 300 MB por mês é tão previsível, você também deve - além de definir configurações de crescimento automático mais razoáveis ​​- aumentar o arquivo agora em 4 ou 8 GB para permitir um ou dois anos de crescimento sem ter se preocupar com eventos de crescimento interrompidos (mesmo com a inicialização instantânea do arquivo, o crescimento do arquivo de dados ainda faz com que as transações esperem enquanto são concluídas). Se você sabe que vai crescer cerca de 300 MB por mês, por que adiar todos esses eventos de crescimento? O que você vai fazer com o espaço enquanto isso? Alugar mês a mês?

    2. Você provavelmente está bem reduzindo esse banco de dados específico para 200 MB. Certifique-se de fazer isso com DBCC SHRINKFILEou ALTER DATABASE MODIFY FILEnão DBCC SHRINKDATABASE.

    3. A limitação do Express está apenas no arquivo de dados. Você pode ter um arquivo de dados de 9,99 GB e um arquivo de log de 600 GB, e o SQL Server não reclamará. Bem, isso acontecerá de outras maneiras, mas não por exceder qualquer limitação arbitrária de tamanho de arquivo. Dito isso, você deve certificar-se de estar em recuperação simples ou fazer backup de seu log a uma taxa razoável. Os arquivos de log nunca devem crescer descontroladamente - e se você está preocupado com o arquivo de log em uma instância Express, algo não está certo. Por favor, veja os seguintes posts para muita discussão:

    • 6

  2. O encolhimento automático ou o encolhimento manual não traz benefícios todas as vezes, pode ser contraproducente, consulte o link abaixo:

    http://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/

    É bom estimar o tamanho do banco de dados de antemão, como você fez. No entanto, seria melhor se você calculasse uma duração mais longa, em vez de um crescimento repetido a cada mês.

    Ter espaço livre não causa nenhum problema de desempenho no banco de dados (embora eu não tenha nenhuma citação para isso), mas diminuir tem um efeito negativo. Em vez de examinar o tamanho do banco de dados, seria bom examinar a fragmentação, se ela existir.

    • 0

relate perguntas