Showing posts with label upgraded. Show all posts
Showing posts with label upgraded. Show all posts

Wednesday, March 28, 2012

I/O issues after SP4 upgrade

Hi,
We have upgraded 3 of our SQL Servers to SP4 in the past 2 weeks. We
monitor these servers with Veritas, and we have noticed that all 3 servers
have shown a marked increase (around 4x) in Disk Sec/Transfer, Disk
Sec/Write, and Disk Queue Length.
For example, on one server, Disk Writes and Disk Transfers were taking on
average 7 ms to complete (with SP3a). Post-SP4, they are taking
approximately 30 ms on average. The queue length has jumped from around 3
to about 15. [I know the avg disk queue length was a bit high to start
with - we are working with our SAN vendor to get this figured out]
Queries are still executing in about the same time, CPU utilization is about
the same, and we see no other negative effects. But we're wondering why the
I/O is so much worse than when we were running SP3a. We changed nothing
besides moving to SP4. And we did install the post-SP4 AWE patch as well.
Has anyone run into this before or know of any articles that touch on
possible causes?
--
Regards,
Jake Marx
www.longhead.com
[please keep replies in the newsgroup - email address unmonitored]Have the query plans changed? Is the increased I/O due to more table scans?
Did you run sp_updatestats?
--
Andrew J. Kelly SQL MVP
"Jake Marx" <msnews@.longhead.com> wrote in message
news:OM%23R2MCVGHA.4348@.TK2MSFTNGP09.phx.gbl...
> Hi,
> We have upgraded 3 of our SQL Servers to SP4 in the past 2 weeks. We
> monitor these servers with Veritas, and we have noticed that all 3 servers
> have shown a marked increase (around 4x) in Disk Sec/Transfer, Disk
> Sec/Write, and Disk Queue Length.
> For example, on one server, Disk Writes and Disk Transfers were taking on
> average 7 ms to complete (with SP3a). Post-SP4, they are taking
> approximately 30 ms on average. The queue length has jumped from around 3
> to about 15. [I know the avg disk queue length was a bit high to start
> with - we are working with our SAN vendor to get this figured out]
> Queries are still executing in about the same time, CPU utilization is
> about the same, and we see no other negative effects. But we're wondering
> why the I/O is so much worse than when we were running SP3a. We changed
> nothing besides moving to SP4. And we did install the post-SP4 AWE patch
> as well. Has anyone run into this before or know of any articles that
> touch on possible causes?
> --
> Regards,
> Jake Marx
> www.longhead.com
>
> [please keep replies in the newsgroup - email address unmonitored]
>|||Hi Andrew,
Andrew J. Kelly wrote:
> Have the query plans changed? Is the increased I/O due to more table
> scans? Did you run sp_updatestats?
Thanks for the suggestions. I did not run sp_updatestats - I just did it on
one of the less-busy servers to see if it makes a difference. The query
plans are not different from what I have seen so far, but I will keep
looking. Table scans have come down a bit since upgrading to SP4.
The strange thing (to me) is that overall I/O activity is about the same;
reads/writes per sec is pretty constant. It's just the duration of each I/O
operation and the disk queue length that went up. And this happened only on
the data drive - the trans log and local (tempdb) drives' queue lengths
actually decreased.
--
Regards,
Jake Marx
www.longhead.com
[please keep replies in the newsgroup - email address unmonitored]
>> We have upgraded 3 of our SQL Servers to SP4 in the past 2 weeks. We
>> monitor these servers with Veritas, and we have noticed that all 3
>> servers have shown a marked increase (around 4x) in Disk
>> Sec/Transfer, Disk Sec/Write, and Disk Queue Length.
>> For example, on one server, Disk Writes and Disk Transfers were
>> taking on average 7 ms to complete (with SP3a). Post-SP4, they are
>> taking approximately 30 ms on average. The queue length has jumped
>> from around 3 to about 15. [I know the avg disk queue length was a
>> bit high to start with - we are working with our SAN vendor to get
>> this figured out] Queries are still executing in about the same time, CPU
>> utilization
>> is about the same, and we see no other negative effects. But we're
>> wondering why the I/O is so much worse than when we were running
>> SP3a. We changed nothing besides moving to SP4. And we did install
>> the post-SP4 AWE patch as well. Has anyone run into this before or
>> know of any articles that touch on possible causes?|||There should be very few table scans if they are optimized properly
regardless of the SP. I haven't seen anything yet that indicates SP4 itself
caused increased I/O times but anything is possible. Any chance you were
monitoring fn_virtualfilestats() before and after? If so do you notice
increased bytes read or written or just increased IOStallms?
--
Andrew J. Kelly SQL MVP
"Jake Marx" <msnews@.longhead.com> wrote in message
news:%23KCJtvNVGHA.4764@.TK2MSFTNGP10.phx.gbl...
> Hi Andrew,
> Andrew J. Kelly wrote:
>> Have the query plans changed? Is the increased I/O due to more table
>> scans? Did you run sp_updatestats?
> Thanks for the suggestions. I did not run sp_updatestats - I just did it
> on one of the less-busy servers to see if it makes a difference. The
> query plans are not different from what I have seen so far, but I will
> keep looking. Table scans have come down a bit since upgrading to SP4.
> The strange thing (to me) is that overall I/O activity is about the same;
> reads/writes per sec is pretty constant. It's just the duration of each
> I/O operation and the disk queue length that went up. And this happened
> only on the data drive - the trans log and local (tempdb) drives' queue
> lengths actually decreased.
> --
> Regards,
> Jake Marx
> www.longhead.com
>
> [please keep replies in the newsgroup - email address unmonitored]
>
>> We have upgraded 3 of our SQL Servers to SP4 in the past 2 weeks. We
>> monitor these servers with Veritas, and we have noticed that all 3
>> servers have shown a marked increase (around 4x) in Disk
>> Sec/Transfer, Disk Sec/Write, and Disk Queue Length.
>> For example, on one server, Disk Writes and Disk Transfers were
>> taking on average 7 ms to complete (with SP3a). Post-SP4, they are
>> taking approximately 30 ms on average. The queue length has jumped
>> from around 3 to about 15. [I know the avg disk queue length was a
>> bit high to start with - we are working with our SAN vendor to get
>> this figured out] Queries are still executing in about the same time,
>> CPU utilization
>> is about the same, and we see no other negative effects. But we're
>> wondering why the I/O is so much worse than when we were running
>> SP3a. We changed nothing besides moving to SP4. And we did install
>> the post-SP4 AWE patch as well. Has anyone run into this before or
>> know of any articles that touch on possible causes?
>|||Hi Andrew,
Andrew J. Kelly wrote:
> There should be very few table scans if they are optimized properly
> regardless of the SP. I haven't seen anything yet that indicates SP4
> itself caused increased I/O times but anything is possible. Any
> chance you were monitoring fn_virtualfilestats() before and after? If so
> do you notice increased bytes read or written or just increased
> IOStallms?
Most of the table/index scans are on very small tables (some of which are
heaps). There aren't any table scans on larger tables, and there are very
few index scans on larger tables (we're working on removing those as we
can). Full scans/sec seem to hover around 3. We have several hundred
concurrent users on this db.
No, I haven't used fn_virtualfilestats() before. Just ran it, and it seems
useful - thanks for the tip. IoStallMS / NumberReads + NumberWrites) is
less than 6 for all files, so that seems OK based on the documentation I've
seen.
--
Regards,
Jake Marx
www.longhead.com
[please keep replies in the newsgroup - email address unmonitored]
>> Andrew J. Kelly wrote:
>> Have the query plans changed? Is the increased I/O due to more
>> table scans? Did you run sp_updatestats?
>> Thanks for the suggestions. I did not run sp_updatestats - I just
>> did it on one of the less-busy servers to see if it makes a
>> difference. The query plans are not different from what I have seen
>> so far, but I will keep looking. Table scans have come down a bit
>> since upgrading to SP4. The strange thing (to me) is that overall I/O
>> activity is about the
>> same; reads/writes per sec is pretty constant. It's just the
>> duration of each I/O operation and the disk queue length that went
>> up. And this happened only on the data drive - the trans log and
>> local (tempdb) drives' queue lengths actually decreased.
>> --
>> Regards,
>> Jake Marx
>> www.longhead.com
>>
>> [please keep replies in the newsgroup - email address unmonitored]
>>
>> We have upgraded 3 of our SQL Servers to SP4 in the past 2 weeks. We
>> monitor these servers with Veritas, and we have noticed that
>> all 3 servers have shown a marked increase (around 4x) in Disk
>> Sec/Transfer, Disk Sec/Write, and Disk Queue Length.
>> For example, on one server, Disk Writes and Disk Transfers were
>> taking on average 7 ms to complete (with SP3a). Post-SP4, they are
>> taking approximately 30 ms on average. The queue length has jumped
>> from around 3 to about 15. [I know the avg disk queue length was a
>> bit high to start with - we are working with our SAN vendor to get
>> this figured out] Queries are still executing in about the same
>> time, CPU utilization
>> is about the same, and we see no other negative effects. But we're
>> wondering why the I/O is so much worse than when we were running
>> SP3a. We changed nothing besides moving to SP4. And we did
>> install the post-SP4 AWE patch as well. Has anyone run into this
>> before or know of any articles that touch on possible causes?|||The filestats will let you know if you are actually reading / writing more
data or simply getting increased access times with the same data.
--
Andrew J. Kelly SQL MVP
"Jake Marx" <msnews@.longhead.com> wrote in message
news:eTDfwOOVGHA.4864@.TK2MSFTNGP12.phx.gbl...
> Hi Andrew,
> Andrew J. Kelly wrote:
>> There should be very few table scans if they are optimized properly
>> regardless of the SP. I haven't seen anything yet that indicates SP4
>> itself caused increased I/O times but anything is possible. Any
>> chance you were monitoring fn_virtualfilestats() before and after? If so
>> do you notice increased bytes read or written or just increased
>> IOStallms?
> Most of the table/index scans are on very small tables (some of which are
> heaps). There aren't any table scans on larger tables, and there are very
> few index scans on larger tables (we're working on removing those as we
> can). Full scans/sec seem to hover around 3. We have several hundred
> concurrent users on this db.
> No, I haven't used fn_virtualfilestats() before. Just ran it, and it
> seems useful - thanks for the tip. IoStallMS / NumberReads +
> NumberWrites) is less than 6 for all files, so that seems OK based on the
> documentation I've seen.
> --
> Regards,
> Jake Marx
> www.longhead.com
>
> [please keep replies in the newsgroup - email address unmonitored]
>> Andrew J. Kelly wrote:
>> Have the query plans changed? Is the increased I/O due to more
>> table scans? Did you run sp_updatestats?
>> Thanks for the suggestions. I did not run sp_updatestats - I just
>> did it on one of the less-busy servers to see if it makes a
>> difference. The query plans are not different from what I have seen
>> so far, but I will keep looking. Table scans have come down a bit
>> since upgrading to SP4. The strange thing (to me) is that overall I/O
>> activity is about the
>> same; reads/writes per sec is pretty constant. It's just the
>> duration of each I/O operation and the disk queue length that went
>> up. And this happened only on the data drive - the trans log and
>> local (tempdb) drives' queue lengths actually decreased.
>> --
>> Regards,
>> Jake Marx
>> www.longhead.com
>>
>> [please keep replies in the newsgroup - email address unmonitored]
>>
>> We have upgraded 3 of our SQL Servers to SP4 in the past 2 weeks. We
>> monitor these servers with Veritas, and we have noticed that
>> all 3 servers have shown a marked increase (around 4x) in Disk
>> Sec/Transfer, Disk Sec/Write, and Disk Queue Length.
>> For example, on one server, Disk Writes and Disk Transfers were
>> taking on average 7 ms to complete (with SP3a). Post-SP4, they are
>> taking approximately 30 ms on average. The queue length has jumped
>> from around 3 to about 15. [I know the avg disk queue length was a
>> bit high to start with - we are working with our SAN vendor to get
>> this figured out] Queries are still executing in about the same
>> time, CPU utilization
>> is about the same, and we see no other negative effects. But we're
>> wondering why the I/O is so much worse than when we were running
>> SP3a. We changed nothing besides moving to SP4. And we did
>> install the post-SP4 AWE patch as well. Has anyone run into this
>> before or know of any articles that touch on possible causes?
>|||Hi Andrew,
Andrew J. Kelly wrote:
> The filestats will let you know if you are actually reading / writing
> more data or simply getting increased access times with the same data.
Thanks. According to perfmon before and after SP4 installation, the I/O
load is about the same now as it was then (approx the same # of writes/sec
and reads/sec) - it's just the sec/write and sec/transfer (along with the
disk queue length) that are higher.
I'm not sure what else to look at. I know that SP4 reports I/O
latching/locking differently than SP3a, but that shouldn't affect perfmon OS
stats, right? I'd imagine those are collected directly by the disk
subsystem and that SQL would have nothing to do with that collection...
Thanks again for your help. I'm going through all the query plans now to
make sure nothing has changed.
--
Regards,
Jake Marx
www.longhead.com
[please keep replies in the newsgroup - email address unmonitored]
>> Andrew J. Kelly wrote:
>> There should be very few table scans if they are optimized properly
>> regardless of the SP. I haven't seen anything yet that indicates
>> SP4 itself caused increased I/O times but anything is possible. Any
>> chance you were monitoring fn_virtualfilestats() before and after?
>> If so do you notice increased bytes read or written or just
>> increased IOStallms?
>> Most of the table/index scans are on very small tables (some of
>> which are heaps). There aren't any table scans on larger tables,
>> and there are very few index scans on larger tables (we're working
>> on removing those as we can). Full scans/sec seem to hover around
>> 3. We have several hundred concurrent users on this db.
>> No, I haven't used fn_virtualfilestats() before. Just ran it, and it
>> seems useful - thanks for the tip. IoStallMS / NumberReads +
>> NumberWrites) is less than 6 for all files, so that seems OK based
>> on the documentation I've seen.
>>
>> Andrew J. Kelly wrote:
>> Have the query plans changed? Is the increased I/O due to more
>> table scans? Did you run sp_updatestats?
>> Thanks for the suggestions. I did not run sp_updatestats - I just
>> did it on one of the less-busy servers to see if it makes a
>> difference. The query plans are not different from what I have
>> seen so far, but I will keep looking. Table scans have come down
>> a bit since upgrading to SP4. The strange thing (to me) is that
>> overall I/O activity is about the
>> same; reads/writes per sec is pretty constant. It's just the
>> duration of each I/O operation and the disk queue length that went
>> up. And this happened only on the data drive - the trans log and
>> local (tempdb) drives' queue lengths actually decreased.
>> We have upgraded 3 of our SQL Servers to SP4 in the past 2
>> weeks. We monitor these servers with Veritas, and we have
>> noticed that all 3 servers have shown a marked increase (around 4x)
>> in Disk
>> Sec/Transfer, Disk Sec/Write, and Disk Queue Length.
>> For example, on one server, Disk Writes and Disk Transfers were
>> taking on average 7 ms to complete (with SP3a). Post-SP4, they
>> are taking approximately 30 ms on average. The queue length has
>> jumped from around 3 to about 15. [I know the avg disk queue
>> length was a bit high to start with - we are working with our
>> SAN vendor to get this figured out] Queries are still executing
>> in about the same time, CPU utilization
>> is about the same, and we see no other negative effects. But
>> we're wondering why the I/O is so much worse than when we were
>> running SP3a. We changed nothing besides moving to SP4. And we
>> did install the post-SP4 AWE patch as well. Has anyone run into
>> this before or know of any articles that touch on possible
>> causes?|||The sp should not affect perfmon stats for I/O. Are you sure there wasn't
anything else done around that same timeframe that may have affected this?
Any changes to the SAN or the OS? I wish I could offer something better
than that but this is not something I have heard happening to others upon
adding SP4 (or any service pack for that matter).
--
Andrew J. Kelly SQL MVP
"Jake Marx" <msnews@.longhead.com> wrote in message
news:u7lZo02VGHA.4724@.TK2MSFTNGP09.phx.gbl...
> Hi Andrew,
> Andrew J. Kelly wrote:
>> The filestats will let you know if you are actually reading / writing
>> more data or simply getting increased access times with the same data.
> Thanks. According to perfmon before and after SP4 installation, the I/O
> load is about the same now as it was then (approx the same # of writes/sec
> and reads/sec) - it's just the sec/write and sec/transfer (along with the
> disk queue length) that are higher.
> I'm not sure what else to look at. I know that SP4 reports I/O
> latching/locking differently than SP3a, but that shouldn't affect perfmon
> OS stats, right? I'd imagine those are collected directly by the disk
> subsystem and that SQL would have nothing to do with that collection...
> Thanks again for your help. I'm going through all the query plans now to
> make sure nothing has changed.
> --
> Regards,
> Jake Marx
> www.longhead.com
>
> [please keep replies in the newsgroup - email address unmonitored]
>> Andrew J. Kelly wrote:
>> There should be very few table scans if they are optimized properly
>> regardless of the SP. I haven't seen anything yet that indicates
>> SP4 itself caused increased I/O times but anything is possible. Any
>> chance you were monitoring fn_virtualfilestats() before and after?
>> If so do you notice increased bytes read or written or just
>> increased IOStallms?
>> Most of the table/index scans are on very small tables (some of
>> which are heaps). There aren't any table scans on larger tables,
>> and there are very few index scans on larger tables (we're working
>> on removing those as we can). Full scans/sec seem to hover around
>> 3. We have several hundred concurrent users on this db.
>> No, I haven't used fn_virtualfilestats() before. Just ran it, and it
>> seems useful - thanks for the tip. IoStallMS / NumberReads +
>> NumberWrites) is less than 6 for all files, so that seems OK based
>> on the documentation I've seen.
>>
>> Andrew J. Kelly wrote:
>> Have the query plans changed? Is the increased I/O due to more
>> table scans? Did you run sp_updatestats?
>> Thanks for the suggestions. I did not run sp_updatestats - I just
>> did it on one of the less-busy servers to see if it makes a
>> difference. The query plans are not different from what I have
>> seen so far, but I will keep looking. Table scans have come down
>> a bit since upgrading to SP4. The strange thing (to me) is that
>> overall I/O activity is about the
>> same; reads/writes per sec is pretty constant. It's just the
>> duration of each I/O operation and the disk queue length that went
>> up. And this happened only on the data drive - the trans log and
>> local (tempdb) drives' queue lengths actually decreased.
>>> We have upgraded 3 of our SQL Servers to SP4 in the past 2
>>> weeks. We monitor these servers with Veritas, and we have
>>> noticed that all 3 servers have shown a marked increase (around 4x)
>>> in Disk
>>> Sec/Transfer, Disk Sec/Write, and Disk Queue Length.
>>>
>>> For example, on one server, Disk Writes and Disk Transfers were
>>> taking on average 7 ms to complete (with SP3a). Post-SP4, they
>>> are taking approximately 30 ms on average. The queue length has
>>> jumped from around 3 to about 15. [I know the avg disk queue
>>> length was a bit high to start with - we are working with our
>>> SAN vendor to get this figured out] Queries are still executing
>>> in about the same time, CPU utilization
>>> is about the same, and we see no other negative effects. But
>>> we're wondering why the I/O is so much worse than when we were
>>> running SP3a. We changed nothing besides moving to SP4. And we
>>> did install the post-SP4 AWE patch as well. Has anyone run into
>>> this before or know of any articles that touch on possible
>>> causes?
>|||Hi Andrew,
Andrew J. Kelly wrote:
> The sp should not affect perfmon stats for I/O. Are you sure there
> wasn't anything else done around that same timeframe that may have
> affected this? Any changes to the SAN or the OS? I wish I could
> offer something better than that but this is not something I have
> heard happening to others upon adding SP4 (or any service pack for
> that matter).
I know - that's why I find this so strange. I would think that maybe we had
done something else at the same time, but we have done the SP4 upgrade on
three separate servers at three separate times, and we see the increase in
perfmon I/O stats on each server beginning with the time we upgraded each
one. We are using an EMC Celerra over iSCSI for the data and log files on
all three servers, so maybe SP4 changed something in that respect? I
wouldn't think so. (?)
Thanks again for all of your help!
--
Regards,
Jake
>> Andrew J. Kelly wrote:
>> The filestats will let you know if you are actually reading /
>> writing more data or simply getting increased access times with the
>> same data.
>> Thanks. According to perfmon before and after SP4 installation, the
>> I/O load is about the same now as it was then (approx the same # of
>> writes/sec and reads/sec) - it's just the sec/write and sec/transfer
>> (along with the disk queue length) that are higher.
>> I'm not sure what else to look at. I know that SP4 reports I/O
>> latching/locking differently than SP3a, but that shouldn't affect
>> perfmon OS stats, right? I'd imagine those are collected directly
>> by the disk subsystem and that SQL would have nothing to do with
>> that collection... Thanks again for your help. I'm going through all
>> the query plans
>> now to make sure nothing has changed.
>> Andrew J. Kelly wrote:
>> There should be very few table scans if they are optimized
>> properly regardless of the SP. I haven't seen anything yet that
>> indicates SP4 itself caused increased I/O times but anything is
>> possible. Any chance you were monitoring fn_virtualfilestats()
>> before and after? If so do you notice increased bytes read or
>> written or just increased IOStallms?
>> Most of the table/index scans are on very small tables (some of
>> which are heaps). There aren't any table scans on larger tables,
>> and there are very few index scans on larger tables (we're working
>> on removing those as we can). Full scans/sec seem to hover around
>> 3. We have several hundred concurrent users on this db.
>> No, I haven't used fn_virtualfilestats() before. Just ran it, and
>> it seems useful - thanks for the tip. IoStallMS / NumberReads +
>> NumberWrites) is less than 6 for all files, so that seems OK based
>> on the documentation I've seen.
>>
>> Andrew J. Kelly wrote:
>>> Have the query plans changed? Is the increased I/O due to more
>>> table scans? Did you run sp_updatestats?
>> Thanks for the suggestions. I did not run sp_updatestats - I
>> just did it on one of the less-busy servers to see if it makes a
>> difference. The query plans are not different from what I have
>> seen so far, but I will keep looking. Table scans have come down
>> a bit since upgrading to SP4. The strange thing (to me) is that
>> overall I/O activity is about the
>> same; reads/writes per sec is pretty constant. It's just the
>> duration of each I/O operation and the disk queue length that
>> went up. And this happened only on the data drive - the trans
>> log and local (tempdb) drives' queue lengths actually decreased.
>>> We have upgraded 3 of our SQL Servers to SP4 in the past 2
>>> weeks. We monitor these servers with Veritas, and we have
>>> noticed that all 3 servers have shown a marked increase
>>> (around 4x) in Disk
>>> Sec/Transfer, Disk Sec/Write, and Disk Queue Length.
>>>
>>> For example, on one server, Disk Writes and Disk Transfers were
>>> taking on average 7 ms to complete (with SP3a). Post-SP4, they
>>> are taking approximately 30 ms on average. The queue length
>>> has jumped from around 3 to about 15. [I know the avg disk
>>> queue length was a bit high to start with - we are working
>>> with our SAN vendor to get this figured out] Queries are still
>>> executing
>>> in about the same time, CPU utilization
>>> is about the same, and we see no other negative effects. But
>>> we're wondering why the I/O is so much worse than when we were
>>> running SP3a. We changed nothing besides moving to SP4. And
>>> we did install the post-SP4 AWE patch as well. Has anyone run
>>> into this before or know of any articles that touch on possible
>>> causes?sql

I/O issues after SP4 upgrade

Hi,
We have upgraded 3 of our SQL Servers to SP4 in the past 2 weeks. We
monitor these servers with Veritas, and we have noticed that all 3 servers
have shown a marked increase (around 4x) in Disk Sec/Transfer, Disk
Sec/Write, and Disk Queue Length.
For example, on one server, Disk Writes and Disk Transfers were taking on
average 7 ms to complete (with SP3a). Post-SP4, they are taking
approximately 30 ms on average. The queue length has jumped from around 3
to about 15. [I know the avg disk queue length was a bit high to start
with - we are working with our SAN vendor to get this figured out]
Queries are still executing in about the same time, CPU utilization is about
the same, and we see no other negative effects. But we're wondering why the
I/O is so much worse than when we were running SP3a. We changed nothing
besides moving to SP4. And we did install the post-SP4 AWE patch as well.
Has anyone run into this before or know of any articles that touch on
possible causes?
Regards,
Jake Marx
www.longhead.com
[please keep replies in the newsgroup - email address unmonitored]
Have the query plans changed? Is the increased I/O due to more table scans?
Did you run sp_updatestats?
Andrew J. Kelly SQL MVP
"Jake Marx" <msnews@.longhead.com> wrote in message
news:OM%23R2MCVGHA.4348@.TK2MSFTNGP09.phx.gbl...
> Hi,
> We have upgraded 3 of our SQL Servers to SP4 in the past 2 weeks. We
> monitor these servers with Veritas, and we have noticed that all 3 servers
> have shown a marked increase (around 4x) in Disk Sec/Transfer, Disk
> Sec/Write, and Disk Queue Length.
> For example, on one server, Disk Writes and Disk Transfers were taking on
> average 7 ms to complete (with SP3a). Post-SP4, they are taking
> approximately 30 ms on average. The queue length has jumped from around 3
> to about 15. [I know the avg disk queue length was a bit high to start
> with - we are working with our SAN vendor to get this figured out]
> Queries are still executing in about the same time, CPU utilization is
> about the same, and we see no other negative effects. But we're wondering
> why the I/O is so much worse than when we were running SP3a. We changed
> nothing besides moving to SP4. And we did install the post-SP4 AWE patch
> as well. Has anyone run into this before or know of any articles that
> touch on possible causes?
> --
> Regards,
> Jake Marx
> www.longhead.com
>
> [please keep replies in the newsgroup - email address unmonitored]
>
|||Hi Andrew,
Andrew J. Kelly wrote:
> Have the query plans changed? Is the increased I/O due to more table
> scans? Did you run sp_updatestats?
Thanks for the suggestions. I did not run sp_updatestats - I just did it on
one of the less-busy servers to see if it makes a difference. The query
plans are not different from what I have seen so far, but I will keep
looking. Table scans have come down a bit since upgrading to SP4.
The strange thing (to me) is that overall I/O activity is about the same;
reads/writes per sec is pretty constant. It's just the duration of each I/O
operation and the disk queue length that went up. And this happened only on
the data drive - the trans log and local (tempdb) drives' queue lengths
actually decreased.
Regards,
Jake Marx
www.longhead.com
[please keep replies in the newsgroup - email address unmonitored]
[vbcol=seagreen]
|||There should be very few table scans if they are optimized properly
regardless of the SP. I haven't seen anything yet that indicates SP4 itself
caused increased I/O times but anything is possible. Any chance you were
monitoring fn_virtualfilestats() before and after? If so do you notice
increased bytes read or written or just increased IOStallms?
Andrew J. Kelly SQL MVP
"Jake Marx" <msnews@.longhead.com> wrote in message
news:%23KCJtvNVGHA.4764@.TK2MSFTNGP10.phx.gbl...
> Hi Andrew,
> Andrew J. Kelly wrote:
> Thanks for the suggestions. I did not run sp_updatestats - I just did it
> on one of the less-busy servers to see if it makes a difference. The
> query plans are not different from what I have seen so far, but I will
> keep looking. Table scans have come down a bit since upgrading to SP4.
> The strange thing (to me) is that overall I/O activity is about the same;
> reads/writes per sec is pretty constant. It's just the duration of each
> I/O operation and the disk queue length that went up. And this happened
> only on the data drive - the trans log and local (tempdb) drives' queue
> lengths actually decreased.
> --
> Regards,
> Jake Marx
> www.longhead.com
>
> [please keep replies in the newsgroup - email address unmonitored]
>
>
|||Hi Andrew,
Andrew J. Kelly wrote:
> There should be very few table scans if they are optimized properly
> regardless of the SP. I haven't seen anything yet that indicates SP4
> itself caused increased I/O times but anything is possible. Any
> chance you were monitoring fn_virtualfilestats() before and after? If so
> do you notice increased bytes read or written or just increased
> IOStallms?
Most of the table/index scans are on very small tables (some of which are
heaps). There aren't any table scans on larger tables, and there are very
few index scans on larger tables (we're working on removing those as we
can). Full scans/sec seem to hover around 3. We have several hundred
concurrent users on this db.
No, I haven't used fn_virtualfilestats() before. Just ran it, and it seems
useful - thanks for the tip. IoStallMS / NumberReads + NumberWrites) is
less than 6 for all files, so that seems OK based on the documentation I've
seen.
Regards,
Jake Marx
www.longhead.com
[please keep replies in the newsgroup - email address unmonitored]
[vbcol=seagreen]
|||The filestats will let you know if you are actually reading / writing more
data or simply getting increased access times with the same data.
Andrew J. Kelly SQL MVP
"Jake Marx" <msnews@.longhead.com> wrote in message
news:eTDfwOOVGHA.4864@.TK2MSFTNGP12.phx.gbl...
> Hi Andrew,
> Andrew J. Kelly wrote:
> Most of the table/index scans are on very small tables (some of which are
> heaps). There aren't any table scans on larger tables, and there are very
> few index scans on larger tables (we're working on removing those as we
> can). Full scans/sec seem to hover around 3. We have several hundred
> concurrent users on this db.
> No, I haven't used fn_virtualfilestats() before. Just ran it, and it
> seems useful - thanks for the tip. IoStallMS / NumberReads +
> NumberWrites) is less than 6 for all files, so that seems OK based on the
> documentation I've seen.
> --
> Regards,
> Jake Marx
> www.longhead.com
>
> [please keep replies in the newsgroup - email address unmonitored]
>
>
|||Hi Andrew,
Andrew J. Kelly wrote:
> The filestats will let you know if you are actually reading / writing
> more data or simply getting increased access times with the same data.
Thanks. According to perfmon before and after SP4 installation, the I/O
load is about the same now as it was then (approx the same # of writes/sec
and reads/sec) - it's just the sec/write and sec/transfer (along with the
disk queue length) that are higher.
I'm not sure what else to look at. I know that SP4 reports I/O
latching/locking differently than SP3a, but that shouldn't affect perfmon OS
stats, right? I'd imagine those are collected directly by the disk
subsystem and that SQL would have nothing to do with that collection...
Thanks again for your help. I'm going through all the query plans now to
make sure nothing has changed.
Regards,
Jake Marx
www.longhead.com
[please keep replies in the newsgroup - email address unmonitored]
[vbcol=seagreen]
[vbcol=seagreen]
|||The sp should not affect perfmon stats for I/O. Are you sure there wasn't
anything else done around that same timeframe that may have affected this?
Any changes to the SAN or the OS? I wish I could offer something better
than that but this is not something I have heard happening to others upon
adding SP4 (or any service pack for that matter).
Andrew J. Kelly SQL MVP
"Jake Marx" <msnews@.longhead.com> wrote in message
news:u7lZo02VGHA.4724@.TK2MSFTNGP09.phx.gbl...
> Hi Andrew,
> Andrew J. Kelly wrote:
> Thanks. According to perfmon before and after SP4 installation, the I/O
> load is about the same now as it was then (approx the same # of writes/sec
> and reads/sec) - it's just the sec/write and sec/transfer (along with the
> disk queue length) that are higher.
> I'm not sure what else to look at. I know that SP4 reports I/O
> latching/locking differently than SP3a, but that shouldn't affect perfmon
> OS stats, right? I'd imagine those are collected directly by the disk
> subsystem and that SQL would have nothing to do with that collection...
> Thanks again for your help. I'm going through all the query plans now to
> make sure nothing has changed.
> --
> Regards,
> Jake Marx
> www.longhead.com
>
> [please keep replies in the newsgroup - email address unmonitored]
>
>

I/O issues after SP4 upgrade

Hi,
We have upgraded 3 of our SQL Servers to SP4 in the past 2 weeks. We
monitor these servers with Veritas, and we have noticed that all 3 servers
have shown a marked increase (around 4x) in Disk Sec/Transfer, Disk
Sec/Write, and Disk Queue Length.
For example, on one server, Disk Writes and Disk Transfers were taking on
average 7 ms to complete (with SP3a). Post-SP4, they are taking
approximately 30 ms on average. The queue length has jumped from around 3
to about 15. [I know the avg disk queue length was a bit high to start
with - we are working with our SAN vendor to get this figured out]
Queries are still executing in about the same time, CPU utilization is about
the same, and we see no other negative effects. But we're wondering why the
I/O is so much worse than when we were running SP3a. We changed nothing
besides moving to SP4. And we did install the post-SP4 AWE patch as well.
Has anyone run into this before or know of any articles that touch on
possible causes?
Regards,
Jake Marx
www.longhead.com
[please keep replies in the newsgroup - email address unmonitored]Have the query plans changed? Is the increased I/O due to more table scans?
Did you run sp_updatestats?
Andrew J. Kelly SQL MVP
"Jake Marx" <msnews@.longhead.com> wrote in message
news:OM%23R2MCVGHA.4348@.TK2MSFTNGP09.phx.gbl...
> Hi,
> We have upgraded 3 of our SQL Servers to SP4 in the past 2 weeks. We
> monitor these servers with Veritas, and we have noticed that all 3 servers
> have shown a marked increase (around 4x) in Disk Sec/Transfer, Disk
> Sec/Write, and Disk Queue Length.
> For example, on one server, Disk Writes and Disk Transfers were taking on
> average 7 ms to complete (with SP3a). Post-SP4, they are taking
> approximately 30 ms on average. The queue length has jumped from around 3
> to about 15. [I know the avg disk queue length was a bit high to star
t
> with - we are working with our SAN vendor to get this figured out]
> Queries are still executing in about the same time, CPU utilization is
> about the same, and we see no other negative effects. But we're wondering
> why the I/O is so much worse than when we were running SP3a. We changed
> nothing besides moving to SP4. And we did install the post-SP4 AWE patch
> as well. Has anyone run into this before or know of any articles that
> touch on possible causes?
> --
> Regards,
> Jake Marx
> www.longhead.com
>
> [please keep replies in the newsgroup - email address unmonitored]
>|||Hi Andrew,
Andrew J. Kelly wrote:
> Have the query plans changed? Is the increased I/O due to more table
> scans? Did you run sp_updatestats?
Thanks for the suggestions. I did not run sp_updatestats - I just did it on
one of the less-busy servers to see if it makes a difference. The query
plans are not different from what I have seen so far, but I will keep
looking. Table scans have come down a bit since upgrading to SP4.
The strange thing (to me) is that overall I/O activity is about the same;
reads/writes per sec is pretty constant. It's just the duration of each I/O
operation and the disk queue length that went up. And this happened only on
the data drive - the trans log and local (tempdb) drives' queue lengths
actually decreased.
Regards,
Jake Marx
www.longhead.com
[please keep replies in the newsgroup - email address unmonitored]
[vbcol=seagreen]|||There should be very few table scans if they are optimized properly
regardless of the SP. I haven't seen anything yet that indicates SP4 itself
caused increased I/O times but anything is possible. Any chance you were
monitoring fn_virtualfilestats() before and after? If so do you notice
increased bytes read or written or just increased IOStallms?
Andrew J. Kelly SQL MVP
"Jake Marx" <msnews@.longhead.com> wrote in message
news:%23KCJtvNVGHA.4764@.TK2MSFTNGP10.phx.gbl...
> Hi Andrew,
> Andrew J. Kelly wrote:
> Thanks for the suggestions. I did not run sp_updatestats - I just did it
> on one of the less-busy servers to see if it makes a difference. The
> query plans are not different from what I have seen so far, but I will
> keep looking. Table scans have come down a bit since upgrading to SP4.
> The strange thing (to me) is that overall I/O activity is about the same;
> reads/writes per sec is pretty constant. It's just the duration of each
> I/O operation and the disk queue length that went up. And this happened
> only on the data drive - the trans log and local (tempdb) drives' queue
> lengths actually decreased.
> --
> Regards,
> Jake Marx
> www.longhead.com
>
> [please keep replies in the newsgroup - email address unmonitored]
>
>|||Hi Andrew,
Andrew J. Kelly wrote:
> There should be very few table scans if they are optimized properly
> regardless of the SP. I haven't seen anything yet that indicates SP4
> itself caused increased I/O times but anything is possible. Any
> chance you were monitoring fn_virtualfilestats() before and after? If so
> do you notice increased bytes read or written or just increased
> IOStallms?
Most of the table/index scans are on very small tables (some of which are
heaps). There aren't any table scans on larger tables, and there are very
few index scans on larger tables (we're working on removing those as we
can). Full scans/sec seem to hover around 3. We have several hundred
concurrent users on this db.
No, I haven't used fn_virtualfilestats() before. Just ran it, and it seems
useful - thanks for the tip. IoStallMS / NumberReads + NumberWrites) is
less than 6 for all files, so that seems OK based on the documentation I've
seen.
Regards,
Jake Marx
www.longhead.com
[please keep replies in the newsgroup - email address unmonitored]
[vbcol=seagreen]|||The filestats will let you know if you are actually reading / writing more
data or simply getting increased access times with the same data.
Andrew J. Kelly SQL MVP
"Jake Marx" <msnews@.longhead.com> wrote in message
news:eTDfwOOVGHA.4864@.TK2MSFTNGP12.phx.gbl...
> Hi Andrew,
> Andrew J. Kelly wrote:
> Most of the table/index scans are on very small tables (some of which are
> heaps). There aren't any table scans on larger tables, and there are very
> few index scans on larger tables (we're working on removing those as we
> can). Full scans/sec seem to hover around 3. We have several hundred
> concurrent users on this db.
> No, I haven't used fn_virtualfilestats() before. Just ran it, and it
> seems useful - thanks for the tip. IoStallMS / NumberReads +
> NumberWrites) is less than 6 for all files, so that seems OK based on the
> documentation I've seen.
> --
> Regards,
> Jake Marx
> www.longhead.com
>
> [please keep replies in the newsgroup - email address unmonitored]
>
>|||Hi Andrew,
Andrew J. Kelly wrote:
> The filestats will let you know if you are actually reading / writing
> more data or simply getting increased access times with the same data.
Thanks. According to perfmon before and after SP4 installation, the I/O
load is about the same now as it was then (approx the same # of writes/sec
and reads/sec) - it's just the sec/write and sec/transfer (along with the
disk queue length) that are higher.
I'm not sure what else to look at. I know that SP4 reports I/O
latching/locking differently than SP3a, but that shouldn't affect perfmon OS
stats, right? I'd imagine those are collected directly by the disk
subsystem and that SQL would have nothing to do with that collection...
Thanks again for your help. I'm going through all the query plans now to
make sure nothing has changed.
Regards,
Jake Marx
www.longhead.com
[please keep replies in the newsgroup - email address unmonitored]
[vbcol=seagreen]
[vbcol=seagreen]|||The sp should not affect perfmon stats for I/O. Are you sure there wasn't
anything else done around that same timeframe that may have affected this?
Any changes to the SAN or the OS? I wish I could offer something better
than that but this is not something I have heard happening to others upon
adding SP4 (or any service pack for that matter).
Andrew J. Kelly SQL MVP
"Jake Marx" <msnews@.longhead.com> wrote in message
news:u7lZo02VGHA.4724@.TK2MSFTNGP09.phx.gbl...
> Hi Andrew,
> Andrew J. Kelly wrote:
> Thanks. According to perfmon before and after SP4 installation, the I/O
> load is about the same now as it was then (approx the same # of writes/sec
> and reads/sec) - it's just the sec/write and sec/transfer (along with the
> disk queue length) that are higher.
> I'm not sure what else to look at. I know that SP4 reports I/O
> latching/locking differently than SP3a, but that shouldn't affect perfmon
> OS stats, right? I'd imagine those are collected directly by the disk
> subsystem and that SQL would have nothing to do with that collection...
> Thanks again for your help. I'm going through all the query plans now to
> make sure nothing has changed.
> --
> Regards,
> Jake Marx
> www.longhead.com
>
> [please keep replies in the newsgroup - email address unmonitored]
>
>
>

