1с sql сжать базу

Обновлено: 02.07.2024

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

Проблема размера базы эффективно решается сверткой базы 1С. При этом все старые документы в базе 1С удаляются, а вместо них создаются документы «Ввод начальных остатков».

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

Существует несколько простых способов, которые помогут поддерживать базу 1С в разумных размерах, не прибегая к свертке базы:

Настройка автоматического удаление помеченных на удаление объектов.
Настройка и сокращение журнала регистрации базы 1С.
Сжатие базы 1С в случаях, когда база 1С файловая.

Рассмотрим указанные способы подробнее:

1. Настройка автоматического удаления помеченных на удаление объектов

Со временем в базе 1С накапливаются помеченные на удаление объекты. Эти объекты физически занимают некоторую объема базы 1С.

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

Рассмотрим настройку автоматического удаления помеченных на удаление объектов на примере конфигурации 1С: Управление Торговлей:

1. Перейдите на закладку «НСИ и Администрирование» и выберите «Обслуживание»:

2. Откроется окно «Обслуживание». В окне выберите «Удаление помеченных объектов»:

3. Откроется окно «Удаление помеченных объектов». В окне установите флажок «Автоматически удалять помеченные объекты по расписанию»

4. Откроется окно «Расписание». В окне на закладке «Общие», укажите как часто нужно запускать удаление помеченных объектов. Каждый день или, например, каждые 7 дней (1 раз в неделю):

5. Затем в окне «Расписание» перейдите на закладку «Дневное» и укажите желаемое время, когда должно запускаться удаление помеченных объектов. Например, начало с 4:00 до 4:15, завершать после 6:00:

ВАЖНО! Если база 1С файловая, то автоматическое удаление помеченных объектов сможет запускаться только, когда база открыта у одного из пользователей. В этом случае расписание нужно устанавливать так, чтобы автоматическое удаление запускалось в рабочее время, например, в начале или в конце рабочего дня.

6. Когда расписание настроено. В окне «Расписание» нажмите «Ок», затем закройте окно «Удаление помеченных объектов»:

7. Готово. Автоматическое удаление помеченных на удаление объектов в базе 1С настроено.

2. Настройка и сокращение журнала регистрации базы 1С

В журнале регистрации базы 1С хранится информация о действиях, которые совершаются в базе 1С. В журнал записывается какие пользователи входили в 1С, какие объекты меняли и т.д.

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

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

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

1. Запустите Вашу базу 1С в режиме «Конфигуратор»:

2. В конфигураторе перейдите на закладку «Администрирование» и выберите «Настройка журнала регистрации»

3. Откроется окно «Настройка журнала регистрации». В окне в поле «Регистрировать в журнале события» настраивается уровень детализации журнала:

Обычно в поле установлен флажок «Регистрировать ошибки, предупреждения, информацию, примечания», что означает максимальный уровень детализации журнала:

Если в Вашей базе 1С журнал регистрации увеличивается в размерах очень быстро, то можно уменьшить уровень детализации журнала установив флажок «Регистрировать ошибки, предупреждения, информацию» или «Регистрировать ошибки, предупреждения»:

Устанавливать флажок «Не регистрировать» или «Регистрировать ошибки» НЕ рекомендуется, т.к. в этом случае, при возникновении проблем с базой 1С, специалистам будет сложнее разобраться в причинах ошибки.

4. В окне «Настройка журнала регистрации» нажмите кнопку «Сократить»:

5. Откроется окно «Сократить журнал регистрации». В окне в поле «Удалить события до» укажите дату, до которой нужно удались старые записи журнала. Обычно указывают начало этого или прошлого месяца. Затем нажмите кнопку «ОК»:

6. Откроется окно с вопросом. В окне нажмите кнопку «Да»:

7. Начнется удаление старых записей журнала регистрации. Удаление может занять некоторое время. Когда удаление записей завершится, окна «Сократить журнал регистрации» закроется автоматически. Закройте окно «Настройка журнала регистрации»:

