Oracle Query Tuning

Question

Hi,
I am having difficulty with a particular issue. We have a column that is indexed, but we are looking just for the NULL columns and it is deciding to do a full table scan.
Here is the query and the output from the explain plan. Much of our cost is spent on step 11 below.
Thanks : )
SELECT          SEVERITY.SEVERITY_CODE,
                         ACCOUNT.ACCOUNT_NUMBER,
                         ACTIVITY.BLOCK_TYPE_ID,
                         ACTIVITY_ACCOUNT.ERROR_MSG,
                         DECODE(ACTIVITY.REISSUE_IND,0,NULL,ACTIVITY.REISSUE_IND) AS REISSUE_IND,
                         ACTIVITY_ACCOUNT.REPLACE_ACCOUNT_NUMBER,
                         ACTIVITY_ACCOUNT.EXP_DATE_OVERRIDE,
                         ACTIVITY.SCHEDULED_BLOCK_DATE,
                         ACTIVITY.EWB_REGION_CODES,
                         ACTIVITY.EWB_PURGE_DATE,
                         ACTIVITY.LETTER_TYPE,
                         ACTIVITY.LETTER_ID,
                         DECODE(ACTIVITY.DIALER_IND,0,NULL,ACTIVITY.DIALER_IND) AS DIALER_IND,
                         DECODE(ACTIVITY.RUSH_PLASTIC_IND,0,NULL,ACTIVITY.RUSH_PLASTIC_IND) AS RUSH_PLASTIC_IND,
                         ALERT.ALERT_EVENT,
                         ACTIVITY.ACTIVITY_DATE,
                         ACTIVITY_ACCOUNT.BLOCK_RECLASS_CODE,
                         ACCOUNT.CORP
               FROM          ACTIVITY
               INNER JOIN     ALERT ON ACTIVITY.ALERT_ID = ALERT.ALERT_ID
               INNER JOIN     SEVERITY ON ALERT.SEVERITY_ID = SEVERITY.SEVERITY_ID
               INNER JOIN     ACTIVITY_ACCOUNT ON ACTIVITY.ACTIVITY_ID = ACTIVITY_ACCOUNT.ACTIVITY_ID
               INNER JOIN     ACCOUNT ON ACTIVITY_ACCOUNT.ACCOUNT_ID = ACCOUNT.ACCOUNT_ID
               WHERE          ACTIVITY_DATE < SYSDATE AND
                              STATUS_ID <> 3 AND                    --3 is DELETED
                    UPLOADED_DATE IS NULL AND
                              ACCOUNT.HOST_SYSTEM_ID = 'P';
38668 rows selected.
Execution Plan
Plan hash value: 409974871
| Id  | Operation                       | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                |                  | 17367 |  2849K|   479   (4)| 00:00:06 |
|*  1 |  HASH JOIN                      |                  | 17367 |  2849K|   479   (4)| 00:00:06 |
|*  2 |   TABLE ACCESS FULL             | ACCOUNT          |  5705 |   172K|    56   (2)| 00:00:01 |
|*  3 |   HASH JOIN                     |                  | 42728 |  5716K|   422   (4)| 00:00:06 |
|*  4 |    HASH JOIN                    |                  |   153 | 17136 |    10  (20)| 00:00:01 |
|   5 |     MERGE JOIN                  |                  |   116 |  6496 |     6  (17)| 00:00:01 |
|   6 |      TABLE ACCESS BY INDEX ROWID| SEVERITY         |     2 |    12 |     2   (0)| 00:00:01 |
|   7 |       INDEX FULL SCAN           | PK_SEVERITY      |     2 |       |     1   (0)| 00:00:01 |
|*  8 |      SORT JOIN                  |                  |   116 |  5800 |     4  (25)| 00:00:01 |
|   9 |       TABLE ACCESS FULL         | ALERT            |   116 |  5800 |     3   (0)| 00:00:01 |
|* 10 |     TABLE ACCESS FULL           | ACTIVITY         |   153 |  8568 |     3   (0)| 00:00:01 |
|* 11 |    TABLE ACCESS FULL            | ACTIVITY_ACCOUNT | 42868 |  1046K|   412   (4)| 00:00:05 |
Predicate Information (identified by operation id):
   1 - access("ACTIVITY_ACCOUNT"."ACCOUNT_ID"="ACCOUNT"."ACCOUNT_ID")
   2 - filter("ACCOUNT"."HOST_SYSTEM_ID"='P')
   3 - access("ACTIVITY"."ACTIVITY_ID"="ACTIVITY_ACCOUNT"."ACTIVITY_ID")
   4 - access("ACTIVITY"."ALERT_ID"="ALERT"."ALERT_ID")
   8 - access("ALERT"."SEVERITY_ID"="SEVERITY"."SEVERITY_ID")
       filter("ALERT"."SEVERITY_ID"="SEVERITY"."SEVERITY_ID")
  10 - filter("ACTIVITY"."STATUS_ID"<>3 AND "ACTIVITY"."ACTIVITY_DATE"<SYSDATE@!)
  11 - filter("ACTIVITY_ACCOUNT"."UPLOADED_DATE" IS NULL)
Statistics
          0  recursive calls
          0  db block gets
       4633  consistent gets
          0  physical reads
          0  redo size
    3111385  bytes sent via SQL*Net to client
      18277  bytes received via SQL*Net from client
       2579  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
      38668  rows processedAs you see, Step 11 is doing a full table scan. Should I be using a different index besides the standard B Tree?

Answer 1

A B-tree index will not contain references to NULL values in an index because NULL compared to any other value is always false, even if that other "value" is NULL (strictly speaking, NULL isn't a value at all).
A bitmap index will, however, have a bitmap for NULL. Whether or not a bitmap index is useful on that particular column is another story. But you did ask so I felt compelled to answer.
If a bitmap index is inappropriate, consider a function-based index where you turn the NULLs into something useful. For instance, if you build a function-based index on
CASE WHEN some_col IS NULL THEN 1 ELSE 0 END
you might be able to put the same syntax in your where clause and experience the performance you need.