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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
