Re: OnLine mirroring, SCO 5
Posted in 1995
Topics: Performance & Tuning, Installation, Setup & Upgrades, Storage & Space Management, Connectivity: ESQL/C, 4GL & Embedded SQL, Server Administration, Logging & Checkpoints, Jobs, Consulting & Announcements
>Max. downtime due to any deffect must be kept to less than 4 hours. >We plan to buy an Intel based server running SCO Unix. We have several successfull >installations of this type. >There will be nothing but an Informix OnLine db engine and our 4GL programs >running on this machine. Initially it will be a single 100MHz Pentium, but >with option to upgrade to 4 x 133 MHz Pentiums and possibly P6 later. > >Now however we plan to use mirroring. We haven't done that before and would >like to here any information/hints/stories about it, particularly on SCO >machines of course. We had an INFORMIX consultant in here a few months ago and we asked him about whether or not INFORMIX mirroring provided major performance boosts for queries and such. From what he said - the answer was no. Seems that INFORMIX uses a brain dead method of using mirrors during query operations. In essence INFORMIX tells one half of the mirror to service 50% of the query request and tells the other side of the mirror to service the last 50% of the disk reads. So, if you are in a heavy OLTP environment (as I am) I don't think you will find much improvement. Also, if your extents are less than 50% full the mirrors won't help either. >The disk hardware is hot swap. The main board of the machine is made by >Intel, while our supplier suggests Mylex disk controllers. >We will run the db on raw devices. You might want to see if your Mylex controller supports a RAID level that incorporates mirroring and striping - i.e. striped on 3 disks with the 3-disk pack mirrored on another pack of 3 disks. From my experience with the Mylex controllers running RAID 5 though, I have had excellent performance. Another option is to buy an external hot box and connect this to a second Mylex controller (the newest controllers have ports out the back for two FWIDE SCSI channels). Then you can place the most critical dbspaces (rootdbs and your critical tables) internally on one RAID controller and larger nonessential DSS tables externally hooked up to the second controller. The Mylex controller should have a connector for AEMI compliant storage systems so it might even be possible to also have hot swappable drives in the external box. Overall - intelligent allocation of dbspaces to different RAID controllers yields major performance boosts. Also, don't forget to use the battery-backed writeback cache on the Mylex controller - this has a definite benefit in the form of faster checkpoints and faster background LRU flushes. Lastly - you should have a second onconfig file handy with different tuning for the event of a databse restore. I have noted that if you completely retune the engine so that almost all available memory is allocated as one gigantic queue (BUFFERS = a very big number!) with one cleaner and your logical tape block size is set to 1024 - log roll-forwards will positively zoom along after the sync on the first checkpoint after a restore. In my tests I have rolled forward logs 16 times faster than they were generated. Stefan Schackow INFORMIX DBA - Intel Corporation