переполнение sql базы

[RishatNurislamov]

Из практики внедрения "Больших" SQL серверов могу добавить:
Workgroup SQL ни чем не отличается от Standard и для Альты его вполне достаточно, но вот какую заметил особенность, когда в одной базе размером окало 50 ГБ работают 15 - 20 декларантов заметны некоторые торможения при отображении списка документов (1-3 сек очень раздражают). Но когда те же 15 - 20 декларантов на том же сервере работают каждый со своей базой в 10 - 15 ГБ такого не замечается.
Вывод - не надо стремиться к большим базам, лучше использовать архивные.

[alta_olg]

Основной объем БД это ЭД сообщения, ну еще, картинки...
Имеет смысл перенести ЭД сообщения в отдельную БД.
Это можно делать через меню Настройка, Сервер и сетевые настройки, Доп. базы ГТД для ЭД.
Создать сначала базу, затем перенести... (еще кнопку сжать имеет смысл применить для старых ЭД сообщений перед переносом)
Но только надо иметь ввиду, что процедура сжатия (и переноса) не быстрая, поэтому имеет смысл ставить на не рабочее время.

И еще, для создания Архивной БД имеет смысл использовать dbutils из папки \alta\utils\, и выбрать последний пункт (Создать архив БД ГТД).
Эта функция создает почищенную рабочую БД (где данные только за последний период), почищенную архивную (данные минус последний период) и копию исходной БД. Очень удобно.

[BigZmei]

А при бэкапе из программы бэкапятся обе базы? Уточнить хочется.

[aiki]

А при бэкапе из программы бэкапятся обе базы? Уточнить хочется.

При таких потребностях, когда приходится делить базы, обычно уже выделенный сервер используется, а там Альта-ГТД делать нечего. Лучше организовывать средствами SQL, агентом если купленный и запросом на sqlcmd если express edition.
На одном рабочем месте мне сложно представляется забить 10ГБ БД SQL2008

[BigZmei]

Не скажите. Есть места где 3-4 декларанта на одной базе сидят без выделенного сервера а база на одном из рабочих компов. С выделенным понятно.
Поэтому и хотелось уточнить, когда программа предлагает сделать копию, она обе базы сольет или нет.

[aiki]

Не скажите. Есть места где 3-4 декларанта на одной базе сидят без выделенного сервера а база на одном из рабочих компов. С выделенным понятно.
Поэтому и хотелось уточнить, когда программа предлагает сделать копию, она обе базы сольет или нет.

Не пробовал, но предположу что нет.
Тогда действуйте по второму сценарию (запросом на sqlcmd если express edition.)
2 cmd файла и планировщик виндовс обеспечат вам автоматический бэкап 2 баз
тут подробней http://spintegra.ru/nash_blog/sozdanie_ ... _sql-bazy/
И напомню, что если у вас 5 раб. мест то вам ГТД сервер предоставляется бесплатно а там уже есть ЭД сервис, чтоб рабочее место с Альта-ГТД разгрузить.

[BigZmei]

Ясно. я на сервере просто Cobian Buckap пользуюсь. Проще тогда его в этом случае и у клиентов настроить.

[aiki]

Ясно. я на сервере просто Cobian Buckap пользуюсь. Проще тогда его в этом случае и у клиентов настроить.

Судя по описанию он просто бэкапит файлы/папки. Если так, то это не то. Просто приаттачить файл БД SQL скопированный не выйдет.

[-Никола-]

вторая ЭД около 7ГБ пухнет быстрее, но при подходе к критическим 10ГБ просто создается новая ЭД БД и сообщения начинают валиться в новую. Делается это под Админом в Альта-ГТД, настройки, доп базы ЭД, там все просто и понятно.

Спасибо, сделал по твоему совету, всё действительно просто.
Возникло несколько вопросов. По достижению 10Гбт новая база создается вручную или автоматически? После создания новой базы старые сообщения становятся невидны? Но ведь декларантам нужны сообщения за последние 3 месяца.
Использовать инструмент очистки базы для базы с сообщениями теперь нельзя?
Про штатный бэкапер альты уже понял, что придется что то делать по новому. База крутится на машине основного декларанта, остальные 2 к нему цепляются.
А можно подробнее, что дает ГТД сервер, как он мне облегчит жизнь?

[aiki]

вторая ЭД около 7ГБ пухнет быстрее, но при подходе к критическим 10ГБ просто создается новая ЭД БД и сообщения начинают валиться в новую. Делается это под Админом в Альта-ГТД, настройки, доп базы ЭД, там все просто и понятно.

Спасибо, сделал по твоему совету, всё действительно просто.
Возникло несколько вопросов. По достижению 10Гбт новая база создается вручную или автоматически? После создания новой базы старые сообщения становятся невидны? Но ведь декларантам нужны сообщения за последние 3 месяца.
Использовать инструмент очистки базы для базы с сообщениями теперь нельзя?
Про штатный бэкапер альты уже понял, что придется что то делать по новому. База крутится на машине основного декларанта, остальные 2 к нему цепляются.
А можно подробнее, что дает ГТД сервер, как он мне облегчит жизнь?

1. Новая база создается вручную, там же, в управлении доп. базами. Только не забыть поставить что сообщения направлять теперь в новую БД.
2. Сообщения все остаются доступными, все "прозрачно" для пользователя, при условии что вы не отключите эту БД или т.п., т.е. просто будет висеть и отдавать сообщения по старым ДТ.
3. Раньше видел смысл в чистке БД, теперь не вижу, если у вас не маленькие SSD вместо много гигобайтных HDD
4. С бэкапами все довольно просто, чтоб в ручную не делать, пишете командный файл, создаете задание в планировщике и будет вам счастье.
ГТД сервер несет в себе неск модулей, полезен он когда появляется выделенный сервер:
1. сервис доставки сообщений, снимается нагрузка с раб. места и не нужно держать специально запущенное рабочее место декларанта.
2. можно организовать зеркало обновления ПО, когда САМ ГТД сервер будет качать допустим в 7 утра обновление с Альты, а рабочие места уже брать с него, снижает нагрузку на интернет, исключает попадание в моменты когда не возможно обновиться, бывает такое при большом наплыве обновляющихся, да и по локальной сети быстрее.
3 Монитор ЭД, как в виде программной оболочки, так и вэб морды, полезен больше для руководителя отдела например, видеть движение по ДТ.
4. Репликатор БД, на случай наличия удаленных офисов, и если нужно сливать/синхронизировать их работу.

[-Никола-]

2. Сообщения все остаются доступными, все "прозрачно" для пользователя, при условии что вы не отключите эту БД или т.п., т.е. просто будет висеть и отдавать сообщения по старым ДТ.

Это здорово

4. С бэкапами все довольно просто, чтоб в ручную не делать, пишете командный файл, создаете задание в планировщике и будет вам счастье.

Только тогда придется машину на ночь не выключать.

ГТД сервер несет в себе неск модулей, полезен он когда появляется выделенный сервер:
1. сервис доставки сообщений, снимается нагрузка с раб. места и не нужно держать специально запущенное рабочее место декларанта.

Да есть проблема с рабочим местом откуда уходят сообщения, оно реально подвисает.
т.е. я покупаю бодрую машину, ставлю в идеале 2 SSD (по 120Гбт) в рэйде зеркале (или это всё таки ненадежно?), ставлю туда ГТД сервер + SQL и будет счастье?
А ключи электронные всё равно будут у декларантов втыкаться в машины?

[aiki]

4. С бэкапами все довольно просто, чтоб в ручную не делать, пишете командный файл, создаете задание в планировщике и будет вам счастье.

Только тогда придется машину на ночь не выключать.

ГТД сервер несет в себе неск модулей, полезен он когда появляется выделенный сервер:
1. сервис доставки сообщений, снимается нагрузка с раб. места и не нужно держать специально запущенное рабочее место декларанта.

Да есть проблема с рабочим местом откуда уходят сообщения, оно реально подвисает.
т.е. я покупаю бодрую машину, ставлю в идеале 2 SSD (по 120Гбт) в рэйде зеркале (или это всё таки ненадежно?), ставлю туда ГТД сервер + SQL и будет счастье?
А ключи электронные всё равно будут у декларантов втыкаться в машины?

В планировщике укажете выключать ПК после завершения задания и все.
А зачем SSD? Я упомянул SSD в ключе их малого объема, в том плане что с нынешними объемами HDD процесс чистки БД от ЭД сообщений теряет смысл, хранить несколько дополнительных БД с ЭД по 10ГБ накладно только если у вас малый объем дискового пространства как при использовании SSD. Обычных HDD на небольшую раб группу вполне хватает в зеркале, но не забывайте что рэйд это не панацея и не отменяет резервного копирования, рэйд это возможность сократить время простоя при аварии и отложить сервисные работы до завершения рабочего процесса при необходимости, ну и повысить производительность при 10 (от 4 дисков) уровне рэйда.

[-Никола-]

А зачем SSD? Я упомянул SSD в ключе их малого объема, в том плане что с нынешними объемами HDD процесс чистки БД от ЭД сообщений теряет смысл, хранить несколько дополнительных БД с ЭД по 10ГБ накладно только если у вас малый объем дискового пространства как при использовании SSD. Обычных HDD на небольшую раб группу вполне хватает в зеркале, но не забывайте что рэйд это не панацея и не отменяет резервного копирования, рэйд это возможность сократить время простоя при аварии и отложить сервисные работы до завершения рабочего процесса при необходимости, ну и повысить производительность при 10 (от 4 дисков) уровне рэйда.

SSD потому что он по скорости работы обойдет обычный хард раз в 10 (именно при работе с базами). Но с надежностью пока не очень.
По рэйду ясно, это защита от поломки носителя, а бэкап защита от кривых рук работающих с базой ).

[-Никола-]

Подниму тему.
Разделение баз на базу с декларациями и базу с ЭД сообщениями помогло на 2 года. База с декларациями достигла 10Гбт. Варианта было 3.
1. Купить SQL
2. Поставить SQL с одного из трекеров )
3. Архивировать старые декларации.

Решил пойти по третьему пути. Большого опыта работы с базами данных нет, есть только общее понимание. Подробного описания процесса не нашел, поэтому делал интуитивно. Сделал бэкап основной базы, создал через SQL Management новую базу Arhiv_1 и попытался восстановить в нее базу из бэкапа. Сразу получил ошибку, поскольку основная база (gtd) и восстанавливаемая база (Arhiv_1) имеют одинаковые файлы.


Два файла подменил на аналогичные от базы Arhiv_1, а третий (ftrow...) создал вручную.


После этого все прошло гладко. Проверил в альте "Просмотр архивной SQL БД", все видно и работает.
Пришло время чистить основную БД. Запустил встроенную процедуру из Альты с параметрами удалить все старее 1го января 2015:


Сжал базу:

Удалив 4 года из 5, базу удалось уменьшить только на 15%.

Собственно возникли вопросы:
1. Правильно ли я делал архивную копию, есть ощущение, что можно было сделать более корректно.
2. Почему база сократилась так незначительно? Это явно какая то ошибка.

[gorkin]

1. Сделали правильно. Но можно проще - в папку utils есть утилита dbutils, где есть пункт Создание архивной БД. Она делает копию базы, а текущую чистит.
2. Скорее всего в последнее время декларанты активно создавали ЭД-картинки, которые занимают большую часть места. Попробуйте почистить документы, оставив за последние 6 месяцев, и поставьте галку где тип документа - оставьте только ЭД-Картинки.

[aiki]

Подниму тему.
Разделение баз на базу с декларациями и базу с ЭД сообщениями помогло на 2 года. База с декларациями достигла 10Гбт. Варианта было 3.
1. Купить SQL
2. Поставить SQL с одного из трекеров )
3. Архивировать старые декларации.

Решил пойти по третьему пути. Большого опыта работы с базами данных нет, есть только общее понимание. Подробного описания процесса не нашел, поэтому делал интуитивно. Сделал бэкап основной базы, создал через SQL Management новую базу Arhiv_1 и попытался восстановить в нее базу из бэкапа. Сразу получил ошибку, поскольку основная база (gtd) и восстанавливаемая база (Arhiv_1) имеют одинаковые файлы.


Два файла подменил на аналогичные от базы Arhiv_1, а третий (ftrow...) создал вручную.


После этого все прошло гладко. Проверил в альте "Просмотр архивной SQL БД", все видно и работает.
Пришло время чистить основную БД. Запустил встроенную процедуру из Альты с параметрами удалить все старее 1го января 2015:


Сжал базу:

Удалив 4 года из 5, базу удалось уменьшить только на 15%.

