New ECC 6.0 system on z/OS - DB2 - good choice?

Question

Hi
   We are considering a new ECC 6.0 system on z/OS - DB2.  Any experiences with the advantages/disadvantages of this platform would be most helpful.
Thanks in advance.
Mike

Answer 1

Omer certainly has more experience with DB2 for z/OS and running SAP on it. He has written lots of great articles on ittoolbox that have been really helpful. In response to his post:
1. rdisp/wp_auto_restart is defaulted to zero, meaning that SAP will never automatically restart a work process. SAP note 101717 (which details how/why to change the default) says "The solution described here should only be used if all other options are exhausted since this is not an elimination of the actual cause of the problem but only a workaround.". I have not personally experienced needing to change this parameter from the default outside of DB2 for z/OS. It is recommended in the SAP for DB2 z/OS Admin Guide to set this parameter to the equivalent of 1 day in seconds. This would seem to acknowledge either a known and unfixed memory leak in DB2 for z/OS (up to and including v9), or is perhaps a precaution because of the 2 gig thread storage limit. As I stated before, it adds no value and causes useless reconnect information to be put into the SM21 system logs.
2. I think perhaps our issue with extents is because our storage system was not setup from the beginning to enable extent constraint relief. Setting the secondary extent quantity to a sufficient size for each tablespace is certainly one way to ensure that extents don't become a problem. With over 70,000 tables in ECC 6.0, even trying to manage 1% of the tables this way could be quite time consuming. Setting ZPARM MGEXTSZ to the SAP recommended value of yes allows DB2 to use the sliding algorithm and make each additional secondary extent bigger and bigger. Even so, we've had surprises (and thanks to Murphy usually off-hours) where there was still plenty of space left on our DB2 volumes but the total number of extents for a particular dataset or the total extents on a non-full volume exceeded the maximum. All that really says is that SAP on DB2 for z/OS appears to require more careful storage monitoring than on other platforms. It does allow for more flexibility, however.
3. Being able to manage individual tables and/or tablespaces is an advantage, though it does not come without the cost of additional overhead for the DBA. As for restoring and individual table, this is certainly possible but it would be best practice to work with SAP support to make sure all table dependencies are resolved and that data integrity is maintained when restoring an individual table. The DBA should not be expected to know about all of the table relationships with the 70,000 tables in ECC 6.0. That would seem to limit the advantages of an individual table restore.
4 & 5. I don't have a lot of experience with virtual memory monitoring on z/OS, but I can understand why it would have vastly superior capabilities compared to other platforms. When memory is expensive (as in thousands of dollars per gigabyte) and when DB2 still has some components which are restricted to 2 gig, it absolutely makes sense to have very detailed tools to manage memory usage.
Regarding sizing... I'm sure that mistakes are made quite often regardless of platform. It was exactly my point that it does not usually add significant cost to increase the resources on commodity hardware. My experience has been that commodity hardware vendors usually size the hardware too big anyway. Whether that is to allow some flexibility or simply to increase their sales, I am not sure. Contrast that to this recent success story for SAP on zSeries:
http://www-01.ibm.com/software/success/cssdb.nsf/cs/STRD-7NGMA9?OpenDocument&Site=gicss67sap&cty=en_us
"Colacem had to come up with more money for the upgrade - but IBM offered it to us at a price that we regard as very fair"
This customer had to upgrade to a Z10 after their Z9 ran out of gas, right in the middle of their first SAP implementation. I can only guess that the additional cost was not insignificant.
6. Thus far we have not experienced any strange problems with other databases and SAP, but we are using database versions that have been certified by SAP for 4+ years. In fairness though, we're not a huge implementation with individual tables in the terabytes.
Being on a platform with a small percentage customers has its disadvantages in trying to get product changes made as well. As an example, where is the Adobe Document Services support for Linux on zSeries? I know of at least one other customer that wanted this. Although adobe is now available for other 64bit platforms that run SAP, it is still not available for Linux on zSeries.
There is also the issue of third party SAP partners (Vertex, BSI, SAP's own WWI product) and the platforms they support. Very few support Linux for zSeries, so there will be additional commodity hardware servers in the datacenter. That results in the added complexity of supporting more platforms.
The one area of concern I do have about running SAP on a non-zSeries platform is the quality of SAP support for other platforms. The zSeries SAP support team is phenomenal and I can't say we've gotten even close to the response times or the quality of answers for non-zSeries related OSS messages.
All that said, I am just offering one person's experiences and opinions. Obviously I am not overly impressed with the value delivered vs the cost of zSeries.
Brian