Não é aconselhável executar o SQL Server com qualquer outro produto, incluindo outra instância do SQL Server. O motivo dessa recomendação é a natureza de como o SQL Server usa os recursos do SO. O SQL Server é executado em uma infraestrutura de agendamento de processador e gerenciamento de memória de modo de usuário chamada SQLOS . O SQL Server foi projetado para ser executado com desempenho máximo e pressupõe que seja o único servidor no sistema operacional. Como tal, o SO SQL reserva toda a RAM na máquina para o processo SQL e cria um agendador para cada núcleo de CPU e aloca tarefas para todos os agendadores serem executados, utilizando toda a CPU que puder obter, quando necessário. Como o SQL reserva toda a memória, outros processos que precisam de memória farão com que o SQL veja pressão de memória , e a resposta à pressão da memória removerá as páginas do buffer pool e os planos compilados do cache de planos. E como o SQL é o único servidor que realmente aproveita a memória notificação API (há rumores de que o próximo Exchange também), SQL é o único processo que realmente encolhe para dar espaço a outros processos (como pools ASP com bugs com vazamento). Esse comportamento também é explicado em BOL:Gerenciamento de memória dinâmica .

Um padrão semelhante acontece com o agendamento da CPU, onde outros processos roubam o tempo da CPU dos agendadores SQL. Em sistemas de ponta e em máquinas Opteron, as coisas pioram porque o SQL usa NUMA localidade para aproveitar ao máximo, mas nenhum outro processo geralmente não conhece o NUMA e, por mais que o SO tente preservar a localidade das alocações, eles acabam alocando toda a RAM física e reduzem o throughput geral do sistema como as CPUs estão ociosos aguardando o acesso à página de limite entre uma. Há outras coisas a serem consideradas, como TLB e aumento da falta de L2 devido a outros processos que ocupam ciclos de CPU.

Então, para resumir, você pode executar outros servidores com SQL Server, mas não é recomendado. Se você deve , certifique-se de isolar os dois servidores da melhor maneira possível. Use máscaras de afinidade de CPU para ambos SQL e IIS/ASP para isolar os dois em núcleos separados, configure o SQL para reservar menos RAM para deixar memória livre para IIS/ASP, configure seus pools de aplicativos para reciclar agressivamente para evitar o crescimento do pool de aplicativos.