BC remote Oracle DBA - Call (800) 766-1884  
Oracle Consulting Oracle Training Development

Remote DBA

Remote DBA Plans  

Remote DBA Service

Remote DBA RAC

   
Remote DBA Oracle Home
Remote DBA Oracle Training
Remote DBA SQL Tuning Consulting
Remote DBA Oracle Tuning Consulting
Remote DBA Data Warehouse Consulting
Remote DBA Oracle Project Management
Remote DBA Oracle Security Assessment
Remote DBA Unix Consulting
Burleson Books
Burleson Articles
Burleson Web Courses
Burleson Qualifications
Oracle Links
Remote DBA Oracle Monitoring
Remote DBA Support Benefits
Remote DBA Plans & Prices
Our Automation Strategy
What We Monitor
Oracle Apps Support
Print Our Brochure
Contact Us (e-mail)
Oracle Job Opportunities
Oracle Consulting Prices





   

 

 

 

Remote DBA services

Remote DBA Support

Remote DBA RAC

Remote DBA Reasons

Remote Oracle Tuning

Remote DBA Links

Oracle DBA Support

Oracle DBA Forum

Oracle Disaster

Oracle Training

Oracle Tuning

Oracle Training

 Remote DBA SQL Server

Remote MSSQL Consulting

Oracle DBA Hosting

Oracle License Negotiation

 

 


 

 

 

 

 

 
 

Oracle Tips 

by Burleson Consulting

The Data Warehouse Development Life Cycle

MANAGING A MULTITHREADED SERVER (MTS)

One of the problems faced by developers using SQL*Net version 1.0 was that each incoming transaction was spawned by the listener as a separate operating system task. With SQL*Net version 2.0, Oracle now has a method for allowing the listener connection to dispatch numerous sub-processes. With the MTS, all communications to a database are handled through a single dispatcher instead of separate Unix process IDs (PIDs) on each database. This translates into faster performance for most online tasks. Even local transactions will be directed through the MTS, and you will no longer see a PID for your local task when you issue ps -ef|grep oracle.

However, be aware that the MTS is not a panacea, especially at times when you want to invoke a dedicated process for your program. For Pro*C programs and I/O-intensive SQL*Forms applications--or any processes that have little idle time--you may derive better performance using a dedicated process.

In general, the MTS offers benefits such as reduced memory use, fewer processes per user, and automatic load balancing. However, it is often very confusing to tell whether the MTS is turned on--much less working properly.

Remember the following rules of thumb when initially starting the MTS:

* The MTS is governed by the init.ora parameters. If no MTS parms are present in init.ora, the MTS is disabled.

* The MTS is used when the MTS parms are in the init.ora and requests are made by service name (such as @myplace). In other words, you must retrieve the ROWID of all version 1.0 connect strings (such as t:unix1:myplace).

* Each user of the MTS requires 1 K of storage, so plan to increase your SHARED_POOL_SIZE.

* The V$QUEUE and V$DISPATCHER system tables indicate when the number of MTS dispatchers is too low. Even though the number of dispatchers is specified in the init.ora file, you can change it online in SQL*Remote DBA with the ALTER SYSTEM command, as follows:

SQLRemote DBA> ALTER SYSTEM SET MTS_DISPATCHERS = 'TCPIP,4';


This is an excerpt from "High Performance Data Warehousing".

If you like Oracle tuning, you may enjoy the book Oracle Tuning: The Definitive Reference , with over 900 pages of BC's favorite tuning tips & scripts. 

You can buy it directly from the publisher and save 30%, and get instant access to the code depot of Oracle tuning scripts.

 


Expert Remote DBA

BC is America's oldest and largest Remote DBA Oracle support provider.  Get real Remote DBA experts, call
BC Remote DBA today.

 

 

Remote DBA Service
 

Oracle Tuning Book

 

Advance SQL Tuning Book 

BC Oracle support

Oracle books by Rampant

Oracle monitoring software

 

 

 

 

 

 

BC Remote Oracle Support

Remote DBA

Remote DBA Services

Copyright © 1996 -  2013 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation.