Re[2]: 1С и WinXP SP 2
- From
- Shurik Koudryavtsev (2:5020/400)
- To
- Vladimir V. Shirjak (2:5054/37.63)
- Date
- 2005-04-09T14:50:32Z
- Area
- RU.WINDOWS.XP
From: Shurik Koudryavtsev <sh71@avtlg.ru>
Здравствуйте, Vladimir.
Вы писали 8 апреля 2005 г., 20:45:25:
VVS> Hello, Shurik Koudryavtsev!
VVS> You wrote to (Vladimir V. Shirjak) on Fri, 08 Apr 2005 01:49:29 +0400:
VVS> [Sorry, skipped]
SK>>>> В связи с этим, когда по сети закрываются несколько сотен dbf/cdx в
SK>>>> одну секунду - восстановление системы не в состоянии справиться с
SK>>>> данными объемами и сетевая сессия виснет.
VVS>>> Опять неправ - точки восстановления сохраняются только во время
VVS>>> бездействия компьютера.
SK>> Речь идет о _подготовке_ данных о том, что же надо сохранять.
SK>> А оно происходит после изменения данных.
VVS> И как оно происходит?
VVS> Допустим даже что просто куда-то записываются пути к файлам, которые
VVS> изменились.
VVS> Допустим, что таких файлов тысячи.
VVS> Сколько милисекунд займет запись файла с такой информацией?
Единственное нормальное объяснение данному факту можно дать такое:
При закрытии измененного файла (а может быть и при изменении) -
система проверяет: а заслуживает ли данный файл того, чтобы быть
записанным в точку восстановления? Является ли он важным для системы?
Что вполне логично, т.к. протоколировать все изменения всех файлов - винт
закончится быстро :)
И в обычной ситуации - все проходит вполне успешно. Но в случае файл -
серверных версий 1С _одномоментно_ происходит закрытие нескольких
сотен файлов. Сколько времени надо на такую проверку? А это зависит от
того, как ее проводить. На мой взгляд - файлы с расширением dbf и cdx
вообще нефиг проверять, но я не MS :)
И вот такая одномоментная проверка у XP сносит крышу. Вероятно, по
таймаутам не успевает.
Мало того, при доступе по сети из 2000/XP по крайней мере явных
вылетов не происходит. Скорее всего, 98 закрывает файлы дольше (или
иначе:) ).
Можешь не верить, но в ДАННОМ вопросе эффект присутствует в 95%
случаях. ЛИЧНО видел где-то полтора десятка случаев
(работа у меня такая).
И в интернете данная проблема обсосана со всех сторон, и другого
ДЕЙСТВУЮЩЕГО способа, кроме отрубания восстановления системы не
предложено НИ РАЗУ (xml файл - это подвариант отрубания, несколько
более корректный).
[skip]
SK>> Данные в нескольких базах данных за пару дней
SK>> "как корова языком слизала". После сообщения
SK>> "Система восстановлена после серьезной ошибки".
VVS> 100% знаю, что это не может быть связано с System Recovery.
Сначала сам слышал, но не верил.
Потом 1 раз увидел своими глазами.
Другого объяснения ни я, ни те, кто сталкивался до меня предложить не
могли.
"картинки с выставки"
Были данные (есть распечатки) - и после сбоя нет их. Причем
данные имеются четко до момента ххх . В дбф-ках никаких следов.
Подходящей архивной копии, более-менее подходящей по составу - нет,
как впрочем и человека, способного ее восстановить :)
Как еще объяснить?
--
С уважением,
Shurik Koudryavtsev mailto:sh71@avtlg.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
SEEN-BY: 46/50 50/361 450/186 247 1024 461/43 132 640 469/999 4614/20 4616/3
SEEN-BY: 4625/8 4627/10 4635/4 4646/1 4652/15 5000/76 5000 5001/5001 5003/57
SEEN-BY: 5006/1 5007/1 5010/53 70 87 5011/13 5012/23 5015/10 5019/31 5020/52
SEEN-BY: 5020/118 154 175 194 400 545 639 715 758 780 830 937 1057 1604 1909
SEEN-BY: 5020/1922 2020 2238 4441 5022/128 5025/3 750 5026/14 45 5027/16
SEEN-BY: 5030/49 115 966 1339 1900 5031/70 5034/13 5035/38 5036/1 34 5041/20
SEEN-BY: 5042/13 5054/1 8 9 36 37 63 66 67 75 81 5060/90 5061/15 5062/10 18
SEEN-BY: 5063/3 5067/2 5069/7 5070/1222 5074/9 5075/5 5077/80 5079/23 5080/80
SEEN-BY: 5080/1003 5082/6 5083/21 5084/32 5085/13 5090/106 107 5092/1 5095/20
SEEN-BY: 5096/18 5099/4 11 6000/12 254 6001/3 10 6002/3 6035/9 6070/228
PATH: 5020/400 4441 545 5054/1 37