Help! What is the risk for data on insufficient hardware?

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,
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

Help! Suspect Databases - Hardware Failure

We have numerous suspect databases across multiple serverse due to a hardware
failure on our SAN. The part of the SAN that failed had a combination of data
and log files, but not both for a given database.
Right now we have services shut down on the server. When we bring the server
back up, after fixing our hardware failure, what would be the best steps?
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums.aspx/sql-server/200703/1
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:6eca09c69ec9c@.uwe...
> We have numerous suspect databases across multiple serverse due to a
> hardware
> failure on our SAN. The part of the SAN that failed had a combination of
> data
> and log files, but not both for a given database.
> Right now we have services shut down on the server. When we bring the
> server
> back up, after fixing our hardware failure, what would be the best steps?
BEFORE bringing up the server, make complete backups of all files.
Then once you bring up the server, check the logs and find out why the
databases are suspect.
In some cases it may be as simple as the drive letters or paths no longer
being right and once you fix those, the database may come up cleanly.
If it's more complex, you'll have to do different things, but hard to
recommend w/o knowing in advance the exact nature of the problems.
No matter what I'd make sure to do a DBCC checkdb once the database is back
up, just to be sure.
(btw, I've found that it takes pretty bad problems to outright corrupt a SQL
2000/2005 database, so you may luck out.)

> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums.aspx/sql-server/200703/1
>
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com
|||Thanks Greg. Once the hardware was repaired and we restarted the services (we
had complete backups available) all databases came up cleanly.
If I were to set a job to execute DBCC CHECKDB WITH NO_INFOMSGS to run after
hours, if there were errors encountered, would I still be informed, even
though I had the "WITH NO_INFOMSGS" option?
Greg D. Moore (Strider) wrote:
>[quoted text clipped - 5 lines]
>BEFORE bringing up the server, make complete backups of all files.
>Then once you bring up the server, check the logs and find out why the
>databases are suspect.
>In some cases it may be as simple as the drive letters or paths no longer
>being right and once you fix those, the database may come up cleanly.
>If it's more complex, you'll have to do different things, but hard to
>recommend w/o knowing in advance the exact nature of the problems.
>No matter what I'd make sure to do a DBCC checkdb once the database is back
>up, just to be sure.
>(btw, I've found that it takes pretty bad problems to outright corrupt a SQL
>2000/2005 database, so you may luck out.)
>
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums.aspx/sql-server/200703/1
|||"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:6ecae312206bc@.uwe...
> Thanks Greg. Once the hardware was repaired and we restarted the services
> (we
> had complete backups available) all databases came up cleanly.
>
Glad to hear it.

> If I were to set a job to execute DBCC CHECKDB WITH NO_INFOMSGS to run
> after
> hours, if there were errors encountered, would I still be informed, even
> though I had the "WITH NO_INFOMSGS" option?
I believe so.

>
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com

Help! Suspect Databases - Hardware Failure

