For instance, detailed design and program specifications are crucial for application managers and developers to effectively develop processing logic. However, in many instances, business requirements tend to arrive late or change frequently, causing significant disruptions and cost overruns as developers scramble to adjust.

The best application managers I’ve encountered have shielded their developers from such chaos, recognizing that incorrect or incomplete specifications only exacerbate the confusion over the business issues. They prioritize clarity in requirements, understanding that no specifications are preferable to incorrect ones.

Moreover, adept application managers skillfully balance legacy system maintenance with system improvements, all while operating within limited budgets and striving for efficient project delivery without compromising code quality or testing protocols.

An exemplary process I witnessed involved generating test data from unique and common production data with complex relationships and anonymizing it through unique filters and processes specific to the company. Db2 environments offer advantages in this regard, as their unload utilities and SQL processes enable swift data generation. SQL statements can be tailored and leveraged with these Db2 utilities to extract different parts of production data and match them with other test data to mirror complex business relationships.

Additionally, Db2 databases excel in extracting complex customer, product, and shipping scenarios with a single SQL statement. This extracted data can then be seamlessly migrated and transformed into test cases for parallelism and concurrency testing, utilizing parameters within the Db2 environment. Such practices ensure thorough testing and validation of application functionality without compromising on data integrity or security.

Application Hardware

Application managers often prioritize other tasks over discussing computing hardware. They are focused on developing, maintaining, and ensuring the functionality of applications. To engage application managers in discussions about hardware, it’s crucial to demonstrate how Db2 optimizes/leverages hardware which can enhance application performance and reduce costs.

For instance, highlighting the benefits of Db2 hardware assist, compression techniques, SQL enhancements, and AI capabilities can illustrate how hardware optimizations can lower chargeback costs and decrease transaction or batch cycle times. Making the Db2 hardware discussion tangible by showcasing significant cost reductions and performance improvements can encourage application managers to consider analyzing application hardware optimizations more deeply.

When delving into Db2 application hardware assist, it’s essential to assess the cost of running applications within the Db2 environment. Determining whether applications run on commodity hardware or utilize specialized engines like zIIP engines can reveal opportunities for cost reduction. Implementing compression can save huge amounts of storage costs, reduce daily backup/recovery times, and enhance application parallelism opportunities. Adjusting Db2 parameters, leveraging zIIP engines, or optimizing SQL queries can lead to quick wins in reducing costs; and improve overall application run-time performance and overall application runtime costs.

Configuring Db2 buffer pools to cache critical or frequently referenced data, especially for web transactions, can significantly optimize data retrieval speed. For example, separating reference data within Db2 buffer pools can expedite data lookup processes in web transactions, resulting in substantial time savings for millions of daily transactions.

Another effective strategy is to set up materialized query tables (MQTs) for various reporting needs, such as daily, weekly, monthly, or quarterly reports. MQTs allow for efficient retrieval of business financials across different reporting criteria, minimizing table and index scans within query environments. This approach is particularly beneficial for application managers managing diverse reporting schemes from different types of departments and a wide variety of user communities.

For instance, in a large-scale data warehouse with billions of rows, implementing a series of refreshed MQTs reduced reporting batch cycle times from four hours to just 20 minutes. This transformation required additional storage hardware, defining MQTs within the environment, and ensuring accessibility for all relevant users and processes, such as Cognos, MicroStrategy and Business Object users and their application developers. Each user community needed the name from different keys and leveraging Db2 MQTs provided excellent application performance. The query performance was enhanced even more when the MQTs were redefined with dedicated buffer pool memory allocations. Such success stories demonstrate the tangible benefits of Db2 hardware optimizations and encourage application managers to prioritize hardware discussions for improved application performance and cost-effectiveness.

Application Software

The true application performance advantages offered by Db2 z/OS and Db2 LUW platforms lie in the Db2 software itself. Over the years, IBM’s Db2 software has continually evolved, incorporating new functionalities, features, and cutting-edge technology. Initially a simple relational SQL database, Db2 has expanded its capabilities to include a myriad of features that many specialty databases are only beginning to explore.
For instance, Db2 boasts advanced SQL functionalities like complex SQL Materialized Query Tables (MQTs) and a comprehensive set of SQL standards and functions such as OLAP RANK and DENSE RANK. Moreover, it offers a range of built-in features including columnar database capabilities for analytical and OLAP tasks, Time Series capabilities, CLOBs, BLOBs, and object-oriented complex data types. Additionally, Db2 supports NoSQL text structures, user-defined functions (UDFs), and user-defined data types (UDTs), enabling extensive customization to suit diverse business application requirements.

Recent developments in Db2 include optimizations for vector data storage and integration with blockchain technology, thus enhancing data integrity and scalability for decentralized applications. Furthermore, Db2 seamlessly integrates with leading cloud providers like Amazon and Google, facilitating vertical and horizontal scaling for transactions across geographical boundaries.

Db2 is renowned for its openness and versatility, offering language interface drivers for emerging programming languages such as RUST and Python, as well as support for machine learning and many other application development languages. Additionally, it provides robust support for web services, JSON calls, stored procedures, and XML functions, ensuring compatibility with a wide range of interfaces and languages. In cases where challenges arise in utilizing these functionalities, Db2 offers the flexibility to set up CALLed procedures or modules, enabling seamless integration with applications written in languages like C, C++, or Java.

Despite the myriad capabilities of Db2, discussions around database platforms often overlook its comprehensive features. Many consultants, including those from prominent consulting and accounting firms, may not fully grasp the depth of functionalities offered by Db2 compared to newer stove pipe database solutions like NoSQL or data lakehouse implementations. It’s essential for organizations to conduct thorough evaluations, comparing openness, features and functionalities across different platforms to ensure their decisions align with their specific requirements.

Db2 z/OS and Db2 LUW platforms stand out for their extensive open protocols, functions, and features, making them ideal for modern development and production systems. These Db2 platforms’ features offer unparalleled flexibility, allowing integration with any application type or language, and can be seamlessly configured into any required web service or business process while providing excellent application price performance.

Applications – Strategies

Throughout my consulting career spanning decades, the majority of my performance reviews and application enhancements have revolved around engaging with application management. It’s crucial to immerse oneself in the application portfolio, comprehending the business implications of potential enhancements and improvements.

Understanding all factors within the application infrastructure and their impact on business operations is paramount. Allowing application managers and stakeholders to provide feedback on proposed changes fosters collaboration and ensures alignment with organizational objectives.

In one notable performance enhancement project, we significantly improved analytics reporting for daily receipts. By optimizing database structures and transitioning to Materialized Query Table (MQT) DB2 table definitions, one business category analytics reporting time was reduced from over an hour to under 5 minutes, marking a significant success at a greatly reduce application SQL cost. However, this improvement triggered unforeseen challenges, as the shift in the analytics schedule affected batch cycles, causing CPU capacity issues, database locking conflicts, and backup time conflicts with other applications that started earlier in nightly schedule. Addressing these challenges required collaboration with various stakeholders, extending the scope of the performance tuning contract.

When engaging with application managers, identifying whether an application is CPU-bound or IO-bound is essential. Analyzing CPU consumption, execution time, and transaction volume provides insights into the nature of application issues, guiding subsequent analysis and optimization efforts. Combining CPU-bound and IO-bound programs strategically can yield overall performance improvements.

Another valuable analysis technique is Cyclomatic Complexity analysis of the application portfolio programs. This practice involves identifying decision points in the code to pinpoint areas with excessive SQL or file calls. By streamlining these processes through consolidation or separation, overall performance in terms of elapsed time, IO, and CPU efficiency can be enhanced. Working with the data governance and application development these Cyclomatic Complexity analysis can quickly identify lengthy logic chains that can be opportunities to consolidate and optimize application decision chains.

Also, this analytical approach proves invaluable details for identifying areas where calculations, SQL statements, or logic affecting specific data elements occur. Such insights empower application management to identify duplicate logic, prioritize optimization efforts effectively, ensuring optimal performance and resource utilization across the application portfolio.

Application – Templates

Analyzing application performance has always posed challenges, underscoring the importance of employing a standardized process to understand the application, its performance attributes, and specific performance metrics. This standardized approach should align with the client’s infrastructure, testing procedures, and performance verification processes across testing, QA, and performance test environments.

Collaborating with existing client staff is essential for navigating entry into these environments and understanding the exit criteria necessary for successful testing. Moreover, client staff can provide valuable insights into the test data required for performance verification. Ensuring active engagement from the management team throughout the project facilitates communication with stakeholders, addressing their concerns, and eliciting collaboration and feedback from all parties impacted by performance improvements.

Close collaboration with client staff also entails integrating analysis into their chosen development methodology, whether it’s scrum, agile, waterfall, or another approach. Having worked with various clients, I’ve encountered many different development practices, each with its own merits. The effectiveness of these methodologies depends on the IT staff’s proficiency in implementing them and their ability to work with real-world complex test data to address business challenges.

Each development process comes with distinct documentation requirements and standards, underscoring the need to meticulously adhere to these guidelines to expedite the project through various testing, QA, and performance test environment processes. This ensures that time is spent optimizing the application rather than navigating infrastructure-related paperwork. By following a standardized process and fostering close collaboration with client stakeholders, application performance improvements can be efficiently implemented, yielding tangible benefits for the organization.

By leveraging Db2 utilities, customized SQL options, a myriad of interface options; and specialty JSON, time series, and binary data stores, Db2 provides a comprehensive set of options for application development and application solutions. These many options and their performance options provide great performance while optimizing the costs better than any other DBMS available.

The post Db2 Application Performance Advantages over Other DBMSs appeared first on Dave Beulke.

Throughout my career, I have had the privilege of working with various clients on projects involving the design of new critical systems, re-platforming, or improving legacy systems using new database technologies. My experience spans leveraging a variety of platforms—mainframe, UNIX, Linux, and Windows—to manage transitioning from VSAM to Db2, IDMS to Db2, IMS to Db2, SQL Server to Db2 LUW, SQLServer to Db2, Oracle to Db2 LUW, and Db2 z/OS to Db2 LUW. All of these conversions to the Db2 platform resulted in reduced software costs, lower operational expenses and improved overall performance. One particularly significant project involved developing a system during the COVID-19 pandemic that processed tens of billions of transactions daily and was completed in only 36 days.

In all these new development, re-platforming, or improvement efforts, it was crucial to analyze and optimize the underlying processing structure through detailed discussions before starting any coding. In some original systems, processing was more record-based rather than relational SQL set-based. By set-based, I mean utilizing large groups of data or SQL Result sets for efficient data handling.

It is essential that management and architecture teams understand that the cost of design encompasses not only processing but also re-engineering data design and streamlining business logic, as well as analyzing development costs, maintenance costs, and time to market for various aspects of application architecture. Understanding all proprietary software costs, specialized complex logic, and the overall environment’s requirements is critical. It’s also vital to understand how the system will be developed, enhanced, maintained, and how open it is to other interfaces or any microservices that might be necessary in the future. All these aspects significantly impact the ongoing viability of the overall system, providing an impetus to migrate to a new architecture.

One of my many successes was converting a 20+ terabyte legacy VSAM system to Db2 for a healthcare client. This VSAM system supported a nationwide database of healthcare information and had been in place for over 25 years. Management was concerned the conversion to Db2 would lead to substantial costs increases. They were especially apprehensive after a previous failed UNIX conversion project by a Big 5 Accounting firm had gone over budget and never passed acceptance testing.

To address these concerns, we analyzed the code base of the current VSAM application and the necessary I/O patterns. The architecture was then redesigned with a main group of tables as the primary source of information. We distilled and summarized this data into a series of Db2 materialized query tables (MQTs) that broke down the information into coverage areas, treatment areas, and business districts. This main information was cross-referenced and broken down by time scale to reflect weekly, monthly, quarterly, and yearly reporting periods necessary for compliance reporting.

By leveraging Db2 and its SQL set-based approach, we dramatically improved the system architecture and optimized processing. The new Db2 system design immediately leveraged data compression saving about 70% on storage expenses. The Db2 system ran much more efficiently than the original VSAM system by getting more data per I/O, saving the corporation significant CPU resources in daily operations, as reflected in the IT chargeback for overall operations. These Db2 advantages also reduced ongoing maintenance expenses because of the overall compression and more data per I/O. Db2’s relational SQL set aspects provided substantial financial savings as groups of SQL sets of similar data could be processed together and more efficiently.

Another significant project success was developing a high-performance system that impacted people nationwide during the COVID-19 pandemic in just 36 days. For this project, we utilized our existing Db2 main database for customers, which was critical to all our other processing supporting the business. We defined a new subset of tables to store the new types of information and ensured that all key business systems from our existing systems were included.

