Разработка СУБД АСКУЭ с использованием сервера SQL

Все необходимые для  хранения таблицы и прочие элементы создаются автоматически и вмешательства пользователей не требуют.

Планирование объема  рабочей базы - достаточно нетривиальная задача. Для ее решения целесообразно сделать сначала ориентировочный расчет суточного увеличения размера таблиц, а затем проверить фактический темп прироста на практике. Сложность задачи заключается в том, что расчетным путем точно спрогнозировать размер базы невозможно, т.к. он зависит от неизвестного наперед количества событий в контролируемой системе и других факторов. Кроме того, размер каждой отдельной суточной таблицы данных сильно меняется. В течение суток после создания таблицы размер ее увеличивается (вследствие поступления данных), по завершению суток размер стабилизируется, а по истечению сроков годности данных размер таблиц начинает уменьшаться вследствие работы процедур автоматического удаления данных. Таким образом, фактический размер базы определяется динамическим взаимодействием двух процессов:

• роста, обусловленного приемом новых данных;
• сокращения объемов вследствие автоматической очистки от устаревшей информации.

Причем на эти процессы еще накладывается специфика  работы самого SQL-сервера. Например, повторное задействование освободившегося (после очистки) пространства производится не сразу и не в полном объеме.

Оценку суточного прироста таблиц базы данных можно выполнить  посредством относительно несложных  расчетов. Они базируются на имеющихся  в разделе "Основные характеристики БПО"  данных о размере строк. Порядок расчета таков:

1. Определяется суточный прирост числа записей о ВТИ;

2. Определяется объем  таблицы ВТИ;

3. Определяется объем  основных и дополнительных данных  ТК.

Рассмотрим порядок  расчетов на конкретном примере. Пусть  в проекте  задействовано:

• 200 ВТИ с 15-сек измерительным интервалом (5760 отсчетов в сутки);
• 1000 ВТИ с 3-х мин измерительным интервалом (480 отсчетов в сутки);
• 2000 ВТИ с 30-ти мин измерительным интервалом (48 отсчетов в сутки).

1. Получаем (200*5760)+(1000*480)+(2000*48)=1728000 отсчетов в сутки, суммарно.

2. Если 1е6 строк записей о ВТИ-сигналах занимают 51Мб, то таблица с рассчитанным количеством отсчетов будет иметь размер (1728000/1000000)*51= 88.1 Мб

3. Прирост размера  основных и дополнительных данных  ТК прогнозировать сложно, т.к.  число записей напрямую зависит  от неизвестного нам количества событий. Как показала практика, объем этих таблиц примерно одинаков, и в среднем составляет около 10-15% от объема данных ВТИ (каждая). Таким образом, суммарный прирост будет составлять 1.2-1.3 от прироста объема записей ВТИ-сигналов. Для нашего примера: 88.1Мб*1.3 = 114,6 Мб/сутки.

Нужно отметить, что прирост  более 100 Мб/сутки характерен для  достаточно больших систем.

При использовании предопределенных сроков хранения ВТИ-каналов, устанавливаемых  по умолчанию в большинстве случаев :

• 15-сек данные - сутки;
• 3-мин - декада;
• 30-мин - квартал;

примерно через сутки  работы системы объем таблиц описанной  выше базы данных уменьшится на 67%, через 10 дней - на 95%, а через квартал  таблицы будут по большей части  пустыми (останутся данные по каналам от календарных групп, которые по умолчанию хранятся дольше и др.).

Для облегчения задачи планирования размера базы данных, а также более  точного учета характеристик проекта, в составе хранимых процедур БПО предусмотрена специальная процедура eu_CommonData31, служащая для расчета планируемого размера базы данных на основе введенного проектного описания (количества УСД, счетчиков, групп, каналов от них и установленных сроков хранения).

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

Фактический размер базы данных и отдельных таблиц в ней  можно получить при помощи, например, штатной хранимой процедуры SQL-сервера sp_helpdb, программы Enterprise Manager и др. способами. Программа "Архиватор БД" из состава БПО также отображает в своем окне список имеющихся в базе наборов таблиц и суммарное количество строк в каждом суточном наборе.

2.5 Оптимизация  размера базы данных

В процессе эксплуатации базы данных АСКУЭ часто возникает противоречие между необходимостью (желанием) увеличивать количество каналов, сроки хранения информации и чрезмерным (вследствие этого) ростом размера базы данных. Как правило, используемые для работы БПО достаточно скромные по характеристикам компьютеры и версии (релизы) программного обеспечения SQL-сервера не позволяют достигнуть рекордных объемов хранения данных с удовлетворительной производительностью. Например, поставляемый в комплекте с БПО MSDE обеспечивает работу с базами только до размера в 2Гб. Как показала практика использования БПО, реально достижимый размер базы данных на ординарном компьютере составляет 10-12Гб; превышение этого предела требует перехода к специализированным серверным компьютерам и старшим релизам SQL-сервера, что не всегда возможно по экономическим соображениям. 

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

• Хранение информации в SQL-сервере. Позволяет обрабатывать информацию в оперативном режиме, но имеет упомянутые выше ограничения в связи с замедлением работы сервера по мере роста размера баз и т.п.;
• Хранение информации в виде отчуждаемых файлов суточных архивов данных. Такие архивы получаются при помощи программы "Архиватор БД" из состава БПО и содержат полную копию данных, хранимых в суточном наборе таблиц (на момент создания архива). Архивные файлы создаются по-суточно и позволяют хранить всю подробную информацию сколь угодно долго (в пределах срока жизни соответствующего машинного носителя - CD-ROM и т.п.). Для оперативной обработки необходимо загрузить соответствующий архив в базу данных сервера (при помощи той же программы "Архиватор БД").

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

Оптимизация размера баз данных достигается при выполнении следующих условий.

• Хранить в базе данных SQL-сервера следует только минимально необходимый набор особо важных каналов, используемых для формирования документов в оперативном режиме. Срок хранения должен прямо зависеть от степени важности канала; исходно можно ориен<span class="dash041e_0431_044b_0447_043d_044b_0439__Char" style=" font-size: 14p