RE: OLTP compression slow update
- From: <Christopher.Taylor2@xxxxxxxxxxxx>
- To: <mdinh235@xxxxxxxxx>, <rjamya@xxxxxxxxx>
- Date: Thu, 27 Dec 2012 13:40:45 -0600
I know I'm late to the party so this might have been covered. Is this a single
session update statement or multiple sessions?
I was wondering about ITL waits if multiple sessions - but if it's a single
session then I figure ITL waits shouldn't be an issue unless the free space in
each block is really, really, low.
While you're testing, grab some AWR reports (change your collection interval
for 5-10 minutes from default 60 minutes) and check your wait events. (Yes, I
know I'm probably preaching to the choir here - but just in case...)
Chris
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Michael Dinh
Sent: Thursday, December 27, 2012 12:51 PM
To: rjamya@xxxxxxxxx
Cc: oracle-l
Subject: Re: OLTP compression slow update
Thanks all for the ressponse.
Still testing and will share results.
-Michael.
On Thu, Dec 27, 2012 at 4:52 AM, rjamya <rjamya@xxxxxxxxx> wrote:
> I saw this first in early 10g versions of plain vanilla compression
> (not fancy oltp etc). We were analyzing http/smtp logs collected
> company-wide, Initially we had daily partitions. since it started
> getting large quickly (we had open web at that time), I introduced
> partition compression, it worked like magic. When updates (due to
> occasional re-loads, corrections, ranking etc) to compressed
> partitions took long, we redesigned our strategy. Kept 7 days worth of
> parttions uncompressed, and everything older was compressed. That
> worked out well in the end. I guess the update issue on compressed
> data still needs work then :) Raj
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
