Разлики между СПО и справка наличности.

[boris]

Има 3-4 обекта които все още си следят тези две операции, но не знам до кога.
Лошото е че базите са големи, прейзчилсението трае над 20 часа, през което време почти не може да се работи с програмите. А и накрая се налага и бекъп рестор, заради самият Атонс.

Явно няма подобни проблеми при колеги, та ако може да споделят как го правят при тях, та да не ги занимават с глупости.

[mIRCata]

Ако е това, което говорихме с изпратената база на Камена - оправено в следващата версия.

[boris]

Има подобрение, вече разликата е само 59лв, в проблемният ми обект.

[mIRCata]

Може да има и друг казус или разликата да се е натрупала между версиите. Когато имаш възможност, изпрати ми нова база с разлики да прегледам защо е така.

[boris]

Вече има още един обект, които ще ползва Атонс3 вместо Сторе и проблема се появява и при него.
Ако се намери време би било добре да се погледне отново въпроса.

[morphieus]

А и накрая се налага и бекъп рестор, заради самият Атонс.

За целите на начинанието преди да преизчисляваш базата си спри "Forced Writes", значително ще намали нуждата от последващ b/r на базата (след приключване си го пускаш отново)

[boris]

Ако имаш в предвид това:

# Number of seconds during which unflushed writes will accumulate
# before they are flushed, at the next transaction commit. For non-Win32
# ports, the default value is -1 (Disabled)
#
# Type: integer
#
#MaxUnflushedWriteTime = 5

Мисля, че по подразбиране е изключено, както казваш да направя.
А не мисля че windows се интересува кога и как да записва нещо (тол си не може).
Два от сървърите са Linux, със SSD, мисля че нямат проблеми с изчакването на записа. Ако пък си играя да отключа този параметър ми се струва малко нередно от гледна точка на сигурност. Така както ги чета нещата има малка вероятност да изчезнат данните, все пак базите са големички и не гарантирам за тока в обекта.


Сега се загледах че май имаш в предвид това: gfix -write async?

[morphieus]

Имам предвид следното:

Код: Избери всички

IBExpert.exe -> Свързване с база данни -> Services -> Database Properties -> Махаме отметката на "Forced Writes" -> OK

После по същия начин я връщаш, за да не боли глава!

P.S. За препоръчване е да се прави при липсва на други връзки с базата!!!

[boris]

Всъщност опцията може да се пуска и спира през gfix -write sync или async, но както и да е.
Вчера си играх да провера до колко по-бързо ще минат преизчисленията, с изключена опция. Реално не видях да става по-бързо, от друга страна при включен sync както си е по подразбиран, скоростта на запис върху диска е около 2.5 пъти по бърза при async.
Опцията е интересна Благодаря че я сподели, но предпочитам да си направя бекъп-рестор, вместо да изключвам опции в базата, освен ако същата не е при мен.

[morphieus]

Като жвло бързината е в пъти! Тествано е на огромна база (с амбалаж)! Ефект категорично има!

Относно опасност - да, така е. Риск си е, но е за предпочитане пред спиране на работа.

Опцията не само че ускорява процесите по запис, но и освобождава после нуждата за дефеагмент!

Помисли пак

[boris]

Нещо се отклонихме от темата. Не съм търсил начин за по-бързо прейзчисление на продуктите.
Нова база на 7 дни, вече има разлики, това са обекти в които се гледат тези справки. Ревизии се правят през няколко дни, не мога да карам оператор да преизчислява база камо ли да маха синхронизация на треидовете.

[boris]

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