Comment débloquer une firebase database SQLite?

sqlite> DELETE FROM mails WHERE (`id` = 71); SQL error: database is locked 

Comment débloquer la firebase database pour que cela fonctionne?

Dans Windows, vous pouvez essayer ce programme http://www.nirsoft.net/utils/opened_files_view.html pour savoir si le processus gère le fichier db. Essayez de fermer ce programme pour déverrouiller la firebase database

Sous Linux et MacOS, vous pouvez faire quelque chose de similaire, par exemple si votre fichier verrouillé est development.db:

$ fuser development.db

Cette commande montre quel processus verrouille le fichier:

> development.db: 5430

Tuez le processus …

tuer -9 5430

… Et votre firebase database sera débloquée.

J’ai bloqué ma firebase database sqlite en plantant une application lors d’une écriture. Voici comment je l’ai réparé:

 echo ".dump" | sqlite old.db | sqlite new.db 

Tiré de: http://random.kakaopor.hu/how-to-repair-an-sqlite-database

La page SQLite wiki DatabaseIsLocked offre une bonne explication de ce message d’erreur. Il indique, en partie, que la source de conflit est interne (au processus émettant l’erreur).

Ce que cette page n’explique pas, c’est comment SQLite décide que quelque chose dans votre processus contient un verrou et quelles conditions peuvent conduire à un faux positif.

Supprimer le fichier -journal semble être une idée terrible. Il est là pour permettre à sqlite de restaurer la firebase database à un état cohérent après un plantage. Si vous le supprimez alors que la firebase database est dans un état incohérent, vous vous retrouvez avec une firebase database corrompue. Citant une page du site sqlite :

En cas de panne ou de panne de courant et si un journal dynamic rest sur le disque, il est essentiel que le fichier de firebase database d’origine et le journal dynamic restnt sur leur disque avec leur nom d’origine jusqu’à ce qu’un autre processus SQLite l’ouvre. . […]

Nous pensons qu’un mode de défaillance courant pour la récupération de SQLite se produit comme suit: une panne de courant se produit. Une fois le courant rétabli, un utilisateur ou un administrateur système bien intentionné commence à rechercher les dommages sur le disque. Ils voient leur fichier de firebase database nommé “important.data”. Ce fichier leur est peut-être familier. Mais après le crash, il y a aussi un journal chaud nommé “important.data-journal”. L’utilisateur supprime ensuite le journal dynamic, pensant qu’il aide à nettoyer le système. Nous ne connaissons aucun moyen d’empêcher cela, sauf l’éducation des utilisateurs.

La restauration est censée se produire automatiquement lors de la prochaine ouverture de la firebase database, mais elle échouera si le processus ne peut pas verrouiller la firebase database. Comme d’autres l’ont dit, une des raisons possibles est qu’un autre processus est actuellement ouvert. Une autre possibilité est un verrou NFS obsolète, si la firebase database se trouve sur un volume NFS. Dans ce cas, une solution consiste à remplacer le fichier de firebase database par une nouvelle copie qui n’est pas verrouillée sur le serveur NFS (mv database.db original.db; cp original.db database.db). Notez que la FAQ sqlite recommande de faire preuve de prudence en ce qui concerne les access simultanés aux bases de données sur les volumes NFS, en raison des mises en œuvre erronées du locking des fichiers NFS.

Je ne peux pas expliquer pourquoi la suppression d’un fichier -journal vous permettrait de verrouiller une firebase database que vous ne pouviez pas auparavant. Est-ce reproductible?

Par ailleurs, la présence d’un fichier -journal ne signifie pas nécessairement qu’il y a eu un plantage ou qu’il y a des modifications à annuler. Sqlite a quelques modes de journal différents, et en modes PERSIST ou TRUNCATE, il laisse toujours le fichier -journal en place et modifie le contenu pour indiquer s’il y a ou non des transactions partielles à annuler.

Si un processus a un verrou sur une firebase database SQLite et se bloque, la firebase database rest définitivement verrouillée. C’est le problème. Ce n’est pas qu’un autre processus a un verrou.