We have numerous suspect databases across multiple serverse due to a hardware
failure on our SAN. The part of the SAN that failed had a combination of data
and log files, but not both for a given database.
Right now we have services shut down on the server. When we bring the server
back up, after fixing our hardware failure, what would be the best steps?
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200703/1"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:6eca09c69ec9c@.uwe...
> We have numerous suspect databases across multiple serverse due to a
> hardware
> failure on our SAN. The part of the SAN that failed had a combination of
> data
> and log files, but not both for a given database.
> Right now we have services shut down on the server. When we bring the
> server
> back up, after fixing our hardware failure, what would be the best steps?
BEFORE bringing up the server, make complete backups of all files.
Then once you bring up the server, check the logs and find out why the
databases are suspect.
In some cases it may be as simple as the drive letters or paths no longer
being right and once you fix those, the database may come up cleanly.
If it's more complex, you'll have to do different things, but hard to
recommend w/o knowing in advance the exact nature of the problems.
No matter what I'd make sure to do a DBCC checkdb once the database is back
up, just to be sure.
(btw, I've found that it takes pretty bad problems to outright corrupt a SQL
2000/2005 database, so you may luck out.)
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200703/1
>
--
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com|||Thanks Greg. Once the hardware was repaired and we restarted the services (we
had complete backups available) all databases came up cleanly.
If I were to set a job to execute DBCC CHECKDB WITH NO_INFOMSGS to run after
hours, if there were errors encountered, would I still be informed, even
though I had the "WITH NO_INFOMSGS" option?
Greg D. Moore (Strider) wrote:
>> We have numerous suspect databases across multiple serverse due to a
>> hardware
>[quoted text clipped - 5 lines]
>> server
>> back up, after fixing our hardware failure, what would be the best steps?
>BEFORE bringing up the server, make complete backups of all files.
>Then once you bring up the server, check the logs and find out why the
>databases are suspect.
>In some cases it may be as simple as the drive letters or paths no longer
>being right and once you fix those, the database may come up cleanly.
>If it's more complex, you'll have to do different things, but hard to
>recommend w/o knowing in advance the exact nature of the problems.
>No matter what I'd make sure to do a DBCC checkdb once the database is back
>up, just to be sure.
>(btw, I've found that it takes pretty bad problems to outright corrupt a SQL
>2000/2005 database, so you may luck out.)
>
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200703/1|||"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:6ecae312206bc@.uwe...
> Thanks Greg. Once the hardware was repaired and we restarted the services
> (we
> had complete backups available) all databases came up cleanly.
>
Glad to hear it.
> If I were to set a job to execute DBCC CHECKDB WITH NO_INFOMSGS to run
> after
> hours, if there were errors encountered, would I still be informed, even
> though I had the "WITH NO_INFOMSGS" option?
I believe so.
>
--
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com|||On 06.03.2007 22:11, cbrichards via SQLMonster.com wrote:
> Thanks Greg. Once the hardware was repaired and we restarted the services (we
> had complete backups available) all databases came up cleanly.
> If I were to set a job to execute DBCC CHECKDB WITH NO_INFOMSGS to run after
> hours, if there were errors encountered, would I still be informed, even
> though I had the "WITH NO_INFOMSGS" option?
Wouldn't it be better to run this first before using the DB again? I
mean if there were issues you'd rather want to fix them before you put
the DB back in production.
Kind regards
robert

Help! Suspect Databases - Hardware Failure

We have numerous suspect databases across multiple serverse due to a hardwar
e
failure on our SAN. The part of the SAN that failed had a combination of dat
a
and log files, but not both for a given database.
Right now we have services shut down on the server. When we bring the server
back up, after fixing our hardware failure, what would be the best steps?
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200703/1"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:6eca09c69ec9c@.uwe...
> We have numerous suspect databases across multiple serverse due to a
> hardware
> failure on our SAN. The part of the SAN that failed had a combination of
> data
> and log files, but not both for a given database.
> Right now we have services shut down on the server. When we bring the
> server
> back up, after fixing our hardware failure, what would be the best steps?
BEFORE bringing up the server, make complete backups of all files.
Then once you bring up the server, check the logs and find out why the
databases are suspect.
In some cases it may be as simple as the drive letters or paths no longer
being right and once you fix those, the database may come up cleanly.
If it's more complex, you'll have to do different things, but hard to
recommend w/o knowing in advance the exact nature of the problems.
No matter what I'd make sure to do a DBCC checkdb once the database is back
up, just to be sure.
(btw, I've found that it takes pretty bad problems to outright corrupt a SQL
2000/2005 database, so you may luck out.)

> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200703/1
>
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com|||Thanks Greg. Once the hardware was repaired and we restarted the services (w
e
had complete backups available) all databases came up cleanly.
If I were to set a job to execute DBCC CHECKDB WITH NO_INFOMSGS to run after
hours, if there were errors encountered, would I still be informed, even
though I had the "WITH NO_INFOMSGS" option?
Greg D. Moore (Strider) wrote:
>[quoted text clipped - 5 lines]
>BEFORE bringing up the server, make complete backups of all files.
>Then once you bring up the server, check the logs and find out why the
>databases are suspect.
>In some cases it may be as simple as the drive letters or paths no longer
>being right and once you fix those, the database may come up cleanly.
>If it's more complex, you'll have to do different things, but hard to
>recommend w/o knowing in advance the exact nature of the problems.
>No matter what I'd make sure to do a DBCC checkdb once the database is back
>up, just to be sure.
>(btw, I've found that it takes pretty bad problems to outright corrupt a SQ
L
>2000/2005 database, so you may luck out.)
>
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200703/1|||"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:6ecae312206bc@.uwe...
> Thanks Greg. Once the hardware was repaired and we restarted the services
> (we
> had complete backups available) all databases came up cleanly.
>
Glad to hear it.

> If I were to set a job to execute DBCC CHECKDB WITH NO_INFOMSGS to run
> after
> hours, if there were errors encountered, would I still be informed, even
> though I had the "WITH NO_INFOMSGS" option?
I believe so.

