SV: [DB2-L] RUNSTATS' Alternative?

Hanne Lyssand

SV: [DB2-L] RUNSTATS' Alternative?
If I was in V7 an started to get questions on the cost of runstats I would use savings as argument for moving fast to V9 ;-)

Best regards
Hanne


Fra: IDUG DB2-L [mailto:[login to unmask email] På vegne av DB2DBAzOS
Sendt: 4. desember 2009 06:41
Til: [login to unmask email]
Emne: Re: [DB2-L] RUNSTATS' Alternative?

DB2 v7 had/have the RTS through few PTFs.. Recently (we are still on v7 in one DB2 ), we applied those PTFs and considering having RTS ON as it has several benefits.

What has been change in DB2 v8 is that RTS is looked up by the IBM DB2 utilities (I think I am right here too). So, if RTS is there, IBM utilities would look upto RTS for sortkeys, dynamic sort file allocation etc..

With V9 , RTS objects are integrated into DB2 Catalog.. (Right here too ?)

Sometimes working on DB2 v7, v8 and v9 simultaneously confuses me

Regards,
Bala.
On Thu, Dec 3, 2009 at 2:18 AM, Dell'Anno, Aurora <[login to unmask email]<mailto:[login to unmask email]>> wrote:
errrr.... were you calling me Raymond? sorry sorry I was just round the corner ;-)

Josh,

my 0.0000002c worth: I assume you will have to move from V7 to V8 kind of soon - and when you get to V8 RTS are always collected, simply not externalised (at which point of course you will have all the overhead as part of the process anyway...) - incidentally a lot of DB2 customers are finding great reductions in their daily process once they move to V9 so maybe you can plan way ahead.

And yes, CA do offer an alternative to RUNSTATS so if you are interested please contact me offline, or your local friendly CA rep...


Thanks.

Aurora

Aurora Emanuela Dell'Anno
CA
Sr. Engineering Services Architect
Tel: +44 (0)1753 577 733
Mobile: +44 (0)7768 235 339
[login to unmask email]
<mailto:[login to unmask email]>

http://www.ca.com/

P please don't print this e-mail unless you really need to!



________________________________
From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>] On Behalf Of Bell, Raymond
Sent: 24 November 2009 08:42

To: [login to unmask email]<mailto:[login to unmask email]>
Subject: Re: [DB2-L] RUNSTATS' Alternative?
Hi Josh,

If you're still on DB2 V7 and z/OS 1.4 I suspect you have bigger issues than the CPU consumption of Runstats. To hopefully accurately summarise some of what Mr. Sevetson quite rightly said, easiest thing might be simply to not run Runstats quite so often. After all, as has been used in a number of contexts, the fastest [insert action being discussed] is no [insert action being discussed]. For those remaining objects that do need Runstats, and for which reducing the Runstats job CPU/elapsed time is important, yes I believe there's at least one ISV that has a Runstats offering.

Cheers,


Raymond

From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>] On Behalf Of DB2 DBA
Sent: 23 November 2009 18:36
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] RUNSTATS' Alternative?

Hello:

DB2 V7
z/OS 1.4

As we all are aware how resource consuming RUNSTATS is (particularly for large tables), is there any alternative for this with any of the vendors? Or is there a work around?

I am not only worried about the cost (don't blame me for this) but also the 'time'. The existing set up is to have RUNSTATS run on Sundays, when rest of the world 'sleeps'. THIS, usually takes around 4 hours. Now, it is being recommended that the set up be moved to the regular weekdays and try to 'fit it' in the maintenance window which is 2 hours. So, we are planning to split this RUNSTATS job and run it in two different days. However, if there is any delay for any reason, we would have to push it beyond our maintenance window. And this is where we might have problems with the resource consumption.

(Splitting it into 5 different days and running 'em Mon-Fri is ruled out as we planned for some other 'adjustments' during maintenance window for the first 3 days of the week. Well, it doesn't look like a maintenance window any longer...)

Any suggestions/ideas/recommendations are welcome!


-Josh

________________________________

Feil! Filnavn er ikke angitt. < http://www.idug.org/ >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

________________________________

Feil! Filnavn er ikke angitt. < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

________________________________

Feil! Filnavn er ikke angitt. < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

________________________________

[ http://www.idug.org/images/M_images/idug%20na3.jpg ] < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/solutions-journal.html - home of the IDUG Solutions Journal
Technical atricles from world famous authors in DB2's most prestigious, peer reviewed
magazine now on-line!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

DB2 DBA

Re: RUNSTATS' Alternative?
(in response to Hanne Lyssand)
Bala - Wow! That sounds like a time-saver. Could you share the info on those
PTFs? I would appreciate if you did it.



-Josh



On Fri, Dec 4, 2009 at 12:40 AM, DB2DBAzOS <[login to unmask email]> wrote:

> DB2 v7 had/have the RTS through few PTFs.. Recently (we are still on v7
> in one DB2 ), we applied those PTFs and considering having RTS ON as it has
> several benefits.
>
> What has been change in DB2 v8 is that RTS is looked up by the IBM DB2
> utilities (I think I am right here too). So, if RTS is there, IBM utilities
> would look upto RTS for sortkeys, dynamic sort file allocation etc..
>
> With V9 , RTS objects are integrated into DB2 Catalog.. (Right here too ?)
>
> Sometimes working on DB2 v7, v8 and v9 simultaneously confuses me
>
> Regards,
> Bala.
>
> On Thu, Dec 3, 2009 at 2:18 AM, Dell'Anno, Aurora <
> [login to unmask email]> wrote:
>
>> errrr.... were you calling me Raymond? sorry sorry I was just round the
>> corner ;-)
>>
>> Josh,
>>
>> my 0.0000002c worth: I assume you will have to move from V7 to V8 kind of
>> soon - and when you get to V8 RTS are always collected, simply not
>> externalised (at which point of course you will have all the overhead as
>> part of the process anyway...) - incidentally a lot of DB2 customers are
>> finding great reductions in their daily process once they move to V9 so
>> maybe you can plan way ahead.
>>
>> And yes, CA do offer an alternative to RUNSTATS so if you are interested
>> please contact me offline, or your local friendly CA rep...
>>
>>
>> Thanks.
>>
>> Aurora
>>
>> **
>>
>> **
>>
>> **
>>
>> *Aurora Emanuela Dell'Anno*
>> CA
>> Sr. Engineering Services Architect
>> Tel: +44 (0)1753 577 733
>> Mobile: +44 (0)7768 235 339
>> *[login to unmask email]
>> * <[login to unmask email]>
>>
>> http://www.ca.com/
>>
>> P please don't print this e-mail unless you really need to!
>>
>>
>>
>>
>> ------------------------------
>> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *Bell,
>> Raymond
>> *Sent:* 24 November 2009 08:42
>>
>> *To:* [login to unmask email]
>> *Subject:* Re: [DB2-L] RUNSTATS' Alternative?
>>
>> Hi Josh,
>>
>>
>>
>> If you’re still on DB2 V7 and z/OS 1.4 I suspect you have bigger issues
>> than the CPU consumption of Runstats. To hopefully accurately summarise
>> some of what Mr. Sevetson quite rightly said, easiest thing might be simply
>> to not run Runstats quite so often. After all, as has been used in a number
>> of contexts, the fastest [insert action being discussed] is no [insert
>> action being discussed]. For those remaining objects that do need Runstats,
>> and for which reducing the Runstats job CPU/elapsed time is important, yes I
>> believe there’s at least one ISV that has a Runstats offering.
>>
>>
>>
>> Cheers,
>>
>>
>>
>>
>>
>> Raymond
>>
>>
>>
>> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *DB2 DBA
>> *Sent:* 23 November 2009 18:36
>> *To:* [login to unmask email]
>> *Subject:* [DB2-L] RUNSTATS' Alternative?
>>
>>
>>
>> Hello:
>>
>>
>>
>> DB2 V7
>>
>> z/OS 1.4
>>
>>
>>
>> As we all are aware how resource consuming RUNSTATS is (particularly for
>> large tables), is there any alternative for this with any of the vendors? Or
>> is there a work around?
>>
>>
>>
>> I am not only worried about the cost (don't blame me for this) but
>> also the 'time'. The existing set up is to have RUNSTATS run on Sundays,
>> when rest of the world 'sleeps'. THIS, usually takes around 4 hours. Now, it
>> is being recommended that the set up be moved to the regular weekdays and
>> try to 'fit it' in the maintenance window which is 2 hours. So, we are
>> planning to split this RUNSTATS job and run it in two different days.
>> However, if there is any delay for any reason, we would have to push it
>> beyond our maintenance window. And this is where we might have problems with
>> the resource consumption.
>>
>>
>>
>> (Splitting it into 5 different days and running 'em Mon-Fri is ruled out
>> as we planned for some other 'adjustments' during maintenance window for the
>> first 3 days of the week. Well, it doesn't look like a maintenance window
>> any longer...)
>>
>>
>>
>> Any suggestions/ideas/recommendations are welcome!
>>
>>
>>
>>
>>
>> -Josh
>>
>>
>> ------------------------------
>>
>> [image: IDUG - The Worldwide DB2 User Community!] < http://www.idug.org/ >
>>
>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>
>> ------------------------------
>>
>> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>>
>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>
>>
>> ------------------------------
>>
>> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>>
>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>
>
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/solutions-journal.html - home of the IDUG Solutions Journal
Technical atricles from world famous authors in DB2's most prestigious, peer reviewed
magazine now on-line!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Bala

Re: RUNSTATS' Alternative?
(in response to DB2 DBA)
Hi Josh,

If you have not looked it up on internet yet, these are the links for those
V7's PTFs.

http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+time+Statistics&uid=swg1PQ48448&loc=en_US&cs=utf-8&cc=us&lang=en

And, there are plenty of IBM docs that can be looked up at
www.ibm.com/support and IDUG presentations (available on IDUG website) that
I referred while implementing RTS in my shop (v7 z/OS 1.4).

References.
http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27004021&loc=en_US&cs=utf-8&cc=us&lang=en

http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27005106&loc=en_US&cs=utf-8&cc=us&lang=en

On Fri, Dec 4, 2009 at 9:11 PM, DB2 DBA <[login to unmask email]> wrote:

> Bala - Wow! That sounds like a time-saver. Could you share the info on
> those PTFs? I would appreciate if you did it.
>
>
>
> -Josh
>
>
>
> On Fri, Dec 4, 2009 at 12:40 AM, DB2DBAzOS <[login to unmask email]> wrote:
>
>> DB2 v7 had/have the RTS through few PTFs.. Recently (we are still on v7
>> in one DB2 ), we applied those PTFs and considering having RTS ON as it has
>> several benefits.
>>
>> What has been change in DB2 v8 is that RTS is looked up by the IBM DB2
>> utilities (I think I am right here too). So, if RTS is there, IBM utilities
>> would look upto RTS for sortkeys, dynamic sort file allocation etc..
>>
>> With V9 , RTS objects are integrated into DB2 Catalog.. (Right here too ?)
>>
>> Sometimes working on DB2 v7, v8 and v9 simultaneously confuses me
>>
>> Regards,
>> Bala.
>>
>> On Thu, Dec 3, 2009 at 2:18 AM, Dell'Anno, Aurora <
>> [login to unmask email]> wrote:
>>
>>> errrr.... were you calling me Raymond? sorry sorry I was just round the
>>> corner ;-)
>>>
>>> Josh,
>>>
>>> my 0.0000002c worth: I assume you will have to move from V7 to V8 kind of
>>> soon - and when you get to V8 RTS are always collected, simply not
>>> externalised (at which point of course you will have all the overhead as
>>> part of the process anyway...) - incidentally a lot of DB2 customers are
>>> finding great reductions in their daily process once they move to V9 so
>>> maybe you can plan way ahead.
>>>
>>> And yes, CA do offer an alternative to RUNSTATS so if you are interested
>>> please contact me offline, or your local friendly CA rep...
>>>
>>>
>>> Thanks.
>>>
>>> Aurora
>>>
>>> **
>>>
>>> **
>>>
>>> **
>>>
>>> *Aurora Emanuela Dell'Anno*
>>> CA
>>> Sr. Engineering Services Architect
>>> Tel: +44 (0)1753 577 733
>>> Mobile: +44 (0)7768 235 339
>>> *[login to unmask email]
>>> * <[login to unmask email]>
>>>
>>> http://www.ca.com/
>>>
>>> P please don't print this e-mail unless you really need to!
>>>
>>>
>>>
>>>
>>> ------------------------------
>>> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *Bell,
>>> Raymond
>>> *Sent:* 24 November 2009 08:42
>>>
>>> *To:* [login to unmask email]
>>> *Subject:* Re: [DB2-L] RUNSTATS' Alternative?
>>>
>>> Hi Josh,
>>>
>>>
>>>
>>> If you’re still on DB2 V7 and z/OS 1.4 I suspect you have bigger issues
>>> than the CPU consumption of Runstats. To hopefully accurately summarise
>>> some of what Mr. Sevetson quite rightly said, easiest thing might be simply
>>> to not run Runstats quite so often. After all, as has been used in a number
>>> of contexts, the fastest [insert action being discussed] is no [insert
>>> action being discussed]. For those remaining objects that do need Runstats,
>>> and for which reducing the Runstats job CPU/elapsed time is important, yes I
>>> believe there’s at least one ISV that has a Runstats offering.
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>>
>>>
>>> Raymond
>>>
>>>
>>>
>>> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *DB2 DBA
>>> *Sent:* 23 November 2009 18:36
>>> *To:* [login to unmask email]
>>> *Subject:* [DB2-L] RUNSTATS' Alternative?
>>>
>>>
>>>
>>> Hello:
>>>
>>>
>>>
>>> DB2 V7
>>>
>>> z/OS 1.4
>>>
>>>
>>>
>>> As we all are aware how resource consuming RUNSTATS is (particularly for
>>> large tables), is there any alternative for this with any of the vendors? Or
>>> is there a work around?
>>>
>>>
>>>
>>> I am not only worried about the cost (don't blame me for this) but
>>> also the 'time'. The existing set up is to have RUNSTATS run on Sundays,
>>> when rest of the world 'sleeps'. THIS, usually takes around 4 hours. Now, it
>>> is being recommended that the set up be moved to the regular weekdays and
>>> try to 'fit it' in the maintenance window which is 2 hours. So, we are
>>> planning to split this RUNSTATS job and run it in two different days.
>>> However, if there is any delay for any reason, we would have to push it
>>> beyond our maintenance window. And this is where we might have problems with
>>> the resource consumption.
>>>
>>>
>>>
>>> (Splitting it into 5 different days and running 'em Mon-Fri is ruled out
>>> as we planned for some other 'adjustments' during maintenance window for the
>>> first 3 days of the week. Well, it doesn't look like a maintenance window
>>> any longer...)
>>>
>>>
>>>
>>> Any suggestions/ideas/recommendations are welcome!
>>>
>>>
>>>
>>>
>>>
>>> -Josh
>>>
>>>
>>> ------------------------------
>>>
>>> [image: IDUG - The Worldwide DB2 User Community!] < http://www.idug.org/ >
>>>
>>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>>
>>> ------------------------------
>>>
>>> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>>>
>>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>>
>>>
>>> ------------------------------
>>>
>>> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>>>
>>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>>
>>
>>
>> ------------------------------
>>
>> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>>
>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>
>
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

DB2 DBA

Re: RUNSTATS' Alternative?
(in response to Bala)
Thanks Bala, that's plenty.


-Josh



On Mon, Dec 7, 2009 at 12:34 AM, DB2DBAzOS <[login to unmask email]> wrote:

> Hi Josh,
>
> If you have not looked it up on internet yet, these are the links for those
> V7's PTFs.
>
>
> http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+time+Statistics&uid=swg1PQ48448&loc=en_US&cs=utf-8&cc=us&lang=en
>
> And, there are plenty of IBM docs that can be looked up at
> www.ibm.com/support and IDUG presentations (available on IDUG website)
> that I referred while implementing RTS in my shop (v7 z/OS 1.4).
>
> References.
>
> http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27004021&loc=en_US&cs=utf-8&cc=us&lang=en
>
>
> http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27005106&loc=en_US&cs=utf-8&cc=us&lang=en
>
> On Fri, Dec 4, 2009 at 9:11 PM, DB2 DBA <[login to unmask email]> wrote:
>
>> Bala - Wow! That sounds like a time-saver. Could you share the info on
>> those PTFs? I would appreciate if you did it.
>>
>>
>>
>> -Josh
>>
>>
>>
>> On Fri, Dec 4, 2009 at 12:40 AM, DB2DBAzOS <[login to unmask email]> wrote:
>>
>>> DB2 v7 had/have the RTS through few PTFs.. Recently (we are still on v7
>>> in one DB2 ), we applied those PTFs and considering having RTS ON as it has
>>> several benefits.
>>>
>>> What has been change in DB2 v8 is that RTS is looked up by the IBM DB2
>>> utilities (I think I am right here too). So, if RTS is there, IBM utilities
>>> would look upto RTS for sortkeys, dynamic sort file allocation etc..
>>>
>>> With V9 , RTS objects are integrated into DB2 Catalog.. (Right here too
>>> ?)
>>>
>>> Sometimes working on DB2 v7, v8 and v9 simultaneously confuses me
>>>
>>> Regards,
>>> Bala.
>>>
>>> On Thu, Dec 3, 2009 at 2:18 AM, Dell'Anno, Aurora <
>>> [login to unmask email]> wrote:
>>>
>>>> errrr.... were you calling me Raymond? sorry sorry I was just round
>>>> the corner ;-)
>>>>
>>>> Josh,
>>>>
>>>> my 0.0000002c worth: I assume you will have to move from V7 to V8 kind
>>>> of soon - and when you get to V8 RTS are always collected, simply not
>>>> externalised (at which point of course you will have all the overhead as
>>>> part of the process anyway...) - incidentally a lot of DB2 customers are
>>>> finding great reductions in their daily process once they move to V9 so
>>>> maybe you can plan way ahead.
>>>>
>>>> And yes, CA do offer an alternative to RUNSTATS so if you are interested
>>>> please contact me offline, or your local friendly CA rep...
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> Aurora
>>>>
>>>> **
>>>>
>>>> **
>>>>
>>>> **
>>>>
>>>> *Aurora Emanuela Dell'Anno*
>>>> CA
>>>> Sr. Engineering Services Architect
>>>> Tel: +44 (0)1753 577 733
>>>> Mobile: +44 (0)7768 235 339
>>>> *[login to unmask email]
>>>> * <[login to unmask email]>
>>>>
>>>> http://www.ca.com/
>>>>
>>>> P please don't print this e-mail unless you really need to!
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *Bell,
>>>> Raymond
>>>> *Sent:* 24 November 2009 08:42
>>>>
>>>> *To:* [login to unmask email]
>>>> *Subject:* Re: [DB2-L] RUNSTATS' Alternative?
>>>>
>>>> Hi Josh,
>>>>
>>>>
>>>>
>>>> If you’re still on DB2 V7 and z/OS 1.4 I suspect you have bigger issues
>>>> than the CPU consumption of Runstats. To hopefully accurately summarise
>>>> some of what Mr. Sevetson quite rightly said, easiest thing might be simply
>>>> to not run Runstats quite so often. After all, as has been used in a number
>>>> of contexts, the fastest [insert action being discussed] is no [insert
>>>> action being discussed]. For those remaining objects that do need Runstats,
>>>> and for which reducing the Runstats job CPU/elapsed time is important, yes I
>>>> believe there’s at least one ISV that has a Runstats offering.
>>>>
>>>>
>>>>
>>>> Cheers,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Raymond
>>>>
>>>>
>>>>
>>>> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *DB2 DBA
>>>> *Sent:* 23 November 2009 18:36
>>>> *To:* [login to unmask email]
>>>> *Subject:* [DB2-L] RUNSTATS' Alternative?
>>>>
>>>>
>>>>
>>>> Hello:
>>>>
>>>>
>>>>
>>>> DB2 V7
>>>>
>>>> z/OS 1.4
>>>>
>>>>
>>>>
>>>> As we all are aware how resource consuming RUNSTATS is (particularly for
>>>> large tables), is there any alternative for this with any of the vendors? Or
>>>> is there a work around?
>>>>
>>>>
>>>>
>>>> I am not only worried about the cost (don't blame me for this) but
>>>> also the 'time'. The existing set up is to have RUNSTATS run on Sundays,
>>>> when rest of the world 'sleeps'. THIS, usually takes around 4 hours. Now, it
>>>> is being recommended that the set up be moved to the regular weekdays and
>>>> try to 'fit it' in the maintenance window which is 2 hours. So, we are
>>>> planning to split this RUNSTATS job and run it in two different days.
>>>> However, if there is any delay for any reason, we would have to push it
>>>> beyond our maintenance window. And this is where we might have problems with
>>>> the resource consumption.
>>>>
>>>>
>>>>
>>>> (Splitting it into 5 different days and running 'em Mon-Fri is ruled out
>>>> as we planned for some other 'adjustments' during maintenance window for the
>>>> first 3 days of the week. Well, it doesn't look like a maintenance window
>>>> any longer...)
>>>>
>>>>
>>>>
>>>> Any suggestions/ideas/recommendations are welcome!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -Josh
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/ >
>>>>
>>>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>>>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>>>
>>>> ------------------------------
>>>>
>>>> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>>>>
>>>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>>>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>>>>
>>>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>>>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>>>
>>>
>>>
>>> ------------------------------
>>>
>>> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>>>
>>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>>
>>
>>
>> ------------------------------
>>
>> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>>
>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>
>
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community!] < http://www.idug.org/ >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

DB2 DBA

Re: RUNSTATS' Alternative?
(in response to DB2 DBA)
Hello:

DB2 V7
z/OS 1.4

We have decided to install/deploy RTS in our shop. However, I realized that
the sample DDL in DSN710.SDSNSAMP(DSNTESS) has storage-group as SYSDEFLT. I
look at RTS as another catalog table and I think STOGROUP should be SYSDEFLT
and BUFFERPOOL should also be the default one used for other catalog tables.

However, my system programmer suggests me that I should consider using the
STOGROUP & BUFFERPOOL that are used for apps or associated with apps.

Can someone confirm if I am going in the right direction.


-Josh

Baba z wozu, koniom lżej


On Mon, Dec 7, 2009 at 12:15 PM, DB2 DBA <[login to unmask email]> wrote:

> Thanks Bala, that's plenty.
>
>
> -Josh
>
>
>
> On Mon, Dec 7, 2009 at 12:34 AM, DB2DBAzOS <[login to unmask email]> wrote:
>
>> Hi Josh,
>>
>> If you have not looked it up on internet yet, these are the links for
>> those V7's PTFs.
>>
>>
>> http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+time+Statistics&uid=swg1PQ48448&loc=en_US&cs=utf-8&cc=us&lang=en
>>
>> And, there are plenty of IBM docs that can be looked up at
>> www.ibm.com/support and IDUG presentations (available on IDUG website)
>> that I referred while implementing RTS in my shop (v7 z/OS 1.4).
>>
>> References.
>>
>> http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27004021&loc=en_US&cs=utf-8&cc=us&lang=en
>>
>>
>> http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27005106&loc=en_US&cs=utf-8&cc=us&lang=en
>>
>> On Fri, Dec 4, 2009 at 9:11 PM, DB2 DBA <[login to unmask email]> wrote:
>>
>>> Bala - Wow! That sounds like a time-saver. Could you share the info on
>>> those PTFs? I would appreciate if you did it.
>>>
>>>
>>>
>>> -Josh
>>>
>>>
>>>
>>> On Fri, Dec 4, 2009 at 12:40 AM, DB2DBAzOS <[login to unmask email]>wrote:
>>>
>>>> DB2 v7 had/have the RTS through few PTFs.. Recently (we are still on v7
>>>> in one DB2 ), we applied those PTFs and considering having RTS ON as it has
>>>> several benefits.
>>>>
>>>> What has been change in DB2 v8 is that RTS is looked up by the IBM DB2
>>>> utilities (I think I am right here too). So, if RTS is there, IBM utilities
>>>> would look upto RTS for sortkeys, dynamic sort file allocation etc..
>>>>
>>>> With V9 , RTS objects are integrated into DB2 Catalog.. (Right here too
>>>> ?)
>>>>
>>>> Sometimes working on DB2 v7, v8 and v9 simultaneously confuses me
>>>>
>>>> Regards,
>>>> Bala.
>>>>
>>>> On Thu, Dec 3, 2009 at 2:18 AM, Dell'Anno, Aurora <
>>>> [login to unmask email]> wrote:
>>>>
>>>>> errrr.... were you calling me Raymond? sorry sorry I was just round
>>>>> the corner ;-)
>>>>>
>>>>> Josh,
>>>>>
>>>>> my 0.0000002c worth: I assume you will have to move from V7 to V8 kind
>>>>> of soon - and when you get to V8 RTS are always collected, simply not
>>>>> externalised (at which point of course you will have all the overhead as
>>>>> part of the process anyway...) - incidentally a lot of DB2 customers are
>>>>> finding great reductions in their daily process once they move to V9 so
>>>>> maybe you can plan way ahead.
>>>>>
>>>>> And yes, CA do offer an alternative to RUNSTATS so if you are
>>>>> interested please contact me offline, or your local friendly CA rep...
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Aurora
>>>>>
>>>>> **
>>>>>
>>>>> **
>>>>>
>>>>> **
>>>>>
>>>>> *Aurora Emanuela Dell'Anno*
>>>>> CA
>>>>> Sr. Engineering Services Architect
>>>>> Tel: +44 (0)1753 577 733
>>>>> Mobile: +44 (0)7768 235 339
>>>>> *[login to unmask email]
>>>>> * <[login to unmask email]>
>>>>>
>>>>> http://www.ca.com/
>>>>>
>>>>> P please don't print this e-mail unless you really need to!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *Bell,
>>>>> Raymond
>>>>> *Sent:* 24 November 2009 08:42
>>>>>
>>>>> *To:* [login to unmask email]
>>>>> *Subject:* Re: [DB2-L] RUNSTATS' Alternative?
>>>>>
>>>>> Hi Josh,
>>>>>
>>>>>
>>>>>
>>>>> If you’re still on DB2 V7 and z/OS 1.4 I suspect you have bigger issues
>>>>> than the CPU consumption of Runstats. To hopefully accurately summarise
>>>>> some of what Mr. Sevetson quite rightly said, easiest thing might be simply
>>>>> to not run Runstats quite so often. After all, as has been used in a number
>>>>> of contexts, the fastest [insert action being discussed] is no [insert
>>>>> action being discussed]. For those remaining objects that do need Runstats,
>>>>> and for which reducing the Runstats job CPU/elapsed time is important, yes I
>>>>> believe there’s at least one ISV that has a Runstats offering.
>>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Raymond
>>>>>
>>>>>
>>>>>
>>>>> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *DB2 DBA
>>>>> *Sent:* 23 November 2009 18:36
>>>>> *To:* [login to unmask email]
>>>>> *Subject:* [DB2-L] RUNSTATS' Alternative?
>>>>>
>>>>>
>>>>>
>>>>> Hello:
>>>>>
>>>>>
>>>>>
>>>>> DB2 V7
>>>>>
>>>>> z/OS 1.4
>>>>>
>>>>>
>>>>>
>>>>> As we all are aware how resource consuming RUNSTATS is (particularly
>>>>> for large tables), is there any alternative for this with any of the
>>>>> vendors? Or is there a work around?
>>>>>
>>>>>
>>>>>
>>>>> I am not only worried about the cost (don't blame me for this) but
>>>>> also the 'time'. The existing set up is to have RUNSTATS run on Sundays,
>>>>> when rest of the world 'sleeps'. THIS, usually takes around 4 hours. Now, it
>>>>> is being recommended that the set up be moved to the regular weekdays and
>>>>> try to 'fit it' in the maintenance window which is 2 hours. So, we are
>>>>> planning to split this RUNSTATS job and run it in two different days.
>>>>> However, if there is any delay for any reason, we would have to push it
>>>>> beyond our maintenance window. And this is where we might have problems with
>>>>> the resource consumption.
>>>>>
>>>>>
>>>>>
>>>>> (Splitting it into 5 different days and running 'em Mon-Fri is ruled
>>>>> out as we planned for some other 'adjustments' during maintenance window for
>>>>> the first 3 days of the week. Well, it doesn't look like a maintenance
>>>>> window any longer...)
>>>>>
>>>>>
>>>>>
>>>>> Any suggestions/ideas/recommendations are welcome!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -Josh
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/ >
>>>>>
>>>>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>>>>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>>>>>
>>>>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>>>>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>>>>>
>>>>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>>>>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>>>>
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>>>>
>>>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>>>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>>>
>>>
>>>
>>> ------------------------------
>>>
>>> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>>>
>>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>>
>>
>>
>> ------------------------------
>>
>> [image: IDUG - The Worldwide DB2 User Community!] < http://www.idug.org/ >
>>
>> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
>> are not already an IDUG member, please register here. < http://www.idug.org/register >
>>
>
>

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-content/index.html has THOUSANDS of free technical presentations!
DB2 LUW, DB2 z/OS, Performance, Installation, Tuning, Coding, BI, Warehouses, - among
many more categories of help waiting for you!
Whether you are an old hand or a DB2 newbie, we have presentations for every level.
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Philip Sevetson

Re: RUNSTATS' Alternative?
(in response to DB2 DBA)
Josh:
If you ever close an application bufferpool, you lose the ability to read all objects associated with that bufferpool. For that reason, I'd recommend putting the RTS spaces in the same BP you use for (other) system objects. For STOGROUPs, if you're recovering the system datasets, you'd want to recover the RTS objects to the same point. So, you're right; your system programmer is wrong on this.

--Phil Sevetson

________________________________
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of DB2 DBA
Sent: Tuesday, December 15, 2009 11:49 AM
To: [login to unmask email]
Subject: Re: [DB2-L] RUNSTATS' Alternative?


Hello:

DB2 V7
z/OS 1.4

We have decided to install/deploy RTS in our shop. However, I realized that the sample DDL in DSN710.SDSNSAMP(DSNTESS) has storage-group as SYSDEFLT. I look at RTS as another catalog table and I think STOGROUP should be SYSDEFLT and BUFFERPOOL should also be the default one used for other catalog tables.

However, my system programmer suggests me that I should consider using the STOGROUP & BUFFERPOOL that are used for apps or associated with apps.

Can someone confirm if I am going in the right direction.

-Josh

Baba z wozu, koniom l¿ej

On Mon, Dec 7, 2009 at 12:15 PM, DB2 DBA <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Thanks Bala, that's plenty.


-Josh



On Mon, Dec 7, 2009 at 12:34 AM, DB2DBAzOS <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Hi Josh,

If you have not looked it up on internet yet, these are the links for those V7's PTFs.

http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+time+Statistics&uid=swg1PQ48448&loc=en_US&cs=utf-8&cc=us&lang=en

And, there are plenty of IBM docs that can be looked up at www.ibm.com/support < http://www.ibm.com/support > and IDUG presentations (available on IDUG website) that I referred while implementing RTS in my shop (v7 z/OS 1.4).

References.
http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27004021&loc=en_US&cs=utf-8&cc=us&lang=en

http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27005106&loc=en_US&cs=utf-8&cc=us&lang=en
On Fri, Dec 4, 2009 at 9:11 PM, DB2 DBA <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Bala - Wow! That sounds like a time-saver. Could you share the info on those PTFs? I would appreciate if you did it.



-Josh



On Fri, Dec 4, 2009 at 12:40 AM, DB2DBAzOS <[login to unmask email]<mailto:[login to unmask email]>> wrote:
DB2 v7 had/have the RTS through few PTFs.. Recently (we are still on v7 in one DB2 ), we applied those PTFs and considering having RTS ON as it has several benefits.

What has been change in DB2 v8 is that RTS is looked up by the IBM DB2 utilities (I think I am right here too). So, if RTS is there, IBM utilities would look upto RTS for sortkeys, dynamic sort file allocation etc..

With V9 , RTS objects are integrated into DB2 Catalog.. (Right here too ?)

Sometimes working on DB2 v7, v8 and v9 simultaneously confuses me

Regards,
Bala.
On Thu, Dec 3, 2009 at 2:18 AM, Dell'Anno, Aurora <[login to unmask email]<mailto:[login to unmask email]>> wrote:
errrr.... were you calling me Raymond? sorry sorry I was just round the corner ;-)

