Hello,
I'm not sure exactly but If the transaction is dropped (dsmEndTxn), then it can
be influenced by the transaction size and transaction time.
Size is adjustable using TXNGROUPMAX time - COMMTIMEOUT.
To eliminate the effect of these parameters I suggest to increase it to higher
values.
Parameters can be changed dynamically (it will be applied to the new client
sessions).
Save the current values of the parameters before changing.
setopt TXNGROUPMAX 20000
setopt COMMTIMEOUT 5000
Efim
> 18 марта 2016 г., в 11:56, Martin Janosik <martin.janosik AT CZ.IBM DOT COM>
> написал(а):
>
> Hi Zoltan,
>
> have you tried to delete all orphaned objects in one run? I had similar
> issue recently, can't remember exact ANS/RC code. But try to split objects
> to smaller group (250 was working for me on one server, 2000 on another),
> and delete object in smaller bunches.
> +1:250
> O
>
> Bye
>
> Martin J.
>
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 03/17/2016
> 09:03:16 PM:
>
>> From: Zoltan Forray <zforray AT VCU DOT EDU>
>> To: ADSM-L AT VM.MARIST DOT EDU
>> Date: 03/17/2016 09:05 PM
>> Subject: Re: [ADSM-L] Data Protection for Oracle 5.5.2 + 7.1.4 API
>> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>>
>> Unfortunately, you are right. I only see 11 + 12, which is where we are.
>>
>> On Thu, Mar 17, 2016 at 3:33 PM, Stefan Folkerts
> <stefan.folkerts AT gmail DOT com>
>> wrote:
>>
>>> I don't think the 7.1.3 TDP supports Oracle 10.
>>> I think this is 11 and 12 only.
>>>
>>> On Thu, Mar 17, 2016 at 5:53 PM, Zoltan Forray <zforray AT vcu DOT edu>
>>> wrote:
>>>
>>>> Why not upgrade the TSM TDP for Oracle to 7.1.3? This combination
> (TSM
>>>> client 7.1.4.4 + TDP 7.1.3.0) is what we are running.
>>>>
>>>> On Thu, Mar 17, 2016 at 12:03 PM, Loon, EJ van (ITOPT3) - KLM <
>>>> Eric-van.Loon AT klm DOT com> wrote:
>>>>
>>>>> Hi guys!
>>>>> I have an issue with one of my Oracle customers. They have several
>>> RedHat
>>>>> 5.8 servers (with Oracle 10) which had TSM 5.5 running, along with
> TDP
>>>> for
>>>>> Oracle 5.5.2.
>>>>> Since the OS support the new 7.1.4 client, they upgraded the BA and
> API
>>>>> client to 7.1.4. Since that moment they can no longer delete
> obsolete
>>>>> backup objects. In TDPOSYSNC you see the list of obsolete objects,
> but
>>> as
>>>>> soon as you try to delete them it returns the following error:
>>>>>
>>>>> ANS0246E (RC2070) Issue dsmEndTxn and then begin a new transaction
>>>> session.
>>>>>
>>>>> The TDP for Oracle 5.5.2 requirement list states "A Tivoli Storage
>>>> Manager
>>>>> API V5.5, or later", so technically it should be compatible...
>>>>> Does anybody else ran into this issue before? And if so, how did
> you
>>>> solve
>>>>> it? I know I could have them downgrade the BA and API client again,
> but
>>>>> then I also have to find a way to force a full back up on the BA
>>>> client...
>>>>> Thanks for any help in advance!
>>>>> 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
>>>>> ********************************************************
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Zoltan Forray*
>>>> TSM Software & Hardware Administrator
>>>> Xymon Monitor Administrator
>>>> VMware Administrator (in training)
>>>> Virginia Commonwealth University
>>>> UCC/Office of Technology Services
>>>> www.ucc.vcu.edu
>>>> zforray AT vcu DOT edu - 804-828-4807
>>>> Don't be a phishing victim - VCU and other reputable organizations
> will
>>>> never use email to request that you reply with your password, social
>>>> security number or confidential personal information. For more
> details
>>>> visit http://infosecurity.vcu.edu/phishing.html
>>>>
>>>
>>
>>
>>
>> --
>> *Zoltan Forray*
>> TSM Software & Hardware Administrator
>> Xymon Monitor Administrator
>> VMware Administrator (in training)
>> Virginia Commonwealth University
>> UCC/Office of Technology Services
>> www.ucc.vcu.edu
>> zforray AT vcu DOT edu - 804-828-4807
>> Don't be a phishing victim - VCU and other reputable organizations will
>> never use email to request that you reply with your password, social
>> security number or confidential personal information. For more details
>> visit http://infosecurity.vcu.edu/phishing.html
>>
|
