728x90

You can perform routine administrative tasks that can prevent assertion failures or help prepare for recovering from assertion failures.

To prevent assertion failures on Informix®, perform the following tasks regularly:

Table 1. Preventing assertion failuresPrevention taskPurpose

Test your applications thoroughly in a realistic environment before releasing your applications into production. Applications can trigger assertion failures.Make sure that you have allocated enough resources: for example, physical and logical logs and shared memory.
Check and repair the consistency of your data.Run the following oncheck commands to check your system:
  • oncheck -cD: Data pages
  • oncheck -cI: Index pages
  • oncheck -cr: Reserved pages
  • oncheck -ce: Chunk-free list
  • oncheck -cc: System catalog tables
  • oncheck -pe: Physical information about chunks
Diagnosing and repairing consistency problems quickly can prevent major problems like data loss and assertion failures.
Upgrade to the latest major and fix pack release. Assertion failures can be caused by product defects. You can avoid many product defects by upgrading to the most current release.
Update statistics.When you change a table or indexing schema, update statistics to update the dictionary cache. By default, statistics are updated automatically by the Scheduler. You can customize automatic statistics updating for your system. Queries that use stale statistics can use too many resources and cause assertion failures. Stale statistics can also have a negative affect on query performance.Always update statistics after upgrading.

To prepare for assertion failures on Informix, perform the following tasks regularly:

Table 2. Preparing for assertion failuresPreparation taskPurpose

Back up your data and logical logs.You can use the ON-Bar utility or the ontape utility to back up your data and logical logs. The ON-Bar utility requires a storage manager. If data loss occurs, you can recover your data and recent transactions.
Back up your database and storage space schema information.Run the following commands to back up your schema information:
  • dbschema -ss -d database_name > dbschema_ss_database_name.out: Saves the schema information about the specified database in a file.
  • dbschema -c > dbschema_c.out: Saves the commands to reproduce storage spaces, chunks, physical logs, and logical logs in a file.
In a catastrophic failure, you can recreate your system.

 

출처 : https://www.ibm.com/docs/en/informix-servers/14.10?topic=failures-prevent-prepare-assertion

728x90
728x90

The message Archive detects that page is corrupt indicates that page validation failed.

During an archive, the database server validates every page before writing it to the archive device. This validation checks that the elements on the page are consistent with the expected values. When a page fails this validation, a message similar to the following is written to the online.log file:

15:06:37  Assert Failed: Archive detects that page 0xc00021 is corrupt.
15:06:37  IBM Informix Dynamic Server Version 9.40.UC1
15:06:37   Who: Session(25, informix@cronus, 67612, 1085259772)
                Thread(50, arcbackup1, 40acf758, 4)
                File: rsarcbu.c Line: 2549
15:06:37  stack trace for pid 67367 written to /tmp/af.41ad7b9
15:06:37   See Also: /tmp/af.41ad7b9

below 9.40 version (Expanded chunk capacity mode: disabled)
16:27:49 Assert Warning: Archive detects that page 1:10164 is corrupt. 
16:27:49 IBM Informix Dynamic Server Version 11.50.FC7
16:27:49 Who: Session(5, informix@cronus, 23467, 10a921048)
Thread(40, arcbackup1, 10a8e8ae8, 1)
File: rsarcbu.c Line: 2915
16:27:49 stack trace for pid 23358 written to /tmp/af.41043f4
16:27:49 See Also: /tmp/af.41043f4
16:27:49 Archive detects that page 1:10164 is corrupt.
16:27:50 Archive on rootdbs Completed with 1 corrupted pages detected.

above 10.00 version (Expanded chunk capacity mode: enabled, always)

The page number is printed in hexadecimal. The format for page number is 0xCCCPPPPP where CCC represents the chunk number, and PPPPP represents the page number. For this example, the corrupted page is in chunk 0xc (12 decimal) and page 0x21 (33 decimal). The archive aborts after detecting 10 corrupt pages. The online.log file displays the full error message, including the page address, for the first 10 errors. Subsequently, only the count of the number of corrupt pages is put in to the online.log.

When you receive this message, identify which table the corrupt page belongs to by examining the output of the oncheck –pe command. (해당 정보는 sysmaster:sysextents 테이블에서도 확인할 수 있습니다.) To determine the extent of the corruption, execute the oncheck –cID command for that table.

A corrupt page is saved onto the backup media. During a restore, the corrupt page is returned in its corrupt form. No errors messages are written to the online.log when corrupt pages are restored, only when they are archived.


http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.bar.doc/barmst369.htm

http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic=%2Fcom.ibm.bar.doc%2Fids_bar_055.htm

http://www-01.ibm.com/support/docview.wss?uid=swg21209842


728x90

+ Recent posts