RE: Disk setup
Larry asked how to present a 12 x 146GB disk cabinet to Informix 11.5 on Solaris 10 (RAID 0, 5, etc.). Art Kagel recommended RAID 10 with small stripe/block sizes (32K up to ~1MB, not the huge SAN defaults), separate mirrored pairs so hot tables, indexes and the logical/physical logs are isolated, and as many spindles as possible; he strongly warned against RAID 5. A follow-up on page sizes noted Informix uses 2K pages (4K on Windows/AIX/Mac), with dbspaces up to 16K, so 32K blocks suit 2K pages while 16K-page dbspaces tolerate larger blocks. Larry then said the new cabinet only supports RAID 0-5, so RAID 10 isn't possible, and asked for an alternative; no answer to that is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Solaris 10 IDS 11.5.FC7 - Growth I remember similar questions being asked in the past, but I can't remember what the concenseous was. I am being given a cabinet with 12-146GB disks to be used as raw storage for a database. The SA is asking how I want it presented....RAID 0, RAID 5...etc. What is the best option. Thanks
RAID10! Small stripe block sizes (32K to 1MB at most). SAN techs love to configure arrays with huge block sizes from 256MB to 1GB which works well for filesystems but is VERY VERY BAD for databases. Build multiple arrays of mirrored pairs so that you can isolate hot tables and indexes from each other and from the logical and physical logs. Ideally, if your logical log and physical log volume is below the bandwidth available from a single drive then make a singleton RAID1 mirrored pair for the logs alone (or one for each logical and physical logs if you need a bit more bandwidth) to keep the logs completely independent of your mainline data and gather the remaining disks into a single big RAID10 for your data and indexes. More spindles is better than fewer. If you can get more drives, double the number and create the VG's for the database to use only the middle 30-50% of the disk (ie not the outer or inner cylinders) and either leave the rest of the drive's space unused or allocated to dbspaces for very low access rate tables like historical or archival data tables. If space is tight, then build the biggest widest RAID10 array you can to spread the IOs out. NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! RAID5 is not a safe place for your data! Period! See my presentation from the 2012 IIUG Conference entitled "Doing Storage Right!" for details on why and the latest research on the subject. Also look for my RAID5 Rant on the BAARF website (www.baarf.com) in the left margin of the main page for a more complete explanation of why NO RAID5!!! Art Art S. Kagel, Principal Consultant Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Thu, Oct 17, 2013 at 10:51 PM, LARRY SORENSEN <lsorensen25@msn.com>wrote: > Solaris 10 > IDS 11.5.FC7 - Growth > > I remember similar questions being asked in the past, but I can't remember > what the concenseous was. I am being given a cabinet with 12-146GB disks > to be > used as raw storage for a database. The SA is asking how I want it > presented....RAID 0, RAID 5...etc. What is the best option. > > Thanks > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a11c233ea8d346304e8fbc410
Do you know what block size informix uses on Solaris 11? Currently running 11.70.FC7W2. --David in4mixdba On Thu, Oct 17, 2013 at 11:45 PM, Art Kagel <art.kagel@gmail.com> wrote: > RAID10! Small stripe block sizes (32K to 1MB at most). SAN techs love to > configure arrays with huge block sizes from 256MB to 1GB which works well > for filesystems but is VERY VERY BAD for databases. > > Build multiple arrays of mirrored pairs so that you can isolate hot tables > and indexes from each other and from the logical and physical logs. > Ideally, if your logical log and physical log volume is below the > bandwidth available from a single drive then make a singleton RAID1 > mirrored pair for the logs alone (or one for each logical and physical logs > if you need a bit more bandwidth) to keep the logs completely independent > of your mainline data and gather the remaining disks into a single big > RAID10 for your data and indexes. > > More spindles is better than fewer. If you can get more drives, double the > number and create the VG's for the database to use only the middle 30-50% > of the disk (ie not the outer or inner cylinders) and either leave the rest > of the drive's space unused or allocated to dbspaces for very low access > rate tables like historical or archival data tables. > > If space is tight, then build the biggest widest RAID10 array you can to > spread the IOs out. > > NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! > > RAID5 is not a safe place for your data! Period! > > See my presentation from the 2012 IIUG Conference entitled "Doing Storage > Right!" for details on why and the latest research on the subject. Also > look for my RAID5 Rant on the BAARF website (www.baarf.com) in the left > margin of the main page for a more complete explanation of why NO RAID5!!! > > Art > > Art S. Kagel, Principal Consultant > > Advanced DataTools (www.advancedatatools.com) > Blog: http://informix-myview.blogspot.com/ > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and do not reflect on my employer, Advanced DataTools, the IIUG, nor any > other organization with which I am associated either explicitly, > implicitly, or by inference. Neither do those opinions reflect those of > other individuals affiliated with any entity with which I am affiliated nor > those of the entities themselves. > > On Thu, Oct 17, 2013 at 10:51 PM, LARRY SORENSEN <lsorensen25@msn.com > >wrote: > > > Solaris 10 > > IDS 11.5.FC7 - Growth > > > > I remember similar questions being asked in the past, but I can't > remember > > what the concenseous was. I am being given a cabinet with 12-146GB disks > > to be > > used as raw storage for a database. The SA is asking how I want it > > presented....RAID 0, RAID 5...etc. What is the best option. > > > > Thanks > > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --001a11c233ea8d346304e8fbc410 > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a11c34f5c1cf7ca04e903aa8e
The default page size on all platforms except Windows, AIX, and MacOSx is 2K (4K on those platforms). However, since version 10.00 any dbspace except the rootdb dbspace and those holding logical or physical logs can be any multiple of the default page size for the platform up to 16K. Informix typically writes either a single page or up to 8 pages in a single IO, so depending on the dbspace's page size, on Solaris, that would be from 2K to 128K. If all of your dbspaces use 2K pages, then a block size of 32K works very well and performance seems to start dropping off above 128K. Chunks in dbspaces that use 16K pages, however, might do just as well with block sizes from 256K to 1MB. But with a finite number of spindles, you may not be able to build multiple RAID10 arrays with different block sizes for different dbspaces. Like everything else we do as DBAs, this is a bunch of tradeoffs. The thing to remember is that the RAID subsystem can only write a complete stripe block to any drive, so even a 2K write must write out the entire block (though not the entire stripe). Multiple contiguous writes from Informix closely spaced in time can be coalesced by the system into a single write, that's not guaranteed and unless you are in the midst of a bulk load or during checkpoint chunk writes just doesn't happen very often. LRU writes by the engine look mostly random to the RAID subsystem and occur in fits and spurts so far less coalescing happens, so if the stripe blocks are too big, you end up rewriting each block many times. We seek a Zen-like balance. ;-) Art Art S. Kagel, Principal Consultant Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Fri, Oct 18, 2013 at 9:11 AM, Informix DBA <in4mixdba@gmail.com> wrote: > Do you know what block size informix uses on Solaris 11? Currently > running 11.70.FC7W2. > > --David > in4mixdba > > On Thu, Oct 17, 2013 at 11:45 PM, Art Kagel <art.kagel@gmail.com> wrote: > > > RAID10! Small stripe block sizes (32K to 1MB at most). SAN techs love to > > configure arrays with huge block sizes from 256MB to 1GB which works well > > for filesystems but is VERY VERY BAD for databases. > > > > Build multiple arrays of mirrored pairs so that you can isolate hot > tables > > and indexes from each other and from the logical and physical logs. > > Ideally, if your logical log and physical log volume is below the > > bandwidth available from a single drive then make a singleton RAID1 > > mirrored pair for the logs alone (or one for each logical and physical > logs > > if you need a bit more bandwidth) to keep the logs completely independent > > of your mainline data and gather the remaining disks into a single big > > RAID10 for your data and indexes. > > > > More spindles is better than fewer. If you can get more drives, double > the > > number and create the VG's for the database to use only the middle 30-50% > > of the disk (ie not the outer or inner cylinders) and either leave the > rest > > of the drive's space unused or allocated to dbspaces for very low access > > rate tables like historical or archival data tables. > > > > If space is tight, then build the biggest widest RAID10 array you can to > > spread the IOs out. > > > > NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! > > > > RAID5 is not a safe place for your data! Period! > > > > See my presentation from the 2012 IIUG Conference entitled "Doing Storage > > Right!" for details on why and the latest research on the subject. Also > > look for my RAID5 Rant on the BAARF website (www.baarf.com) in the left > > margin of the main page for a more complete explanation of why NO > RAID5!!! > > > > Art > > > > Art S. Kagel, Principal Consultant > > > > Advanced DataTools (www.advancedatatools.com) > > Blog: http://informix-myview.blogspot.com/ > > > > Disclaimer: Please keep in mind that my own opinions are my own opinions > > and do not reflect on my employer, Advanced DataTools, the IIUG, nor any > > other organization with which I am associated either explicitly, > > implicitly, or by inference. Neither do those opinions reflect those of > > other individuals affiliated with any entity with which I am affiliated > nor > > those of the entities themselves. > > > > On Thu, Oct 17, 2013 at 10:51 PM, LARRY SORENSEN <lsorensen25@msn.com > > >wrote: > > > > > Solaris 10 > > > IDS 11.5.FC7 - Growth > > > > > > I remember similar questions being asked in the past, but I can't > > remember > > > what the concenseous was. I am being given a cabinet with 12-146GB > disks > > > to be > > > used as raw storage for a database. The SA is asking how I want it > > > presented....RAID 0, RAID 5...etc. What is the best option. > > > > > > Thanks > > > > > > > > > > > > > > > > > > ******************************************************************************* > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > --001a11c233ea8d346304e8fbc410 > > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --001a11c34f5c1cf7ca04e903aa8e > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e013d1866e05bb404e904358f
Art, Thank you for the detailed information and thank you for your continued support to this community. Have a great day, --David On Fri, Oct 18, 2013 at 9:50 AM, Art Kagel <art.kagel@gmail.com> wrote: > The default page size on all platforms except Windows, AIX, and MacOSx is > 2K (4K on those platforms). However, since version 10.00 any dbspace > except the rootdb dbspace and those holding logical or physical logs can be > any multiple of the default page size for the platform up to 16K. Informix > typically writes either a single page or up to 8 pages in a single IO, so > depending on the dbspace's page size, on Solaris, that would be from 2K to > 128K. If all of your dbspaces use 2K pages, then a block size of 32K works > very well and performance seems to start dropping off above 128K. Chunks > in dbspaces that use 16K pages, however, might do just as well with block > sizes from 256K to 1MB. But with a finite number of spindles, you may not > be able to build multiple RAID10 arrays with different block sizes for > different dbspaces. Like everything else we do as DBAs, this is a bunch of > tradeoffs. > > The thing to remember is that the RAID subsystem can only write a complete > stripe block to any drive, so even a 2K write must write out the entire > block (though not the entire stripe). Multiple contiguous writes from > Informix closely spaced in time can be coalesced by the system into a > single write, that's not guaranteed and unless you are in the midst of a > bulk load or during checkpoint chunk writes just doesn't happen very often. > LRU writes by the engine look mostly random to the RAID subsystem and > occur in fits and spurts so far less coalescing happens, so if the stripe > blocks are too big, you end up rewriting each block many times. We seek a > Zen-like balance. ;-) > > Art > > Art S. Kagel, Principal Consultant > > Advanced DataTools (www.advancedatatools.com) > Blog: http://informix-myview.blogspot.com/ > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and do not reflect on my employer, Advanced DataTools, the IIUG, nor any > other organization with which I am associated either explicitly, > implicitly, or by inference. Neither do those opinions reflect those of > other individuals affiliated with any entity with which I am affiliated nor > those of the entities themselves. > > On Fri, Oct 18, 2013 at 9:11 AM, Informix DBA <in4mixdba@gmail.com> wrote: > > > Do you know what block size informix uses on Solaris 11? Currently > > running 11.70.FC7W2. > > > > --David > > in4mixdba > > > > On Thu, Oct 17, 2013 at 11:45 PM, Art Kagel <art.kagel@gmail.com> wrote: > > > > > RAID10! Small stripe block sizes (32K to 1MB at most). SAN techs love > to > > > configure arrays with huge block sizes from 256MB to 1GB which works > well > > > for filesystems but is VERY VERY BAD for databases. > > > > > > Build multiple arrays of mirrored pairs so that you can isolate hot > > tables > > > and indexes from each other and from the logical and physical logs. > > > Ideally, if your logical log and physical log volume is below the > > > bandwidth available from a single drive then make a singleton RAID1 > > > mirrored pair for the logs alone (or one for each logical and physical > > logs > > > if you need a bit more bandwidth) to keep the logs completely > independent > > > of your mainline data and gather the remaining disks into a single big > > > RAID10 for your data and indexes. > > > > > > More spindles is better than fewer. If you can get more drives, double > > the > > > number and create the VG's for the database to use only the middle > 30-50% > > > of the disk (ie not the outer or inner cylinders) and either leave the > > rest > > > of the drive's space unused or allocated to dbspaces for very low > access > > > rate tables like historical or archival data tables. > > > > > > If space is tight, then build the biggest widest RAID10 array you can > to > > > spread the IOs out. > > > > > > NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! > > > > > > RAID5 is not a safe place for your data! Period! > > > > > > See my presentation from the 2012 IIUG Conference entitled "Doing > Storage > > > Right!" for details on why and the latest research on the subject. Also > > > look for my RAID5 Rant on the BAARF website (www.baarf.com) in the > left > > > margin of the main page for a more complete explanation of why NO > > RAID5!!! > > > > > > Art > > > > > > Art S. Kagel, Principal Consultant > > > > > > Advanced DataTools (www.advancedatatools.com) > > > Blog: http://informix-myview.blogspot.com/ > > > > > > Disclaimer: Please keep in mind that my own opinions are my own > opinions > > > and do not reflect on my employer, Advanced DataTools, the IIUG, nor > any > > > other organization with which I am associated either explicitly, > > > implicitly, or by inference. Neither do those opinions reflect those of > > > other individuals affiliated with any entity with which I am affiliated > > nor > > > those of the entities themselves. > > > > > > On Thu, Oct 17, 2013 at 10:51 PM, LARRY SORENSEN <lsorensen25@msn.com > > > >wrote: > > > > > > > Solaris 10 > > > > IDS 11.5.FC7 - Growth > > > > > > > > I remember similar questions being asked in the past, but I can't > > > remember > > > > what the concenseous was. I am being given a cabinet with 12-146GB > > disks > > > > to be > > > > used as raw storage for a database. The SA is asking how I want it > > > > presented....RAID 0, RAID 5...etc. What is the best option. > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > ******************************************************************************* > > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > > > > > --001a11c233ea8d346304e8fbc410 > > > > > > > > > > > > > > > > > > ******************************************************************************* > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > --001a11c34f5c1cf7ca04e903aa8e > > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --089e013d1866e05bb404e904358f > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a11c3675eae821504e9052202
Yes, thank you Art. > To: ids@iiug.org > From: in4mixdba@gmail.com > Subject: Re: Disk setup [31755] > Date: Fri, 18 Oct 2013 10:56:21 -0400 > > Art, > > Thank you for the detailed information and thank you for your continued > support to this community. > > Have a great day, > > --David > > On Fri, Oct 18, 2013 at 9:50 AM, Art Kagel <art.kagel@gmail.com> wrote: > > > The default page size on all platforms except Windows, AIX, and MacOSx is > > 2K (4K on those platforms). However, since version 10.00 any dbspace > > except the rootdb dbspace and those holding logical or physical logs can be > > any multiple of the default page size for the platform up to 16K. Informix > > typically writes either a single page or up to 8 pages in a single IO, so > > depending on the dbspace's page size, on Solaris, that would be from 2K to > > 128K. If all of your dbspaces use 2K pages, then a block size of 32K works > > very well and performance seems to start dropping off above 128K. Chunks > > in dbspaces that use 16K pages, however, might do just as well with block > > sizes from 256K to 1MB. But with a finite number of spindles, you may not > > be able to build multiple RAID10 arrays with different block sizes for > > different dbspaces. Like everything else we do as DBAs, this is a bunch of > > tradeoffs. > > > > The thing to remember is that the RAID subsystem can only write a complete > > stripe block to any drive, so even a 2K write must write out the entire > > block (though not the entire stripe). Multiple contiguous writes from > > Informix closely spaced in time can be coalesced by the system into a > > single write, that's not guaranteed and unless you are in the midst of a > > bulk load or during checkpoint chunk writes just doesn't happen very often. > > LRU writes by the engine look mostly random to the RAID subsystem and > > occur in fits and spurts so far less coalescing happens, so if the stripe > > blocks are too big, you end up rewriting each block many times. We seek a > > Zen-like balance. ;-) > > > > Art > > > > Art S. Kagel, Principal Consultant > > > > Advanced DataTools (www.advancedatatools.com) > > Blog: http://informix-myview.blogspot.com/ > > > > Disclaimer: Please keep in mind that my own opinions are my own opinions > > and do not reflect on my employer, Advanced DataTools, the IIUG, nor any > > other organization with which I am associated either explicitly, > > implicitly, or by inference. Neither do those opinions reflect those of > > other individuals affiliated with any entity with which I am affiliated nor > > those of the entities themselves. > > > > On Fri, Oct 18, 2013 at 9:11 AM, Informix DBA <in4mixdba@gmail.com> wrote: > > > > > Do you know what block size informix uses on Solaris 11? Currently > > > running 11.70.FC7W2. > > > > > > --David > > > in4mixdba > > > > > > On Thu, Oct 17, 2013 at 11:45 PM, Art Kagel <art.kagel@gmail.com> wrote: > > > > > > > RAID10! Small stripe block sizes (32K to 1MB at most). SAN techs love > > to > > > > configure arrays with huge block sizes from 256MB to 1GB which works > > well > > > > for filesystems but is VERY VERY BAD for databases. > > > > > > > > Build multiple arrays of mirrored pairs so that you can isolate hot > > > tables > > > > and indexes from each other and from the logical and physical logs. > > > > Ideally, if your logical log and physical log volume is below the > > > > bandwidth available from a single drive then make a singleton RAID1 > > > > mirrored pair for the logs alone (or one for each logical and physical > > > logs > > > > if you need a bit more bandwidth) to keep the logs completely > > independent > > > > of your mainline data and gather the remaining disks into a single big > > > > RAID10 for your data and indexes. > > > > > > > > More spindles is better than fewer. If you can get more drives, double > > > the > > > > number and create the VG's for the database to use only the middle > > 30-50% > > > > of the disk (ie not the outer or inner cylinders) and either leave the > > > rest > > > > of the drive's space unused or allocated to dbspaces for very low > > access > > > > rate tables like historical or archival data tables. > > > > > > > > If space is tight, then build the biggest widest RAID10 array you can > > to > > > > spread the IOs out. > > > > > > > > NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! > > > > > > > > RAID5 is not a safe place for your data! Period! > > > > > > > > See my presentation from the 2012 IIUG Conference entitled "Doing > > Storage > > > > Right!" for details on why and the latest research on the subject. Also > > > > look for my RAID5 Rant on the BAARF website (www.baarf.com) in the > > left > > > > margin of the main page for a more complete explanation of why NO > > > RAID5!!! > > > > > > > > Art > > > > > > > > Art S. Kagel, Principal Consultant > > > > > > > > Advanced DataTools (www.advancedatatools.com) > > > > Blog: http://informix-myview.blogspot.com/ > > > > > > > > Disclaimer: Please keep in mind that my own opinions are my own > > opinions > > > > and do not reflect on my employer, Advanced DataTools, the IIUG, nor > > any > > > > other organization with which I am associated either explicitly, > > > > implicitly, or by inference. Neither do those opinions reflect those of > > > > other individuals affiliated with any entity with which I am affiliated > > > nor > > > > those of the entities themselves. > > > > > > > > On Thu, Oct 17, 2013 at 10:51 PM, LARRY SORENSEN <lsorensen25@msn.com > > > > >wrote: > > > > > > > > > Solaris 10 > > > > > IDS 11.5.FC7 - Growth > > > > > > > > > > I remember similar questions being asked in the past, but I can't > > > > remember > > > > > what the concenseous was. I am being given a cabinet with 12-146GB > > > disks > > > > > to be > > > > > used as raw storage for a database. The SA is asking how I want it > > > > > presented....RAID 0, RAID 5...etc. What is the best option. > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ******************************************************************************* > > > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > > > > > > > > > --001a11c233ea8d346304e8fbc410 > > > > > > > > > > > > > > > > > > > > > > > > > > > ******************************************************************************* > > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > > > > > --001a11c34f5c1cf7ca04e903aa8e > > > > > > > > > > > > > > > > > ****************************************************************
I need to revisit this for our new server. We are setting up the cabinet with 12 drives. The cabinet only supports RAID 0-5, so we can't do RAID 10 as hoped. What is the recommendation for the configuration, since you were so insistent on not using RAID 5? Thank you again. Larry > To: ids@iiug.org > From: art.kagel@gmail.com > Subject: Re: Disk setup [31753] > Date: Fri, 18 Oct 2013 09:50:10 -0400 > > The default page size on all platforms except Windows, AIX, and MacOSx is > 2K (4K on those platforms). However, since version 10.00 any dbspace > except the rootdb dbspace and those holding logical or physical logs can be > any multiple of the default page size for the platform up to 16K. Informix > typically writes either a single page or up to 8 pages in a single IO, so > depending on the dbspace's page size, on Solaris, that would be from 2K to > 128K. If all of your dbspaces use 2K pages, then a block size of 32K works > very well and performance seems to start dropping off above 128K. Chunks > in dbspaces that use 16K pages, however, might do just as well with block > sizes from 256K to 1MB. But with a finite number of spindles, you may not > be able to build multiple RAID10 arrays with different block sizes for > different dbspaces. Like everything else we do as DBAs, this is a bunch of > tradeoffs. > > The thing to remember is that the RAID subsystem can only write a complete > stripe block to any drive, so even a 2K write must write out the entire > block (though not the entire stripe). Multiple contiguous writes from > Informix closely spaced in time can be coalesced by the system into a > single write, that's not guaranteed and unless you are in the midst of a > bulk load or during checkpoint chunk writes just doesn't happen very often. > LRU writes by the engine look mostly random to the RAID subsystem and > occur in fits and spurts so far less coalescing happens, so if the stripe > blocks are too big, you end up rewriting each block many times. We seek a > Zen-like balance. ;-) > > Art > > Art S. Kagel, Principal Consultant > > Advanced DataTools (www.advancedatatools.com) > Blog: http://informix-myview.blogspot.com/ > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and do not reflect on my employer, Advanced DataTools, the IIUG, nor any > other organization with which I am associated either explicitly, > implicitly, or by inference. Neither do those opinions reflect those of > other individuals affiliated with any entity with which I am affiliated nor > those of the entities themselves. > > On Fri, Oct 18, 2013 at 9:11 AM, Informix DBA <in4mixdba@gmail.com> wrote: > > > Do you know what block size informix uses on Solaris 11? Currently > > running 11.70.FC7W2. > > > > --David > > in4mixdba > > > > On Thu, Oct 17, 2013 at 11:45 PM, Art Kagel <art.kagel@gmail.com> wrote: > > > > > RAID10! Small stripe block sizes (32K to 1MB at most). SAN techs love to > > > configure arrays with huge block sizes from 256MB to 1GB which works well > > > for filesystems but is VERY VERY BAD for databases. > > > > > > Build multiple arrays of mirrored pairs so that you can isolate hot > > tables > > > and indexes from each other and from the logical and physical logs. > > > Ideally, if your logical log and physical log volume is below the > > > bandwidth available from a single drive then make a singleton RAID1 > > > mirrored pair for the logs alone (or one for each logical and physical > > logs > > > if you need a bit more bandwidth) to keep the logs completely independent > > > of your mainline data and gather the remaining disks into a single big > > > RAID10 for your data and indexes. > > > > > > More spindles is better than fewer. If you can get more drives, double > > the > > > number and create the VG's for the database to use only the middle 30-50% > > > of the disk (ie not the outer or inner cylinders) and either leave the > > rest > > > of the drive's space unused or allocated to dbspaces for very low access > > > rate tables like historical or archival data tables. > > > > > > If space is tight, then build the biggest widest RAID10 array you can to > > > spread the IOs out. > > > > > > NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! > > > > > > RAID5 is not a safe place for your data! Period! > > > > > > See my presentation from the 2012 IIUG Conference entitled "Doing Storage > > > Right!" for details on why and the latest research on the subject. Also > > > look for my RAID5 Rant on the BAARF website (www.baarf.com) in the left > > > margin of the main page for a more complete explanation of why NO > > RAID5!!! > > > > > > Art > > > > > > Art S. Kagel, Principal Consultant > > > > > > Advanced DataTools (www.advancedatatools.com) > > > Blog: http://informix-myview.blogspot.com/ > > > > > > Disclaimer: Please keep in mind that my own opinions are my own opinions > > > and do not reflect on my employer, Advanced DataTools, the IIUG, nor any > > > other organization with which I am associated either explicitly, > > > implicitly, or by inference. Neither do those opinions reflect those of > > > other individuals affiliated with any entity with which I am affiliated > > nor > > > those of the entities themselves. > > > > > > On Thu, Oct 17, 2013 at 10:51 PM, LARRY SORENSEN <lsorensen25@msn.com > > > >wrote: > > > > > > > Solaris 10 > > > > IDS 11.5.FC7 - Growth > > > > > > > > I remember similar questions being asked in the past, but I can't > > > remember > > > > what the concenseous was. I am being given a cabinet with 12-146GB > > disks > > > > to be > > > > used as raw storage for a database. The SA is asking how I want it > > > > presented....RAID 0, RAID 5...etc. What is the best option. > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > ******************************************************************************* > > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > > > > > --001a11c233ea8d346304e8fbc410 > > > > > > > > > > > > > > > > > ******************************************************************************* > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > --001a11c34f5c1cf7ca04e903aa8e > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --089e013d1866e05bb404e904358f > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >
I need to revisit this for our new server. We are setting up a cabinet with 12 drives. The cabinet only supports RAID 0-5, so we can't do RAID 10 as hoped. What is the recommendation for the configuration, since you were so insistent on not using RAID 5? Thank you again. Larry > To: ids@iiug.org > From: art.kagel@gmail.com > Subject: Re: Disk setup [31753] > Date: Fri, 18 Oct 2013 09:50:10 -0400 > > The default page size on all platforms except Windows, AIX, and MacOSx is > 2K (4K on those platforms). However, since version 10.00 any dbspace > except the rootdb dbspace and those holding logical or physical logs can be > any multiple of the default page size for the platform up to 16K. Informix > typically writes either a single page or up to 8 pages in a single IO, so > depending on the dbspace's page size, on Solaris, that would be from 2K to > 128K. If all of your dbspaces use 2K pages, then a block size of 32K works > very well and performance seems to start dropping off above 128K. Chunks > in dbspaces that use 16K pages, however, might do just as well with block > sizes from 256K to 1MB. But with a finite number of spindles, you may not > be able to build multiple RAID10 arrays with different block sizes for > different dbspaces. Like everything else we do as DBAs, this is a bunch of > tradeoffs. > > The thing to remember is that the RAID subsystem can only write a complete > stripe block to any drive, so even a 2K write must write out the entire > block (though not the entire stripe). Multiple contiguous writes from > Informix closely spaced in time can be coalesced by the system into a > single write, that's not guaranteed and unless you are in the midst of a > bulk load or during checkpoint chunk writes just doesn't happen very often. > LRU writes by the engine look mostly random to the RAID subsystem and > occur in fits and spurts so far less coalescing happens, so if the stripe > blocks are too big, you end up rewriting each block many times. We seek a > Zen-like balance. ;-) > > Art > > Art S. Kagel, Principal Consultant > > Advanced DataTools (www.advancedatatools.com) > Blog: http://informix-myview.blogspot.com/ > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and do not reflect on my employer, Advanced DataTools, the IIUG, nor any > other organization with which I am associated either explicitly, > implicitly, or by inference. Neither do those opinions reflect those of > other individuals affiliated with any entity with which I am affiliated nor > those of the entities themselves. > > On Fri, Oct 18, 2013 at 9:11 AM, Informix DBA <in4mixdba@gmail.com> wrote: > > > Do you know what block size informix uses on Solaris 11? Currently > > running 11.70.FC7W2. > > > > --David > > in4mixdba > > > > On Thu, Oct 17, 2013 at 11:45 PM, Art Kagel <art.kagel@gmail.com> wrote: > > > > > RAID10! Small stripe block sizes (32K to 1MB at most). SAN techs love to > > > configure arrays with huge block sizes from 256MB to 1GB which works well > > > for filesystems but is VERY VERY BAD for databases. > > > > > > Build multiple arrays of mirrored pairs so that you can isolate hot > > tables > > > and indexes from each other and from the logical and physical logs. > > > Ideally, if your logical log and physical log volume is below the > > > bandwidth available from a single drive then make a singleton RAID1 > > > mirrored pair for the logs alone (or one for each logical and physical > > logs > > > if you need a bit more bandwidth) to keep the logs completely independent > > > of your mainline data and gather the remaining disks into a single big > > > RAID10 for your data and indexes. > > > > > > More spindles is better than fewer. If you can get more drives, double > > the > > > number and create the VG's for the database to use only the middle 30-50% > > > of the disk (ie not the outer or inner cylinders) and either leave the > > rest > > > of the drive's space unused or allocated to dbspaces for very low access > > > rate tables like historical or archival data tables. > > > > > > If space is tight, then build the biggest widest RAID10 array you can to > > > spread the IOs out. > > > > > > NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! > > > > > > RAID5 is not a safe place for your data! Period! > > > > > > See my presentation from the 2012 IIUG Conference entitled "Doing Storage > > > Right!" for details on why and the latest research on the subject. Also > > > look for my RAID5 Rant on the BAARF website (www.baarf.com) in the left > > > margin of the main page for a more complete explanation of why NO > > RAID5!!! > > > > > > Art > > > > > > Art S. Kagel, Principal Consultant > > > > > > Advanced DataTools (www.advancedatatools.com) > > > Blog: http://informix-myview.blogspot.com/ > > > > > > Disclaimer: Please keep in mind that my own opinions are my own opinions > > > and do not reflect on my employer, Advanced DataTools, the IIUG, nor any > > > other organization with which I am associated either explicitly, > > > implicitly, or by inference. Neither do those opinions reflect those of > > > other individuals affiliated with any entity with which I am affiliated > > nor > > > those of the entities themselves. > > > > > > On Thu, Oct 17, 2013 at 10:51 PM, LARRY SORENSEN <lsorensen25@msn.com > > > >wrote: > > > > > > > Solaris 10 > > > > IDS 11.5.FC7 - Growth > > > > > > > > I remember similar questions being asked in the past, but I can't > > > remember > > > > what the concenseous was. I am being given a cabinet with 12-146GB > > disks > > > > to be > > > > used as raw storage for a database. The SA is asking how I want it > > > > presented....RAID 0, RAID 5...etc. What is the best option. > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > ******************************************************************************* > > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > > > > > --001a11c233ea8d346304e8fbc410 > > > > > > > > > > > > > > > > > ******************************************************************************* > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > --001a11c34f5c1cf7ca04e903aa8e > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --089e013d1866e05bb404e904358f > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >
I responded to Larry directly yesterday. There seems to have been a problem with the IIUG Forums or the email gateway to them over the last 24 hours or so because I just saw about 15 posts from yesterday like this one show up in my mailbox. Anyway, the short answer to Larry was that RAID3 is OK and better than RAID5 for write IO but no safer. Best to use RAID1 pairs for everything for both performance and safety maximization carefully placing data on the 6 mirrored pairs to take advantage of all 12 spindles as much as possible. Art Art S. Kagel, Principal Consultant Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Oct 29, 2013 at 2:47 PM, LARRY SORENSEN <lsorensen25@msn.com> wrote: > I need to revisit this for our new server. We are setting up a cabinet > with 12 > drives. The cabinet only supports RAID 0-5, so we can't do RAID 10 as > hoped. > What is the recommendation for the configuration, since you were so > insistent > on not using RAID 5? Thank you again. > > Larry > > > To: ids@iiug.org > > From: art.kagel@gmail.com > > Subject: Re: Disk setup [31753] > > Date: Fri, 18 Oct 2013 09:50:10 -0400 > > > > The default page size on all platforms except Windows, AIX, and MacOSx is > > 2K (4K on those platforms). However, since version 10.00 any dbspace > > except the rootdb dbspace and those holding logical or physical logs can > be > > any multiple of the default page size for the platform up to 16K. > Informix > > typically writes either a single page or up to 8 pages in a single IO, so > > depending on the dbspace's page size, on Solaris, that would be from 2K > to > > 128K. If all of your dbspaces use 2K pages, then a block size of 32K > works > > very well and performance seems to start dropping off above 128K. Chunks > > in dbspaces that use 16K pages, however, might do just as well with block > > sizes from 256K to 1MB. But with a finite number of spindles, you may not > > be able to build multiple RAID10 arrays with different block sizes for > > different dbspaces. Like everything else we do as DBAs, this is a bunch > of > > tradeoffs. > > > > The thing to remember is that the RAID subsystem can only write a > complete > > stripe block to any drive, so even a 2K write must write out the entire > > block (though not the entire stripe). Multiple contiguous writes from > > Informix closely spaced in time can be coalesced by the system into a > > single write, that's not guaranteed and unless you are in the midst of a > > bulk load or during checkpoint chunk writes just doesn't happen very > often. > > LRU writes by the engine look mostly random to the RAID subsystem and > > occur in fits and spurts so far less coalescing happens, so if the stripe > > blocks are too big, you end up rewriting each block many times. We seek a > > Zen-like balance. ;-) > > > > Art > > > > Art S. Kagel, Principal Consultant > > > > Advanced DataTools (www.advancedatatools.com) > > Blog: http://informix-myview.blogspot.com/ > > > > Disclaimer: Please keep in mind that my own opinions are my own opinions > > and do not reflect on my employer, Advanced DataTools, the IIUG, nor any > > other organization with which I am associated either explicitly, > > implicitly, or by inference. Neither do those opinions reflect those of > > other individuals affiliated with any entity with which I am affiliated > nor > > those of the entities themselves. > > > > On Fri, Oct 18, 2013 at 9:11 AM, Informix DBA <in4mixdba@gmail.com> > wrote: > > > > > Do you know what block size informix uses on Solaris 11? Currently > > > running 11.70.FC7W2. > > > > > > --David > > > in4mixdba > > > > > > On Thu, Oct 17, 2013 at 11:45 PM, Art Kagel <art.kagel@gmail.com> > wrote: > > > > > > > RAID10! Small stripe block sizes (32K to 1MB at most). SAN techs > love to > > > > configure arrays with huge block sizes from 256MB to 1GB which works > well > > > > for filesystems but is VERY VERY BAD for databases. > > > > > > > > Build multiple arrays of mirrored pairs so that you can isolate hot > > > tables > > > > and indexes from each other and from the logical and physical logs. > > > > Ideally, if your logical log and physical log volume is below the > > > > bandwidth available from a single drive then make a singleton RAID1 > > > > mirrored pair for the logs alone (or one for each logical and > physical > > > logs > > > > if you need a bit more bandwidth) to keep the logs completely > independent > > > > of your mainline data and gather the remaining disks into a single > big > > > > RAID10 for your data and indexes. > > > > > > > > More spindles is better than fewer. If you can get more drives, > double > > > the > > > > number and create the VG's for the database to use only the middle > 30-50% > > > > of the disk (ie not the outer or inner cylinders) and either leave > the > > > rest > > > > of the drive's space unused or allocated to dbspaces for very low > access > > > > rate tables like historical or archival data tables. > > > > > > > > If space is tight, then build the biggest widest RAID10 array you > can to > > > > spread the IOs out. > > > > > > > > NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO > > > > RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! > > > > > > > > RAID5 is not a safe place for your data! Period! > > > > > > > > See my presentation from the 2012 IIUG Conference entitled "Doing > Storage > > > > Right!" for details on why and the latest research on the subject. > Also > > > > look for my RAID5 Rant on the BAARF website (www.baarf.com) in the > left > > > > margin of the main page for a more complete explanation of why NO > > > RAID5!!! > > > > > > > > Art > > > > > > > > Art S. Kagel, Principal Consultant > > > > > > > > Advanced DataTools (www.advancedatatools.com) > > > > Blog: http://informix-myview.blogspot.com/ > > > > > > > > Disclaimer: Please keep in mind that my own opinions are my own > opinions > > > > and do not reflect on my employer, Advanced DataTools, the IIUG, nor > any > > > > other organization with which I am associated either explicitly, > > > > implicitly, or by inference. Neither do those opinions reflect those > of > > > > other individuals affiliated with any entity with which I am > affiliated > > > nor > > > > those of the entities themselves. > > > > > > > > On Thu, Oct 17, 2013 at 10:51 PM, LARRY SORENSEN < > lsorensen25@msn