We observed an interesting phenomenon that is driving us crazy. We have
an archive process that takes rows off of a primary database, then
inserts them into a history database. After loading the exported rows
into the history database, we observed abysmal performance (queries
increasing from 2 minutes to 2 hours). No amount of runstats or
explaining/tuning queries yielded anything significant.
In an effort to study the problem on a different server so we wouldn't
kill the primary server with these long-running queries, we took a
backup and restored it onto the new server. It was a similarly classed
machine. Much to our surprise, the problem didn't exist on the new
server. We looked at all the differences in the configurations and
never found anything significant.
For grins, we decided to restore the same database back to itself on
the primary server, and again, we were were surprised to see our
problem go away.
We just completed a new archive cycle and the problem has resurfaced. I
have two questions:
1. Does a restore do an implicit reorg of the tables? (I had always
thought that it just copied the data pages verbatim and reloaded them
in the same order.)
2. Why does the load create such chaos? Doesn't it allocate data on
contiguous new pages appended to the end? (We don't delete anything on
target DB, so there shouldn't be any "holes" in the data pages...)
Any enlightenment on this issue would be greatly appreciated.
Platform = UDB 7.2 FP 12 on AIX 5.2
Thanks,
Evan