Josh,

my 0.0000002c worth: I assume you will have to move from V7 to V8 kind of soon - and when you get to V8 RTS are always collected, simply not externalised (at which point of course you will have all the overhead as part of the process anyway...) - incidentally a lot of DB2 customers are finding great reductions in their daily process once they move to V9 so maybe you can plan way ahead.

And yes, CA do offer an alternative to RUNSTATS so if you are interested please contact me offline, or your local friendly CA rep...


Thanks.

Aurora

Aurora Emanuela Dell'Anno
CA
Sr. Engineering Services Architect
Tel: +44 (0)1753 577 733
Mobile: +44 (0)7768 235 339
[login to unmask email]
<mailto:[login to unmask email]>

http://www.ca.com/

P please don't print this e-mail unless you really need to!



________________________________
From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>] On Behalf Of Bell, Raymond
Sent: 24 November 2009 08:42

To: [login to unmask email]<mailto:[login to unmask email]>
Subject: Re: [DB2-L] RUNSTATS' Alternative?
Hi Josh,

If you're still on DB2 V7 and z/OS 1.4 I suspect you have bigger issues than the CPU consumption of Runstats. To hopefully accurately summarise some of what Mr. Sevetson quite rightly said, easiest thing might be simply to not run Runstats quite so often. After all, as has been used in a number of contexts, the fastest [insert action being discussed] is no [insert action being discussed]. For those remaining objects that do need Runstats, and for which reducing the Runstats job CPU/elapsed time is important, yes I believe there's at least one ISV that has a Runstats offering.

Cheers,


Raymond

From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>] On Behalf Of DB2 DBA
Sent: 23 November 2009 18:36
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] RUNSTATS' Alternative?

Hello:

DB2 V7
z/OS 1.4

As we all are aware how resource consuming RUNSTATS is (particularly for large tables), is there any alternative for this with any of the vendors? Or is there a work around?

I am not only worried about the cost (don't blame me for this) but also the 'time'. The existing set up is to have RUNSTATS run on Sundays, when rest of the world 'sleeps'. THIS, usually takes around 4 hours. Now, it is being recommended that the set up be moved to the regular weekdays and try to 'fit it' in the maintenance window which is 2 hours. So, we are planning to split this RUNSTATS job and run it in two different days. However, if there is any delay for any reason, we would have to push it beyond our maintenance window. And this is where we might have problems with the resource consumption.

(Splitting it into 5 different days and running 'em Mon-Fri is ruled out as we planned for some other 'adjustments' during maintenance window for the first 3 days of the week. Well, it doesn't look like a maintenance window any longer...)

Any suggestions/ideas/recommendations are welcome!


-Josh

________________________________

[%20 ] < http://www.idug.org/ >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

________________________________

[%20 ] < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

________________________________

[%20 ] < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

________________________________

[%20 ] < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

________________________________

[%20 ] < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

________________________________

[%20 ] < http://www.idug.org/ >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >


________________________________

[ http://www.idug.org/images/M_images/idug%20org.jpg ] < http://www.idug.org >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-content/index.html has THOUSANDS of free technical presentations!
DB2 LUW, DB2 z/OS, Performance, Installation, Tuning, Coding, BI, Warehouses, - among
many more categories of help waiting for you!
Whether you are an old hand or a DB2 newbie, we have presentations for every level.
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

DB2 DBA

Re: RUNSTATS' Alternative?
(in response to Philip Sevetson)
Phil,

Thanks for confirming my take on it, with an apt example. One more question,
do you think there could be any ill-effect on the overall performance of DB2
due to the installation of RTS? As, this also works like RUNSTATS, as far as
collecting statistics goes.

Also, how does RTS collect statistics of the tables that are loaded using
BMC utilities that run outside of DB2?


-Josh


2009/12/15 Sevetson, Phil <[login to unmask email]>

> Josh:
>
> If you ever close an application bufferpool, you lose the ability to read
> all objects associated with that bufferpool. For that reason, I'd recommend
> putting the RTS spaces in the same BP you use for (other) system objects.
> For STOGROUPs, if you're recovering the system datasets, you'd want to
> recover the RTS objects to the same point. So, you're right; your system
> programmer is wrong on this.
>
>
>
> --Phil Sevetson
>
>
> ------------------------------
>
> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *DB2 DBA
> *Sent:* Tuesday, December 15, 2009 11:49 AM
>
> *To:* [login to unmask email]
> *Subject:* Re: [DB2-L] RUNSTATS' Alternative?
>
>
>
> Hello:
>
> DB2 V7
> z/OS 1.4
>
> We have decided to install/deploy RTS in our shop. However, I realized that
> the sample DDL in DSN710.SDSNSAMP(DSNTESS) has storage-group as SYSDEFLT. I
> look at RTS as another catalog table and I think STOGROUP should be SYSDEFLT
> and BUFFERPOOL should also be the default one used for other catalog tables.
>
> However, my system programmer suggests me that I should consider using the
> STOGROUP & BUFFERPOOL that are used for apps or associated with apps.
>
> Can someone confirm if I am going in the right direction.
>
>
> -Josh
>
> Baba z wozu, koniom l¿ej
>
> On Mon, Dec 7, 2009 at 12:15 PM, DB2 DBA <[login to unmask email]> wrote:
>
> Thanks Bala, that's plenty.
>
>
>
>
>
> -Josh
>
>
>
>
>
> On Mon, Dec 7, 2009 at 12:34 AM, DB2DBAzOS <[login to unmask email]> wrote:
>
> Hi Josh,
>
>
>
> If you have not looked it up on internet yet, these are the links for those
> V7's PTFs.
>
>
>
>
> http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+time+Statistics&uid=swg1PQ48448&loc=en_US&cs=utf-8&cc=us&lang=en
>
>
>
> And, there are plenty of IBM docs that can be looked up at
> www.ibm.com/support and IDUG presentations (available on IDUG website)
> that I referred while implementing RTS in my shop (v7 z/OS 1.4).
>
>
>
> References.
>
>
> http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27004021&loc=en_US&cs=utf-8&cc=us&lang=en
>
>
>
>
> http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27005106&loc=en_US&cs=utf-8&cc=us&lang=en
>
> On Fri, Dec 4, 2009 at 9:11 PM, DB2 DBA <[login to unmask email]> wrote:
>
> Bala - Wow! That sounds like a time-saver. Could you share the info on
> those PTFs? I would appreciate if you did it.
>
>
>
>
>
>
>
> -Josh
>
>
>
>
>
> On Fri, Dec 4, 2009 at 12:40 AM, DB2DBAzOS <[login to unmask email]> wrote:
>
> DB2 v7 had/have the RTS through few PTFs.. Recently (we are still on v7
> in one DB2 ), we applied those PTFs and considering having RTS ON as it has
> several benefits.
>
>
>
> What has been change in DB2 v8 is that RTS is looked up by the IBM DB2
> utilities (I think I am right here too). So, if RTS is there, IBM utilities
> would look upto RTS for sortkeys, dynamic sort file allocation etc..
>
>
>
> With V9 , RTS objects are integrated into DB2 Catalog.. (Right here too ?)
>
>
>
> Sometimes working on DB2 v7, v8 and v9 simultaneously confuses me
>
>
>
> Regards,
>
> Bala.
>
> On Thu, Dec 3, 2009 at 2:18 AM, Dell'Anno, Aurora <[login to unmask email]>
> wrote:
>
> errrr.... were you calling me Raymond? sorry sorry I was just round the
> corner ;-)
>
>
>
> Josh,
>
>
>
> my 0.0000002c worth: I assume you will have to move from V7 to V8 kind of
> soon - and when you get to V8 RTS are always collected, simply not
> externalised (at which point of course you will have all the overhead as
> part of the process anyway...) - incidentally a lot of DB2 customers are
> finding great reductions in their daily process once they move to V9 so
> maybe you can plan way ahead.
>
>
>
> And yes, CA do offer an alternative to RUNSTATS so if you are interested
> please contact me offline, or your local friendly CA rep...
>
>
>
> Thanks.
>
> Aurora
>
> *Aurora Emanuela Dell'Anno*
>
> CA
> Sr. Engineering Services Architect
>
> Tel: +44 (0)1753 577 733
> Mobile: +44 (0)7768 235 339
> [login to unmask email]
>
> http://www.ca.com/
>
> P please don't print this e-mail unless you really need to!
>
>
>
>
>
>
> ------------------------------
>
> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *Bell,
> Raymond
> *Sent:* 24 November 2009 08:42
>
>
> *To:* [login to unmask email]
>
> *Subject:* Re: [DB2-L] RUNSTATS' Alternative?
>
> Hi Josh,
>
>
>
> If you're still on DB2 V7 and z/OS 1.4 I suspect you have bigger issues
> than the CPU consumption of Runstats. To hopefully accurately summarise
> some of what Mr. Sevetson quite rightly said, easiest thing might be simply
> to not run Runstats quite so often. After all, as has been used in a number
> of contexts, the fastest [insert action being discussed] is no [insert
> action being discussed]. For those remaining objects that do need Runstats,
> and for which reducing the Runstats job CPU/elapsed time is important, yes I
> believe there's at least one ISV that has a Runstats offering.
>
>
>
> Cheers,
>
>
>
>
>
> Raymond
>
>
>
> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *DB2 DBA
> *Sent:* 23 November 2009 18:36
> *To:* [login to unmask email]
> *Subject:* [DB2-L] RUNSTATS' Alternative?
>
>
>
> Hello:
>
>
>
> DB2 V7
>
> z/OS 1.4
>
>
>
> As we all are aware how resource consuming RUNSTATS is (particularly for
> large tables), is there any alternative for this with any of the vendors? Or
> is there a work around?
>
>
>
> I am not only worried about the cost (don't blame me for this) but also the
> 'time'. The existing set up is to have RUNSTATS run on Sundays, when rest of
> the world 'sleeps'. THIS, usually takes around 4 hours. Now, it is being
> recommended that the set up be moved to the regular weekdays and try to 'fit
> it' in the maintenance window which is 2 hours. So, we are planning to split
> this RUNSTATS job and run it in two different days. However, if there is any
> delay for any reason, we would have to push it beyond our maintenance
> window. And this is where we might have problems with the resource
> consumption.
>
>
>
> (Splitting it into 5 different days and running 'em Mon-Fri is ruled out as
> we planned for some other 'adjustments' during maintenance window for the
> first 3 days of the week. Well, it doesn't look like a maintenance window
> any longer...)
>
>
>
> Any suggestions/ideas/recommendations are welcome!
>
>
>
>
>
> -Josh
>
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community!] < http://www.idug.org/ >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community!] < http://www.idug.org/ >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>
>
>
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community!] < http://www.idug.org/ >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community!] < http://www.idug.org/ >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-content/index.html has THOUSANDS of free technical presentations!
DB2 LUW, DB2 z/OS, Performance, Installation, Tuning, Coding, BI, Warehouses, - among
many more categories of help waiting for you!
Whether you are an old hand or a DB2 newbie, we have presentations for every level.
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Randy Bright

Re: RUNSTATS' Alternative?
(in response to DB2 DBA)
I'll answer the second half of your question first. The BMC Utilities update the RTS tables in much the same way as the IBM Utilities. There are some subtle differences because the BMC Utilities have some capabilities that differ from IBM so sometimes there isn't a "one-to-one" match between what the IBM utilities and the BMC Utilities do. But the end result should be the same. The RTS tables are maintained by the BMC Utilities.

Back on your first question. We have not seen any noticeable performance difference with RTS turned on. DB2, for the most part, keeps track of a lot of the information that is in the RTS tables anyway. The only additional overhead is that involved in actually updating the tables. As long as you don't get carried away with lowering the interval used to update these tables, you should not see any effect.

________________________________

Randy Bright
Solutions Architect
DB2 Utilities
BMC Software, Inc.

phone: 512-340-6014
cell: 512-656-0240

10431 Morado Circle
Austin, TX 78759

[ http://www.bmc.com/USA/Corporate/graphics/logo_with_tag1.gif ] < http://www.bmc.com >


________________________________
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of DB2 DBA
Sent: Tuesday, December 15, 2009 3:19 PM
To: [login to unmask email]
Subject: Re: [DB2-L] RUNSTATS' Alternative?


Phil,

Thanks for confirming my take on it, with an apt example. One more question, do you think there could be any ill-effect on the overall performance of DB2 due to the installation of RTS? As, this also works like RUNSTATS, as far as collecting statistics goes.

Also, how does RTS collect statistics of the tables that are loaded using BMC utilities that run outside of DB2?

-Josh

2009/12/15 Sevetson, Phil <[login to unmask email]<mailto:[login to unmask email]>>
Josh:
If you ever close an application bufferpool, you lose the ability to read all objects associated with that bufferpool. For that reason, I'd recommend putting the RTS spaces in the same BP you use for (other) system objects. For STOGROUPs, if you're recovering the system datasets, you'd want to recover the RTS objects to the same point. So, you're right; your system programmer is wrong on this.

--Phil Sevetson

________________________________
From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>] On Behalf Of DB2 DBA
Sent: Tuesday, December 15, 2009 11:49 AM

To: [login to unmask email]<mailto:[login to unmask email]>
Subject: Re: [DB2-L] RUNSTATS' Alternative?


Hello:

DB2 V7
z/OS 1.4

We have decided to install/deploy RTS in our shop. However, I realized that the sample DDL in DSN710.SDSNSAMP(DSNTESS) has storage-group as SYSDEFLT. I look at RTS as another catalog table and I think STOGROUP should be SYSDEFLT and BUFFERPOOL should also be the default one used for other catalog tables.

However, my system programmer suggests me that I should consider using the STOGROUP & BUFFERPOOL that are used for apps or associated with apps.

Can someone confirm if I am going in the right direction.

-Josh

Baba z wozu, koniom l¿ej
On Mon, Dec 7, 2009 at 12:15 PM, DB2 DBA <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Thanks Bala, that's plenty.


-Josh



On Mon, Dec 7, 2009 at 12:34 AM, DB2DBAzOS <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Hi Josh,

If you have not looked it up on internet yet, these are the links for those V7's PTFs.

http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+time+Statistics&uid=swg1PQ48448&loc=en_US&cs=utf-8&cc=us&lang=en

And, there are plenty of IBM docs that can be looked up at www.ibm.com/support < http://www.ibm.com/support > and IDUG presentations (available on IDUG website) that I referred while implementing RTS in my shop (v7 z/OS 1.4).

References.
http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27004021&loc=en_US&cs=utf-8&cc=us&lang=en

http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27005106&loc=en_US&cs=utf-8&cc=us&lang=en
On Fri, Dec 4, 2009 at 9:11 PM, DB2 DBA <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Bala - Wow! That sounds like a time-saver. Could you share the info on those PTFs? I would appreciate if you did it.



-Josh



On Fri, Dec 4, 2009 at 12:40 AM, DB2DBAzOS <[login to unmask email]<mailto:[login to unmask email]>> wrote:
DB2 v7 had/have the RTS through few PTFs.. Recently (we are still on v7 in one DB2 ), we applied those PTFs and considering having RTS ON as it has several benefits.

What has been change in DB2 v8 is that RTS is looked up by the IBM DB2 utilities (I think I am right here too). So, if RTS is there, IBM utilities would look upto RTS for sortkeys, dynamic sort file allocation etc..

With V9 , RTS objects are integrated into DB2 Catalog.. (Right here too ?)

Sometimes working on DB2 v7, v8 and v9 simultaneously confuses me

Regards,
Bala.
On Thu, Dec 3, 2009 at 2:18 AM, Dell'Anno, Aurora <[login to unmask email]<mailto:[login to unmask email]>> wrote:
errrr.... were you calling me Raymond? sorry sorry I was just round the corner ;-)

Josh,

my 0.0000002c worth: I assume you will have to move from V7 to V8 kind of soon - and when you get to V8 RTS are always collected, simply not externalised (at which point of course you will have all the overhead as part of the process anyway...) - incidentally a lot of DB2 customers are finding great reductions in their daily process once they move to V9 so maybe you can plan way ahead.

And yes, CA do offer an alternative to RUNSTATS so if you are interested please contact me offline, or your local friendly CA rep...


Thanks.

Aurora

Aurora Emanuela Dell'Anno
CA
Sr. Engineering Services Architect
Tel: +44 (0)1753 577 733
Mobile: +44 (0)7768 235 339
[login to unmask email]
<mailto:[login to unmask email]>

http://www.ca.com/

P please don't print this e-mail unless you really need to!



________________________________
From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>] On Behalf Of Bell, Raymond
Sent: 24 November 2009 08:42

To: [login to unmask email]<mailto:[login to unmask email]>
Subject: Re: [DB2-L] RUNSTATS' Alternative?
Hi Josh,

If you're still on DB2 V7 and z/OS 1.4 I suspect you have bigger issues than the CPU consumption of Runstats. To hopefully accurately summarise some of what Mr. Sevetson quite rightly said, easiest thing might be simply to not run Runstats quite so often. After all, as has been used in a number of contexts, the fastest [insert action being discussed] is no [insert action being discussed]. For those remaining objects that do need Runstats, and for which reducing the Runstats job CPU/elapsed time is important, yes I believe there's at least one ISV that has a Runstats offering.

Cheers,


Raymond

From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>] On Behalf Of DB2 DBA
Sent: 23 November 2009 18:36
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] RUNSTATS' Alternative?

Hello:

DB2 V7
z/OS 1.4

As we all are aware how resource consuming RUNSTATS is (particularly for large tables), is there any alternative for this with any of the vendors? Or is there a work around?

