Постоянные ошибки сохранения базы ( Cannot save data to DB )

[ipf]

Ув. Форумчане. Столкнулся с проблемой, с решением которой поддержка никак не может помочь.
Сервер на ксеоне + 32 гига оперативки. Всего порядка 10 терминальных лицензий +4 мобильные лицензии.
Хранение данных в базе выставлено в 30 дней.
Вес файла базы 32 гигабайта. вес лога 81 гигабайт.
Каждый день вылетает ошибка Cannot save data to DB. Лечится перезагрузкой сервера, но сервер с первого раза не всегда запускает базу + сама загрузка в базу может занимать по 30 минут.
Вот только что опять звонили из ресторана. На официантском терминале висят открытые столы, но на кассе они не появляются, естественно нельзя расчитать людей. База опять пишет что невозможно сохранить данные. Такая проблема уже несколько раз в день, поддержка более 3х месяцев пытается решать проблему, но теперь вовсе забили. До этого пробовали ограничивать память sql, но не помогало.
В логе ошибок сначала появляется вот такая строчка

[2016-09-19 20:31:38,994] WARN [http-bio-8080-exec-121@117.3.82.229] (resto.rpc.ServiceMethodCaller) Error calling method public static resto.back.cache.EntitiesUpdate resto.back.cache.UpdateService.getEntitiesUpdate(i nt,int)
resto.RestoException: Failed to flush data to database within given timeout
затем
[2016-09-19 20:31:38,994] ERROR [http-bio-8080-exec-121@117.3.82.229] (resto.rpc.ServicesServlet) Service call 'update.getEntitiesUpdate' failed, entitiesUpdates: null
resto.RestoException: Failed to flush data to database within given timeout

затем
[2016-09-19 20:34:41,702] WARN [Thread-3] (resto.watchdog.EntitiesFlushTimerChecker) Cannot save data to DB for 5 minutes. The system has been transferred to emergency mode and will be stopped within 54 minutes. Data may be lost upon continuing work. Contact your system administrator or support immediately!



Вот несколько скринов ошибки во время работы.
5233523452355236

Пожалуйста подскажите как решить данную проблем.
Еще в логе в течеии дня вот такие ошибки [2016-09-19 19:53:19,306] ERROR [scheduler_Worker-5] (resto.iikonet.MQChecker) JMS: crmId is not consistent
[2016-09-19 19:53:19,306] ERROR [scheduler_Worker-7] (resto.iikonet.MQChecker) JMS: crmId is not consistent
[2016-09-19 19:00:50,223] WARN [Resto Executor] (resto.back.cache.AemUpdateManager) Building 'committed' update from revision 6145792 to 6145793 for BACK. Cache states: committed 6135794..6145793 (6145793), flushed 6100467..6145793 (6145792) (inconsistent revision!)
resto.RestoException: Building 'committed' update from revision 6145792 to 6145793 for BACK. Cache states: committed 6135794..6145793 (6145793), flushed 6100467..6145793 (6145792) (inconsistent revision!)
Спасибо

[banrofun]

По умолчанию задан таймаут 5 минут, в течении которого iikoTomcat должен обработать полученные данные и записать их в базу.
Если данные не сохранились за такой таймаут, система выводит предупреждение.
==
Не удалось сохранить данные в БД в течение 5 минут. Система переведена в аварийный режим работы и будет остановлена через 54 минут. При продолжении работы возможна потеря данных. Срочно свяжитесь с системным администратором или со службой поддержки!!!
==
Если время в предупреждении не превышает 20 минут, как правило, проблемы нет.
Сервер мог получить большой пакет данных ( например в результате репликации) и должен их обработать.
Или , например, задним числом правились техкарты или заводились документы.
В таком случае сервер должен сначала обработать эти данные, пересчитать себестоимости и тд.
В зависимости от мощности машины (Disk i/o time) это может занимать некоторое время, в течении которого запись в базу не идет и выходит предупреждение.

Если время в предупреждении превышает 1 час это уже может свидетельствовать о проблемах.
Но если на сервере был открыт большой период редактирования и проводили документ, кторый делает приход на отрицательные остатки не торопитесь останавливать сервер!
Дайте ему обработать и записать данные!

1 Переведите режим запуска службы Томкат с "Автоматически (Automatic)" на "Ручной (Manual)" и Остоновите Tomcat
2. Выполните скрипт проверки БД Resto на ошибки:
DBCC CHECKDB ('Resto') WITH NO_INFOMSGS, ALL_ERRORMSGS
(Если у вас проблемы с базой Чейн, то скрипт должен быть DBCC CHECKDB ('Chain') WITH NO_INFOMSGS, ALL_ERRORMSGS)
3. Если в БД обнаружены ошибки (строки в логе красного цвета, в конце логи строка вида «CHECKDB found ... allocation errors and ... consistency errors in database 'Resto'», где "..." - ненулевое значение) , то:

