Как посмотреть, какие документы, справочники были изменены в SH за определенный день?
Как посмотреть, какие документы, справочники были изменены в SH за определенный день?
Сервис - Протоколы
Спасибо. Еще вопрос, если база битая и выдает ошибку "Неверная контрольная сумма страницы файла данных. Номер страницы: 387". Как понять в каком документе ошибка?Сообщение от sibgaba
Печальная ошибка...
0. Попробовать бекап/рестор - но вряд ли получится.
1. Пробовать прогнать через Shc.exe
2. Восстановить резервную копию "за вчера" где ошибки еще нет и вбить заново (или перенести) недостающий документооборот.
3. В противном случае на ремонт в UCS (может быть долго и не бесплатно)
Да, собственно из-за прекращения создания автобэкапа и обратили внимание на проблему (галка автостопа сервера стояла).
Нет, не помогает.
Так и сделали. Вот только группового импорта\экспорта нет в SH, поэтому при большом кол-ве документов это задача не из простых.
Так и есть. Не бесплатно, да и вообще сказали, что не факт, что восстановят.
О причинах появления данной ошибки UCS отвечает стандартными фразами-"скачок напряжения", "битый винт". Естественно всего этого не было-проверяли. Могут-ли данные ошибки появляться из-за, мягко говоря, несовершенства базы made in UCS? Из-за чего обычно происходят такие сбои в БД? Могут ли, какие-либо действия пользователя (ну например правка документов задним числом и т. д.) привести к таким ошибкам?
Ну быть уверенным на 100% что в момент работы (на запись) с БД не вырубился свет - вы не можете.О причинах появления данной ошибки UCS отвечает стандартными фразами-"скачок напряжения", "битый винт". Естественно всего этого не было-проверяли.
Этого думаю даже в UCS не знают. А если знают, то не скажут. А если скажут, то не нам...Могут-ли данные ошибки появляться из-за, мягко говоря, несовершенства базы made in UCS? Из-за чего обычно происходят такие сбои в БД?
В философском смысле вопроса ответ будет Да. Причина любого сбоя, так или иначе, действия пользователя. Если с БД никто бы не работал, то она бы и не поломаласьМогут ли, какие-либо действия пользователя (ну например правка документов задним числом и т. д.) привести к таким ошибкам?
С практической точки зрения - Нет.
Суть проблемы в следующем (это мои догадки и теории): Файл БД разбит на страницы, данные хранятся в страницах. Но это не значит что 1 страница это какой то конкретный 1 документ или элемент справочника. Документ может занимать несколько страниц или в одной странице их может быть несколько. Такая структура хранения свойственна для некоторых типов баз данных (например IB и FB имеют похожую архитектуру).
При изменении данных страница перезаписывается целиком. Т.е. если у нас в 1 странице лежит 2 документа. Мы меняем первый, он успешно записался, но при перезаписи той части страницы где хранится документ №2 произошел сбой (например отключение питания), то получится что битый документ №2 хотя его никто и не правил.
На www.ibase.ru где то была статья, в которой описываются типичные причины повреждения баз IB/FB Это конечно не совсем про UCS, но учитывая что архитектура схожая это статья применима и к базе SH. Если интересно, найдите почитайте...
По логу SDB видно, что сервер в течении этих дней, когда перестал сохраняться бэкап не стартовал. Сервер SH запускается службой и соответственно при любом рестарте мы бы это увидели в логах...
Из-за того, что железо несовершенно.Из-за чего обычно происходят такие сбои в БД?
Что ошибка в проектировании архитектуры - очень вряд ли, т.к., основы проектирования СУБД давно разобраны по косточкам - это раз; у UCS огромный опыт построения СУБД - это два.
База сидит целиком в памяти, вряд ли Вы применяете память с контролем четности, пролетела ошибка - и привет. На то и нужен бэкап.
Алексей Аркадьев
Когда заказчик ищет волшебника, то чаще всего он находит сказочника.
Если у Вас есть вопрос по поддержке - напишите его на форуме, я обязательно отвечу, если знаю ответ.
Если Вам нужны какие-то файлы, пишите на почту: support@carbis.ru, но вначале посмотрите в разделе для скачивания.
Для коммерческих вопросов:
+7 (495) 740-49-91, или на почту: sales@carbis.ru
Так на то она и БД, что должна минимизировать (сводить к нулю) эти ошибки. Для примера. Почти у всех клиентов на тех же ПК стоят базы 1С и я ни разу не видел, чтобы базы так бились... Тем более в 8-ке. На дворе уже не 90-е... И технологии построения СУБД другие. Да и всяко у Microsoft-a намного больше опыта в построении СУБД, почему не использовать проверенные временем (и созданные профессионалами) системы (MSSQL)?
Ого, сейчас начнется что то интересное...
Архитектура БД определяет собой множество вещей. В том числе надежность хранения и скорость обработки (read/write/rewrite).
Я уверен на 100% что если бы SH использовал для хранения SQL это сразу бы привело как минимум к 2-м вещам:
1. Отчеты (списки документов, доступ к элементам справочников) отнимали бы у оператора сильно больше времени. Сейчас SH просто летает в этом плане.
2. Требования к железу сильно бы возросли. Не думаю что SQL адекватно будет работать с базой предприятия в которой 2-3 года работы на третьем пне. А SH работает...
И еще: открытая архитектура БД - это может создать проблему с защитой данных.
Я уже сказал что архитектура БД SH очень похожа на архитектуру FB/IB. А это разве не проверенные временем технологии?
У Вас, если стояла правильная галка в настройках, потерялись документы за 1 день. Если это дело прошляпили и просто запустили сервак в ручную и продолжали работать в таком режиме несколько дней (что накопилась груда документов которые вы теперь не можете перенести), то это уже не беда архитектуры БД, это уже камень в другой огород полететь должен...
Ваши права
Ответить с цитированием