Просмотр полной версии : Как посмотреть транзакции SH4?
Как посмотреть, какие документы, справочники были изменены в SH за определенный день?
Сервис - ПротоколыСпасибо. Еще вопрос, если база битая и выдает ошибку "Неверная контрольная сумма страницы файла данных. Номер страницы: 387". Как понять в каком документе ошибка?
Печальная ошибка...
0. Попробовать бекап/рестор - но вряд ли получится.
1. Пробовать прогнать через Shc.exe
2. Восстановить резервную копию "за вчера" где ошибки еще нет и вбить заново (или перенести) недостающий документооборот.
3. В противном случае на ремонт в UCS (может быть долго и не бесплатно)
0. Попробовать бекап/рестор - но вряд ли получится.Да, собственно из-за прекращения создания автобэкапа и обратили внимание на проблему (галка автостопа сервера стояла).
1. Пробовать прогнать через Shc.exeНет, не помогает.
2. Восстановить резервную копию "за вчера" где ошибки еще нет и вбить заново (или перенести) недостающий документооборот.Так и сделали. Вот только группового импорта\экспорта нет в SH, поэтому при большом кол-ве документов это задача не из простых.
3. В противном случае на ремонт в UCS (может быть долго и не бесплатно)Так и есть. Не бесплатно, да и вообще сказали, что не факт, что восстановят.
О причинах появления данной ошибки UCS отвечает стандартными фразами-"скачок напряжения", "битый винт". Естественно всего этого не было-проверяли. Могут-ли данные ошибки появляться из-за, мягко говоря, несовершенства базы made in UCS? Из-за чего обычно происходят такие сбои в БД? Могут ли, какие-либо действия пользователя (ну например правка документов задним числом и т. д.) привести к таким ошибкам?
О причинах появления данной ошибки UCS отвечает стандартными фразами-"скачок напряжения", "битый винт". Естественно всего этого не было-проверяли.
Ну быть уверенным на 100% что в момент работы (на запись) с БД не вырубился свет - вы не можете.
Могут-ли данные ошибки появляться из-за, мягко говоря, несовершенства базы made in UCS? Из-за чего обычно происходят такие сбои в БД?
Этого думаю даже в UCS не знают. А если знают, то не скажут. А если скажут, то не нам...
Могут ли, какие-либо действия пользователя (ну например правка документов задним числом и т. д.) привести к таким ошибкам?
В философском смысле вопроса ответ будет Да. Причина любого сбоя, так или иначе, действия пользователя. Если с БД никто бы не работал, то она бы и не поломалась :)
С практической точки зрения - Нет.
Суть проблемы в следующем (это мои догадки и теории): Файл БД разбит на страницы, данные хранятся в страницах. Но это не значит что 1 страница это какой то конкретный 1 документ или элемент справочника. Документ может занимать несколько страниц или в одной странице их может быть несколько. Такая структура хранения свойственна для некоторых типов баз данных (например IB и FB имеют похожую архитектуру).
При изменении данных страница перезаписывается целиком. Т.е. если у нас в 1 странице лежит 2 документа. Мы меняем первый, он успешно записался, но при перезаписи той части страницы где хранится документ №2 произошел сбой (например отключение питания), то получится что битый документ №2 хотя его никто и не правил.
На www.ibase.ru где то была статья, в которой описываются типичные причины повреждения баз IB/FB Это конечно не совсем про UCS, но учитывая что архитектура схожая это статья применима и к базе SH. Если интересно, найдите почитайте...
Ну быть уверенным на 100% что в момент работы (на запись) с БД не вырубился свет - вы не можете.По логу SDB видно, что сервер в течении этих дней, когда перестал сохраняться бэкап не стартовал. Сервер SH запускается службой и соответственно при любом рестарте мы бы это увидели в логах...
Из-за чего обычно происходят такие сбои в БД?
Из-за того, что железо несовершенно.
Что ошибка в проектировании архитектуры - очень вряд ли, т.к., основы проектирования СУБД давно разобраны по косточкам - это раз; у UCS огромный опыт построения СУБД - это два.
База сидит целиком в памяти, вряд ли Вы применяете память с контролем четности, пролетела ошибка - и привет. На то и нужен бэкап.
База сидит целиком в памяти, вряд ли Вы применяете память с контролем четности, пролетела ошибка - и привет.Так на то она и БД, что должна минимизировать (сводить к нулю) эти ошибки. Для примера. Почти у всех клиентов на тех же ПК стоят базы 1С и я ни разу не видел, чтобы базы так бились... Тем более в 8-ке. На дворе уже не 90-е... И технологии построения СУБД другие. Да и всяко у Microsoft-a намного больше опыта в построении СУБД, почему не использовать проверенные временем (и созданные профессионалами) системы (MSSQL)?
Ого, сейчас начнется что то интересное...
Архитектура БД определяет собой множество вещей. В том числе надежность хранения и скорость обработки (read/write/rewrite).
Я уверен на 100% что если бы SH использовал для хранения SQL это сразу бы привело как минимум к 2-м вещам:
1. Отчеты (списки документов, доступ к элементам справочников) отнимали бы у оператора сильно больше времени. Сейчас SH просто летает в этом плане.
2. Требования к железу сильно бы возросли. Не думаю что SQL адекватно будет работать с базой предприятия в которой 2-3 года работы на третьем пне. А SH работает...
И еще: открытая архитектура БД - это может создать проблему с защитой данных.
Я уже сказал что архитектура БД SH очень похожа на архитектуру FB/IB. А это разве не проверенные временем технологии?
У Вас, если стояла правильная галка в настройках, потерялись документы за 1 день. Если это дело прошляпили и просто запустили сервак в ручную и продолжали работать в таком режиме несколько дней (что накопилась груда документов которые вы теперь не можете перенести), то это уже не беда архитектуры БД, это уже камень в другой огород полететь должен...
Так на то она и БД, что должна минимизировать (сводить к нулю) эти ошибки.
Она и минимизирует. Если Вы считаете, что в SQL не бывает ошибок - ну, Вы заблуждаетесь :)
Да и всяко у Microsoft-a намного больше опыта в построении СУБД, почему не использовать проверенные временем (и созданные профессионалами) системы (MSSQL)?
А Вы попробуйте запустить базу аналогичного объема приличного работающего ресторана за год на старом Celeron 478 и 256мб оперативки на SQL.
SQL упадет и больше не встанет.
А SHouse - будет работать.
Поэтому, не надо считать, что СУБД SH4 создавалась не-профессионалами. Это узкоспециализированное решение, которое в своей нише уделывает многие универсальные.
Не хочу спорить, ибо не такой уж я и программист БД. Но я вижу факты: 1С и базы на MSSQL не валятся просто так. Раньше я работал в конторе, где было очень много баз на 1С (и файловых и SQL-ных), стояли они на псевдосервере. И там скачки напряжения были очень часто-даже бесперебойник не помогал. Так вот, за несколько лет я ни разу не встречался с побитой базой. Максимом, что в файловой 1С надо было сделать реиндексацию, а SQL-ная база и так всегда корректно отрабатывала откат транзакций. Поэтому
пролетела ошибка - и привет
выглядит странно на этом фоне.
VampireKB
04.02.2014, 15:27
Celeron 478 и 256мб
PostgreSQL спокойно потянет базу с 1 клиентом
у меня Доставка на р3 800 Мегагерц и 512 ОЗУ работает..и ничего,полтора года уже )
А увеличение размера БД вручную-это тоже современные технологии? Просмотрел, что файл БД надо увеличивать и проблемы тебе обеспечены (а СУБД тебе даст даже какое-то время поработать в этой неисправной базе, чтобы потом проблем было больше). А создать сразу большой размер файла, UCS не рекомендует, ибо могут возникнуть проблемы. Вот и получается, что нужен глаз да глаз.
---------- Добавлено в 14:34 ---------- Предыдущее сообщение было размещено в 14:31 ----------
у меня Доставка на р3 800 Мегагерц и 512 ОЗУ работает..и ничего,полтора года уже )Да железо в наше время это вообще не проблема. Любого среднего офисного компа, хватит за глаза для базы MSSQL. Поэтому, считаю это не показателем.
---------- Добавлено в 15:03 ---------- Предыдущее сообщение было размещено в 14:34 ----------
Да и не было в моем случае проблем с железом-это видно по логам. А, если БД можно убить простыми действиями пользователей при работе с программой, то это, ИМХО, недоработка разработчиков. Почему тогда ремонт должен платным? Возможно, я что-то не так настроил\недонастроил-это тоже, как вариант. Но во-первых эта база работала уже не первый год, а во-вторых особых рекомендаций по технической настройке SH я не нашел. Буду рад советам, на что следует обратить внимание. Вот моя конфигурация: одна база SH, с 2 корневыми вершинами меню. Данные сливаются в нее из 2 ресторанов. Работа с базой одновременно с 3-ех рабочих мест по TCP\IP (ЛВС, не интернет). Документов заносят достаточно много (после года работы размер файла базы пришлось увеличивать от стандартного размера).
Да железо в наше время это вообще не проблема. Любого среднего офисного компа, хватит за глаза для базы MSSQL. Поэтому, считаю это не показателем.
хм... яб поспорил с вами...
"нормальный" офисный комп стоит 10тыров+моник 4тыра
нормальная pos касса стоит 1тыр на радиорынке+моник 4тыра(хз почем там сейчас тачскрины 15"... но последний раз брал за 4тыра)
и того реальная Экономия 9 тыров за комплект... а если это Огромный кинотеатр(как в моем случае)? там где 4 бара+5кафешек+4кассы премьеры+терминалы Автопродажи билетов...
вот и посчитайте сколько там экономии выльется...(заказчик "ВСЕГДА ЗА" удешевления проэкта). причем удешевление никак на работоспособности не сказывается.
Так данное ПО работает по клент-серверной технологии. Кто ж вас заставляет покупать "хороший офисный комп" на все рабочие места? База крутится на одном, а на остальных, пожалуйста-экономьте. Хотя такая экономия ни к чему хорошему не приводит и бизнес от такой экономии терпит одни убытки. Это дома можно поставить абы что, а для бизнеса, каждая минута простоя выливается в убытки.
Так данное ПО работает по клент-серверной технологии. Кто ж вас заставляет покупать "хороший офисный комп" на все рабочие места? База крутится на одном, а на остальных, пожалуйста-экономьте. Хотя такая экономия ни к чему хорошему не приводит и бизнес от такой экономии терпит одни убытки. Это дома можно поставить абы что, а для бизнеса, каждая минута простоя выливается в убытки.
поверьте мне, Это адекватная экономия. все работает... причем в разы быстрее чем на Мускуле... у меня есть с чем сравнивать 8-)
1С и базы на MSSQL не валятся просто так.
Да и база SH4 не валится просто так. В свое время на interbase было на порядок больше проблем.
Подобные Вашей, проблемы с базой - единичные случаи.
если БД можно убить простыми действиями пользователей при работе с программой
Нельзя.
А увеличение размера БД вручную-это тоже современные технологии?
В данном случае - да. Специфика архитектуры. Резервирование размера обеспечивает скорость.
---------- Добавлено в 19:00 ---------- Предыдущее сообщение было размещено в 18:57 ----------
PostgreSQL спокойно потянет базу с 1 клиентом
С той же скоростью - нет.
Возвращаюсь к своему вопросу. В подстолбце "пользователь", столбца "изменена", некоторые поля пустые, что это значит? Т.е. я вижу, например накладная изменена пользователем Admin - такого-то числа. А в некоторых строках (и их много) - это поле (пользователь) пустое. Т.е. получается, что накладная есть в протоколе, но кто (и как) с ней работал непонятно... Или это просто накладные, которые не изменяли и не удаляли, а просто открывали?
Туплю. В столбце "создана" есть пользователь.
В прошлом году дважды поднимал базу SQL Server 2008 и 2012 (gamekeeper). В одном из случаев пришлось потерять выручку за пол дня - и это только на одном объекте.
Базу SH4 в прошлом году у меня ни одной не упало и это по сотне объектов.
Моя статистика говорит о том, что база SH4 будет постабильнее чем SQL Server
Powered by vBulletin® Version 4.2.6 LTS Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot