| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Oracle on windows and shadow thread file access
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:Received on Fri Nov 29 2002 - 10:18:42 CST
> 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).
 |
 |