PRE-Loading EDM ??

Daniel Sullivan

PRE-Loading EDM ??
Hello,
When we bring DB2 down for whatever reason and bring
it back up again, first time through for anything takes
forever until the EDM buffers get loaded. After that
the plans, the programs, the BDB's, the table spaces,
the indexes and so on are a lot faster and I understand
this. But my question is, is there any way of loading
the EDM buffers ahead of time in order to save time such
as maybe loading the DBD's as step right after DB2 comes
back up? This is a PeopleSoft-DB2 application and is
running on z/OS. We might also look into running sum
dummy transactions, such as pocalc or pocreate, right
after start up to have them load all their table spaces
and indexes rather than wait for the 1st user to come in
and have to wait on their transaction to do this. Also
would look into whatever other transactions if possible
to this to. Will look into compression at the table
space level too. Is there anything DB2 wise that I
could be doing to help alleviate this too? I don't mean
fully load them but to see if ANYTHING could be preloaded
such as maybe the BDB's??
Thanks, Dan


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Pete Woodman

Re: PRE-Loading EDM ??
(in response to Daniel Sullivan)
You could pre-load the DBDs by doing a -DISPLAY DB(xxxx) command, probably
best doing it in batch.


Pete Woodman

Production DBA Team,
Database Design & Support,
Infrastructure Support,
Information Technology Outsourcing EMEA,
EDS.

TEL: 01253 688084 (external) 88084 (internal)
EMAIL: [login to unmask email]

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]On Behalf Of
Daniel Sullivan
Sent: 24 December 2003 11:07
To: [login to unmask email]
Subject: PRE-Loading EDM ??


Hello,
When we bring DB2 down for whatever reason and bring
it back up again, first time through for anything takes
forever until the EDM buffers get loaded. After that
the plans, the programs, the BDB's, the table spaces,
the indexes and so on are a lot faster and I understand
this. But my question is, is there any way of loading
the EDM buffers ahead of time in order to save time such
as maybe loading the DBD's as step right after DB2 comes
back up? This is a PeopleSoft-DB2 application and is
running on z/OS. We might also look into running sum
dummy transactions, such as pocalc or pocreate, right
after start up to have them load all their table spaces
and indexes rather than wait for the 1st user to come in
and have to wait on their transaction to do this. Also
would look into whatever other transactions if possible
to this to. Will look into compression at the table
space level too. Is there anything DB2 wise that I
could be doing to help alleviate this too? I don't mean
fully load them but to see if ANYTHING could be preloaded
such as maybe the BDB's??
Thanks, Dan

----------------------------------------------------------------------------
----- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select "Join or Leave the list". If you will be out of the office, send the
SET DB2-L NO MAIL command to [login to unmask email] The IDUG List
Admins can be reached at [login to unmask email] Find out the
latest on IDUG conferences at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Pete Woodman

Re: PRE-Loading EDM ??
(in response to Pete Woodman)
Could you not do a -DISPLAY DB(xxxx) SPACE(*) LIMIT(20000)? Probably best
running it in batch.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Daniel Sullivan

Re: PRE-Loading EDM ??
(in response to Avram Friedman)
Thanks Pete!! I'll give it a try!!


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Avram Friedman

Re: PRE-Loading EDM ??
(in response to Pete Woodman)
While I am sure it is true that you are observing slow opening of the
EDM pool, it is probally infact something else that is causing poor
performance at start up. If I had 25 extra cents and were a betting man
I would put my money on database dataset open. VSAM open can be timed
sucessfully on a wrist watch without a second hand!!! Can you speed
this up? Not really, who could consider having schedule schedule
fakework in response to the DB2 ready message but it is usually not
worth it. One technique that works is leaving DB2 up.

I think the people who suggest a -DIS DB are correct ... this may load
the DBDs into the EDM pool but once again it is unlikly loading the DBDs
is the problem. Its opening the datasets ... loading the DBD's does not
do that.

Besides for databases there are a lot of other things in the EDM pool
that take time to establish. Just like the databases initial 1 time
establishiment in the EDM pool, when referenced is unlikly to be an
observable performace problem.

Some of the other objects are
Skelton cursor tables
Dynamic Statement Cache
etc

Daniel Sullivan wrote:

> Hello, When we bring DB2 down for whatever reason and bringit back
> up again, first time through for anything takesforever until the EDM
> buffers get loaded. After thatthe plans, the programs, the BDB's, the
> table spaces,the indexes and so on are a lot faster and I
> understandthis. But my question is, is there any way of loadingthe
> EDM buffers ahead of time in order to save time suchas maybe loading
> the DBD's as step right after DB2 comesback up? This is a
> PeopleSoft-DB2 application and isrunning on z/OS. We might also look
> into running sumdummy transactions, such as pocalc or pocreate,
> rightafter start up to have them load all their table spacesand
> indexes rather than wait for the 1st user to come inand have to wait
> on their transaction to do this. Alsowould look into whatever other
> transactions if possibleto this to. Will look into compression at the
> tablespace level too. Is there anything DB2 wise that Icould be doing
> to help alleviate this too? I don't meanfully load them but to see if
> ANYTHING could be preloadedsuch as maybe the
> BDB's?? Thanks,
> Dan ---------------------------------------------------------------------------------
> Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
> home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
> page select "Join or Leave the list". If you will be out of the
> office, send the SET DB2-L NO MAIL command to
> [login to unmask email] The IDUG List Admins can be reached at
> [login to unmask email] Find out the latest on IDUG
> conferences at http://conferences.idug.org/index.cfm

--
NOTICE: If received in error, please destroy and notify sender. Sender
does not waive confidentiality or privilege, and use is prohibited.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Roger Miller

Re: PRE-Loading EDM ??
(in response to Daniel Sullivan)
There are some huge differences in various shops for the time to open data
sets. The key techniques are tuning for the VSAM catalog and caching the
VSAM catalog in memory, rather than reading from disk all the time. There
is also a big difference between the slowest, most overloaded disks and
the best performing disks in most shops. Another important part is making
parallelism for the open work. We published a benchmark in V7 showing the
difference for parallelism of the parts within a table space, with about 4
seconds for 200 partition opens in V6 and 2 seconds for the same opens in
V7. See the redbook, SG24-6129, section 4.2 Parallel data set open for
more.

Some other sources for slower times at startup include dynamic statement
cache, buffer pools, compression dictionaries, ...

Roger Miller

On Wed, 24 Dec 2003 09:14:18 -0500, Avram Friedman
<[login to unmask email]> wrote:

>While I am sure it is true that you are observing slow opening of the
>EDM pool, it is probally infact something else that is causing poor
>performance at start up. If I had 25 extra cents and were a betting man
>I would put my money on database dataset open. VSAM open can be timed
>sucessfully on a wrist watch without a second hand!!! Can you speed
>this up? Not really, who could consider having schedule schedule
>fakework in response to the DB2 ready message but it is usually not
>worth it. One technique that works is leaving DB2 up.
>
>I think the people who suggest a -DIS DB are correct ... this may load
>the DBDs into the EDM pool but once again it is unlikly loading the DBDs
>is the problem. Its opening the datasets ... loading the DBD's does not
>do that.
>
>Besides for databases there are a lot of other things in the EDM pool
>that take time to establish. Just like the databases initial 1 time
>establishiment in the EDM pool, when referenced is unlikly to be an
>observable performace problem.
>
>Some of the other objects are
>Skelton cursor tables
>Dynamic Statement Cache
>etc
>
>Daniel Sullivan wrote:
>
>> Hello, When we bring DB2 down for whatever reason and bringit back
>> up again, first time through for anything takesforever until the EDM
>> buffers get loaded. After thatthe plans, the programs, the BDB's, the
>> table spaces,the indexes and so on are a lot faster and I
>> understandthis. But my question is, is there any way of loadingthe
>> EDM buffers ahead of time in order to save time suchas maybe loading
>> the DBD's as step right after DB2 comesback up? This is a
>> PeopleSoft-DB2 application and isrunning on z/OS. We might also look
>> into running sumdummy transactions, such as pocalc or pocreate,
>> rightafter start up to have them load all their table spacesand
>> indexes rather than wait for the 1st user to come inand have to wait
>> on their transaction to do this. Alsowould look into whatever other
>> transactions if possibleto this to. Will look into compression at the
>> tablespace level too. Is there anything DB2 wise that Icould be doing
>> to help alleviate this too? I don't meanfully load them but to see if
>> ANYTHING could be preloadedsuch as maybe the
>> BDB's?? Thanks,
>> Dan

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm