Skip to Main Content
  • Questions
  • Alter table add column on a FDA enabled table - how to avoid the row chain effect without using the 'move' option?

Breadcrumb

Question and Answer

Chris Saxon

Thanks for the question, Eric.

Asked: October 31, 2017 - 4:26 pm UTC

Last updated: November 03, 2017 - 11:34 am UTC

Version: Oracle 12c

Viewed 1000+ times

You Asked

Hi,

We'd like to use FDA on our Oracle db for its bi-temporality feature.

So far when we add a column to a table, we also perform the 'alter table T move;' + rebuild indexes, to avoid performance issues and to re-organize the row IDS.
But the 'move' command is not supported by FDA.

In order to bypass this, we are asked to
- create a new table with the new column,
- transfer the data from the initial table to the new one,
- rename the old one so that it is not used anymore, but keep it live in order to still access its FDA logs on demand,
- rename the new one to replace the old one,
- rebuild indexes and alike on the new table,
- enable FDA on the new table.

Considering all this, I see the scenario where, in a couple of years, we will end up with several versions of the same table, impacting the storage, and making the data model complex, if not unreadable. I can think of moving the 'old' tables to a dedicated table space, but this does not ease the pain anyway.

Is there another way to add columns into a FDA enabled table without duplicating the table and underlying data?


ADDITIONAL INFORMATION:
By 'performance issues' I meant row-chaining effect. We have tables containing blobs, other containing a good amount of columns. Some of these tables are interval partitioned. In the past we faced slowness due to a wrong execution plan optimization despite the stats were up to date. Our DBAs mentioned it was because of column additions, done without table re-organization.

and Chris said...

Just add the columns normally!

Stop second guessing where you might have performance problems. Deal with ones you have when they arise.

Re-creating the table like this is a lot of work. And may cause the plans to change (for the worse) too!

There's a much better method to ensure you keep the current plans. SQL Plan Management. This can lock a statement to a given plan. Do this to key statements before adding columns. Then you can review plans later.

Read more about this at:

http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-sql-plan-mgmt-12c-1963237.pdf

Also, as you've mentioned blobs, you may want to look into the storage options for these. You can specify whether you want to store this in or out of line, which may help deal with the "row chaining" issues you've hit:

https://docs.oracle.com/database/122/ADLOB/LOB-storage-with-applications.htm#ADLOB45273

Is this answer out of date? If it is, please let us know via a Comment

More to Explore

Design

New to good database design? Check out Chris Saxon's full fundamentals class.