2007년 12월 18일에 IIUG에 올라온 글을 발췌해 봤습니다.

IDS11에만 해당하는 기능으로 일반적으로 column을 만들고 row를 insert할때 db를 만들때 정의된 page size로 인하여 disk 공간이 낭비되는 경우가 있습니다.

이때 IDS 11의 onconfig parameter에 "MAX_FILL_DATA_PAGES 1" 을 해주면 디스크 공간이 절약되는 효과를 볼 수 있습니다.

내부적으로 동작하는 원리는

table을 column lvarchar(6000) 에 pagesize를 4K로 만들었습니다. 이때 어떤 6K 짜리 row가 연속해서 들어오면 4K page 하나, 4K page하나 이렇게 둘을 연속해서 사용하게 됩니다. 문제는 두번째 4K는 2K만 들어가고 다음의 6K row가 들어왔을때 나머지 2K를 사용하는것이 아닌 새로운 4K page를 사용한다는 것입니다. 이런식으로 계속되다 보면 낭비되는 2K가 많이 생기게 됩니다.

그러나 위의 option을 주면 page의 10%만 남겨두고(4K page의 10%라면 400 byte) 나머지 남은 1600 Byte를 다음 들어온 row를 위해 사용한다는 것입니다.

위의 parameter는 IDS 11.x 에서 사용할 수 있으며 parameter 적용 시 IDS를 restart 해야 합니다.

다음은 IIUS에서 발췌한 원문입니다.
========================================================
Enhanced variable length row compression

In IDS, when a new row containing a column that can vary in length is to be inserted on a page, the row will be inserted only if the page contains sufficient space to allow the new row to grow to its maximum length. This can result in low disk space usage. In IDS 11, you can change this default behavior by setting the configuration parameter MAX_FILL_DATA_PAGES to 1. When MAX_FILL_DATA_PAGES is enabled, the server will add a new row to a page if after adding the row, at least 10 percent of the page is free for the future expansion of the rows. The database server needs to be restarted after changing this configuration parameter.

To take advantage of this setting:

• Existing tables with variable-length rows must be reloaded
  OR
  
• Existing pages must be modified, followed by further inserts
  

Advantages of enabling MAX_FILL_DATA_PAGES are:

• More data can be stored in less disk space
• Enables the server to use the buffer pool more efficiently
• Reduces fetch times as more rows can be accessed by reading less number of pages
  

The possible disadvantages of enabling MAX_FILL_DATA_PAGES are:

• Allowing more variable-length rows per page might store rows in a different physical order
  
• As the page fills, updates made to the variable-length columns in a row could cause the row to expand so it no longer completely fits on the page. This causes the server to split the row onto two pages, increasing the access time for the row
  

Example: Suppose you have a table with a column of type lvarchar(6000). If the dbspace in which the table resides is of 4K or 8k pagesize, you might see a lot of unused space in the pages. If you do not have to make updates which would cause most of the rows to expand to their full length, you might want to enable MAX_FILL_DATA_PAGES to better use the space in each page.

Suma Vinod