I shall shortly be required to create a new Informix instance using SAN
disk managed by a third party. At the OS level it is looking like the
SAN storage will be presented as a single disk. This will actually be
striped across a number of SAN disks to be shared with other customers.
I have a number of concerns as follows:

1. Separating dbspaces for performance no longer makes sense as I have
lost control of which physical disks they will reside on. The only
reason I can now see for having separate dbspaces is for ease of
management.

2. By sharing the physical SAN disks with other customers of the third
party SAN provider, performance of our application may suffer for
reasons totally outside our control.

I would be interested to hear experiences others have had with Informix
using shared SAN storage. Are my concerns justified?

Many thanks.

Desmodromic wrote:
> I shall shortly be required to create a new Informix instance using SAN
> disk managed by a third party. At the OS level it is looking like the
> SAN storage will be presented as a single disk. This will actually be
> striped across a number of SAN disks to be shared with other customers.
> I have a number of concerns as follows:
>
> 1. Separating dbspaces for performance no longer makes sense as I have
> lost control of which physical disks they will reside on. The only
> reason I can now see for having separate dbspaces is for ease of
> management.
>
> 2. By sharing the physical SAN disks with other customers of the third
> party SAN provider, performance of our application may suffer for
> reasons totally outside our control.
>
> I would be interested to hear experiences others have had with Informix
> using shared SAN storage. Are my concerns justified?
>
> Many thanks.

It still may have sense to have multiple dbspaces. For example, for
faster recovery of dbspaces with most important data.

Regarding performance, it seems very risky to accept that the same
disks that contain your Informix databases hold other information,
about usage of which you have no knowledge and that you cannot control.
For example, one hot spot in the "other guy's" region would kill your
performance. Also, I would pay attention to RAID configuration (RAID
1+0 is highly desirable, RAID 5 is no-no, read posts by Art Kagel). So,
I would recommend RAID 1+0 configuration over physical disks that hold
only your data.

Darko Krstic

"Desmodromic" <davies_ms@yahoo.com.au> wrote in message
news:1159849312.163378.55170@i42g2000cwa.googlegro ups.com...
>I shall shortly be required to create a new Informix instance using SAN
> disk managed by a third party. At the OS level it is looking like the
> SAN storage will be presented as a single disk. This will actually be
> striped across a number of SAN disks to be shared with other customers.
> I have a number of concerns as follows:
>
> 1. Separating dbspaces for performance no longer makes sense as I have
> lost control of which physical disks they will reside on. The only
> reason I can now see for having separate dbspaces is for ease of
> management.

Halleluljah! Somone else has seen the light!
You'll get burned for heresy by some of the dinosaurs from the JBOD age on
here though .... ;-)

> 2. By sharing the physical SAN disks with other customers of the third
> party SAN provider, performance of our application may suffer for
> reasons totally outside our control.

Some SANs have resource managers that limit the amount of damage any one
host can do: perhaps ask your supplier if this is so on theirs?

> I would be interested to hear experiences others have had with Informix
> using shared SAN storage. Are my concerns justified?

The first is , but it shouldn't be a concern. The second could be: I'd put
it to the vendor. A good SAN with a decent cache size should give you a
boost in performance, particularly if you're moving from SCSI to
fibre-attached, so make sure you do ostentatiously do some tuning first, and
claim the credit for yourself!

Separate ´temp dbspaces are essential, at least 3, and some logged if
you have a poorly designed app (or badly trained users!)
If you want to use warm restores, these work at dbspace level, so you
might have issues if all your data is in one dbspace and you only want
to restore a sub-set at some future time. rble pgsizes at v10) also
reqi separae dbspace
You don´t mention th siyze of you database, but physical splitting of
logical areas will, as you mention, help with admin.
(Grr Germanb Kezboards Grrrr.)
How are you archiving? Ontape can get a bit funnz with very large
spaces on earlier IDS versions.

Keith

On 03/10/06, Neil Truby <neil.truby@ardenta.com> wrote:
> "Desmodromic" <davies_ms@yahoo.com.au> wrote in message
> news:1159849312.163378.55170@i42g2000cwa.googlegro ups.com...
> >I shall shortly be required to create a new Informix instance using SAN
> > disk managed by a third party. At the OS level it is looking like the
> > SAN storage will be presented as a single disk. This will actually be
> > striped across a number of SAN disks to be shared with other customers.
> > I have a number of concerns as follows:
> >
> > 1. Separating dbspaces for performance no longer makes sense as I have
> > lost control of which physical disks they will reside on. The only
> > reason I can now see for having separate dbspaces is for ease of
> > management.
>
> Halleluljah! Somone else has seen the light!
> You'll get burned for heresy by some of the dinosaurs from the JBOD age on
> here though .... ;-)
>
> > 2. By sharing the physical SAN disks with other customers of the third
> > party SAN provider, performance of our application may suffer for
> > reasons totally outside our control.
>
> Some SANs have resource managers that limit the amount of damage any one
> host can do: perhaps ask your supplier if this is so on theirs?
>
> > I would be interested to hear experiences others have had with Informix
> > using shared SAN storage. Are my concerns justified?
>
> The first is , but it shouldn't be a concern. The second could be: I'd put
> it to the vendor. A good SAN with a decent cache size should give you a
> boost in performance, particularly if you're moving from SCSI to
> fibre-attached, so make sure you do ostentatiously do some tuning first, and
> claim the credit for yourself!
>
>
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>

And don't forget that one day you might like to use PDQ - fragmented
tables across multiple dbspaces.
Think multiple LUN's, HBA's and how you route your switches if you ever
go down this path.

Hi,

I run Informix on EMC Symmetrix.
Other than my storage guy giving me 2 GB chunks (because i have not turned on
the large chunk feature), I don't care where he puts it.

We have a lot of cache for EMC so chances are IDS is getting data from EMC
cache and the application on top of IDS (which is SAP for me) gets it's data
from IDS cache. In addition our SAP has plenty of cache. With cache up the
wazoo, chances are the end users are getting data from cache be it SAP
cache/IDS cache/EMC cache.
My DB checkpoints happen to be double digits but do not make my customers
scream. My checkpoints are high because we run EMC SRDF to our disaster
site, without SRDF on, my checkpoints are usually under 3 seconds.

While i don't care where my storage guy puts my chunks, I still care about
defining dbspaces and managing them.
Mostly i need to manage my dbspaces because of BACKUPS. I use onbar. the
smallest unit of work for onbar is a DBSPACE. We use Veritas (I mean
Symantec) Netbackup as our backup utility in hand with onbar. This does not
change the fact that my smallest unit of BACKUP work is a DBSPACE.
Onbar hands a dbspace to netbackup .... if the DBSPACE is 100GB, well, the
amount of time it takes to backup a 100GB space is longer than a 50GB space
or a 10GB space.

So my dbspaces become a management issue for handling DB recovery. Remember
the duration of your backup influences the amount of time you need to restore
that DB (to a test system or egads after a failure).

Before we changed out netbackup infrastructure a 50GB dbspace took 8 hours to
backup. it did not matter that all 125 other dbspaces were 20GB or less....
the duration of my DB backup was still 8 hours because of that 50GB dbspace.
(yup, multi-threaded backup with BAR_MAX... but all threads can finish well
before the 50GB dbspace, but the 50GBer still marks the official
end/completion of backup).

In your case i would be concerned about sharing that SAN with other customers.

Make the contract clearly state how much storage cache you get for DB and
what performance (SLA - service level agreement) they adhere too.

You are right to be concerned. your neck is on the line because you're the
DBA.... and you need to know whose neck you choke at the SAN vendor (24x7
unless your DB doesn't need to be up 24x7).

is the SAN vendor also providing the backups? if all they provide is the
disk space and your employer is choosing to put a DB there....... who is
responsible for backing it up/providing recovery/restores?

interesting situation you are in.
Norma Jean

--
Message posted via DBMonster.com
http://www.dbmonster.com/Uwe/Forums....ormix/200610/1