DB2DART is a tool that allows DBAs to inspect, format, and repair DB2 databases and objects. It can be used to handle storage reclamation issues by lowering high water marks, detect and repair index corruption, extract data from corrupt tables, and remove backup pending states. DB2DART provides granular analysis at the database, tablespace, and table level and its repair capabilities save DBAs from having to call support or restore from backups in many cases.
This document provides an overview of the DB2DART tool and examples of how it can be used to analyze and repair issues with DB2 databases and tables. Key points include:
- DB2DART is an offline tool that can be used to check the architectural correctness of databases and investigate problems like data corruption.
- It allows inspection of entire databases, specific tablespaces, tables, and indexes. Examples demonstrate using it to check for index corruption and reduce high water marks.
- The document shows the command syntax and provides a sample report output. It also provides steps to use DB2DART to export table data in delimited format when the original data is corrupted.
Solving the DB2 LUW Administration DilemmaRandy Goering
As a DB2 LUW Database Administrator you are probably reluctant to or prohibited from granting your users* these permissions because doing so gives them permission to other DB2 administrations tasks like stopping the database. If your users are not allowed to do these tasks then who is? Most likely, you, as the DBA will perform these and other administrative functions for your users. Would you like a way to eliminate these tasks from your daily to-do list? This presentation will discuss how to externalize specific administrative tasks with Stored Procedures, Federated procedures, Administrative SQL routines, and views.
Optimizer is the component of the DB2 SQL compiler responsible for selecting an optimal access plan for an SQL statement. The optimizer works by calculating the execution cost of many alternative access plans, and then choosing the one with the minimal estimated cost. Understanding how the optimizer works and knowing how to influence its behaviour can lead to improved query performance and better resource usage.
This presentation was created for the workshop delivered at the CASCON 2011 conference. Its aim is to introduce basic optimizer and related concepts, and to serve as a starting point for further study of the optimizer techniques.
The document discusses High Availability Disaster Recovery (HADR) in DB2. It describes how HADR uses log shipping to replicate transactions from a primary database to a standby database. HADR supports three synchronization modes - SYNC, NearSync and Async - which determine how transaction logs are replicated. The document provides steps for setting up and configuring HADR, including required database parameters. It also discusses using reorgchk and runstats utilities to check for table/index reorganization needs and update database statistics.
This document discusses various DB2 database objects and utilities. It provides descriptions of storage groups, databases, tablespaces, tables, indexes, views, and the utilities for unload, load, reorganization, running statistics, and copy. It includes examples of creating and using these objects and utilities.
Best Practices For Optimizing DB2 Performance FinalDatavail
DB2 performance tuning and optimization is a complex issue comprising multiple sub-disciplines and levels of expertise. Mastering all of the nuances can take an entire career. Deploying standard best practices can minimize the effort to achieve efficient DB2 applications and databases.
This white paper outlines the most important aspects and ingredients of successful DB2 for z/ OS performance management. It offers multiple guidelines and tips for improving performance within the three major performance tuning categories required of every DB2 implementation: the application, the database and the system.
IDUG NA 2014 / 11 tips for DB2 11 for z/OSCuneyt Goksu
DB2 11 includes several new features such as global variables, the ability to alter partition keys online without impacting availability, selecting data from directory tables, dropping columns, auto-mapping of tables during reorganization, transparent archiving of data, enhancements to RUNSTATS utilities, and deprecated functionality. Some highlights include global variables that can be shared across SQL statements, altering partition limits online which sets partitions to AREOR status until reorganization, and dropping columns in tables without taking them offline.
Using Release(deallocate) and Painful Lessons to be learned on DB2 lockingJohn Campbell
This document discusses thread reuse using the RELEASE(DEALLOCATE) bind option in DB2, considerations for lock avoidance, and lessons learned on DB2 locking. It provides primers on thread reuse, the RELEASE bind option, lock avoidance techniques like commit log sequence numbers and possibly uncommitted bits, and the ramifications of lock avoidance for SQL. It recommends using programming techniques to avoid data currency exposures when using lock avoidance, and outlines how to identify packages that can safely be rebound with CURRENTDATA(NO).
This document provides an overview of the DB2DART tool and examples of how it can be used to analyze and repair issues with DB2 databases and tables. Key points include:
- DB2DART is an offline tool that can be used to check the architectural correctness of databases and investigate problems like data corruption.
- It allows inspection of entire databases, specific tablespaces, tables, and indexes. Examples demonstrate using it to check for index corruption and reduce high water marks.
- The document shows the command syntax and provides a sample report output. It also provides steps to use DB2DART to export table data in delimited format when the original data is corrupted.
Solving the DB2 LUW Administration DilemmaRandy Goering
As a DB2 LUW Database Administrator you are probably reluctant to or prohibited from granting your users* these permissions because doing so gives them permission to other DB2 administrations tasks like stopping the database. If your users are not allowed to do these tasks then who is? Most likely, you, as the DBA will perform these and other administrative functions for your users. Would you like a way to eliminate these tasks from your daily to-do list? This presentation will discuss how to externalize specific administrative tasks with Stored Procedures, Federated procedures, Administrative SQL routines, and views.
Optimizer is the component of the DB2 SQL compiler responsible for selecting an optimal access plan for an SQL statement. The optimizer works by calculating the execution cost of many alternative access plans, and then choosing the one with the minimal estimated cost. Understanding how the optimizer works and knowing how to influence its behaviour can lead to improved query performance and better resource usage.
This presentation was created for the workshop delivered at the CASCON 2011 conference. Its aim is to introduce basic optimizer and related concepts, and to serve as a starting point for further study of the optimizer techniques.
The document discusses High Availability Disaster Recovery (HADR) in DB2. It describes how HADR uses log shipping to replicate transactions from a primary database to a standby database. HADR supports three synchronization modes - SYNC, NearSync and Async - which determine how transaction logs are replicated. The document provides steps for setting up and configuring HADR, including required database parameters. It also discusses using reorgchk and runstats utilities to check for table/index reorganization needs and update database statistics.
This document discusses various DB2 database objects and utilities. It provides descriptions of storage groups, databases, tablespaces, tables, indexes, views, and the utilities for unload, load, reorganization, running statistics, and copy. It includes examples of creating and using these objects and utilities.
Best Practices For Optimizing DB2 Performance FinalDatavail
DB2 performance tuning and optimization is a complex issue comprising multiple sub-disciplines and levels of expertise. Mastering all of the nuances can take an entire career. Deploying standard best practices can minimize the effort to achieve efficient DB2 applications and databases.
This white paper outlines the most important aspects and ingredients of successful DB2 for z/ OS performance management. It offers multiple guidelines and tips for improving performance within the three major performance tuning categories required of every DB2 implementation: the application, the database and the system.
IDUG NA 2014 / 11 tips for DB2 11 for z/OSCuneyt Goksu
DB2 11 includes several new features such as global variables, the ability to alter partition keys online without impacting availability, selecting data from directory tables, dropping columns, auto-mapping of tables during reorganization, transparent archiving of data, enhancements to RUNSTATS utilities, and deprecated functionality. Some highlights include global variables that can be shared across SQL statements, altering partition limits online which sets partitions to AREOR status until reorganization, and dropping columns in tables without taking them offline.
Using Release(deallocate) and Painful Lessons to be learned on DB2 lockingJohn Campbell
This document discusses thread reuse using the RELEASE(DEALLOCATE) bind option in DB2, considerations for lock avoidance, and lessons learned on DB2 locking. It provides primers on thread reuse, the RELEASE bind option, lock avoidance techniques like commit log sequence numbers and possibly uncommitted bits, and the ramifications of lock avoidance for SQL. It recommends using programming techniques to avoid data currency exposures when using lock avoidance, and outlines how to identify packages that can safely be rebound with CURRENTDATA(NO).
DB2 12 introduces continuous delivery of new capabilities through function levels, simplifying migration to a single phase process. Explain tables must be recreated in DB2 12 format prior to migration. Application compatibility settings should be set to the target function level and packages rebound to enable new SQL features and optimize access plans.
DB2 10 & 11 for z/OS System Performance Monitoring and OptimisationJohn Campbell
This is a "One day Seminar -ODS " . The objectives of this ODS are to focus on key areas
• System address space CPU, EDM pools, data set activity, logging, lock/latch contention, DBM1
virtual and real storage, buffer pools and GBP,…
• Identify the key performance indicators to be monitored
• Provide rules-of-thumb to be applied
• Typically expressed in a range, e.g. < X-Y
• If <x,>Y, need further investigation and tuning - RED
• Boundary condition if in between - AMBER
• Investigate with more detailed tracing and analysis when time available
• Provide tuning advice for common problems
DB2 11 for z/OS Migration Planning and Early Customer ExperiencesJohn Campbell
This extensive presentation provides help and guidance to help DB2 for z/OS customer migrate as quickly as possible, but safely to V11. The material will provide additional planning information, share customer customer experiences and best practices.
This document provides an overview of various database administration concepts in DB2 including tables, views, indexes, procedures, triggers, tablespaces, and buffer pools. It discusses how tables are used to store column and row data, and how system catalog tables track metadata. It also describes views, indexes, procedures, triggers, how they are used and created. The document outlines how tablespaces are used to logically group database objects and storage, and how buffer pools cache data pages in memory to improve performance.
This document discusses how to monitor an IBM Db2 Analytics Accelerator (IDAA). It provides an overview of the resources, use cases, and tools for monitoring an IDAA. Key metrics for monitoring include accelerator resources, system resources, SQL statements, workload, performance, and capacity planning. Tools mentioned for monitoring include the appliance UI, OMPE, Data Studio, DISPLAY ACCEL command, and stored procedures.
This document summarizes a presentation about trends and directions for Db2 for z/OS. It discusses Db2 for z/OS's strategy of investing in AI, cloud, and analytics while simplifying and modernizing. It provides an overview of recent releases of Db2 12 including new features and function levels delivered through continuous delivery. It also discusses future potential features such as Db2 AI for z/OS and integration with IBM Cloud Pak for Data.
The document discusses various database backup, restore, load, and import utilities in DB2. It provides information on taking full and table space backups online and offline, restoring from backups, and loading and importing data. Backup options include incremental and delta backups. The load utility loads data in four phases and supports restarting failed loads. The import utility inserts data from files into tables and supports restarting failed imports.
The document discusses various DB2 recovery options including backup and restore, the recovery process model, important recovery-related system files, advanced copy services, and transportable schemas. It provides examples of the backup and restore process models and describes key DB2 recovery-related files. It also outlines the scripted interface for advanced copy services backup and differences between DB2 versions 9.7 and 10.1 related to advanced copy services.
IBM DB2 Analytics Accelerator Trends & Directions by Namik Hrle Surekha Parekh
IBM DB2 Analytics Accelerator has drawn lots of attention from DB2 for z/OS users. In many respects it presents itself as just another DB2 access path (but what a powerful one!) and its deep integration into DB2 as well as application transparency makes it one of the most exciting DB2 enhancements in years. The IBM DB2 Analytics Accelerator complements DB2 by adding industry leading data intensive complex query performance thanks to being powered by the Netezza engine and enhances DB2 to the ultimate database management system that delivers the best of both worlds: transactional as well as analytical workloads. This presentation brings the latest news from the IDAA development and shows the trends and directions in which this technology develops.
Perfect trio : temporal tables, transparent archiving in db2 for z_os and idaaCuneyt Goksu
Temporal tables and transparent archiving in DB2 for z/OS, combined with IDAA, provide three key benefits:
1. They allow organizations to retain data for long periods of time in a cost-effective manner by moving inactive data offline.
2. They improve application performance by separating newer, more frequently accessed rows from older, less frequently accessed rows.
3. They enable transparent access to both current and archived data through a single query, reducing the need for application changes.
The document discusses the evolution of DB2 HADR tool from version 8.2 to 10. It provides an overview of HADR and how it works, describes the key features introduced in each version, provides an example of how to set up HADR, and discusses techniques for optimizing HADR performance and using HADR beyond high availability for database migration.
DB2 for z/OS Real Storage Monitoring, Control and PlanningJohn Campbell
Just added another hot DB2 topic around DB2 for z/OS Real Storage Monitoring, Control and Planning - Check it out and make sure your system runs safely
This document provides an overview and update on Db2 Analytics Accelerator. It discusses the Accelerator's version 7.5 functionality including integrated synchronization, a wider range of scalability, and pass-through support for additional built-in functions. It also reviews the Accelerator's deployment options and data synchronization techniques for incremental updates with low latency between Db2 for z/OS and the Accelerator.
The document discusses DB2's use of storage on the mainframe. It notes that DB2 uses VSAM data sets to store tablespaces, indexes, and other objects. These data sets can be managed by DB2 storage groups or SMS. Storage groups are lists of volumes where data sets are placed. The document recommends letting DB2 manage data sets using storage groups for less administrative work, but with less control, or defining your own data sets for more control but more work. It also provides details on where to find storage-related information in the DB2 catalog.
The document discusses DB2 security concepts including authentication, authorization, administrative authorities, and database object privileges. It describes how authentication can be configured on the server and client. The major DB2 administrative authorities like SYSADM, SYSCTRL, and DBADM are explained along with how privileges can be granted and revoked for database objects, schemas, tables, indexes, and packages. Examples are provided for granting privileges using SQL statements. The document also includes a case study about troubleshooting a user not having insert privileges on a table.
Optimal query access plans are essential for good data server performance and it is the DB2 for Linux, UNIX and Windows query optimizer's job to choose the best access plan. However, occasionally queries that were performing well suddenly degrade, due to an unexpected access plan change. This presentation will cover a number of best practices to ensure that access plans don't unexpectedly change for the worse. All access plans can be made more stable with accurate DB statistics and proper DB configuration. DB2 9.7 provides a new feature to stabilize access plans for static SQL across binds and rebinds, which is particularly important for applications using SQL Procedural Language. When all else fails, optimization profiles can be used to force the desired access plan. This presentation will show you how to develop and implement a strategy to ensure your access plans are rock-solid.
[pdf presentation with notes]
This document discusses database transaction logging and concurrency control in DB2. It covers topics such as locks, isolation levels, deadlocks, snapshots, and transaction logging. It provides information on DB2's use of row-level and table-level locks, lock modes, lock escalation, lock monitoring using snapshots, and the two logging methods of circular logging and archival logging.
This document discusses the relationship between DB2 and storage management. It describes how DB2 uses storage through tablespaces, indexes, and other objects that are stored on disk as VSAM data sets. It also discusses how DB2 interacts with DFSMS to manage data sets and how storage groups and SMS can be used to simplify storage administration for DB2 objects. While DB2 provides storage management features, there is still a gap between DBA and storage administration that tools can help address.
This document discusses the relationship between DB2 and storage management on IBM mainframes. It begins by describing how DBAs and storage administrators typically have different focuses, with DBAs more focused on database objects and storage administrators focused on overall storage capacity. It then discusses how DB2 uses storage, including for tablespaces, indexes, logs, and backups. It also covers DB2's integration with DFSMS for storage management capabilities like storage groups, data placement, and space management. Finally, it discusses how modern storage architectures have reduced the importance of careful data set placement that was previously recommended for database performance.
DB2 12 introduces continuous delivery of new capabilities through function levels, simplifying migration to a single phase process. Explain tables must be recreated in DB2 12 format prior to migration. Application compatibility settings should be set to the target function level and packages rebound to enable new SQL features and optimize access plans.
DB2 10 & 11 for z/OS System Performance Monitoring and OptimisationJohn Campbell
This is a "One day Seminar -ODS " . The objectives of this ODS are to focus on key areas
• System address space CPU, EDM pools, data set activity, logging, lock/latch contention, DBM1
virtual and real storage, buffer pools and GBP,…
• Identify the key performance indicators to be monitored
• Provide rules-of-thumb to be applied
• Typically expressed in a range, e.g. < X-Y
• If <x,>Y, need further investigation and tuning - RED
• Boundary condition if in between - AMBER
• Investigate with more detailed tracing and analysis when time available
• Provide tuning advice for common problems
DB2 11 for z/OS Migration Planning and Early Customer ExperiencesJohn Campbell
This extensive presentation provides help and guidance to help DB2 for z/OS customer migrate as quickly as possible, but safely to V11. The material will provide additional planning information, share customer customer experiences and best practices.
This document provides an overview of various database administration concepts in DB2 including tables, views, indexes, procedures, triggers, tablespaces, and buffer pools. It discusses how tables are used to store column and row data, and how system catalog tables track metadata. It also describes views, indexes, procedures, triggers, how they are used and created. The document outlines how tablespaces are used to logically group database objects and storage, and how buffer pools cache data pages in memory to improve performance.
This document discusses how to monitor an IBM Db2 Analytics Accelerator (IDAA). It provides an overview of the resources, use cases, and tools for monitoring an IDAA. Key metrics for monitoring include accelerator resources, system resources, SQL statements, workload, performance, and capacity planning. Tools mentioned for monitoring include the appliance UI, OMPE, Data Studio, DISPLAY ACCEL command, and stored procedures.
This document summarizes a presentation about trends and directions for Db2 for z/OS. It discusses Db2 for z/OS's strategy of investing in AI, cloud, and analytics while simplifying and modernizing. It provides an overview of recent releases of Db2 12 including new features and function levels delivered through continuous delivery. It also discusses future potential features such as Db2 AI for z/OS and integration with IBM Cloud Pak for Data.
The document discusses various database backup, restore, load, and import utilities in DB2. It provides information on taking full and table space backups online and offline, restoring from backups, and loading and importing data. Backup options include incremental and delta backups. The load utility loads data in four phases and supports restarting failed loads. The import utility inserts data from files into tables and supports restarting failed imports.
The document discusses various DB2 recovery options including backup and restore, the recovery process model, important recovery-related system files, advanced copy services, and transportable schemas. It provides examples of the backup and restore process models and describes key DB2 recovery-related files. It also outlines the scripted interface for advanced copy services backup and differences between DB2 versions 9.7 and 10.1 related to advanced copy services.
IBM DB2 Analytics Accelerator Trends & Directions by Namik Hrle Surekha Parekh
IBM DB2 Analytics Accelerator has drawn lots of attention from DB2 for z/OS users. In many respects it presents itself as just another DB2 access path (but what a powerful one!) and its deep integration into DB2 as well as application transparency makes it one of the most exciting DB2 enhancements in years. The IBM DB2 Analytics Accelerator complements DB2 by adding industry leading data intensive complex query performance thanks to being powered by the Netezza engine and enhances DB2 to the ultimate database management system that delivers the best of both worlds: transactional as well as analytical workloads. This presentation brings the latest news from the IDAA development and shows the trends and directions in which this technology develops.
Perfect trio : temporal tables, transparent archiving in db2 for z_os and idaaCuneyt Goksu
Temporal tables and transparent archiving in DB2 for z/OS, combined with IDAA, provide three key benefits:
1. They allow organizations to retain data for long periods of time in a cost-effective manner by moving inactive data offline.
2. They improve application performance by separating newer, more frequently accessed rows from older, less frequently accessed rows.
3. They enable transparent access to both current and archived data through a single query, reducing the need for application changes.
The document discusses the evolution of DB2 HADR tool from version 8.2 to 10. It provides an overview of HADR and how it works, describes the key features introduced in each version, provides an example of how to set up HADR, and discusses techniques for optimizing HADR performance and using HADR beyond high availability for database migration.
DB2 for z/OS Real Storage Monitoring, Control and PlanningJohn Campbell
Just added another hot DB2 topic around DB2 for z/OS Real Storage Monitoring, Control and Planning - Check it out and make sure your system runs safely
This document provides an overview and update on Db2 Analytics Accelerator. It discusses the Accelerator's version 7.5 functionality including integrated synchronization, a wider range of scalability, and pass-through support for additional built-in functions. It also reviews the Accelerator's deployment options and data synchronization techniques for incremental updates with low latency between Db2 for z/OS and the Accelerator.
The document discusses DB2's use of storage on the mainframe. It notes that DB2 uses VSAM data sets to store tablespaces, indexes, and other objects. These data sets can be managed by DB2 storage groups or SMS. Storage groups are lists of volumes where data sets are placed. The document recommends letting DB2 manage data sets using storage groups for less administrative work, but with less control, or defining your own data sets for more control but more work. It also provides details on where to find storage-related information in the DB2 catalog.
The document discusses DB2 security concepts including authentication, authorization, administrative authorities, and database object privileges. It describes how authentication can be configured on the server and client. The major DB2 administrative authorities like SYSADM, SYSCTRL, and DBADM are explained along with how privileges can be granted and revoked for database objects, schemas, tables, indexes, and packages. Examples are provided for granting privileges using SQL statements. The document also includes a case study about troubleshooting a user not having insert privileges on a table.
Optimal query access plans are essential for good data server performance and it is the DB2 for Linux, UNIX and Windows query optimizer's job to choose the best access plan. However, occasionally queries that were performing well suddenly degrade, due to an unexpected access plan change. This presentation will cover a number of best practices to ensure that access plans don't unexpectedly change for the worse. All access plans can be made more stable with accurate DB statistics and proper DB configuration. DB2 9.7 provides a new feature to stabilize access plans for static SQL across binds and rebinds, which is particularly important for applications using SQL Procedural Language. When all else fails, optimization profiles can be used to force the desired access plan. This presentation will show you how to develop and implement a strategy to ensure your access plans are rock-solid.
[pdf presentation with notes]
This document discusses database transaction logging and concurrency control in DB2. It covers topics such as locks, isolation levels, deadlocks, snapshots, and transaction logging. It provides information on DB2's use of row-level and table-level locks, lock modes, lock escalation, lock monitoring using snapshots, and the two logging methods of circular logging and archival logging.
This document discusses the relationship between DB2 and storage management. It describes how DB2 uses storage through tablespaces, indexes, and other objects that are stored on disk as VSAM data sets. It also discusses how DB2 interacts with DFSMS to manage data sets and how storage groups and SMS can be used to simplify storage administration for DB2 objects. While DB2 provides storage management features, there is still a gap between DBA and storage administration that tools can help address.
This document discusses the relationship between DB2 and storage management on IBM mainframes. It begins by describing how DBAs and storage administrators typically have different focuses, with DBAs more focused on database objects and storage administrators focused on overall storage capacity. It then discusses how DB2 uses storage, including for tablespaces, indexes, logs, and backups. It also covers DB2's integration with DFSMS for storage management capabilities like storage groups, data placement, and space management. Finally, it discusses how modern storage architectures have reduced the importance of careful data set placement that was previously recommended for database performance.
Presentation db2 best practices for optimal performancesolarisyougood
This document summarizes best practices for optimizing DB2 performance on various platforms. It discusses sizing workloads based on factors like concurrent users and response time objectives. Guidelines are provided for selecting CPUs, memory, disks and platforms. The document reviews physical database design best practices like choosing a page size and tablespace design. It also discusses index design, compression techniques, and benchmark results showing DB2's high performance.
Tempdb is created immediately after the master database during SQL Server startup. It is created by copying the structure and contents of the model database and then configuring the tempdb files. Tempdb is used to store temporary user objects like temp tables and table variables as well as internal objects used for sorting and queries. Logging is minimized in tempdb to improve performance, with logging only needed to support transaction rollback. The allocation of objects to tempdb data files uses a round-robin approach to distribute allocations evenly across the files.
The document discusses ways to optimize performance of the TEMPDB database in SQL Server. It begins by explaining what objects are stored in TEMPDB and how it works internally. Some common TEMPDB problems are TEMPDB experiencing I/O bottlenecks, contention on allocation structures, and running out of space. The document then provides various ways to monitor and optimize TEMPDB performance, such as pre-allocating more space, locating TEMPDB on fast storage, minimizing temporary object usage, and enhancing temporary object reuse.
DB2 10 Webcast #1 Overview And Migration PlanningCarol Davis-Mann
DB2 10 for z/OS provides many new features and performance enhancements over previous versions. Migrating to DB2 10 involves following standard upgrade procedures, meeting all technical prerequisites, moving to conversion mode, then enabling new functions mode. Customers on DB2 8 can also do a "skip migration" directly to DB2 10. IBM offers workshops to help customers plan their DB2 10 migrations.
The document discusses tempdb, a system database in SQL Server that is used to store temporary objects. It covers topics like restrictions on tempdb, what takes up space in tempdb such as queries and triggers, best practices for allocating and configuring tempdb files, using trace flags to improve performance, minimizing usage of tempdb to avoid contention, and tips for correctly configuring tempdb.
#DNUG45 - IBM Notes and Domino Performance Boost - ReloadedChristoph Adler
This document provides an agenda and slides for a presentation titled "IBM Notes and Domino Performance Boost - Reloaded". The presentation is split into three parts - the first part covers optimizing IBM Domino performance and is presented by Luis Guirigay, the second part covers optimizing IBM Notes client performance and is presented by Christoph Adler, and the third part provides a summary. The slides discuss various techniques for improving performance such as optimizing transaction logging, database properties, mailbox usage, and other server-side settings. Additional techniques for improving IBM Notes client performance include upgrading to the latest IBM Notes release, optimizing the on-disk structure of local databases, disabling antivirus scanning of Notes data directories, and
Similar to DB2DART - DB2Night Show October 2011 (11)
This document discusses a security issue that occurred when improperly configuring DB2 federation. Specifically:
1. A client site configured DB2-LDAP federation but also enabled the FED_NOAUTH parameter, bypassing authentication.
2. This meant any user could connect to the database as any other user without providing the correct password.
3. If the database owner username was guessed, full access to all data could be obtained, potentially exposing the database to a major security breach.
The issue was caused by incorrectly enabling the FED_NOAUTH parameter when federation was set up. Proper authentication should have occurred at the database rather than being bypassed. The moral is to not enable
What do you do when disaster strikes? In part 9 of our DB2 Support Nightmare series we look at another DB2 disaster scenario and how it was resolved by the experts at Triton Consulting.
Number 8 in our Top 10 DB2 Support Nightmares series. This month we take a look at what happens when organisations are not able to keep up to date with the latest DB2 technology.
Imagine the scene – a broken database on an unsupported version of DB2, with no backups or log files to recover the database.
Yes – this one really was the stuff of nightmares!
Download if you dare! In part six of our DB2 Nightmares series we see what can happen when an experienced DBA goes on holiday leaving the Junior DBA in charge with no support.
Consultancy on Demand is a specially designed service for customers who need varying levels of DB2 support throughout the year.
You purchase a block of 20, 50 or 100 hours. You can then call off hours as and when you need them. No commitment required!
A Time Traveller's Guide to DB2: Technology Themes for 2014 and BeyondLaura Hood
This document discusses technology themes for DB2 in 2014 and beyond, including cost reduction, high availability, in-memory computing, skills availability, database commoditization, and big data. It summarizes DB2's focus on these areas today and potential future directions, such as further optimization to reduce software licensing fees, expanded data sharing capabilities, increased memory capacities, evolving skills needs, and continued integration with big data platforms. The document aims to help DB2 professionals consider strategies for addressing these themes.
A junior DBA accidentally deleted all rows from a critical table in a pre-production environment. The DBA had connected to the wrong system and used the instance owner userid. The system administrator had enabled the FED_NOAUTH parameter, which bypasses authentication at the instance level. This meant any user could connect as any other user without the correct password and impact the database. The moral is that unintended consequences can occur from small configuration changes and it is important to get skilled DB2 support.
Db2 10 memory management uk db2 user group june 2013 [read-only]Laura Hood
DB2 10 provides significant enhancements to memory management that allow for much greater scalability. Key changes include moving most objects above the 2GB bar, enabling larger buffer pools through 1MB page support, and enhanced real storage monitoring. Migrating to DB2 10 requires ensuring sufficient real storage is available, monitoring real storage usage, and addressing other limiting factors before taking advantage of new features to further scale vertically.
DbB 10 Webcast #3 The Secrets Of ScalabilityLaura Hood
The third in the Migration Month webcast series looking at DB2 10 migration planning. This webcast goes into the scalability benefits available in DB2 10, with Julian Stuhler of Triton Consulting & Jeff Josten of IBM.
DB2 10 Webcast #2 - Justifying The UpgradeLaura Hood
This document discusses justifying an upgrade from DB2 9 or 8 to DB2 10 for z/OS. It outlines potential CPU, productivity, and availability savings from the upgrade. CPU savings can come from improved performance in conversion mode through features like high performance database application transition support. Productivity savings may result from features that improve plan stability and temporal tables. Availability improvements like online reorganization of LOBs can reduce downtime costs. The presentation recommends using IBM's DB2 10 Business Value Assessment Estimator Tool to quantify specific savings for an organization.
DB2 10 for z/OS introduced temporal data support which allows applications to query data as it existed at different points in time. The document discusses system temporal tables, business temporal tables, and bi-temporal tables. It provides examples of temporal DDL, SELECT extensions for querying historical data, and discusses early experiences and performance considerations with temporal data in DB2 10.
Temporal And Other DB2 10 For Z Os HighlightsLaura Hood
The document discusses DB2 10 for z/OS and its new temporal data support feature. It provides an overview of DB2 10, describing new features such as temporal data, virtual storage enhancements, and optimizer enhancements. It then discusses temporal data concepts in more detail, including temporal tables, periods, business temporal tables and system temporal tables. The document provides examples and explains how to implement temporal tables in DB2 10. It concludes by listing further reading materials on DB2 10.
DB210 Smarter Database IBM Tech Forum 2011Laura Hood
DB2 10 for z/OS is a new version of IBM's database software that provides significant performance improvements, new security and temporal data features, and easier migration paths from prior versions. Key enhancements in DB2 10 include 5-20% CPU reductions, up to 10x more threads per subsystem due to virtual storage improvements, row and column access controls, and built-in support for tracking historical data. Customers running DB2 8 or 9 can upgrade directly to DB2 10 using new "skip migration" functionality, or upgrade sequentially from earlier versions. Migrating to DB2 10 requires meeting prerequisites and following steps to move to conversion mode and then normal mode.
Pure Genius: How To Get Mainframe-Like Scalability & Availability For Midrange DB2 discusses pureScale, an optional feature for DB2 that implements shared-disk clustering to provide high scalability and availability. It can support up to 128 members. The architecture uses a shared database, coordination facilities, and InfiniBand networking. Customers experience scalability gains, easy installation, and resilience like continued operation despite coordination facility failure. The presentation evaluates pureScale's benefits and customer experiences.
The document discusses IBM's pureScale technology which allows DB2 databases to scale up to 128 nodes for high availability and scalability. PureScale forms a shared-disk cluster and uses proven "data sharing" technology from DB2 for z/OS. It provides agility to rapidly scale up or down capacity as needed with little application change. The company Triton built a basic 2-node pureScale cluster within a budget of under £1K to validate IBM's claims and gain hands-on experience. Their testing showed the cluster delivered 1000 transactions per second under load. The summary concludes that pureScale provides robust clustering with excellent price/performance.
Episode 4 DB2 pureScale Performance Webinar Oct 2010Laura Hood
DB2 pureScale provides scalability and high performance through its clustered database architecture. It uses a cluster caching facility to manage data consistency across member nodes and leverage low-latency interconnects like InfiniBand. The architecture features two-level buffer pool caching between local and global pools for improved read performance. Monitoring and tuning focuses on optimizing buffer pool hit ratios at both levels. Initial proof points showed near-linear scalability up to 12 nodes and over 80% scalability even at 128 nodes, demonstrating the architecture's ability to transparently scale database workloads across many servers.
DB2 pureScale provides high availability and continuous operations by automatically recovering from component failures through workload redistribution and fast in-flight transaction recovery. It protects databases by balancing workloads across nodes and uses duplexed secondary components to tolerate multiple simultaneous node failures while keeping other nodes online and services available.
Episode 3 DB2 pureScale Availability And Recovery [Read Only] [Compatibility...
DB2DART - DB2Night Show October 2011
1. DB2DART
DART
Iqbal Goralwalla
DB2Night Show
October 14, 2011
The Information Management Specialists
2. About Triton
• Formed in 1996
• IBM Premier Business Partner
• Largest independent DB2 Consultancy in the UK
• Strong team of highly experienced and certified DB2
specialists
• Work with customers across a range of sectors
providing them with DB2 consultancy and support for
both DB2 LUW and DB2 z/OS
• Preferred DB2 services supplier to IBM UK and others
The Information Management Specialists
3. About Me
• Head of Midrange (DB2 on LUW) at Triton
Consulting
• Principal Consultant on DB2 LUW
• Experience of DB2 LUW since DB2 Common
Server
• IBM Champion for Data Management
• Tendency to talk too much
The Information Management Specialists
4. DB2DART
• DB2DART – An Overview
• My 3 Key DB2DARTs
• My bonus DB2DART
• Anything on DB2DART and DPF?
• What about INSPECT?
• GOTCHAS
The Information Management Specialists
5. DB2DART – An Overview
db2top
• One of the less used
db2pd
performance reporting
db2exfmt
tools
db2diag
• Historically used with db2support
IBM support
db2trc
• DBAs can use the tool – db2dart
increases productivity
Why am I here?
The Information Management Specialists
6. DB2DART – An Overview
• Database Analysis and Reporting Tool
• “Offline” tool for checking the architectural correctness of a
database
Checks validity of meta-data structures, page headers, row
headers, etc.
• Critical for investigating problems involving data corruption
• Runs against the data on disk
Not aware of what’s in the buffer pool
May show false errors if users are connected to the database
The Information Management Specialists
7. DB2DART – An Overview
• Granularity
Database: db2dart <db> /DB
Tablespace: db2dart <db> /TS
Table: db2dart <db> /T /TSI /OI
• Options for inspecting, formatting, and repairing
data
• Run db2dart /H to see all of the supported
options
The Information Management Specialists
8. DB2DART – Inspecting data
Examples:
db2dart <db> /DB
db2dart <db> /TS /TSI 2
db2dart <db> /T /TSI 2 /OI 6
The Information Management Specialists
9. DB2DART – Formatting data
Example: db2dart <db> /DD /TSI 2 /OI 6
The Information Management Specialists
11. DB2DART – My 3 Key DB2DARTs
DARTs
1. Storage Reclamation and High Water Mark
2. Index Corruption
3. Extracting Data
The Information Management Specialists
12. Storage Reclamation – the DBA
dilemma
Why is the
space not being
Deleted thousands of released?
rows
Dropped a BIG table
Reorged the table
The Information Management Specialists
13. Storage Reclamation – HWM for DMS
tablespaces
• High Water Mark (HWM) is the highest numbered page
that is currently allocated in a DMS tablespace
• HWM can be much higher than the number of pages
currently in use due to:
Dropped tables or delete activity
Offline table reorg using same tablespace
Index reorg using “allow read or write access”
• Makes it difficult to release unused disk space for reuse
• HWM can be seen using LIST TABLESPACES SHOW DETAIL or
GET SNAPSHOT FOR TABLESPACES
The Information Management Specialists
14. Storage Reclamation – HWM for DMS
tablespaces
• LIST TABLESPACES SHOW DETAIL
The Information Management Specialists
15. HWM – Dropped table (1)
DMS TABLESPACE DMS TABLESPACE
T1 T1
5 pages 5 pages
Drop table T2
T2 Free
3 pages 3 pages
T1 T1
2 pages 2 pages
Table Space HWM
Used pages = 10 Used pages = 8
does NOT change
HWM = 10 HWM = 10
The Information Management Specialists
16. HWM – Dropped table (2)
DMS TABLESPACE DMS TABLESPACE
T1 Free
5 pages 5 pages
Drop table T1
T2 T2
3 pages 3 pages
T1 Free
2 pages 2 pages
Table Space HWM
Used pages = 10 Used pages = 3
DOES change
HWM = 10 HWM = 8
The Information Management Specialists
17. HWM – Offline Table Reorg (1)
REORG TABLE T1
DMS TABLESPACE INTERMEDIATE STATE DMS TABLESPACE
T1 T1 Free
5 pages 7 pages
T1
Free T1 4 pages
Shadow
6 pages
Copy
Used pages = 5 Used pages = 4
HWM = 5 Table Space HWM HWM = 11
INCREASES
The Information Management Specialists
18. HWM – Offline Table Reorg (2)
REORG TABLE T1
DMS TABLESPACE INTERMEDIATE STATE DMS TABLESPACE
T1
Free Shadow T1
7 pages Copy 4 pages
Free
T1
T1 7 pages
4 pages
Used pages = 4
Used pages = 4
HWM = 11 Table Space HWM HWM = 4
DECREASES
The Information Management Specialists
19. HWM headaches
• Space not released even though free extents available
• Redirected RESTORE needs space equal to or greater
than the HWM
All extents in DMS table spaces up to the HWM copied to
the backup image.
Tablespaces containers cannot be reduced below HWM
• ALTER TABLESPACE <drop container/reduce containers
size> only affects extents above the HWM
The Information Management Specialists
20. Storage Reclamation – the DBA
dilemma (DB2 9.1/9.5)
Shall I call IBM DB2DART
Support?
Not when
I’m around!
The Information Management Specialists
21. Storage Reclamation – DB2DART 1
DART
• db2dart /DHWM – display table space and high-
water mark information
A map of the extents in the table space, showing
objects owning them
The ID and type of the object holding the high-water
mark extent
Amount of free extents and in-use extents below the
high-water mark
TIP: If online, use db2pdcfg –flushbp first (V9.1FP5,
V9.5FP1)
The Information Management Specialists
22. db2dart /DHWM
LIST TABLESPACES SHOW DETAIL
The Information Management Specialists
23. db2dart /DHWM – Drop table ID 5
LIST TABLESPACES SHOW DETAIL
The Information Management Specialists
24. Storage Reclamation – DB2DART
• db2dart /LHWM – Assists in lowering the high-water
mark
Table space ID and desired high-water mark are required
May not be possible to actually lower it to the desired level
Use "0" for the desired high-water mark to go as low as
possible
Result is a list of operations to execute (EXPORT/LOAD,
REORG, etc.)
Estimate of resulting in use and free extents below the
high-water mark is displayed for each step
The Information Management Specialists
25. db2dart /LHWM
The Information Management Specialists
26. db2dart /LHWM – after REORG
The Information Management Specialists
27. Storage Reclamation – DB2DART
• db2dart /RHWM – Removes empty SMP
extents holding up the high-water mark
DB2 9.5 – ALTER TABLESPACE <tbsp>
REDUCE/DROP
► Drops/reduces containers to the table space’s high-
water mark
► First removes empty SMP extents
► No need for db2dart /RHWM
The Information Management Specialists
28. Storage Reclamation – DB2DART
enhancements
• V9.1 FP4 – db2dart /DHWM and /LHWM can be
run against active/inconsistent database
IZ04647 http://www-
01.ibm.com/support/docview.wss?uid=swg1IZ04647
• V9.1 FP5 – db2dart /DHWM is not correct when
an empty SMP extent is holding the HWM
IZ07663 http://www-
01.ibm.com/support/docview.wss?uid=swg1IZ07663
The Information Management Specialists
29. Storage Reclamation – DB2 9.7
• For a DMS or Automatic Storage table space created in
DB2 9.7, you can use reclaimable storage to return
unused storage to the system for reuse.
• For Automatic Storage table spaces, the REDUCE MAX
option of ALTER TABLESPACE can be used to release all
unused spaced
• For DMS, two steps are required to release the unused
extents
The High Water can be reduced to match the number of
used extents with the LOWER HIGH WATER MARK option
The REDUCE, RESIZE or DROP options then be used
• Reclaiming storage is an online operation
The Information Management Specialists
30. Index Corruption
• Possible causes
Hardware or software failure
Killing an executing process (e.g., LOAD)
After migration from one system to another
• Symptoms
Bad page errors
SQL0980C during a backup database command
SQL0902C – database marked bad
The Information Management Specialists
31. Index Corruption – the DBA dilemma
Restore from
backup?
Shall I call IBM
Support? DB2DART
Not when
I’m around!
The Information Management Specialists
32. Index Corruption – DB2DART 2
DART
• Find out which indexes are problematic
db2dart <db> /DD /TSI <pool id> /OI <object id>
db2dart <db> /DI /TSI <pool id> /OI <object id>
• Mark indexes as invalid
db2dart <db> /MI /TSI <pool id> /OI <object id>
• Indexes recreated based on INDEXREC (database
configuration parameter)
► RESTART
► ACCCESS
► Monitor using db2diag.log
The Information Management Specialists
33. Index Corruption – DB2DART
• Indexes recreated:
First access of invalid index
RESTART DATABASE
LOAD – Build phase
Classic offline table reorg
• To prevent access to problematic index
LOCK TABLE IN EXCLUSIVE MODE
The Information Management Specialists
34. Index Corruption – DB2DART –
Partitioned tables/indexes
• db2dart /MI requires table space ID and index
object ID.
For partitioned indexes, use INDPARTITIONOBJECTID
and INDPARTITIONTBSPACEID from
SYSCAT.INDEXPARTITIONS.
The Information Management Specialists
35. Extracting Data
• Table space or database is corrupt or inaccessible
• Access to “bad/damaged” data causes an
instance crash
• Need to salvage data
Cannot use SQL to select data
Cannot use Export
Restore from backup image
► Does one exist?
► Circular logging?
The Information Management Specialists
36. Extracting Data – the DBA dilemma
Shall I call IBM DB2DART
Support?
Not when
I’m around!
The Information Management Specialists
37. Extracting Data – DB2 DART 3
• db2dart <db> /DDEL
• Dumped in delimited ASCII format
• Prompted for
table name (or ID),
table space ID,
starting page,
number of pages, and
output file name
• LONG VARCHAR or LOB data will not be dumped
The Information Management Specialists
38. Extracting Data – DB2DART
• May require multiple invocations
Dump up to “bad/damaged” page using /DDEL option
► Aborts on reaching corruption
Dump “bad/damaged” page using /DD option
► Incorrupt data can be viewed
Dump rest of pages after “bad/damaged” page using
/DDEL option and appropriate start page
• Some data loss inevitable
The Information Management Specialists
39. Backup Pending State (aka “Forced
backup”)
• LOAD with COPY NO (default)
• Logging strategy changed (circular to
archival)
• LOGARCHIVE enabled
• LOGFILSIZ changed while using raw
device for logging
The Information Management Specialists
40. Backup Pending State – the DBA
dilemma
Do I really need DB2DART
to do a backup?
Not when
I’m around!
The Information Management Specialists
41. Backup Pending State – bonus DB2DART
DART
• db2dart <db> /CHST /WHAT DBBP OFF
The Information Management Specialists
42. DB2DART – Does it work with DPF?
• Yes!
• Run db2dart on desired partition or on all
partitions
• Use db2_all to run db2dart on all partitions in a
single invocation
• Default destination of report file is in diagnostic
directory
The Information Management Specialists
43. DB2DART – IBM service options
• /ETS – extends the table limit in a 4 KB table
space (DMS only), if possible
• /MT – marks table with drop-pending state
Needs password – supplied by IBM
• /IP – initializes the data page of a table as empty
Needs password – supplied by IBM
The Information Management Specialists
44. What about INSPECT?
• Online “equivalent” of DB2DART
• Integrated into runtime engine resulting in
performance gains
Makes use of prefetchers and buffer pools
• Runs on all logical nodes in a partitioned system
Can be directed to run on specific nodes
• Can estimate row compression results for table,
dictionary based on sample
The Information Management Specialists
45. What about INSPECT?
• Granular: inspection can be on database,
tablespace, or a table
• Results (unformatted) are written to the
specified file (placed in diagnostic directory
path). Use db2inspf to format results
The Information Management Specialists
46. DB2DART vs. INSPECT
• INSPECT does not provide any of the formatting or
repair options that db2dart provides
• Unlike DB2DART, INSPECT of a tablespace will only
process objects that reside in that tablespace. It will
not inspect:
Corresponding index objects residing in a different
tablespace
LOB objects residing in a different tablespace
Note: running DB2DART on an INDEX tablespace would
not seek out the parent data
The Information Management Specialists
47. DB2DART – Gotchas
• Security – user with authority to run the db2dart
tool or with access to the db2dart output can
gain access to information that they might not be
authorized for
• LOAD – ALLOW READ ACCESS option not
supported if indexes marked invalid
The Information Management Specialists
48. Summary & Conclusions
• DB2DART is a very powerful tool
• Can be used by DBAs to deal with:
Storage Reclamation
Index Corruption
Extracting Data
Database backup pending state
• Increases productivity
The Information Management Specialists