RE: Oncheck taking too long ...

I have been complaining about oncheck performance in 7.x for a long = time. With all this neat wiz-bang parallelism, you think Informix could = implement a parallelized oncheck. PLEASE, if you are interested in a more performant oncheck, contact your = local reps., and submit a feature request. I have done so already.=20 I know that some 'un-official' work has been done by some bright = Informix people, outside of R&D. If enough people request/complain about = oncheck, just maybe something will happen. If no one requests, NOTHING = will happen. Jon ----------------------------------------------------------------------- Jon C. Vemo jvemo@cyberspace.com Bothell, WA USA ---------- From: Nilesh N Kunvarji[SMTP:kunvarji@worldnet.att.net] Sent: Tuesday, July 23, 1996 6:07 PM To: informix-list@rmy.emory.edu Subject: Oncheck taking too long ... We have OnLine 7.13 UC1 running on Solaris 2.4.. Our DB is approx 35+ = GB in total. Some tables or over 2GB in size and quite a few are over 1GB. Approx 85-90 % of the=20 tables in DB are very small. Our problem is that when we run oncheck -cI, the whole process takes approx. 4 hours. I have 13 concurrent oncheck -cI running. We have 32 processors on = this machine of which=20 13 are allocated to OnLine (NOT affinity). I can drop and recreate all the indexes in about 1 Hour, by setting PSORT_NPROC environment. My question is, why does checking the indexes taking longer than = creating the indexes ? Also during the oncheck process, one of the thread is going into a critical section, which in turn keeps the checkpoint waiting until its out of critical section (some checkpoint takes over 1500=20 seconds) Why does oncheck -cI go in to critical section ? Please advise. Nilesh K.