Si vous souhaitez supprimer une erreur “firebase database verrouillée”, procédez comme suit:

  1. Copiez votre fichier de firebase database vers un autre emplacement.
  2. Remplacez la firebase database par la firebase database copiée. Cela déréférencera tous les processus qui accédaient à votre fichier de firebase database.

les fichiers SQLite db ne sont que des fichiers, la première étape serait de s’assurer qu’elle n’est pas en lecture seule. L’autre chose à faire est de vous assurer que vous n’avez pas de visualiseur de firebase database SQLite avec la firebase database ouverte. Vous pourriez avoir la firebase database ouverte dans un autre shell, ou votre code peut avoir la firebase database ouverte. En règle générale, vous verriez cela si un thread différent, ou une application telle que SQLite Database Browser, a ouvert le DB pour l’écriture.

J’ai eu ce problème tout à l’heure, en utilisant une firebase database SQLite sur un serveur distant, stockée sur un assembly NFS. SQLite n’a pas réussi à obtenir un verrou après que la session shell distante que j’ai utilisée s’est bloquée pendant que la firebase database était ouverte.

Les recettes de récupération suggérées ci-dessus n’ont pas fonctionné pour moi (y compris l’idée de déplacer d’abord la firebase database, puis de la copier). Mais après l’avoir copié sur un système non-NFS, la firebase database est devenue utilisable et aucune donnée ne semble avoir été perdue.

J’ai trouvé la documentation des différents états de locking dans SQLite très utile. Michael, si vous pouvez effectuer des lectures mais ne peut pas effectuer d’écriture dans la firebase database, cela signifie qu’un processus a obtenu un verrou RESERVED sur votre firebase database, mais qu’il n’a pas encore exécuté l’écriture. Si vous utilisez SQLite3, il existe un nouveau verrou appelé PENDING, dans lequel plus aucun processus n’est autorisé à se connecter, mais les connexions existantes peuvent effectuer des lectures.

Cette erreur peut être générée si le fichier se trouve dans un dossier distant, comme un dossier partagé. J’ai changé la firebase database en un répertoire local et cela a fonctionné parfaitement.

Mon verrou a été causé par le blocage du système et non par un processus de suspension. Pour résoudre ce problème, j’ai simplement renommé le fichier, puis recopié son nom et son emplacement d’origine.

Utiliser un shell Linux qui serait …

 mv mydata.db temp.db cp temp.db mydata.db 

J’ai un tel problème dans l’application, qui accède à SQLite à partir de 2 connexions – l’une était en lecture seule et l’autre pour l’écriture et la lecture. Il semble que cette connexion en lecture seule ait bloqué l’écriture de la seconde connexion. Enfin, il s’avère qu’il est nécessaire de finaliser ou, au moins, de réinitialiser IMMÉDIATEMENT les instructions préparées après utilisation. Tant que l’instruction préparée n’est pas ouverte, elle a été bloquée pour écriture dans la firebase database.

N’OUBLIEZ PAS D’APPELER:

 sqlite_reset(xxx); 

ou

 sqlite_finalize(xxx); 

Certaines fonctions, comme INDEX, peuvent prendre beaucoup de temps et verrouiller toute la firebase database pendant son exécution. Dans des cas comme celui-là, il est possible que le fichier journal ne soit même pas utilisé!

Donc, la meilleure et la seule façon de vérifier si votre firebase database est verrouillée parce qu’un processus y écrit activement (et vous devriez donc la laisser seule jusqu’à la fin de son opération) est de md5 (ou md5sum sur certains systèmes) le fichier deux fois . Si vous obtenez une sum de contrôle différente, la firebase database est en cours d’écriture et vous ne voulez vraiment pas tuer ce processus car vous pouvez facilement vous retrouver avec une table / firebase database corrompue.

