To have a server (Database Server) that contains the database to which all Client Applications or all devices that contain programs that need to connect to the database are connected.

This is the natural and usual thing that most companies in the world work with, as it is not conceivable that all devices that contain programs that need to connect to the database also contain

a database Data, otherwise we need a database for every device that contains a program, and this is not acceptable rationally or practically. If we assume that we have a server that contains a database, all devices that contain programs that need a database can connect to this server. The focus of our discussion here will be on how to make this connection successful. So the matter will be on two sides:

The first side is the Database Server side and how it can serve all the requests that reach it to connect to the database.

As for the second side, it is the Client Application side: It is the device that wants to connect to the database, and how can it access the database?

Now we will talk about the first side, which is the Database Server side, and how it can serve all requests to connect to the database?

Server Side:

In this aspect, the Database Server can serve database connection requests via the Oracle Net Listener, which is responsible for processing the Clients' requests to connect to the database. Without the Listener, trying to connect to the database from outside the server will fail, but trying to connect to the database from within the server does not need the Listener, as it is specialized in receiving External requests.

One Listener can serve a number of instances, and it is basically a file located in the following path if we are working on the WINDOWS operating system.

ORACLE_HOME%\NETWORK\ADMIN\LISTENER.ORA%

If we are working on the UNIX operating system

ORACLE_HOME/NETWORK/ADMIN/LISTENER.ORA$

The database administrator can edit and configure this file to receive requests to connect to the database.

This is a sample of a Listener file that contains one Listener called Listener running on the nbs server and monitoring Port 1251 using the TCP protocol.

This listener serves an INSTANCE called ORCL. Of course, the database administrator can add a new LISTENER. Let's assume that we want to add a new listener called LISTENER1 that works on the same NBS server, monitors PORT 1521, and serves the same INSTANCE called ORCL using TCP PROTOCOL.

The file format after modification is as follows:-

Notice the new changes in the file, which is the addition of a new listener called LISTENER1.

After that we can control the LISTENERS by the command LSNRCTL.

The commands shown are the ones available to deal with the LISTENER.

These are commands to turn on, off, and display the listener's status, as well as setting and changing a password for the listener as a form of verification, as well as restarting the listener to absorb the updated configuration of the LISTENER.ORA file and other commands. Since we have added a new listener named 1LISTENER, it is better to run this listener, but it should be noted that when Writing the command LISTENER deals with the default listener DEFAULT, which here is LISTENER

So if we want to deal with the non-native listener, we have two options:

The first option: specify the listener name when directing the command.

LSNRCTL START LISTENER1 

Now we run the new listener that we created in the previous step, which is the listener LISTENER1, and if we did not write the listener name after the START command, the default listener, which is the listener LISTENER, would have been dealt with.

The second option: Use the SET CUR LISTENER_NAME command to set the new DEFAULT LISTENER, meaning the new name of the listener will be the default that we will deal with.

LSNRCTL> SET CUR LISTENERE1 

Now LISTENER1 is the DEFAULT LISTENER.

After creating and running LISTENER1 listener, it can be followed via SERVICES if we are working on WINDOWS operating system

Now the listener LISTENER1 can receive database connection requests on PORT (1521) on the NBS server using the TCP protocol to serve ORCL INSTANCE.

If we want to monitor and know information about the listener, it is better to use the STATUS or SERVICE command to display information about the listener such as the listener name, its version, when it was started, the services it serves, the path of the LISTENER.ORA file, and other information. As we mentioned, one listener can serve a number of INSTANCES, and a number of LISTENERS can share in serving one INSTANCE, and there can be a number of INSTANCES on one device, each of which has a listener serving it. From Oracle8i onwards, the new instance is automatically registered in the Default Listener, meaning the database administrator does not need to add it manually in the Listener, in what is known as

Dynamic Service registration.

Setting a password for the listener:

1- Run the listener editor.

LSNRCTL 

2- Set the password, let's assume it is 123, noting that it does not appear on the editor, and that there is no current password for the listener.

LSNRCTL> change_password 

3- Save the password in the LISTENER.ORA file.

LSNRCTL>save_config 

4- Now you need the password to stop the listener.

LSNRCTL> set passwdord 123

LSNRCTL> stop 

5- Changes can be observed in the LISTENER.ORA file.