This old thread was linked to by a much newer one.

Had I noticed this at the tim

e, I would have written before now.

The problem is your definition of Service Name: it misses the point by a mile.

It most definitely is NOT a way "to identify a target instance to get connected
to". That's it's whole point! If you want to identify an INSTANCE to connect to,
you can simply specify SID=SOMETHING in your tnsnames.ora... and the fact that
doing so has been deprecated since 8i tells you that identifying an instance to
connect to is not such a good idea.

A service is a[b] logical representation of one or more instances. When you spec
ify SERVICE_NAME=SOMETHING in your tnsnames.ora, you are NOT asking to be connec
ted to an instance at all. In fact, you're saying, "I don't care what instance I
end up being connected to, so long as whatever one it happens to be is able to
provide the SOMETHING service.

In a single instance environment, service and instance are effectively synonymou
s: the collection of memory structures and processes we call an instance provide
s a service, so the service and instance can be viewed as the same thing. It wou
ld be unusual to allocate multiple service names to a single instance in a singl
e instance environment, but it's certainly do-able: it's just rather pointless,
since the only game in town is likely to be the only provider of any service you
can think of! I have never seen people needing (or wanting) to alias their sing
le instances, though, so I find your emphasis of that possibility rather peculia
r. Besides which, aliasing things in a single instance environment is rather mor
e simply achieved by having multiple tnsnames aliases in the one tnsnames.ora po
inting to the same instance or service.

The concept of a service makes a lot more sense in a multi-instance environment
(RAC). There, a number of instances could offer one service, whilst a couple of
spare instances could be offering another. A service therefore can be seen as a
way of logically "partitioning" your RAC into separate functional areas, even th
ough all instances have equal access to the same database. As such, the service
is a good way of dividing and prioritising resources (not necessarily with resou
rce manager, by the way) within the RAC.

The service is key to failover precisely because it does NOT mean "connect me to
an instance". If you said connect me to SID=INST1, then you have demanded a con
nection to a named instance and if that instance fails, tough luck: that's what
you wanted, that's what you got. I won't be failing you over to surviving instan
ce INST2. But if you had connected to SERVICE=SALES, which happens to be provide
d by INST1 and INST2, then whilst you may have -almost incidentally!- ended up c
onnected to INST1, if that instance were to fail it would be permissable and leg
itimate and possible to fail you over to INST2, because that provides the same s
ervice you actually wanted to connect to.

It is precisely because of this multi-instance subtlety that it is NOT common to
name all three the same. It's impossible to do so, in fact, because my database
sales cannot be opened by two instances both called SALES. One will have to be
called SALES1 (or something similar) and the other SALES2... and immediately, yo
ur database name does not equal your instance names. Similarly, it would rather
unusual to have instances SALES1 and SALES2 and yet have services SALES1 and SAL
ES2. That would be to see service as the same thing as instance (the trap I thin
k your description has fallen into, actually) and would negate the whole point o
f the service in the first place. More likely, you will have a service called SA
LES, comprised of instances SALES1 and SALES2 which both open a database called
SALESDB... and at that point, not one of the three elements you discussed has th
e same name!

RAC is not perhaps the most common environment to work in, so this multi-instanc
e reality might not be something you'd call "common" -and certainly, in a single
instance environment, there would be no great harm in calling all three the sam
e thing. But RAC isn't exactly rare, either: so your statement "it's common to n
ame all three the same" is deficient in specificity and accuracy.

It would not be wise, I think, to start off learning that "service is a way of d
efining an instance to connect to" when it was invented precisely not to mean th
at and where such a definition will seriously lead you astray once you move to a
RAC or Data Guard environment where understanding the profound but subtle diffe
rence between the two things becomes absolutely critical.