забэкапьте файлы базы (посмотрите путь к ним в свойствах базы - пункт Файлы)
сохраните данные этого лога и оформите заявку в службу тех.поддержки. Не забудьте приаттачить к заявке лог скрипта, логи сервера, а также напишите параметры подключения к серверу с проблемной БД.
4. Ошибки Жесткого диска ( физическое повреждение или логическое , вызванное как правило первой причиной )
http://support.iiko.ru/sd/data/kbFile_c235e220-07d4-4bd8-8029-5f19c784c45f.png
Решение : Замена жесткого диска и только после переноса данных на новый диск применить скрипты из решения ниже

Если база данных в состоянии Suspect (Подозрительный), то сначала ее нужно перевести в аврийный режим. Исправлять базу в режиме Suspect невозможно.
Для этого нужно выполнить скрипт:
ALTER database Resto SET EMERGENCY
После этого можно выполнить проверку базы ( пункт 2)
Если последння строка , которую показавает скрипт проверки вида:
repair_rebuild is the minimum repair level for the errors found by DBCC CHECKDB (Resto).
И база не показывается как Аварийная, можно вылечить ее простым перестроением несогласованных данных ( индексов)
alter database resto set single_user with rollback immediate
go
dbcc checkdb('resto',repair_rebuild) with no_infomsgs,all_errormsgs
go
alter database resto set multi_user

Скрипт Напишет, что завершился с ошибками покажет строки вида:
CHECKDB found 0 allocation errors and 2 consistency errors in database 'Resto'.
CHECKDB fixed 0 allocation errors and 2 consistency errors in database 'Resto'

Завершился с ошибками - означает, что ошибки были в базе при выполнении скрипта.
В строках говорится сколько ошибок нашел(CHECKDB found ) и сколько исправил (CHECKDB fixed )
Если исправил все, что нашел, значит база починена.
Можно еще раз проверить базу на ошибки и при их отстуствии ззапускать томкет.

Мне помогало.

[ipf]

Добрый день. Спасибо, все прошло как вы говорили. Скрипт нашел 2 ошибки и исправил их. Следующая проверка показала что ошибок больше нет. Но проблема осталась как и была. Существует ли способ как либо сократить базу, например урезав данный 3х годичной давности ?
Еще вопрос в айке есть очистить лог транзакций Б.Д. Никогда не использовал, поскольку не знаю что это такое. Может поможет ?
С дисками тоже все в порядке, у меня установлены 2 wd black, в raid1. Ошибок не выводит, им около 5 месяцев.

[banrofun]

Как сократить базу: Базу можно обрезать.
Процедуры обрезки РМС и Чейн не зависят друг от друга. Можно обрезать либо то, либо другое, либо и то и другое.
Версия желательно чтобы была последняя 4.2.3006.0 (на момент обновления этой статьи) так как было много изменений, в том числе по проблемам обрезки
Запускается по адресу
http://host:port/resto/service/maintance/shrinkDatabase.jsp
Принцип работы простой: ввести дату, до которой обрезать, нажать кнопку, через 2-10 минут урезанная БД готова.
Порядок действия для оптимальной обрезки:

1.Остановить томкет.
2.Снять бекап.
3.Сделать период в 1 день для ускорения запуска.
4.В server.xml сменить порт со штатного, чтобы ничего не мешало ( фронты, беки, обмены)
5. Запустить томкет.
6. Запустить скрипт обрезки базы на изменнном ранее порту.
7. Проконтролировать его работу как в браузере, так и по логу по словам DBShrinker ( Удобнее всего в FAR Manager . который читает full.log сервера онлайн)
8.По завершению работы скрипта остановить томкет.
9. Дефрагментировать и сжать базу.
10. Вернуть на место порт и период.
11. Запустить томкет
12. Наслаждаться уменьшенной базой

Удаляются все исторические данные, которые имеют дату (документы, транзакции, техкарты, события, и т.п.) до указанной даты. Никакие справочники не удаляются. Начальные балансы по счетам сохраняются.
ВНИМАНИЕ: создаваемые скриптом приходные накладные нельзя перепроводить, в том числе репликацией!
Они не валидны: строки могут содержать отрицательные количества товаров, а проводки имеют бОльшую точность, чем у обычных накладных, эта информация теряется при перепроведении.
ВНИМАНИЕ: дата обрезки должна быть ДО начала периода.



Это не просто защита от дурака, чтобы не удалить слишком много. После обрезки нельзя расширять период, чтобы включить дату обрезки, это приведет к расхождению себестоимости.


