This is topic Отказ Тренда по работе с SIAD in forum SIAD/SQL. Архивирование в TRACE MODE / SIAD/SQL. Data Logging in TRACE MODE at Форум TRACE MODE: техническая поддержка.
Господа разработчики! У нас получилось так. Когда объём архивного файла перевалил за 600 Мб при чтениии МРВ начал периодически виснуть, а сейчас и вовсе отказался работать с архивом!? Что нам нужно предпринять по этому поводу? Заранее благодарю!
Posted by Grigorovskih (Участник № / Member № 1915) on :
После отказа работы с архивом мы обнаружили, что РТМ как бы заново начал писать в него данные, а старые не читает, по чему не понятно! Максимальный размер файла архива выставлен 800 Мб.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Судя по всему, Ваш архив был повреждён в следствии возникновения нештатного выхода из системы, определить причины не представляется возможным. Выяснить действительно ли архив был повреждён, мы можем лишь только получив от Вас сам файл архива. Если есть такая возможность, то выложите сжатый файл архива в интернете и пришлите нам ссылку для скачивания. Что касается медленной выборки из архива большого размера, то следует предпринимать меры при которых осуществляется более быстрое чтение, это: 1. Сокращать максимальный размер архива, выполняя резервное копирование. 2. Избегать неоднородных (наличие редких записей)записей в архиве. Использовать принудительную запись в архив. Мы продолжаем совершенствовать механизмы работы с архивами СПАД, в следующем релизе будет добавлен ряд функций позволяющих восстанавливать повреждённые архивы с минимальными потерями данных.
Posted by Путинцев Н.В. (Участник № / Member № 1093) on :
У нас тоже такая проблема. Но мы сбрасываем архив в текстовый файл, а потом своими средствами просматриваем его. Вы пишите, что надо делать резервное копирование. В таком случае скажите, пожалуйста, как потом посмотреть резервную копию архива?
Posted by Grigorovskih (Участник № / Member № 1915) on :
//Но мы сбрасываем архив в текстовый файл, а потом своими средствами просматриваем его// А не поделитесь средствами?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Для проверки работы с данным архивом нам необходим Ваш проект.
Posted by Майборода Алексей (Участник № / Member № 1701) on :
Товарищи! Почему игнорируются вопросы?!?!? Вы писали "1. Сокращать максимальный размер архива, выполняя резервное копирование.". Мы спросили "В таком случае скажите, пожалуйста, как потом посмотреть резервную копию архива?". Иначе смысл в резервной копии неясен.
2 Grigorovskih: Мы писали на delphi парсер текстовых файлов с возможностью просмотра в виде графиков. Программа написана конкретно под нашу задачу, с конкретными именами каналов. Без изменения использовать Вам её не получится, проще самим написать под Вашу задачу.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
2 Майборода Алексей: 1. Вы можете экспортировать СПАД архив из модуля rtmg32.exe ИС ТМ6. 2. Используйте проект на отдельной машине, в который "подставляйте" файл архива необходимый для анализа.
Posted by Майборода Алексей (Участник № / Member № 1701) on :
Здравствуйте. 1. из модуля rtmg32.exe могу экспортировать в теже самые текстовики. Причем резервную копию архива он не воспринимает (не делает текстовиков из копии). Вопрос же стоял как я могу просмотреть копию не экспортируя её в текстовики? С текстовиками мы и так сделали, но этож надо писать свой софт (который мы написали) для отображения текстовиков в виде графиков. Или предполагается что оператор будет сидеть и смотреть текстовики строку за строкой? У нас автоматом каждые сутки экспортируется архив в текстовик который потом можно в написанной программе смотреть. Тоесть смысл резервной копии теряется. Было бы неплохо если бы был компонент типа Архивного трэнда с возможностью задания имени архива (в том числе и копии) тогда бы вопросов не было. А так приходится городить...
2. А как вы это видите? Оператор выгружает монитор на АРМ вынимает аппаратный ключ, идет на другую машину, вставляет аппаратный ключ, загружает тот же самый проект, заменяет SIAD архивным SIADом и смотрит? Это чтож получается надо покупать два монитора один из которых нужен только для просмотра архива? (сколько тогда будет стоить один канал?) Или монитор тот же самый а ключ носить туда сюда. А если в это время авария, надо срочно скорректировать параметры, а ключ черт знает где. К томуже ещё и машины две надо будет. Вобщем как то непонятно с этим всем. Помню Вы хотели писать ODBC-драйвер к SIAD но потом передумали, это тоже был бы неплохой вариант.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Господа! Архив я отослал на службу техподдержки.
А замечения в принципе справедливые по поводу трудностей с резервной копией! Драйвер ODBC это было бы самое лучшее, но при такой структуре архива как у Вас (2/3 файла одни нули) вряд ли будет эффективно! Файл SIAD сжимается архиватором аж в 28 раз! Хотя записи ведутся равномерно по всем каналам (цикл пересчёта для каналов одинаковый), это Вы делали замечание по поводу неоднородности записей. Поэтому стоит на будущее задуматься над структурой SIAD.
Posted by Grigorovskih (Участник № / Member № 1915) on :
...Пордон! Не архив, а проект...
Posted by Grigorovskih (Участник № / Member № 1915) on :
Ну, как там проверка нашего архива?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Проверка Вашего архива подтвердила версию о повреждении. К сожалению, восстановить данный архив не представляется возможным.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Господа! Ведь Вы же везде пишете, что SIAD это мощная, быстродействующая и надёжная БД! Архив месячный для 12 каналов весит 600 мБ и еле, извиняюсь, "ворочается"! Причём если его сжать архиватором, размер уменьшается до 16 мБ! Какова его структура, нам не понятен смысл? Если такие сбои будут происходить и дальше, как решать такие проблемы? Вся ответственность лежит на нас, кому претензии предъявлять? Архив должен быть, как минимум, за один месяц, всё остальное можно сделать в резервную копию. Но если бы месячный имел объём порядка 100-200 мб, при прочих равных условиях, он бы работал нормально! Если разбить каналы на три архива то объём каждого не уменьшается пропорционально в три раза, проверяли. Как решить проблему быстродействия и надёжности, подскажите пожалуйста? Заранее благодарю!
Posted by Grigorovskih (Участник № / Member № 1915) on :
Участники форума! Если не секрет, а у Вас какие размеры архивов и сколько там каналов? И на сколько быстро они работают? Поделитесь, если есть свободная минутка.
Posted by Майборода Алексей (Участник № / Member № 1701) on :
Каналов у нас пишется штук 40. На скорость записи не жалуемся, а вот например текстовик экспортируется с данными за сутки где-то минуты 2-3. Ещё не решили что делать с большим архивом, если мы делаем текстовики каждые сутки то его поидее можно и удалять каждые сутки чтобы он каждый раз новый начанался, но пока ещё не пробывали. Смысла держать большой архив нету, копию тоже нет смысла делать, ибо она бесполезна.
Posted by Grigorovskih (Участник № / Member № 1915) on :
А размер какой архива выставлен максимальный в настройках узла?
Posted by Grigorovskih (Участник № / Member № 1915) on :
На скорость записи и мы не жалуемся, а вот когда трендом смотреть начинаем, тогда и проблемы начинаются!
Posted by Майборода Алексей (Участник № / Member № 1701) on :
Размер архива 128 мегабайт выставлен. Мы пока этим не заморачивались. Смысла делать его большим нету, несколько десятков мегабайт и хватит, каждые сутки генерировать текстовики, а архив сносить чтобы начинался новый и все.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Уважаемая AdAstra! Т.е. я вижу один путь решения проблемы - всё что свыше суток, писать в SQL. Тогда вопрос разработчикам: Господа! А как трендом просматривать данные c SQL? Т.к. делать какие то "текстовики" нет смысла, т.к. нет типовых средств для его воспроизведения!
Posted by Майборода Алексей (Участник № / Member № 1701) on :
Проще свое написать "средство", под свою конкретную задачу
Posted by Grigorovskih (Участник № / Member № 1915) on :
... ну в принципе получается так! Только это средство должно с чем работать? С "текстовиком" или уж наверно с SQL тогда. Алексей - спасибо за участие! В этом топике техподдержка про нас наверно забыла!
К стати Господа разработчики писали о том, что надо использовать принудительную запись в архив, тогда что это даст? И кто нибудь это использовал?
Posted by Майборода Алексей (Участник № / Member № 1701) on :
Мы работает с текстовиками, нам так "проще" чем ставить SQL Server. Хотя если бы данные были в SQL то выбрать их и отобразить на графике было бы проще и быстрее, чем парсить текстовик. Но так или иначе нехорошо получается то, что приходится дописывать что-то самим, уплатив немалые деньги, ведь заявлена возможность создания резервной копии, а толку, просмотреть нельзя. Если уж даете возможность создавать резервную копию, то надо бы и средства просмотра... а то как-то нелогично получается
Posted by Дмитрий Юрьевич М. (Участник № / Member № 1930) on :
Хм, у меня тут маленькая мысль родилась. Про просмотр резервного архива. На уровне танцев с бубном. Архивировать в SIAD1, например, с именем SIAD1.rep. При резервировании копируем его куда-нибудь. При желании просмотреть кладем его вместо SIAD_backup.rep. А на этот файл настроен, к примеру, SIAD2 (или SIAD3). А уже когда имеем этот SIAD2, можно и срезами его, и статистикой, по крайней мере хоть что-то можно попытаться предпринять. В качестве второго, более реального, решения хочу подумать на тему портирования в SQL Server. Например, раз в сутки, как и Вы, буду экспортировать в txt, запускать для него парсер и загонять данные в БД SQL Server. А уж там внешними для ТМ средствами делай с ней что хочешь. По крайней мере, при желании можно поднять данные пятилетней давности не заморачиваясь по поводу "1. Сокращать максимальный размер архива, выполняя резервное копирование. 2. Избегать неоднородных (наличие редких записей)записей в архиве. Использовать принудительную запись в архив." Ваши мысли, господа?
Posted by Майборода Алексей (Участник № / Member № 1701) on :
1) Неуверен что получится, пробывать нет времени, но просто так подменить наврятли получится.
2) Если у Вас на объекте будет использовать SQLServer то решение нормальное. Нам проще делать текстовики, сжимать их и ложить в папку отдельную. А программа уже берет нужный архивчик, разворачивает, парсит его и отображает в виде графиков. Так уже сделано и так работает (правда пока без архивирования текстовиков).
Тут вопрос в другом, почему есть возможность создавать резервную копию а нет средства его просмотра (нормального средства, а не через пень колоду)? Вот это самое обидное, а не то что самим приходится чтото дописывать. У нас тут уже кучка своих библиотек и не одна самопальная сторонняя программа.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Я думаю АдАстре нужно рассмотреть эту, как вы сказали "самопальщину" и выбрать рациональное "зерно"! Т.к. опыт эксплуатации очень ценен!
Posted by Grigorovskih (Участник № / Member № 1915) on :
И ещё, господа, у меня возникла проблема с МРВ после того как я попытался использовать для тренда сохранение его буфера в файл. И я уж было обрадовался, в течении суток размер составил 1,5 Мб и тренд просто летает при работе с этого файла, но не тут то было. Начинаешь листать тренд сразу МРВ вылетает. Я буду освещать этот вопрос не в этом топике, т.к. тема относится к другому разделу - "МРВ".
