How to increase OID performance ( compared to SQL )

Question

I have an OID directory with about 100,000 entries in it. One
portion of our DIT has about 43,000 entries that use UID as part
of the DN.
If I need to get a list of the valid UIDs, it takes a very long
time to do it via OID. Since I know a little about how OID
stores the data inside Oracle, I know how to write an SQL
statement to pull out the data. ( I know, I am not supposed to
do this...)
The point is that if I use ldapsearch, the query takes about 2.5
minutes, which the SQL query takes only 11 seconds.
This would seem to me to indicate that it is an OID issue, not a
database issue. How can I tune OID to make this process go
faster?
Bob
[email protected]
p.s. If you are interested, here is what I am doing.
date
ldapsearch -D cn=orcladmin -w welcome \
-b ou=account,o=lilly,dc=com uid=* uid \
> ldap_uid.out
date
cat <<EOF > get_uids.sql
host date
set termout off
set pagesize 0
set trimspool on
set echo off
set verify off
set feedback off
spool icux3001.uid
select attrvalue from ods.ct_uid u, ods.ct_dn d
where u.entryid=d.entryid
and d.parentdn='dc=com,o=lilly,ou=account,';
spool off
set termout on
host date
exit
EOF
sqlplus / @get_uids.sql
Here is the output from that script.
$ ./compare_ldap.ksh
Connected to: PRODUCTION ENTERPRISE DIRECTORY SERVICE ON ICUX3001
Wed Oct 10 15:10:38 EST 2001
Wed Oct 10 15:13:12 EST 2001
SQL*Plus: Release 8.1.7.0.0 - Production on Wed Oct 10 15:13:13
2001
(c) Copyright 2000 Oracle Corporation. All rights reserved.
Connected to:
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
JServer Release 8.1.7.0.0 - Production
Wed Oct 10 15:13:13 EST 2001
Wed Oct 10 15:13:24 EST 2001
Disconnected from Oracle8i Enterprise Edition Release 8.1.7.0.0 -
Production

Answer 1

I would like to add the original question. I putan OID on my NT
workstation. I am running a JNDI stress-test program from a
separate server, doing 300 lookups. I run an initial prime to
make sure everything gets into memory, then a second test. In
theory it seems to me that it should be entirely memory
lookups. The CPU and memory stats look fine from NT Task
Manager. However, during the test I can hear the disk drive
going tap-tap-tap; obviously it is being hit again and again.
When I run statspack (granted, this is a very short test) the
following is said:
Top Wait Events
sort segment request: 1 wait, 103 wait time (cs)
db file sequential read: 33 waits, 71 wait time
control file parallel write: 14 waits, 38 wait time
control file sequential read: 37 waits, 35 wait time
So, why are there so many sequential file reads and writes? Is
it something with redo? Later on the report says:
redo blocks written 479
redo entries 209