1. Networking Overview
1. Identify networking business trends
Is it necessary to illustrate ? In a Nutshell:Client-Server
2. Describe Oracle networking solutions
Oracle networking environments are based on two concepts:
Distributed Processing: Client and servers exist as separate logical entities on separate physical machines. This configuration allows for the division of labor where resources are allocated efficiently between a client workstation and the server machine.
Stack Communications: The concept of distributed processing relies on the ability of computers separated by both design and physical location to communicate and interact with each other. This is accomplished through a process known as stack communications. The layers in a typical Oracle communications stack are similar to those of a standard OSI communications stack
In an Oracle client-server transaction, information passes through the following layers:
1. Client Application: Provide all user-orientated activities, such as character or graphical user display, screen control, data presentation, application flow, and other application specifics. The application identifies database operations to send the server and passes them through the Oracle Call Interface (OCI).
2. Oracle Call Interfaca (OCI): The OCI code contains all the information required to initiate a SQL dialogue between the client and the server. It defines calls to the server to: parse SQL statements for syntax validations, open a cursor for the SQL statement, bind client application variables into the server shared memory, describe the contents of the fields being returned based on the values in the servers data dictionary, execute SQL statements within the cursor memory space,fetch one or more rows of data into the client application,close the cursor.
The client application uses a combination of these calls to request activity within the server. OCI calls can be combined into a single message to the server, or they may be processed one at a time through multiple messages to the server, depending on the nature of the client application. Oracle products attempt to minimize the number of messages sent to the server be combining many OCI calls into a single message to the server. When a call is performed, control is passed to Net8 to establish the connection and transmit the request to the server.
3. Two Task Common : Provides character set and data type conversion between different character sets or formats on the client and the server. This layer is optimized to perform conversion only when required on a per connection basis. At the time of connection, it is reponsible for evaluating differences in internal data and charactet set representations and determining wheter conversions are required for the two computers to communicate.
4. Net8 : Provides all session layer functionality in an Oracle communications stack. It is responsible for establishing and maintaining the connection between a client application and a server, as well as exchanging massages between them. Net8 itself has three component layers that facilitate session layer functionality :
1. Network Interface (NI)- This layer provides a generic interface for Oracle clients, servers, or external processes to access Net8 functions. The NI handles the "break" and "reset" requests for a connection.
2. Network Routing (NR)/Network Naming(NN)/Network Authentication(NA) - NR provides routing of the session to the destination. This may include any intermediary destination or 'hops', on the route to the server destination. NN resolves aliases to a Net8 destination address. NA negotiates any authentication requirement with the destination.
3. Transparent Network Substrat (TNS)- TNS is an underlying layer of Net8 providing a common interface to industry standard protocols. TNS receives requests from Net8, and settlles all generic machine-level connectivity issues, such as: the location of the server or destination ( open, close functions); wheter one or more protocols will be involved in the connection ( open,close functions); and how to handle interrupts between client and server based on the capabilities of each ( send, receive functions). The generic set of TNS functions ( open , close, send, receive) passes control to an Oracle Protocol Adapter to make a protocol-specific call. Additionally, TNS supports encryption and sequenced cryptographic message digests to protect data in transit.
5. Oracle Protocol Adapters : Are responsible for mapping TNS functionality to industry-standard protocols used in the client-server connection. Each adapter is responible for mapping the equivalent functions between TNS and specific protocol
6. Network Specific Protocols: All Oracle client-server connection require an existing network protocol stack to make the machine-level connection between the two machines. The network protocol is responsible only for getting the data from the client machine to the server machine, at which point the data is passed to the server-side Oracle Protocol Adapter
7. Server side Interaction : The following components above the Net8 session layer are different from those on the client side:
8. Oracle Program Interface (OPI) : It performs a complementary function to that of the OCI. It is reponsible for responding to each of the possible messages sent by the OCI.e.g., an OCI request to fetch 25 rows would have an OPI reponse to return the 25 rows once they have been fetched.
9. Oracle Server : The Oracle Server side of the connection is responsible for receiving dialog requests from the client OCI code and resolving SQL statments on behalf of the client application. Once received, a request is processed and the resulting data is passed to the OPI for responses to be formatted and returned to the client applciation.
10. Server to Server Interaction : When two servers communicate to complete a distributed transaction, the process, layers, and dialogues are the same as in the client-server scenarion, except that there is no client application. The server has its own version of OCI, called the Network Program Interface (NPI). The NPI interface performs all of the functions that the OCI does for clients, allowing a coordinating server to contruct SQL requests for additional servers.
2. Basic Net8 Architecture
1. Define the procedure by which Net 8 establishes a server connection
2. Identify the key components of Net 8 architecture and their interaction
Net8 uses the Transparent Network Substrate (TNS) and industry-standard networking protocols to connect a client to a server and establish an Oracle session. Net8 is responsible for enabling communications between the cooperating partners in an Oracle distributed transaction, wheter they be client-server or server. Specificaly Net 8 provide 3 basic networking operations:
1. Connection Operations
1. Connecting to Servers (open): Users initiate a connect request by passing information such as username and password along with a short name for the database service that they wish to connect(this is in tnsnames.ora) . This short name, called a service name , is mapped to a network address contained in a connect descriptor . Depending on the network configuration this descriptor may be stored in:
1. A local configuration file named TNSNAMES.ORA
2. A Name server for use by Oracle Names
3. A native naming server such as NIS or DCE CDS
Net8 coordinates its sessions with the help of network listener
2. Bequeath the session to a new dedicated server process
If the listener and server exist on the same node, the listener may create or 'spawn' dedicated server processes as connect requests are receive. Dedicated server processes are commited to one session only and exist for the duration of that session. The sequence of events is
1. The listener is started and listenes on an address specified in a listener configuration file (LISTENER.ORA)
2. A client connects to the listener with the network address
3. The listener receives the session request, and determines if the client's request may be serviced. If not, the listener refuses the session.The listener continues listening for incoming connections
4. The listener spawns a new dedicated server process to serve the incoming session, and bequeaths the session to that server proces. Once the session is established, data flows directly between the client and dedicated server process.
5. The listener continues listening for incoming connections
When a client disconnects, the dedicated server processes associated with the client closes.
3. Redirect to an existing server process ( such as a dispatcher or prestarted dedicated server process)
It does this by sending the address of an exisiting server process back to the client. The client will then resend its connect request to the server address provided,there are two options:
1. Prespawned Dedicated Server Process: This option automatically creates a dedicated server processes before the request is received. These processes last for the life of the listener, and can be reused by subsequent connection requests. The use of prespawned dedicated server processes requires specification in a listener configuration files. The events that take place are:
1. The listener is started and listens on an address specified in a listener configuration file.
2. The listener then spawns a series of dedicated server processes until it reaches the specified pool size for each SID defined in its config file.
3. Each spawned server process performs a partial address listen and provides the listener with a partial address that it is listening on. The listener initially marks all prespawned servers as idle.NOTE: A partial address listener is where the server process listenes, but informs the underlying protocol stack that it has no preference as to the specific address it will listen on. As a result, many protocol stacks will choose a free listening address and automatically assing this to the requesting server process.
4. The client send a connect request to the listener.
5. The listener receives the session request, and determines if the clients request may be serviced. If not, the listener refuses the session.
6. The listener issues a redirect message to the client containing one of the network addresses of the prespawned servers. The listener logs that server as active.
7. The client dissolves the session to the listener and establishes a session to the prespawned server using the address provided in the redirect message.
8. The listener spawns another server process to replace the active prespawned server (provided a value called PRESPAWN_MAX in the listener config. file is grater than the number of prespawned server processes active and idle)
9. The listner continues listening for incoming sessions.
2. Dispatcher Server Processes :A dispatcher server processes enables many clients to connect to the same server without the need for a dedicated server processes for each client. It does this with the help of a dispatcher which handles and directs multiple incoming session request to the shared server.
When an Oracle server has been configured as multi-thereaded server, incoming sessions are always routed to the dispatcher unless either the session specifically requests a dedicated server or no dispatchers are available. The sequence of events is as follows:
1. The listener is started and listens on either a default address or the addresses specified in its configuration file
2. A database instance starts. Dispatchers start according to the configuration parameters in the initialization file. Each dispatcher then performs a listen on the address assigned to it.
3. Each dispatchers address is registered. When the listener is not listening on its default address, the listener netowork name may be specified in the database init.ora file. The name may resolve to more than one such address if multiple listeners are used.
Once the dispatchers addresses are registered, the listener can redirect incoming connect request to them. If step 2 is performed before step 1, the dispatchers will not be able to contact the listener in step 3. If this occurs, there may be a delay as the dispatcher attempts to contact the listener. If a connect request comes in a timeframe where no dispatchers are registered, these requests may be handled through prespawned dedicated or newly spawned dedicated server processes or be rejected.
4. The listener and the Oracle dispatcher server are now ready to receive incoming sessions.
5. Once the listener and the dispatcher server have been started, the session activity continues as follows:
6. The client connects to the listener with the network address
7. The listener receives the connect request, and ddetermines if the clients request may be serviced. If not, the listener refueses the session.
8. The listener issues a redirect message to the client containing the network address of the least-used dispatcher for the shared server.
9. The client dissolves the session to the listener and establishes a sesion to the shared server using the network address provided in the redirect message.
10. The dispatcher updates the listener with the new load value because of the presence of the new session.
This allows the listener to balance the incoming session requests between dispatchers on the same protocol
11. The listener resumes listening for incoming sessions.
4. Refuse the session: The network listener will refuse a session in the event that it does not know about the server being requested, or if the server is unavailable. It refuses the session by generating and sending a refuse response packet back to the client.
2. Data Operations: Net8 supports four sets of client-server data operations:
1. Send data synchronously
2. Receive data synchronously
3. Send data asynchronously
4. Receive data asynchronously
Basic send and receive requests are synchornous. When a client initiates a request, it waits for the server to respond with the answer. It can then issue an additional request. The asynchronous capability to send and receive data requests asynchronously, was added to support Oracle shared server(Multithreaded-Server), which requires asynchronous calls to service incoming request from multiple clients.
3. Exception Operations:Net8 supports three type of exception operations:
1. Initiate a break over the connection
2. Reset a connection for synchronization
3. Test the condition of the connection for incoming break
The user control only one of these operations, that is, the initiation of a break, with de CTRL-C command. Additionaly the database can initiate a break to the client if an abnormal operation occurs, such as during an attempt to load a row of invalid data using SQL*Loader.
The other two excptions operations are internal to products that use Net8 to resolve network timing issues. Net8 can initiate a test of the communication channel, for example, to see if new data has arrived. The reset function is used to resolve abnormal states, such as getting the connection back in synchronization after a break operation has occurred.
3. Basic Net 8 Server-Side Configuration
1. Describe the listener process
The network listener is a single process or task setup specifically to receive connection requests on behalf of an application. Listeners are configured to "listen on" an address specified in a listener configuration file (listener.ora) for a database or a non-database service. Once started the listener will receive client connect requests on behalf of a service, and respond in one of three ways.
2. Configure the listener
3. Start the Net 8 listener using the Listener Control Utility (LSNRCTL)
4. Stop the Net 8 listener using the Listener Control Utility (LSNRCTL)
5. Identify additional LSNRCTL commands
SERVICES : Displays which dispatchers have registered with the listener.
4. Basic Net8 Client-side configuration
1. Establish the connection from the Net 8 client side using the host named method
2. Configure Net 8 client-side files and connect using the local naming method
3. Define preferences on the client side
4. Configure Net8 client to use the client load balancing and failover feature.
1. Connection Pooling : It is a resource utilization feature that allows you to maximize the number of physical network connections to a multi-threaded server. This is achieved by sharing or pooling a dispatchers set of connections among multiple client processes . By using a time-out mechanism to temporarily release transport connection that have been idle for a specified period of time, connection pooling makes these physical connections available for incoming clients, while still maintaining a logical session with the previous idle connection. When the the idle client has more work to do, the physical connection is reestablished with the dispatcher.Connect pooling is enabled by parameters in init.ora
2. Connection Concetration : This feature is availabel through Oracle Connection Manager, it allows you to take advantage of Net8's ability to multiplex or funnel multiple client sessions over a single transport to a multithreded server. Like connection pooling, concentration optimizes network resources and increses the number of client-server sessions that are possible across a fixed number of physical server ports. Unlike connection pooling, concentration maintains the transport connection.
4. Centralized Naming Concepts
1. Define the Names server Concept
2. Identify the various names resolution methods
Net8 provides four naming methods :
1. Host Naming: Oracle resolves service names using their existing name resolution service, the name resolution service might be DNS,NIS, or simply a centrally-maintained set of /etc/hosts files. It allows users to connect to an Oracle server simply by using the server computers host name alias. No client configuration is required to take adavantage of this feature. The connection is established by using the default TCP/IP port for the listener (1521). Host naming can eliminate the need for a local naming configuration file (TNSNAMES.ORA) in environments where simple database connectivity is desired. However it is recommended for complex environments where features like connection pooling, heterogeneous services or application failover will be used.
Steps using Host Naming Option
1. The client initiates a connect request providing a service name which is also a TCP/IP hostname or alias
2. A host naming adapter resolves this service name by generating a network address using the service name as both the TCP/IP hostname and the global database name. The port defaults to 1521.
3. Net8 makes the connect request to the address created.
4. A network listener, listening at registered TCP/IP port 1521, receives the request and establishes a connection to the database with a matching global database name as specified in the listeners configuration
5. The connection is accepted by the server
Host naming is used as a naming method by default, it will be used in the absence of a local naming configuration file and Names server.
2. Local Naming : Is the method for resolving a service name to a network address by using information configured on each individual client. Much like an address book, this information is entered in a local naming configuration file called TNSNAMES.ORA . The process for establishing a connection is:
1. The client initiates a connect request providing a service name
2. The service name is resolved to a network address configured in a local naming file
3. Net8 makes the connect request to the address provided
4. A network listener receives the request and directs it to the database it is servicing
5. The connection is accepted by the server.
To configure:
1. Verify that "TNSNAMES" is listed in the field of selected naming methods in the client profile.If it is not, use the Oracle Net8 Assistant to edit the profile.
2. Verify that service names are correctly mapped to their appropriate network address in a local naming configuration file (TNSNAMES.ORA).
3. Centralized Naming using Oracle Names : Oracle names uses Name Servers to store the names and addresses of all database services on the network.Name Servers resolve the service name to a network address and return that information to the client. The process is as follows:
1. The client initiates a connect request providing a service name
2. The connect request is forwarded to a Names Server where the service name is resolved to a network address. This address is returned to the client.
3. Net8 makes the connect request to the address provided
4. A network listener receives the request and redirects it to the database it is servicing
5. The connection is accepted by the server
To configure :
1. Verify that "ONAMES" is listed in the field of selected naming methods in your profile.
2. Verify that a Names Server exists and is running on the network.
4. External Naming.: This method refers to resolving a service name to a network address by using supported non-Oracle naming service. Oracle Native Naming Adapters resolve service names stored in customers native (non-Oracle) naming services. They include: Network Information Service (NIS) and Netware Directory Services (NDS). To establish a connection :
1. The client initiates a connect request providing a service name.
2. A native adapter forwards the request to a native naming system that resolves the service name to a netowork address. The address is returned to the client.
3. Net8 makes the connect request to the address provided.
4. A network listener receives the request and redirects it to the database it is servicing.
5. The connection is accepted by the server
To configure External Naming:
1. Verify that the applicable Native Naming Adapter has been installed on the client node.
2. Specify the use of an external naming adapter ( CDS, NDS,NIS) in your profile.
Oracle Names and Native Naming Adapters Oracle Names can be used in conjunction with other propietary or open naming services to provide cross-environment name resolution. e.g. Oracle Native Naming Adapters for CDS/DCE, NIS or NDS could be installed on all clients and servers in an enterprise network already running Oracle to provide name resolution accross multiple name services. Since Oracle Names is a proprietary name service storing and resolving names and addresses for Oracle database only, one names solution could be to store all your Oracle services in Oracle Names, and use a directory service such as DNS or X.500 as your global naming service.
3. Identify the benefits of a Names server
4. Define the Administration obejcts used in a Names server Environment
5. Define the naming methods
5. Oracle Names Usage and Configuration
1. Configure Centralized Naming
2. Store the Network configuration in the client cache
3. Store the Network configuration in the region database
4. Start and stop the Names server using the Names Control Utility
6. Multithreaded Server Usage and Configuration
1. Identify the components of the multithreaded server (MTS)
2. Configure dispatachers using init.ora
3. Configure shared server using init.ora
4. Specify the listener address for multithreaded server
5. Set up connection pooling using the multithreaded server
7. Connection Manager and Configuration
1. Identify the capabilities of Connection Manager
2. Configure Connection concentration
3. Enable network access control
4. Configure Multiprotocol interchange
8. Troubleshooting and Network Environment
1. Follow a troubleshooting checklist
2. Use the TNSPING utility
3. Configure the logging and tracing with Net 8 assistant
4. Use the listener audit trail
5. Interpret logging and tracing components
9. Security in the Network Environment
1. Identify network security risks during data transmission
2. Identify security features in Oracle Networking products
3. Identify the features of the Advanced Security Option
4. Configure the components of the Advanced Securiy Option
1. Identify networking business trends
Is it necessary to illustrate ? In a Nutshell:Client-Server
2. Describe Oracle networking solutions
Oracle networking environments are based on two concepts:
Distributed Processing: Client and servers exist as separate logical entities on separate physical machines. This configuration allows for the division of labor where resources are allocated efficiently between a client workstation and the server machine.
Stack Communications: The concept of distributed processing relies on the ability of computers separated by both design and physical location to communicate and interact with each other. This is accomplished through a process known as stack communications. The layers in a typical Oracle communications stack are similar to those of a standard OSI communications stack
In an Oracle client-server transaction, information passes through the following layers:
1. Client Application: Provide all user-orientated activities, such as character or graphical user display, screen control, data presentation, application flow, and other application specifics. The application identifies database operations to send the server and passes them through the Oracle Call Interface (OCI).
2. Oracle Call Interfaca (OCI): The OCI code contains all the information required to initiate a SQL dialogue between the client and the server. It defines calls to the server to: parse SQL statements for syntax validations, open a cursor for the SQL statement, bind client application variables into the server shared memory, describe the contents of the fields being returned based on the values in the servers data dictionary, execute SQL statements within the cursor memory space,fetch one or more rows of data into the client application,close the cursor.
The client application uses a combination of these calls to request activity within the server. OCI calls can be combined into a single message to the server, or they may be processed one at a time through multiple messages to the server, depending on the nature of the client application. Oracle products attempt to minimize the number of messages sent to the server be combining many OCI calls into a single message to the server. When a call is performed, control is passed to Net8 to establish the connection and transmit the request to the server.
3. Two Task Common : Provides character set and data type conversion between different character sets or formats on the client and the server. This layer is optimized to perform conversion only when required on a per connection basis. At the time of connection, it is reponsible for evaluating differences in internal data and charactet set representations and determining wheter conversions are required for the two computers to communicate.
4. Net8 : Provides all session layer functionality in an Oracle communications stack. It is responsible for establishing and maintaining the connection between a client application and a server, as well as exchanging massages between them. Net8 itself has three component layers that facilitate session layer functionality :
1. Network Interface (NI)- This layer provides a generic interface for Oracle clients, servers, or external processes to access Net8 functions. The NI handles the "break" and "reset" requests for a connection.
2. Network Routing (NR)/Network Naming(NN)/Network Authentication(NA) - NR provides routing of the session to the destination. This may include any intermediary destination or 'hops', on the route to the server destination. NN resolves aliases to a Net8 destination address. NA negotiates any authentication requirement with the destination.
3. Transparent Network Substrat (TNS)- TNS is an underlying layer of Net8 providing a common interface to industry standard protocols. TNS receives requests from Net8, and settlles all generic machine-level connectivity issues, such as: the location of the server or destination ( open, close functions); wheter one or more protocols will be involved in the connection ( open,close functions); and how to handle interrupts between client and server based on the capabilities of each ( send, receive functions). The generic set of TNS functions ( open , close, send, receive) passes control to an Oracle Protocol Adapter to make a protocol-specific call. Additionally, TNS supports encryption and sequenced cryptographic message digests to protect data in transit.
5. Oracle Protocol Adapters : Are responsible for mapping TNS functionality to industry-standard protocols used in the client-server connection. Each adapter is responible for mapping the equivalent functions between TNS and specific protocol
6. Network Specific Protocols: All Oracle client-server connection require an existing network protocol stack to make the machine-level connection between the two machines. The network protocol is responsible only for getting the data from the client machine to the server machine, at which point the data is passed to the server-side Oracle Protocol Adapter
7. Server side Interaction : The following components above the Net8 session layer are different from those on the client side:
8. Oracle Program Interface (OPI) : It performs a complementary function to that of the OCI. It is reponsible for responding to each of the possible messages sent by the OCI.e.g., an OCI request to fetch 25 rows would have an OPI reponse to return the 25 rows once they have been fetched.
9. Oracle Server : The Oracle Server side of the connection is responsible for receiving dialog requests from the client OCI code and resolving SQL statments on behalf of the client application. Once received, a request is processed and the resulting data is passed to the OPI for responses to be formatted and returned to the client applciation.
10. Server to Server Interaction : When two servers communicate to complete a distributed transaction, the process, layers, and dialogues are the same as in the client-server scenarion, except that there is no client application. The server has its own version of OCI, called the Network Program Interface (NPI). The NPI interface performs all of the functions that the OCI does for clients, allowing a coordinating server to contruct SQL requests for additional servers.
2. Basic Net8 Architecture
1. Define the procedure by which Net 8 establishes a server connection
2. Identify the key components of Net 8 architecture and their interaction
Net8 uses the Transparent Network Substrate (TNS) and industry-standard networking protocols to connect a client to a server and establish an Oracle session. Net8 is responsible for enabling communications between the cooperating partners in an Oracle distributed transaction, wheter they be client-server or server. Specificaly Net 8 provide 3 basic networking operations:
1. Connection Operations
1. Connecting to Servers (open): Users initiate a connect request by passing information such as username and password along with a short name for the database service that they wish to connect(this is in tnsnames.ora) . This short name, called a service name , is mapped to a network address contained in a connect descriptor . Depending on the network configuration this descriptor may be stored in:
1. A local configuration file named TNSNAMES.ORA
2. A Name server for use by Oracle Names
3. A native naming server such as NIS or DCE CDS
Net8 coordinates its sessions with the help of network listener
2. Bequeath the session to a new dedicated server process
If the listener and server exist on the same node, the listener may create or 'spawn' dedicated server processes as connect requests are receive. Dedicated server processes are commited to one session only and exist for the duration of that session. The sequence of events is
1. The listener is started and listenes on an address specified in a listener configuration file (LISTENER.ORA)
2. A client connects to the listener with the network address
3. The listener receives the session request, and determines if the client's request may be serviced. If not, the listener refuses the session.The listener continues listening for incoming connections
4. The listener spawns a new dedicated server process to serve the incoming session, and bequeaths the session to that server proces. Once the session is established, data flows directly between the client and dedicated server process.
5. The listener continues listening for incoming connections
When a client disconnects, the dedicated server processes associated with the client closes.
3. Redirect to an existing server process ( such as a dispatcher or prestarted dedicated server process)
It does this by sending the address of an exisiting server process back to the client. The client will then resend its connect request to the server address provided,there are two options:
1. Prespawned Dedicated Server Process: This option automatically creates a dedicated server processes before the request is received. These processes last for the life of the listener, and can be reused by subsequent connection requests. The use of prespawned dedicated server processes requires specification in a listener configuration files. The events that take place are:
1. The listener is started and listens on an address specified in a listener configuration file.
2. The listener then spawns a series of dedicated server processes until it reaches the specified pool size for each SID defined in its config file.
3. Each spawned server process performs a partial address listen and provides the listener with a partial address that it is listening on. The listener initially marks all prespawned servers as idle.NOTE: A partial address listener is where the server process listenes, but informs the underlying protocol stack that it has no preference as to the specific address it will listen on. As a result, many protocol stacks will choose a free listening address and automatically assing this to the requesting server process.
4. The client send a connect request to the listener.
5. The listener receives the session request, and determines if the clients request may be serviced. If not, the listener refuses the session.
6. The listener issues a redirect message to the client containing one of the network addresses of the prespawned servers. The listener logs that server as active.
7. The client dissolves the session to the listener and establishes a session to the prespawned server using the address provided in the redirect message.
8. The listener spawns another server process to replace the active prespawned server (provided a value called PRESPAWN_MAX in the listener config. file is grater than the number of prespawned server processes active and idle)
9. The listner continues listening for incoming sessions.
2. Dispatcher Server Processes :A dispatcher server processes enables many clients to connect to the same server without the need for a dedicated server processes for each client. It does this with the help of a dispatcher which handles and directs multiple incoming session request to the shared server.
When an Oracle server has been configured as multi-thereaded server, incoming sessions are always routed to the dispatcher unless either the session specifically requests a dedicated server or no dispatchers are available. The sequence of events is as follows:
1. The listener is started and listens on either a default address or the addresses specified in its configuration file
2. A database instance starts. Dispatchers start according to the configuration parameters in the initialization file. Each dispatcher then performs a listen on the address assigned to it.
3. Each dispatchers address is registered. When the listener is not listening on its default address, the listener netowork name may be specified in the database init.ora file. The name may resolve to more than one such address if multiple listeners are used.
Once the dispatchers addresses are registered, the listener can redirect incoming connect request to them. If step 2 is performed before step 1, the dispatchers will not be able to contact the listener in step 3. If this occurs, there may be a delay as the dispatcher attempts to contact the listener. If a connect request comes in a timeframe where no dispatchers are registered, these requests may be handled through prespawned dedicated or newly spawned dedicated server processes or be rejected.
4. The listener and the Oracle dispatcher server are now ready to receive incoming sessions.
5. Once the listener and the dispatcher server have been started, the session activity continues as follows:
6. The client connects to the listener with the network address
7. The listener receives the connect request, and ddetermines if the clients request may be serviced. If not, the listener refueses the session.
8. The listener issues a redirect message to the client containing the network address of the least-used dispatcher for the shared server.
9. The client dissolves the session to the listener and establishes a sesion to the shared server using the network address provided in the redirect message.
10. The dispatcher updates the listener with the new load value because of the presence of the new session.
This allows the listener to balance the incoming session requests between dispatchers on the same protocol
11. The listener resumes listening for incoming sessions.
4. Refuse the session: The network listener will refuse a session in the event that it does not know about the server being requested, or if the server is unavailable. It refuses the session by generating and sending a refuse response packet back to the client.
2. Data Operations: Net8 supports four sets of client-server data operations:
1. Send data synchronously
2. Receive data synchronously
3. Send data asynchronously
4. Receive data asynchronously
Basic send and receive requests are synchornous. When a client initiates a request, it waits for the server to respond with the answer. It can then issue an additional request. The asynchronous capability to send and receive data requests asynchronously, was added to support Oracle shared server(Multithreaded-Server), which requires asynchronous calls to service incoming request from multiple clients.
3. Exception Operations:Net8 supports three type of exception operations:
1. Initiate a break over the connection
2. Reset a connection for synchronization
3. Test the condition of the connection for incoming break
The user control only one of these operations, that is, the initiation of a break, with de CTRL-C command. Additionaly the database can initiate a break to the client if an abnormal operation occurs, such as during an attempt to load a row of invalid data using SQL*Loader.
The other two excptions operations are internal to products that use Net8 to resolve network timing issues. Net8 can initiate a test of the communication channel, for example, to see if new data has arrived. The reset function is used to resolve abnormal states, such as getting the connection back in synchronization after a break operation has occurred.
3. Basic Net 8 Server-Side Configuration
1. Describe the listener process
The network listener is a single process or task setup specifically to receive connection requests on behalf of an application. Listeners are configured to "listen on" an address specified in a listener configuration file (listener.ora) for a database or a non-database service. Once started the listener will receive client connect requests on behalf of a service, and respond in one of three ways.
2. Configure the listener
3. Start the Net 8 listener using the Listener Control Utility (LSNRCTL)
4. Stop the Net 8 listener using the Listener Control Utility (LSNRCTL)
5. Identify additional LSNRCTL commands
SERVICES : Displays which dispatchers have registered with the listener.
4. Basic Net8 Client-side configuration
1. Establish the connection from the Net 8 client side using the host named method
2. Configure Net 8 client-side files and connect using the local naming method
3. Define preferences on the client side
4. Configure Net8 client to use the client load balancing and failover feature.
1. Connection Pooling : It is a resource utilization feature that allows you to maximize the number of physical network connections to a multi-threaded server. This is achieved by sharing or pooling a dispatchers set of connections among multiple client processes . By using a time-out mechanism to temporarily release transport connection that have been idle for a specified period of time, connection pooling makes these physical connections available for incoming clients, while still maintaining a logical session with the previous idle connection. When the the idle client has more work to do, the physical connection is reestablished with the dispatcher.Connect pooling is enabled by parameters in init.ora
2. Connection Concetration : This feature is availabel through Oracle Connection Manager, it allows you to take advantage of Net8's ability to multiplex or funnel multiple client sessions over a single transport to a multithreded server. Like connection pooling, concentration optimizes network resources and increses the number of client-server sessions that are possible across a fixed number of physical server ports. Unlike connection pooling, concentration maintains the transport connection.
4. Centralized Naming Concepts
1. Define the Names server Concept
2. Identify the various names resolution methods
Net8 provides four naming methods :
1. Host Naming: Oracle resolves service names using their existing name resolution service, the name resolution service might be DNS,NIS, or simply a centrally-maintained set of /etc/hosts files. It allows users to connect to an Oracle server simply by using the server computers host name alias. No client configuration is required to take adavantage of this feature. The connection is established by using the default TCP/IP port for the listener (1521). Host naming can eliminate the need for a local naming configuration file (TNSNAMES.ORA) in environments where simple database connectivity is desired. However it is recommended for complex environments where features like connection pooling, heterogeneous services or application failover will be used.
Steps using Host Naming Option
1. The client initiates a connect request providing a service name which is also a TCP/IP hostname or alias
2. A host naming adapter resolves this service name by generating a network address using the service name as both the TCP/IP hostname and the global database name. The port defaults to 1521.
3. Net8 makes the connect request to the address created.
4. A network listener, listening at registered TCP/IP port 1521, receives the request and establishes a connection to the database with a matching global database name as specified in the listeners configuration
5. The connection is accepted by the server
Host naming is used as a naming method by default, it will be used in the absence of a local naming configuration file and Names server.
2. Local Naming : Is the method for resolving a service name to a network address by using information configured on each individual client. Much like an address book, this information is entered in a local naming configuration file called TNSNAMES.ORA . The process for establishing a connection is:
1. The client initiates a connect request providing a service name
2. The service name is resolved to a network address configured in a local naming file
3. Net8 makes the connect request to the address provided
4. A network listener receives the request and directs it to the database it is servicing
5. The connection is accepted by the server.
To configure:
1. Verify that "TNSNAMES" is listed in the field of selected naming methods in the client profile.If it is not, use the Oracle Net8 Assistant to edit the profile.
2. Verify that service names are correctly mapped to their appropriate network address in a local naming configuration file (TNSNAMES.ORA).
3. Centralized Naming using Oracle Names : Oracle names uses Name Servers to store the names and addresses of all database services on the network.Name Servers resolve the service name to a network address and return that information to the client. The process is as follows:
1. The client initiates a connect request providing a service name
2. The connect request is forwarded to a Names Server where the service name is resolved to a network address. This address is returned to the client.
3. Net8 makes the connect request to the address provided
4. A network listener receives the request and redirects it to the database it is servicing
5. The connection is accepted by the server
To configure :
1. Verify that "ONAMES" is listed in the field of selected naming methods in your profile.
2. Verify that a Names Server exists and is running on the network.
4. External Naming.: This method refers to resolving a service name to a network address by using supported non-Oracle naming service. Oracle Native Naming Adapters resolve service names stored in customers native (non-Oracle) naming services. They include: Network Information Service (NIS) and Netware Directory Services (NDS). To establish a connection :
1. The client initiates a connect request providing a service name.
2. A native adapter forwards the request to a native naming system that resolves the service name to a netowork address. The address is returned to the client.
3. Net8 makes the connect request to the address provided.
4. A network listener receives the request and redirects it to the database it is servicing.
5. The connection is accepted by the server
To configure External Naming:
1. Verify that the applicable Native Naming Adapter has been installed on the client node.
2. Specify the use of an external naming adapter ( CDS, NDS,NIS) in your profile.
Oracle Names and Native Naming Adapters Oracle Names can be used in conjunction with other propietary or open naming services to provide cross-environment name resolution. e.g. Oracle Native Naming Adapters for CDS/DCE, NIS or NDS could be installed on all clients and servers in an enterprise network already running Oracle to provide name resolution accross multiple name services. Since Oracle Names is a proprietary name service storing and resolving names and addresses for Oracle database only, one names solution could be to store all your Oracle services in Oracle Names, and use a directory service such as DNS or X.500 as your global naming service.
3. Identify the benefits of a Names server
4. Define the Administration obejcts used in a Names server Environment
5. Define the naming methods
5. Oracle Names Usage and Configuration
1. Configure Centralized Naming
2. Store the Network configuration in the client cache
3. Store the Network configuration in the region database
4. Start and stop the Names server using the Names Control Utility
6. Multithreaded Server Usage and Configuration
1. Identify the components of the multithreaded server (MTS)
2. Configure dispatachers using init.ora
3. Configure shared server using init.ora
4. Specify the listener address for multithreaded server
5. Set up connection pooling using the multithreaded server
7. Connection Manager and Configuration
1. Identify the capabilities of Connection Manager
2. Configure Connection concentration
3. Enable network access control
4. Configure Multiprotocol interchange
8. Troubleshooting and Network Environment
1. Follow a troubleshooting checklist
2. Use the TNSPING utility
3. Configure the logging and tracing with Net 8 assistant
4. Use the listener audit trail
5. Interpret logging and tracing components
9. Security in the Network Environment
1. Identify network security risks during data transmission
2. Identify security features in Oracle Networking products
3. Identify the features of the Advanced Security Option
4. Configure the components of the Advanced Securiy Option
Comentarios