8. Готово. Журнал регистрации базы 1С настроен и сокращен.

3. Сжатие файловой базы 1С

База 1С может храниться на жестком диске компьютера в обычном виде и в сжатом виде. В сжатом виде база 1С занимает значительно меньше места. Сжатая база может занимать более чем в 2 раза меньше места.

Если база 1С серверная, то за сжатие базы 1С отвечает сервер (sql или другой). При правильной настройке сервера база 1С всегда находится в сжатом виде и дополнительных действия со стороны пользователя не требуется.

Если же база 1С файловая, то рекомендуется периодически вручную проводить сжатие базы. Так база 1С будет занимать меньше места и будет работать быстрее, за счет оптимизированного размещения всех компонентов базы.

ВАЖНО! Описанный способ сжатия базы 1С подходит только для случаев, когда база 1С файловая. Если база 1С серверная, то, чтобы настроить сжатие базы, нужно обратиться к системному администратору.

Для того, чтобы сжать файловую базу 1С, нужно выполнить следующие действия:

1. Закройте базу 1С на всех компьютерах, если она где-то открыта.

2. Запустите Вашу базу 1С в режиме «Конфигуратор»:

3. В конфигураторе перейдите на закладку «Администрирование» и нажмите кнопку «Тестирование и исправление»:

4. Откроется окно с вопросом. В окне нажмите кнопку «Продолжить»:

5. Откроется окно «Тестирование и исправление информационной базы». В окне в списке «Таблицы и режимы» установите только один флажок «Сжатие таблиц информационной базы» и нажмите кнопку «Выполнить»:

ВАЖНО! Следует убедиться, что установлен только флажок «Сжатие таблиц информационной базы». Все остальные флажки в списке «Таблицы и режимы» должны быть сняты. Неправильная их установка может привести к проблемам с базой 1С.

Если база 1С большая, то сжатие таблиц может выполняться довольно долго. При необходимости, Вы в окне можете установить флажок «Прервать выполнение проверки через» и указать, когда следует прекратить сжатие таблиц:

Если до установленного времени сжатие базы не успеет выполниться, оно автоматически завершится, и Вы сможете продолжить работу в 1С.

Шринк (shrink) - это сжатие файлов данных для уменьшения занимаемого ими пространства на диске. Выполняется за счет перемещения страниц данных с конца файла в свободное пространство в начало файла. После этого страницы в конце файла становятся неиспользованными и это пространство может быть возвращено файловой системе.

Стоит различать сжатие файла данных (shrink) со сжатием строк и страниц для таблиц и индексов.

Также есть шринк лога транзакций, но он также не совсем относится к теме статьи.

В стародавние времена считалось нормальным выполнять шринк базы данных. Некоторые администраторы даже настраивали регламентные процедуры для "шринкования" вне рабочего времени. К счастью, такое уже редко где можно увидеть, но случаи еще есть.

Почему шринк не стоит делать регулярно на рабочем окружении? Вот основные причины:

Сама по себе операция сжатия файла данных очень ресурсоемка и на больших базах может выполняться десятки часов, а то и больше. Также во время ее выполнения пользователи могут, и скорее всего будут, ощущать замедление работы системы.
Значительное снижение эффективности работы индексов. Шринк переносит страницы в начало файла, так он может перенести и индекс. Причем часть его страниц может быть в самом начале файла, другая где-то по середине, а третья вообще разбросана где попало. В итоге фрагментация индекса будет под 99.9%, что значительно снижает производительность. Индексы попросту не могут быть использованы должным образом. Спасти может только перестроение или реорганизация (иногда), но это снова может увеличит размер файла данных. Есть отличная статья об этом от Brent Ozar.
Появление дополнительных задержек при увеличении файла данных. После шринка база занимает минимальный размер, но если информационная система жива, то новые данные в нее будут поступать снова и снова. Новые данные = нужно больше места. Каждое увеличение файла данных потребует дополнительных ресурсов. Оптимизировать можно уменьшив количество таких операций за счет большего шага автоувеличения файла в настройках базы данных. О влиянии на производительность можно узнать вооооот здесь.

