select ...
from table
where (param_1 is null or field1 = param_1)
and
(param_2 is null or field2 = param_2)
and
(param_3 is null or field3 = param_3)
и.т.д

стандартная схема пропука пустых параметов.

к Billing Group:

> SELECT name1, name2, name3
> FROM CUSTOMER
> WHERE NVL(:name_param1,name1) = name1
> AND NVL(:name_param2,name2) = name2
> AND NVL(:name_param3,name3) = name3

Такой запрос в принципе не правильный поскольку:
-- в случае :name_param1 is null и name1 is null что в результате
-- NVL(:name_param1,name1) полностью выключит индексы
и мы получим только и однозначно FULL SCAN TABLE

мой вариант тоже не полный т.к. не учитывал null/null значений
но в изначальной постановке null для параметра означал, что такой параметр проверять не надо.

полная схема проверки, которая сохраняет в живых индексы должна быть:
((param_1 is null or field1 = param_1) or (param_1 is null and field1 is null))

Зачем спорить просто я покужу разницу на примере, включая
execution plan --> это очень просто!!!

SQL> create table test_plan
2 as
3 select object_id, object_name, object_type
4 from all_objects;
Table created.
SQL> select count(*) from test_plan;
COUNT(*)
----------
23510
SQL> create index i1_test_plan on test_plan(object_id);
Index created.
SQL> create index i2_test_plan on test_plan(object_name);
Index created.
SQL> create index i3_test_plan on test_plan(object_type);
Index created.

SQL> analyze table test_plan compute statistics;
Table analyzed.

SQL> set autotrace traceonly;
SQL> select * from test_plan
2 where
3 (23 is null or object_id = 23)
4 and
5 (null is null or object_name = 'TEST_PLAN')
6 and
7 ('TABLE' is null or object_type = 'TABLE');
no rows selected
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=38)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TEST_PLAN' (Cost=2 Card=
1 Bytes=38)
2 1 BITMAP CONVERSION (TO ROWIDS)
3 2 BITMAP OR
4 3 BITMAP CONVERSION (FROM ROWIDS)
5 4 INDEX (RANGE SCAN) OF 'I1_TEST_PLAN' (NON-UNIQUE)
(Cost=1)

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
2 consistent gets
0 physical reads
...
0 rows processed

SQL> select * from test_plan
2 where
3 nvl(23,object_id) = object_id
4 and
5 nvl(null,object_name) = object_name
6 and
7 nvl('TABLE',object_type) = object_type;

no rows selected


Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=17 Card=1 Bytes=38)
1 0 TABLE ACCESS (FULL) OF 'TEST_PLAN' (Cost=17 Card=1 Bytes=3
8)

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
149 consistent gets
0 physical reads
...
0 rows processed

Прошу обратить внимание на :
-- TABLE ACCESS (FULL) OF 'TEST_PLAN'
против
2 1 BITMAP CONVERSION (TO ROWIDS)
3 2 BITMAP OR
4 3 BITMAP CONVERSION (FROM ROWIDS)
5 4 INDEX (RANGE SCAN) OF 'I1_TEST_PLAN' (NON-UNIQUE)
(Cost=1)
поскольку версия 9i то при таких типах запросов оптимизатор
бубет пытаться применить onlinr битовые матрицы для выполниея запроса -- очень быстрый способ

а также на:
2 consistent gets
против
149 consistent gets
правда первый запрс смотрится в 30 раз эффективнее...