Re: Logical Logs to Disk?

FWIW - it really doesn't matter where you back up if you have no idea if your backup is good. I think later versions of IDS bundle the archecker utility for this purpose. Tape seems to be preferred even when doing system backups, not so much for reliability (tapes fail miserably too, but less, because they are used less frequently), as for off-system, and possibly off-site, storage. On Mon, 11 Jan 1999, Neil Truby wrote: > > David Williams wrote in message ... > > > Yep. > > > > We had recently had a failure on a Sun box of the part of the > > motherboard which handles disks/tapes. The tape drive was not affected > > but the disks were (we had 2 chunks go offline and Solaris report > > errors on 4 other disks). Had we been logging to disk the logs would > > not be salvageable. > > > > Disks tend to fail more than tape drive don't they? (CAN someone > > confirm this? > > Did you have some sort of problem that was actually corrupting the disks, > rather than just reporting corruptions? If the latter, then the data would > still have been retrievable by connecting the pack to another server. (Not > ideal, I know!) > > FWIW. ever since I encountered Informix I've been surprised at the seeming > unquestioning acceptance of log back-ups to tape. For instance, the first > edition of Joe Lubmley's excellent "Informix Database Adminstrator's > Survival Guide" mentions the possibility of it being possible to have disk > saving "kludged together", but clearly doesn't really believe in it and > spends the next six or seven pages describing tape strategies. And clearly, > the very name of the utility suggests that tape is its spiritual medium > (sorry!). > > I've worked on systems that deploy both methods and, provided that its > underpinned by water-tight scripting and highly-resilient disk, I believe > that backing up logs to disk can provide an equivalent level of safety for > much less maintenance and intervention. > > Neil Truby > aracnet Limited > Weybridge, UK > > > > > > > > > >>------------ > >> > >>One of the most difficult things about Informix and ontape is that it is > >>designed to back up the logical logs to a single tape. Once that tape > >>fills up, the logical log backups stop, and the server hangs. This > >>means that you must constantly be watching the tape drives to which were > >>backing up logical logs, swapping tapes throughout the day as they fill > >>out. It's important to note that you cannot monitor how close a tape > >>drive is to being full. You can only watch your logs to see when > >>Informix has told you that a tape is full. It can also become > >>unmanageable because each Informix server requires a separate tape > >>device. Since it is not uncommon to have four or five Informix servers > >>on a single host, you would need four or five tape drives just to do > > > > ??? You should only need one server per machine. Otherwise how do you > > allocate CPU VPs? If all the instances in total have more CPU VPs than > > physical CPUs you can get thrashing. If in total CPU VPS = number of > > physical CPUs than each instance can only use a small portion of the > > number of CPUs. > > > > Also do you have >1 instance accessing the same disk. Then disks heads > > will start trashing since each instance optimizes access to it's own > > part of the disk, not considering access to the rest of the disk. > >>your logical log backups. > >> > >>The alternative is to backup the logical logs to disk. The flexibility > >>that this affords you cannot be underestimated. You no longer have to > >>watch several log files on multiple servers to see if any of your > >>logical log devices are full. All of the logical log backups on a > >>single host can share a single /logical file system. You do not have to > >>swap tapes all day long. For each Informix server, you'll need a script > > > > In this age of 20GB tape devices, if you have a large enough server to > > consider 4/5 instances then you should be able to afford a 20Gb tape > > devices and that should last a day.. > > > >>that: > >> > >>1. Stops logical logging for a moment > >>2. Moves the current logical log backup file to a date time stamped file > >> > >>3. Creates another logical log backup file > >>4. Starts logical logging again > >> > >>Once this has been done, the only management required is monitoring the > >>available space in the file systems where you're sending your logical > >>logs. > >> > >>Informix support has never officially sanctioned this method. Their > >>answer is that ontape was designed to go to tape, not to disk. However, > >>there are hundreds of companies around the world that backup their > >>logical logs to disk. No one has ever pointed out any technical issues > >>with backing up to disk. It seems to be a matter of preference. > >> > > > > Disk failure. > >>Some DBAs do not feel that backing up to disk is a wise choice . They > >>feel that the logical logs are extremely important, and backing them up > >>to disk places them at risk. Disks can fail. If the disk drive that > >>contains your logical logs fails at the same time as the disk drives > >>that contains your database fails, you are out of luck. They feel it is > >>safer to get the backups out to tape. > >>I, however, and a strong proponent of backing up logical logs to disk. > >>I feel that the value that is added by backing up to disk far outweighs > >>the added risk. I would also present that backing up to tape has risks > >>as well. By reasoning is as follows: > >> > >>1. Backing up to disk allows complete automation. No one has to > >>remember to swap tapes. No one needs to be available to swap tapes. > >>Continuous backups just happen. It's always a good thing to automate > >>your backups. Why would you want operators, when a simple shell script > >>will do the job for you -- day in and day out? > >> > > What happens if you run out of disk space? > > > >>2. Oracle backs up its redo logs to disk. > >> > > Oracle Urrrg! > >>3. The slowest portion of an Informix database restore is the reading of > >>the logical logs. Placing the logical logs on disk significantly > >>increases the speed of this critical path of a restore. > >> > > > > 20GB tape drive = 50Mb per 14seconds!! > > > >>4. The "all your eggs in one basket" problem is solved by using remote > >>devices. For example, you can backup elvis' logical logs to a file > >>system on apollo. All that is necessary to do this is to specify > >>apollo:/logical/servername/logfile as the logical tape device. This > >>significantly reduces the chance that both the logical tape device and > >>the database server will be damaged at the same time. > >> > > ?? Device MTBF does not depend upon which machine the device is > > plugged into.. > > > >>5. The proponents of logical log backups to tape would also state that > >>the above would not protect you from a fire that destroys both systems. > >>Don't forget that a fire would also destroy any tapes that are in the > >>drives! > >> > > What about power supply/motherboard/CPU failure, disks are