ADSM-L

Re: [ADSM-L] Very weird design change SAP HANA client

2016-08-16 10:57:29
Subject: Re: [ADSM-L] Very weird design change SAP HANA client
From: "Loon, Eric van (ITOPT3) - KLM" <Eric-van.Loon AT KLM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 16 Aug 2016 14:55:59 +0000
Hi Del!
Thank you very much for the explanation!
Kind regards,
Eric van Loon
Air France/KLM Storage Engineering


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Del Hoobler
Sent: dinsdag 16 augustus 2016 15:59
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Very weird design change SAP HANA client

Hi Eric,

The primary reason the ERP clients store backups as archive objects is the 
requirement to be able to group multiple independent objects into a logical 
backup set.  The ERP clients were written before the Spectrum Protect server 
implemented the grouping constructs for backups and so it was architected to 
use the archive description string as a mechanism to logically group multiple 
objects.

Del

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


"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 08/02/2016
05:45:52 AM:

> From: "Loon, EJ van (ITOPT3) - KLM" <Eric-van.Loon AT KLM DOT COM>
> To: ADSM-L AT VM.MARIST DOT EDU
> Date: 08/02/2016 05:46 AM
> Subject: Re: Very weird design change SAP HANA client Sent by: "ADSM: 
> Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 
> Hi Del!
> Thanks again for the explanation. I will plan a meeting with our SAP 
> guys and discuss with them what to do.
> Just out of curiosity: why is the DP for SAP HANA and the DP for ERP 
> client creating archive files where the other TDP clients are all 
> creating backup files?
> Kind regards,
> Eric van Loon
> Air France/KLM Storage Engineering
> 
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of Del Hoobler
> Sent: maandag 1 augustus 2016 17:19
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Very weird design change SAP HANA client
> 
> 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" <ADSM-L AT VM.MARIST DOT EDU> wrote on 08/01/2016
> 05:03:29 AM:
> 
> > From: "Loon, EJ van (ITOPT3) - KLM" <Eric-van.Loon AT KLM DOT COM>
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Date: 08/01/2016 05:04 AM
> > Subject: Re: Very weird design change SAP HANA client Sent by: "ADSM: 
> > Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> > 
> > 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 AT VM.MARIST DOT EDU] On 
> > Behalf Of Del Hoobler
> > Sent: vrijdag 29 juli 2016 19:05
> > To: ADSM-L AT VM.MARIST DOT 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" <ADSM-L AT VM.MARIST DOT EDU> wrote on 07/29/2016
> > 07:23:32 AM:
> > 
> > > From: "Loon, EJ van (ITOPT3) - KLM" <Eric-van.Loon AT KLM DOT COM>
> > > To: ADSM-L AT VM.MARIST DOT EDU
> > > Date: 07/29/2016 07:24 AM
> > > Subject: Very weird design change SAP HANA client Sent by: "ADSM: 
> > > Dist
> 
> > > Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> > > 
> > > 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
> > > ********************************************************
> > > 
> > ********************************************************
> > 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
> > ********************************************************
> > 
> > 
> ********************************************************
> 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
> ********************************************************
> 
> 
********************************************************
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
********************************************************
                        

<Prev in Thread] Current Thread [Next in Thread>