Analytics Software

Is the execution plan different between the CTAS and the select statement (other than the create table part)?

Adding parallelism is only going to make it difficult to compare, sometimes you’ll get the parallel slaves you want, sometimes you’ll get less and sometimes you’ll get none depending on the amount of other parallel work going on.

What is the session executing the CTAS waiting on? Check v$session_event to see where it’s spending most of its time.

Any chance youre referencing views/synonyms that point to remote tables?

Remember we don’t have your DDL.

Hi,

As Andrew suggested, start by checking what the session is waiting for. Since you're using SQL Developer check this from the "monitor sessions" screen.

When you say the query takes 10 min to complete, are you talking about retrieving all the rows? How many of them in total?

Using PARALLEL with a wrong execution plan only makes things worse because the wrong plan is multiplied to different sessions. Make sure the stats are up to date.

Andrew,

Thanks for quick response, and yes, the explain plain are differnt. I don't know why it does the INDEX RANGE SCAN when we do CTAS but it doesn't when we just select.

What wait event on all active sessions just CPU (resmgr:cpu quantum).

The SELECT statement only explain plan:

The complete CTAS explain plan:

Greg,

When you say the query takes 10 min to complete, are you talking about retrieving all the rows? How many of them in total?

Yes, either just run the select statement directly or retrieve all rows (by export that result to an excel file from SQL developer). It takes just ~10 minutes.

The excel sheet in return about 65K of rows. We have try the parallel cause the select statement get executing slowly (just 1 x vCPU on 4 x vCPU machine).

It just return in ~10 when we add the parallel hint. But however, once added to CTAS then it just take forever.

3339281 wrote:
Andrew,
Thanks for quick response, and yes, the explain plain are differnt. I don't know why it does the INDEX RANGE SCAN when we do CTAS but it doesn't when we just select.
What wait event on all active sessions just CPU (resmgr:cpu quantum).
The SELECT statement only explain plan:
cid:d02facd8-106c-4b26-80ab-1a048a26200a
The complete CTAS explain plan:
cid:0f0b7330-faa1-4901-8e16-edb49370caeb

I am not going to download files.

Please use sql*plus, grab the execution (not explain) plan from memory using dbms_xplan.display_cursor and copy and paste the plans using a fixed width font here.

resmgr:cpu quantum is NOT CPU, it's specifically a wait event to prevent you from using CPU. How is your resource manager configured? Is this wait event really the most significant - ie it's spent hours on it?  Show us the results from v$session_event (remember to use a fresh session each time as this shows the aggregate usage for the lifetime of a session). How does that compare to the simple select statement?

I've noticed you're querying 4 times the IMPORT_METADATA table and you're using 2 ORDER BY clauses within in-line views, which gives unecessary pain to the optimizer. And worse, you're not even selecting columns from the IMPORT_METADATA table in your final SELECT list! So remove the scalar queries on IMPORT_METADATA and the ORDER BY clauses and see if it improves your query performance.