We are gathering wait stats of SQL Server to troubleshoot intermittent issue of slowness related to database server. While doing so I came across wait type MSQL_XP it is consuming 39 wait percentage.When I researched more I find that it is coming due to extended events. Then using Activity Monitor I tried to find out which database executing extended stored procedure. So there are two stored procedure which are using sp_OAMEthod extended stored procedure.We have scheduled db job which which will poll after 15 min to table.So DB Job having sp which ultimately call's extended stored procedure.
So Is is true that extensive use of extended stored procedure causes performance problem in SQL Server.
I searched on database then I found bunch of extended stored procedure our DBA is using and they are scheduled.
Please let me know whether is it right to used to Extended Stored Procedure? Since Mircrosft has already deprecated usage of Extended Stored Procedure.
Also, We have Dynamics 365 MS-CRM,I searched in that database I found dozens of Extended stored procedure.
Related
I am thinking of using some Azure services to share SQL reports with external users. And now I am a little bit confused because there seems no good option for the thing I need.
I have an on-premise SQL database with parametrised stored procedure which returns a set of rows like a select statement. The final effect should be a solution which will give external user possibility to execute this stored procedure with provided input parameters and be able to save the results to Excel file.
So I've thought about migrating tables which are used by this procedure to Azure SQL database and then maybe build some application using PowerApp or Functions, but at this moment I am just stuck and don't know from where to start.
Scenario:
Our application database (in SQL Server 2012) contains entire business logic in stored procedures. Every time we have to publish the database to the client, it unnecessarily results in copying the stored procedures to the client database.
Problem:
All the business logic gets copied to the client side and results in proprietary issues.
Solutions tried earlier:
Using WITH ENCRYPTION
CREATE PROCEDURE Proc_Name WITH ENCRYPTION
This method results in encrypted and non-maintainable stored procedure code. We cannot judge which version of code is running at the client side, hence cannot debug. Version control cannot be applied. Moreover, client cannot perform database replication since encrypted stored procedures do not get replicated.
Creating synonyms
CREATE SYNONYM SchemaName.Proc_Name FOR LinkedServerDB.SchemaName.Proc_Name
This allows for creation of references (synonyms) at Client_DB which access the actual stored procedures residing on a Remote_Linked_Server_DB. In each stored procedure call, entire data is accessed from Client_DB and transmitted to Remote_Linked_Server_DB where the calculations are done and the result is sent back. This results in acute performance issues. Also requires 24x7 internet connectivity to the remote linked server.
Requirement
We are looking for a solution whereby the stored procedure code could be compiled (secured) and separated from the client database. Also, the compiled stored procedure code should be available at the client-end so that client does not require 24x7 connection to a remote location for accessing the stored procedures. Maybe Visual Studio database projects could be used to compile stored procedure code or something else.
[Edit]
I got to know that SQL Server 2014 allows for natively compiled stored procedure code. Can that be of help? msdn link And is the SQL Server 2014 RTM version stable enough?
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.
I've written a stored procedure that takes 15 min when executed from Management Studio. When it's activated from Service Broker, however, after 4 hours it hasn't done even half of its work.
Are there known performance issues when running SPs from Service Broker? (Perhaps Service Broker runs the SP inside a transaction and Management Studio doesn't?)
I'm using SQL Server 2005.
Update:
It appears the problem was executing a stored procedure from another stored procedure. More specifically, I have a stored procedure which receives an operation (export or delete). This SP then calls the respective SP based on the operation (one has an ETL process, the other deletes data). Forcing recompile on these SPs seems to have fixed the problem. I wonder if SQL Server should make an action plan for each sub-SP though, independent of the SP that's calling them. In that case, no recompile would be needed.
I don't know about Service Broker, but for general stored procedure troubleshooting check out the suggestions given at this question. They helped me a lot to figure out some problems with my stored procedures.
You can take a look at what the stored procedure is doing with the WhoIsActive routine, you can acquire the query plan and study if there is any difference with the query plan when executed in Management Studio, you can experiment with the OPTIMIZE FOR hint to eradicate parameter sniffing...
(Parameter sniffing is that the query plan is generated differently when other parameters are supplied. Is Service Broker passing the same parameters to your SP as the ones you pass in Management Studio?)
Good luck and please post your findings here if you are unsuccessful.
What's the best way to know which stored procedure are currently running in a database.
I have a stored procedure which basically calls other 3 and passes them some parameters and these 3 stored procedures take a long time to complete... I would like to know which one is running...
Thanks
I think you can also use SQL profiler to get information in more detail.
Use Activity Monitor to detect what is currently running on your database.
The Command column might indicate which stored procedure is currently running.
To help you monitor whats stored procedure is running I would suggest creating a SQL Job to run those 3 stored procedures seperately as steps. That way you can place an email alert step in between them so that you know when each one has completed.
This shouldn't be too difficult to setup in SQL Server Agent.
EDIT: SQL Profiler is an option, but this will have an impact on performance as you will be monitoring the live database, plus you indicated that the stored procedures take a while to run so you would want those times to increase. IMO I think a simple email alert, or some other form of notification which could be built at the end of each stored procedure would be you best option.
e.g. An simple insert to a log file with a timestamp indication when each stored procedure has finished.