I am setting up a server that will be a dedicated database server. I don't have much flexibility in choosing a server, and the servers we use are limited to six disk drives. There will be only one user database on the server, aside from the system databases. Everything I have read indicates it is better to place the transaction log file on a separate disk array from the data files. I could put the transaction log file on a mirrored disk array (RAID 1) and then put the data file on a RAID 10 array of four disks. But where would I put the OS and SQL binaries? The application in question is fairly write-intensive, and does not perform well in a RAID 5 array. In the past, we placed everything (OS, data, logs, etc.) on the same RAID 5 array. It is apparent that this configuration is not going to work, or at least it won't scale very well. My questions are as follows:
1) How much write activity is generated by the transaction log? Will I see a tangible performance benefit by separating the log file onto its own physical array?
2) What would be the optimal RAID configuration for the above scenario, while limited to six drives?
3) What would be the optimal RAID configuration if I had more that one user database on the same server, with the six drive limit?
Any help would be very much appreciated.As a GENERAL rule, you want to seperate your log files, databases and indexs from each other. In your case I doubt if you will have much oppertunity to optimize your hardware.
IMnsHO, I would put the os, binaries and logs on the RAID 1 drives and db et all on the RAID 10 drives. I suspect you have a single channel controler so watch disk I/O as I would bet you will have a bottleneck here. If you have a dual channel controler put the RAID 1 on one channel and the RAID 10 on the other.
Your question...
1) Every write to a table will generate a write to the transaction log even in Simple mode! Putting your logs on a RAID one drive will increase performance on a write intensive db.
2) It is more a question of RAID configuration and controler configuration. Unless you have a dual channel controler you aren't going to see much of a performance increase. Switching from RAID 5 to RAID 1 & 10 will help. Make sure the data cache on the controler is optimized for more writes than reads.
3) Get a three channel controler, channel one for the RAID 1 drives, channel two and three for the RAID 10 drives, mirror across the two channels so the strip stays on one channel.
Showing posts with label configuration. Show all posts
Showing posts with label configuration. Show all posts
Friday, March 23, 2012
Monday, March 12, 2012
optimal location for database files on SAN?
Hi, we have 2 sql servers that will have all their system databases/user
databases/log files located to a san. what is the best configuration?
note: sql1 performs transactional replication to sql2 (which is used for
reporting):
we have 2 x RAID 1 and 1 x RAID 5. I was thinking:
RAID 1: sql2 user + system data files
RAID 1: Logs (from both sql1 and sql2)
RAID 5: sql1 user + system data files
if I could get access to another RAID 1 how would this sound:
RAID 1: sql2 user + system data files
RAID 1: Logs (from both sql1 and sql2)
RAID 1: tempdb (from both sql1 and sql2)
RAID 5: sql1 user + system data files
Would both servers share the same tempdb? or would there be two instances?
since sql1 replicates to sql2, having all the logs on the same RAID 1 would
increase replication speed?
Any help most appreciated!
thanks, johni will have access to initially 9 hdd's to build my config, but i might
possibly get a hold of more. any help most appreciated! ciao john
"john r" <johnr@.trailer.com> wrote in message
news:uSqTyAS6FHA.2364@.TK2MSFTNGP12.phx.gbl...
> Hi, we have 2 sql servers that will have all their system databases/user
> databases/log files located to a san. what is the best configuration?
> note: sql1 performs transactional replication to sql2 (which is used for
> reporting):
> we have 2 x RAID 1 and 1 x RAID 5. I was thinking:
> RAID 1: sql2 user + system data files
> RAID 1: Logs (from both sql1 and sql2)
> RAID 5: sql1 user + system data files
> if I could get access to another RAID 1 how would this sound:
> RAID 1: sql2 user + system data files
> RAID 1: Logs (from both sql1 and sql2)
> RAID 1: tempdb (from both sql1 and sql2)
> RAID 5: sql1 user + system data files
> Would both servers share the same tempdb? or would there be two instances?
> since sql1 replicates to sql2, having all the logs on the same RAID 1
> would increase replication speed?
> Any help most appreciated!
> thanks, john
>|||I am not sure if I hit enter or lost the page. I tried an earlier response
Anyway, I suggest Mirroring your OS drive and a Binaries Drive witht the SAN
used for all the data files.
I like mirroring, but that is a bias others will contest.
Without knowing your SAN, I can't say much more. Some SANs don't give you
enough control to worry about RAID levels.
The real question is how many LUNs to the SAN?
--
Joseph R.P. Maloney, CSP,CCP,CDP
"john r" wrote:
> i will have access to initially 9 hdd's to build my config, but i might
> possibly get a hold of more. any help most appreciated! ciao john
>
> "john r" <johnr@.trailer.com> wrote in message
> news:uSqTyAS6FHA.2364@.TK2MSFTNGP12.phx.gbl...
> > Hi, we have 2 sql servers that will have all their system databases/user
> > databases/log files located to a san. what is the best configuration?
> >
> > note: sql1 performs transactional replication to sql2 (which is used for
> > reporting):
> >
> > we have 2 x RAID 1 and 1 x RAID 5. I was thinking:
> >
> > RAID 1: sql2 user + system data files
> > RAID 1: Logs (from both sql1 and sql2)
> > RAID 5: sql1 user + system data files
> >
> > if I could get access to another RAID 1 how would this sound:
> >
> > RAID 1: sql2 user + system data files
> > RAID 1: Logs (from both sql1 and sql2)
> > RAID 1: tempdb (from both sql1 and sql2)
> > RAID 5: sql1 user + system data files
> >
> > Would both servers share the same tempdb? or would there be two instances?
> >
> > since sql1 replicates to sql2, having all the logs on the same RAID 1
> > would increase replication speed?
> >
> > Any help most appreciated!
> > thanks, john
> >
>
>|||The primary question for me is how many LUNs do you have.
I like Raid 0+1 (mirroring) rather than Raid-5 and all. Personal bias.
I would look to configure as follows:
Logical C: Mirror, OS files
Logical D: Mirror, Application (including SS) binaries
Logical E; SAN-data and log files.
This presumes 1 LUN, probably fiber, to the SAN.
As I said, I like mirroring. Without knowing which SAN you are using,
though, it is difficult to give advice (foot in mouth?) there. Some SANS do
not give you
--
Joseph R.P. Maloney, CSP,CCP,CDP
"john r" wrote:
> i will have access to initially 9 hdd's to build my config, but i might
> possibly get a hold of more. any help most appreciated! ciao john
>
> "john r" <johnr@.trailer.com> wrote in message
> news:uSqTyAS6FHA.2364@.TK2MSFTNGP12.phx.gbl...
> > Hi, we have 2 sql servers that will have all their system databases/user
> > databases/log files located to a san. what is the best configuration?
> >
> > note: sql1 performs transactional replication to sql2 (which is used for
> > reporting):
> >
> > we have 2 x RAID 1 and 1 x RAID 5. I was thinking:
> >
> > RAID 1: sql2 user + system data files
> > RAID 1: Logs (from both sql1 and sql2)
> > RAID 5: sql1 user + system data files
> >
> > if I could get access to another RAID 1 how would this sound:
> >
> > RAID 1: sql2 user + system data files
> > RAID 1: Logs (from both sql1 and sql2)
> > RAID 1: tempdb (from both sql1 and sql2)
> > RAID 5: sql1 user + system data files
> >
> > Would both servers share the same tempdb? or would there be two instances?
> >
> > since sql1 replicates to sql2, having all the logs on the same RAID 1
> > would increase replication speed?
> >
> > Any help most appreciated!
> > thanks, john
> >
>
>|||I believe it is going to depend on the size of your databases and what they
are used for. Are they creating a lot of temp tables in the temp database?
if so, then temp needs two RAID1 volumes, 1 for data, 1 for logs.
Also, whatever config you end up with, separate the log files from the data
files.
Another thing to consider if you have it available is to use RAID1 or RAID10
on your databases. RAID5 is too expensive on the write operation for your
heavily used databases.
I hope this helps.
"john r" <johnr@.trailer.com> wrote in message
news:uSqTyAS6FHA.2364@.TK2MSFTNGP12.phx.gbl...
> Hi, we have 2 sql servers that will have all their system databases/user
> databases/log files located to a san. what is the best configuration?
> note: sql1 performs transactional replication to sql2 (which is used for
> reporting):
> we have 2 x RAID 1 and 1 x RAID 5. I was thinking:
> RAID 1: sql2 user + system data files
> RAID 1: Logs (from both sql1 and sql2)
> RAID 5: sql1 user + system data files
> if I could get access to another RAID 1 how would this sound:
> RAID 1: sql2 user + system data files
> RAID 1: Logs (from both sql1 and sql2)
> RAID 1: tempdb (from both sql1 and sql2)
> RAID 5: sql1 user + system data files
> Would both servers share the same tempdb? or would there be two instances?
> since sql1 replicates to sql2, having all the logs on the same RAID 1
> would increase replication speed?
> Any help most appreciated!
> thanks, john
>
databases/log files located to a san. what is the best configuration?
note: sql1 performs transactional replication to sql2 (which is used for
reporting):
we have 2 x RAID 1 and 1 x RAID 5. I was thinking:
RAID 1: sql2 user + system data files
RAID 1: Logs (from both sql1 and sql2)
RAID 5: sql1 user + system data files
if I could get access to another RAID 1 how would this sound:
RAID 1: sql2 user + system data files
RAID 1: Logs (from both sql1 and sql2)
RAID 1: tempdb (from both sql1 and sql2)
RAID 5: sql1 user + system data files
Would both servers share the same tempdb? or would there be two instances?
since sql1 replicates to sql2, having all the logs on the same RAID 1 would
increase replication speed?
Any help most appreciated!
thanks, johni will have access to initially 9 hdd's to build my config, but i might
possibly get a hold of more. any help most appreciated! ciao john
"john r" <johnr@.trailer.com> wrote in message
news:uSqTyAS6FHA.2364@.TK2MSFTNGP12.phx.gbl...
> Hi, we have 2 sql servers that will have all their system databases/user
> databases/log files located to a san. what is the best configuration?
> note: sql1 performs transactional replication to sql2 (which is used for
> reporting):
> we have 2 x RAID 1 and 1 x RAID 5. I was thinking:
> RAID 1: sql2 user + system data files
> RAID 1: Logs (from both sql1 and sql2)
> RAID 5: sql1 user + system data files
> if I could get access to another RAID 1 how would this sound:
> RAID 1: sql2 user + system data files
> RAID 1: Logs (from both sql1 and sql2)
> RAID 1: tempdb (from both sql1 and sql2)
> RAID 5: sql1 user + system data files
> Would both servers share the same tempdb? or would there be two instances?
> since sql1 replicates to sql2, having all the logs on the same RAID 1
> would increase replication speed?
> Any help most appreciated!
> thanks, john
>|||I am not sure if I hit enter or lost the page. I tried an earlier response
Anyway, I suggest Mirroring your OS drive and a Binaries Drive witht the SAN
used for all the data files.
I like mirroring, but that is a bias others will contest.
Without knowing your SAN, I can't say much more. Some SANs don't give you
enough control to worry about RAID levels.
The real question is how many LUNs to the SAN?
--
Joseph R.P. Maloney, CSP,CCP,CDP
"john r" wrote:
> i will have access to initially 9 hdd's to build my config, but i might
> possibly get a hold of more. any help most appreciated! ciao john
>
> "john r" <johnr@.trailer.com> wrote in message
> news:uSqTyAS6FHA.2364@.TK2MSFTNGP12.phx.gbl...
> > Hi, we have 2 sql servers that will have all their system databases/user
> > databases/log files located to a san. what is the best configuration?
> >
> > note: sql1 performs transactional replication to sql2 (which is used for
> > reporting):
> >
> > we have 2 x RAID 1 and 1 x RAID 5. I was thinking:
> >
> > RAID 1: sql2 user + system data files
> > RAID 1: Logs (from both sql1 and sql2)
> > RAID 5: sql1 user + system data files
> >
> > if I could get access to another RAID 1 how would this sound:
> >
> > RAID 1: sql2 user + system data files
> > RAID 1: Logs (from both sql1 and sql2)
> > RAID 1: tempdb (from both sql1 and sql2)
> > RAID 5: sql1 user + system data files
> >
> > Would both servers share the same tempdb? or would there be two instances?
> >
> > since sql1 replicates to sql2, having all the logs on the same RAID 1
> > would increase replication speed?
> >
> > Any help most appreciated!
> > thanks, john
> >
>
>|||The primary question for me is how many LUNs do you have.
I like Raid 0+1 (mirroring) rather than Raid-5 and all. Personal bias.
I would look to configure as follows:
Logical C: Mirror, OS files
Logical D: Mirror, Application (including SS) binaries
Logical E; SAN-data and log files.
This presumes 1 LUN, probably fiber, to the SAN.
As I said, I like mirroring. Without knowing which SAN you are using,
though, it is difficult to give advice (foot in mouth?) there. Some SANS do
not give you
--
Joseph R.P. Maloney, CSP,CCP,CDP
"john r" wrote:
> i will have access to initially 9 hdd's to build my config, but i might
> possibly get a hold of more. any help most appreciated! ciao john
>
> "john r" <johnr@.trailer.com> wrote in message
> news:uSqTyAS6FHA.2364@.TK2MSFTNGP12.phx.gbl...
> > Hi, we have 2 sql servers that will have all their system databases/user
> > databases/log files located to a san. what is the best configuration?
> >
> > note: sql1 performs transactional replication to sql2 (which is used for
> > reporting):
> >
> > we have 2 x RAID 1 and 1 x RAID 5. I was thinking:
> >
> > RAID 1: sql2 user + system data files
> > RAID 1: Logs (from both sql1 and sql2)
> > RAID 5: sql1 user + system data files
> >
> > if I could get access to another RAID 1 how would this sound:
> >
> > RAID 1: sql2 user + system data files
> > RAID 1: Logs (from both sql1 and sql2)
> > RAID 1: tempdb (from both sql1 and sql2)
> > RAID 5: sql1 user + system data files
> >
> > Would both servers share the same tempdb? or would there be two instances?
> >
> > since sql1 replicates to sql2, having all the logs on the same RAID 1
> > would increase replication speed?
> >
> > Any help most appreciated!
> > thanks, john
> >
>
>|||I believe it is going to depend on the size of your databases and what they
are used for. Are they creating a lot of temp tables in the temp database?
if so, then temp needs two RAID1 volumes, 1 for data, 1 for logs.
Also, whatever config you end up with, separate the log files from the data
files.
Another thing to consider if you have it available is to use RAID1 or RAID10
on your databases. RAID5 is too expensive on the write operation for your
heavily used databases.
I hope this helps.
"john r" <johnr@.trailer.com> wrote in message
news:uSqTyAS6FHA.2364@.TK2MSFTNGP12.phx.gbl...
> Hi, we have 2 sql servers that will have all their system databases/user
> databases/log files located to a san. what is the best configuration?
> note: sql1 performs transactional replication to sql2 (which is used for
> reporting):
> we have 2 x RAID 1 and 1 x RAID 5. I was thinking:
> RAID 1: sql2 user + system data files
> RAID 1: Logs (from both sql1 and sql2)
> RAID 5: sql1 user + system data files
> if I could get access to another RAID 1 how would this sound:
> RAID 1: sql2 user + system data files
> RAID 1: Logs (from both sql1 and sql2)
> RAID 1: tempdb (from both sql1 and sql2)
> RAID 5: sql1 user + system data files
> Would both servers share the same tempdb? or would there be two instances?
> since sql1 replicates to sql2, having all the logs on the same RAID 1
> would increase replication speed?
> Any help most appreciated!
> thanks, john
>
Optimal disk configuration for SQL
I think that RAID5 is still sort of the default for the main database
for average conditions, because it is more efficient in the use of
disk, when you get up to four or more drives, and it may be better for
reads, and average tables in average databases do 99% reads.
But, most apps may have a few more actively written tables, which
might be best on a filegroup and/or database on a RAID10 drive
instead.
I'm having my conscious raised on a number of hardware and
configurations issues these days myself.
Josh
On Sat, 03 Mar 2007 09:05:52 +0100, sp <kofa@.noemail.noemail> wrote:
>sp napisa?(a):
>
>what do you think about this configuration?
Hello KoFa,
The default Stripe Element Size for your hardware configuration is
recommanded. For example, in the Dell EMC white paper, it recommanded to
use the default size 128 blocks or 64 KB
Here are some article for you to refer:
http://www.dell.com/downloads/global/solutions/dell_emc_sap_bestpractice.pdf
http://forums.dantz.com/ubbthreads/showflat.php?Number=93175&page=0
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
|||Hi ,
How is everything going? Please feel free to let me know if you need any
assistance.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
for average conditions, because it is more efficient in the use of
disk, when you get up to four or more drives, and it may be better for
reads, and average tables in average databases do 99% reads.
But, most apps may have a few more actively written tables, which
might be best on a filegroup and/or database on a RAID10 drive
instead.
I'm having my conscious raised on a number of hardware and
configurations issues these days myself.
Josh
On Sat, 03 Mar 2007 09:05:52 +0100, sp <kofa@.noemail.noemail> wrote:
>sp napisa?(a):
>
>what do you think about this configuration?
Hello KoFa,
The default Stripe Element Size for your hardware configuration is
recommanded. For example, in the Dell EMC white paper, it recommanded to
use the default size 128 blocks or 64 KB
Here are some article for you to refer:
http://www.dell.com/downloads/global/solutions/dell_emc_sap_bestpractice.pdf
http://forums.dantz.com/ubbthreads/showflat.php?Number=93175&page=0
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
|||Hi ,
How is everything going? Please feel free to let me know if you need any
assistance.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Optimal disk configuration for SQL
Optimal disk configuration for SQL
I think it is:
For datafiles (RAID10)
Stripe Element Size 8KB â' because page has 8 KB
Read Policy: No read Ahead (there is a choose beetwen read ahead i
adaptive read ahead)
Write Policy: Write Back (there is a choose beetwen Write Through i
Force Write Back)
For log files as above but RAID1sp napisaÅ?(a):
> Optimal disk configuration for SQL
> I think it is:
> For datafiles (RAID10)
> Stripe Element Size 8KB â' because page has 8 KB
> Read Policy: No read Ahead (there is a choose beetwen read ahead i
> adaptive read ahead)
> Write Policy: Write Back (there is a choose beetwen Write Through i
> Force Write Back)
>
> For log files as above but RAID1
what do you think about this configuration?|||I think that RAID5 is still sort of the default for the main database
for average conditions, because it is more efficient in the use of
disk, when you get up to four or more drives, and it may be better for
reads, and average tables in average databases do 99% reads.
But, most apps may have a few more actively written tables, which
might be best on a filegroup and/or database on a RAID10 drive
instead.
I'm having my conscious raised on a number of hardware and
configurations issues these days myself.
Josh
On Sat, 03 Mar 2007 09:05:52 +0100, sp <kofa@.noemail.noemail> wrote:
>sp napisa?(a):
>> Optimal disk configuration for SQL
>> I think it is:
>> For datafiles (RAID10)
>> Stripe Element Size 8KB ? because page has 8 KB
>> Read Policy: No read Ahead (there is a choose beetwen read ahead i
>> adaptive read ahead)
>> Write Policy: Write Back (there is a choose beetwen Write Through i
>> Force Write Back)
>>
>> For log files as above but RAID1
>
>what do you think about this configuration?|||What is about Stripe Element Size in RAID 10 or 5 '
JXStern napisaÅ?(a):
> I think that RAID5 is still sort of the default for the main database
> for average conditions, because it is more efficient in the use of
> disk, when you get up to four or more drives, and it may be better for
> reads, and average tables in average databases do 99% reads.
> But, most apps may have a few more actively written tables, which
> might be best on a filegroup and/or database on a RAID10 drive
> instead.
> I'm having my conscious raised on a number of hardware and
> configurations issues these days myself.
> Josh
>
> On Sat, 03 Mar 2007 09:05:52 +0100, sp <kofa@.noemail.noemail> wrote:
>> sp napisa?(a):
>> Optimal disk configuration for SQL
>> I think it is:
>> For datafiles (RAID10)
>> Stripe Element Size 8KB â' because page has 8 KB
>> Read Policy: No read Ahead (there is a choose beetwen read ahead i
>> adaptive read ahead)
>> Write Policy: Write Back (there is a choose beetwen Write Through i
>> Force Write Back)
>>
>> For log files as above but RAID1
>> what do you think about this configuration?
>|||Hello KoFa,
The default Stripe Element Size for your hardware configuration is
recommanded. For example, in the Dell EMC white paper, it recommanded to
use the default size 128 blocks or 64 KB
Here are some article for you to refer:
http://www.dell.com/downloads/global/solutions/dell_emc_sap_bestpractice.pdf
http://forums.dantz.com/ubbthreads/showflat.php?Number=93175&page=0
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Hi ,
How is everything going? Please feel free to let me know if you need any
assistance.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.
I think it is:
For datafiles (RAID10)
Stripe Element Size 8KB â' because page has 8 KB
Read Policy: No read Ahead (there is a choose beetwen read ahead i
adaptive read ahead)
Write Policy: Write Back (there is a choose beetwen Write Through i
Force Write Back)
For log files as above but RAID1sp napisaÅ?(a):
> Optimal disk configuration for SQL
> I think it is:
> For datafiles (RAID10)
> Stripe Element Size 8KB â' because page has 8 KB
> Read Policy: No read Ahead (there is a choose beetwen read ahead i
> adaptive read ahead)
> Write Policy: Write Back (there is a choose beetwen Write Through i
> Force Write Back)
>
> For log files as above but RAID1
what do you think about this configuration?|||I think that RAID5 is still sort of the default for the main database
for average conditions, because it is more efficient in the use of
disk, when you get up to four or more drives, and it may be better for
reads, and average tables in average databases do 99% reads.
But, most apps may have a few more actively written tables, which
might be best on a filegroup and/or database on a RAID10 drive
instead.
I'm having my conscious raised on a number of hardware and
configurations issues these days myself.
Josh
On Sat, 03 Mar 2007 09:05:52 +0100, sp <kofa@.noemail.noemail> wrote:
>sp napisa?(a):
>> Optimal disk configuration for SQL
>> I think it is:
>> For datafiles (RAID10)
>> Stripe Element Size 8KB ? because page has 8 KB
>> Read Policy: No read Ahead (there is a choose beetwen read ahead i
>> adaptive read ahead)
>> Write Policy: Write Back (there is a choose beetwen Write Through i
>> Force Write Back)
>>
>> For log files as above but RAID1
>
>what do you think about this configuration?|||What is about Stripe Element Size in RAID 10 or 5 '
JXStern napisaÅ?(a):
> I think that RAID5 is still sort of the default for the main database
> for average conditions, because it is more efficient in the use of
> disk, when you get up to four or more drives, and it may be better for
> reads, and average tables in average databases do 99% reads.
> But, most apps may have a few more actively written tables, which
> might be best on a filegroup and/or database on a RAID10 drive
> instead.
> I'm having my conscious raised on a number of hardware and
> configurations issues these days myself.
> Josh
>
> On Sat, 03 Mar 2007 09:05:52 +0100, sp <kofa@.noemail.noemail> wrote:
>> sp napisa?(a):
>> Optimal disk configuration for SQL
>> I think it is:
>> For datafiles (RAID10)
>> Stripe Element Size 8KB â' because page has 8 KB
>> Read Policy: No read Ahead (there is a choose beetwen read ahead i
>> adaptive read ahead)
>> Write Policy: Write Back (there is a choose beetwen Write Through i
>> Force Write Back)
>>
>> For log files as above but RAID1
>> what do you think about this configuration?
>|||Hello KoFa,
The default Stripe Element Size for your hardware configuration is
recommanded. For example, in the Dell EMC white paper, it recommanded to
use the default size 128 blocks or 64 KB
Here are some article for you to refer:
http://www.dell.com/downloads/global/solutions/dell_emc_sap_bestpractice.pdf
http://forums.dantz.com/ubbthreads/showflat.php?Number=93175&page=0
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Hi ,
How is everything going? Please feel free to let me know if you need any
assistance.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.
Optimal disk configuration for SQL
Optimal disk configuration for SQL
I think it is:
For datafiles (RAID10)
Stripe Element Size 8KB – because page has 8 KB
Read Policy: No read Ahead (there is a choose beetwen read ahead i
adaptive read ahead)
Write Policy: Write Back (there is a choose beetwen Write Through i
Force Write Back)
For log files as above but RAID1sp napisa?(a):
> Optimal disk configuration for SQL
> I think it is:
> For datafiles (RAID10)
> Stripe Element Size 8KB – because page has 8 KB
> Read Policy: No read Ahead (there is a choose beetwen read ahead i
> adaptive read ahead)
> Write Policy: Write Back (there is a choose beetwen Write Through i
> Force Write Back)
>
> For log files as above but RAID1
what do you think about this configuration?|||I think that RAID5 is still sort of the default for the main database
for average conditions, because it is more efficient in the use of
disk, when you get up to four or more drives, and it may be better for
reads, and average tables in average databases do 99% reads.
But, most apps may have a few more actively written tables, which
might be best on a filegroup and/or database on a RAID10 drive
instead.
I'm having my conscious raised on a number of hardware and
configurations issues these days myself.
Josh
On Sat, 03 Mar 2007 09:05:52 +0100, sp <kofa@.noemail.noemail> wrote:
>sp napisa?(a):
>
>what do you think about this configuration?|||What is about Stripe Element Size in RAID 10 or 5 '
JXStern napisa?(a):
> I think that RAID5 is still sort of the default for the main database
> for average conditions, because it is more efficient in the use of
> disk, when you get up to four or more drives, and it may be better for
> reads, and average tables in average databases do 99% reads.
> But, most apps may have a few more actively written tables, which
> might be best on a filegroup and/or database on a RAID10 drive
> instead.
> I'm having my conscious raised on a number of hardware and
> configurations issues these days myself.
> Josh
>
> On Sat, 03 Mar 2007 09:05:52 +0100, sp <kofa@.noemail.noemail> wrote:
>
>|||Hello KoFa,
The default Stripe Element Size for your hardware configuration is
recommanded. For example, in the Dell EMC white paper, it recommanded to
use the default size 128 blocks or 64 KB
Here are some article for you to refer:
http://www.dell.com/downloads/globa...estpractice.pdf
http://forums.dantz.com/ubbthreads/...er=93175&page=0
Sincerely,
Wei Lu
Microsoft Online Community Support
========================================
==========
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
==========
This posting is provided "AS IS" with no warranties, and confers no rights.|||Hi ,
How is everything going? Please feel free to let me know if you need any
assistance.
Sincerely,
Wei Lu
Microsoft Online Community Support
========================================
==========
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
==========
This posting is provided "AS IS" with no warranties, and confers no rights.
I think it is:
For datafiles (RAID10)
Stripe Element Size 8KB – because page has 8 KB
Read Policy: No read Ahead (there is a choose beetwen read ahead i
adaptive read ahead)
Write Policy: Write Back (there is a choose beetwen Write Through i
Force Write Back)
For log files as above but RAID1sp napisa?(a):
> Optimal disk configuration for SQL
> I think it is:
> For datafiles (RAID10)
> Stripe Element Size 8KB – because page has 8 KB
> Read Policy: No read Ahead (there is a choose beetwen read ahead i
> adaptive read ahead)
> Write Policy: Write Back (there is a choose beetwen Write Through i
> Force Write Back)
>
> For log files as above but RAID1
what do you think about this configuration?|||I think that RAID5 is still sort of the default for the main database
for average conditions, because it is more efficient in the use of
disk, when you get up to four or more drives, and it may be better for
reads, and average tables in average databases do 99% reads.
But, most apps may have a few more actively written tables, which
might be best on a filegroup and/or database on a RAID10 drive
instead.
I'm having my conscious raised on a number of hardware and
configurations issues these days myself.
Josh
On Sat, 03 Mar 2007 09:05:52 +0100, sp <kofa@.noemail.noemail> wrote:
>sp napisa?(a):
>
>what do you think about this configuration?|||What is about Stripe Element Size in RAID 10 or 5 '
JXStern napisa?(a):
> I think that RAID5 is still sort of the default for the main database
> for average conditions, because it is more efficient in the use of
> disk, when you get up to four or more drives, and it may be better for
> reads, and average tables in average databases do 99% reads.
> But, most apps may have a few more actively written tables, which
> might be best on a filegroup and/or database on a RAID10 drive
> instead.
> I'm having my conscious raised on a number of hardware and
> configurations issues these days myself.
> Josh
>
> On Sat, 03 Mar 2007 09:05:52 +0100, sp <kofa@.noemail.noemail> wrote:
>
>|||Hello KoFa,
The default Stripe Element Size for your hardware configuration is
recommanded. For example, in the Dell EMC white paper, it recommanded to
use the default size 128 blocks or 64 KB
Here are some article for you to refer:
http://www.dell.com/downloads/globa...estpractice.pdf
http://forums.dantz.com/ubbthreads/...er=93175&page=0
Sincerely,
Wei Lu
Microsoft Online Community Support
========================================
==========
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
==========
This posting is provided "AS IS" with no warranties, and confers no rights.|||Hi ,
How is everything going? Please feel free to let me know if you need any
assistance.
Sincerely,
Wei Lu
Microsoft Online Community Support
========================================
==========
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
==========
This posting is provided "AS IS" with no warranties, and confers no rights.
Optimal configuration for report generator
I am working with a report generator that is based on SQL Server 2000 and
uses ASP as the UI. Basically we have a set of reports that end users can
execute through a web browser. In general the model works fine, but we are
running into some scaling issues.
What I'm trying to determine is, what is the optimal configuration for this
system. It is currently a 2.4G Pentium with a large RAID and 1G of RAM. We
have been using the "fixed" memory configuration, allocating 864M to SQL.
This is on a Windows 2003 server box.
This works fine when a "small" query or two is executed, but the performance
suffers terribly when several users try to run reports in parallel. A single
query might take 10 minutes to run if nothing else is happening on the box,
but if additional users log on an run reports, it's almost impossible to
predict when the queries will finish.
I am also looking at the effect of database size on performance, running
tests against a database with 1 month, 3 months, and say 12 months of data,
running the same query against 2 databases in parallel. With the original
configuration, the results were all over the place, with the 12 month
database outperforming the smaller dbs, while other times there was little
difference. It seems that once the system starts paging, and paging heavily,
it's over; the system never "recovers" and queries that previously ran in a
few minutes now take hours.
I added 3 G more memory to the system, and modified boot.ini to include the
/3GB switch. Now when I run the same tests, the results are much more
consistent, as the system rarely ever has to swap. Then again I've never
seen it go past 1.7G in Task manager, making me think that any more than say
2.5G of memory is a waste?
Things we are trying to determine are:
- in the SQL Server memory configuration, is Fixed better than Dynamic? We
have read that Dynamic is not good at returning memory to the OS once it's
been allocated
- What else can we do to optimize the performance for this application? It
seems to me if the indexes are properly designed, the database size
shouldn't have that much impact on performance, but this appears to be true
only to a point. In comparing the execution plans between say a 12 month and
a 3 month database, the plans are sometimes dramatically different. I assume
this is due to the optimizer deciding that going directly to the base tables
and not using an index will result in better performance, when in reality,
this doesn't always appear to be true.
- Are there other SQL Server switches I should be tweaking? Is there some
number of simultaneous queries that this configuration should be limited to?
- What about other versions of SQL Server (e.g. Enterprise, Data Center,
etc) would these buy us anything?
Thanks for any advice,
-Gary
Gary,
I suppose I would have to have more information. Performance and Tuning
is a step by step process (one is always robbing Peter to pay Paul, so
to speak).
how big is the database in question?
what is the RAID configuration (0,1,5,10)?
what does the queries that are running look like? have you looked at
the execution plan to make sure the indexes are being used? (a nested
iteration join with a table scan can cause massive slow downs).
how big are the tables?
it might be the case that you are suffering from spinlock contention
(context switching on the processor)...in which case you might need to
have more processors. you can run a profile on the processor
performance to get the proper information. however, i would strongly
suggest looking at the logical design of the database, the query
itself, the statistics on the objects involved and the indexes. the
optimizer could be ignoring your indexes because the statistics are out
of wack or the weight of the search is to high.
there are just too many factors that could be responsible for the
slowness for me to answer without knowing them.
there is a decent performance and tuning section in the manual, if you
want to give it a look.
hth.
hans nelsen
|||Here are my two cents. Mileage may vary, past results do not guarantee
future performance etc...
-- in the SQL Server memory configuration, is Fixed better than
Dynamic? We have read that Dynamic is not good at returning memory to
the OS once it's been allocated
CHOOSE DYNAMIC. MSSQL is meant to function on its own box. It will
take over all the resources. If you're running MSFT small business
server - then you might want fixed.
-- What else can we do to optimize the performance for this
application? It seems to me if the indexes are properly designed, the
database size shouldn't have that much impact on performance, but this
appears to be true only to a point. In comparing the execution plans
between say a 12 month and a 3 month database, the plans are sometimes
dramatically different. I assume this is due to the optimizer deciding
that going directly to the base tables
and not using an index will result in better performance, when in
reality,this doesn't always appear to be true.
COMMON PROBLEMS. The most common problems are user locks. Unlike
Oracle, MSSQL is lock crazy. It places locks on everything. Ensure
that read-locks are not competing against write-locks. Also ensure
that your indexes are being regularly defragged. DBCC DBREINDEX or
DBCC INDEXDEFRAG. Looking at the execution plan in query analyzer --
should tell you. Auto create statistics and auto update statistics
should also be turned on.
-- Are there other SQL Server switches I should be tweaking? Is there
some number of simultaneous queries that this configuration should be
limited to?
Look at this free article from microsoft/technet.
http://www.microsoft.com/technet/pro.../c02ppcsq.mspx
Here is a quote from it:
Caution: Setting fixed memory incorrectly can cause serious performance
problems on SQL Server. Use fixed memory only in circumstances when you
need to ensure that an exact amount of memory is available for SQL
Server.
-- What about other versions of SQL Server (e.g. Enterprise, Data
Center, etc) would these buy us anything?
No. Standard works just fine for 99% of users. Enterprise does get
you Reporting Services and indexed views and log shipping.
uses ASP as the UI. Basically we have a set of reports that end users can
execute through a web browser. In general the model works fine, but we are
running into some scaling issues.
What I'm trying to determine is, what is the optimal configuration for this
system. It is currently a 2.4G Pentium with a large RAID and 1G of RAM. We
have been using the "fixed" memory configuration, allocating 864M to SQL.
This is on a Windows 2003 server box.
This works fine when a "small" query or two is executed, but the performance
suffers terribly when several users try to run reports in parallel. A single
query might take 10 minutes to run if nothing else is happening on the box,
but if additional users log on an run reports, it's almost impossible to
predict when the queries will finish.
I am also looking at the effect of database size on performance, running
tests against a database with 1 month, 3 months, and say 12 months of data,
running the same query against 2 databases in parallel. With the original
configuration, the results were all over the place, with the 12 month
database outperforming the smaller dbs, while other times there was little
difference. It seems that once the system starts paging, and paging heavily,
it's over; the system never "recovers" and queries that previously ran in a
few minutes now take hours.
I added 3 G more memory to the system, and modified boot.ini to include the
/3GB switch. Now when I run the same tests, the results are much more
consistent, as the system rarely ever has to swap. Then again I've never
seen it go past 1.7G in Task manager, making me think that any more than say
2.5G of memory is a waste?
Things we are trying to determine are:
- in the SQL Server memory configuration, is Fixed better than Dynamic? We
have read that Dynamic is not good at returning memory to the OS once it's
been allocated
- What else can we do to optimize the performance for this application? It
seems to me if the indexes are properly designed, the database size
shouldn't have that much impact on performance, but this appears to be true
only to a point. In comparing the execution plans between say a 12 month and
a 3 month database, the plans are sometimes dramatically different. I assume
this is due to the optimizer deciding that going directly to the base tables
and not using an index will result in better performance, when in reality,
this doesn't always appear to be true.
- Are there other SQL Server switches I should be tweaking? Is there some
number of simultaneous queries that this configuration should be limited to?
- What about other versions of SQL Server (e.g. Enterprise, Data Center,
etc) would these buy us anything?
Thanks for any advice,
-Gary
Gary,
I suppose I would have to have more information. Performance and Tuning
is a step by step process (one is always robbing Peter to pay Paul, so
to speak).
how big is the database in question?
what is the RAID configuration (0,1,5,10)?
what does the queries that are running look like? have you looked at
the execution plan to make sure the indexes are being used? (a nested
iteration join with a table scan can cause massive slow downs).
how big are the tables?
it might be the case that you are suffering from spinlock contention
(context switching on the processor)...in which case you might need to
have more processors. you can run a profile on the processor
performance to get the proper information. however, i would strongly
suggest looking at the logical design of the database, the query
itself, the statistics on the objects involved and the indexes. the
optimizer could be ignoring your indexes because the statistics are out
of wack or the weight of the search is to high.
there are just too many factors that could be responsible for the
slowness for me to answer without knowing them.
there is a decent performance and tuning section in the manual, if you
want to give it a look.
hth.
hans nelsen
|||Here are my two cents. Mileage may vary, past results do not guarantee
future performance etc...
-- in the SQL Server memory configuration, is Fixed better than
Dynamic? We have read that Dynamic is not good at returning memory to
the OS once it's been allocated
CHOOSE DYNAMIC. MSSQL is meant to function on its own box. It will
take over all the resources. If you're running MSFT small business
server - then you might want fixed.
-- What else can we do to optimize the performance for this
application? It seems to me if the indexes are properly designed, the
database size shouldn't have that much impact on performance, but this
appears to be true only to a point. In comparing the execution plans
between say a 12 month and a 3 month database, the plans are sometimes
dramatically different. I assume this is due to the optimizer deciding
that going directly to the base tables
and not using an index will result in better performance, when in
reality,this doesn't always appear to be true.
COMMON PROBLEMS. The most common problems are user locks. Unlike
Oracle, MSSQL is lock crazy. It places locks on everything. Ensure
that read-locks are not competing against write-locks. Also ensure
that your indexes are being regularly defragged. DBCC DBREINDEX or
DBCC INDEXDEFRAG. Looking at the execution plan in query analyzer --
should tell you. Auto create statistics and auto update statistics
should also be turned on.
-- Are there other SQL Server switches I should be tweaking? Is there
some number of simultaneous queries that this configuration should be
limited to?
Look at this free article from microsoft/technet.
http://www.microsoft.com/technet/pro.../c02ppcsq.mspx
Here is a quote from it:
Caution: Setting fixed memory incorrectly can cause serious performance
problems on SQL Server. Use fixed memory only in circumstances when you
need to ensure that an exact amount of memory is available for SQL
Server.
-- What about other versions of SQL Server (e.g. Enterprise, Data
Center, etc) would these buy us anything?
No. Standard works just fine for 99% of users. Enterprise does get
you Reporting Services and indexed views and log shipping.
Optimal configuration for report generator
I am working with a report generator that is based on SQL Server 2000 and
uses ASP as the UI. Basically we have a set of reports that end users can
execute through a web browser. In general the model works fine, but we are
running into some scaling issues.
What I'm trying to determine is, what is the optimal configuration for this
system. It is currently a 2.4G Pentium with a large RAID and 1G of RAM. We
have been using the "fixed" memory configuration, allocating 864M to SQL.
This is on a Windows 2003 server box.
This works fine when a "small" query or two is executed, but the performance
suffers terribly when several users try to run reports in parallel. A single
query might take 10 minutes to run if nothing else is happening on the box,
but if additional users log on an run reports, it's almost impossible to
predict when the queries will finish.
I am also looking at the effect of database size on performance, running
tests against a database with 1 month, 3 months, and say 12 months of data,
running the same query against 2 databases in parallel. With the original
configuration, the results were all over the place, with the 12 month
database outperforming the smaller dbs, while other times there was little
difference. It seems that once the system starts paging, and paging heavily,
it's over; the system never "recovers" and queries that previously ran in a
few minutes now take hours.
I added 3 G more memory to the system, and modified boot.ini to include the
/3GB switch. Now when I run the same tests, the results are much more
consistent, as the system rarely ever has to swap. Then again I've never
seen it go past 1.7G in Task manager, making me think that any more than say
2.5G of memory is a waste?
Things we are trying to determine are:
- in the SQL Server memory configuration, is Fixed better than Dynamic? We
have read that Dynamic is not good at returning memory to the OS once it's
been allocated
- What else can we do to optimize the performance for this application? It
seems to me if the indexes are properly designed, the database size
shouldn't have that much impact on performance, but this appears to be true
only to a point. In comparing the execution plans between say a 12 month and
a 3 month database, the plans are sometimes dramatically different. I assume
this is due to the optimizer deciding that going directly to the base tables
and not using an index will result in better performance, when in reality,
this doesn't always appear to be true.
- Are there other SQL Server switches I should be tweaking? Is there some
number of simultaneous queries that this configuration should be limited to?
- What about other versions of SQL Server (e.g. Enterprise, Data Center,
etc) would these buy us anything?
Thanks for any advice,
-Gary
Gary,
I suppose I would have to have more information. Performance and Tuning
is a step by step process (one is always robbing Peter to pay Paul, so
to speak).
how big is the database in question?
what is the RAID configuration (0,1,5,10)?
what does the queries that are running look like? have you looked at
the execution plan to make sure the indexes are being used? (a nested
iteration join with a table scan can cause massive slow downs).
how big are the tables?
it might be the case that you are suffering from spinlock contention
(context switching on the processor)...in which case you might need to
have more processors. you can run a profile on the processor
performance to get the proper information. however, i would strongly
suggest looking at the logical design of the database, the query
itself, the statistics on the objects involved and the indexes. the
optimizer could be ignoring your indexes because the statistics are out
of wack or the weight of the search is to high.
there are just too many factors that could be responsible for the
slowness for me to answer without knowing them.
there is a decent performance and tuning section in the manual, if you
want to give it a look.
hth.
hans nelsen
|||Here are my two cents. Mileage may vary, past results do not guarantee
future performance etc...
-- in the SQL Server memory configuration, is Fixed better than
Dynamic? We have read that Dynamic is not good at returning memory to
the OS once it's been allocated
CHOOSE DYNAMIC. MSSQL is meant to function on its own box. It will
take over all the resources. If you're running MSFT small business
server - then you might want fixed.
-- What else can we do to optimize the performance for this
application? It seems to me if the indexes are properly designed, the
database size shouldn't have that much impact on performance, but this
appears to be true only to a point. In comparing the execution plans
between say a 12 month and a 3 month database, the plans are sometimes
dramatically different. I assume this is due to the optimizer deciding
that going directly to the base tables
and not using an index will result in better performance, when in
reality,this doesn't always appear to be true.
COMMON PROBLEMS. The most common problems are user locks. Unlike
Oracle, MSSQL is lock crazy. It places locks on everything. Ensure
that read-locks are not competing against write-locks. Also ensure
that your indexes are being regularly defragged. DBCC DBREINDEX or
DBCC INDEXDEFRAG. Looking at the execution plan in query analyzer --
should tell you. Auto create statistics and auto update statistics
should also be turned on.
-- Are there other SQL Server switches I should be tweaking? Is there
some number of simultaneous queries that this configuration should be
limited to?
Look at this free article from microsoft/technet.
http://www.microsoft.com/technet/pro.../c02ppcsq.mspx
Here is a quote from it:
Caution: Setting fixed memory incorrectly can cause serious performance
problems on SQL Server. Use fixed memory only in circumstances when you
need to ensure that an exact amount of memory is available for SQL
Server.
-- What about other versions of SQL Server (e.g. Enterprise, Data
Center, etc) would these buy us anything?
No. Standard works just fine for 99% of users. Enterprise does get
you Reporting Services and indexed views and log shipping.
uses ASP as the UI. Basically we have a set of reports that end users can
execute through a web browser. In general the model works fine, but we are
running into some scaling issues.
What I'm trying to determine is, what is the optimal configuration for this
system. It is currently a 2.4G Pentium with a large RAID and 1G of RAM. We
have been using the "fixed" memory configuration, allocating 864M to SQL.
This is on a Windows 2003 server box.
This works fine when a "small" query or two is executed, but the performance
suffers terribly when several users try to run reports in parallel. A single
query might take 10 minutes to run if nothing else is happening on the box,
but if additional users log on an run reports, it's almost impossible to
predict when the queries will finish.
I am also looking at the effect of database size on performance, running
tests against a database with 1 month, 3 months, and say 12 months of data,
running the same query against 2 databases in parallel. With the original
configuration, the results were all over the place, with the 12 month
database outperforming the smaller dbs, while other times there was little
difference. It seems that once the system starts paging, and paging heavily,
it's over; the system never "recovers" and queries that previously ran in a
few minutes now take hours.
I added 3 G more memory to the system, and modified boot.ini to include the
/3GB switch. Now when I run the same tests, the results are much more
consistent, as the system rarely ever has to swap. Then again I've never
seen it go past 1.7G in Task manager, making me think that any more than say
2.5G of memory is a waste?
Things we are trying to determine are:
- in the SQL Server memory configuration, is Fixed better than Dynamic? We
have read that Dynamic is not good at returning memory to the OS once it's
been allocated
- What else can we do to optimize the performance for this application? It
seems to me if the indexes are properly designed, the database size
shouldn't have that much impact on performance, but this appears to be true
only to a point. In comparing the execution plans between say a 12 month and
a 3 month database, the plans are sometimes dramatically different. I assume
this is due to the optimizer deciding that going directly to the base tables
and not using an index will result in better performance, when in reality,
this doesn't always appear to be true.
- Are there other SQL Server switches I should be tweaking? Is there some
number of simultaneous queries that this configuration should be limited to?
- What about other versions of SQL Server (e.g. Enterprise, Data Center,
etc) would these buy us anything?
Thanks for any advice,
-Gary
Gary,
I suppose I would have to have more information. Performance and Tuning
is a step by step process (one is always robbing Peter to pay Paul, so
to speak).
how big is the database in question?
what is the RAID configuration (0,1,5,10)?
what does the queries that are running look like? have you looked at
the execution plan to make sure the indexes are being used? (a nested
iteration join with a table scan can cause massive slow downs).
how big are the tables?
it might be the case that you are suffering from spinlock contention
(context switching on the processor)...in which case you might need to
have more processors. you can run a profile on the processor
performance to get the proper information. however, i would strongly
suggest looking at the logical design of the database, the query
itself, the statistics on the objects involved and the indexes. the
optimizer could be ignoring your indexes because the statistics are out
of wack or the weight of the search is to high.
there are just too many factors that could be responsible for the
slowness for me to answer without knowing them.
there is a decent performance and tuning section in the manual, if you
want to give it a look.
hth.
hans nelsen
|||Here are my two cents. Mileage may vary, past results do not guarantee
future performance etc...
-- in the SQL Server memory configuration, is Fixed better than
Dynamic? We have read that Dynamic is not good at returning memory to
the OS once it's been allocated
CHOOSE DYNAMIC. MSSQL is meant to function on its own box. It will
take over all the resources. If you're running MSFT small business
server - then you might want fixed.
-- What else can we do to optimize the performance for this
application? It seems to me if the indexes are properly designed, the
database size shouldn't have that much impact on performance, but this
appears to be true only to a point. In comparing the execution plans
between say a 12 month and a 3 month database, the plans are sometimes
dramatically different. I assume this is due to the optimizer deciding
that going directly to the base tables
and not using an index will result in better performance, when in
reality,this doesn't always appear to be true.
COMMON PROBLEMS. The most common problems are user locks. Unlike
Oracle, MSSQL is lock crazy. It places locks on everything. Ensure
that read-locks are not competing against write-locks. Also ensure
that your indexes are being regularly defragged. DBCC DBREINDEX or
DBCC INDEXDEFRAG. Looking at the execution plan in query analyzer --
should tell you. Auto create statistics and auto update statistics
should also be turned on.
-- Are there other SQL Server switches I should be tweaking? Is there
some number of simultaneous queries that this configuration should be
limited to?
Look at this free article from microsoft/technet.
http://www.microsoft.com/technet/pro.../c02ppcsq.mspx
Here is a quote from it:
Caution: Setting fixed memory incorrectly can cause serious performance
problems on SQL Server. Use fixed memory only in circumstances when you
need to ensure that an exact amount of memory is available for SQL
Server.
-- What about other versions of SQL Server (e.g. Enterprise, Data
Center, etc) would these buy us anything?
No. Standard works just fine for 99% of users. Enterprise does get
you Reporting Services and indexed views and log shipping.
Optimal configuration for report generator
I am working with a report generator that is based on SQL Server 2000 and
uses ASP as the UI. Basically we have a set of reports that end users can
execute through a web browser. In general the model works fine, but we are
running into some scaling issues.
What I'm trying to determine is, what is the optimal configuration for this
system. It is currently a 2.4G Pentium with a large RAID and 1G of RAM. We
have been using the "fixed" memory configuration, allocating 864M to SQL.
This is on a Windows 2003 server box.
This works fine when a "small" query or two is executed, but the performance
suffers terribly when several users try to run reports in parallel. A single
query might take 10 minutes to run if nothing else is happening on the box,
but if additional users log on an run reports, it's almost impossible to
predict when the queries will finish.
I am also looking at the effect of database size on performance, running
tests against a database with 1 month, 3 months, and say 12 months of data,
running the same query against 2 databases in parallel. With the original
configuration, the results were all over the place, with the 12 month
database outperforming the smaller dbs, while other times there was little
difference. It seems that once the system starts paging, and paging heavily,
it's over; the system never "recovers" and queries that previously ran in a
few minutes now take hours.
I added 3 G more memory to the system, and modified boot.ini to include the
/3GB switch. Now when I run the same tests, the results are much more
consistent, as the system rarely ever has to swap. Then again I've never
seen it go past 1.7G in Task manager, making me think that any more than say
2.5G of memory is a waste?
Things we are trying to determine are:
- in the SQL Server memory configuration, is Fixed better than Dynamic? We
have read that Dynamic is not good at returning memory to the OS once it's
been allocated
- What else can we do to optimize the performance for this application? It
seems to me if the indexes are properly designed, the database size
shouldn't have that much impact on performance, but this appears to be true
only to a point. In comparing the execution plans between say a 12 month and
a 3 month database, the plans are sometimes dramatically different. I assume
this is due to the optimizer deciding that going directly to the base tables
and not using an index will result in better performance, when in reality,
this doesn't always appear to be true.
- Are there other SQL Server switches I should be tweaking? Is there some
number of simultaneous queries that this configuration should be limited to?
- What about other versions of SQL Server (e.g. Enterprise, Data Center,
etc) would these buy us anything?
Thanks for any advice,
-GaryGary,
I suppose I would have to have more information. Performance and Tuning
is a step by step process (one is always robbing Peter to pay Paul, so
to speak).
how big is the database in question?
what is the RAID configuration (0,1,5,10)?
what does the queries that are running look like? have you looked at
the execution plan to make sure the indexes are being used? (a nested
iteration join with a table scan can cause massive slow downs).
how big are the tables?
it might be the case that you are suffering from spinlock contention
(context switching on the processor)...in which case you might need to
have more processors. you can run a profile on the processor
performance to get the proper information. however, i would strongly
suggest looking at the logical design of the database, the query
itself, the statistics on the objects involved and the indexes. the
optimizer could be ignoring your indexes because the statistics are out
of wack or the weight of the search is to high.
there are just too many factors that could be responsible for the
slowness for me to answer without knowing them.
there is a decent performance and tuning section in the manual, if you
want to give it a look.
hth.
hans nelsen|||Here are my two cents. Mileage may vary, past results do not guarantee
future performance etc...
-- in the SQL Server memory configuration, is Fixed better than
Dynamic? We have read that Dynamic is not good at returning memory to
the OS once it's been allocated
CHOOSE DYNAMIC. MSSQL is meant to function on its own box. It will
take over all the resources. If you're running MSFT small business
server - then you might want fixed.
-- What else can we do to optimize the performance for this
application? It seems to me if the indexes are properly designed, the
database size shouldn't have that much impact on performance, but this
appears to be true only to a point. In comparing the execution plans
between say a 12 month and a 3 month database, the plans are sometimes
dramatically different. I assume this is due to the optimizer deciding
that going directly to the base tables
and not using an index will result in better performance, when in
reality,this doesn't always appear to be true.
COMMON PROBLEMS. The most common problems are user locks. Unlike
Oracle, MSSQL is lock crazy. It places locks on everything. Ensure
that read-locks are not competing against write-locks. Also ensure
that your indexes are being regularly defragged. DBCC DBREINDEX or
DBCC INDEXDEFRAG. Looking at the execution plan in query analyzer --
should tell you. Auto create statistics and auto update statistics
should also be turned on.
-- Are there other SQL Server switches I should be tweaking? Is there
some number of simultaneous queries that this configuration should be
limited to?
Look at this free article from microsoft/technet.
http://www.microsoft.com/technet/prodtechnol/sql/2000/books/c02ppcsq.mspx
Here is a quote from it:
Caution: Setting fixed memory incorrectly can cause serious performance
problems on SQL Server. Use fixed memory only in circumstances when you
need to ensure that an exact amount of memory is available for SQL
Server.
-- What about other versions of SQL Server (e.g. Enterprise, Data
Center, etc) would these buy us anything?
No. Standard works just fine for 99% of users. Enterprise does get
you Reporting Services and indexed views and log shipping.
uses ASP as the UI. Basically we have a set of reports that end users can
execute through a web browser. In general the model works fine, but we are
running into some scaling issues.
What I'm trying to determine is, what is the optimal configuration for this
system. It is currently a 2.4G Pentium with a large RAID and 1G of RAM. We
have been using the "fixed" memory configuration, allocating 864M to SQL.
This is on a Windows 2003 server box.
This works fine when a "small" query or two is executed, but the performance
suffers terribly when several users try to run reports in parallel. A single
query might take 10 minutes to run if nothing else is happening on the box,
but if additional users log on an run reports, it's almost impossible to
predict when the queries will finish.
I am also looking at the effect of database size on performance, running
tests against a database with 1 month, 3 months, and say 12 months of data,
running the same query against 2 databases in parallel. With the original
configuration, the results were all over the place, with the 12 month
database outperforming the smaller dbs, while other times there was little
difference. It seems that once the system starts paging, and paging heavily,
it's over; the system never "recovers" and queries that previously ran in a
few minutes now take hours.
I added 3 G more memory to the system, and modified boot.ini to include the
/3GB switch. Now when I run the same tests, the results are much more
consistent, as the system rarely ever has to swap. Then again I've never
seen it go past 1.7G in Task manager, making me think that any more than say
2.5G of memory is a waste?
Things we are trying to determine are:
- in the SQL Server memory configuration, is Fixed better than Dynamic? We
have read that Dynamic is not good at returning memory to the OS once it's
been allocated
- What else can we do to optimize the performance for this application? It
seems to me if the indexes are properly designed, the database size
shouldn't have that much impact on performance, but this appears to be true
only to a point. In comparing the execution plans between say a 12 month and
a 3 month database, the plans are sometimes dramatically different. I assume
this is due to the optimizer deciding that going directly to the base tables
and not using an index will result in better performance, when in reality,
this doesn't always appear to be true.
- Are there other SQL Server switches I should be tweaking? Is there some
number of simultaneous queries that this configuration should be limited to?
- What about other versions of SQL Server (e.g. Enterprise, Data Center,
etc) would these buy us anything?
Thanks for any advice,
-GaryGary,
I suppose I would have to have more information. Performance and Tuning
is a step by step process (one is always robbing Peter to pay Paul, so
to speak).
how big is the database in question?
what is the RAID configuration (0,1,5,10)?
what does the queries that are running look like? have you looked at
the execution plan to make sure the indexes are being used? (a nested
iteration join with a table scan can cause massive slow downs).
how big are the tables?
it might be the case that you are suffering from spinlock contention
(context switching on the processor)...in which case you might need to
have more processors. you can run a profile on the processor
performance to get the proper information. however, i would strongly
suggest looking at the logical design of the database, the query
itself, the statistics on the objects involved and the indexes. the
optimizer could be ignoring your indexes because the statistics are out
of wack or the weight of the search is to high.
there are just too many factors that could be responsible for the
slowness for me to answer without knowing them.
there is a decent performance and tuning section in the manual, if you
want to give it a look.
hth.
hans nelsen|||Here are my two cents. Mileage may vary, past results do not guarantee
future performance etc...
-- in the SQL Server memory configuration, is Fixed better than
Dynamic? We have read that Dynamic is not good at returning memory to
the OS once it's been allocated
CHOOSE DYNAMIC. MSSQL is meant to function on its own box. It will
take over all the resources. If you're running MSFT small business
server - then you might want fixed.
-- What else can we do to optimize the performance for this
application? It seems to me if the indexes are properly designed, the
database size shouldn't have that much impact on performance, but this
appears to be true only to a point. In comparing the execution plans
between say a 12 month and a 3 month database, the plans are sometimes
dramatically different. I assume this is due to the optimizer deciding
that going directly to the base tables
and not using an index will result in better performance, when in
reality,this doesn't always appear to be true.
COMMON PROBLEMS. The most common problems are user locks. Unlike
Oracle, MSSQL is lock crazy. It places locks on everything. Ensure
that read-locks are not competing against write-locks. Also ensure
that your indexes are being regularly defragged. DBCC DBREINDEX or
DBCC INDEXDEFRAG. Looking at the execution plan in query analyzer --
should tell you. Auto create statistics and auto update statistics
should also be turned on.
-- Are there other SQL Server switches I should be tweaking? Is there
some number of simultaneous queries that this configuration should be
limited to?
Look at this free article from microsoft/technet.
http://www.microsoft.com/technet/prodtechnol/sql/2000/books/c02ppcsq.mspx
Here is a quote from it:
Caution: Setting fixed memory incorrectly can cause serious performance
problems on SQL Server. Use fixed memory only in circumstances when you
need to ensure that an exact amount of memory is available for SQL
Server.
-- What about other versions of SQL Server (e.g. Enterprise, Data
Center, etc) would these buy us anything?
No. Standard works just fine for 99% of users. Enterprise does get
you Reporting Services and indexed views and log shipping.
Optimal configuration for report generator
I am working with a report generator that is based on SQL Server 2000 and
uses ASP as the UI. Basically we have a set of reports that end users can
execute through a web browser. In general the model works fine, but we are
running into some scaling issues.
uses ASP as the UI. Basically we have a set of reports that end users can
execute through a web browser. In general the model works fine, but we are
running into some scaling issues.
What I'm trying to determine is, what is the optimal configuration for this
system. It is currently a 2.4G Pentium with a large RAID and 1G of RAM. We
have been using the "fixed" memory configuration, allocating 864M to SQL.
This is on a Windows 2003 server box.
This works fine when a "small" query or two is executed, but the performance
suffers terribly when several users try to run reports in parallel. A single
query might take 10 minutes to run if nothing else is happening on the box,
but if additional users log on an run reports, it's almost impossible to
predict when the queries will finish.
I am also looking at the effect of database size on performance, running
tests against a database with 1 month, 3 months, and say 12 months of data,
running the same query against 2 databases in parallel. With the original
configuration, the results were all over the place, with the 12 month
database outperforming the smaller dbs, while other times there was little
difference. It seems that once the system starts paging, and paging heavily,
it's over; the system never "recovers" and queries that previously ran in a
few minutes now take hours.
I added 3 G more memory to the system, and modified boot.ini to include the
/3GB switch. Now when I run the same tests, the results are much more
consistent, as the system rarely ever has to swap. Then again I've never
seen it go past 1.7G in Task manager, making me think that any more than say
2.5G of memory is a waste?
Things we are trying to determine are:
- in the SQL Server memory configuration, is Fixed better than Dynamic? We
have read that Dynamic is not good at returning memory to the OS once it's
been allocated
- What else can we do to optimize the performance for this application? It
seems to me if the indexes are properly designed, the database size
shouldn't have that much impact on performance, but this appears to be true
only to a point. In comparing the execution plans between say a 12 month and
a 3 month database, the plans are sometimes dramatically different. I assume
this is due to the optimizer deciding that going directly to the base tables
and not using an index will result in better performance, when in reality,
this doesn't always appear to be true.
- Are there other SQL Server switches I should be tweaking? Is there some
number of simultaneous queries that this configuration should be limited to?
- What about other versions of SQL Server (e.g. Enterprise, Data Center,
etc) would these buy us anything?
Thanks for any advice,
-GaryGary,
I suppose I would have to have more information. Performance and Tuning
is a step by step process (one is always robbing Peter to pay Paul, so
to speak).
how big is the database in question?
what is the RAID configuration (0,1,5,10)?
what does the queries that are running look like? have you looked at
the execution plan to make sure the indexes are being used? (a nested
iteration join with a table scan can cause massive slow downs).
how big are the tables?
it might be the case that you are suffering from spinlock contention
(context switching on the processor)...in which case you might need to
have more processors. you can run a profile on the processor
performance to get the proper information. however, i would strongly
suggest looking at the logical design of the database, the query
itself, the statistics on the objects involved and the indexes. the
optimizer could be ignoring your indexes because the statistics are out
of wack or the weight of the search is to high.
there are just too many factors that could be responsible for the
slowness for me to answer without knowing them.
there is a decent performance and tuning section in the manual, if you
want to give it a look.
hth.
hans nelsen|||Here are my two cents. Mileage may vary, past results do not guarantee
future performance etc...
-- in the SQL Server memory configuration, is Fixed better than
Dynamic? We have read that Dynamic is not good at returning memory to
the OS once it's been allocated
CHOOSE DYNAMIC. MSSQL is meant to function on its own box. It will
take over all the resources. If you're running MSFT small business
server - then you might want fixed.
-- What else can we do to optimize the performance for this
application? It seems to me if the indexes are properly designed, the
database size shouldn't have that much impact on performance, but this
appears to be true only to a point. In comparing the execution plans
between say a 12 month and a 3 month database, the plans are sometimes
dramatically different. I assume this is due to the optimizer deciding
that going directly to the base tables
and not using an index will result in better performance, when in
reality,this doesn't always appear to be true.
COMMON PROBLEMS. The most common problems are user locks. Unlike
Oracle, MSSQL is lock crazy. It places locks on everything. Ensure
that read-locks are not competing against write-locks. Also ensure
that your indexes are being regularly defragged. DBCC DBREINDEX or
DBCC INDEXDEFRAG. Looking at the execution plan in query analyzer --
should tell you. Auto create statistics and auto update statistics
should also be turned on.
-- Are there other SQL Server switches I should be tweaking? Is there
some number of simultaneous queries that this configuration should be
limited to?
Look at this free article from microsoft/technet.
http://www.microsoft.com/technet/pr...s/c02ppcsq.mspx
Here is a quote from it:
Caution: Setting fixed memory incorrectly can cause serious performance
problems on SQL Server. Use fixed memory only in circumstances when you
need to ensure that an exact amount of memory is available for SQL
Server.
-- What about other versions of SQL Server (e.g. Enterprise, Data
Center, etc) would these buy us anything?
No. Standard works just fine for 99% of users. Enterprise does get
you Reporting Services and indexed views and log shipping.
Wednesday, March 7, 2012
Operator failing
sql2k sp3
SQLMail and the Mail Profile are configured and
successfully test when hitting the "test" button in the
SQL Mail Configuration Properties box.
But when I try to do a test for an operator in the
Operator Properties it says "Error 22022: SQLServerAgent
mail session not running; check mail profile and/ or
SQLServerAgent service startup account in SQLServerAgent
properites dialog box".
The Agent and the Mail Profile(same account) are in the
Local Admins Group. I have already rebooted.
Any ideas?
TIA, ChrisR
Hi Chris
You have already asked this question once and got a reply...:-).
Have you tried to check the properties of the SQLSERVERAgent in EM. Here
you have to set a mailprofile for the mail session.
Regards
Steen
"ChrtisR" <anonymous@.discussions.microsoft.com> skrev i en meddelelse
news:2901301c464fa$6779e5a0$a501280a@.phx.gbl...
> sql2k sp3
> SQLMail and the Mail Profile are configured and
> successfully test when hitting the "test" button in the
> SQL Mail Configuration Properties box.
> But when I try to do a test for an operator in the
> Operator Properties it says "Error 22022: SQLServerAgent
> mail session not running; check mail profile and/ or
> SQLServerAgent service startup account in SQLServerAgent
> properites dialog box".
> The Agent and the Mail Profile(same account) are in the
> Local Admins Group. I have already rebooted.
> Any ideas?
> TIA, ChrisR
>
SQLMail and the Mail Profile are configured and
successfully test when hitting the "test" button in the
SQL Mail Configuration Properties box.
But when I try to do a test for an operator in the
Operator Properties it says "Error 22022: SQLServerAgent
mail session not running; check mail profile and/ or
SQLServerAgent service startup account in SQLServerAgent
properites dialog box".
The Agent and the Mail Profile(same account) are in the
Local Admins Group. I have already rebooted.
Any ideas?
TIA, ChrisR
Hi Chris
You have already asked this question once and got a reply...:-).
Have you tried to check the properties of the SQLSERVERAgent in EM. Here
you have to set a mailprofile for the mail session.
Regards
Steen
"ChrtisR" <anonymous@.discussions.microsoft.com> skrev i en meddelelse
news:2901301c464fa$6779e5a0$a501280a@.phx.gbl...
> sql2k sp3
> SQLMail and the Mail Profile are configured and
> successfully test when hitting the "test" button in the
> SQL Mail Configuration Properties box.
> But when I try to do a test for an operator in the
> Operator Properties it says "Error 22022: SQLServerAgent
> mail session not running; check mail profile and/ or
> SQLServerAgent service startup account in SQLServerAgent
> properites dialog box".
> The Agent and the Mail Profile(same account) are in the
> Local Admins Group. I have already rebooted.
> Any ideas?
> TIA, ChrisR
>
Operator failing
sql2k sp3
SQLMail and the Mail Profile are configured and
successfully test when hitting the "test" button in the
SQL Mail Configuration Properties box.
But when I try to do a test for an operator in the
Operator Properties it says "Error 22022: SQLServerAgent
mail session not running; check mail profile and/ or
SQLServerAgent service startup account in SQLServerAgent
properites dialog box".
The Agent and the Mail Profile(same account) are in the
Local Admins Group. I have already rebooted.
Any ideas?
TIA, ChrisRHi Chris
You have already asked this question once and got a reply...:-).
Have you tried to check the properties of the SQLSERVERAgent in EM. Here
you have to set a mailprofile for the mail session.
Regards
Steen
"ChrtisR" <anonymous@.discussions.microsoft.com> skrev i en meddelelse
news:2901301c464fa$6779e5a0$a501280a@.phx
.gbl...
> sql2k sp3
> SQLMail and the Mail Profile are configured and
> successfully test when hitting the "test" button in the
> SQL Mail Configuration Properties box.
> But when I try to do a test for an operator in the
> Operator Properties it says "Error 22022: SQLServerAgent
> mail session not running; check mail profile and/ or
> SQLServerAgent service startup account in SQLServerAgent
> properites dialog box".
> The Agent and the Mail Profile(same account) are in the
> Local Admins Group. I have already rebooted.
> Any ideas?
> TIA, ChrisR
>
SQLMail and the Mail Profile are configured and
successfully test when hitting the "test" button in the
SQL Mail Configuration Properties box.
But when I try to do a test for an operator in the
Operator Properties it says "Error 22022: SQLServerAgent
mail session not running; check mail profile and/ or
SQLServerAgent service startup account in SQLServerAgent
properites dialog box".
The Agent and the Mail Profile(same account) are in the
Local Admins Group. I have already rebooted.
Any ideas?
TIA, ChrisRHi Chris
You have already asked this question once and got a reply...:-).
Have you tried to check the properties of the SQLSERVERAgent in EM. Here
you have to set a mailprofile for the mail session.
Regards
Steen
"ChrtisR" <anonymous@.discussions.microsoft.com> skrev i en meddelelse
news:2901301c464fa$6779e5a0$a501280a@.phx
.gbl...
> sql2k sp3
> SQLMail and the Mail Profile are configured and
> successfully test when hitting the "test" button in the
> SQL Mail Configuration Properties box.
> But when I try to do a test for an operator in the
> Operator Properties it says "Error 22022: SQLServerAgent
> mail session not running; check mail profile and/ or
> SQLServerAgent service startup account in SQLServerAgent
> properites dialog box".
> The Agent and the Mail Profile(same account) are in the
> Local Admins Group. I have already rebooted.
> Any ideas?
> TIA, ChrisR
>
Operator failing
sql2k sp3
SQLMail and the Mail Profile are configured and
successfully test when hitting the "test" button in the
SQL Mail Configuration Properties box.
But when I try to do a test for an operator in the
Operator Properties it says "Error 22022: SQLServerAgent
mail session not running; check mail profile and/ or
SQLServerAgent service startup account in SQLServerAgent
properites dialog box".
The Agent and the Mail Profile(same account) are in the
Local Admins Group. I have already rebooted.
Any ideas?
TIA, ChrisRHi Chris
You have already asked this question once and got a reply...:-).
Have you tried to check the properties of the SQLSERVERAgent in EM. Here
you have to set a mailprofile for the mail session.
Regards
Steen
"ChrtisR" <anonymous@.discussions.microsoft.com> skrev i en meddelelse
news:2901301c464fa$6779e5a0$a501280a@.phx.gbl...
> sql2k sp3
> SQLMail and the Mail Profile are configured and
> successfully test when hitting the "test" button in the
> SQL Mail Configuration Properties box.
> But when I try to do a test for an operator in the
> Operator Properties it says "Error 22022: SQLServerAgent
> mail session not running; check mail profile and/ or
> SQLServerAgent service startup account in SQLServerAgent
> properites dialog box".
> The Agent and the Mail Profile(same account) are in the
> Local Admins Group. I have already rebooted.
> Any ideas?
> TIA, ChrisR
>
SQLMail and the Mail Profile are configured and
successfully test when hitting the "test" button in the
SQL Mail Configuration Properties box.
But when I try to do a test for an operator in the
Operator Properties it says "Error 22022: SQLServerAgent
mail session not running; check mail profile and/ or
SQLServerAgent service startup account in SQLServerAgent
properites dialog box".
The Agent and the Mail Profile(same account) are in the
Local Admins Group. I have already rebooted.
Any ideas?
TIA, ChrisRHi Chris
You have already asked this question once and got a reply...:-).
Have you tried to check the properties of the SQLSERVERAgent in EM. Here
you have to set a mailprofile for the mail session.
Regards
Steen
"ChrtisR" <anonymous@.discussions.microsoft.com> skrev i en meddelelse
news:2901301c464fa$6779e5a0$a501280a@.phx.gbl...
> sql2k sp3
> SQLMail and the Mail Profile are configured and
> successfully test when hitting the "test" button in the
> SQL Mail Configuration Properties box.
> But when I try to do a test for an operator in the
> Operator Properties it says "Error 22022: SQLServerAgent
> mail session not running; check mail profile and/ or
> SQLServerAgent service startup account in SQLServerAgent
> properites dialog box".
> The Agent and the Mail Profile(same account) are in the
> Local Admins Group. I have already rebooted.
> Any ideas?
> TIA, ChrisR
>
Subscribe to:
Posts (Atom)