мы удоволетворены работой системы архивов TRACE MODE 5: они быстрые (особенно на запись информации), надежные, имеют ODBC-доступ. В новой версии планируются ряд улучшений: работа с множеством томов, оптимизация операций ввода/вывода, развитие сервиса по связи с СУБД и т.д.

1. Вот выдержка из документации по ТМ5:

********************************************************************
Следует учитывать, что в таблицу заносится время изменения значений. Поэтому, чтобы узнать значение в определенный момент времени, нужно сделать следующее:

· Ввести в фильтр для поля времени выражение вида <TIME, где TIME – значение времени в формате данной прикладной программы;

· Отсортировать значения поля TIME в обратном направлении.
*********************************************************************

Именно по этой причине я никому не рекомендую пользоваться ODBC-драйвером к архиву, поскольку ради одного значения приходится выбирать весь архив, потом его еще отсортировать и еще проверить, работала ли система...
Для чего люди придумали SQL-сервера - чтобы не таскать набор данных целиком, а только результат запроса. Разве не очевидно, что работа по поиску данных должна выполняться ODBC-драйвером, а не клиентом?

2. Часто необходимо хранить разные параметры с разной глубиной (например, параметр с периодичностью обновления в 1 сек хочу хранить 3 дня, а параметр с периодичностью 1 сутки - год)

3. Часто необходима настройка архивирования отдельно каждого атрибута канала, а не как в ТМ5 - или все архивируем или ничего. Сейчас приходится либо создавать ради архивирования отдельного атрибута дополнительные каналы либо замусоривать архив значениями ненужных для архивации атрибутов.

>Разве не очевидно, что >работа по поиску данных должна выполняться >ODBC-драйвером, а не клиентом?

Не очевидно. Принятая нами система промышленных архивов оптимизирует следующие параметры:

1) быстрая запись данных,
2) быстрое из извлечение данных
3) компактное хранение
4) резервирование, синхронизацию и восстановление данных

За эти свойства (для нас они представляются имеющими наивысший приоритет) приходится платить некоторым неудобством. У нас реализовано хранилище данных, в которое значения каналов заносятся по изменению, а не с указанным периодом. Это позволяет хранить данные очень компактно и иметь точную информацию о времени изменения параметра, чего нельзя добиться при сохранении с заданным периодом. В проекте Нассирия по ГРЕС в день заполняется 100 мегабайт - винчестера 100 Гб хватит на 3 года (такой винчестер стоит сейчас менее 200$).

Для чего люди придумали SQL-сервер? Не для АСУ ТП, а для хранения бизнесс-информации. Поэтому SQL-сервер очень медленный. Он оптимизирован на исполнение структурированных запросов к данным. Тогда как архив АСУ ТП должен в первую очередь обеспечивать быструю запись данных, быстрое из извлечение и компактное хранение. Поэтому основой ситемы архивов ТМ6 будет модернизированнаый СПАД. Впрочем писать данные в SQL-сервер можно уже и в ТМ5. Но не советую!

>2. Часто необходимо хранить разные >параметры с разной глубиной (например, >параметр с периодичностью обновления в 1 >сек хочу хранить 3 дня, а параметр с >периодичностью 1 сутки - год)

Это будет решено путем введения множества томов (об этом я уже писал).

>3. Часто необходима настройка архивирования >отдельно каждого атрибута канала,

Поясните, какие атрибуты каналов Вам требуется сохранять? В общем случае сохранение абсолютно всех атрибутов нецелесообразно. Это сильно раздует структуру канала и усложнит систему архивирования, что в свою очередь снизит быстродействие архивов и раздует их объем. Кроме того мы получим замедление пересчета базы каналов, более высокие требования по памяти и кучу других проблем. С другой стороны, атрибуты каналов меняются редко (как часто меняются границы каналов), а если они не меняются, то и запись в архив не производится - так что места в архиве они почти не занимают. Поэтому не очень понятно, чем реально Вы не довольны. Объем "мусора" минимален!

>4. Входное и аппаратное значение вообще >невозможно архивировать, не прибегая к доп. > каналам. Хотя сплош и рядом ситуация, >когда при разборе аварий КИПовцу нужно >входное или аппаратное значение, а >технологу - реальное.

<В проекте Нассирия по ГРЕС в день заполняется 100 мегабайт - винчестера 100 Гб хватит на 3 года (такой винчестер стоит сейчас менее 200$).>

