Das Verhalten, das du siehst, ist ein klassischer Effekt, wenn SQL Server‑MaxMemory und Hyper‑V‑Dynamic‑Memory nicht sauber aufeinander abgestimmt sind. SQL Server nimmt sich standardmäßig so viel RAM, wie er kriegen kann, und gibt ihn nur sehr träge wieder frei – dadurch denkt Hyper‑V, die VM sei „unter Druck“ und beginnt, Host‑Swap zu nutzen, was die Performance natürlich komplett killt. Der wichtigste Schritt ist, SQL‑MaxMemory hart zu begrenzen, sodass der Buffer Pool nicht den gesamten VM‑Speicher frisst. Parallel dazu solltest du die Dynamic‑Memory‑Grenzen so setzen, dass die VM nie unter den SQL‑Server‑MaxMemory‑Wert fallen kann, sonst kämpft der Balloon‑Driver ständig gegen den Buffer Pool.
In der Praxis funktioniert eine feste SQL‑MaxMemory‑Obergrenze plus ein moderater Dynamic‑Memory‑Bereich am stabilsten – viele Kunden fahren damit deutlich bessere Batch‑Performance
Wenn dir die Erklärung weiterhilft, klick gern auf „Accept answer“