Temos o tempdb em sua própria matriz de unidade dividida em vários arquivos para desempenho. Temos arquivos de logs do banco de dados em unidades que não são de dados. Nós questionamos se devemos colocar o arquivo de log tempDB na unidade de log para todos os DBs ou outros lugares, mas separados dos arquivos de dados do temdb.
Eu nunca me preocupei com isso. Dando uma olhada no site da MS, ele diz que o registro para tempdb é minimizado. Pode não ser um problema para você. E, claro, não é uma boa ideia otimizar prematuramente - por exemplo, antes de testar seu ambiente atual com carga realista. Não existe uma única prática recomendada para configurações SQL para todas as condições.
Estamos falando de um log de transação binário ou apenas um arquivo de log de aplicativo de texto simples? A prática recomendada geral para cargas de trabalho de banco de dados é manter seus logs de transação em disco físico diferente do seu armazenamento de dados; isso mantém gravações sequenciais sequenciais no log de transações e melhora a taxa de acertos do cache em ambos os volumes, minimizando a perda de cache.
A visão tradicional é que os arquivos de dados dos bancos de dados do usuário devem estar em uma unidade, os arquivos de log dos usuários em outra unidade (essa é a unidade que realmente precisa ter latências rápidas) e TempDB em uma unidade separada. Além de isolá-los uns dos outros, logs e arquivos de dados têm características IO muito diferentes.
As coisas mudaram com a aparência das SANs, já que os administradores de SAN geralmente davam aos DBAs partes de grandes blocos de diferenças de desempenho de disco que não eram tão aparentes.
A virtualização mudou ainda mais, já que o DBA pode ter pensado que ele separou seus arquivos de dados de seus logs de seu TempDB, mas o administrador da VM colocou todos esses "drives" diferentes na mesma unidade física - em um mundo de VM essas unidades são apenas arquivos.
A minha opinião é que ainda é bom manter arquivos de dados, arquivos de log e arquivos do TempDB separados - se um deles inchar, você espera que consiga um pouco mais de tempo para consertá-lo - e não derrubará tudo.
Se você puder fazer isso, a melhor prática ainda é manter seus arquivos de dados e arquivos de log separados - e se você puder manter o TempDB separado também, então ótimo. Alguns aplicativos, especialmente usando o Read Committed Snapshot Isolation, usam intensamente o TempDB.
Sim, seria melhor colocar os arquivos de log e dados do TempDB em unidades separadas. como de costume, estamos colocando arquivos de dados para todos os arquivos de log e de banco de dados de todos os bancos de dados em unidades separadas, à medida que as transações são gravadas em ambos os arquivos ao mesmo tempo. então o mesmo conceito aplicável aos arquivos TempDB também.
Tags sql-server-2008 tempdb