Re: 3 Standby database settings questions

<76434.1353_at_compuserve.com> wrote in message news:401d81b4.53474322_at_news.hccnet.nl...
> Question:
>
> I see this enable /defer statement in the documentation of the Oracle
> Standby server:
>
> 1. Why should I add this " enable " statement in the ini file when it
> is already a default value? Or is it not? Does this "enable" statement
> has additional value?

None whatsoever. Except that it is generally good practice to state things explicitly. If you are silent on a subject, and a default kicks in, do I assume you knew what the default was and wanted it to apply? Or do I assume you didn't know what the default was, and you just forgot to specify a setting? By having an explicit setting, I can see very definitely what you intended to be enabled and what you intended to be deferred, and I don't have to wonder about your thought processes. But functionally, no: setting it explicitly adds nothing.

>
> 2. Same question for " optional " archiving. Do I have to put in
> "optional " if I never want to make use of mandatory?

Nope. Same as above.

> 3. TNSNAMES. When configuring the TNSNAMES file of the primairy
> database while implementing the standby database: some examples makes
> use of the "Service name = " parameter instead of " SID = "
> Which one should I use. What is the difference?

In a single instance environment, it makes no real difference, except that SID= is a bit old-fashioned, and you should get used to the more modern way of doing it with SERVICE=. The real difference between the two is that, starting from 8i, Oracle realised that sometimes you want to connect to something bigger than an instance. Think Real Application Clusters, for example. A cluster "SALESRAC" might be composed of INSTA and INSTB and INSTC. You don't particularly want to connect to a specific instance (because then you lose many of the benefits of failover, cache fusion and so on): you just want to connect to the cluster. Hence, there is an entity (the cluster) which is bigger than its component instances. A service therefore represents the bigger entity. You configure all of the individual instances to have SERVICE_NAME=SALESRAC in their init.ora's, and as each starts up they announce to the Listener that, although specifically called "INSTA" or "INSTB" etc they are nevertheless all part of the "SALESRAC" service. In which case, your tnsnames can then request a connection to the *service*, not a specific SID (which is the same as a specific instance). The Listener then knows it can pick one of three instances to actually forward you on to, and will partake in some load-balancing when working out which one to pick. You end up connected OK, but you don't know which specific instance you got routed through to.

Regards
HJR

-- 
------------------------------------
Oracle insights at www.dizwell.com
------------------------------------