The dbsrv/dbeng -m option causes the transaction log to be truncated on every checkpoint. It is probably the easiest AND most extreme method of controlling log file growth.
Consider this (true) scenario: the transaction log of a "high throughput" database grows by 6G per day... in a test... with production growth rates expected to be higher. Running with -m does not seem to affect performance too much, although there seems to be a bit of a query slow down while each checkpoint is in progress... and -m certainly does eliminate log file growth.
OK, so the database is not protected against the physical loss of the database file, that's a given as a "con". And no, this won't work for a SQL Remote or MobiLink application.
Are there any other cons?
Suppose the server crashes... will the normal starup recovery process work OK? (assuming the database and log files are readable).
Any and all comments and replies are welcome!
asked 23 Sep '10, 11:39
This is just an incidental use, not it's primary indented purpose, but I often use -m in preparation for stowing a copy of a database for future reference or for distribution, in order to collapse the size of the log file. I just take the copy of the database and log files, start them with -m, and as soon as the server comes up, stop it. Voilà!
(Note the usual caveats on when it's not okay to use -m.)
answered 03 Nov '10, 04:46