Whenever I open the Activity Monitor in SQL Server Management Studio 17.8.1(14.0.17277) the overview always switches to (paused). Even if I choose resume, it quickly changes back to paused.
This happens on a variety of SQL Servers and SQL Server versions (2005 through 2016) so I don't believe it is a conflict with old vs new SQL Setups.
I can run Activity Monitor in SSMS 2012 (11.0.2100.60) on the same servers with no error which confirms that the service is actually running and functional.
Any help or insights would be appreciated. I'm not a fan of switching back and forth between two management studios if I can help it. (I uses 17 so I can have context menus when right clicking on items in SSMS which wont work on 2016 servers in older versions of the studio).
I setup a basic SQL login and found that activity monitor was permanently paused for this login. Then I granted this login the "View server state" permission and activity monitor now works. To do this, open up the Security and Logins folders for the relevant server instance, right click a login and choose properties. Choose Securables and you should see all Permissions listed in the bottom pane. Put a tick in the grant column next to "View server state".
Run as administrator helps, but I only see this happen on SQL clusters
However I have found the following somewhere, can't remember where.
And I added the AD group with Sysadmin rights using these steps 1-5
Click Start, click Run, type DCOMCNFG, and then click OK.
In the Component Services dialog box, expand Component Services, expand Computers, and then right-click My Computer and click Properties.
In the My Computer Properties dialog box, click the COM Security tab.
Under Launch and Activation Permissions, click Edit Limits.
In the Launch Permission dialog box, select your user and group in the Group or user names box. In the Allow column under Permissions for User, select Remote Launch and select Remote Activation, and then click OK.
Seems I don't need to follow step 6-8, so I have not tried these.
Under Access Permissions, click Edit Limits and give Remote Access to your user.
Go to DCOM Config(Expand My Computer), find "Windows Management Instrumentation", right-click and select Properties
In the Security tab, click on Edit under Launch and Activation Permissions, and give your user Remote Launch and Remote Activation.
I experienced the same as Izulien (running v 17.7 of SSMS), in out production environment with my personal user.
Reconnecting to dbs and restarting SSMS did not help.
However I did have access via the sa user to our dev-environment. Using the sa user did the trick in dev, and the same applied for our production environment, leading me to assume that this is connected with privileges/roles on my user.
In the environments that I manage, that only happens when I am using SSMS in a different computer, other than the server where actually the SQL Server ENGINE is installed. That is: SSMS client on a PC, and SQL Server engine/instance in a server. For me, 99% of the time this means: I am in Florida running a local PC Virtual Machine on my personal iMacPro, running SSMS, accessing a SQL Server server in Chicago via VPN.
So, I tend to believe this may be some sort of network timeout that happens..?
This is just a theory of mine. Because, if I actually Remote Desktop into the SQL Server itself and run SSMS locally in the server the Activity Monitor does not pause.
My two cents. Maybe someone can unravel this better.
EDIT: Also, I notice that it's when I expand the processes panel that shortly thereafter it pauses. If I leave the processes panel collapsed it does not happen, or at least not as promptly. AND, interestingly, if I open Activity Monitor, then I do NOT immediately open the process panel and let the graphs run for a while, say, two minutes, and THEN I open the process panel it does not pause anymore.
It seems to be that the initial population of the graphs AND the initial population of the process panel at the same time that cause the problem. At least that's the case for me across the SQL Servers I manage.
R.
Related
I am wondering about something. I work with a lof of SQL servers, to which I need to connect several times a day. Unfortunately there are quite a lot of them and I constantly need to check the IPs and select them by IPs. Each server belongs to a different customer, none are mine and none are local.
what I'm looking for is the ability to give them names/aliases in my SSMS application, so that when I go to connect Object explorer and get the server login screen, I don't have under "server name" a list of IP addresses, but names/aliases, that I create for my purposes only. Just as a display option, so that others' ability to connect to the servers or use them remains completely unaffected. So that instead of having a bunch of 192.168........., I could see for example: "Cust1_Prod, Cust2_Prod, Cust1_Test, Cust2_Test" aliases as I please.
Any advise would be appreciated.
You should be able to leverage the Registered Server functionality for this.
In the toolbar, View -> Registered Servers. Pin the window that opens up.
You can create folders for more organization if you like.
Right click on a folder name and click New Server Registration. In the dialog box that opens, you can give each server whatever name you prefer. In this case, I put "My Custom Name for This Server" in the box.
From this list, you can right click the server name and click on Object Explorer to open the connection. In your OE window, your custom name shows up, followed by the actual name of the box.
These names get saved to your local config files. You can export them when you get a new machine, or if you want to share with your team, but it's strictly a local SSMS rename.
Also, once you have some servers registered, you can right click on a folder and select Object Explorer and it will open connections to all of the servers in the folder. I use that trick to cluster my Dev, UAT, and Prod boxes together, but if there are groups of servers you frequently use together, this is a quick way to get to them all with one click.
This is relatively similar to questions such as these:
How can I change my default database in SQL Server without using MS SQL Server Management Studio?
https://superuser.com/questions/364825/sql-server-management-studio-ignores-default-db
That being said, Management Studio is ignoring all the suggestions. I'm logging in as sa, and I can see that the default catalog for sa is being changed successfully, but Management Studio ignores these changes in the dropdown:
Even if I change it to specific_database_name, and even if I can look at the sa login Properties menu and see that it's set to specific_database_name, Management Studio will always default that combo box to master.
I've tried:
Exec sp_defaultdb #loginame='sa', #defdb='specific_database_name'
ALTER LOGIN sa
WITH DEFAULT_DATABASE = specific_database_name
Going into the Properties menu for login sa in Management Studio and setting it in the dropdown box there.
The OP in the second question eventually fell back to using a batch file to log in as a different user, but I'd personally just rather keep having master show up. Also he did mention being able to set this on the connection properties themselves, but it's greyed out on my system, and I seem to remember being able to set this for an individual user a long time ago on another machine.
How can this be set? Note that this is not using a Windows login, but a SQL Server one instead. Thanks.
I don't know why these methods are not working. Just to be sure I just did the following (on SQL Server 2012 enterprise)
1) Created Login test and assigned x1 as default database
2) Added login test to database x1 (and made test a member of datareaders)
3) Reopened SSMS - Logged in as Test
4) Opened query window - was placed in x1.
You really want to make users default to a database that is not a system database - otherwise they will attempt to create objects in Master which is something you really want to avoid.
After avoid disasters for a few years, my luck finally ran out.
I had a few query windows open (one of them on our production server which I forgot about). Thinking I was on our dev server, I did all sorts of nasties and totally hosed our production database.
Any BKM's on how you folks keep this from happening?
All advice appreciated!
Open up SQL Server Management Studio
On the View menu make sure that Registered Servers is visible (alternatively hit CTRL+ALT+G
In the Registered Server panel expand Database Engine
Right-click Local Server Groups
Chose New Server Registration
Fill in your necessary server details and then switch to the Connection Properties tab
Click on the Use custom color checkbox
Select the colour to be used. I tend to chose bright-red for live servers and green for development environments.
Save your Registered Server.
Next time you open a query on this connection the status bar at the footer should show the colour you selected.
IMPORTANT: If you change the connection of a query window (option in the right-click context menu) the colour of the status bar does not change. Just be careful out there!
Specially for such case I have added "Important DB Alert" function into my SSMS add-in called SSMSBoost.
You can "save" your production and development databases and assign them different colors. Whenever you change your connection to "Important DB" you will be warned with additional tooltip, appearing in SQL Editor window.
The feature is described here:
http://www.ssmsboost.com/Features/ssms-add-in-preferred-connections
I have a database in a local file that is used by a program. The program has limited functionality and I needed to run some quick queries. I installed SQL Server Management Studio Express 2005 (SSMSE), connected to the SQL Server instance, attached the database file, and ran the queries. Now the original program will no longer connect to the database. I receive the error:
Cannot open user default database. Login failed. Login failed for user 'MyComputer\MyUserName'.
I've gone back into SSMSE and tried to set the default database. I've opened up Security, Logins, BUILTIN\Administrators and BUILTIN\Users. Under General, I have set the default database to the program's database. Under User Mappings, I made sure the database is ticked and that db_datareader and db_datawriter are ticked.
The program uses the connection string:
Server=(local)\Instance; AttachDbFilename=C:\PathToDatabase\Database.mdf; Integrated Security=True; User Instance=True;
I know jack-all about database administration. What else am I missing?
This may not be answering your question specifically, but it may help others with similar issue caused by different problem
In my case the problem was my user is defaulted to a database which is not accessible for any reason (can be renamed, removed, corrupted or ...)
To solve the issue just follow the following instruction
Try to login again on the login page there is other tabs select
"Connection Properties".
under the tab locate "Connect to database" and select an existing database you have access to like tempdb or master
Once you are connected to the SQL Server Instance execute the below TSQL to assign the login a new default database.
Use master
GO
ALTER LOGIN [yourloginname] WITH DEFAULT_DATABASE = TempDB
GO
Alternatively once you connected change your default database name to master via UI
Article taken from :
http://www.mytechmantra.com/LearnSQLServer/Fix-cannot-open-user-default-database-Login-failed-Login-failed-for-user-SQL-Server-Error/
This problem manifested for me when I took my default db offline. Next thing I know I couldn't login. Switching to the Connection Properties tab and selecting the drop down to change the database I want to connect to also failed.
It let me in right away once I manually typed master as the db I wanted to connect to (on the Connection Properties tab).
First, try to isolate your problem:
Take a backup of the file! Some of the steps below can, apparently, in some circumstances cause the file to vanish.
Are you sure you are connecting to the same instance through Management Studio as the program is?
If possible, try to shut down the instance that you are not expecting to use.
Set the user's default database to master and try to make the program logon.
Try to login as the user through Management Studio - since you have integrated security, you should open Management Studio as the program's user.
Are you using "User instances" - perhaps without knowing it? If so, this may be helpful: http://blogs.msdn.com/b/sqlexpress/archive/2006/11/22/connecting-to-sql-express-user-instances-in-management-studio.aspx
I haven't worked much with files being attached in the way your program does - but you write that you attached the DB in the Management Studio as well. Have you tried detaching it there before running your program? Perhaps you are seeing the Management Studio and your program competing for exclusive access to the MDF-file?
EDIT: I added point 6 above - this is new in my own list of TODOs when troubleshooting this type of Login failed. But it does sound a lot like what you're experiencing.
EDIT2: In the first edit, new item was added to the list. So the numbers in the comments doesn't correspond with the numbers in the answer.
I finally figured this out, and my situation is different than every other I've read about tonight.
I had restored my database from a backup. I knew that there was a particular login user that I had been using, so I created that user in SSMS. However, there was already a user by that name under the database that had come in with the backup.
Since I had screwed around so much trying to fix this, I wasn't able to delete the user under the DB easily. I deleted the database and restored again. Then:
Delete the user under the Databases->[my database]->Users
Create the user again in Security->Logins (not under your DB, although that probably works too.
Go to the newly created user. Select properties. Then under User Mappings, tell it to make your database the default. Give it read and write access.
Summary: I had two users. One that came with the DB, and one that I had created. Remove the one that came with the DB and create your own.
First click on Option>> Button of “Connect to Server” Prompt.
Now change the connect to database to any existing database on your server like master or msdb.
More Details
https://blog.sqlauthority.com/2008/11/04/sql-server-fix-error-4064-cannot-open-user-default-database-login-failed-login-failed-for-user/
I've also had this same problem, it turned out that I was trying to access the built in membership classes (in a view), and that .Net was trying to create the database in the App_Data folder:
#Membership.GetUser().ProviderUserKey
This will trigger the system to try and create a database based in the built in membership system, which may not be the way your system is setup.
I had a similar problem had to simply download SQL Express Utility that is capable of starting User Instances. SSEUtil is a tool written by the Visual Studio team to help troubleshoot User Instance issues, you can read more about it in the read me file that is installed with the utility.
http://www.microsoft.com/downloads/details.aspx?FamilyID=fa87e828-173f-472e-a85c-27ed01cf6b02&DisplayLang=en.
Hope this will help.
In my case I had to set "connect to any database" right path:
On your instance, go to Security , then to Logins.
Right Click on there, you will see properties and you should click on Securables.
There it give possibility to connect to any database.
SQL Server 2008 doesn't remember password inspite of checking the "Remember Password" checkbox.
I was suspecting a reboot would solve the problem. But, the issue persists.
Environment: Windows Vista Ultimate, SQL Server 2008
I have been hesitant to post this, as it seems so trivial and weird.
There is a solution for this in SSMS 2012 that worked for me. Microsoft now provides a mechanism for removing a server from the list of remembered servers, and removing the offending server from the list will allow you to save the password the next time you connect to it:
In the Connect to Database Engine dialog, drop down the server name list
Use the arrow keys to select the server for which passwords aren't remembered
Press the delete key on the keyboard.
https://web.archive.org/web/20160216044501/http://blogs.msdn.com/b/managingsql/archive/2011/07/13/deleting-old-server-names-from-quot-connect-to-server-quot-dialog-in-ssms.aspx
If you register the server, and connect to it that way (just a quick double click), it works great!
In SSMS -> View | Registered Servers
Choose "Database Engine" (should be selected by default)
Right click on "Local Server Groups" and choose "New Server Registration" (or create your own group first if you prefer)
Enter all required details: Server address, username, password, tick "Remember password" box, Registered server name
Click "OK" -- now you can always connect to this server from this "Registered Servers" tool window - it will not ask for a password again.
I got this from serverfault.com and it worked great!
Does this bug report match what you're seeing?
EDIT (January 10, 2015): Ganesh points out in a comment that this link is now dead. This decade-old bug was closed as “Won’t Fix,” but it has been reposted/reopened here. (I put a screenshot of the cached page here, for anyone who’s interested.)
I believe I found the solution to this problem.
If your SQL Server seems to have forgotten your passwords, try this:
At the log on screen, click on the down arrow of the Logon selection box.
Do not select a logon name right away.
Wait a few seconds.
Then select the logon name from the list.
Your password will appear in the password box.
Why does this strange behavior occur? I believe SQL Server may have to poll accounts and does not do it in time when you click immediately on the log on name.
The SSMS 2012 answer didn't work for me since I'm on 2008 R2. However, I did find a way to "fix" it. It's not a true fix, but if you keep a backup of the file, you can always restore it very easily if one of the servers loses your credentials.
Important Note:
While playing around trying to find out WHY/WHEN it actually does lose credentials, I found that it seems to always remember the last used username that has never been used for that specific server using your profile. For example, if you start with a fresh profile, and you connect to a server called MyServer, and you begin by using sa for the username, regardless of if you check "remember password" or not, if you log in successfully with sa, it seems that SSMS now stores that in memory. Now if you use the username Tester and log in successfully, it will always open by default with Tester as the user.
Now for the fix/workaround:
First, check out this article, but I recommend that you DON'T DELETE the file, just rename it to SqlStudio.bin.OLD or something, so you can always restore it to check any settings that would have been reset using this method.
MY Approach:
I first renamed my bin file like I recommended. Then, I opened SSMS and logged in to every server that I use most often, using the credentials I always want to use for those servers, and selected "Remember password" for each one. I then made a BACKUP of the bin file, and store it in a secure place on my network. This way, if I ever need to log in to a server with another username for testing or whatever, I can easily restore my original bin file afterward. Or, if you want, before you use the new username, you could just rename the bin file and do your work as the new user. Once you're done, just delete the new bin file and rename your original back to .bin and you'll be good to go.
The key is to get a good version of your bin file and make a backup. If you ever add a new server, you can log in using the same approach as above, using your desired credentials and remember password, and then copy the bin file to the backup location. Hope this helps!
You can remove user setting completely and SSMS will be able to remember new logins. Be aware this way you'll lose all the saved ssms logins.
User settings location is
%APPDATA%\Microsoft\SQL Server Management Studio\[you ssms version here]\UserSettings.xml
For me, I solve my problem by running "SQL Server Manage Studio" (SSMS) by Admin right (right click, Run as Administrator) and tick check box "Remember password", type password and connect.
Then the next time I run SSMS normally and boom, no need to type password again.
It seems that SSMS have problem writing credential and run as Administrator do solve it.
This worked for me:
I went to Control Panel -> Credential Manager, in the "Windows credentials" category then "add a Windows credential" and manually created a record with:
IP
User
Password
and then SSMS started to remember the password