shailendra atre
New Member
dear Tom,
in which condition we use Recovery log threshold?
with regards
Shailendra
in which condition we use Recovery log threshold?
with regards
Shailendra
recovery log threshold
- Thread starter shailendra atre
- Start date
RealHeavyDude
Well-Known Member
On top of my head the term "recovery log threshold" is not familiar to me. Could you provide more information like where you have read or heard about it? Furthermore, it would be very polite if you would also provide some other basic information like what Progress/OpenEdge version you are talking about and on which OS this is running.
Heavy Regards, RealHeavyDude.
Heavy Regards, RealHeavyDude.
shailendra atre
New Member
dear dude
-bistall Quiets a database and sends a message to the
log file when the recovery log threshold is
reached. Use with -bithold.i found in progress administration guide
-bistall Quiets a database and sends a message to the
log file when the recovery log threshold is
reached. Use with -bithold.i found in progress administration guide
RealHeavyDude
Well-Known Member
Sorry, just had a brain camp in the morning. Over time the BI usually reaches a certain high water mark and should not grow any bigger unless there are some unexpected things (like an usual high transaction load or unexpectedly long running transactions). In such a case the BI would grow bigger than usual. Depending on how your system is laid out the BI might reach some limit (for example filling the file system) which causes the database to shut down abnormally when it can't write to the BI anymore. In order to prevent that from happening, for one you can limit on the BI so that it can't grow any bigger before such a limit is reached. Secondly, in order to prevent the database from shutting down abnormally you can use BI stall so that it goes in a read-only mode instead. This should give you time to be able to analyze and fix the root cause.
Heavy Regards, RealHeavyDude.
Heavy Regards, RealHeavyDude.
TomBascom
Curmudgeon
Many years ago there was a 2GB limit associated with the bi log. If the active bi log hit 2GB the db would crash and you would not be able to recover because recovery takes (roughly) 2X the bi space as was active at the time of the crash -- and if you crash because you used too much BI you are in an infinitely recursive logic loop that you cannot get out of 
To prevent that from happening -bithold could be set to some value well below 2GB. 900MB being a common value.
Starting with v9 the 2GB limit was removed and the need to use -bithold for that purpose eliminated.
But many other improvements have since been made to the DB engine... some of those improvements have been focused on greatly increasing transactional throughput. An unplanned side effect of those improvements is that it is now possible for poorly written code to write vast amounts of data to the bi log very, very quickly. So you can potentially fill up your filesystem quite rapidly. Maybe even before you have time to notice and do something about it. Luckily that is not as fatal an event as the old 2GB bi limit -- it is easy to add more disk space and recover. But it is a pain in the neck and users tend to frown on long outages so -bithold is still a handy option for limiting excessive bi log growth. A good idea is to set it to either 1) a "reasonable" value for your application (if you know such a value, which is uncommon) or 2) a fraction of the filesystem size -- such as 25%.
To prevent that from happening -bithold could be set to some value well below 2GB. 900MB being a common value.
Starting with v9 the 2GB limit was removed and the need to use -bithold for that purpose eliminated.
But many other improvements have since been made to the DB engine... some of those improvements have been focused on greatly increasing transactional throughput. An unplanned side effect of those improvements is that it is now possible for poorly written code to write vast amounts of data to the bi log very, very quickly. So you can potentially fill up your filesystem quite rapidly. Maybe even before you have time to notice and do something about it. Luckily that is not as fatal an event as the old 2GB bi limit -- it is easy to add more disk space and recover. But it is a pain in the neck and users tend to frown on long outages so -bithold is still a handy option for limiting excessive bi log growth. A good idea is to set it to either 1) a "reasonable" value for your application (if you know such a value, which is uncommon) or 2) a fraction of the filesystem size -- such as 25%.
