[MVS] Only one extend for TS/index?

dusan pospisil

[MVS] Only one extend for TS/index?
Hello Listers:

Is it still worth trying to allocate data set for TS/index in such a way to cover all allocation by priqty?
And how much could I gain on performance?

DB2 V8 NFM - z/OS

Thanks,
dusan




_____________
Tato zpráva a v¹echny pøipojené soubory jsou dùvìrné a urèené výluènì adresátovi(-ùm). Jestli¾e nejste oprávnìným adresátem, je zakázáno jakékoliv zveøejòování, zprostøedkování nebo jiné pou¾ití tìchto informací. Jestli¾e jste tento mail dostali neoprávnìnì, prosím, uvìdomte odesilatele a sma¾te zprávu i pøilo¾ené soubory. Odesilatel nezodpovídá za jakékoliv chyby nebo opomenutí zpùsobené tímto pøenosem.
 
Jste si jisti, ¾e opravdu potøebujete vytisknout tuto zprávu a/nebo její pøílohy? Myslete na pøírodu.
 
 
This message and any attached files are confidential and intended solely for the addressee(s). Any publication, transmission or other use of the information by a person or entity other than the intended addressee is prohibited. If you receive this in error please contact the sender and delete the message as well as all attached documents. The sender does not accept liability for any errors or omissions as a result of the transmission.
 
Are you sure that you really need a print version of this message and/or its attachments? Think about nature.

-.- --

______________________________________________________________________

* 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

Cathy Taddei

Re: [MVS] Only one extend for TS/index?
(in response to dusan pospisil)
One good reason to be careful with that, especially in test subsystems, is the likelihood of a tablespace being migrated by HSM. If you use a large primary, you should allocate it as multivolume. We had this painful experience: a long gap between training classes allowing a lot of our large training subsytem tablespaces to migrate. The next training class initiated a slew of recalls which bogged down the system, and many of them failed due to not a large enough space on a single volume to do the recall. If you use a smaller primary and allocate as multivolume, HSM will have no problem bringing back all the pieces.

We also had the experience of a certain table suffering "death by random I/O". We noticed a marked performance improvement when the various extents were on separate volumes. We later resolved the problem with a huge bufferpool, but the situation clearly demonstrated that DB2 performs quite well with multiple extents.

My preference is for the primary to be 2 or 3 times what I expect the secondaries to be. We use the sliding scale algorithm for secondaries, so a relatively large tablespace would have a primary of 300-500 cylinders.

Regards,
Cathy Taddei

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Pospí¹il Du¹an
Sent: Friday, January 16, 2009 11:49 PM
To: [login to unmask email]
Subject: [MVS] Only one extend for TS/index?

Hello Listers:

Is it still worth trying to allocate data set for TS/index in such a way to cover all allocation by priqty?
And how much could I gain on performance?

DB2 V8 NFM - z/OS

Thanks,
dusan




------------------------------------------------------------------------------

This email is confidential and may be legally privileged.

It is intended solely for the addressee. Access to this email by anyone else, unless expressly approved by the sender or an authorized addressee, is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution or any action omitted or taken in reliance on it, is prohibited and may be unlawful. If you believe that you have received this email in error, please contact the sender, delete this e-mail and destroy all copies.

=====

______________________________________________________________________

* 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

Isaac Yassin

Re: [MVS] Only one extend for TS/index?
(in response to Cathy Taddei)
Hi,

I refer to " We also had the experience of a certain table suffering "death by random I/O". We noticed a marked performance improvement when the various extents were on separate volumes. "

This means you've had an IOSQ problem as all requests for the table when it resided on one volume were slow.
Spreading the extents over multiple volumes gave you respite from that as each request went to a separate volume so you did not get the "DBRIO" situation.
You could've used PAV (or even better , hiper-pav) instead of the huge BP to solve the problem.


Isaac Yassin


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Taddei, Cathy
Sent: Saturday, January 17, 2009 10:18 AM
To: [login to unmask email]
Subject: Re: [DB2-L] [MVS] Only one extend for TS/index?

One good reason to be careful with that, especially in test subsystems, is the likelihood of a tablespace being migrated by HSM. If you use a large primary, you should allocate it as multivolume. We had this painful experience: a long gap between training classes allowing a lot of our large training subsytem tablespaces to migrate. The next training class initiated a slew of recalls which bogged down the system, and many of them failed due to not a large enough space on a single volume to do the recall. If you use a smaller primary and allocate as multivolume, HSM will have no problem bringing back all the pieces.

We also had the experience of a certain table suffering "death by random I/O". We noticed a marked performance improvement when the various extents were on separate volumes. We later resolved the problem with a huge bufferpool, but the situation clearly demonstrated that DB2 performs quite well with multiple extents.

My preference is for the primary to be 2 or 3 times what I expect the secondaries to be. We use the sliding scale algorithm for secondaries, so a relatively large tablespace would have a primary of 300-500 cylinders.

Regards,
Cathy Taddei

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Pospíšil Dušan
Sent: Friday, January 16, 2009 11:49 PM
To: [login to unmask email]
Subject: [MVS] Only one extend for TS/index?

Hello Listers:

Is it still worth trying to allocate data set for TS/index in such a way to cover all allocation by priqty?
And how much could I gain on performance?

DB2 V8 NFM - z/OS

Thanks,
dusan




------------------------------------------------------------------------------

This email is confidential and may be legally privileged.

It is intended solely for the addressee. Access to this email by anyone else, unless expressly approved by the sender or an authorized addressee, is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution or any action omitted or taken in reliance on it, is prohibited and may be unlawful. If you believe that you have received this email in error, please contact the sender, delete this e-mail and destroy all copies.

=====

______________________________________________________________________

* 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

--
I am using the free version of SPAMfighter.
We are a community of 5.8 million users fighting spam.
SPAMfighter has removed 4120 of my spam emails to date.
Get the free SPAMfighter here: http://www.spamfighter.com/len

The Professional version does not have this message

______________________________________________________________________

* 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

Ted MacNEIL

Re: [MVS] Only one extend for TS/index?
(in response to Isaac Yassin)
>You could've used PAV (or even better , hiper-pav) instead of the huge BP to solve the problem.

While PAV (in any flavour) is a good thing, the best I/O is no I/O.
So, I'm biased toward BP first, I/O improvement a distant second.
-
Too busy driving to stop for gas!

______________________________________________________________________

* 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

Cathy Taddei

Re: [MVS] Only one extend for TS/index?
(in response to Ted MacNEIL)
The problem I cited was a long time ago before we had PAV. Perhaps it was a clumsy example, but I just wanted to assure Dusan that tablespaces in multiple extents are no big deal to DB2, and may even be beneficial. It seems to me that a lot of people care about consolidating extents, and I agree with that when a particular disk volume is very fragmented, but as a part-time DASD manager, I prefer everything to be smaller than 1000 cylinders.

Thanks,
Cathy

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Isaac Yassin
Sent: Saturday, January 17, 2009 9:24 AM
To: [login to unmask email]
Subject: Re: [MVS] Only one extend for TS/index?

Hi,

I refer to " We also had the experience of a certain table suffering "death by random I/O". We noticed a marked performance improvement when the various extents were on separate volumes. "

This means you've had an IOSQ problem as all requests for the table when it resided on one volume were slow.
Spreading the extents over multiple volumes gave you respite from that as each request went to a separate volume so you did not get the "DBRIO" situation.
You could've used PAV (or even better , hiper-pav) instead of the huge BP to solve the problem.


Isaac Yassin


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Taddei, Cathy
Sent: Saturday, January 17, 2009 10:18 AM
To: [login to unmask email]
Subject: Re: [DB2-L] [MVS] Only one extend for TS/index?

One good reason to be careful with that, especially in test subsystems, is the likelihood of a tablespace being migrated by HSM. If you use a large primary, you should allocate it as multivolume. We had this painful experience: a long gap between training classes allowing a lot of our large training subsytem tablespaces to migrate. The next training class initiated a slew of recalls which bogged down the system, and many of them failed due to not a large enough space on a single volume to do the recall. If you use a smaller primary and allocate as multivolume, HSM will have no problem bringing back all the pieces.

We also had the experience of a certain table suffering "death by random I/O". We noticed a marked performance improvement when the various extents were on separate volumes. We later resolved the problem with a huge bufferpool, but the situation clearly demonstrated that DB2 performs quite well with multiple extents.

My preference is for the primary to be 2 or 3 times what I expect the secondaries to be. We use the sliding scale algorithm for secondaries, so a relatively large tablespace would have a primary of 300-500 cylinders.

Regards,
Cathy Taddei

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Pospí¹il Du¹an
Sent: Friday, January 16, 2009 11:49 PM
To: [login to unmask email]
Subject: [MVS] Only one extend for TS/index?

Hello Listers:

Is it still worth trying to allocate data set for TS/index in such a way to cover all allocation by priqty?
And how much could I gain on performance?

DB2 V8 NFM - z/OS

Thanks,
dusan




------------------------------------------------------------------------------

This email is confidential and may be legally privileged.

It is intended solely for the addressee. Access to this email by anyone else, unless expressly approved by the sender or an authorized addressee, is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution or any action omitted or taken in reliance on it, is prohibited and may be unlawful. If you believe that you have received this email in error, please contact the sender, delete this e-mail and destroy all copies.

=====

______________________________________________________________________

* 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

--
I am using the free version of SPAMfighter.
We are a community of 5.8 million users fighting spam.
SPAMfighter has removed 4120 of my spam emails to date.
Get the free SPAMfighter here: http://www.spamfighter.com/len

The Professional version does not have this message

______________________________________________________________________

* 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


------------------------------------------------------------------------------

This email is confidential and may be legally privileged.

It is intended solely for the addressee. Access to this email by anyone else, unless expressly approved by the sender or an authorized addressee, is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution or any action omitted or taken in reliance on it, is prohibited and may be unlawful. If you believe that you have received this email in error, please contact the sender, delete this e-mail and destroy all copies.

=====

______________________________________________________________________

* 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

Isaac Yassin

Re: [MVS] Only one extend for TS/index?
(in response to Cathy Taddei)
Hi

As long as you have unlimited memory - use it :-)
Somewhere along the road you always run out of memory (or gas :-) )

Isaac Yassin

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Ted MacNEIL
Sent: Saturday, January 17, 2009 7:33 PM
To: [login to unmask email]
Subject: Re: [DB2-L] [MVS] Only one extend for TS/index?

>You could've used PAV (or even better , hiper-pav) instead of the huge BP to solve the problem.

While PAV (in any flavour) is a good thing, the best I/O is no I/O.
So, I'm biased toward BP first, I/O improvement a distant second.
-
Too busy driving to stop for gas!

______________________________________________________________________

* 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

--
I am using the free version of SPAMfighter.
We are a community of 5.8 million users fighting spam.
SPAMfighter has removed 4120 of my spam emails to date.
Get the free SPAMfighter here: http://www.spamfighter.com/len

The Professional version does not have this message

______________________________________________________________________

* 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

Ted MacNEIL

Re: [MVS] Only one extend for TS/index?
(in response to Isaac Yassin)
>As long as you have unlimited memory - use it :-)
>Somewhere along the road you always run out of memory (or gas :-) )

Not these days.
1. You can always buy more -- it's cheap.
2. Memory/buffers suffer from the law of diminishing returns. In other words, buy what you need to improve performance, then worry about optimising I/O.
The best I/O is no I/O.
Get rid of what you can, and fix the rest.

I've been a performance analyst since 1981, and everybody says fix the I/O.
I say remove it first.

-
Too busy driving to stop for gas!

______________________________________________________________________

* 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

Ted MacNEIL

Re: [MVS] Only one extend for TS/index?
(in response to Ted MacNEIL)
>I just wanted to assure Dusan that tablespaces in multiple extents are no big deal to DB2, and may even be beneficial.

Is it DB2, or MVS.
With all of the improvements to disk hardware over the last 20+ years, nobody should care about extents anymore, regardless of the sub-system.

-
Too busy driving to stop for gas!

______________________________________________________________________

* 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

dusan pospisil

Re: [MVS] Only one extend for TS/index?
(in response to Ted MacNEIL)
Many thanks to all for answering my question dusan

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Ted MacNEIL
Sent: Saturday, January 17, 2009 7:16 PM
To: [login to unmask email]
Subject: Re: [DB2-L] [MVS] Only one extend for TS/index?

>I just wanted to assure Dusan that tablespaces in multiple extents are no big deal to DB2, and may even be beneficial.

Is it DB2, or MVS.
With all of the improvements to disk hardware over the last 20+ years, nobody should care about extents anymore, regardless of the sub-system.

-
Too busy driving to stop for gas!

______________________________________________________________________

* 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



_____________
Tato zpráva a v¹echny pøipojené soubory jsou dùvìrné a urèené výluènì adresátovi(-ùm). Jestli¾e nejste oprávnìným adresátem, je zakázáno jakékoliv zveøejòování, zprostøedkování nebo jiné pou¾ití tìchto informací. Jestli¾e jste tento mail dostali neoprávnìnì, prosím, uvìdomte odesilatele a sma¾te zprávu i pøilo¾ené soubory. Odesilatel nezodpovídá za jakékoliv chyby nebo opomenutí zpùsobené tímto pøenosem.
 
Jste si jisti, ¾e opravdu potøebujete vytisknout tuto zprávu a/nebo její pøílohy? Myslete na pøírodu.
 
 
This message and any attached files are confidential and intended solely for the addressee(s). Any publication, transmission or other use of the information by a person or entity other than the intended addressee is prohibited. If you receive this in error please contact the sender and delete the message as well as all attached documents. The sender does not accept liability for any errors or omissions as a result of the transmission.
 
Are you sure that you really need a print version of this message and/or its attachments? Think about nature.

-.- --


______________________________________________________________________

* 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