Adding new column to production database

Question

I have to add a new timestamp column, that defaults to the current date/time, to an existing production database. The table is large - 150M records. I am trying to understand the ramifications of adding a new column to a table this large that gets hit often, mostly with inserts and reads. The column does allow null values and I am not going back and populating existing records with a value. Basically, I am looking for some best practice guidelines - how to prepare, what to expect, what other processes should be followed along with this schema update.

Answer 1

Radiators wrote:
Thanks, I have not found any %TYPE or %ROWTYPE dependencies on the table I am altering. But at the same time I do not understand how these types of dependencies would invalidate packages. I wouldn't be breaking any %TYPE dependency because I am not dropping columns, only adding a new one. And according to documentation for %ROWTYPE - "If columns are later added to or dropped from the table, your code can keep working without changes." Can you point me to Oracle documentation that describes your concern in detail? Thanks.you can test it yourself
SQL> CREATE TABLE abc (c1 NUMBER);
Table created.
SQL> INSERT INTO abc
  2       VALUES (99);
1 row created.
SQL> CREATE OR REPLACE PROCEDURE test_proc
  2  AS
  3     v   abc%ROWTYPE;
  4  BEGIN
  5     SELECT c1
  6       INTO v
  7       FROM abc
  8       WHERE ROWNUM = 1;
  9  END;
10  /
Procedure created.
SQL> SELECT object_name, status
  2    FROM user_objects
  3   WHERE object_name = 'TEST_PROC';
OBJECT_NAME                STATUS
TEST_PROC                    VALID
SQL> ALTER TABLE abc ADD (c2 VARCHAR2(10));
Table altered.
SQL> SELECT object_name, status
  2    FROM user_objects
  3   WHERE object_name = 'TEST_PROC';
OBJECT_NAME                 STATUS
TEST_PROC                     INVALID
SQL> you should also consider the chance that some where if people are using "select * into" using this table, which will fail since you added new column. i don't see any unusual performance bottlenecks by adding a new column. in case of the backups, yes the earlier backups will not have the column. if you restore it, you will see earlier table structure itself. i have one specific question. why are you not attempting this in development/test environment first? even if it is a simple insert, it's always important to do it in test environments before attempting on production db. one thing for sure i know is, after adding column, you will have to recompile all the invalid dependencies. i think, it's better if you attempt it in test db and come up with any issues you see rather than asking a general question where problematic scenarios are plenty and rarely unknown before hand.