On Apr 27, 5:39 am, Robert Klemme <shortcut..._at_googlemail.com> wrote:
> On 27.04.2007 07:31, Mladen Gogala wrote:
>
> > 3) When you have very write-intensive application and relatively slow
> > peripherals. I frequently see compressed tables used on Linux boxes
> > which have notoriously low I/O capacity. I work for a company that
> > is loading tons of data (~ 3,000,000 records a day) into several
> > tables for later processing. I tuned I/O well (6 4GB redo logs,
> > 8MB log buffer, 2 DB writer processes, asynchronous I/O, 20 freelists,
> > 25% of free space, 32 inittrans, reverse index for primary key and
> > the analog boxes feeding the database were still too fast. I also
> > went after the Linux kernel and fixed network parameters, Ext3
> > mount options and the Ethernet drivers. My compressing few critical
> > tables made a difference and caused the boxes to report backlog once
> > a week instead of once a day. It has cut down the number of I/O
> > requests for approximately 12% which was enough. Once we overgrow
> > that, the only thing to do will be to buy a box with more I/O
> > bandwidth.
>
> I guess with "write intesive" you mean "will be frequently truncated and
> bulk loaded / recreated". Tom Kyte writes in "Effective Oracle by
> Design" that modified blocks are not compressed. So in an OLTP
> application you likey won't benefit from table compression.
>
> Kind regards
>
> robert
Yes, compression happens only for the new blocks. The table is being
re-partitioned every day and the old partitions are dropped. This is
definitely
not an OLTP table.
Received on Fri Apr 27 2007 - 07:38:24 CDT
