Bi Threshold

[durgaprasad1538]

Hi All,

We are planning to setup Bithold for our databases . These are things i getting confused

1)How will we decide the starting Bithold value (As per document : The recommended threshold is between three and one hundred percent (3-100%) of the largest possible recovery log file size, rounded to the nearest cluster boundary Clusters)?
2) Is bi thold still required if we already enabled large files?
3) During Bi thold once the threshold value reached any constraints on application end when proquiet enabled?

To calculate Bi threshold
How many biclusters * bi cluster size

Bi clusters means where we can see how many Bi clusters formed?

Database size: 30Gb Progress version 11.4.AI not enabled.

Red Hat Enterprise Linux Server release 6.6 (Santiago)

And also PFA...... Bi log details

Regards,
............

 

[Chris Hughes]

I don't enable this for our customers, my general understanding is that it isn't really used any more.

As you have said you have enabled large files so the last variable extent would just grow anyway. Old OS used to have file size limits of 2GB - which this setting protected against.
Are you short on disk space where your BI is - that could be a reason for setting it.

Do you have bugs in your software right now that cause the BI file to grow rapidly and unexpectedly?

Regarding disk space I think off the top of my head you need to allow double the actual BI size on disk to recover the database if required.

There are others that will be able to give you more detail I'm sure.

 

[durgaprasad1538]

Hi Chris,

Thanks for quick update.

We don't have any disk space issue. My idea is if any schema updates or any long running transactions happening BI file grows.To avoid such things Bithold is helpful for our database not getting shutdown.

And also kindly help me how to setup starting value for bithold.how to calculate it.
And how to find exactly how many BI clusters are formed for database.

 

[TomBascom]

Many of the original reasons for using -bithold have gone away.

But at the same time -- there is no good reason why an application should have large bi files. And when things go sideways modern servers can make that bi file grow at crazy fast rates (I've seen 100GB filesystems filled in just a few minutes of out of control bi growth...)

The issue is that to recover from a db crash due to the bi file filling a filesystem you will need roughly 2x to 3x the bi space that was used (backing out the bi notes needs to write even more bi notes...) Which means that, ideally, you really don't want the bi file to take up more than about 25% of the filesystem that it is on. Otherwise you're going to have to go out and add disk space -- sometimes that it easy but often times it means that users have to wait while someone scrambles to find space and add it.

Having said all of that... I would not get into the weeds of trying to find the perfect values for bithold by calculating anything related to cluster sizes and so forth. Just set it to some modest value that is big enough for your application's normal bi usage. I like -bithold 900 as my "I have no better idea" rule of thumb value.

 

[Cringer]

And if you are worried about the potential for your BI to grow out of control then you should get a good look at your transaction scoping within the application.