Не надо уж так, всех под одну гребенку, далеко не у всех задачи 1:1 как в Насирии. И то что хорошо подходит для них вовсе не означает, что это именно то что нужно всем остальным. Кстати, не могли бы Вы озвучить такую статистику: как распределяются объемы продаж МРВ на 128, 1024, 32000 и 64000 точек в.в.?
Просто любопытно, какая же средняя "Крупность" АСУТП.

<Впрочем писать данные в SQL-сервер можно уже и в ТМ5. Но не советую!>

Я тоже не советую делать этого средствами ТМ5. БД то нынче "навороченные" пошли, хранимые процедуры и транзакции там всякие, понимаш... С простейшим INSERT INTO и не суйся.

<Поясните, какие атрибуты каналов Вам требуется сохранять? >

Помните, как на форуме asutp@yahoogroups.com на вопрос чем число точек в/в отличается от числа тэгов Вы ответили, что в ТМ на каждую точку в/в приходится >100 (точную цифру не помню) внутр. переменных. Замечательно, но допустимое число каналов = числу точек в/в. Платить за каждую перменную, требующую архивироания как за отдельный канал многим не по карману, поэтому исполнительные модули покупаются, как правило, именно строго по числу точек в/в. Как же быть с расчетными параметрами, если их нужно архивировать или сохранять в дамп? Вот и приходится писать их в атрибуты каналов.

<В общем случае сохранение абсолютно всех атрибутов нецелесообразно.
Это сильно раздует структуру канала и усложнит систему архивирования, что в свою очередь снизит быстродействие архивов и раздует их объем. Кроме того мы получим замедление пересчета базы каналов, более высокие требования по памяти и кучу других проблем.>

Сами же прекрасно осознаете проблему, не сделали наоборот - атрибуты можно архивировать только все сразу.

<С другой стороны, атрибуты каналов меняются редко (как часто меняются границы каналов), а если они не меняются, то и запись в архив не производится - так что места в архиве они почти не занимают.>

Запрос "дай мне значение параметра за такое-то время" - это штатная функция ODBC-драйвера, которая реализуется, если клиент обратится к нему с помощью соответствующего SQL-запроса. Для этого действительно не надо клиенту шерстить весь архив.

Вы не находите, что противоречите сами себе. Еще раз привожу выдержку из документации:
********************************************************************
Следует учитывать, что в таблицу заносится время изменения значений. Поэтому, чтобы узнать значение в определенный момент времени, нужно сделать следующее:

· Ввести в фильтр для поля времени выражение вида <TIME, где TIME – значение времени в формате данной прикладной программы;

· Отсортировать значения поля TIME в обратном направлении.
*********************************************************************
Да, формально такой SQL-запрос есть, но возвращает он как правило пусто. И шерстить (выбрать весь и отсортировать) архив придется.

<Мы уведомили Вас об этом (с предоставлением примера), когда Вы с этой проблемой обратились в службу техподдержки.>

Неточности в документации необходимо признать. Мы их, безусловно, вылавливаем и документацию выправляем.
Но в данном случае это не так. Я вынужден был откорректировать свой предыдущий ответ (см.мой ответ от 9.11.01) по поводу проблемы "атрибуты пишутся в архив при каждой попытке записать в них значения, в том числе и при повторе старого значения".
Здесь нет ошибок.

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

В соответствии с этим уточнением я откорректировал 2 своих предыдущих сообщения за 9.11.01

1.
05.11.2001 18:02 Дмитрий А. Попов, инженер службы техподдержки пишет (мне директом):
"Функция сохранения в СПАД по изменению реализована на данный момент только для реального значения канала. Реализация этой функции для других атрибутов канала связана с необходимостью существенной переработки существующей структуры базы каналов, что не планируется в текущей, пятой версии"

2.
08 November 2001 11:34 Lev Anzimirov wrote:
"С другой стороны, атрибуты каналов меняются редко (как часто меняются границы каналов), а если они не меняются, то и запись в архив не производится - так что места в архиве они почти не занимают."

Вы правы по поводу необходимости соблюдения тематической направленности данного раздела ФОРУМА. Извините.

Свои ответы переношу в раздел "Архивирование в Трейс Моуд", тема "Архивирование атрибутов".