Re: Limited Transaction Logging

In a word - no. However, turning on logging does not mean that you have to open every program and put in a begin work and end work in each of your programs. Let me explain. There are really two things that logging gives us - 1) the ability to recover the database to the point of failure and 2) the ability to ensure that work gets done in logical units. If a system crashes for what ever reason, we want to be able to recover the data to the point of the failure. To do this there are basically two steps involved. First information from the physical log file must be put back to the database. This will cause the database to appear as it did at the point of the last checkpoint. Then the logical logs since that same checkpoint are replayed. This takes us to the point of failure. If the log information indicates that any transaction was active at the point of failure, then that transaction is rolled back by undoing the logical log entries associated with that transaction. During this replay of the logical log, it is imparative that the database appear exactly as it did when the original entry was done or recovery will fail. For instance, if there is a logical log entry which says to update the fifth row on page 3 of table foo and there is no such row, then how can the update be done? OK -- now for the second feature of logging - the ability to ensure that work gets done in logical units. If the database is not logged, then there is no rollback of a command at all. That means that if a command is being executed, it is possible that the command itself will not be executed as a unit. For instance, suppose that a command "update foo set col1 = 1" was issued. It is possible that the command might get half way through and encounter some kind of problem. Since there is no logging, there is no way that the command can be rolled back. That means that only some of the rows in table foo were actually updated. Now for the same situation in a logged database. If the command is issued and there has been no "begin work" statement issued, there is an implicit transaction started at the beginning of the statement. The command is executed and if the execution is successful, there is an implicit "commit work" entered into the log. If there is some kind of failure during the actual execution of the statement, then the entire statement is rolled back. This is sometimes refered to as command level transactions. That is, the command is either completly done or completly undone. This can not be guarenteed in an unlogged database. I would strongly encourage the use of logged databases, if only for the ability to ensure command level transactions. There are a lot of subtile problems that you can run into if using an unlogged database. Many of these problems will seem illogical unless it is understood what the full implications of an unlogged database imply. OK -- now for the impact of logging. If you are not concerned about recovering to the point of failure in the event of a disk failure, you can set your log tape device to /dev/null. This will still allow transaction processing and command level transactions. However, it is imperative that you have enough log space to hold all of the log entries for a given transaction. Also, it is imperative that the parameters for LTXHWM and LTXEHWM be in the 50/60 range. This is to ensure that you don't get into the situation where your log files get completly full. A couple of friendly suggestions. First of all, since you are in between DBA's, I would suggest that you contact your INFORMIX salesman for some possible help in getting this set up. Also, you're on 5.2. This is a rather old version and there's been quite a few patches in the 5.x product since then. It might be worth it to start considering migration to a more recent stability release of the 5.x product, such as 5.7. Madison Pruet