White Owl
Вот формат таблицы для хранения данных
1.
2.
3.
CREATE TABLE Data (ID INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, BlN INTEGER, Type INTEGER[1], DateTime INTEGER,
Long INTEGER, Lat INTEGER, Speed INTEGER, Heading INTEGER[2], Alt INTEGER, GPSQty INTEGER);
CREATE INDEX i_datetime_bln on data (bln,datetime);
Вот точный sql-запрос на удаление
1.
DELETE FROM Data WHERE ID in (SELECT ID FROM Data WHERE DateTime<%d LIMIT 10000000);
Вместо %d подставляется целое число, соответствующее дате (дата в формате времени Unix).
Использую следующие настройки для базы:
1.
2.
PRAGMA journal_mode=WAL;
pragma cache_size=100000;
Пример данных, на которых происходит ошибка, дать не могу - там база весит уже 39Гб.
Если создаю базу с тестовыми данными вручную ошибка не происходит - удаляется ровно то количество данных, которое указано в LIMIT. Там, где работает реальная база несколько раз были аварийные отключения питания. Один раз даже восстанавливали базу через текстовое представление. Возможно, в базе есть какие-то "битые" записи, и это влияет на результаты DELETE..LIMIT? Но на запросы база отвечает корректно.
Версия движка - 3.7.17 (кстати, недоработка авторов sqlite.dll, что версию нельзя узнать из свойств самой dll в системе, не вызывая функцию по извлечению версии).
Что делать дальше? Можно изменить проверку и завершать только по условию SQLite3_Changes() = 0;
Мне просто непонятна сама причина поведения движка. Хотя, если рассуждать философски, то указание LIMIT 10000000 вроде может и не обязывать движок возвращать
ровно 10000000, т.е. при каких-то условиях он может вернуть и меньше, главное - чтобы не больше.
А почему вы считаете, что удалять частями это плохо? У меня реальной альтернативы пока нет. Ошибка 'Out of memory' - это факт, подтверждённый и на тестовой базе - при удалении большого количества записей из моей базы происходит значительный рост потребления памяти (это прямо видно по "Диспетчеру задач"). Уж не знаю, чем это обусловлено, но база почему-то предпочитает не создать кэш своих данных на диске в этом случае, а именно занимает значительный объём ОЗУ.
