Yes, I meant "files they need for read." No matter how many times you proofread before sending...
A shadow server process would only write if it were using direct path insert /*+append*/ or sqlldr or sorting to TEMP. -- Jeremiah Wilton http://www.speakeasy.net/~jwilton On Fri, 29 Nov 2002, Jeremiah Wilton wrote: > 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).