Постойте! Но статья же о быстром шринке! Если сам по себе он так плох, то неужели статью можно уже закончить?

Конечно, нет! Бывают ситуации, когда шринк для базы целесообразен. Замете, целесообразен, но не обязателен!

Вот несколько кейсов, когда его стоит использовать:

В базе данных произошли серьезные изменения. Например, вы удалили какой-либо исторический регистр из базы 1С, который занимал 100 ГБ. И если эти 100 ГБ важны и их нужно освободить на диске, то от шринка не уйти.
Вы применили сжатие страниц для таблиц и индексов, что уменьшило размер занимаемых данных на 70%! А файл базы данных на диске не изменился! Снова шринк! Но опять же, если место и правда нужно под что-то освободить, ведь рано или поздно данные в базе смогут занять его снова.
Вы готовите тестовую базу и удаляете из нее данные, чтобы она не весила 1ТБ. Без шринка тоже никуда, но вопрос производительности может быть неактуальным. Ведь это тестовая среда.

Вообщем, смысл думаю уже понятен.

Классический путь

Стандартный способ выполнить шринк файлов базы данных - воспользоваться такими командами как "SHRINKDATABASE" или "SHRINKFILE". Вот примеры.

Разница между ними заключается лишь в том, что "SHRINKDATABASE" сжимает все файлы данных и журналы транзакций для указанной базы, а "SHRINKFILE" применяет изменения только для указанного файла.

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

Также для каждой операции могут быть указаны дополнительные параметры, о который вы можете узнать по ссылкам:"SHRINKDATABASE" или "SHRINKFILE".

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

Ах да, ни в коем случае не ставьте в настройках базы данных включенной опцию "Auto Shrink".

Все еще сомневаетесь? Прочитайте перевод статьи от разработчика Microsoft, который имел прямое отношение к алгоритму сжатия файлов.

Быстрее, выше, сильнее

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

Речь идет о переносе данных из одной файловой группы в другую, при котором есть два пути:

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

На сколько перемещение данных в новую файловую группу быстрее, чем стандартный шринк? Трудно сказать, т.к это зависит от дисковой подсистемы, где находятся файловые группы, а также от объема BLOB-данных в базе. Как показала практика, чем больше таких данных хранится, тем медленнее выполняется шринк, тем быстрее будет работать сжатие через файловые группы.

На моем опыте использование этого подхода позволяло ускорить сжатие файла данных от 3 до 8 раз, да и последствий для производительности куда меньше.

Как это сделать для баз 1С? Допустим, у нас есть некоторая база "bsl" на инстансе SQL Server и мы решили ее сжать через файловые группы. Т.к. файловая группа по умолчанию только одна, то нужно добавить еще одну дополнительную и файл данных для нее.

Теперь с помощью этих скриптов мы можем переместить все таблицы, индексы и даже BLOB-данные в эту файловую группу вот так.

Скрипт не универсальный, по крайней мере в текущей его версии, и не может перенести таблицы, в которых, например, только одно поле с BLOB-типом. Для баз 1С это таблица "DBSchema" с описанием структуры базы данных, которую автоматически в новую файловую группу переместить нельзя. Для этого нужно выполнить немного ручной работы:

Так как файловую группу "PRIMARY" удалить нельзя, то мы можем ее сжать через стандартный шринк. Это уже будет работать гораздо быстрее, чем выполнение этой операции до переноса данных.

В итоге все данные перемещены в новую файловую группу, что можно проверить с помощью этого скрипта.

По ссылке выше в своей статье Paul S. Randal этот способ рекомендовал использовать вместо стандартного сжатия данных. Так почему бы не прислушаться? Если бы исходную файловую группу можно было бы удалить (если это не "PRIMARY"), то можно было бы сделать следующее.

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

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

База в базу

