RE: High cell single Block physical Read
Date: Fri, 15 Dec 2017 06:18:13 -0500
Message-ID: <095501d37596$65f8e170$31eaa450$_at_rsiz.com>
doh. typo – Multiple row pieces per row.
From what you’ve written so far leading possibilities in my mind are:
Perhaps you can rule in or out #1 quickly by whether your table:
- Has too many columns for a single row piece, especially if columns in different row pieces are being updated
- Has a column type that makes the rows have multiple row pieces
- 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
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-lReceived on Fri Dec 15 2017 - 12:18:13 CET