[Info-Ingres] Optimization Problem on Ingres2006 database

[marcop...@gmail.com]

We have some optimization statistics problem.

First we run optimizedb -zk sales

But then we get this messages on every table we try to use on our
application.

E_OP03A2_HISTINCREASING consistency check
- histogram on taliprovta attribute idmes is not monotonically
increasing

We fix this running an optimization at 50% with this command:
optimizedb -zk -zs50.0 ventas -rtaliprovta.

So at noon we run an optimization like this optimizedb -zk -zs50.0
sales, but now the problem persist not in all the table but more than
a 70% of all the database, we are at stage of migration from IngresII
2.6 version, and think maybe in this new version of ingres is diferent
form of optimization somebody can give us a clue?

Thanks in advance.
_______________________________________________
Info-Ingres mailing list
Info-...@kettleriverconsulting.com
http://www.kettleriverconsulting.com/mailman/listinfo/info-ingres

[weasel]

On Apr 25, 6:06 am, marcopolo...@gmail.com wrote:
> We have some optimization statistics problem.
>
> First we run optimizedb -zk sales
>
> But then we get this messages on every table we try to use on our
> application.
>
> E_OP03A2_HISTINCREASING consistency check
> - histogram on taliprovta attribute idmes is not monotonically
> increasing
>
> We fix this running an optimization at 50% with this command:
> optimizedb -zk -zs50.0 ventas -rtaliprovta.
>
> So at noon we run an optimization like this optimizedb -zk -zs50.0
> sales, but now the problem persist not in all the table but more than
> a 70% of all the database, we are at stage of migration from IngresII
> 2.6 version, and think maybe in this new version of ingres is diferent
> form of optimization somebody can give us a clue?
>
> Thanks in advance.

Can you post the statdump for one of these tables and columns?

[Paul White]

I sounds like we had the same bug - 119583
Talk to ingres support. The turnaround was very fast.

Problem.
Simple select on table recently moved from 2.6 to 2006 using unloaddb

Server errlog.log
E_OP04AA_HISTOMOD Histogram modification failed. Original histogram will be
used.

E_OP03A2_HISTINCREASING consistency check - histogram on

ta_employee_clockings attribute actual_clock_datetime is not monotonically
increasing

client
select clocking_source, actual_clock_datetime
from ta_employee_clockings where employee_no= 123
and employee_attend_id= 456
and (actual_clock_datetime= '07/07/2007 10:00:00' or
actual_clock_datetime= '07/07/2007 11:00:00')

E_OP03A2 consistency check
- histogram on ta_employee_clockings attribute actual_clock_datetime is
not monotonically increasing

optimizedb did not fix.
verifydb did not detect problems.
restored database to another machine worked. (sorry not sure version)

Temporary fix was to remove stats or optimize with -zna flag. eg
statdump -zdl mwp -rta_employee_clockings

version.rel
II 9.1.0 (int.w32/123)

Paul White

[Laframboise André]

We also have the same problem with 9.1.0 (R2) on Linux Itanium. A select based on any date field will
cause this unless the stats are either dropped or ignored.

Andre

________________________________

[Paul White]

Sorry I wasnt clear.
We received a patch to fix the problem on windows pretty quickly.

Paul