1. Please help support our sponsors by considering their products and services.
    Our sponsors enable us to maintain high-speed Internet connection and fast webservers.
    They support this free information and knowledge exchange forum service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions

Spectrum Protect Server is out

Discussion in 'News & Announcements' started by Trident, Jun 21, 2017.

  1. Trident

    Trident TSM noob with 10 years expirience ADSM.ORG Moderator

    Apr 2, 2007
    Likes Received:
    IT operations
    Oslo, Norway
  3. erwanns

    erwanns ADSM.ORG Senior Member

    Mar 29, 2006
    Likes Received:
  4. shcart

    shcart ADSM.ORG Member

    Jan 6, 2003
    Likes Received:
    Monroe, NC
    If you are still back on the early 7.1... versions be careful when upgrading.

    We upgraded (a special efix) up to, and since in an attempt to fix things had to upgrade to

    From 7.1.1 to 7.1.7 our expire inventory went from < 1.5 hours to almost 8 hours over a day and remains there eating up CPU like its going out of fashion. Q stgpool takes hours to respond while its running. IBM have now been investigating why its happening for months. This included getting the DB2 performance guru's involved who found nothing.

    Our biggest worry is that over consecutive weekends (Mgt Directive, not our preferred schedule) we upgraded Adapter Firmware, AIX and Atape Drivers then the nexy weekend we upgraded TSM. The issue could have crept in anywhere over these two weeks because there was no time for things to stabilize and be monitored. Be aware and learn from us. Document every AIX, Adaptor, LAN, DB2, OS and driver setting before you start. And check them all once you are finished. Because of our underlying shared VTL hardware structure just a primary VTL reboot takes 7+ hours ( A VTL Fix can take 15-18 Hours but thats yet another story) so even performance tweeks can take a full day.

    TSM is a very complex product. Agile or similar development techniques now in use lead to rapid and necessarily limited testing. Even with thorough testing IBM could often only test on tens of thousands or millions rather than billions of objects under management. Move slowly and if at all possible make sure you can get out of trouble as fast as you get into it. Also make support do their job rather than just accept them telling you that you must upgrade because your problem might be fixed in version X+3.

    Finally we also have an 8.1 server, Dedupe + compression ratio is amazing, Ingest seems good, directory pool ingest appears at least double what it would be on a Disk / File stgpool (We tested it multiple times and couldnt test raw LV disk pools because raw LV's > 2TB didnt work [How Very Agile]). Even so we still looking to move everything over to 8.1.x ASAP. Once again however we have no idea if the same expiration performance issue still exists in 8.1. Like IBM because we only have 10's of thousands of objects on that server and IBM have no clue, or at least are not admitting to one, why we have an issue.

Share This Page