Re: SQL*Net communities, domains, etc.

Darin Strait wrote:
>
> I'm trying to set up a tiny SQL*Net 2.x network that will (hopefully)
> evolve into a large SQL*Net network. I am trying to do things the
> Right Way, but I find the Oracle-supplied examples in the
> understanding SQL*Net manual a little lacking. The examples are
> designed to show tactical stuff for small networks, but I am
> interested in strategic stuff for large networks.
>
> For example, how do I want to set up my domains? Do I want them to map
> to sites or protocols? Do I need separate communities for each site,
> even though everyone is using TCP? What is a "remote" database,
> anyway? I can see all the database machines as notes on my WAN, does
> that mean that I have no "remote" database?
>

You will map to both protocols and sites. The highest level, regardless of how they explain it in the user guides, is community. The word community, when used in connection with Oracle SQL*NET, is synonymous with protocol. A community is a protocol, i.e., TCP/IP = 1 community, DECNET = 1 community. You only need one community per protocol for the enterprise. The next level down is domain. This is where you must decide whether to use the default domain, WORLD, or develop your own domain naming strategy. You can identify domains by almost anything you want, for example, all UNIX machines in one domain, all marketing machines in one domain, all California machines in one domain, etc. It really is up to you to decide what makes the most sense in terms of current and future use/growth. You may find it easier to specify domains in terms of what department owns (pays for) the machine, or what organization in the company the databases on the machine support.

As far as I can tell, remote means any database that is not running on the machine that you are sitting in front of. Which, these days, means almost every database you are managing. A database on one machine is remote from databases on other machines. In SQL*NET parlance, remote helps to identify the connection necessary to access the database. For example, if I am running SQL*PLUS on the local machine (i.e., I am at the root terminal or telnet to the machine) I connect to the database in a different way, normally, than if I use a SQL*NET connection from, say, a PC. This distinction is useful in building and deploying SQL*NET control files.

If you do not have it, get the latest version of Network Manager. I have version 3.0.1.0.2. It is a much improved product and helps to visually design and maintain your SQL*NET network. Received on Mon Apr 15 1996 - 00:00:00 CEST