dbvalid time dramatically increasing

[Former Member]

Hi Community,

a customer starts dbvalid every night on a 68 GB Backup of SQL Anywhere DB. Up to 20.7.2013 that takes 3 hours. Since 20.7.2003 it takes 12 to 15 hours. Increasing cache from 4 to 6 GB leads to duration of 10 hours. What can be the reason for this dramatically increase of time?

Some more information: Sql Anywhere 10.0.1.3415 64 bit. VM, quad core, 2.93 GHz, Intel Xeon, Win2008 R2, 24 GB RAM. Backup-DB ist startet by: dbeng -c 6g -ca 0 . Validation is startet by: dbvalid -q -fx . During validation resource-monitor shows reading of dbeng by 53,000,000 B/min.

[MCMartin]

53 MBytes per minute mean < 1MBytes per second, so just the reading of the DB file would last more than 18 hours. I would check the underlying IO system, maybe you have a degraded performance there.

[johnsmirnios]

I agree. With -fx, I believe most of the IO should be sequential since the index probes (which can require a lot of random IO if the cache is too small) would be skipped. Sequential IOs should be fast. Maybe another process in this VM or another VM was doing IOs to the same drive? That would introduce randomness to the IO and drastically lower performance.

[reimer_pods]

Copying the database to a "real" machine (not a VM), preferably with no other activity for that time, and running the validation there should give you the chance to compare results.

[Former Member]

Thank you all, dbvalid on backup.db and productiv.db are running on the same server since years. We have to clearify with the local administrators if there are other processes in this VM or another VM that are doing IOs to the same drive.