Unanswered: load replace behaviour/effect on previous access paths
I have a thing on my mind that is bugging me, as I cannot really explain/understand what's happening...
I explain it better.
We have a prod environment - db2 9.1.7 - where each day a certain job is run.
This job is a monster, in the sense that it runs for 4 hours to spool something like 22kk records on a file.
Basically what it does is
- open a cursor on table A, B and C(22kk rows) (with table A being a 115kk record one)
- for each row,
- run 2/3 queries on table A (yes, I know what you're thinking... I do the same :P) to "enrich" it
- write a line on a file
- read next line
However, this night, this job took 14 hours to run successfully.
Looking at what could have happened, I saw this thing, a series of operations on table A, in particular
- table was unloaded, and the files split into two.
- after modifying the first file (non key-cols), a load replace on the very same table was performed (with no statistics collection)
- second file, modified, and load inserted (again, no stats collection)
- our program "ran" (well, "tried crawling" is more appropriate ) in 14 hours...
- this morning, the stats on table A were automatically collected, we tried relaunching the job and it is proceding at the "usual" pace.
The base statistics did not change at all (same cardinality of records before-during-after )
The doubt I have is... what happens to already bound packages in the time between load and automatic runstat?
In theory nothing (indexes should be rebuilt during the build phase) and as for the statistics/access path, it should just use the bind ones, correct?
I just don't wanna find out that for whatever reason the db starts thinking something like "awww, wait, the table has been replaced with god-knows-what, it's better if I don't use the previous package plan"