I have stored procedure having two select statement combined with union all operator. Each select statement contains five left joins with views. The select performance is very slow. Each table contains 10 million records.
Is there any way (query or any other method) to find missing index details for the stored procedure?
Missing index details, if any, are included in the stored procedure execution plan. The actual or estimated plan can be viewed from SSMS (Query menu options) or retrieved from cache using the query below.
SELECT query_plan
FROM sys.dm_exec_procedure_stats AS ps
CROSS APPLY sys.dm_exec_query_plan(ps.plan_handle)
WHERE object_id = OBJECT_ID(N'YourDatabase.dbo.YourProcedure');
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.
I have approx 820,000 records in my SQL Server table and it is taking 5 seconds to select the data from the table. The table has one clustered index on a time column that could be NULL (as of now it does not contain any NULL value). Why is it taking 5 to 6 seconds to fetch only this much records?
What did you mean by 'select the data'? If you are fetching so many records in management studio (displaying all the records) most of this 6 seconds is consumed by showing you all the rows. If it is the case just insert the records to a temp table. It will be much faster.
I recomend you this:
1.Check if you are using Clustered and Non-Clustered in you columns (best way I think with a sp_help NameTable).
2.When you using comand "select" specific always all name columns (never use Select * From ..... ).
3.If you are using SSMS check in tools SQL Execution Plan , with this tool you can make simple review your TSQL (you can see cost
each query you make.
4.Dont use "convert(...." in clause WHERE , for example .. Where Convert(int,NameColum)=100.
I am running the following query in SQL Server which gives me a result in just 5 seconds with 80,000+ rows and 75+ columns:
SELECT * FROM VIEW_ITEM_STOCK_LEDGER AS ItemLedger
LEFT JOIN VIEW_PRODUCT_WITH_CHARACTERISTIC_COLUMN_DATA AS Characteristics
ON Characteristics.Code = ItemLedger.ItemCode
But when I add a WHERE clause to the query it takes too long time to execute the query. It takes more than 5 minutes for 13450 records.
SELECT * FROM VIEW_ITEM_STOCK_LEDGER AS ItemLedger
LEFT JOIN VIEW_PRODUCT_WITH_CHARACTERISTIC_COLUMN_DATA AS Characteristics
ON Characteristics.Code = ItemLedger.ItemCode
WHERE (ItemLedger.VoucherTypeCode=204 OR ItemLedger.VoucherTypeCode=205)
What could be the reason? How do I solve this?
It sounds to me like there is no index on the column VoucherTypeCode.
If VoucherTypeCode is a column of a table in your database, you can try indexing that column (see this article about creating indexes on MS Docs)
If VoucherTypeCode is a product of multiple columns, you can try indexing the view itself (see this Article about indexed views on sqlshack.com)
Alternatively, if you can't/don't want to create an index, check out the accepted answer in this StackOverflow-Thread
INSERT INTO #TEMP(ID,CID,STS,ETL_NBR,T_ID)
SELECT STG.ID,STG.CID,STG.STS,STG.ETL_NBR,STG.T_ID
FROM DBO.A_STAGE STG(NOLOCK)
INNER JOIN DBO.A_PRE PRE(NOLOCK)
ON PRE.ID=STG.ID AND PRE.CID=STG.CID
WHERE PRE.STS = 'D'
AND STG.ETL_NBR < PRE.ETL_NBR
Above query is constructed from Dynamic SQL inside a stored procedure. Tables involved in joins are actually being read through variables.This query hangs for small volume of data as well.
1) If I perform SELECT based on above conditions, The query still results 0 records. For insert it hangs for hours.
2) There are no blockers on this query.
Note: Since this is dynamic query when other tables are passed to variables this query runs smooth. It has issue with specific table only. I did update stats and rebuild index on that table. No use.
This can be the classic Parameter Sniffing, you can read more here: what-is-parameter-sniffing
There's a way to improve performance with such a queries, using the OPTION (RECOMPILE) in your query
You need to incluide at the end of query
You can also use the UNKNOWN for the each variable, like this:
OPTION (OPTIMIZE FOR (#variable 1UNKNOWN, #variable2 UNKNOWN, ....))
You can read more here: improving-query-performance-with-option-recompile-constant-folding-and-avoiding-parameter-sniffing-issues/
PRE.CID=STG.CID
This particular join has NULL and Spaces. It is not Unique or PK column. Hence the slowness. I have excluded them in Join by adding PRE.CID IS NOT NULL .
The query now runs fast.
I am running a query which is selecting data on the basis of joins between 6-7 tables. When I execute the query it is taking 3-4 seconds to complete. But when I put a where clause on the fetched data it's taking more than one minute to execute. My query is fetching large amounts of data so I can't write it here but the situation I faced is explained below:
Select Category,x,y,z
from
(
---Sample Query
) as a
it's only taking 3-4 seconds to execute. But
Select Category,x,y,z
from
(
---Sample Query
) as a
where category Like 'Spart%'
is taking more than 2-3 minutes to execute.
Why is it taking more time to execute when I use the where clause?
It's impossible to say exactly what the issue is without seeing the full query. It is likely that the optimiser is pushing the WHERE into the "Sample query" in a way that is not performant. Possibly could be resolved by updating statistics on the table, but an easier option would be to insert the whole query into a temporary table, and filter from there.
Select Category,x,y,z
INTO #temp
from
(
---Sample Query
) as a
SELECT * FROM #temp WHERE category Like 'Spart%'
This will force the optimiser to tackle it in the logical order of pulling your data together before applying the WHERE to the end result. You might like to consider indexing the temp table's category field also.
If you're using MS SQL by checking the management studio actual execution plan it may already suggest an index creation
In any case, you should add to the index used by the query the column "Category"
If you don't have an index on that table create it composed by column "Category" and all the other columns used in join or where
bear in mind by using like 'text%' clause you could end in index scan and not index seek