RE: DBSPACETEMP Variable [3248]

On Fri, 16 Jul 2004 08:53:08 -0400, Simmons, Keith wrote: > David > > Is this something new in 9.? (4 ??). I can find no reference to it in my 7.3 This is real. It's definitely in the 9.4 and 9.3 Administrators Reference manuals both specify RAW devices for temp dbspaces in a clearly delineated italic section. Don't know why that would be either, but there it is. > manuals and it doesn't 'feel' right as follows:- If DBSPACETEMP is not set > the engine will use root dbspace for all its temporary tables/sort files. > Suppose this is on cooked space, will the engine act differently in using > this space? If DBSPACETEMP only contains unlogged (-t) spaces. It will > therefore use rootdbs for logged temp tables, again will there be different All true. > actions if this root dbspace is on cooked file store, and how does the > engine 'know' the diference? Getting above my head now, would someone in the > know wish to comment/elucidate further. Actually the engine can tell if the chunk is RAW or COOKED just by calling the stat() system call on the chunk. It can even know that the chunk is actually a link and follow the links to stat() the underlying file/device. I've done that myself. The engine has to know if the chunk is RAW or COOKED to know if it has to open the chunk in OSYNC mode (COOKED) or not (RAW) because OSYNCH mode operations are MUCH slower EVEN on RAW chunks that do not need separate synch operations (hmm perhaps that's why the big O does not get as much gain from RAW disk as IDS does? 8^) Art S. Kagel > Keith > > -> -----Original Message----- > -> From: David Linthwaite [mailto:dlinthwaite@lintel.co.uk] -> Sent: Friday, > July 16, 2004 10:40 AM -> To: informix-list@iiug.org -> Subject: RE: > DBSPACETEMP Variable [3248] -> -> > -> Keith > ->> -> The following is an extract from the administrators reference manual: -> > -> ".....The list of dbspaces can contain standard dbspaces, temporary -> > dbspaces, or > -> both. Use a colon or comma to separate the dbspaces in your list. If -> > both > -> standard and temporary dbspaces are listed in the DBSPACETEMP -> > configuration > -> parameter or environment variable, the following rules apply: -> Sort, > backup, implicit, and nonlogging explicit temporary tables are -> created in > temporary dbspaces if adequate space exists. -> Explicit temporary tables > created without the WITH NO LOG option -> are created in standard (rather > than temporary) dbspaces. -> Important: The dbspaces that you list in the > DBSPACETEMP -> configuration> -> parameter must be composed of chunks that are allocated as unbuffered -> > (sometimes > -> referred to as "raw") UNIX devices....." -> -> This may be to do with > recoverability under specific crash conditions -> since the spaces are not > logged rather than the ability to use as -> temporary storage, although this > is just a guess - maybe the book is -> wrong. -> > -> Regards > -> > -> David Linthwaite > -> Lintel Software Consultancy Ltd > -> IBM Business Partner > -> > -> Tel: 01244 316297 > -> Fax: 01244 357248 > -> mailto:dlinthwaite@lintel.co.uk > -> > -> > -> > -> -----Original Message----- > -> From: owner-informix-list@iiug.org > -> [mailto:owner-informix-list@iiug.org] -> On Behalf Of Simmons, Keith -> > Sent: 16 July 2004 09:00 > -> To: informix-list@iiug.org > -> Subject: RE: DBSPACETEMP Variable [3248] -> -> -> See Below > -> > -> -> -----Original Message----- > -> -> From: David Linthwaite [mailto:dlinthwaite@lintel.co.uk] -> -> Sent: > Thursday, July 15, 2004 4:37 PM -> -> To: informix-list@iiug.org -> -> > Subject: RE: DBSPACETEMP Variable [3248] -> -> -> -> -> -> Anthony > -> -> > -> -> A few things to check: > -> -> > -> -> 1. The environment variable takes priority over -> the 'onconfig' -> > -> setting. Perhaps unset the environment variable in case -> it is being > -> -> picked up incorrectly. > -> -> 2. onstat -c reads from the configuration file on -> disk and is -> -> > therefore not necessarily what you are running with. -> -> 3. if my memory > serves me right, temporary -> dbspaces must be raw - -> -> are you using the > character special devices. -> -> I am not aware of this and can see (nor > find) any reason why temp -> dbspaces cannot be cooked any more than normal > dbspaces cannot be -> cooked. -> > -> -> > -> -> Regards > -> -> > -> -> David Linthwaite > -> -> Lintel Software Consultancy Ltd > -> -> IBM Business Partner > -> -> > -> -> Tel: 01244 316297 > -> -> Fax: 01244 357248 > -> -> mailto:dlinthwaite@lintel.co.uk > -> -> > -> <SNIP> > -> -> > -> > -> Keith > -> > -> > -> ************************************************************* -> > *********** > -> ********** > -> This message is sent in strict confidence for the addressee only. It -> > may contain legally privileged information. The contents are -> not to be -> > disclosed to anyone other than the addressee. Unauthorised recipients -> are > requested to preserve this confidentiality and to advise -> the sender -> > immediately of any error in transmission. This footnote also confirms -> > that this email message has been swept for the presence of computer -> > viruses, however we cannot guarantee that this message is -> free from such > -> problems. > -> ************************************************************* -> > *********** > -> ********** > -> > -> > -> sending to informix-list > -> > -> sending to informix-list > -> > > sending to informix-list

David Is this something new in 9.? (4 ??). I can find no reference to it in my 7.3 manuals and it doesn't 'feel' right as follows:- If DBSPACETEMP is not set the engine will use root dbspace for all its temporary tables/sort files. Suppose this is on cooked space, will the engine act differently in using this space? If DBSPACETEMP only contains unlogged (-t) spaces. It will therefore use rootdbs for logged temp tables, again will there be different actions if this root dbspace is on cooked file store, and how does the engine 'know' the diference? Getting above my head now, would someone in the know wish to comment/elucidate further. Keith -> -----Original Message----- -> From: David Linthwaite [mailto:dlinthwaite@lintel.co.uk] -> Sent: Friday, July 16, 2004 10:40 AM -> To: informix-list@iiug.org -> Subject: RE: DBSPACETEMP Variable [3248] -> -> -> Keith -> -> The following is an extract from the administrators reference manual: -> -> ".....The list of dbspaces can contain standard dbspaces, temporary -> dbspaces, or -> both. Use a colon or comma to separate the dbspaces in your list. If -> both -> standard and temporary dbspaces are listed in the DBSPACETEMP -> configuration -> parameter or environment variable, the following rules apply: -> Sort, backup, implicit, and nonlogging explicit temporary tables are -> created in temporary dbspaces if adequate space exists. -> Explicit temporary tables created without the WITH NO LOG option -> are created in standard (rather than temporary) dbspaces. -> Important: The dbspaces that you list in the DBSPACETEMP -> configuration -> parameter must be composed of chunks that are allocated as unbuffered -> (sometimes -> referred to as "raw") UNIX devices....." -> -> This may be to do with recoverability under specific crash conditions -> since the spaces are not logged rather than the ability to use as -> temporary storage, although this is just a guess - maybe the book is -> wrong. -> -> Regards -> -> David Linthwaite -> Lintel Software Consultancy Ltd -> IBM Business Partner -> -> Tel: 01244 316297 -> Fax: 01244 357248 -> mailto:dlinthwaite@lintel.co.uk -> -> -> -> -----Original Message----- -> From: owner-informix-list@iiug.org -> [mailto:owner-informix-list@iiug.org] -> On Behalf Of Simmons, Keith -> Sent: 16 July 2004 09:00 -> To: informix-list@iiug.org -> Subject: RE: DBSPACETEMP Variable [3248] -> -> -> See Below -> -> -> -----Original Message----- -> -> From: David Linthwaite [mailto:dlinthwaite@lintel.co.uk] -> -> Sent: Thursday, July 15, 2004 4:37 PM -> -> To: informix-list@iiug.org -> -> Subject: RE: DBSPACETEMP Variable [3248] -> -> -> -> -> -> Anthony -> -> -> -> A few things to check: -> -> -> -> 1. The environment variable takes priority over -> the 'onconfig' -> -> setting. Perhaps unset the environment variable in case -> it is being -> -> picked up incorrectly. -> -> 2. onstat -c reads from the configuration file on -> disk and is -> -> therefore not necessarily what you are running with. -> -> 3. if my memory serves me right, temporary -> dbspaces must be raw - -> -> are you using the character special devices. -> -> I am not aware of this and can see (nor find) any reason why temp -> dbspaces cannot be cooked any more than normal dbspaces cannot be -> cooked. -> -> -> -> -> Regards -> -> -> -> David Linthwaite -> -> Lintel Software Consultancy Ltd -> -> IBM Business Partner -> -> -> -> Tel: 01244 316297 -> -> Fax: 01244 357248 -> -> mailto:dlinthwaite@lintel.co.uk -> -> -> <SNIP> -> -> -> -> Keith -> -> -> ************************************************************* -> *********** -> ********** -> This message is sent in strict confidence for the addressee only. It -> may contain legally privileged information. The contents are -> not to be -> disclosed to anyone other than the addressee. Unauthorised recipients -> are requested to preserve this confidentiality and to advise -> the sender -> immediately of any error in transmission. This footnote also confirms -> that this email message has been swept for the presence of computer -> viruses, however we cannot guarantee that this message is -> free from such -> problems. -> ************************************************************* -> *********** -> ********** -> -> -> sending to informix-list -> -> sending to informix-list -> sending to informix-list