Adding column with default value on a large table...

We all know that we can easily add a column to an existing table with DEFAULT value. It's not a problem when the the table size is small because when adding a column with default value, all existing rows needs to be updated with the value specified in default clause.

Problem is only when the table has millions of records. It will take anywhere from minutes to close to hours (depending on the size of the table).

Thanks to 11g with its new feature:

Alter Script:

alter table table_name add column_name varchar2(3) default 'YES' NOT NULL;

The above statement will not issue an update to existing records. New records will have the value YES. So, what will happen to existing records data for this column? Here comes the 11g new feature, when a user selects the column for an existing record, oracle gets the default value from the data dictionary.

Now you can happily add a column with default value to even billion records table in fraction of a second!!! sweet...

Here is the test results with and without NOT NULL:

15:59:35 SQL> select count(1)from ln_stage_data;

  COUNT(1)
----------
  12540411

Elapsed: 00:00:00.93
15:59:40 SQL> alter table ln_stage_data add test_flag char(1) default 'Y';

Table altered.

Elapsed: 01:02:03.38
17:01:51 SQL> alter table ln_stage_data add test_flag2 char(1) default 'Y' not null;

Table altered.

Elapsed: 00:00:01.13
17:02:14 SQL>

Index Usage and Monitoring...

Thought of blogging about this long ago but never took a step and now is the time to put it up here instead of keep digging my repository for queries.

Creating an Index is the first solution for every developer to overcome the issue :)
But once its created its way too hard to decide whether to keep it or drop it after days go by...

How do we know if the particular index is being used or not? Big Question...

Well, one can turn on monitoring on index:

alter index index_name monitoring usage;

Once done, you can check v$object_usage to see if the index is being used or not.
Great. But how often? Sorry view wont have answer for that.

Below query helps in finding how many times the index is being used (and one can digg thru more to find the actual query also by using sql_id):

select di.table_name "Table Name", di.index_name "Index Name",
       round(sum((ds.bytes)/1024/1024),2) "Index Size -MB",
       dhsp.options "Index Operation", count(dhsp.options) "No# of Executions"
  from dba_hist_sql_plan dhsp, dba_indexes di, dba_segments ds
 where di.owner = user
   and dhsp.object_name(+) = di.index_name
   and dhsp.object_owner(+) = di.owner
   and di.index_name = ds.segment_name
   and di.owner = ds.owner
   and not exists (select 1 from dba_constraints dc where dc.constraint_name = di.index_name and dc.constraint_type = 'P')
   --and di.table_name in ('TABLE1', 'TABLE2')
 group by di.table_name, di.index_name, dhsp.options
 having count(dhsp.options) = 0
 order by 1,2,3;

As you can see, the above query is filtering for count = 0 meaning, I am only interested in showing indexes which were never used.

Note: Recently executed queries wont show up in DBA_HIST_SQL_PLAN so replace with V$SQL_PLAN. Also check the min(timestamp) from dba_hist_sql_plan to see the retention of the history. 

ORA-02050: transaction 11.9.23629 rolled back, some remote DBs may be in-doubt is local tran 11.9.23629 (hex=0b.09.5c4d)

Full stack of error message:
ORA-02050: transaction 11.9.23629 rolled back, some remote DBs may be in-doubt
  is local tran 11.9.23629 (hex=0b.09.5c4d)
ORA-02051: another session or branch in same transaction failed or finalized
  insert pending collecting tran, scn=7859252260641 (hex=725.dff06f21)

Developer reported this error while he is trying to perform an update.

First thought it might be due to exceeded connections over db links.

Later found it was due to Materialized View Log that was created on the base table on which the update was being performed. This log was not being refreshed due to some reasons and thus causing this failure.

Check the alert log for any additional/following errors for this ORA-02050 messages: