vasilis АнатоЛой Журавлев ДенисПока экстентов меньше сотен это не должно быть проблемой
Эээ
Вроде нижняя граница по формуле была 50-52. Нужно доку смотреть...
Это была рекомендация, т.е. то же, что и Денис говорит, но количеством в 50.
Для многих пользователей (админов) даже 200 "не является проблемой", т.к. они о ней не знают и спят спокойно :)
И когда, в конце концов, получают 136-ю ошибку, то жутко удивляются.


Главная проблема не 136 ошибка, а понижение производительности, чем меньше экстентов - тем лучше (идеальный вариант - 1)

* If a table has more than one extent, there is no guarantee that those extents are contiguous; extents may be scattered throughout the dbspace where the table resides. Contiguity of physical disk pages is important to performance. When pages of data are contiguous, the time used to access data on disk is minimized and the database can read rows sequentially. If tables have too many extents, it is very likely that those extents are interleaved. This harms performance a great deal, because when you retrieve data for a certain table, the disk head needs to seek multiple, noncontiguous extents belonging to this table instead of one large extent with contiguous physical pages. This slows down disk-seeking speed rather significantly.
* Another reason is to avoid an automatic allocation of extents for tables, which is a very expensive operation and will use a lot of system resources, such as CPU and memory.

To implement the Informix documentation recommendations, you need to specify extent size when you create tables so that the Informix server won't use the default extent size, which is 16 KB. The EXTENT SIZE and NEXT SIZE clause in the CREATE TABLE statement allows you to specify the first and second extent size that the Informix server will allocate for every table created.

http://www.ibm.com/developerworks/db2/library/techarticle/dm-0501fan/