I have a unique situation relating to my conversion from 2.1 to 2.3. What I did: slapcat -c -f 2.1.slapd.conf remove entryCSN slapadd -c -q -f 2.3.slapd.conf
This worked well, but I got a few errors about duplicate data. It turns out that my 2.1 database had multiple entries of some near-the-top data. ex: dn: dc=com dc: com objectClass: dcObject objectClass: organization o: Example Org structuralObjectClass: organization entryUUID: 0ac313d0-4aba-1099-9dd8-f266f9337e15 creatorsName: cn=Manager,dc=example,dc=com modifiersName: cn=Manager,dc=example,dc=com createTimestamp: 20030720064923Z modifyTimestamp: 20030720064923Z
<100 lines later> dn: ou=SITE1,ou=people,dc=example,dc=com ou: SITE1 objectClass: top objectClass: organizationalunit structuralObjectClass: organizationalunit entryUUID: 80a3eee6-2c61-1028-8468-973a8421431b creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20040427064022Z modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20040427064022Z
<millions of lines later>
dn: ou=SITE1,ou=people,dc=example,dc=com ou: SITE1 objectClass: top objectClass: organizationalunit structuralObjectClass: organizationalunit entryUUID: c41ed3f6-2c62-1028-8418-82cea5fe7b2c creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20040427064925Z modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20040427064925Z
dn: cn=someuser,ou=SITE1,ou=people,dc=exmaple,dc=com etc: bar
dn: cn=someotheruser,ou=SITE1,ou=people,dc=exmaple,dc=com etc: foo
Now, during my slapadd, the FIRST definition of SITE1 was added, but it's really far away from all of its data. (the second one gave an error, so at least we have more correct data) The rest of my SITEn's are really close to their data, so searches based in ou=SITEn,ou=people,dc=exmaple,dc=com for objectclass=* return very quickly with top-level info and everything under it. For SITE1, however, there's a -long- gap.
I tried to reindex, and now I can find the top-level definition quickly, but the rest of the data is still slow to find (it appears to be searching for everything). Is there a way to get the data re-ordered so it's closer to where its children without slapcat, reorder manually, and slapadd? (would that even work?)
(By the way, this only hurts searches like the one described above, looking for actual people works the same throughout the dataset.)
matthew sporleder wrote:
I tried to reindex, and now I can find the top-level definition quickly, but the rest of the data is still slow to find (it appears to be searching for everything). Is there a way to get the data re-ordered so it's closer to where its children without slapcat, reorder manually, and slapadd? (would that even work?)
No other way. You can slapcat just that subtree into one file, and then slapcat everything except that subtree into another file, and then recreate the DB by slapadd'ing both files.
openldap-software@openldap.org