Octavio Gomez wrote:
> Hi everyone,
> I used to work with servers with a bunch of disks connected to them, so
> it was relative easy to design dbspaces and tables fragmentation in that
> scene.
>
> 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?

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.

Use fragmentation as normal, even if you are not 100% sure about the
physical location of your data, it's also about allocating more CPU
resources. If you manage to saturate the SAN storage, then get your SAN
Administrator to reconfigure that LUN. ;-)

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

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.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 ...

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