Hilary and Paul : SQL 2005 Book and Materials

I considered the idea, but have decided to produce a few
articles on the main changes that I'm interested in
instead - merge over the internet and peer-to-peer
transactional. Hilary's the man for books, and he'll be
able to update you about his plans.
BTW to be honest as MVPs we don't have much of an
advantage over anyone else in this regard - we still have
to do the research, trial and error, digging through
system stored procedures etc, although some changes we
hear about a little earlier. I know Kalen was able to
interview PMs for the various groups but that was
exceptional and we don't really have such access. If this
is something you're interested in - ie close contact with
the developers - then now is the time we can all do it.
Have a good look at the Beta2 and try to figure the
replication features out, then post your questions in the
Beta2 newsgroups
(http://communities.microsoft.com/new...s/default.asp?
icp=sqlserver2005&slcid=us). I have used these and the
Yukon ones, and the questions are answered by the actual
TSQL code developers - the people we don't usually see on
the public newsgroups, so this is pretty valuable stuff.
Regards,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Paul is right. Please post your comments about SQL server 2005 betas. We
will be delighted to have your feedback.
thanks - Deepak
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
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:1f5e01c4f7c1$8cafb250$a401280a@.phx.gbl...
> I considered the idea, but have decided to produce a few
> articles on the main changes that I'm interested in
> instead - merge over the internet and peer-to-peer
> transactional. Hilary's the man for books, and he'll be
> able to update you about his plans.
> BTW to be honest as MVPs we don't have much of an
> advantage over anyone else in this regard - we still have
> to do the research, trial and error, digging through
> system stored procedures etc, although some changes we
> hear about a little earlier. I know Kalen was able to
> interview PMs for the various groups but that was
> exceptional and we don't really have such access. If this
> is something you're interested in - ie close contact with
> the developers - then now is the time we can all do it.
> Have a good look at the Beta2 and try to figure the
> replication features out, then post your questions in the
> Beta2 newsgroups
> (http://communities.microsoft.com/new...s/default.asp?
> icp=sqlserver2005&slcid=us). I have used these and the
> Yukon ones, and the questions are answered by the actual
> TSQL code developers - the people we don't usually see on
> the public newsgroups, so this is pretty valuable stuff.
> Regards,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>

High disk I/O with long running queries surprising?

Hello,
I am interested in opinions about a case that I recently ran into. We
have a server with SQL Server 2000 Standard where a 50 GB database is
run. A stored procedure is run every night that performs data updates
and perform several aggregations and calculations of the data for about
4 hours in this database. Based on this little information, would you
be surprised to find out that during the execution of this stored
procedure, SQL Server uses the disk to 100 % (or at least want to)?
/Stefan> Based on this little information, would you
> be surprised to find out that during the execution of this stored
> procedure, SQL Server uses the disk to 100 % (or at least want to)?
Unless all data can fit in the memory allocated to SQL Server, I would
expect significant disk activity during the process. Even then, modified
still data needs to be written to disk.
--
Hope this helps.
Dan Guzman
SQL Server MVP
<sl@.invativa.se> wrote in message
news:1151406632.094352.37510@.u72g2000cwu.googlegroups.com...
> Hello,
> I am interested in opinions about a case that I recently ran into. We
> have a server with SQL Server 2000 Standard where a 50 GB database is
> run. A stored procedure is run every night that performs data updates
> and perform several aggregations and calculations of the data for about
> 4 hours in this database. Based on this little information, would you
> be surprised to find out that during the execution of this stored
> procedure, SQL Server uses the disk to 100 % (or at least want to)?
> /Stefan
>|||<sl@.invativa.se> wrote in message
news:1151406632.094352.37510@.u72g2000cwu.googlegroups.com...
> Hello,
> I am interested in opinions about a case that I recently ran into. We
> have a server with SQL Server 2000 Standard where a 50 GB database is
> run. A stored procedure is run every night that performs data updates
> and perform several aggregations and calculations of the data for about
> 4 hours in this database. Based on this little information, would you
> be surprised to find out that during the execution of this stored
> procedure, SQL Server uses the disk to 100 % (or at least want to)?
>
Assuming that SQL Server is using a buffer cache of significantly less than
50GB, and these queries need to read a large percentage of the 50GB of data,
then SQL Server will need to read the data from disk.
So no, I would not be surprised.
David|||In addition to what the others have said, if this is based on the readings
from the % Disk Time counter, you may want to check a few more disk counters
to be sure. This counter can be funky. It's more reliable to check I/O
latency counters such as Avg Disk Sec/Read and Avg Disk Sec/Write.
Linchi
"sl@.invativa.se" wrote:
> Hello,
> I am interested in opinions about a case that I recently ran into. We
> have a server with SQL Server 2000 Standard where a 50 GB database is
> run. A stored procedure is run every night that performs data updates
> and perform several aggregations and calculations of the data for about
> 4 hours in this database. Based on this little information, would you
> be surprised to find out that during the execution of this stored
> procedure, SQL Server uses the disk to 100 % (or at least want to)?
> /Stefan
>|||And, of course, WRITE the updates back to disk.
No, I wouldn't be at all surprised.
The next question 'should be', based upon the following DDL and stored
procedure code, is there a more efficient way to accomplish the task?
(include table DDL and stored procedure code.)
--
Arnie Rowland, YACE*
"To be successful, your heart must accompany your knowledge."
*Yet Another Certification Exam
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:eacg56dmGHA.660@.TK2MSFTNGP05.phx.gbl...
> <sl@.invativa.se> wrote in message
> news:1151406632.094352.37510@.u72g2000cwu.googlegroups.com...
>> Hello,
>> I am interested in opinions about a case that I recently ran into. We
>> have a server with SQL Server 2000 Standard where a 50 GB database is
>> run. A stored procedure is run every night that performs data updates
>> and perform several aggregations and calculations of the data for about
>> 4 hours in this database. Based on this little information, would you
>> be surprised to find out that during the execution of this stored
>> procedure, SQL Server uses the disk to 100 % (or at least want to)?
> Assuming that SQL Server is using a buffer cache of significantly less
> than 50GB, and these queries need to read a large percentage of the 50GB
> of data, then SQL Server will need to read the data from disk.
> So no, I would not be surprised.
> David|||Thanks for all answers.
Great that you all confirmed that lots of disk I/O is no surprise in
this scenario.
/Stefan