Начальные остатки и себестоимость сохраняются в накладные от поставщика «Администратор».
При обрезке даты необходимо указать дату на которую нужно обрезать. Например нужно удалить все до 1 июля - ставить дату 01.07.2011.
Удалятся документы и кассовые смены до этой даты, на 00:00 остатки заведутся приходными накладными от имени поставщика Администратор.

Еще вопрос в айке есть очистить лог транзакций Б.Д. Никогда не использовал, поскольку не знаю что это такое. Может поможет ?
Очистить лог можно, но обычно это делается если. Файл транзакций Resto_log.ldf в разы превышает файл базы Resto.mdf.


Но проблема осталась как и была.

Что бы сделал я еще:
1. Проверить доступность дискового пространства на диске куда сохраняются бекапы
2. Проверить журналы Windows:
· Системы - на наличие ошибок диска, и др ошибки
· Приложений – на ошибки и предупреждения от SQL сервера
3. Просмотреть логи сервера Tomcat на наличие ошибок %programfiles%\iikoRMS\Server\logs\error.log и full.log
4. Проверить, чтобы размер файла логов БД %programfiles%\iikoRMS\Server\DatabaseData\Resto_l og.ldf не превышал более чем в 4 раза размер файла данных БД %programfiles%\iikoRMS\Server\DatabaseData\Resto.m df
5. Просмотреть наличие в папке %programfiles%\iikoRMS\Server\DatabaseData\ файлов с именем Suspend_
6. Подключиться через SQL Management Studio к инстансу Resto и развернуть структуру таблиц БД Resto
7. Выполнить запрос dbcc checkdb к БД Resto. Результат=зеленый галочка: БД Resto без ошибок, иначе – что-то не так. Если что-то не так , переходите к пункту 11
8. Выполнить запрос dbcc checkdb к служебным БД master, msdb, model . Результат=зеленая галочка: , иначе – что-то не так. Если что-то не так , переходите к пункту 11
9. Просмотреть наличие в папке %programfiles%\iikoRMS\Server\ файлов unsaveddata.xml или unsaveddata.xml.old
10. Если таковые файлы есть, то необходимо остановить службу сервера iiko Appache Tomcat, чтобы касса и станции ушли в автономный режим.
11 Остановить службу SQL и скопировать все файлы из папки %programfiles%\iikoRMS\Server\DatabaseData\ на ДРУГОЙ физический носитель
12. При положительных результатах проверки по пп 3, 4,8 должно быть произведено обращение:
Клиентов – к обслуживающей организации, партнеру iiko
Партнеров – к вышестоящей организации партнеру, или в техподдержку iiko, если такой алгоритм прописан в партнерском договоре

Проверить доступность дискового пространства на диске куда сохраняются бекапы
Проверить журналы Windows:

Системы - на наличие ошибок диска
Приложений (на наличие ошибок с кодами (832, )
832 Event: A page that should have been constant has changed (expected checksum: 0dc764f0, actual checksum: 0dc764a0, database 6, file 'C:\Program Files (x86)\iikoRMS\Server\DatabaseData\Resto.mdf', page (1:38783)). This usually indicates a memory failure or other hardware or OS corruption.
3 Остановить службы Tomcat и SQL и скопировать файлы БД в резервное хранилище: %programfiles%\iikoRMS\Server\DatabaseData\Resto.m df и %programfiles%\iikoRMS\Server\DatabaseData\Resto_l og.ldf
5. Просмотреть наличие в папке %programfiles%\iikoRMS\Server\DatabaseData\ файлов с именем Suspend_ / если есть также скопировать в резервное хранилище
6. Подключиться через SQL Management Studio к инстансу Resto и развернуть структуру таблиц БД Resto
7. В файле конфигурации сервера Tomcat C:\Program Files\iikoRMS\Server\tomcat\conf\server.xml измените порт подключения <Connector port="8080" на <Connector port="8070" , чтобы кассы оставались в автономном режиме (перекинуть сервер на другой порт)

Рекомендации:
В данной заявке побилась таблица справочников 'entity'.
8 Запустите службу SQL
8. Выполните рекомендации 1-7 и можете запустить скрипт проверки и восстановления БД с потерей данных
9 Проверить корретность процедуры лечения тестовым запуском службыTomcat
10 Если Tomcat успешно запустится, то можно вернуть порт из п 7 на место и перезапустить Tomcat

Так же есть платный вариант, могу взять вас в свое обслуживание. (если устали искать проблемы самостоятельно)
Dead line Неделя с постановки на обслуживание.

Способ решения будет, как руками наших специалистов, а так же способами разработчиков iiko.


-------------->ВНИМАНИЕ ПЕРЕД ВЫПОЛНЕНИЕМ НЕ ЗАБУДЬТЕ СДЕЛАТЬ BACKUP<--------------