Tuesday, March 20, 2012

Scheduled jobs

Hello people.

I have an SQL 2000 Server which was handle to me today out of the blue
and i was told that it has the following problem:

The SQL Server has several jobs that get executed in regular intervals
to extract data (to a text file) and send them to a specific directory.
It has been seen that as of May 30th, these jobs, although they seem to
complete OK, they do not actually produce the expected output files.

We have executed the jobs manually, and again the files are not
created. We have executed the DTS packages associated with the jobs
manually, and the files WERE CREATED.

This problem is causing issues in production.

ny ideas what might be causing this strange behaviour?

thanksSee if it might be some type of permission related problem.

I have an SQL 2000 Server which was handle to me today out of the blue
and i was told that it has the following problem:

The SQL Server has several jobs that get executed in regular intervals
to extract data (to a text file) and send them to a specific directory.
It has been seen that as of May 30th, these jobs, although they seem to
complete OK, they do not actually produce the expected output files.

We have executed the jobs manually, and again the files are not
created. We have executed the DTS packages associated with the jobs
manually, and the files WERE CREATED.

This problem is causing issues in production.

ny ideas what might be causing this strange behaviour?|||When you run a DTS package manually, it runs under your user ID; it
also runs under the context of the machine from which you are running
the package (i.e., if you are running Enterprise Manager on your PC
desktop to manage a remote server, and you execute a DTS package on
that server from your desktop, all file references are pointing from
your machine, not the server). When you schedule a DTS package or run
a package as a job, the package runs under the context of the owner of
the job; if it is sa, then it will run as the Windows Service Account.

If your Service Account or owner of the scheduled job does not have the
same permissions on a file folder that the person running the package
manually has, the package will not work as expected.

Maybe that will help you narrow it down; if not, post back.

Stu|||Stu wrote:
> When you run a DTS package manually, it runs under your user ID; it
> also runs under the context of the machine from which you are running
> the package (i.e., if you are running Enterprise Manager on your PC
> desktop to manage a remote server, and you execute a DTS package on
> that server from your desktop, all file references are pointing from
> your machine, not the server). When you schedule a DTS package or run
> a package as a job, the package runs under the context of the owner of
> the job; if it is sa, then it will run as the Windows Service Account.
> If your Service Account or owner of the scheduled job does not have the
> same permissions on a file folder that the person running the package
> manually has, the package will not work as expected.
> Maybe that will help you narrow it down; if not, post back.

I'd also say, if it does help, post back. It's amazing the number of
times I'm hunting for help through Google Groups, find someone who
seems to have an identical problem to me, and there's no actual
resolution. i.e. Did the suggestions help them out?, Was their problem
something different to what they thought?, Have they managed to solve
the problem or work around it?, etc.

Damien|||Hello again! Thanks a lot for the responses!

The cause was found and it comes down to insufficient space of internal
disks of the server. There are two partitions C:\ and D:\. The files
which the DTS was exporting are place on D:\ which has a lot of free
space.

The C:\ drive although had zero free space!!!! Thus when the job was
running it was completing successfully but could not produce the file.
Isnt that misleading?

Thanks a lot again!

No comments:

Post a Comment