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

David Linthwaite wrote: > > 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. Land's sakes! Someone who reads a manual! I suspect this just for performance reasons, I don't know of any reason a temporary dbspace *can't* be cooked. The system would be slower than a sloth mating dance if temporary dbspaces were cooked files. -- Strewth! Stick a sock in it, Sheila!