Lotus Nut

Recently I have run into an issue with moving users (specifically the "Accelerated Create Replica" AdminP request) from 7.x or earlier to 8.x servers. The new replica that gets created on the 8.x server is not at ODS48. The CREATE_R8_DATABASES=1 setting is correct on all servers. I have checked with IBM and this is similar to an internal technote.

So, in the meantime, I have whipped up some code to find databases not at ODS48, dump them into an Indirect File, and run a compact -v -n -c on them to enable design and "body" compression and perform the copy-style compact to update it to the new On-Disk Structure.

In response to: Another problem with the document table map property

Chad, thanks for posting this information that I've personally seen happen (unfortunately it was on a NAB!). Thanks for letting us all know that this particular issue with the "Optimize document table map" property should be fixed in 8.0.3. Does this seem to happen more when the database is replicated with pre-8.0.2 servers? It seems that some of the customers in the forum (and my client as well) saw this issue when the database was replicated with 8.0.1 or earlier servers. I'm cross-posting this comment to my blog as well.

In response to: What is your typical database maintenance routine?

Regarding Compact, I had an entry I posted a while back related to fragmentation and compacting. In that, I actually recommended using something like a load compact -c +10. We all know that fragmentation causes very poor performance. However, defragging causes the databases to be even more fragmented because every new write will likely be to a non-contiguous block on the drive. I've been pondering this a lot more lately and thinking that allowing the 10% white space (like you mentioned) is actually a good idea. Something could even be accomplished by some code to add data to a database and then delete it so that there's white space. Then defragmenting that database (using something like defraggler, you can choose to just defrag a single file at a time) will yield a contiguous space that will not become fragmented very quickly. This, coupled with archiving, I believe can be a pretty good boost in i/o performance. I'm cross-posting this comment at my blog too for further thoughts...

Yeah, David beat me to it! I think there were a lot of concerns with previous versions related to DB integrity. So we still see a good many customers still running fixups fairly regularly (more than once per week). I don't guess this would hurt, but it would definitely cause a good bit of overhead for something that's pretty unnecessary.