Надграждане до нова версия на задачата за лидер при аварийно прекъсване на програмата (LT възстановяване на база данни) -
На примера на обновяване от версия 7.3.3.1 до 7.3.7.6
Всички използвани инструменти са описани в статията тук - легло на SQLite.
Преди започване на всяко действие, необходимо да се направи пълно копие на LT работната папка (за всеки случай). Например, за мен това е копие на цялата папка U: \ ProgramFiles \ LeaderTask.
Всички манипулации трябва да се правят на копие на базата данни. За да направите това, да копирате файла с базата данни, имам ли да бъде в U: \ ProgramFiles \ LeaderTask \ Data \ ltmain.dbase по някакъв друг място, като m: \ TEMP.
Каквото и да правиш - направи го направите на свой собствен риск, аз приемаме не носи отговорност за своите действия и искове няма да бъдат приемани.
Преамбюл (или Кой е виновен?)
Когато се опитате да обновите чрез актуализира автоматично до нова версия Лидер Task (LT), попадащи в грешка "Грешка по време! аварийно прекъсване на програмата ".
Тогава за пръв път се опитах да инсталирате нова версия на LT с чиста база данни и след това да ги възстановите резервно копие на базата данни. Но LT започнах да правя "Преобразуване на база данни ..." и затвори до безкрайност (я оставите през уикенда, процесът не е приключил, въпреки че не са наблюдавани на монитора специфична активност на LT ресурси) - трябваше да излети на процеса.
Тогава реших да проверя, но като цяло не мога да се възстанови по-стара версия на LT от резервно копие? Оказа се, че има. Когато се опитате да се възстанови програмата, за да доведе до грешка "Достъпът до неназован файл е отказан".
МИСЛЕНЕ на глас. Както се оказа, тази грешка не е стабилна, тъй като В по-нататъшен опит да се възстанови базата данни все още се възстанови. И между другото, във форума теми в LT с проблемите на обновяването, са имали подобна ситуация, когато актуализацията е леело, и все още се провежда за десети път. Т.е. Може би можете да опитате да опресните скучна десет пъти подред - може да се измъкне. Въпреки че, ако причината е в прилеп база данни, а след това, въпреки че ще се измъкне, но ще остане бухалка.
След всички тези опити, възникна идеята: "Не е ли така в базата данни?". Реших да извършва вакуум. Това е толкова специален екип SQL SQLite а като дефрагментиране на базата данни, която, както се компресира базата данни, премахване на празните пространства, след операциите DML (вписване, актуализиране, изтриване).
За проверка на базата данни, вие все още може да изпълнява PRAGMA integrity_check. (Заключение хриле)
Оказва се, че базата данни счупен. Между другото, ако проверите целостта на файла, например Chkdsk тогава всичко ще е ОК. Т.е. това е някаква логика грешка във файла с базата данни.
МИСЛЕНЕ на глас. Най-общо казано, в sqllite с често задавани въпроси писмено (Какво е грешка SQLITE_CORRUPT? Какво означава това за базата данни, за да се «неправилно образуван»? Защо получавам тази грешка?) Това, че той може да SQLite много рядко повреди в базата данни, ако техните грешки. Но ето външни програми, OS грешки или желязо могат да го направят много по-често.
Какво да се прави?
Какво да се прави? Какво да се прави? разбира се, просто трябва да я възстанови от резервно копие и всички случаи.
Но се оказва, че всички архиви имат същия проблем - всички те са счупени. защото LT-вероятно ще трябва само да се физическо копие на файла с базата данни, а логическа грешка във файла с база данни също така получава и да копирате.
За такива случаи .dump отбор (sqlite3.exe) може да дойде по-удобно. Тази команда сметища базата данни или отделни таблици в SQL-файл. Които след това могат да се движат по други бази данни. Т.е. планът е както следва:
- Уверете се изсере база данни бухалка
- Създаване на нова, празна база данни
- Изсипете сметището в нова база данни
Аз правя един сметище. изпълнение
т: \ TEMP> sqlite3 ltmain.dbase .dump> М: \ TEMP \ aaa.sql
в резултат на получаване на SQL файл M: \ TEMP \ aaa.sql за това съдържание
/ **** ГРЕШКА: (11) диск с данни за изображенията се дължи на неправилни ***** /
Това предполага, че сметището се опитва да чете данни от файла с базата данни, и не може, т.е. парче липсват данни и безвъзвратно. Проверени последната налична резервната база данни вече съществува грешка, т.е. в моя случай това наистина трайна загуба на които ще трябва да се приеме.
Създаване на нова база данни, това е направено много просто, и веднага се излива в нея се изсере. Самосвал изсипва отбор .read
SQLiteManagen
ЗАПОЧНЕТЕ сделка; [Не можете да започнете сделка в рамките на една транзакция]
Изключение Име: NS_ERROR_FAILURE
Изключение Съобщение: Компонент върна провал код: 0x80004005 (NS_ERROR_FAILURE)
[MozIStorageStatement.execute]
С една дума, екипът чист.
Между другото, в края на екип от намаление на цените; - тя не може да повлияе на нищо, но аз го отстранили, също за всеки случай. Поемане на ангажимент се извършва автоматично.
Написах една партида файл start.cmd да започне процеса, просто, за да може да се измери издръжливостта й. За партида файл, необходим помощен command.txt файла, който съдържа команди, които се въвеждат sqlite3.exe. Въпреки това, всички действия могат да се извършват ръчно. И тук е на самите файлове.
PRAGMA PAGE_SIZE = 32768; - Задава размера на страницата на база данни. Проверих, аз бях с размера на LT създава база данни. Най-вероятно зависи от операционната система (т.е. на друг компютър може да бъде друга стойност). Мисля, че ако се създаде база данни с различен размер на страницата, нищо страшно не е така. Това само може да се отрази на работата, но за да се разбере как - трябва да бъдат допълнително разследвани. Ако пропуснете тази команда, за sqlite3.exe създава база данни с размер на страница от 1024 байта. Колкото по-голям размер на страницата, толкова по-висока е файла с базата данни, но запълване сметище преминава neeemnogo по-бързо. Счупих оригиналния файл на базата данни е 7,5 MB. Когато PAGE_SIZE = 1024 получи досието на 3,6 MB и попълнете време 2 минути 19 секунди. Когато PAGE_SIZE = 32768 даде 4.6 MB файл и да попълните време 2 минути 07 секунди.
PRAGMA journal_mode = OFF; - Изключване на сеч. Когато това намаление на цените спира да работи, но за запълване не е важно на данни, тъй като ако нещо се обърка, можете просто да повторите процеса на пълнене от самото начало, което е, създаване на чиста база данни. Но налива време с дърводобив инвалиди намалява до два или три пъти. За мен журнал запълни времето на 6 минути, без да излизате 2 мин 19 сек. SQLite мениджър плъгин за Firefox може да направи внос дори по-бързо, така че ако една голяма база данни - че има смисъл да го използвате.
ехо% време%
sqlite3.exe ltmain777.dbase
пауза
PRAGMA PAGE_SIZE = 32768;
PRAGMA journal_mode = OFF;
.прочетете aaa.sql
.изход
Във всеки случай, трябва да се провери базата данни за възстановяване
Е, това е всичко. Остава да преименувате М база данни за възстановяване: \ TEMP \ ltmain777.dbase в M: \ TEMP \ ltmain.dbase и копирате файла в папката на работа LT програма (ф: \ ProgramFiles \ LeaderTask \ Data), вместо DB бухалка.
Сега можете да работите и да се актуализира.
Заключение (съвети или заключения):
1) Ако LT пада с аварийно прекъсване програма - проверка на целостта на базата данни.
2) Който LT (не знам коя версия), пише лог файла (U: \ ProgramFiles \ LeaderTask \ Logs), с които можете да се опитате да диагностицирате проблема.
защото Започвам да се актуализира през цялото време "над върха" и сложи всякакви експерименти с LT - програма папка леко осеяна. Затова реших да се съчетаят актуализацията на новата версия от глобалната почистване.
За това съм изпълнил запазването на базата данни в по-старата версия на LT (7.3.3.1), като използвате менюто Файл - Съхраняване. Преименуване на старата папка с LT. LT инсталирана нова версия (7.3.7.6) напълно. Стартирана LT. И чрез менюто File - Open. възстановяване на базата данни от резервно копие. В същото време, LT призова конвертиране на база данни към новата версия (DB прилеп в тази стъпка падна LT).
Настройките на файлове, реших да не мигрират от по-стара версия. И току-що влезе отново и отново зададете всички настройки.
- Автор: Дмитрий Bobrovsky Google