Oracle Database Multiple Instance - database

Can anybody elaborate the architecture of Oracle database which have multiple instance? I want to create a multiple instance in my local oracle database.
Currently I assume that 1 SID = 1 database. is that correct?
Do i need to have different listener for each SID? or I just need 1 listener for every SID in my machine?

Usually yes, 1 SID is 1 database with the exception of RAC (Real Application Cluster) where you can have multiple instances on different servers for the same database. In this case all the instances share the same database by accessing a SAN for exemple.
You don't need to have a separate listener for each instance on the same server, I listener is sufficient for multiple instance, it's a good practice to have the listener running on the higher version of oracle though.
You can have multiple instances on the same server using multiple oracle versions.

Related

How to query multiple databases from different SQL Servers

We have approx. 8 odd SQL Servers used for different purposes like inserting data in 1 server, update in another etc. (or connecting to only that database based on user’s region).
The problem is sometimes query for data needs to be done from multiple SQL Server databases. So say, I have an Id property, and based on the Id data needs to be retrieved from multiple of these 8 servers (if there is an Id match, so basically querying all database).
So basically the server which the user is logged into, will use “Linked Server” functionality and connect to other SQL Servers (with the server which the user is currently on acts as the source SQL Server), and using “UNION” functionality to club all data.
As a lot of transactions is taking place each day, this approach is not feasible, performance wise.
So any recommendations on a better approach to achieve the same above functionality. I read a concept called “Server Groups” but not sure of it.
The application is made in .Net Web Forms using Jquery/Ajax/HTML/API and ADO.NET.
If you have a .net application which is outside these 8 servers can't you establish individual connections and pass the ID from .net app to these servers ?
As far as I know "Server Group" is a concept in SSMS which helps you to group the servers and can run common scripts at same time.

What are the benefits of named instances in SQL Server?

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.

When connecting to SQL Server what are the values for the datasource?

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

Moving and merging reporting server instances

I have a machine where we have SSRS and SQL Server running, Currently we use SSRS and configured it to use localhost SQL Server hosted ReportServer and ReportServertempdb.
Now we need decomission this machine and move the reports to a brand new machine. Now the brand new machine does not have SQL Server, but we have another SQL Server which has 2 pre-existing databases: ReportServer and ReportServertempdb which are already being used by another SSRS instance. Now we are planning to use them for our to-be-moved SSRS instance as well.
Is it possible for multiple SSRS instance to use same ReportServer and ReportServertempdb? If yes how do you merge these? There are certain conflicting values. For example in the ReportServer DB in the table "ConfigurationInfo", SystemReportTimeout is 1800 for my current instance, but on my proposed instance value is -1. How to tackle this during a merge? I have many conflicting records in both ReportServer databases.
You can create several databases on your machine, each DB + TempDB for one instance. But it is not possible to share DB + TempDB for two different instances.
Even if this would work in theory, you will get a lot of problems with sync. caches tables, security tokens, etc.
Edit: So imho backup your databases and restore on a different name. Then you SSRS configration manager to connect to a existing database.
If you use security tokens for those DB's, make sure your have the .snk file.
Though you can share RS databases across multiple instances, you cannot merge two different ones to the same one. Unfortunately we cannot even rename RS databases as they are considered system databases. Your best bet would be to see if you can host your databases on another SQL instance on the same server or redeploy your reports on the new server.
For additional information you can refer to the following links:
Scaleout deployment: http://msdn.microsoft.com/en-us/library/ms157293(v=SQL.90).aspx
Managing RS DBs:http://msdn.microsoft.com/en-us/library/ms156421%28v=SQL.90%29.aspx
http://msdn.microsoft.com/en-us/library/ms159093.aspx

Storage issues in cloud when creating multiple instances

In a cloud hosting environment (amazon, rackspace,) you can create multiple instances. Let's say I have a database server (mysql,) and other persistent data.
If I create more instances, what happens to the data ? Ex.
1 Instance -> user table (in a db)
I make another 3 instances
4 Instances -> each one has it's one user table
Errors: if someone adds data to the table on instance 3 how does instance nr 4 see it ? If I merge the instances back to one, which instance data does it keep ?
Thank you
I would suggest having one (or more) dedicated database servers that all the instances connect to. If you are using Amazon Web Services check out their RDS service ( http://aws.amazon.com/rds/ )
That way you don't need to worry about replication - if you do want each server running it's own db instance you'll have to look into replication - for MySQL this is a good guide: http://dev.mysql.com/doc/refman/5.0/en/replication.html
I would strongly recommend the former solution for the database. Replication is tricky to get right and can be a nightmare to maintain
If you are using static data eg images I would recommend using amazon's S3 service for uploading to ( http://aws.amazon.com/s3/ ) - that way all your servers are getting their data from a single point instead of having to replicate over servers, which is always going to end up a less scalable solution

Resources