Re: Need help on MTS configuration

Syltrem wrote:

> Howard,
>
> Yes, The INSTANCE_NAME has to be set otherwise the instance name is
> registered as "@" by the listener.
> Even if ORA_SID (the logical name that does the same job as the Unix
> variable ORACLE_SID) is set.
> $ lsnrctl service
> @ has 1 service handler(s)
> DEDICATED SERVER established:0 refused:0
> LOCAL SERVER
>
> and...
> $ sqlplus user/pwd_at_inercs
>
> SQL*Plus: Release 8.1.7.0.0 - Production on Tue Oct 26 15:30:37 2004
>
> (c) Copyright 2000 Oracle Corporation. All rights reserved.
>
> ERROR:
> ORA-12500: TNS:listener failed to start a dedicated server process
>
> -------------------------------------------
> What I have now is this:
>
> INIT.ORA
> -----------------------------
> db_name = "INERCS"
> instance_name = "INERCS"

I'll buy that you need this. Perhaps someone else with OpenVMS experience would confirm?

> db_domain = world
> service_names = INERCS.WORLD

Just to satisfy a curmudgeonly bastard this end, does everything work without that parameter? Because SERVICE_NAMES should default to DB_NAME+DB_DOMAIN, and you've already got both of those set. It should do, but again OpenVMS might be different in this regard.

> mts_dispatchers = "(PROTOCOL=TCP)(DISPATCHERS=1)"

Beautiful!

> mts_max_dispatchers = 3
> mts_servers = 4
> local_listener = INERCS
>
> TNSNAMES.ORA
> -----------------------------------------
> MTS_INERCS.WORLD =
> (DESCRIPTION =
> (ADDRESS_LIST =
> (ADDRESS = (PROTOCOL = TCP)(HOST = HELIOS)(PORT = 1526))
> )
> (CONNECT_DATA =
> (SERVICE_NAME = INERCS.WORLD)
> )
> )
>
> INERCS.WORLD =
> (DESCRIPTION =
> (ADDRESS_LIST =
> (ADDRESS = (PROTOCOL = TCP)(HOST = HELIOS)(PORT = 1526))
> )
> (CONNECT_DATA =
> (SERVICE_NAME = INERCS.WORLD)
> (SERVER = DEDICATED)
> )
> )
>
> Btw, I noticed that the alias names must also have the .WORLD in
> tnsnames.ora (not just the service names need it).

You need to read what's in your sqlnet.ora. There is a parameter that is usually set in there called something like NAMES.DEFAULT_DOMAIN (I don't have one to hand to check out the specifics). If that is set to "WORLD", then whenever an unqualified connection request is made (eg, connect scott/tiger_at_LX10) then the sqlnet.ora slaps on the default domain, silently (so, in reality, what gets issued under the hood is connect scott/tiger_at_lx10.dizwell.local).

But, of course, if what is really being issued under the hood is a fully-qualified connection alias, then your tnsnames.ora must contain qualified aliases, otherwise there'll be the 'unable to resolve' error message.

So you then have a choice: either domain-less tnsnames.ora, and no default_domain in the sqlnet.ora. Or you have the default_domain in the sqlnet.ora and use domains in your tnsnames.

Now again, that's the story from a Windows and Linux and Solaris perspective. It could all be very different in the planet where you come from!!

> What's all about the
> domains? What purpose do they serve? Certainly here they're just
> cumbersome.

Agreed, but the idea is that a large organisation might have a SALES database for European sales, and a SALES database for American sales and a SALES database for Australasian sales. How then do you distinguish between three otherwise identical databases?

The suggestion is that you would have a SALES.LARGECORP.EU SALES.LARGECORP.US and a SALES.LARGECORP.AU, and then the problem is solved.

But yes, absolutely. For a small shop with no need to differentiate databases in that way, they are a pain in the butt, and I for one would like a USE_DOMAIN=FALSE parameter in the init.ora and every other .ora I could lay my hands on!  

> As for the hanging problem, the TAR is still in "Work In Progress" status.
> I was told there are many bugs in 8i that will not be fixed (even if the
> desupport date is officially 2 months from now). If nothing else works I
> will try to use a 9.2 listener and see if that helps.

That is a very good idea, actually. No reason I can think of not to use 9i networking functionality whilst keeping the database back at 8i. Shame the trick won't work with 10g!

Good luck
HJR
> I'm waiting for
> another Oracle fix before I can (re)install 9i. I can't upgrade my db
> right now, must wait for the vendor software to be upgraded as well
> (soon).
>
> Thanks !
>
Received on Tue Oct 26 2004 - 14:54:28 CDT