Sqlite3 exec failed disk i o error

12.05.15 — 10:35

Сделал штатное сокращение. Место на диске уменьшилось. Как я понял, всё теперь в логе сидит (в логе лога

Там три файлика — lgd, lgd-shm, lgd-wal. Подозреваю, что последний и есть этот самый лог, судя по размеру. Как этого гада шринкнуть?

1 — 12.05.15 — 11:18

открыть каким-либо просмотрщиком sqlite.

vacuum

закрыть.

2 — 12.05.15 — 11:39

У меня Линух. Может, я что не так делаю…

Поставил sqlite3

Успешно приаттачил lgd.

Сделал вакуум… Никаких изменений. Команду проглотил мгновенно и ничего не сделал.

3 — 12.05.15 — 11:41

По-ходу выяснил, что sqlite даже вьюхи и триггеры поддерживает. Вау!

4 — 12.05.15 — 11:42

(2)

Попробуй не аттачить, а просто открыть:

sqlite3 имяфайла

vacuum

.quit

5 — 12.05.15 — 11:47

(0) а просто удалить файлы журнала?

6 — 12.05.15 — 11:49

(4) Да, что-то я намудрил с этими аттачами. Запустил просто

sqlite3 1Cv8.lgd «VACUUM;»

Вроде задумался… Подождем.

(5) А мне не надо просто удалить.

7 — 12.05.15 — 11:51

8 — 12.05.15 — 11:51

(6) а чего же тебе тогда надо?

9 — 12.05.15 — 11:52

неужели никто еще не сделал обработку из 1с для администрирования нового лога?

10 — 12.05.15 — 11:55

(7) Разбить-то не проблема. А вот прозрачно с ними потом работать, по-ходу — не предусмотрено.

(8) Сократить до указанной даты

(all) Короче VACCUM шринкнул, но как-то странно. Шринкнулось почти до первоначального размера (до сокращения). При этом уменьшился именно lgd, а lgd-wal наоборот — подрос. При том, что штатно на рабочих базах он в десятки раз меньше.

11 — 12.05.15 — 11:57

Для разбиения можно использовать штатные СкопироватьЖурналРегистрации() и ОчиститьЖурналРегистрации(). Для обоих можно сложные фильтры указывать.

12 — 12.05.15 — 11:58

В общем, в плане разбиения на файлики со старым форматом удобнее работать было.

13 — 12.05.15 — 11:59

Но в новом формате особой необходимости в разбиении как бы и нет.

14 — 12.05.15 — 12:00

(10) «Сократить до указанной даты»

а где ты в команде VACUUM дату указал?

15 — 12.05.15 — 12:02

16 — 12.05.15 — 12:12

(14) Нигде. Сократил штатно до этого.

(15) Ежедневный диф-бэкап журнала регистрации? Хм… Никогда таким не заморачивался. Умер максим да и хрен с ним. Но если надо — то таки неудобство выходит. Это да.

(all) Терзают меня смутные сомнения, что ентот lgd-wal — это одноэсный велосипед какой-то… Какие-то доп-хрени сбоку от основного лога.

17 — 12.05.15 — 12:15

А, нет. Таки штатные.

18 — 12.05.15 — 12:15

кстати 1с не рекомендует новый формат жр на большой нагрузке (от 100 чел)

19 — 12.05.15 — 12:17

Таки я был прав. Это лог.

WAL stands for Write Ahead Logging and is some kind of optimization to make transactions faster.

VACUUM, выходит, только базу чистит.

Может, лог сам шринкается? Но вот когда? Может, когда его «отпускает»? При рестарте сервера приложений типа или еще как-то? Будем посмотреть.

20 — 12.05.15 — 12:19

(18) Пруф?

21 — 12.05.15 — 12:19

(16) что такое lgd-wal в документации написано. почитай и тебя не будут терзать смутные сомнения.

22 — 12.05.15 — 12:21

23 — 12.05.15 — 12:22

+(22) например PRAGMA wal_checkpoint TRUNCATE

24 — 12.05.15 — 12:23

Да я уже нашел типа:

1. -shm file contains an index to -wal file. -shm improves the performance of reading -wal file.

2. If -shm file gets deleted, it get created again during next access to database.

3. If checkpoint is run, -wal file can be deleted.

Короче

25 — 12.05.15 — 12:24

(23) Ага, спс.

26 — 12.05.15 — 12:34

TRUNCATE — нету такого. Чекпоинт сделал. Прибил руками shm и val. Теперь 1С при попытке открыть журнал регистрации пишет

sqlite3_exec failed: disk I/O error

sql: PRAGMA journal_mode = wal

Но хоть при работе не падает. Видать при записи исключение обрабатывается

27 — 12.05.15 — 12:37

28 — 12.05.15 — 12:39

А, блин. TRUNCATE надо было в скобки брать…

29 — 12.05.15 — 12:42

(27) Хм… Будем иметь в виду. Хотя с проблемами пока не сталкивался.

30 — 12.05.15 — 12:52

Короче, народ — удалять новый журнал регистрации «на лету» — плохая идея. 1С его заново не создает. Просто исключения сыпет при попытках с ним работать. Теперь тестовую базу «отпустит» только после рестарта сервака, как я понимаю…

31 — 12.05.15 — 12:57

Всё страньше и страньше. Лог таки 1С пересоздала, но работать с ним не может Сыпет

sqlite3_prepare_v2 failed: SQL logic error or missing database

sql: SELECT code, name, uuid FROM UserCodes;

Хотя весь комплект файлов в наличии…

(30) ясен пень на лету нельзя

Проблема

sqlite3_step failed: database disk image is malformed
db: C:ut111Cv8Log1Cv8.lgd

Или другие ошибки связанные с sqlite.

Причина

Причиной ошибок sqlite может служить повреждение данных в файле журнала регистрации. Способ решения этой проблемы описан в данной статье. О том, что Вы столкнулись именно с этой проблемой говорит ошибка database disk image is malformed . При этом она может быть скрыта другими ошибками sqlite. Когда пользователи получают ошибки sqlite, следует искать ошибку database disk image is malformed в журналах клиентских приложений (для файлового варианта) или менеджеров кластера. Она будет указана в журнале в виде:

16:29.504002-0,EXCP,0,process=rmngr,Exception=EventLogException,Descr=’sqlite3_exec failed: database disk image is malformed
db: C:Program Files1cv8srvinfo
eg_154150b80b42-24a3-4f33-8508-5672acb806211Cv8Log1Cv8.lgd sql: PRAGMA journal_mode = OFF’

Такая ошибка означает, что файл журнала регистрации, указанный в ошибке, поврежден.

Решение

Утилита командной строки sqlite

Для Windows утилиту нужно скачать отсюда.

Для Linux следует использовать утилиту, доступную в официальных репозиториях.

Восстановление

ВНИМАНИЕ! Все нижеследующие операции обязательно производите над копией файла журнала регистрации

• Остановите кластер «1С:Предприятия» или завершите все клиенты для файлового варианта.
• Скопируйте испорченный файл 1Cv8.lgd в отдельную директорию. Например, «C:LogRestore».
• Туда же разархивируйте sqlite3.exe из архива, который скачале ранее.
• В командной строке перейдите в рабочую директорию («C:LogRestore»).
• Выполните команду:

sqlite3 1Cv8.lgd .dump >> backup.sql

Восстановление внешней базы данных mobi_s.sqlite3

Исходная ситуация

При открытии обработки или в процессе работы в логе появляются сообщения:

Причина

Причиной ошибок в базе данных sqlite может служить повреждение данных в файле (физические/логические повреждения жесткого диска, последствия вирусов, ошибки при копировании файла…).

Решение

Восстановление поврежденной базы данных производится с помощью утилиты командной строки sqlite.

Столкнулся с интересной и достаточно редкой ошибкой при работе с 1С. После отключения света в офисе, при запуске 1С предприятия у пользователей появлялась ошибка

sqlite3_exec failed: database disk image is malformed

db: c:1CBase1Cv8Log1Cv8.lgd

sql: PRAGMA journal_mode = delete

Если нажать «Показать информацию для технической поддержки», то можно увидеть некоторые подробности ошибки:

Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/login:
по причине:
Ошибка при выполнении операции с информационной базой
Файл базы данных поврежден «c:1CBase1Cv8.1CD»
по причине:
Файл базы данных поврежден «c:1CBase1Cv8.1CD»

Возникла эта ошибка после того, как в офисе выключилось электричество и часть клиентов отрубились. При этом сам сервер не выключался и никак не пострадал от пропажи света. Первым делом я решил проверить целостность файла с базой. Стоит отметить, что в данном случае речь идет про файловый вариант базы 1С.

У 1С Предприятия есть в комплекте утилита для проверки файла базы данных 1Cv8.1CD на наличие ошибок. Называется она chdbfl.exe и живет по адресу

C:Program Files (x86)1cv88.3.5.1383in

Работа этой утилиты по восстановлению ошибок в базе данных не выявила. Тогда стал смотреть на файл 1Cv8.lgd, он упоминается в тексте ошибки. С версии платформы 8.3.5.1068 в нем хранится журнал регистрации. Мне он был не нужен, я просто его удалил, предварительно на всякий случай сохранив. Ошибка исчезла. При первом запуске базы файл был создан вновь.

Hi Paul,
I am running FindFungi for the demo ERR675624 fastq on cluster(CentOS Linux release 7.4.1708). I had remove bsub and got the following results.
There something error I can’t fix, could help have a check? Thank you.

• ouput files in ./ERR675624/FindFungi/Results

128K Oct 21 09:34 BLAST_Processing
24bytes Oct 21 11:32 ERR675624.WordCloud.R
0bytes Oct 21 11:32 Final_Results_ERR675624-lca.sorted.csv
21bytes Oct 21 11:29 Final_Results_ERR675624-taxids.txt
91K Oct 21 05:48 Final_Results_ERR675624.tsv
2.9K Oct 21 11:30 Final_Results_ERR675624.tsv_AllResults-taxids.txt
11M Oct 21 05:48 Final_Results_ERR675624.tsv_AllResults.tsv
0bytes Oct 21 11:32 Final_Results_ERR675624_AllResults-lca.sorted.csv

The CSV is always empty with the errors showing below

• source script code

$ScriptPath/LowestCommonAncestor_V4.sh $Dir/Results/Final_Results_$z.tsv
$ScriptPath/LowestCommonAncestor_V4.sh $Dir/Results/Final_Results_$z.tsv_AllResults.tsv

• error information (using ete3-3.1.1 )

Uploading to /users/username/.etetoolkit/taxa.sqlite
Traceback (most recent call last):
  File "/users/username/tools/FindFungi-v0.23.3/LowestCommonAncestor_V4.py", line 26, in <module>
    ncbi = NCBITaxa()
  File "/users/username/username/tools/conda3/lib/python2.7/site-packages/ete3/ncbi_taxonomy/ncbiquery.py", line 120, in __init__
    self.update_taxonomy_database(taxdump_file)
  File "/users/username/username/tools/conda3/lib/python2.7/site-packages/ete3/ncbi_taxonomy/ncbiquery.py", line 129, in update_taxonomy_database
    update_db(self.dbfile)
  File "/users/username/username/tools/conda3/lib/python2.7/site-packages/ete3/ncbi_taxonomy/ncbiquery.py", line 760, in update_db
    upload_data(dbfile)
  File "/users/username/username/tools/conda3/lib/python2.7/site-packages/ete3/ncbi_taxonomy/ncbiquery.py", line 791, in upload_data
    db.execute(cmd)
sqlite3.OperationalError: disk I/O error
Done

• error information(using older version ete3)

/users/username/tools/FindFungi-v0.23.3//LowestCommonAncestor_V4.sh: line 14: 28870 Segmentation fault      python2.7 ~/tools/FindFungi-v0.23.3/LowestCommonAncestor_V4.py ${1} ${y}-taxids.txt ${y}-lca.csv
Done
/users/username/tools/FindFungi-v0.23.3//LowestCommonAncestor_V4.sh: line 14: 28875 Segmentation fault      python2.7 ~/tools/FindFungi-v0.23.3/LowestCommonAncestor_V4.py ${1} ${y}-taxids.txt ${y}-lca.csv
Done

Best
Keli