what are named and default instance? what is the difference between them? why they are used?
|
feedback
|
|
According to Microsoft regarding named vs default
| |||
|
feedback
|
|
In addition to the explanation Brett G posted, here are some reasons on why to use them:
All kinds of reasons to use them. Doesn't mean it's always a good idea, though :P | |||
|
feedback
|
|
Also you can install only one default (unnamed instance) but you can install many named instances. Many third party software will usually use a default named instance although they may not mention it. The reason is clear from the above answers, standard versions installs an unnamed instance by default while Express version install a named instance be default. It is important to know about the difference from this perspective because if you have 2 or 3 DB Servers running, you might never connect to the right version. Because the third party software is looking for the default instance while you are thinking it is the SQLEXPRESS instance it is trying to connect to. It can significantly increase your troubleshoot time, if you dont know how to connect to named vs unnamed instance. So if you want to connect to Named Version, the connection string would be
Note that even though a default instance has a name, it can not be referenced by that name! | |||
|
feedback
|
|
One of the best reasons is seperation of databases. If you are developing your own application and packaging SQL Express with it, then it makes sense to install it into it's own instance. Plus giving the user the option to specify an existing SQL installation if they perfer that. If you have a database that is critical that you want to ensure no one else has access to, it can go into it's own instance with a very limited security authorization. Say that's your prodcution DB, and it then replicates over to the reporting DB on the same server** which is read only for people. It is less likely though user (admin) error the users would accidently get access to the production DB, by limiting who is actually able to update the security groups on the production instance to only a few people. **good practice says to make the reporting server a seperate machine, but I'm just doing this as an example. | |||
|
feedback
|
|
You can also cap memory and assign limit processor usage per instance. You could also create an instance for vendor written apps that 'need' system admin privileges, so you don't put your other applications at risk. | |||
|
feedback
|
|
Yet another practical difference: SQL2005 and up allow you to install 16 or more instances per system. Since licensing is per physical CPU, per installation of SQL server (and not per instance!), this means you can run up to 16 instances of SQL Server 2005 without paying a cent more than you did already. Given that CPU licenses can run to $15000 (!) per socket, this is a must-have for large installations with, say, 16 cores and 256GB memory. | |||
|
feedback
|