This post is more than 5 years old
11 Posts
0
2161
Info on DPA-9451
Hi,
we recently upgraded to DPA v5.7.1, but since the upgrade, we are seeing quite a lot of "false-failed" savejobs for Networker. I found a bugid related to the issue in the v5.8 release notes (DPA-9451), but I can't find more information on the extend of the problem.
As upgrading to v5.8 failed recently, and support can't help us, is anybody able to give more information on bug DPA-9451, or point me to information on it?
Thanks in advance!
Regards,
Karl.
ElvinKan
59 Posts
0
July 6th, 2011 07:00
Hi
Support can provide assistance with both issues you have listed viz
- the failed upgrade to DPA 5.8
- the "false-failed" issue
If Support is not able to assist, please ask them to escalate to the next level and/or speak to your local EMC account rep. These are basics that Support can handle.
For the failed DPA Upgrade, please submit the emc_dpa_setup.log and relevant screenshots of the failed message.
As for the "false-failed" issue, there is knowledgebase article esg120378 that deals with this (if it applies to your environment).
For your covnenience, here is the detail from the esg article about bug DPA-9451:
Symptoms
After upgrade from Data Protection Advisor (DPA) 5.5 to DPA 5.7, some savesets which were reported as successful by Networker show up as failed in DPA.
Cause
Later versions of DPA include code to deal with abandoned jobs - DPA 5.6 and 5.7 and earlier in 5.5 with specific patches. This code only activates when mminfo stops reporting the job, which in theory should only happen when the job is complete.
There are instances where the job disappears from mminfo but later return before finally completing successfully.
By default, DPA waits for 6 hours before reporting these abandoned job as failed. But if the job disappears from mminfo for longer than 6 hours, it will be marked as failed in DPA even if the job reappears in mminfo and completes successfully in Networker.
Resolution
The following configuration can be set on the collector host to increase the wait time in DPA before marking the abandoned job as failed.
Assuming the request is set to the default 5 min polling, the value of 250 increases the wait time to 20 hours.
On Windows
Create the following registry key:
Next time the request is run, this value is picked up.
On Unix
Put the following entry in the dpa.config file:
Restart the collector. This can also be placed in a dpa.custom file to avoid the change being lost when an upgrade occurs.
If the issues persist, please open an SR and ask Support to escalate if L1 cannot assist.
HTH
Karleke
11 Posts
0
July 8th, 2011 02:00
Thank you very much Elvin for that info. I implemented the work-around and will see if the false-positives become less.
PS: Apparently we can not upgrade to v5.8 because we are using Fujitsu NMC instead of the "real" EMC NMC, and our L1-support is very stuborn and won't escalate the issue that the v5.8 install-scripts has with that (previous upgrades went fine).
Same issue happens when you install "EMC NMC" in a non-default location, but they claim that is beside the point...
Thanks again!
Regards,
Karl.
ElvinKan
59 Posts
1
July 8th, 2011 08:00
Hi Karl
DPA is not dependant on NMC at all..... are you using DPA where the backend database is the NMC iAnywhere database ?
If you install DPA on a host with NMC on it, and it installs into the NMC's iAnywhere database - all DPA does is provide a hyperlink from the NMC console to launch a DPA console - datawise, DPA does not read any data from NMC at all.
If you can, I'd split DPA onto a host of its own - then the upgrade is 'supportable'.
DPA running on iAnywhere is a poor performer as well if your database is large, Personally, I would split the DPA Server from the NMC Server (so it has more resources of its own) - and choose/migrate to another database platform eg. Oracle. SQL Server or postgres (depending which platform the DPA Server is going to be on).
Your local EMC TC or Fujitsu TC has access to a DPA Server sizing spreadsheet to assist with the specs.
iAnywhere should ONLY be used if your backup environment is about 200 backup clients or less - and have the relevant database maintenance plans in place and a regular REORG (as per the manual)
HTH
-E
Karleke
11 Posts
0
July 12th, 2011 02:00
Hi Elvin,
>> DPA is not dependant on NMC at all
I thought that as well. Apart from the little "start DPA" menu-entry in the NMC-UI, I could not find any other links between DPA and NMC. That's kind of why this DPA-install error is bothering me so much
This is was emc_dpa_setup.log spits out:
===========================================
(Jul 5, 2011 11:45:58 AM), null, GetValueFromConfigFile, dbg, search key=GST_HOME section=
============================================
After which the install-script bombs out...
It's looking for the "lgtonmc"-string, and the FSC-version is simply called nmc.
>> are you using DPA where the backend database is the NMC iAnywhere database ?
No way, I realize the restrictions on iAnywhere. We are using Postgres, on a 12CPU / 24Gig RAM machine, so resources should be fine.
>> If you can, I'd split DPA onto a host of its own - then the upgrade is 'supportable'.
That would off course be an option, it's just that, timewise, that would be a hell of a job. We support about 30 different customers, each of them protected by our own firewall, and most of them, additionally with their own customer-firewall, so doing all the change-requests to get DPA (or EMC) talking to a new machine, TCP-wise, is a real nightmare
Isn't there just a simple option in the DPA install-script to say "ignore EMC". I don't care if the little menu-entry in the EMC-UI isn't available afterwards.
Previous DPA-upgrades went fine, so it definitely looks like a bug in the DPA-install-scripts to me.
Thanks a bunch for the help!