Как посмотреть транзакции SH4?

[olegash]

0. Попробовать бекап/рестор - но вряд ли получится.

Да, собственно из-за прекращения создания автобэкапа и обратили внимание на проблему (галка автостопа сервера стояла).

1. Пробовать прогнать через Shc.exe

Нет, не помогает.

2. Восстановить резервную копию "за вчера" где ошибки еще нет и вбить заново (или перенести) недостающий документооборот.

Так и сделали. Вот только группового импорта\экспорта нет в SH, поэтому при большом кол-ве документов это задача не из простых.

3. В противном случае на ремонт в UCS (может быть долго и не бесплатно)

Так и есть. Не бесплатно, да и вообще сказали, что не факт, что восстановят.
О причинах появления данной ошибки UCS отвечает стандартными фразами-"скачок напряжения", "битый винт". Естественно всего этого не было-проверяли. Могут-ли данные ошибки появляться из-за, мягко говоря, несовершенства базы made in UCS? Из-за чего обычно происходят такие сбои в БД? Могут ли, какие-либо действия пользователя (ну например правка документов задним числом и т. д.) привести к таким ошибкам?

[sibgaba]

О причинах появления данной ошибки UCS отвечает стандартными фразами-"скачок напряжения", "битый винт". Естественно всего этого не было-проверяли.

Ну быть уверенным на 100% что в момент работы (на запись) с БД не вырубился свет - вы не можете.

Могут-ли данные ошибки появляться из-за, мягко говоря, несовершенства базы made in UCS? Из-за чего обычно происходят такие сбои в БД?

Этого думаю даже в UCS не знают. А если знают, то не скажут. А если скажут, то не нам...

Могут ли, какие-либо действия пользователя (ну например правка документов задним числом и т. д.) привести к таким ошибкам?

В философском смысле вопроса ответ будет Да. Причина любого сбоя, так или иначе, действия пользователя. Если с БД никто бы не работал, то она бы и не поломалась
С практической точки зрения - Нет.

Суть проблемы в следующем (это мои догадки и теории): Файл БД разбит на страницы, данные хранятся в страницах. Но это не значит что 1 страница это какой то конкретный 1 документ или элемент справочника. Документ может занимать несколько страниц или в одной странице их может быть несколько. Такая структура хранения свойственна для некоторых типов баз данных (например IB и FB имеют похожую архитектуру).

При изменении данных страница перезаписывается целиком. Т.е. если у нас в 1 странице лежит 2 документа. Мы меняем первый, он успешно записался, но при перезаписи той части страницы где хранится документ №2 произошел сбой (например отключение питания), то получится что битый документ №2 хотя его никто и не правил.

На www.ibase.ru где то была статья, в которой описываются типичные причины повреждения баз IB/FB Это конечно не совсем про UCS, но учитывая что архитектура схожая это статья применима и к базе SH. Если интересно, найдите почитайте...

[olegash]

Ну быть уверенным на 100% что в момент работы (на запись) с БД не вырубился свет - вы не можете.

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

[SH]

Из-за чего обычно происходят такие сбои в БД?

Из-за того, что железо несовершенно.
Что ошибка в проектировании архитектуры - очень вряд ли, т.к., основы проектирования СУБД давно разобраны по косточкам - это раз; у UCS огромный опыт построения СУБД - это два.
База сидит целиком в памяти, вряд ли Вы применяете память с контролем четности, пролетела ошибка - и привет. На то и нужен бэкап.

[olegash]

База сидит целиком в памяти, вряд ли Вы применяете память с контролем четности, пролетела ошибка - и привет.

Так на то она и БД, что должна минимизировать (сводить к нулю) эти ошибки. Для примера. Почти у всех клиентов на тех же ПК стоят базы 1С и я ни разу не видел, чтобы базы так бились... Тем более в 8-ке. На дворе уже не 90-е... И технологии построения СУБД другие. Да и всяко у Microsoft-a намного больше опыта в построении СУБД, почему не использовать проверенные временем (и созданные профессионалами) системы (MSSQL)?

[sibgaba]

Ого, сейчас начнется что то интересное...

Архитектура БД определяет собой множество вещей. В том числе надежность хранения и скорость обработки (read/write/rewrite).

Я уверен на 100% что если бы SH использовал для хранения SQL это сразу бы привело как минимум к 2-м вещам:
1. Отчеты (списки документов, доступ к элементам справочников) отнимали бы у оператора сильно больше времени. Сейчас SH просто летает в этом плане.
2. Требования к железу сильно бы возросли. Не думаю что SQL адекватно будет работать с базой предприятия в которой 2-3 года работы на третьем пне. А SH работает...

И еще: открытая архитектура БД - это может создать проблему с защитой данных.

Я уже сказал что архитектура БД SH очень похожа на архитектуру FB/IB. А это разве не проверенные временем технологии?

У Вас, если стояла правильная галка в настройках, потерялись документы за 1 день. Если это дело прошляпили и просто запустили сервак в ручную и продолжали работать в таком режиме несколько дней (что накопилась груда документов которые вы теперь не можете перенести), то это уже не беда архитектуры БД, это уже камень в другой огород полететь должен...

[SH]

Так на то она и БД, что должна минимизировать (сводить к нулю) эти ошибки.

Она и минимизирует. Если Вы считаете, что в SQL не бывает ошибок - ну, Вы заблуждаетесь

Да и всяко у Microsoft-a намного больше опыта в построении СУБД, почему не использовать проверенные временем (и созданные профессионалами) системы (MSSQL)?

А Вы попробуйте запустить базу аналогичного объема приличного работающего ресторана за год на старом Celeron 478 и 256мб оперативки на SQL.
SQL упадет и больше не встанет.
А SHouse - будет работать.
Поэтому, не надо считать, что СУБД SH4 создавалась не-профессионалами. Это узкоспециализированное решение, которое в своей нише уделывает многие универсальные.

[VampireKB]

Celeron 478 и 256мб

PostgreSQL спокойно потянет базу с 1 клиентом
у меня Доставка на р3 800 Мегагерц и 512 ОЗУ работает..и ничего,полтора года уже )

[olegash]

Не хочу спорить, ибо не такой уж я и программист БД. Но я вижу факты: 1С и базы на MSSQL не валятся просто так. Раньше я работал в конторе, где было очень много баз на 1С (и файловых и SQL-ных), стояли они на псевдосервере. И там скачки напряжения были очень часто-даже бесперебойник не помогал. Так вот, за несколько лет я ни разу не встречался с побитой базой. Максимом, что в файловой 1С надо было сделать реиндексацию, а SQL-ная база и так всегда корректно отрабатывала откат транзакций. Поэтому

пролетела ошибка - и привет

выглядит странно на этом фоне.

[olegash]

А увеличение размера БД вручную-это тоже современные технологии? Просмотрел, что файл БД надо увеличивать и проблемы тебе обеспечены (а СУБД тебе даст даже какое-то время поработать в этой неисправной базе, чтобы потом проблем было больше). А создать сразу большой размер файла, UCS не рекомендует, ибо могут возникнуть проблемы. Вот и получается, что нужен глаз да глаз.

---------- Добавлено в 14:34 ---------- Предыдущее сообщение было размещено в 14:31 ----------

у меня Доставка на р3 800 Мегагерц и 512 ОЗУ работает..и ничего,полтора года уже )

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

---------- Добавлено в 15:03 ---------- Предыдущее сообщение было размещено в 14:34 ----------

Да и не было в моем случае проблем с железом-это видно по логам. А, если БД можно убить простыми действиями пользователей при работе с программой, то это, ИМХО, недоработка разработчиков. Почему тогда ремонт должен платным? Возможно, я что-то не так настроил\недонастроил-это тоже, как вариант. Но во-первых эта база работала уже не первый год, а во-вторых особых рекомендаций по технической настройке SH я не нашел. Буду рад советам, на что следует обратить внимание. Вот моя конфигурация: одна база SH, с 2 корневыми вершинами меню. Данные сливаются в нее из 2 ресторанов. Работа с базой одновременно с 3-ех рабочих мест по TCP\IP (ЛВС, не интернет). Документов заносят достаточно много (после года работы размер файла базы пришлось увеличивать от стандартного размера).