RE: High cell single Block physical Read

From what you’ve written so far leading possibilities in my mind are:  

1. Multiple row pieces per block
2. Artifacts of updating advanced compressed rows with very little free space in the block (or in general)

Perhaps you can rule in or out #1 quickly by whether your table:

1. Has too many columns for a single row piece, especially if columns in different row pieces are being updated
2. Has a column type that makes the rows have multiple row pieces
3. Has a lot of migrated rows

Are you getting direct reads or cached reads?

Is your table partitioned (and if so, are the updates to many partitions or just 1 or a few partitions) ?  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Sanjay Mishra (Redacted sender "smishra_97" for DMARC) Sent: Wednesday, December 13, 2017 7:51 PM To: dmarc-noreply_at_freelists.org; Oracle-L Freelists Subject: Re: High cell single Block physical Read  

Sorry small correction on the trace. If object is 540334 then it is "cell multiblock Physical read" but obj#=0 is "cell single block physical read" There is One "cell multiblock Physical read" after several rows on "cell multiblock Physical read"  

name='cell single block physical read' ela=1511 celhas=12345555 diskhash=12345555 bytes=8192 obj#0 time=11111111

name='cell multiblock physical read' ela=1511 celhas=12345555 diskhash=12345555 bytes=8192 obj#540334 time=11111111  

These are the only one taking 95% of time for the query.  

Sanjay  

On Wednesday, December 13, 2017 7:44 PM, Sanjay Mishra <smishra_97_at_yahoo.com> wrote:  

I checked and found that in 10046 trace, there are around 1mil rows with obj#=0 and around 100K with obj#=540334 which is the object I am updating.  

Sanjay  

On Wednesday, December 13, 2017 7:33 PM, Sanjay Mishra <dmarc-noreply_at_freelists.org> wrote:  

Hi  

I am running an update on Advance row compress table by selecting data from another table on Unique Seq No. Runing Select from other table is very fast and even running Select instead of update columns is very fast BUT WHEN update comes, it is taking almost an hour to just update 5 mil Records. Does Compress for OLTP be factor for so many single block phsuicall Read as I am monitoring the trace and what it is doing is

name='cell single block physical read' ela=1511 celhas=12345555 diskhash=12345555 bytes=8192 obj#0 time=11111111

name='cell single block physical read' ela=1511 celhas=12345555 diskhash=12345555 bytes=8192 obj#540334 time=11111111  

So can see doing this against obj#0 and obj#540334  

Any help is appreciated.  

TIA Sanjay    

--
http://www.freelists.org/webpage/oracle-l