RE: Oracle on windows and shadow thread file access

2002-12-02 Thread Grant Allen
 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

2002-12-02 Thread Fink, Dan
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

2002-12-02 Thread Khedr, Waleed
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

2002-12-02 Thread Jamadagni, Rajendra
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



Oracle on windows and shadow thread file access

2002-11-29 Thread Grant Allen
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).




Re: Oracle on windows and shadow thread file access

2002-11-29 Thread Jeff Herrick

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).




RE: Oracle on windows and shadow thread file access

2002-11-29 Thread Grant Allen
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

2002-11-29 Thread Jeremiah Wilton
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 (control,
  data, redo), some of 

Re: Oracle on windows and shadow thread file access

2002-11-29 Thread Jeremiah Wilton
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 if
   a shadow thread needed an open file handle on all files in a instance (or
   even some of them), 

Re: Oracle on windows and shadow thread file access

2002-11-29 Thread Hemant K Chitale

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

2002-11-29 Thread Jeff Herrick

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

2002-11-29 Thread Jared Still
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

2002-11-29 Thread Jeff Herrick

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).