Re: Improve Query sqlm_9csc97utkgjub

From: Jonathan Lewis <jlewisoracle_at_gmail.com>
Date: Mon, 28 Oct 2024 14:58:33 +0000
Message-ID: <CAGtsp8nuTCsUpOG19Sgi2F6Y1iY0E4Sf-P5A0BVLg45TfiU7AA_at_mail.gmail.com>



I've found a definition of the table that has 363 columns with last_update_date at column 158. This means that if any column past column 255 holds a value then the last_update_date column will be in the second rowpiece of the table (although all sorts of nasty breakdowns can happen, the simplest case for tables with more than 255 columns (but less than 510) is for the last row piece to hold the last 255 columns and the 1st row piece to hold the first 510 - "column count".

363 - 255 = 108, so you can expect all columns past the first 108 to be in the second row piece; and may find cases where updates to a row result in the second row piece moving to a new block ... hence the threat of single block reads on a tablescan of last_update_date

Regards
Jonathan Lewis

On Fri, 25 Oct 2024 at 15:21, Amit Saroha <eramitsaroha_at_gmail.com> wrote:

> Thank you for your detailed email and feedback. I will carefully read both
> the blog entries but one thing I have checked is that the last update date
> is not in the middle of the table, the table has 360 plus columns and the
> rows are not chained.
>
> Best Regards,
> AMIT
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Oct 28 2024 - 15:58:33 CET

Original text of this message