>
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com|||On 06.03.2007 22:11, cbrichards via droptable.com wrote:
> Thanks Greg. Once the hardware was repaired and we restarted the services
(we
> had complete backups available) all databases came up cleanly.
> If I were to set a job to execute DBCC CHECKDB WITH NO_INFOMSGS to run aft
er
> hours, if there were errors encountered, would I still be informed, even
> though I had the "WITH NO_INFOMSGS" option?
Wouldn't it be better to run this first before using the DB again? I
mean if there were issues you'd rather want to fix them before you put
the DB back in production.
Kind regards
robertsql

help! question about hardware request for SQL Server and Analysis Services

I built a database with a huge table which has 18 billion lines for 6(or 7) columns.

And in the Analysis Services the table is used to create a dimention and a measure.

One of the other two dimentions is made form a 4000 line table,and the other is

made from a 3 million line table(time dimension table).

The specification of my Server is Windows Server 2003 with Xeon Intel Cpu 5160 @.3.00GHz,

2.99GHz,4.00G RAM.

The problem comes out when i start the processing of Analysis Services.

the "time out" error comes out after 1 hour, however, the performance i need

is completing the Processing for one cube within 10 munites.

I want to know the hardware request to reach my needs and how to speed the

processing of Analysis Services.

Thank you

So, to be clear, you have an 18 billion row fact table, you have built a cube on top of it and you want a full process to complete in 10 minutes?

Chris

|||

Dear Mr

yes! I wanna a full process within 10 minutes.

Can it be done?

thanks in advance

tomigisi

|||

The short answer is no, not if you're using MOLAP storage for your measure group. The best throughput I've ever seen for cube processing with MOLAP storage is around 200000 rows per second, and that was a maximum rather than something that could be consistently achieved throughout the whole process; you should be happy with 60-70000 rows per second if you've got a top-end server and a properly-tuned relational datasource.

I would experiment with using ROLAP or HOLAP storage, or with pre-aggregating your fact table in some way to reduce the overall number of rows.

Sorry,

Chris

|||

We have a monster server: 8 - 3.2GHZ processors, a disk frame that reads/writes 400 MB/sec, 32 GB of ram, etc and we couldn't even process 18 Billion rows that fast. The slowdown is reading rows from the DB, and most likely not the server (unless you have slow disks).

sql

HELP! Please Server Crash

I have had a piece of hardware fail (motherboard died),
and I don't have a back up of the entire SQL Box. What I
do have is all the files, master, tempdb, etc etc... in
the directory on the hard drive they were on. They are
fine.
I can't get SQL to run on another box tho, and there is a
humongous amount of jobs, and dts' that I need from there.
The data is fine, but is there a way to get this server
to run on another box?
I am in desparate need.
THank you
SvenInstall SQL Server on the new box .If you remember the paths for the install
,set it up in that fashion. Once completed, stop the SQL server service and
if you remember the exact path names/locations of your data files and log
files , you could restore all those files exactly in the same location
before you start the SQL Server instance on the other box. Give that a try..
"Sven Hansen" <shansen@.westjet.com> wrote in message
news:00c001c3c914$177c3210$a001280a@.phx.gbl...
> I have had a piece of hardware fail (motherboard died),
> and I don't have a back up of the entire SQL Box. What I
> do have is all the files, master, tempdb, etc etc... in
> the directory on the hard drive they were on. They are
> fine.
> I can't get SQL to run on another box tho, and there is a
> humongous amount of jobs, and dts' that I need from there.
> The data is fine, but is there a way to get this server
> to run on another box?
> I am in desparate need.
> THank you
> Sven
>|||After you install SQL , then stop the services and copy all of the files
back. You would then have to use sp_attach_db to attach the non-system
databases..
THe copying over of master, model , tempdb and msdb may or may not work...
The very least thing is that you MUST use the same collation that was
originally used...
--
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Sven Hansen" <shansen@.westjet.com> wrote in message
news:00c001c3c914$177c3210$a001280a@.phx.gbl...
> I have had a piece of hardware fail (motherboard died),
> and I don't have a back up of the entire SQL Box. What I
> do have is all the files, master, tempdb, etc etc... in
> the directory on the hard drive they were on. They are
> fine.
> I can't get SQL to run on another box tho, and there is a
> humongous amount of jobs, and dts' that I need from there.
> The data is fine, but is there a way to get this server
> to run on another box?
> I am in desparate need.
> THank you
> Sven
>sql