Monday, March 19, 2012

I upgraded from MSDE to 2005 Express, now my apps get 'login faile

All of my RDO (2.0) connections are getting this error:
Login failed for user 'my_user'
All of my apps that use ADO are working fine.
I know the userid/password are correct because I use the same ones with my
ADO apps. Does anyone have any ideas?
Thanks in advance!
apf
Nevermind! The root of my problem was - passwords are case sensitive in
2005! If anyone knows how to turn this "option" off, I would appreciate it.
|||It can't be turned off. It was part of improving password strength to
improve security of SQL logins.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"apf" <apf@.discussions.microsoft.com> wrote in message
news:2786F0F5-CBDB-4B3A-AAC4-67AADE6A4CF0@.microsoft.com...
> Nevermind! The root of my problem was - passwords are case sensitive in
> 2005! If anyone knows how to turn this "option" off, I would appreciate
> it.
>

I upgraded from MSDE to 2005 Express - now my apps get login faile

All of my RDO (2.0) connections are getting this error:
Login failed for user 'my_user'
All of my apps that use ADO are working fine.
I know the userid/password are correct because I use the same ones with my
ADO apps. Does anyone have any ideas?
Thanks in advance!
apfSorry for posting in the wrong forum!
The answer, by the way, is passwords are case sensitive in SQL Server 2005.

