I run the following query on an Oracle database:
EXPLAIN PLAN FOR
SELECT *
FROM table_name
However, it's not returning any data. When I delete the EXPLAIN PLAN FOR clause, the query does run as expected. Thanks for the help!
In case it's relevant, I'm accessing the database through Teradata and also a Jupyter IPython notebook.
From Using EXPLAIN PLAN:
The PLAN_TABLE is automatically created as a global temporary table to hold the output of an EXPLAIN PLAN statement for all users. PLAN_TABLE is the default sample output table into which the EXPLAIN PLAN statement inserts rows describing execution plans
EXPLAIN PLAN FOR SELECT last_name FROM employees;
This explains the plan into the PLAN_TABLE table. You can then select the execution plan from PLAN_TABLE.
Displaying PLAN_TABLE Output
UTLXPLS.SQL
UTLXPLP.SQL
DBMS_XPLAN.DISPLAY table function
I suggest to use:
EXPLAIN PLAN FOR SELECT * FROM table_name;
SELECT * FROM TABLE(dbms_xplan.display);
Related
Why Oracle "DDL" statements (like "CTAS"), after executed, does not shown in V$SQL view ?
How can get "SQL_ID" of that? I want to use "SQL_ID" in SQl plan baselines. TNX
V$SQL shows just the first 20 charachter for CTAS. It is a bug in Oracle Database 11g. For more details, see: (https://stackoverflow.com/questions/27623646/oracle-sql-text-truncated-to-20-characters-for-create-alter-grant-statements/28087571#28087571\)1.
CTAS operations appear in the v$sql view
SQL> create table t1 as select * from dba_objects ;
Table created.
SQL> select sql_text,sql_id from v$sql where sql_text like '%create table t1 as select%' ;
SQL_TEXT
--------------------------------------------------------------------------------
SQL_ID
-------------
create table t1 as select * from dba_objects
4j5kv6x7cz5r7
select sql_text,sql_id from v$sql where sql_text like '%create table t1 as selec
t%'
5n4xnjkt3vz3h
SQL Plan Baselines are part of SPM ( SQL Plan Management )
A SQL plan baseline. A plan baseline is a set of accepted plans that
the optimizer is allowed to use for a SQL statement. In the typical
use case, the database accepts a plan into the plan baseline only
after verifying that the plan performs well. In this context, a plan
includes all plan-related information (for example, SQL plan
identifier, set of hints, bind values, and optimizer environment) that
the optimizer needs to reproduce an execution plan.
If you are using a CTAS recurrently, I guess you are doing it in batch mode, thus dropping the table and then recreate it afterwards using the mentioned CTAS command. I would rather try to see what is the problem with the SELECT itself of that statement.
But SQL Baselines are more focus for solving queries which plans can be fixed and evolved as the optimizer is not always choosing the best one.
Could you help me with a Hive Query Efficiency problem? I have two queries working for the same problem. I just cannot figure out why one is much faster than the other. If you know please feel free to provide insight. Any info is welcomed!
Problem: I am trying to check the minimum value of a bunch of variables in a Hive parquet table.
Queries: I tried two two queries as follows:
query 1
drop table if exists tb_1 purge;
create table if not exists tb_1 as
select 'v1' as name, min(v1) as min_value from src_tb union all
select 'v2' as name, min(v2) as min_value from src_tb union all
select 'v3' as name, min(v3) as min_value from src_tb union all
...
select 'v200' as name, min(v200) as min_value from src_tb
;
query 2
drop table if exists tb_2 purge;
create table if not exists tb_2 as
select min(v1) as min_v1
, min(v2) as min_v2
, min(v3) as min_v3
...
, min(v200) as min_v200
from src_tb
;
Result: Query 2 is much faster than query 1. It took probably 5 mins to finish the second query. I don't know how long will query 1 take. But after I submit the first query, it took a long time to even react to the query, by which I mean that usually after I submit a query, the system will start to analyze and provides some compiling information in the terminal. However, for my first query, after my submission, the system won't even react to this. So I just killed it.
What do you think? Thank you in advance.
Query execution time depends on environment that you execute it.
In MSSQL.
Some people like you think query execution is similar to algorithm that they see in some theoretical resources, but in practical situation, it depends on other things.
For example both of your queries have SELECT statement that perform on a table and at first glance, they need to read all rows, but database server must analyze the statement to determine the most efficient way to extract the requested data. This is referred to as optimizing the SELECT statement. The component that does this is called the Query Optimizer. The input to the Query Optimizer consists of the query, the database schema (table and index definitions), and the database statistics. The output of the Query Optimizer is a query execution plan, sometimes referred to as a query plan or just a plan. (Please see this for more information about query-processing architecture)
You can see execution plan in MSSQL by reading this article and I think you will understand better by seeing execution plan for both of your queries.
Edit (Hive)
Hive provides an EXPLAIN command that shows the execution plan for a query. The syntax for this statement is as follows:
EXPLAIN [EXTENDED|DEPENDENCY|AUTHORIZATION] query
A Hive query gets converted into a sequence of stages. The description of the stages itself shows a sequence of operators with the metadata associated with the operators.
Please see LanguageManual Explain for more information.
What is surprising? The first query has to read src_tb a total of 200 times. The second reads the data once and performs 200 aggregations. It is a no brainer that it is faster.
I am having a simple query with all joined columns indexed but still i receive a full table scan
Following is the query
select rsb.REP_STATUS_BRIDGE_ID
from REP_STATUS_BRIDGE_DETAILS rsd,
rep_status_bridge rsb
where rsd.REP_STATUS_BRIDGE_ID = rsb.REP_STATUS_BRIDGE_ID;
the columns REP_STATUS_BRIDGE_ID is indexed in both the tables, following is the explain plan
Explain plan at the following link
Please assist me in resolving this issue
As many Folks have asked this is the query that is taking forever to load
select count(rsb.REP_STATUS_BRIDGE_ID) from
pcfc_dba.rep_pass rp,
pcfc_dba.rep_status_bridge rsb,
pcfc_dba.REP_STATUS_BRIDGE_DETAILS rsd,
pcfc_dba.rep_status_ref rsf
where trunc(rp.APPR_ACTION_END_DATE)>=to_date('01/02/2017','dd/MM/yyyy')
and trunc(rp.APPR_ACTION_END_DATE)<=to_date('06/02/2107','dd/MM/yyyy')
and rp.REP_STATUS_BRIDGE_ID = rsb.REP_STATUS_BRIDGE_ID
and rsb.REP_STATUS_BRIDGE_ID=rsd.REP_STATUS_BRIDGE_ID
and rsf.REP_STATUS_REF_ID=rsd.REP_STATUS_REF_ID;
The explain plan
I think the main problem is a stale statistic as was said above.
The table REP_STATUS_BRIDGE_DETAILS has 1.3 mil records as you said before. But in plan we see full table scan expect to get only 310 rows( I suppose it's rows, but I don't see a header). Could you please gather statistics ec.:
begin
DBMS_STATS.GATHER_TABLE_STATS (
ownname => USER,
tabname => 'REP_STATUS_BRIDGE_DETAILS',
cascade => true);
end;
/
and then check num_rows from all_tables view
select t.owner, t.table_name, t.num_rows
from all_tables t
where t.table_name in ('REP_STATUS_BRIDGE_DETAILS');
It's take in account statistic's data. After statics will be gathered you should get a different plans for both queries.
I have a query that has a good execution plan...
When I take this query and run it over a database link I lose the index in the execution plan...
Is there any way to get this query to keep the index?
regards
Your query has to be this way only,
SELECT /*+ DRIVING_SITE(thead) */ *
FROM thead#ORPMYRP.CMLTD.NET.AU
WHERE business_part_date=trunk(sysdate)
and processed_ind='N';
OR use a Global hint like below, when subquery is in place.
SELECT /*+ DRIVING_SITE(a.thead) */ *
FROM
(SELECT * FROM thead#ORPMYRP.CMLTD.NET.AU
WHERE business_part_date=trunk(sysdate)
and processed_ind='N') a
When you use like below,
SELECT /*+ DRIVING_SITE(a) */ *
FROM
(SELECT * FROM thead#ORPMYRP.CMLTD.NET.AU
WHERE business_part_date=trunk(sysdate)
and processed_ind='N') a
The hint gets useless as the alias name a is no more meaningful to be useful in HINT as it doesnt refer a table but a subquery's result. And entire rows of AU table in remote db is sent to the local now. So it means, index is of no use now, so oracle goes for full table scan.
I have a table with 226 million rows that has a varchar2(2000) column. The first 10 characters are indexed using a functional index SUBSTR("txtField",1,10).
I am running a query such as this:
select count(1)
from myTable
where SUBSTR("txtField",1,10) = 'ABCDEFGHIJ';
The value does not exist in the database so the return in "0".
The explain plan shows that the operation performed is "INDEX (RANGE SCAN)" which I would assume and the cost is 4. When I run this query it takes on average 114 seconds.
If I change the query and force it to not use the index:
select count(1)
from myTable
where SUBSTR("txtField",1,9) = 'ABCDEFGHI';
The explain plan shows the operation will be a "TABLE ACCESS (FULL)" which makes sense. The cost is 629,000. When I run this query it takes on average 103 seconds.
I am trying to understand how scanning an index can take longer than reading every record in the table and performing the substr function on a field.
Followup:
There are 230M+ rows in the table and the query returns 17 rows; I selected a new value that is in the database. Initially I was executing with a value that was not in the database and returned zero rows. It seems to make no difference.
Querying for information on the index yields:
CLUSTERING_FACTOR=201808147
LEAF_BLOCKS=1131660
I am running the query with AUTOTRACE ON and the gather_plan_statistics and will add those results when they are available.
Thanks for all the suggestions.
There's a lot of possibilities.
You need to look at the actual execution plan, though.
You can run the query with the /*+ gather_plan_statistics */ hint, and then execute:
select * from table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST'));
You should also look into running a trace/tkprof to see what is actually happening - your DBA should be able to assist you with this.