I am not only worried about the cost (don't blame me for this) but also the 'time'. The existing set up is to have RUNSTATS run on Sundays, when rest of the world 'sleeps'. THIS, usually takes around 4 hours. Now, it is being recommended that the set up be moved to the regular weekdays and try to 'fit it' in the maintenance window which is 2 hours. So, we are planning to split this RUNSTATS job and run it in two different days. However, if there is any delay for any reason, we would have to push it beyond our maintenance window. And this is where we might have problems with the resource consumption.

(Splitting it into 5 different days and running 'em Mon-Fri is ruled out as we planned for some other 'adjustments' during maintenance window for the first 3 days of the week. Well, it doesn't look like a maintenance window any longer...)

Any suggestions/ideas/recommendations are welcome!


-Josh

________________________________

[%20 ] < http://www.idug.org/ >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

________________________________

[%20 ] < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

________________________________

[%20 ] < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

________________________________

[%20 ] < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

________________________________

[%20 ] < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

________________________________

[%20 ] < http://www.idug.org/ >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >


________________________________

[%20 ] < http://www.idug.org/ >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

________________________________

[%20 ] < http://www.idug.org/ >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

________________________________

[ http://www.idug.org/images/M_images/idug%20org.jpg ] < http://www.idug.org >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-content/index.html has THOUSANDS of free technical presentations!
DB2 LUW, DB2 z/OS, Performance, Installation, Tuning, Coding, BI, Warehouses, - among
many more categories of help waiting for you!
Whether you are an old hand or a DB2 newbie, we have presentations for every level.
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Philip Sevetson

Re: RUNSTATS' Alternative?
(in response to Randy Bright)
Josh,

I defer to Randy on the second question, of course. And I agree with him on the first question.

The last place I worked at which had RTS turned on, found that three hours was a fine interval. I'd go thirty minutes, myself. Not much less.

--Phil

________________________________
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Bright, Randy
Sent: Tuesday, December 15, 2009 4:42 PM
To: [login to unmask email]
Subject: Re: [DB2-L] RUNSTATS' Alternative?

I'll answer the second half of your question first. The BMC Utilities update the RTS tables in much the same way as the IBM Utilities. There are some subtle differences because the BMC Utilities have some capabilities that differ from IBM so sometimes there isn't a "one-to-one" match between what the IBM utilities and the BMC Utilities do. But the end result should be the same. The RTS tables are maintained by the BMC Utilities.

Back on your first question. We have not seen any noticeable performance difference with RTS turned on. DB2, for the most part, keeps track of a lot of the information that is in the RTS tables anyway. The only additional overhead is that involved in actually updating the tables. As long as you don't get carried away with lowering the interval used to update these tables, you should not see any effect.

________________________________


Randy Bright
Solutions Architect
DB2 Utilities
BMC Software, Inc.

phone: 512-340-6014
cell: 512-656-0240

10431 Morado Circle
Austin, TX 78759

[ http://www.bmc.com/USA/Corporate/graphics/logo_with_tag1.gif ] < http://www.bmc.com >


________________________________
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of DB2 DBA
Sent: Tuesday, December 15, 2009 3:19 PM
To: [login to unmask email]
Subject: Re: [DB2-L] RUNSTATS' Alternative?


Phil,

Thanks for confirming my take on it, with an apt example. One more question, do you think there could be any ill-effect on the overall performance of DB2 due to the installation of RTS? As, this also works like RUNSTATS, as far as collecting statistics goes.

Also, how does RTS collect statistics of the tables that are loaded using BMC utilities that run outside of DB2?

-Josh
2009/12/15 Sevetson, Phil <[login to unmask email]<mailto:[login to unmask email]>>
Josh:
If you ever close an application bufferpool, you lose the ability to read all objects associated with that bufferpool. For that reason, I'd recommend putting the RTS spaces in the same BP you use for (other) system objects. For STOGROUPs, if you're recovering the system datasets, you'd want to recover the RTS objects to the same point. So, you're right; your system programmer is wrong on this.
--Phil Sevetson
________________________________
From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>] On Behalf Of DB2 DBA
Sent: Tuesday, December 15, 2009 11:49 AM

To: [login to unmask email]<mailto:[login to unmask email]>
Subject: Re: [DB2-L] RUNSTATS' Alternative?



Hello:

DB2 V7
z/OS 1.4

We have decided to install/deploy RTS in our shop. However, I realized that the sample DDL in DSN710.SDSNSAMP(DSNTESS) has storage-group as SYSDEFLT. I look at RTS as another catalog table and I think STOGROUP should be SYSDEFLT and BUFFERPOOL should also be the default one used for other catalog tables.

However, my system programmer suggests me that I should consider using the STOGROUP & BUFFERPOOL that are used for apps or associated with apps.

Can someone confirm if I am going in the right direction.

-Josh

Baba z wozu, koniom l¿ej
On Mon, Dec 7, 2009 at 12:15 PM, DB2 DBA <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Thanks Bala, that's plenty.
-Josh
On Mon, Dec 7, 2009 at 12:34 AM, DB2DBAzOS <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Hi Josh,
If you have not looked it up on internet yet, these are the links for those V7's PTFs.
http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+time+Statistics&uid=swg1PQ48448&loc=en_US&cs=utf-8&cc=us&lang=en
And, there are plenty of IBM docs that can be looked up at www.ibm.com/support < http://www.ibm.com/support > and IDUG presentations (available on IDUG website) that I referred while implementing RTS in my shop (v7 z/OS 1.4).
References.
http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27004021&loc=en_US&cs=utf-8&cc=us&lang=en
http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27005106&loc=en_US&cs=utf-8&cc=us&lang=en
On Fri, Dec 4, 2009 at 9:11 PM, DB2 DBA <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Bala - Wow! That sounds like a time-saver. Could you share the info on those PTFs? I would appreciate if you did it.
-Josh
On Fri, Dec 4, 2009 at 12:40 AM, DB2DBAzOS <[login to unmask email]<mailto:[login to unmask email]>> wrote:
DB2 v7 had/have the RTS through few PTFs.. Recently (we are still on v7 in one DB2 ), we applied those PTFs and considering having RTS ON as it has several benefits.
What has been change in DB2 v8 is that RTS is looked up by the IBM DB2 utilities (I think I am right here too). So, if RTS is there, IBM utilities would look upto RTS for sortkeys, dynamic sort file allocation etc..
With V9 , RTS objects are integrated into DB2 Catalog.. (Right here too ?)
Sometimes working on DB2 v7, v8 and v9 simultaneously confuses me
Regards,
Bala.
On Thu, Dec 3, 2009 at 2:18 AM, Dell'Anno, Aurora <[login to unmask email]<mailto:[login to unmask email]>> wrote:
errrr.... were you calling me Raymond? sorry sorry I was just round the corner ;-)
Josh,
my 0.0000002c worth: I assume you will have to move from V7 to V8 kind of soon - and when you get to V8 RTS are always collected, simply not externalised (at which point of course you will have all the overhead as part of the process anyway...) - incidentally a lot of DB2 customers are finding great reductions in their daily process once they move to V9 so maybe you can plan way ahead.
And yes, CA do offer an alternative to RUNSTATS so if you are interested please contact me offline, or your local friendly CA rep...

Thanks.

Aurora

Aurora Emanuela Dell'Anno
CA
Sr. Engineering Services Architect
Tel: +44 (0)1753 577 733
Mobile: +44 (0)7768 235 339
[login to unmask email]
<mailto:[login to unmask email]>

http://www.ca.com/

P please don't print this e-mail unless you really need to!

________________________________
From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>] On Behalf Of Bell, Raymond
Sent: 24 November 2009 08:42

To: [login to unmask email]<mailto:[login to unmask email]>
Subject: Re: [DB2-L] RUNSTATS' Alternative?
Hi Josh,
If you're still on DB2 V7 and z/OS 1.4 I suspect you have bigger issues than the CPU consumption of Runstats. To hopefully accurately summarise some of what Mr. Sevetson quite rightly said, easiest thing might be simply to not run Runstats quite so often. After all, as has been used in a number of contexts, the fastest [insert action being discussed] is no [insert action being discussed]. For those remaining objects that do need Runstats, and for which reducing the Runstats job CPU/elapsed time is important, yes I believe there's at least one ISV that has a Runstats offering.
Cheers,
Raymond

From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>] On Behalf Of DB2 DBA
Sent: 23 November 2009 18:36
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] RUNSTATS' Alternative?
Hello:
DB2 V7
z/OS 1.4
As we all are aware how resource consuming RUNSTATS is (particularly for large tables), is there any alternative for this with any of the vendors? Or is there a work around?
I am not only worried about the cost (don't blame me for this) but also the 'time'. The existing set up is to have RUNSTATS run on Sundays, when rest of the world 'sleeps'. THIS, usually takes around 4 hours. Now, it is being recommended that the set up be moved to the regular weekdays and try to 'fit it' in the maintenance window which is 2 hours. So, we are planning to split this RUNSTATS job and run it in two different days. However, if there is any delay for any reason, we would have to push it beyond our maintenance window. And this is where we might have problems with the resource consumption.
(Splitting it into 5 different days and running 'em Mon-Fri is ruled out as we planned for some other 'adjustments' during maintenance window for the first 3 days of the week. Well, it doesn't look like a maintenance window any longer...)
Any suggestions/ideas/recommendations are welcome!

-Josh


________________________________

[ http://www.idug.org/images/M_images/idug%20org.jpg ] < http://www.idug.org >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-content/index.html has THOUSANDS of free technical presentations!
DB2 LUW, DB2 z/OS, Performance, Installation, Tuning, Coding, BI, Warehouses, - among
many more categories of help waiting for you!
Whether you are an old hand or a DB2 newbie, we have presentations for every level.
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Cathy Taddei

Re: RUNSTATS' Alternative?
(in response to Philip Sevetson)
V7, eh?

Phil and Josh, I agree with you that the RTS tables may as well utilize BP0, because in DB2 9 they will be moved to the catalog (DSNDB06). What I am unclear on is the concern about sharing bufferpools and stogroups with applications -- how do you "close" a bufferpool and why would you do it? For me, the criteria for which bufferpool to use would be the type and level of activity on the tablespaces being compatible with other users of the bufferpool; the stogroup only matters in terms of DASD management. That said, when I implemented RTS back in V7, I did use BP0. I don't think Josh's systems programmer is necessarily wrong, but s/he might do better by upgrading DB2 than by finding ways to tweak the installation jobs.

Cathy

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Sevetson, Phil
Sent: Tuesday, December 15, 2009 9:18 AM
To: [login to unmask email]
Subject: Re: [DB2-L] RUNSTATS' Alternative?

Josh:
If you ever close an application bufferpool, you lose the ability to read all objects associated with that bufferpool. For that reason, I'd recommend putting the RTS spaces in the same BP you use for (other) system objects. For STOGROUPs, if you're recovering the system datasets, you'd want to recover the RTS objects to the same point. So, you're right; your system programmer is wrong on this.

--Phil Sevetson

________________________________
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of DB2 DBA
Sent: Tuesday, December 15, 2009 11:49 AM
To: [login to unmask email]
Subject: Re: [DB2-L] RUNSTATS' Alternative?


Hello:

DB2 V7
z/OS 1.4

We have decided to install/deploy RTS in our shop. However, I realized that the sample DDL in DSN710.SDSNSAMP(DSNTESS) has storage-group as SYSDEFLT. I look at RTS as another catalog table and I think STOGROUP should be SYSDEFLT and BUFFERPOOL should also be the default one used for other catalog tables.

However, my system programmer suggests me that I should consider using the STOGROUP & BUFFERPOOL that are used for apps or associated with apps.

Can someone confirm if I am going in the right direction.

-Josh

Baba z wozu, koniom l¿ej
On Mon, Dec 7, 2009 at 12:15 PM, DB2 DBA <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Thanks Bala, that's plenty.


-Josh



On Mon, Dec 7, 2009 at 12:34 AM, DB2DBAzOS <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Hi Josh,

If you have not looked it up on internet yet, these are the links for those V7's PTFs.

http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+time+Statistics&uid=swg1PQ48448&loc=en_US&cs=utf-8&cc=us&lang=en

And, there are plenty of IBM docs that can be looked up at www.ibm.com/support < http://www.ibm.com/support > and IDUG presentations (available on IDUG website) that I referred while implementing RTS in my shop (v7 z/OS 1.4).

References.
http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27004021&loc=en_US&cs=utf-8&cc=us&lang=en

http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27005106&loc=en_US&cs=utf-8&cc=us&lang=en
On Fri, Dec 4, 2009 at 9:11 PM, DB2 DBA <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Bala - Wow! That sounds like a time-saver. Could you share the info on those PTFs? I would appreciate if you did it.



-Josh



On Fri, Dec 4, 2009 at 12:40 AM, DB2DBAzOS <[login to unmask email]<mailto:[login to unmask email]>> wrote:
DB2 v7 had/have the RTS through few PTFs.. Recently (we are still on v7 in one DB2 ), we applied those PTFs and considering having RTS ON as it has several benefits.

What has been change in DB2 v8 is that RTS is looked up by the IBM DB2 utilities (I think I am right here too). So, if RTS is there, IBM utilities would look upto RTS for sortkeys, dynamic sort file allocation etc..

With V9 , RTS objects are integrated into DB2 Catalog.. (Right here too ?)

Sometimes working on DB2 v7, v8 and v9 simultaneously confuses me

Regards,
Bala.
On Thu, Dec 3, 2009 at 2:18 AM, Dell'Anno, Aurora <[login to unmask email]<mailto:[login to unmask email]>> wrote:
errrr.... were you calling me Raymond? sorry sorry I was just round the corner ;-)

Josh,

my 0.0000002c worth: I assume you will have to move from V7 to V8 kind of soon - and when you get to V8 RTS are always collected, simply not externalised (at which point of course you will have all the overhead as part of the process anyway...) - incidentally a lot of DB2 customers are finding great reductions in their daily process once they move to V9 so maybe you can plan way ahead.

And yes, CA do offer an alternative to RUNSTATS so if you are interested please contact me offline, or your local friendly CA rep...


Thanks.

Aurora

Aurora Emanuela Dell'Anno
CA
Sr. Engineering Services Architect
Tel: +44 (0)1753 577 733
Mobile: +44 (0)7768 235 339
[login to unmask email]
<mailto:[login to unmask email]>

http://www.ca.com/

P please don't print this e-mail unless you really need to!



________________________________
From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>] On Behalf Of Bell, Raymond
Sent: 24 November 2009 08:42

