Как я разблокировал базу данных SQLite?
Ответ на этот вопрос выше, просто чтобы вы чувствовали себя комфортно, используя все четыре строки одновременно в соединении
<?php
define("DB_HOST", "localhost");
define("DB_USER", "root");
define("DB_PASSWORD", "");
define("DB_DATABASE", "databasename");
$db = new mysqli(DB_SERVER, DB_USERNAME, DB_PASSWORD, DB_DATABASE);
// you could test connection eventually using a if and else conditional statement,
// feel free to take out the code below once you see Connected!
if ($db) {
echo "Connected!";
} else {
echo "Connection Failed";
}
?>
13 ответов
В Windows вы можете попробовать эту программу http://www.nirsoft.net/utils/opened_files_view.html , чтобы узнать, что процесс обрабатывает файл базы данных. Попробуйте закрыть эту программу для разблокировки базы данных
В Linux и macOS вы можете сделать что-то подобное, например, если ваш заблокированный файл - development.db:
$ fuser development.db
Эта команда покажет, что за процесс блокировка файла:
> development.db: 5430
Просто завершите процесс ...
kill -9 5430
... И ваша база данных будет разблокирована.
Из Ваших предыдущих комментариев Вы сказали - файл журнала присутствовал.
Это могло означать, что Вы открылись и (ЭКСКЛЮЗИВНЫЙ?) транзакция и еще не фиксировали данные. Ваша программа или некоторый другой процесс уезжают - журналируют позади??
Перезапуск процесса sqlite посмотрит на файл журнала и очистит любые незафиксированные действия и удалит - файл журнала.
Упомянутая ниже страница DatabaseIsLocked больше не доступна. Страница File Locking And Concurrency описывает изменения, связанные с захватом файла, представленным в v3, и может быть полезна для будущих читателей. https://www.sqlite.org/lockingv3.html
страница SQLite wiki DatabaseIsLocked предлагает хорошее объяснение этого сообщения об ошибке. Это указывает, частично, что источник конкуренции является внутренним (к процессу, испускающему ошибку).
то, Что не объясняет эта страница, - то, как SQLite решает, что что-то в Вашем процессе содержит блокировку и что условия могли привести к положительной лжи.
Если процесс имеет блокировку на DB SQLite и катастрофических отказах, DB остается заблокированным постоянно. Это - проблема. It не, что некоторый другой процесс имеет блокировку.
файлы дб SQLite являются просто файлами, таким образом, первый шаг должен был бы удостовериться, что это не только для чтения. Другая вещь сделать состоит в том, чтобы удостовериться, что у Вас нет своего рода GUI средством просмотра DB SQLite с DB открытый. У Вас мог быть DB, открытый в другой оболочке, или Ваш код может иметь открытый DB. Обычно Вы видели бы это, если различный поток или приложение, такое как Браузер Базы данных SQLite имеет DB, открытый для записи.
Я нашел документация из различных состояний привязки SQLite быть очень услужливым. Michael, если Вы можете выполнить чтения, но не можете выполнить записи к базе данных, которая означает, что процесс получил ЗАРЕЗЕРВИРОВАННОЕ, соединяет Вашу базу данных, но еще не выполнил запись. При использовании SQLite3 существует названное ОЖИДАНИЕ новой блокировки, где больше процессов не позволяют соединиться, но существующие соединения могут подоконник выполнять чтения, поэтому если это - проблема, необходимо посмотреть на это вместо этого.
У меня просто было что-то подобное, происходят со мной - мое веб-приложение смогло читать из базы данных, но не могло работать, любой вставляет или обновляет. Перезагрузка Apache решила проблему, по крайней мере, временно.
было бы хорошо, однако, быть в состоянии разыскать первопричину.
Я столкнулся с той же проблемой в Mac OS X 10.5.7, выполняя сценарии Python из сеанса терминала. Несмотря на то, что я остановил скрипты и окно терминала находилось в командной строке, при следующем запуске оно выдало бы эту ошибку. Решением было закрыть окно терминала, а затем снова открыть его. Для меня это не имеет смысла, но это сработало.
Deleting the -journal file sounds like a terrible idea. It's there to allow sqlite to roll back the database to a consistent state after a crash. If you delete it while the database is in an inconsistent state, then you're left with a corrupted database. Citing a page from the sqlite site:
If a crash or power loss does occur and a hot journal is left on the disk, it is essential that the original database file and the hot journal remain on disk with their original names until the database file is opened by another SQLite process and rolled back. [...]
We suspect that a common failure mode for SQLite recovery happens like this: A power failure occurs. After power is restored, a well-meaning user or system administrator begins looking around on the disk for damage. They see their database file named "important.data". This file is perhaps familiar to them. But after the crash, there is also a hot journal named "important.data-journal". The user then deletes the hot journal, thinking that they are helping to cleanup the system. We know of no way to prevent this other than user education.
The rollback is supposed to happen automatically the next time the database is opened, but it will fail if the process can't lock the database. As others have said, one possible reason for this is that another process currently has it open. Another possibility is a stale NFS lock, if the database is on an NFS volume. In that case, a workaround is to replace the database file with a fresh copy that isn't locked on the NFS server (mv database.db original.db; cp original.db database.db). Note that the sqlite FAQ recommends caution regarding concurrent access to databases on NFS volumes, because of buggy implementations of NFS file locking.
I can't explain why deleting a -journal file would let you lock a database that you couldn't before. Is that reproducible?
By the way, the presence of a -journal file doesn't necessarily mean that there was a crash or that there are changes to be rolled back. Sqlite has a few different journal modes, and in PERSIST or TRUNCATE modes it leaves the -journal file in place always, and changes the contents to indicate whether or not there are partial transactions to roll back.
Моя блокировка была вызвана сбоем системы, а не зависанием. Чтобы решить эту проблему, я просто переименовал файл, а затем скопировал его обратно в его исходное имя и местоположение.
Используя оболочку Linux, которая будет ...
mv mydata.db temp.db
cp temp.db mydata.db
Как сказал Сын Осева, иногда зомби-процесс будет сидеть в терминале с запрошенным замком, даже если вы не думаете, что это возможно. Ваш скрипт запускается, выходит из строя, и вы возвращаетесь к подсказке, но где-то возникает зомби-процесс, вызванный вызовом библиотеки, и этот процесс имеет блокировку.
Закрытие терминала, в котором вы находились (на OSX), может сработать. Перезагрузка сработает. Вы можете искать "питоновские" процессы (например), которые ничего не делают, и убить их.
.Перед тем, как перейти к параметру перезагрузки, стоит посмотреть, сможете ли вы найти пользователя базы данных sqlite.
В Linux для этого можно использовать fuser :
$ fuser database.db
$ fuser database.db-journal
В моем случае я получил следующий ответ:
philip 3556 4700 0 10:24 pts/3 00:00:01 /usr/bin/python manage.py shell
который показал, что у меня есть другая программа Python с pid 3556 (manage.py ) с использованием базы данных.
вы можете попробовать следующее: .timeout 100 , чтобы установить время ожидания.
Я не знаю, что происходит в командной строке, но в C # .Net, когда я делаю это: «ОБНОВИТЬ имя-таблицы SET имя-столбца = значение;« Я получаю, что база данных заблокирована, но это » ОБНОВЛЕНИЕ имя-таблицы УСТАНОВИТЬ имя-столбца = значение " все идет нормально.
Похоже, что когда вы добавите;, sqlite будет искать дальнейшую команду.