SQL база ГТД. Сиквестирование базы. Вопросы.

[Koteneff]

База данных деклараций уже настолько большая, что заметно начинает влиять на работу декларантов. Есть кашерное средство для сбрасывания части ГТД в другое хранилище ? Если нет, можно ли сделать предзаказ на такой инструмент ? Все ГТД храняться в структре папок. Есть две подкорнеевые папки архив 08 и 09 годов, от которых хотелось бы избавиться в текущем хранилище. И вообще очень интересна тема на предмет скажем дефрагментации-нормализации БД.

[popov]

Сделайте резервную копию базы (backup), а затем удалите папки за 08 и 09гг. вместе со всем содержимым. Рез. копия будет "архивом", который можно в случае чего восстановить "с боку", а раб. база станет "легче".
Я думаю сделаем скоро менюшку Сервис/Чистка базы, которая по всем папкам позволит пройтись и удалить лишнее...

[Koteneff]

Сделайте резервную копию базы (backup), а затем удалите папки за 08 и 09гг. вместе со всем содержимым. Рез. копия будет "архивом", который можно в случае чего восстановить "с боку", а раб. база станет "легче".
Я думаю сделаем скоро менюшку Сервис/Чистка базы, которая по всем папкам позволит пройтись и удалить лишнее...

тоже вариант... спасибо будем ждать от вас интересных решений

[AndrewT]

Есть вероятность, что у Вас разрослась база сообщений. Пока мы не сделали культурное "обрезание" в программе, попробуйте выполнить следующую команду в Express Studio (только после бэкапа!):

Update EdMsgs set Msg=null where PreparationDateTime<DATEADD(Day, -60, GetDate())

60 - это количество дней, старше которых удалятся сообщения.

[vvs]

Попытался очистить все ЭД сообщения, как описано выше. Не получается. Сообщения так и остались в списке.

[Nick]

Сообщения в списке остались, так и задумано. Но главную нагрузку создают не "заголовки" сообщений, а их XML-содержимое, полный текст сообщения висящий на поле Msg. От 4Kb до 10Mb на сообщение. Вот его то предлагаемый скрипт и отвешивает. База сразу должна полегчать в разы по объему (это можно увидеть по размеру файлового бэкапа).

P.S. В каком-то из приказов по ЭД написано, что именно подписанные ЭЦП электронные ГТД должны хранится 3 года, как и бумажные. Так что backup и еще раз backup, именно база сообщений, а не ГТД в формате "Альты" в случае чего является документом! Она конечно есть в таможне... А вдруг потеряется

[Koteneff]

на выходных попробую.

[Koteneff]

Вообщем докладываюсь.
Бекап базы.
Файл базы данных 1.9 ГБ.
Запустил скрипт для таблицы EDMSGS. Удалилось 6000 строк. Размер файла не поменялся ни на байт.
Удалил целую папку в базе за 2008 год со всеми документами. Аналогично - файл как был таким и остался.
Запустил task сжатия БД. После сжатия получил базу на 24 мегобайта меньше. И весь результат.

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

[popov]

Так, во-первых, тут ошибочка закралась.
Если Вы выполняли запрос:

Update EdMsgs set Msg=null where PreparationDateTime>DATEADD(Day, -60, GetDate())

То откатывайте базу из бэкапа, т.к. Вы почистили НОВЫЕ сообщения, а все старые остались как были!

Я бы их конечно удалял, а не чистил:
DELETE FROM EdMsgs WHERE PreparationDateTime < DATEADD(d, -60, GetDate())
Но можно и тот запрос выполнить, только знак поменять (PreparationDateTime < ...)

Плюс удаление документов с последующим сжатием БД должны существенно повлиять на размер БД...
(если у Вас конечно не 90% всех ЭД-сообщений за последние 60 дней)

[Koteneff]

Так, во-первых, тут ошибочка закралась.
Если Вы выполняли запрос:

Update EdMsgs set Msg=null where PreparationDateTime>DATEADD(Day, -60, GetDate())

То откатывайте базу из бэкапа, т.к. Вы почистили НОВЫЕ сообщения, а все старые остались как были!

Я бы их конечно удалял, а не чистил:
DELETE FROM EdMsgs WHERE PreparationDateTime < DATEADD(d, -60, GetDate())
Но можно и тот запрос выполнить, только знак поменять (PreparationDateTime < ...)

Плюс удаление документов с последующим сжатием БД должны существенно повлиять на размер БД...
(если у Вас конечно не 90% всех ЭД-сообщений за последние 60 дней)

Дмитрий, не могли бы вы оставить свой телефон в личку? А то в выходной день даже не с кем проконсультироваться когда с базой занимался.

[kots]

Как скоро будет приделано "культурное обрезание базы"? обещали ведь.

[Koteneff]

Как скоро будет приделано "культурное обрезание базы"? обещали ведь.

я думаю, что надо культурно изложить свои пожелания как мы видим "культурное обрезание" базы со своей стороны

Вот как видишь это ты ? Делись

[kots]

Я вижу это в виде кнопки в программе в меню сервис. я нуб в этом, но думаю програмерам не составит труда сделать что то, чтоб не грузилась вся база при запуске.

[Sergey]

Я вижу это в виде кнопки в программе в меню сервис. я нуб в этом, но думаю програмерам не составит труда сделать что то, чтоб не грузилась вся база при запуске.

Ну так база у вас и не грузится, ни целиком, ни частично. Программа посылает запрос к базе, а база выдает ответ в виде списка, который и показывается. Так что навешивание на запрос дополнитенльных условий скорее приведет к замедлению работы, нежели к ускорению.
Да, визуально может быть будет удобнее, когда видишь декларации ну например за 1 месяц, а не все, но скорость работы при этом не увеличится точно.
А вот если под "обрезанием" подразумевается очистка (удаление) не нужного, то делитесь, что по ванему мнению является лишним и от чего бы вам хотелось избавится. Уменьшение размеров конечно повлияет на скорость.

[Koteneff]

Ну тут все просто.
Так как визуально есть список слева экрана и декларант как обычный человек привык работать максимум с файлами, то ему и надо дать возможность визуально работать с файлами поэтому надо как в Windows Commandare дать ему две панели со списком файлов сиречь деклараций

Вторую панель привентить к новой базе (к примеру "Архивной") куда декларант может визуально drag-and_drop'ом перетаскивать декларации со взаимосвязанными документами, тем самым освобождая базу самолично и контролируя процесс.

Это очень удобно, особенно если декларации в списке лежат в папках. Папку перетащил в архив и спокоен. У меня в корне базы есть папка Архив2008, Архив2009... скоро появиться папка архив2010, вот куда их перетаскивать ?
__________

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

Вообщем нет ничего простокго как дать возможность как с файлами работать. Причем с возможностью создать БД чистую из Альты со всеми правами доступа как в текущей для переноса туда чего нибудь не нужного уже. Причем переносить историю ЭД при переноси ЭГТД которая была подана по ЭД. Или забить на это Но признак того что она была подана по ЭД надо оставить, что бы всегда можно было поднять нужный год, найти нужную ГТД и сформировать запрос по истории этой ГТД. (важный ньанс)

Собственно вот так.

[Koteneff]

есть еще вариант - напписать инсткцию по работе в сиквеле и дать пару скриптов )) но опять же нужно четкое описание что и как делать если у вас база зашкаливает за 2 Гигобайта или если вас растерзали декларанты за тормоза

[Sergey]

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

Серега, рулеж базами, это чисто админская ф-я. А ты предлагаешь из программы дать полный доступ к Б/Д. По незнанию можно такого наворотить, что и во век не разгребешься. Поэтому изначально и было сделано прописывание прав, создание/удаление баз руками админа. А декларанту только доступ к тому, что можно.
Я с тобой согласен, надо что-то придумывать с архивами, сжатием и т.д. Но не из ГТД, возможно из ГТД-Сервера или скриптами.
По поводу архивов, постоянное переключение между несколькими базами в процессе работы не есть гуд. Так же как не есть гуд постоянно держать открытыми несколько соединений.
Опять таки "перетащить папку" - это же физическое перетаскивание данных на серваке из базы в базу, а это время и много... Если при такой "случайной" операции работа подвиснет на полчаса у всех, декларанты спасибо точно не скажут.

[Koteneff]

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

Я не собираюсь давать декларантом полную рулежку. к тому же при граммотной организации процесса все будет элементарно просто: "Я открыл меню - выбрал пунк - манипуляии с ГТД - открылось окошко с двумя списками ГТД и я начал манипулировать. Если не была готова вторая база - программа мне предложила ее создать на сервере, перенеся всю структуру из первой с правами доступа к ней из первой таблицы - ну и тд.

Давай так, давай определяться по пунктам.
Определения:
БД - текущая SQL-база данных декларанта
АРХИВ - любая другая SQL-база