To: [login to unmask email]<mailto:[login to unmask email]>
Subject: Re: [DB2-L] RUNSTATS' Alternative?
Hi Josh,

If you're still on DB2 V7 and z/OS 1.4 I suspect you have bigger issues than the CPU consumption of Runstats. To hopefully accurately summarise some of what Mr. Sevetson quite rightly said, easiest thing might be simply to not run Runstats quite so often. After all, as has been used in a number of contexts, the fastest [insert action being discussed] is no [insert action being discussed]. For those remaining objects that do need Runstats, and for which reducing the Runstats job CPU/elapsed time is important, yes I believe there's at least one ISV that has a Runstats offering.

Cheers,


Raymond

From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>] On Behalf Of DB2 DBA
Sent: 23 November 2009 18:36
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] RUNSTATS' Alternative?

Hello:

DB2 V7
z/OS 1.4

As we all are aware how resource consuming RUNSTATS is (particularly for large tables), is there any alternative for this with any of the vendors? Or is there a work around?

I am not only worried about the cost (don't blame me for this) but also the 'time'. The existing set up is to have RUNSTATS run on Sundays, when rest of the world 'sleeps'. THIS, usually takes around 4 hours. Now, it is being recommended that the set up be moved to the regular weekdays and try to 'fit it' in the maintenance window which is 2 hours. So, we are planning to split this RUNSTATS job and run it in two different days. However, if there is any delay for any reason, we would have to push it beyond our maintenance window. And this is where we might have problems with the resource consumption.

(Splitting it into 5 different days and running 'em Mon-Fri is ruled out as we planned for some other 'adjustments' during maintenance window for the first 3 days of the week. Well, it doesn't look like a maintenance window any longer...)

Any suggestions/ideas/recommendations are welcome!


-Josh

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

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 North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/solutions-journal.html - home of the IDUG Solutions Journal
Technical atricles from world famous authors in DB2's most prestigious, peer reviewed
magazine now on-line!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Philip Sevetson

Re: RUNSTATS' Alternative?
(in response to Cathy Taddei)
Cathy,
I was, perhaps, imprecise with the term "close" for bufferpools. In cases where systems managers are dealing with limited amounts of real memory, it is sometimes expedient to reduce the size of bufferpools assigned to daytime applications to leave more space for overnight processing, and vice versa. I'm told that some companies use this strategy, though I haven't worked at one which does.

Also on point, though not previously mentioned; if you have application-specific bufferpools in V7, and your application goes quiescent, any paging your OS does is going to eventually strike the quiescent bufferpools. If your RTS spaces are assigned to such a bufferpool, you will experience OS page retrieval delays for that pool, as well as whatever costs there may be to read the RTS pages back into the newly-reloaded bufferpool pages. This need not be large if the system is not incredibly busy, but why take the chance? A system-objects bufferpool is much less likely to be paged out.

--Phil

________________________________
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Taddei, Cathy
Sent: Tuesday, December 15, 2009 7:09 PM
To: [login to unmask email]
Subject: Re: [DB2-L] RUNSTATS' Alternative?

V7, eh?

Phil and Josh, I agree with you that the RTS tables may as well utilize BP0, because in DB2 9 they will be moved to the catalog (DSNDB06). What I am unclear on is the concern about sharing bufferpools and stogroups with applications -- how do you "close" a bufferpool and why would you do it? For me, the criteria for which bufferpool to use would be the type and level of activity on the tablespaces being compatible with other users of the bufferpool; the stogroup only matters in terms of DASD management. That said, when I implemented RTS back in V7, I did use BP0. I don't think Josh's systems programmer is necessarily wrong, but s/he might do better by upgrading DB2 than by finding ways to tweak the installation jobs.

Cathy

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Sevetson, Phil
Sent: Tuesday, December 15, 2009 9:18 AM
To: [login to unmask email]
Subject: Re: [DB2-L] RUNSTATS' Alternative?

Josh:
If you ever close an application bufferpool, you lose the ability to read all objects associated with that bufferpool. For that reason, I'd recommend putting the RTS spaces in the same BP you use for (other) system objects. For STOGROUPs, if you're recovering the system datasets, you'd want to recover the RTS objects to the same point. So, you're right; your system programmer is wrong on this.

--Phil Sevetson

________________________________
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of DB2 DBA
Sent: Tuesday, December 15, 2009 11:49 AM
To: [login to unmask email]
Subject: Re: [DB2-L] RUNSTATS' Alternative?


Hello:

DB2 V7
z/OS 1.4

We have decided to install/deploy RTS in our shop. However, I realized that the sample DDL in DSN710.SDSNSAMP(DSNTESS) has storage-group as SYSDEFLT. I look at RTS as another catalog table and I think STOGROUP should be SYSDEFLT and BUFFERPOOL should also be the default one used for other catalog tables.

However, my system programmer suggests me that I should consider using the STOGROUP & BUFFERPOOL that are used for apps or associated with apps.

Can someone confirm if I am going in the right direction.

-Josh

Baba z wozu, koniom l¿ej
On Mon, Dec 7, 2009 at 12:15 PM, DB2 DBA <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Thanks Bala, that's plenty.


-Josh



On Mon, Dec 7, 2009 at 12:34 AM, DB2DBAzOS <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Hi Josh,

If you have not looked it up on internet yet, these are the links for those V7's PTFs.

http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+time+Statistics&uid=swg1PQ48448&loc=en_US&cs=utf-8&cc=us&lang=en

And, there are plenty of IBM docs that can be looked up at www.ibm.com/support < http://www.ibm.com/support > and IDUG presentations (available on IDUG website) that I referred while implementing RTS in my shop (v7 z/OS 1.4).

References.
http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27004021&loc=en_US&cs=utf-8&cc=us&lang=en

http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27005106&loc=en_US&cs=utf-8&cc=us&lang=en
On Fri, Dec 4, 2009 at 9:11 PM, DB2 DBA <[login to unmask email]<mailto:[login to unmask email]>> wrote:
Bala - Wow! That sounds like a time-saver. Could you share the info on those PTFs? I would appreciate if you did it.



-Josh



On Fri, Dec 4, 2009 at 12:40 AM, DB2DBAzOS <[login to unmask email]<mailto:[login to unmask email]>> wrote:
DB2 v7 had/have the RTS through few PTFs.. Recently (we are still on v7 in one DB2 ), we applied those PTFs and considering having RTS ON as it has several benefits.

What has been change in DB2 v8 is that RTS is looked up by the IBM DB2 utilities (I think I am right here too). So, if RTS is there, IBM utilities would look upto RTS for sortkeys, dynamic sort file allocation etc..

With V9 , RTS objects are integrated into DB2 Catalog.. (Right here too ?)

Sometimes working on DB2 v7, v8 and v9 simultaneously confuses me

Regards,
Bala.
On Thu, Dec 3, 2009 at 2:18 AM, Dell'Anno, Aurora <[login to unmask email]<mailto:[login to unmask email]>> wrote:
errrr.... were you calling me Raymond? sorry sorry I was just round the corner ;-)

Josh,

my 0.0000002c worth: I assume you will have to move from V7 to V8 kind of soon - and when you get to V8 RTS are always collected, simply not externalised (at which point of course you will have all the overhead as part of the process anyway...) - incidentally a lot of DB2 customers are finding great reductions in their daily process once they move to V9 so maybe you can plan way ahead.

And yes, CA do offer an alternative to RUNSTATS so if you are interested please contact me offline, or your local friendly CA rep...


Thanks.

Aurora

Aurora Emanuela Dell'Anno
CA
Sr. Engineering Services Architect
Tel: +44 (0)1753 577 733
Mobile: +44 (0)7768 235 339
[login to unmask email]
<mailto:[login to unmask email]>

http://www.ca.com/

P please don't print this e-mail unless you really need to!



________________________________
From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>] On Behalf Of Bell, Raymond
Sent: 24 November 2009 08:42

To: [login to unmask email]<mailto:[login to unmask email]>
Subject: Re: [DB2-L] RUNSTATS' Alternative?
Hi Josh,

If you're still on DB2 V7 and z/OS 1.4 I suspect you have bigger issues than the CPU consumption of Runstats. To hopefully accurately summarise some of what Mr. Sevetson quite rightly said, easiest thing might be simply to not run Runstats quite so often. After all, as has been used in a number of contexts, the fastest [insert action being discussed] is no [insert action being discussed]. For those remaining objects that do need Runstats, and for which reducing the Runstats job CPU/elapsed time is important, yes I believe there's at least one ISV that has a Runstats offering.

Cheers,


Raymond

From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>] On Behalf Of DB2 DBA
Sent: 23 November 2009 18:36
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] RUNSTATS' Alternative?

Hello:

DB2 V7
z/OS 1.4

As we all are aware how resource consuming RUNSTATS is (particularly for large tables), is there any alternative for this with any of the vendors? Or is there a work around?

