R
Richard Banville
Guest
It is the exact number since –omsize is the number of entries in the primary and secondary om caches, not the amount of memory allocated. When adding new objects online, the mapping information will be stored in the secondary om cache – regardless if there is space in the primary cache or not. Access to the secondary cache is always latched regardless of the –omsize. Setting the –omsize larger than the result of select count(*) from _storageobject will allow newly added objects (tables, indexes, lobs) to be stored in the primary (non-latched) part of the om cache the NEXT time the database is brought up. Based on how often you add new object you might want to set the –omsize a bit larger than the current count. Other than that, there is no need to set it larger. Cache paging in the secondary will only occur when both the primary and secondary caches are filled up. If –omsize is set as described, that should not happen unless you have just added many new unaccounted for object to the database (say after a load .df). _________________________________ Richard Banville Fellow, OpenEdge Development PROGRESS SOFTWARE CORPORATION 14 Oak Park | Bedford, MA 01730 | USA DIRECT +1 781 280 4875 richb@progress.com From: S33 [mailto:bounce-S33@community.progress.com] Sent: Friday, October 17, 2014 2:10 PM To: TU.OE.RDBMS@community.progress.com Subject: RE: [Technical Users - OE RDBMS] 11.3.2: default -omsize & high number of MTL_OM latches RE: 11.3.2: default -omsize & high number of MTL_OM latches Reply by S33 gus -- So is that resulting number of objects (from "select count...") what you set the -omsize to, or do you have ti multiply by some mem size constant like 1024k to get the actual parameter you need? Stop receiving emails on this subject. Flag this post as spam/abuse.
Continue reading...
Continue reading...