RE: query performance - getting started
- From: <Joel.Patterson@xxxxxxxxxxx>
- To: <harperjm@xxxxxxxxxxxxx>, <Finn.Jorgensen@xxxxxxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 8 Apr 2011 08:22:41 -0400
I now have one for, one says its about the same (Complete refresh verses CTAS).
We would not be dropping the table so it would be a bulk insert.
Right now I only have 4000 rows. I suspect it could climb as high as 40000,
but I suspect no larger. Still going to follow the 11g path as well and the
results cache suggestion and see what happens.
Joel Patterson
Database Administrator
904 727-2546
________________________________
From: John Harper [mailto:harperjm@xxxxxxxxxxxxx]
Sent: Thursday, April 07, 2011 4:02 PM
To: Finn.Jorgensen@xxxxxxxxxxxxxxxxx; Patterson, Joel; 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: query performance - getting started
There IS NO FASTER way than CTAS. If you want to really push a DB do several
CTAS at the same time... I was able to accomplish 2.9 million rows/second with
direct attached storage and 1.8 million rows/second over SAN (EMC Clarion).
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Jorgensen, Finn
Sent: Thursday, April 07, 2011 11:48 AM
To: 'Joel.Patterson@xxxxxxxxxxx'; 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: query performance - getting started
Last time I looked into MV refreshes (in 10gR2) they did not do truncates. They
do a delete of all rows. I assume this is so running queries aren't interrupted
by the refresh.
So, if you have the luxury of doing a truncate and then insert (append) or
better yet, drop table and CTAS, and the table is large, then that would be
faster.
Thanks,
Finn
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Joel.Patterson@xxxxxxxxxxx
Sent: Thursday, April 07, 2011 8:51 AM
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 e-mail and any attachments are confidential, may contain legal,
professional or other privileged information, and are intended solely for the
addressee. If you are not the intended recipient, do not use the information
in this e-mail in any way, delete this e-mail and notify the sender. CEG-IP2
NOTICE: This email message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies of
the original message.
Other related posts:
