Timothy Snyder wrote: > Manuel Owens <[EMAIL PROTECTED]> wrote > > > UCB is interested in enabling the RFS on our UniData Ben > > installation for use with our transaction files. > > I would be interested in hearing from anyone out there who > > has taken this step. I am particularly interested in > > any configuration/performance issues that arose from > > converting files to recoverable and/or surprises encountered. > > > > I would also welcome feedback on the positive impact the > > use of RFS has had at your site.
> There are many benefits to implementing RFS, but you have to > be careful. > The protection offered does require some additional system > resources in > terms of memory and CPU. And the logs that are at the heart > of RFS can > require significant disk resources if your transaction rate > is high. It > is sometimes necessary to beef up the system hardware before > implementing RFS. Tim makes some good points in his post. I think that the 'significant disk resources' thing needs to be put in context for modern computer systems. Yes, you'll need a few gigabytes of space for your image and archive logs, but these days it is hard to buy a disk smaller than 30GB, so the real problem becomes how to place these log files to maximise performance and resilience - obviously you don't want transaction log files and the database on the same platters or you will cause unnecessary IO waits and risk losing everything if you lose the disk. But you also need to think about separating the image logs from the archives because there is a lot of IO between the after images and the archive logs at each checkpoint and if you can't move data out of your previous after image set and into the archive log by the next checkpoint you'll end up with the entire database waiting most of the time. The important thing is not just to switch RFS on, but to try and understand what you want to achieve from it, how it facilitates those goals of yours, and then to make sure that you give it the best chance to succeed at the task you are setting it. If you were somewhere in my part of the world, I'd try and interest you in a few days consulting to get this up and running, but with you in California, I'd suggest you think strongly about getting Tim or someone from IBM or a big VAR like Strategy 7 to come and assist. Two points I'll throw in quickly because one of them goes a little against the letter of what Tim said (though I suspect not against what he intended). 1) Be very wary of only switching on RFS for 'one or two' files. If the perception in your organisation is that with RFS on, you'll be able to restore a backup and roll forward your transactions to get the database back up to the minute after a major failure, then you'll need pretty much every file that contains persistent data to be recoverable. Yes, temporary work files can be left out, but omit things like VOC and you'll be completely stuffed. I'd look at making everything recoverable and then selectively switching recoverability off for specific files rather than going the other way round. 2) Like Tim said, offloading your archive files is really important. Do this to disk, or across the network to another machine. Under no circumstances should you even consider using the default arch_offload script shipped with UniData that tries to write them to tape. If you hit a program that starts picking up big records and making lots of small changes to them (like adding to huge long MV lists of status codes or action dates) then you will get bursts of extreme activity against your archive files and you'll need to be able to offload them quickly or your system will essentially dbpause itself while it waits for the offloads. One more point that shouldn't be overlooked is that while you can often get away with doing your backup of a normal UniData system while it is still nominally in use so long as people aren't actively updating it, once you switch RFS on that just won't work any longer because RFS makes UniData keep its own memory caches of blocks in files and what is on disk will seldom match the true state of the database. It is the combination of what is on disk, and what UniData has in its image logs that allows a consistent state to be achieved after any crash. Restore a backup of just the disk versions of the files and you'll be in trouble. In fact, any OS level manipulation of UniData recoverable files is a bad idea. I had a client that switched RFS on and then couldn't understand why the system crashed once a month while they were running a job that moved a months worth of data from 12 months ago into archive by physically moving the UNIX file holding that data to a different directory and copying an empty template file into its place. You'll need to either shut down UniData to do a backup, or use dbpause to suspend activity and synchronize the disk images of files then do your backup or create a snapshot for backup before using dbresume to get going again. You'll see a bigger memory footprint and slower disk writes with RFS on, but you may see faster reads and a lot of that memory is shared between all your users. Best Regards, Ken Wallis > Also, we've seen problems when people have tried to implement > RFS without > a full understanding of it. RFS can be fairly complex to set > up. By its > nature, it will do what it can to protect the integrity of > the database. > If anything is not set up correctly, it's possible that > update activity > will be suspended and in some cases the database will be shut > down if data > loss appears imminent. A common mistake is to set up archive > logs without > properly off-loading them. If archive logs aren't off-loaded > properly, > update activity can be suspended and manual intervention is > required. You > need to be careful about which files are made recoverable. > If very active > files are made recoverable, they will add to the logging > overhead. You > need to be sure you're marking as recoverable all of the > critical files > without logging some that aren't necessary, such as temporary > work files. ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
