It's turned out that proutil -C bigrow is approx 6 times faster in V11.5 than in V10.2B on the same hardware:
prodb tmpdb sports
proutil tmpdb -C truncate bi -bi 1024 -biblocksize 16
echo proutil tmpdb -C bigrow 96
ls -l tmpdb.b1
echo y | prodel tmpdb
rm tmpdb.st
Tested on AIX and Solaris. In all cases it was Progress 64-bit.
I thought that bigrow is just the sequential calls of write() with O_DSYNC flag (unbuffered synchronous I/O).
How can the bigrow time depend from Progress version?
Regards,
George
The performance of bigrow was able to be improved on several platforms that support manipulation of the fcntl. Internal stuff that you should not need to worry about but suffice it to say that on those platforms the bigrow will extend the bi file with buffered writes and complete the operation with an fdatasync() to be sure data is on disk. The recovery subsystem is able to deal with a partially written bit in the even of a crash during the buffered writes.
This is similar to the behavior you would get if you were to do a bigrow with -r but with the -r you don't get the fdatasync() - something that probably should be changed at database close time.
This change was made in OpenEdge 11.3
BTW, you can revert to the old behavior by running with the -zextendSyncIO (extend with Synchronous I/O)
It is one of those -zecret parameters that we do not expect customers to ever need to run with but was added as a failsafe for support.
Richard,
Thanks for explanation.
We used bigrow to test the disk write speed. It's how we notice the difference.
Best regards,
George