Image copy compression question

Tim Hare

Image copy compression question

We've noticed that our image copy jobs consume quite a bit of CPU when they run.  We write to TMM (Tape Mount Management) disk via SMS,  and the output datasets are currently compressed with SMS compression. We don't have zEDC.  Here's our question though:   are we decompressing the DB2 data when the utility reads it in, only to compress it when we write it? 

James Campbell

Image copy compression question
(in response to Tim Hare)
The individual pages (which contain, I presume, compressed rows) will be written by Db2
without decompression / recompresion.

The problem you are getting is because the compressed rows mean that the pages seem to
be, to an observer outside of Db2, comprised of fairly random data. So when SMS tries to
further compress the entire page it spends a lot of time to get not much further compression.
(There will be some compression because, for example, binary zeros in holes in the page,
can be compressed.)

James Campbell

On 15 May 2019 at 22:11, Tim Hare wrote:

>
> We've noticed that our image copy jobs consume quite a bit of CPU when they run.  We write to
> TMM (Tape Mount Management) disk via SMS,  and the output datasets are currently
> compressed with SMS compression. We don't have zEDC.  Here's our question though:   are we
> decompressing the DB2 data when the utility reads it in, only to compress it when we write it? 
>
>

---
This email has been checked for viruses by AVG.
https://www.avg.com

Tim Hare

RE: Image copy compression question
(in response to James Campbell)

Do you have a reference to a point in a manual or somewhere from IBM I can point to so the SMS administators will not balk at removing compression from the output?

Tim Hare

RE: Image copy compression question
(in response to Tim Hare)

Never mind - I found it at  this page

(I was guilty of not going far enough down the tree my search results)

Phil Grainger

Image copy compression question
(in response to Tim Hare)
May not apply, but do I remember reading somewhere that using tape compression on ARCHIVE LOGS can result in Db2 not being able to read them backwards?

If this is still true, might be something else to check with your storage admins!

Phil Grainger
Principal Enablement Manager

[BMC Exchange 2019 - Global Event Series - REGISTER] https://www.bmc.com/ami

Direct

+44 1189 218 000

Mobile

+44 7808 643 479

Email

[login to unmask email]

E2, Eskdale Road
Winnersh
Berkshire
United Kingdom
RG41 5TS
[image001 (002)][https://acclaim-production-app.s3.amazonaws.com/images/2429c3cd-a1de-44fc-b4f3-bc762bb2f963/IBM%2BChampion%2B-%2BAnalytics%2B2018.png][https://acclaim-production-app.s3.amazonaws.com/images/2429c3cd-a1de-44fc-b4f3-bc762bb2f963/IBM%2BChampion%2B-%2BAnalytics%2B2018.png]



From: Tim Hare [mailto:[login to unmask email]
Sent: 16 May 2019 15:20
To: [login to unmask email]
Subject: [EXTERNAL] [DB2-L] - RE: Image copy compression question


Do you have a reference to a point in a manual or somewhere from IBM I can point to so the SMS administators will not balk at removing compression from the output?

-----End Original Message-----
BMC Software Limited Registered Office: Building E2, Eskdale Road, Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in England No. 1927903 The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately.
Attachments

  • image001.jpg (49.7k)
  • image002.png (6.7k)
  • image003.png (3.7k)
  • image004.png (<1k)