Hilary / Paul 2. questions.

1. I need to upgrade to sp3a on a distributor
that has about 40 publications to various
subscribers. I will be going from sql2k rtm to
sql2k sp3a. Are there any issues as far as
replication goes patching from rtm to sp3a? I
cannot afford to reinitilize any of these
publications.
2. Is there like a file size limit on using the
compress feature of a snapshot? I was able to
compress a 1gb table fine, but when I tried a
10gb one it always fails with a time out.
tia
-comb
btw, Hilary I just ordered your book for
45bucks.. hope it helps.
1. There are not issues that I am aware of. Your best bet is to stop all
agents, upgrade the distributor, then the publisher and then the
subscribers.
It is critical to upgrade the distributor and the publisher simultaneously.
The subscribers can wait.
2. You may need to restore your publication database on your subscriber and
then fix it up (ie NFR on all triggers, constraints, and identity columns).
Then do a nosync subscription and do a validation and try to sync any
discrepancies manually.
"Combfilter" <adsf@.asdf.com> wrote in message
news:MPG.1bf96d8fc0db9a09896dc@.news.newsreader.com ...
> 1. I need to upgrade to sp3a on a distributor
> that has about 40 publications to various
> subscribers. I will be going from sql2k rtm to
> sql2k sp3a. Are there any issues as far as
> replication goes patching from rtm to sp3a? I
> cannot afford to reinitilize any of these
> publications.
> 2. Is there like a file size limit on using the
> compress feature of a snapshot? I was able to
> compress a 1gb table fine, but when I tried a
> 10gb one it always fails with a time out.
> tia
> -comb
> btw, Hilary I just ordered your book for
> 45bucks.. hope it helps.
>
|||In article <eEcwkWfxEHA.748
@.TK2MSFTNGP14.phx.gbl>, hilary.cotter@.gmail.com
says...
Actually everyone is already at sp3a except the
dist. Pub and Sub are already sp3a. So I am
just going to do the distributor. I think that
should go on without a hitch right? I shouldn't
have to do anything to any of the db's on the
servers (pub/sub) that are already sp3a.
Do you have any websites or documentation that
explains how to do step 2. in a step by step
format?
Thanks for the info.

> 1. There are not issues that I am aware of. Your best bet is to stop all
> agents, upgrade the distributor, then the publisher and then the
> subscribers.
> It is critical to upgrade the distributor and the publisher simultaneously.
> The subscribers can wait.
> 2. You may need to restore your publication database on your subscriber and
> then fix it up (ie NFR on all triggers, constraints, and identity columns).
> Then do a nosync subscription and do a validation and try to sync any
> discrepancies manually.
>
> "Combfilter" <adsf@.asdf.com> wrote in message
> news:MPG.1bf96d8fc0db9a09896dc@.news.newsreader.com ...
>
>

High usage of RAM on SQL2k

Hi

I have an sql server with very high usage. The web which is connected to the sql server has approx. 1000 unique visitors every time.
The database is optimized and the site goes really fast now.

But a problem we've had since the beginning is that SQL Server constantly uses 1.8 GB of RAM. Never less, never more.

Do you have any idea on how to decrease the usage of RAM. I am sure that this high usage is necessary.check your logs,if they are more truncate them,
may be it helps you.|||But arent the log files truncated during the backup?|||Logs?

run sp_configure and tell me what the results are for min server memory.|||min server memory (MB) 0 2147483647 0 0

High Number of lock requests

We're running SQL2K over 2K server, there server just has one main database
besides the system' ones for our administration system
Recently we got a tool for monitoring the server and it's registered up to
5.500.000 lock requests/min, my point is, is that normal?It really depends on what you are doing but it sounds like you have a lot of
scans happening. Basically sounds like you are missing proper indexes and
reading too many rows when you select or modify.
--
Andrew J. Kelly SQL MVP
"FJC" <FJC@.discussions.microsoft.com> wrote in message
news:0F0E10B5-9D70-4EB1-AD64-0CA9480910DB@.microsoft.com...
> We're running SQL2K over 2K server, there server just has one main
> database
> besides the system' ones for our administration system
> Recently we got a tool for monitoring the server and it's registered up to
> 5.500.000 lock requests/min, my point is, is that normal?|||Thanks Andrew
I had a look at some of the tables and as you said it seems the developers
did not index the tables properly; I just set a couple of indexes and the
reads went down straight away.
Thanks
"Andrew J. Kelly" wrote:
> It really depends on what you are doing but it sounds like you have a lot of
> scans happening. Basically sounds like you are missing proper indexes and
> reading too many rows when you select or modify.
> --
> Andrew J. Kelly SQL MVP
>
> "FJC" <FJC@.discussions.microsoft.com> wrote in message
> news:0F0E10B5-9D70-4EB1-AD64-0CA9480910DB@.microsoft.com...
> > We're running SQL2K over 2K server, there server just has one main
> > database
> > besides the system' ones for our administration system
> > Recently we got a tool for monitoring the server and it's registered up to
> > 5.500.000 lock requests/min, my point is, is that normal?
>
>

High Number of lock requests

We're running SQL2K over 2K server, there server just has one main database
besides the system' ones for our administration system
Recently we got a tool for monitoring the server and it's registered up to
5.500.000 lock requests/min, my point is, is that normal?It really depends on what you are doing but it sounds like you have a lot of
scans happening. Basically sounds like you are missing proper indexes and
reading too many rows when you select or modify.
Andrew J. Kelly SQL MVP
"FJC" <FJC@.discussions.microsoft.com> wrote in message
news:0F0E10B5-9D70-4EB1-AD64-0CA9480910DB@.microsoft.com...
> We're running SQL2K over 2K server, there server just has one main
> database
> besides the system' ones for our administration system
> Recently we got a tool for monitoring the server and it's registered up to
> 5.500.000 lock requests/min, my point is, is that normal?|||Thanks Andrew
I had a look at some of the tables and as you said it seems the developers
did not index the tables properly; I just set a couple of indexes and the
reads went down straight away.
Thanks
"Andrew J. Kelly" wrote:

> It really depends on what you are doing but it sounds like you have a lot
of
> scans happening. Basically sounds like you are missing proper indexes and
> reading too many rows when you select or modify.
> --
> Andrew J. Kelly SQL MVP
>
> "FJC" <FJC@.discussions.microsoft.com> wrote in message
> news:0F0E10B5-9D70-4EB1-AD64-0CA9480910DB@.microsoft.com...
>
>sql

High Number of lock requests

We're running SQL2K over 2K server, there server just has one main database
besides the system' ones for our administration system
Recently we got a tool for monitoring the server and it's registered up to
5.500.000 lock requests/min, my point is, is that normal?
It really depends on what you are doing but it sounds like you have a lot of
scans happening. Basically sounds like you are missing proper indexes and
reading too many rows when you select or modify.
Andrew J. Kelly SQL MVP
"FJC" <FJC@.discussions.microsoft.com> wrote in message
news:0F0E10B5-9D70-4EB1-AD64-0CA9480910DB@.microsoft.com...
> We're running SQL2K over 2K server, there server just has one main
> database
> besides the system' ones for our administration system
> Recently we got a tool for monitoring the server and it's registered up to
> 5.500.000 lock requests/min, my point is, is that normal?
|||Thanks Andrew
I had a look at some of the tables and as you said it seems the developers
did not index the tables properly; I just set a couple of indexes and the
reads went down straight away.
Thanks
"Andrew J. Kelly" wrote:

> It really depends on what you are doing but it sounds like you have a lot of
> scans happening. Basically sounds like you are missing proper indexes and
> reading too many rows when you select or modify.
> --
> Andrew J. Kelly SQL MVP
>
> "FJC" <FJC@.discussions.microsoft.com> wrote in message
> news:0F0E10B5-9D70-4EB1-AD64-0CA9480910DB@.microsoft.com...
>
>

High CPU -- identify which query ties up cpu

Hello,
I'm running SQL2K enterprise, recently faced constant high cpu usage by
sqlsrvr process.
How can I identify which query or queries tie up cpu? I mean something more
precise and comprehensible than cpu column in sp_who2.
thanks for any help,
Gary.Gary
I'd run SQL Server profiler to identify long running queries , there are
some events liek CPU,Duration and then try to speed them up
http://www.sql-server-performance.c...or_counters.asp
http://www.sql-server-performance.c...counters_io.asp
"Gary" <Gary@.discussions.microsoft.com> wrote in message
news:5079326B-B881-4728-B042-0448C1105D71@.microsoft.com...
> Hello,
> I'm running SQL2K enterprise, recently faced constant high cpu usage by
> sqlsrvr process.
> How can I identify which query or queries tie up cpu? I mean something
> more
> precise and comprehensible than cpu column in sp_who2.
> thanks for any help,
> Gary.

High CPU -- identify which query ties up cpu

Hello,
I'm running SQL2K enterprise, recently faced constant high cpu usage by
sqlsrvr process.
How can I identify which query or queries tie up cpu? I mean something more
precise and comprehensible than cpu column in sp_who2.
thanks for any help,
Gary.Gary
I'd run SQL Server profiler to identify long running queries , there are
some events liek CPU,Duration and then try to speed them up
http://www.sql-server-performance.com/performance_monitor_counters.asp
http://www.sql-server-performance.com/performance_monitor_counters_io.asp
"Gary" <Gary@.discussions.microsoft.com> wrote in message
news:5079326B-B881-4728-B042-0448C1105D71@.microsoft.com...
> Hello,
> I'm running SQL2K enterprise, recently faced constant high cpu usage by
> sqlsrvr process.
> How can I identify which query or queries tie up cpu? I mean something
> more
> precise and comprehensible than cpu column in sp_who2.
> thanks for any help,
> Gary.