В современных условиях очень странно бывает иногда слышать "нам нужно свернуть БД 1С — её объём превышает 50 ГБ". Если бы такое собирались сделать администраторы систем SAP R3 или Oracle e Business Suite или даже MS Dynamics Ax их бы наверное уволили. Тем не менее, для 1С это является "стандартной практикой".
I) Проблемы, которые мы пытаемся решать сверткой БД
1) Увеличение размера БД
2) Низкая производительность выполнения запросов
3) Большой объём «ненужных данных» которые мешают работе пользователей
II) «Технологические» решения проблем
1) Проблема увеличения размера БД
а) Разделение БД на файловые группы
б) Размещение БД или её части на сетевом диске
в) Сжатие таблиц БД
г) Секционирование таблиц БД
2) Проблема низкой производительности запросов
3) Проблема большого объёма «ненужных данных», которые мешают работе пользователей
В современных условиях очень странно бывает иногда слышать «нам нужно свернуть БД 1С — её объём превышает 50 ГБ». Если бы такое собирались сделать администраторы систем SAP R3 или Oracle e Business Suite или даже MS Dynamics Ax их бы наверное уволили. Тем не менее, для 1С это является «стандартной практикой».
Для файловых версий история тянется ещё с версии 1С 7.7 с ограничением в 2ГБ на размер базы. Сейчас ограничение 2ГБ уже только на размер таблицы, размер файла уже может получиться очень и очень не маленьким. Правда если база у вас выросла до такого размера, то наверное туда активно вносились данные — может нужно задуматься о клиент-сервере?
Собственно целью данной статьи является «отговорить» от выполнения свертки БД пользователей клиент-серверного варианта 1С, за счет использования несколько более «продвинутых» технологий.
I) Проблемы, которые мы пытаемся решать сверткой БД
1) Увеличение размера БД
Собственно главный вопрос: а для чего уменьшать размер БД?
Давайте приложим немного математики:
Серверный жесткий диск на 500 ГБ стоит около 10 т.р. Объединить в RAID 1 для надежности будет 20 т.р.
Естественно могут быть проблемы отсутствия места под новые жесткие диски в самом сервере…
А покупка внешнего дискового массива уже обойдётся не так дешево. Что же делать?
Да всё просто — разместить файлы БД на сетевом диске, а как? Ну об этом статье далее.
Увеличение доступного для БД дискового пространства обойдётся нам в 20 т.р. + 10 минут работы специалиста. Сколько часов работы специалиста потребует свертка БД? А сколько времени простоя может получиться? По самым скромным оценкам за свертку УПП объемом гигабайт в 60, со средним количеством ошибок, партионным учетом с проверкой результатов свертки, выправления этого же партионного учета возьмутся тысяч за 30-40.
Универсальной обработкой всё и сразу вряд ли свернётся, особенно если у вас база практически «никогда не останавливается». Партионный учет в любом случае выправлять. Вообщем много там работы. А самое главное, что итоговая проверка должна быть очень тщательной, и всё равно останутся ошибки…
Кроме того, если база уже размером не 60 а, к примеру, 120 ГБ… малейшая ошибка в коде 1С при свертке и всё… процедура заканчивается не удачно. А ошибки точно будут. Как «недостаточно памяти» при работе с ТЗ, так и ошибки вроде
http://img180.imageshack.us/img180/656/1c3y.jpg
Итоговая цифра получается 30-40 т. минимум против 20-25 в случае покупки жесткого диска, и получения 500 ГБ дополнительного места
Поэтому появляются продукты вроде //infostart.ru:8080/public/78934/
Хорошие наверное продукты, и цели свои выполняют. Вот только меняется структура таблиц от версии к версии платформы. 1С нам об этом не раз говорили. Появился разделитель данных в 14-ом релизе и всё… скорее всего эта обработка для 14 релиза уже не подойдёт. Да и страшно как-то, не говоря уже о нарушении лицензионного соглашения.
И даже после этого найдутся пользователи которым «вдруг неожиданно понадобились» стертые данные, которые «как раз хотели поправить» каку-то циферку, которая «не влияет на последовательнсти» в документе закрытого периода. А хуже если выяснится что кто-то эти документы смотрел постоянно для каких-то только ему ведомых целей. Конечно это всё лишь ошибки в методике работы, но тем не менее недовольство пользователей будет.
2) Низкая производительность выполнения запросов
Ну кто же сказал что «чем меньше тем быстрее»? Для корректно разработанной ИС это утверждение не верно.
На рисунке ниже кратко и «на птичьем языке» приведен простейший пример выборки по индексу типа B-Дерева записи в таблице адресов:
В тему индексов углубляться не хочу, тем более там всё несколько сложнее. Самое главное — поиск проходит не «горизонтально» по таблице, а «вертикально» по «уровням» индекса.
Аналогия — записная книжка: Каждая страница начинается со своей буквы, только вот на каждой странице ещё такая же записная книжка в которой вы можете выбрать вторую букву в слове, и так до тех пор, пока не встретите ту страницу, на которой будет одна или несколько записей. Удобно? Конечно удобно, в случае если у вас больше нескольких сотен контактов. А если у вас их всего десять? Не проще ли их просто записать на один листочек, который можно просмотреть глазами? Вот и в случае индексов так же. Он эффективен если в таблице несколько тысяч записей, а вот если одна единственная — не очень. Благо СУБД научились самостоятельно выбирать «план запроса» и решать использовать или не использовать тот или иной индекс. Вот только в случае «перебора» всех строк таблицы без индекса СУБД очень часто блокирует всю эту таблицу, и вы наблюдаете «непонятно откуда взявшиеся блокировки» после свертки ИБ.
Сворачиваем мы обычно таблицы остатков. В таблице остатков первым полем во всех индексах будет период. Т.е при любых запросах на самом верхнем уровне индекса будет уже отобраны рассчитанные остатки на нужный период. Следовательно на запросы по остаткам свёртка базы окажет наименьшее влияние, повторюсь, при правильной организации системы.
3) Большой объём «ненужных данных» которые мешают работе пользователей
Об этом вы пользователям сперва сделайте рассылку. И получите кучу сообщений что «данные ненужными не бывают». Тем не менее многим не нравится «видеть документы за прошлые периоды» и «архивные данные», с ними нельзя не согласиться. Но решает ли сверка эти проблемы? Убирает ли она ненужные номенклатуры из номенклатурного справочника? Контрагентов с которыми больше не будет вестись работа? А как показывает практика большинство проблем именно в этом.
II) «Технологические» решения проблем
1) Проблема увеличения размера БД
а) Разделение БД на файловые группы
— Открываем Management Studio в списке баз выбираем нужную, открываем её свойства.
— Переходим на вкладку «Файловые группы» как показано на рисунке, и добавляем ещё одну файловую группу (на примере она названа SECONDARY)
— Переходим на вкладку «Файлы» и добавляем новый файл, для которого выбираем созданную файловую группу. Этот файл МОЖНО РАСПОЛОЖИТЬ НА ДРУГОМ ДИСКЕ
— Теперь используя обработку к примеру://infostart.ru/public/78049/ определяем какие таблицы мы можем смело «пожертвовать» на более медленный (ну или наоборот всё на медленный, остальные — на более быстрый) носитель. Правило 80/20 здесь действует. 80% операций проводятся с 20% данными, так что думайте какие таблички вам нужны оперативно, а какие не очень. «Хранилище дополнительной информации», документы ввода начальных остатков, документы которые уже не используете сразу определяйте как те которые можно перенести в «медленную» файловую группу.
— Выбираем таблицу которую нужно перенести в другую файловую группу — выбираем меню изменения таблицы (проект) и в свойствах меняем файловую группу:
индексы таблицы при этом тоже переносятся в данную файловую группу.
Достаточно удобный механизм распределения таблиц по дисковым массивом разной скорости. Лицензионному соглашению это не противоречит, т.к. в решении мы не используем доступ к данным и к информационной базе средствами отличными от платформы 1С. Мы лишь организуем хранение этих данных удобным образом.
б) Размещение БД или её части на сетевом диске
DBCC TRACEON (1807)
Пишем данную команду в Management Studio, выполняем и можем успешно создавать базы по сети. Само собой при этом экземпляр SQL Server-а должен быть запущен от имени доменной учетной записи, и у этой записи должны быть права на нужную сетевую папку.
Но прошу быть очень внимательными при использовании данной команды в случае если у вас пропадёт сеть при работе с БД вся БД на время её отсутствия будет не доступной. Microsoft не зря закрыли эту возможность для массового использования. Вообще эта возможность предполагается для создания баз на NAS хранилищах, что и настоятельно рекомендую. Подойдёт так же стабильный и надежный файловый сервер, имеющий прямое подключение к серверу на котором запущен MS SQL СУБД.
Подробнее про другие флаги трассировки можно прочитать в статье http://msdn.microsoft.com/ru-ru/library/ms188396.aspx
Т.е. часть файловую группу можно вообще хранить в сети, а уж там дисковое пространство расширяется без проблем.
EXEC sp_MSforeachtable ‘ALTER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE)’ GO
После выполнения этого кода все таблицы в БД будут сжаты. Очевидно, что можно сжимать и таблицы по отдельности… это как бы на ваш выбор. Что даёт сжатие?
— Экономия дискового пространства
— Снижение нагрузки на дисковую подсистему
Что расходуется? — процессорное время.
Так что если у вас процессор загружен всё время на 70% и выше — сжатие вам использовать нельзя. Если 20-30% загрузка процессора, и при этом очередь к диску вырастает до 3-4… то сжатие таблиц — как раз «лекарство» для вас. Подробнее про сжатие таблиц БД —http://msdn.microsoft.com/ru-ru/library/cc280449(v=sql.100).aspx
Важное замечание — функция сжатия таблиц доступна только для обладателей версии Enterprise SQL Server
Разделить таблицы на разные файловые группы конечно хорошо… но вы скажете что есть тут парочка таблиц… которые тянутся с 2005 года… и уже занимают с десяток гигабайт.. вот бы в них все данные да отдельный диск положить, а текущие оставить.
Вы не поверите, но и это тоже возможно, хотя и не очень просто:
— Создаём функуцию секционирования по дате:
create partition function YearSection(datetime)
as range right for values (‘20110101’);
Всё что до 2011 года будет попадать в одну секцию, всё что после — в другую.
— Создаём схему секционирования
create partition scheme YearScheme
as partition YearSection to (SECONDARY, PRIMARY);
— Этим говорим, что все данные до 11 года будут попадать в файловую группу «Secondary» а после — в «Primary»
— Теперь осталось таблицу перестроить с разделением на секции. Для этого проще всего воспользоваться уже management studio, потому как процесс не простой. Вам нужно перестроить кластерный индекс для таблицы (который по сути и является самой таблицей), выбрав для индекса созданную схему секционирования:
На рисунке вы видите что выбор не доступен — всё правильно, секционирование таблиц возможно только в версии Enterprise MS SQL Server. Кластерный индекс отличить легко — картинка с круглыми скобками. Для РН и всех объектов 1С он создаётся. Для РН кластерный индекс по периоду есть всегда. Для документов и справочников хорошо бы конечно создать другой, который включает реквизит по которому будет секционирование… но это уже будет являться нарушением лицензионного соглашения.
2) Проблема низкой производительности запросов
Все действия, описанные выше не должны повлиять на скорость выполнения основных запросов. Более того, использование файловых групп и секций таблиц позволит вам разместить наиболее часто используемые данные на быстрых дисковых массивах, позволит поменять конфигурацию дисковых массивов, использовать небольшие по размеру i/o accelerator. Таким образом скорость выполнение запросов только повысится. А сжатие таблиц позволит вам дополнительно разгрузить дисковую подсистему, если она являлась узким местом. А вообще если говорить о скорости выполнения запросов, то анализ их планов выполнения, оптимизация запросов для грамотного использования индексов даст намного более существенный прирост производительности, чем все «ухищрения» на уровне MS SQL.
3) Проблема большого объёма «ненужных данных», которые мешают работе пользователей
Но для этого нужно не сворачивать базу, а проделать следующее:
а) Объяснить всем как пользоваться отборами, как они сохраняются, как пользоваться интервалами журнала, как они сохраняются
б) Пометить на удаление ненужные данные если они не несут никакой смысловой нагрузки (контрагентов и номенклатуру, с которыми больш не работаете) — этим вы принесёте пользователям больше пользы чем сверткой. В случае наличия ресурсов настроить автоматическую пометку на удаление неиспользуемых объектов и сделать отбор по умолчанию в программном коде для того чтобы не отображались по умолчанию не нужные пользователям объекты — помеченные на удаление
в) Настроить другие полезные «отборы по умолчанию» — например чтобы каждый менеджер по умолчанию видел только свои документы. А если хочет посмотреть документы «товарища» — нужно отключать отбор.
По всем реквизитам, которые участвуют в отборе не забывайте ставить признак «Индексировать с доп. упорядочиванием» — тогда на производительности системы такие «удобства» не скажутся.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Целью данной статьи является «отговорить» от выполнения свертки БД пользователей клиент-серверного варианта 1С, за счет использования несколько более «продвинутых» технологий.
В современных условиях очень странно бывает иногда слышать «нам нужно свернуть БД 1С — её объём превышает 50 ГБ». Если бы такое собирались сделать администраторы систем SAP R3 или Oracle e Business Suite или даже MS Dynamics Ax их бы наверное уволили. Тем не менее, для 1С это является «стандартной практикой».
Перейти к публикации
(0)
«Для файловых версий история тянется ещё с версии 1С 7.7 с ограничением в 2ГБ на размер базы. Сейчас ограничение 2ГБ уже только на размер таблицы, размер файла уже может получиться очень и очень не маленьким.»(с)
В файловой версии 1С 7.7 нет ограничения на размер базы данных.
(2) объяснение, что не надо сворачивать, у ТС выглядит более аргументировано. что-то из статьи даже применю на практике
напишите более развернуто чтоли, а не издевательские вырывания цитат из контекста.
(3)
Антон (anton.fly7).
А какие еще могут быть слова?
Автор пояснил, что если проблема в размере базы и нехватке дисковой памяти, то она легко решается. Рассказы об использовании сетевого диск интересные и познавательные. Но снижать скорость и надежность, думаю, не следует.
Причины для свертки базы, чаще выдвигаются по скорости и отсутствии причин для работы со «старой» информацией. Не знаю какие аргументы против сворачивания базы данных «у ТС»(с), но у меня пользователи желают иметь всю историю взаимодействия с «клиентами» и «товарами». В прошлой системе за 7 лет, в текущей за 11 лет. Т.е. за всё время жизни компании…
(3) ну так если вам нужны данные за 11 лет, то вы тоже против сворачивания базы? И что вы будете делать, когда база не влезет на диски? Ии запросы тупить? Автор обозначил свой план де.ствий
(5) Запросы не тупят. Просто пишутся они в типовых конфигурациях для «типовых» баз. Если база большая и где-то возникают проблемы связанные с производительностью, то необходимо просто переписать некоторые запросы и всё.
У нас база УПП за 6 лет. Сворачивать не собираемся.
(6) я и не утверждал что у вас проблемы с ИС
>> что вы будете делать, когда база не влезет на диски ?
(7) Перенесу ежедневные архивы за прошлый год на другой ПК, но это понадобится только через 10 лет, а к тому времени уже можно будет менять сам сервер. 🙂
(8) ок ) ая хочу попробовать вынести некоторые таблицы на другой диск ) например SSD
(9)
(9) anton.fly7, Вот так и делали… очень помогает основные «товарные» регистры даже если только перекинуть… регистры бухгалтерии.. на порядок растёт производительность… особенно «неправильных» запросов
(3) anton.fly7, он просто будет писать всегда «против», чтобы я не написал 🙂
Интересно и познавательно. Могёт быть и придется воспользоваться описанными в статье мерами. Автору за статью «+». Не у каждого найдется время так обстоятельно написать о проблеме разрастания и тормозах в 1С и способах ее решения…
(13) тролит? ) я еще твой жж читаю, откуда ты столько много знаешь???
(1) hogik, Я конечно не эксперт по 7.7.. но вроде у dbf формата есть такое ограничение. Ссылку на источник не приведу и проверять лень, но как бы «везде на слуху»
(2) hogik,
Улыбнуло
Господа, объясните ему пожалуйста :). Что внешние дисковые массивы, SAN, NAS не просто так для развлечения люди придумали :). Что нормальный RAID массив требует около 9 дисков, и что сервера давно уже не делают вместе с «коробкой для дисков»…. как-то прошли те времена 🙂
(17) программисту надо платить зарплату и он должен знать ms sql, причем в плане администрирования
(0) А есть какая-то статистика? Или это все на теоретическом уровне? (14) наверное читает
PS В любом случае зачот.
(18) cool.vlad4, Это перевод (17)?
(0) (15) в интернетах пишут что ограничение на размер файла DBF 2 гига или 4 гига
(14) anton.fly7, СПС. да знаете… когда что-то случается жизнь заставляет узнавать :). В ЖЖ там чуть больше.. здесь только то что 1с касается выкладываю..
(20) Нет, конечно, — ответ.
Примерный перевод
В этом что-то есть, но в 50-60% случаях и свертка подойдет. А в организации где есть сервер и база больше 500Гб, работа сильно завязана на БД , поэтому в штате должен быть программист, которому не надо платить 30 -40 тыс.
(19) cool.vlad4, Статистика чего? Сразу могу сказать что «Сжатие таблиц» на уровне всей БД не пробовал… Но читал очень живописные комментарии тех кто пробовал… Размер уменьшается раза в 2, при этом нагрузка на процессор возрастает процентов на 60. Секционирование испытал.. но не на на 1C. На 1с тоже, естественно, попробовал но не на production — на production пока нет потребности особо. Собсвтенно секционирование позволяет не только «таблицу распределить», но больше для производительности и параллельности выполнения запросов MS это планировали. Но как я писал в — для 1С эту фичу лучше отключать
(23) cool.vlad4, А… ну тогда надо «+» поставить 🙂
(25)
я уже как 15 минут назад это сделал)))А это ты мне…не понял, спросонья)))(24) собственно, читаешь мои мысли, — как раз на production как-то стремно это делать(именно для 1С).
Однозначно плюс.
Я не знал о таких возможностях MS SQL, и, что задним числом обидно, не знали этого мои инженеры на прошлом месте работы, отправленные на курсы по MS SQL.
Спасибо за статью!
(26) cool.vlad4, Нуу… Гилёв вроде писал что делал на production. Я лично верю в технологии MS :). В плане что физический уровень на логический не повлияет.
Свёртки свёртками, но запросы «тупят» гораздо чаще по другим причинам — написаны криво или в расчёте на малые объёмы. Когда дописыванием четырёх букв в текст запроса он ускоряется с 1.5 часов до 7 минут — это не требует комментариев. Притом, что исходный запрос принадлежит авторству АОЗТ «1С». 🙂
(31)Пример приведите пожалуйста. Не то что бы я вам не доверял, но правила хорошего тона…
Еще можно было бы добавить про «Создание недостающих индексов» для повышения скорости выполнения запросов ))
(30) hrip, Сетевой диск это скорее для справочника вида «Хранилище дополнительной информации». Если и правда в базе файлы храним. Или для документов «которыми перестали пользоваться»… Но не знаю в чём связь секционирования в вашем случае и блокировок… надо уточнять что оперативные данные переложили на более быстрый дисковый массив, архивные — на более медленный. Для «борьбы» с блокировками лучше прочитать что я писал про блокировки и .
(31) Yashazz, ну это да… просто это уже «избитая» тема 🙂
(33) Maks_Payn, Я старался уложиться в рамки лицензионного соглашения 1с… а индексы это уже операции с данными — это уже точно нарушение…
прелесно
Действительно очень дельное предложение. Учитывая приведенную статистику следует взять на вооружение. Попробую начать эти работы в ближайшее время. База растет, блокировки лезут. Посмотрим, что получится
(38) Блокировки слабо зависят от размера базы.
Автор как раз и говорит о том, что размер базы на самом деле на производительность работы почти не влияет 🙂
Я также противник свертки всю свою сознательную жизнь на 1С.
Поэтому статью считаю полезной. Плюсанул.
ЗЫ ни разу не сворачивал базу, даже не пытался это пробовать 🙂
(33) Уже есть такая обработка.
Посмотри публикации автора desty
PS сейчас он
готовитуже сделал намного более мощную версию, которая, например, позволяет показать сам запрос, про который MS SQL говорит о недостающих или неверных индексах, и план выполнения этого запроса.Удобно разруливать косяки запросов 🙂 я уже пользуюсь
(38) владимирп, Про блокировки я другие статьи писал… не от размера базы они…
(34) Диски одинаковые, но архивные и рабочие файловые группы разместил на разных дисках.
отличная статья. возьму себе на заметку обязательно приведенные в публикации методики 🙂
(43) hrip, А смысл? Рабочая файловая группа как использовалась активно так и будет использоваться… Смысл был бы наверное если рабочую к примеру на SSD положить, а архивную на какой-нить RAID 10… Или вы из каких соображений?
(16)
Олег.
Ну, давайте, пожалуйста читать друг-друга! 😉
Это же Вы написали:
«Естественно могут быть проблемы отсутствия места под новые жесткие диски в самом сервере… «(с)
Или, я это написал?
Лично, мне представляются странным разговор о скорости и предложение:
«разместить файлы БД на сетевом диске»(с)
И еще раз повторю — нехватка места на жестком диске не являться основной причиной (поводом) для свертки базы данных.
Т.к. см. (6),(8) сообщения. Или Ваше, же утверждение:
«Увеличение доступного для БД дискового пространства обойдётся нам в 20 т.р. + 10 минут работы специалиста. «(с)
Т.е. суть Вашей публикации — рассказать о «Management Studio» с искусственной привязкой к «проблеме» свертки базы данных 1С.
Про «Management Studio» — спасибо за информацию…
(31)(35), Поясните, плз.
(47) WellMaster,
Да даже в книжке А.Габец «Профессиональная разработка…» В последней главе это всё расписано.
+
Вот здесь собрание только официальных материалов от 1С
+ в КБ
+ презентации с партнёрских мероприятий
И это только официальная информация… так что «оптимизировать запросы» и «подбирать индексы» не умеет только ленивый
(46) hogik, Владимир, в школьной программе изучают замечательный рассказ:
Не пишите пожалуйста больше ваших комментариев, они смущают людей. Если что-то плохое хотите написать потому что хочется — это в личку.
P.S. Господа, кто прочитал комментарий и кого он смутил на всякий случай поясню:
1) Основной сформировавшей мнение комментирующего является работа по глобальному переписыванию 77
2) Современные Blade сервера не рассчитаны на установку большого количества дисков — поэтому используются SAN хранилища и NAS диски. NAS диск по сути похож на файловый сервер, только очень надёжный файловый сервер.
3) Сворачивать БД из за падения производительности в 1С 8 не стоит не в коем случае. Для этого существуют известные методики оптимизации запросов
(48)
Олег.
Вопрос не в тему. А как получить доступ к содержанию этих ссылок?
(50) hogik, Это с франчайзи договориться… 🙂 ну или в открытых источниках можно Книжку «Профессиональная разработка» А.Габец-а скачать. Там в 7 главе почти всё это есть.
(51)
Спасибо за информацию.
(49)
Олег.
Да, не пытаюсь я Вам говорит «плохое»(с) !!!
У меня просто стиль общения такой — задавать вопросы собеседнику цитируя его информацию для, как мне кажется, заострения (конкретизации) своего вопроса.
По сути:
Про SAN в статье ничего не сказано. Зато есть слова про NAS и «стабильный и надежный файловый сервер»(с). Т.е. обмен с применением сетевых адаптеров? Вот и мой вопрос (мнение) про скорость. И к 7.7 это никакого отношения не имеет… Т.е. общий вопрос (разговор) по железу. Вродей это в теме Ваше публикации.
за инфу по скулю спсб.
базы у меня совсем небольшие, но ятакже против сворачивания…
на трех фирмах где поддерживал — на одном база с 2003 г, на других с 2006…
обрезать не надо хотя бы из-за необходимости посчитать иногда статистику…
(0) Очень интересно. Побольше бы таких статей. Оставил закладку — потом поковыряюсь
у нас база больше 100 Гб,просто добавили дискового пространства.информация в статье очень полезная
статья полезная, так что закладочка.
(48)(51) Книга Габеца у меня есть, читал. Доступа в партнерку нет.
Вопрос: о каких 4 буквах в запросе речь в комментарии (31):
«Когда дописыванием четырёх букв в текст запроса он ускоряется с 1.5 часов до 7 минут — это не требует комментариев.»?
(57) WellMaster, Это конфигурация, по-моему даже не типовая.
Про файловые группы очень понравилось! Надо будет что-нить порыскать на PostgresSQL.
Спасибо автору за труд!
Я так понимаю, файловые группы в экспресс версии не поддерживается?
(59) den_vladimir, Где-то в комментариях вроде приводилась статья по PostgresSQL с тем же самым…
(60) den_vladimir, Так и 1С вроде с Express Версией не работает… если просто протестить хотите там вроде Developer версия есть, в которой всё поддерживается…
(62) В экспрессе ограничение на объем базы и количество процов, а так-то 1С работает с ней
(45)
Секционирование базы данных улучшает производительность и упрощает обслуживание. Благодаря разбиению большой таблицы на несколько маленьких запросы, которые обращаются к отдельной порции данных, могут выполняться быстрее, поскольку при этом приходится просматривать меньше данных. Такие задачи обслуживания, как перестроение индексов и резервное копирование данных, выполняются более эффективно.
Для базы я файловые группы разделил по годам, а таблицы разбил на секции по месяцам.
т.е. например в файловой группе 2011 находятся 12 таблиц регистра (для каждого месяца отдельная таблица) накопления «Партии товаров на складах». И как я (надеюсь что правильно) понимаю время чтения/записи одной секции будет меньше чем всей таблицы и соответственно время которое данные находятся в заблокированном состоянии тоже будет меньше.
(64) hrip, Согласен… с Microsoft-ом не поспоришь. наверное будет быстрее обслуживание, параллелизм если включить будет тоже ускорение, но его лучше не включать…
А вот почему при разбиении одной таблицы на части по дискам будут быстрее запросы я пока не могу понять :(… наверное нужно более подробно разбираться в физической организации MS SQL…. Если понимаете почему — напишите…
(65) я и не претендую на роль знатока по ms sql, но думаю что есть разница во времени, когда запрос получает выборку из таблицы содержащей 3 млн. или 50 тыс записей. В 1С это будут запросы на получение остатков и оборотов и вероятно срез последних (Благодаря разбиению большой таблицы на несколько маленьких запросы, которые обращаются к отдельной порции данных, могут выполняться быстрее, поскольку при этом приходится просматривать меньше данных.). Предыдущие периоды в регистрах перенесены в файловые группы на другой диск и разделены на секции, а таблицы текущего периода находятся в файловой группе на основном диске и тоже разделены на секции (файловая группа — это год, секция — месяц).
(66) hrip,
Писал же… разницы практически нет… только если в плане запроса Table scan есть… но это проблема кривого запроса уже… или индексов не правильных… И тем не менее Microsoft уверены что производительность вырастет… там скорее всего другие факторы… на более «физическом» уровне.
(67) Результат запросов будет один и тот же. Если например период за который получаются данные — месяц, тогда первый запрос будет получать данные из всей таблицы, а второй запрос — из одной секции (хотя он и без секционирования будет выполняться быстрее чем первый т.к. отбор данных осуществляется на стороне sql сервера).
«ВЫБРАТЬ
| ПартииТоваровНаСкладах.Регистратор КАК Регистратор,
| СУММА(ПартииТоваровНаСкладах.Количество) КАК Количество
|ИЗ
| РегистрНакопления.ПартииТоваровНаСкладах КАК ПартииТоваровНаСкладах
|ГДЕ
| ПартииТоваровНаСкладах.Период МЕЖДУ &Начало И &Конец
| И ПартииТоваровНаСкладах.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
|
|СГРУППИРОВАТЬ ПО
| ПартииТоваровНаСкладах.Регистратор»
«ВЫБРАТЬ
| ПартииТоваровНаСкладахОбороты.Регистратор КАК Регистратор,
| СУММА(ПартииТоваровНаСкладахОбороты.КоличествоПриход) КАК Количество
|ИЗ
| РегистрНакопления.ПартииТоваровНаСкладах.Обороты(&Начало, &Конец, Регистратор, ) КАК ПартииТоваровНаСкладахОбороты
|
|СГРУППИРОВАТЬ ПО
| ПартииТоваровНаСкладахОбороты.Регистратор»
(67)
И тем не менее Microsoft уверены что производительность вырастет…
Ну я надеюсь что Microsoft знает о чем пишет.
Ну а для меня результатом деления таблиц базы на файловые группы и их секционирования стало то что больше практически не слышу жалоб пользователей о том что они не могут проводить документы из-за конфликтов блокировок.
(49)
«hogik, Владимир … Не пишите пожалуйста больше ваших комментариев, они смущают людей.»(с)
Слушаюсь и повинуюсь, мой Господин! 🙂 🙂 🙂
Написал тут:
Господа, у кого 7-ка статья (70) наверное будет интересна. У кого 8-ка про «СУБД-Строение» я бы не стал читать.
Все мои предложения проверялись только под 1С 8, для 1С 7.7 может и вправду свертка полезна…
(71)
Олег.
В моей статейке нет призыва: «сверните БД». 🙂
Я не пытаюсь противопоставить свертку БД средствам «Management Studio».
Иначе бы, и под эту публикацию поставил «минус»…
упс… не ожидал, что так дофига получится 🙂
(74) нормально. Действительно, для меня основная причина для свертки — увеличение времени бэкапа, реиндексации, обновления в структуре базы, тестирования и исправления и т.д.
(73) speshuric,
Эх… всё это уже давно работает на практике 🙂
А вот автор комментария похоже собрался 1С в газпроме использовать в качестве основной системы — вместо SAP, причём в режим 24/7, допустимое время простоя по SLA 1 час в год :).
Вы не понимаете… для АРХИВНЫХ данных я рекоммендую не использовать 8-10 дисков. Не нужна там скорость… нужно просто чтобы они были доступны :).
Хотел бы я работать в компании где это считали бы аварийной ситуацией :))))) Можно было бы вообще ничего не делать, а всё время кричать — 20% загрузка процессора, а что вы хотели — нужен новый сервер :).
Относительно прогнозируемое время выполнения.
Ага… запустите как-нибудь на базе в 1ТБ :))) Будет «Гарантированный результат» , я даже знаю какой :).
30 минут это очень удачный расклад… Но вот только резврные копии можно тоже делать по файловым группам, и соответственно бэкапы можно гибко настроить то же касается и остальных пунктов
Ну всей БД вы конечно преувеличели… но про опасности такого подхода я писал. Да простои возможны — при этом сетевой диск лучше подключать напрямую к серверу
Это же в каком состоянии нужно быть, чтобы умудриться при копировании на сетевой диск потерять файл :)))
— посмотрел, период первый 🙂
Вообщем итог — замечание по поводу того что поле «пометка на удаление» не индексировано принимается. Я ручками индекс ставил — уже забыл…, всё остальное — «рассуждения на тему»
Статья очень во время:) база 50Гб, хотел делать свертку! попробую сначала все оптимизировать! «+» однозначно
(73)(78)
Alexander (speshuric).
Браво!!!
Такие аргументы достойны отдельной Публикации.
Спасибо за Ваш труд…
(76)Кстати, если у вас на полный бэкап
, то почему не используете сжатие бэкапов? Если затык на подсистеме ввода-вывода, то сжатие бэкапов очень ускоряет.
(78) speshuric,
1) Что касается простоя либо SLA есть либо его нет. Если есть, то оценивается независыми экспертами ДОПУСТИМЫЙ простой. Если его поставить 5 часов в неделю — это одна стоимость обслуживания, если час в год — другая. В последнем случае и система уже будет другая и оборудование. Если SLA никто даже не оговаривал, тут что можно сказать — «извините», сложности у всех бывают, если хотите уменьшить вероятность — давайте обсудим SLA :). Это мировой цивилизованный подход.
2)По поводу процессоров: 70% это не с потолка — это официальная рекомендация 1С. Если Вы «Бьете тревогу» при 25% вам просто очень повезло с бюджетом :).
3)
Вообще-то я имел в виду что создавать резеврную копию нужно только одной (ну или нескольких) РАБОЧИХ файловых групп. Вы никак не можете понять основного смысла: даже если база в 1 ТБ, рабочая часть этой базы 20-50 ГБ, всё остальное — просто архивных хлам, к которому просто нужен удобный пользователям доступ. Ну не набирает 1С даже при интенсивной работе за год больше. Если соберёт больше то уже надо думать не об учетных системах, а о системах другого класса. Поэтому и про диски и про файловые группы и про сетевые диски все ваши вопросы. И потерять эту всю файловую группу не страшно, и без неё работать будет…
4)
Кластерный индекс становится эффективным, и он практически всегда используется, да и в некластерные добавление поля повышает эффективность запросов. У меня просто конфа не типовая… во всех запросах стоит «ПометкаУдаления = ЛОЖЬ». Не знаю над чем вы смеялись, видимо так просто… иногда бывает. в DAX, к примеру, все индексы таблицы остатков содержат поле CLOSED с двумя значениями.
(80) speshuric, Так вообщем-то не напрягает.. Backup на сетевой диск. Процессорное время пока самое узкое место.
(79) hogik, Владимир, человек хотя бы со знанием дела и по сути даже кое-что пишет 🙂
(83)
Олег.
Извините, не в тему напишу.
Если человек точно знает, что 2*2=4, и утверждает, что 2*2*х=4, только на основании того, что 2*2 используется в обеих формулах. То я сначала пытаюсь обратить его внимание на наличие «х», а потом разговаривать про 2*2.
А Alexander (speshuric) поступил иначе. И сделал это отлично!
(86)
Я вас не понимаю.
Вы предлагаете решение в рамках администрирования БД и жалуетесь, что вам отвечают в тех же понятиях и терминах. Я, кстати, вообще не администратор БД.
Вы так и не рассказали, как будете работать, если протеряете ФГ с архивными данными. Вы же даже пересчитать итоги после этого не сможете принципиально, не говоря уж о том какие будут простои и какие танцы с бубном будут нужны, чтобы заставить 1С после этого нормально запуститься.
Вы путаетесь в показаниях про индекс по пометке удаления (даже без учета того, что 1С его не делает). Берём упомянутый вами справочник, в котором настроили «автоматическую пометку на удаление неиспользуемых объектов» и «отбор по умолчанию в программном коде для того чтобы не отображались по умолчанию не нужные пользователям объекты — помеченные на удаление». Какие индексы с участием пометки удаления будете создавать? Кластерные/некластерные, какие поля и в каком порядке входят, есть ли столбцы включаемые (INCLUDE) в индекс? Поможет ли этот индекс, когда непомеченных на удаление значительно больше, чем помеченных?
Кстати, к результатам DTA я отношусь крайне настороженно, потому что он нередко генерирует рекомендации на индексы, которые дублируют друг друга и плохо учитывает затраты на вставку/удаление записей и на хранение данных. Т.е. посмотреть «а не профукали ли где-нибудь индекс» можно, но генерить тупо индексы по рекомендациям стремно. Например, он может предложить 2 индекса с разным порядком колонок, которые сравниваются в запросах на равенство.
(88) speshuric, Вы правы, вы меня не понимаете :). Вы сторонник стратегий «Из пушки по воробьям». Больше в дискуссии не вступаю. Сворачивайте базы в 0.5 ТБ могу только удачи вам пожелать :).
Вместо того чтобы писать «всё неправильно» могли бы лучше что-нибудь и правда полезное написать — про влияние секционирование на производительность (я так и не разобрался почему Microsoft пишут что в целом производительность запросов возрастет) и польза была бы, и знания свои показали бы.
Дискутировать можно было лишь на тему нарушения лицензионного соглашения… потому что вопрос и правда спорный, вроде физическая организация не противоречит соглашению, а может есть другое мнение…
P.S. Во все более-менее адекватные индексы пометку на удаление нужно вставлять, именно потому что помеченных на удаление намного больше чем не помеченных (справочники). Кластерный индекс в общем по полю с 2-мя значениями будет эффективен, а если там ID 1-м конечно уже не очень.
(87) hogik, Владимир, я в вас не сомневался. Должен же кто-то «минус» ставить :).
В любом случае что-то в этом есть.
(89)
Может всё-таки не затруднит ответить на 2 простых вопроса, которые я задаю третий раз, чтобы я наконец-то прозрел?
1.
Вы так и не рассказали, как будете работать, если протеряете ФГ с архивными данными
2.
Конкретику.
Кластерные/некластерные, какие поля и в каком порядке входят, есть ли столбцы включаемые (INCLUDE) в индекс? Поможет ли этот индекс, когда непомеченных на удаление значительно больше, чем помеченных?
(92) speshuric,
1) Восстанавливать
2) Ищите индексы где присутствует _Folder и добавляете перед ним _Marked. В принципе то же самое помошник как правило советует.. ну на моих запросах…
(89)
Олег.
А, и не надо вступать в дискуссии. 😉
Еще раз, рекомендую Вам — потратить час своего времени и перечитать сообщения своих собеседников. Например вот это: «Я сам был и остаюсь противником свертки баз данных 1С.»(с) из (73) сообщения.
Да. Вас трудно понять. Вы считаете, что: «Вы сторонник стратегий «Из пушки по воробьям»(с) и пытаетесь доказать, что «раздолбайство» — лучше… 🙂
У мене такое впечатление, что Вашу фразу:
«В случае же если вы продаёте булочки или шариковые ручки, на вряд ли вам нужно…»(с)
заменить на, примерно, такую фразу:
«Я продаю булочки или шариковые ручки, и мне … не нужно…».
(94) hogik, Владимир, надо признать что все кто продаёт не «булочки и ручки» работают не на 1С :). В 1С как speshuric писал у вас всё равно есть шанс получить противоречивые данные :).
(95)
«надо признать что все кто продаёт не «булочки и ручки» работают не на 1С :).»(с)
Олег.
Вот — так? Запросто…
Взять и «нагадить в открытый рот» всем пользователям 1С-а и сообществу данного ресурса.
хорошая статья, благодарю
Очень полезная статья. Прочитал про секционирование БД, теперь надо бы протестировать как увеличится скорость если старые документы не обрезать, а по дате секционировать.
Можно ли как-то секционировать движения документов(У меня очень много документов установок цен) ?
(98) Murom, Да, движения документов можно секционировать…. Но вот с установками цен это сложнее… вам там нужна по большому счету вся таблица… срез последних только индекс использовать будет…. Скорость опять же не увеличится ни в случае образения, ни в случае секционирования… Если только вы не планируете более быстрый дисковый массив (I/O Accelerator) поставить, и на него вынести только таблицу цен.