Собственно возникли вопросы:
1. Правильно ли я делал архивную копию, есть ощущение, что можно было сделать более корректно.
2. Почему база сократилась так незначительно? Это явно какая то ошибка.

Доброго дня. Вы пошли мудреным путем
Для создания архивной БД лучше воспользоваться утилитой DBUTILS (там и другие плюшки есть) Находится на любом месте где установлен продукт Альта-софт в подкаталоге utils. Она значительно упростит вам работу с БД, проста и понятна.

Теперь по поводу объема.
Если вы чистили основную БД с параметрами как на вашем скрине, то видно что не включены множество типов документов. Возможно самые "тяжелые" остались в БД, например ЭД2-картинки.
По уму, надо разобраться что в вашей основной БД кушает больше места и уже смотреть можете ли вы удалить этот тип документов и до каких пределов. Сделать это можно SQL запросом к базе в том же менеджмент студио

SELECT doctyp, sum(convert(bigint,[DOCSIZE])), count(*)

FROM ["имя базы"].[dbo].[Docs]
group by doctyp
order by 2 desc

в выводе получите 3 столбца
1 - тип документов
2 - занимаемый объем в БД типом документов (в байтах. Думаю учить как пересчитывать не стоит )
3 - количество документов в БД конкретным типом

Таким образом, посмотрев на столбец 2, вы поймете какой тип документов в вашей БД занимает больше все места.

[terminalzm]

Не стал создавать новую тему, спрошу тут. Возникла слудующая ситуация:

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

Если подключить эту самую архивную базу в качестве основной, наблюдаем следующую картину:


Из этого всего у меня возникают следующие вопросы:
1)Почему при подключении архивной базы доп. база помечается как "БД испочена!?" при этом количество сообщений в ней вообще не отображается?
2)Если мое предположение о том что появление всех этих "красных" сообщений в доп.базе связано с тем что из основной выгружена часть деклараций в архив верно, можно ли все эти сообщения так же переместить в архивную базу чтобы они там все вместе красиво жили? Если не верно, то откуда они еще могли возникнуть и можно ли их как-то почистить? Кнопочка "исправить" никаких результатов не дала.

[gorkin]

Если место есть лучше не обращать внимания. А если хотите всё-таки подчистить напишем скрипт, но если чего-то потом будет не хватать, мы не виноваты.

[popov]

1)Почему при подключении архивной базы доп. база помечается как "БД испочена!?" при этом количество сообщений в ней вообще не отображается?

Потому что в ней прописано, что она принадлежит раб. БД с именем gtd, а не gtd_archiv1.
Подключать архивные БД как рабочие не предполагается - это неправильно, т.к. в них может пойти ЭД-доставка и пр. неприятности.
Для просмотра архивных БД есть спец. пункт в меню Сервис.

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

Да, кол-во указанное в колонке "мусор" (192 579) - это те самые сообщения, которые были перенесены в архивную БД и соотв-но удалены их заголовки из основной (рабочей) БД - она теперь на них не ссылается и это как бы мусор.
А вот те что в колонке "дубли" (11 545) - это задвоившиеся XML-тела одних и тех же сообщений. Видимо когда-то перенос сообщений оборвали и он не дошел до конца...
В принципе эти "красные" XML-тела никому не мешают и переносить их куда-то после архивации данных основной БД не предполагается опять же. Поскольку чисто технически они при необходимости всегда доступны всем тем пользователям SQL-сервера, которые имеют SQL-доступ к этой доп. БД, независимо от того какая у них БД подключена в кач-ве рабочей/архивной. А гонять туда-сюда большие блобы это только лишняя потеря времени. Предполается, что доп. базы для ЭД должны "умирать" естественным путем - через 3 года после того как в них закончилась запись новых сообщений (см. колонку "Период: ПО"). А "отчеркиваются" эти моменты, путем создания очередной новой доп. БД и направления в нее записи новых сообщений, например, раз в год или как Вам больше нравится...

[terminalzm]

Если место есть лучше не обращать внимания. А если хотите всё-таки подчистить напишем скрипт, но если чего-то потом будет не хватать, мы не виноваты.

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

popov
Спасибо за разъяснения. Вот только в меню "Сервис" пункта для просмотра архивных баз не нашел, не подскажете поконкретнее куда там смотреть?