Проблема:
1) Рост БД.
1.1. физический рост БД от прироста числа ГТД и взаимосвязанных документов
1.3. физический рост БД от таблицы ЭД

2) отсутствие файловых манипуляций с ГТД или с папками с ГТД.
2.1. отсутствует перенос, копирование из БД в АРХИВ и обратно.

Пути решения:
1) сделать инструкции и скрипты для администратора БД.
2) сделать инструмент для файловых манипуляций с БД.

Причем в Альте надо сделать возможным работать с двумя источниками (БД и АРХИВОМ). Потому что администратора может и не быть, а перенести папку в АРХИВ и забыть о ней декларант должен уметь. Да и администратору проще работать, ему сказали хекнуть "клиента" или сразу нескольких или за целый год и он хекает. БД полегчала, АРХИВ пополнился - все давольны. Если декларанту взбелениться влезть в архив, откроет меню - подключит на выбор АРХИВную базу и перенесет свои наработки в БД.

Но это мое видение на собтсвенном опыте работы с отделом декларантов в 12 человек. Не знаю много это или мало по нынишним меркам. Вообщем где то так.

Хочется информацию накапливать а не терять. Сортировать и хранять. Сейчас вся сортировка идет в БД в папках по имени года 2008, 2009... . Хранение тоже в БД. А это уже напрягает.

Возможно требуется более системный подход. База ЗАРЕГИСТРОВАННЫХ ГТД. ЕЕ использовать. В нее сливаем мы только ГТД с отметкой для построения отсчетов. Обратно из нее получить что то проблематично - восстановление происходит в файл на диск, а не в БД.
База ЗАРЕГИСТРОВАННЫХ ГТД - это эрзац всех наработок брокера в чистом виде, ее было бы удобно подключать и драг-эгд-дропом перетаскивать в БД.

...
p/s/ написал это все и понял что просто самому хочется нормальной работы )) а не шхереться на серверах и запускать непонятные скрипты ожидая всяких неожиданностей.

[Koteneff]

Так, во-первых, тут ошибочка закралась.
Если Вы выполняли запрос:

Update EdMsgs set Msg=null where PreparationDateTime>DATEADD(Day, -60, GetDate())

То откатывайте базу из бэкапа, т.к. Вы почистили НОВЫЕ сообщения, а все старые остались как были!

Я бы их конечно удалял, а не чистил:
DELETE FROM EdMsgs WHERE PreparationDateTime < DATEADD(d, -60, GetDate())
Но можно и тот запрос выполнить, только знак поменять (PreparationDateTime < ...)

Плюс удаление документов с последующим сжатием БД должны существенно повлиять на размер БД...
(если у Вас конечно не 90% всех ЭД-сообщений за последние 60 дней)

я сегодня сутра сделал с цифрой 30 дней. БД полегчала на 210 Мбайт. Так что за неполных семь месяцев База ростет на 200 МБайт только из за ЭД. И это только начальная скорость, потому что количество ЭГТД в месяц растет тоже. Если мы в прошлые полгода утилизировали пакет в 50 и 500 ЭГТД, что сейчас утилизируем пакет в 1000 ЭГТД.

[popov]

Я так думаю что данная проблема (большой размер БД) актуальна в основном для бесплатной версии SQL Server (Express Edition), которая имеет ограничение на размер БД в 4 Гб (кстати для SQL 2008 R2 уже 10 Гб разрешили ), соответственно одним архивом (одной доп. БД) здесь дело не ограничится, т.е. рано или поздно в архивной БД тоже место закончится. А это значит, что архивов придется делать несколько. И такой подход (с drag'n'drop) может закончится полным бардаком, особенно если это отдать на откуп пользователям (декларантам).
Именно поэтому нам ближе схема с периодической чисткой БД, т.е. рабочая БД должна быть ровно одна (именно в нее сыпятся все новые ЭД-сообщения и в ней делаются документы), просто периодически (например, раз в месяц-два) администратор делает ее резервную копию (backup), обозначая соотв-щим периодом времени, и затем удаляет из нее старые ЭД-сообщения (и возможно документы).
При таком подходе можно всегда быстро найти рез. копию БД за интересующий период времени, восстановить ее "сбоку" и что-то там посмотреть, достать (копируя через файлы)... Главное не забыть отключить ф-ции ЭД при подключении к такой БД из ГТДшки, а то туда начнут сыпаться новые ЭД-сообщения и потом проблем не оберешься...