I got an error message in my Log Reader Agent:
The process could not execute 'sp_replcmds' on 'Database Name'.
I created another agent profile with a large query timeout and a min value to batch, but it still doesn't work.
Can someone help me?
I'm using SQL Server 2008 and I'm trying to do a replication between databases on different servers.
It could be possible that owner of the database could be someone other than what you have permissions for. Below there's a simple command to change ownership...if you have the rights to do so.
--TSQL Code--
USE PublishedDatabase
GO
EXEC sp_changedbowner 'sa'
GO
There are a lot of things that can cause this error (which include, but is not limited to):
The database has been publication disabled
The account trying to run the log reader agent doesn't have the ability connect to the publisher server
The account trying to run the log reader agent doesn't have permission to run sp_replcmds
In my experience, there's a little more to the error in the replication monitor. Is this the case for you?
This could be due to Owner is not set for the database.
You can check by right clicking on database then choose Property and go to File Table and the Owner selection should be there.
Related
Over the weekend my Dev server experienced a very interesting issue. I have a scripts that periodically take several databases offline, and then bring them back online again. They ran, and took all the specified databases offline, but then failed to bring them online again, the specified error message was:
Msg 5011, Level 14, State 7, Line 4 User does not have permission to
alter database 'XXX', the database does not exist, or the database is
not in a state that allows access checks. Msg 5069, Level 16, State 1,
Line 4 ALTER DATABASE statement failed.
This doesn't seem right to me as they we're run from a user account that has the following properties set:
I further validated that it wasn't a permissions issue by logging on to that server, running SSMS as an Administrator and logging in with my windows credentials (also a admin account) and executing the following SQL on the offline database:
USE [master]
GO
ALTER DATABASE [XXX] SET ONLINE
GO
With the same results...
I've looked at the SQL logs for more details about the specific error, however there are no entries associated with this issue. I can reproduce this issue on every database on this particular server. The only way I've been able to get the databases online is by de-attaching and reattaching them.
Most other stack overflow tickets involving this error message are specific to one database or a specific user account. My issue spans all databases and all admin users I've tried so far, also my issue occurred on a script that had previous worked fine on this server and account, clearly something has shifted over the weekend that is causing this query to now fail. I wonder if anyone else has experienced this issue before?
Update 1
This post talks about how file security can trigger this error message, I granted full access to the user group on one of the databases, then reran the online command, no luck. My SQL Server service is running under a service account that is part of the "Administrator" user group and has full access to all database files.
Update 2
All sorts of interesting idea's put forward here, also discussed here. Lots of commands and ideas on how to repair damaged databases with a several combinations of repair like SQL command, unfortunately none of them work in my situation, they either won't run on offline databases, or after detach and reattachment do not report any errors. Of course, there are always a number of posts simply insisting that the solution is permission based and that running: GRANT ALTER ON DATABASE will resolve all issues. For my admin user account it shouldn't make a difference, but it's a moot point as I can't even run that command on a offline database...
Finally tracked down the issue, apparently we had a completely unrelated SQL database instance on the same server in recovery mode. While it was recovering we we're unable to bring any offline instances online. Detach/re-attach would work, and we could restore the database just fine, but just not set it online.
The separate database finished recovering and we are now able to run the command without issue. I suppose in the future, if I don't care about the database that's in recovery(which I often don't) I'll following the linked steps to get rid of it, before restarting SQL Server and proceeding:
Stop SQL Server
Delete MDF + LDF
Start SQL Server
Restore (may need to drop first, comes up suspect)
Have a SQL Server 2008 db which I connect to the Windows Authentication .. has worked good for 7-8 months .. but now when I come to work today it no longer worked to connect, without that I had done something
Error message was:
Can not open user default database. Login failed.
Login failed for user 'Jimmy-PC \ Jimmy'.
where the first is the computer name and the second is the user. The problem seems to be that it tries to connect to the default database. Have tried to change it without success .. I do not have sql server management tools for sql 2008 but only to 2005, someone who has similar experience? who have not touched anything said over the weekend and it worked last Friday without any problems.
The user's default database is offline. the thing that changed since yesterday is that your database had failed, for whatever reason.
You need to log in with a different account, one that does not have a default database, and inspect the state of the database. If you do not have such an account, then you can use an administrator account. If the administrators group is not granted login into SQL Server then see this article Troubleshooting: Connecting to SQL Server When System Administrators Are Locked Out.
Once you can log in, the only tool you need is sqlcmd.exe, which is installed on your machine. Look into sys.databases, the state_desc column will tell if a database is offline. You can try a to ALTER DATABASE ... SET ONLINE and see if it recovers, but that would be unlikely. Your best choice will be to apply your disaster recovery plan and restore the database from the backups you keep for it.
It is strange that it just stopped working. Have you checked the status of the user's default database? Make sure the database exists and is online.
To find the user's default database run the following command using sqlcmd.exe
select dbname from syslogins where name = 'Jimmy-PC \ Jimmy'
I have seen this error when recovering a system and the user's default database hadn't been restored yet and another time when a database was in "Recovery" mode.
I would also make sure that the windows account is not disabled.
If you find that you need to change the user's default database you can use a T-SQL command, see the following question:
How do I set the default database in Sql Server from code?
I have a strange scenario that I am currently unable to explain. I live in hope that it's just "the Friday feeling" or that some kindly sole here will bail my brain out and save me from endless loops of "but why!?" :)
Two servers, running SQL Server 2005, with DNS Entries of:
1. ServerA
2. ServerB
(Well, they're not really called that, but it will suffice...)
On both SQL Server Instances there are Linked Servers configured pointing to the other server.
For obvious security reasons the LinkedServer Security configuration is set to:
- Be made using the login's current security context
The other "Linked Server Options" are...
Collation Compatible: True
Data Access: True
RPC: True
RPC Out: True
Use Remote Collation: True
Collation Name: <blank>
Connection Timeout: 30
Command Timeout: 10
A login is created with the same password on both Instances. The logins are given the appropriate execute permissions to the relevant stored procedures.
I write some code, and execute it under that login and it all works hoorah
But when I create an Agent Job to run these stored procedures it all goes wrong. The owner of the Agent Job is 'automated_job_login' but my error logging gives the following:
- Login failed for user 'automated_job_login'
(Again that name has been altered to protect the guilty.)
I can't figure out for the life of me why it will work when I log in as that user, but the job errors when connecting to the linked server. (It's definately at the point of the linked server connection.)
To make things more confusing, if I change the Linked Server Security configuration to "Be made using this secuirty context:" and specify 'automated_job_login' with the correct password, it works fine.
I'm missing something, I know I must be, but I can't find what. I've read documentation until my eyes bleed and I've failed. Please help me :)
[Leaving the Linked Server Secuiry option as "Be made using this secuirty context:" is not an option as this would give all users of that server unnaceptable levels of access to the other server.]
The SQL agent job may be owned by your login, but it is not executed in that login context. It's in the SQL Agent service account context
Because you have SQL Server 2005, you could use EXEC AS USER = 'mylogin' as a stored proc option.
Otherwise, you have to set the database user name using the #database_user_name parameter of sp_add_jobstep. In SSMS, you can set the context. Job ownership is slighty different to setting ths, IIRC.
I have backed up and restored a MS SQL Server 2005 database to a new server.
What is the best way of recreating the login, the users, and the user permissions?
On SQL Server 2000's Enterprise Manager I was able to script the logins, script the users and script the user permissions all seperately. I could then run one after the other and the only remaining manual step was to set the login password (which do not script for security reasons)
This does not seem possible in SQL Server 2005's Management Studio, making everything very fiddly and time consuming. (I end up having to script the whole database, delete all logins and users from the new database, run the script, and then trawl through a mixture of error message to see what worked and what didn't.)
Does anyone have any experience and recommendations on this?
The easiest way to do this is with Microsoft's sp_help_revlogin, a stored procedure that scripts all SQL Server logins, defaults and passwords, and keeps the same SIDs.
You can find it in this knowledge base article:
http://support.microsoft.com/kb/918992
Run this:
EXEC sp_change_users_login 'Report'
This will show a list of all Orphaned users, for example:
Now execute this script here for each user, for example
exec sp_change_users_login 'Update_One', 'UserNameExample', 'UserNameExample'
This fixed my problem.
I use the SQL Compare product from Red Gate (http://www.red-gate.com/products/SQL_Compare/index.htm). There are other similar products around but I've had no reason to look for one as SQL Compare has never let me down.
You'll find it is useful for a lot more than the your current requirement as it will help synchronize all types of database object, not just login and permissions.
I have taken a copy of a database home with me so I can do some testing. However when I try to run a stored procedure I get Cannot open user default database. Login failed..
I have checked and checked and checked I can open tables in the databases login to sql management studio and access the default as well as other databases any ideas?
Possibly a corrupt user it was from sql 2000 at work to 2005 at home
EDIT: Mine was from 2005 to 2005. Not sure if this will work for your case...
I had a similar problem. For me, when I detach or create a back up and then re-create the database, it will loose connection to users. User I've been using is still there under Login but it would fail to log in.
In my case, I was able to log in by deleting the User under the database -> security -> users, not the user that's in the root sql server users list.
Then go to root users list and reassign database mapping or create user if not exists.
Hope this helps.
This is a shot in the dark, so forgive me if it just wastes your time.
Another poster mentioned that a given user has an id for the system and an id for any given database. This can be proven out by comparing sid's between the master.sys.syslogins and dbname.sys.users for the same login / user name. If you restore a backup from another sql server that has it's own copy of the master databases, the sids won't match.
Sql Server 2005 doesn't allow direct editing of system tables with out a lot of pain. To help out with these mis matches, they added a stored procedure to help you fix them:
USE dbName
GO
sp_change_users_login #Action='Report'
That will show you what users have a dbName.sys.users entry, but no master.sys.syslogins one - or where the name exists in both, but differ by sids.
If it shows that your user is out of synch, the procedure also has a mode to change the linking:
USE dbName
GO
sp_change_users_login 'Update_One', 'userNameInDbUsers', 'UserNameInLogins'
If the sid mis-match isn't your problem, I've also seen really screwy stuff with Sql Server 2005. The gui is especially buggy. To fix a problem like this, I had to actually drop the syslogins entry (via the gui or DROP LOGIN command )
sp_change_users_login: http://msdn.microsoft.com/en-us/library/ms174378(SQL.90).aspx
Drop Login syntax: http://msdn.microsoft.com/en-us/library/ms188012(SQL.90).aspx
I had the same issue and I fixed it with:
C:\> sqlcmd -E -d master
1> ALTER LOGIN ***** WITH DEFAULT_DATABASE=master
2> GO
Where ***** is your username.
(If you are using a domain username: [*****])
Edit:
Where ***** could be:
username if the user is local
[username] if the user belongs to the actual domain
[domain\username] if the user belongs to another domain (not tested)
I moved 8 databases from SQL Server 2000 to SQL Server 2005 and onto a whole different computer. I normally like to know what stored procs are doing so I dug a little bit and found that the actual command is ALTER USER.
It's what everybody else has been saying. The users get disassociated when you detach and reattach databases in SQL Server 2005. I find this behavior most annoying, as I didn't see that behavior in SQL Server 2000.
The T-SQL to fix this issue looks like this:
USE AdventureWorks;
ALTER USER Mary5 WITH NAME = Mary51;
GO
This MSDN article talks a bit more about this:
http://msdn.microsoft.com/en-us/library/ms176060.aspx
I just solved this issue. My default database was AdventureWorks2008, so as an Administrator, I ended up removing my login from the server. Then running the following to recreate my user
CREATE LOGIN [NT\mylogin] FROM WINDOWS WITH DEFAULT_DATABASE=[Master], DEFAULT_LANGUAGE=[us_english]
GO
My understanding is that Logins are stored in the server, whereas a User is an assignment of a login to a database (correct me if I'm wrong).
Therefore, you cannot move Logins by detaching/attaching databases, and the solution would be to create a database User connecting a (valid) login to the copied database.
http://benharrell.wordpress.com/2007/01/15/cannot-open-user-default-database-login-failed-login-failed-for-user-username-microsoft-sql-server-error-4064/
ALTER LOGIN works only in SQL 2005 and up.
To change the default database for a user in 2000 use
EXEC master.dbo.sp_defaultdb #loginname = N'BuiltIn\Administrators', #defdb = N'master'
I found this out the hard way when I set the builtin\administrators account to default to the application db and it went Offline somehow and I could no longer login. Using Management Studio, you can set the option to login to master but you must run the above command before any other operation will work, less you get the default database is unavailable error.
As was mentioned before, the login mapping to that user account probably became disassociated during the move. Or, you moved it without creating the credentials it was expecting, in which case, you'd need to create the login first...
If it was a backup set and you are restoring it, however, there is no way (that I know of) to reassociate the login to the user via the management UI. Instead, you have to use:
exec sp_change_users_login update_one, 'user', 'login'
to get it to restore the link.