DB2 Interview Questions Database

Db2 column-organized tables add columnar capabilities to DB2 databases, which include data that is stored with column organization and vector processing of column data.

If the workload is entirely an analytics or OLAP workload, the recommended approach is to put as many tables as possible into a column-organized format.

The process of inserting data into column-organized tables, or updating previously inserted data, is optimized for large insert transactions. As a result, workloads that are transactional in nature should not use column-organized tables. Traditional row-organized tables with index access are generally better suited for these types of workloads. With column-organized tables, performance is optimal if 100 or more rows are impacted by each insert or update transaction.

The four types of Db2 registry variables are:

• Db2 global-level profile registry: All server-wide environment variable settings reside in this registry. These settings are applicable to all the instances that pertain to a particular version of DB2.
• Db2 instance-level profile registry: The environment variable settings for a particular instance are stored in this registry. The values defined in this profile registry override any corresponding settings in the global-level profile registry.
• Db2 instance node-level profile registry: The environment variable settings that are specific to a node in a Massively Parallel Processing (MPP) database environment are stored in this registry. The values defined in this profile registry override any corresponding settings in the global-level and instance-level profile registries.
• DB2 user-level profile registry: The environment variable settings that are specific to each user are stored in this registry, and they take higher precedence over other profile registry settings.

• agent_stack_sz

Agent stack size configuration parameter. This parameter determines the memory that is allocated by Db2 for each agent thread stack.

• aslheapsz

Application support layer heap size configuration parameter.The application support layer heap represents a communication buffer between the local application and its associated agent. This buffer is allocated as shared memory by each database manager agent that is started.

• audit_buf_sz

Audit buffer size configuration parameter. This parameter specifies the size of the buffers used when you audit the Db2instance.

To create and maintain an MQT is a two-step process.

First, we need to create an MQT based on the needs of the business logic, and then refresh the data in the MQT table.

Below is an example

CREATE TABLE SALES_MQT AS
(SELECT SUM (AMOUNT) AS TOTAL_SUM, DATE
FROM SALES
GROUP BY DATE)
DATA INITIALLY DEFERRED REFRESH DEFERRED;
REFRESH TABLE SALES_MQT;

The monitoring elements in Db2 are as follows :

• Counter: This records a precise count of the number of times an activity or event has occurred in the database system. For example, the pool_col_l_reads monitor element records the number of column-organized page requests from the buffer pool for regular and large tablespaces.
• Gauge: This represents the current value for a monitoring element based on how much of something is happening or is used. For example, the num_locks_held monitoring element shows how many locks are being currently held in the database.
• Watermark: This represents the highest value for a given monitoring element. For example, the connections_top monitoring element shows the highest number of simultaneous connections to the database since the database's activation.
• Text: This represents the text value that monitoring elements report. For example, the bp_name monitoring element states the name of the buffer pool.
• Timestamp: This monitor element represents the time that an event happened. 

For example, the last_backup monitoring element lists the date and time that thelatest database backup was completed.

• ACTIVITIES: Records activity events that occur as the database is used.
• BUFFERPOOLS: Records a buffer pool event when the last application disconnects from the database.
• CONNECTIONS: Records a connection event when an application disconnects from the database.
• DATABASE: Records a database event when the last application disconnects from the database.
• DEADLOCKS: Records a deadlock event whenever a deadlock occurs. However, this monitor is depreciated and the LOCKING event should be used instead.
  • DEADLOCKS WITH DETAILS
  • DEADLOCKS WITH DETAILS HISTORY
  • DEADLOCKS WITH DETAILS HISTORY VALUES
• STATEMENTS: Records a statement event whenever a SQL statement finishes running.
• STATISTICS: Record statistics events that occur when using the database.
• TABLES: Records a tabled event for each active table when the last application disconnects from the database.
• TABLESPACES: Records a tablespace event for each tablespace when the last application disconnects from the database.
• THRESHOLD VIOLATIONS: Records threshold violation events that occur when using the database.
• TRANSACTIONS: Records a transaction event whenever a transaction completes. 
• UNIT OF WORK: Records events when a unit of work completes.
• LOCKING: Records a lock event whenever a lock-related event occurs, such as lock timeout, lock waits, and deadlocks.
• PACKAGE CACHE: Records events related to the package cache statement.
• CHANGE HISTORY: Records events related to changes to the DB CFG, DBM CFG, and Db2 registry settings, track the execution of utilities such as LOAD, online backup, REORG, and RUNSTATS.

First, MDC enables a table to be physically clustered on more than one key, or dimension, simultaneously. As a result query performance is improved where there is a clustering of one or more specified dimensions of a table. Consequently not only will these queries access only those pages having records with the correct dimension values, but these qualifying pages will also be grouped into blocks, or extents.

Second, although a table with a clustering index can become unclustered over time, in most cases an MDC table is able to maintain and guarantee its clustering overall dimensions automatically and continuously.

Third, in MDC the clustering indexes are block-based. These indexes are much smaller than regular record-based indexes, hence they take up much less disk space and are faster to scan.