Discussions
Categories
- 196.8K 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
- 544 SQLcl
- 4K SQL Developer Data Modeler
- 187K SQL & PL/SQL
- 21.3K SQL Developer
- 295.8K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.5K 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
- 439 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
last item on page sorted greater than parent entry
I am getting Berkeley database corruption after of hundreds write-read cycles. db_verify return this message:
db_verify: BDB1094 Page 221: last item on page sorted greater than parent entry
db_verify: messages.db: BDB0090 DB_VERIFY_BAD: Database verification failed
BDB5105 Verification of messages.db failed.
I always write the same size of data (512 bytes), with put-get functions using cursor.
Later of hundreds of cycles, I am getting invalid pages. db_dump show me this message:
...
page 219: invalid: LSN [0][1]: level 0
prev: 0 next: 218 entries: 0 offset: 8192
....
for hundreds pages. I am working with aarch64 arquitecture, aarch64-linux-gnu-gcc compiler, DB_BTREE type and db berkeley version 18.1.32
Answers
-
your database is corrupted -- you are going to need to restore. That is not one of the particular architectures that we test in house, however, it appears to be posix compliant so there should not be any issues.
-
There is zero useful information in that response. The O.P. knows their db is corrupt, and they provided specific and technical information.
@op
Bugs that only seem to come up after running for a long time are always hard to nail down. Without seeing you code, I would suggest making sure you check the return result of every BDB function call to try and find exactly when things start going bad. If you can afford the extra overhead, you can also do a "read after write" to make sure the record was written correctly, and error if you find any corruption.