(actually quite desperate).
The extra CPU and 1GB of RAM to be added to a server (Compaq DL380 G2:
1.4 GHz PIII with a Gig of RAM) have not come in and we are scheduled
to go live tomorrow with a MS SQL Server web app. Will potentially
insufficient hardware resources endanger the data of other apps
running on the SQL Server or will the system simply be slow for
everyone?
Basically, I need to know whether SQl Server bogs down gracefully
(under 2x-3x an acceptable load) or will we be corrupting the database
with a crash.
Thanks a million,
Bertalbertcraig@.hotmail.com (Bert) wrote in message news:<898d9fd7.0402101736.4b5c3e54@.posting.google.com>...
> I am sertainly no SQL expert so I am looking for a bit of help
> (actually quite desperate).
> The extra CPU and 1GB of RAM to be added to a server (Compaq DL380 G2:
> 1.4 GHz PIII with a Gig of RAM) have not come in and we are scheduled
> to go live tomorrow with a MS SQL Server web app. Will potentially
> insufficient hardware resources endanger the data of other apps
> running on the SQL Server or will the system simply be slow for
> everyone?
> Basically, I need to know whether SQl Server bogs down gracefully
> (under 2x-3x an acceptable load) or will we be corrupting the database
> with a crash.
> Thanks a million,
> Bert
If you overload the system, then things should just get a lot slower.
Even if there is a crash, MSSQL will protect data integrity by rolling
back/forward any uncommitted transactions.
You should also be aware that SQL Server takes as much memory as
possible (by design), but will release it to other applications if
needed. Whether or not that happens fast enough to avoid paging, or
timeouts from other applications isn't really possible to say without
testing.
Simon|||Bert (albertcraig@.hotmail.com) writes:
> The extra CPU and 1GB of RAM to be added to a server (Compaq DL380 G2:
> 1.4 GHz PIII with a Gig of RAM) have not come in and we are scheduled
> to go live tomorrow with a MS SQL Server web app. Will potentially
> insufficient hardware resources endanger the data of other apps
> running on the SQL Server or will the system simply be slow for
> everyone?
> Basically, I need to know whether SQl Server bogs down gracefully
> (under 2x-3x an acceptable load) or will we be corrupting the database
> with a crash.
To add to Simon's response: if you are running more applications on that
machine, you may want to configure SQL Server to not use more than a
certain amount of memory (but don't forget to change the setting when
that extra gig comes in!). SQL Server does yield when other applications
needs memory, but it does not always yield fast enough.
--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Erland Sommarskog <sommar@.algonet.se> wrote in message news:<Xns948CEF61FD7A1Yazorman@.127.0.0.1>...
> Bert (albertcraig@.hotmail.com) writes:
> > The extra CPU and 1GB of RAM to be added to a server (Compaq DL380 G2:
> > 1.4 GHz PIII with a Gig of RAM) have not come in and we are scheduled
> > to go live tomorrow with a MS SQL Server web app. Will potentially
> > insufficient hardware resources endanger the data of other apps
> > running on the SQL Server or will the system simply be slow for
> > everyone?
> > Basically, I need to know whether SQl Server bogs down gracefully
> > (under 2x-3x an acceptable load) or will we be corrupting the database
> > with a crash.
> To add to Simon's response: if you are running more applications on that
> machine, you may want to configure SQL Server to not use more than a
> certain amount of memory (but don't forget to change the setting when
> that extra gig comes in!). SQL Server does yield when other applications
> needs memory, but it does not always yield fast enough.
Thanks gentlemen! In the end we postponed the rollout by two days and
twisted some arms to get some RAM. So, fortunately, we didn't get to
see if the server bogged down. I will, however, have someone look into
controlling the amount of RAM that SQL Server grabs initially.
Thanks,
Bertsql
No comments:
Post a Comment