Re: Sloooow deletion of objects on Replication target server

[Sasa Drnjevic]

Not sure of course...But, I would blame NFS

Did you check the negotiated speed of your NFS eth 10G ifaces?
And that network?

Regards,

--
Sasa Drnjevic
www.srce.unizg.hr


On 24.7.2017. 15:49, Zoltan Forray wrote:
> 8-cores/16-threads.  It wasn't bad when it was replicating from 4-SP/TSM
> servers.  We had to stop all replication due to running out of space and
> until I finish this cleanup, I have been holding off replication.  So, the
> deletion has been running standalone.
>
> I forgot to mention that DB backups are also running very long.  1.5TB DB
> backup runs 8+hours to NFS storage.  These are connected via 10G.
>
> On Mon, Jul 24, 2017 at 9:41 AM, Sasa Drnjevic 
> wrote:
>
>> On 24.7.2017. 15:25, Zoltan Forray wrote:
>>> Due to lack of resources, we have had to stop replication on one of our
>> SP
>>> servers. The replication target server is 7.1.6.3 RHEL 7, Dell T710 with
>>> 192GB RAM.  NFS/ISILON storage.
>>>
>>> After removing replication from the nodes on source server, I have been
>>> cleaning up the replication server by deleting the filespaces for the
>> nodes
>>> we are no longer replicating.
>>>
>>> My issue is the delete filespaces on the replication server is taking
>>> forever.  It took over a week to delete one filespace with 31-million
>>> objects?
>>
>>
>> That is definitely to lng :-(
>>
>> It would take 6-8 hrs max, in my environment even under "standard" load...
>>
>> How many CPU cores does it have?
>>
>> And how is/was it performing the role of a target repl. server
>> performance wise?
>>
>> Regards,
>>
>> --
>> Sasa Drnjevic
>> www.srce.unizg.hr
>>
>>
>>
>>
>>
>>
>>
>>>
>>> To me it is highly unusual to take this long. Your thoughts on this?
>>>
>>> --
>>> *Zoltan Forray*
>>> Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
>>> Xymon Monitor Administrator
>>> VMware Administrator
>>> Virginia Commonwealth University
>>> UCC/Office of Technology Services
>>> www.ucc.vcu.edu
>>> zfor...@vcu.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*
> Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> Xymon Monitor Administrator
> VMware Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> www.ucc.vcu.edu
> zfor...@vcu.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
>

Re: Client Application version script

[Loon, Eric van (ITOPT3) - KLM]

Hi Zoltan!
You are right! I just checked and this is new in 7.1 and higher. So I stand 
corrected.
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 Zoltan 
Forray
Sent: maandag 24 juli 2017 14:25
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Client Application version script

Actually there are the APPLICATION fields/columns.

APPLICATION_VERSION,APPLICATION_RELEASE,APPLICATION_LEVEL,APPLICATION_SUBLEVEL

For example, on a node that uses the Oracle TDP, I get

APPLICATION_VERSION = 7
APPLICATION_RELEASE = 1
APPLICATION_LEVEL = 3
APPLICATION_SUBLEVEL = 0

or 7.1.3.0 for the TDP client

While the client info is:

CLIENT_VERSION = 8
CLIENT_RELEASE = 1
CLIENT_LEVEL = 0
CLIENT_SUBLEVEL = 2

or SP Client 8.1.0.2

YMMV - not sure when this came in.  My servers are 7.1.6.3

Hope this helps

On Sun, Jul 23, 2017 at 11:51 AM, Loon, Eric van (ITOPT3) - KLM < 
eric-van.l...@klm.com> wrote:

> Hi Robert!
> Unfortunately the TDP versions are not collected by the TSM server, so 
> no, that won't be possible I'm afraid.
> 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 rou...@univ.haifa.ac.il
> Sent: zondag 23 juli 2017 6:54
> To: ADSM-L@VM.MARIST.EDU
> Subject: Client Application version script
>
> Hello all
>
> I wonder if a can write a script to get the version of Clients 
> application as Oracle , SQL , etc 
>
> My current script give me the version of the B.A client.
>
> select cast(node_name as varchar(30)) as "Nodename" , cast(contact as
> varchar(18)) as "Contact" , cast(CLIENT_OS_NAME as varchar(60)) as 
> "O.S" , cast(CLIENT_SYSTEM_ARCHITECTURE as varchar(4)) as "Bit" , 
> CLIENT_VERSION, CLIENT_RELEASE, CLIENT_LEVEL , CLIENT_SUBLEVEL  from 
> nodes  order by
> 5,6,7,8,2
>
> T.I.A, Best Regards
>
> Robert
> 
> 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*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor 
Administrator VMware Administrator Virginia Commonwealth University UCC/Office 
of Technology Services www.ucc.vcu.edu zfor...@vcu.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

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

Re: Sloooow deletion of objects on Replication target server

[Zoltan Forray]

8-cores/16-threads.  It wasn't bad when it was replicating from 4-SP/TSM
servers.  We had to stop all replication due to running out of space and
until I finish this cleanup, I have been holding off replication.  So, the
deletion has been running standalone.

I forgot to mention that DB backups are also running very long.  1.5TB DB
backup runs 8+hours to NFS storage.  These are connected via 10G.

On Mon, Jul 24, 2017 at 9:41 AM, Sasa Drnjevic 
wrote:

> On 24.7.2017. 15:25, Zoltan Forray wrote:
> > Due to lack of resources, we have had to stop replication on one of our
> SP
> > servers. The replication target server is 7.1.6.3 RHEL 7, Dell T710 with
> > 192GB RAM.  NFS/ISILON storage.
> >
> > After removing replication from the nodes on source server, I have been
> > cleaning up the replication server by deleting the filespaces for the
> nodes
> > we are no longer replicating.
> >
> > My issue is the delete filespaces on the replication server is taking
> > forever.  It took over a week to delete one filespace with 31-million
> > objects?
>
>
> That is definitely to lng :-(
>
> It would take 6-8 hrs max, in my environment even under "standard" load...
>
> How many CPU cores does it have?
>
> And how is/was it performing the role of a target repl. server
> performance wise?
>
> Regards,
>
> --
> Sasa Drnjevic
> www.srce.unizg.hr
>
>
>
>
>
>
>
> >
> > To me it is highly unusual to take this long. Your thoughts on this?
> >
> > --
> > *Zoltan Forray*
> > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> > Xymon Monitor Administrator
> > VMware Administrator
> > Virginia Commonwealth University
> > UCC/Office of Technology Services
> > www.ucc.vcu.edu
> > zfor...@vcu.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*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
zfor...@vcu.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

Re: Sloooow deletion of objects on Replication target server

[Sasa Drnjevic]

On 24.7.2017. 15:25, Zoltan Forray wrote:
> Due to lack of resources, we have had to stop replication on one of our SP
> servers. The replication target server is 7.1.6.3 RHEL 7, Dell T710 with
> 192GB RAM.  NFS/ISILON storage.
>
> After removing replication from the nodes on source server, I have been
> cleaning up the replication server by deleting the filespaces for the nodes
> we are no longer replicating.
>
> My issue is the delete filespaces on the replication server is taking
> forever.  It took over a week to delete one filespace with 31-million
> objects?


That is definitely to lng :-(

It would take 6-8 hrs max, in my environment even under "standard" load...

How many CPU cores does it have?

And how is/was it performing the role of a target repl. server
performance wise?

Regards,

--
Sasa Drnjevic
www.srce.unizg.hr







>
> To me it is highly unusual to take this long. Your thoughts on this?
>
> --
> *Zoltan Forray*
> Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> Xymon Monitor Administrator
> VMware Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> www.ucc.vcu.edu
> zfor...@vcu.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
>

Sloooow deletion of objects on Replication target server

[Zoltan Forray]

Due to lack of resources, we have had to stop replication on one of our SP
servers. The replication target server is 7.1.6.3 RHEL 7, Dell T710 with
192GB RAM.  NFS/ISILON storage.

After removing replication from the nodes on source server, I have been
cleaning up the replication server by deleting the filespaces for the nodes
we are no longer replicating.

My issue is the delete filespaces on the replication server is taking
forever.  It took over a week to delete one filespace with 31-million
objects?

To me it is highly unusual to take this long. Your thoughts on this?

--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
zfor...@vcu.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

Re: Client Application version script

[Zoltan Forray]

Actually there are the APPLICATION fields/columns.

APPLICATION_VERSION,APPLICATION_RELEASE,APPLICATION_LEVEL,APPLICATION_SUBLEVEL

For example, on a node that uses the Oracle TDP, I get

APPLICATION_VERSION = 7
APPLICATION_RELEASE = 1
APPLICATION_LEVEL = 3
APPLICATION_SUBLEVEL = 0

or 7.1.3.0 for the TDP client

While the client info is:

CLIENT_VERSION = 8
CLIENT_RELEASE = 1
CLIENT_LEVEL = 0
CLIENT_SUBLEVEL = 2

or SP Client 8.1.0.2

YMMV - not sure when this came in.  My servers are 7.1.6.3

Hope this helps

On Sun, Jul 23, 2017 at 11:51 AM, Loon, Eric van (ITOPT3) - KLM <
eric-van.l...@klm.com> wrote:

> Hi Robert!
> Unfortunately the TDP versions are not collected by the TSM server, so no,
> that won't be possible I'm afraid.
> 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
> rou...@univ.haifa.ac.il
> Sent: zondag 23 juli 2017 6:54
> To: ADSM-L@VM.MARIST.EDU
> Subject: Client Application version script
>
> Hello all
>
> I wonder if a can write a script to get the version of Clients application
> as Oracle , SQL , etc 
>
> My current script give me the version of the B.A client.
>
> select cast(node_name as varchar(30)) as "Nodename" , cast(contact as
> varchar(18)) as "Contact" , cast(CLIENT_OS_NAME as varchar(60)) as "O.S" ,
> cast(CLIENT_SYSTEM_ARCHITECTURE as varchar(4)) as "Bit" , CLIENT_VERSION,
> CLIENT_RELEASE, CLIENT_LEVEL , CLIENT_SUBLEVEL  from nodes  order by
> 5,6,7,8,2
>
> T.I.A, Best Regards
>
> Robert
> 
> 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*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
zfor...@vcu.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