Можно пойти дальше и переносить данные не в новые файловые группы, а в новую базу данных. Довольно радикальный способ, но работоспособный. Можно выделить несколько основных способов перемещения таблиц и индексов между базами:

Использовать Bulk-операции, как, например, описано здесь.
Штатный мастер импорта и экспорта данных
Использовать утилиту "sqlpackage.exe", входящую в состав SQL Server Data Tools.
Сгенерировать скрипт с помощью SQL Server Managment Studio
Использовать операцию "INSERT INTO".

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

Вы все еще шринкуете?

На этом все. Думаю, в публикации не открыл особо ничего нового для сообщества, но может хотя бы скрипты пригодятся. Главное помнить - шринку нет места в продакшене! Хватит шринковать! :)

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

Для выключения сжатия надо запустить скрипт, заменив в нем DATA_COMPRESSION = PAGE на DATA_COMPRESSION = NONE

Специальные предложения

Описание способа включения сжатия выглядит как рекомендация. Это так?
При этом не указано, сколько % места это экономит и сколько % нагрузки добавляет.
ИМХО место на дисках стоит условно дешевле, чем процессоры. При этом диски можно докупать разной ценовой категории под разные потребности. (1) ознакомился с темой подробнее. Вопросы сняты. Крайне заинтригован отзывами. Побежал тестировать сжатие ))) (3) тесты прекрасны. Сжатие порой существенно - на порядок.
При этом чтение ускоряется в 2-3 раза точно.
А вот с записью все грустно. Замедляется раз в 10.
Для хранения например журналов, истории чего либо, с ассинхронной записью в таблицы - само то.
За использование сжатия и синхронной записи - расстрел на месте))) (15) >А вот с записью все грустно. Замедляется раз в 10.
не было дефицита процессора? у меня запись, конечно, замедлилась, но не настолько. Восстановление из .dt в два-три раза дольше стало. (16) Антон, тесты я точно не в 1с проводил )))
Точно уже не вспомню условия теста, но делал его на своем ноуте (i5, ssd). Операция - insert в таблицу1 и в таблицу2.
Примерно аналогичное замедление(+/-) получил на рабочем сервере. (17) а, я думал что как минимум что-то типа перепроведения всех документов за период было. (18) нееее )))))))) ну это же бред ))))
Влияние размывается на тысячи аспектов. Какой удельный вес замедления записи в общей операции - одному богу известно. Наиболее точная оценка от 10% до 90% )) (19) ИМХО мерить синтетикой в наших условиях - не совсем то. Самое правильное - тест центр, правда его настраивать задолбаешься :)
Перепроведение хотя бы к реальности ближе. (20) вообще не понимаю что вы собираетесь мерить, даже ТЦ. И что вам это даст?
Я попытался измерить технологию. Очень приближенно и усредненно. Технология не имеет никакого отношения к 1с. Однако полученный результат все же зависит от состава данных, не спорю.
Производить какие-то замеры в 1с бессмыслица и дилетантство. Одно поведение - 90% дискового времени, другое - 10%. Куда деть процессорное время, ожидания и т.п. чтобы понять чистое влияние сжатия СУБД?
Важно в принципе понимать это чистое поведение, чтобы оценить области его применения. И возможно ли хоть где-то его в 1с применять.
Да. Но, например, на ssd обновление строки в СУБД занимает перезапись всего 4кб сектора, что со сжатием, что без сжатия. Таким образом запись больше упирается в процессор. На hdd немного по другому, и при обновлении одной строки действительно нужно читать и писать намного больше данных. + профиль нагрузки, создаваемый 1с действительно очень разнообразный. Для розницы с десятком касс - один, для финансистов с аналитическими отчетами в центральной управленческой базе, в которую оперативные данные сливаются по обменам - совсем другой. Даже сами алгоритмы проведения разные по соотношению чтения/записи. По этому я и говорю, что нужно моделировать именно на конкретном оборудовании с конкретным профилем нагрузки. Более-менее неплохо с этим справляется как раз тест центр от 1с, но он очень долго настраивается. А синтетические тесты - зло. Вот в моем случае пользователи даже не заметили ничего, да и показатели апдекс не поплыли. Скрипт отработал, но ничего не изменилось, размер базы не изменился. До запуска 19,9гб, после 19,9Гб. В чем может быть пролема? Делал для отдельной таблицы
ALTER TABLE [dbo].[TestTable] REBUILD PARTITION = ALL
WITH (DATA_COMPRESSION = PAGE)
Результата тоже нет.
sp_estimate_data_compression_savings расчитывала сжатие, почему его нет после выполнения скрипта? (4)Сжатие данных в базе (Сжатие базы) и сжатие файлов базы данных - две большие разницы. И первое не обязывает сервер делать второе. (5) Из описания к статье "основным плюсом идет экономия ввода вывода и места на диске". Я так понимаю сжатие базы необходимо делать отдельно? (6)Термин "Сжатие базы" некорректный.
Есть сжатие данных и сжатие файлов.
Первое описано в публикации.
Второе нужно делать только по необходимости. И ни в коем случае не на регулярной основе. И да, отдельно.

