Database disk image is malformed linux

Multiple threads and Sqlite — database disk image is malformed

DB is always in /tmp/ folder so it’s basically held in RAM. Integrity check says DB is fine.

What can cause this problem and is there a solution?

It’s there because it’s relatively small and read very often. (and it’s just a working copy! — i didn’t mention it). Is there any particular reason I shouldn’t put a working copy in tmp?

Because you are duplicating the function of the [page cache] (thomas-krenn.com/en/wiki/Linux_Page_Cache_Basics) and you’ve collected data that indicates /tmp and sqlite don’t like each other.

1 Answer 1

Solved. Problem was due to connection to database was opened before fork(). Many processes used one connection. Now it’s opened after fork() and everything is ok.

Sqlite3 provides support to multiple selects at the same time only in the case of multiple connections to this db. In this case multiple processes were trying to query db through the same connection. On slower hosts it wasn’t a problem but on newer machines probably process run too quickly and previous queries were overwritten/interrupted by new ones. Just guessing 🙂

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.7.14.43533

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

How to Fix Yum Error: Database Disk Image is Malformed

In this article, we will briefly describe YUM, YumDB, then the cause of Yum Error: database disk image is malformed and how to fix this error.

YUM (Yellowdog Updater, Modified) is the default, high-level tool for Linux package management on RPM (RedHat Package Manager) based Linux distributions such as Red Hat Enterprise Linux (RHEL), CentOS as well as older versions of Fedora Linux, just to mention but a few.

It works just like apt-get command or the relatively new apt command; it can be used to install new packages, remove old packages and query installed and/or available packages. It can also be used to update a system (together with dependency resolution and obsolete processing depending on stored repository metadata).

Note: This guide will assume you are controlling your system as root, otherwise use the sudo command to run all the commands below. Interestingly, you can also run sudo command without entering a password; did you know that, okay, let’s continue.

Brief Understanding of YumDB

Starting from version 3.2.26, yum stores supplementary information concerning installed packages in a location outside of the generic rpmdatabase; in a simple flat file database called yumdb (/var/lib/yum/yumdb/) – not a real database.

You can check out one of the sub-directories to find out more about yumdb as follows.

Although this information is not of great significance to yum processes, it is very useful to the system administrators: it clearly describes the context in which a package was installed on the system.

If you tried looking through the files (from_repo, installed_by, releasever etc..) shown in the screen shot above, you would probably see nothing important in them.

To access the information in them, you must install yum-utils which provides a script called yumdb – then use this script as explained below.

The following command will get the repo from which httpd was installed.

# yumdb get from_repo httpd

To define a note on the packages httpd and mariadb, type.

# yumdb set note "installed by aaronkilik to setup LAMP" httpd mariadb

And to vew all yumdb values concerning httpd and mariadb, type.

Fix Yum Error: database disk image is malformed

Occasionally while installing a package or updating your system using YUM, you may encounter the error: “database disk image is malformed”. It may result from a corrupted yumdb: possibly caused by an impediment of the “yum update” process or package installation.

To fix this error, you need to clean database cache by running the command below.

If the above command fails to work (fix the error), try running the series of commands below.

# yum clean all #delete entries in /var/cache/yum/ directory. # yum clean metadata #clear XML metadeta # yum clean dbcache #clear the cached files for database # yum makecache #make cache

Finally, you must rebuild your system’s RPM database for it to work.

# mv /var/lib/rpm/__db* /tmp # rpm --rebuilddb

If you have followed the above instructions well, then the error should be resolved by now. Then try to update your system as follows.

You may also check out these important articles concerning yum and other Linux package managers:

Do you have any queries or ideas to share concerning this topic, use the comment section below to do that.

Источник

Как исправить ошибку Yum: Database Disk Image is Malformed

Когда вы используете RHEL/Fedora/CentOS/SUSE Linux, вы иногда можете получить ошибку ‘Database Disk is Malformed’. В этой статье мы узнаем, как исправить эту ошибку.

Как исправить ошибку Yum: Образ диска базы данных неправильно сформирован

Yum — это менеджер пакетов по умолчанию для систем RHEL/CentOS/SUSE/Fedora, который позволяет загружать, устанавливать, обновлять и удалять пакеты в вашей системе. Начиная с версии yum 3.2.26, он хранит дополнительную информацию об установленных пакетах вашей системы в плоском файле вне rpmdatabase в /var/lib/yum/yumdb. Он известен как yumdb.

