RE: query performance - getting started

  • From: <Joel.Patterson@xxxxxxxxxxx>
  • To: <Hemant.Chitale@xxxxxx>
  • Date: Fri, 8 Apr 2011 08:19:58 -0400

Very good, I remember that now from the good 'ol days.  Thx for the doc Ids.


Joel Patterson
Database Administrator
904 727-2546

________________________________
From: Chitale, Hemant Krishnarao [mailto:Hemant.Chitale@xxxxxx]
Sent: Friday, April 08, 2011 2:06 AM
To: Patterson, Joel
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: query performance - getting started


You can check to see if the MV refresh really does a TRUNCATE.  If you can 
query and see data while the Refresh is running, then a DELETE-INSERT is being 
done.
To revert to the 9i behaviour of TRUNCATE-INSERT ,  set ATOMIC_REFRESH to FALSE 
in your DBMS_MVIEW.REFRESH call.
(See OracleSupport article Complete Refresh Read Consistency Behavior During 
Refresh and Complete Refresh Performance as Influenced by the ATOMIC_REFRESH 
Refresh Parameter [ID 553464.1]
)

You can also define the MV to use Parallel Query in the COMPLETE Refresh's.

(See OracleSupport article How to Refresh a Materialized View in Parallel [ID 
577870.1] )

Hemant K Chitale



________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Joel.Patterson@xxxxxxxxxxx
Sent: Thursday, April 07, 2011 8:51 PM
To: Joel.Patterson@xxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Cc: kylelf@xxxxxxxxx
Subject: RE: query performance - getting started


Query performance continued.

We have a very complicated Materialized view, and a view that utilizes the MV.  
 We cannot use Fast refresh - a complete refresh is necessary.   The app can 
decide when the view is refreshed, and can execute dbms_refresh when necessary.

Essentially all records are truncated, and the view is rebuilt as part of the 
complete refresh.    So, is this just as easy, efficient as any other method 
such as Temp tables, Truncating a permanent table and re-inserting, or other?


Moving forward,

JP


This email and any attachments are confidential and may also be privileged.  If 
you are not the addressee, do not disclose, copy, circulate or in any other way 
use or rely on the information contained in this email or any attachments.  If 
received in error, notify the sender immediately and delete this email and any 
attachments from your system.  Emails cannot be guaranteed to be secure or 
error free as the message and any attachments could be intercepted, corrupted, 
lost, delayed, incomplete or amended.  Standard Chartered PLC and its 
subsidiaries do not accept liability for damage caused by this email or any 
attachments and may monitor email traffic.



Standard Chartered PLC is incorporated in England with limited liability under 
company number 966425 and has its registered office at 1 Aldermanbury Square, 
London, EC2V 7SB.



Standard Chartered Bank ("SCB") is incorporated in England with limited 
liability by Royal Charter 1853, under reference ZC18.  The Principal Office of 
SCB is situated in England at 1 Aldermanbury Square, London EC2V 7SB. In the 
United Kingdom, SCB is authorised and regulated by the Financial Services 
Authority under FSA register number 114276.



If you are receiving this email from SCB outside the UK, please click 
http://www.standardchartered.com/global/email_disclaimer.html to refer to the 
information on other jurisdictions.

Other related posts: