G
George Potemkin
Guest
> setting max rows per block to 128 would be slightly better. or not, since rows are not all the same size Storing a table not in the same area as the LOB field would make at least it's possible to set the optimal RPB value. Table's records and LOB's fields are too different "animals" to be locked in one "cage". Having 64-bit dbkeys and the create limit that can be changed at any time I'd always set RPB for the /table/'s areas higher than the value based on mean record size. Maybe I just a coward and I don't say: set it always to 256 . ;-) CToman's case seems to be rather specific. Look at the names of CLOB fields in table zsazaudit: querydata, returndata, reqheader, rqst, rspons. I guess the table is a part of system that is used to monitor the execution of application itself. The values of these CLOB fields except the "querydata" are mostly empty and they are not using any slots in the "LOB" area. But they can be used in the future. And it might create the additional problems. I guess the table has the huge numbers of the creates/deletes: > RM CHAIN ANALYSIS > 182160 Table PUB.zsaztdl:624 With 64 records per block it means that at some point in time the table had more than ten million records. Dbanalys reported only 451,692 records. This explains why the "LOB" area is large while its current contents is rather small.
Continue reading...
Continue reading...