Oracle-L: Re: Oracle on windows and shadow thread file access

From: Jeremiah Wilton <jwilton_at_speakeasy.net>
Date: Fri, 29 Nov 2002 07:19:08 -0800
Message-ID: <F001.0050EF9C.20021129071908@fatcity.com>

On Fri, 29 Nov 2002, Jeff Herrick wrote:

> None...only the oracle background processes (threads in Winblows)
> access the datafiles/logfiles etc. All other communication is
> done through the SGA. On some Unix variants you _can_ reach
> a file_open max kernel parameter because each process (in a
> dedicated server scenario) opens it's own stdin/stdout/stderr.
> I guess the same could be true of processes running under
> windows too. So in the limit...you could hit a wall but only
> due to the per-process overhead.

Uh, I'm probably not going to be the only one to point out this isn't true. I don't know about Win32 thread architecture, but in Unix and unix-like operating systems, the shadow (server) processes each open whatever files they need for write. It is true that they also open the shared memory segments in order to write and read from the SGA, but they do the reading from disk. Otherwise, which process do you think is reading from the datafiles?

A sample lsof of a typical server process: unixhost# lsof -p 29290

COMMAND     PID   USER   FD   TYPE     DEVICE   SIZE/OFF  NODE NAME
oracleorc 29290 oracle  cwd   VDIR 64,0x10002      22528 10090 /oracle/product/8.1.7/dbs
oracleorc 29290 oracle  mem   VREG     64,0x7        532 20465 /var/spool/pwgr/status
oracleorc 29290 oracle  txt   VREG 64,0x10002   38558888 22842 /oracle/product/8.1.7/bin/oracle
oracleorc 29290 oracle  mem   VREG     64,0x6      13215  3024 /usr/lib/tztab
oracleorc 29290 oracle  mem   VREG     64,0x6    1572640  6873 /usr/lib/pa20_64/libc.2
oracleorc 29290 oracle  mem   VREG     64,0x6     274664  8414 /usr/lib/pa20_64/libm.2
oracleorc 29290 oracle  mem   VREG     64,0x6      24032  8484 /usr/lib/pa20_64/libdl.1
oracleorc 29290 oracle  mem   VREG     64,0x6      23336  2688 /usr/lib/pa20_64/libnss_dns.1
oracleorc 29290 oracle  mem   VREG     64,0x6     131264 19010 /usr/lib/pa20_64/libpthread.1
oracleorc 29290 oracle  mem   VREG     64,0x6      24896  2671 /usr/lib/pa20_64/librt.2
oracleorc 29290 oracle  mem   VREG 64,0x10002      40600  3388 /oracle/product/8.1.7/lib64/libdsbtsh8.sl
oracleorc 29290 oracle  mem   VREG 64,0x10002    7101192  3390 /oracle/product/8.1.7/lib64/libjox8.sl
oracleorc 29290 oracle  mem   VREG     64,0x6     289000  8482 /usr/lib/pa20_64/dld.sl
oracleorc 29290 oracle    0r  VCHR      3,0x2        0t0    66 /dev/null
oracleorc 29290 oracle    1w  VREG     64,0x5       1177  6173 /tmp/listener_L_ORCL_start.out
oracleorc 29290 oracle    2w  VREG     64,0x5       1177  6173 /tmp/listener_L_ORCL_start.out
oracleorc 29290 oracle    3r  VCHR      3,0x2        0t0    66 /dev/null
oracleorc 29290 oracle    4r  VCHR      3,0x2        0t0    66 /dev/null
oracleorc 29290 oracle    5r  VCHR      3,0x2        0t0    66 /dev/null
oracleorc 29290 oracle    6u  inet 0x4ecd0668        0t0   TCP *:* (IDLE)
oracleorc 29290 oracle    7r  VCHR      3,0x2        0t0    66 /dev/null
oracleorc 29290 oracle    8u  unix 0x4a1c8e00        0t0       /var/spool/sockets/pwgr/client29290
oracleorc 29290 oracle    9r  VREG 64,0x10002     360448  2274 /oracle/product/8.1.7/rdbms/mesg/oraus.msb

oracleorc 29290 oracle 10u VCHR 64,0x3000e 0x512bc000 2233 /dev/data3/rorclsession_item-01 oracleorc 29290 oracle 11u inet 0x515d3a68 0t1684264 TCP unixhost.corporation.com:1541->clienthost.corporation.com:1577 (ESTABLISH ED)

oracleorc 29290 oracle   12u  VCHR 64,0x3000f  0x842c000  2237 /dev/data3/rorclts1_idx-02
oracleorc 29290 oracle   13u  VCHR 64,0x10078  0xaacc000  2197 /dev/data1/rorclts1-02
oracleorc 29290 oracle   14u  VCHR 64,0x2006a 0t59826176  2203 /dev/data2/rorclts1_idx-01
oracleorc 29290 oracle   15u  VCHR 64,0x1006d  0xad0a000  2050 /dev/data1/rorclts1-01
oracleorc 29290 oracle   16u  VCHR 64,0x20078 0t89505792  2231 /dev/data2/rorclts2-01
oracleorc 29290 oracle   17u  VCHR 64,0x30015 0x16aa2000  2248 /dev/data3/rorclts3_idx-02
oracleorc 29290 oracle   18u  VCHR 64,0x20073 0x6a144000  2221 /dev/data2/rorclts3_idx-01
oracleorc 29290 oracle   19u  VCHR 64,0x30010 0x3819c000  2239 /dev/data3/rorclts4_idx-02
oracleorc 29290 oracle   20u  VCHR 64,0x20072 0x375a8000  2219 /dev/data2/rorclts4_idx-01
oracleorc 29290 oracle   21u  VCHR 64,0x1006f 0x77b6a000  2179 /dev/data1/rorclts3-01
oracleorc 29290 oracle   22u  VCHR 64,0x10079 0x75c94000  2199 /dev/data1/rorclts3-02

--
Jeremiah Wilton
http://www.speakeasy.net/~jwilton



> On Fri, 29 Nov 2002, Grant Allen wrote:

> 

> > Saw an interesting post in comp.databases.oracle.server postulating that if

> > a shadow thread needed an open file handle on all files in a instance (or

> > even some of them), the process handle limit in windows could constrain user

> > scalability (e.g. too many users would result in ora-12500 unable to spawn

> > errors and the like).   (Let's ignore MTS/shared server mode for the moment)

> >

> > Sounded interesting, but I thought I'd ask if anyone knows whether a shadow

> > thread (or process under unix) does open a handle on each file (control,

> > data, redo), some of them, or none of them?


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Jeremiah Wilton
  INET: jwilton_at_speakeasy.net

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Received on Fri Nov 29 2002 - 09:19:08 CST