Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: max number of handles 9.2, win32, partitioning

Re: max number of handles 9.2, win32, partitioning

From: Tanel Põder <>
Date: Fri, 30 Jul 2004 03:19:02 +0300
Message-ID: <02d401c475ca$d25ed390$36ae9fd9@porgand>


> What is the largest number of user sessions *
> datafiles = filesystem handles that you've encountered
> in win32 land?

Hm, strange, I always thought that due the single-process architecture in Win32, Oracle shares the file handles, but now when I started thinking a bit about OS IO architecture and checked with process explorer, I see that yes, there are separate handles for some objects (btw, handles in Windows may mean file handles, registry handles and a great deal of other types of handles which I don't know..)

> I had the bright idea of partitioning several large
> tables at a client site that are frequently hit, that
> typically supports 250 simultaneous sessions.

That's dedicated server config?

> I'm currently seeing around 6000 handles for 225
> threads in a non-partitioned setup for a single
> oracle.exe process.

I never checked the handle count, but the largest handle count could have been on a 8.0 database with 600-700 datafiles and about 800 concurrent users with dedicated sessions on WinNT 4.0 SP5. This was about 4 years ago, so I guess Oracle9.2 on W2k should cope with more novadays..

> I'm aware of the parameter session_max_open_files and
> will have to bump it up.

This relates to BFILES only...

> To sum it up, If I partition 42 tables into 42
> partitions (months) that each have 42 indexes and 42
> users simultaneously access the application, will it
> throw an ora-00942 error? :)

The handle usage isn't dependant on structure inside the Oracle datafiles, it depends on how many datafiles you have and how many processes (!) you have accessing those datafiles (as you asked in your first question).

> thanks in advance.

my 2 cents :)


Please see the official ORACLE-L FAQ:

To unsubscribe send email to: put 'unsubscribe' in the subject line.
Archives are at
FAQ is at
Received on Thu Jul 29 2004 - 19:15:35 CDT

Original text of this message