Access to Network Services in Oracle Database - Oracle DBA

What is a listener?
Listener is a process that resides on the Oracle server whose responsibility is to listen for incoming client connection requests and manage the traffic to the server.

- By default, the listener name is (amazingly enough) “listener” (but you can call it anything you like). It listens for connection requests on a particular port (the default port number in 8.0 and above is 1521, but once again, you can set this to any valid port number if you wish). A client knows where to contact the listener (the machine it’s running on, and the port it’s listening on) because a local configuration file, called “tnsnames.ora”, gives it the necessary information. More advanced configurations can dispense with the tnsnames.ora (for example, you can opt to install a “names server”, which does the same job of telling the client where to find the listener).

- Upon receiving a connection request from a client, the listener can do one of two things. Either it will spawn a new server process, and redirect the client to talk directly to that server process… at which point, the listener drops out of the picture altogether, and continues to listen for connection requests from other clients. This is known as ‘bequeathing’ the server process to the client, in the sense of ‘making a gift’ –and the client is then said to have a bequeath session.

- Or it will inform the client of the network address of a server process which has already been created when the instance was started (a “pre-spawned server process), and the client is then able to make direct contact with that server process. Note again, however, that once the connection is established between the client and the server process, the listener simply continues to listen for new connection requests. This is known as ‘redirecting’ the client to the server process, and hence the client is said to have a redirect session. The only real difference between bequeath and redirect sessions is that, in theory, it takes longer to set up a bequeath session (the server process has to be created from scratch, for a start). However, the drawback with redirect sessions is that you have to pre-spawn a bunch of server process and hope that enough clients want to connect to make them useful… overdo it, and you just have a lot of processes chewing up memory and CPU cycles for no particular reason.

- Whatever type of session you end up with, though, it’s important to realise that the Listener is merely instrumental in establishing the connection; once established, the listener plays no further part in client-server communications. It is therefore possible to kill a listener, and no existing user would be any the wiser.

- The above description applies only to dedicated server configurations, where each user is connected directly to one server process that does nothing but service that user’s requests. It is also possible, however, to configure oracle in what is known as multi-threaded server configuration (now known in 9i, more accurately, as “shared server configuration”). The only real difference this makes to the listener is that, upon receiving a client connection request, the listener redirects the connection to a dispatcher process, several of which are pre-spawned at instance startup. Yet again, however, once the client connection is established, the listener plays no further role in the communications process, and continues to listen for new requests

- A single listener process can listen out for client connection requests on a variety of different networking protocols (such as tcp/ip, ipx/spx, appletalk and so on). A single listener can also listen out on multiple ports for a single protocol (for example, port 1521 for tcp/ipan d port 1526 for tcp/ip) –but there are additional configuration issues when you use anything other than the default port of 1521 for tcp/ip connections (the short story is that local_listener must be set in the init.ora of the instance using the non- default port address).

- A single listener process is also perfectly capable of listening for connection requests to any number of instances. In other words, if your machine happens to be hosting 3 instances, you don’t need three different listeners. On the other hand, it’s legitimate to create additional listeners if the number of client requests to your various instances is so high that you are at risk from ‘listener contention’ problems (where a single listener just can’t keep up with the rate of connection requests).

- Listeners are created and configured using a text file, called listener.ora. This file can be edited at any time, but changes you make to it have no effect until the listener is stopped and re-started. Starting and stopping the listener is most easily done by using a command-line utility, called lsnrctl (“listener control”). It is possible to connect to an instance, without a listener running at all… but it requires you to make the connection directly on the machine hosting the instance. By setting the oracle_sid environment variable, and then simply issuing a ‘connect username/password’ request (i.e., a connection string with no instance name specified), you are able to make a direct connection to the instance using what is known as the IPC (inter-process communication) protocol. This is a valid approach for database administrators, but it’s not exactly useful for ordinary users: remote connections across a network must always go via a listener.

Checkout Oracle DBA Interview Questions

ORACLE NETWORK configuration:
Configuring Enterprise User Security for an Oracle database primarily involves creating directory objects to store enterprise user and database information.
In its most basic form, oracle uses three files (listener.ora, tnsnames.ora & sqlnet.ora) for network configuration. This field gives an example of each file as a starting point for simple network configuration:
Assumptions

• ora
• ora
• ora
• Testing

Assumptions:
The example files below are relevant for an oracle installation and instance with the following values.

• Parameter value
• Host hostname
• Oracle_home /opt/oracle/product/11.1.0
• Oracle_sid orcl
• Domain world

Listener.ora:
Oracle Net Listener configuration, stored in the listener.ora file, consists of the following elements:

• Name of the listener
• Protocol addresses that the listener is accepting connection requests on
• Database services
• Control parameters

The listerner.ora file contains server side network configuration parameters. It can be found in the “$oracle_home/network/admin” directory on the server. Here is an example of a listener.ora file

Listener =
  (description_list =
    (description =
      (address_list =
        (address = (protocol = tcp) (host =  port = 1521))
      )
    )
)
Sid_list_listener =
  (sid_list =
    (sid_desc =
      (global_dbname = orcl.world)
      (oracle_home = /opt/oracle/product/11.0.1)
      (sid_name = cricket)
    )
)?

After the “listener.ora” file is amended, the listener should be restarted or reloaded to allow the new configuration to take effect.

$ lsnrctl  stop
$ lsnrctl  start
$ lsnrctl reload

Tnsnames.ora:
The “tnsnames.ora” file contains client side network configuration parameters. It can be found in the “$oracle_home/network/admin” or “$oracle_home/net80/admin” directory on the client. This file will also be present on the server if client style connections are used on the server itself. Here is an example of a “tnsnames.ora” file.

Cricket =
  (description =
    (address_list =
      (address = (protocol = tcp) (host = hostname/ipaddress of server) (port = 1521))
    )
    (connect_data =
      (service_name = cricket)
    )
)

Sqlnet.ora:
The sqlnet.ora file is the profile configuration file.
The “sqlnet.ora” file contains client side network configuration parameters. It can be found in the “$oracle_home/network/admin” or “$oracle_home/net80/admin” directory on the client. This file will also be present on the server if client style connections are used on the server itself. Here is an example of an “sqlnet.ora” file.

Names.directory_path= (tnsnames, onames, hostname)
Names.default_domain = world
# the following entry is necessary on windows if os authentication is required.
Sqlnet.authentication_services= (nts)

Testing:
Once the files are present in the correct location and amended as necessary, the configuration can be tested using sql*plus by attempting to connect to the database using the appropriate username (scott), password (tiger) and service (orcl).

$ sqlplus scott/tiger@cricket

Configuring multiple listeners:
The Listener is a process that establishes a communication with Oracle database/databases.

Listener_krb11g =
(description_list =
(description =
(address = (protocol = ipc)(key = extproc1522))
(address = (protocol = tcp)(host = krbrhel)(port = 1522))
)
)
Sid_list_listener_krb11g=
( sid_list =
( sid_desc =
( global_dbname = krb11g )
( oracle_home = /u01/app/oracle/product/11.1.0/db_1 )
( sid_name = krb11g )
)
)
Krb11g2_listener =
(description_list =
(description =
(address = (protocol = tcp)(host = krbrhel)(port = 1523))
)
)
Sid_list_krb11g2_listener =
( sid_list =
( sid_desc =
( global_dbname = krb11g )
( oracle_home = /u01/app/oracle/product/11.1.0/db_1 )
( sid_name = krb11g )))

To get status:

$lsnrctl status krb11g2_listener

To start:

$ lsnrctl start krb11g2_listener

Oracle listener security:
The first thing to do is to put a password on your listener. By default, the listener comes with no password, and anyone can change listener settings through the lsnrctl tool. In Oracle 9i, any computer on your network can stop your listener in the blink of an eye if you do not protect it with a password.
First point on passwords. Yes, they are inconvenient, but they are much better than the alternatives. And yes, an unprotected listener can easily be used to corrupt your entire database.
To password protect your listener, perform the following as your oracle user:

$ lsnrctl
Lsnrctl> change_password
Old password:
New password:
Reenter new password:
If you have done all of this correctly, you will see the following:
Connecting to (description=(address=(protocol=tcp)(host=)(port=)))
Password changed for  

The command completed successfully.
Just as a note, if the listener you are protecting does not have the default name of listener, you must do set cur  before issuing the change_password command.
At this point, save the configuration of the listener to the file system. If you are on 10g, it will save with no problems:

Lsnrctl> save_config
Connecting to (description=(address=(protocol=tcp)(host=)(port=)))
Saved configuration parameters.
Listener parameter file /listener.ora
Old parameter file /listener.bak

The command completed successfully.
And you have a password protected listener.
However, this does not happen on 9i. If you perform a save_config, you will see the following:

Lsnrctl> save_config
Connecting to (description=(address=(protocol=tcp)(host=)(port=)))

Tns-01169: the listener has not recognized the password
The reason is that: in oracle 10g, operating system authentication for the listener has been implemented. The listener checks to make sure that you are part of the privileged dba group, and if so it will grant you access to change the password, save configuration, stop the listener, etc. In 9i, we must do the following at this point:
Lsnrctl> set password
Password:
The command completed successfully
At this point, you can now perform a save_config.
In 9i, you will now require a password whenever you wish to stop the listener or any other “destructive” listener actions. In 10g, if you are not logged into the operating system with a privileged account, you will have to enter a password as well. A typical listener stop may look like this in oracle 9i:

$ lsnrctl
Lsnrctl> stop
Connecting to (description=(address=(protocol=tcp)(host=)(port=)))
Tns-01169: the listener has not recognized the password
Lsnrctl> set password
Password:
The command completed successfully
Lsnrctl> stop
Connecting to (description=(address=(protocol=tcp)(host=)(port=)))

The command completed successfully
You are now protected against unauthorized shutdowns of your listener. This protects you from a whole range of possible security breaches. Remember that “set password” is how you enter your password for authentication; change_password is how it is changed.