Re: query auditocc question

[Paul_Dudley]

Thanks David - I ran the second command which provided me with a report. 
However the figures in that report match what I already receive from the query 
auditocc command.
This makes me think that there is something wrong with the data that it is 
reporting on. There are two SQL database servers for which the reported data 
appears to be obviously wrong.

For one of them the reported primary storage pool data has increased over the 
past 4 weeks from 2.3Tb, to 4.5Tb, to 7.0Tb and now this week it is 9.1Tb.
We have not increased the number of backups kept, and we have not added any new 
SQL databases.
When I start the DP for SQL client and add up all the active and inactive 
databases which I can restore from, the total amount of data is 2.3Tb.

On another SQL server, the reported primary storage pool data has increased 
over the past 4 weeks from 310Gb, to 610Gb, then 950Gb and now it is 1300Gb.
When I start the DP for SQL client and add up all the active and inactive 
databases which I can restore from, the total amount of data is around 310Gb.

It is as if each week the amount of primary storage pool data is being added to 
rather than replaced. However this is only happening for SQL database servers.
For other non-database servers the amount of reported primary storage pool data 
has been stable.

Where is this the information for this reported primary storage pool data kept? 
Is it on our TSMADMIN server somewhere?

Thanks & Regards
Paul



-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of David 
Ehresman
Sent: Thursday, 28 July 2016 10:57 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] query auditocc question

Paul,

You are right.  All of my data is in primary storage pools so I no longer worry 
about copy pools.  Back when I had copy pools, my storage pool names would 
indicate whether it was primary or copy pool.  Can you mask on pool name to 
distinguish between primary and copy pool?

If so,

select node_name,sum(reporting_mb) as "TOTAL_OCCUPANCY" from occupancy group by 
node_name  where stgpool_name like '%NAME MASK%'c

Alternatively,

select node_name,sum(reporting_mb) as "TOTAL_OCCUPANCY" from occupancy where 
stgpool_name in (select stgpool_name from stgpools where POOLTYPE='PRIMARY' ) 
group by node_name

David

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Paul_Dudley
Sent: Wednesday, July 27, 2016 8:11 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] query auditocc question

Thanks. I ran this command and it ran successfully and provided me with a list 
of totals.
However they are a lot higher than what is reported by my query auditocc 
command.
Does it total just the primary storage or all storage pools?

I am just interested in primary storage to keep track of storage used as we 
have the unified terabyte licensing for TSM.

Thanks & Regards
Paul



-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of David 
Ehresman
Sent: Wednesday, 27 July 2016 11:13 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] query auditocc question

Perhaps the following query would give you better data:

select node_name,sum(reporting_mb) as "TOTAL_OCCUPANCY" from occupancy group by 
node_name


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Paul_Dudley
Sent: Tuesday, July 26, 2016 9:35 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] query auditocc question

To keep track of our primary storage usage, on a weekly basis I run the 
following command:



query auditocc pooltype=primary



For one of the nodes - an SQL server - it is reporting that the backup storage 
used is 7Tb.

However knowing the size of the databases on that server and the number of 
copies of each backup we keep, I believe that to be incorrect.

I started the DP for SQL client on that server, clicked on Restore Data, and 
then selected all backups (both active and inactive).

I then added up the size of each backup (both active and inactive) and it added 
up to 2.2Tb.



How could there be such a huge difference between each total?





Thanks & Regards

Paul Dudley

IT Operations

ANL Container Line

pdud...@anl.com.au








ANL DISCLAIMER

This e-mail and any file attached is confidential, and intended solely to the 
named add ressees. Any unauthorised dissemination or use is strictly 
prohibited. If you received this e-mail in error, please immediately notify the 
sender by return e-mail from your s ystem. Please do not copy, use or make 
reference to it for any purpose, or disclose its  contents to any person.
--
Message  protected by MailGuard: e-mail anti-virus, anti-spam and content 
filtering.

Re: Need timeline/version for inline-dedup container stgpool with tape vaulting support

[Del Hoobler]

I cannot discuss confidential dates on a public forum. I can tell you that 
this is a known high priority requirement.

If you want more details and to understand time frames, please connect 
with your IBM representative and they can share this information with you 
under NDA.

You can also join our beta program if you want to be more closely involved 
as well as get access to early code. If this is of interest, mention this 
to your IBM representative.


Thank you,

Del





"ADSM: Dist Stor Manager"  wrote on 08/01/2016 
01:19:10 PM:

> From: "Michaud, Luc [Analyste principal - environnement AIX]" 
> 
> To: ADSM-L@VM.MARIST.EDU
> Date: 08/01/2016 01:19 PM
> Subject: Need timeline/version for inline-dedup container stgpool 
> with tape vaulting support
> Sent by: "ADSM: Dist Stor Manager" 
> 
> We are looking at upgrading our existing TSM 7.1.1.300 server (on AIX).
> We would really like to gain benefits from the reworked inline dedup
> architecture (hopefully it wont pound the db2 as much), but our 
> current DR strategy relies on external vaulting of LTO tapes.
> Anyone has a roadmap (w/ versions and tentative dates) when the 
> inline-dedup container stgpool will support this ?
> 
> Regards,
> LUC MICHAUD, B.Ing
> Analyste Principal Exploitation
> Division Technologies de l'information
> Sociéte de Transport de Montréal
> (514) 280-7416
> luc.micha...@stm.info
> 

Need timeline/version for inline-dedup container stgpool with tape vaulting support

[Michaud, Luc [Analyste principal - environnement AIX]]

We are looking at upgrading our existing TSM 7.1.1.300 server (on AIX).
We would really like to gain benefits from the reworked inline dedup 
architecture (hopefully it wont pound the db2 as much), but our current DR 
strategy relies on external vaulting of LTO tapes.
Anyone has a roadmap (w/ versions and tentative dates) when the inline-dedup 
container stgpool will support this ?

Regards,
LUC MICHAUD, B.Ing
Analyste Principal Exploitation
Division Technologies de l'information
Sociéte de Transport de Montréal
(514) 280-7416
luc.micha...@stm.info

Re: Very weird design change SAP HANA client

[Del Hoobler]

Hi Eric,

I don't have much else to offer other than monitoring the SAP HANA backups 
to ensure any failures are caught and corrected promptly. If you have a 
two week retention period, you should be able to detect failed backups and 
react well before all backups have expired. 

It may also help if you placed a requirement against SAP directly to 
provide the enhancement as well. If they see more heat on this, it could 
motivate them to release this sooner and specify a target date. 

Thank you,

Del



"ADSM: Dist Stor Manager"  wrote on 08/01/2016 
05:03:29 AM:

> From: "Loon, EJ van (ITOPT3) - KLM" 
> To: ADSM-L@VM.MARIST.EDU
> Date: 08/01/2016 05:04 AM
> Subject: Re: Very weird design change SAP HANA client
> Sent by: "ADSM: Dist Stor Manager" 
> 
> Hi Del!
> Thank you very much for your explanation. And sorry for blaming IBM 
> for this. I'm really puzzled over what to do next. Like I said, 
> implementing policy based expiration introduces the risk of losing 
> all your backups when a client stops backing up for a certain amount
> of time. The option of deleting backup data through SAP HANA Studio 
> is also not very attractive: I know the customer will do this in the
> beginning, but over time they will become sloppy or just forget...
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
> 
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On 
> Behalf Of Del Hoobler
> Sent: vrijdag 29 juli 2016 19:05
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: Very weird design change SAP HANA client
> 
> Eric,
> 
> This "design change" is a "change" from the Data Protection for ERP 
> perspective, but not from the Data Protection for ERP for SAP HANA 
> perspective, which has always worked this way.
> 
> This design "change" is a result of a current limitation in the SAP 
> HANA BACKINT API and is expected to be temporary.  This backup API 
> streams the backup data to the DP for SAP HANA client via named 
> pipes and today it gives no indication whether the data stream was 
> complete or the pipe was closed prematurely due to some error. 
> 
> We don't want to expire a prior/older backup version unless we know 
> we have a successful new backup version so we do not currently offer
> expiration of backups based on version limit.  However, we do plan 
> to provide that capability once SAP implements the enhancement to 
> the backup API we have requested (to indicate whether or not all the
> data was streamed  successfully).  SAP did indicate they plan to 
> provide that enhancement but we do not yet have a target date for that. 
> 
> 
> Thank you,
> 
> Del
> 
> 
> 
> "ADSM: Dist Stor Manager"  wrote on 07/29/2016
> 07:23:32 AM:
> 
> > From: "Loon, EJ van (ITOPT3) - KLM" 
> > To: ADSM-L@VM.MARIST.EDU
> > Date: 07/29/2016 07:24 AM
> > Subject: Very weird design change SAP HANA client Sent by: "ADSM: Dist 

> > Stor Manager" 
> > 
> > Hello all!
> > Recently we started to use the Data Protection for SAP HANA client. 
> > I created a TSM node identical to the already existing Data Protection 

> > for SAP node and now customer reported that he received the following 
> > error message after a successful backup:
> > 
> > BKI8649E: The automatic deletion of backups is not supported. Change 
> > the value of the MAX_VERSIONS parameter to 0
> > 
> > I googled for the BKI8649E and stumbled across technote IT11810 which 
> > explains that versioning through the MAX_VERSIONS parameter is no 
> > longer supported. You now have to use TSM to control the retention for 

> > your SAP backups. That would be very nice if the TDP client was 
> > creating backup files on TSM and was working like the Oracle client 
> > (active files are kept forever until they are marked inactive by 
> > RMAN/TDP for Oracle). But the DP for SAP client creates archive files, 

> > so when you backup your SAP database, the files are kept for the 
> > amount of time set in the archive copy group. This means that if you 
> > have a copygroup setting of 14 days and you do not backup your 
> > database for 14 days for some reason, on day 15 you no longer have any 

> > backup available for recovery!!!
> > I think this is absolutely unacceptable and I really don't understand 
> > why IBM has decided to change this.
> > The only work around one has is to set retver to unlimited and delete 
> > the obsolete backup versions through HANA Studio. This is also 
> > unacceptable I think, this is moving a design flaw to the customer
> side.
> > Am I the only one struggling with this issue?
> > Kind regards,
> > Eric van Loon
> > Air France/KLM Storage Engineering
> > 
> > For information, services and offers, please visit 

Re: Very weird design change SAP HANA client

[Loon, EJ van (ITOPT3) - KLM]

Hi Del!
Thank you very much for your explanation. And sorry for blaming IBM for this. 
I'm really puzzled over what to do next. Like I said, implementing policy based 
expiration introduces the risk of losing all your backups when a client stops 
backing up for a certain amount of time. The option of deleting backup data 
through SAP HANA Studio is also not very attractive: I know the customer will 
do this in the beginning, but over time they will become sloppy or just 
forget...
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Del 
Hoobler
Sent: vrijdag 29 juli 2016 19:05
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Very weird design change SAP HANA client

Eric,

This "design change" is a "change" from the Data Protection for ERP 
perspective, but not from the Data Protection for ERP for SAP HANA perspective, 
which has always worked this way.

This design "change" is a result of a current limitation in the SAP HANA 
BACKINT API and is expected to be temporary.  This backup API streams the 
backup data to the DP for SAP HANA client via named pipes and today it gives no 
indication whether the data stream was complete or the pipe was closed 
prematurely due to some error. 

We don't want to expire a prior/older backup version unless we know we have a 
successful new backup version so we do not currently offer expiration of 
backups based on version limit.  However, we do plan to provide that capability 
once SAP implements the enhancement to the backup API we have requested (to 
indicate whether or not all the data was streamed  successfully).  SAP did 
indicate they plan to provide that enhancement but we do not yet have a target 
date for that. 


Thank you,

Del



"ADSM: Dist Stor Manager"  wrote on 07/29/2016
07:23:32 AM:

> From: "Loon, EJ van (ITOPT3) - KLM" 
> To: ADSM-L@VM.MARIST.EDU
> Date: 07/29/2016 07:24 AM
> Subject: Very weird design change SAP HANA client Sent by: "ADSM: Dist 
> Stor Manager" 
> 
> Hello all!
> Recently we started to use the Data Protection for SAP HANA client. 
> I created a TSM node identical to the already existing Data Protection 
> for SAP node and now customer reported that he received the following 
> error message after a successful backup:
> 
> BKI8649E: The automatic deletion of backups is not supported. Change 
> the value of the MAX_VERSIONS parameter to 0
> 
> I googled for the BKI8649E and stumbled across technote IT11810 which 
> explains that versioning through the MAX_VERSIONS parameter is no 
> longer supported. You now have to use TSM to control the retention for 
> your SAP backups. That would be very nice if the TDP client was 
> creating backup files on TSM and was working like the Oracle client 
> (active files are kept forever until they are marked inactive by 
> RMAN/TDP for Oracle). But the DP for SAP client creates archive files, 
> so when you backup your SAP database, the files are kept for the 
> amount of time set in the archive copy group. This means that if you 
> have a copygroup setting of 14 days and you do not backup your 
> database for 14 days for some reason, on day 15 you no longer have any 
> backup available for recovery!!!
> I think this is absolutely unacceptable and I really don't understand 
> why IBM has decided to change this.
> The only work around one has is to set retver to unlimited and delete 
> the obsolete backup versions through HANA Studio. This is also 
> unacceptable I think, this is moving a design flaw to the customer
side.
> Am I the only one struggling with this issue?
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
> 
> For information, services and offers, please visit our web site: 
> http://www.klm.com. This e-mail and any attachment may contain 
> confidential and privileged material intended for the addressee only. 
> If you are not the addressee, you are notified that no part of the 
> e-mail or any attachment may be disclosed, copied or distributed, and 
> that any other action related to this e-mail or attachment is strictly 
> prohibited, and may be unlawful. If you have received this e-mail by 
> error, please notify the sender immediately by return e-mail, and 
> delete this message.
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/ or 
> its employees shall not be liable for the incorrect or incomplete 
> transmission of this e-mail or any attachments, nor responsible for 
> any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal 
> Dutch Airlines) is registered in Amstelveen, The Netherlands, with 
> registered number 33014286
> 
>