(0)То же самое, но без курсоров и кучи переменных:
DECLARE @cmd VARCHAR(MAX)

sel ect @cmd =(
SELECT
'PRINT '''+Table_catalog + '.' + Table_schema + '.' + Table_name+ ''''+CHAR(10) +
'ALT ER TABLE [' + Table_catalog + '].[' + Table_schema + '].[' + Table_name + '] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)'
+';'+char(10)
as "data()"
FR OM
INFORMATION_SCHEMA.TABLES WH ERE TABLE_TYPE = 'BASE TABLE'
ORDER BY Table_catalog, Table_schema, Table_name
for xml path('')
)

Exec(@cmd)
--Print @cmd

SELECT @cmd =(
SELECT
'PRINT '''+DB_NAME() + '.' + sch.name + '.' + tabl.name + '.' + ind.name + ''''+CHAR(10) +
'ALT ER INDEX [' + ind.name + '] ON [' + DB_NAME() + '].[' + sch.name + '].[' + tabl.name + '] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)'
+';'+char(10) as "data()"
FR OM
sys.schemas as sch
inner join sys.tables as tabl on sch.schema_id = tabl.schema_id
inner join sys.indexes as ind on tabl.object_id = ind.object_id
ORDER BY sch.name, tabl.name, ind.name
for xml path('')
)

Exec(@cmd)
--Print @cmd

Не забудьте убрать лишние пробелы, которые вставляет движок форума.

(9) неплохо, не знал, что exec работает не только со строками, но и с таблицами. (10)Ну здрасте! И где вы там таблицы нашли? :) А закомментированные Print по вашему мнению тоже таблицы выводят? :)

(11) ну условно если этот select просто выполнить, то результатом будет таблица

EXEC sp_MSforeachtable 'ALTER TABLE ? REBUILD WITH (DATA_COMPRESSION = PAGE)'
EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE)'

Может кто подскажет при попытке сжатия базы скриптом выдается ошибка:
Внутренняя ошибка. Буфер, предоставленный для считывания значения столбца, слишком мал.
База конечно не маленькая но может кто в курсе как можно победить ошибку Буфер, предоставленный для считывания значения столбца, слишком мал

Большая таблица и мало памяти? По английски есть текст ошибки?

(26) Таблицы большие база размером 250 гиг по английски ошибки нет пишет только на русском (29) Ну так это первым делом и надо сделать. А потом уже дальше смотреть. (30) ну так это я сделал и уже дважды а что толку не каких ошибок не обнаружено и все равно ошибка та же выдается

Это одна из тех технологий, которую нельзя применять бездумно. Первое что стоит сделать - снять статистику по объектам базы данных, а именно по чтению и записи. Если какая-нибудь таблица меняется чаще чем читается, или поровну, то включать сжатие не следует. Если четко видно, что таблица в основном читается, чем пишется, скажем в 80% случаях, то можно и включить.

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

для определения соотношения чтения/записи, но даже если запись осуществляется в 10 раз чаще, профит от сжатия может быть. Нужно тетсить. Как правило все равно процессора больше, чем диска.

(33) Т.к. форум "ломает" запрос прикреплю его в виде файла, если не возражаете.

С удивлением обнаружил, что таблица _Reference183 (Справочник.ИдентификаторыОбъектовМетаданных) читается чаще всех после регистра накопления ПрочиеРасходыНезавершенногоПроизводства, и при этом туда 0 записей. RLS похоже.

В целом общая статистика по моей базе говорит, что чтений конечно больше. Причем видно, что конфигурацией читаются объекты, которые в принципе не содержат документов вообще. Тем не менее, табличку она "дергает".

скрипт не учитывает специфику 1с : некоторые данные сжимаются deflate . смысла сжимать такие таблицы нет. (35) посмотреть эффект можно с помощью sp_estimate_data_compression_savings По идее если мы не отбираем таблицы с разными типами индексов и не задействуем параметры типа on line = on\off все выборки списка таблиц и индексов можно заменить парой строк
EXEC sp_MSforeachtable 'ALT ER TABLE ? REBUILD WITH (DATA_COMPRESSION = PAGE, MAXDOP = N)'
EXEC sp_MSforeachtable 'ALT ER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE, MAXDOP = N)'
А если вы счастливый обладатель 2017 MSSQL то можно указать явно RESUMABLE = ON
И после шринка обязательно запустить обслуживание индексов, т.к. операция сжатия полностью фрагментирует индекс День добрый, а может подскажете как расчитать оборудование для базы размером в 1.7тб и в 2500 пользователей? потому что как только начинаю делать сжатие так сразу по cpu проседать начинаю Может кому не лень упростит скрипт при помощи которого смогу сжать данные в конкретной таблице.

Написал вот так, синтаксис прошёл, табличка лопатится. как отлопатит напишу, она большая а тестовый сервак не самый мощный.
ALTER TABLE [upp_3].[dbo].[_AccumRg24455] Rebuild partition = all with (data_compression = page)

Опережая вопросы опишу цель: на сервере начало заканчиваться место, путём анализа было выяснено что много файлов хранится в базе. Для выноса их из базы на хранилку сделана доработка требующая реструктуризации таблицы с файлами, этой сцуко большой . при реструктуризации требуется свободное место равное лучше больше этой таблицы а его нет, вот и хочу пожать 3-5 самых больших таблиц у которых статистика в пользу чтения а не записи и мне хватит места на реструктуризацию, выброс файлов на ружу и освобождение места на SQL диске для данных.

Просмотры 19025

Загрузки 0

Рейтинг 27

Создание 27.10.17 12:36

Обновление 13.12.17 16:10

№ Публикации 692209

Тип файла Нет файла

Конфигурация Не имеет значения

Операционная система MS SQL

Вид учета Не имеет значения

Доступ к файлу Бесплатно (free)

Код открыт Да

См. также

Диспетчер Хранилища Запросов в SQL Server 2016+ (он же Query Store) Промо

Если вы используете SQL Server 2016 или более позднюю версию, то у вас есть возможность использовать встроенную систему мониторинга, которая позволяет отслеживать самые базовые метрики выполняемых запросов и статистику ожиданий (потребления ресурсов). Эта информация позволяет быстро получить самые ресурсоемкие запросы с их планами и агрегированной статистикой выполнения.

26.04.2019 14043 Aleksey.Bochkov 7

Инструкция по получению плана запроса через Extended Events

Доброго времени суток, коллеги. Хочу рассказать, как можно посмотреть план запроса через механизм Extended Events. Я хочу ответить на вопрос - как разработчику через SQL Management Studio посмотреть, что запрос, который он сделал, работает оптимально. На Инфостарте есть несколько статей, которые посвящены трассировкам в этом механизме. Мне, когда я не понимал, как это правильно делать, не хватало простой пошаговой инструкции. Я напишу инструкцию, выполняя которую можно будет увидеть план запроса, который выполняется из базы данных.

вчера в 07:00 167 Andrei_Ivanov 0

Подходы к организации информационной безопасности в корпоративных проектах

Оформили в виде статьи наш доклад на недавно прошедшем семинаре партнеров 1С на тему требований к информационной безопасности на проектах, с которыми всё чаще встречаемся мы и наши партнеры. В статье рассмотрено, почему этими вопросами стоит озаботиться уже сейчас. Куда бежать и что делать, если вы попали на проект с требованиями по информационной безопасности…

29.10.2021 1775 it-expertise 11

Повышение производительности веб-сервисов. Переиспользование сеансов

Повышение производительности веб-сервисов. Переиспользование сеансов. Практическая реализация.

20.10.2021 1573 sorter1 2

Опыт миграции из собственного датацентра в облако AWS Промо

29.07.2018 12263 Aleksey.Bochkov 9

Смотрим запросы 1С через Microsoft SQL Profiler по следам ошибок разработчиков, приводящих к проблемам производительности

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

07.09.2021 4018 ivanov660 23

Показатель Page Life Expectancy (PLE)

18.08.2021 1429 vasilev2015 6

Кластер для отказоустойчивости

На Infostart Meetup «PostgreSQL VS Microsoft SQL» выступил руководитель проектов в по разработке ПО в компании «Газинформсервис» Денис Рожков. В рамках доклада Денис рассказал о том, какие механизмы кластеризации используются для PostgreSQL и в MS SQL и поделился с коллегами, какие решения можно использовать для построения отказоустойчивого кластера на PostgreSQL.

18.08.2021 2581 FB_3393521717335803 0

Опыт оптимизации и контроля производительности в БД с 3000 пользователей Промо

Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года. Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии". Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность. Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры. **update от 04.03.2016 по вопросам из комментариев

05.08.2015 67198 Sergey.Noskov 119

Адекватный параллелизм в 1С

Параллелизм ускоряет выполнение тяжелых регламентных операций на СУБД, но может негативно влиять на работу многопользовательских учетных систем. О том, как анализировать влияние параллелизма и настраивать его для MS SQL и PostgreSQL, рассказал ведущий разработчик компании ООО МКК «Ваш Инвестор» Вадим Фоминых.

13.08.2021 3455 Shmell 7

Создаем счетчики производительности Windows для 1С

В статье описан подход, позволяющий создавать счетчики производительности Windows для 1С:Предприятие.

09.08.2021 3570 blackhole321 8

Распространенные ошибки разработчиков, приводящие к проблемам производительности

Рассмотрим примеры ошибок, анализ, исправление и мероприятия по недопущению подобного в будущем. Всего будет 18 примеров.

02.08.2021 9377 ivanov660 77

Долго открывается конфигуратор Промо

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015 43992 Gilev.Vyacheslav 1

Fill factor

02.08.2021 2646 vasilev2015 6

Parameter sniffing и генерация планов для разработчиков 1С

Особенности генерации планов запросов. Статья написана по мотивам вебинара Виктора Богачева.

01.06.2021 8929 vasilev2015 17

Ускорение реструктуризации больших таблиц. Мой вариант

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

28.04.2021 1314 buganov 0

Видеодемонстрация применения Теста-центра для нагрузочного тестирования конфигураций Промо

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

16.09.2012 36452 Aleksey.Bochkov 29

Поиск причин блокировок СУБД

Расследование блокировок СУБД. Статья написана по мотивам вебинара Виктора Богачева.

28.04.2021 5709 vasilev2015 13

Тонкости эксплуатации, плюшки и особенности Postgres Pro Enterprise

В ходе онлайн-встречи INFOSTART MEETUP Novosibirsk Руководитель ИТ из компании ИнфоСофт Антон Дорошкевич поделился с коллегами тонкостями и опытом работы с Postgresql для 1С.

22.04.2021 2412 a.doroshkevich 4

Решение нестандартных проблем производительности на реальных примерах

На екатеринбургском Infostart Meetup выступил с докладом архитектор ИС центра разработки ФТО Александр Криулин. Он поделился с коллегами кейсами нестандартных проблем производительности и рассказал о способах их решения.

24.03.2021 4981 AlexKriulin 37

Сжатие баз данных 1С:Предприятие в MS SQL Server Промо

Тема сжатия баз данных 1С в настоящий момент довольно часто обсуждается. Достоинства сжатия известны – уменьшение размера базы данных, уменьшение нагрузки на дисковую подсистему и некоторое ускорение выполнения тяжелых операций чтения/записи. Из недостатков – небольшое увеличение нагрузки на процессоры сервера СУБД за счет расхода ресурсов на компрессию/декомпрессию данных. Но при использовании в качестве MSSQL и DB2 (за Oracle и PostgreSQL не скажу, т.к. не знаю) есть один «подводный камень» - при выполнении реструктуризации происходит декомпрессия новых таблиц и индексов. Происходить это может как при выполнении обновления конфигурации с изменением структуры метаданных, так и при выполнении тестирования и исправления ИБ (реиндексация пересоздает только индексы, а реструктуризация – и таблицы, и индексы). «Проблема» кроется в том, что признак сжатия устанавливается индивидуально для каждой таблицы и индекса.

Подсистема работает в конфигурациях 8.2 и 8.3 в толстом, тонком и WEB -клиенте (обычные и управляемые формы). Сейчас сложилась парадоксальная ситуация. Есть конфигурации, которые используют обычные формы, есть которые работают на управляемых формах, а также есть те, которые работают и так, и так. Наша подсистема позволяет работать в любом режиме, причем если будет запущена в толстом клиенте, то будет интерфейс и формы толстого клиента, если в тонком или WEB, то на управляемых формах. При этом практически не будет никакой разницы с точки зрения функциональности.

Регистрируются изменения для следующих видов объектов: константы, справочники, документы, планы видов характеристик, планы счетов, планы видов расчета, бизнес-процессы, задачи и регистры сведений.

Для хранения истории изменений объектов используется внешняя информационная база 1 C «Хранитель журнала регистрации». Был выбран именно механизм внешнего хранения изменений, т.к. он не влияет на размер основной информационной базы 1 C , а работа напрямую с внешней базой данный позволяет быстро производить чтение и запись событий.

Алгоритм работы подсистемы такой: при произведении изменения объекта, полный образ изменённого объекта попадает в так называемый «кэш журнала регистрации» – справочник в подсистеме, в который попадают все данные по измененным объектам. Затем, фоновое задание запускает перенос данных из кэша во внешнюю базу данных хранителя, данные просто переносятся из кэша. Далее в информационной базе хранителя происходит определение изменений. Что это значит? Приведем пример. Допустим пользователь «А» создал номенклатуру, заполнил ее и сохранил. Затем пользователь «Б» через время открыл ее и изменил в ней один реквизит, после чего также сохранил. При этом наша подсистема позволит Вам увидеть, как то, что пользователь «Б» изменил без показа всех остальных реквизитов, табличных частей и т.д., так и полные образы объектов. Это позволяет точно сказать, что было изменено пользователем, а что нет. Удобно, не правда ли?

При просмотре истории данные по изменениям подгружаются из внешней базы хранителя и из кэша. Причем данные, которые находятся в кэше в журнале «подсвечиваются» темно-красным цветом , данные которые находятся в базе хранителя и не определены изменения отображаются светло-серым цветом , а данные которые обработаны обычным черным цветом. Как уже было сказано ранее, данные в кэше содержат полный образ объекта на момент изменения объекта (содержат все реквизиты, все табличные части, все предопределённые реквизиты), а в хранителе хранятся те же полные образы, но уже с определением изменений, т.е. как было и как стало.

После переноса «сжатых» данных из кэша в базу данных хранителя, изменения в кэше удаляются. Таким образом, общий размер информационной базы остается практически неизменным.

Читайте также: