IDS Forum

RE: DBSPACETEMP Variable

Posted By: Konikoff, Rob (Contractor)
Date: Thursday, 15 July 2004, at 10:56 a.m.

In Response To: RE: DBSPACETEMP Variable (Olson, Kenneth \(GEI, GEFA\))

Kenneth:
I read the same references you read. (I keep them handy!)

I believe it to be true based on the performance we get here.
I'm on:
IDS 7.23.UC11
SQL 7.20.UD1

Read Dan Michaels response to the group and you'll see what I mean. He said
it much better than I was going to put it.

Anyone else care to chip in!?

Rob

-----Original Message-----
From: Olson, Kenneth (GEI, GEFA) [mailto:Kenneth.Olson@ge.com]
Sent: Thursday, July 15, 2004 10:20 AM
To: Konikoff, Rob (Contractor)
Subject: RE: DBSPACETEMP Variable [3248]

Thanks, but is it true that if you add a chunk without the "T" option to the
DBSPACETEMP Variable all the temp table will be built there regardless of
logged or not?

-----Original Message-----
From: Konikoff, Rob (Contractor) [mailto:konikoffr@BRAGG.ARMY.MIL]
Sent: Thursday, July 15, 2004 9:08 AM
To: Olson, Kenneth (GEI, GEFA); ids@iiug.org
Subject: RE: DBSPACETEMP Variable [3248]


Yes, that is true...

I build temp tables routinely without logs for inquiry only so that we save
processing burden and reduce tape IO. We fill up logs pretty quickly in our
OLTP DB, so this helps control system effort.

If you don't specify "with no log;" then it defaults to the database
default, logged or not logged.

Note: If you are making changes to the dataset via ad hoc queries, LOG YOUR
TRANSACTIONS. Just In Case (JIC) is a viable argument.

Rob
-----Original Message-----
From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On Behalf
Of Olson, Kenn....
Sent: Thursday, July 15, 2004 9:18 AM
To: ids@iiug.org
Subject: RE: DBSPACETEMP Variable [3248]

Wow, can anyone confirm this? Thanks.

-----Original Message-----
From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org]On
Behalf Of Simmons, Keith
Sent: Thursday, July 15, 2004 2:45 AM
To: ids@iiug.org
Subject: RE: DBSPACETEMP Variable [3246]


Anthony

There are two types of temporary table, those created 'WITH NO LOG', which
are unlogged, and those without this caveat which are logged in the same
way as any permanent tables in the database.
There are also two type of dbspaces. Those created with the '-t' option
which can only contain unlogged tables and those created without this option
which can only contain logged tables. The '-t' option doesn't really mean
temporary, more it means unlogged.
The solution to you problem is to create a dbspace without the '-t' option,
but include it in the colon (':') separated list of dbspaces in the
DBSPACETEMP parameter of you onconfig file.
If you do this the logged temp tables will go in the logged temp dbspace
(until it fills then they will default to rootdbspace) and the unlogged
tables will go into the unlogged temp space.

-> -----Original Message-----
-> From: Anthony.Oje.... [mailto:Anthony.Ojeda@LW.com]
-> Sent: Wednesday, July 14, 2004 10:47 PM
-> To: ids@iiug.org
-> Subject: DBSPACETEMP Variable [3245]
->
->
-> I'm running into a situation where temporary tables created
-> by "SELECT
-> .... INTO TEMP tmptablename" are using space from the root dbspace
-> instead of our temp dbspace. Both the onconfig and environment
-> DBSPACETEMP variables are set to the temp dbspace that is flagged as
-> temporary space (see below). The only way I can force the temporary
-> table to use the temp dbspace is to add "WITH NO LOG" to the SQL
-> statement. I've consulted Ron Flannery's "The Informix Handbook",
-> "Informix Online Dynamic Server Performance Guide", and the "Informix
-> Guide to SQL", each of which say that all I need to do is set the
-> DBSPACETEMP variable in either the onconfig file or environment, and
-> make sure my temp dbspace was created with onspaces' "-t" control
-> argument.
->
->
->
-> :/ >onstat -c |grep -i dbspacetemp
-> # DBSPACETEMP:
-> DBSPACETEMP tempdbs #Default temp dbspaces
->
->
->
-> :/ >onstat -d |more
-> Dbspaces
-> address number flags fchunk nchunks flags owner name
-> 9de4c158 1 1 1 1 N
-> informix rootdbs
-> 9e8a5a58 2 1 2 1 N informix logdbs
-> 9e8a5b18 3 1 3 56 N informix
-> elitedbs
-> 9e8a5bd8 4 2001 29 8 N T
-> informix tempdbs
->
->
->
-> Thanks,=20
->
-> Anthony Ojeda
-> Senior Systems Administrator
->
-> LATHAM & WATKINS LLP
-> 555 W. 5th Street, Suite 800
-> Los Angeles, CA 90013-1010
-> Direct Tel: (213) 891-7211
-> =46ax: (213) 891-7123
-> E-mail: anthony.ojeda@lw.com
-> www.lw.com
->
->
-> This email may contain material that is confidential,
-> privileged and/or attorney work product for the sole use of
-> the intended recipient. Any review, reliance or
-> distribution by others or forwarding without express
-> permission is strictly prohibited. If you are not the
-> intended recipient, please contact the sender and delete all copies.
->
-> Latham & Watkins LLP
->
->
->


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

Messages In This Thread

• DBSPACETEMP Variable
  Anthony.Ojeda@LW.com -- Wednesday, 14 July 2004, at 5:47 p.m.
  • RE: DBSPACETEMP Variable
    Simmons, Keith -- Thursday, 15 July 2004, at 3:44 a.m.
    • RE: DBSPACETEMP Variable
      Olson, Kenneth \(GEI, GEFA\) -- Thursday, 15 July 2004, at 9:18 a.m.
      • RE: DBSPACETEMP Variable
        Konikoff, Rob (Contractor) -- Thursday, 15 July 2004, at 10:56 a.m.
    • RE: DBSPACETEMP Variable
      Simmons, Keith -- Thursday, 15 July 2004, at 10:42 a.m.
  • RE: DBSPACETEMP Variable
    Michaelis, Daniel -- Thursday, 15 July 2004, at 10:05 a.m.
  • RE: DBSPACETEMP Variable
    Anthony.Ojeda@LW.com -- Thursday, 15 July 2004, at 10:22 a.m.
  • Re: DBSPACETEMP Variable
    GARY GU -- Tuesday, 20 July 2004, at 2:41 a.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.