Do scheduled jobs stay in memory?

My boss was looking at our SQL box, comparing the jobs list to the running
processes list. He noticed that the numbers are roughly analogous to each
other. He posed me the question, "do scheduled jobs stay in memory, or do
they release themselves when complete?"
I'm pretty sure the answer is that they release themselves, but I figured I
would bow to somebody from this group who had much more knowledge of the
matter.
Regards,
Scott
i don't know exactly what numbers you see in the job list.
if a job is running, you will see it in "current activity - process info"
to answer his question, more than likely that job (or at least pieces of it)
will stay in memory
some of its code may stay in the procedure cache.
some of its data may stay in the buffer cache.
sql server generally tries to keep everything in memory and only releases
things when it feels it's necessary.
Scott McNair wrote:

> My boss was looking at our SQL box, comparing the jobs list to the running
> processes list. He noticed that the numbers are roughly analogous to each
> other. He posed me the question, "do scheduled jobs stay in memory, or do
> they release themselves when complete?"
> I'm pretty sure the answer is that they release themselves, but I figured I
> would bow to somebody from this group who had much more knowledge of the
> matter.
> Regards,
> Scott
|||Scott,
if you look at the "current activity" in EM under Management, in Process
Info you will find the process running. You can find that when the jobs are
not running, you will not have processes related to the jobs. Yes, when a
job finishes, it releases itself.
A task (a job, a QA query etc) can possibly spin off multiple processes, so
you may have more processes then your currently running task. This might be
the reason that you sometimes see a relation between the number of processes
and processes, but that is completely coincidental.
Quentin
"Scott McNair" <scott.mcnair@.sfmco.takethispartout.com> wrote in message
news:Xns94E688FF6C32Asfmco@.207.46.248.16...
> My boss was looking at our SQL box, comparing the jobs list to the running
> processes list. He noticed that the numbers are roughly analogous to each
> other. He posed me the question, "do scheduled jobs stay in memory, or do
> they release themselves when complete?"
> I'm pretty sure the answer is that they release themselves, but I figured
I
> would bow to somebody from this group who had much more knowledge of the
> matter.
> Regards,
> Scott

Do scheduled jobs stay in memory?

My boss was looking at our SQL box, comparing the jobs list to the running
processes list. He noticed that the numbers are roughly analogous to each
other. He posed me the question, "do scheduled jobs stay in memory, or do
they release themselves when complete?"
I'm pretty sure the answer is that they release themselves, but I figured I
would bow to somebody from this group who had much more knowledge of the
matter.
Regards,
Scotti don't know exactly what numbers you see in the job list.
if a job is running, you will see it in "current activity - process info"
to answer his question, more than likely that job (or at least pieces of it)
will stay in memory
some of its code may stay in the procedure cache.
some of its data may stay in the buffer cache.
sql server generally tries to keep everything in memory and only releases
things when it feels it's necessary.
Scott McNair wrote:
> My boss was looking at our SQL box, comparing the jobs list to the running
> processes list. He noticed that the numbers are roughly analogous to each
> other. He posed me the question, "do scheduled jobs stay in memory, or do
> they release themselves when complete?"
> I'm pretty sure the answer is that they release themselves, but I figured I
> would bow to somebody from this group who had much more knowledge of the
> matter.
> Regards,
> Scott|||Scott,
if you look at the "current activity" in EM under Management, in Process
Info you will find the process running. You can find that when the jobs are
not running, you will not have processes related to the jobs. Yes, when a
job finishes, it releases itself.
A task (a job, a QA query etc) can possibly spin off multiple processes, so
you may have more processes then your currently running task. This might be
the reason that you sometimes see a relation between the number of processes
and processes, but that is completely coincidental.
Quentin
"Scott McNair" <scott.mcnair@.sfmco.takethispartout.com> wrote in message
news:Xns94E688FF6C32Asfmco@.207.46.248.16...
> My boss was looking at our SQL box, comparing the jobs list to the running
> processes list. He noticed that the numbers are roughly analogous to each
> other. He posed me the question, "do scheduled jobs stay in memory, or do
> they release themselves when complete?"
> I'm pretty sure the answer is that they release themselves, but I figured
I
> would bow to somebody from this group who had much more knowledge of the
> matter.
> Regards,
> Scott

Do scheduled jobs stay in memory?

