Not In Too Slow

Question

Hello. I have a simple performance problem.
It's a common configuration error to have a user account, but no extended information about them. To help administrators identify this, I've created two views. Anyone who is in view 1, but not view 2 is a potential problem, so I'd like to show them to administrators in a report.
The problem is that the statement:
select user_name from view1 where user_name not in view2;
is a real dud. It rarely returns in a reasonable amount of time. Table 1 has about 6000 entries and view2 has about 500 entries.
How should I be doing this?

Answer 1

Kevin:
You raise a good point. If the queries underlying the views are slow, then optimizing this query is probably not going to help much, if at all.
Sri:
Which is better, depends on a number of factors. I think that some of the most important factors are:
1. Absloute sizes of the two tables
2. The relative sizes of the two tables
3. CBO versus RBO
4. Version of Oracle
5. Which columns are being compared.
Number 5 may need a little clarification. If the question is find all PK's in table1 which do not exist in table2, then I would more likely use NOT EXISTS or perhaps OUTER JOIN. However if the question is find entire rows in table1 that do not have a corresponding entire row in table2 then I would be more likely to use MINUS.
If we assume that there are no criteria used agains either table (which might affect the choice of indexes), then all methods will require at least one full table scan (at best a fast full index scan), and sometimes two. So, the chief factor affecting performance is the method Oracle uses to get the rows in table1 that do not exist in table2. On a conceptual basis, this is how I understand the various approaches operate. This is almost certainly not the exact algorithm that Oracle uses.
The NOT IN will do a full scan of table2 to get a list of values, then for each row of table1 scan this LOV to see if it finds a match (FILTER operation). If not, add the record to the result set. If table two is absolutely small (e.g. state_code table with 50 records) then this may well be the fastest approach since scanning the LOV should be fast in memory.
MINUS does a full scan of both tables, sorts each, then scans the two lists together to identify mismatches (MINUS operation). If the two tables are relatively similar in size, then this is likely to be one of the faster methods. The optimizer may choose to use index scans if the columns being compared are all indexed. If you are trying to compare all columns, or a large (unindexed) subset, then this is likely to be the fastest method. It may also be faster if you expect a relatively large number of mis-matched records.
In a NOT EXISTS (or EXISTS), for each row in table 1, the correlated sub-query is executed against table2. If the all of the indentity columns in the sub-query are indexed, then this is pretty quick. The relative sizes of the tables do not matter much, but if both are large, this may be a little slower. Also, it is not as efficient when you need to look at values in several columns. If table2 is not appropriately indexed, and it is large, then this could be incredibly slow since it will require a full scan of table2 for each row in table1.
The OUTER JOIN approach uses the expected SORT JOIN - MERGE JOIN or SORT JOIN - NESTED LOOP approach (depending on the version and optimizer mode). This is pretty efficient, particularly if the two tables are large, and relativley equally sized, and you expect a relativley small number of mismatches.
There is also a fifth approach.
In sqlplus run $ORACLE_HOME/rdbms/admin/utlexcpt.sql then
ALTER TABLE table1
ADD constraint t1_t2_fk
FOREIGN KEY (column_list) REFERENCES table2 (column list)
EXCEPTIONS INTO exceptionsThen deal with the error rows you get in the table exceptions. This requires a unique index on column_list in table2.
Probably not useful for a one-off excercise, but it will prevent it happening on an ongoing basis.
John