We have a 12 disk 2.4TB Raid 10 Array, where we have 3 large database data
files, theres been a suggestion that we split the physical drive into 3
partitions so if we have to grow the files in future the files will stay
contiguous on the disk.. ..I'm not worried about splitting the array into
three from a size point of view we have bags of space for future growth..
...I'm aware the databases should be sized properly so they don't autogrow and
that minimal fragmentation at the os level will have little to no impact on
the performance... ...however for sake of argument will splitting the RAID
array into the 3 partitions keep the database files contiguous on the disks,
and would there be any performance hit on the array by splitting it into 3
volumes?
Thanks in advance
Ben
I'd be inclined to not create three logical partitions. I don't have any
current empirical data to back me up on this. But I do remember a Compaq
study a few years ago on using a single partition vs. multiple logical
partitions on a physical device, and the single partition configuration came
out better performance wise. I'm not claiming that the Compaq study is still
relevant. But then I don't see any substantial benefit of creating three
logical partitions.
The practice I follow has always been: single physical device (as presented
to the OS) -> single partition -> single NTFS volume.
Do note that if you have files on the same volume, moving a file to another
place on that same volume is a filesystem metadata operation. Moving a file
across volumes, however, must move data. If you don't plan to move your
files, this is not an issue.
Linchi
"Ben UK" wrote:
> We have a 12 disk 2.4TB Raid 10 Array, where we have 3 large database data
> files, theres been a suggestion that we split the physical drive into 3
> partitions so if we have to grow the files in future the files will stay
> contiguous on the disk.. ..I'm not worried about splitting the array into
> three from a size point of view we have bags of space for future growth..
> ..I'm aware the databases should be sized properly so they don't autogrow and
> that minimal fragmentation at the os level will have little to no impact on
> the performance... ...however for sake of argument will splitting the RAID
> array into the 3 partitions keep the database files contiguous on the disks,
> and would there be any performance hit on the array by splitting it into 3
> volumes?
> Thanks in advance
> Ben
Showing posts with label raid. Show all posts
Showing posts with label raid. Show all posts
Monday, February 20, 2012
Partitions on RAID Array
We have a 12 disk 2.4TB Raid 10 Array, where we have 3 large database data
files, theres been a suggestion that we split the physical drive into 3
partitions so if we have to grow the files in future the files will stay
contiguous on the disk.. ..I'm not worried about splitting the array into
three from a size point of view we have bags of space for future growth..
..I'm aware the databases should be sized properly so they don't autogrow a
nd
that minimal fragmentation at the os level will have little to no impact on
the performance... ...however for sake of argument will splitting the RAID
array into the 3 partitions keep the database files contiguous on the disks,
and would there be any performance hit on the array by splitting it into 3
volumes?
Thanks in advance
BenI'd be inclined to not create three logical partitions. I don't have any
current empirical data to back me up on this. But I do remember a Compaq
study a few years ago on using a single partition vs. multiple logical
partitions on a physical device, and the single partition configuration came
out better performance wise. I'm not claiming that the Compaq study is still
relevant. But then I don't see any substantial benefit of creating three
logical partitions.
The practice I follow has always been: single physical device (as presented
to the OS) -> single partition -> single NTFS volume.
Do note that if you have files on the same volume, moving a file to another
place on that same volume is a filesystem metadata operation. Moving a file
across volumes, however, must move data. If you don't plan to move your
files, this is not an issue.
Linchi
"Ben UK" wrote:
> We have a 12 disk 2.4TB Raid 10 Array, where we have 3 large database data
> files, theres been a suggestion that we split the physical drive into 3
> partitions so if we have to grow the files in future the files will stay
> contiguous on the disk.. ..I'm not worried about splitting the array into
> three from a size point of view we have bags of space for future growth..
> ..I'm aware the databases should be sized properly so they don't autogrow
and
> that minimal fragmentation at the os level will have little to no impact o
n
> the performance... ...however for sake of argument will splitting the RAID
> array into the 3 partitions keep the database files contiguous on the disk
s,
> and would there be any performance hit on the array by splitting it into 3
> volumes?
> Thanks in advance
> Ben|||Hi Ben,
I tend to agree with Linchi, that splitting it up might not give you
much in term of performance. If you should gain from splitting the files
up, you should split them up on physical different spindles and best of
all on seperate disk controllers. If you go down that route, you should
at the same time add some more spindles to each array - otherwise I
don't think you'll gain anything from the change.
You can also try to look at www.storageperformance.org to see if you can
find some usefull info in there.
Regards
Steen Schlüter Persson
Database Administrator / System Administrator
Ben UK wrote:
> We have a 12 disk 2.4TB Raid 10 Array, where we have 3 large database data
> files, theres been a suggestion that we split the physical drive into 3
> partitions so if we have to grow the files in future the files will stay
> contiguous on the disk.. ..I'm not worried about splitting the array into
> three from a size point of view we have bags of space for future growth..
> ..I'm aware the databases should be sized properly so they don't autogrow
and
> that minimal fragmentation at the os level will have little to no impact o
n
> the performance... ...however for sake of argument will splitting the RAID
> array into the 3 partitions keep the database files contiguous on the disk
s,
> and would there be any performance hit on the array by splitting it into 3
> volumes?
> Thanks in advance
> Ben
files, theres been a suggestion that we split the physical drive into 3
partitions so if we have to grow the files in future the files will stay
contiguous on the disk.. ..I'm not worried about splitting the array into
three from a size point of view we have bags of space for future growth..
..I'm aware the databases should be sized properly so they don't autogrow a
nd
that minimal fragmentation at the os level will have little to no impact on
the performance... ...however for sake of argument will splitting the RAID
array into the 3 partitions keep the database files contiguous on the disks,
and would there be any performance hit on the array by splitting it into 3
volumes?
Thanks in advance
BenI'd be inclined to not create three logical partitions. I don't have any
current empirical data to back me up on this. But I do remember a Compaq
study a few years ago on using a single partition vs. multiple logical
partitions on a physical device, and the single partition configuration came
out better performance wise. I'm not claiming that the Compaq study is still
relevant. But then I don't see any substantial benefit of creating three
logical partitions.
The practice I follow has always been: single physical device (as presented
to the OS) -> single partition -> single NTFS volume.
Do note that if you have files on the same volume, moving a file to another
place on that same volume is a filesystem metadata operation. Moving a file
across volumes, however, must move data. If you don't plan to move your
files, this is not an issue.
Linchi
"Ben UK" wrote:
> We have a 12 disk 2.4TB Raid 10 Array, where we have 3 large database data
> files, theres been a suggestion that we split the physical drive into 3
> partitions so if we have to grow the files in future the files will stay
> contiguous on the disk.. ..I'm not worried about splitting the array into
> three from a size point of view we have bags of space for future growth..
> ..I'm aware the databases should be sized properly so they don't autogrow
and
> that minimal fragmentation at the os level will have little to no impact o
n
> the performance... ...however for sake of argument will splitting the RAID
> array into the 3 partitions keep the database files contiguous on the disk
s,
> and would there be any performance hit on the array by splitting it into 3
> volumes?
> Thanks in advance
> Ben|||Hi Ben,
I tend to agree with Linchi, that splitting it up might not give you
much in term of performance. If you should gain from splitting the files
up, you should split them up on physical different spindles and best of
all on seperate disk controllers. If you go down that route, you should
at the same time add some more spindles to each array - otherwise I
don't think you'll gain anything from the change.
You can also try to look at www.storageperformance.org to see if you can
find some usefull info in there.
Regards
Steen Schlüter Persson
Database Administrator / System Administrator
Ben UK wrote:
> We have a 12 disk 2.4TB Raid 10 Array, where we have 3 large database data
> files, theres been a suggestion that we split the physical drive into 3
> partitions so if we have to grow the files in future the files will stay
> contiguous on the disk.. ..I'm not worried about splitting the array into
> three from a size point of view we have bags of space for future growth..
> ..I'm aware the databases should be sized properly so they don't autogrow
and
> that minimal fragmentation at the os level will have little to no impact o
n
> the performance... ...however for sake of argument will splitting the RAID
> array into the 3 partitions keep the database files contiguous on the disk
s,
> and would there be any performance hit on the array by splitting it into 3
> volumes?
> Thanks in advance
> Ben
partitions
Hi,
I have a question in the middle beetween Windows and SQL.
I have RAID 5 system and then I can put SQL database and log file where i
want...
But..
Can be important create more logical partitions in RAID system for improve
defrag efficiency?
Example: I have only one database in SQL. I create a system partition C, a
database partition D and a log partition E.
Can I have better performance putting database in D and log in E?
Thank's a lot.. and sotty for my english..
Andrea
Since the drives are all a single Raid 5 you will not gain any performance by
spreading the data to the D drive and logs to the E drive.
"Rusty73" wrote:
> Hi,
> I have a question in the middle beetween Windows and SQL.
> I have RAID 5 system and then I can put SQL database and log file where i
> want...
> But..
> Can be important create more logical partitions in RAID system for improve
> defrag efficiency?
> Example: I have only one database in SQL. I create a system partition C, a
> database partition D and a log partition E.
> Can I have better performance putting database in D and log in E?
> Thank's a lot.. and sotty for my english..
> Andrea
>
>
|||I know that log files are writing sequentially to the disk btu with RAID 5 i
can decide to block the writing only on log disk...
but I can have no better performance to the defrag of log?
"fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...[vbcol=seagreen]
> Since the drives are all a single Raid 5 you will not gain any performance
> by
> spreading the data to the D drive and logs to the E drive.
>
> "Rusty73" wrote:
|||The best way to combat file fragmentation is to create the database files
once, as large as you will need them. If the files are allocated
contigueously, and never grow, then no file fragmentation will occur. Make
sure you give enough room for the Index Defrags, that will use internal data
pages, not file fragments to reorganize, again, as long as the file does not
grow.
Go ahead and leave the AUTOGROW feature on, but only as a fail-safe, in case
you've underestimated the space you will need.
Besides, file fragmentation will only affect scans and DSS type queries.
For a true OLTP system, the disk and database page access will be pretty
random, which will not be affected as much by file level fragmentation.
Sincerely,
Anthony Thomas
"Rusty73" <rusty77@.libero.it> wrote in message
news:%23iqlJn6tFHA.3932@.TK2MSFTNGP15.phx.gbl...
I know that log files are writing sequentially to the disk btu with RAID 5 i
can decide to block the writing only on log disk...
but I can have no better performance to the defrag of log?
"fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...[vbcol=seagreen]
> Since the drives are all a single Raid 5 you will not gain any performance
> by
> spreading the data to the D drive and logs to the E drive.
>
> "Rusty73" wrote:
|||Hi there,
Raid 5 will give you better performance for the DB.
For logs is best to create a mirror pair for improved performance, exactly
because of sequential writing.
My server is configured as follows:
system partition C - array of 2 mirrored drives - RAID 1
DB partition - array of a few disks in raid 5
log partition - another pair of mirrored drives - RAID 1
I agree with the previous comment that having different logical partitions
on the same disk array will not improve performance.
Hope this helps.
Kind regards,
Doru
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:u7bc6z$tFHA.2848@.TK2MSFTNGP10.phx.gbl...
> The best way to combat file fragmentation is to create the database files
> once, as large as you will need them. If the files are allocated
> contigueously, and never grow, then no file fragmentation will occur.
> Make
> sure you give enough room for the Index Defrags, that will use internal
> data
> pages, not file fragments to reorganize, again, as long as the file does
> not
> grow.
> Go ahead and leave the AUTOGROW feature on, but only as a fail-safe, in
> case
> you've underestimated the space you will need.
> Besides, file fragmentation will only affect scans and DSS type queries.
> For a true OLTP system, the disk and database page access will be pretty
> random, which will not be affected as much by file level fragmentation.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Rusty73" <rusty77@.libero.it> wrote in message
> news:%23iqlJn6tFHA.3932@.TK2MSFTNGP15.phx.gbl...
> I know that log files are writing sequentially to the disk btu with RAID 5
> i
> can decide to block the writing only on log disk...
> but I can have no better performance to the defrag of log?
> "fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
> news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...
>
I have a question in the middle beetween Windows and SQL.
I have RAID 5 system and then I can put SQL database and log file where i
want...
But..
Can be important create more logical partitions in RAID system for improve
defrag efficiency?
Example: I have only one database in SQL. I create a system partition C, a
database partition D and a log partition E.
Can I have better performance putting database in D and log in E?
Thank's a lot.. and sotty for my english..
Andrea
Since the drives are all a single Raid 5 you will not gain any performance by
spreading the data to the D drive and logs to the E drive.
"Rusty73" wrote:
> Hi,
> I have a question in the middle beetween Windows and SQL.
> I have RAID 5 system and then I can put SQL database and log file where i
> want...
> But..
> Can be important create more logical partitions in RAID system for improve
> defrag efficiency?
> Example: I have only one database in SQL. I create a system partition C, a
> database partition D and a log partition E.
> Can I have better performance putting database in D and log in E?
> Thank's a lot.. and sotty for my english..
> Andrea
>
>
|||I know that log files are writing sequentially to the disk btu with RAID 5 i
can decide to block the writing only on log disk...
but I can have no better performance to the defrag of log?
"fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...[vbcol=seagreen]
> Since the drives are all a single Raid 5 you will not gain any performance
> by
> spreading the data to the D drive and logs to the E drive.
>
> "Rusty73" wrote:
|||The best way to combat file fragmentation is to create the database files
once, as large as you will need them. If the files are allocated
contigueously, and never grow, then no file fragmentation will occur. Make
sure you give enough room for the Index Defrags, that will use internal data
pages, not file fragments to reorganize, again, as long as the file does not
grow.
Go ahead and leave the AUTOGROW feature on, but only as a fail-safe, in case
you've underestimated the space you will need.
Besides, file fragmentation will only affect scans and DSS type queries.
For a true OLTP system, the disk and database page access will be pretty
random, which will not be affected as much by file level fragmentation.
Sincerely,
Anthony Thomas
"Rusty73" <rusty77@.libero.it> wrote in message
news:%23iqlJn6tFHA.3932@.TK2MSFTNGP15.phx.gbl...
I know that log files are writing sequentially to the disk btu with RAID 5 i
can decide to block the writing only on log disk...
but I can have no better performance to the defrag of log?
"fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...[vbcol=seagreen]
> Since the drives are all a single Raid 5 you will not gain any performance
> by
> spreading the data to the D drive and logs to the E drive.
>
> "Rusty73" wrote:
|||Hi there,
Raid 5 will give you better performance for the DB.
For logs is best to create a mirror pair for improved performance, exactly
because of sequential writing.
My server is configured as follows:
system partition C - array of 2 mirrored drives - RAID 1
DB partition - array of a few disks in raid 5
log partition - another pair of mirrored drives - RAID 1
I agree with the previous comment that having different logical partitions
on the same disk array will not improve performance.
Hope this helps.
Kind regards,
Doru
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:u7bc6z$tFHA.2848@.TK2MSFTNGP10.phx.gbl...
> The best way to combat file fragmentation is to create the database files
> once, as large as you will need them. If the files are allocated
> contigueously, and never grow, then no file fragmentation will occur.
> Make
> sure you give enough room for the Index Defrags, that will use internal
> data
> pages, not file fragments to reorganize, again, as long as the file does
> not
> grow.
> Go ahead and leave the AUTOGROW feature on, but only as a fail-safe, in
> case
> you've underestimated the space you will need.
> Besides, file fragmentation will only affect scans and DSS type queries.
> For a true OLTP system, the disk and database page access will be pretty
> random, which will not be affected as much by file level fragmentation.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Rusty73" <rusty77@.libero.it> wrote in message
> news:%23iqlJn6tFHA.3932@.TK2MSFTNGP15.phx.gbl...
> I know that log files are writing sequentially to the disk btu with RAID 5
> i
> can decide to block the writing only on log disk...
> but I can have no better performance to the defrag of log?
> "fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
> news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...
>
partitions
Hi,
I have a question in the middle beetween Windows and SQL.
I have RAID 5 system and then I can put SQL database and log file where i
want...
But..
Can be important create more logical partitions in RAID system for improve
defrag efficiency'
Example: I have only one database in SQL. I create a system partition C, a
database partition D and a log partition E.
Can I have better performance putting database in D and log in E?
Thank's a lot.. and sotty for my english..
AndreaSince the drives are all a single Raid 5 you will not gain any performance b
y
spreading the data to the D drive and logs to the E drive.
"Rusty73" wrote:
> Hi,
> I have a question in the middle beetween Windows and SQL.
> I have RAID 5 system and then I can put SQL database and log file where i
> want...
> But..
> Can be important create more logical partitions in RAID system for improve
> defrag efficiency'
> Example: I have only one database in SQL. I create a system partition C, a
> database partition D and a log partition E.
> Can I have better performance putting database in D and log in E?
> Thank's a lot.. and sotty for my english..
> Andrea
>
>|||I know that log files are writing sequentially to the disk btu with RAID 5 i
can decide to block the writing only on log disk...
but I can have no better performance to the defrag of log?
"fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...[vbcol=seagreen]
> Since the drives are all a single Raid 5 you will not gain any performance
> by
> spreading the data to the D drive and logs to the E drive.
>
> "Rusty73" wrote:
>|||The best way to combat file fragmentation is to create the database files
once, as large as you will need them. If the files are allocated
contigueously, and never grow, then no file fragmentation will occur. Make
sure you give enough room for the Index Defrags, that will use internal data
pages, not file fragments to reorganize, again, as long as the file does not
grow.
Go ahead and leave the AUTOGROW feature on, but only as a fail-safe, in case
you've underestimated the space you will need.
Besides, file fragmentation will only affect scans and DSS type queries.
For a true OLTP system, the disk and database page access will be pretty
random, which will not be affected as much by file level fragmentation.
Sincerely,
Anthony Thomas
"Rusty73" <rusty77@.libero.it> wrote in message
news:%23iqlJn6tFHA.3932@.TK2MSFTNGP15.phx.gbl...
I know that log files are writing sequentially to the disk btu with RAID 5 i
can decide to block the writing only on log disk...
but I can have no better performance to the defrag of log?
"fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...[vbcol=seagreen]
> Since the drives are all a single Raid 5 you will not gain any performance
> by
> spreading the data to the D drive and logs to the E drive.
>
> "Rusty73" wrote:
>|||Hi there,
Raid 5 will give you better performance for the DB.
For logs is best to create a mirror pair for improved performance, exactly
because of sequential writing.
My server is configured as follows:
system partition C - array of 2 mirrored drives - RAID 1
DB partition - array of a few disks in raid 5
log partition - another pair of mirrored drives - RAID 1
I agree with the previous comment that having different logical partitions
on the same disk array will not improve performance.
Hope this helps.
Kind regards,
Doru
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:u7bc6z$tFHA.2848@.TK2MSFTNGP10.phx.gbl...
> The best way to combat file fragmentation is to create the database files
> once, as large as you will need them. If the files are allocated
> contigueously, and never grow, then no file fragmentation will occur.
> Make
> sure you give enough room for the Index Defrags, that will use internal
> data
> pages, not file fragments to reorganize, again, as long as the file does
> not
> grow.
> Go ahead and leave the AUTOGROW feature on, but only as a fail-safe, in
> case
> you've underestimated the space you will need.
> Besides, file fragmentation will only affect scans and DSS type queries.
> For a true OLTP system, the disk and database page access will be pretty
> random, which will not be affected as much by file level fragmentation.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Rusty73" <rusty77@.libero.it> wrote in message
> news:%23iqlJn6tFHA.3932@.TK2MSFTNGP15.phx.gbl...
> I know that log files are writing sequentially to the disk btu with RAID 5
> i
> can decide to block the writing only on log disk...
> but I can have no better performance to the defrag of log?
> "fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
> news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...
>
I have a question in the middle beetween Windows and SQL.
I have RAID 5 system and then I can put SQL database and log file where i
want...
But..
Can be important create more logical partitions in RAID system for improve
defrag efficiency'
Example: I have only one database in SQL. I create a system partition C, a
database partition D and a log partition E.
Can I have better performance putting database in D and log in E?
Thank's a lot.. and sotty for my english..
AndreaSince the drives are all a single Raid 5 you will not gain any performance b
y
spreading the data to the D drive and logs to the E drive.
"Rusty73" wrote:
> Hi,
> I have a question in the middle beetween Windows and SQL.
> I have RAID 5 system and then I can put SQL database and log file where i
> want...
> But..
> Can be important create more logical partitions in RAID system for improve
> defrag efficiency'
> Example: I have only one database in SQL. I create a system partition C, a
> database partition D and a log partition E.
> Can I have better performance putting database in D and log in E?
> Thank's a lot.. and sotty for my english..
> Andrea
>
>|||I know that log files are writing sequentially to the disk btu with RAID 5 i
can decide to block the writing only on log disk...
but I can have no better performance to the defrag of log?
"fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...[vbcol=seagreen]
> Since the drives are all a single Raid 5 you will not gain any performance
> by
> spreading the data to the D drive and logs to the E drive.
>
> "Rusty73" wrote:
>|||The best way to combat file fragmentation is to create the database files
once, as large as you will need them. If the files are allocated
contigueously, and never grow, then no file fragmentation will occur. Make
sure you give enough room for the Index Defrags, that will use internal data
pages, not file fragments to reorganize, again, as long as the file does not
grow.
Go ahead and leave the AUTOGROW feature on, but only as a fail-safe, in case
you've underestimated the space you will need.
Besides, file fragmentation will only affect scans and DSS type queries.
For a true OLTP system, the disk and database page access will be pretty
random, which will not be affected as much by file level fragmentation.
Sincerely,
Anthony Thomas
"Rusty73" <rusty77@.libero.it> wrote in message
news:%23iqlJn6tFHA.3932@.TK2MSFTNGP15.phx.gbl...
I know that log files are writing sequentially to the disk btu with RAID 5 i
can decide to block the writing only on log disk...
but I can have no better performance to the defrag of log?
"fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...[vbcol=seagreen]
> Since the drives are all a single Raid 5 you will not gain any performance
> by
> spreading the data to the D drive and logs to the E drive.
>
> "Rusty73" wrote:
>|||Hi there,
Raid 5 will give you better performance for the DB.
For logs is best to create a mirror pair for improved performance, exactly
because of sequential writing.
My server is configured as follows:
system partition C - array of 2 mirrored drives - RAID 1
DB partition - array of a few disks in raid 5
log partition - another pair of mirrored drives - RAID 1
I agree with the previous comment that having different logical partitions
on the same disk array will not improve performance.
Hope this helps.
Kind regards,
Doru
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:u7bc6z$tFHA.2848@.TK2MSFTNGP10.phx.gbl...
> The best way to combat file fragmentation is to create the database files
> once, as large as you will need them. If the files are allocated
> contigueously, and never grow, then no file fragmentation will occur.
> Make
> sure you give enough room for the Index Defrags, that will use internal
> data
> pages, not file fragments to reorganize, again, as long as the file does
> not
> grow.
> Go ahead and leave the AUTOGROW feature on, but only as a fail-safe, in
> case
> you've underestimated the space you will need.
> Besides, file fragmentation will only affect scans and DSS type queries.
> For a true OLTP system, the disk and database page access will be pretty
> random, which will not be affected as much by file level fragmentation.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Rusty73" <rusty77@.libero.it> wrote in message
> news:%23iqlJn6tFHA.3932@.TK2MSFTNGP15.phx.gbl...
> I know that log files are writing sequentially to the disk btu with RAID 5
> i
> can decide to block the writing only on log disk...
> but I can have no better performance to the defrag of log?
> "fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
> news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...
>
partitions
Hi,
I have a question in the middle beetween Windows and SQL.
I have RAID 5 system and then I can put SQL database and log file where i
want...
But..
Can be important create more logical partitions in RAID system for improve
defrag efficiency'
Example: I have only one database in SQL. I create a system partition C, a
database partition D and a log partition E.
Can I have better performance putting database in D and log in E?
Thank's a lot.. and sotty for my english..
AndreaSince the drives are all a single Raid 5 you will not gain any performance by
spreading the data to the D drive and logs to the E drive.
"Rusty73" wrote:
> Hi,
> I have a question in the middle beetween Windows and SQL.
> I have RAID 5 system and then I can put SQL database and log file where i
> want...
> But..
> Can be important create more logical partitions in RAID system for improve
> defrag efficiency'
> Example: I have only one database in SQL. I create a system partition C, a
> database partition D and a log partition E.
> Can I have better performance putting database in D and log in E?
> Thank's a lot.. and sotty for my english..
> Andrea
>
>|||I know that log files are writing sequentially to the disk btu with RAID 5 i
can decide to block the writing only on log disk...
but I can have no better performance to the defrag of log?
"fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...
> Since the drives are all a single Raid 5 you will not gain any performance
> by
> spreading the data to the D drive and logs to the E drive.
>
> "Rusty73" wrote:
>> Hi,
>> I have a question in the middle beetween Windows and SQL.
>> I have RAID 5 system and then I can put SQL database and log file where i
>> want...
>> But..
>> Can be important create more logical partitions in RAID system for
>> improve
>> defrag efficiency'
>> Example: I have only one database in SQL. I create a system partition C,
>> a
>> database partition D and a log partition E.
>> Can I have better performance putting database in D and log in E?
>> Thank's a lot.. and sotty for my english..
>> Andrea
>>|||The best way to combat file fragmentation is to create the database files
once, as large as you will need them. If the files are allocated
contigueously, and never grow, then no file fragmentation will occur. Make
sure you give enough room for the Index Defrags, that will use internal data
pages, not file fragments to reorganize, again, as long as the file does not
grow.
Go ahead and leave the AUTOGROW feature on, but only as a fail-safe, in case
you've underestimated the space you will need.
Besides, file fragmentation will only affect scans and DSS type queries.
For a true OLTP system, the disk and database page access will be pretty
random, which will not be affected as much by file level fragmentation.
Sincerely,
Anthony Thomas
"Rusty73" <rusty77@.libero.it> wrote in message
news:%23iqlJn6tFHA.3932@.TK2MSFTNGP15.phx.gbl...
I know that log files are writing sequentially to the disk btu with RAID 5 i
can decide to block the writing only on log disk...
but I can have no better performance to the defrag of log?
"fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...
> Since the drives are all a single Raid 5 you will not gain any performance
> by
> spreading the data to the D drive and logs to the E drive.
>
> "Rusty73" wrote:
>> Hi,
>> I have a question in the middle beetween Windows and SQL.
>> I have RAID 5 system and then I can put SQL database and log file where i
>> want...
>> But..
>> Can be important create more logical partitions in RAID system for
>> improve
>> defrag efficiency'
>> Example: I have only one database in SQL. I create a system partition C,
>> a
>> database partition D and a log partition E.
>> Can I have better performance putting database in D and log in E?
>> Thank's a lot.. and sotty for my english..
>> Andrea
>>|||Hi there,
Raid 5 will give you better performance for the DB.
For logs is best to create a mirror pair for improved performance, exactly
because of sequential writing.
My server is configured as follows:
system partition C - array of 2 mirrored drives - RAID 1
DB partition - array of a few disks in raid 5
log partition - another pair of mirrored drives - RAID 1
I agree with the previous comment that having different logical partitions
on the same disk array will not improve performance.
Hope this helps.
Kind regards,
Doru
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:u7bc6z$tFHA.2848@.TK2MSFTNGP10.phx.gbl...
> The best way to combat file fragmentation is to create the database files
> once, as large as you will need them. If the files are allocated
> contigueously, and never grow, then no file fragmentation will occur.
> Make
> sure you give enough room for the Index Defrags, that will use internal
> data
> pages, not file fragments to reorganize, again, as long as the file does
> not
> grow.
> Go ahead and leave the AUTOGROW feature on, but only as a fail-safe, in
> case
> you've underestimated the space you will need.
> Besides, file fragmentation will only affect scans and DSS type queries.
> For a true OLTP system, the disk and database page access will be pretty
> random, which will not be affected as much by file level fragmentation.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Rusty73" <rusty77@.libero.it> wrote in message
> news:%23iqlJn6tFHA.3932@.TK2MSFTNGP15.phx.gbl...
> I know that log files are writing sequentially to the disk btu with RAID 5
> i
> can decide to block the writing only on log disk...
> but I can have no better performance to the defrag of log?
> "fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
> news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...
>> Since the drives are all a single Raid 5 you will not gain any
>> performance
>> by
>> spreading the data to the D drive and logs to the E drive.
>>
>> "Rusty73" wrote:
>> Hi,
>> I have a question in the middle beetween Windows and SQL.
>> I have RAID 5 system and then I can put SQL database and log file where
>> i
>> want...
>> But..
>> Can be important create more logical partitions in RAID system for
>> improve
>> defrag efficiency'
>> Example: I have only one database in SQL. I create a system partition C,
>> a
>> database partition D and a log partition E.
>> Can I have better performance putting database in D and log in E?
>> Thank's a lot.. and sotty for my english..
>> Andrea
>>
>
I have a question in the middle beetween Windows and SQL.
I have RAID 5 system and then I can put SQL database and log file where i
want...
But..
Can be important create more logical partitions in RAID system for improve
defrag efficiency'
Example: I have only one database in SQL. I create a system partition C, a
database partition D and a log partition E.
Can I have better performance putting database in D and log in E?
Thank's a lot.. and sotty for my english..
AndreaSince the drives are all a single Raid 5 you will not gain any performance by
spreading the data to the D drive and logs to the E drive.
"Rusty73" wrote:
> Hi,
> I have a question in the middle beetween Windows and SQL.
> I have RAID 5 system and then I can put SQL database and log file where i
> want...
> But..
> Can be important create more logical partitions in RAID system for improve
> defrag efficiency'
> Example: I have only one database in SQL. I create a system partition C, a
> database partition D and a log partition E.
> Can I have better performance putting database in D and log in E?
> Thank's a lot.. and sotty for my english..
> Andrea
>
>|||I know that log files are writing sequentially to the disk btu with RAID 5 i
can decide to block the writing only on log disk...
but I can have no better performance to the defrag of log?
"fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...
> Since the drives are all a single Raid 5 you will not gain any performance
> by
> spreading the data to the D drive and logs to the E drive.
>
> "Rusty73" wrote:
>> Hi,
>> I have a question in the middle beetween Windows and SQL.
>> I have RAID 5 system and then I can put SQL database and log file where i
>> want...
>> But..
>> Can be important create more logical partitions in RAID system for
>> improve
>> defrag efficiency'
>> Example: I have only one database in SQL. I create a system partition C,
>> a
>> database partition D and a log partition E.
>> Can I have better performance putting database in D and log in E?
>> Thank's a lot.. and sotty for my english..
>> Andrea
>>|||The best way to combat file fragmentation is to create the database files
once, as large as you will need them. If the files are allocated
contigueously, and never grow, then no file fragmentation will occur. Make
sure you give enough room for the Index Defrags, that will use internal data
pages, not file fragments to reorganize, again, as long as the file does not
grow.
Go ahead and leave the AUTOGROW feature on, but only as a fail-safe, in case
you've underestimated the space you will need.
Besides, file fragmentation will only affect scans and DSS type queries.
For a true OLTP system, the disk and database page access will be pretty
random, which will not be affected as much by file level fragmentation.
Sincerely,
Anthony Thomas
"Rusty73" <rusty77@.libero.it> wrote in message
news:%23iqlJn6tFHA.3932@.TK2MSFTNGP15.phx.gbl...
I know that log files are writing sequentially to the disk btu with RAID 5 i
can decide to block the writing only on log disk...
but I can have no better performance to the defrag of log?
"fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...
> Since the drives are all a single Raid 5 you will not gain any performance
> by
> spreading the data to the D drive and logs to the E drive.
>
> "Rusty73" wrote:
>> Hi,
>> I have a question in the middle beetween Windows and SQL.
>> I have RAID 5 system and then I can put SQL database and log file where i
>> want...
>> But..
>> Can be important create more logical partitions in RAID system for
>> improve
>> defrag efficiency'
>> Example: I have only one database in SQL. I create a system partition C,
>> a
>> database partition D and a log partition E.
>> Can I have better performance putting database in D and log in E?
>> Thank's a lot.. and sotty for my english..
>> Andrea
>>|||Hi there,
Raid 5 will give you better performance for the DB.
For logs is best to create a mirror pair for improved performance, exactly
because of sequential writing.
My server is configured as follows:
system partition C - array of 2 mirrored drives - RAID 1
DB partition - array of a few disks in raid 5
log partition - another pair of mirrored drives - RAID 1
I agree with the previous comment that having different logical partitions
on the same disk array will not improve performance.
Hope this helps.
Kind regards,
Doru
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:u7bc6z$tFHA.2848@.TK2MSFTNGP10.phx.gbl...
> The best way to combat file fragmentation is to create the database files
> once, as large as you will need them. If the files are allocated
> contigueously, and never grow, then no file fragmentation will occur.
> Make
> sure you give enough room for the Index Defrags, that will use internal
> data
> pages, not file fragments to reorganize, again, as long as the file does
> not
> grow.
> Go ahead and leave the AUTOGROW feature on, but only as a fail-safe, in
> case
> you've underestimated the space you will need.
> Besides, file fragmentation will only affect scans and DSS type queries.
> For a true OLTP system, the disk and database page access will be pretty
> random, which will not be affected as much by file level fragmentation.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Rusty73" <rusty77@.libero.it> wrote in message
> news:%23iqlJn6tFHA.3932@.TK2MSFTNGP15.phx.gbl...
> I know that log files are writing sequentially to the disk btu with RAID 5
> i
> can decide to block the writing only on log disk...
> but I can have no better performance to the defrag of log?
> "fnguy" <fnguy@.discussions.microsoft.com> ha scritto nel messaggio
> news:B17E4200-29D1-429B-AD10-B2A9C41DC43B@.microsoft.com...
>> Since the drives are all a single Raid 5 you will not gain any
>> performance
>> by
>> spreading the data to the D drive and logs to the E drive.
>>
>> "Rusty73" wrote:
>> Hi,
>> I have a question in the middle beetween Windows and SQL.
>> I have RAID 5 system and then I can put SQL database and log file where
>> i
>> want...
>> But..
>> Can be important create more logical partitions in RAID system for
>> improve
>> defrag efficiency'
>> Example: I have only one database in SQL. I create a system partition C,
>> a
>> database partition D and a log partition E.
>> Can I have better performance putting database in D and log in E?
>> Thank's a lot.. and sotty for my english..
>> Andrea
>>
>
Subscribe to:
Posts (Atom)