My boss was looking at our SQL box, comparing the jobs list to the running
processes list. He noticed that the numbers are roughly analogous to each
other. He posed me the question, "do scheduled jobs stay in memory, or do
they release themselves when complete?"
I'm pretty sure the answer is that they release themselves, but I figured I
would bow to somebody from this group who had much more knowledge of the
matter.
Regards,
Scotti don't know exactly what numbers you see in the job list.
if a job is running, you will see it in "current activity - process info"
to answer his question, more than likely that job (or at least pieces of it)
will stay in memory
some of its code may stay in the procedure cache.
some of its data may stay in the buffer cache.
sql server generally tries to keep everything in memory and only releases
things when it feels it's necessary.
Scott McNair wrote:

> My boss was looking at our SQL box, comparing the jobs list to the running
> processes list. He noticed that the numbers are roughly analogous to each
> other. He posed me the question, "do scheduled jobs stay in memory, or do
> they release themselves when complete?"
> I'm pretty sure the answer is that they release themselves, but I figured
I
> would bow to somebody from this group who had much more knowledge of the
> matter.
> Regards,
> Scott|||Scott,
if you look at the "current activity" in EM under Management, in Process
Info you will find the process running. You can find that when the jobs are
not running, you will not have processes related to the jobs. Yes, when a
job finishes, it releases itself.
A task (a job, a QA query etc) can possibly spin off multiple processes, so
you may have more processes then your currently running task. This might be
the reason that you sometimes see a relation between the number of processes
and processes, but that is completely coincidental.
Quentin
"Scott McNair" <scott.mcnair@.sfmco.takethispartout.com> wrote in message
news:Xns94E688FF6C32Asfmco@.207.46.248.16...
> My boss was looking at our SQL box, comparing the jobs list to the running
> processes list. He noticed that the numbers are roughly analogous to each
> other. He posed me the question, "do scheduled jobs stay in memory, or do
> they release themselves when complete?"
> I'm pretty sure the answer is that they release themselves, but I figured
I
> would bow to somebody from this group who had much more knowledge of the
> matter.
> Regards,
> Scott

Do I trust what my SMS agents are telling me?

This XML update that was originally released Oct 10th and then updated Oct
19th has got me .
I have roughly 600 SMS clients, 150 of which would be XP machines and 450
Windows 2000.
Right now I have a little over 400 SMS clients (a mix of XP and 2000)
requesting 924191 which SMS describes as a Security update for Windows (but
updates the XML parser and Core Services), and another 532 clients
requesting 925672, described as MSXML4.0 SP2 Security update.
Obviously, I've got a lot of clients requesting both (or requesting the same
update under two different names'). Is this simply because they have
multiple versions of these XML components on their machines, all of which
need updating? These updates aren't going to stomp on each other? Should I
be deploying both?
Advice for an SMS admin (not an XML guy) appreciated.
SMS 2003 SP1 on W2K3 SP1> Obviously, I've got a lot of clients requesting both (or requesting the
> same update under two different names').
The update released for MSXML3 was seperate from the update released for
MSXML4, even though the issue that each of these updates fixed was the same.

> Is this simply because they have multiple versions of these XML components
> on their machines, all of which need updating?
Yes

>These updates aren't going to stomp on each other? Should I be deploying
>both?
No they are not going to stomp on each other, yes, deploy both.
"Phil McNeill" <philmcneill@.NOSPAM4MEhydroottawa.com> wrote in message
news:uhwgP$G%23GHA.1224@.TK2MSFTNGP04.phx.gbl...
> This XML update that was originally released Oct 10th and then updated Oct
> 19th has got me .
> I have roughly 600 SMS clients, 150 of which would be XP machines and 450
> Windows 2000.
> Right now I have a little over 400 SMS clients (a mix of XP and 2000)
> requesting 924191 which SMS describes as a Security update for Windows
> (but updates the XML parser and Core Services), and another 532 clients
> requesting 925672, described as MSXML4.0 SP2 Security update.
> Obviously, I've got a lot of clients requesting both (or requesting the
> same update under two different names'). Is this simply because they
> have multiple versions of these XML components on their machines, all of
> which need updating? These updates aren't going to stomp on each other?
> Should I be deploying both?
> Advice for an SMS admin (not an XML guy) appreciated.
> SMS 2003 SP1 on W2K3 SP1
>
>|||Thanks for the reply Alex. I was fairly sure that was the case, but already
deployed to my test group prior to the Oct 19th update that added updates
for Windows 2000. I'll deploy the additional updates to that group and see
how it goes.
Thanks again,
Phil
"Alex Krawarik[MSFT]" <alexkr@.microsoft.com> wrote in message
news:eC2DC0I%23GHA.3456@.TK2MSFTNGP02.phx.gbl...
> The update released for MSXML3 was seperate from the update released for
> MSXML4, even though the issue that each of these updates fixed was the
> same.
>
> Yes
>
> No they are not going to stomp on each other, yes, deploy both.
>