Circular vs Roll Forward logging

[Zorlac]

Just finished a training course and the trainer recommended that 'Roll forward' logging should be used in a production environment.

I then asked our 3rd party TSM implementer and support, who told me circular logging is a better option.

Just wondering what the 'real world' preferred configuration is? Pros and cons?




.Z

 

[denisl]

Roll Forward - If log fills up server will stop and emergency extension will be required. If the server needs to be recovered you can recover up to the moment before failure by restoring the full database backup and applying the log.

Normal (circular) - The log should never fill up (it can). If the server needs to be recovered your recovery point is to the last database backup.

The choice is usually based on your client SLA's. I would imaging the majority run in normal mode due to ease of adminstration and acceptable data loss in the event of a server recovery. With 13GB log sizes roll forward becomes a lot more managable then in the past and should be considered at least for some servers.

You can "reset logconsumption" and "reset logmaxu" daily and "q log f=d" to understand your log behavior and see if roll forward will work for you. Start off in normal mode.

 

[chad_small]

Rollforward is the best method so you don't lose recent backup data. The DB is only as good as your last backup with Normal mode, but with ROLL-FORWARD any activity since the last DB backup is recorded in the log and able to be recovered to the most current transaction commit point. I would only use NORMAL mode if I had log pinning issues (which I do on one of my servers).

 

[Zorlac]

thanks for the feedback.

As we don't run continuous backups or any backups during the day, would roll forward be overkill for us? The typical cycle is server backups overnight then admin tasks (db backups etc) in the early morning after the backups have completed.

 

[zatogo]

ChadSmall is right on with his recommmendation.

Even if you don't do backups throughout the day, in most environments, TSM is doing a number of things behind the scenes (ie, ie, reclamation, storage pool migrations, etc) during the day time and the log captures those changes between TSM DB backups.

One thing to watch for...you don't want the log filling up as it will halt the TSM server. Recovery is not that big of a deal...just irritating and there really is no excuse for it happening as the normal cause is a lack of TSM DB backups for days.

Lastly...I always recommend keeping the Log's total size around 10 GB (made up of 3-4 similar sized volumes)...with a physical max of 12.5 to 13 GB, you want to keep a little breathing room.

 

[THE_WIPET]

you can setup a DBBACKUPTRIGGER... once your log hit a certain percentage, the DB backup is trigger and the logs is clear.. ( Correct me if i'm wrong).. This can avoid a 3:00AM emergency call that the backup server is down cause the log is full...

Cheers

 

[spidermila]

Sure. DBBackuptrigger is a must when you have log in roll forward mode.

Recently we had a problem on log volume due to some HW error on DS. That caused TSM server to crash. Then it could not recover the log volume as it was supposed to because it was corrupt. I recommend not only to have roll forward mode but also having a mirror log volume and "MirrorWrite LOG" option set to "Sequential".