Quais são as grandes limitações que devo esperar dos servidores SQL vinculados?

Nosso produto é baseado no Microsoft SQL Server. Atualmente, estamos usando três bancos de dados e sempre os implantamos em uma instância do SQL Server.

Os três bancos de dados são OLTP, OLAP e auditoria. O banco de dados OLAP possui dados de entrada massivos no EOD do OLTP e da auditoria, usando consultas entre bancos de dados.

Questões

Se implantássemos esses três bancos de dados em três instâncias separadas do Standard Edition em um único servidor físico e vinculá-los usando o recurso Servidor Vinculado do SQL Server:

1. Quão transparente será para o código do aplicativo? Quanta mudança devo esperar?
2. Os dados de entrada no OLAP totalizaram em 50 mil a 100 mil linhas, 200 a 500 MB de carga útil por EOD. Quanta queda de desempenho devo esperar?
3. Que outras grandes limitações devo esperar?

fundo

Atualmente, estamos lançando nosso potencialmente primeiro cliente com mais de 500 usuários simultâneos.

Estamos elaborando uma especificação de servidor, que inclui 64 núcleos e 256 GB de RAM. Para o SQL Server utilizar todos esses recursos abundantes, o cliente precisaria comprar o Enterprise Edition, que para o SQL Server 2016 está disponível apenas no licenciamento por núcleo.

Temos medo de que apenas o custo do licenciamento (64 x US $ 7400) os reduza. Então, estou pensando em dividir o banco de dados em três instâncias do Standard Edition e conectá-los, esperando que o recurso de vinculação seja transparente com o código do aplicativo.

Quão transparente será para o código do aplicativo? Quanta mudança devo esperar?

Não é transparente. Espere grandes mudanças.

Você deve estar preparado para uma degradação de desempenho muito substancial.

A Consulta Distribuída (a estrutura para servidores vinculados) usa um modelo OLEDB geral, independentemente do servidor do outro lado. É verdade que um destino do SQL Server pode oferecer informações mais completas (metadados, estatísticas etc.), mas o resultado ainda está longe de ser tão fortemente integrado ou capaz quanto uma operação nativa entre bancos de dados.

As consultas remotas têm uma reputação merecida por desempenho lento e más escolhas de plano pelo otimizador. Instruções que alteram dados (excluir, inserir, atualizar, mesclar) são particularmente propensas, pois o modelo básico geralmente é o de um cursor.

Se você nunca precisar executar consultas ad-hoc entre instâncias, poderá ajustar manualmente cada consulta armazenada para obter um desempenho aceitável, mas isso é muito trabalhoso e o sucesso não é garantido.

Para operações em massa cruzada exemplo, você seria muito melhor fora de usar operações reais granel ( bcp, BULK INSERT, SSIS ... etc.) Entre instâncias do que usando servidores vinculados.

Tudo isso dito, a idéia básica parece muito mais problemática do que vale para mim. Especifique o hardware que funcionará dentro das restrições da Standard Edition; ou, se o cliente exigir um desempenho superior, obtenha um servidor maior e use o Enterprise Edition.