The main problem may be that there are access paths (for example in logical
files with select/omit clauses) that are currently used by the CQE but
ignored by the SQE.
In this way SQL statement that perform well in the current environment will
run very slowly.
The best way is to search your logical files with keys and select omit
clauses. Delete the logical files, create indexes for the key information
and recreate your logical files. In this way SQL/SQE can use the new indexes
and native I/O can use the DDS described logical files. Deleting and
recreating the logical files is necessary, because a logical file can share
access path with an SQL index, but a SQL index cannot share access path with
a logical file (because of the larger default page size).
Mit freundlichen Grüßen / Best regards
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Jonathan Mason
Gesendet: Friday, 28. August 2009 14:54
Betreff: CQE, SQE and QAQQINI
We have an SQL statement that uses the CQE and runs extremely slowly. In
test I have created an Encoded Vector Index and also changed a local version
of the QAQQINI file so that the IGNORE_DERIVED_INDEXES is set to *YES.
With these settings the SQL runs extremely fast, however the powers that be
are nervous about changing a global setting that would potentially affect
all SQL requests.
I've spent the morning talking to my friend, Google, and searching through
the Midrange.com archives, and everything I have seen indicates that using
the SQE is better than using the CQE.
With this in mind, are there any pitfalls in changing the
IGNORE_DERIVED_INDEXES setting to *YES? Should we expect all SQL to run at
least as fast as does currently or is there a risk that some SQL processes
could run slower?
Thanks in advance
This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact