Você leu o título e ainda está confuso? Bem, eu também estou.
Acabei de começar um novo trabalho como DBA para um novo empregador e encontrei algumas formas criativas de instalar o SQL Server. Minha experiência anterior com o SQL Server é toda baseada em instâncias únicas do MSSQLSERVER executadas em hardware virtual ou físico. Costumávamos evitar instalações de várias instâncias do SQL Server apenas para manter tudo realmente separado e simples.
Aqui, em meu novo empregador, eles agruparam algumas instâncias do SQL Server Standard Edition em um único hardware virtual. O raciocínio deles (bem, acho que agora devo chamá-lo de nosso...):
- Ter várias instâncias do SQL Server em um hardware (virtual) reduz a quantidade de SQL Servers e os custos de licença em todo o ambiente.
Ainda não encontrei nenhum outro raciocínio por trás dessa configuração.
Não há absolutamente nenhum grupo de disponibilidade ou replicação transacional em andamento e o envio de log de transações não foi implementado.
Os servidores foram configurados para ter a instância padrão e várias instâncias adicionais conforme explicado abaixo.
Ambiente SQL Server
Os SQL Servers são configurados para conter várias instâncias.
Relacionamento de servidor para instância
Cada SQL Server pode ter de 1 a n instâncias
SQL_SERVER_01 (Standard Edition SQL Server)
\ MSSQLSERVER (default instance)
\ VARIOUS_INS (the 2nd instance)
\ SOMETHINGNW (the 3rd instance)
\ A_NAMEGIVEN (the 4th instance)
\ INSTANCENEW (the xth instance)
Instância | PI | Porto | Alias (CNAME)
Cada instância está relacionada a um endereço IP e cada endereço IP possui um Alias individual (CNAME) para que o SQL Server possa sempre escutar na porta 1433. Isso simplifica a configuração do firewall, pois as regras só precisam ser adicionadas para a porta padrão do SQL Server . Hmmm.
MSSQLSERVER | 10.0.0.22 | 1433 | SQL_SERVER_01_I00
VARIOUS_INS | 10.0.0.23 | 1433 | SQL_SERVER_01_I01
SOMETHINGNW | 10.0.0.24 | 1433 | SQL_SERVER_01_I02
A_NAMEGIVEN | 10.0.0.25 | 1433 | SQL_SERVER_01_I03
INSTANCENEW | 10.0.0.26 | 1433 | SQL_SERVER_01_I04
Portanto, para cada instância do SQL Server em execução no mesmo servidor virtual, a equipe de rede deve fornecer um endereço IP para a NIC virtual e criar um CNAME/Alias para o endereço IP da instância. Cada NIC virtual deve ser configurada para o endereço IP correto e a Configuração do SQL Server deve ser configurada corretamente para o endereço IP de cada instância (ouvir neste endereço IP, ativo para este endereço IP, ....). O SQL Server não responderá à notação SERVER\INSTANCE típica, o que significa que os servidores só podem ser acessados por meio do Alias/CNAME (por exemplo, SQL_SERVER_01_I00)
O hardware (virtual)
Antes que eu me esqueça, acho que seria uma boa ideia dar a você uma ideia do hardware virtual típico configurado para tantas instâncias do SQL Server.
discos
Os discos virtuais são pré-configurados no VMware e anexados ao SQL Server. Algum fornecedor de hardware em segundo plano. Pode ser IBM, pode ser Hitachi, .... Um disco para os arquivos MDF e um disco para os arquivos LDF.
processadores
Sim, vários processadores. Neste exemplo, quatro processadores lógicos @2,9 GHz
Memória
Apenas 32 GB para este servidor. Cada instância do SQL Server é configurada para consumir entre 1 GB e 4 GB de memória. Este servidor tem, por exemplo, 6 instâncias, cada uma contendo entre 1 ... 10 bancos de dados variando em tamanho de alguns 100 MBs a alguns GBs. Nada enorme.
Configuração da instância do SQL Server
Cada instância do SQL Server será configurada da seguinte maneira.
grau máximo de paralelismo
Padrão (0)
Memória
A memória mínima será definida como 256 MB e a memória máxima entre 1 GB e 4 GB.
máscara de afinidade
Não configurado.
custo para grau máximo de paralelismo
Padrão (5)
Meus pensamentos
Com minha experiência, aprendi que ter instâncias únicas é o melhor em relação às definições de configuração e ao analisar problemas. Mas isso não parece ser uma opção aqui. Portanto, não há necessidade de começar a discutir nessa direção. Eu sei.
Acho que ter apenas 4 processadores lógicos e MAX_DOP definido como 0 para todas as sete instâncias e os vários bancos de dados em segundo plano é uma má ideia. Se um sistema atrasar, todos eles vão atrasar seriamente.
As questões)
Visto que você conheceu meu ambiente, acho que alguém por aí terá uma configuração semelhante e poderá me fornecer algum script para analisar tudo ou ser capaz de me indicar a direção certa para recomendações.
Aqui vai:
- Devo ter pelo menos um processador lógico por instância, visto que atualmente tenho apenas 4 processadores lógicos para 6 instâncias e MAX_DOP definido como 0?
- Se eu tivesse um processador lógico por instância, devo deixar MAX_DOP em 0 ou limitar cada instância a MAX_DOP = 1?
- Visto que é uma Standard Edition, devo limitar MAX_DOP a 4 como alternativa?
Não estou com pressa e tenho algum tempo para gastar. Só estou curioso para saber se alguém já passou pela mesma situação que eu e como lidou com a situação.
Obrigado pelo seu tempo.
Isso depende, quanto uso de CPU cada instância está usando em média? Você pode obter essas informações do evento estendido de sessão de integridade padrão que está em execução (assumindo 2008+).
Quatro processadores lógicos podem ser perfeitamente adequados para esta carga de trabalho - não saberemos até que tenhamos dados. Dito isso, como cada instância do SQL Server age por conta própria e não tem ideia das outras instâncias instaladas, tenho certeza de que o Windows não está muito feliz com a troca de threads.
Eu daria uma olhada em minhas estatísticas de espera dmv e veria se temos uma porcentagem maior de tempo de espera na parte signal_wait, o que indicaria problemas de agendamento e possível contenção entre instâncias. Além disso, eu faria isso com as opções de contexto da CPU para ver se há uma correlação fraca ou direta com "momentos ruins" e "bons momentos" da integridade da instância.
Meu instinto, porém, me diz que, a menos que sejam instâncias lamentavelmente subutilizadas, esse servidor está sujeito a problemas - estejam acontecendo agora ou daqui a alguns meses.
MAXDOP apenas limita o número de processadores lógicos ('schedulers') que uma única consulta paralela pode usar durante a execução. Não há nada que impeça o SQL Server de executar várias consultas paralelas; na verdade, diagnostiquei e corrigi esse mesmo problema várias vezes para lugares que nem sabiam que tinham um problema de agendamento (era considerado um problema de "bloqueio").
Definir MAXDOP como 1 essencialmente torna todas as consultas do usuário de thread único. Isso, novamente, não impede que o SQL Server execute mais de uma única tarefa por vez, pois apenas força execuções seriais. Isso significa que cada instância tem quatro (4) agendadores online visíveis para um total de 4*x número de instâncias possíveis de consultas simultâneas. Definir MAXDOP aqui não resolve o problema de ser logicamente sobrecarregado, não levando em consideração a configuração real do servidor virtual quanto à possibilidade de execução em núcleos hiperencadeados (se ativado). Caramba.
Não estou dizendo que forçar MAXDOP para 1 é bom ou ruim, apenas que não temos dados para prosseguir. Assim, não saberemos o impacto da configuração. Mais uma vez, porém, DEFINITIVAMENTE não o definiria como quatro (4)!
Bem, não pode ser maior que quatro (4), então já é limitado. Esta questão, acredito, está intimamente ligada à pergunta acima. Espero ter explicado a um nível satisfatório de compreensão.
Se você quiser ter uma ideia (devido ao pequeno limite de paralelismo) de quantas consultas estão sendo paralelizadas, verifique os planos de execução dmv. Esta é uma operação bastante cara, portanto, faça-a fora do horário ou em horários de pouco ou nenhum uso entre TODAS as instâncias. Lembre-se, o que você fizer em uma instância será (aproximadamente) feito em todas devido à natureza compartilhada do servidor.