I am trying to look for the query plan for alter table query in sql server management studio for sql server 2008.
the alter query is something like:
alter table myTable add my_timestamp datetime not null default(getdate())
When I try to see the 'estimated execution plan' for this query, it shows result as :
Estimated Operator cost 0%. Also when I try to look for the 'actual execution plan' for the query, no result is shown. How can I see the query plan for this query?
The plan is not available for DDL statements, alas. I assume you want to know whether the statement will scan or update all rows, or whether it is just a metadata operation. The way to find that out is:
Read the docs
Test it
The Display execution plan is valid only for Data Manipulation Language (DML) statements. The execution plan is not displayed for Data Definition Language (DDL) statements.
Your query is DDL. Hence the observed behaviour.
Raj
Related
I have a Snowflake stored procedure which is running for 8 hrs. Upon checking the query profiler to see which query is running long I just see a single entry for the call stored procedure statement.
However, Through the logs I know that an insert statement is running which is like:
insert into Snowflake_table
select *
from External_table(over S3 bucket)
I want to check and find out why reading from external table is taking lot of time but the insert query is not showing up in the Query profiler. I have tried querying the information_schema.Query_history but its not showing another query running apart from the call stored procedure statement
SELECT *
FROM Table(information_schema.Query_history_by_warehouse('ANALYTICS_WH_PROD'))
WHERE execution_status = 'RUNNING'
ORDER BY start_time desc;
Please suggest how to find the bottleneck here
Docs is stating that Queries on INFORMATION_SCHEMA views do not guarantee consistency with respect to concurrent DDL: https://docs.snowflake.com/en/sql-reference/info-schema.html
This means that it is possible that your insert-statement is running but is not shown as a result of your query. It could be included but it's not a must.
You could now change the filter to execution_status IN 'success', 'failed' and check again after the procedure finished.
currenty i am working on a report system for our data archive.
the aim is to select data for every 1st of a month, every full hour and so on.
So I have a bunch of parameters to select the data down to a single hour.
To achieve that I used CASE statements to adjust the select like this:
SELECT
MIN(cd.Timestamp) as Mintime,
--Hours
CASE
WHEN
#SelHour IS NOT NULL
THEN
DATEPART(HOUR, cd.Timestamp)
END as Hour,
... -- more CASES up to DATEPART(YEAR, cd.Timestamp)
FROM dbo.CustomerData cd
... -- filter data and other stuff
This statements works good for me so far, but I am a bit worried about the performance of the stored procedure. Because I don't know how the server will behave with this "changing" statement. The result can vary between a 20 row result up to a 250.000 rows and more. Depending on the given parameters. As far as I know the sql server saves the query plan and reuses it for future execution.
When it saves the plan for the 20 row result the performance for the 250.000 result is propably pretty poor.
Now I am wondering whats the better aproach. Using this stored procedure or create the statement inside my c# backend and pass the "adjusted" statement to the sql server?
Thanks and greetings
For 20 rows result set it will work good anywhere. But for returning 250k records to c# code seems change in design for this code since loading 250k records in memory & looping will also consume significant memory and such concurrent requests from different session/user will multiply load exponentially.
Anyway to address problem with SQL Server reusing same query plan, you can recompile query plans selectively or every time. These are options available for Recompile execution plan:
OPTION(RECOMPILE)
SELECT
MIN(cd.Timestamp) as Mintime,
--Hours
CASE
WHEN
#SelHour IS NOT NULL
THEN
DATEPART(HOUR, cd.Timestamp)
END as Hour,
... -- more CASES up to DATEPART(YEAR, cd.Timestamp)
FROM dbo.CustomerData cd
... -- filter data and other stuff
OPTION(RECOMPILE)
WITH RECOMPILE Option this will recompile execution plan every time
CREATE PROCEDURE dbo.uspStoredPrcName
#ParamName varchar(30) = 'abc'
WITH RECOMPILE
AS
...
RECOMPILE Query Hint providing WITH RECOMPILE in execute
NOTE: this will require CREATE PROCEDURE permission in the database and ALTER permission on the schema in which the procedure is being created.
EXECUTE uspStoredPrcName WITH RECOMPILE;
GO
sp_recompile System Stored Procedure
NOTE: Requires ALTER permission on the specified procedure.
EXEC sp_recompile N'dbo.uspStoredPrcName ';
GO
For more details on Recompile refer Microsoft Docs:
https://learn.microsoft.com/en-us/sql/relational-databases/stored-procedures/recompile-a-stored-procedure?view=sql-server-ver15
I would like to know whether my stored procedure will get impacted without specifying Go
Here is the code flow:
Create or replace store_proc1
As
Begin
While loop
{SQL statements repeating itself until source table record count is 0}
End
"Go"
Here I have missed Go at the end of my stored procedure.. Will it impact the performance?
GO is not a SQL statement - it's a delimiter used only in SQL Server Management Studio.
So no, omitting GO will NOT in any way affect your stored procedure's ability to run, nor it performance.
I would like a list of all new or modified records created after a specific date in all tables in a SQL Server database.
I am using SQL Server 2005 and ssms.
Is there a way to do this with one query, or some other tool?
How could I do this for one table?
Assuming all the tables have a ModifiedDate date column, you can then use the undocumented sp_msforeachtable proc
sp_msforeachtable 'select ''?'',count(*)
from ? where ModifiedDate > ''20100101'''
Just adjust the date range, I also use count(*) because I doubt you want millions of rows returned to you
If you don't have a column then you are out of luck, or if the column is named differently in every table then you need to use dynamic sql together with information_schema.columns and information_schema.tables to construct this query
There is nothing inherent in SQL Server where you can get that information. As #JNK indicated, you have to build that into your database design. And, you have to build the solution for each table by adding the create date as a column. Then, you can use SQL to capture the information.
I'd like to put the results of a stored proc into a temp table. It seems that the temp table must be defined beforehand and an INSERT INTO will not work.
Anyone know how to get the schema of the recordset being returned from a select statement?
sp_help only gets info on parameters.
You should be able to insert into a temp table without defining the schema using OPENQUERY:
SELECT * INTO #TempTable
FROM OPENQUERY(ServerName, ‘EXEC DataBaseName.dbo.StoredProcedureName paramvalues1, paramvalues1′)
Where ServerName is the name of your Sql Server instance. See this article for more info
Sometimes you just need to know the schema without creating a table. This command outputs the structure of the resultset without actually executing the stored procedure.
From rachmann on 16 April, 2015 from the Microsoft SQL Server forum article How to get schema of resultset returned by a stored procedure without using OPENQUERY?:
SELECT * FROM sys.dm_exec_describe_first_result_set ('owner.sprocName', NULL, 0) ;
Can you execute the logical content including INSERT INTO in a query window? That should generate a temp table that you can use as a model.
Worst case you build the schema by hand, once, which shouldn't be onerous if you are the one writing the SP.
For the benefit of future documentation, I like to hand-craft DDL in SPs anyway. It helps when debugging to have the schema explicitly at hand.
If you are able, change the stored procedure into a user-defined function.
http://www.scottstonehouse.ca/blog/2007/03/stored-procedures-are-not-parameterized.html