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
Showing posts with label box. Show all posts
Showing posts with label box. Show all posts
Thursday, March 29, 2012
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
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
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
Tuesday, March 27, 2012
Do I still need pagefile?
Hi,
If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
pagefile?
Thanks!
JohnAbsolutely, you must have a page file...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>|||Yes. Wayne is correct a page file is required. However, (assuming a 32 bit
version) you will be using PAE and AWE. With AWE the memory SQL Server will
all of the memory you defined to it apon startup and will not exceed that
amount. The only use of the page file should be any other applications
running on the server. You also need to have a page file big enough for
whatever kind of memory dump you need in case of a blue screen.
Danny
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>|||Wrong answer. Again, assuming this is a 32-bit platform, you can only store
data pages in the AWE mapped memory space, and, perhaps a few other trivial
items. Data pages, however, will be the bulk of that usage. That means all
of the other 4 memory managers, the active data pages, and the MEM TO LEAVE
area will all reside in the lower 2 GB of physical ram.
2 GB? Yes, if you have 16 GB or more, you MUST NOT USE the /3GB switch and
if you are on Win2K3, then you also want to use the /USERVA to scale the 3
GB back incrementaly from 3 GB to 2 GB starting around the 12 GB mark.
Now, what happens when you have cached procedures and new compile requests
come in? Most likely, you will flush old execution plans. Correct. Now,
what if the bulk of them are currently active? That's right, the free list
drops and eventually even SQL Server will start paging to the swap file;
that is, if it exists...right?
If you are needing the 16 GB of ram, seriously consider migrating to the
64-bit platform, the IA64 of course, where all the memory managers have use
of the entire memory segment.
Sincerely,
Anthony Thomas
"Danny" <someone@.nowhere.com> wrote in message
news:CcFme.6751$m%3.4525@.trnddc02...
Yes. Wayne is correct a page file is required. However, (assuming a 32 bit
version) you will be using PAE and AWE. With AWE the memory SQL Server will
all of the memory you defined to it apon startup and will not exceed that
amount. The only use of the page file should be any other applications
running on the server. You also need to have a page file big enough for
whatever kind of memory dump you need in case of a blue screen.
Danny
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>
If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
pagefile?
Thanks!
JohnAbsolutely, you must have a page file...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>|||Yes. Wayne is correct a page file is required. However, (assuming a 32 bit
version) you will be using PAE and AWE. With AWE the memory SQL Server will
all of the memory you defined to it apon startup and will not exceed that
amount. The only use of the page file should be any other applications
running on the server. You also need to have a page file big enough for
whatever kind of memory dump you need in case of a blue screen.
Danny
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>|||Wrong answer. Again, assuming this is a 32-bit platform, you can only store
data pages in the AWE mapped memory space, and, perhaps a few other trivial
items. Data pages, however, will be the bulk of that usage. That means all
of the other 4 memory managers, the active data pages, and the MEM TO LEAVE
area will all reside in the lower 2 GB of physical ram.
2 GB? Yes, if you have 16 GB or more, you MUST NOT USE the /3GB switch and
if you are on Win2K3, then you also want to use the /USERVA to scale the 3
GB back incrementaly from 3 GB to 2 GB starting around the 12 GB mark.
Now, what happens when you have cached procedures and new compile requests
come in? Most likely, you will flush old execution plans. Correct. Now,
what if the bulk of them are currently active? That's right, the free list
drops and eventually even SQL Server will start paging to the swap file;
that is, if it exists...right?
If you are needing the 16 GB of ram, seriously consider migrating to the
64-bit platform, the IA64 of course, where all the memory managers have use
of the entire memory segment.
Sincerely,
Anthony Thomas
"Danny" <someone@.nowhere.com> wrote in message
news:CcFme.6751$m%3.4525@.trnddc02...
Yes. Wayne is correct a page file is required. However, (assuming a 32 bit
version) you will be using PAE and AWE. With AWE the memory SQL Server will
all of the memory you defined to it apon startup and will not exceed that
amount. The only use of the page file should be any other applications
running on the server. You also need to have a page file big enough for
whatever kind of memory dump you need in case of a blue screen.
Danny
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>
Do I still need pagefile?
Hi,
If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
pagefile?
Thanks!
JohnAbsolutely, you must have a page file...
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>|||Yes. Wayne is correct a page file is required. However, (assuming a 32 bit
version) you will be using PAE and AWE. With AWE the memory SQL Server will
all of the memory you defined to it apon startup and will not exceed that
amount. The only use of the page file should be any other applications
running on the server. You also need to have a page file big enough for
whatever kind of memory dump you need in case of a blue screen.
Danny
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>|||Wrong answer. Again, assuming this is a 32-bit platform, you can only store
data pages in the AWE mapped memory space, and, perhaps a few other trivial
items. Data pages, however, will be the bulk of that usage. That means all
of the other 4 memory managers, the active data pages, and the MEM TO LEAVE
area will all reside in the lower 2 GB of physical ram.
2 GB? Yes, if you have 16 GB or more, you MUST NOT USE the /3GB switch and
if you are on Win2K3, then you also want to use the /USERVA to scale the 3
GB back incrementaly from 3 GB to 2 GB starting around the 12 GB mark.
Now, what happens when you have cached procedures and new compile requests
come in? Most likely, you will flush old execution plans. Correct. Now,
what if the bulk of them are currently active? That's right, the free list
drops and eventually even SQL Server will start paging to the swap file;
that is, if it exists...right?
If you are needing the 16 GB of ram, seriously consider migrating to the
64-bit platform, the IA64 of course, where all the memory managers have use
of the entire memory segment.
Sincerely,
Anthony Thomas
"Danny" <someone@.nowhere.com> wrote in message
news:CcFme.6751$m%3.4525@.trnddc02...
Yes. Wayne is correct a page file is required. However, (assuming a 32 bit
version) you will be using PAE and AWE. With AWE the memory SQL Server will
all of the memory you defined to it apon startup and will not exceed that
amount. The only use of the page file should be any other applications
running on the server. You also need to have a page file big enough for
whatever kind of memory dump you need in case of a blue screen.
Danny
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>
If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
pagefile?
Thanks!
JohnAbsolutely, you must have a page file...
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>|||Yes. Wayne is correct a page file is required. However, (assuming a 32 bit
version) you will be using PAE and AWE. With AWE the memory SQL Server will
all of the memory you defined to it apon startup and will not exceed that
amount. The only use of the page file should be any other applications
running on the server. You also need to have a page file big enough for
whatever kind of memory dump you need in case of a blue screen.
Danny
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>|||Wrong answer. Again, assuming this is a 32-bit platform, you can only store
data pages in the AWE mapped memory space, and, perhaps a few other trivial
items. Data pages, however, will be the bulk of that usage. That means all
of the other 4 memory managers, the active data pages, and the MEM TO LEAVE
area will all reside in the lower 2 GB of physical ram.
2 GB? Yes, if you have 16 GB or more, you MUST NOT USE the /3GB switch and
if you are on Win2K3, then you also want to use the /USERVA to scale the 3
GB back incrementaly from 3 GB to 2 GB starting around the 12 GB mark.
Now, what happens when you have cached procedures and new compile requests
come in? Most likely, you will flush old execution plans. Correct. Now,
what if the bulk of them are currently active? That's right, the free list
drops and eventually even SQL Server will start paging to the swap file;
that is, if it exists...right?
If you are needing the 16 GB of ram, seriously consider migrating to the
64-bit platform, the IA64 of course, where all the memory managers have use
of the entire memory segment.
Sincerely,
Anthony Thomas
"Danny" <someone@.nowhere.com> wrote in message
news:CcFme.6751$m%3.4525@.trnddc02...
Yes. Wayne is correct a page file is required. However, (assuming a 32 bit
version) you will be using PAE and AWE. With AWE the memory SQL Server will
all of the memory you defined to it apon startup and will not exceed that
amount. The only use of the page file should be any other applications
running on the server. You also need to have a page file big enough for
whatever kind of memory dump you need in case of a blue screen.
Danny
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>
Do I still need pagefile?
Hi,
If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
pagefile?
Thanks!
John
Absolutely, you must have a page file...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>
|||Yes. Wayne is correct a page file is required. However, (assuming a 32 bit
version) you will be using PAE and AWE. With AWE the memory SQL Server will
all of the memory you defined to it apon startup and will not exceed that
amount. The only use of the page file should be any other applications
running on the server. You also need to have a page file big enough for
whatever kind of memory dump you need in case of a blue screen.
Danny
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>
|||Wrong answer. Again, assuming this is a 32-bit platform, you can only store
data pages in the AWE mapped memory space, and, perhaps a few other trivial
items. Data pages, however, will be the bulk of that usage. That means all
of the other 4 memory managers, the active data pages, and the MEM TO LEAVE
area will all reside in the lower 2 GB of physical ram.
2 GB? Yes, if you have 16 GB or more, you MUST NOT USE the /3GB switch and
if you are on Win2K3, then you also want to use the /USERVA to scale the 3
GB back incrementaly from 3 GB to 2 GB starting around the 12 GB mark.
Now, what happens when you have cached procedures and new compile requests
come in? Most likely, you will flush old execution plans. Correct. Now,
what if the bulk of them are currently active? That's right, the free list
drops and eventually even SQL Server will start paging to the swap file;
that is, if it exists...right?
If you are needing the 16 GB of ram, seriously consider migrating to the
64-bit platform, the IA64 of course, where all the memory managers have use
of the entire memory segment.
Sincerely,
Anthony Thomas
"Danny" <someone@.nowhere.com> wrote in message
news:CcFme.6751$m%3.4525@.trnddc02...
Yes. Wayne is correct a page file is required. However, (assuming a 32 bit
version) you will be using PAE and AWE. With AWE the memory SQL Server will
all of the memory you defined to it apon startup and will not exceed that
amount. The only use of the page file should be any other applications
running on the server. You also need to have a page file big enough for
whatever kind of memory dump you need in case of a blue screen.
Danny
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>
If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
pagefile?
Thanks!
John
Absolutely, you must have a page file...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>
|||Yes. Wayne is correct a page file is required. However, (assuming a 32 bit
version) you will be using PAE and AWE. With AWE the memory SQL Server will
all of the memory you defined to it apon startup and will not exceed that
amount. The only use of the page file should be any other applications
running on the server. You also need to have a page file big enough for
whatever kind of memory dump you need in case of a blue screen.
Danny
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>
|||Wrong answer. Again, assuming this is a 32-bit platform, you can only store
data pages in the AWE mapped memory space, and, perhaps a few other trivial
items. Data pages, however, will be the bulk of that usage. That means all
of the other 4 memory managers, the active data pages, and the MEM TO LEAVE
area will all reside in the lower 2 GB of physical ram.
2 GB? Yes, if you have 16 GB or more, you MUST NOT USE the /3GB switch and
if you are on Win2K3, then you also want to use the /USERVA to scale the 3
GB back incrementaly from 3 GB to 2 GB starting around the 12 GB mark.
Now, what happens when you have cached procedures and new compile requests
come in? Most likely, you will flush old execution plans. Correct. Now,
what if the bulk of them are currently active? That's right, the free list
drops and eventually even SQL Server will start paging to the swap file;
that is, if it exists...right?
If you are needing the 16 GB of ram, seriously consider migrating to the
64-bit platform, the IA64 of course, where all the memory managers have use
of the entire memory segment.
Sincerely,
Anthony Thomas
"Danny" <someone@.nowhere.com> wrote in message
news:CcFme.6751$m%3.4525@.trnddc02...
Yes. Wayne is correct a page file is required. However, (assuming a 32 bit
version) you will be using PAE and AWE. With AWE the memory SQL Server will
all of the memory you defined to it apon startup and will not exceed that
amount. The only use of the page file should be any other applications
running on the server. You also need to have a page file big enough for
whatever kind of memory dump you need in case of a blue screen.
Danny
"John Lee" <johnl@.newsgroup.nospam> wrote in message
news:OOfwjpOZFHA.580@.TK2MSFTNGP15.phx.gbl...
> Hi,
> If I have 16GB RAM on my 4 CPU box for my SQL Server, do I still need
> pagefile?
> Thanks!
> John
>
Thursday, March 22, 2012
Do I have to install SQL Express?
I'm using the login/roles from Visual Studio 2005 in a website.
Is MS SQL Express mandatory? I already have MS SQL 2000 on the box. Is there any way to use that instead?
And if so, will I need to install MS SQL on the box I'm building the webiste on?
Thanks,
oilcan
You dont't have to have MS SQL 2005 express on your developer machine.
There is a build-in database schema behind the memebership function in ASP.NET 2.0. By default, if you have MS SQL 2005 express installed, you will get a database named as ASPNETDB.MDF installed under App_data folder in your application when you start using membership.
It would be easy to play with samples and test simple things. However, you need to know how to move this database to another database if you want to host your application somewhere. For example, SQL 2005 or SQL 2000.
You can mannuly install this database by using a tool in this location(most likely): C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regsql.exe
You can pick where you want to install this database from this tool's interface.
After you install this database, you need change your connection string to point to your new database which includes all tables from ASPNETDB.MDF
You may need to read through some articles from searching this topic about membership.
This is just a start and you will get there. If you have problems, you will easily get answers from here.
Enjoy the journey.
|||Any idea where I might find some of those articles you mentioned? I don't feel real comfortable just experimenting, it is a live web server.|||Hello there:
This article talks about how to merge this ASPNETDB.MDF to your database.
http://aspnet.4guysfromrolla.com/articles/040506-1.aspx
Please follow this article, you will bepretty close. I think you better to test on your developer machine before you move on.
Also I came across this one from DisccountASP forum to show users how to move the starter kits to their server. Just for you as a reference.
http://community.discountasp.net/default.aspx?f=25&m=8785
Let me know if I can help more.
Limno
Wednesday, March 7, 2012
Distrubuter has sick hardware. Need to change box.
We run our distribution on another server ie not on the publisher.
We have had some hardware errors and to be honest it's an old machine and
spares are getting sparse.
Is there a step by step for moving distribution to another server?
Thanks
Paul
The short answer is no. The longer answer is no there is not step by step
guide for moving a distributor to another server.
An even longer answer is, no, but it is possible to do a tape restore to the
new distributor with the same name bounce it and hope for the best. I don't
like remote distributors. DBAs IMHO are too quick to migrate to them, and
you need to cluster them otherwise you have a single point of failure which
can be problematic for you as you have discovered.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Paul Cahill" <noname@.anon.com> wrote in message
news:e6FVdryzFHA.2792@.tk2msftngp13.phx.gbl...
> We run our distribution on another server ie not on the publisher.
> We have had some hardware errors and to be honest it's an old machine and
> spares are getting sparse.
> Is there a step by step for moving distribution to another server?
> Thanks
> Paul
>
We have had some hardware errors and to be honest it's an old machine and
spares are getting sparse.
Is there a step by step for moving distribution to another server?
Thanks
Paul
The short answer is no. The longer answer is no there is not step by step
guide for moving a distributor to another server.
An even longer answer is, no, but it is possible to do a tape restore to the
new distributor with the same name bounce it and hope for the best. I don't
like remote distributors. DBAs IMHO are too quick to migrate to them, and
you need to cluster them otherwise you have a single point of failure which
can be problematic for you as you have discovered.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Paul Cahill" <noname@.anon.com> wrote in message
news:e6FVdryzFHA.2792@.tk2msftngp13.phx.gbl...
> We run our distribution on another server ie not on the publisher.
> We have had some hardware errors and to be honest it's an old machine and
> spares are getting sparse.
> Is there a step by step for moving distribution to another server?
> Thanks
> Paul
>
Saturday, February 25, 2012
distribution database SUSPECT - HELP! HELP!
We have SQL 2000 server replicate to another box.
I just found replication stopped! and distribution database was marked SUSPECT.
I am a SQL server newby, I checked sysdatabases table in master database and found
the status column is 280 and status2 is 1090519040.
Is there any way I can quickly recover this database and make replication moving?
Thanks in advance
David
David,
have a look in BOL for sp_resetstatus. Here is a brief synopsis:
"sp_resetstatus turns off the suspect flag on a database. This procedure
updates the mode and status columns of the named database in sysdatabases.
The SQL Server error log should be consulted and all problems resolved
before running this procedure. Stop and restart SQL Server after executing
sp_resetstatus.
A database can become suspect for several reasons. Possible causes include
denial of access to a database resource by the operating system, and the
unavailability or corruption of one or more database files."
Regards,
Paul Ibison
|||Thank you very much!
|||i m also in same case.
if u know pls let me know
- delwar
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
|||Delwar,
the main reason for this is faulty hardware - drive array etc. Sp_resetstatus will help if the MDF or LDF file for the database is not available during startup. If there's still an issue, start the database in Emergency mode, Update the Status column in
master..sysdatabases table for that database to 32768. After this database will be usable with out transaction log so you can create a new database and use DTS to transfer objects and data (thanks to Hari Prasad for this). DBCC CHECKDB with REPAIR_REBUIL
D can be used if there is still a problem, and after that it's a PSS call.
HTH,
Paul Ibison
I just found replication stopped! and distribution database was marked SUSPECT.
I am a SQL server newby, I checked sysdatabases table in master database and found
the status column is 280 and status2 is 1090519040.
Is there any way I can quickly recover this database and make replication moving?
Thanks in advance
David
David,
have a look in BOL for sp_resetstatus. Here is a brief synopsis:
"sp_resetstatus turns off the suspect flag on a database. This procedure
updates the mode and status columns of the named database in sysdatabases.
The SQL Server error log should be consulted and all problems resolved
before running this procedure. Stop and restart SQL Server after executing
sp_resetstatus.
A database can become suspect for several reasons. Possible causes include
denial of access to a database resource by the operating system, and the
unavailability or corruption of one or more database files."
Regards,
Paul Ibison
|||Thank you very much!
|||i m also in same case.
if u know pls let me know
- delwar
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
|||Delwar,
the main reason for this is faulty hardware - drive array etc. Sp_resetstatus will help if the MDF or LDF file for the database is not available during startup. If there's still an issue, start the database in Emergency mode, Update the Status column in
master..sysdatabases table for that database to 32768. After this database will be usable with out transaction log so you can create a new database and use DTS to transfer objects and data (thanks to Hari Prasad for this). DBCC CHECKDB with REPAIR_REBUIL
D can be used if there is still a problem, and after that it's a PSS call.
HTH,
Paul Ibison
Subscribe to:
Posts (Atom)