J'ai une base de données SQLite3 sur certains systèmes que je dois télécharger pendant une opération en cours. Arrêter ou mettre en pause les processus d'accès n'est pas une option. Donc, aussi loin que je comprenne, j'ai besoin de conserver une serrure partagée (comme décrit dans http://www.sqlite.org/Lockingv3. HTML ) à la DB pendant le téléchargement pour éviter les modifications et la corruption de DB pendant le téléchargement. Comment puis-je obtenir explicitement une telle serrure? Le téléchargement est contrôlé à partir d'un programme C ++ et je devrais donc obtenir le verrou.
Edit: Thkala a suggéré de faire une décharge de dB. Mais je préférerais trouver une solution avec un verrouillage car je ne suis pas sûr s'il ya suffisamment de mémoire disponible pour une copie complète de la DB.
3 Réponses :
Non, non. non et non!
Message avec des serrures et copier des fichiers à la main est l'ancienne façon de faire des choses. SQLite a maintenant un API de sauvegarde que vous pouvez utiliser. Il est recommandé d'effectuer des copies en ligne d'une base de données SQLITE - vous pouvez l'utiliser pour créer une copie de la base de données, qui peut ensuite être téléchargée à votre convenance.
EDIT:
Si vous êtes absolument avez utiliser le verrouillage, vous pouvez utiliser la méthode décrite ici - éventuellement après avoir traduit en C:
ouvre la base de données
Utilisez le copiez / téléchargez les fichiers manuellement - assurez-vous de ne pas manquer. Il y a au moins le fichier db, le fichier journal et éventuellement le fichier wal. Vous voudrez peut-être placer la base de données dans un répertoire séparé pour rendre les choses plus simples.
Je comprends comment cette méthode pourrait être utile dans certains cas, mais je dois répéter que ce n'est pas la méthode recommandée.
commencer immédiatement déclaration pour acquérir un Verroutage partagé.
Rollback La transaction que vous venez de commencer. < / p>
Je ne connaissais pas l'API de sauvegarde, très agréable!
L'utilisation de l'API de sauvegarde est un problème car je ne suis pas sûr si j'ai suffisamment d'espace disponible pour effectuer une copie complète de la DB.
La solution ici est fausse, laissant la postérité et que les gens apprennent pourquoi c'est une mauvaise idée.
Je pense que vous pouvez également vous en sortir avec la copie de la base de données avec le journal. (Copiez les fichiers DB et Journal aux fichiers TMP, puis téléchargez-les), puis sur l'extrémité distante, essayez d'ouvrir cette base de données et celle-ci fixera lui-même. Ceci est fourni que l'application utilise des transactions appropriées.
Veuillez lire ci-dessous des commentaires qui expliquent pourquoi c'est faux:
Le gist, vous pouvez copier le db & journal, mais seulement si vous pourrait obtenir les deux d'exactement le même instant dans le temps.
qui est plus ou moins impossible.
NON! NON! NON! Ceci a recette pour la corruption de données! Les revues DB nécessitent une sémantique appropriée des systèmes de fichiers - que vous n'avez pas à la copie de fichiers sur un réseau. -1
Problème 1: Sur le Web, le fichier db pourrait être téléchargé des secondes ou même minutes après / avant le journal
Je ne pense pas que cela fonctionnera s'il y a un accès en écriture lors de la copie.
Mais la revue n'est-elle pas censée prévenir la corruption des données? J'ai explicitement dit de copier lesdits fichiers afin que les secondes soient hors de question.
Problème 2: Il est tout à fait possible que lorsque vous téléchargez la base de données, le début du fichier sera à la transaction n, et au moment où vous avez terminé, la fin sera à la transaction n + m ...
Je conviens que c'est une façon totalement non correcte d'atteindre cette tâche, mais j'aimerais voir un test si cela fonctionne. Imaginez, lors de la perte de puissance, un fichier pourrait déjà être synchronisé et l'autre non. Il doit y avoir quelque chose d'empêcher l'incohérence.
@Rushpl: Les secondes ne sont pas hors de question. Le fichier DB peut avoir une taille significative et l'accès au fichier sera lent (carte CF). En outre, le jeu ne semble pas approprié ici.
C'est un peu de jeu, n'est-ce pas? Je ne discuterais pas. Acclamations.
Pour clarifier: Oui, le journal empêche la corruption du fichier. Mais il le fait parce que le journal et le fichier db sont conservés dans Lockstep (ils sont modifiés dans un certain ordre). Lisez comment SQLITE implémente atomique commit: sqlite.org/atomiccommit.html pour plus de détails. Le gist, vous pouvez copier le DB & Journal, mais seulement si vous pouviez obtenir exactement le même instant à temps.
Je suis un peu négligé la solution: Démarrez une transaction avec
END TRANSACTION