Explain plan, show plan and other commands are not allowed in stored procedures.
I thought, I will call back from plancache (as per documentation said here), but there are no plans in there.
I am on cluster-in-a-box, with memsql 7.0.15.
Regards,
cashy
from version memsql 7.1 EXPLAIN, PROFILE, and SHOW PROFILE are now allowed inside of stored procedures.
You can show explains in the plancache with the command SHOW PLAN <plan_id>, after you have enabled enable_disk_plan_explain. See https://docs.memsql.com/v7.0/reference/sql-reference/data-manipulation-language-dml/explain/
Related
i am looking to retrieve the SP execution log from system table.
I looking to retrieve the parameters passed for the sp at the time of execution.
You can't. There is no such thing available without running a trace or capturing system events.
There are NO logs that Sql Server maintains itself that will help you.
Your best course of action in the future would be to log this inside the procedure when it's call. Profile traces might help you, but depending on how the procedure was called, it also might not.
Not the answer you were looking for, but it's the answer none the less.
We have a .NET Application using LINQ to SQL (ORM) to call a view which contains joins from multiple objects in different databases. The .NET Application times out calling this view, however our DBA runs the following statement:
sp_refreshview on the view and the subsequennt sql views
the application starts running again.
This application starts timing out again on the same view after close to 20 minutes. So our DBA has scheduled a job to run the above statement every 30 minutes. There has been no structural changes to the view and we are trying to figure why sp_refreshview fixes this problem and what could be the underlying issue that we could fix?
The reason that sp_refreshview is fixing the issue is that the view is not schema-bound. SQLServer keeps metadata about the view to aid in execution, and since the view is not schema-bound the metadata becomes outdated as the base objects are updated (think DML statements). What sp_refreshview does is update that metadata for non-schema-bound views so they can run optimally. Take a look at the documentation for sp_refreshview.
For some clarification on why this works, think about what a view is? A view is just a query. The metadata that is stored relates to that query.
Whenever you run a query, the server will figure out the most optimal way to run that query (called a plan), and that depends on the statistics of the tables used in the query. As the data in the tables change, the statistics for the tables will change, and so the plan can change. When you create a view (non-schema-bound), metadata around the optimal execution is stored (most likely the plan). Since a view is just a query, the plan can become outdated and sp_refreshview updates that metadata.
Most likely sp_refreshview causes the server to remove the cached execution plan of your query from the cache. When you run the query after a call to sp_refreshview the new (better) execution plan is generated. This is why calling sp_refreshview helps. Apparently, updating statistics doesn't remove cached execution plans, that's why it doesn't help in your case.
There are some types of queries that can't have a good plan for all possible values of parameters, or your data may be significantly skewed.
If you add OPTION(RECOMPILE) to your query most likely you will not need to call sp_refreshview to make it work fast.
I don't know how to add this query hint when the query is generated by your ORM.
I recommend you to read an excellent article Slow in the Application, Fast in SSMS by Erland Sommarskog.
Metadata is information about the tables used by the view. Statistics updates the information about the data. It might help to see your View definition. For example, having a select * in the view could really cause you problems. As a refresher, a view is just a statement until it is executed. If you are using tables that are always changing their structure or are dropped and re-added, you will need to be running sp_refreshview every time. If you want additional help, you will need to provide the query and any information on the underlying tables, like processes the refresh them. All of the above comments were within reason correct.
My boss and I have been trying to see what sort of auditing plan we could try for our stored procedures. Currently there're two external applications taking information from our database through stored procedures and we're interested in auditing when they're being executed, and what values are passed as parameters. So far what I've done is simply create a table for the stored procedures one of the apps is using, and as they use the same input parameters, have one column per parameter. Obviously this isn't the best choice, but we wanted to get quick info to see if they were running batch processes and when they were running them. I've tried SQL Server Audit, but it doesn't catch the parameters unless you're executing a SP in a query.
SQL Server Profiler will do this for you; its included for free. Setup a trace and let it run.
You can also apply quite a bit of filtering to the trace, so you don't need to track everything; you can also direct the output to a file, or sql table for later analysis. This is probably your best bet for a time limited audit.
I think I've used the SQL Server Profiler (http://msdn.microsoft.com/en-us/library/ms181091.aspx) in the past to audit SQL execution. It's not something you would run all the time, but you can get a snapshot of what's running and how it's being executed.
I haven't tried using them, but you might look at event notifications and see if they will work for you.
From BOL
Event notifications can be used to do the following:
Log and review changes or activity occurring on the database.
Is there any system defined sp is available in SQL Server 2005, to find what are the tables are got affected when the applicaion is running and we are navigating from one page to other.
There's really no easy way (if any at all) to find that out, unfortunately.
As SQL Server MVP Aaron Bertrand puts it in his excellent blog post When was my database / table last accessed? :
A frequently asked question that surfaced again today is, "how do I see when my data has been accessed last?" SQL Server does not track this information for you. SELECT triggers still do not exist. Third party tools are expensive and can incur unexpected overhead. And people continue to be reluctant or unable to constrain table access via stored procedures, which could otherwise perform simple logging. Even in cases where all table access is via stored procedures, it can be quite cumbersome to modify all the stored procedures to perform logging.
However, with the help of the sys.dm_db_index_usage_stats DMV (dynamic management views) function and some clever T-SQL programming by Aaron, you can find out a few of those answers - check out his very enlightening blog post for details !
However: since this information is based on a DMV and the "D" in DMV stands for dynamic, those values are only valid since the last server reboot and will be wiped out and not preserved when you next have to restart your SQL Server process / reboot your server machine.
I know of none, but Profiler offers a solution. Run Profiler (can be a developer box) and navigate. It will create an output file for you of what is being run.
There are also code tools that show dependencies. I would imagine at least one shows dependencies on SQL objects.
I don't think so. You can run the SQL-profiler to see which commands are fired against the SQL server but you will have to parse them yourself.
You could also try to empty the query cache and then look at it when your navigation is done, but this cache will be contaminated by other queries running on the server (including the ones run by SQL server itself).
How can I make my SQL statements not to appear in Profiler ?
They contain sensitive information and I don't want them to
show in Profiler.
Thanks for the replies !
The profiler can only be run by someone with proper rights so if your installation is properly secured you should be fine (no users should be able to profile your application).This goes beyond security, since profiler slows down the server considerably.
There is no way. The "text" column in profiler can not be removed from use.
You need rights to run profiler (sysadmin or GRANT ALTER TRACE) so it's not an implicit right.
Note:
sysadmins could decrypt stored procs or add logging code, regardless of whether they run profiler
physical access needs controlled, at least to stop someone taking a copy of the database away
things like sp_password or ALTER LOGIN are not traced anyway
Only way I can think of to do this would be to make them stored procedures (The profiler would only show the call), but if the arguments are what's secure (which is likely) then that won't help you (Edit: As pointed out in comments you can change the config of the profiler to include this anyway, so this won't help much)
Have you considered not giving access to people not allowed to view the data? Access to run the profiler is a pretty high level of access...
Also, have you considered hashing your data before storing/querying it? Sometimes that won't work, but if we're talking passwords then they really should be stored and looked up in an encrypted form anyway.
I've noticed if you use the encryption functions build into SQL (Written about at https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/sql-server-encryption?view=sql-server-ver15) like ENCRYPTBYPASSPHRASE, the text is not shown in profiler - I'm not sure if this is 100% fool proof but it does fit the question.
Example...