Re: db2index.pl Questionable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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
Paul M. Whitney
E-mail: paul.whitney@xxxxxxx
Sent from my browser.




_______________________________________________
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

[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux