2

I am doing some maintenance on a database for an application that uses the Bold for Delphi object persistence framework. This database has been been in production for several years and several of the tables have grown quite large. One of them is the BOLD_CLOCKLOG which has something to do with Bold's transaction management.

I want to trim this table (it is up to 1.2GB, with entries from Jan 2006).

Can anyone confirm the system does not need this old information?

Laurel
  • 5,965
  • 14
  • 31
  • 57
DaveK
  • 709
  • 7
  • 21
  • Can't you just do a backup and then zap it? :-) – Warren P Jan 16 '12 at 18:39
  • 1
    That's the plan, but there are no tests, so I don't want to put it into a state where it looks fine for a while, then a few weeks later bombs on some rare operation. – DaveK Jan 16 '12 at 18:57
  • It should be pretty safe to nuke things that are > 1 year ago. I find it hard to believe they would not have "keyframes" in their transaction log, that is, if the length of the log reads extends to infinity, then the performance of bold has no lower bound, it can be slow down to unbounded levels. :-) – Warren P Jan 17 '12 at 14:22
  • After testing, I deployed a script to truncate BOLD_CLOCKLOG on a weekly basis. It's been out there for a while now and is working just fine. Thanks for the input! – DaveK May 10 '12 at 13:13

2 Answers2

2

From the bolds documentation:

BOLD_CLOCKLOG

To be able to map the transaction numbers used in the TimeStamp columns to the corresponding physical time (such as 2001-01-01 12:34) the persistence mapper will store a log with timestamps and times. Normally, this log is written for each database operation, but if the traffic to the database is very intensive, it is possible to restrict how often this log is written by setting the property ClockLogGranularity. The event OnGetCurrentTime should also be implemented to ensure that all clients have the same time.The usage of this table can be controlled with the tagged value: Model.UseClockLog

So I believe this is used for versioning Boldobjects, see Object Versioning Extension in bolds documentation. If your application don't need this you can drop this in the database.

In our Bold application we don't use that feature. Why don't simply test to turn off Bold_ClockLog in the model, drop that big table and try to use your application. I'm pretty sure if something is wrong then it say so at once.

I can also mention that we have an own custom objecthistoy. It is simply big string (as TStringList.DelimetedText) in a ObjectHistory class that have Time, user and a note about action. This suits our need better that Bolds builtin objecthistory. The disadvantage is of course that we need to add calls in the code when logging to history is done.

Roland Bengtsson
  • 5,058
  • 9
  • 58
  • 99
1

Bold_ClockLog is an optional table, it's purpose is to store mapping between integer timestamps and corresponding DateTime values.

This allows you to find out datetime of the last modification to any object.

If you don't need this feature feel free to empty the table, it won't cause any problems.

In addition to Bold_ClockLog, the Bold_XFiles is another optional table that tends to grow large. But unlike the Bold_ClockLog the Bold_XFiles can not be emptied.

Both of these tables can be turned on/off in the model tag values.