OCA/OCP Oracle Database 11g All-in-One Exam Guide 156 8. Create a new service name: highlight Service Naming in the navigation tree, and click the + icon. 9. Enter NEW as the net service name, and click Next. 10. Select TCP/IP as the protocol, and click Next. 11. Enter 127.0.0.1 as the host name and 2521 as the port and click Next. 12. Enter SERV1 as the service name, and click Next. 13. Click Finish. If you try the test, it will fail at this time. The illustration that follows shows the result. 14. Save the configuration by clicking File and Save Network Configuration. This will create the listener.ora and tnsnames.ora files in the TNS_ADMIN directory. 15. Use an editor to check the two files. They will look like this: LISTENER.ORA: NEWLIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 2521)) ) TNSNAMES.ora: NEW = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 2521)) ) (CONNECT_DATA = (SERVICE_NAME = SERV1) ) ) Chapter 4: Oracle Networking 157 PART I 16. From an operating system prompt, start the listener with lsnrctl start newlist. 17. From an operating system prompt, test the connect string with tnsping new. 18. Connect to your database using operating system authentication, bypassing any listener, with sqlplus / as sysdba. 19. Set the service_names and local_listener parameters for the running instance (memory only, not the parameter file) and register the new service name with the new listener: alter system set service_names=serv1 scope=memory; alter system set local_listener=new scope=memory; alter system register; 20. From an operating system prompt, confirm that the new service has registered with the new listener with lsnrctl services newlist. 21. Confirm that the new network environment is functional by logging on: sqlplus system/oracle@new Use the Oracle Shared Server Architecture The standard dedicated server architecture requires that the database listener should spawn a dedicated server process for each concurrent connection to the instance. These server processes will persist until the session is terminated. On Unix-type platforms, the server processes are real operating system processes; on Windows, they are threads within the one ORACLE.EXE process. This architecture does not scale easily to support a large number of user processes on some platforms. An alternative is the shared server architecture, known as the multithreaded server (or MTS) in earlier releases. The Limitations of Dedicated Server Architecture As more users log on to your instance, more server processes get launched. This is not a problem as far as Oracle is concerned. The database listener can launch as many processes as required, though there may be limits on the speed with which it can launch them. If you have a large number of concurrent connection requests, your listener will have to queue them up. You can avoid this by running multiple listeners on different ports, and load-balancing between them. Then once the sessions are established, there is no limit to the number that PMON can manage. But your operating system may well have limits on the number of processes that it can support, limits to do with context switches and with memory. A computer can only do one thing at once unless it is an SMP machine, in which case each CPU can only do one thing at once. The operating system simulates concurrent processing by using an algorithm to share CPU cycles across all the currently executing processes. This algorithm, often referred to as a time slicing or time sharing algorithm, takes care of allocating a few CPU cycles to each process in turn. The switch of taking one process off CPU in order to put another process on CPU is called a context switch. Context switches are very expensive: the operating system has to do a lot of work to OCA/OCP Oracle Database 11g All-in-One Exam Guide 158 restore the state of each process as it is brought on to CPU and then save its state when it is switched off the CPU. As more users connect to the instance, the operating system has to context-switch between more and more server processes. Depending on your operating system, this can cause a severe degradation in performance. A decent mainframe operating system can context-switch between tens of thousands of processes without problems, but newer (and simpler) operating systems such as Unix and Windows may not be good at running thousands, or even just hundreds, of concurrent processes. Performance degrades dramatically, because a large proportion of the computer’s processing capacity is taken up with managing the context switches, leaving a relatively small amount of processing capacity available for actually doing work. There may also be memory problems that occur as more sessions are established. The actual server processes themselves are not an issue, because all modern operating systems use shared memory when the same process is loaded more than once. So launching a thousand server processes should take no more memory than launching one. The problem comes with the program global area, or PGA. The PGA is a block of memory associated with each server process, to maintain the state of the session and as a work area for operations such as sorting rows. Clearly, the PGAs cannot be in shared memory: they contain data unique to each session. In many operating systems, as memory thresholds are reached, they make use of swap space or paging areas on disk, and memory pages are swapped out to disk to make room for memory requirements of other processes. When the memory pages that have been swapped out to disk are required, they are swapped back into memory and something else is swapped out to disk. Excessive swapping can be catastrophic for the performance of your system. Due to the PGA requirements of each session, your system may begin to swap as more users log on. So in the dedicated server environment, performance may degrade if your operating system has problems managing a large number of concurrent processes, and the problem will be exacerbated if your server machine has insufficient memory. Note that it doesn’t really matter whether the sessions are actually doing anything or not. Even if the sessions are idle, the operating system must still bring them on and off CPU, and possibly page the appropriate PGA into main memory from swap files, according to its time slicing algorithm. There comes a point when, no matter what you do in the way of hardware upgrades, performance begins to degrade because of operating system inefficiencies in managing context switches and paging. These are not Oracle’s problems, but to overcome them Oracle offers the option of the shared server architecture. This allows a large number of user processes to be serviced by a relatively small number of shared server processes, thus reducing dramatically the number of processes that the server’s operating system has to manage. As a fringe benefit, memory usage may also reduce. Always remember that the need for a shared server is very much platform and installation specific. Some operating systems will hardly ever need it. For example, a mainframe computer can time-share between many thousands of processes with no problems—it is usually simpler operating systems like Windows or Unix that are more likely to have problems. Chapter 4: Oracle Networking 159 PART I The Shared Server Architecture One point to emphasize immediately is that shared server is implemented purely on the server side. The user process and the application software have no way of telling that anything has changed. The user process issues a connect string that must resolve to the address of a listener and the name of a service (or of an instance). In return, it will receive the address of a server-side process that it will think is a dedicated server. It will then proceed to send SQL statements and receive back result sets; as far as the user process is concerned, absolutely nothing has changed. But the server side is very different. Shared server is implemented by additional processes that are a part of the instance. They are background processes, launched at instance startup time. There are two new process types, dispatchers and shared servers. There are also some extra queue memory structures within the SGA, and the database listener modifies its behavior for shared server. When an instance that is configured for shared server starts up, in addition to the usual background processes one or more dispatcher processes also start. The dispatchers, like any other TCP process, run on a unique TCP port allocated by your operating system’s port mapper: they contact the listener and register with it, using the local_ listener parameter to locate the listener. One or more shared server processes also start. These are conceptually similar to a normal dedicated server process, but they are not tied to one session. They receive SQL statements, parse and execute them, and generate a result set—but they do not receive the SQL statements directly from a user process, they read them from a queue that is populated with statements from any number of user processes. Similarly, the shared servers don’t fetch result sets back to a user process directly—instead, they put the result sets onto a response queue. The next question is, how do the user-generated statements get onto the queue that is read by the server processes, and how do results get fetched to the users? This is where the dispatchers come in. When a user process contacts a listener, rather than launching a server process and connecting it to the user process, the listener passes back the address of a dispatcher. If there is only one dispatcher, the listener will connect it to all the user processes. If there are multiple dispatchers, the listener will load-balance incoming connection requests across them, but the end result is that many user processes will be connected to each dispatcher. Each user process will be under the impression that it is talking to a dedicated server process, but it isn’t: it is sharing a dispatcher with many other user processes. At the network level, many user processes will have connections multiplexed through the one port used by the dispatcher. EXAM TIP A session’s connection to a dispatcher persists for the duration of the session, unlike the connection to the listener, which is transient. When a user process issues a SQL statement, it is sent to the dispatcher. The dispatcher puts all the statements it receives onto a queue. This queue is called the common queue, because all dispatchers share it. No matter which dispatcher a user process is connected to, all statements end up on the common queue. OCA/OCP Oracle Database 11g All-in-One Exam Guide 160 All the shared server processes monitor the common queue. When a statement arrives on the common queue, the first available shared server picks it up. From then execution proceeds through the usual parse-bind-execute cycle, but when it comes to the fetch phase, it is impossible for the shared server to fetch the result set back to the user process: there is no connection between the user process and the shared server. So instead, the shared server puts the result set onto a response queue that is specific to the dispatcher that received the job in the first place. Each dispatcher monitors its own response queue, and whenever any results are put on it, the dispatcher will pick them up and fetch them back to the user process that originally issued the statement. Figure 4-11 depicts three user processes making use of shared server mode. User processes 1 and 2 try to connect to an instance or service and are handed over to Dispatcher 1 by the listener, while user process 3 interacts with the instance via Dispatcher 2. A User process 1 submits a statement for execution. B Dispatcher 1 places the statement onto the common queue. C A shared server process picks up the statement from the common request queue, parses it, executes it, and generates a result set. D The shared server places the result set in Dispatcher 1’s response queue. E Dispatcher 1 fetches the result set from its response queue. F Dispatcher 1 returns the results to User process 1. G–L These steps are identical to steps A–F but apply to User process 2. Note that Dispatcher 1 services both these user processes. M User process 3 submits a statement for execution. N Dispatcher 2 places the statement onto the common queue. O A shared server process picks up the statement from the common request queue, parses it, executes it, and generates a result set. P The shared server places the result set in Dispatcher 2’s response queue. Note that this shared server process could be the very same process that performed preceding steps C, I, O, D and J. Q Dispatcher 2 fetches the result set from its response queue. R Dispatcher 2 returns the results to User process 3. EXAM TIP There is a common input queue shared by all dispatchers, but each dispatcher has its own response queue. A result of the mechanism of dispatchers and queues is that any statement from any user process could be executed by any available shared server. This raises the question of how the state of the session can be maintained. It would be quite possible Chapter 4: Oracle Networking 161 PART I for a user process to issue, for example, a SELECT FOR UPDATE, a DELETE, and a COMMIT. In a normal dedicated server connection, this isn’t a problem because the PGA (which is tied to the one server process that is managing the session) stores information about what the session was doing, and therefore the dedicated server will know what to COMMIT and what locks to release. The PGA for a dedicated server session will store the session’s session data, its cursor state, its sort space, and its stack space. But in the shared server environment, each statement might be picked off the common queue by a different shared server process, which will have no idea what the state of the transaction is. To get around this problem, a shared server session stores most of the session data in the SGA, rather than in a PGA. Then whenever a shared server picks a job off the common queue, it will go to the SGA and connect to the appropriate block of memory to find out the state of the session. The memory used in the SGA for each shared server session is known as the user global area (the UGA) and includes all of what would have been in a PGA with the exception of the session’s stack space. This is where the memory saving will come from. Oracle can manage memory in the shared pool much more effectively than it can in many separate PGAs. The part of the SGA used for storing UGAs is the large pool. This can be configured manually with the large_pool_size parameter, or it can be automatically managed. EXAM TIP In shared server, what PGA memory structure does not go into the SGA? The stack space. Configuring Shared Server Being a server-side capability, no additional client configuration is needed beyond the regular client-side Oracle Net (the tnsnames.ora and sqlnet.ora files) as detailed previously. On the server side, shared server has nothing to do with the database—only Figure 4-11 Shared server mode OCA/OCP Oracle Database 11g All-in-One Exam Guide 162 the instance. The listener will be automatically configured for shared server through dynamic instance registration. It follows that shared server is configured though instance initialization parameters. There are a number of relevant parameters, but two are all that are usually necessary: dispatchers and shared_servers. The first parameter to consider is shared_servers. This controls the number of shared servers that will be launched at instance startup time. Shared server uses a queuing mechanism, but the ideal is that there should be no queuing: there should always be a server process ready and waiting for every job that is put on the common queue by the dispatchers. Therefore, shared_servers should be set to the maximum number of concurrent requests that you expect. But if there is a sudden burst of activity, you don’t have to worry too much, because Oracle will dynamically launch additional shared servers, up to the value specified by max_shared_servers. By default, shared_servers is one if dispatchers is set. If the parameter max_shared_ servers is not set, then it defaults to one eighth of the processes parameter. The dispatchers parameter controls how many dispatcher processes to launch at instance startup time, and how they will behave. This is the only required parameter. There are many options for this parameter, but usually two will suffice: how many to start, and what protocol they should listen on. Among the more advanced options are ones that allow you to control the port and network card on which the dispatcher will listen, and the address of the listener(s) with which it will register, but usually you can let your operating system’s port mapper assign a port, and use the local_listener parameter to control which listener they will register with. The max_dispatchers parameter sets an upper limit to the number of dispatchers you can start, but unlike with shared servers, Oracle will not start extra dispatchers on demand. You can, however, manually launch additional dispatchers at any time up to this limit. For example, to enable the shared server architecture, adjust the two critical parameters as follows: SQL> alter system set dispatchers='(dispatchers=2)(protocol=tcp)'; SQL> alter system set shared_servers=20; Tuning the shared server is vital. There should always be enough shared servers to dequeue requests from the common queue as they arrive, and enough dispatchers to service incoming requests as they arrive and return results as they are enqueued to the response queues. Memory usage by shared server sessions in the SGA must be monitored. After converting from dedicated server to shared server, the SGA will need to be substantially larger. When to Use the Shared Server You will not find a great deal of hard advice in the Oracle documentation on when to use shared server, or how many dispatchers and shared servers you’ll need. The main point to hang on to is that shared server is a facility you use because you are forced to, not something you use automatically. It increases scalability, but it could potentially Chapter 4: Oracle Networking 163 PART I reduce performance. It is quite possible that any one statement will take longer to execute in a shared server environment than if it were executing on a dedicated server, because it has to go via queues. It may also take more CPU resources because of the enqueuing and dequeuing activity. But overall, the scalability of your system will increase dramatically. Even if each request is marginally slower, you will be able to carry out many more requests per second through the instance. TIP It is often said that you should think about using shared server when your number of concurrent connections is in the low hundreds. If you have less than a hundred concurrent connections, you almost certainly don’t need it. But if you have more than a thousand, you probably do. The critical factor is whether your operating system performance is beginning to degrade. Consider an OLTP environment, such as one where the application supports hundreds of telephone operators in a call center. Each operator may spend one or two minutes per call, collecting the caller details and entering them into the user process (their application session). Then when the Submit button is clicked, the user process constructs an insert statement and sends it off to the server process. The server process might go through the whole parse/bind/execute/fetch cycle for the statement in just a few hundredths of a second. Clearly, no matter how fast the clerks work, their server processes are idle 99.9 percent of the time. But the operating system still has to switch all those processes on and off CPU, according to its time sharing algorithm. By contrast, consider a data warehouse environment. Here, users submit queries that may run for a long time. The batch uploads of data will be equally long running. Whenever one of these large jobs is submitted, the server process for that session could be working flat out for hours on just one statement. It should be apparent that shared server is ideal for managing many sessions doing short transactions, where the bulk of the work is on the client side of the client-server divide. In these circumstances, one shared server will be able to service dozens of sessions. But for batch processing work, dedicated servers are much better. If you submit a large batch job through a shared server session, it will work—but it will tie up one of your small pool of shared server processes for the duration of the job, leaving all your other users to compete for the remaining shared servers. The amount of network traffic involved in batch uploads from a user process and in fetching large result sets back to a user process will also cause contention for dispatchers. A second class of operations that are better done through a dedicated server is database administration work. Index creation, table maintenance operations, and backup and recovery work through the Recovery Manager will perform much better through a dedicated server. And it is logically impossible to issue startup or shutdown commands through a shared server: the shared servers are part of the instance and thus not available at the time you issue a startup command. So the administrator should always have a dedicated server connection. OCA/OCP Oracle Database 11g All-in-One Exam Guide 164 TIP If the default mode has been changed to shared server mode, batch and administration user processes can ensure that they are serviced by dedicated server processes, by modifying their client-side tnsnames.ora by adding the entry: (SERVER=DEDICATED). Exercise 4-2: Set Up a Shared Server Environment In this exercise, which continues from Step 21 of Exercise 4-1, you will configure the shared server and prove that it is working. 1. Set the dispatchers and shared_servers parameters and register with the listener as follows: alter system set dispatchers='(protocol=tcp)(dispatchers=2)' scope=memory; alter system set shared_servers=4 scope=memory; alter system register; 2. Confirm that the dispatchers and shared servers have started by querying the view V$PROCESS. Look for processes named S000, S001, S002, S003, D000, and D001: select program from v$process order by program; 3. From an operating system prompt, confirm that the dispatchers have registered with the listener: lsnrctl services newlist 4. Connect through the listener, and confirm that the connection is through the shared server mechanism: connect system/oracle@new; select d.name,s.name from v$dispatcher d,v$shared_server s, v$circuit c where d.paddr=c.dispatcher and s.paddr=c.server; This query will show the dispatcher to which your season is connected, and the shared server process that is executing your query. 5. Tidy up the environment, by returning to the original configuration: alter system set local_listener='' scope=memory; alter system set service_names='' scope=memory; alter system set dispatchers='' scope=memory; alter system set shared_servers=0 scope=memory; alter system register; Stop the listener from an operating system prompt with lsnrctl stop newlist. Unset the TNS_ADMIN variable: on Linux, export TNS_ADMIN=" or on Windows, remove the TNS_ADMIN registry key. Chapter 4: Oracle Networking 165 PART I Two-Minute Drill Configure and Manage the Oracle Network • The server-side files are the listener.ora and (optionally) sqlnet.ora files. • The client-side files are the tnsnames.ora and (optionally) sqlnet.ora files. • The Oracle Net files live by default in ORACLE_HOME/network/admin, or in whatever directory the TNS_ADMIN variable points to. • Name resolution can be local (with a tnsnames.ora file) or central (with an LDAP directory). • Easy Connect does not need any name resolution. • One listener can listen for many databases. • Many listeners can connect to one database. • Instance registration with listeners can be static (by coding details in the listener.ora file) or dynamic (by the PMON process updating the listener). • Each user process has a persistent connection to its dedicated server process. Use the Oracle Shared Server Architecture • User processes connect to dispatchers; these connections are persistent. • All dispatchers place requests on a common queue. • Shared server processes dequeue requests from the common queue. • Each dispatcher has its own response queue. • Shared server processes place results onto the appropriate dispatcher’s response queue. • The dispatchers fetch results back to the appropriate user process. • Shared server is configured with (as a minimum) two instance parameters: dispatchers and shared_servers. . connection. OCA/ OCP Oracle Database 11g All-in-One Exam Guide 164 TIP If the default mode has been changed to shared server mode, batch and administration user processes can ensure that they are serviced. sqlnet.ora files) as detailed previously. On the server side, shared server has nothing to do with the database only Figure 4-11 Shared server mode OCA/ OCP Oracle Database 11g All-in-One Exam Guide 162 the. commands through a shared server: the shared servers are part of the instance and thus not available at the time you issue a startup command. So the administrator should always have a dedicated