On 05/16/2017 02:23 PM, Paul Whitney
wrote:
Hi guys,
I am trying to update the index on our userRoot database. I
imported the attribute using the ldif2db routine. Error log
reports success.
Then I ran the db2index.pl routine with no particular
attribute
(in essence I guess the whole database is re-indexed) causing
the database to grow, fill partition up, and crash.
What files are consuming all the disk space?
Tested on another system similar process but this time used
the "-t" option with the new attribute. Error log shows
success. However, no re-indexing occurred.
How are you verifying the index was not re-indexed?
Are you using dbscan to verify that a key is missing that should be
present?
Are you looking at file timestamps?
What is in the errors log exactly?
When we import through the console, then add the attribute
for indexing, the console kicks off a reindex of the database
with the new attribute selected.
Stats:
Version 389-DS: 1.3.5.10
Can you please do a: rpm -qa | grep 389-ds-base
Command used to import attribute:
/usr/lib64/dirsrv/slapd-test/ldif2db -n userRoot -i
/var/log/dirsrv/slapd-test/my.ldif; systemctl start
dirsrv@test.service
Command to index:
/usr//lib64/dirsrv/slapd-test/db2index.pl -D "cn=Directory
Manager" -w - -n userRoot (re-indexes all but fills partition
and crashes)
Second test:
/usr//lib64/dirsrv/slapd-test/db2index.pl -D "cn=Directory
Manager" -w - -n userRoot -t my_attribute:pres (log reports
success but does not re-index like it does on console.)
Any ideas on why through console it indexes the whole
database with new attribute, but not from the command line?
To see what the console does verses db2index.pl you can always turn
on audit logging, and you'll see what it is doing for each one.
Thanks,
Mark
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
|
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx