In this video, we will identify the role of the Oracle listener as the gateway to the Oracle database and how the Oracle listener facilitates the connetion process for remote users
- [Narrator] So far we have talked quite a bit about the Oracle architecture, paying special attention to how users sessions work with the Oracle database. We discussed the roles of the Oracle server processes, which are the server-side counterpart to user sessions. Remember these? They process user queries, read data from files, and return the results back to the user. However, we have yet to talk about how users actually initiate, or establish a connection with an Oracle server.
Especially considering that in a real-world scenario, users will probably connect to an Oracle database over the network. So the question is, how do users specify which database they want to connect to? Maybe you have a lot of Oracle databases running all over your network. How do users initiate the connection to the correct database? How do users locate the Oracle instance they want to work with? To solve this problem, Oracle has another component in its architecture known as the Oracle Network Listener, or just Oracle Listener, in short.
Every user, application server, anything basically that wants to connect to an Oracle database is known as an Oracle Client. And Oracle Client has to go through an Oracle Listener before it can remotely connect to a running Oracle database. You can think of the Oracle listener as a gateway to the actual Oracle database. The Listener is responsible for coordinating connections between the database and external applications. In order for Client to successfully connect to an Oracle instance, and thus gain access to the Oracle database, they must first go through the Oracle Listener.
Once clients have established the connection with the Oracle Listener, the Oracle Listener will hand off the connection to the Oracle database. We represent the Oracle Listener as a separate component of the Oracle architecture in our graphics. This is just because it is easier for us to view the Listener as a separate component in relation to the Oracle database. However, if we want to be 100% technically accurate, and we always do, the placement of the Listener in relation to the Oracle instance will usually look something similar to this.
A single physical server on which both the Oracle instance as well as the Oracle Listener are running. There is no need to place the Oracle Listener process on a separate machine compared to the Oracle instance itself. Actually, a single physical server can have multiple Oracle instances running. Each with its own uniquely identifying alias known as service name in Oracle terms. This way, a single physical server can host multiple Oracle instances.
Think about it as having a single server run multiple Oracle databases. Such as a sales database, as well as a CRM, customer relations management database. Having multiple databases on the same physical server can maximize the efficient usage of server resources. Multiple Oracle instances running locally on the same server can use the same Oracle Listener as a gateway for all connecting clients.
I know it sounds confusing, but bear with me. It's actully quite simple. When a client wants to establish a connection to a specific Oracle instance or database, the Oracle Client will use a combination of the host name where the instance and listener are running as well as the uniquely identifying service name for the desired instance. This way, if we have multiple Oracle instances running on the same physical machine, clients can choose which instance, and thus which database, they want to connect to.
For example, if the client wants to connect to the sales database, it needs to know the host name where the sales instance is located as well as the sales database service name. In our case, sales underscore DB. The client will connect to the listener on that machine and asked to be assigned a server process in the Sales_DB database. Similarly, the process is the same if the client wants to connect to the CRM database. This is a very important concept to understand. Especially when you would start working with real Oracle databases in real environments where multiple Oracle database can run on the same physical server.
A single Oracle Listener can hand off connections from clients to all instances running on that physical server as Oracle instances register themselves with the Oracle Listener upon startup. So to summarize, the components involved in the database connection include first, we have our client. This is any computer, server, or desktop on our network that requires opening a remote connection to an Oracle server. We also have our Oracle database instance running on a server in our network.
And facilitating the connection between the two, acting as a connection broker, we have the Oracle Listener itself.
After completing this course, you'll have fundamentals required for installation, configuration, and administration of an Oracle 12c database.
- Database instance and storage
- Instance memory pools
- Instance background processes
- Client connections
- Database storage file types
- Control files and backup files
- Multitenant databases
- Starting and stopping the database
- Installing Oracle 12c software
- Using the developer tools
- Database management