To minimize the manual software coding required for the new business requirements, we consciously chose to use SQL, Unload, Db2 utilities, and SYNCSORT to reduce manual coding, maintenance, and complexity within the processing code base. We analyzed the processing requirements and used a pattern to ensure we only processed data once per business key. For instance, the customer ID was used once to determine eligibility and admissibility for further daily processing, and financial eligibility and admissibility were processed through another SQL utility.

Each subsequent process had distinct processing criteria and a separate business aspect to evaluate the customer, their eligibility, and admissibility for inclusion in the final process. By separating the business logic into distinct department-dependent processes, each criterion could be developed independently and in parallel with the respective business department and application team. This approach ensured that all detailed business considerations were addressed promptly.

By employing parallel development, acceptance testing, and business criteria evaluation, the entire organization was able to quickly implement this system, processing billions of rows a day, in just 36 days. This achievement was a significant success and much faster than a similar system developed seven years earlier, which took almost double the time (59 days) to complete.

Understanding the financial impacts of Db2 architecture design alternatives is crucial. By leveraging Db2’s technology and doing detailed analysis, redesign, and optimization, significant improvements in system efficiency and cost-effectiveness can be achieved. The examples from my experience illustrate the importance of thoughtful planning and execution in architectural design during re-engineering efforts to gain substantial benefits for the organization.

Hardware Advantages of Db2

When analyzing hardware architecture, it is crucial to understand all components of the existing hardware and the proposed hardware for your system. With numerous options available today, including specialty hardware, storage devices, CPU chips, and GPU chips, it is vital to communicate requirements effectively. This ensures that the overall system architecture aligns with the general, specialized, or binary AI-related processing needs. Both processing and hardware analyses must be aligned to ensure that network capacity, storage I/O rate, and necessary computing power are readily available within the configuration, regardless of whether the architecture is based on z/OS, Linux, UNIX, Windows, or cloud implementations. It is also vital to align the compute hardware (CPUs and GPUs) to the processing model, the data to the storage model, and the program execution type to the memory model whether it is an AI or transaction type application.

To minimize architecture hardware costs, many systems are now built on commodity-based cloud architectures. These cloud architectures are advantageous for placing computing and I/O activity on the appropriate hardware, where the synchronicity of application processing parallelism, throughput, and CPU types match up. Analyzing the number of virtual servers their memory requirements, physical servers, and the amount of CPU or GPU engines available for your processing environment is essential. Matching the amount of memory for your Large Language Model (LLM), its related I/O with the number of I/O channels and storage to dynamic or archival type devices is critical to optimizing elapsed time processing and minimizing the overall hardware cost for the architecture.

Understanding the LLM and the I/O performance level needed to support transaction or processing flow levels ensures that applications complete their dynamic, batch, or online processes in a timely fashion. Processing large data caches for LLMs, sorting large result sets, utilizing parallel processing, and having physical memory, fast storage, efficient I/Os, GPUs, and enough CPUs are all critical in today’s complex computing environments. Leveraging everything effectively requires a significant number of storage devices to aid in application parallelism. Optimizing these activities with proper hardware is vital, and it is important to address these topics early in discussions to ensure everyone understands their interdependence and importance for overall performance.

Discussions about hardware-related issues are also crucial for disaster recovery planning. Modern cloud environments, along with LUW and z/OS environments, offer the capability to mirror storage locally, remotely, or stage for a concurrent environment ready for standby High Availability Disaster Recovery (HADR) capabilities. Disaster recovery can be challenging because achieving fast Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) often requires increased hardware investment. Working with several clients, I implemented data mirroring and data reflection within the storage devices themselves. These devices mirrored data updates to a remote data center running in parallel. However, as business transactions increased, the I/O and CPU rates also increased, necessitating hardware upgrades for the disaster recovery site. Increased transaction rates impact RTO and RPO, and businesses must understand the hardware architectural requirements to accommodate these changes.

In the healthcare client example mentioned earlier the architecture was redesigned with a main group of tables as the primary source of information, with the distilled and summarized data kept in a series of materialized query tables (MQTs) that broke down the information into coverage areas, treatment areas, and business districts. This main information was cross-referenced and broken down by time scale to reflect weekly, monthly, quarterly, and yearly reporting periods and then optimized within Db2 with dedicated buffer pool memory support for the fastest data access available for the most referenced data.

Leveraging Db2 storage, Db2 buffer pool memory allocations, and z/OS zIIP CPU parallel processing models, Db2 and its SQL set-based access dramatically dropped the overall cost of retrieving this data and this summarized data.

Since the Db2 MQTs summarized data was referenced 100s of million times a day throughout a wide number of financial and patient applications, the improved cost performance provided a dramatic cost reduction for the overall related IT applications and operations.

Understanding these Db2 hardware optimization opportunities and Db2 attributes and having detailed discussions with architecture teams ensures that the hardware can handle the business transaction rate and meet disaster recovery time and recovery point objectives. These Db2 hardware architectural advantages do not exist in other DBMSs and can provide tremendous benefits to ensure the system’s overall performance and reliability.

Software Advantages of Db2

When analyzing the software architecture within an application, it’s crucial to identify the unique attributes that can leverage the Db2 hardware and the Db2 operating platform. In Db2 z/OS and LUW environments, numerous software parameters and processing options that do not exist in other DBMSs can capitalize on memory, storage, CPU, GPU, or general processors available in specialized hardware and cloud environments.

Initially, parallelism was manually designed and built into systems to manage huge workloads by separating files and running multiple job streams concurrently. For instance, one of the first systems I implemented utilized a matrix of parallelism and separate processing job streams along Db2 tablespace partitioning range limits. However, with advancements in systems, such manual design and matrix of jobs, is no longer necessary and can be integrated into the database using specific z/OS Sysplex, UNIX system, application parameters and/or specific Java program Spring Batch configuration settings.

Understanding the operations environment, hardware supporting it, and the software configuration is vital to map out workload capacity across physical device hardware capacity limits and software configuration parallelism settings. In today’s web transaction environments with millions or billions of transactions per day, balancing the workload across cloud and hardware software configurations is essential. Setting up a balanced Spring Batch environment with the right chunk size and commit scope is crucial for application flow. Moreover, optimizing settings within Java JVM and overall java garbage collection and memory allocations within the JVM are vital to maximize processing performance.

While testing capacity planning and performance settings within the Spring Batch environment during one client project, we encountered a challenging situation. A 10-parallel processing environment was set up using Spring Batch configurations to distribute workload across twenty partitions within a multi-hundred partitioned database environment. However, issues arose because the Java processing chunk size didn’t match partition ranges, resulting in database locks due to misaligned unit of work with the partitioning scheme. Additionally, Spring Batch chunk size needed optimization to minimize garbage collection within the execution of a single unit of work.

Another challenge was determining the number of parallel processes to kick off simultaneously within the Spring Batch Java environment. Processing against a large multi-billion row database with heavy partitioning posed limitations even in cloud environments. Java and other languages perform best with dedicated CPU, GPU processors, memory, and storage allocated to their processing environment. Multiple web servers running multiple Java processes concurrently strained IO and CPU capacities and needed further resource allocation to optimize their runtimes. Optimal capacity planning involved dedicating maximizing CPU processor power to JVMs and sub-stacks of the parallel processes.

Adjusting parallelism in Db2 z/OS and Db2 LUW to match the hardware supporting the environment is crucial. In Db2 for z/OS, this can be done at the system level, within parallelism utilities’ parameters, and SQL written within the application. Close attention is needed to understand the number of z/OS no-cost zIIP processors available that can be utilized to eliminate any CPU charges for running parallelized workloads.

In several Db2 LUW performance reviews, it was discovered that parallelism was minimized or turned off within the OS or Db2 configuration. Verifying Db2 LUW Workload Manager (WLM) settings and optimizing sort workspace for parallelism and large sorts are essential for multiple programs running concurrently.

Many application architects overlook Db2 DB and DBM or sort settings, which are critical for optimizing system workload performance. Hence, discussions regarding software and parallelism settings are essential when discussing architecture performance objectives.

These architectural Db2 for z/OS and Db2 LUW hardware and software attributes are perfect for today’s huge business transaction or AI workloads. These Db2 architectural advantages provide dramatic processing elapse time improvements and huge possible cost savings over any other DBMS available today.

The post Db2 Architectural Price Performance Advantages over Other DBMSs appeared first on Dave Beulke.

The speech highlighted my decades of consulting experiences in optimizing Db2 z/OS and LUW environments, systems, and applications. I focused on the intricate details of Db2 financials, hardware, and software costs when engaging with the C-Suite, architecture, and application development groups, unveiling the often overlooked but sustained cost benefits of leveraging the Db2 family product line.

