Есть файловая база Бух 3.0, платформа 8.3.10.2466
Размер базы 5,6 Гб. Лежит на 1м рейде из 2х ssd на 120гб, тут же стоит система Srv2008r2. Ежедневные копии средствами win на соседний диск. Работает 4-5 человек в терминале.
С периодичностью в 1-2 месяца в базе появляются ошибки, как говорит chdbfl:
Повреждены данные таблицы '_DOCUMENT99_VT1349'
Обнаружено рассогласование между данными и индексами таблицы '_DOCUMENT99_VT1349'
Повреждены данные таблицы '_DOCUMENTJOURNAL5710'
Обнаружено рассогласование между данными и индексами таблицы '_DOCUMENTJOURNAL5710'
Повреждены данные таблицы '_ACCRG453'
Обнаружено рассогласование между данными и индексами таблицы '_ACCRG453'
Повреждены данные таблицы '_DOCUMENT185'
Обнаружено рассогласование между данными и индексами таблицы '_DOCUMENT185'
Повреждаются разные таблицы, но с завидной регулярностью, после исправления некоторые документы недоступны в программе.
Вопрос: в какую сторону посмотреть, чтобы решить данную делему?
Основная проблема в том, что данные ошибки обнаруживаются не сразу (база продолжает работать) и как следствие из архива восстанавливать уже не вариант, приходится исправлять утилитой chdbfl, с потерей некоторых документов, которые потом еще предстоит найти.
(4) Вообще лучший вариант конечно отказаться от файловой базы. Если уж совсем невозможно, то возможно поможет публикация файловой базы, и пользователи пусть работают в тонком клиенте - но путь к базе укажите к опубликованному ресурсу. Суть в том, что iis или apache более устойчивы или заточены на условия работы при обрывах соединения, отключения электричества и т.д.
11.
JohnConnor
6408.08.18 06:07 Сейчас в теме+3 $m
попробуй не использовать рейд, положи базу на 1 ссд. Бекап делай на другой диск через обычным копированием как тебе удобно в нужный отрезок времени.Файловой базе становится тяжело когда ее размер больше 20 гб. В твоем случае все должно быть норм.
(1) бесперебойник на сервере стоит? электричество часто отключают?
ssd сколько лет? если нет проблем с внезапным завершением работы 1С, то возможно накопители выходят из строя
Повреждаются разные таблицы, но с завидной регулярностью
Если действительно нет закономерности, то дело явно в случайных событиях, которые случаются в произвольные моменты и не позволяют корректно записать информацию в базу.
В первую очередь - это некорректные завершения работы сервера из-за отказа ИБП. Во вторую - аппаратные неисправности - RAM, SSD, БП сервера.
Вопрос: в какую сторону посмотреть, чтобы решить данную делему?
Прежде всего - в сторону мощного ИБП с обратной связью, который позволил бы серверу корректно выключаться при разряде батареи ИБП автоматически, не доверяя это юзерам - как показывает опыт, они к этому относятся предельно наплевательски.
У меня есть такие, которые сутками держат запущенной терминальную сессию с 1С, несмотря на все разъяснения.
Так что - проверять имеющиеся бэкапы, а при обнаружении ошибок - под микроскопом изучать журнал сервера в этот и предыдущий день - были отключения или нет?
Ну, а потом - тестировать RAM и БП, раз диски уже проверены.
(7)
Чтобы исключить такие ошибки переходите на клиент-серверный режим.
А что, клиент-серверный режим заменит собой ИБП? Или при клиент-сервере не страшны внезапные отключения физического сервера?
(3) ТиИ вылетает - информационная база повреждена. Сейчас попробую выгрузить/загрузить
(2) ИБП стоит, но нужно посмотреть по логам, возможно не успевает переключаться. ССДшкам около года, по отдельности тестил, вполне живые.
(4) Вообще лучший вариант конечно отказаться от файловой базы. Если уж совсем невозможно, то возможно поможет публикация файловой базы, и пользователи пусть работают в тонком клиенте - но путь к базе укажите к опубликованному ресурсу. Суть в том, что iis или apache более устойчивы или заточены на условия работы при обрывах соединения, отключения электричества и т.д.
Вообще лучший вариант конечно отказаться от файловой базы. Если уж совсем невозможно, то возможно поможет публикация файловой базы, и пользователи пусть работают в тонком клиенте - но путь к базе укажите к опубликованному ресурсу. Суть в том, что iis или apache более устойчивы или заточены на условия работы при обрывах соединения, отключения электричества и т.д.
Сделаю так и +, как посоветовал JohnConnor:
Оставлю ссд в сингле под систему + ссд под базы + обычный под бэкапы
Разверну IIS, и всех запущу работать через него. ИБП тоже прийдется заменить, не успевает переключиться при отключении эл-ва - у сервака идет ребут.
11.
JohnConnor
6408.08.18 06:07 Сейчас в теме+3 $m
попробуй не использовать рейд, положи базу на 1 ссд. Бекап делай на другой диск через обычным копированием как тебе удобно в нужный отрезок времени.Файловой базе становится тяжело когда ее размер больше 20 гб. В твоем случае все должно быть норм.
Ситуация ненормальная.
Учитывая, что все работают локально (через терминал), подобные ошибки с такой систематичностью могут говорить о какой-то системной проблеме при работе с дисковой подсистемой. Первым делом я бы проверил системный журнал на предмет возникновения сбоев в работе сервера, убедился что база не расшарена по сети и не имеет сетевых подключений и т.п. Вторым делом помониторил одинэсовский журнал на предмет сбоев работы 1С.
Переход с локальной работы на работу через веб-сервер может помочь, а может и нет - зависит от корня проблемы.
(26) Именно так и отказываться от RAID - это вообще плохая идея. А так нужно смотреть. Причиной могут быть: диск, память, настройки кеширования, действия какого -то системного ПО и т.д. и т.п. В общем надо детально анализировать ситуацию.
+ конечно посмотреть настройки кеширования рейда
встарину были такие ошибки у виндов когда они за кешем не успевали
если есть возможность - отключить вообще