Recent content by dje

Just an additional point, verify doesn't make any sense in the case of an online backup so Progress ignores your -vp switch when you request an online backup. This is because it can't guarantee that blocks haven't changed as a result of normal backup activity between the time of the backup and...

Yes, that's correct. Well, as always, "it depends". Increasing -Mf demands increased -bibufs and -aibufs... and you are using both BIW and AIW, aren't you? It can be useful if the BI and AI disks are very busy. Otherwise it doesn't get you much. I don't think so. Cluster size only...

Yes, I don't see anything 'wrong' with the figures. But if the highish BI write rate bugs you, then perhaps you might try racking the BI block size back to 8kB. That should still give you enough BI write bandwidth to not bottleneck hopelessly during a billing run (note to non-Ron readers - I...

You may want to make sure that the AI and BI block sizes are the same. As a side note, using AI almost always forces BI partial writes to increase. This is because when you write an AI block it has to make sure that any notes in the AI block to be written have been first written to the BI...

Records per block in index-only storage areas Just another point, my $0.02 regarding index areas: Personally I think that using 1 record per block is needlessly risky - unless you are planning to have your storage area exceed 256GB (for an 8kB block size) I frankly don't see that there's any...

Just a quick follow-up to Ron's last post: The observed behaviour appears to have been caused by a combination of a (very) large table, an index whose active keyspace is randomly distributed throughout the total keyspace of the index, and the way that idxbuild works. As previously noted...