Does oracle db serialize concurrent read-only SELECT ? (ora10gr2)

Question

Hi all.
Sorry for a bit provocative topic name )
While testing multiple concurrent select request I found that
the server seems to serialize cursor SELECT done from multiple threads (Java jdbc).
There is no write operations on the table.
I'm doing a SELECT from 2 tables and measure the time it takes to execute the select and fetch matched rows. The result of N concurrent SELECTs is approximately N times a single SELECT.
The logic behind: there is a black list of customers with their all variations of names(spellings, AKA, former known as... etc). We need to check all system customers against the black list.
Technical data:
Table with names is about 1,000,000 records.
Customer table contains about 500,000 records.
Customers to verify: 400,000
Here are the tables:
CREATE TABLE CUSTOMER_ENTITY
ID NUMBER(19) NOT NULL,
IS_ACTIVE NUMBER(1) NOT NULL,
IS_COMPANY NUMBER(1) NOT NULL,
primary key (ID)
CREATE INDEX IDX_CUSTENTITY_ACTIVE_COMPANY ON CUSTOMER_ENTITY
(IS_ACTIVE, IS_COMPANY);
create table RDB.CUSTOMER_NAMES (
ENTITY_ID number(19,0) not null,
TYPE varchar2(255 char) not null,
FIRST_NAME nvarchar2(255),
LAST_NAME nvarchar2(255),
COMPANY_NAME NVARCHAR2(255),
Constraints and indices:
ALTER TABLE CUSTOMER_NAMES ADD (
CONSTRAINT FK3B65D3874835ED42
FOREIGN KEY (ENTITY_ID)
REFERENCES CUSTOMER_ENTITY (ID)
ON DELETE CASCADE);
CREATE INDEX IDX_CUST_NAMES ON CUSTOMER_NAMES
(ENTITY_ID);
CREATE INDEX IDX_CUSTNAMES_LASTNAME ON CUSTOMER_NAMES
(NLSSORT("LAST_NAME",'nls_sort=''BINARY_CI'''));
CREATE INDEX IDX_CUSTNAMES_COMPANYNAME ON CUSTOMER_NAMES
(NLSSORT("COMPANY_NAME",'nls_sort=''BINARY_CI'''))
CREATE INDEX IDX_CUST_NAMES_TYPE ON CUSTOMER_NAMES
(TYPE);
SELECT statement:
set timing on;
select * from
(select distinct customer.id, customer.birth_day, customer.birth_month, customer.birth_year from
(select names.entity_id from RDB.CUSTOMER_NAMES names where names.LAST_NAME='KRAAIPOEL' )
namesin inner join RDB.CUSTOMER_ENTITY customer on namesin.entity_id=customer.id) customerin
inner join RDB.CUSTOMER_NAMES namesout on customerin.id=namesout.entity_id
00:00:00:23
Before check the session is altered to enable string case insensitive comparison as follows:
alter session set nls_comp=ansi
alter session set nls_sort=binary_ci
I have no idea, no clue where is a bottleneck.
I appreciate your help.

Answer 1

Hello Sybrand Bakker.
Your assumptions about the KGB are very close )
OS: Red Hat Linux 3.2.3-42 (2.4.21-20.EL)
Hardware: Dual-Core AMD Opteron(tm) Processor 2214 (1.6GHz), RAM 3GB
NLSSORT is utilized on a session level.
alter session set nls_comp=ansi;
alter session set nls_sort=binary_ci;
set autotrace traceonly
We search among all customer's names (aka, spellings and so on..), but the result should contain customer's primary name:
select * from
        (select distinct customer.id, customer.birth_day, customer.birth_month, customer.birth_year from
                     (select names.entity_id from RDB.CUSTOMER_NAMES names where names.LAST_NAME='KRAAIPOEL' and (names.FIRST_NAME is NULL OR names.FIRST_NAME=NVL('robert',names.FIRST_NAME))) namesin
                  inner join RDB.CUSTOMER_ENTITY customer on namesin.entity_id=customer.id) customerin
         inner join RDB.CUSTOMER_NAMES namesout on customerin.id=namesout.entity_id where namesout.type='Primary Name'
Output is:
Execution Plan
   0      SELECT STATEMENT Optimizer Mode=ALL_ROWS   2   236   22                          
   1    0   TABLE ACCESS BY INDEX ROWID RDB.CUSTOMER_NAMES 1   66   3                          
   2    1     NESTED LOOPS   2   236   22                          
   3    2       VIEW   2   104   17                          
   4    3         HASH UNIQUE   2   98   17                          
   5    4           NESTED LOOPS   2   98   16                          
   6    5             TABLE ACCESS BY INDEX ROWID RDB.CUSTOMER_NAMES 2   70   12                          
   7    6               INDEX RANGE SCAN RDB.IDX_CUSTNAMES_LASTNAME 12     3                          
   8    5             TABLE ACCESS BY INDEX ROWID RDB.CUSTOMER_ENTITY 1   14   2                          
   9    8               INDEX UNIQUE SCAN RDB.SYS_C0020745 1     1                          
  10    2       INDEX RANGE SCAN RDB.IDX_CUST_NAMES 2     2                          
Statistics
        441  recursive calls
          0  physical write total IO requests
          0  physical write total multi block requests
          0  physical write total bytes
          0  physical writes direct temporary tablespace
          0  cursor authentications
          0  queries parallelized
          0  DML statements parallelized
          0  Parallel operations downgraded to serial
          0  Parallel operations downgraded 75 to 99 pct
          1  rows processedCould you explain the plan, please?
I think the cause is in
are exhausting your buffer cache, and subsequent invocations have to reload the data from disk.
Is there a way (does it help?) to increase the size of that buffer?
Database instance parameters:
ecom.__db_cache_size=88080384
ecom.__java_pool_size=4194304
ecom.__large_pool_size=4194304
ecom.__shared_pool_size=67108864
ecom.__streams_pool_size=0
*.db_block_size=8192
*.db_file_multiblock_read_count=16
Thanks.
null
null