Showing posts with label idea. Show all posts
Showing posts with label idea. Show all posts

Wednesday, March 28, 2012

New to Cursors - HELP

My stored proc is below but I have no idea as to why the proc just spins - i
t
runs and never returns - I am assuming I have an infinite look somehow in my
cursor but this is the first SP I've written with a cursor so I'm lost -
Anyone who can point me in the right direction I would be very grateful -
ALSO - is there a way to return to the results screen values at certain
points in a transaction - for example as each row changes can you return a
value to the results screen so you can see that it is doing something at all
?
- No debug authority on the server or I'd do that.
ALTER PROCEDURE dbo.InterrogateRealignRecords AS
/* ----
GO SEE IF THERE ARE ANY CHANGED SHADE
RECORDS FIRST AND RETURN THE COUNT INTO
@.ICOUNTSHDCHGS
---- */
Declare @.numSUCforShade int,@.ICOUNTSHDCHGS int,@.ICOUNTPROPCHGS INT,
@.ICOUNTSUBSEGCHGS INT,@.old_shade_ID Int, @.old_property_ID Int, @.old_subseg_I
D
Int
-- select count(*) from #shades_suc_bu
-- drop table #shades_suc_bu
select Shade_ID, SUC_Code,UPC
into #shades_suc_bu
from shade_Suc
Declare curChangeValues Scroll Cursor For
Select Count(*)
From PPGG_Admin.UPC_Shades_Realigned
Where shade_ID <> old_Shade_ID
Open curChangeValues
Fetch Next From curChangeValues
Into @.iCOUNTSHDCHGS
WHILE (@.@.fetch_status = 0)
BEGIN
if @.ICOUNTSHDCHGS > 0
/* --- */
/* THERE ARE CHANGED SHADE ID'S TO LOOK AT */
/* GO AND GET THE RECORDS SO WE CAN LOOK */
/* AT EACH ONE SEPARATELY */
/* --- */
declare curShadeChngVal scroll cursor for
Select old_Shade_ID, old_property_ID,old_product_Subsegment_I
D
From PPGG_Admin.UPC_Shades_Realigned
Where shade_ID <> old_Shade_ID
Open curShadeChngVal
Fetch Next From curShadeChngVal
Into @.old_shade_ID
,@.old_property_ID
,@.old_subseg_ID
Select @.old_shade_ID
,@.old_property_ID
,@.old_subseg_ID
WHILE (@.@.fetch_status =0)
Begin
/* ---*/
/* DURING THE LOOP CHECK THE SUC TABLE
TO SEE IF ANY UPCS STILL EXIST
FOR THIS SHADE */
/* ---*/
DECLARE curSUCVal scroll cursor for
Select Count(*) from Shade_SUC
where Shade_ID = @.old_Shade_ID
OPEN curSUCVal
fetch next from curSUCVal
into @.numSUCforShade
if @.numSUCforShade > 0
Begin
--declare @.dan int
--set @.dan =1
delete from #shades_suc_bu where Shade_ID = @.old_Shade_ID
end
CLOSE curSUCVal
Deallocate curSUCVal
END
end
Close curChangeValues
Deallocate curChangeValues
GO
SET QUOTED_IDENTIFIER OFF
GO
SET ANSI_NULLS ON
GOHEY THANKS - I sufficiently feel like an idiot - not everyone is a guru my
friend. But thanks for your tact. (not)
"CBretana" wrote:
> Entire thing is messed up
> 1) Each time you execute a cursor loop you have to Fetch Next INSIDE THE
> LOOP at the end, or you're just processing the same row over and over..
> 2) Same with cursor curShadeChngVal, there's a Ferch Next just befor the
> While Loop, but no Fetch Next at the end of the While loop to move to the
> nect record...
> 3) you have triply nested cursors and the innermost cursor (curSUCVal) see
ms
> not to be looping at all, (THERE'S NO WHILE LOOP FOR IT !!) you're just
> processing the first row of it...
> So why use cursor curSUCVal at all '
> "Dan" wrote:
>|||Entire thing is messed up
1) Each time you execute a cursor loop you have to Fetch Next INSIDE THE
LOOP at the end, or you're just processing the same row over and over..
2) Same with cursor curShadeChngVal, there's a Ferch Next just befor the
While Loop, but no Fetch Next at the end of the While loop to move to the
nect record...
3) you have triply nested cursors and the innermost cursor (curSUCVal) seems
not to be looping at all, (THERE'S NO WHILE LOOP FOR IT !!) you're just
processing the first row of it...
So why use cursor curSUCVal at all '
"Dan" wrote:

> My stored proc is below but I have no idea as to why the proc just spins -
it
> runs and never returns - I am assuming I have an infinite look somehow in
my
> cursor but this is the first SP I've written with a cursor so I'm lost -
> Anyone who can point me in the right direction I would be very grateful -
> ALSO - is there a way to return to the results screen values at certain
> points in a transaction - for example as each row changes can you return a
> value to the results screen so you can see that it is doing something at a
ll?
> - No debug authority on the server or I'd do that.
> ALTER PROCEDURE dbo.InterrogateRealignRecords AS
> /* ----
> GO SEE IF THERE ARE ANY CHANGED SHADE
> RECORDS FIRST AND RETURN THE COUNT INTO
> @.ICOUNTSHDCHGS
> ---- */
> Declare @.numSUCforShade int,@.ICOUNTSHDCHGS int,@.ICOUNTPROPCHGS INT,
> @.ICOUNTSUBSEGCHGS INT,@.old_shade_ID Int, @.old_property_ID Int, @.old_subseg
_ID
> Int
> -- select count(*) from #shades_suc_bu
> -- drop table #shades_suc_bu
> select Shade_ID, SUC_Code,UPC
> into #shades_suc_bu
> from shade_Suc
> Declare curChangeValues Scroll Cursor For
> Select Count(*)
> From PPGG_Admin.UPC_Shades_Realigned
> Where shade_ID <> old_Shade_ID
> Open curChangeValues
> Fetch Next From curChangeValues
> Into @.iCOUNTSHDCHGS
> WHILE (@.@.fetch_status = 0)
> BEGIN
> if @.ICOUNTSHDCHGS > 0
> /* --- */
> /* THERE ARE CHANGED SHADE ID'S TO LOOK AT */
> /* GO AND GET THE RECORDS SO WE CAN LOOK */
> /* AT EACH ONE SEPARATELY */
> /* --- */
> declare curShadeChngVal scroll cursor for
> Select old_Shade_ID, old_property_ID,old_product_Subsegment_I
D
> From PPGG_Admin.UPC_Shades_Realigned
> Where shade_ID <> old_Shade_ID
> Open curShadeChngVal
> Fetch Next From curShadeChngVal
> Into @.old_shade_ID
> ,@.old_property_ID
> ,@.old_subseg_ID
> Select @.old_shade_ID
> ,@.old_property_ID
> ,@.old_subseg_ID
> WHILE (@.@.fetch_status =0)
> Begin
> /* ---*/
> /* DURING THE LOOP CHECK THE SUC TABLE
> TO SEE IF ANY UPCS STILL EXIST
> FOR THIS SHADE */
> /* ---*/
> DECLARE curSUCVal scroll cursor for
> Select Count(*) from Shade_SUC
> where Shade_ID = @.old_Shade_ID
> OPEN curSUCVal
> fetch next from curSUCVal
> into @.numSUCforShade
> if @.numSUCforShade > 0
> Begin
> --declare @.dan int
> --set @.dan =1
> delete from #shades_suc_bu where Shade_ID = @.old_Shade_ID
> end
> CLOSE curSUCVal
> Deallocate curSUCVal
> END
>
> end
> Close curChangeValues
> Deallocate curChangeValues
>
> GO
> SET QUOTED_IDENTIFIER OFF
> GO
> SET ANSI_NULLS ON
> GO
>|||Dan, I Just noticed somethiong else...
the First cursor, curChangeValues is defined on
Select Count(*)
From PPGG_Admin.UPC_Shades_Realigned
Where shade_ID <> old_Shade_ID
This doesn't return a set of records at all, it just returns a single count
of records.. .You use cursors (when there's no other alternative) to ITERAT
E
through a COLLECTION of records when you need t oprocess each one
individually... not simply to get data. I suspect you really need to read a
bit about the basics of SQL.
"Dan" wrote:

> My stored proc is below but I have no idea as to why the proc just spins -
it
> runs and never returns - I am assuming I have an infinite look somehow in
my
> cursor but this is the first SP I've written with a cursor so I'm lost -
> Anyone who can point me in the right direction I would be very grateful -
> ALSO - is there a way to return to the results screen values at certain
> points in a transaction - for example as each row changes can you return a
> value to the results screen so you can see that it is doing something at a
ll?
> - No debug authority on the server or I'd do that.
> ALTER PROCEDURE dbo.InterrogateRealignRecords AS
> /* ----
> GO SEE IF THERE ARE ANY CHANGED SHADE
> RECORDS FIRST AND RETURN THE COUNT INTO
> @.ICOUNTSHDCHGS
> ---- */
> Declare @.numSUCforShade int,@.ICOUNTSHDCHGS int,@.ICOUNTPROPCHGS INT,
> @.ICOUNTSUBSEGCHGS INT,@.old_shade_ID Int, @.old_property_ID Int, @.old_subseg
_ID
> Int
> -- select count(*) from #shades_suc_bu
> -- drop table #shades_suc_bu
> select Shade_ID, SUC_Code,UPC
> into #shades_suc_bu
> from shade_Suc
> Declare curChangeValues Scroll Cursor For
> Select Count(*)
> From PPGG_Admin.UPC_Shades_Realigned
> Where shade_ID <> old_Shade_ID
> Open curChangeValues
> Fetch Next From curChangeValues
> Into @.iCOUNTSHDCHGS
> WHILE (@.@.fetch_status = 0)
> BEGIN
> if @.ICOUNTSHDCHGS > 0
> /* --- */
> /* THERE ARE CHANGED SHADE ID'S TO LOOK AT */
> /* GO AND GET THE RECORDS SO WE CAN LOOK */
> /* AT EACH ONE SEPARATELY */
> /* --- */
> declare curShadeChngVal scroll cursor for
> Select old_Shade_ID, old_property_ID,old_product_Subsegment_I
D
> From PPGG_Admin.UPC_Shades_Realigned
> Where shade_ID <> old_Shade_ID
> Open curShadeChngVal
> Fetch Next From curShadeChngVal
> Into @.old_shade_ID
> ,@.old_property_ID
> ,@.old_subseg_ID
> Select @.old_shade_ID
> ,@.old_property_ID
> ,@.old_subseg_ID
> WHILE (@.@.fetch_status =0)
> Begin
> /* ---*/
> /* DURING THE LOOP CHECK THE SUC TABLE
> TO SEE IF ANY UPCS STILL EXIST
> FOR THIS SHADE */
> /* ---*/
> DECLARE curSUCVal scroll cursor for
> Select Count(*) from Shade_SUC
> where Shade_ID = @.old_Shade_ID
> OPEN curSUCVal
> fetch next from curSUCVal
> into @.numSUCforShade
> if @.numSUCforShade > 0
> Begin
> --declare @.dan int
> --set @.dan =1
> delete from #shades_suc_bu where Shade_ID = @.old_Shade_ID
> end
> CLOSE curSUCVal
> Deallocate curSUCVal
> END
>
> end
> Close curChangeValues
> Deallocate curChangeValues
>
> GO
> SET QUOTED_IDENTIFIER OFF
> GO
> SET ANSI_NULLS ON
> GO
>|||Seriously, if you are new to cursors then you should stay away from
them for straight data manipulation stuff. Most of the time there are
better solutions without using cursors so until you are VERY confident
that you have enough SQL expertise to know when a cursor is the right
choice it's best to assume that you don't need them at all.
If you need more help with a solution then please come back with DDL
and sample data so that we can understand your requirements. See:
http://www.aspfaq.com/etiquette.asp?id=5006
David Portas
SQL Server MVP
--|||OK David,
If I am in need of iterating through a row of records to decide on an action
(update, delete, insert new etc) then what other option do I have in a Store
d
Proc?
Thanks
"David Portas" wrote:

> Seriously, if you are new to cursors then you should stay away from
> them for straight data manipulation stuff. Most of the time there are
> better solutions without using cursors so until you are VERY confident
> that you have enough SQL expertise to know when a cursor is the right
> choice it's best to assume that you don't need them at all.
> If you need more help with a solution then please come back with DDL
> and sample data so that we can understand your requirements. See:
> http://www.aspfaq.com/etiquette.asp?id=5006
> --
> David Portas
> SQL Server MVP
> --
>|||Dan,
CAPS not meant to insult, just to emphasize, sorry if tone was rough...
No attempt to insult or denigrate was intended.
And there's a differencve between being intelligence, and education.
EVERYONE (CAPS only to emphasize) is "undeducated" when they begin learning
a
new skill... There's no need to feel offended because you're not yet educate
d
...
From your post, a judgement might be made about your SQL knowledge, but
not about your intelligence. It's what you decide to do next that will
speak to the latter issue !
"Dan" wrote:
> HEY THANKS - I sufficiently feel like an idiot - not everyone is a guru my
> friend. But thanks for your tact. (not)
> "CBretana" wrote:
>|||Maybe a WHERE clause on each of those statements in succession -
probably with EXISTS, but that depends on what you are doing.
UPDATE x
SET ... ?
WHERE EXISTS
(SELECT *
FROM PPGG_Admin.UPC_Shades_Realigne=ADd
WHERE id =3D x.id
AND ... ?)
INSERT INTO z (...)
SELECT ...
FROM PPGG_Admin.UPC_Shades_Realigne=ADd AS T
WHERE NOT EXISTS
(SELECT *
FROM z
WHERE T.id =3D z.id
AND ... ?)
--=20
David Portas
SQL Server MVP
--|||Why do you need to iterate through a collection of records?
It appears from the code you posted the only thing the SP is doing is
deleting selected records from temp table #shades_suc_bu in the line
delete from #shades_suc_bu where Shade_ID = @.old_Shade_ID
Which is sort of pointless because the temp table is not then used for
anything else, and it will dissapear immediately after the SP terminates.
But even if it was doing something, the delete could probably be done in one
SQL statement that properly identified the records that need to be deleted,
instead of using any cursors at all...
But first, what exactly is this SP supposed to be doing ?
"Dan" wrote:
> OK David,
> If I am in need of iterating through a row of records to decide on an acti
on
> (update, delete, insert new etc) then what other option do I have in a Sto
red
> Proc?
> Thanks
> "David Portas" wrote:
>|||Usenet drama....
"Dan" <Dan@.discussions.microsoft.com> wrote in message
news:4F63E75A-9565-464A-AA41-36F7F3B46CDA@.microsoft.com...
> My stored proc is below but I have no idea as to why the proc just spins -
it
> runs and never returns - I am assuming I have an infinite look somehow in
my
> cursor but this is the first SP I've written with a cursor so I'm lost -
> Anyone who can point me in the right direction I would be very grateful -
> ALSO - is there a way to return to the results screen values at certain
> points in a transaction - for example as each row changes can you return a
> value to the results screen so you can see that it is doing something at
all?
> - No debug authority on the server or I'd do that.
> ALTER PROCEDURE dbo.InterrogateRealignRecords AS
> /* ----
> GO SEE IF THERE ARE ANY CHANGED SHADE
> RECORDS FIRST AND RETURN THE COUNT INTO
> @.ICOUNTSHDCHGS
> ---- */
> Declare @.numSUCforShade int,@.ICOUNTSHDCHGS int,@.ICOUNTPROPCHGS INT,
> @.ICOUNTSUBSEGCHGS INT,@.old_shade_ID Int, @.old_property_ID Int,
@.old_subseg_ID
> Int
> -- select count(*) from #shades_suc_bu
> -- drop table #shades_suc_bu
> select Shade_ID, SUC_Code,UPC
> into #shades_suc_bu
> from shade_Suc
> Declare curChangeValues Scroll Cursor For
> Select Count(*)
> From PPGG_Admin.UPC_Shades_Realigned
> Where shade_ID <> old_Shade_ID
> Open curChangeValues
> Fetch Next From curChangeValues
> Into @.iCOUNTSHDCHGS
> WHILE (@.@.fetch_status = 0)
> BEGIN
> if @.ICOUNTSHDCHGS > 0
> /* --- */
> /* THERE ARE CHANGED SHADE ID'S TO LOOK AT */
> /* GO AND GET THE RECORDS SO WE CAN LOOK */
> /* AT EACH ONE SEPARATELY */
> /* --- */
> declare curShadeChngVal scroll cursor for
> Select old_Shade_ID, old_property_ID,old_product_Subsegment_I
D
> From PPGG_Admin.UPC_Shades_Realigned
> Where shade_ID <> old_Shade_ID
> Open curShadeChngVal
> Fetch Next From curShadeChngVal
> Into @.old_shade_ID
> ,@.old_property_ID
> ,@.old_subseg_ID
> Select @.old_shade_ID
> ,@.old_property_ID
> ,@.old_subseg_ID
> WHILE (@.@.fetch_status =0)
> Begin
> /* ---*/
> /* DURING THE LOOP CHECK THE SUC TABLE
> TO SEE IF ANY UPCS STILL EXIST
> FOR THIS SHADE */
> /* ---*/
> DECLARE curSUCVal scroll cursor for
> Select Count(*) from Shade_SUC
> where Shade_ID = @.old_Shade_ID
> OPEN curSUCVal
> fetch next from curSUCVal
> into @.numSUCforShade
> if @.numSUCforShade > 0
> Begin
> --declare @.dan int
> --set @.dan =1
> delete from #shades_suc_bu where Shade_ID = @.old_Shade_ID
> end
> CLOSE curSUCVal
> Deallocate curSUCVal
> END
>
> end
> Close curChangeValues
> Deallocate curChangeValues
>
> GO
> SET QUOTED_IDENTIFIER OFF
> GO
> SET ANSI_NULLS ON
> GO
>

Friday, March 23, 2012

new sql server

hi,
i was wondering is it a good idea to use sata drive as a system\mssql
drive and scsi for data ant log files?
am i right that data and log files must be on raid 10'
one more q... if i want to have 300gb data on db how much Filegroups
should i use ?
how much disk drives should i use for best performance (7 or 8 as best
performance is achieve only if even no. of drives is used)?
thanx"benamis" <nera@.meilo.lt> wrote in message
news:OZtP$ixpFHA.3936@.TK2MSFTNGP10.phx.gbl...
> hi,
> i was wondering is it a good idea to use sata drive as a system\mssql
> drive and scsi for data ant log files?
> am i right that data and log files must be on raid 10'
> one more q... if i want to have 300gb data on db how much Filegroups
> should i use ?
> how much disk drives should i use for best performance (7 or 8 as best
> performance is achieve only if even no. of drives is used)?
> thanx
>
All of that depends!
SATA drives are find for the O/S and software. I'm not sure why you would
need those in addition to your SCSI drives. SCSI is generally going to have
double the throughput of comparable SATA drives.
As far as filegroups are concerned. Filegroups are used in two situations.
Situation 1 is to ease administration and allow for partial backups and
restores. Situation 2 is to create a poor mans RAID. If you already have
a RAID solution, then there is no reason to use filegroups to force
table-writes across multiple specific hard drives.
Now for best performance on drives. It depends? Is your application
primarily read only? If so, then a big RAID-5 would do the trick. Is your
application write intensive. Then some combination of data on RAID 0+1 and
logs on separate RAID 0+1. Do you have a single channel RAID controller or
dual channel?
All of this may be a moot point if you don't have enough RAM in your system.
Read up on performance and www.sql-server-performance.com
This should give you enough information to make better choices about your
given situation.
Rick Sawtell
MCT, MCSD, MCDBA|||thanx lots of info
Rick Sawtell wrote:
> "benamis" <nera@.meilo.lt> wrote in message
> news:OZtP$ixpFHA.3936@.TK2MSFTNGP10.phx.gbl...
>
>
> All of that depends!
> SATA drives are find for the O/S and software. I'm not sure why you would
> need those in addition to your SCSI drives. SCSI is generally going to ha
ve
> double the throughput of comparable SATA drives.
> As far as filegroups are concerned. Filegroups are used in two situations
.
> Situation 1 is to ease administration and allow for partial backups and
> restores. Situation 2 is to create a poor mans RAID. If you already hav
e
> a RAID solution, then there is no reason to use filegroups to force
> table-writes across multiple specific hard drives.
> Now for best performance on drives. It depends? Is your application
> primarily read only? If so, then a big RAID-5 would do the trick. Is you
r
> application write intensive. Then some combination of data on RAID 0+1 an
d
> logs on separate RAID 0+1. Do you have a single channel RAID controller
or
> dual channel?
> All of this may be a moot point if you don't have enough RAM in your syste
m.
>
> Read up on performance and www.sql-server-performance.com
>
> This should give you enough information to make better choices about your
> given situation.
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>

new sql server

hi,
i was wondering is it a good idea to use sata drive as a system\mssql
drive and scsi for data ant log files?
am i right that data and log files must be on raid 10?
one more q... if i want to have 300gb data on db how much Filegroups
should i use ?
how much disk drives should i use for best performance (7 or 8 as best
performance is achieve only if even no. of drives is used)?
thanx
"benamis" <nera@.meilo.lt> wrote in message
news:OZtP$ixpFHA.3936@.TK2MSFTNGP10.phx.gbl...
> hi,
> i was wondering is it a good idea to use sata drive as a system\mssql
> drive and scsi for data ant log files?
> am i right that data and log files must be on raid 10?
> one more q... if i want to have 300gb data on db how much Filegroups
> should i use ?
> how much disk drives should i use for best performance (7 or 8 as best
> performance is achieve only if even no. of drives is used)?
> thanx
>
All of that depends!
SATA drives are find for the O/S and software. I'm not sure why you would
need those in addition to your SCSI drives. SCSI is generally going to have
double the throughput of comparable SATA drives.
As far as filegroups are concerned. Filegroups are used in two situations.
Situation 1 is to ease administration and allow for partial backups and
restores. Situation 2 is to create a poor mans RAID. If you already have
a RAID solution, then there is no reason to use filegroups to force
table-writes across multiple specific hard drives.
Now for best performance on drives. It depends? Is your application
primarily read only? If so, then a big RAID-5 would do the trick. Is your
application write intensive. Then some combination of data on RAID 0+1 and
logs on separate RAID 0+1. Do you have a single channel RAID controller or
dual channel?
All of this may be a moot point if you don't have enough RAM in your system.
Read up on performance and www.sql-server-performance.com
This should give you enough information to make better choices about your
given situation.
Rick Sawtell
MCT, MCSD, MCDBA
|||thanx lots of info
Rick Sawtell wrote:
> "benamis" <nera@.meilo.lt> wrote in message
> news:OZtP$ixpFHA.3936@.TK2MSFTNGP10.phx.gbl...
>
> All of that depends!
> SATA drives are find for the O/S and software. I'm not sure why you would
> need those in addition to your SCSI drives. SCSI is generally going to have
> double the throughput of comparable SATA drives.
> As far as filegroups are concerned. Filegroups are used in two situations.
> Situation 1 is to ease administration and allow for partial backups and
> restores. Situation 2 is to create a poor mans RAID. If you already have
> a RAID solution, then there is no reason to use filegroups to force
> table-writes across multiple specific hard drives.
> Now for best performance on drives. It depends? Is your application
> primarily read only? If so, then a big RAID-5 would do the trick. Is your
> application write intensive. Then some combination of data on RAID 0+1 and
> logs on separate RAID 0+1. Do you have a single channel RAID controller or
> dual channel?
> All of this may be a moot point if you don't have enough RAM in your system.
>
> Read up on performance and www.sql-server-performance.com
>
> This should give you enough information to make better choices about your
> given situation.
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>

Wednesday, March 21, 2012

new sql server

hi,
i was wondering is it a good idea to use sata drive as a system\mssql
drive and scsi for data ant log files?
am i right that data and log files must be on raid 10'
one more q... if i want to have 300gb data on db how much Filegroups
should i use ?
how much disk drives should i use for best performance (7 or 8 as best
performance is achieve only if even no. of drives is used)?
thanx"benamis" <nera@.meilo.lt> wrote in message
news:OZtP$ixpFHA.3936@.TK2MSFTNGP10.phx.gbl...
> hi,
> i was wondering is it a good idea to use sata drive as a system\mssql
> drive and scsi for data ant log files?
> am i right that data and log files must be on raid 10'
> one more q... if i want to have 300gb data on db how much Filegroups
> should i use ?
> how much disk drives should i use for best performance (7 or 8 as best
> performance is achieve only if even no. of drives is used)?
> thanx
>
All of that depends!
SATA drives are find for the O/S and software. I'm not sure why you would
need those in addition to your SCSI drives. SCSI is generally going to have
double the throughput of comparable SATA drives.
As far as filegroups are concerned. Filegroups are used in two situations.
Situation 1 is to ease administration and allow for partial backups and
restores. Situation 2 is to create a poor mans RAID. If you already have
a RAID solution, then there is no reason to use filegroups to force
table-writes across multiple specific hard drives.
Now for best performance on drives. It depends? Is your application
primarily read only? If so, then a big RAID-5 would do the trick. Is your
application write intensive. Then some combination of data on RAID 0+1 and
logs on separate RAID 0+1. Do you have a single channel RAID controller or
dual channel?
All of this may be a moot point if you don't have enough RAM in your system.
Read up on performance and www.sql-server-performance.com
This should give you enough information to make better choices about your
given situation.
Rick Sawtell
MCT, MCSD, MCDBA|||thanx lots of info :)
Rick Sawtell wrote:
> "benamis" <nera@.meilo.lt> wrote in message
> news:OZtP$ixpFHA.3936@.TK2MSFTNGP10.phx.gbl...
>>hi,
>>i was wondering is it a good idea to use sata drive as a system\mssql
>>drive and scsi for data ant log files?
>>am i right that data and log files must be on raid 10'
>>one more q... if i want to have 300gb data on db how much Filegroups
>>should i use ?
>>how much disk drives should i use for best performance (7 or 8 as best
>>performance is achieve only if even no. of drives is used)?
>>thanx
>
> All of that depends!
> SATA drives are find for the O/S and software. I'm not sure why you would
> need those in addition to your SCSI drives. SCSI is generally going to have
> double the throughput of comparable SATA drives.
> As far as filegroups are concerned. Filegroups are used in two situations.
> Situation 1 is to ease administration and allow for partial backups and
> restores. Situation 2 is to create a poor mans RAID. If you already have
> a RAID solution, then there is no reason to use filegroups to force
> table-writes across multiple specific hard drives.
> Now for best performance on drives. It depends? Is your application
> primarily read only? If so, then a big RAID-5 would do the trick. Is your
> application write intensive. Then some combination of data on RAID 0+1 and
> logs on separate RAID 0+1. Do you have a single channel RAID controller or
> dual channel?
> All of this may be a moot point if you don't have enough RAM in your system.
>
> Read up on performance and www.sql-server-performance.com
>
> This should give you enough information to make better choices about your
> given situation.
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>

Wednesday, March 7, 2012

New idea to use the EXCEPT operator to paging

Last night, I have this idea, but can not know if it can have a good performance and efficiency when the @.CurrentPage is big.

--------------------

--DATABASE:AdventureWorks

DECLARE @.CurrentPage int
DECLARE @.PageSize int
DECLARE @.OrderExpression nvarchar(100)
DECLARE @.Sql nvarchar(500)

SET @.CurrentPage = 1
SET @.PageSize = 10
SET @.OrderExpression = N' employeeid '

DECLARE @.BigTop int
DECLARE @.SmallTop int
SET @.BigTop = @.CurrentPage * @.PageSize
SET @.SmallTop = (@.CurrentPage -1) * @.PageSize

DECLARE @.StartTime datetime
SET @.StartTime = GETDATE()

SET @.Sql = N' SELECT TOP (' + CAST(@.BigTop AS nvarchar(10)) + ') * FROM humanresources.Employee '
+ ' EXCEPT '
+ ' SELECT TOP (' + CAST(@.SmallTop AS nvarchar(10)) + ') * FROM humanresources.Employee ORDER BY ' + @.OrderExpression

EXEC sp_executesql @.Sql

DECLARE @.EndTime datetime
SET @.EndTime = GETDATE()

SELECT DATEPART(s,@.EndTime-@.StartTime)
SELECT DATEPART(ms,@.EndTime-@.StartTime)

GO

--------------------

It does get progressively slower as the number of records you are dealing with increases.

:(

|||

What's really needed in t-sql is this:

select ROWS 50 to 75 * from some_table order by some_column

It would remove the need for so many additional passes thru the data that other approaches require.

(And if someone knows a trick to do that, speak up now!)

|||

I have done some tests, comparee several different stored procedures, found this has a very good performance when the @.CurrentPage is less than 500 and @.PageSize = 10, in general use, this is enough.

dose anybody have interesting to do more test and post the result?

|||

Another way, by using the operator IN, can have an average speed when the @.CurrentPage is smaller and bigger, but when the @.CurrentPage is smaller, it is slower than not use "IN"
...

...

SELECT * FROM Employee WHERE employeeid IN (
SELECT TOP (@.BigTop) employeeid FROM Employee
EXCEPT
SELECT TOP (@.SmallTop) employeeid FROM Employee ORDER BY employeeid
)

...

...

|||

I made a new test,I copy the HumanResources.Employee table of AdventureWorks database to a new table, and add to about 200,000 rows,

test the performance of the following 3 different ways:

------1 start----------

DECLARE @.CurrentPage int
DECLARE @.PageSize int
DECLARE @.OrderExpression nvarchar(100)
DECLARE @.Sql nvarchar(500)

SET @.CurrentPage = 300
SET @.PageSize = 20
SET @.OrderExpression = N' employeeid '

DECLARE @.BigTop int
DECLARE @.SmallTop int
SET @.BigTop = @.CurrentPage * @.PageSize
SET @.SmallTop = (@.CurrentPage -1) * @.PageSize

/*
SET @.Sql = N' SELECT TOP (' + CAST(@.BigTop AS nvarchar(10)) + ') * FROM Employee '
+ ' EXCEPT '
+ ' SELECT TOP (' + CAST(@.SmallTop AS nvarchar(10)) + ') * FROM Employee ORDER BY ' + @.OrderExpression
*/

DECLARE @.StartTime datetime
SET @.StartTime = GETDATE()

SELECT TOP (@.BigTop) * FROM Employee
EXCEPT
SELECT TOP (@.SmallTop) * FROM Employee ORDER BY modifieddate

DECLARE @.EndTime datetime
SET @.EndTime = GETDATE()

SELECT DATEPART(s,@.EndTime-@.StartTime)
SELECT DATEPART(ms,@.EndTime-@.StartTime)

GO

------1 end----------

------2 start----------

DECLARE @.CurrentPage int
DECLARE @.PageSize int
DECLARE @.OrderExpression nvarchar(100)
DECLARE @.Sql nvarchar(500)

SET @.CurrentPage = 300
SET @.PageSize = 20
SET @.OrderExpression = N' employeeid '

DECLARE @.BigTop int
DECLARE @.SmallTop int
SET @.BigTop = @.CurrentPage * @.PageSize
SET @.SmallTop = (@.CurrentPage -1) * @.PageSize

/*
SET @.Sql = N' SELECT TOP (' + CAST(@.BigTop AS nvarchar(10)) + ') * FROM Employee '
+ ' EXCEPT '
+ ' SELECT TOP (' + CAST(@.SmallTop AS nvarchar(10)) + ') * FROM Employee ORDER BY ' + @.OrderExpression
*/

DECLARE @.StartTime datetime
SET @.StartTime = GETDATE()
SELECT * FROM Employee WHERE employeeid IN (
SELECT TOP (@.BigTop) employeeid FROM Employee
EXCEPT
SELECT TOP (@.SmallTop) employeeid FROM Employee ORDER BY employeeid
)

DECLARE @.EndTime datetime
SET @.EndTime = GETDATE()

SELECT DATEPART(s,@.EndTime-@.StartTime)
SELECT DATEPART(ms,@.EndTime-@.StartTime)

GO

------2 end----------

------3 start----------

DECLARE @.StartTime datetime
SET @.StartTime = GETDATE()
SELECT *
FROM (SELECT ROW_NUMBER() OVER (ORDER BY employeeid DESC)
AS Row, * FROM Employee)
AS LogWithRowNumbers
WHERE Row >= 6010 AND Row <= 6020

DECLARE @.EndTime datetime
SET @.EndTime = GETDATE()

SELECT DATEPART(s,@.EndTime-@.StartTime)
SELECT DATEPART(ms,@.EndTime-@.StartTime)

GO

------3 end----------

When the database has about 200,000 rows,

When @.CurrentPage*@.PageSize <=6000, the first way has good performance

When @.CurrentPage*@.PageSize >6000, the second way has good performance

The 3rd way had the worst performance.

ex. When @.CurrentPage = 100, @.PageSize = 10,

the 1st: 30ms,

the 2nd: 500ms

the 3rd: 4s and 400ms

-------------

But when I made another test that the database has about 30,000 rows,

the 3rd is the fastest, the 1st is the slowest


sorry to all for my bad english ;-p

|||

New test script

------Start--------

DECLARE @.CurrentPage int
DECLARE @.PageSize int

SET @.CurrentPage = 3000
SET @.PageSize = 10

DECLARE @.BigTop int
DECLARE @.SmallTop int
SET @.BigTop = @.CurrentPage * @.PageSize
SET @.SmallTop = (@.CurrentPage -1) * @.PageSize

DECLARE @.StartTime datetime
SET @.StartTime = GETDATE()

IF(SELECT COUNT(SalesOrderId) FROM Sales.SalesOrderHeader) < 40000 /* IF rows less than 40000 */
BEGIN
/*
WITH Rows AS
(
SELECT ROW_NUMBER() OVER (ORDER BY SalesOrderId DESC) AS Row, * FROM Sales.SalesOrderHeader
)
SELECT * FROM Rows
WHERE Row >= @.SmallTop AND Row <=@.BigTop
*/

SELECT *
FROM (SELECT ROW_NUMBER() OVER (ORDER BY SalesOrderId DESC)
AS Row, * FROM Sales.SalesOrderHeader)
AS Rows
WHERE Row BETWEEN @.SmallTop AND @.BigTop

END
ELSE
BEGIN
IF @.BigTop < 5000 /* IF @.CurrentPage*@.PageSize < 5000 Rows */
BEGIN
SELECT TOP (@.BigTop) * FROM Sales.SalesOrderHeader
EXCEPT
SELECT TOP (@.SmallTop) * FROM Sales.SalesOrderHeader ORDER BY SalesOrderId
END
ELSE
BEGIN
SELECT * FROM Sales.SalesOrderHeader WHERE SalesOrderId IN (
SELECT TOP (@.BigTop) SalesOrderId FROM Sales.SalesOrderHeader
EXCEPT
SELECT TOP (@.SmallTop) SalesOrderId FROM Sales.SalesOrderHeader ORDER BY SalesOrderId
)
END
END

DECLARE @.EndTime datetime
SET @.EndTime = GETDATE()

SELECT DATEPART(s,@.EndTime-@.StartTime)
SELECT DATEPART(ms,@.EndTime-@.StartTime)

GO

------End--------

Monday, February 20, 2012

New Database Server Advice

We are looking to upgrade our database server to gain additional speed.
I've come up with an idea of what we should get but wanted to get advice
from some experts to make sure my assumptions are accurate. Basically I
don't want to spend a bunch of my boss's money and not see any results. :-)
We are using MS SQL 2K on Window Server 2003
Our current server is a Zeon 3Ghz with 4G RAM
We have two main databases each about 25Gigs
The OS runs on one partition and the entire database runs on a single
partition (part of a Serial ATA RAID)
From my research mostly using perfmon, the bottle neck is always the disk,
we commonly have items queued and when the queue increases performance is
noticeably down. CPU speed has never been an issue. Therefore in a new
server I believe we should:
1. Use the maximum amount of RAM the server supports
2. Partition the databases by putting larger more active tables on they're
own physical drive as well as a sperate drive for SQL logs.
If this seems reasonable, I have a couple questions:
1. Is there a large performance difference between a SCSI RAID and Serial
ATA raid?
2. To evaluate disk systems should I look at drive RPM's, seek time, and
transfer rates? Am I missing something with this?
3. In addition to using separate drives when partitioning the database,
should I try to have separate interfaces to the motherboard. i.e. would it
make more sense to have two SCSI interfaces each with two drives instead of
one SCSI interface with four drives (from a performance standpoint) (Does
this logic apply to SATA systems?)
As a side note: I use the profiler tool with the SQLProfilerTuning Template,
then the index tuning wizard with default settings to generate our indexes.
If there is more I should be doing here, please let me know.
Any advice on any part of this is appreciated!1) Performace of disks has many factors, including the type of PCI bus the
card sits on, drive rpm, drive cache, I/O card cache, etc.
2) See 1 above. Get the maximum I/O card cache the card can have.
3) More interfaces is better up to the point where they exist on the same
PCI bus and saturate it.
4) More spindles is almost always better.
5) Go for at least 2 cores, preferably 4 or more. Do NOT enable
hyperthreading if you get CPUs that have it.
6) Avoid RAID 5 if possible for anything that has high writes, which always
includes tempdb and all transaction logs.
7) I avoid ITW. Have seen too many bad things come out of it.
--
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
"Bishop" <nospam@.nospam.com> wrote in message
news:Ogk%235o1NIHA.3516@.TK2MSFTNGP02.phx.gbl...
> We are looking to upgrade our database server to gain additional speed.
> I've come up with an idea of what we should get but wanted to get advice
> from some experts to make sure my assumptions are accurate. Basically I
> don't want to spend a bunch of my boss's money and not see any results.
> :-)
> We are using MS SQL 2K on Window Server 2003
> Our current server is a Zeon 3Ghz with 4G RAM
> We have two main databases each about 25Gigs
> The OS runs on one partition and the entire database runs on a single
> partition (part of a Serial ATA RAID)
> From my research mostly using perfmon, the bottle neck is always the disk,
> we commonly have items queued and when the queue increases performance is
> noticeably down. CPU speed has never been an issue. Therefore in a new
> server I believe we should:
> 1. Use the maximum amount of RAM the server supports
> 2. Partition the databases by putting larger more active tables on they're
> own physical drive as well as a sperate drive for SQL logs.
> If this seems reasonable, I have a couple questions:
> 1. Is there a large performance difference between a SCSI RAID and Serial
> ATA raid?
> 2. To evaluate disk systems should I look at drive RPM's, seek time, and
> transfer rates? Am I missing something with this?
> 3. In addition to using separate drives when partitioning the database,
> should I try to have separate interfaces to the motherboard. i.e. would
> it make more sense to have two SCSI interfaces each with two drives
> instead of one SCSI interface with four drives (from a performance
> standpoint) (Does this logic apply to SATA systems?)
> As a side note: I use the profiler tool with the SQLProfilerTuning
> Template, then the index tuning wizard with default settings to generate
> our indexes. If there is more I should be doing here, please let me know.
> Any advice on any part of this is appreciated!
>|||Thank You, this will give me plenty to look into!
Any thoughts on if ECC memory is really worth the money. I have several
servers that don't use ECC memory that get hit hard and never have problems?
"TheSQLGuru" <kgboles@.earthlink.net> wrote in message
news:13ldpj8nb3i5nf0@.corp.supernews.com...
> 1) Performace of disks has many factors, including the type of PCI bus the
> card sits on, drive rpm, drive cache, I/O card cache, etc.
> 2) See 1 above. Get the maximum I/O card cache the card can have.
> 3) More interfaces is better up to the point where they exist on the same
> PCI bus and saturate it.
> 4) More spindles is almost always better.
> 5) Go for at least 2 cores, preferably 4 or more. Do NOT enable
> hyperthreading if you get CPUs that have it.
> 6) Avoid RAID 5 if possible for anything that has high writes, which
> always includes tempdb and all transaction logs.
> 7) I avoid ITW. Have seen too many bad things come out of it.
> --
> Kevin G. Boles
> TheSQLGuru
> Indicium Resources, Inc.
>
> "Bishop" <nospam@.nospam.com> wrote in message
> news:Ogk%235o1NIHA.3516@.TK2MSFTNGP02.phx.gbl...
>> We are looking to upgrade our database server to gain additional speed.
>> I've come up with an idea of what we should get but wanted to get advice
>> from some experts to make sure my assumptions are accurate. Basically I
>> don't want to spend a bunch of my boss's money and not see any results.
>> :-)
>> We are using MS SQL 2K on Window Server 2003
>> Our current server is a Zeon 3Ghz with 4G RAM
>> We have two main databases each about 25Gigs
>> The OS runs on one partition and the entire database runs on a single
>> partition (part of a Serial ATA RAID)
>> From my research mostly using perfmon, the bottle neck is always the
>> disk, we commonly have items queued and when the queue increases
>> performance is noticeably down. CPU speed has never been an issue.
>> Therefore in a new server I believe we should:
>> 1. Use the maximum amount of RAM the server supports
>> 2. Partition the databases by putting larger more active tables on
>> they're own physical drive as well as a sperate drive for SQL logs.
>> If this seems reasonable, I have a couple questions:
>> 1. Is there a large performance difference between a SCSI RAID and Serial
>> ATA raid?
>> 2. To evaluate disk systems should I look at drive RPM's, seek time, and
>> transfer rates? Am I missing something with this?
>> 3. In addition to using separate drives when partitioning the database,
>> should I try to have separate interfaces to the motherboard. i.e. would
>> it make more sense to have two SCSI interfaces each with two drives
>> instead of one SCSI interface with four drives (from a performance
>> standpoint) (Does this logic apply to SATA systems?)
>> As a side note: I use the profiler tool with the SQLProfilerTuning
>> Template, then the index tuning wizard with default settings to generate
>> our indexes. If there is more I should be doing here, please let me know.
>> Any advice on any part of this is appreciated!
>|||I think ECC memory is more about keeping your data integrity. If you
consider that important it is indeed worth the money. :-)
--
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
"Bishop" <nospam@.nospam.com> wrote in message
news:uWbQ%23H4NIHA.4656@.TK2MSFTNGP03.phx.gbl...
> Thank You, this will give me plenty to look into!
> Any thoughts on if ECC memory is really worth the money. I have several
> servers that don't use ECC memory that get hit hard and never have
> problems?
> "TheSQLGuru" <kgboles@.earthlink.net> wrote in message
> news:13ldpj8nb3i5nf0@.corp.supernews.com...
>> 1) Performace of disks has many factors, including the type of PCI bus
>> the card sits on, drive rpm, drive cache, I/O card cache, etc.
>> 2) See 1 above. Get the maximum I/O card cache the card can have.
>> 3) More interfaces is better up to the point where they exist on the same
>> PCI bus and saturate it.
>> 4) More spindles is almost always better.
>> 5) Go for at least 2 cores, preferably 4 or more. Do NOT enable
>> hyperthreading if you get CPUs that have it.
>> 6) Avoid RAID 5 if possible for anything that has high writes, which
>> always includes tempdb and all transaction logs.
>> 7) I avoid ITW. Have seen too many bad things come out of it.
>> --
>> Kevin G. Boles
>> TheSQLGuru
>> Indicium Resources, Inc.
>>
>> "Bishop" <nospam@.nospam.com> wrote in message
>> news:Ogk%235o1NIHA.3516@.TK2MSFTNGP02.phx.gbl...
>> We are looking to upgrade our database server to gain additional speed.
>> I've come up with an idea of what we should get but wanted to get advice
>> from some experts to make sure my assumptions are accurate. Basically I
>> don't want to spend a bunch of my boss's money and not see any results.
>> :-)
>> We are using MS SQL 2K on Window Server 2003
>> Our current server is a Zeon 3Ghz with 4G RAM
>> We have two main databases each about 25Gigs
>> The OS runs on one partition and the entire database runs on a single
>> partition (part of a Serial ATA RAID)
>> From my research mostly using perfmon, the bottle neck is always the
>> disk, we commonly have items queued and when the queue increases
>> performance is noticeably down. CPU speed has never been an issue.
>> Therefore in a new server I believe we should:
>> 1. Use the maximum amount of RAM the server supports
>> 2. Partition the databases by putting larger more active tables on
>> they're own physical drive as well as a sperate drive for SQL logs.
>> If this seems reasonable, I have a couple questions:
>> 1. Is there a large performance difference between a SCSI RAID and
>> Serial ATA raid?
>> 2. To evaluate disk systems should I look at drive RPM's, seek time, and
>> transfer rates? Am I missing something with this?
>> 3. In addition to using separate drives when partitioning the database,
>> should I try to have separate interfaces to the motherboard. i.e. would
>> it make more sense to have two SCSI interfaces each with two drives
>> instead of one SCSI interface with four drives (from a performance
>> standpoint) (Does this logic apply to SATA systems?)
>> As a side note: I use the profiler tool with the SQLProfilerTuning
>> Template, then the index tuning wizard with default settings to generate
>> our indexes. If there is more I should be doing here, please let me
>> know.
>> Any advice on any part of this is appreciated!
>>
>

New Database Server Advice

We are looking to upgrade our database server to gain additional speed.
I've come up with an idea of what we should get but wanted to get advice
from some experts to make sure my assumptions are accurate. Basically I
don't want to spend a bunch of my boss's money and not see any results. :-)
We are using MS SQL 2K on Window Server 2003
Our current server is a Zeon 3Ghz with 4G RAM
We have two main databases each about 25Gigs
The OS runs on one partition and the entire database runs on a single
partition (part of a Serial ATA RAID)
From my research mostly using perfmon, the bottle neck is always the disk,
we commonly have items queued and when the queue increases performance is
noticeably down. CPU speed has never been an issue. Therefore in a new
server I believe we should:
1. Use the maximum amount of RAM the server supports
2. Partition the databases by putting larger more active tables on they're
own physical drive as well as a sperate drive for SQL logs.
If this seems reasonable, I have a couple questions:
1. Is there a large performance difference between a SCSI RAID and Serial
ATA raid?
2. To evaluate disk systems should I look at drive RPM's, seek time, and
transfer rates? Am I missing something with this?
3. In addition to using separate drives when partitioning the database,
should I try to have separate interfaces to the motherboard. i.e. would it
make more sense to have two SCSI interfaces each with two drives instead of
one SCSI interface with four drives (from a performance standpoint) (Does
this logic apply to SATA systems?)
As a side note: I use the profiler tool with the SQLProfilerTuning Template,
then the index tuning wizard with default settings to generate our indexes.
If there is more I should be doing here, please let me know.
Any advice on any part of this is appreciated!
1) Performace of disks has many factors, including the type of PCI bus the
card sits on, drive rpm, drive cache, I/O card cache, etc.
2) See 1 above. Get the maximum I/O card cache the card can have.
3) More interfaces is better up to the point where they exist on the same
PCI bus and saturate it.
4) More spindles is almost always better.
5) Go for at least 2 cores, preferably 4 or more. Do NOT enable
hyperthreading if you get CPUs that have it.
6) Avoid RAID 5 if possible for anything that has high writes, which always
includes tempdb and all transaction logs.
7) I avoid ITW. Have seen too many bad things come out of it.
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
"Bishop" <nospam@.nospam.com> wrote in message
news:Ogk%235o1NIHA.3516@.TK2MSFTNGP02.phx.gbl...
> We are looking to upgrade our database server to gain additional speed.
> I've come up with an idea of what we should get but wanted to get advice
> from some experts to make sure my assumptions are accurate. Basically I
> don't want to spend a bunch of my boss's money and not see any results.
> :-)
> We are using MS SQL 2K on Window Server 2003
> Our current server is a Zeon 3Ghz with 4G RAM
> We have two main databases each about 25Gigs
> The OS runs on one partition and the entire database runs on a single
> partition (part of a Serial ATA RAID)
> From my research mostly using perfmon, the bottle neck is always the disk,
> we commonly have items queued and when the queue increases performance is
> noticeably down. CPU speed has never been an issue. Therefore in a new
> server I believe we should:
> 1. Use the maximum amount of RAM the server supports
> 2. Partition the databases by putting larger more active tables on they're
> own physical drive as well as a sperate drive for SQL logs.
> If this seems reasonable, I have a couple questions:
> 1. Is there a large performance difference between a SCSI RAID and Serial
> ATA raid?
> 2. To evaluate disk systems should I look at drive RPM's, seek time, and
> transfer rates? Am I missing something with this?
> 3. In addition to using separate drives when partitioning the database,
> should I try to have separate interfaces to the motherboard. i.e. would
> it make more sense to have two SCSI interfaces each with two drives
> instead of one SCSI interface with four drives (from a performance
> standpoint) (Does this logic apply to SATA systems?)
> As a side note: I use the profiler tool with the SQLProfilerTuning
> Template, then the index tuning wizard with default settings to generate
> our indexes. If there is more I should be doing here, please let me know.
> Any advice on any part of this is appreciated!
>
|||Thank You, this will give me plenty to look into!
Any thoughts on if ECC memory is really worth the money. I have several
servers that don't use ECC memory that get hit hard and never have problems?
"TheSQLGuru" <kgboles@.earthlink.net> wrote in message
news:13ldpj8nb3i5nf0@.corp.supernews.com...
> 1) Performace of disks has many factors, including the type of PCI bus the
> card sits on, drive rpm, drive cache, I/O card cache, etc.
> 2) See 1 above. Get the maximum I/O card cache the card can have.
> 3) More interfaces is better up to the point where they exist on the same
> PCI bus and saturate it.
> 4) More spindles is almost always better.
> 5) Go for at least 2 cores, preferably 4 or more. Do NOT enable
> hyperthreading if you get CPUs that have it.
> 6) Avoid RAID 5 if possible for anything that has high writes, which
> always includes tempdb and all transaction logs.
> 7) I avoid ITW. Have seen too many bad things come out of it.
> --
> Kevin G. Boles
> TheSQLGuru
> Indicium Resources, Inc.
>
> "Bishop" <nospam@.nospam.com> wrote in message
> news:Ogk%235o1NIHA.3516@.TK2MSFTNGP02.phx.gbl...
>
|||I think ECC memory is more about keeping your data integrity. If you
consider that important it is indeed worth the money. :-)
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
"Bishop" <nospam@.nospam.com> wrote in message
news:uWbQ%23H4NIHA.4656@.TK2MSFTNGP03.phx.gbl...
> Thank You, this will give me plenty to look into!
> Any thoughts on if ECC memory is really worth the money. I have several
> servers that don't use ECC memory that get hit hard and never have
> problems?
> "TheSQLGuru" <kgboles@.earthlink.net> wrote in message
> news:13ldpj8nb3i5nf0@.corp.supernews.com...
>

New Database Server Advice

We are looking to upgrade our database server to gain additional speed.
I've come up with an idea of what we should get but wanted to get advice
from some experts to make sure my assumptions are accurate. Basically I
don't want to spend a bunch of my boss's money and not see any results. :-)
We are using MS SQL 2K on Window Server 2003
Our current server is a Zeon 3Ghz with 4G RAM
We have two main databases each about 25Gigs
The OS runs on one partition and the entire database runs on a single
partition (part of a Serial ATA RAID)
From my research mostly using perfmon, the bottle neck is always the disk,
we commonly have items queued and when the queue increases performance is
noticeably down. CPU speed has never been an issue. Therefore in a new
server I believe we should:
1. Use the maximum amount of RAM the server supports
2. Partition the databases by putting larger more active tables on they're
own physical drive as well as a sperate drive for SQL logs.
If this seems reasonable, I have a couple questions:
1. Is there a large performance difference between a SCSI RAID and Serial
ATA raid?
2. To evaluate disk systems should I look at drive RPM's, seek time, and
transfer rates? Am I missing something with this?
3. In addition to using separate drives when partitioning the database,
should I try to have separate interfaces to the motherboard. i.e. would it
make more sense to have two SCSI interfaces each with two drives instead of
one SCSI interface with four drives (from a performance standpoint) (Does
this logic apply to SATA systems?)
As a side note: I use the profiler tool with the SQLProfilerTuning Template,
then the index tuning wizard with default settings to generate our indexes.
If there is more I should be doing here, please let me know.
Any advice on any part of this is appreciated!1) Performace of disks has many factors, including the type of PCI bus the
card sits on, drive rpm, drive cache, I/O card cache, etc.
2) See 1 above. Get the maximum I/O card cache the card can have.
3) More interfaces is better up to the point where they exist on the same
PCI bus and saturate it.
4) More spindles is almost always better.
5) Go for at least 2 cores, preferably 4 or more. Do NOT enable
hyperthreading if you get CPUs that have it.
6) Avoid RAID 5 if possible for anything that has high writes, which always
includes tempdb and all transaction logs.
7) I avoid ITW. Have seen too many bad things come out of it.
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
"Bishop" <nospam@.nospam.com> wrote in message
news:Ogk%235o1NIHA.3516@.TK2MSFTNGP02.phx.gbl...
> We are looking to upgrade our database server to gain additional speed.
> I've come up with an idea of what we should get but wanted to get advice
> from some experts to make sure my assumptions are accurate. Basically I
> don't want to spend a bunch of my boss's money and not see any results.
> :-)
> We are using MS SQL 2K on Window Server 2003
> Our current server is a Zeon 3Ghz with 4G RAM
> We have two main databases each about 25Gigs
> The OS runs on one partition and the entire database runs on a single
> partition (part of a Serial ATA RAID)
> From my research mostly using perfmon, the bottle neck is always the disk,
> we commonly have items queued and when the queue increases performance is
> noticeably down. CPU speed has never been an issue. Therefore in a new
> server I believe we should:
> 1. Use the maximum amount of RAM the server supports
> 2. Partition the databases by putting larger more active tables on they're
> own physical drive as well as a sperate drive for SQL logs.
> If this seems reasonable, I have a couple questions:
> 1. Is there a large performance difference between a SCSI RAID and Serial
> ATA raid?
> 2. To evaluate disk systems should I look at drive RPM's, seek time, and
> transfer rates? Am I missing something with this?
> 3. In addition to using separate drives when partitioning the database,
> should I try to have separate interfaces to the motherboard. i.e. would
> it make more sense to have two SCSI interfaces each with two drives
> instead of one SCSI interface with four drives (from a performance
> standpoint) (Does this logic apply to SATA systems?)
> As a side note: I use the profiler tool with the SQLProfilerTuning
> Template, then the index tuning wizard with default settings to generate
> our indexes. If there is more I should be doing here, please let me know.
> Any advice on any part of this is appreciated!
>|||Thank You, this will give me plenty to look into!
Any thoughts on if ECC memory is really worth the money. I have several
servers that don't use ECC memory that get hit hard and never have problems?
"TheSQLGuru" <kgboles@.earthlink.net> wrote in message
news:13ldpj8nb3i5nf0@.corp.supernews.com...
> 1) Performace of disks has many factors, including the type of PCI bus the
> card sits on, drive rpm, drive cache, I/O card cache, etc.
> 2) See 1 above. Get the maximum I/O card cache the card can have.
> 3) More interfaces is better up to the point where they exist on the same
> PCI bus and saturate it.
> 4) More spindles is almost always better.
> 5) Go for at least 2 cores, preferably 4 or more. Do NOT enable
> hyperthreading if you get CPUs that have it.
> 6) Avoid RAID 5 if possible for anything that has high writes, which
> always includes tempdb and all transaction logs.
> 7) I avoid ITW. Have seen too many bad things come out of it.
> --
> Kevin G. Boles
> TheSQLGuru
> Indicium Resources, Inc.
>
> "Bishop" <nospam@.nospam.com> wrote in message
> news:Ogk%235o1NIHA.3516@.TK2MSFTNGP02.phx.gbl...
>|||I think ECC memory is more about keeping your data integrity. If you
consider that important it is indeed worth the money. :-)
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
"Bishop" <nospam@.nospam.com> wrote in message
news:uWbQ%23H4NIHA.4656@.TK2MSFTNGP03.phx.gbl...
> Thank You, this will give me plenty to look into!
> Any thoughts on if ECC memory is really worth the money. I have several
> servers that don't use ECC memory that get hit hard and never have
> problems?
> "TheSQLGuru" <kgboles@.earthlink.net> wrote in message
> news:13ldpj8nb3i5nf0@.corp.supernews.com...
>