Quais são os riscos de alterar o modelo de recuperação do SharePoint_Config DB para simples?

Question

O arquivo de log do banco de dados do SharePoint_Config cresce na medida em que ele se reserva muito espaço em disco para aparentemente nenhum bom motivo. No meu ambiente de desenvolvimento eu mudei seu modelo de recuperação para simples para permitir a liberação do espaço em disco, e evitar o risco do arquivo de log para crescer no mesmo ritmo novamente.

O próximo passo foi encolher o arquivo de log com o atributo arquivo vazio, migrando os dados para outros arquivos no mesmo grupo de arquivos .

Quando isso foi feito, um terço do disco (33 GB) foi liberado, e meu ambiente de desenvolvimento parece ok. Meu palpite é que isso é perfeitamente ok em um ambiente de desenvolvimento, onde uma recuperação e registro de banco de dados não é tão crítica.

No entanto, isso poderia ser feito em um ambiente de produção também? Eu entendo que todos os meus logs se foram, mas quais são os riscos de prosseguir da maneira que eu faço na produção? Quais são os riscos de alterar o modelo de recuperação do SharePoint_Config DB para simples?

Answer 1

Há duas maneiras para olhar para essa preocupação.

primeiro é literalmente pegar o que a Microsoft diz no valor de face, porque eles estão na maior parte do tempo correto sobre as melhores práticas operacionais para seus próprios produtos.

Disse então, se você seguir a diretriz aqui mencionada aqui http://technet.microsoft.com/en-us/library/cc678868. (v= escritório.14) .aspx

diz

.

notas adicionais Arquivos de log de transações. Recomendamos que você faça backup do log de transações para o banco de dados de configuração regularmente para forçar a truncamento ou - se você não estiver espelhando seu sistema - altere o banco de dados para ser executado no modo de recuperação simples. Para mais informações, consulte Truncation Log de Transação ( http://go.microsoft.com/fwlink/f/?Linkid= 186687 ).

Então, simplesmente o modo de recuperação é o caminho a percorrer se o espelhamento estiver desativado.

segunda maneira é examinar como suas estratégias de backup e recuperação são definidas. Qual é a sua abordagem de restauração?

Backup completo de fazenda completo e restauração de fazenda dirigida por administrador central ou restauração do SQL durante o banco de dados anexado pelo mesmo servidor aliases e hardware. A simples recuperação seria o modo preferível para o primeiro caso e para o segundo caso, seu preferível manter o DB de configuração do SharePoint em um modo de recuperação completo apenas para garantir uma réplica "como é" do estado anterior do ponto que a fazenda falhou. < / p >.

ms descreve isso como mencionado abaixo do

.

O banco de dados de configuração é feito de backup quando você executa um SharePoint Configuração da fazenda e backup de conteúdo e algumas configurações A partir do banco de dados são exportados e armazenados como arquivos XML. Quando uma fazenda é Restaurado, o banco de dados de configuração não é restaurado. Em vez disso, o. As configurações salvas são importadas. O banco de dados de configuração pode ser backup e restaurado com sucesso usando o SQL Server ou Outras ferramentas se o farm do SharePoint for iniciado offline pela primeira vez.

Literalmente, os IFS e os bastões de sua preocupação são altamente subjetivos com base em sua escolha de planos de backup e recuperação, uma vez que o SharePoint suporta alguns deles. Portanto, você pode optar por ir para um modelo de recuperação simples para o banco de dados de configuração e encolher os logs na produção somente se satisfizer as condições mencionadas acima para que as precauções sejam tiradas de acordo.

Answer 2

Por padrão, o banco de dados SharePoint_Config é definido como modelo de recuperação completo. Mas a recomendação da Microsoft é definir o modelo de recuperação para o seu banco de dados SharePoint_config para simples em produção (referência: http://technet.microsoft.com/en-us/library/cc678868.aspx ). Você pode alterar o modelo de recuperação para SharePoint_config depois de criar o SharePoint_Config DB.

Nunca encolher seus bancos de dados serem desenvolvimento, produção ou onde quer que. Porque quando você encolhe seu DBS, aumenta a fragmentação que reduz o desempenho. Não vale a pena o valor do armazenamento que você libera (referência: http://www.microsoftvirtualacademy.com/tuning-courses/tuning-sql-server-2012-for-sherepoint-2013-Jump-start#fbbbb7 Em um desses vídeos eles mencionaram isso, não me lembro qual) e http://blog.sqlauthority.com/2011/01/19/19/19/sql-server-shring-database-is-bad-creshes-frages- desempenho / ).