Je vais répéter, car c’est important – la solution n’est PAS de trouver le programme de locking et de le tuer – c’est de savoir si la firebase database dispose d’un verrou en écriture pour une bonne raison, et de partir de là. Parfois, la solution correcte n’est qu’une pause café.

La seule façon de créer cette situation verrouillée mais non en cours d’inscription est si votre programme exécute BEGIN EXCLUSIVE , car il souhaite effectuer des modifications de table ou quelque chose, alors pour une raison quelconque, il n’envoie plus END par la suite, et le processus ne se termine jamais Les trois conditions remplies sont très improbables dans tout code correctement écrit, et à ce titre, 99 fois sur 100, lorsque quelqu’un souhaite supprimer son processus de locking, le processus de locking verrouille en fait votre firebase database pour une bonne raison. En règle générale, les programmeurs n’ajoutent pas la condition BEGIN EXCLUSIVE moins qu’ils en aient vraiment besoin, car cela empêche la concurrence et augmente les plaintes des utilisateurs. SQLite lui-même ne l’ajoute que lorsqu’il en a vraiment besoin (comme lors de l’indexation).

Enfin, le statut «verrouillé» n’existe pas à l’intérieur du fichier, comme plusieurs réponses l’ont indiqué – il réside dans le kernel du système d’exploitation. Le processus qui a exécuté BEGIN EXCLUSIVE a demandé au système d’exploitation de verrouiller le fichier. Même si votre processus exclusif est tombé en panne, votre système d’exploitation sera en mesure de déterminer s’il doit ou non conserver le locking du fichier !! Il n’est pas possible de se retrouver avec une firebase database verrouillée mais aucun processus ne le verrouille activement !! Quand il s’agit de voir quel processus verrouille le fichier, il est généralement préférable d’utiliser lsof plutôt que fuser (c’est une bonne démonstration de pourquoi: https://unix.stackexchange.com/questions/94316/fuser-vs-lsof- to-check-files-in-use ). Si vous avez DTrace (OSX), vous pouvez également utiliser iosnoop dans le fichier.

J’ai ajouté ” Pooling=true ” à la chaîne de connexion et cela a fonctionné.

Il m’est arrivé quelque chose de similaire: mon application Web était capable de lire depuis la firebase database, mais elle ne pouvait effectuer aucune insertion ou mise à jour. Un redémarrage d’Apache a résolu le problème au moins temporairement.

Ce serait bien, cependant, d’être capable de retrouver la cause profonde.

La commande lsof sur mon environnement Linux m’a aidé à comprendre qu’un processus était suspendu en gardant le fichier ouvert.
Tué le processus et le problème a été résolu.

Ce lien résout le problème. : Lorsque Sqlite donne: Erreur de locking de la firebase database Résolu mon problème peut vous être utile.

Et vous pouvez utiliser begin transaction et end transaction pour ne pas rendre la firebase database verrouillée à l’avenir.

Devrait être le problème interne d’une firebase database …
Pour moi, cela s’est manifesté après avoir essayé de parcourir la firebase database avec le “gestionnaire SQLite” …
Donc, si vous ne pouvez pas trouver un autre processus, connectez-vous à la firebase database et que vous ne pouvez tout simplement pas y remédier, essayez simplement cette solution radicale:

  1. Fournir pour exporter vos tables (Vous pouvez utiliser “Gestionnaire SQLite” sur Firefox)
  2. Si la migration modifie votre schéma de firebase database, supprimez la dernière migration ayant échoué
  3. Renommez votre fichier “database.sqlite”
  4. Exécutez “rake db: migrate” pour créer une nouvelle firebase database de travail
  5. Fournir pour donner les permissions appropriées à la firebase database pour l’importation de table
  6. Importez vos tables sauvegardées
  7. Ecrire la nouvelle migration
  8. Exécutez-le avec ” rake db:migrate

J’ai rencontré ce même problème sur Mac OS X 10.5.7 exécutant des scripts Python à partir d’une session de terminal. Même si j’avais arrêté les scripts et que la fenêtre du terminal se trouvait à l’invite de commandes, cela donnerait cette erreur la prochaine fois qu’elle s’exécuterait. La solution consistait à fermer la fenêtre du terminal et à l’ouvrir à nouveau. Cela n’a pas de sens pour moi, mais ça a marché.

Je viens d’avoir la même erreur. Après 5 minutes de google-ing, j’ai découvert que je n’avais pas fermé un shell utilisant la firebase database. Fermez le et réessayez;)

J’ai eu le même problème. Apparemment, la fonction de restauration semble écraser le fichier de firebase database avec le journal, qui est identique au fichier de firebase database, mais sans les modifications les plus récentes. Je l’ai implémenté dans mon code ci-dessous et cela fonctionne bien depuis, alors qu’avant mon code était simplement bloqué dans la boucle car la firebase database restait bloquée.

J’espère que cela t’aides

mon code python

 ############## #### Defs #### ############## def conn_exec( connection , cursor , cmd_str ): done = False try_count = 0.0 while not done: try: cursor.execute( cmd_str ) done = True except sqlite.IntegrityError: # Ignore this error because it means the item already exists in the database done = True except Exception, error: if try_count%60.0 == 0.0: # print error every minute print "\t" , "Error executing command" , cmd_str print "Message:" , error if try_count%120.0 == 0.0: # if waited for 2 miutes, roll back print "Forcing Unlock" connection.rollback() time.sleep(0.05) try_count += 0.05 def conn_comit( connection ): done = False try_count = 0.0 while not done: try: connection.commit() done = True except sqlite.IntegrityError: # Ignore this error because it means the item already exists in the database done = True except Exception, error: if try_count%60.0 == 0.0: # print error every minute print "\t" , "Error executing command" , cmd_str print "Message:" , error if try_count%120.0 == 0.0: # if waited for 2 miutes, roll back print "Forcing Unlock" connection.rollback() time.sleep(0.05) try_count += 0.05 ################## #### Run Code #### ################## connection = sqlite.connect( db_path ) cursor = connection.cursor() # Create tables if database does not exist conn_exec( connection , cursor , '''CREATE TABLE IF NOT EXISTS fix (path TEXT PRIMARY KEY);''') conn_exec( connection , cursor , '''CREATE TABLE IF NOT EXISTS tx (path TEXT PRIMARY KEY);''') conn_exec( connection , cursor , '''CREATE TABLE IF NOT EXISTS completed (fix DATE, tx DATE);''') conn_comit( connection ) 

Une des raisons courantes pour obtenir cette exception est lorsque vous essayez d’effectuer une opération d’écriture tout en conservant des ressources pour une opération de lecture. Par exemple, si vous sélectionnez une table, puis essayez de mettre à jour quelque chose que vous avez sélectionné sans fermer votre ResultSet en premier.

Avant d’arrêter l’option de redémarrage, il est utile de voir si vous pouvez trouver l’utilisateur de la firebase database sqlite.

Sous Linux, on peut employer une fuser de fuser à cette fin:

 $ fuser database.db $ fuser database.db-journal 

Dans mon cas, j’ai reçu la réponse suivante:

 philip 3556 4700 0 10:24 pts/3 00:00:01 /usr/bin/python manage.py shell 

Ce qui a montré que j’avais un autre programme Python avec le pid 3556 (manage.py) utilisant la firebase database.

Une vieille question, avec beaucoup de réponses, voici les étapes que j’ai suivies récemment en lisant les réponses ci-dessus, mais dans mon cas, le problème était dû au partage de ressources cifs. Ce cas n’est pas signalé précédemment, alors espérons qu’il aide quelqu’un.

  • Vérifiez qu’aucune connexion n’est laissée ouverte dans votre code Java.
  • Vérifiez qu’aucun autre processus n’utilise votre fichier SQLite db avec lsof.
  • Vérifiez que le propriétaire de votre processus jvm en cours d’exécution dispose d’permissions r / w sur le fichier.
  • Essayez de forcer le mode de locking sur l’ouverture de la connexion avec

     final SQLiteConfig config = new SQLiteConfig(); config.setReadOnly(false); config.setLockingMode(LockingMode.NORMAL); connection = DriverManager.getConnection(url, config.toProperties()); 

