В силу своего характера никогда не верю написанному. Потому что на заборе может быть написано х.., а там дрова лежат. Я про работу на SQL 1С и требования к оборудованию. Можно разводиться на дорогое железо, слушать басни эсников и производителей железа, проводить тесты Гилева и на выходе получить ноль или заплатить куеву тучу бабла непонятно за что.

Итак стояла задача в 2013 году приобрести сервер для 4х организаций в торговой сети. 5 магазинов и склад. Учет на Торговля и склад 7.7 и это дело выгружать в БП2.0. Прикинув размер базы 7-ки и разрастание базы за год на 1Gb ничего критичного не почувствовал в ближайшее время. Поэтому купили систему на I3 процессоре с 8Gb оперативы. Мать P8Q77-M Lga 1155на 4 планки памяти и поддерживает разгон. Но руководствуясь прошлым опытом я решил поставить зеркалом новомодные в то время SSD. Тогда тормоза SQL упирались в скорость дисков. Мудрые люди уговорили взять SAS. Со скрипом согласился, они мои клиенты, плохого не посоветуют. Контроллер стоил дороже чем системник с потрохами. Диски тоже не отставали по цене. Бухгалтерия предприятия была сразу установлена на SQL Server 2008R2. Ставить операционкой Server 2012 смысла не видел. Windows 8 с небольшой модификацией реестра на открытие файлов и модификации DLL для доступа по RDP нескольких юзеров ничем не отличается. Уж поверьте! Ну и стало это дело благополучно работать. Не тормозило, пока размер базы не перевалил за 10 Gb. Подкинул серваку оперативы и опять вроде нормуль. Потом, наблюдая за проведением документов в диспетчере задач заметил нагрузку на процессор. Купили I7 2600 у китайских друзей почти задаром. И опять бухгалтерия благополучно работала. А вот месяц назад до написания этого материала начались тормоза. Вся нагрузка шла на жесткий диск. Память на мамке предел – 32 Gb. Но в силу ряда причин размер планок памяти стал немного меньше. В оффлайне DDR3 стоит что реактивный самолет. Планки по 8 Gb успешно заказаны у желтопузиков и едут. Но сейчас что-то делать надо. Ради эксперимента запустил базу на SSD. Прироста скорости – ноль. Но SQL сервер его так грузит что пришлось отказаться от этой затеи. Кстати по этой причине у меня два диска вылетели на других машинах. Диски купленные в оффлайне. Китаезные диски купленные за копейки все живы. Это так, отступление. Делайте выводы сами.

Вывод 1. Для SQL сервера достаточно SAS дисков. Это порадовало.

Вывод 2. Для быстрой работы SQL сервера нужна память и есть закономерность размер базы/объем памяти. Какая? ХЕЗ. Дальнейшее наращивание памяти вроде как не ускорит работу (так пишут в инете…)

Вывод 3. Процессор. Здесь странная ситуация. Если хватает памяти и быстрые диски — то чем больше ядер и выше частота, тем лучше. (Странно если бы было наоборот). Но скажем кассовые ордера и банковские выписки грузят процессор сильнее чем приходные накладные, перемещения товаров и отчеты о розничных продажах.

Итак размер базы в 2018 году почти 40Gb. Начинаем исследования.

Если кратко. Я на копии сделал подрезку базы обработкой с созданием документов ввода остатков и удалил записи бухгалтерских регистров и регистров накопления запросом truncate table. Сжал базу и ее размер стал 4 Gb. Но в в августе месяце мне в облом проводить заново документы с начала года. База стала тормозить месяц назад, и выкинув из нее две организации я дотяну до конца года и подрежу по взрослому.

А пока

Проганяю запрос на SQL дабы выявить что занимает более всего места

select

t.name as table_name,

sum(sz.used_page_count*8) used_size,

sum(sz.reserved_page_count*8) reserved_size,

max(sz.row_count) row_count

from

sys.dm_db_partition_stats sz

inner join sys.tables t on t.object_id = sz.object_id

group by t.name

order by reserved_size desc

Итак видно что это регистры бухгалтерии. Кто-б сомневался! А конкретно

Ага. И в них реквизит организация.

Грохну я для начала две ненужные организации у меня в базе. Начну с регистров. Нет записей регистров – нет проблем документы моментально ставятся на удаление.

Осталось посмотреть идентификаторы, что кому принадлежит

Здесь понятно, идентификатор организации в виде двоичного кода

Мне нужно грохнуть организации с кодами

0x91ABEF95F76A2D0442764BC09100A7B5

0xA163C48C77C3E934460746C72267C993

Пишем запрос

DELETE FROM _AccRgAT37950

WHERE _Fld7917RRef=0xA163C48C77C3E934460746C72267C993;

Перекрестились и нажали Выполнить. Запрос делал на базе которую подрезаю

На мастере выглядит так

DELETE FROM [Account].[dbo].[_AccRg7916]

WHERE _Fld7917RRef=0x91ABEF95F76A2D0442764BC09100A7B5;

GO

GO! – это хорошо! Кстати если хотите грохнуть всю таблицу, то здесь все просто и быстро произойдет

truncate table _ AccRgAT37950 Это делать не рекомендую! Помните как говорил Доцент в Джентельменах удачи: — Опомнитесь! Пока не поздно, опомнитесь!

На крайняк сделайте бэкап.

И далее дело техники

DELETE FROM _AccRg7916

WHERE _Fld7917RRef=0xA163C48C77C3E934460746C72267C993;

И соответствено на другую организацию делаем.

DELETE FROM _AccRgAT37950

WHERE _Fld7917RRef=0x91ABEF95F76A2D0442764BC09100A7B5;

и

DELETE FROM _AccRg7916

WHERE _Fld7917RRef=0x91ABEF95F76A2D0442764BC09100A7B5;

Короче я удаляю на всех бухгалтерских регистрах

Далее хотел грохнуть

Теперь грохнем отчеты о розничных продажах (они много места занимают)

И поступления товаров и услуг

Зачем мелочиться!

А может грохнуть организацию и проверить базу на ошибки? По логике эска в таблицах скуля поудалять должна строки.

Как говаривал Брекодкин из Уральских пельменей: — И что, просто так Delete? Ликвидировать профессора и обеспечить круглосуточную охрану розетки.

Все верно, нужно только было грохнуть организацию.

Сработало!

Однако очень долго конфигуратор висел

Нужно было регистр первичных документов почистить.

Теперь сжатие базы

А после Нового года сверну базу документами, поудаляю записи в регистрах, проведу документы ввода остатков. А может сверну штатной обработкой от 1С. Пока не решил. Как правильно будет формироваться оборотно-сальдовая ведомость после подрезки – на том варианте и остановлюсь.

PS

При подрезке применял обработки с инфостарта. Некоторые из них модифицировал под свои нужды. Позднее выложу их здесь. Если встретите что-то свое, не обижайтесь.

Эсники не были бы эсниками, если бы не навязывали свой агрессивный маркетинг. В БП 3.0 реализован нормальный механизм подрезки Документом корректировки регистров. Мда… Хотя регистры я корректировал еще в 7-ке, потом в УТ-10. Единственнное — запрет на дату ставить чтоб не слетело от действий безумного юзера.