How to identify the most common damage problems when using IBMDB2

Learn how to identify and classify the most common damage problems when using IBMDB2. In this article, you will learn about some rectification and prevention techniques that you can use to solve annoying damages.

Learn how to identify and classify the most common corruption issues when using IBM DB2. In this article, you will learn about some rectification and prevention techniques that you can use to solve annoying damages.

It is regarded as one of the most troublesome business problems. Damage is often gradually formed without knowing it, which has a negative impact on the Enterprise. In short, damage can be defined as any unexpected item in. Damage may cause severe performance impact to the system. In some cases, it may cause frequent system crashes and cause critical business system downtime. Database corruption can occur at any level, from DB2 to the operating system and the hardware layer. Therefore, it is important to understand and troubleshoot, that is, to analyze all potentially affected layers and collect any available diagnostic data that may be needed as soon as possible.

In this article, you will learn why the database is offline when it encounters a corruption issue. You will also learn to analyze the symptoms of damage and distinguish between easy-to-repair faults and catastrophic faults. This article will clarify the corruption issues when using IBM DB2 and help DB2 users understand and choose the best way to handle this critical high impact issue.

This article first discusses possible sources of corruption and then explains the following tasks:

1. Identify and eliminate damage faults, identify and classify Damage Problems in the database when using DB2, and supplement the sample symptom messages in db2diag. log. Corruption can be divided into five categories: Data Page damage (or table damage), index damage, CBIT damage, log damage, and compression descriptor damage.
2. Use db2dart and INSPECT to identify corruption issues and gain insight into useful DB2 commands, db2dart and INSPECT, to check for database corruption.
3. It is critical to identify a damage issue from the methods to recover from the damage, how to handle the situation, what data to collect, and how to recover from the situation. Learn possible recovery methods and how to select available solutions.
4. Preventive strategies to avoid possible damages and discuss best practices.

Source

Database corruption may occur during writing, reading, storage, transmission, or processing, which introduces unplanned changes to raw data. Common causes of damage:

1. Corrupt file systems are one of the most common causes of database corruption. Sudden system shutdown, surge, file system dual-host mounting, disk migration, file system-level activities, such as checking and repairing the file system when the database goes online and running (the Utilities used include Linux®When the file is opened, Ctrl + Alt + Delete and viruses may all introduce unexpected changes to the database.
2. Hardware faults.
3. Memory Corruption.
4. DB2 defects.
5. I/O and network problems (such as problems in fiber adapters and switches ).
6. Incorrect application code.
7. The value of the buffer pool (sqldPage) is inconsistent with that of the page stored in the file system.
8. Overwriting disk data may cause damage.
9. User Interference with important database configuration files, log files, log control files, and so on will make the database in an inconsistent state.

Although the damage problem is caused by various causes, it is extremely challenging to find out exactly what causes data damage. In most cases, this problem is caused by file system problems and hardware problems.

Identify and troubleshoot

For a DBMS, the page is the smallest unit of Data allocated by the operating system for the memory executed by a program, transmitted between the main memory and any other auxiliary storage (such as hard drive. Therefore, database corruption means that some pages in the database are damaged.

If DB2 has errors that cannot be properly handled, panic is a method it can use to cause a crash. When DB2 detects a page corruption, it stops all processing through a controlled crash (panic) because it cannot determine database integrity. This is also to prevent further data damage or loss.

When DB2 encounters database corruption, many error messages are dumped in db2diag. log. When an unexpected interruption occurs and automatic first-time data capture (FODC) is enabled, data is collected based on the symptoms. When the following conditions are met, FODC data is automatically collected on DB2 9.5:

1. FOCD_Trap: When a trap occurs within the instance range.
2. FODC_Panic, when a DB2 engine detects inconsistency and decides not to continue.
3. FODC_BadPage: When a bad page is detected.
4. FODC_DBMarkedBad: When the database is marked as "bad" due to an error.

Collect necessary information, such as OS diagnostics (such as AIX®On errpt-a, snap and fileplace output) and any hardware diagnostics (such as status saving and error logs), the key is to include OS and hardware support. It is important to ensure that critical file systems have sufficient disk space, such as dump space and log directories, to ensure that critical events are fully captured.

You can view db2diag. log to check whether the panic is damaged or not. The following shows how to identify and classify DB2 corruption. The following are some of the most common db2diag. log error messages that identify corruption.