Published on

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Configuring Shared Server (or Multi-Threaded Server) Networking TipsConfiguring Shared Server (MTS)A true story: the first time I taught the Oracle Networking course, my class spent nearly 4hours trying to get Multi-Threaded Server configuration working. And not a single student(still less the Instructor, yours truly) could get the damn thing to work. Then one of thestudents hit the space bar when editing his tnsnames.ora, and Lo! Multi-Threaded Serverconfiguration suddenly sprang into life!!Fortunately, that was back in the bad old days of Oracle 8.1.5, and things have got steadilyeasier since then, with much less sensitivity to the odd space here and there. However, Imention this story to advise you that if Multi-Threaded Server (or Shared Server as it isnow known in 9i) refuses to work, stick with it… check your syntax extremely carefully.Given enough fiddling (and patience) it can be made to work.For the record, I run my test-bed 9i database at home in dedicated server mode. Justprior to starting this paper, I switched to Shared Server configuration. It was workingwithin three minutes.Configuring the init.oraShared Server can be made to work with just two additions to your init.ora. First,DISPATCHERS needs to be set to the number of dispatchers you want spawned when theInstance starts up, and the networking protocol you want them to work on. Second,SHARED_SERVERS needs to be set to the number of Server Processes you want spawnedand ready in the pool of shared Server Processes when the Instance starts up.And that’s all there is to it!With some slight provisos, naturally!! First, those parameter names are the 9i versions. In8i or before, they are called MTS_DISPATCHERS and MTS_SERVERS respectively. Toconfuse the issue even more, if in 9i you do a show parameter dispatcher, you’ll seelisted both the new parameters and the old ones:dispatchers string (PROTOCOL=TCP)(DISPATCHERS=2)mts_dispatchers string (PROTOCOL=TCP)(DISPATCHERS=2)Likewise, both the new and the old SERVER parameters are available in 9i. For the hell ofit, I’ve tested 9i using the old syntax, and it works perfectly well –but you are stronglyadvised to stick to the new parameter names, because the old ones are only there forbackwards compatibility, and there’s no telling when exactly in the future they will ceaseto function.Copyright © Howard Rogers 2002 17/03/2002 Page 1 of 9
  2. 2. Configuring Shared Server (or Multi-Threaded Server) Networking TipsTo stress the point, Oracle will give you the following stern-looking warning when you startup after adding these parameters into your init.ora:SQL> startup force pfile=d:oracleadmindb9pfileinit.oraORA-32006: MTS_DISPATCHERS initialization parameter has been deprecatedORA-32006: MTS_SERVERS initialization parameter has been deprecatedORACLE instance started.Total System Global Area 93089624 bytesFixed Size 282456 bytesVariable Size 58720256 bytesDatabase Buffers 33554432 bytesRedo Buffers 532480 bytesDatabase mounted.Database opened.As you can see, the database does proceed to start up perfectly normally, the key pointbeing that the parameters are “deprecated” not actually “obsolete”.The other thing I should mention at this point is: what are reasonable values for thenumber of Dispatchers and shared Server Processes? Good question, though outside thescope of this paper: you might care to read my paper “How do I know the right number ofDispatchers and Servers to start?” for a detailed answer.Finally, I’ll mention some additional init.ora parameters that can be set at this point,though they are optional.MAX_DISPATCHERS sets a hard limit to the number of Dispatchers than can runconcurrently. If not set, this defaults to 5. If you subsequently discover that the numberof Users connecting to your database is causing contention for the existing number ofDispatchers, you can start additional ones, up to this hard limit. Allowing the default of 5to be set is therefore restricting your tuning options, so you might want to think aboutexplicitly setting a rather higher limit to give yourself some future flexibility. (in 8i andbefore, this parameter was called MTS_MAX_DISPATCHERS).MAX_SHARED_SERVERS does a similar sort of job for the number of shared ServerProcesses that are allowed to be running concurrently. Oracle will automatically detectcontention for the existing pool of Shared Server processes, and will spawn additional onesas it sees fit (and kill of unnecessary ones, too, if the load on the system decreases). Butit can only spawn extra processes up to this hard limit. Again, if you choose not to set thisparameter explicitly, there is a default setting –either 20, or twice whateverSHARED_SERVERS was set to, whichever is the higher. Those seem quite reasonabledefaults to me, so there is perhaps less need to set this one yourself… though, of course,it’s there for future tuning use as necessary. In 8i and before, this parameter was calledMTS_MAX_SERVERS.There are other init.ora parameters that can be set, but these are the ones most closelyrelated to getting Shared Server working in the first place. I’ll discuss the others at theend of this paper.Copyright © Howard Rogers 2002 17/03/2002 Page 2 of 9
  3. 3. Configuring Shared Server (or Multi-Threaded Server) Networking TipsConfiguring the tnsnames.oraYou shouldn’t actually need to do anything to your tnsnames.ora. By default, if there areDispatchers running when a User requests a connection to an Instance, they are connectedto a Dispatcher by the Listener –and hence are immediately making use of a Shared Serverconnection.On the other hand, it’s usually good advice to make your connection choices explicit,rather than rely on slightly mysterious Oracle defaults. And if there seems to be somedifficulty getting Shared Server configuration to work, a bit of light editing of thetnsnames.ora can’t do any harm!Probably, your tnsnames.ora looks a bit like this:DB9 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = mozart)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = db9.aldeburgh.local) ) )What you can do is to edit it so that it looks like this:DB9 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = mozart)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = db9.aldeburgh.local) (SERVER=SHARED) ) )The one addition is the line I’ve highlighted in bold. It explicitly demands that a SharedServer connection be made.There is a drawback to explicitly setting this parameter: if, for some reason, the Instanceis started without any Dispatchers, then a User request to connect will simply fail: histnsnames.ora is demanding a connection to a Dispatcher, and there aren’t any. Had thatline been left out, as in the original version of the file, a User request to connect wouldhave caused the Listener to spawn a dedicated Server Process for him in the absence ofany Dispatchers.Should you explicitly demand shared connections, then? It’s up to you: I always do, on thegrounds that I’d rather I couldn’t connect at all than make the wrong sort of connection,but your mileage might well vary.Copyright © Howard Rogers 2002 17/03/2002 Page 3 of 9
  4. 4. Configuring Shared Server (or Multi-Threaded Server) Networking TipsOn the other hand, there is another edit to the tnsnames.ora that I always make, and itresults in a tnsnames that looks like this:DB9 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = mozart)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = db9.aldeburgh.local) (SERVER=SHARED) ) )DB9DBA = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = mozart)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = db9.aldeburgh.local) (SERVER=DEDICATED) ) )In short, I copy the entire original contents, and paste them underneath. I then modify theservice alias (the “DB9 = ” bit), and make it clear that the new alias is for DBA use. Hencethe new alias is, in this case, “DB9DBA”. Finally, I make an explicit request that the newalias connects using a dedicated Server Process.This is actually quite an important thing to do. The benefits of Shared Server configurationonly start to really make themselves felt when Users are performing short, sharptransactions …and a dedicated Server Process would then have to sit around idle waitingfor them to submit their next one. In Shared Server configuration, that User idle time isused by the Server Process to service other User’s requests. If, however, your Users are inthe habit of firing off an enormous transaction, what that means in Shared Serverconfiguration is that they’ve effectively tied up a Server Process in exclusive mode –andthus other Users have less processes around to service their requests. Performancedegrades all round as a result.Now, your typical DBA is likely to connect to the database to perform administrative taskswhich, by their nature, are lengthy (the rebuild of an index, for example, or the collectionof statistics on a table). You need a dedicated Server Process to perform such tasks if youare not to effectively shrink the pool of processes available to everyone else.So this additional service alias is a useful way of not clogging up a Shared Serverconfiguration. You should consider allowing any User that needs to perform a long-runningtransactions (greater than around 10 seconds or so) to connect to a primarily Shared Serverdatabase in dedicated mode. And this is the way to do it.Copyright © Howard Rogers 2002 17/03/2002 Page 4 of 9
  5. 5. Configuring Shared Server (or Multi-Threaded Server) Networking TipsHow do you know it’s working?Apart from the edits to the init.ora and the tnsnames.ora I’ve just mentioned, there’sreally nothing else to configure. Obviously, any edit to the init.ora requires that yourestart your Instance to pick up the new settings. (Incidentally, a word of warning in 9i:it’s no good editing your init.ora and then issuing a bare “startup” command if you happento have previously created an spfile. The spfile takes precedence over an init.ora, so thenet effect would be… nothing. You may need, therefore, to explicitly specify that thestartup sequence should use the init.ora, and then create a new spfile from the init.oraonce the database comes back up, so that future startups use Shared Server configuration).But, given the Instance bounce, how do you then know whether Shared Server is workingproperly?There a couple of things to check. First, you need to make sure that the Dispatchers havebeen spawned and have registered themselves with the Listener. From the command line,you can run the lsnrctl tool to check this:C:Documents and SettingsAdministrator>lsnrctl servicesLSNRCTL for 32-bit Windows: Version - Production on 17-MAR-2002 12:57:44Copyright (c) 1991, 2001, Oracle Corporation. All rights reserved.Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=mozart)(PORT=1521)))Services Summary...Service "db9.aldeburgh.local" has 3 instance(s). Instance "db9", status UNKNOWN, has 1 handler(s) for this service... Handler(s): "DEDICATED" established:0 refused:0 LOCAL SERVER Instance "db9", status READY, has 1 handler(s) for this service... Handler(s): "DEDICATED" established:6 refused:0 state:ready LOCAL SERVER Instance "db9", status READY, has 3 handler(s) for this service... Handler(s): "DEDICATED" established:1 refused:0 state:ready LOCAL SERVER "D001" established:2 refused:0 current:1 max:1002 state:ready DISPATCHER <machine: MOZART, pid: 1564> (ADDRESS=(PROTOCOL=tcp)(HOST=mozart.aldeburgh.local)(PORT=4199)) "D000" established:2 refused:0 current:0 max:1002 state:ready DISPATCHER <machine: MOZART, pid: 1920> (ADDRESS=(PROTOCOL=tcp)(HOST=mozart.aldeburgh.local)(PORT=4197))The command completed successfullyI’ve again highlighted the important lines in bold. All Dispatchers have a process name of“Dxxx”, where “xxx” is just a monotonically incrementing sequence number starting atzero. So those two highlighted lines show me that two Dispatchers have been started –andsince this is the Listener Control utility we’re running, it’s obvious that they must haveregistered themselves with the Listener.Copyright © Howard Rogers 2002 17/03/2002 Page 5 of 9
  6. 6. Configuring Shared Server (or Multi-Threaded Server) Networking TipsHowever, just having Dispatchers at the ready isn’t enough: remember that it’s perfectlypossible for a Shared Server Instance to allow dedicated connections.So… what I then do is go to a client machine, and issue the standard connection commands.Once the User has connected, if you then query V$CIRCUIT and get a row returned, that’sa guarantee that a Shared Server connection has been made. Dedicated Serverconnections don’t cause rows to be added to V$CIRCUIT. Using the tnsnames.ora Ishowed you earlier, it’s easy enough to prove this point:SQL> connect system/manager@db9Connected.SQL> select count(*) from v$circuit; COUNT(*)---------- 1SQL> connect system/manager@db9dbaConnected.SQL> select count(*) from v$circuit; COUNT(*)---------- 0You’ll recall that the alias “db9” demanded a shared connection, but the alias “db9dba”demanded a dedicated connection. When the shared connection is made, V$CIRCUITshows some positive row count. Dedicated connections just leave V$CIRCUIT at zero,however.There’s another test I sometimes do, just to remind myself what Shared Serverconfiguration is really all about: count the number of processes as, on client machines, Imake more and more connections. Shared Server configuration should show no increase inthe number of processes as additional Users connect (which is the whole point, of course).Dedicated connections, however, cause a new dedicated Server Process to be spawned, sothe process count should increase by one as each new connection is made.SQL> connect system/manager@db9Connected.SQL> select count(*) from v$process union select count(*) from v$session; COUNT(*)---------- 7 13SQL> connect system/manager@db9dbaConnected.SQL> select count(*) from v$process union select count(*) from v$session; COUNT(*)---------- 7 14Copyright © Howard Rogers 2002 17/03/2002 Page 6 of 9
  7. 7. Configuring Shared Server (or Multi-Threaded Server) Networking TipsHere we connect first in what we hope is Shared Server mode. We have a count of 7sessions, requiring 13 processes. Then we connect in what is supposed to be dedicatedmode. The same 7 sessions now require 14 processes –the additional process being, ofcourse, the Server Process that the dedicated connection request caused to be spawned.Other Init.ora ParametersI mentioned earlier that there are other parameters that may need to be altered in theinit.ora. None of them are actually required to get Shared Server configuration working,but they may be needed to get Shared Server configuration working well.LARGE_POOL_SIZE: This one is actually very important. If you don’t set it, then the memory that, in Dedicated configuration, would have been part of the PGA is now stolen from the SGA, and in particular the Library Cache of the Shared Pool. That will probably cause fragmentation of the Shared Pool, and excessive ageing out of parsed SQL statements (requiring excessive amounts of re- parsing). If a Large Pool is configured, however, the relevant bits of the PGA take their memory requirements from that pool, leaving the Shared Pool largely untouched. I say “largely” untouched, because even with a Large Pool, each User connection requires about 10K from the Shared Pool. You probably also want to boost your existing SHARED_POOL_SIZE by (10K*the expected number of concurrent Users) as a result.CIRCUITS: As we’ve seen, each Shared Server connection increments the row count of V$CIRCUIT by one. This parameter sets a hard limit on the number of concurrent circuits (that is, concurrent Shared Server connections) that are permitted on the Instance. If you don’t set this, then the value of the SESSIONS parameter is assumed to be the maximum number of circuits that are permitted. (Called MTS_CIRCUITS in 8i and earlier).SESSIONS: The maximum number of concurrent sessions, whether dedicated or shared that are permitted on the Instance. The default appears to be 170.SHARED_SERVER_SESSIONS: The maximum number of concurrent Shared Server connections that are permitted on the Instance. Dedicated connections don’t count towards this total. If this parameter is not set, it defaults to SESSIONS-5, which means that Oracle is assuming that 5 dedicated sessions will be needed on a primarily Shared Server Instance, and thus reserves those expected sessions. (Called MTS_SESSIONS in 8i and earlier).Copyright © Howard Rogers 2002 17/03/2002 Page 7 of 9
  8. 8. Configuring Shared Server (or Multi-Threaded Server) Networking TipsAdvanced init.ora parametersI’m not going to go into detail here, but there are things you can do to some of the init.oraparameters I’ve already mentioned which get us into the realm of advanced Shared Serverconfigurations.The main culprit is the DISPATCHERS init.ora parameter. That can take a number ofadditional parameters, above and beyond the two we mentioned earlier. So far, we’ve gotthis:DISPATCHERS=”(PROTOCOL=TCP)(DISPATCHERS=2)”…which means ‘create me 2 dispatchers, both working on the TCP/IP protocol. There’snothing to stop you doing this:DISPATCHERS=”(PROTOCOL=TCP)(DISPATCHERS=2)”DISPATCHERS=”(PROTOCOL=IPC)(DISPATCHERS=1)”DISPATCHERS=”(PROTOCOL=TCPS)(DISPATCHERS=3)”… which means you’ll have 6 Dispatchers, 2 working on TCP/IP, 3 working on secure TCP/IPand 1 on the IPC protocol. To have multi-protocol Dispatchers, however, requires that youconfigure your Listener to listen on the same protocols.You can force the Dispatchers to work with non-default Listeners, too. That would looklike this:DISPATCHERS=”(PROTOCOL=TCP)(DISPATCHERS=2)(LISTENER=XYZ)”That “XYZ” is actually a service name alias, meaning that there needs to be a server-sidetnsnames.ora file to resolve that into a location (host and port number) where a non-default Listener can be found. The 2 Dispatchers thus configured will register themselveswith this Listener, rather than the default one found on the Server. You’ll need toconfigure like this if you’ve chosen not to have your Listener listening on the standard 1521port, for example.Two other variations to the DISPATCHERS parameter spring to mind: Multiplexing andConnection Pooling. To configure those, you’d end up with this:DISPATCHERS=”(PROTOCOL=TCP)(DISPATCHERS=2)(MULTIPLEX=ON)(POOL=ON)”Session Multiplexing is a feature of Connection Manager, whereby many Users makeseparate connections to a Connection Manager server, and it then establishes a singleconnection to the back-end database. That spares your back-end server from having tosupport thousands of individual direct connections, and compromising performance as aresult.Copyright © Howard Rogers 2002 17/03/2002 Page 8 of 9
  9. 9. Configuring Shared Server (or Multi-Threaded Server) Networking TipsConnection Pooling is a way of sort-of disconnecting an idle User, thus making hisconnection circuit available for someone else, and then automatically re-connecting himwhen he starts performing real work again (this is very commonly used when you’re dealingwith web connections to the database). In this way, a fixed number of available circuitscan actually be made to service the requests from many more real Users than you mighthave expected.All of these features are fiendishly clever, but this is not the place to start discussing theintricacies of their configuration. At this stage, I simply wanted to point out that, if youneed to, there’s far more to Shared Server configurations than just getting it working. Still:if you managed to get it working at all, congratulate yourself!Copyright © Howard Rogers 2002 17/03/2002 Page 9 of 9