I encountered Error code= -41 and Error code= -52 Internal error: object overflow address 0|760|-1 may be corrupted
From today, all of sudden it is unable to select data.
When tried the 1st query, the error was -493
Error messages in a SQL log file:
Syntax: Internal error: object overflow address 0|760|-1 may be corrupted. select * from scan_temp where (rownum between 1 and 5000)
I searched how to handle this, and the link http://www.cubrid.com/zbxe/346902 said I should try "cubrid checkdb" so I did.
cubrid chckdb -S -r [databasename]
then I have found different error codes(-41 and -52) the log file of [databasename]_checkdb :
Time: 02/07/13 10:36:29.408 - ERROR *** file ..\..\src\storage\file_manager.c, line 5089 ERROR CODE = -41 Tran = 1, EID = 1
Internal error: Page 1|14377(volume "C:\CUBRID\DATABA~1\EB_SCA~1\EB_SCAN_TR_x001") is not part of file VFID 0|9219(volume "C:\CUBRID\DATABA~1\EB_SCA~1\EB_SCAN_TR").
Time: 02/07/13 10:36:29.409 - ERROR *** file ..\..\src\storage\overflow_file.c, line 977 ERROR CODE = -52 Tran = 1, EID = 2
Internal error: object overflow address 0|760|-1 may be corrupted.
---------------------------
I also tried to backup with cubrid backupdb utility, but failed.
How should I do?
![[레벨:2]](http://www.cubrid.org/modules/point/icons/default/2.gif "Rank: 2/30, reputation score 41 (70% completed for the next level)"){kind=icon}
cottonspan2. If 1st way doesn't work well, you need to restore your previous backup files by using "cubrid restoredb" . Then there is a possibility to lose a partial data after your last backup time.
I have translated a tip from Q&A forum on Korean community
![[레벨:7]](http://www.cubrid.org/modules/point/icons/default/7.gif "Rank: 7/30, reputation score 491 (91% completed for the next level)"){kind=icon}
ginarrbrik asked a question how this situation happened?
Before I answer to your question, it is very difficult to say why/how exactly happened.
In principle, it should not be happened no matter what/how a user did to the DB. However it is a higher possibility when followings occurred.
1) Bugs from CUBRID Old versions
Since November 2008, CUBRID becomes stabilized a lot by resolving many bugs from a variety of users. Especially volume corruption bugs were on a high priority over years. I can say the later versions(8.4.1 or later) are much more stable compared with lower versions in terms of accidental corruption. Therefore we suggest the DBAs who are running CUBRID old versions to upgrade to the latest & stable version, otherwise to the latest patch version .
2) Disk Fault
Not an excuse but a fact :D
Very low possibility but we've experienced several times. If DB is run on the old machine, servers from hosting services, partitioned disk by different vendors, or newaly addded disk, disk fault happened unexpectedly.
3) Other reasons we've never seen
Despite of dev team's efforts, CUBRID QA test senarios cannot cover every case before release out. Although it happened very rarely but is a critical issue, we will keep investigate whenever any of similar cases were reported and fix them to be more stabilized.
Hope this answer helps you.