Page compress will lock the whole page forcedly and escalate lock to page if lock granularity less than page lock, but higher lock granularity have higher opportunity cause deadlock occur on higher concurrency .So we should try to reduce page compress operation internally though some useful ways.

Database compress page will be occur more easily on these two conditions.One is table include VARCHAR data type ,the other is table can include any other data type but without initial size and use DEFAULT NULL .

For VARCHAR,it’s varchar special behavior, varchar type fit real data size not allocate space fix always. So update data in varchar type cause original size is not enough for updated data easily, need to find other continuous space. When free space is enough in page but not continuous; DBMaker Server will compress the page for collect fragments space automatically. Database compress page lock whole page forcedly, it's DBMaker try to use free page in the page,at this moment, the real lock causing from compress operation.

For other data type which supported by DBMaker,its initial value was defined “DEFAULT NULL” at original,so not storage space preset in table initializtion.when putting new row data into it,DBMaker should check continuous free space in page.The situation like above behaviors.

In order to reduce Page compress we can reference the following Suggestions:

1. Replace varchar to char data type and give data initial value like other data type use NOT NULL.
2. Adjust Fillfactor value to an appropriate value.
3. Both 1 and 2 only reduce the opportunity for page compress but not avoid thoroughly.If method 1and 2 not enough needs we will provide other way depends on customers’s request to solve this problem.

Version: DBMaker4.x, DBMaker5.x

Product: Normal / Bundle

Platform: All