Discussions
Categories
- 196.9K All Categories
- 2.2K Data
- 239 Big Data Appliance
- 1.9K Data Science
- 450.3K Databases
- 221.7K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 550 MySQL Community Space
- 478 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 546 SQLcl
- 4K SQL Developer Data Modeler
- 187K SQL & PL/SQL
- 21.3K SQL Developer
- 295.9K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.6K Development Tools
- 107 DevOps
- 3.1K QA/Testing
- 646K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 155 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 18 Java Essentials
- 160 Java 8 Questions
- 86K Java Programming
- 80 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 204 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 442 LiveLabs
- 38 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 171 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 232 Portuguese
Correct way to handle db PANIC errors

Hello.
I am trying to handle the case where there is an issue with my db or log files. it would not be great but if there was an error I could delete them and accept the data loss.
for example errors like
BDB1513 Checkpoint LSN record [2][2040412] not found
BDB0061 PANIC: BDB0073 DB_NOTFOUND: No matching key/data pair found
How can i catch these errors before they terminate the program.
whats the best way to open the db and check for errors.
verify did not work - it said all was ok!
Db db_verify(NULL, 0);
db_verify.verify(_db, "db/env/", "db", NULL, DB_ORDERCHKONLY );
how can i properly test for correct db/logs without it PANICking and falling over?
Thanks
Answers
-
For what it is worth, I had a panic situation recently that was caused by db->get failing with DBD0073 DB_NOTFOUND. The panic happened if I ignored the failure and kept trying to look up more keys (which some failed and some did not). But this was also related to an underlying problem with b-tree databases being memory mapped.
Anyway, you mentioned the DBD0073 error and were asking for a way to handle the panic. If you know the key is in the database, and you get the DBD0073 from db->get, then that is probably your indicator that something has gone wrong, and you should close the db at that point.
Maybe a little helpful?