Имя: Пароль:
IT
1С v8
1С и PostgresPro 9.6
0 Valkyrie
 
10.05.18
18:00
Имеется куча разных баз 1с на 64 битном сервере с рейдом.
Периодически умирает какой-нибудь диск в рейде, производится замена и все казалось бы относительно ОК. Но появляются ошибки в базах 1С. Не во всех. При проведении некоторых доков ругается на отсутствующие объекты/таблицы и ошибки SQL. Реиндексация средствами Postgre не проходит - валится с ошибкой. ТиИ аналогично, dt не выгружается. Бекапы конечно есть, но хотелось бы понять причины данного явления. В последний раз прилегла буха 2.0.
Сервером и рейдом занимаются админы, так что что там с железом я хз. По факту вопросы только к SQL и 1С.
1 systemstopper
 
10.05.18
18:12
ты так говоришь, как будто для вас упавший диск это норма и происходит каждую неделю
2 Fragster
 
гуру
10.05.18
18:14
когда умирает диск в рейде - оно для софта целиком прозрачно и никак не влиет на данные. ну если админы не совсем криворукие
3 Valkyrie
 
10.05.18
18:27
(1) Я знал, что так кто-нибудь скажет =D Сервер не наш, старенький уже, поэтому не могу знать точно. За последние полгода умирает второй диск. И каждый раз после этого проблемы с 1С.
4 ansh15
 
10.05.18
18:28
(0) >>Сервером и рейдом занимаются админы, так что что там с железом
Выяснить какой сервер что за PAID не представляется возможным?
5 Valkyrie
 
10.05.18
18:28
(2) Вот и я про что... RAID5, диск втыкается, идет ребилд и все вроде бы норм.
6 Valkyrie
 
10.05.18
18:29
(4) RAID5
7 Valkyrie
 
10.05.18
18:31
(4) WinServ 2003 кажется.
8 Fragster
 
гуру
10.05.18
18:31
(5) я надеюсь, это все происходит без жесткой перезагрузки?
9 ansh15
 
10.05.18
18:32
(6) А с ОС, СУБД и 1С в момент выпадания диска?
10 Valkyrie
 
10.05.18
18:33
(8) Не могу знать, я там не админ и происходит это действо без меня. Но админы вроде бы грамотные в этом плане
11 Йохохо
 
10.05.18
18:38
сервер не наш, старенький, рейд5, без меня, второй раз за полгода, 2003 + 1с х64 (сборка от енота), посгре
беги оттуда
12 ansh15
 
10.05.18
18:43
(10) Посмотри в postgres.conf параметры fsync, synchronous_commit и full_page_writes. Если что-то стоит в off, включи(on). Если контроллер RAID аппаратный, то сильного уменьшения производительности не будет, понадежнее станет.
13 Valkyrie
 
10.05.18
18:50
(8) Админы вырубают комп, меняют диск, включают, утилитой делают ребилд.
(9) Ошибся, Server 2008R2. Платформа 8.3.10.2752, Агент сервера 64-бит. PostgresPro 9.6. i7-2600, 24 ОЗУ.
(11) Ну не все так плохо как кажется =D
(12) Ок, сейчас гляну... fsync не включали точно. Ребилд делался в выходные, в базах никого не было.
14 Fragster
 
гуру
10.05.18
18:52
(13).1 ну и нафига? и вырубают, судя по всему, не через завершение работы (ну, или софт какой-то некорректно работает)
15 rphosts
 
10.05.18
18:53
(0) вопрос №1 - в чем причина смерти дисков?
вопрос №2 - ну неплохо-бы привести конфиг постгри.
(7) чё? А что не пингвин?
16 rphosts
 
10.05.18
18:54
(14) жесть! И возможно причина.
17 Valkyrie
 
10.05.18
18:58
(14) (16) Не думал, что это так критично. Естественно как завершают работу не видел, но не думаю что прям кнопкой... Серьезно может быть в этом проблема?
18 Valkyrie
 
10.05.18
19:01
(12) Все параметры "on"
19 ansh15
 
10.05.18
19:03
(17) Если при выключении файловый кэш операционной системы не сбросится на диск весь, то вполне. Поэтому желательно перед выключением сервера сначала остановить 1С, СУБД и только потом завершение работы.
(18) Это хорошо.
20 rphosts
 
10.05.18
19:03
(18) это ты сейчас отредактировал? перезапускал?

и да, причина смерти дисков не раскрыта.
21 Valkyrie
 
10.05.18
19:09
(20) Нет, это было так.
После предыдущего умирания диска во время работы, админы следили за SMART и при появлении плохих секторов и за давностью службы этого конкретного диска решили его заменить.
22 Fragster
 
гуру
10.05.18
19:13
а батарейка в контроллере живая? а принудительный writeback в контроллере в обход батарейки не включен случайно?
23 rphosts
 
10.05.18
19:14
(22) это уже почти вредительство!
24 Йохохо
 
10.05.18
19:29
(21) проведите тест, так же "аварийно" потушите сервер
25 rphosts
 
10.05.18
19:30
(24) а что не проверить систему пожаротушения: разлить канистру с бензином и поджечь серверную?
26 Valkyrie
 
10.05.18
20:29
(22) Нет, все живое вроде как.
(24) Это шутка надеюсь?)

Все-таки склоняюсь к версии некорректного завершения работы 1С-Сервера и SQL.
27 mexanik_96
 
10.05.18
20:34
(26) 1С-Сервера - это не причем здесь
SQL - возможно, но не должно доходить до разрушения данных, ибо по идиологии субд, должна обеспечивать целостность, иначе нахер она тогда нужна
(0) смотри логи пг, он вроде как не тупой может найдешь там причину не поднятия базы, тем более если есть ошибка
28 Йохохо
 
10.05.18
20:41
(26) это не шутка, это способ перестать склоняться и узнать. Не знаю что у вас там с отгулами и доплатами за выходные или переработки
29 mexanik_96
 
10.05.18
20:43
+(28) поддерживаю, + проверить регламентное время восстановления работоспособности. типа (м)учений. ведь если откажет совсем что будете делать? бегать по офису и орать?
30 Йохохо
 
10.05.18
21:04
(29) именно, и написать письмо админам как ребутать хорошо, а как плохо. Еще можно им намекнуть что диски подешевели и под шумок перейти на 10 рейд, который проще и шустрее
31 Valkyrie
 
10.05.18
21:21
(29) (28) Понял.

Сейчас образовалась другая проблема. Служба postgres останавливается и не стартует. Ругается на уже существующий процесс, обращающийся к data, где базы лежат. Все процессы postgres.exe завершены - служба не запускается. В логах ругань на  msvcr110.dll, что лежит в папке с платформой.
32 mexanik_96
 
10.05.18
22:34
ну там наверняка код ошибки какой то есть
33 Valkyrie
 
11.05.18
00:23
Да уже решили переустановкой всего Postgres и новой платформы. Но трабла с запуском походу была в dll платформы. Всем спасибо за помощь!
Выдавать глобальные идеи — это удовольствие; искать сволочные маленькие ошибки — вот настоящая работа. Фредерик Брукс-младший