Actualizarea la o versiune nouă a sarcinii lider atunci când terminare anormală a programului (lt de recuperare a bazei de date) -
Pe exemplul de modernizare de la versiunea 7.3.3.1 la 7.3.7.6
Toate instrumentele utilizate sunt descrise în articolul aici - pentru copii pe SQLite.
Înainte de a începe orice acțiune necesară pentru a face o copie completă a LT dosarul de lucru (doar în cazul). De exemplu, pentru mine este o copie a întregului dosar U: \ ProgramFiles \ LeaderTask.
Toate manipulările trebuie să se facă pe copia bazei de date. Pentru a face acest lucru, copiați fișierul de bază de date, am fi în U: \ ProgramFiles \ LeaderTask \ Data \ ltmain.dbase într-o altă locație, cum ar fi m: \ TEMP.
Orice ai face - faci pe propriul risc, eu iau nici o responsabilitate pentru acțiunile și cererile tale nu vor fi acceptate.
Preambul (sau cine este de vina?)
Când încercați să faceți upgrade prin auto-update la o versiune nouă sarcina de lider (LT), care se încadrează în eroare „Runtime Error! de încetare a programului anormal“.
Apoi, mai întâi am încercat să instaleze o versiune nouă a LT, cu o bază de date curată și apoi a restabili înapoi baza de date. Dar, LT a început să facă „Conversia bazei de date ...“ și a închis la infinit (lăsați-l pe week-end, procesul nu sa încheiat, cu toate că activitatea specifică de monitorizare a resurselor LT nu au fost observate) - a trebuit să decoleze procesul.
Apoi am decis pentru a verifica, dar, în general, pot recupera o versiune mai veche a LT de la o copie de rezervă? Sa dovedit că există. Când încercați să restabiliți programul pentru a produce un „Acces la un fișier fără nume a fost refuzat“ eroare.
GÂNDIRE cu glas tare. După cum sa dovedit, această eroare nu este stabil, deoarece Într-o încercare suplimentară de a recupera baza de date încă recuperate. Si apropo, subiectele forum în LT cu problemele de renovare, a avut o situație similară atunci când actualizarea este în scădere, în scădere, și încă a avut loc pentru a zecea oară. Ie probabil, puteți încerca să reîmprospăta plictisitoare de zece ori într-un rând - poate aluneca prin. Cu toate că, în cazul în care cauza a fost în lilieci bază de date, atunci deși va aluneca, dar va rămâne un liliac.
După toate aceste încercări, ideea a apărut: „Nu este cazul în baza de date?“. Am decis să efectueze vid. Aceasta este o astfel de construcții SQLite echipa sql, cum ar fi defragmentarea baza de date, care, așa cum se comprimă baza de date, eliminând spațiile goale rămase după operațiile DML (insert, update, șterge).
Pentru a verifica baza de date, puteți efectua în continuare PRAGMA integrity_check. (Concluzie eviscerată)
Se pare că baza de date rupt. Apropo, dacă vă verificați integritatea fișierului, de exemplu, Chkdsk atunci totul va fi OK. Ie aceasta este o eroare logică în fișierul bază de date.
GÂNDIRE cu glas tare. În general vorbind, în SQLLite Întrebări frecvente scrise (Ce este o eroare SQLITE_CORRUPT? Ce înseamnă pentru baza de date care urmează să fie «format incorect»? De ce primesc această eroare?) Că el SQLite poate deteriora foarte rar baza de date în cazul în care bug-uri lor. Dar aici e programele externe, bug-uri OS sau fier poate face mult mai des.
Ce să fac?
Ce să fac? Ce să fac? desigur, trebuie doar să restaurați baza de date dintr-o copie de rezervă și toate cazurile.
Dar se pare că toate copiile de rezervă au aceeași problemă - toate acestea sunt rupte. pentru că LT va face probabil doar o copie fizică a fișierului bazei de date, o eroare de logică în fișierul bază de date, de asemenea, devine pentru a copia.
Pentru astfel de cazuri .dump echipa (sqlite3.exe) poate veni la îndemână. Această comandă gropilor de baza de date sau tabele individuale într-un sql-fișier. Care pot fi apoi rula pe alte baze de date. Ie planul este după cum urmează:
- Fă-o bâtă groapa de bază de date
- Crearea unei baze de date nou, gol
- Se toarnă un depozit într-o nouă bază de date
Fac o groapa. îndeplinirea
m: \ TEMP> SQLite3 ltmain.dbase .dump> M: \ TEMP \ aaa.sql
ca urmare a obținerii unui fișier sql-M: \ TEMP \ aaa.sql despre acest conținut
/ **** EROARE: (11) imagine de disc bază de date este incorectă ***** /
Acest lucru sugerează că groapa a fost încercarea de a citi datele din fișierul de bază de date, și nu ar putea, de exemplu, o bucată de date lipsesc, și irevocabil. Verificat cele mai recente copie de rezervă a bazei de date disponibile există deja o eroare, și anume, în cazul meu din care într-adevăr o pierdere permanentă va trebui să accepte.
Creați o nouă bază de date, se face foarte simplu, și imediat se toarnă în ea o groapa. Dump turnat echipa se citi
SQLiteManagen
BEGIN TRANSACTION; [Nu se poate începe o tranzacție în cadrul unei tranzacții]
Excepție Nume: NS_ERROR_FAILURE
Excepție Mesaj: Componentă a returnat codul de eșec: 0x80004005 (NS_ERROR_FAILURE)
[MozIStorageStatement.execute]
Pe scurt, echipa curată.
Apropo, la sfârșitul unei echipe de retroactivitate; - aceasta nu poate afecta nimic, dar am eliminat, de asemenea, doar în cazul în. Commit se face automat.
Am scris un fișier batch start.cmd pentru a începe procesul, pur și simplu pentru a fi capabil să măsoare runtime. Pentru fișierul command.txt auxiliar fișier batch necesare care conține comenzile care sunt de intrare sqlite3.exe. Cu toate acestea, toate acțiunile pot fi efectuate manual. Și aici este fișierele în sine.
PRAGMA page_size = 32768; - Setează dimensiunea paginii bazei de date. Am verificat, am fost cu dimensiunea LT creează o bază de date. Cel mai probabil depinde de sistemul de operare (de exemplu, pe un alt calculator poate fi o altă valoare). Cred că dacă creați o bază de date cu o dimensiune de pagină diferită, nimic nu este teribil. Ea doar poate afecta performanța, dar pentru a înțelege modul în care - trebuie să fie investigate în continuare. Dacă omiteți această comandă, sqlite3.exe creează o bază de date cu o dimensiune a paginii de 1024 octeți. Cu cât dimensiunea paginii, cu atât mai mare este fișierul de bază de date, dar groapa de umplere trece neeemnogo mai repede. Am rupt fișierul de bază de date inițială a fost de 7,5 MB. Când PAGE_SIZE = 1024 a primit fișierul de 3.6 MB si umple timp de 2 minute 19 secunde. Când PAGE_SIZE = 32768 da fișierului 4.6 MB și umple timp de 2 minute 07 secunde.
PRAGMA journal_mode = OFF; - Dezactivați logare. Când această revenire nu mai funcționează, dar pentru a umple nu sunt date importante, deoarece dacă ceva nu merge bine, puteți pur și simplu repetați procesul de umplere de la început, adică, crearea unei baze de date curat. Dar timpul de turnare cu handicap logare redusă la două sau de trei ori. Pentru mine, jurnalizarea umple de timp de 6 minute, fără logare 2 min 19 sec. SQLite Manager de plug-in pentru Firefox poate face importul chiar mai repede, așa că, dacă o bază de date de mare - are sens să-l folosească.
echo% timp%
ltmain777.dbase sqlite3.exe
pauză
PRAGMA page_size = 32768;
PRAGMA journal_mode = OFF;
.citește aaa.sql
.ieșire
În orice caz, trebuie să verificați baza de date de recuperare
Ei bine, asta-i tot. Rămâne de a redenumi baza de date de recuperare M: \ TEMP \ ltmain777.dbase în M: \ TEMP \ ltmain.dbase și copiați fișierul în folderul cu programul de lucru LT (u: \ ProgramFiles \ LeaderTask \ de date) în loc de DB liliac.
Acum puteți lucra și să fie actualizate.
Concluzie (consiliere sau concluzii):
1) În cazul în care LT scade cu terminare anormală de program - verifica integritatea bazei de date.
2) Cine LT (nu stiu ce versiune), scrie fișierul jurnal (U: \ ProgramFiles \ LeaderTask \ Logs), cu care puteți încerca pentru a diagnostica problema.
pentru că Eu încep să fie actualizate tot timpul „peste partea de sus“ și a pus tot felul de experimente pe LT - directorul de program ușor fătat. Așa că am decis să combine actualizarea la noua versiune de curățare la nivel mondial.
Pentru aceasta am îndeplinit păstrarea bazei de date în versiunea mai veche a LT (7.3.3.1) folosind meniul File - Save. Redenumiți folderul vechi cu LT. LT instalat noua versiune (7.3.7.6) complet. LT Lansat. Și folosind meniul File - Deschidere. a restabili baza de date dintr-o copie de rezervă. În același timp, LT a cerut conversia bazei de date la noua versiune (DB lilieci în această etapă a scăzut LT).
fișier Setările, am decis să nu migreze de la o versiune mai veche. Și tocmai a intrat din nou și setați din nou toate setările.
- Autor: Dmitry Bobrovsky Google