Det er uklogt at køre SQL Server med enhver andet produkt, herunder en anden forekomst af SQL Server. Årsagen til denne anbefaling er karakteren af, hvordan SQL Server bruger OS-ressourcerne. SQL Server kører på en brugertilstandshukommelsesstyrings- og processorplanlægningsinfrastruktur kaldet SQLOS . SQL Server er designet til at køre med maksimal ydeevne og antager, at det er den eneste server på operativsystemet. Som sådan reserverer SQL OS al RAM på maskinen til SQL-processer og opretter en skemalægger for hver CPU-kerne og tildeler opgaver, som alle skemalæggere kan køre, ved at bruge al CPU, den kan få, når den har brug for det. Fordi SQL reserverer al hukommelse, vil andre processer, der har brug for hukommelse, få SQL til at se hukommelsestryk , og responsen på hukommelsestryk vil fjerne sider fra bufferpuljen og kompilerede planer fra plancachen. Og da SQL er den eneste server, der rent faktisk udnytter hukommelsen meddelelse API (der er rygter om, at den næste Exchange også vil), SQL er den eneste proces, der faktisk krymper for at give plads til andre processer (såsom utætte buggy ASP-puljer). Denne adfærd er også forklaret i BOL:Dynamic Memory Management .
Et lignende mønster sker med CPU-planlægning, hvor andre processer stjæler CPU-tid fra SQL-planlæggerne. På avancerede systemer og på Opteron-maskiner bliver tingene værre, fordi SQL bruger NUMA lokalitet til fuld fordel, men ingen andre processer er normalt ikke opmærksomme på NUMA, og så meget som operativsystemet kan forsøge at bevare lokaliteten af allokeringer, ender de med at allokere hele den fysiske RAM og reducere den samlede gennemstrømning af systemet som CPU'erne går i tomgang og venter på sideadgang på tværs af numa-grænser. Der er også andre ting at overveje, f.eks. TLB og L2 misforøgelse på grund af andre processer, der optager CPU-cyklusser.
Så for at opsummere, du kan køre andre servere med SQL Server, men anbefales ikke. Hvis du skal , så sørg for at isolere de to servere efter bedste evne. Brug CPU-affinitetsmasker til begge SQL og IIS/ASP for at isolere de to på separate kerner, konfigurer SQL til at reservere mindre RAM, så det efterlader ledig hukommelse til IIS/ASP, konfigurer dine app-puljer til at genbruge aggressivt for at forhindre vækst i applikationspuljen.