.png)
Fala galera, tudo bem? Nesse post vou abordar um tema que é bem interessante, você que esta começando na área de banco de dados SQL Server deve saber sobre o tema que é: Estrutura de um banco de dados SQL Server!
Quando você instala uma instância do SQL, automaticamente são criados 4 bancos de dados que são:
MASTER: banco que centraliza informações de configuração da instância
MODEL: banco modelo usado na criação de novos bancos de dados
MSDB: armazena informações do SQL Agent (jobs, históricos, databasemail...)
TEMPDB: banco temporário responsável por ser um apoio aos bancos de usuários (algumas operações como uma criação de uma tabela temporária são feitas nela, ordenações, dentre outras funções), esse banco é compartilhado entre todos os bancos de usuário da instância e é imprescindível para a performance do ambiente.
Dentro de uma instância que contém esses 4 bancos citados anteriormente você pode criar bancos de dados de "usuário", que são os bancos das aplicações e você pode ter vários dentro de uma mesma instância.
Independente se o banco é de sistema( os 4 que falei antes ) ou de usuário (que é da aplicação) a estrutura por detrás é a mesma. Um banco tem 2 tipos de arquivos, o primeiro é o de dados que de fato é onde os dados ficam alocados e o segundo é o de log de transações, responsável por guardar as operações (transações) executadas no banco.
O arquivo de dados é identificado pela extensão padrão MDF (considerado o arquivo primário) todo banco tem um arquivo mdf, já o log de transações tem sua extensão LDF. Em algumas ocasiões definidas por estratégia de arquitetura do banco você pode ter arquivos secundários de dados que são identificados pela extensão NDF (você pode não ter nenhum ndf ou ter vários, vai depender da estratégia da aplicação).
Quando pode existir arquivos NDF?
O ponto principal é performance e custo, um dos principais fatores de custo alto hoje em dia é disco, armazenamento. Vou te mostrar dois cenários onde os arquivos NDF podem ser úteis.
1) Uma tabela do banco da aplicação é muito grande, porém os dados que são acessados dela de forma frequente são apenas do mês atual, dali para trás os dados nunca são acessados (mas não podem ser excluídos), nesse cenário pode ser configurado um particionamento dessa tabela (nativo do SQL ou manual mesmo) onde os dados "históricos" ficam armazenados em um NDF que é armazenado em outro disco diferente de onde esta o banco oficial (e esse disco não precisa ter o mesmo desempenho que o banco oficial pois são dados que quase nunca são acessados) com isso você pode guardar esses dados em um disco mais barato e maior pois a quantidade de dados é maior.
2) A aplicação precisa realizar os JOINS entre tabelas grandes (JOINS são técnicas de desenvolvimento para ligar tabelas e retornar os dados para o sistema), quando você tem todas as tabelas e dados em um mesmo arquivo ele esta armazenado em um disco físico que tem uma capacidade de IOPs (que é a capacidade de leitura e escrita que o disco pode te oferecer de desempenho, por exemplo, um disco pode te entregar até 300 IOPs, isso significa que ele consegue realizar até 300 operações de leitura e/ou escrita por segundo). Nesse cenário, se você divide tabelas grandes em arquivos de dados diferentes e os coloca em discos diferentes onde cada disco tem o seu desempenho individual você pode, por exemplo, dobrar a capacidade de IOPs naquela operação, então se você esta juntando dados de duas tabelas diferentes que estão em discos diferentes elas poderão ser lidas em paralelo "fisicamente", onde cada disco individualmente vai gastar os "seus IOPs" para ler e até mesmo escrever.
Agora que você já entendeu sobre a estrutura vamos juntos montar a arquitetura de um ambiente simples, mas que é muito comum nas empresas. Em nosso exemplo de estudo temos um banco de dados apenas de usuário para uma aplicação.
Como estruturar os discos para garantir o mínimo necessário de performance?
Unidade C deve sempre ficar para o sistema operacional
A ideia é dividir os arquivos e componentes em discos diferentes que podem oferecer IOPs individuais (*ambientes locais, onde a própria empresa tem seu servidor isso é um pouco mais incomum, pois para montar essa estrutura fica bem mais caro, porém no ambiente de nuvem onde você contrata uma maquina virtual no Azure ou AWS, por exemplo, o desempenho já é individualizado por unidade que você criar, inclusive você pode contratar IOPs extras se precisar, claro que isso vai ser cobrado, mas da pra fazer).
Unidade B armazenará a instalação do SQL Server, a instância, e as bases de sistema Master, Model e Msdb.
Unidade T ficaria com o TEMPDB, como é um banco estratégico para performance, é extremamente importante que ele esteja em um disco separado para garantir que nenhum outro processo concorra com ele no disco.
Unidade D fica com o arquivo de dados do banco da aplicação (caso existissem arquivos NDF poderiam ficar junto ou ainda em outros discos separados)
Unidade L armazenará o log de transações do banco da aplicação (ele recebe muita escrita pois são os registros das transações, portanto é importante estar separado também)
A estrutura fica assim:
Essa é uma arquitetura simples mas muito eficaz, existem muitos ambientes pequenos e de médio porte que podem ser ajustados nesse formato e que terão um bom ganho de performance (lembrando que os discos/unidades precisam ter IOPs individuais, pois do contrario a questão da performance perde o sentido, você teria apenas a organização do ambiente).
Bacana não é? Diz aí, você já tinha pensado sobre essa estrutura?
Gostou do post? Compartilha com seus colegas que querem ser um DBA SQL Server!
Nos acompanhe em nossas redes sociais!
Grupo VIP Telegram: DBA On boarding
Youtube(vídeos novos todas as quartas): DBA On boarding
Face & Instagram(conteúdo diário): DBA On boarding
Até a próxima, tchau!
Comments