I've not seen this scenario in all my web searches.
We have several SQL Server Agent jobs that get kicked off by users through various applications.
Quite randomly, these executions will fail. When log in and manually kick the jobs off i'm immediately presented with 'SQL Agent not started' errors.
When I check the agent it says it's running. If I force a restart the problem is fixed.
The random nature of the issue causes testing issues.
The agent is already set up to 'restart if stopped unexpectedly' and 'restart with delay'.
A recent disaster recovery was performed and SQL Server Agent started successfully and declared itself 'running'. However once again it required a manual restart to actually work.
Is this a known issue or bug?
How can I mitigate against this when the agent says its running and all parameters are set correctly and meet the 'internet's' suggestions?
I created a SQL Server instance in my cloud a few days ago for the 1st time.
Today for no apparent reason this instance stopped responding and presents a revolving wait sign for hours now.
I created successfully another instance but the first one does still does not respond.
Could not find a way to reboot it or make it work again.
Any suggestions, anyone?
I am looking into performance issues with an app that uses SQL Server Express (Microsoft SQL Server 2014 (SP2) (KB3171021) - 12.0.5000.0 (X64)) for the back end database.
I'm logging slow running queries using Extended Events. Looking at these I have identified a job that runs every night a series of queries, some of which take quite an extended period. The longest single query takes 10 minutes or so. It seems to be some sort of reporting, gathering broad information about everything in the tables it is looking at.
This seems to be an automated process that is running nightly at exactly the same time and takes about the same length of time to execute each night (around 20 minutes).
It runs on a Windows account with Administrative privileges that connects to SQL using Windows authentication. There is other legit stuff we do know about also running on this account.
The client doesn't know what it is.
The app name logged is just ".Net SqlClient Data Provider" which I believe is a generic default.
This is different than the client application which identifies itself correctly. I have identified with the client everything else that is running against the database- there are a few other jobs that generate accounting emails for example.
I can't find anything in Windows Scheduled Tasks that corresponds and SQL Express obviously doesn't have SQL Server Agent- everything other SQL job I have identified is scheduled in Windows Scheduled Tasks.
I've tried turning login auditing on and I can see the login occurring but it gives even less information as to what it is, it doesn't even give me the client app name.
I have no reason to believe it is in any way malicious, it is likely something that was set up years ago and simply forgotten.
Any ideas for how I could pinpoint where exactly this is coming from?
You will need to do this while you think the mystery program is running.
Open a Remote Desktop windows session on the actual SQL server since you are pretty sure that is where it is running.
Have TaskMgr.exe ready. Go to the “Details” tab so that you can search by TaskManager PID (not SQL PID) . Sort by this TaskMgr PID.
Right Click on the Columns at the top of this Details tab.. Choose “Select Columns”
Add this column …
Command line
While you think the mystery program is running run the following sql.
select x.host_process_id as USE_ME_TaskMgr_PID_OnClient_PC
, x.host_name as PCNameFromClient
, x.program_name as ProgNmFromClient
, x.client_interface_name
, x.original_login_name
, x.login_name
, x.nt_domain
, x.nt_user_name
, x.*
FROM sys.dm_exec_sessions x
order by x.host_name DESC
, x.program_name DESC
GO
Look at the first column of this sql. Find your mystery program in the list. Take the first value. This is the Program PID that will be the PID on the TaskMgr PID. Then you will see the command line full execution directory path.
By using something like sp_who you can find the hostname for each user connecting. Maybe that can give you a hint on where to look?
About 11 hours ago I've started a SQL database creation operation on Azure and it is still being processed. Since my other databases almost took seconds to be installed, it is obvious that there is a technical problem with this one.
AFAIK there is no option for a user to cancel the current process and start a new one. I have also tried to create another but the system throws the following error:
Unable to edit or replace deployment 'Microsoft.SQL.NewDatabase':
previous deployment from '11/24/2015 9:01:59 PM' is still active
(expiration time is '12/1/2015 9:01:59 PM').
Since I haven't purchased any support package I also cannot request it from the Azure team.
We ran out of space on our Production Server and during this time we started getting: "Cannot execute 'sp_replcmds' on " on Replication. The Distributor is the Publisher as well.
After fixing the space issue - this is the only error I'm getting on my Replication
We have five databases set-up for Replication. The four small databases work with no error messages except that the Last Synchronization Status says the following: "The process could not connect to Distributor "
The one large database gets the error in the subject and also that it cannot connect to the Distributor . The Error Code is: MSSQL_REPL22037
I checked the DBOwner and it is set up correctly. I stopped and started the Log Reader Agents too many times to count. I restarted the MSSQLServer Agent Processes on the Subscriber Server as well.
I solved this one myself. After all the other suggestions
It was definitely the BatchSize and the QueryTimeOut properties.
In order to change this:
Launch Replication Monitor.
Expand to the Publication in question.
Go to Agents Tab.
Right Click on Log Reader Agent > Agent Profile.
Create a New Agent Profile with the new parameters you need.
Set the New Profile to 'Use for this Agent'
Restart the Log Reader Agent and just wait.
Rinse/Repeat until you get the right amount.
I set the Timeout to 2400 and the BatchSize to 100 from 1800 and 500 respectively.