É uma prática comum separar os dados dos arquivos log no SQL Server. Isso ainda é válido como prática recomendada ao trabalhar com bancos de dados SharePoint .
Por exemplo, usando o exemplo acima, eu poderia ter minha unidade de log com os seguintes arquivos:
E, na minha unidade de dados, temos o seguinte:
Alternativamente, seria mais prático colocar cada banco de dados (dados e log) em sua própria unidade da seguinte forma:
A outra coisa que quero entender é como esse conselho é afetado quando o banco de dados WSS_Content_MainSite fica maior e decidimos adicionar outro banco de dados ao aplicativo da web. Esse novo banco de dados deve ficar no mesmo lugar que os outros arquivos de banco de dados ou isoladamente?
Sim, pelas mesmas razões. Esta postagem discute algumas das questões relacionadas ao layout e ao armazenamento em disco design para bancos de dados do SQL Server. Um back-end de banco de dados para o SharePoint tem exatamente os mesmos tipos de problemas.
Colocá-los em unidades separadas só funciona se eles forem físicos em volumes diferentes que não tenham certeza dos mesmos fusos.
Exemplo: SE seu servidor SharePoint é um Dell 2950 com 6 das unidades SAS 2.5 em uma invasão 10. E você cria as seguintes partições de unidade. Isso não faz sentido, pois compartilham os mesmos discos.
G: 100 GB H: 100 GB I: 100 GB J: 100 GB
A menos que você tenha uma SAN ou vários dispositivos RAID anexados diretamente para trabalhar com você, não verá o benefício de dividir os arquivos em várias unidades.
Se você tiver a capacidade de colocá-los em unidades separadas, apenas coloque todos os arquivos .mdf e .ldf como em seu primeiro exemplo. Dessa forma, com todos os arquivos .mdf ou dados em uma unidade, eles têm uma atividade IO de disco e colocam todos os arquivos .ldf ou log em outra unidade.
Veja alguns desses artigos no TechNet sobre Armazenamento e banco de dados com o SharePoint. link
Além disso, pense em como organizar seu TempDB. Isso é muito importante com o SharePoint.
Tags sql sharepoint