Oracle8i Documentation Addendum Release 3 (8.1.7) Part Number A85455-01 |
|
This chapter describes new and changed features for Net8 in release 8.1.7. This chapter contains these topics:
Directory access configuration, described on pages 6-17 through 6-18 of the Net8 Administrator's Guide has changed in release 8.1.7. The configuration method is described in this section.
Net8 directory naming and Oracle Advanced Security enterprise user features use a centralized directory server to store entries. If you want to use these features, you must establish a directory for them, as well as enable computers to access the directory.
You can configure directory access during or after installation. This section contains these topics:
Oracle Universal Installer launches Net8 Configuration Assistant after software installation. Net8 Configuration Assistant enables you to configure access to a directory. Directory access configuration varies depending on the installation mode you selected during installation, as described in these topics:
After a custom installation on the server, Net8 Configuration Assistant prompts you to configure access to a directory. Directory access configuration enables:
During directory access configuration, Net8 Configuration Assistant prompts you to configure the following directory access settings:
The administrative context is a directory entry that contains an Oracle Context (cn=OracleContext
). An Oracle Context is the root of a directory subtree under which all Oracle software-related information is kept. A published directory entry for the administrative context must exist; otherwise, you cannot select an administrative context.
This configuration information is stored in an ldap.ora
file that the server reads to locate the directory and to access Oracle entries.
If an Oracle Context does not exist in the directory under the selected administrative context, Net8 Configuration Assistant prompts you to create it. During Oracle Context creation, you are prompted for directory authentication credentials. If the Oracle Context is created successfully, the authenticated user is added to the following groups in the directory:
cn=OracleDBCreators,cn=OracleContext
)
Being a member of OracleDBCreators enables a user to use Oracle Database Configuration Assistant to register a database service entry.
cn=OracleNetAdmins,cn=OracleContext
)
Being a member of OracleNetAdmins enables a user to use Net8 Assistant to create, modify, and delete net service names, and modify Net8 attributes of database services.
cn=OracleSecurityAdmins,cn=OracleContext
)
Being a member of the OracleSecurityAdmins group gives the user full control over the Oracle Context. Such a user can perform the same operations as users who are members of both OracleDBCreators and OracleNetAdmins, as well as being able to perform additional enterprise security operations.
A directory administrator can add other users to these groups.
In addition, Net8 Configuration Assistant verifies that the Oracle schema was created. The Oracle schema defines the Oracle entries and their attributes. If the schema does not exist or is an older version, you are prompted to create it. During Oracle schema creation, you are prompted for directory authentication credentials.
After Net8 Configuration Assistant completes configuration, Oracle Database Configuration Assistant creates the database. The service name for the database is automatically created under the Oracle Context.
See Also:
|
During client installation, Net8 Configuration Assistant prompts you to configure access to a directory. Directory access configuration enables the client to look up connect identifier entries in the directory. If directory access is not configured, the client cannot use directory naming.
Net8 Configuration Assistant typically performs the necessary directory access configuration during client installation and stores the following in a read-only ldap.ora
file.
During directory access configuration, Net8 Configuration Assistant prompts you to configure the following directory access settings:
This configuration information is stored in a ldap.ora
file that the client reads to locate the directory and to access Oracle entries.
In addition, Net8 Configuration Assistant verifies that the Oracle schema was installed. If an Oracle Context or the Oracle schema was not configured by the server, you cannot complete directory access configuration on the client.
Directory access can be configured with Net8 Configuration Assistant at any time.
To configure directory access:
netca
from $ORACLE_HOME/bin
.
The Welcome page appears.
The Directory Service Access page appears.
The Directory Service Access page options are as follows:
Option | Description |
---|---|
Configure this Oracle Home to use a directory server that is already set up for Oracle features |
Choose this option to enable this computer to use a directory server that is already configured to use directory naming or enterprise user security features. This option is ideal for clients that use a directory server that has already been configured for these features. Once configuration is complete, this option enables this computer to look up entries in the directory. This option prompts you to:
Note: If no Oracle Context or Oracle schema exists, you cannot configure this computer to use the directory. |
Configure a directory server for Oracle features, and configure this Oracle Home to use the directory |
Choose this option to configure a directory server for directory naming and enterprise user security features, and to enable this computer to use that directory. This option is designed for administrators who first configure these features. Once configuration is complete, this computer can then look up entries in the directory. This option prompts you to:
A published directory entry for the administrative context must exist; otherwise, you cannot select an administrative context. If an Oracle Context does not exist under the administrative context, you are prompted to create one. Likewise, if the Oracle schema does not exist or is an older version, you are prompted to create it. During Oracle Context or Oracle schema creation, you are prompted for directory authentication credentials. If the Oracle Context is created successfully, the authenticated user is added to the following groups in the directory:
See Also:
|
Create a new Oracle Context |
Choose this option to create an additional Oracle Context in the directory. To create an Oracle Context, the following must exist in the directory: During Oracle Context creation, you are prompted for directory authentication credentials. If the Oracle Context is created successfully, the authenticated user is added to the following groups in the directory: |
Create or update Oracle schema objects |
Choose this option to create the Oracle schema in the directory, or update the Oracle schema to the current release. During Oracle schema creation, you are prompted for directory authentication credentials. |
The user that creates the Oracle Context is a member of the OracleNetAdmins (cn=OracleNetAdmins,cn=OracleContext
) group. Using directory tools, such as ldapmodify
, a directory administrator or the directory user who created the Oracle Context can add users to this group.
To add a user to the OracleNetAdmins group with ldapmodify
:
cn=OracleNetAdmins
and the user that you want to add.
dn: cn=OracleNetAdmins,cn=OracleContext,... changetype: modify add: uniquemember uniquemember: <DN of user being added to group>
ldapmodify
syntax to add the user:
ldapmodify -h host -p port -D binddn
-w password -f ldif_file
Before sending data across the network, Net8 buffers and encapsulates data into the session data unit (SDU). Net8 sends the data stored in this buffer when the buffer is full, flushed, or when RDBMS tries to read data. When large amounts of data are being transmitted or when the message size is consistent, adjusting the size of the SDU buffers can improve performance, network utilization, or memory consumption.
The SDU size can range from 512 bytes to 32 KB. The default SDU for the client and the database is 2 KB.
Optimal SDU size depends on the maximum segment size (MSS) and message fragmentation. For TTC connections, configuring an SDU size larger than the 2 KB default requires configuring the SDU on both the client and server computers. When the configured values do not match, the lower of the two values will be used.
To minimize packet header overhead and message fragmentation, set the SDU size as a multiple of the MSS. When Oracle Advanced Security encryption is not used, increase the SDU size by one (1). For example, the TCP/IP version 4 MSS on Ethernet is 1460 bytes. Use a multiple of 1460 for the SDU size if encryption is used. If encryption is not used, increase the SDU size to 1461.
The packet header overhead and message fragmentation can be measured using a network sniffer or by analyzing Net8 trace files.
To configure the client, set the SDU size with the SDU
parameter in a connect descriptor as follows:
net_service_name= (DESCRIPTION= (SDU=2920) (ADDRESS=...) (ADDRESS=...) (CONNECT_DATA= (SERVER_NAME=sales.us.acme.com)))
Database server configuration depends upon whether or not the database is configured to use MTS or dedicated servers.
If using MTS, set the SDU size in the MTS_DISPATCHERS
parameter as follows:
MTS_DISPATCHERS="(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp))(SDU=2920))"
Ensure the SDU size matches the value configured for the client.
If using dedicated servers for a database that is dynamically registered with the listener through service registration, then the SDU size cannot be set. Instead, the 2 KB default is used.
If using dedicated servers for a database that is registered with the listener through static configuration in the listener.ora
file, then set the SDU size in the SID_DESC
section of the listener.ora
file as follows:
SID_LIST_listener_name= (SID_LIST= (SID_DESC= (SDU=2920) (SID_NAME=sales)))
Ensure the SDU size matches the value configured for the client.
The INSTANCE_ROLE
parameter is an optional parameter for the CONNECT_DATA
section of a connect descriptor. It enables you to specify a connection to the primary or secondary instance in Oracle Parallel Server and Oracle Parallel Fail Safe primary/secondary configurations.
This parameter is useful when:
INSTANCE_ROLE
supports the following values:
primary
-- Specifies a connection to the primary instance
secondary
-- Specifies a connection to the secondary instance
any
-- Specifies a connection to whichever instance has the lowest load, regardless of primary or secondary instance role
In the following example, net service name sales_primary
enables connections to the primary instance, and net service name sales_secondary
enables connections to the secondary instance.
sales_primary= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=sales1-server) (PORT=1521)) (ADDRESS= (PROTOCOL=tcp) (HOST=sales2-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (INSTANCE_ROLE=primary))) sales_secondary= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=sales1-server) (PORT=1521)) (ADDRESS= (PROTOCOL=tcp) (HOST=sales2-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (INSTANCE_ROLE=secondary)))
There are times when Oracle Enterprise Manager and other system management products need to connect to a specific instance regardless of its role to perform administrative tasks. For these types of connections, configure (INSTANCE_NAME=
instance_name)
and (INSTANCE_ROLE=any)
to connect to the instance regardless of its role.
In the following example, net service name sales1
enables connections to the instance on sales1-server
and sales2
enables connections to the instance on sales2-server
. (SERVER=dedicated)
is specified to force a dedicated server connection.
sales1= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=sales1-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (INSTANCE_ROLE=any) (INSTANCE_NAME=sales2) (SERVER=dedicated))) sales2= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=sales2-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (INSTANCE_ROLE=any) (INSTANCE_NAME=sales2) (SERVER=dedicated)))
If Transparent Application Failover (TAF) is configured, a backup connection can be pre-established to the secondary instance. The initial and backup connections must be explicitly specified. In the following example, Net8 connects to the listener on sales1-server
and preconnects to sales2-server
, the secondary instance. If sales1-server
fails after the connection, the TAF application fails over to sales2-server
, the secondary instance, preserving any SELECT
statements in progress.
sales1.acme.com= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=sales1-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (INSTANCE_ROLE=primary) (FAILOVER_MODE= (BACKUP=sales2.acme.com) (TYPE=select) (METHOD=preconnect)))) sales2.acme.com= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=sales2-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (INSTANCE_ROLE=secondary)))
In this release of 8.1.7, the following changes affect the Oracle Names Control utility:
The Oracle Names Control utility command DOMAIN_HINT
to create a domain hint is no longer supported in this release. Instead, configure the NAMES.DOMAIN_HINTS
parameter in the names.ora
file.
A domain hint contains the name of the domain and at least one address of an Oracle Names server in that domain. This enables an Oracle Names server to forward client requests to a specific address, reducing network traffic.
It is necessary for all Oracle Names servers in delegated administrative regions to be configured with a domain hint to an Oracle Names server in the root administration region. This enables Oracle Names server to forward requests anywhere outside their own subtrees, because all name lookups can be found by forwarding through the root. If a domain hint to the root administrative region is not specified, then the local Oracle Names server may be unable to forward requests to other regions.
If you want to forward requests directly to other administrative regions, configure additional domain hints. This can ensure that clients do not have to wait for a request to be forwarded from the root administrative region. If domain hints to other administrative regions are not specified, the local Oracle Names server may go through unnecessary routing.
The local Oracle Names server will forward a client request on to whatever remote Oracle Names servers it knows, who then forward the request to the root Oracle Names server in its region. The root Oracle Names server will forward the request to the Oracle Names servers that have information on the domain that the request refers to.
To configure a domain hint, manually configure the names.ora
file with the NAMES.DOMAIN_HINTS
parameter. The syntax for this parameter follows:
NAMES.DOMAIN_HINTS= (HINT_DESC= (HINT_LIST= (HINT=(NAME=onames_server)(ADDRESS=...))) (DOMAIN_LIST= (DOMAIN=domain)))
The HINT_LIST
specifies the list of Oracle Names servers to forward the initial set of queries for the domains listed in the DOMAIN_LIST
. A hint contains the name and address of an Oracle Names server in the remote administrative region. The Oracle Names server caches the results of those queries in its memory. If the queries fail, the Oracle Names servers listed in the HINT_LIST
will not be cached and the local Oracle Names server continues to run without information about the root administrative region. The HINT_LIST
should include enough Oracle Names servers to guarantee that the local Oracle Names server can resolve the query for the root.
In the following example, NAMES.DOMAINS_HINTS
contains a domain hint for Oracle Names server rootsvr.com
that is located in the root domain of the remote administrative region. The DOMAIN
parameter is left null, meaning that the hint is for the root domain.
NAMES.DOMAIN_HINTS= (HINT_DESC= (HINT_LIST= (HINT=(NAME=rootsvr.com)(ADDRESS=(PROTOCOL=tcp)(HOST=rootsvr)(PORT=1575)))) (DOMAIN_LIST= (DOMAIN=)))
When the local Oracle Names server is started:
NAMES.DOMAIN_HINTS
parameter. For each domain listed in the DOMAIN_LIST
, it calls the Oracle Name server listed in the HINT_LIST
and queries for all Oracle Names servers in the domain.
The following example shows a hint to query two domains, the root domain and the acme.com
domain, for Oracle Names servers rootsvr1.com
and rootsvr2.com
.
NAMES.DOMAIN_HINTS= (HINT_DESC= (HINT_LIST= (HINT=(NAME=rootsvr1.com)(ADDRESS=(PROTOCOL=tcp)(HOST=sales-pc)(PORT=1575))) (HINT=(NAME=rootsvr2.com)(ADDRESS=(PROTOCOL=tcp)(HOST=hr-pc)(PORT=1575)))) (DOMAIN_LIST= (DOMAIN=) (DOMAIN=acme.com)))
In this query, the local Oracle Names server:
HINT
acme.com
domain, using the same addresses from the HINT
descriptor
Two new Oracle Names Control utility commands, REGISTER_NS
and UNREGISTER
_NS
, enable you to register and unregister an Oracle Names server as an authoritative server for a given domain. These commands replace Oracle Names server registration capabilities that were previously available with the REGISTER
and UNREGISTER
commands.
Use the REGISTER_NS
command to define an Oracle Names server and its authoritative domain.
None
No
From the operating system:
NAMESCTL REGISTER_NS {onames_server}{(ADDRESS=...)}{domain}
From Oracle Names Control utility:
NAMESCTL> REGISTER_NS {onames_server}{(ADDRESS=...)}{domain}
{
onames_server
}
--Specify the Oracle Names server name.
{(ADDRESS=...)}
--Specify the Oracle Names server protocol address.
{
domain
}
--Specify the domain name.
This command provides a mechanism for registering an Oracle Names server as an authoritative server for a given domain. The command adds a network session record type, NS.SMD
, for the Oracle Names server to the domain, and provides the Oracle Names server with an address record, A.SMD
.
This command will fail if either the domain exists and has non-NS records or the server exists and has a type of service record that is other than 'ORACLE_NAMESERVER
'.
Ordinarily, the Oracle Names servers will maintain their own data by registering themselves when they start. This command is provided as a manual way to manage domain and Oracle Names server data if for some reason the Oracle Names server cannot. This may occur if the region database tables are set up as read-only for security reasons.
If the Oracle Names servers are not registering themselves, this command should be used to define the region topology data. Each Oracle Names server in the region should be defined using this command for each top-level domain in the region. Usually, the top level consists of a single parent domain, for example, acme.com
. However, a region may also have multiple sibling parent domains, for example, a region covering North America would have US, CA, and MX as its top-level parent domains.
Note the regions which were defined using the Oracle Network Manager in SQL*Net version 2 have NS.SMD
records defined for every domain in the administrative region, but in Net8 only the top-level parent domains need to have NS.SMD
records defined for each server in the region.
Use the Oracle Names Control utility DELEGATE DOMAIN
command to define Oracle Names servers which are delegation points for subregions.
Use the NAMES.DOMAIN_HINTS
parameter in the names.ora
file to provide data about any other Oracle Names servers in foreign regions.
NAMESCTL> REGISTER_NS namesrv1 (ADDRESS=(PROTOCOL=tcp)(HOST=namesvr)(PORT=1575)) Total response time: 7 minutes 59.14 seconds Response status: normal, successful completion
Use the UNREGISTER_NS
command to undefine an Oracle Names server and its authoritative domain.
None
No
From the operating system:
NAMESCTL UNREGISTER_NS {onames_server}{(ADDRESS=...)}{domain}
From Oracle Names Control utility:
NAMESCTL> UNREGISTER_NS {onames_server}{(ADDRESS=...)}{domain}
{
onames_server
}
--Specify the Oracle Names server name.
{(ADDRESS=...)}
--Specify the Oracle Names server protocol address.
{
domain
}
--Specify the domain name.
This command provides a mechanism for unregistering an Oracle Names server as an authoritative server for a given domain. This command removes the NS.SMD
record for the Oracle Names from the domain, and deletes the Oracle Names server and its A.SMD
address record.
This command will fail if either the domain exists and has non-NS records or the server exists and has a type of service record that is other than 'ORACLE_NAMESERVER
'.
Ordinarily, the Oracle Names servers will maintain their own data by registering themselves when they start. This command is provided as a manual way to manage domain and Oracle Names server data if for some reason the Oracle Names server cannot. This can occur if the region database tables are set up as read-only for security reasons.
If the Oracle Names servers are not registering themselves, this command should be used to define the region topology data. Each Oracle Names server in the region should be defined using this command for each top-level domain in the region. Usually, the top level consists of a single parent domain, for example, acme.com
. However, a region may also have multiple sibling parent domains, for example, a region covering North America would have US, CA and MX as its top-level parent domains.
Note the regions which were defined using the Oracle Network Manager in SQL*Net version 2 have NS.SMD
records defined for every domain in the administrative region, but in Net8 only the top-level parent domains need to have NS.SMD
records defined for each server in the region.
NAMESCTL> UNREGISTER_NS namesrv1 (ADDRESS=(PROTOCOL=tcp)(HOST=namesvr)(PORT=1575)) Total response time: 7 minutes 59.14 seconds Response status: normal, successful completion
|
![]() Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|