Re: External table performance

  • From: "Sanjay Mishra" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "smishra_97" for DMARC)
  • To: "Mark W. Farnham" <mwf@xxxxxxxx>, Tanel Poder <tanel@xxxxxxxxxxxxxx>
  • Date: Mon, 15 Jan 2018 06:00:05 +0000 (UTC)

 Thanks All and indeed got lot of good points and references from Mark, Kim, 
Niall, Mladen and Kellyn and ofcourse also has to check Tanel slides.I created 
the MV which gives back lots of good time to the queries and creating one main 
index met the business SLA requirements. I still will have to check all 
suggestion for future reference.

In addition, as this environment is moving to Exadata and so not sure if the 
Exadata will be high performance or high capacity but due to high usage of the 
External table data, I will also test INMEMORY or FLASH CACHE to see if this 
can provide some more help.
Thanks Again to all for your experience and suggestions
Sanjay
    On Sunday, January 14, 2018, 2:15:04 PM EST, Tanel Poder 
<tanel@xxxxxxxxxxxxxx> wrote:  
 
 Thanks Mark for mentioning my presentation. It was actually the first one in 
my "troubleshooting the most complex performance issues I've ever seen" series 
and the slides are still available here:
https://www.slideshare.net/tanelp/tanel-poder-troubleshooting-complex-oracle-performance-issues-part-1

I think I have done 4 such presentations over time (most should be available in 
Slideshare). Maybe it's time to re-deliver these online - they're lots of fun! 
;-)
Thanks,Tanel Poderhttps://blog.tanelpoder.com
On Sun, Jan 14, 2018 at 7:23 AM, Mark W. Farnham <mwf@xxxxxxxx> wrote:


Roger that. This was a problem that database file systems will eventually solve 
with an implicit index on file name.

 

... 



 


Tanel wrote  up a classic performance track down at Hotsos several years ago 
where no waits were traceable to the Oracle engine and he had to get all the 
way down to “find the file” in subroutines before the problem became apparent.




  

Other related posts: