DSNDB07 tablespace dataset placement

teldb2kals

DSNDB07 tablespace dataset placement
Hi,

I have gone thru some past messages in the archives, and have seen different
opinions about placing of the DSNDB07 work datasets in a separate DASD
pool. There was one posting that suggested that with PAV and modern DASD
architecture, it doesn't really matter where we place our datasets.

We currently have them under separate pools, but our storage folks would like
to consolidate the various pools into lesser but larger volumes (which would
also result in easier management of these for them). We don't have any issue
as such at present with our temp space, and I reckon it would be OK to
accept the storage folks' recommendation. But I would like to know whether
anyone has a strong differing opinion or other comments on this.

Also, how exactly can we measure any difference in performance if we did
consilidate them ?

Thanks in advance,

Regards,
Kals

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Phil Grainger

Re: DSNDB07 tablespace dataset placement
(in response to teldb2kals)
DB2 assumes that your multiple workfile table spaces ARE on different volumes, so when it is looking to parallelise (sp?) that's the key fact

So, if you put more than one table space on a single volume and DB2 parellises assuming they are on different devices, you may see performance degradation

Then we need to look at what is happening outside DB2 and if the OS can support multiple parallel access to the same volume, then the potential problems are minimised

And, of course, don't lose sight of the fact that the volumes that DB2 sees are only virtual in any case and who really knows how thay map to real physical devices anyway?

How to measure any difference? I am not too sure that's at all easy

Bottom line, for average workloads (assuming you are not squeezing the DB2 pips) you'll probably not notice any difference - and it might even be worth considering combining multiple workfile table spaces if they are going to end up on the same volume

Phil Grainger
CA

________________________________

From: DB2 Data Base Discussion List on behalf of Teldb2kals
Sent: Tue 20/01/2009 00:25
To: [login to unmask email]
Subject: [DB2-L] DSNDB07 tablespace dataset placement



Hi,

I have gone thru some past messages in the archives, and have seen different
opinions about placing of the DSNDB07 work datasets in a separate DASD
pool. There was one posting that suggested that with PAV and modern DASD
architecture, it doesn't really matter where we place our datasets.

We currently have them under separate pools, but our storage folks would like
to consolidate the various pools into lesser but larger volumes (which would
also result in easier management of these for them). We don't have any issue
as such at present with our temp space, and I reckon it would be OK to
accept the storage folks' recommendation. But I would like to know whether
anyone has a strong differing opinion or other comments on this.

Also, how exactly can we measure any difference in performance if we did
consilidate them ?

Thanks in advance,

Regards,
Kals

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html




______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Max Scarpa

Re: DSNDB07 tablespace dataset placement
(in response to Phil Grainger)
DSNDB07 dataset placement was debated many times. Their usage by DB2 is
somewhat particular.

Obviously it depends on your DASD HW (here for instance we have 3 WF on
the same disk but a great DASD machine) but probably as Phil said you'll
notice no difference during normal work if datasets are anyway spread in a
smart way. Don't forget modern DASD uses mainly cache (now there are very
big cache than in the past) and caching algorithms are quite efficent to
get rid of 'work' data in cache.

Anyway after move of your WF any simple DASD report tool can give an idea
is you DB2 is working better or worse from a DASD point of view.

Just a considaration

Max Scarpa







"Grainger, Phil" <[login to unmask email]>
Sent by: DB2 Data Base Discussion List <[login to unmask email]>
20/01/09 10.32
Please respond to
DB2 Database Discussion list at IDUG <[login to unmask email]>


To
[login to unmask email]
cc

Subject
Re: [DB2-L] DSNDB07 tablespace dataset placement






DB2 assumes that your multiple workfile table spaces ARE on different
volumes, so when it is looking to parallelise (sp?) that's the key fact

So, if you put more than one table space on a single volume and DB2
parellises assuming they are on different devices, you may see performance
degradation

Then we need to look at what is happening outside DB2 and if the OS can
support multiple parallel access to the same volume, then the potential
problems are minimised

And, of course, don't lose sight of the fact that the volumes that DB2
sees are only virtual in any case and who really knows how thay map to
real physical devices anyway?

How to measure any difference? I am not too sure that's at all easy

Bottom line, for average workloads (assuming you are not squeezing the DB2
pips) you'll probably not notice any difference - and it might even be
worth considering combining multiple workfile table spaces if they are
going to end up on the same volume

Phil Grainger
CA

From: DB2 Data Base Discussion List on behalf of Teldb2kals
Sent: Tue 20/01/2009 00:25
To: [login to unmask email]
Subject: [DB2-L] DSNDB07 tablespace dataset placement

Hi,

I have gone thru some past messages in the archives, and have seen
different
opinions about placing of the DSNDB07 work datasets in a separate DASD
pool. There was one posting that suggested that with PAV and modern DASD
architecture, it doesn't really matter where we place our datasets.

We currently have them under separate pools, but our storage folks would
like
to consolidate the various pools into lesser but larger volumes (which
would
also result in easier management of these for them). We don't have any
issue
as such at present with our temp space, and I reckon it would be OK to
accept the storage folks' recommendation. But I would like to know whether
anyone has a strong differing opinion or other comments on this.

Also, how exactly can we measure any difference in performance if we did
consilidate them ?

Thanks in advance,

Regards,
Kals

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You
should have gotten an e-mail with the temporary password assigned to your
account. Please log in and update your member profile. If you are not
already an IDUG.org member, please register at
http://www.idug.org/component/juser/register.html



IDUG 2009 - Australasia * 18-20 March * Melbourne, Australia
IDUG.org was recently updated requiring members to use a new password. You
should have gotten an e-mail with the temporary password assigned to your
account. Please log in and update your member profile. If you are not
already an IDUG.org member, please register here.

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Adam Baldwin

Re: DSNDB07 tablespace dataset placement
(in response to Max Scarpa)
Kals, have a look at the following redpaper for some general - and very useful -
info re dataset placement, disk storage and DB2. You will find some pointers
re DSNDB07 and workfiles.

http://www.redbooks.ibm.com/redpapers/pdfs/redp4187.pdf

Cheers, Adam

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Richard Humphris

Re: DSNDB07 tablespace dataset placement
(in response to Adam Baldwin)
Hi Kals,

Does anyone actually use real "3390" devices??? I seriously doubt it;
but with a real 3390 I'd worry about dataset placement; otherwise I
suggest you just ignore dataset placement.

Of course, if you have multiple storage boxes, then allocating packs on
different boxes would ensure actual pack separation.

But on the EMC box we use, the "logical 3390" devices are simply not
anything like the hardware underneath; so what you think may be
"separated" may be a total fiction.

All the "3390-like" boxes (including IBM's) are just faking the 3390
technology. With our EMC box, what appears to be multiple 3390 packs
(up to 9 last time I heard) were actually on one physical volume (no
separation here). And unless you have the storage group show you the
internal mapping of dasd addresses to internal physical volumes you
can't even guess which packs may be on the same volume. And although
different boxes may handle things quite differently, you can be sure
these virtual 3390 packs and the physical hardware underneath aren't the
same.

So like others have already said, with things like "dasd fast write" (to
cache), with PAV, with logical 3390's hiding the physical reality, etc.
the old "separate packs" philosophy is fairly useless, unless you have
real knowledge of how the packs are layed out (or used) under the covers
of any HW dasd device you're using.

My philosophy is: let the storage folks do what they want. :-)

Thanks,
Rich Humphris

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Teldb2kals
Sent: Monday, January 19, 2009 6:26 PM
To: [login to unmask email]
Subject: [DB2-L] DSNDB07 tablespace dataset placement

Hi,

I have gone thru some past messages in the archives, and have seen
different
opinions about placing of the DSNDB07 work datasets in a separate DASD
pool. There was one posting that suggested that with PAV and modern DASD

architecture, it doesn't really matter where we place our datasets.

We currently have them under separate pools, but our storage folks would
like
to consolidate the various pools into lesser but larger volumes (which
would
also result in easier management of these for them). We don't have any
issue
as such at present with our temp space, and I reckon it would be OK to
accept the storage folks' recommendation. But I would like to know
whether
anyone has a strong differing opinion or other comments on this.

Also, how exactly can we measure any difference in performance if we did

consilidate them ?

Thanks in advance,

Regards,
Kals

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events
*
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password.
You should have gotten an e-mail with the temporary password assigned to
your account. Please log in and update your member profile. If you are
not already an IDUG.org member, please register at
http://www.idug.org/component/juser/register.html

E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the
addressee(s) and may contain confidential and/or legally privileged information. If you are not the
intended recipient of this message or if this message has been addressed to you in error, please
immediately alert the sender by reply e-mail and then delete this message and any attachments. If you
are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or
storage of this message or any attachment is strictly prohibited.

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

teldb2kals

Re: DSNDB07 tablespace dataset placement
(in response to Richard Humphris)
Thanks, Richard, and everyone else for your replies (and for the link to that
redpaper, Adam). I have forwarded a summary to our storage management
team, and I think in reality I don't much issue with the consolidation of
volumes.

Regards,
Kals
On Fri, 23 Jan 2009 00:46:13 -0600, Humphris,Richard P.
<[login to unmask email]> wrote:

>Hi Kals,
>
>Does anyone actually use real "3390" devices??? I seriously doubt it;
>but with a real 3390 I'd worry about dataset placement; otherwise I
>suggest you just ignore dataset placement.
>
>Of course, if you have multiple storage boxes, then allocating packs on
>different boxes would ensure actual pack separation.
>
>But on the EMC box we use, the "logical 3390" devices are simply not
>anything like the hardware underneath; so what you think may be
>"separated" may be a total fiction.
>
>All the "3390-like" boxes (including IBM's) are just faking the 3390
>technology. With our EMC box, what appears to be multiple 3390 packs
>(up to 9 last time I heard) were actually on one physical volume (no
>separation here). And unless you have the storage group show you the
>internal mapping of dasd addresses to internal physical volumes you
>can't even guess which packs may be on the same volume. And although
>different boxes may handle things quite differently, you can be sure
>these virtual 3390 packs and the physical hardware underneath aren't the
>same.
>
>So like others have already said, with things like "dasd fast write" (to
>cache), with PAV, with logical 3390's hiding the physical reality, etc.
>the old "separate packs" philosophy is fairly useless, unless you have
>real knowledge of how the packs are layed out (or used) under the covers
>of any HW dasd device you're using.
>
>My philosophy is: let the storage folks do what they want. :-)
>
>Thanks,
>Rich Humphris
>
>-----Original Message-----
>From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
>Behalf Of Teldb2kals
>Sent: Monday, January 19, 2009 6:26 PM
>To: [login to unmask email]
>Subject: [DB2-L] DSNDB07 tablespace dataset placement
>
>Hi,
>
>I have gone thru some past messages in the archives, and have seen
>different
>opinions about placing of the DSNDB07 work datasets in a separate DASD
>pool. There was one posting that suggested that with PAV and modern DASD
>
>architecture, it doesn't really matter where we place our datasets.
>
>We currently have them under separate pools, but our storage folks would
>like
>to consolidate the various pools into lesser but larger volumes (which
>would
>also result in easier management of these for them). We don't have any
>issue
>as such at present with our temp space, and I reckon it would be OK to
>accept the storage folks' recommendation. But I would like to know
>whether
>anyone has a strong differing opinion or other comments on this.
>
>Also, how exactly can we measure any difference in performance if we did
>
>consilidate them ?
>
>Thanks in advance,
>
>Regards,
>Kals
>


______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html