все что связано с моей работой
Главная » Технические » СЭД и база в 2G

СЭД и база в 2G

Как известно СЭД умеет работать с двумя тапами БД – MS Access (всем ставиться по умолчанию) и опять же бд от MS – SQL Server 2000. Для экономии средств можно использовать MSDE. Скорость работы увеличивается ощутимо, и не просто ощутимо, а я бы сказал, – визуально ощутимо. Поэтому всем у кто может я советую переходить, даже если ваша база не доставляет вам проблем – поверьте все еще впереди. Да и переход при малой базе гораздо проще.

Но вернемся к нашим “баранам”. MSDE хоть и ускоряет работу ПО, но не решает “аксесовскую” проблему с размером базы в 2G. Сначала периодический шринк (SHRINKDATABASE) спасает, но со временем его надо делать все чаще и чаще – раз в месяц, потом раз в неделю, а потом появляется повод для такой вот заметки. Да и приближение к пределу практически сводит на нет, прирост производительности. А значит проблему надо решать.

Я не зря так много сказал про SQL, во-первых, у меня база стоит на MSDE, а во-вторых, SQL предоставляет некоторые ну очень полезные инструменты в данной ситуации. Дальше я буду просто писать SQL опуская даже “Server”, так проще, но подразумевается естественно технология SQL Server, не зависимо от реализации MSDE или полноценный SQL Server. Кстати про инструменты – я пользовался Среда SQL Server Management Studio Express удобно и распространяется она бесплатно, хоть предназначена для SQL2005, но и 2000-ным она прекрасно работает. При большой лени или чтоб держать систему “чистой”, можно запросто пользоваться и osql.exe из командной строки – просто у меня уже была установлена консоль от другого ПО. Как ей пользоваться объяснять не буду.

Итак начнем как и полагается с исследования. Самые большие тормоза проявляются при работе со справочниками и со справочником “счетов расходов, доходов и ИФ” (далее просто справочник счетов). У меня так открытие этого справочника занимает иногда до 7-10 минут, к слову на аксесе эта операция занимала до 20минут (!!!). Кто не в курсе это таблица KBKDRI.

В SQL существует очень полезная системная процедура sp_spaceused. Она позволяет узнать размер занимаемый объектом, в нашем случае таблицей. Результат для таблиц будет такой:

Column name Data type Description
name nvarchar(128) наименование объекта
rows char(11) количество записей в таблице
reserved varchar(18) всего зарезервировано места для таблицы
data varchar(18) всего фактически использовано.
index_size varchar(18) всего занято индексами.
unused varchar(18) остаток свободного места. (= факт. — использ.)

Делаем для базы с СЭД-ом:

exec sp_spaceused N'dba.KBKDRI'

У меня было 600+ записей и в колонке datа было где-то в районе 1.6Г с копейками (статью пишу по памяти уже после решения проблемы, и скринов не осталось). При общем размере базы в 2Г. После стандартной чистки база уменьшилась до 1.8Г почти 1.9Г

Теперь собственно суть проблемы. Начало года, отправка справочников. Объем полного справочника счетов около 300М (!) с копейками, объем “очищенной” базы, но с принятыми и не обработанными репликами справочника счетов 1.9Г. Еще раз оговорюсь, что, цифры не совсем точные, потому что все делалось несколько дней назад, и времени на документирование не было, надо было срочно что-то решать, чтоб не зависло финансирование и другие текущие операции.

Но общий смысл не меняется — база перед обработкой реплик полного справочника счетов на грани 2Г (!!!) и львиную долю из этого объема занимает как раз справочник счетов, который при стандартной чистке никак не затрагивается. Вариант с архивной базой тоже не сильно спасет ситуацию, т.к. документов в базе как оказывается не много, вернее объем который они занимают. Для других клиентов (ПБС и т.д.), которые отсылают в казначейство сканы документов, отправка “Произвольных документов” (FreeDualDocs) в архивную базу, конечно немного улучшит ситуацию, но и приведет к “пределу” раньше.

В этом состоянии при обработки реплик начинается “балансирование на грани”. У меня получилось, так что, половина реплик обработалось, а вторая половина повисла с ошибками от SQL о превышении базы. А теперь представьте детские сады, школы где нет таких специалистов – что делать им? И чем руководствовалось казначейство когда решили что все необходимы справочники со всеми бюджетами области?

После всяких “шаманствов”, танцев с бубном и т.д. ОТР посоветовали удалить из KBKDRI все что не бюджет Аксайского района. Это действительно сильно бы облегчило справочник и как следствие всю базу, а как повысило бы производительность … И хоть сотрудники поддержали, и сказали что мы не используем счета не из нашего бюджета, но все равно как-то боязно. Кстати сделать бэкап одной таблице можно из диктмана: “ПКМ”->“Export”.

Вообще для начала решил удалить записи которые имеют статус “удаленные”. Эти записи не показываются в программе даже с отключенной галочкой “только актуальные”, по крайней мере мне не удалось найти в колонке статус запись отличную от “Добавлена/Изменена”. Делается это простым запросом:

delete from dba.KBKDRI where STATUS=4

Результат слегка удивил, у меня из базы было удалено:

(строк обработано: 366942)

и после этого как всегда сжатие

USE [sed]
GO
DBCC SHRINKDATABASE(N'sed')
GO

размер базы стал 1.3 (!!!) немного отойдя, ну мало ли, кто как считает записи, еще раз запустил sp_spaceused и результат опять ввел в ступор:

namе     rows   reserved      data    index_size  unused
------- ------ ----------- ---------- ---------- ---------
KBKDRI  164882 1397312 KB  681656 KB  531208 KB  184448 KB

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

На этом наверно закончу, как-то очень длинно получилось из-за “крика души”

Комментариев нет

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.