Re: Chained Rows
Date: Thu, 24 Apr 2014 05:34:19 -0400
Message-ID: <CAEidWqMOW9v0s6mfEjhah5wTf+c=F9PiXifLACE_=0LvoT5reg_at_mail.gmail.com>
Yes. We are at 8k and I suspect a 16k block size would reduce the rate by 1/2. We have talked about doing this for some time. Unfortunately the most widely affected areas of the database is 20T of data out of 160T of databases. Also efficiently managing multiple buffer pools becomes difficult.
What I find challenging is that I don't see a way to avoid it all together. If you have a table with more than 255 columns and you use any of the columns beyond 255 this is going to happen at some difficult to predict rate.
Ideally I would want Oracle to put all row pieces in a single block if they would fit. If not then consider them chained and break it up. It seems to treat each row piece independently from the start. On Apr 24, 2014 1:42 AM, "Hans Forbrich" <fuzzy.graybeard_at_gmail.com> wrote:
> Is this possibly a valid use case for larger tablespace block size?
>
> On 23/04/2014 4:29 PM, Kenny Payton wrote:
>
> Thanks.
>
> Unfortunately the data and access patterns change pretty frequently. Â
> Another reason we find ourselves in this situation.
> On Apr 23, 2014 6:02 PM, "Sayan Malakshinov" <xt.and.r_at_gmail.com> wrote:
>
>>
>> On Thu, Apr 24, 2014 at 12:56 AM, Kenny Payton <k3nnyp_at_gmail.com> wrote:
>>>
>>> I know a lot of the tricks for avoiding chained rows and migrated rows
>>> but the only trick I know of to element these intra or inter block chained
>>> rows is to break the table into multiple tables or the row into multiple
>>> rows.Â
>>
>>
>> Sometimes might be helpful to redefine table with moving less-used
>> columns to the ends of rows. It allows to reduce extra-work if most queries
>> use only the first columns
>>
>>
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Apr 24 2014 - 11:34:19 CEST