The article below discusses how to interact with the C-Suite executives, and a few stories demonstrating how my team saved millions through the optimization of the Db2 environments, systems, and applications. I highlight the many financial, hardware, and software benefits Db2 offers. The C-Suite needs to understand how these benefits can be leveraged in their environments to +save potentially millions of dollars of unnecessary expenses.

C-Suite Financials

When engaging with C-suite executives, the first thing you notice is their limited time. They face immense pressures due to their extensive responsibilities and multifaceted political pressures from various angles, including different IT departments, budgets, industry trends, competition, and ultimately, the Board of Directors.

In my consulting assignments, I was often tasked with improving the performance or reducing the costs associated with the Db2 environment, systems, and application processing. When speaking with C-suite executives, it is crucial to be straightforward, direct, adoptive of their ideas, and attentive to both what they say and how they say it. By paying close attention, you can identify their most critical issues within the major pain points, systems, applications, or personnel and determine the best ways to address them.

For C-suite executives, the primary concern is often financial. They might be spending excessively on the Db2 environment, whether it’s z/OS or LUW. Alternatively, a single application could be causing performance problems and driving up costs.

During one particular assignment at a large insurance company, the CEO and CIO were using a chargeback system for computing costs within various departments. The Db2 costs were being blamed for a significant portion of these chargeback costs. As part of the assignment’s statement of work, we were instructed to reduce application and Db2 system expenses as much as possible.

This organization had a costly habit of performing nightly reorgs for some tables and weekly reorgs for the majority of their tables. This practice was expensive and significantly increased chargeback costs. We analyzed these activities and the associated SQL usage, ultimately implementing criteria to reduce the reorg frequency to once a month for some tables and even longer for certain reference tables. Additionally, SQL index usage analysis and subsequent reduction of indexesgreatly improved application performance. These changes significantly reduced the overall Db2 environment costs, benefiting both the application system and the IT department, and made the CEO and CIO extremely pleased.

However, the dramatic drop in IT chargeback costs for the Db2 applications created a major issue with the client chargeback system. The newfound efficiency of the Db2 environment highlighted the inefficiencies of other systems like IDMS, VSAM, IMS, and other NoSQL databases. This Db2 optimization disrupted the chargeback ratios used to cover IT spending, necessitating a readjustment of the entire IT budget both for the z/OS and the UNIX, Linux systems. I later learned that the significant Db2 cost savings caused many architects to abandon or reexamine their efforts to leave the mainframe causing friction among several departments outside of IT.

Previously seen as a burden, the Db2 systems were now lauded for their processing efficiency. The optimization of the Db2 environment demonstrates how to quickly add value to the Db2 z/OS and LUW environments by reducing costs and improving processing efficiency, albeit at the risk of unsettling other areas. While the CEO and CIO were delighted with the reduced costs, they were also troubled by the exposure of issues within their chargeback systems. It’s a clear case of no-good deed going unpunished.

C-Suite – Hardware

When discussing z/OS and LUW computing with C-suite executives, it is crucial to emphasize how Db2 can leverage hardware for improved cost and performance. Given the average tenure of CIOs is around two to three years, ensuring they quickly grasp the benefits of mainframe z/OS hardware, especially zIIP processors, is vital. Equally important ensuring they allocate sufficient computer hardware, CPU, memory, and storage for the Db2 LUW systems.

In the early years of Db2, zIIP, and zAAP processors had to be purchased and configured separately within the z/OS environment. However, with the introduction of the Z16 mainframe, many zIIP processors are pre-configured and can be dynamically activated to handle peak processing loads. This capability enhances both performance and the price-performance ratio of the mainframe environment. zIIP processors can also significantly reduce costs by enhancing parallelism in Db2 utilities and Java process applications.

For the LUW environment, it is essential to optimize the operating system, hardware, number of engines, and memory allocation. C-suite executives must understand that Db2 performance relies heavily on caching for complex SQL, BLU columnar data store processing, and sorting query results. Using outdated or mismatched hardware, or running too many VMs within the Db2 LUW environment, can severely impact performance and cost efficiency. This principle also applies to cloud environments; ensuring adequate hardware, CPUs, memory, storage, and sort space is crucial. Sharing resources across too many virtual machines or critical workloads can degrade performance.

One notable example from my consulting experience involved early process optimization and parallelism within Db2 utilities. During an initial test, we enabled all available parallelism in both SQL and Db2 utilities. When we ran an Unload utility against a highly partitioned database table, the parallelism initiated over 40 subtasks and utilized more than 20 zIIP processors within the z/OS complex. This test, fortunately conducted late in the afternoon, avoided any negative impact on online systems.

Recognizing the impact of this parallelism, we collaborated with system programmers and Db2 representatives to limit the degree of parallelism one utility job or SQL statement could leverage within the overall Db2 Sysplex environment. In an eight-way data-sharing Db2 system, parallelism parameters had to be finely tuned for the entire Sysplex complex. Without this customization, a series of utility jobs could monopolize the main CPU and all zIIP processors across the Sysplex, potentially disrupting other operations.

It is imperative to communicate to C-suite executives the substantial cost savings achievable through the effective use of hardware, memory, and specialty zIIP processors. Properly configured and managed, these no-charge-back zIIP processors can offer significant price performance improvements and reduce elapsed processing times dramatically. In the scenario described, the use of zIIP processors resulted in multi-million-dollar savings in CPU chargebacks and reduced the overall batch processing window by several hours for client applications.

When engaging with C-suite executives, focus on the tangible benefits of hardware optimization, particularly in the context of z/OS and LUW computing environments. Highlighting real-world examples and potential cost savings can help convey the importance of these technological investments and configurations.

C-Suite – Software

When engaging with C-suite executives, it’s crucial to discuss the software advantages of Db2 platforms over other industry DBMSs. Both z/OS and LUW have built-in SQL functionalities that significantly improve cost performance and reduce query elapsed time. These SQL functionalities are quickly leveraged with Db2’s new AI capabilities for discovering customer similarities and gaining insights into customer behaviors and trends for better marketing and sales campaigns.

Each Db2 release introduces new functions that make the platform more cost-effective, efficient, and capable of enhancing overall application performance. Communicating these Db2 software improvements is essential when considering upgrades to the next version or function level within Db2 environments.

It’s critical that Db2 teams, especially application developers, understand how to leverage new functions and features within Db2 platforms. For example, in the early days of Db2 LUW, OLAP functions were vital for processing efficiency. Properly configuring sort work areas to prevent sort overflows continues to be crucial for overall performance. However, even today, many Db2 LUW systems suffer performance issues because they do not adjust or closely monitor the sort overflows, SQL index utilization, or the default Db2 optimization level. Simple performance improvements can be achieved by tuning related SQL optimization settings, SQL timeout variables, and locking configurations in the Db2 LUW DBM and DB environment configurations.

In the z/OS environment, understanding SQL improvements is equally important. For instance, leveraging universal table spaces and use of INCLUDE column indexing capabilities significantly enhances application performance. With Db2 13 for z/OS, it is essential for C-suite executives to recognize the AI capabilities built into the platform so that application developers can take adavantage of these advanced functions as soon as possible.

A real-world example of the benefits of leveraging Db2 functionalities involves a client facing performance issues with end-of-day closing and reporting on Db2 LUW. The concurrent sort requirements for numerous queries were causing sort overflows and memory issues. By rewriting queries to use Db2 OLAP functions, updating optimization levels, and staggering query start times, we reduced processing time from four hours to about 15 minutes. This quick win using Db2 OLAP functions was met with great enthusiasm and led to further adoption of these functions.

Similarly, the new AI functions in Db2 13 for z/OS, such as semantic clustering and similarity functions, offer significant potential for improving application performance and quickly gaining customer insights. These built-in functions enable application and database designers to perform semantic commonality queries, detecting normal customer characteristics and behaviors.

Optimizing Performance with Materialized Query Tables (MQTs)

Another successful approach involved creating several materialized query tables (MQTs) for several clients. These MQTs provided daily, weekly, monthly, quarterly, and yearly reports that previously took several hours to generate. With MQTs, these reports were produced in just 15 minutes, resulting in substantial cost savings and eliminating the need for additional hardware to address end-of-day processing issues.

When talking to C-suite executives, it is important to highlight the significant financial benefits of using the hardware and software advantages of Db2 platforms. Emphasizing the hardware configuration flexibility, impact of new functions and features, as well as providing detailed examples of performance improvements, the value of Db2 technological investments can be conveyed dramatically. By showing them how to leverage the full capabilities of Db2, a consultant can help organizations achieve millions in cost savings over other DBMS platforms, enhance performance, and leverage new AI capabilities to unlock valuable customer insights from their data.

The post Important Db2 Cost Saving Features the C-Suite Needs to Know appeared first on Dave Beulke.