There are clouds on the horizon

I've often observed DBAs who confidently set the maximum memory size, yet few truly understand the implications of their actions. In my view, this issue is closely tied to the SQL Server Interface. While it appears straightforward, allowing anyone to feel competent in its use, the reality is far more intricate than it seems.

In such instances, a poorly designed user interface (UI) actually serves a purpose by making us more conscious of our actions, similar to other relational database management systems (RDBMS). It's common knowledge that some DBAs set the maximum memory based on intuition rather than through careful calculation.

Regrettably, inexperienced DBAs frequently allocate a figure to the operating system, believing it to be sufficient. But one must ask, is this assumption valid? Is this figure derived from any concrete calculations or metrics? Consider whether you've accounted for the maximum number of worker threads, tracked the server's total memory usage hosting the SQL Server instance, and deducted memory allocations beyond the control of maximum server memory. This includes backup buffers, extended stored procedure DLLs, objects created through automation procedures (sp_OA calls), and allocations from linked server providers.

In summary, it's essential to question each configuration step you intend to make. Reflect on the rationale, read white papers, and seek out best practices from MVPs in the field.