RE: Oracle on windows and shadow thread file access
Title: RE: Oracle on windows and shadow thread file access I recently downloaded program which is like 'truss' but works in windows environment ... called strace ... from sysinternals.com it shows all files it accesses and all sys calls it makes. Not exactly what you need ... but close by I guess .. they also have a bunch of utilities one that might interest you is filemon. www.sysinternals.com is a good site ... I found it few years ago and I regularly visit them to find neat tools. Raj __ Rajendra Jamadagni MIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed here is personal and doesn't reflect that of ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an art! *This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*1
RE: Oracle on windows and shadow thread file access
I guess it has to do with the fact that Oracle on Windows is a single process multithreads. So any opened file in the main thread will be accessible and opened for the spawned threads (correct me if I'm wrong). So concurrent access to the files would need to be controlled by O/S resources like mutex. It would be helpful if some one with multithread programming experience in Windows could shed some light here. Regards, Waleed -Original Message- Sent: Monday, December 02, 2002 2:49 PM To: Multiple recipients of list ORACLE-L On UNIX, when a user process needs to access data, it will open the files of interest. The background processes 'attach' to all of the files when the OPEN state of the database is achieved. They do not open each file when they need to read/write. For example, CKPT attaches to the files and will maintain the handle as long as the process is running. Why do I know this, you ask? One afternoon, a support tech moved a datafile since the device was 95% full. User queries would fail when trying to open the file, but checkpoints were succeeding and we could even dump the file headers without any problem. After discussing this situation with the SAs, we postulated that the background processes were keeping the files open and thus were still attached to the files original location. If we shutdown the background processes, the files would have been closed and the original blocks released. Once we resolved the issue, the support techs were scheduled for Oracle 101 training immediately! On Windows, they handle files slightly differently and I am not sure. -Original Message- Sent: Friday, November 29, 2002 3:34 PM To: Multiple recipients of list ORACLE-L On Friday 29 November 2002 08:43, Jeff Herrick wrote: > My understanding > from the question was that he was wondering whether each > user's process in a dedicated-server configuration opened > all of the datafiles too Maybe not all of the data files, but the users dedicated server process will open datafiles as needed to read data into the block buffer. Now I don't know if I've helped any, or just added to the confusion. Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Fink, Dan 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Khedr, Waleed 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).
RE: Oracle on windows and shadow thread file access
On UNIX, when a user process needs to access data, it will open the files of interest. The background processes 'attach' to all of the files when the OPEN state of the database is achieved. They do not open each file when they need to read/write. For example, CKPT attaches to the files and will maintain the handle as long as the process is running. Why do I know this, you ask? One afternoon, a support tech moved a datafile since the device was 95% full. User queries would fail when trying to open the file, but checkpoints were succeeding and we could even dump the file headers without any problem. After discussing this situation with the SAs, we postulated that the background processes were keeping the files open and thus were still attached to the files original location. If we shutdown the background processes, the files would have been closed and the original blocks released. Once we resolved the issue, the support techs were scheduled for Oracle 101 training immediately! On Windows, they handle files slightly differently and I am not sure. -Original Message- Sent: Friday, November 29, 2002 3:34 PM To: Multiple recipients of list ORACLE-L On Friday 29 November 2002 08:43, Jeff Herrick wrote: > My understanding > from the question was that he was wondering whether each > user's process in a dedicated-server configuration opened > all of the datafiles too Maybe not all of the data files, but the users dedicated server process will open datafiles as needed to read data into the block buffer. Now I don't know if I've helped any, or just added to the confusion. Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Fink, Dan 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).
RE: Oracle on windows and shadow thread file access
> Maybe not all of the data files, but the users dedicated server > process will open datafiles as needed to read data into the > block buffer. > > Now I don't know if I've helped any, or just added to the confusion. > > Jared No, that was pretty much what I wanted to know - was there any time when a user's dedicated server process - as opposed to smon, pmon, chpt, arch, lgwr, dbwr, etc. - actually acquired a file handle and opened the file. Thanks for the discussion on this. Ciao Fuzzy :-) -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Grant Allen 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).
Re: Oracle on windows and shadow thread file access
Jared, You're right. There's a cool diagram in the Server Concepts manual. So back to the original issue, scalabilty could be affected in a dedicated server configuration depending on how many files needed to be opened. I guess the problem could be mitigated by fewer/larger datafiles and/or MTS Cheers On Fri, 29 Nov 2002, Jared Still wrote: > On Friday 29 November 2002 08:43, Jeff Herrick wrote: > > My understanding > > from the question was that he was wondering whether each > > user's process in a dedicated-server configuration opened > > all of the datafiles too > > Maybe not all of the data files, but the users dedicated server > process will open datafiles as needed to read data into the > block buffer. > > Now I don't know if I've helped any, or just added to the confusion. > > Jared > > > but I might have mis-understood the question. > > > > 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? > > > > [snip] > > > > > > 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: Jared Still > 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). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jeff Herrick 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).
Re: Oracle on windows and shadow thread file access
On Friday 29 November 2002 08:43, Jeff Herrick wrote: > My understanding > from the question was that he was wondering whether each > user's process in a dedicated-server configuration opened > all of the datafiles too Maybe not all of the data files, but the users dedicated server process will open datafiles as needed to read data into the block buffer. Now I don't know if I've helped any, or just added to the confusion. Jared > but I might have mis-understood the question. > > 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? > > [snip] > > > > 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: Jared Still 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).
Re: Oracle on windows and shadow thread file access
Jeremiah I _did_ say the background oracle 'processes' meaning lgwr,dbwr,ckpt threads on Win32 specifically. My understanding from the question was that he was wondering whether each user's process in a dedicated-server configuration opened all of the datafiles too but I might have mis-understood the question. 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? > [snip] > > 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: Jeff Herrick 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).
Re: Oracle on windows and shadow thread file access
You'd hit "nfile" limits on HPUX [or at least HPUX 10.xx] pretty quickly. Hemant At 06:43 AM 29-11-02 -0800, you 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. Cheers Jeff Herrick 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? > > Ciao > Fuzzy > :-) > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Grant Allen > 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). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jeff Herrick 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). Hemant K Chitale My web site page is : http://hkchital.tripod.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Hemant K Chitale 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).
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: > 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,0x7532 20465 /var/spool/pwgr/status > oracleorc 29290 oracle txt VREG 64,0x10002 3855 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,0x61572640 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,0x100027101192 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 oracle0r VCHR 3,0x20t066 /dev/null > oracleorc 29290 oracle1w VREG 64,0x5 1177 6173 >/tmp/listener_L_ORCL_start.out > oracleorc 29290 oracle2w VREG 64,0x5 1177 6173 >/tmp/listener_L_ORCL_start.out > oracleorc 29290 oracle3r VCHR 3,0x20t066 /dev/null > oracleorc 29290 oracle4r VCHR 3,0x20t066 /dev/null > oracleorc 29290 oracle5r VCHR 3,0x20t066 /dev/null > oracleorc 29290 oracle6u inet 0x4ecd06680t0 TCP *:* (IDLE) > oracleorc 29290 oracle7r VCHR 3,0x20t066 /dev/null > oracleorc 29290 oracle8u unix 0x4a1c8e000t0 >/var/spool/sockets/pwgr/client29290 > oracleorc 29290 oracle9r 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
Re: Oracle on windows and shadow thread file access
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,0x7532 20465 /var/spool/pwgr/status oracleorc 29290 oracle txt VREG 64,0x10002 3855 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,0x61572640 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,0x100027101192 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 oracle0r VCHR 3,0x20t066 /dev/null oracleorc 29290 oracle1w VREG 64,0x5 1177 6173 /tmp/listener_L_ORCL_start.out oracleorc 29290 oracle2w VREG 64,0x5 1177 6173 /tmp/listener_L_ORCL_start.out oracleorc 29290 oracle3r VCHR 3,0x20t066 /dev/null oracleorc 29290 oracle4r VCHR 3,0x20t066 /dev/null oracleorc 29290 oracle5r VCHR 3,0x20t066 /dev/null oracleorc 29290 oracle6u inet 0x4ecd06680t0 TCP *:* (IDLE) oracleorc 29290 oracle7r VCHR 3,0x20t066 /dev/null oracleorc 29290 oracle8u unix 0x4a1c8e000t0 /var/spool/sockets/pwgr/client29290 oracleorc 29290 oracle9r 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 (contro
RE: Oracle on windows and shadow thread file access
Thanks Jeff. The more I thought of it, the more I thought this had to be the case (e.g. only SMON, PMON, ARCH, etc. actually handled file access), but the topic raised just enough curiosity in my mind to seek another opinion. Ciao Fuzzy :-) > 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. > > Cheers > > Jeff Herrick -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Grant Allen 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).
Re: Oracle on windows and shadow thread file access
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. Cheers Jeff Herrick 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? > > Ciao > Fuzzy > :-) > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Grant Allen > 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). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jeff Herrick 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).