Firebird архиватор

[morphieus]

От известно време насам използвам Инсенити за архиватор на Атонски бази. Доволен съм от него и като цяло функцията му за услуга (при инсталирането му под НТ базирани системи) е доста удобна. Стой си някъде в паметта и си върши работата добре. Чудесна е и функцията да може да копира архивите на допълнително място по файловата система. Не на последно място се намира и опцията за изпращане на архивите по интернет. С развитието на Атон-а и корекциите в движение на Атона се налага доста често да изпращаме бази данни на програмистите за да могат да "уловят" къде се зараждат нашите проблеми. С нарастването на всяка една база данни се увеличава и времето за трансфер (и възможността файла да не пристигне до получателя си). При условие, че все пак говорим за Уиндоус базирана складова система при огромна част от клиентите дадените собственици се възползват и от наличието на интернет поне на една работна станция в работната мрежа на програмата. Това като цяло позволява и архивирането и изпращането на бази към ФТП сървър. Аз лично предлагам следното:

Да може да се конфигурира на всеки клиент потребител и парола във централизиран фтп сървър, от който да могат програмистите по всяко едно време да си "разпънат" един архив от клиент и без проблеми да тестват и решават ситуации по-лесно.

П.С. За мойте клиенти такъв сървър се води компютърът ми в къщи. Доста добра работа ми върши.
Ако се хареса идеята може да се пусне като услуга за всеки един клиент. А кой няма нужда от още един backup на базата "някъде"?

[stoar08]

Преди всичко искам да благодаря за подкрепата

Идеята за централизирано FTP (нещо със стабилна интернет връзка и приличен хард диск) съм я подмятал от както работим с SHOP - да не се лъжем, база 100+ MB по мейл е неприятна процедура ... Да не говорим, че на въпросното FTP може да има "разархиватор", който да поддържа разпънато свежо копие на съответната база, което да е готово за работа и да е не по-старо от 24 часа

Колкото до самия архиватор - ето няколко идеи, за които лично аз съм се сетил, и които могат да бъдат реализирани :
1 Индивидуален, независим график за всяка база
2 Графикът да бъде седмичен
3 Неограничен брой FTP mirror-а, отново индивидуални за всяка база
4 Работа с по-малко временни файлове при машини с повече RAM (.*bk файлът, който ще се компресира да не се пише на хард-а,а да се създава и мачка в RAM-а)

Само т.4 не съм опитал понеже не при всички клиенти RAM е консуматив (за сега ...). Всякакви идеи за подобрения естествено са добре дошли и вероятно всичките, по 1 или друг начин ще съществуват и в Severina (Linux-базираната братовчедка на Insanity). Стига да има интерес - и за MAC ще мога да го портна, но там няма да има бира за първите трима с принoс 8)

Естествено, цялото това нещо е труд (не казвам много, просто труд), който докато Insanity се ползва само от мен и morphieus нямам намерение да насилвам от към време.
Наясно съм, че искането е безплатна опция на съвремието, но просто с цел да докажа умение съм готов да вложа този труд, при условие, че Insanity получи шанса да стане Arc3. Не държа по никой начин да запази името си, да има моето име някъде там, дори сорс-а давам на секундата, стига ми аз да си знам, че съм написал нещо, което се ползва и е добро.

Ако в тази тема се появят в няколко реда ясни и точни условия за този шанс, ще приема, че го получавам.

[morphieus]

30 пъти темата е разглежданата, а само един отговор...

[kondev]

За съжаление този архиватор не се използваше другаде освен при вас. От вчера това вече започна да се променя. Пускаме го активно във Варна и в Пазарджик. Искам да поработи известно време реално и ще действаме натам.

[stoar08]

За съжаление този архиватор не се използваше другаде освен при вас. От вчера това вече започна да се променя. Пускаме го активно във Варна и в Пазарджик. Искам да поработи известно време реално и ще действаме натам.

