Re: dbspaces design in SAN arrays
Neil Truby wrote: > "Mark D. Stock" <mdstock@MydasSolutions.com> wrote in message > news:mailman.134.1154639919.20706.informix-list@iiug.org... > > >>If you can, allocate different LUNs to each dbspace. Make sure you choose >>an appropriate LUN RAID level, i.e. no RAID5. Each LUN can be configured >>differently and moved around, so if you can keep to one dbspace per LUN >>and you run into performance or storage issues, you can get that LUN >>reconfigured. > > ... > >>If you have enough invested in your SAN, you should also be able to play >>with business continuity volume (BCV) snapshots using external backups. >>Who doesn't like to see a several hundred Gb level 0 archive complete in a >>couple of seconds? :-D > > > If you're talking about BCVs this implies you're using EMC Symmetrix. If > you have a Symmetrix you are *absolutely* wasting your time aligning LUNs > and dbspaces, for the reasons I gave earlier. > > Is it only me who thinks this?! I keep reading people with expensive SANs > advocating orthodoxies from the days when you were lucky if you had two > disks (one of which was for the OS and swap anyway), and wonder if I'm > missing something ... Well try it for yourself: 1. Get yourself a multi-processor box, with at least 4 CPUs. 2. Set up IDS with at least 3 CPU VPs. 3. Create a non-fragmented table and populate it with some data. 4. Run some benchmarks on it. 5. Now fragment the table across at least 3 dbspaces, all on the same disk, logical or physical 6. Run the same benchmarks and compare times. Cheers, -- Mark. +----------------------------------------------------------+-----------+ | Mark D. Stock mailto:mdstock@MydasSolutions.com |//////// /| | |///// / //| | +-----------------------------------+//// / ///| | |We value your comments, which have |/// / ////| | |been recorded and automatically |// / /////| | |emailed back to us for our records.|/ ////////| +----------------------+-----------------------------------+-----------+
"Mark D. Stock" <mdstock@MydasSolutions.com> wrote in message news:mailman.363.1156732291.20706.informix-list@iiug.org... > Neil Truby wrote: >> "Mark D. Stock" <mdstock@MydasSolutions.com> wrote in message >> news:mailman.134.1154639919.20706.informix-list@iiug.org... >> >> >> Is it only me who thinks this?! I keep reading people with expensive >> SANs advocating orthodoxies from the days when you were lucky if you had >> two disks (one of which was for the OS and swap anyway), and wonder if >> I'm missing something ... > > > Well try it for yourself: > > 1. Get yourself a multi-processor box, with at least 4 CPUs. > 2. Set up IDS with at least 3 CPU VPs. > 3. Create a non-fragmented table and populate it with some data. > 4. Run some benchmarks on it. > 5. Now fragment the table across at least 3 dbspaces, all on the same > disk, > logical or physical > 6. Run the same benchmarks and compare times. I don't understand what benchmarks for Informix fragmentation will tell me about the allocation and positioning of LUNs on a SAN.
Neil Truby wrote: > "Mark D. Stock" <mdstock@MydasSolutions.com> wrote in message > news:mailman.363.1156732291.20706.informix-list@iiug.org... > >>Neil Truby wrote: >> >>>"Mark D. Stock" <mdstock@MydasSolutions.com> wrote in message >>>news:mailman.134.1154639919.20706.informix-list@iiug.org... >>> > > >>>Is it only me who thinks this?! I keep reading people with expensive >>>SANs advocating orthodoxies from the days when you were lucky if you had >>>two disks (one of which was for the OS and swap anyway), and wonder if >>>I'm missing something ... >> >> >>Well try it for yourself: >> >>1. Get yourself a multi-processor box, with at least 4 CPUs. >>2. Set up IDS with at least 3 CPU VPs. >>3. Create a non-fragmented table and populate it with some data. >>4. Run some benchmarks on it. >>5. Now fragment the table across at least 3 dbspaces, all on the same >>disk, >>logical or physical >>6. Run the same benchmarks and compare times. > > > I don't understand what benchmarks for Informix fragmentation will tell me > about the allocation and positioning of LUNs on a SAN. Nothing, but the question was about dbspaces, chunks & table fragmentation: > Octavio Gomez wrote: > > Is there any special consideration for dbspaces, chunks and tables > fragmentation design in SAN environments with dozens or hundreds of > disks inside of one array? And you implied this was a waste of time: > Neil Truby wrote: > > Don't waste time doing anything more than rudimentary placement planning. > The level of indirection between the LUNs presented to your host and the > physical disks is so high as to make the exercise worthless. Sorry if I misunderstood your recommendations. Cheers, -- Mark. +----------------------------------------------------------+-----------+ | Mark D. Stock mailto:mdstock@MydasSolutions.com |//////// /| | |///// / //| | +-----------------------------------+//// / ///| | |We value your comments, which have |/// / ////| | |been recorded and automatically |// / /////| | |emailed back to us for our records.|/ ////////| +----------------------+-----------------------------------+-----------+
Mark D. Stock wrote: > Neil Truby wrote: > > "Mark D. Stock" <mdstock@MydasSolutions.com> wrote in message > > news:mailman.134.1154639919.20706.informix-list@iiug.org... > > > > > >>If you can, allocate different LUNs to each dbspace. Make sure you choose > >>an appropriate LUN RAID level, i.e. no RAID5. Each LUN can be configured > >>differently and moved around, so if you can keep to one dbspace per LUN > >>and you run into performance or storage issues, you can get that LUN > >>reconfigured. > > > > ... > > > >>If you have enough invested in your SAN, you should also be able to play > >>with business continuity volume (BCV) snapshots using external backups. > >>Who doesn't like to see a several hundred Gb level 0 archive complete in a > >>couple of seconds? :-D > > > > > > If you're talking about BCVs this implies you're using EMC Symmetrix. If > > you have a Symmetrix you are *absolutely* wasting your time aligning LUNs > > and dbspaces, for the reasons I gave earlier. > > > > Is it only me who thinks this?! I keep reading people with expensive SANs > > advocating orthodoxies from the days when you were lucky if you had two > > disks (one of which was for the OS and swap anyway), and wonder if I'm > > missing something ... > > > Well try it for yourself: > > 1. Get yourself a multi-processor box, with at least 4 CPUs. > 2. Set up IDS with at least 3 CPU VPs. > 3. Create a non-fragmented table and populate it with some data. > 4. Run some benchmarks on it. > 5. Now fragment the table across at least 3 dbspaces, all on the same disk, > logical or physical > 6. Run the same benchmarks and compare times. > > Cheers, > -- > Mark. > Small amendment: Regarding the number of CPU VPs on a 4 CPU server: with faster CPUs, it may be very advantageous to have 2 or 3 CPU VPs per CPU that is to execute IDS. At least, that is my experience with SPARCs running at >1 GHz (haven't tried slower SPARCs, except very old ones). For more info, look at some posts to c.d.i related to the number of CPU VPs for use with fast CPUs. I think Art Kagel provided clear explanation why is it advantageous. Darko Krstic