PSORT_DBTEMP does not work
Heinz set PSORT_DBTEMP=/online but found that while CREATE INDEX wrote sort files there, a large GROUP BY/ORDER BY query appeared to use the tmpdbs temp dbspace instead (failing with error 264/131 when it filled). Art Kagel explained sorts may fit in memory or be satisfied by an index, and that the _temptable in the temp dbspace holds the GROUP BY results (needed for further processing such as HAVING), with sort work files still going to PSORT_DBTEMP. Fernando Nunes and Art also noted the plan used an AUTOINDEX, suggesting a permanent index on vzswiegdat (vzswerk, vzsbuchkr, vzswaagnr, vzsdatum). Behaviour was explained rather than a bug fixed.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hello,
IBM Informix Dynamic Server Version 11.70.UC7W3
SUSE Linux Enterprise Server 11 (i586) VERSION = 11 PATCHLEVEL = 1
I set:
export PSORT_DBTEMP=/online
env|grep PSO
PSORT_DBTEMP=/online
If I create an Index (with dbaccess) the sortfiles where created in the
directory /online
ls -l /online
-rw------- 1 root informix 90963968 Feb 19 15:48 srt0086779_001
When I started an sql like:
Select .............. from ..... GROUP BY 1, 2, 3, 5, 6, 7, 8 orderby 1,2,3,5,6,7,8;
nothing where created in the directory /online.
Why not?
Doku says:
The PSORT_DBTEMP environment variable specifies the location where the
database server writes the temporary files that the PSORT_NPROCS
environment variable uses to perform a sort.
The database server uses the directory that PSORT_DBTEMP specifies,
even if the environment variable PSORT_NPROCS is not set.
The sortfiles where created in the Temp-Dbspace 'tmpdbs'.
onstat -d:5ff73018 4 0x2001 6 1 2048 N T A
informix tmpdbs
The onconfig has the parameter:
DBSPACETEMP tmpdbs
Any hints would be appreciated
Thanks
Heinz
--
WESTFLEISCH eG * Hauptsitz: Brockhoffstr. 11, 48143 Münster
Amtsgericht Münster: Gen.-Reg. 307
Aufsichtsratsvorsitzender: Josef Lehmenkühler
Vorstand: Dirk Niederstucke (Vorsitzender); Peter Piekenbrock; Gerhard
Meierzuherde; Dr. Helfried Giesen, Geschäftsführer (Sprecher); Carsten
Schruck, Geschäftsführer
Hinweise: Es können nur Mails bis 30 MB empfangen werden.
PowerPoint-Dateien müssen in eine ZIP-Datei gepackt werden.
--------------------------------------------------
Heinz:
There are two possibilities:
1) The sort is fitting completely in memory, so no sort-work files are
needed.
2) The row ordering needed by the GROUP BY and ORDER by clauses are being
satisfied by an index.
You can check the former while the session is still open by looking at the
session's record in the sysmaster:syssesprof table. That will show the
number of disk sorts performed by the session and the total number of sorts
as well as the size of the largest sort. The second condition could be
verified by running the query under SET EXPLAIN ON to see if the query plan
is including a sort or not.
FYI: For best performance set PSORT_DBTEMP to at least three and as many as
six completely independent filesystems if possible.
Art
Art S. Kagel, Principal Consultant
ASK Database Management
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on the IIUG, nor any other organization with which I am
associated either explicitly, implicitly, or by inference. Neither do
those opinions reflect those of other individuals affiliated with any
entity with which I am affiliated nor those of the entities themselves.
On Wed, Feb 19, 2014 at 10:16 AM, Weitkamp Heinz <
Heinz.Weitkamp@westfleisch.de> wrote:
> Hello,
>
> IBM Informix Dynamic Server Version 11.70.UC7W3
> SUSE Linux Enterprise Server 11 (i586) VERSION = 11 PATCHLEVEL = 1
>
> I set:
> export PSORT_DBTEMP=/online
>
> env|grep PSO
> PSORT_DBTEMP=/online
>
> If I create an Index (with dbaccess) the sortfiles where created in the
> directory /online
>
> ls -l /online
> -rw------- 1 root informix 90963968 Feb 19 15:48 srt0086779_001
>
> When I started an sql like:
>
> Select .............. from ..... GROUP BY 1, 2, 3, 5, 6, 7, 8 order> by 1,2,3,5,6,7,8;
>
> nothing where created in the directory /online.
> Why not?
>
> Doku says:
> The PSORT_DBTEMP environment variable specifies the location where the
> database server writes the temporary files that the PSORT_NPROCS
> environment variable uses to perform a sort.
> The database server uses the directory that PSORT_DBTEMP specifies,
> even if the environment variable PSORT_NPROCS is not set.
>
> The sortfiles where created in the Temp-Dbspace 'tmpdbs'.
>
> onstat -d:> 5ff73018 4 0x2001 6 1 2048 N T A
> informix tmpdbs
>
> The onconfig has the parameter:
> DBSPACETEMP tmpdbs>
> Any hints would be appreciated
>
> Thanks
> Heinz
>
> --
> WESTFLEISCH eG * Hauptsitz: Brockhoffstr. 11, 48143 Münster
> Amtsgericht Münster: Gen.-Reg. 307
>
> Aufsichtsratsvorsitzender: Josef Lehmenkühler
> Vorstand: Dirk Niederstucke (Vorsitzender); Peter Piekenbrock; Gerhard
> Meierzuherde; Dr. Helfried Giesen, Geschäftsführer (Sprecher); Carsten
> Schruck, Geschäftsführer
>
> Hinweise: Es können nur Mails bis 30 MB empfangen werden.
> PowerPoint-Dateien müssen in eine ZIP-Datei gepackt werden.
> --------------------------------------------------
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001a11349a0253ac6b04f2c3fd1b
Hello Art,
thanks for the quick reply.
Environment:
PSORT_DBTEMP=/online
DBSPACETEMP=tmpdbs
New experiences:
IDS creates the Table _temptable in the temp_dbspace 'tmpdbs'.
If the temp_dbspace is full then it creates the errormessage:
264: Could not write to a temporary file.
131: ISAM error: no free disk space
If the space of the temp_dbspace is big enough for the created
_temptable then i see temporary files on /online like:
first:
srt0086917_013
at the end a few files:
ove0086899_xxx xxx=various number
What are the 'ovexxxx' files?
The SQL terminates without errors.
Why does ids need the _temptable in the temp_dbspace 'tmpdbs'.
Output of 'set explain on':
QUERY: (OPTIMIZATION TIMESTAMP: 02-20-2014 11:45:15)
------
SELECT AL1.vzswaagnr, AL1.vzszustand, AL1.vzsqualtnr, SUM (AL1.vzsgewich
), AL1.vzsartnr, AL2.arti_bez, AL1.vzskundennr, AL3.kst_kurz_name
FROM
root.vzswiegdat AL1, OUTER root.kulistamm AL3, root.artikel AL2 WHERE
(
AL1.vzskundennr = AL3.kst_kulinr AND AL1.vzsmandant =
AL3.kst_mandant AND AL1.vzsbuchkr = AL3.kst_firma AND
AL1.vzsartnr=AL2.arti_artinr AND AL1.vzsmandant=AL2.arti_mandant AND
AL1.vzsfirma=AL2.arti_firma) AND ((AL1.vzsmandant=1 AND
AL1.vzsfirma=1
AND AL1.vzsbuchkr=11 AND AL1.vzswerk=11 AND AL1.vzswaagnr IN (22, 23,
45,
46, 47, 48) AND AL1.vzsdatum>='01.01.2013')) GROUP BY 1, 2, 3, 5, 6,
7, 8
order by 1,2,3,5,6,7,8
Estimated Cost: 3960305
Estimated # of Rows Returned: 62
Temporary Files Required For: Order By Group By
1) root.al2: INDEX PATH
(1) Index Name: root.keyarti2
Index Keys: arti_mandant arti_firma arti_bez
Lower Index Filter: (root.al2.arti_mandant = 1 AND
root.al2.arti_firma =
1 )
2) root.al1: AUTOINDEX PATH
Filters:
Table Scan Filters: (((root.al1.vzswerk = 11 AND
root.al1.vzsbuchkr = 11
) AND root.al1.vzswaagnr IN (22 , 23 , 45 , 46 , 47 , 48 )) AND
root.al1.vzsdat
um >= 01.01.2013 )
(1) Index Name: (Auto Index)
Index Keys: vzsartnr vzsfirma vzsmandant
Lower Index Filter: ((root.al1.vzsartnr = root.al2.arti_artinr
AND root.
al1.vzsfirma = root.al2.arti_firma ) AND root.al1.vzsmandant =
root.al2.arti_man
dant )
NESTED LOOP JOIN
3) root.al3: INDEX PATH
(1) Index Name: root.keykst1
Index Keys: kst_kulinr kst_mandant kst_firma
Lower Index Filter: ((root.al1.vzskundennr = root.al3.kst_kulinr
AND roo
t.al1.vzsbuchkr = root.al3.kst_firma ) AND root.al1.vzsmandant =
root.al3.kst_ma
ndant )
NESTED LOOP JOIN
Query statistics:
-----------------
Table map :
----------------------------
Internal name Table name
----------------------------
t1 al2
t2 al1
t3 al1
t4 al3
type table rows_prod est_rows rows_scan time est_cost
-------------------------------------------------------------------
scan t1 16135 24443 16135 00:20.09 18842
type table rows_prod est_rows rows_scan time est_cost
-------------------------------------------------------------------
scan t2 1507671 100 6452883 01:18.05 1
type table rows_prod est_rows rows_scan time est_cost
-------------------------------------------------------------------
scan t3 1507671 100 1507671 06:04.08 1
type rows_prod est_rows time est_cost
-------------------------------------------------
nljoin 1507671 126 06:24.45 3960046
type table rows_prod est_rows rows_scan time est_cost
-------------------------------------------------------------------
scan t4 0 302 0 00:10.46 1
type rows_prod est_rows time est_cost
-------------------------------------------------
nljoin 1507671 126 06:35.72 3960123
type rows_prod est_rows rows_cons time es
t_cost
------------------------------------------------------------
group 1154 63 1507671 06:40.98 170
type rows_sort est_rows rows_cons time est_cost
------------------------------------------------------------
sort 57 63 1154 06:40.98 12
>>> "Art Kagel" <art.kagel@gmail.com> 19.02.2014 16:24 >>>
Heinz:
There are two possibilities:
1) The sort is fitting completely in memory, so no sort-work files are
needed.
2) The row ordering needed by the GROUP BY and ORDER by clauses are
being
satisfied by an index.
You can check the former while the session is still open by looking at
the
session's record in the sysmaster:syssesprof table. That will show the
number of disk sorts performed by the session and the total number of
sorts
as well as the size of the largest sort. The second condition could be
verified by running the query under SET EXPLAIN ON to see if the query
plan
is including a sort or not.
FYI: For best performance set PSORT_DBTEMP to at least three and as
many as
six completely independent filesystems if possible.
Art
Art S. Kagel, Principal Consultant
ASK Database Management
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own
opinions
and do not reflect on the IIUG, nor any other organization with which I
am
associated either explicitly, implicitly, or by inference. Neither do
those opinions reflect those of other individuals affiliated with any
entity with which I am affiliated nor those of the entities themselves.
On Wed, Feb 19, 2014 at 10:16 AM, Weitkamp Heinz <
Heinz.Weitkamp@westfleisch.de> wrote:
> Hello,
>
> IBM Informix Dynamic Server Version 11.70.UC7W3
> SUSE Linux Enterprise Server 11 (i586) VERSION = 11 PATCHLEVEL = 1
>
> I set:
> export PSORT_DBTEMP=/online
>
> env|grep PSO
> PSORT_DBTEMP=/online
>
> If I create an Index (with dbaccess) the sortfiles where created in
the
> directory /online
>
> ls -l /online
> -rw------- 1 root informix 90963968 Feb 19 15:48 srt0086779_001
>
> When I started an sql like:
>
> Select .............. from ..... GROUP BY 1, 2, 3, 5, 6, 7, 8 order> by 1,2,3,5,6,7,8;
>
> nothing where created in the directory /online.
> Why not?
>
> Doku says:
> The PSORT_DBTEMP environment variable specifies the location where
the
> database server writes the temporary files that the PSORT_NPROCS
> environment variable uses to perform a sort.
> The database server uses the directory that PSORT_DBTEMP specifies,
> even if the environment variable PSORT_NPROCS is not set.
>
> The sortfiles where created in the Temp-Dbspace 'tmpdbs'.
>
> onstat -d:> 5ff73018 4 0x2001 6 1 2048 N T A
> informix tmpdbs
>
> The onconfig has the parameter:
> DBSPACETEMP tmpdbs>
> Any hints would be appreciated
>
> Thanks
> Heinz
>
> --
> WESTFLEISCH eG * Hauptsitz: Brockhoffstr. 11, 48143 Münster
> Amtsgericht Münster: Gen.-Reg. 307
>
> Aufsichtsratsvorsitzender: Josef Lehmenkühler
> Vorstand: Dirk Niederstucke (Vorsitzender); Peter Piekenbrock;
Gerhard
> Meierzuherde; Dr. Helfried Giesen, Geschäftsführer (Sprecher);
Carsten
> Schruck, Geschäftsführer
>
> Hinweise: Es können nur Mails bis 30 MB empfangen werden.
>
Your query has an AUTO INDEX. That's not very usual, and I think it can't
be created "externally"... Having said this, I'm not sure (and only support
or someone with more "internal knowledge" could tell) if the "_temptable"
matches this dynamic structure.
Regards.
On Thu, Feb 20, 2014 at 11:52 AM, Weitkamp Heinz <
Heinz.Weitkamp@westfleisch.de> wrote:
> Hello Art,
>
> thanks for the quick reply.
>
> Environment:
> PSORT_DBTEMP=/online
> DBSPACETEMP=tmpdbs
>
> New experiences:
>
> IDS creates the Table _temptable in the temp_dbspace 'tmpdbs'.
> If the temp_dbspace is full then it creates the errormessage:
>
> 264: Could not write to a temporary file.
> 131: ISAM error: no free disk space>
> If the space of the temp_dbspace is big enough for the created
> _temptable then i see temporary files on /online like:
>
> first:
> srt0086917_013
>
> at the end a few files:
> ove0086899_xxx xxx=various number
>
> What are the 'ovexxxx' files?
>
> The SQL terminates without errors.
>
> Why does ids need the _temptable in the temp_dbspace 'tmpdbs'.
>
> Output of 'set explain on':
>
> QUERY: (OPTIMIZATION TIMESTAMP: 02-20-2014 11:45:15)
> ------
> SELECT AL1.vzswaagnr, AL1.vzszustand, AL1.vzsqualtnr, SUM (> AL1.vzsgewich
> ), AL1.vzsartnr, AL2.arti_bez, AL1.vzskundennr, AL3.kst_kurz_name
> FROM
> root.vzswiegdat AL1, OUTER root.kulistamm AL3, root.artikel AL2 WHERE
> (
> AL1.vzskundennr = AL3.kst_kulinr AND AL1.vzsmandant =
> AL3.kst_mandant AND AL1.vzsbuchkr = AL3.kst_firma AND
> AL1.vzsartnr=AL2.arti_artinr AND AL1.vzsmandant=AL2.arti_mandant AND
> AL1.vzsfirma=AL2.arti_firma) AND ((AL1.vzsmandant=1 AND
> AL1.vzsfirma=1
> AND AL1.vzsbuchkr=11 AND AL1.vzswerk=11 AND AL1.vzswaagnr IN (22, 23,
> 45,
> 46, 47, 48) AND AL1.vzsdatum>='01.01.2013')) GROUP BY 1, 2, 3, 5, 6,
> 7, 8
> order by 1,2,3,5,6,7,8
>
> Estimated Cost: 3960305
> Estimated # of Rows Returned: 62
> Temporary Files Required For: Order By Group By
>
> 1) root.al2: INDEX PATH
>
> (1) Index Name: root.keyarti2
>
> Index Keys: arti_mandant arti_firma arti_bez
>
> Lower Index Filter: (root.al2.arti_mandant = 1 AND
> root.al2.arti_firma =
> 1 )
>
> 2) root.al1: AUTOINDEX PATH
>
> Filters:
>
> Table Scan Filters: (((root.al1.vzswerk = 11 AND
> root.al1.vzsbuchkr = 11
> ) AND root.al1.vzswaagnr IN (22 , 23 , 45 , 46 , 47 , 48 )) AND
> root.al1.vzsdat
> um >= 01.01.2013 )
>
> (1) Index Name: (Auto Index)
>
> Index Keys: vzsartnr vzsfirma vzsmandant
>
> Lower Index Filter: ((root.al1.vzsartnr = root.al2.arti_artinr
> AND root.
> al1.vzsfirma = root.al2.arti_firma ) AND root.al1.vzsmandant =
> root.al2.arti_man
> dant )
> NESTED LOOP JOIN
>
> 3) root.al3: INDEX PATH
>
> (1) Index Name: root.keykst1
>
> Index Keys: kst_kulinr kst_mandant kst_firma
>
> Lower Index Filter: ((root.al1.vzskundennr = root.al3.kst_kulinr
> AND roo
> t.al1.vzsbuchkr = root.al3.kst_firma ) AND root.al1.vzsmandant =
> root.al3.kst_ma
> ndant )
> NESTED LOOP JOIN
>
> Query statistics:
> -----------------
> Table map :
> ----------------------------
> Internal name Table name
> ----------------------------
> t1 al2
> t2 al1
> t3 al1
> t4 al3
>
> type table rows_prod est_rows rows_scan time est_cost
> -------------------------------------------------------------------
> scan t1 16135 24443 16135 00:20.09 18842
>
> type table rows_prod est_rows rows_scan time est_cost
> -------------------------------------------------------------------
> scan t2 1507671 100 6452883 01:18.05 1
>
> type table rows_prod est_rows rows_scan time est_cost
> -------------------------------------------------------------------
> scan t3 1507671 100 1507671 06:04.08 1
>
> type rows_prod est_rows time est_cost
> -------------------------------------------------
> nljoin 1507671 126 06:24.45 3960046
>
> type table rows_prod est_rows rows_scan time est_cost
> -------------------------------------------------------------------
> scan t4 0 302 0 00:10.46 1
>
> type rows_prod est_rows time est_cost
> -------------------------------------------------
> nljoin 1507671 126 06:35.72 3960123
>
> type rows_prod est_rows rows_cons time es
> t_cost
> ------------------------------------------------------------
> group 1154 63 1507671 06:40.98 170
>
> type rows_sort est_rows rows_cons time est_cost
> ------------------------------------------------------------
> sort 57 63 1154 06:40.98 12
>
> >>> "Art Kagel" <art.kagel@gmail.com> 19.02.2014 16:24 >>>
> Heinz:
>
> There are two possibilities:
> 1) The sort is fitting completely in memory, so no sort-work files are
>
> needed.
> 2) The row ordering needed by the GROUP BY and ORDER by clauses are
> being
> satisfied by an index.
>
> You can check the former while the session is still open by looking at
> the
> session's record in the sysmaster:syssesprof table. That will show the
>
> number of disk sorts performed by the session and the total number of
> sorts
> as well as the size of the largest sort. The second condition could be
>
> verified by running the query under SET EXPLAIN ON to see if the query
> plan
> is including a sort or not.
>
> FYI: For best performance set PSORT_DBTEMP to at least three and as
> many as
> six completely independent filesystems if possible.
>
> Art
>
> Art S. Kagel, Principal Consultant
> ASK Database Management
>
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own
> opinions
> and do not reflect on the IIUG, nor any other organization with which I
> am
> associated either explicitly, implicitly, or by inference. Neither do
> those opinions reflect those of other individuals affiliated with any
> entity with which I am affiliated nor those of the entities themselves.
>
> On Wed, Feb 19, 2014 at 10:16 AM, Weitkamp Heinz <
> Heinz.Weitkamp@westfleisch.de> wrote:
>
> > Hello,
> >
> > IBM Informix Dynamic Server Version 11.70.UC7W3
> > SUSE Linux Enterprise Server 11 (i586) VERSION = 11 PATCHLEVEL = 1
> >
> > I set:
> > export PSORT_DBTEMP=/online
> >
> > env|grep PSO
> > PSORT_DBTEMP=/online
> >
> > If I create an Index (with dbaccess) the sortfiles where created in
> the
> > directory /online
> >
> > ls -l /online
> > -rw------- 1 root informix 90963968 Feb 19 15:48 srt0086779_001
> >
> > When I started an sql like:
> >
> > Select .............. from ..... GROUP BY 1, 2, 3, 5, 6, 7, 8 order> > by 1,2,3,5,6,7,8;
> >
> > nothing where created in the directory /online.
> > Why not?
> >
> > Doku says:
> > The PSORT_DBTEMP environment variable specifies the location where
> the
> > database server writes the temporary files that the PSORT_NPROCS
> > environment variable uses to perform a sort.
> > The database server uses the directory that PSORT_DBTEMP specifies,
> > e
The temp table is to hold the sorted rows for the GROUP BY clause. It
needs that because in general you could have a HAVING clause filtering the
results of the GROUP BY so the engine has to be able to perform general
query processing on the results.
Art
Art S. Kagel, Principal Consultant
ASK Database Management
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on the IIUG, nor any other organization with which I am
associated either explicitly, implicitly, or by inference. Neither do
those opinions reflect those of other individuals affiliated with any
entity with which I am affiliated nor those of the entities themselves.
On Thu, Feb 20, 2014 at 6:52 AM, Weitkamp Heinz <
Heinz.Weitkamp@westfleisch.de> wrote:
> Hello Art,
>
> thanks for the quick reply.
>
> Environment:
> PSORT_DBTEMP=/online
> DBSPACETEMP=tmpdbs
>
> New experiences:
>
> IDS creates the Table _temptable in the temp_dbspace 'tmpdbs'.
> If the temp_dbspace is full then it creates the errormessage:
>
> 264: Could not write to a temporary file.
> 131: ISAM error: no free disk space>
> If the space of the temp_dbspace is big enough for the created
> _temptable then i see temporary files on /online like:
>
> first:
> srt0086917_013
>
> at the end a few files:
> ove0086899_xxx xxx=various number
>
> What are the 'ovexxxx' files?
>
> The SQL terminates without errors.
>
> Why does ids need the _temptable in the temp_dbspace 'tmpdbs'.
>
> Output of 'set explain on':
>
> QUERY: (OPTIMIZATION TIMESTAMP: 02-20-2014 11:45:15)
> ------
> SELECT AL1.vzswaagnr, AL1.vzszustand, AL1.vzsqualtnr, SUM (> AL1.vzsgewich
> ), AL1.vzsartnr, AL2.arti_bez, AL1.vzskundennr, AL3.kst_kurz_name
> FROM
> root.vzswiegdat AL1, OUTER root.kulistamm AL3, root.artikel AL2 WHERE
> (
> AL1.vzskundennr = AL3.kst_kulinr AND AL1.vzsmandant =
> AL3.kst_mandant AND AL1.vzsbuchkr = AL3.kst_firma AND
> AL1.vzsartnr=AL2.arti_artinr AND AL1.vzsmandant=AL2.arti_mandant AND
> AL1.vzsfirma=AL2.arti_firma) AND ((AL1.vzsmandant=1 AND
> AL1.vzsfirma=1
> AND AL1.vzsbuchkr=11 AND AL1.vzswerk=11 AND AL1.vzswaagnr IN (22, 23,
> 45,
> 46, 47, 48) AND AL1.vzsdatum>='01.01.2013')) GROUP BY 1, 2, 3, 5, 6,
> 7, 8
> order by 1,2,3,5,6,7,8
>
> Estimated Cost: 3960305
> Estimated # of Rows Returned: 62
> Temporary Files Required For: Order By Group By
>
> 1) root.al2: INDEX PATH
>
> (1) Index Name: root.keyarti2
>
> Index Keys: arti_mandant arti_firma arti_bez
>
> Lower Index Filter: (root.al2.arti_mandant = 1 AND
> root.al2.arti_firma =
> 1 )
>
> 2) root.al1: AUTOINDEX PATH
>
> Filters:
>
> Table Scan Filters: (((root.al1.vzswerk = 11 AND
> root.al1.vzsbuchkr = 11
> ) AND root.al1.vzswaagnr IN (22 , 23 , 45 , 46 , 47 , 48 )) AND
> root.al1.vzsdat
> um >= 01.01.2013 )
>
> (1) Index Name: (Auto Index)
>
> Index Keys: vzsartnr vzsfirma vzsmandant
>
> Lower Index Filter: ((root.al1.vzsartnr = root.al2.arti_artinr
> AND root.
> al1.vzsfirma = root.al2.arti_firma ) AND root.al1.vzsmandant =
> root.al2.arti_man
> dant )
> NESTED LOOP JOIN
>
> 3) root.al3: INDEX PATH
>
> (1) Index Name: root.keykst1
>
> Index Keys: kst_kulinr kst_mandant kst_firma
>
> Lower Index Filter: ((root.al1.vzskundennr = root.al3.kst_kulinr
> AND roo
> t.al1.vzsbuchkr = root.al3.kst_firma ) AND root.al1.vzsmandant =
> root.al3.kst_ma
> ndant )
> NESTED LOOP JOIN
>
> Query statistics:
> -----------------
> Table map :
> ----------------------------
> Internal name Table name
> ----------------------------
> t1 al2
> t2 al1
> t3 al1
> t4 al3
>
> type table rows_prod est_rows rows_scan time est_cost
> -------------------------------------------------------------------
> scan t1 16135 24443 16135 00:20.09 18842
>
> type table rows_prod est_rows rows_scan time est_cost
> -------------------------------------------------------------------
> scan t2 1507671 100 6452883 01:18.05 1
>
> type table rows_prod est_rows rows_scan time est_cost
> -------------------------------------------------------------------
> scan t3 1507671 100 1507671 06:04.08 1
>
> type rows_prod est_rows time est_cost
> -------------------------------------------------
> nljoin 1507671 126 06:24.45 3960046
>
> type table rows_prod est_rows rows_scan time est_cost
> -------------------------------------------------------------------
> scan t4 0 302 0 00:10.46 1
>
> type rows_prod est_rows time est_cost
> -------------------------------------------------
> nljoin 1507671 126 06:35.72 3960123
>
> type rows_prod est_rows rows_cons time es
> t_cost
> ------------------------------------------------------------
> group 1154 63 1507671 06:40.98 170
>
> type rows_sort est_rows rows_cons time est_cost
> ------------------------------------------------------------
> sort 57 63 1154 06:40.98 12
>
> >>> "Art Kagel" <art.kagel@gmail.com> 19.02.2014 16:24 >>>
> Heinz:
>
> There are two possibilities:
> 1) The sort is fitting completely in memory, so no sort-work files are
>
> needed.
> 2) The row ordering needed by the GROUP BY and ORDER by clauses are
> being
> satisfied by an index.
>
> You can check the former while the session is still open by looking at
> the
> session's record in the sysmaster:syssesprof table. That will show the
>
> number of disk sorts performed by the session and the total number of
> sorts
> as well as the size of the largest sort. The second condition could be
>
> verified by running the query under SET EXPLAIN ON to see if the query
> plan
> is including a sort or not.
>
> FYI: For best performance set PSORT_DBTEMP to at least three and as
> many as
> six completely independent filesystems if possible.
>
> Art
>
> Art S. Kagel, Principal Consultant
> ASK Database Management
>
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own
> opinions
> and do not reflect on the IIUG, nor any other organization with which I
> am
> associated either explicitly, implicitly, or by inference. Neither do
> those opinions reflect those of other individuals affiliated with any
> entity with which I am affiliated nor those of the entities themselves.
>
> On Wed, Feb 19, 2014 at 10:16 AM, Weitkamp Heinz <
> Heinz.Weitkamp@westfleisch.de> wrote:
>
> > Hello,
> >
> > IBM Informix Dynamic Server Version 11.70.UC7W3
> > SUSE Linux Enterprise Server 11 (i586) VERSION = 11 PATCHLEVEL = 1
> >
> > I set:
> > export PSORT_DBTEMP=/online
> >
> > env|grep PSO
> > PSORT_DBTEMP=/online
> >
> > If I create an Index (with dbaccess) the sortfiles where created in
> the
> > directory /online
> >
> > ls -l /online
> > -rw------- 1 root informix 90963968 Feb 19 15:48 srt0086779_001
> >
> > When I started an sql like:
> >
> > Select .............. from .....
Good catch Fernando. I haven't see an AUTOINDEX PATH used in so long I've
stopped looking for them.
Heinz, one thing to note is that if you see an AUTOINDEX PATH in a SET
EXPLAIN output file, and the query is a common one, then you probably
should create that index. In this case you seem to need an index on
the vzswiegdat
table on columns (vzswerk, vzsbuchkr, vzswaagnr, vzsdatum).
Art
Art S. Kagel, Principal Consultant
ASK Database Management
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on the IIUG, nor any other organization with which I am
associated either explicitly, implicitly, or by inference. Neither do
those opinions reflect those of other individuals affiliated with any
entity with which I am affiliated nor those of the entities themselves.
On Thu, Feb 20, 2014 at 7:10 AM, Fernando Nunes <domusonline@gmail.com>wrote:
> Your query has an AUTO INDEX. That's not very usual, and I think it can't
> be created "externally"... Having said this, I'm not sure (and only support
> or someone with more "internal knowledge" could tell) if the "_temptable"
> matches this dynamic structure.
>
> Regards.
>
> On Thu, Feb 20, 2014 at 11:52 AM, Weitkamp Heinz <
> Heinz.Weitkamp@westfleisch.de> wrote:
>
> > Hello Art,
> >
> > thanks for the quick reply.
> >
> > Environment:
> > PSORT_DBTEMP=/online
> > DBSPACETEMP=tmpdbs
> >
> > New experiences:
> >
> > IDS creates the Table _temptable in the temp_dbspace 'tmpdbs'.
> > If the temp_dbspace is full then it creates the errormessage:
> >
> > 264: Could not write to a temporary file.
> > 131: ISAM error: no free disk space> >
> > If the space of the temp_dbspace is big enough for the created
> > _temptable then i see temporary files on /online like:
> >
> > first:
> > srt0086917_013
> >
> > at the end a few files:
> > ove0086899_xxx xxx=various number
> >
> > What are the 'ovexxxx' files?
> >
> > The SQL terminates without errors.
> >
> > Why does ids need the _temptable in the temp_dbspace 'tmpdbs'.
> >
> > Output of 'set explain on':
> >
> > QUERY: (OPTIMIZATION TIMESTAMP: 02-20-2014 11:45:15)
> > ------
> > SELECT AL1.vzswaagnr, AL1.vzszustand, AL1.vzsqualtnr, SUM (> > AL1.vzsgewich
> > ), AL1.vzsartnr, AL2.arti_bez, AL1.vzskundennr, AL3.kst_kurz_name
> > FROM
> > root.vzswiegdat AL1, OUTER root.kulistamm AL3, root.artikel AL2 WHERE
> > (
> > AL1.vzskundennr = AL3.kst_kulinr AND AL1.vzsmandant =
> > AL3.kst_mandant AND AL1.vzsbuchkr = AL3.kst_firma AND
> > AL1.vzsartnr=AL2.arti_artinr AND AL1.vzsmandant=AL2.arti_mandant AND
> > AL1.vzsfirma=AL2.arti_firma) AND ((AL1.vzsmandant=1 AND
> > AL1.vzsfirma=1
> > AND AL1.vzsbuchkr=11 AND AL1.vzswerk=11 AND AL1.vzswaagnr IN (22, 23,
> > 45,
> > 46, 47, 48) AND AL1.vzsdatum>='01.01.2013')) GROUP BY 1, 2, 3, 5, 6,
> > 7, 8
> > order by 1,2,3,5,6,7,8
> >
> > Estimated Cost: 3960305
> > Estimated # of Rows Returned: 62
> > Temporary Files Required For: Order By Group By
> >
> > 1) root.al2: INDEX PATH
> >
> > (1) Index Name: root.keyarti2
> >
> > Index Keys: arti_mandant arti_firma arti_bez
> >
> > Lower Index Filter: (root.al2.arti_mandant = 1 AND
> > root.al2.arti_firma =
> > 1 )
> >
> > 2) root.al1: AUTOINDEX PATH
> >
> > Filters:
> >
> > Table Scan Filters: (((root.al1.vzswerk = 11 AND
> > root.al1.vzsbuchkr = 11
> > ) AND root.al1.vzswaagnr IN (22 , 23 , 45 , 46 , 47 , 48 )) AND
> > root.al1.vzsdat
> > um >= 01.01.2013 )
> >
> > (1) Index Name: (Auto Index)
> >
> > Index Keys: vzsartnr vzsfirma vzsmandant
> >
> > Lower Index Filter: ((root.al1.vzsartnr = root.al2.arti_artinr
> > AND root.
> > al1.vzsfirma = root.al2.arti_firma ) AND root.al1.vzsmandant =
> > root.al2.arti_man
> > dant )
> > NESTED LOOP JOIN
> >
> > 3) root.al3: INDEX PATH
> >
> > (1) Index Name: root.keykst1
> >
> > Index Keys: kst_kulinr kst_mandant kst_firma
> >
> > Lower Index Filter: ((root.al1.vzskundennr = root.al3.kst_kulinr
> > AND roo
> > t.al1.vzsbuchkr = root.al3.kst_firma ) AND root.al1.vzsmandant =
> > root.al3.kst_ma
> > ndant )
> > NESTED LOOP JOIN
> >
> > Query statistics:
> > -----------------
> > Table map :
> > ----------------------------
> > Internal name Table name
> > ----------------------------
> > t1 al2
> > t2 al1
> > t3 al1
> > t4 al3
> >
> > type table rows_prod est_rows rows_scan time est_cost
> > -------------------------------------------------------------------
> > scan t1 16135 24443 16135 00:20.09 18842
> >
> > type table rows_prod est_rows rows_scan time est_cost
> > -------------------------------------------------------------------
> > scan t2 1507671 100 6452883 01:18.05 1
> >
> > type table rows_prod est_rows rows_scan time est_cost
> > -------------------------------------------------------------------
> > scan t3 1507671 100 1507671 06:04.08 1
> >
> > type rows_prod est_rows time est_cost
> > -------------------------------------------------
> > nljoin 1507671 126 06:24.45 3960046
> >
> > type table rows_prod est_rows rows_scan time est_cost
> > -------------------------------------------------------------------
> > scan t4 0 302 0 00:10.46 1
> >
> > type rows_prod est_rows time est_cost
> > -------------------------------------------------
> > nljoin 1507671 126 06:35.72 3960123
> >
> > type rows_prod est_rows rows_cons time es
> > t_cost
> > ------------------------------------------------------------
> > group 1154 63 1507671 06:40.98 170
> >
> > type rows_sort est_rows rows_cons time est_cost
> > ------------------------------------------------------------
> > sort 57 63 1154 06:40.98 12
> >
> > >>> "Art Kagel" <art.kagel@gmail.com> 19.02.2014 16:24 >>>
> > Heinz:
> >
> > There are two possibilities:
> > 1) The sort is fitting completely in memory, so no sort-work files are
> >
> > needed.
> > 2) The row ordering needed by the GROUP BY and ORDER by clauses are
> > being
> > satisfied by an index.
> >
> > You can check the former while the session is still open by looking at
> > the
> > session's record in the sysmaster:syssesprof table. That will show the
> >
> > number of disk sorts performed by the session and the total number of
> > sorts
> > as well as the size of the largest sort. The second condition could be
> >
> > verified by running the query under SET EXPLAIN ON to see if the query
> > plan
> > is including a sort or not.
> >
> > FYI: For best performance set PSORT_DBTEMP to at least three and as
> > many as
> > six completely independent filesystems if possible.
> >
> > Art
> >
> > Art S. Kagel, Principal Consultant
> > ASK Database Management
> >
> > Blog: http://informix-myview.blogspot.com/
> >
> > Disclaimer: Please keep in mind that my own opinions are my own
> > opinions
> > and do not reflect on the IIUG, nor any other organization with which I
> > a
Fernando and Art thanks a lot for quick and skilled response.
FYI
After i created the index Art mentioned, no _temptable where created
any longer. No errors
Therefore i guess the (big) _temptable belongs to the AUTOINDEX.
Heinz
>>> "Art Kagel" <art.kagel@gmail.com> 20.02.2014 13:30 >>>
Good catch Fernando. I haven't see an AUTOINDEX PATH used in so long
I've
stopped looking for them.
Heinz, one thing to note is that if you see an AUTOINDEX PATH in a SET
EXPLAIN output file, and the query is a common one, then you probably
should create that index. In this case you seem to need an index on
the vzswiegdat
table on columns (vzswerk, vzsbuchkr, vzswaagnr, vzsdatum).
Art
Art S. Kagel, Principal Consultant
ASK Database Management
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own
opinions
and do not reflect on the IIUG, nor any other organization with which I
am
associated either explicitly, implicitly, or by inference. Neither do
those opinions reflect those of other individuals affiliated with any
entity with which I am affiliated nor those of the entities themselves.
On Thu, Feb 20, 2014 at 7:10 AM, Fernando Nunes
<domusonline@gmail.com>wrote:
> Your query has an AUTO INDEX. That's not very usual, and I think it
can't
> be created "externally"... Having said this, I'm not sure (and only
support
> or someone with more "internal knowledge" could tell) if the
"_temptable"
> matches this dynamic structure.
>
> Regards.
>
> On Thu, Feb 20, 2014 at 11:52 AM, Weitkamp Heinz <
> Heinz.Weitkamp@westfleisch.de> wrote:
>
> > Hello Art,
> >
> > thanks for the quick reply.
> >
> > Environment:
> > PSORT_DBTEMP=/online
> > DBSPACETEMP=tmpdbs
> >
> > New experiences:
> >
> > IDS creates the Table _temptable in the temp_dbspace 'tmpdbs'.
> > If the temp_dbspace is full then it creates the errormessage:
> >
> > 264: Could not write to a temporary file.
> > 131: ISAM error: no free disk space> >
> > If the space of the temp_dbspace is big enough for the created
> > _temptable then i see temporary files on /online like:
> >
> > first:
> > srt0086917_013
> >
> > at the end a few files:
> > ove0086899_xxx xxx=various number
> >
> > What are the 'ovexxxx' files?
> >
> > The SQL terminates without errors.
> >
> > Why does ids need the _temptable in the temp_dbspace 'tmpdbs'.
> >
> > Output of 'set explain on':
> >
> > QUERY: (OPTIMIZATION TIMESTAMP: 02-20-2014 11:45:15)
> > ------
> > SELECT AL1.vzswaagnr, AL1.vzszustand, AL1.vzsqualtnr, SUM (> > AL1.vzsgewich
> > ), AL1.vzsartnr, AL2.arti_bez, AL1.vzskundennr, AL3.kst_kurz_name
> > FROM
> > root.vzswiegdat AL1, OUTER root.kulistamm AL3, root.artikel AL2
WHERE
> > (
> > AL1.vzskundennr = AL3.kst_kulinr AND AL1.vzsmandant =
> > AL3.kst_mandant AND AL1.vzsbuchkr = AL3.kst_firma AND
> > AL1.vzsartnr=AL2.arti_artinr AND AL1.vzsmandant=AL2.arti_mandant
AND
> > AL1.vzsfirma=AL2.arti_firma) AND ((AL1.vzsmandant=1 AND
> > AL1.vzsfirma=1
> > AND AL1.vzsbuchkr=11 AND AL1.vzswerk=11 AND AL1.vzswaagnr IN (22,
23,
> > 45,
> > 46, 47, 48) AND AL1.vzsdatum>='01.01.2013')) GROUP BY 1, 2, 3, 5,
6,
> > 7, 8
> > order by 1,2,3,5,6,7,8
> >
> > Estimated Cost: 3960305
> > Estimated # of Rows Returned: 62
> > Temporary Files Required For: Order By Group By
> >
> > 1) root.al2: INDEX PATH
> >
> > (1) Index Name: root.keyarti2
> >
> > Index Keys: arti_mandant arti_firma arti_bez
> >
> > Lower Index Filter: (root.al2.arti_mandant = 1 AND
> > root.al2.arti_firma =
> > 1 )
> >
> > 2) root.al1: AUTOINDEX PATH
> >
> > Filters:
> >
> > Table Scan Filters: (((root.al1.vzswerk = 11 AND
> > root.al1.vzsbuchkr = 11
> > ) AND root.al1.vzswaagnr IN (22 , 23 , 45 , 46 , 47 , 48 )) AND
> > root.al1.vzsdat
> > um >= 01.01.2013 )
> >
> > (1) Index Name: (Auto Index)
> >
> > Index Keys: vzsartnr vzsfirma vzsmandant
> >
> > Lower Index Filter: ((root.al1.vzsartnr = root.al2.arti_artinr
> > AND root.
> > al1.vzsfirma = root.al2.arti_firma ) AND root.al1.vzsmandant =
> > root.al2.arti_man
> > dant )
> > NESTED LOOP JOIN
> >
> > 3) root.al3: INDEX PATH
> >
> > (1) Index Name: root.keykst1
> >
> > Index Keys: kst_kulinr kst_mandant kst_firma
> >
> > Lower Index Filter: ((root.al1.vzskundennr = root.al3.kst_kulinr
> > AND roo
> > t.al1.vzsbuchkr = root.al3.kst_firma ) AND root.al1.vzsmandant =
> > root.al3.kst_ma
> > ndant )
> > NESTED LOOP JOIN
> >
> > Query statistics:
> > -----------------
> > Table map :
> > ----------------------------
> > Internal name Table name
> > ----------------------------
> > t1 al2
> > t2 al1
> > t3 al1
> > t4 al3
> >
> > type table rows_prod est_rows rows_scan time est_cost
> > -------------------------------------------------------------------
> > scan t1 16135 24443 16135 00:20.09 18842
> >
> > type table rows_prod est_rows rows_scan time est_cost
> > -------------------------------------------------------------------
> > scan t2 1507671 100 6452883 01:18.05 1
> >
> > type table rows_prod est_rows rows_scan time est_cost
> > -------------------------------------------------------------------
> > scan t3 1507671 100 1507671 06:04.08 1
> >
> > type rows_prod est_rows time est_cost
> > -------------------------------------------------
> > nljoin 1507671 126 06:24.45 3960046
> >
> > type table rows_prod est_rows rows_scan time est_cost
> > -------------------------------------------------------------------
> > scan t4 0 302 0 00:10.46 1
> >
> > type rows_prod est_rows time est_cost
> > -------------------------------------------------
> > nljoin 1507671 126 06:35.72 3960123
> >
> > type rows_prod est_rows rows_cons time es
> > t_cost
> > ------------------------------------------------------------
> > group 1154 63 1507671 06:40.98 170
> >
> > type rows_sort est_rows rows_cons time est_cost
> > ------------------------------------------------------------
> > sort 57 63 1154 06:40.98 12
> >
> > >>> "Art Kagel" <art.kagel@gmail.com> 19.02.2014 16:24 >>>
> > Heinz:
> >
> > There are two possibilities:
> > 1) The sort is fitting completely in memory, so no sort-work files
are
> >
> > needed.
> > 2) The row ordering needed by the GROUP BY and ORDER by clauses are
> > being
> > satisfied by an index.
> >
> > You can check the former while the session is still open by looking
at
> > the
> > session's record in the sysmaster:syssesprof table. That will show
the
> >
> > number of disk sorts performed by the session and the total number
of
> > sorts
> > as well as the size of the largest sort. The second condition could
be
> >
> > verified by running the query under SET EXPLAIN ON to see if the
query
> > plan
> > is including a sort or not.
> >
> > FYI: For best performance set
Related threads
- IDS 10 table-level restore
- Informix Development Webinar December 11, 2007
- ontape -p/r with changed ROOTPATH
- Migrate from HP PA-RISC to HP ITANIUM by ontape