I am not only worried about the cost (don't blame me for this) but also the 'time'. The existing set up is to have RUNSTATS run on Sundays, when rest of the world 'sleeps'. THIS, usually takes around 4 hours. Now, it is being recommended that the set up be moved to the regular weekdays and try to 'fit it' in the maintenance window which is 2 hours. So, we are planning to split this RUNSTATS job and run it in two different days. However, if there is any delay for any reason, we would have to push it beyond our maintenance window. And this is where we might have problems with the resource consumption.

(Splitting it into 5 different days and running 'em Mon-Fri is ruled out as we planned for some other 'adjustments' during maintenance window for the first 3 days of the week. Well, it doesn't look like a maintenance window any longer...)

Any suggestions/ideas/recommendations are welcome!


-Josh

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



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.



======

________________________________

[ http://www.idug.org/images/M_images/idug%20na3.jpg ] < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/solutions-journal.html - home of the IDUG Solutions Journal
Technical atricles from world famous authors in DB2's most prestigious, peer reviewed
magazine now on-line!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

DB2 DBA

Re: RUNSTATS' Alternative?
(in response to Philip Sevetson)
Phil, Randy & Cathy - Thank you all for the help. I just enabled the RTS
environment. It is 30 mins (which is default) interval for now. I shall wait
and see, if there's any 'ill-effect' on the performance, to decide whether
or not to increase the interval. However, I feel there shouldn't be any, if
I understand you all and the manuals correctly.


-Josh



2009/12/16 Sevetson, Phil <[login to unmask email]>

> Cathy,
>
> I was, perhaps, imprecise with the term "close" for bufferpools. In cases
> where systems managers are dealing with limited amounts of real memory, it
> is sometimes expedient to reduce the size of bufferpools assigned to daytime
> applications to leave more space for overnight processing, and vice versa.
> I'm told that some companies use this strategy, though I haven't worked at
> one which does.
>
>
>
> Also on point, though not previously mentioned; if you have
> application-specific bufferpools in V7, and your application goes quiescent,
> any paging your OS does is going to eventually strike the quiescent
> bufferpools. If your RTS spaces are assigned to such a bufferpool, you will
> experience OS page retrieval delays for that pool, as well as whatever costs
> there may be to read the RTS pages back into the newly-reloaded bufferpool
> pages. This need not be large if the system is not incredibly busy, but why
> take the chance? A system-objects bufferpool is much less likely to be
> paged out.
>
>
>
> --Phil
>
>
> ------------------------------
>
> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *Taddei,
> Cathy
> *Sent:* Tuesday, December 15, 2009 7:09 PM
>
> *To:* [login to unmask email]
> *Subject:* Re: [DB2-L] RUNSTATS' Alternative?
>
>
>
> V7, eh?
>
>
>
> Phil and Josh, I agree with you that the RTS tables may as well utilize
> BP0, because in DB2 9 they will be moved to the catalog (DSNDB06). What I
> am unclear on is the concern about sharing bufferpools and stogroups with
> applications -- how do you "close" a bufferpool and why would you do it?
> For me, the criteria for which bufferpool to use would be the type and level
> of activity on the tablespaces being compatible with other users of the
> bufferpool; the stogroup only matters in terms of DASD management. That
> said, when I implemented RTS back in V7, I did use BP0. I don't think
> Josh's systems programmer is necessarily wrong, but s/he might do better by
> upgrading DB2 than by finding ways to tweak the installation jobs.
>
>
>
> Cathy
>
>
>
> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *Sevetson,
> Phil
> *Sent:* Tuesday, December 15, 2009 9:18 AM
> *To:* [login to unmask email]
> *Subject:* Re: [DB2-L] RUNSTATS' Alternative?
>
>
>
> Josh:
>
> If you ever close an application bufferpool, you lose the ability to read
> all objects associated with that bufferpool. For that reason, I'd recommend
> putting the RTS spaces in the same BP you use for (other) system objects.
> For STOGROUPs, if you're recovering the system datasets, you'd want to
> recover the RTS objects to the same point. So, you're right; your system
> programmer is wrong on this.
>
>
>
> --Phil Sevetson
>
>
> ------------------------------
>
> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *DB2 DBA
> *Sent:* Tuesday, December 15, 2009 11:49 AM
> *To:* [login to unmask email]
> *Subject:* Re: [DB2-L] RUNSTATS' Alternative?
>
>
>
> Hello:
>
> DB2 V7
> z/OS 1.4
>
> We have decided to install/deploy RTS in our shop. However, I realized that
> the sample DDL in DSN710.SDSNSAMP(DSNTESS) has storage-group as SYSDEFLT. I
> look at RTS as another catalog table and I think STOGROUP should be SYSDEFLT
> and BUFFERPOOL should also be the default one used for other catalog tables.
>
> However, my system programmer suggests me that I should consider using the
> STOGROUP & BUFFERPOOL that are used for apps or associated with apps.
>
> Can someone confirm if I am going in the right direction.
>
>
> -Josh
>
> Baba z wozu, koniom l¿ej
>
> On Mon, Dec 7, 2009 at 12:15 PM, DB2 DBA <[login to unmask email]> wrote:
>
> Thanks Bala, that's plenty.
>
>
>
>
>
> -Josh
>
>
>
>
>
> On Mon, Dec 7, 2009 at 12:34 AM, DB2DBAzOS <[login to unmask email]> wrote:
>
> Hi Josh,
>
>
>
> If you have not looked it up on internet yet, these are the links for those
> V7's PTFs.
>
>
>
>
> http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+time+Statistics&uid=swg1PQ48448&loc=en_US&cs=utf-8&cc=us&lang=en
>
>
>
> And, there are plenty of IBM docs that can be looked up at
> www.ibm.com/support and IDUG presentations (available on IDUG website)
> that I referred while implementing RTS in my shop (v7 z/OS 1.4).
>
>
>
> References.
>
>
> http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27004021&loc=en_US&cs=utf-8&cc=us&lang=en
>
>
>
>
> http://www-01.ibm.com/support/docview.wss?rs=0&q1=Real+Time+Statistics&uid=swg27005106&loc=en_US&cs=utf-8&cc=us&lang=en
>
> On Fri, Dec 4, 2009 at 9:11 PM, DB2 DBA <[login to unmask email]> wrote:
>
> Bala - Wow! That sounds like a time-saver. Could you share the info on
> those PTFs? I would appreciate if you did it.
>
>
>
>
>
>
>
> -Josh
>
>
>
>
>
> On Fri, Dec 4, 2009 at 12:40 AM, DB2DBAzOS <[login to unmask email]> wrote:
>
> DB2 v7 had/have the RTS through few PTFs.. Recently (we are still on v7
> in one DB2 ), we applied those PTFs and considering having RTS ON as it has
> several benefits.
>
>
>
> What has been change in DB2 v8 is that RTS is looked up by the IBM DB2
> utilities (I think I am right here too). So, if RTS is there, IBM utilities
> would look upto RTS for sortkeys, dynamic sort file allocation etc..
>
>
>
> With V9 , RTS objects are integrated into DB2 Catalog.. (Right here too ?)
>
>
>
> Sometimes working on DB2 v7, v8 and v9 simultaneously confuses me
>
>
>
> Regards,
>
> Bala.
>
> On Thu, Dec 3, 2009 at 2:18 AM, Dell'Anno, Aurora <[login to unmask email]>
> wrote:
>
> errrr.... were you calling me Raymond? sorry sorry I was just round the
> corner ;-)
>
>
>
> Josh,
>
>
>
> my 0.0000002c worth: I assume you will have to move from V7 to V8 kind of
> soon - and when you get to V8 RTS are always collected, simply not
> externalised (at which point of course you will have all the overhead as
> part of the process anyway...) - incidentally a lot of DB2 customers are
> finding great reductions in their daily process once they move to V9 so
> maybe you can plan way ahead.
>
>
>
> And yes, CA do offer an alternative to RUNSTATS so if you are interested
> please contact me offline, or your local friendly CA rep...
>
>
>
> Thanks.
>
> Aurora
>
> *Aurora Emanuela Dell'Anno*
>
> CA
> Sr. Engineering Services Architect
>
> Tel: +44 (0)1753 577 733
> Mobile: +44 (0)7768 235 339
> [login to unmask email]
>
> http://www.ca.com/
>
> P please don't print this e-mail unless you really need to!
>
>
>
>
>
>
> ------------------------------
>
> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *Bell,
> Raymond
> *Sent:* 24 November 2009 08:42
>
>
> *To:* [login to unmask email]
>
> *Subject:* Re: [DB2-L] RUNSTATS' Alternative?
>
> Hi Josh,
>
>
>
> If you're still on DB2 V7 and z/OS 1.4 I suspect you have bigger issues
> than the CPU consumption of Runstats. To hopefully accurately summarise
> some of what Mr. Sevetson quite rightly said, easiest thing might be simply
> to not run Runstats quite so often. After all, as has been used in a number
> of contexts, the fastest [insert action being discussed] is no [insert
> action being discussed]. For those remaining objects that do need Runstats,
> and for which reducing the Runstats job CPU/elapsed time is important, yes I
> believe there's at least one ISV that has a Runstats offering.
>
>
>
> Cheers,
>
>
>
>
>
> Raymond
>
>
>
> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *DB2 DBA
> *Sent:* 23 November 2009 18:36
> *To:* [login to unmask email]
> *Subject:* [DB2-L] RUNSTATS' Alternative?
>
>
>
> Hello:
>
>
>
> DB2 V7
>
> z/OS 1.4
>
>
>
> As we all are aware how resource consuming RUNSTATS is (particularly for
> large tables), is there any alternative for this with any of the vendors? Or
> is there a work around?
>
>
>
> I am not only worried about the cost (don't blame me for this) but also the
> 'time'. The existing set up is to have RUNSTATS run on Sundays, when rest of
> the world 'sleeps'. THIS, usually takes around 4 hours. Now, it is being
> recommended that the set up be moved to the regular weekdays and try to 'fit
> it' in the maintenance window which is 2 hours. So, we are planning to split
> this RUNSTATS job and run it in two different days. However, if there is any
> delay for any reason, we would have to push it beyond our maintenance
> window. And this is where we might have problems with the resource
> consumption.
>
>
>
> (Splitting it into 5 different days and running 'em Mon-Fri is ruled out as
> we planned for some other 'adjustments' during maintenance window for the
> first 3 days of the week. Well, it doesn't look like a maintenance window
> any longer...)
>
>
>
> Any suggestions/ideas/recommendations are welcome!
>
>
>
>
>
> -Josh
>
> ------------------------------------------------------------------------------
>
>
>
> 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.
>
>
>
> ======
>
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/solutions-journal.html - home of the IDUG Solutions Journal
Technical atricles from world famous authors in DB2's most prestigious, peer reviewed
magazine now on-line!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L