What is the benefit of creating a named instance in SqlLocalDB instead of using the default v11.0 instance? In my scenario I am attaching a database file using AttachDbFileName option in connection string.
A helper question: is it possible to have different settings for different LocalDB instances? If so, what kind of settings (I read that you cannot change eg. collation)?
Be aware that you can only install one default instance but you can install multiple named instances. It is better to install only the default instance per host unless you have a special need to install multiple SQL Server instances on the same host, such as running different versions concurrently, clustering or other isolation requirements. Any additional instance must be named (obviously for differentiation reasons).
The underlying difference between a default and named instance is mostly a matter of network connectivity. Clients can connect to the default instance using only the host name over the well-known 1433 port. To connect to a named instance, clients specify the host and instance name (e.g. "MyHost\My_Instance") and the SQL Server Browser service returns the port the named instance is listening on.
In the real world, the reasons for having multiple instances varies from organization to organization. Here are some of the most common reasons:
Application functional or load testing
Load Testing - Ability to have multiple code bases loaded, coordinate stopping the needed instances to perform load testing, conduct the load testing then restart all of the instances once you are complete.
Functional Testing
Ability to have multiple code bases and be able to test independently with a pre-allocated amount of resources.
Server Consolidation
One of the recent trends is consolidating multiple instances of SQL Server on to a single server. With multiple SQL Server instances, it is possible to perform full SQL Server backups and restorations to a single instance to maintain the same functionality as the original server.
Internal Hosting\Departmental Server Sharing
With SQL Server originally considered a departmental solution, it is possible to have multiple instances of SQL Server on 1 physical server to equally share the server's resources (large number of CPUs and memory).
This scenario is ideal for charge backs to the departments for organizations following that paradigm.
Security
Multiple instances are ideal for those pesky third party applications that require elevated SQL Server privileges where you do not want to commingle applications on the same instance.
Demos
Multiple instances are ideal to support demo's where it is necessary to demonstrate a particular application and how it affects SQL Server.
Sources :
http://goo.gl/kJoWfz
http://goo.gl/IFBCAl
Nice to read :
What are named and default instance?
I can see two possible benefits, performance and ability to control your configuration.
LocalDB is limited the same way as other SQL Express instances, CPU and RAM limits are applied per-instance. If your application uses its own instance it will get it all for itself and won't need to share with other applications. Using default instance means your application has to share with other apps using default instance.
You might also use named instance if you need to make any special instance-wide configuration that might break other applications. Or if you're concerned that some other misbehaving application might make changes to the default instance that break your application, and have your customers blame you. Works both ways :-)
If you wanted multiple instances of SQL Server running on the same machine, you would have to name them to differentiate them. Other than that there's no real "benefit", as far as normal usage goes.
Multiple instances are useful if you need different server configurations, or even different versions. Say for example that you have a database made for Sql 2008 and want a new one for a new application with Sql 2012. You could host both on the same machine and use features for the most advanced version while keeping the old one working as it is.
Related
Basically I'm developing a website using ASP.NET MVC4, when creating a model, I need to establish a connection to the database first
When I selected the database name 7CH3LM1 (default in the drop down list), it said:
cannot connect to the database
but when I wrote like 7CH3LM1\SQLEXPRESS, it let me through
That reminded me of a question: what's the real difference behind that? what's the meaning of 7CH3LM1 and what's the point adding the SQLEXPRESS?
Any ideas are very welcomed!
7CH3LM1 is your machine name, and it helps identify the instance of SQL Server you're connecting to. In this case, you are connecting to a named instance of SQL Server running Express Edition, and its instance name is SQLEXPRESS. A machine can run multiple instances of SQL Server concurrently, and it can have one default instance and 0, 1 or multiple named instances. To connect to the default instance, you would use 7CH3LM1, and to connect to a named instance, you would use 7CH3LM1\<instance name>, as you have with 7CH3LM1\SQLEXPRESS.
I typically rename my machines to something a little more memorable and meaningful, as that can make things much easier, but that's just me.
An instance of SQL Server can contain many databases. You can specify the database in your connection string as well (recommended), or you can rely on your login's default database to define initial context (not recommended, since that database could be offline, single user, detached, etc. - which will affect your ability to log in).
Ultimately, your software will need both an instance and a database in order to read / write data.
You're talking about an INSTANCE name. Multiple instances of SQL servers can exist on the same machine. If you do not specify the instance, you will connect to the DEFAULT instance of SQL server on the machine (which may or may not exist.) When you do specify one (after the "\"), it's known as a NAMED instance.
You can read more about instances, here: msdn.microsoft.com/en-us/library/hh231298.aspx
In summary, syntax for selection of instance on MSSQL servers is expressed as
SERVERNAME\INSTANCENAME
or for the DEFAULT instance:
SERVERNAME
And, personally, I think the docs for SQL 2000 are much easier to read about DEFAULT vs. NAMED instances. You can find them here: http://msdn.microsoft.com/en-us/library/aa174516(v=sql.80).aspx
Developers are working in two different locations in differents countries, instead of having one TFS db in one location (and others connecting from another place), is it possible to have 2 replicated sites of TFS2010, each on a different server and some kind of nightly synchronisation?
We support this scenario with TFS Proxy. It stores a local cache of Version Control data on the remote location.
There is no counterpart for Work Items.
Replication is possible, because it is just a SQL Server feature. But you will have lots of conflicts during the synchronization. It is not a supported scenario, and not recommended.
I got VPS with limited memory and my WCF service is hosted using AppFabric.
Since memory is limited and I am not using SQL server for anything other than AppFabric prerequisite im thinking about uninstalling SQL Server. (instance can eat up to 200mb memory at times). I am not using any DB related features of AppFabric like dashboard or caching. I like IIS extensions and simplicity for WCF service manipulations however, and I am thinking those do not require Sql Server actually.
I am unable to just try it out so wonder if someone has such experience, or can predict result of uninstalling SQL server on appfabric behaviour.
Instead of uninstalling SQL Server you could just stop the SQL Server process. Set the process to manual startup.
That way if you need SQL Server in the future you can just start the process.
As #Shiraz Bhajiji illudes to if you are using SQLServer as the configuration store, you will need to reconfigure it to use file based configuration instead, it sounds like you are only using a single AppFabric instance, but if you are or needed to use multiple instances the config file would need to be accessible to all instances.
Again it isn't necessarily relevant to you, but if you have multiple app fabric instances, the sql server configuration option is a much more robust approach. With the file based approach, if you configure things incorrectly one app fabric node going down can take down the entire cluster. The SQLServer approach does represent a single point of failure however, if you are using clustering etc you can easily mitigate this. Again I appreciate I'm getting a little off topic here.
We have 4 products and each supports below 4 datasources.
Oracle
SQL server 2005
DB2
Datopia
Now We are building Administration product which will interact will all the products and hence their databases.We have some requirements where we have to access tables from different datasources in a single query.We initially thought of using Oracle transparent gateway to create DB links and then access tables in different datasources. But this requires oracle to be installed for one of the products. This restrictions cannot be brought in our environment(For example among 4 products 2 may have SQL server installation and other two may have DB2 installation). Which is the best way to connect to all datasources with out any restriction. One more thing, we are using java to connect to these databases. Thanks in advance.
You don't say what kind of framework your client software uses. But if it uses Java, dotnet, or PERL, you will be able to use that framework's data access modules to connect to the various table servers. You can connect to all of them from a single client process easily enough.
You db access won't be perfectly transparent. You'll need some aspects of your program to be Oracle- or SQL-Server- specific, for example. On the other hand, if you do this right, it won't be hard to add MySQL and PostgreSQL support if your customers need it.
You'll have a fairly steep QA burden -- you'll need to test with at least one and two instances of all four table servers connected simultaneously to make sure everything works.
But this kind of product usually has high value, so you should be able to justify the QA effort.
I'm currently developing an application that needs to store data in it's on database, I'm currently using SQL Server Express 2005 with Advanced Services (because we need full text search capabilities).
Local company lore says there have been all sorts of strange problems some years ago when two products used MS SQL Server with the default instance and they had interesting times cleaning everything up into making each application use a named instance.
As I can't remember the exact problems they had ... is it advisable for an application that has to run in a stable way without interference from some other application to have its database in its own named instance? If so, why? What additional isolation does that grant me as opposed to attaching the database to the default instance (or even use a watchacallit - user instance? - where you specify the mdb file location in the connection string).
Update:
The main concern I have is not performance/CPU - I'm talking about an application that manages Persons/Guests at the front desks of large organizations, think a hotel for example. I think even SQLite could easily handle the amount of data I need (disregarding some features like fulltext search).
My main concern is Customers installing stuff that interferes. From Mitchell's Answer and John's comment from it I think it is advisable to stay in a named instance - but if you have more reasons for that, please voice them.
A few things.
Using attached databases (User instance dbs) are a royal PITA for administrators to manage, as they must be attached to be accessible from SSMS and more.
Putting individual applications on their own named instances of SQL Server will create individual processes for each application, isolating resources and memory spaces for each.
Is it really necessary for each application to have its own instance of SQL Server? No, I would say typically it is not, unless it is truly 100% mission critical, however, if it is that critical, I would be surprised if it is running SQL Express.
I would recommend though from a maint. perspective that you use a standard database, rather than a user instance.