| Hi Renee,
The following comes from chapter 2 in the 7.0 server configuration guide:
2.8.1 Which Services to Provide?
The following guidelines can help you to decide whether to
provide clients with a universal service or a database service:
� Provide one or more universal services if:
- Your system has a large number of databases that are
accessed infrequently and where creating a database
service for each database would be unmanageable.
- You have legacy applications or third-party ap-
plications that are able to select the database to be
used only by connecting to a universal service and
executing an SQL ATTACH statement.
- You are providing an application development en-
vironment where application developers need full
control over the databases they are using.
- You need to provide access to remote Oracle Rdb
databases when database authorization is by connect
user name.
� Provide database services if:
- Your system has a number of frequently accessed
databases that can be managed easily by using
database services.
- You want to provide fast client connection times using
prestarted executor processes that are preattached to
the appropriate database.
- You have one or more databases with suitable trans-
action workload characteristics that can take ad-
vantage of the performance gains made possible with
transaction reusable database services.
------------------------ Note --------------------------
You cannot use database services with database ac-
cess authorization set to the connect user name
to provide access to remote Oracle Rdb databases.
However, Oracle SQL/Services does allow you to pro-
vide a database service for a remote Oracle Rdb
database if you create the service with database access
authorization set to the service owner.
---------------------------------------------------------
The reason for this restriction is the method that SQL and the Rdb engine
currently provide to SQL/Service for setting the Rdb SESSION USER name for
pre-attached, database services. Specifically, SQL/Services uses what we call
internally, a 'light-weight connect'. Normally, when a client issues a SQL
CONNECT request, a new attach is made to the database (even if the connect is
made to an existing alias - effectively, the database file name of the
specified alias is used to make another attach). When SQL/Services uses a
light-weight connect, SQL and the engine simply treat the connect as a new
connection to the existing attach (or heavy-weight connect, if you like).
If database authorization service owner is specified, then no user name is
specified on the connect, so the session user name defaults to the system
username. If database authorization connect user is specified, then a username
is specified on the connect, but no password is specified. In this latter case,
SQL/Services calls an internal DSRI routine to tell dispatch and the Rdb exec
how to handle this situation (username with no password). Note that we don't
use this mode with database authorization service owner, so that's why that
attach works. One of the things this mode enforces is that all attaches must
have an explicit username and password, hence the implicit authorization
failure. I can't explain why the attach with explicit username/password fails,
except to say that when I tried it first, it tried to use my proxy, which meant
it didn't run the correct login.com/rdb$setver procedure; when i used "":: to
disable the proxy, it worked fine.
The reason why the engine allows a username with no password is because it
'trusts' the SQL client (the executor in this case), because it has a special
identifier on VMS (RDB$TRUSTED_USER) or is running under the rdbmgr account on
OSF. The reason it doesn't work remotely is that the Rdb engine is no longer
in the same process, or even on the same node, as the executor, so it has no
way to verify that the SQL client is trusted to specify a username with no
password.
(FYI - Don't look at me, I didn't design this, I wanted to use passwords so
that we could support this very situation, but I got out-voted).
As it happens, this doesn't work on NT either, because the Rdb engine is always
in a separate process from the SQL client. So as of 8.0, on NT at least, we'll
have to start using passwords to create light-weight connects. Whether or not
this gets supported on VMS or OSF is a different matter - I'll pass it onto the
folks who are doing this though. For what its worth, this whole thing only
works if the SQL/Services executor and Rdb server are in the same VMS cluster
or other security domain, or if the executor and Rdb server nodes have accounts
with the same names and passwords. But that's getting us down an even bigger
rat-hole, that I'd rather avoid right now...! :-)
Sections 2.7, 2.9 and 2.12 in the 7.0 server configuration guide try their best
to explain how all this works, but have to stop short of discussing
light-weight connects and other internal mechanisms on which SQL/Services
relies.
Hope this explains it, though I understand its not going to help much...
Si
|