Вы можете проверить его содержимое с помощью команды ls.

Вы увидите список папок с алфавитом в качестве названия папки. В каждой из этих папок вы увидите файлы, связанные с пакетами, названия которых начинаются с буквы, соответствующей названию папки. Эти файлы содержат информацию о конкретном контексте, в котором был установлен пакет. Вы можете легко получить необходимую информацию из yumdb с помощью yum-utils.

yum-utils поставляется вместе с командой yumdb, которую можно использовать для доступа к информации в базе данных yum. Вот команда для получения имени репо пакета httpd, установленного в вашей системе.

yumdb get from_repo httpd

Вы также можете использовать команду yumdb для внесения изменений в существующие файлы в базе данных yum. Вот команда для установки примечания в файлах yumdb пакетов httpd и mariadb.

yumdb set note "установлен пользователем abc для установки LAMP" httpd

Если вы хотите просмотреть всю информацию о пакете, используйте команду yumdb info. Вот команда для получения полной информации о пакете httpd, установленном в вашей системе.

Исправление ошибки Yum: Database Disk Image is Malformed

Обычно, когда вы устанавливаете пакет с помощью Yum, вы можете получить эту ошибку. Это может быть связано с повреждением yumdb, проблемами в команде ‘yum update’ или во время установки пакета. Это происходит потому, что каждый раз, когда вы запускаете yum update или устанавливаете пакет с помощью yum, yumdb обновляется. Если это происходит неправильно или завершается до завершения, то это может привести к повреждению yumdb.

Чтобы исправить эту ошибку, очистите кэш базы данных, выполнив следующую команду.

Если вышеуказанная команда по какой-то причине не сработала, попробуйте выполнить команды, перечисленные ниже.

Удалите записи в каталоге /var/cache/yum/.

очистить кэшированные файлы для базы данных

Далее необходимо пересобрать базу данных RPM вашей системы, чтобы она работала как раньше.

mv /var/lib/rpm/__db* /tmp rpm --rebuilddb

Наконец, выполните команду yum update для обновления до последней версии.

Вот и все. На этом этапе ваша проблема должна быть решена.

Источник

SQLite3 database or disk is full / the database disk image is malformed

My database is about 25 MB, and I’ve verified that the username accessing it, as well as the file permissions haven’t changed in months. I’m having a problem where queries are failing due to a «database or disk is full» and then sometimes «database disk image is malformed» issue. Unless I’m reading this wrong, my disk isn’t anywhere near full (this is an Ubuntu server, 9.10, if it makes any difference)

Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 19610300 2389596 16224560 13% / udev 10240 128 10112 2% /dev none 254136 0 254136 0% /dev/shm none 254136 36 254100 1% /var/run none 254136 0 254136 0% /var/lock none 254136 0 254136 0% /lib/init/rw 

As a test I just did an action that added a new record, and it’s fine. I’m trying to fiqure out if there’s a specific set of actions that are failing. However, after the insert (and verifying that it’s there) the number of bytes on disk for the database has not changed (neither up nor down). Using the command line utility results in something like the following, which is failing spectacularly 🙂

SQLite version 3.6.12 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> pragma integrity_check; *** in database main *** On tree page 2 cell 0: 2nd reference to page 26416 On tree page 2 cell 1: 2nd reference to page 26417 On tree page 2 cell 2: 2nd reference to page 26434 On tree page 2 cell 3: 2nd reference to page 26449 On tree page 2 cell 4: 2nd reference to page 26464 On tree page 2 cell 5: 2nd reference to page 26358 On tree page 2 cell 6: 2nd reference to page 26494 On tree page 2 cell 7: Child page depth differs On tree page 2 cell 8: 2nd reference to page 26190 On tree page 2 cell 8: Child page depth differs . etc., etc. . 

Any ideas on where I should be looking next? Is there a problem with the maximum number of rows in a table or something? I did some reading on SQLite3 max values, and nothing in my database is anything close to them as far as I can tell. I then took a look at my daily backups, and I see that the database backup hasn’t changed in file size for 3-4 days — very strange. I restored a backup copy of the database from before the time it was not changing in file size, and still getting strange issues. I’m thinking I’m going to have to (1) restore from an older backup, and (2) re-run my Rails migrations to fix.

Источник