Quase Tudo na vida tem um limite, seja ele tangível ou não.

É de muita importância o conhecimento dos limites de tudo que se lida na vida, tanto pessoal quanto profissional, para que se possa mensurar e planejar melhor como lidar com coisas, pessoas e ferramentas.

Com o SQL Server não é diferente, existem limites, que apesar de serem bastante generosos (ao ponto de que se por acaso você os atingir, algo pode não estar bem planejado), é interessante e importante conhecê-los para um correto sizing e melhor utilização dos recursos disponíveis.

A motivação deste post, foi devido a um compartilhamento no Facebook, do meu amigo Thiago Carlos Alencar (Blog | Twitter), justamente falando sobre os limites do SQL Server.

Falando especificamente da limitação da quantidade de Bancos de dados por instância, existe uma mensagem de erro, que acredito ter sido vista por pouquíssimos profissionais que trabalham direta ou indiretamente com o SQL Server.

Msg 1835, Level 16, State 1, line 29

Unable to create/attach any new database because the number of existing databases has reached the maximum number allowed: 32766

O numero máximo de bancos de dados visíveis por instância no SQL Server é de 32766.

Nas versões anteriores do SQL Server, a view de sistema sysdatabases, a coluna que indica o id de um banco de dados é o dbid, que é do tipo smallint (32767). 

Nas versões mais recentes (2005+) esta view foi substituída pela view sys.databases e a coluna que indica o id do banco de dados é a database_id que é uma coluna do tipo int (2.147.483.647). 

A explicação mais lógica seria que o número 32766 é um número consideravelmente alto, e por questões de compatibilidade.

Os bancos de dados e seus respectivos database_id ficam distribuídos da seguinte forma:

• 1 – master
• 2 – tempdb
• 3 – model
• 4 – msdb
• [5 .. 32766] – user databases
•  32767 –  mssqlsystemresource (oculto)

Só acredito vendo…

Se o propósito fosse simplesmente ver a mensagem de erro, um simples select na view sys.messages resolveria, porém qual seria o efeito colateral, prós e contras em se criar tantos bancos de dados em uma única instância? Quanto de recurso adicional seria necessário? Hora de testar…

 

Criação dos bancos de dados:

 Clique aqui – para download do script

O script exemplificado na imagem acima, executa a criação de 32763 bancos de dados de usuários na instância SQL Server em que for executado (obviamente, não faça isto em seu ambiente de produção). No caso do meu teste, ainda ficou faltando uma base a ser criada, o que será demonstrado no próximo exemplo.

A linha de código: ALTER DATABASE  ‘+@NOMEBANCO+‘ SET OFFLINE WITH ROLLBACK IMMEDIATE’ está propositalmente inserida após a criação de cada banco de dados.

Quando uma base é iniciada (ou criada), mesmo que a mesma não possua nenhum objeto ou dado, o SQL Server carrega algumas páginas da mesma para o data cache, o processo de inicialização da base, também conhecido como Recovery, carrega páginas de controle e da base, para que a mesma possa ser utilizada quando e se necessário.

O motivo de cada uma das bases de dados criadas neste teste terem sido alteradas para offline foi para que estas páginas de controle, não fossem carregadas e consequentemente não houvesse problemas de falta de memória durante a criação das mesmas.

Números:

• 115 – Média de páginas carregadas (neste teste) por banco (mesmo vazio)
• 115 (páginas) * 8 (tamanho em KB por página) = 920 KBytes (Média de espaço, por banco de dados)
• 920 KB * 32762 (Qtde máxima de bancos de usuários) = 30.141.040 KB
• ~29 GB

Olhando pelos números supracitados, podemos concluir que apenas para criar todos estes bancos de dados vazios, ou mesmo iniciar uma instância com este número de bancos de dados, precisar-se-ia de aproximadamente 30 GB de memória RAM.

Apresentação do erro:

Para que pudesse ser exibida a mensagem de erro, após alguns ajustes, foi executado o script abaixo, que retornou o erro exibido na mensagem.

 

Conclusão:

Este teste foi realizado com o intuito de uma avaliação dos impactos positivos e negativos em se utilizar o máximo do que o SQL Server oferece em possibilidade de número de bancos de dados em uma instância única.

A conclusão (Opinião pessoal) é que em linhas gerais, é esperado um número maior de problemas do que benefícios quando ambos são comparados com os prós e contras desta abordagem (Utilizar o SQL Server em seu limite).

Prós:

• Consolidação do ambiente em um único local, mesmo com uma infinidade de banco de dados a serem administrados.

Contras:

• Má utilização dos recursos, visto que será necessário um servidor absurdamente potente para gerenciar e conseguir trabalhar com este número enorme de bancos de dados.
• Maior exposição a downtime, visto que estando todos os bancos em uma única instância, em caso de falha desta, todos os bancos de dados ficarão inacessíveis.
• Não há margem para crescimento, e caso seja necessário um banco adicional, seria necessário uma instância nova… o que já pode ser pensando previamente, antes mesmo de se atingir tal número.

Resumindo

Tudo na vida tem um limite, isto não quer dizer que seja necessário trabalhar-se neste limite. Ouvi certa vez em um webcast de uma profissional de SQL Server Americana, que faz todo sentido aqui agora. “É um limite, não uma meta”.

 

Referências:

Maximum Capacity Specifications for SQL Server

https://msdn.microsoft.com/en-us/library/ms143432.aspx

Resource Database

https://msdn.microsoft.com/en-us/library/ms190940.aspx

 

Abraços,

 

Edvaldo Castro

 

Tagged Benchmark, Benchmarking, FoRG, Friends of RedGate, MTAC, SQL Server DF, sqlserver2014, virtual pass, Virtual Pass Br, VirtualPassPT