Put differently, should I always set the job owner to sa for a SQL job, even though it defaults to the user who created it?
Any jobs that are owned by a user will cease to run if that user is disabled or deleted. The jobs may also not run if there is an Active Directory problem at run time. Brent Ozar has an article about this on his website:
http://www.brentozar.com/blitz/jobs-owned-by-user-accounts/
You're gonna have to bear with me. Because I'm going by memory.
Looking at some old scripts, I have this code.
select #jobOwnerNameVeryImportantToSetCorrectly = 'someSqlAuthenticatonUser'
Now. In my scenario, I allowed a non 'sa' user to schedule and run the jobs.
Thus why I made the owner a non 'sa' user.
The question I think to answer is, "who runs the jobs". If it is always 'sa', then its not an issue.
But, if you want a non 'sa' account to run it, then how is a less privileged account going to run a job owned by the super-mack-daddy account?
My test would be.
Create a job. Let 'sa' own it.
Create a temp sql-authentication account.
Login to the database as this sql-authentication account.
See if you can run the job.
My memory is saying "the lesser account won't be able to". However, I dealt with jobs on Sql Server 2005. So even if I remember correctly for 2005, it may not be the same for 2008 or 2008R2.
But I remember having issues with this. And thus my variable declaration:
select #jobOwnerNameVeryImportantToSetCorrectly = 'someSqlAuthenticatonUser'
I read Brent Ozar's article as well and am in a similar situation where there are a lot of jobs not owned by SA that are enabled. From what I have researched, I haven't found any compelling reason NOT to change the ownership to 'SA' but two good reasons mentioned above why you should.
You don't have to worry about them not being able to run from this change. The only two things I would be cautious about are:
1) Jobs that you run as SA and
2) If you are coming into an environment, enabling jobs that have been disabled after you've made this change.
Why someone would ever do those two things, IDK but you can always back up msdb and then test these changes in a dev or training server. Just note the jobs that you change in case something unexpected happens.
Related
I've googled my issue all weekend, but can't seem to solve the problem
So basically, I have a query, when I run it manually in a query window, it works fine and my job executes, resulting in an email being sent. However, when I set up a schedule, I get the following error:
If you can't read it, the error message says,
"The job failed. The job was invoked by Schedule 9. The last step to run was step 1."
Then underneath it says,
"Executed as user 'adminName(not sa)'. Failed to initialize sqlcmd library with error number -2147467259 (SQLSTATE 42000) (Error 22050). The step failed"
So I log in with user sa, and apparently this user needs to have SQL Agent permissions in the msdb database. According to this screenshot, sa is the owner:
So since sa is the owner, it would mean it has all the SQL Agent related permissions, right? Furthermore, the code I'm using executes from the CompanyDB, so I think perhaps this may be the issue. If I look at properties, under sa, I get this window:
So the CompanyDB is unchecked for user sa, so in order to allow sa to query CompanyDB in SQL Agent, what permissions would it need? I'm assuming this is the issue, but I'm not really sure, I can't seem to figure it out, any help is greatly appreciated.
Jobs should have dbAdmin permissions. That being said, it depends on whether you wrote to the db, update, or just send the email.
The better option would be to create a webservice and call it when you want to send the email.
I am in a unique situation where I need to test my server connectivity to Oracle databases however I do not have access to any account or password.
Reason why the connectivity needs to be tested is because many times there are multiple layers of firewalls between my servers and the database, and also particularly recently while trying to access RAC/Exadata databases we realized that doing a telnet on the "scan" IP range (which were the only range visible to me) was not enough and that there are underlying physical/virtual IPs that are actually used to connect which were blocked. If I can test connectivity I can at least confirm the database is accessible.
I thought about connecting using sqlplus test#DB, where "test" account doesn't actually exist. If I get a reply saying that incorrect username/password logon denied, then at least I know the database connectivity is working because at least it reached the database to perform authentication. But I have audit concerns (whether DBAs will think someone is trying to hack the system) and also whether there's an actual way or command to do this test.
like #OldProgrammer pointed out, this is pretty much an optimal case for tnsping from the command line
tnsping MY_SERVICE_NAME
Here's a good post showing the basic options. Oh, and I'm pretty sure the DBA's can still see the traffic if they want to.
I did something stupid, I think I fixed it, and I would like to know if there is anything obvious I missed or should check. I'm a first-time DBA who has formal training for only some operations within SSMS 2008 R2. I have a moderate to good understanding of SQL and that knowledge is growing fairly rapidly. I'm still making some mistakes.
Today I created a user and, on autopilot, accidentally hit Enter after giving her a password. I had meant to uncheck Enforce Password Expiration and User must change password at next login. The user was mapped to three databases.
The stupid thing I did was in deciding to delete the login in the server, delete the login from each of the three databases, and recreate the login. Obviously this should not have been my solution. Obviously again, attempting to recreate the login returned an error: "The server principal FOO already exists..." This was error 15025.
So I found that sure enough, there was a row in sys.server_principles for FOO row. I used Drop User to get rid of it, then checked again and it was gone. Great, recreate the login. New error: "User, group, or role already exists in the current database..." Error number 15023. This also added a new row for FOO back into sys.server_principal, which I dropped again.
So then I recreated the login without any mapping, which worked. Then I tried adding the mapping but got the same error 15023, which didn't surprise me. I used Alter User FOO with login = FOO. Ran successfully. Tried adding the mapping again, same error. I tried adding each mapping one at a time and found that two of the three databases I could map just fine, but the third one was a problem.
Finally, I closed SSMS and reopened it, and for some reason I was now able to map the third database. It is probable that closing and reopening SSMS did nothing, I don't see why it would, but I don't know what caused the mapping to fail previously and work that last time.
I have tested the login and it works for all of the databases. I'm wondering if there is any cleanup I should perform or look into, or any concern I should have. I do have daily full and hourly transaction backups, but as the databases are in use right now I obviously hope not to have to use them.
So obviously I messed up and I won't be doing that again. Any places to check, concerns, or assurances would be appreciated.
Thanks.
You can check that the mapping is correct with the following query:
select name, suser_sname(sid) as [login]
from sys.database_principals
where name = 'foobar'
The suser_sname(sid) function will take a security identifier (sid) and map it back to the server-level login. Run that in each database you're concerned about and ensure that the login is indeed what you expect it to be. If it's not, you already know how to fix it (the `alter user … with login = …) is the right move there).
As an aside, part of your story doesn't quite match up for me. You said that you were checking sys.database_principals to see whether the login existed or not. The thing is that logins are in sys.server_principals (whereas users for each individual database are in sys.database_principals). This may account for the trouble you had.
My problem with database starts with situation where I cant really modify anything in database. My project specialist has limited time to help me. Here is the thing:
My user in Oracle database has older schema than actual production one. My section is working on stable and older version. After every release we are keep getting this issue, that something is set (maybe on Jenkins, maybe not) automatically to update our database to version, which we dont want. We tried to resolve it by changing password to user, but it produce new issue. Automat is trying to log in and when it gets wrong pass error, it is trying again. Oracle 11g has this limit 10 failed login attempts, after which it is locking the whole user account, which we use to connect do db by our application server.
We can not investigate this by turning on auditing failed logins, because it takes place on database space and our db-guy has not allowed us to do it, because if we exceed the space limit (which is about 11GB) the whole database will be dead (our project is not as important to do it). Another thing is that person who probably set the scripts which are our problem doesnt work anymore here.
Our workaround was to manually unlock account to get the connection by application server, and then wait a few secs to get locked again (but the connection of app server was stable). It is stupid, you must admit and the problem is when the connection drops by any reason - app server will not get it automatically, we have to do it manually which is not a solution. I have reconsidered it all again, my db-guy has no time to help me, I have no tools and access rights to investigate where this script or whatever other problem causing thing is beeing executed, so I started to thinking: what if we set limit of failed login attempts to unlimited? Will this decrease the performance of database? Will this generate any special new problems? Maybe the solution would be change the PASSWORD_LOCK_TIME to small value? I am asking you to some arguments that I could provide to my db-guy to convince him to use this new workarounds so I can start working again with code and not this database problems.
Currently, i have SQL Server 2005 database for which I have admin rights, but do not have sysadmin rights.
There was a particular process which was stopping me to do few things on a table.
Is there a way to kill a user SQL queries, if they were ran through a web client without having sys admin rights. In my case, django website ran the query using pymssql ?
Using "KILL" is role-restricted for a very good reason, and should be used only when you understand what the blocking process is doing. If the KILL statement is used against a SPID executing a long-running transaction, the KILL will initiate a ROLLBACK on the table (which can take quite a while on a large table) to maintain DB consistency. The statement:
SELECT open_tran FROM master.sys.sysprocesses WHERE SPID=<blocking SPID number>
will give you some detail about the process and what it's doing. Alternatively you can try:
DBCC INPUTBUFFER(<spid>)
to find the last statement that was submitted by a SPID (though I think your permissions might not be sufficient). If it's determined that the SPID is sleeping on the block, you'll still need to be promoted to a minimum role of processadmin in order to execute a KILL statement.
Three other recommendations to help you:
Work to implement the use of Locking Hints in code executed against the DB.
If this is a consistent problem, ask your DBA's to evaluate the statement(s) that cause the blocks, and ask their advice.
Getting close to your DBAs never hurts, and a little buttering up (pizza lunch, after-work drinks, etc.) once or twice can really make a difference. They may not grant you the permission promotion you need, but they could create a workaround for you as described here that could solve your problem without changing your role.
Use command for see connections sp_who then use command KILL <SPID>
if you are using ssms then try to close/save the editor window where you sp or query started running
ssms will ask you to commit the transaction just press ok
That's it!