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?
Related
On the frontend of the plesk when I go to "Tools" > "Backupmanager" the page loads some minutes and then it times just out.
On the server via ssh I saw, that the process pmmcli get one more entry for one call of the backupmanager-page. Even killing the process is not going to work except the timeout comes faster. And the pmmcli - process is keeping the machine quite busy after a few tries.
My question is, how I can get the backup manager up running again?
I am still a rookie with server and even more (or less?) with plesk. I beg for your help or some tips please :)
I know similar questions have been asked before...
I am using SQL server 2005, with SSRS 2005 installed on the same box. (aka. production DB, Report DB/TempDB, Database engine, and SSRS all in the same box).
We have about 200 reports deployed in the box.
SSRS/DB is running on a W2k3 64-bit VM.
Now the problem...
Occasionally almost on a daily basis our users get the 'operation timeout' error (error in XML document....). At first I thought it was a report size problem, but then when I try the Report Manager URL (http://<>/reports), nothing appears on the browser. The only thing I can do is to recycle the Report server IIS pool and it will work again. Everytime when the 'operation timeout' happens, the Report Manager URL will not work, and I can't find any logs in IIS to indicate there's a problem.
I researched on the net and found that some people have put a dummy report as part of the SQL server agent job which runs every 10 minutes from 9-5 to 'warm up' the SSRS. The dummy report made a small connection to the DB on one row from a very small table. The operation timeout problem seems to have disappeared for 95% of time, but it still happens. Strange enough, when the operation timeout problem happens, I notice the dummy report job has also stopped working. In this case, I had to recycle the IIS pool, and start the SQL server job again, and then SSRS will work again (until the same problem happens next time)
The error I got from the SQL server job is:
System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host
However I am totally confused by how the IIS issue on the report server somehow affects the SSRS job. Maybe I am on the wrong track but that's bizzare.
My observation so far is if it takes forever for the Report Manager URL (http://<>/reports) to appear it is a bad sign that something has gone terribly wrong on SSRS.
I have also added a new task which call the SSRS Report Manager http://<>/reports URL using PowerShell in order to 'warm-up' the IIS but it does not seem to make much difference.
Can someone point me to the right direction? Thanks. WM
In the past, after much research, I've found memory allocation for SSRS to be the root of many issues. You can try this.
Add the following into the <Service> node in the rsreportserver.config file
<WorkingSetMaximum>4000000</WorkingSetMaximum>
The file is typically in c:\program files\Microsoft SQL Server\MSRS11.iMIS\Reporting Services\ReportServer
This sets the maximum memory available for the report which also set the minimum memory to 60% of the maximum.
https://msdn.microsoft.com/en-us/library/ms159206(v=sql.110).aspx
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.
I have a SQL Server 2008 database, and I need a mergereplication because i want to sync with mobile devices afterwards.
So I created a replication but when it comes to start the snapshotagent, the agent tries to start for about 20 minutes and then it shows the message
The replication agent has not logged a progress message in 10 minutes.
This might indicate an unresponsive agent or high system activity.
Verify that records are being replicated to the destination and that
connections to the Subscriber, Publisher, and Distributor are still
active.
There aren't any other errormessages, neither in the snapshot-agent-status-window nor in the agent-log-window.
I don't have the administrator of the domain, but the local administrator and a domainuser with admin-privilegs. Both have all rights to database, are in the access-list of the replication.
The server agent runs on the local administrator-account and there are 3 MergeReplications on the server, working
The job runs also under the local administrator.
Thank you for your help, Karl
So it works again...
Maybe someone else has got the same issue one day, so i post the solution here:
I researched on the server and found out, the sql server service is running under a local user. The reason for this is, that there were problems with the backupsystem, used by our customers and so they changed it years ago.
Because of the local user account a 15404-Error occures.
Knowing, that i mustn't use domain-accounts, I also solved the initial problem with my snapshot-agent. I searched for hours (nearly days ;) ) and it was just this little change:
When the Replication is created, the job is created too. The job has three steps. The Job-owner is the local-admin, also for the server-agent-service. But the second step of my job (replictionsnapshot) has one setting: run as. And by default this isn't the job-owner but the user running the creation, in my case my domain-account.
Now, that I set it to the local-administrator as well everything works fine again.
Thanks, Karl
I had the same issue, And the below fixed the issue. The replication agent was timing out after 10 minutes and changing the heartbeat from 10 to 30 minutes solved the issue,
Run the below command
exec sp_changedistributor_property #property = 'heartbeat_interval', #value = 30;
and then restart the sql agent on the subscriber to continue syncing.
Provide Used: Microsoft OLE DB Provider for SQL Server. Can anyone help me with this..
I was trying to connect with LLBLgen
This MSDN blog page has some useful on this...
http://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx
In my case, I found the account was locked.
Reason was I previously, on another machine more than 3 times tried to login.
It did not recognise me - and tthen finally it locked my account.
Reopening account made all work fine.
br
Jan
The error you get is almost always caused by a problem with using Windows Authentication. Please try switching to a SQL server login (username/password), or make sure your current Windows login has access to the SQL server and database you're trying to connect to.
-Edoode
I fixed this by mapping a drive to the server running MSSQL. This seemed to generate some kind of trust that allows MSSQL to connect without this error even after a reboot.
I used to get this error sometimes when connecting to my local SQL Server with Windows Authentication. I never fixed it unfortunately - it went away when I reinstalled windows.
I think a reboot used to fix it - have you tried that? Not exactly the best solution, I know :P
Try to synchronize your date and time with the your domain's. The SSPI issue may be related to Active Directory authentication problems, some of them related to date and time changes. This is very simple to check and fix. Try it out!
There is a Microsoft KB article that addresses many of the reasons for this area (KB811889) at the following URL: http://support.microsoft.com/kb/811889.
A lot of Googling shows that one of the diagnostic steps helped most people who encountered the issue.
I recently had this exact issue where I'd get this error only when authenticating with certain accounts, but not others. Ultimately what was causing my problem was not mentioned in any KB or article I found on the net, but through trial and error I discovered that when the account used through SSPI authentication to SQL Server (2k8) happened to be in a large number of groups (in my case over 250) you would get the "Cannot Generate SSPI context" error. I suspect it has something to do with overflowing the security token that Kerberos uses and have seen similar strange authentication problems for user accounts in a large number of groups.
I get the problem when I have the time set differently on my client machine than either the server or the AD machine ( I was trying to test into the future).
Short Answer: Have you recently change the user the service is running as? Was there a system crash?
Long Answer:
I know this is old, but I want to post my experience that I just had.
We had spent hours Googling and found nothing that worked.
Eventually we ran across a set of actions that could cause this:
If you change the user that the Sql Server runs as (e.g. from Local System to a domain usr) and do certain updates and the server doesn't safely reboot -- you get this.
So, we set things back to Local System and bam it worked. Swapped it to the domain user, no worky worky. Ok. Swapped it to Local System, rebooted, swapped it to domain user, rebooted, bam -- worky worky. All was good in our world. Later that morning it crapped out again... still working on that now but the priority is changing and I'm not sure we're going to continue work on this problem so I wanted to post something in case this happens to someone else.
What caused ours was we did an update and, apparently, we learned that it's bad practice to let Sql Server run as Local System so we changed it to a domain user. We never rebooted, but restart the service. A month later, we do updates. We don't reboot. A month goes by and a power strip fries causing the server to have an unexpected shutdown. Yet another month later we find out problem because we rarely connect to this particular database (Interestingly, Sql Server 2008 worked fine... it was only 2005). Or... at least this is the best we've come across.
Our admin guy doesn't like Vista and likes to blame everything on Vista (refuses to let us test Windows 7)... so he Googled "sspi vista" or something like (I know it had sspi and vista, but it might have had another one... in case you need to Google it was well) that and ran across an article that pretty explained our scenario after we had a meeting we all remember these pieces and placed this picture together.
In my case, the time synchronization issue in the Windows 2003 domain environment was actually the issue.
This was quite easy to overlook as the two had been on two different time zones, whilst showing the same times on their clocks; which in effect was about 1 hour apart.
So other than the time on their watches, check the time zones as well.