RE: OLTP compression slow update
Date: Thu, 27 Dec 2012 13:40:45 -0600
Message-ID: <F05D8DF1FB25F44085DB74CB916678E8856A0C5759_at_NADCWPMSGCMS10.hca.corpad.net>
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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Michael Dinh
Sent: Thursday, December 27, 2012 12:51 PM
To: rjamya_at_gmail.com
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_at_gmail.com> 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
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Thu Dec 27 2012 - 20:40:45 CET