Greetings from UKGSE, Wednesday, Day 3
I started the day by attending two excellent sessions from Peter Enrico. The subject of the first session was Db2 Use of Independent Enclaves and How to Measure Usage. Every Db2 system administrator and every WLM administrator should get hold of a copy of the excellent slide deck. Peter provided clarity on the subject with important recommendations. Some takeaways: DIST system address space should be classified the same as DBM1 and MSTR; use SMF Type 72 to look at CPU consumption specific to DIST system address space which is very little; SMF Type 72 accumulates all the CPU for the CPU for an address space and if it creates the enclave gets charged with the total CPU for the independent enclave; WLM ignores the service class and importance level of the SPAS (stored procedure) address space; put SPAS into a separate service class away from DBM1 and MSTR for measurement purposes.
Peter introduced and discussed Db2 APAR PH34378 which changed the behavior of independent enclaves for High Performance DBATs. Most customers exploit service classes with multiple periods for distributed application workloads. After applying PTF for the subject APAR now have many bundled transactions in long running enclave which will automatically degrade to a low period. It will now be challenge for the WLM administrator to identify distributed application workloads which are exclusively using High Performance DBATs. Peter offered a pragmatic solution: use a single service class with importance x running both regular workload and High Performance DBAT workload, with period 1 having a short duration with a response time goal, and with period 2 having a velocity goal.
The second session from Peter Enrico was about Parallel Sysplex and Data Sharing Retrospective and Lessons Learned. This was time for me to reminisce on my own personal history between 1992-1995 when I worked as the Performance Team Leader within Db2 for z/OS Development for Data Sharing and Type 2 Index Manager. Many lessons learned by me from performance measurements, improvements recommended and successfully implemented, and the evolution of the technology since then. In hindsight the best years of my working life and very special. Multi system data sharing whilst maintaining data consistency has been a huge success. Only disappointment has been seeing some customers performing insane unnatural design acts to reduce software cost at the expense of compromising availability.
Next session I attended was about Db2 and DORA (Digital Operational Resilience Act). This session discussed examples of system and Db2 vulnerabilities, and provided some recommended best practices beyond configuration ad security controls. They introduced and discussed the anatomy, before and after a ransomware attack. This is very a important use case to be prepared for and to recover from. Such incidents are painful but thankfully rare. My own personal view is that slow logical data corruption caused by software or microcode defect and/or operational is more common, more difficult but are still rare. I have been involved historically in a number of such incidents. They are horrible, leading to mass data recovery to previous point in time when things were good, and involve some degree of data loss as a result of page regression or bad log records.
That’s all for today.