How to minimise performance degradation when querying a growing table during processing...?

Question

Hi everyone
Let's say you have a PL/SQL routine that is processing data from a source table and for each record, it checks to see whether a matching record exists in a header table (TableA); if one does, it uses it otherwise it creates a new one. It then inserts associated detail records (into TableB) linked to the header record. So the process is:
Read record from source table
Check to see if matching header record exists in TableA (using indexed field)
If match found then store TXH_ID (PK in TableA)
If no match found then create new header record in TableA with new TXH_ID
Create detail record in TableB where TXD_TXH_ID (FK on TableB) = TXH_ID
If the header table (Table A) starts getting big (i.e. the process adds a few million records to it), presumably the stats on TableA will start to get stale and therefore the query in step 2 will become more time consuming?
If so, is there any way to rectify this? Would updating the stats at certain points in the process be effective?
Would it be any different if a MERGE was used to (conditionally) insert the header records into TableA? (i.e. would the stats still get stale?)
DB is 11GR2 and OS is Windows Server 2008
Thanks

Answer 1

Let's say you have a PL/SQL routine that is processing data from a source table and for each record, it checks to see whether a matching record exists in a header table (TableA); if one does, it uses it otherwise it creates a new one. It then inserts associated detail records (into TableB) linked to the header record. So the process is:
Read record from source table
Check to see if matching header record exists in TableA (using indexed field)
If match found then store TXH_ID (PK in TableA)
If no match found then create new header record in TableA with new TXH_ID
Create detail record in TableB where TXD_TXH_ID (FK on TableB) = TXH_ID
If the header table (Table A) starts getting big (i.e. the process adds a few million records to it), presumably the stats on TableA will start to get stale and therefore the query in step 2 will become more time consuming?
What do you mean 'presumably the stats . .'?
In item #3 you said that TXH_ID is the primary key. That means only ONE value will EVER be found in the index so there should be NO degradation for looking up that primary key value.
The plan you posted shows an index range scan. A range scan is NOT used to lookup primary key values since they must be unique (meaning there is NO RANGE).
So there should be NO impact due to the header table 'getting big'.