BI Buffer size & DB buffer size
- Thread starter SSuhaib
- Start date
TomBascom
Curmudgeon
Look in the .lg file. Current parameter value and configuration option settings are detailed in the first 50 or so lines after your most recent database start. Pretty much everything you see there is tunable.
"How" depends on how you are managing your database.
If you have a "managed" database and are using a so-called graphical "tool" such as one of the exploder variants you basically mostly guess at the relationship between the field labels on the screens and the parameter values. There doesn't seem to be any reliable relationship. Quite a few things do not have any representation at all on the screens and you end up setting them in "other args". Oh, and default values are sometimes helpfully indicated by the use of "0" or "blank".
Or you can fiddle with the properties files directly and use dbman to start/stop the db. (Many people are afraid to do this, I think that if you're stuck in an environment that dictates that you must have a "managed" database it works way better than exploder.)
The other major option is "scripted". In this case it depends on how your scripts were written (or will be written). You use "proserve" to start the db and you specify command line options. You can (and should) gather parameters together in a .pf file to make it much simpler and more manageable. (You can also specify a .pf file in "other args" for a "managed" database.)
As to "when"... when you need to. For instance you if you have 1,000 IO ops/sec and you need to get it down to 250 because you only have 2 spindles for your database then -B needs to be roughly 8x whatever its current value is. Key terms in the preceding sentence: "have", "need", "because" and "then" -- you cannot figure out what to do (the "then" part) without knowing why (the "because") and for that you need data about what is happening (the "have") and an idea about what should be happening (the "need").
"How" depends on how you are managing your database.
If you have a "managed" database and are using a so-called graphical "tool" such as one of the exploder variants you basically mostly guess at the relationship between the field labels on the screens and the parameter values. There doesn't seem to be any reliable relationship. Quite a few things do not have any representation at all on the screens and you end up setting them in "other args". Oh, and default values are sometimes helpfully indicated by the use of "0" or "blank".
Or you can fiddle with the properties files directly and use dbman to start/stop the db. (Many people are afraid to do this, I think that if you're stuck in an environment that dictates that you must have a "managed" database it works way better than exploder.)
The other major option is "scripted". In this case it depends on how your scripts were written (or will be written). You use "proserve" to start the db and you specify command line options. You can (and should) gather parameters together in a .pf file to make it much simpler and more manageable. (You can also specify a .pf file in "other args" for a "managed" database.)
As to "when"... when you need to. For instance you if you have 1,000 IO ops/sec and you need to get it down to 250 because you only have 2 spindles for your database then -B needs to be roughly 8x whatever its current value is. Key terms in the preceding sentence: "have", "need", "because" and "then" -- you cannot figure out what to do (the "then" part) without knowing why (the "because") and for that you need data about what is happening (the "have") and an idea about what should be happening (the "need").
RealHeavyDude
Well-Known Member
I just love that - it is the best statement in this sense if ever read!!!
Heavy Regards, RealHeavyDude.
RealHeavyDude
Well-Known Member
Nope. You don't define the size of the buffers - they always match the blocksize, instead you define the number of buffers which should be allocated.
But, you can define the database and BI blocksize. The bad news is, you can only define the blocksize of the database when you create it - therefore if you want to change it you need to dump your database, create a new one with the desired blocksize and load it. The good news is, you can change the blocksize of the BI every time you truncate it - the database just needs to be offline for that.
There is a rule of thumb for the blocksizes - the bigger the better. Particularly the blocksizes should be equal or bigger than the file system blocksizes. If they are smaller you will have a serious performance penalty. Therefore the best settings for the database blocksize is 8K and 16 for the BI respectively (both are the maximum values).
Heavy Regards, RealHeavyDude.
But, you can define the database and BI blocksize. The bad news is, you can only define the blocksize of the database when you create it - therefore if you want to change it you need to dump your database, create a new one with the desired blocksize and load it. The good news is, you can change the blocksize of the BI every time you truncate it - the database just needs to be offline for that.
There is a rule of thumb for the blocksizes - the bigger the better. Particularly the blocksizes should be equal or bigger than the file system blocksizes. If they are smaller you will have a serious performance penalty. Therefore the best settings for the database blocksize is 8K and 16 for the BI respectively (both are the maximum values).
Heavy Regards, RealHeavyDude.
TomBascom
Curmudgeon
So far as I know there are no plans for the OpenEdge db to support multiple db block sizes any time soon.
There has been some talk that a larger maximum block size might be forthcoming some day but I've not heard anything about multiple block sizes.
On the other hand... once they start seriously looking at the possibility of larger blocks they might decide that we need variety
And now that we have an alternate buffer pool I can imagine that the concept might be extended to multiple alternate buffer pools with different block sizes which would go a long ways to making it feasible. (But don't hold your breath...)
There has been some talk that a larger maximum block size might be forthcoming some day but I've not heard anything about multiple block sizes.
On the other hand... once they start seriously looking at the possibility of larger blocks they might decide that we need variety
And now that we have an alternate buffer pool I can imagine that the concept might be extended to multiple alternate buffer pools with different block sizes which would go a long ways to making it feasible. (But don't hold your breath...)