I upgraded from MSDE to 2005 Express - now my apps get login faile

All of my RDO (2.0) connections are getting this error:
Login failed for user 'my_user'
All of my apps that use ADO are working fine.
I know the userid/password are correct because I use the same ones with my
ADO apps. Does anyone have any ideas?
Thanks in advance!
apf
Sorry for posting in the wrong forum!
The answer, by the way, is passwords are case sensitive in SQL Server 2005.

I upgraded from MSDE to 2005 Express - now my apps get login faile

All of my RDO (2.0) connections are getting this error:
Login failed for user 'my_user'
All of my apps that use ADO are working fine.
I know the userid/password are correct because I use the same ones with my
ADO apps. Does anyone have any ideas?
Thanks in advance!
apfSorry for posting in the wrong forum!
The answer, by the way, is passwords are case sensitive in SQL Server 2005.

Wednesday, March 7, 2012

I need some serious help here

I had the evaluation version running, generated beautiful reports.
I upgraded my computer from Windows 2000 to 2003 and after a day or two
realized RS would not run, but it could have expired.
I upgraded my RS from the evaluation version to the release version,
choosing "upgrade". After the upgrade at first it wouldn't allow access to
the virtual dirs (eventually I hard-coded the Admin name/password in the
impersonation line in web.config which fixed it) and after that it
complained about unable to connect to the database. I tried the rsconfig
utility, then it complained about unable to decrypt a key pair and it
suggested restoring the default, which of course I did not have (it really
surprised me there).
I un-installed RS and started a fresh install. Now it says "The edition of
the Report Server Database is not supported on the edition of SQL Server
2000 you have chosen".
Both SQL 2000 and RS are Enterprise, and the evaluation was quite happy
using my SQL Server version (my machine was still Win 2000 though).
I have been fighting this install for about 7 hours now (on a Sunday),
googled, newsgroups, used bad language, etc, etc.
I am (or was) going to demo some (beautiful) reports to a client tomorrow.Do you have SP3a installed on your SQL2K enterprise?
--
Brian Welcker
Group Program Manager
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
news:uG8PvNLXEHA.796@.TK2MSFTNGP10.phx.gbl...
>I had the evaluation version running, generated beautiful reports.
> I upgraded my computer from Windows 2000 to 2003 and after a day or two
> realized RS would not run, but it could have expired.
> I upgraded my RS from the evaluation version to the release version,
> choosing "upgrade". After the upgrade at first it wouldn't allow access to
> the virtual dirs (eventually I hard-coded the Admin name/password in the
> impersonation line in web.config which fixed it) and after that it
> complained about unable to connect to the database. I tried the rsconfig
> utility, then it complained about unable to decrypt a key pair and it
> suggested restoring the default, which of course I did not have (it really
> surprised me there).
> I un-installed RS and started a fresh install. Now it says "The edition of
> the Report Server Database is not supported on the edition of SQL Server
> 2000 you have chosen".
> Both SQL 2000 and RS are Enterprise, and the evaluation was quite happy
> using my SQL Server version (my machine was still Win 2000 though).
> I have been fighting this install for about 7 hours now (on a Sunday),
> googled, newsgroups, used bad language, etc, etc.
> I am (or was) going to demo some (beautiful) reports to a client tomorrow.
>|||Hi Brian,
I had SP3 and upgraded to SP3a yesterday as well. What is RS looking at when
it decides that this is the wrong version?
I guess I can backup all databases and re-install SQL Server if you think
that should do it. I gave that a thought already, but then it came to mind
what if it is something else and I went through that exercise for nothing.
Thanks for your ideas,
Chris.
"Brian Welcker [MSFT]" <bwelcker@.online.microsoft.com> wrote in message
news:OZ40yyMXEHA.3512@.TK2MSFTNGP12.phx.gbl...
> Do you have SP3a installed on your SQL2K enterprise?
> --
> Brian Welcker
> Group Program Manager
> SQL Server Reporting Services
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
> news:uG8PvNLXEHA.796@.TK2MSFTNGP10.phx.gbl...
> >I had the evaluation version running, generated beautiful reports.
> > I upgraded my computer from Windows 2000 to 2003 and after a day or two
> > realized RS would not run, but it could have expired.
> > I upgraded my RS from the evaluation version to the release version,
> > choosing "upgrade". After the upgrade at first it wouldn't allow access
to
> > the virtual dirs (eventually I hard-coded the Admin name/password in the
> > impersonation line in web.config which fixed it) and after that it
> > complained about unable to connect to the database. I tried the rsconfig
> > utility, then it complained about unable to decrypt a key pair and it
> > suggested restoring the default, which of course I did not have (it
really
> > surprised me there).
> > I un-installed RS and started a fresh install. Now it says "The edition
of
> > the Report Server Database is not supported on the edition of SQL Server
> > 2000 you have chosen".
> > Both SQL 2000 and RS are Enterprise, and the evaluation was quite happy
> > using my SQL Server version (my machine was still Win 2000 though).
> > I have been fighting this install for about 7 hours now (on a Sunday),
> > googled, newsgroups, used bad language, etc, etc.
> > I am (or was) going to demo some (beautiful) reports to a client
tomorrow.
> >
> >
>|||I just looked at my notes from my install on Windows 2003. For Windows 2003
only, you need a hotfix for SQL Server. Seems strange that SQL Server needs
it but only on 2003 but there you are. It is in the installation notes for
the install. Besides SP3a you need hotfix 859.
Your situation is a bit different. Only RS is on 2003 and your SQL Server is
still on 2000 so it seems like you wouldn't need the hotfix but you are
accessing it from Windows 2003 so maybe that is the key point. In my case
SQL Server and RS are both on Windows 2003.
In any case, it won't hurt anything and it might fix your problem so I
suggest installing the hotfix and see if that helps.
Hope that helps.
"Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
news:uETJr%23RXEHA.1764@.TK2MSFTNGP10.phx.gbl...
> Hi Brian,
> I had SP3 and upgraded to SP3a yesterday as well. What is RS looking at
when
> it decides that this is the wrong version?
> I guess I can backup all databases and re-install SQL Server if you think
> that should do it. I gave that a thought already, but then it came to mind
> what if it is something else and I went through that exercise for nothing.
> Thanks for your ideas,
> Chris.
> "Brian Welcker [MSFT]" <bwelcker@.online.microsoft.com> wrote in message
> news:OZ40yyMXEHA.3512@.TK2MSFTNGP12.phx.gbl...
> > Do you have SP3a installed on your SQL2K enterprise?
> >
> > --
> > Brian Welcker
> > Group Program Manager
> > SQL Server Reporting Services
> >
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> >
> > "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
> > news:uG8PvNLXEHA.796@.TK2MSFTNGP10.phx.gbl...
> > >I had the evaluation version running, generated beautiful reports.
> > > I upgraded my computer from Windows 2000 to 2003 and after a day or
two
> > > realized RS would not run, but it could have expired.
> > > I upgraded my RS from the evaluation version to the release version,
> > > choosing "upgrade". After the upgrade at first it wouldn't allow
access
> to
> > > the virtual dirs (eventually I hard-coded the Admin name/password in
the
> > > impersonation line in web.config which fixed it) and after that it
> > > complained about unable to connect to the database. I tried the
rsconfig
> > > utility, then it complained about unable to decrypt a key pair and it
> > > suggested restoring the default, which of course I did not have (it
> really
> > > surprised me there).
> > > I un-installed RS and started a fresh install. Now it says "The
edition
> of
> > > the Report Server Database is not supported on the edition of SQL
Server
> > > 2000 you have chosen".
> > > Both SQL 2000 and RS are Enterprise, and the evaluation was quite
happy
> > > using my SQL Server version (my machine was still Win 2000 though).
> > > I have been fighting this install for about 7 hours now (on a Sunday),
> > > googled, newsgroups, used bad language, etc, etc.
> > > I am (or was) going to demo some (beautiful) reports to a client
> tomorrow.
> > >
> > >
> >
> >
>|||Hi Bruce,
I have both SQL Server and RS running on the same 2003 machine, upgraded
from Win 2000 to 2003.
I am now attempting to locate hotfix 859, if you know the URL drop it here.
Thanks.
"Bruce Loehle-Conger" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:OLbvvSSXEHA.3972@.TK2MSFTNGP12.phx.gbl...
> I just looked at my notes from my install on Windows 2003. For Windows
2003
> only, you need a hotfix for SQL Server. Seems strange that SQL Server
needs
> it but only on 2003 but there you are. It is in the installation notes for
> the install. Besides SP3a you need hotfix 859.
> Your situation is a bit different. Only RS is on 2003 and your SQL Server
is
> still on 2000 so it seems like you wouldn't need the hotfix but you are
> accessing it from Windows 2003 so maybe that is the key point. In my case
> SQL Server and RS are both on Windows 2003.
> In any case, it won't hurt anything and it might fix your problem so I
> suggest installing the hotfix and see if that helps.
> Hope that helps.
> "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
> news:uETJr%23RXEHA.1764@.TK2MSFTNGP10.phx.gbl...
> > Hi Brian,
> >
> > I had SP3 and upgraded to SP3a yesterday as well. What is RS looking at
> when
> > it decides that this is the wrong version?
> > I guess I can backup all databases and re-install SQL Server if you
think
> > that should do it. I gave that a thought already, but then it came to
mind
> > what if it is something else and I went through that exercise for
nothing.
> >
> > Thanks for your ideas,
> >
> > Chris.
> >
> > "Brian Welcker [MSFT]" <bwelcker@.online.microsoft.com> wrote in message
> > news:OZ40yyMXEHA.3512@.TK2MSFTNGP12.phx.gbl...
> > > Do you have SP3a installed on your SQL2K enterprise?
> > >
> > > --
> > > Brian Welcker
> > > Group Program Manager
> > > SQL Server Reporting Services
> > >
> > > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> > >
> > > "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
> > > news:uG8PvNLXEHA.796@.TK2MSFTNGP10.phx.gbl...
> > > >I had the evaluation version running, generated beautiful reports.
> > > > I upgraded my computer from Windows 2000 to 2003 and after a day or
> two
> > > > realized RS would not run, but it could have expired.
> > > > I upgraded my RS from the evaluation version to the release version,
> > > > choosing "upgrade". After the upgrade at first it wouldn't allow
> access
> > to
> > > > the virtual dirs (eventually I hard-coded the Admin name/password in
> the
> > > > impersonation line in web.config which fixed it) and after that it
> > > > complained about unable to connect to the database. I tried the
> rsconfig
> > > > utility, then it complained about unable to decrypt a key pair and
it
> > > > suggested restoring the default, which of course I did not have (it
> > really
> > > > surprised me there).
> > > > I un-installed RS and started a fresh install. Now it says "The
> edition
> > of
> > > > the Report Server Database is not supported on the edition of SQL
> Server
> > > > 2000 you have chosen".
> > > > Both SQL 2000 and RS are Enterprise, and the evaluation was quite
> happy
> > > > using my SQL Server version (my machine was still Win 2000 though).
> > > > I have been fighting this install for about 7 hours now (on a
Sunday),
> > > > googled, newsgroups, used bad language, etc, etc.
> > > > I am (or was) going to demo some (beautiful) reports to a client
> > tomorrow.
> > > >
> > > >
> > >
> > >
> >
> >
>|||Nope, did not help if this was the correct hotfix, downloaded from
http://support.microsoft.com/default.aspx?scid=kb;en-us;821334
Thanks in any case.
"Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
news:Orv6o6SXEHA.3972@.TK2MSFTNGP12.phx.gbl...
> Hi Bruce,
> I have both SQL Server and RS running on the same 2003 machine, upgraded
> from Win 2000 to 2003.
> I am now attempting to locate hotfix 859, if you know the URL drop it
here.
> Thanks.
> "Bruce Loehle-Conger" <bruce_lcNOSPAM@.hotmail.com> wrote in message
> news:OLbvvSSXEHA.3972@.TK2MSFTNGP12.phx.gbl...
> > I just looked at my notes from my install on Windows 2003. For Windows
> 2003
> > only, you need a hotfix for SQL Server. Seems strange that SQL Server
> needs
> > it but only on 2003 but there you are. It is in the installation notes
for
> > the install. Besides SP3a you need hotfix 859.
> >
> > Your situation is a bit different. Only RS is on 2003 and your SQL
Server
> is
> > still on 2000 so it seems like you wouldn't need the hotfix but you are
> > accessing it from Windows 2003 so maybe that is the key point. In my
case
> > SQL Server and RS are both on Windows 2003.
> >
> > In any case, it won't hurt anything and it might fix your problem so I
> > suggest installing the hotfix and see if that helps.
> >
> > Hope that helps.
> >
> > "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
> > news:uETJr%23RXEHA.1764@.TK2MSFTNGP10.phx.gbl...
> > > Hi Brian,
> > >
> > > I had SP3 and upgraded to SP3a yesterday as well. What is RS looking
at
> > when
> > > it decides that this is the wrong version?
> > > I guess I can backup all databases and re-install SQL Server if you
> think
> > > that should do it. I gave that a thought already, but then it came to
> mind
> > > what if it is something else and I went through that exercise for
> nothing.
> > >
> > > Thanks for your ideas,
> > >
> > > Chris.
> > >
> > > "Brian Welcker [MSFT]" <bwelcker@.online.microsoft.com> wrote in
message
> > > news:OZ40yyMXEHA.3512@.TK2MSFTNGP12.phx.gbl...
> > > > Do you have SP3a installed on your SQL2K enterprise?
> > > >
> > > > --
> > > > Brian Welcker
> > > > Group Program Manager
> > > > SQL Server Reporting Services
> > > >
> > > > This posting is provided "AS IS" with no warranties, and confers no
> > > rights.
> > > >
> > > > "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
> > > > news:uG8PvNLXEHA.796@.TK2MSFTNGP10.phx.gbl...
> > > > >I had the evaluation version running, generated beautiful reports.
> > > > > I upgraded my computer from Windows 2000 to 2003 and after a day
or
> > two
> > > > > realized RS would not run, but it could have expired.
> > > > > I upgraded my RS from the evaluation version to the release
version,
> > > > > choosing "upgrade". After the upgrade at first it wouldn't allow
> > access
> > > to
> > > > > the virtual dirs (eventually I hard-coded the Admin name/password
in
> > the
> > > > > impersonation line in web.config which fixed it) and after that it
> > > > > complained about unable to connect to the database. I tried the
> > rsconfig
> > > > > utility, then it complained about unable to decrypt a key pair and
> it
> > > > > suggested restoring the default, which of course I did not have
(it
> > > really
> > > > > surprised me there).
> > > > > I un-installed RS and started a fresh install. Now it says "The
> > edition
> > > of
> > > > > the Report Server Database is not supported on the edition of SQL
> > Server
> > > > > 2000 you have chosen".
> > > > > Both SQL 2000 and RS are Enterprise, and the evaluation was quite
> > happy
> > > > > using my SQL Server version (my machine was still Win 2000
though).
> > > > > I have been fighting this install for about 7 hours now (on a
> Sunday),
> > > > > googled, newsgroups, used bad language, etc, etc.
> > > > > I am (or was) going to demo some (beautiful) reports to a client
> > > tomorrow.
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>|||OK, just in case any of the following might help you. There were several
things I had to do different under 2003 Server.
1. Hotfix 859
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/RSUIREF/htm/f1_rsc_installation_v1_036u.asp
2. Configure server with application server, asp.net (two distinct
activities). Seems if this was an issue you would get a different error
message
3. I selected built-in account. Two choices: network and system. It defaults
to network. I wanted system (which is how my previous configurations were
configured).
Other than these my installation went smoothly but then I had a clean
install of Windows 2003 Advanced Server and SQL Server Enterprise.
What do you get when you do a select @.@.version? I get this:
Microsoft SQL Server 2000 - 8.00.859 (Intel X86) Sep 18 2003 12:53:45
Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on Windows
NT 5.2 (Build 3790: )
Bruce L-C
"Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
news:ePWpOETXEHA.644@.tk2msftngp13.phx.gbl...
> Nope, did not help if this was the correct hotfix, downloaded from
> http://support.microsoft.com/default.aspx?scid=kb;en-us;821334
> Thanks in any case.
> "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
> news:Orv6o6SXEHA.3972@.TK2MSFTNGP12.phx.gbl...
> > Hi Bruce,
> >
> > I have both SQL Server and RS running on the same 2003 machine, upgraded
> > from Win 2000 to 2003.
> > I am now attempting to locate hotfix 859, if you know the URL drop it
> here.
> >
> > Thanks.
> >
> > "Bruce Loehle-Conger" <bruce_lcNOSPAM@.hotmail.com> wrote in message
> > news:OLbvvSSXEHA.3972@.TK2MSFTNGP12.phx.gbl...
> > > I just looked at my notes from my install on Windows 2003. For Windows
> > 2003
> > > only, you need a hotfix for SQL Server. Seems strange that SQL Server
> > needs
> > > it but only on 2003 but there you are. It is in the installation notes
> for
> > > the install. Besides SP3a you need hotfix 859.
> > >
> > > Your situation is a bit different. Only RS is on 2003 and your SQL
> Server
> > is
> > > still on 2000 so it seems like you wouldn't need the hotfix but you
are
> > > accessing it from Windows 2003 so maybe that is the key point. In my
> case
> > > SQL Server and RS are both on Windows 2003.
> > >
> > > In any case, it won't hurt anything and it might fix your problem so I
> > > suggest installing the hotfix and see if that helps.
> > >
> > > Hope that helps.
> > >
> > > "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
> > > news:uETJr%23RXEHA.1764@.TK2MSFTNGP10.phx.gbl...
> > > > Hi Brian,
> > > >
> > > > I had SP3 and upgraded to SP3a yesterday as well. What is RS looking
> at
> > > when
> > > > it decides that this is the wrong version?
> > > > I guess I can backup all databases and re-install SQL Server if you
> > think
> > > > that should do it. I gave that a thought already, but then it came
to
> > mind
> > > > what if it is something else and I went through that exercise for
> > nothing.
> > > >
> > > > Thanks for your ideas,
> > > >
> > > > Chris.
> > > >
> > > > "Brian Welcker [MSFT]" <bwelcker@.online.microsoft.com> wrote in
> message
> > > > news:OZ40yyMXEHA.3512@.TK2MSFTNGP12.phx.gbl...
> > > > > Do you have SP3a installed on your SQL2K enterprise?
> > > > >
> > > > > --
> > > > > Brian Welcker
> > > > > Group Program Manager
> > > > > SQL Server Reporting Services
> > > > >
> > > > > This posting is provided "AS IS" with no warranties, and confers
no
> > > > rights.
> > > > >
> > > > > "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in
message
> > > > > news:uG8PvNLXEHA.796@.TK2MSFTNGP10.phx.gbl...
> > > > > >I had the evaluation version running, generated beautiful
reports.
> > > > > > I upgraded my computer from Windows 2000 to 2003 and after a day
> or
> > > two
> > > > > > realized RS would not run, but it could have expired.
> > > > > > I upgraded my RS from the evaluation version to the release
> version,
> > > > > > choosing "upgrade". After the upgrade at first it wouldn't allow
> > > access
> > > > to
> > > > > > the virtual dirs (eventually I hard-coded the Admin
name/password
> in
> > > the
> > > > > > impersonation line in web.config which fixed it) and after that
it
> > > > > > complained about unable to connect to the database. I tried the
> > > rsconfig
> > > > > > utility, then it complained about unable to decrypt a key pair
and
> > it
> > > > > > suggested restoring the default, which of course I did not have
> (it
> > > > really
> > > > > > surprised me there).
> > > > > > I un-installed RS and started a fresh install. Now it says "The
> > > edition
> > > > of
> > > > > > the Report Server Database is not supported on the edition of
SQL
> > > Server
> > > > > > 2000 you have chosen".
> > > > > > Both SQL 2000 and RS are Enterprise, and the evaluation was
quite
> > > happy
> > > > > > using my SQL Server version (my machine was still Win 2000
> though).
> > > > > > I have been fighting this install for about 7 hours now (on a
> > Sunday),
> > > > > > googled, newsgroups, used bad language, etc, etc.
> > > > > > I am (or was) going to demo some (beautiful) reports to a client
> > > > tomorrow.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>|||DAMN, my @.@.version is exactly the same, word for word, except for one word,
where yours says "Enterprise" mine says "Developer". It was installed close
to 3 years ago and I could swear by it that it was the Enterprise. The
evaluation version was happy, what a shame the release is not happy.
Bruce, thanks for your help.
Now I am sitting here with the Enterprise Edition CD in my hand, wondering
what will happen if I install it over the Developers.
I am going to post this question in the SQL Server newsgroup as well, if you
know the answer though, drop it here. Thanks again.
"Bruce Loehle-Conger" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:##mhJXTXEHA.2520@.TK2MSFTNGP12.phx.gbl...
> OK, just in case any of the following might help you. There were several
> things I had to do different under 2003 Server.
> 1. Hotfix 859
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/RSUIREF/htm/f1_rsc_installation_v1_036u.asp
> 2. Configure server with application server, asp.net (two distinct
> activities). Seems if this was an issue you would get a different error
> message
> 3. I selected built-in account. Two choices: network and system. It
defaults
> to network. I wanted system (which is how my previous configurations were
> configured).
> Other than these my installation went smoothly but then I had a clean
> install of Windows 2003 Advanced Server and SQL Server Enterprise.
> What do you get when you do a select @.@.version? I get this:
> Microsoft SQL Server 2000 - 8.00.859 (Intel X86) Sep 18 2003 12:53:45
> Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on
Windows
> NT 5.2 (Build 3790: )
> Bruce L-C
> "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
> news:ePWpOETXEHA.644@.tk2msftngp13.phx.gbl...
> > Nope, did not help if this was the correct hotfix, downloaded from
> > http://support.microsoft.com/default.aspx?scid=kb;en-us;821334
> >
> > Thanks in any case.
> >
> > "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
> > news:Orv6o6SXEHA.3972@.TK2MSFTNGP12.phx.gbl...
> > > Hi Bruce,
> > >
> > > I have both SQL Server and RS running on the same 2003 machine,
upgraded
> > > from Win 2000 to 2003.
> > > I am now attempting to locate hotfix 859, if you know the URL drop it
> > here.
> > >
> > > Thanks.
> > >
> > > "Bruce Loehle-Conger" <bruce_lcNOSPAM@.hotmail.com> wrote in message
> > > news:OLbvvSSXEHA.3972@.TK2MSFTNGP12.phx.gbl...
> > > > I just looked at my notes from my install on Windows 2003. For
Windows
> > > 2003
> > > > only, you need a hotfix for SQL Server. Seems strange that SQL
Server
> > > needs
> > > > it but only on 2003 but there you are. It is in the installation
notes
> > for
> > > > the install. Besides SP3a you need hotfix 859.
> > > >
> > > > Your situation is a bit different. Only RS is on 2003 and your SQL
> > Server
> > > is
> > > > still on 2000 so it seems like you wouldn't need the hotfix but you
> are
> > > > accessing it from Windows 2003 so maybe that is the key point. In my
> > case
> > > > SQL Server and RS are both on Windows 2003.
> > > >
> > > > In any case, it won't hurt anything and it might fix your problem so
I
> > > > suggest installing the hotfix and see if that helps.
> > > >
> > > > Hope that helps.
> > > >
> > > > "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
> > > > news:uETJr%23RXEHA.1764@.TK2MSFTNGP10.phx.gbl...
> > > > > Hi Brian,
> > > > >
> > > > > I had SP3 and upgraded to SP3a yesterday as well. What is RS
looking
> > at
> > > > when
> > > > > it decides that this is the wrong version?
> > > > > I guess I can backup all databases and re-install SQL Server if
you
> > > think
> > > > > that should do it. I gave that a thought already, but then it came
> to
> > > mind
> > > > > what if it is something else and I went through that exercise for
> > > nothing.
> > > > >
> > > > > Thanks for your ideas,
> > > > >
> > > > > Chris.
> > > > >
> > > > > "Brian Welcker [MSFT]" <bwelcker@.online.microsoft.com> wrote in
> > message
> > > > > news:OZ40yyMXEHA.3512@.TK2MSFTNGP12.phx.gbl...
> > > > > > Do you have SP3a installed on your SQL2K enterprise?
> > > > > >
> > > > > > --
> > > > > > Brian Welcker
> > > > > > Group Program Manager
> > > > > > SQL Server Reporting Services
> > > > > >
> > > > > > This posting is provided "AS IS" with no warranties, and confers
> no
> > > > > rights.
> > > > > >
> > > > > > "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in
> message
> > > > > > news:uG8PvNLXEHA.796@.TK2MSFTNGP10.phx.gbl...
> > > > > > >I had the evaluation version running, generated beautiful
> reports.
> > > > > > > I upgraded my computer from Windows 2000 to 2003 and after a
day
> > or
> > > > two
> > > > > > > realized RS would not run, but it could have expired.
> > > > > > > I upgraded my RS from the evaluation version to the release
> > version,
> > > > > > > choosing "upgrade". After the upgrade at first it wouldn't
allow
> > > > access
> > > > > to
> > > > > > > the virtual dirs (eventually I hard-coded the Admin
> name/password
> > in
> > > > the
> > > > > > > impersonation line in web.config which fixed it) and after
that
> it
> > > > > > > complained about unable to connect to the database. I tried
the
> > > > rsconfig
> > > > > > > utility, then it complained about unable to decrypt a key pair
> and
> > > it
> > > > > > > suggested restoring the default, which of course I did not
have
> > (it
> > > > > really
> > > > > > > surprised me there).
> > > > > > > I un-installed RS and started a fresh install. Now it says
"The
> > > > edition
> > > > > of
> > > > > > > the Report Server Database is not supported on the edition of
> SQL
> > > > Server
> > > > > > > 2000 you have chosen".
> > > > > > > Both SQL 2000 and RS are Enterprise, and the evaluation was
> quite
> > > > happy
> > > > > > > using my SQL Server version (my machine was still Win 2000
> > though).
> > > > > > > I have been fighting this install for about 7 hours now (on a
> > > Sunday),
> > > > > > > googled, newsgroups, used bad language, etc, etc.
> > > > > > > I am (or was) going to demo some (beautiful) reports to a
client
> > > > > tomorrow.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>|||Ah ha. I was wondering about that but you seemed real certain it was
enterprise. Developer has the same features as enterprise so it is easy to
not know, that is why I had you check. I had developer and went to
enterprise but darn if I can remember if I had to unistall/reinstall or if I
could upgrade. Good news is that the problem is solved. Simple once you know
the solution <g>.
Bruce L-C
"Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
news:uFvSAFUXEHA.4000@.TK2MSFTNGP09.phx.gbl...
> DAMN, my @.@.version is exactly the same, word for word, except for one
word,
> where yours says "Enterprise" mine says "Developer". It was installed
close
> to 3 years ago and I could swear by it that it was the Enterprise. The
> evaluation version was happy, what a shame the release is not happy.
> Bruce, thanks for your help.
> Now I am sitting here with the Enterprise Edition CD in my hand, wondering
> what will happen if I install it over the Developers.
> I am going to post this question in the SQL Server newsgroup as well, if
you
> know the answer though, drop it here. Thanks again.
>
> "Bruce Loehle-Conger" <bruce_lcNOSPAM@.hotmail.com> wrote in message
> news:##mhJXTXEHA.2520@.TK2MSFTNGP12.phx.gbl...
> > OK, just in case any of the following might help you. There were several
> > things I had to do different under 2003 Server.
> > 1. Hotfix 859
> >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/RSUIREF/htm/f1_rsc_installation_v1_036u.asp
> > 2. Configure server with application server, asp.net (two distinct
> > activities). Seems if this was an issue you would get a different error
> > message
> > 3. I selected built-in account. Two choices: network and system. It
> defaults
> > to network. I wanted system (which is how my previous configurations
were
> > configured).
> >
> > Other than these my installation went smoothly but then I had a clean
> > install of Windows 2003 Advanced Server and SQL Server Enterprise.
> >
> > What do you get when you do a select @.@.version? I get this:
> > Microsoft SQL Server 2000 - 8.00.859 (Intel X86) Sep 18 2003 12:53:45
> > Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on
> Windows
> > NT 5.2 (Build 3790: )
> >
> > Bruce L-C
> >
> > "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
> > news:ePWpOETXEHA.644@.tk2msftngp13.phx.gbl...
> > > Nope, did not help if this was the correct hotfix, downloaded from
> > > http://support.microsoft.com/default.aspx?scid=kb;en-us;821334
> > >
> > > Thanks in any case.
> > >
> > > "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in message
> > > news:Orv6o6SXEHA.3972@.TK2MSFTNGP12.phx.gbl...
> > > > Hi Bruce,
> > > >
> > > > I have both SQL Server and RS running on the same 2003 machine,
> upgraded
> > > > from Win 2000 to 2003.
> > > > I am now attempting to locate hotfix 859, if you know the URL drop
it
> > > here.
> > > >
> > > > Thanks.
> > > >
> > > > "Bruce Loehle-Conger" <bruce_lcNOSPAM@.hotmail.com> wrote in message
> > > > news:OLbvvSSXEHA.3972@.TK2MSFTNGP12.phx.gbl...
> > > > > I just looked at my notes from my install on Windows 2003. For
> Windows
> > > > 2003
> > > > > only, you need a hotfix for SQL Server. Seems strange that SQL
> Server
> > > > needs
> > > > > it but only on 2003 but there you are. It is in the installation
> notes
> > > for
> > > > > the install. Besides SP3a you need hotfix 859.
> > > > >
> > > > > Your situation is a bit different. Only RS is on 2003 and your SQL
> > > Server
> > > > is
> > > > > still on 2000 so it seems like you wouldn't need the hotfix but
you
> > are
> > > > > accessing it from Windows 2003 so maybe that is the key point. In
my
> > > case
> > > > > SQL Server and RS are both on Windows 2003.
> > > > >
> > > > > In any case, it won't hurt anything and it might fix your problem
so
> I
> > > > > suggest installing the hotfix and see if that helps.
> > > > >
> > > > > Hope that helps.
> > > > >
> > > > > "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in
message
> > > > > news:uETJr%23RXEHA.1764@.TK2MSFTNGP10.phx.gbl...
> > > > > > Hi Brian,
> > > > > >
> > > > > > I had SP3 and upgraded to SP3a yesterday as well. What is RS
> looking
> > > at
> > > > > when
> > > > > > it decides that this is the wrong version?
> > > > > > I guess I can backup all databases and re-install SQL Server if
> you
> > > > think
> > > > > > that should do it. I gave that a thought already, but then it
came
> > to
> > > > mind
> > > > > > what if it is something else and I went through that exercise
for
> > > > nothing.
> > > > > >
> > > > > > Thanks for your ideas,
> > > > > >
> > > > > > Chris.
> > > > > >
> > > > > > "Brian Welcker [MSFT]" <bwelcker@.online.microsoft.com> wrote in
> > > message
> > > > > > news:OZ40yyMXEHA.3512@.TK2MSFTNGP12.phx.gbl...
> > > > > > > Do you have SP3a installed on your SQL2K enterprise?
> > > > > > >
> > > > > > > --
> > > > > > > Brian Welcker
> > > > > > > Group Program Manager
> > > > > > > SQL Server Reporting Services
> > > > > > >
> > > > > > > This posting is provided "AS IS" with no warranties, and
confers
> > no
> > > > > > rights.
> > > > > > >
> > > > > > > "Chris Botha" <chris_s_botha@.AT_h.o.t.m.a.i.l.com> wrote in
> > message
> > > > > > > news:uG8PvNLXEHA.796@.TK2MSFTNGP10.phx.gbl...
> > > > > > > >I had the evaluation version running, generated beautiful
> > reports.
> > > > > > > > I upgraded my computer from Windows 2000 to 2003 and after a
> day
> > > or
> > > > > two
> > > > > > > > realized RS would not run, but it could have expired.
> > > > > > > > I upgraded my RS from the evaluation version to the release
> > > version,
> > > > > > > > choosing "upgrade". After the upgrade at first it wouldn't
> allow
> > > > > access
> > > > > > to
> > > > > > > > the virtual dirs (eventually I hard-coded the Admin
> > name/password
> > > in
> > > > > the
> > > > > > > > impersonation line in web.config which fixed it) and after
> that
> > it
> > > > > > > > complained about unable to connect to the database. I tried
> the
> > > > > rsconfig
> > > > > > > > utility, then it complained about unable to decrypt a key
pair
> > and
> > > > it
> > > > > > > > suggested restoring the default, which of course I did not
> have
> > > (it
> > > > > > really
> > > > > > > > surprised me there).
> > > > > > > > I un-installed RS and started a fresh install. Now it says
> "The
> > > > > edition
> > > > > > of
> > > > > > > > the Report Server Database is not supported on the edition
of
> > SQL
> > > > > Server
> > > > > > > > 2000 you have chosen".
> > > > > > > > Both SQL 2000 and RS are Enterprise, and the evaluation was
> > quite
> > > > > happy
> > > > > > > > using my SQL Server version (my machine was still Win 2000
> > > though).
> > > > > > > > I have been fighting this install for about 7 hours now (on
a
> > > > Sunday),
> > > > > > > > googled, newsgroups, used bad language, etc, etc.
> > > > > > > > I am (or was) going to demo some (beautiful) reports to a
> client
> > > > > > tomorrow.
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>