Благодаря, този ефект беше една от основните цели да "спамя" толкова много из форума.
Понеже обратната връзка е неземно важна, мога да добавя само, че приемам оплаквания, идеи, искания и .т.н. денонощно :
GSM : 0886 715 530
ICQ#: 281898008
skype: intelrullz
mail: intelrullz@data.bg, intelrullz@unrealsoft.net, intelrullz@gmail.com
irc: pentium4


ПС morphieus и kondev още не са казали каква бира пият:). А съм обещал на още 2ма души - големи сте трезвеници, колеги 8)

[kondev]

...morphieus и kondev още не са казали каква бира пият:). А съм обещал на още 2ма души - големи сте трезвеници, колеги 8)

Ще почерпиш на някой банкет

[stoar08]

...morphieus и kondev още не са казали каква бира пият:). А съм обещал на още 2ма души - големи сте трезвеници, колеги 8)

Ще почерпиш на някой банкет

Има бира за morphieus + първите трима с принос, обещал съм . Затова питам за предпочитания

[rad]

Иван наистина черпи!

Дори и с година да забави, не забравя!
8)
Споделям личен опит!

[detelin]

Днес правих проби на програмата, много бавно стават архивите - 40 мин. за 340 мб база, възстановяването пък е още по-бавно, зависи от компютъра, моя в офиса е семпрон на 2600+ с 512 рам памет и почти през цялото време работи на 100% - разликата е 65 мб по-малко след разпъването, но времето е ужасно много - почти 2 часа отне архивирането и разпъването на архива

[stoar08]

Днес правих проби на програмата, много бавно стават архивите - 40 мин. за 340 мб база, възстановяването пък е още по-бавно, зависи от компютъра, моя в офиса е семпрон на 2600+ с 512 рам памет и почти през цялото време работи на 100% - разликата е 65 мб по-малко след разпъването, но времето е ужасно много - почти 2 часа отне архивирането и разпъването на архива

Бира N2 очкавам и от теб предпочитания.


LZMA е наистина бавничко и малко специфично за машината. Компресиращ режим 0 (от настройки) е значително по-бърз, но мисля, че ще даде по-слаби резултати от ZIP.
В момента тествам "on the fly" режим, при който изхода от gbak.exe да не стига до харда при LZMA компресия. Ако ми хареса и го стабилизирам - би следвало да забърза процедурата.
Самият ZIP обаче е неработеща опция при ръчните архиви от gbak.exe - днес ще се постарая да завърша 1-2 други подобрения и да пусна оправена версия.


Ето база за сравнение между LZMA(стандартни настройки) и ZIP (ниво 9) :
arhiv.zip
размер : 34244319 байта
време : 29 секунди
arhiv.lzma
размер : 21677725
време : 254 секунди

Тестът е проведен на Core 2 Duo T7200 с 2GB RAM и работещ BOINC клиент . Тестваната база е 129536000 байта. Данните са за архив с nbackup.exe (ниво 0).

[kondev]

Според мен не е важен чак толкова размера, а най-вече времето за правене на архив.

[stoar08]

Оставил съм съвместимост със ZIP за да има "за всеки цвят и всеки вкус" .
По принцип ангажирането на базата е винаги еднакво като време (докато gbak.exe/nbackup.exe създаде файлът, който да бъде компресиран).
Друга идея на LZMA са случаите, в които трябва да се прати база някъде - тогава обикновено няколко минути повече в компресиране не са фатални, а в някой части на България всеки байт е ценен (живея в 1 от тях) . За това е и опцията за прекомпресиране при Ъплоуд/мейл.

Крайната цел на инструмента е да стане завършено "швейцарско ножче" Може би дори ще проима Web interface, през който да може да се нареди изпращането на база някъде... с няколко кб трансфер и без изисквания към клиентската ОС

[morphieus]

Има ли това почва у нас?

[stoar08]

За почва не знам (статистиката не радва много ...), но скоро ще използва доста по-пълноценно многоядрени системи и ще може да дефрагментира база автоматично (по график)