Showing posts with label agent. Show all posts
Showing posts with label agent. Show all posts

Monday, March 26, 2012

principal to proxy problem

I can successfully execute my package via Business Studio but when I schedule it in SQL Agent I get the error message, 'could not get proxy data for proxy id = 2.' I am trying to execute the scheduled job with that proxy (call it abcd_proxy) because I have a logon id (call it abcd) with access to a specific network drive folder, which holds a required source flat file. The abcd logon is defined as a sysadmin account. I am unable to see that the abcd logon id is an added principal within the abcd_proxy, which I think is because the abcd logon principal has a sysadmin role. My proxy id = 2 definition looks to be defined the same way that my first proxy id was.

Does anyone have an idea about what the message means and how I can fix it?

I had to create a proxy recently to have an SSIS package write a file to a network folder. I am by no means an expert on the subject, but here is what I had to do.

I had to first create a windows account with the right credentials. I then created a credential, a proxy for the credential, and of course set the "Run As" parameter for the step to the proxy. I made sure that the new account was added as a sysadmin in SQL Server, added the account to the "Users" group on the server, as well as to the Logon as batch security policy. When I still had problems with the package being able to read a file it was related to the credentials of the account, which I had the network admin fix. Everything now runs fine.

I apologize if I have stated the obvious to you, but just wanted to share with you all the steps I had to take to perform a task very similar to what you are trying to do. Of course, I had to also use an "absolute" network path and not a mapped drive letter.

Hope this helps.

Friday, March 9, 2012

Primary File Group Full

Weird. I have an Agent job that populates some warehouse data every night. It's been working fine for over a year. Then it fails with a message that thePRIMARY file group is full. The database is set to Simple recovery, automatic, unrestricted growth by 10% for both the log file and the data file. The drive it's on has 96GB free. The data file is 1.5GB and the log is 2MB and there's not very much fluctuation in the amoutn of data going into it.

Anybody have an idea why that would happen?

Thanks for any insight,
Pete

You're probably timing out when it hits the autogrow. As ageneral rule, you should never rely on auto-growth! Instead, keepyour databases a lot bigger than you think you'll need. And setthe auto-grow rate to a very small amount (maybe 5-10 megs, some amountthat can grow within a few seconds). You have 96 GB free on thedrive -- why not set your databases to 10 or 20 GB?
And make sure you keep an eye on them. Keep growing them as they fill up.

|||

That's what I suspected since all the settings appear correct and the only activity in the job is just a huge number of inserts. I figured that at the point of needing to grow, there's a pile-up of inserts trying to happen. The problem with increasing the size significantly is that it's anything but the most important database on that server and I wouldn't want to limit the others just for this one. I can give it a little boost, though. Thanks for the help.

Pete

|||At the least, set a smaller auto-grow threshold so that it won't haveto wait -- it should take very little time to grow 5 or 10 megs. Note that this can contribute to fragmentation, which is why I suggestgrowing manually, in much larger chunks.