User and Server Processes in Oracle 12c - dummies

User and Server Processes in Oracle 12c

By Chris Ruel, Michael Wessler

When you start and initiate connections to the Oracle 12c instance, many processes are involved, including the component of the Oracle instance that uses the Oracle programs and the code to gain access to your data.

There are no processes when the Oracle instance is shut down. Some of the processes are mandatory, and others are optional depending on the features you’ve enabled. It can also depend on your OS.

Three types of processes are part of the instance:

  • Background processes are involved in running the Oracle software itself.

  • Server processes negotiate the actions of the users.

  • User processes commonly work outside the database server itself to run the application that accesses the database.

Because user and server processes are intertwined, they are discussed together. However, they are distinct and separate processes. As a matter of fact, they typically run on separate machines. A very simple example: When you start SQL*Plus on a Windows client, you get a user process called sqlplus.exe.

The user process represents a user’s session in the database. When a connection is made to the database on a Linux machine, you get a connection to a process named something like oracle<database_name> or ora_S000_<database_name>.

The server process serves and exists on the database server. It does anything the user requests of it. It is responsible for reading blocks into the buffer cache. It changes the blocks if requested. It can create objects.

Server processes can be one of two types:

  • Dedicated

  • Shared

The type depends on how your application operates and how much memory you have. You’re first presented with the choice of dedicated or shared when you create your database with Oracle’s Database Configuration Assistant (DBCA). However, you can change it one way or the other later on.

Dedicated server architecture

Each user process gets its own server process. This is the most common Oracle configuration. It allows a server process to wait on you. If the resources can support dedicated connections, this method also is the most responsive. However, it can also use the most memory. Even if you’re not doing anything, that server process is waiting for you.

Not that it’s a bad thing. Imagine, though, 5,000 users on the system sitting idle most of the time. If your applications can’t use connection pools (similar to shared server processes), your database probably won’t survive and perform adequately for more than a day.

Shared server architecture

Just as the name implies, the server processes are shared. Now, instead of a server process waiting on you hand and foot, you have only one when you need it.

Think of a server process as a timeshare for Oracle. It’s more cost-effective (in terms of memory), and you almost always have one available when you need it (provided the infrastructure is properly configured).

On a system with 5,000 mostly idle users, you might be able to support them with only 50 server processes. You must do these things for this to work properly:

  • Make sure the number of concurrent database requests never exceeds the number of shared servers configured.

  • Make sure users don’t hold on to the processes for long periods. This works best in a fast transaction-based environment like an e-commerce site.

  • Have a few extra CPU cycles available. All the interprocess communication seems to have small CPU cost associated with it over dedicated server processes.

The fact is shared server configurations are less common in today’s environment where memory is cheap. Most applications these days get around the problems associated with too many dedicated servers by using advanced connection pooling on the application server level.

You should know about some other limitations: DBA connections must have a dedicated server. Therefore, a shared server environment is actually a hybrid. Shared servers can coexist with a dedicated server.

Many different types of files are required (and optional) to run an Oracle database:

  • Data files

  • Control files

  • Redo log files

  • Archive log files

  • Server and initialization parameter files

Knowing what each of these files does greatly increases your database management success.