Database Consolidation – Named instance vs default instance
I have searched SO, but cannot find a question/answer close enough.
We are busy consolidating our database servers, partially due to address performance issues using cross-server (cross-instance – SEE: RPC) queries. A lot of extra thought is put to trying to manage the “chunk of data over the linked server” vs just letting the compiler help.
During installation, we are faced with the issue of using the default instance (.) vs. using a named instance MSSQL2016. My experience, thus far, suggest the named instance for two reasons – obscurity for security (to a lesser degree) AND the flexibility for side-by-side (upgrade, test, etc.). We use Alias’ anyway, so pointing them after installation to the “SAME” instance or different, is not going to make any real difference.
We currently have a cluster and plan to move it into a single HyperV VM. The CPU for the host (64 cores 128 GB Memory) “purrs” at 10%, so we want the compiler to start working for it’s meal.
SUMMARY: Best Practice – Should we install a named instance or use default instance for production. Most of us are programmers – so more bang for buck is better.
One Solution collect form web for “Database Consolidation – Named instance vs default instance”
Use a default instance. You can always add additional named instances later. But with VMs it’s increasingly rare to need multiple instances per VM.