Si vous utilisez votre fichier de firebase database SQLite sur un dossier partagé NFS, vérifiez ce sharepoint la FAQ SQLite et passez en revue vos options de configuration de assembly pour vous assurer que vous évitez les verrous, comme décrit ici :

 //myserver /mymount cifs username=*****,password=*****,iocharset=utf8,sec=ntlm,file,nolock,file_mode=0700,dir_mode=0700,uid=0500,gid=0500 0 0 

J’ai eu cette erreur dans un scénario un peu différent de ceux décrits ici.

La firebase database SQLite reposait sur un système de fichiers NFS partagé par 3 serveurs. Sur deux des serveurs que j’ai pu exécuter avec succès sur la firebase database, sur le troisième, je pensais recevoir le message “La firebase database est verrouillée”.

Le truc avec cette 3ème machine était qu’il n’y avait plus d’espace sur /var . Chaque fois que j’essayais d’exécuter une requête dans N’IMPORTE QUELLE firebase database SQLite située dans ce système de fichiers, j’ai reçu le message “La firebase database est verrouillée” ainsi que cette erreur sur les journaux:

Aug 8 10:33:38 server01 kernel: lockd: impossible de surveiller 172.22.84.87

Et celui-ci aussi:

8 août 10:33:38 server01 rpc.statd [7430]: Impossible d’insérer: écriture /var/lib/nfs/statd/sm/other.server.name.com: aucun espace disponible 8 août 10:33: 38 server01 rpc.statd [7430]: STAT_FAIL à server01 pour SM_MON de 172.22.84.87

Après le traitement de la situation, tout est rentré dans l’ordre.

D’après vos commentaires précédents, un fichier de journal était présent.

Cela pourrait signifier que vous avez ouvert et (EXCLUSIVE?) Transaction et n’avez pas encore engagé les données. Votre programme ou un autre processus a-t-il laissé le journal derrière?

Le redémarrage du processus sqlite examinera le fichier journal et nettoiera toutes les actions non validées et supprimera le fichier -journal.

Comme l’a dit Seun Osewa, parfois un processus de zombies sera installé dans le terminal avec un verrou acquis, même si vous ne le pensez pas. Votre script s’exécute, tombe en panne, et vous revenez à l’invite, mais il y a un processus de zombie généré quelque part par un appel de bibliothèque, et ce processus a le verrou.

La fermeture du terminal dans lequel vous vous trouviez (sous OSX) pourrait fonctionner. Le redémarrage fonctionnera. Vous pouvez rechercher des processus “python” (par exemple) qui ne font rien et les tuer.

vous pouvez essayer ceci: .timeout 100 pour définir le délai d’attente. Je ne sais pas ce qui se passe en ligne de commande mais en C # .Net quand je fais ceci: "UPDATE table-name SET column-name = value;" J’obtiens que la firebase database est verrouillée mais cette "UPDATE table-name SET column-name = value" ça va bien.

Il semble que lorsque vous ajoutez, sqlite recherchera d’autres commandes.

J’ai eu cette erreur lors de l’utilisation de Delphi avec les composants LiteDAC. Il s’est avéré que cela ne se produisait que lors de l’exécution de mon application à partir de l’EDI Delphi si la propriété Connected était définie sur True pour le composant de connexion SQLite (dans ce cas, TLiteConnection).

Adminer est une petite (mais puissante) alternative phpmyadmin que j’utilise pour surveiller la firebase database sqlite. Pour une raison quelconque, la firebase database a été verrouillée. Voici comment je l’ai corrigé.

  1. J’ai téléchargé le fichier sqlite sur mon système (FTP)
  2. Supprimé le fichier sqlite en ligne
  3. Téléchargement du fichier vers le fournisseur d’hébergement

Cela fonctionne très bien maintenant.