Re: LoadRowForGBY, PTInsertURowForGBY
- From: Riyaj Shamsudeen <riyaj.shamsudeen@xxxxxxxxx>
- To: przemolicc@xxxxxxxxx
- Date: Wed, 1 Aug 2012 16:38:56 -0500
Hi
First set of stack trace indicates hash group by execution step
(qeshPTInsertURowForGBY).
Second and third stack trace below indicates hash join (kxhf*).
I think, fourth one is also related to hash join, but building hash
table, not sure though.
I think, your DBA should review AWR report or statspack report to
understand performance issues. Yes, it is possible for the database issues
to show up as high syscall in the server. We need more details to
understand the issue.
Cheers
Riyaj Shamsudeen
Principal DBA,
Ora!nternals - http://www.orainternals.com - Specialists in Performance,
RAC and EBS
Blog: http://orainternals.wordpress.com
OakTable member http://www.oaktable.com and Oracle ACE Director
Co-author of the books: Expert Oracle
Practices<http://tinyurl.com/book-expert-oracle-practices/>,
Pro Oracle SQL, Expert PL/SQL
Practices<http://tinyurl.com/book-expert-plsql-practices>
Join me for next RAC training in Fall
2012<http://www.orainternals.com/services/training/advanced-rac-training/>:
<http://tinyurl.com/book-expert-plsql-practices>
On Wed, Aug 1, 2012 at 5:55 AM, <przemolicc@xxxxxxxxx> wrote:
> Hi all,
>
> we have been facing some performance problems on Solaris 10 server running
> Oracle 10.2.0.5.
> There is high syscall time during the problems involving system page
> faults.
> During these page faults I was able to catch stack of Oracle processes:
>
> oracle`qeshsFindFreeSlot+0xe0
> oracle`qeshfFindFreeSlot+0xc
> oracle`qeshBufferAlloc+0x110
> oracle`qeshPTInsertURowForGBY+0x1b4
> oracle`qeshLoadRowForGBY+0x360
>
> or
>
> oracle`klmalf+0x48
> oracle`kllcqas+0xc0
> oracle`kcblasm1+0x34
> oracle`kxhfFndFreeSlot+0xe4
> oracle`kxhfNewBuffer+0x2c
> oracle`qerhjGetNewBuffer+0x24
> oracle`ksxb1bqb+0xd0
> oracle`kxhrPack+0x450
> oracle`qerhjSplitBuild+0x11c
> oracle`qerixFetchUniqueIndex+0x36c
> oracle`qerjotFetch+0xbc
> oracle`rwsfcd+0x78
> oracle`qerhjFetch+0x3f0
> oracle`rwsfcd+0x78
> oracle`qerhjFetch+0x3f0
> oracle`rwsfcd+0x78
> oracle`qerhjFetch+0x3f0
> oracle`rwsfcd+0x78
> oracle`qerhjFetch+0x3f0
>
> or
>
> oracle`klmalf+0x48
> oracle`kllcqas+0xc0
> oracle`kcblasm1+0x34
> oracle`kxhfFndFreeSlot+0xe4
> oracle`kxhfNewBuffer+0x2c
> oracle`qerhjGetNewBuffer+0x24
> oracle`ksxb1bqb+0xd0
> oracle`kxhrPack+0x450
> oracle`qerhjSplitBuild+0x11c
> oracle`qerhjWalkHashBucket+0x13c
> oracle`kdstf0000101km+0x190
> oracle`kdsttgr+0x8f44
> oracle`qertbFetch+0x2c4
> oracle`rwsfcd+0x78
> oracle`qerhjFetch+0x1b0
> oracle`rwsfcd+0x78
> oracle`qerhjFetch+0x3f0
> oracle`rwsfcd+0x78
> oracle`qerhjFetch+0x3f0
>
> or
>
> oracle`qerhjadf+0x44
> oracle`qerhjBuildHashTable+0x54c
> oracle`qerhjInnerProbeHashTable+0x274
> oracle`qergsFetch+0x370
> oracle`qervwFetch+0x98
> oracle`rwsfcd+0x78
> oracle`qerhjFetch+0x1b0
> oracle`qerjotFetch+0x104
> oracle`qerghFetch+0x500
> oracle`rwsfcd+0x78
> oracle`insfch+0x84
> oracle`insdrv+0x240
> oracle`inscovexe+0x32c
> oracle`insExecStmtExecIniEngine+0x50
> oracle`insexe+0x218
> oracle`opiexe+0x2dc4
> oracle`opipls+0x844
> oracle`opiodr+0x600
> oracle`rpidrus+0xc4
> oracle`skgmstack+0xa8
>
>
> Can abybody shed a light what it might be on Oracle ? Where should our DBA
> look for ?
>
> Regards
> Przemyslaw Bak (przemol)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
