SQL Server: grupo de arquivos apenas para tabelas do sistema?

11

Um de nossos padrões corporativos é ter um grupo de arquivos / arquivo separado para tabelas / índices de usuários. Isso é definido como o padrão, portanto, não é necessário qualificar as instruções CREATE TABLE.

Então parece que isso

fileid 1 = tabelas de sistema, MDF
fileid 2 = t-log = LDF
fileid 3 = material do usuário = NDF

Alguém aqui pode me ajudar a entender a justificativa original por que isso era obrigatório?

Vou ficar limpo e dizer que acho que é vodu. Am I errado ...?

Editar: Estou ciente de como usar grupos de arquivos para separar índices / partições / arquivos, bem como restaurar aos poucos. Esta pergunta é sobre o uso de um grupo de arquivos separado no mesmo volume apenas para tabelas do sistema.

sql-server filegroups disk-structures

— gbn
fonte

9

O livro de treinamento 70-432 da Microsoft diz "O principal motivo para não colocar nenhum objeto no grupo de arquivos primário é fornecer o máximo de isolamento possível na E / S. Os dados nos objetos do sistema não são alterados com tanta frequência quanto os dados Ao minimizar a atividade de gravação no arquivo de dados primário, você reduz a possibilidade de introduzir corrupção devido a falhas de hardware.Além disso, como o estado do grupo de arquivos primário também determina o estado do banco de dados, você pode aumentar a disponibilidade do banco de dados, minimizando as alterações feitas no grupo de arquivos primário ".

Então, tome isso como quiser. Outros dizem que isso não é necessário em determinadas circunstâncias e, claro, é mais para manter. Apenas pensei em fornecer o raciocínio da Microsoft.

— Jared
fonte

Razoável, alguma justificativa escrita para isso. Eu aceito isso

— gbn

11

Outro motivo é que uma restauração PARCIAL do banco de dados permite a restauração do grupo de arquivos PRIMARY mais outros grupos de arquivos selecionados, permitindo uma recuperação mais rápida de um VLDB projetado corretamente. Permitindo que os grupos de arquivos arquivados / secundários sejam restaurados posteriormente.

— MartinC 02/02/12

@ MartinC: Eu sei sobre restaurações parciais, etc, mas nunca entendi a lógica de separar explicitamente as tabelas do sistema. Grupos de arquivos para desempenho, arquivamento, manutenção, particionamento etc. Mas tabelas do sistema? Jared ofereceu a melhor explicação até agora ..

— gbn 2/02/12

Se o banco de dados como um todo for muito grande, o grupo de arquivos primário poderá ter um backup mais regular que os dados principais. A restauração exigiria apenas um backup do log de cauda e restauração do grupo de arquivos primário e logs de transações desde o backup do grupo de arquivos mais a cauda. Como as tabelas do sistema são pequenas, seria um processo de recuperação mais rápido do que o de todo o banco de dados, para reduzir o tempo de inatividade no caso de um problema.

— MartinC 02/02/12

12

Não é um ganho de desempenho para isso, há um ganho recuperável a ser feito. Se a corrupção do arquivo ocorrer nas tabelas do sistema, o banco de dados será perdido. Se você mantiver os dados do usuário em um grupo (ou grupos) de arquivos separado, poderá restaurar apenas os arquivos mantendo o restante do banco de dados online durante a restauração (assumindo a Enterprise Edition aqui).

Se é por isso que eles afirmam isso, não posso dizer, mas isso seria um benefício de ter vários grupos de arquivos apenas com os objetos do sistema no grupo de arquivos PRIMARY.

No entanto, você deve chutar no lixo por dizer que o AutoShrink deve estar ativado.

— Mrdenny
fonte

Para saber mais sobre isso, você pode procurar a Restauração fragmentada online nos Manuais Online.

— Brent Ozar

11

Eu sempre pensei que isso também é vodu, pois os 2 grupos de arquivos estão no mesmo volume (em uma SAN). O risco de corrupção é tão alto? (Os DBAs operacionais reais configuram o AutoShrink como falso)

— gbn 21/02

As probabilidades são de que, se houver corrupção, haverá uma única página em um único arquivo, pois o armazenamento será danificado ao gravar a página no disco. Algo como 99,9999% da corrupção do banco de dados é um problema de armazenamento. Metade dos outros problemas tem memória ruim e os demais são erros de SQL. À medida que os bancos de dados aumentam (multi-TB), isso se torna mais importante, pois a restauração de um banco de dados multi-TB leva vários dias.

— mrdenny

Eu não estaria certo ao pensar que, se os objetos do sistema estiverem apenas no grupo de arquivos primário, caso você precise no futuro, poderá fazer o seguinte. Crie x arquivos adicionais em outro grupo de arquivos. Preencher proporcionalmente esses arquivos migrando seus dados do seu arquivo de dados existente?

— Ally Reilly

4

Não sei ao certo, você está pedindo alguém para justificar seu padrão corporativo? Eu pensaria que quem escreveu esse documento de padrões para sua empresa poderia lançar alguma luz sobre o motivo de isso ser feito.

Dito isto, não é incomum que algumas lojas desejem separar os dados do sistema dos dados do usuário. E, se usado em conjunto com conjuntos de discos dedicados, você poderá obter alguns ganhos de desempenho.

— SQLRockstar
fonte

Obrigado. Não justifique, mas explique. Essa é a mesma equipe da DB Engineering que disse que o AutoShrink está ativado. Dadas as tabelas do sistema ocupam alguns MBs e estarão na memória de qualquer maneira, você acredita em algum ganho de desempenho?

— gbn 20/02