Давайте забудем о свертке БД? Файловые группы и секции таблиц SQL, сжатие таблиц SQL.

Публикация № 94040

Администрирование - Производительность и оптимизация (HighLoad)

Целью данной статьи является "отговорить" от выполнения свертки БД пользователей клиент-серверного варианта 1С, за счет использования несколько более "продвинутых" технологий.
В современных условиях очень странно бывает иногда слышать "нам нужно свернуть БД 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) Проблема большого объёма "ненужных данных", которые мешают работе пользователей  

Но для этого нужно не сворачивать базу, а проделать следующее:
а) Объяснить всем как пользоваться отборами, как они сохраняются, как пользоваться интервалами журнала, как они сохраняются
б) Пометить на удаление ненужные данные если они не несут никакой смысловой нагрузки (контрагентов и номенклатуру, с которыми больш не работаете) - этим вы принесёте пользователям больше пользы чем сверткой. В случае наличия ресурсов настроить автоматическую пометку на удаление неиспользуемых объектов и сделать отбор по умолчанию в программном коде для того чтобы не отображались по умолчанию не нужные пользователям объекты - помеченные на удаление
в) Настроить другие полезные "отборы по умолчанию" - например чтобы каждый менеджер по умолчанию видел только свои документы. А если хочет посмотреть документы "товарища" - нужно отключать отбор.

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

 

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
0. comol 4384 01.01.70 03:00 Сейчас в теме
Целью данной статьи является "отговорить" от выполнения свертки БД пользователей клиент-серверного варианта 1С, за счет использования несколько более "продвинутых" технологий.
В современных условиях очень странно бывает иногда слышать "нам нужно свернуть БД 1С - её объём превышает 50 ГБ". Если бы такое собирались сделать администраторы систем SAP R3 или Oracle e Business Suite или даже MS Dynamics Ax их бы наверное уволили. Тем не менее, для 1С это является "стандартной практикой".

Перейти к публикации

1. hogik 435 12.10.11 04:02 Сейчас в теме
(0)
"Для файловых версий история тянется ещё с версии 1С 7.7 с ограничением в 2ГБ на размер базы. Сейчас ограничение 2ГБ уже только на размер таблицы, размер файла уже может получиться очень и очень не маленьким."(с)
В файловой версии 1С 7.7 нет ограничения на размер базы данных.
artem_from_minsk; g26516; Ёпрст; Трактор; +4 Ответить
15. comol 4384 12.10.11 10:59 Сейчас в теме
(1) hogik, Я конечно не эксперт по 7.7.. но вроде у dbf формата есть такое ограничение. Ссылку на источник не приведу и проверять лень, но как бы "везде на слуху"
2. hogik 435 12.10.11 06:54 Сейчас в теме
(0)
Очередной дельный совет: "если мало дисковой памяти, то ее надо увеличить".
Далее, автор представил себе сервер (!!!), где нет места для установки дополнительных дисков. И рассказал, как можно разнести информацию, аж, на сетевые диски. Используя средство предназначенное для повышения производительности. Да, "Microsoft не зря закрыли эту возможность"(с)...
Пояснения про индексы, трудно обсуждать (критиковать), т.к. есть приписка (оправдание): "там всё несколько сложнее"(с). Но, объяснение на "на птичьем языке"(с) впечатляет. Это, типа для тех у кого куриные мозги... :-)
Олег.
Основная причина (аргумент) для НеСворачивания БД это: "данные ненужными не бывают"(с), если ИС АвтоМехАнизирует не только "бухгалтерский" учет. А у НАС основные мотивы "не нравится "видеть документы за прошлые периоды"(с). Вот и сворачиваем, даже SQL-ные базы данных, при наличии свободной и достаточной дисковой памяти...
handscenter; quNas; Yakud3a; afk; +4 4 Ответить
3. anton.fly7 149 12.10.11 07:03 Сейчас в теме
(2) объяснение, что не надо сворачивать, у ТС выглядит более аргументировано. что-то из статьи даже применю на практике
напишите более развернуто чтоли, а не издевательские вырывания цитат из контекста.
ivan_luzinov; Yakov52; amaksimov; +3 Ответить
4. hogik 435 12.10.11 07:25 Сейчас в теме
(3)
Антон (anton.fly7).
А какие еще могут быть слова?
Автор пояснил, что если проблема в размере базы и нехватке дисковой памяти, то она легко решается. Рассказы об использовании сетевого диск интересные и познавательные. Но снижать скорость и надежность, думаю, не следует.
Причины для свертки базы, чаще выдвигаются по скорости и отсутствии причин для работы со "старой" информацией. Не знаю какие аргументы против сворачивания базы данных "у ТС"(с), но у меня пользователи желают иметь всю историю взаимодействия с "клиентами" и "товарами". В прошлой системе за 7 лет, в текущей за 11 лет. Т.е. за всё время жизни компании...
5. anton.fly7 149 12.10.11 08:00 Сейчас в теме
(3) ну так если вам нужны данные за 11 лет, то вы тоже против сворачивания базы? И что вы будете делать, когда база не влезет на диски? Ии запросы тупить? Автор обозначил свой план де.ствий
6. alexk-is 6485 12.10.11 08:53 Сейчас в теме
(5) Запросы не тупят. Просто пишутся они в типовых конфигурациях для "типовых" баз. Если база большая и где-то возникают проблемы связанные с производительностью, то необходимо просто переписать некоторые запросы и всё.

У нас база УПП за 6 лет. Сворачивать не собираемся.
CratosX; Divoric; +2 Ответить
7. anton.fly7 149 12.10.11 08:55 Сейчас в теме
(6) я и не утверждал что у вас проблемы с ИС
>> что вы будете делать, когда база не влезет на диски ?
8. alexk-is 6485 12.10.11 09:04 Сейчас в теме
(7) Перенесу ежедневные архивы за прошлый год на другой ПК, но это понадобится только через 10 лет, а к тому времени уже можно будет менять сам сервер. :)
9. anton.fly7 149 12.10.11 09:11 Сейчас в теме
(8) ок ) ая хочу попробовать вынести некоторые таблицы на другой диск ) например SSD
11. comol 4384 12.10.11 10:54 Сейчас в теме
(9) anton.fly7, Вот так и делали... очень помогает основные "товарные" регистры даже если только перекинуть... регистры бухгалтерии.. на порядок растёт производительность... особенно "неправильных" запросов
13. comol 4384 12.10.11 10:55 Сейчас в теме
(3) anton.fly7, он просто будет писать всегда "против", чтобы я не написал :)
14. anton.fly7 149 12.10.11 10:57 Сейчас в теме
(13) тролит? ) я еще твой жж читаю, откуда ты столько много знаешь???
22. comol 4384 12.10.11 11:31 Сейчас в теме
(14) anton.fly7, СПС. да знаете... когда что-то случается жизнь заставляет узнавать :). В ЖЖ там чуть больше.. здесь только то что 1с касается выкладываю..
16. comol 4384 12.10.11 11:03 Сейчас в теме
(2) hogik,

Улыбнуло

Далее, автор представил себе сервер (!!!), где нет места для установки дополнительных дисков


Господа, объясните ему пожалуйста :). Что внешние дисковые массивы, SAN, NAS не просто так для развлечения люди придумали :). Что нормальный RAID массив требует около 9 дисков, и что сервера давно уже не делают вместе с "коробкой для дисков".... как-то прошли те времена :)
46. hogik 435 12.10.11 18:43 Сейчас в теме
(16)
Олег.
Ну, давайте, пожалуйста читать друг-друга! ;-)
Это же Вы написали:
"Естественно могут быть проблемы отсутствия места под новые жесткие диски в самом сервере... "(с)
Или, я это написал?
Лично, мне представляются странным разговор о скорости и предложение:
"разместить файлы БД на сетевом диске"(с)
И еще раз повторю - нехватка места на жестком диске не являться основной причиной (поводом) для свертки базы данных.
Т.к. см. (6),(8) сообщения. Или Ваше, же утверждение:
"Увеличение доступного для БД дискового пространства обойдётся нам в 20 т.р. + 10 минут работы специалиста. "(с)
Т.е. суть Вашей публикации - рассказать о "Management Studio" с искусственной привязкой к "проблеме" свертки базы данных 1С.
Про "Management Studio" - спасибо за информацию...
49. comol 4384 13.10.11 00:55 Сейчас в теме
(46) hogik, Владимир, в школьной программе изучают замечательный рассказ: http://lib.ru/SHUKSHIN/srezal.txt
Не пишите пожалуйста больше ваших комментариев, они смущают людей. Если что-то плохое хотите написать потому что хочется - это в личку.

P.S. Господа, кто прочитал комментарий и кого он смутил на всякий случай поясню:

1) Основной сформировавшей мнение комментирующего является работа по глобальному переписыванию 77 http://forum.infostart.ru/ajax/show_comment.php?t=42684&c=68
2) Современные Blade сервера не рассчитаны на установку большого количества дисков - поэтому используются SAN хранилища и NAS диски. NAS диск по сути похож на файловый сервер, только очень надёжный файловый сервер.
3) Сворачивать БД из за падения производительности в 1С 8 не стоит не в коем случае. Для этого существуют известные методики оптимизации запросов
70. hogik 435 14.10.11 17:14 Сейчас в теме
(49)
"hogik, Владимир ... Не пишите пожалуйста больше ваших комментариев, они смущают людей."(с)

Слушаюсь и повинуюсь, мой Господин! :-) :-) :-)

Написал тут: http://infostart.ru/public/94437/
71. comol 4384 14.10.11 17:32 Сейчас в теме
Господа, у кого 7-ка статья (70) наверное будет интересна. У кого 8-ка про "СУБД-Строение" я бы не стал читать.
Все мои предложения проверялись только под 1С 8, для 1С 7.7 может и вправду свертка полезна...
72. hogik 435 14.10.11 18:52 Сейчас в теме
(71)
Олег.
В моей статейке нет призыва: "сверните БД". :-)
Я не пытаюсь противопоставить свертку БД средствам "Management Studio".
Иначе бы, и под эту публикацию поставил "минус"...
12. fomix 26 12.10.11 10:55 Сейчас в теме
Интересно и познавательно. Могёт быть и придется воспользоваться описанными в статье мерами. Автору за статью "+". Не у каждого найдется время так обстоятельно написать о проблеме разрастания и тормозах в 1С и способах ее решения...
18. cool.vlad4 45 12.10.11 11:18 Сейчас в теме
(17) программисту надо платить зарплату и он должен знать ms sql, причем в плане администрирования
20. comol 4384 12.10.11 11:29 Сейчас в теме
23. cool.vlad4 45 12.10.11 11:35 Сейчас в теме
(20) Нет, конечно, - ответ.
Примерный перевод
В этом что-то есть, но в 50-60% случаях и свертка подойдет. А в организации где есть сервер и база больше 500Гб, работа сильно завязана на БД , поэтому в штате должен быть программист, которому не надо платить 30 -40 тыс.
25. comol 4384 12.10.11 11:38 Сейчас в теме
(23) cool.vlad4, А... ну тогда надо "+" поставить :)
27. cool.vlad4 45 12.10.11 11:40 Сейчас в теме
(25) я уже как 15 минут назад это сделал))) А это ты мне...не понял, спросонья)))
19. cool.vlad4 45 12.10.11 11:21 Сейчас в теме
(0) А есть какая-то статистика? Или это все на теоретическом уровне? (14) наверное книжки умные читает

PS В любом случае зачот.
24. comol 4384 12.10.11 11:37 Сейчас в теме
(19) cool.vlad4, Статистика чего? Сразу могу сказать что "Сжатие таблиц" на уровне всей БД не пробовал... Но читал очень живописные комментарии тех кто пробовал... Размер уменьшается раза в 2, при этом нагрузка на процессор возрастает процентов на 60. Секционирование испытал.. но не на на 1C. На 1с тоже, естественно, попробовал но не на production - на production пока нет потребности особо. Собсвтенно секционирование позволяет не только "таблицу распределить", но больше для производительности и параллельности выполнения запросов MS это планировали. Но как я писал в http://comol.livejournal.com/1807.html - для 1С эту фичу лучше отключать
26. cool.vlad4 45 12.10.11 11:40 Сейчас в теме
(24) собственно, читаешь мои мысли, - как раз на production как-то стремно это делать(именно для 1С).
29. comol 4384 12.10.11 11:58 Сейчас в теме
(26) cool.vlad4, Нуу... Гилёв вроде писал что делал на production. Я лично верю в технологии MS :). В плане что физический уровень на логический не повлияет.
21. anton.fly7 149 12.10.11 11:30 Сейчас в теме
(0) (15) в интернетах пишут что ограничение на размер файла DBF 2 гига или 4 гига
28. Medvedik 12.10.11 11:47 Сейчас в теме
Однозначно плюс.
Я не знал о таких возможностях MS SQL, и, что задним числом обидно, не знали этого мои инженеры на прошлом месте работы, отправленные на курсы по MS SQL.
Спасибо за статью!
30. hrip 214 12.10.11 12:11 Сейчас в теме
На сетевой диск я бы не стал переносить базу (ну или ее часть).
А вот разбиение базы на файловые группы и секционирование реально помогает.
После прочтения статьи http://infostart.ru/public/79517/ сделал по аналогии для ms sql
Статистику в цифрах привести не могу, но после разбиения базы на файловые группы и секционирования таблиц жалобы пользователей на конфликты блокировок при проведении документов практически прекратились (база УПП, размер базы 50Гб, одновременно работает 50 пользователей).

Если кому пригодяться скрипты для создания схемы и функции секционирования

USE [МояБаза1С]
GO

CREATE PARTITION SCHEME [myDate] AS PARTITION [myDate] TO ([ARCHIVE], [2011], [2011], [2011], [2011], [2011], [2011], [2011], [2011], [2011], [2011], [2011], [2011], [2012], [2012], [2012], [2012], [2012], [2012], [2012], [2012], [2012], [2012], [2012], [2012], [2013], [2013], [2013], [2013], [2013], [2013], [2013], [2013], [2013], [2013], [2013], [2013], [2014], [2014], [2014], [2014], [2014], [2014], [2014], [2014], [2014], [2014], [2014], [2014], [2015], [2015], [2015], [2015], [2015], [2015], [2015], [2015], [2015], [2015], [2015], [2015], [OTHER], [PRIMARY])
GO

USE [МояБаза1С]
GO

CREATE PARTITION FUNCTION [myDate](datetime) AS RANGE RIGHT FOR VALUES (N'2011-01-01T00:00:00.000', N'2011-02-01T00:00:00.000', N'2011-03-01T00:00:00.000', N'2011-04-01T00:00:00.000', N'2011-05-01T00:00:00.000', N'2011-06-01T00:00:00.000', N'2011-07-01T00:00:00.000', N'2011-08-01T00:00:00.000', N'2011-09-01T00:00:00.000', N'2011-10-01T00:00:00.000', N'2011-11-01T00:00:00.000', N'2011-12-01T00:00:00.000', N'2012-01-01T00:00:00.000', N'2012-02-01T00:00:00.000', N'2012-03-01T00:00:00.000', N'2012-04-01T00:00:00.000', N'2012-05-01T00:00:00.000', N'2012-06-01T00:00:00.000', N'2012-07-01T00:00:00.000', N'2012-08-01T00:00:00.000', N'2012-09-01T00:00:00.000', N'2012-10-01T00:00:00.000', N'2012-11-01T00:00:00.000', N'2012-12-01T00:00:00.000', N'2013-01-01T00:00:00.000', N'2013-02-01T00:00:00.000', N'2013-03-01T00:00:00.000', N'2013-04-01T00:00:00.000', N'2013-05-01T00:00:00.000', N'2013-06-01T00:00:00.000', N'2013-07-01T00:00:00.000', N'2013-08-01T00:00:00.000', N'2013-09-01T00:00:00.000', N'2013-10-01T00:00:00.000', N'2013-11-01T00:00:00.000', N'2013-12-01T00:00:00.000', N'2014-01-01T00:00:00.000', N'2014-02-01T00:00:00.000', N'2014-03-01T00:00:00.000', N'2014-04-01T00:00:00.000', N'2014-05-01T00:00:00.000', N'2014-06-01T00:00:00.000', N'2014-07-01T00:00:00.000', N'2014-08-01T00:00:00.000', N'2014-09-01T00:00:00.000', N'2014-10-01T00:00:00.000', N'2014-11-01T00:00:00.000', N'2014-12-01T00:00:00.000', N'2015-01-01T00:00:00.000', N'2015-02-01T00:00:00.000', N'2015-03-01T00:00:00.000', N'2015-04-01T00:00:00.000', N'2015-05-01T00:00:00.000', N'2015-06-01T00:00:00.000', N'2015-07-01T00:00:00.000', N'2015-08-01T00:00:00.000', N'2015-09-01T00:00:00.000', N'2015-10-01T00:00:00.000', N'2015-11-01T00:00:00.000', N'2015-12-01T00:00:00.000', N'2016-12-01T00:00:00.000', N'2020-01-01T00:00:00.000')
GO

теперь лет 5 можно не париться с производительностью :-)

Но для регистров есть три таблицы в sql сервере(основная, итоги и регистрация изменений) и как применить секционирование к таблицам регистрации изменений, в какие файловые группы их помещать и как они могут влиять на производительность я так и не понял.
bohdan-k; makarovy; amaksimov; +3 Ответить
34. comol 4384 12.10.11 13:56 Сейчас в теме
(30) hrip, Сетевой диск это скорее для справочника вида "Хранилище дополнительной информации". Если и правда в базе файлы храним. Или для документов "которыми перестали пользоваться"... Но не знаю в чём связь секционирования в вашем случае и блокировок... надо уточнять что оперативные данные переложили на более быстрый дисковый массив, архивные - на более медленный. Для "борьбы" с блокировками лучше прочитать что я писал про блокировки http://comol.livejournal.com/558.html и http://comol.livejournal.com/1013.html...
43. hrip 214 12.10.11 17:10 Сейчас в теме
(34) Диски одинаковые, но архивные и рабочие файловые группы разместил на разных дисках.
45. comol 4384 12.10.11 17:48 Сейчас в теме
(43) hrip, А смысл? Рабочая файловая группа как использовалась активно так и будет использоваться... Смысл был бы наверное если рабочую к примеру на SSD положить, а архивную на какой-нить RAID 10... Или вы из каких соображений?
64. hrip 214 14.10.11 13:43 Сейчас в теме
(45) http://msdn.microsoft.com/ru-ru/library/ms178148.aspx

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

Для базы я файловые группы разделил по годам, а таблицы разбил на секции по месяцам.
т.е. например в файловой группе 2011 находятся 12 таблиц регистра (для каждого месяца отдельная таблица) накопления "Партии товаров на складах". И как я (надеюсь что правильно) понимаю время чтения/записи одной секции будет меньше чем всей таблицы и соответственно время которое данные находятся в заблокированном состоянии тоже будет меньше.
65. comol 4384 14.10.11 15:14 Сейчас в теме
(64) hrip, Согласен... с Microsoft-ом не поспоришь. наверное будет быстрее обслуживание, параллелизм если включить будет тоже ускорение, но его лучше не включать...

А вот почему при разбиении одной таблицы на части по дискам будут быстрее запросы я пока не могу понять :(... наверное нужно более подробно разбираться в физической организации MS SQL.... Если понимаете почему - напишите...
66. hrip 214 14.10.11 15:56 Сейчас в теме
(65) я и не претендую на роль знатока по ms sql, но думаю что есть разница во времени, когда запрос получает выборку из таблицы содержащей 3 млн. или 50 тыс записей. В 1С это будут запросы на получение остатков и оборотов и вероятно срез последних (Благодаря разбиению большой таблицы на несколько маленьких запросы, которые обращаются к отдельной порции данных, могут выполняться быстрее, поскольку при этом приходится просматривать меньше данных.). Предыдущие периоды в регистрах перенесены в файловые группы на другой диск и разделены на секции, а таблицы текущего периода находятся в файловой группе на основном диске и тоже разделены на секции (файловая группа - это год, секция - месяц).
67. comol 4384 14.10.11 16:15 Сейчас в теме
(66) hrip,
но думаю что есть разница во времени, когда запрос получает выборку из таблицы содержащей 3 млн. или 50 тыс записей


Писал же... разницы практически нет... только если в плане запроса Table scan есть... но это проблема кривого запроса уже... или индексов не правильных... И тем не менее Microsoft уверены что производительность вырастет... там скорее всего другие факторы... на более "физическом" уровне.
68. hrip 214 14.10.11 16:31 Сейчас в теме
(67) Результат запросов будет один и тот же. Если например период за который получаются данные - месяц, тогда первый запрос будет получать данные из всей таблицы, а второй запрос - из одной секции (хотя он и без секционирования будет выполняться быстрее чем первый т.к. отбор данных осуществляется на стороне sql сервера).

"ВЫБРАТЬ
| ПартииТоваровНаСкладах.Регистратор КАК Регистратор,
| СУММА(ПартииТоваровНаСкладах.Количество) КАК Количество
|ИЗ
| РегистрНакопления.ПартииТоваровНаСкладах КАК ПартииТоваровНаСкладах
|ГДЕ
| ПартииТоваровНаСкладах.Период МЕЖДУ &Начало И &Конец
| И ПартииТоваровНаСкладах.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
|
|СГРУППИРОВАТЬ ПО
| ПартииТоваровНаСкладах.Регистратор"

"ВЫБРАТЬ
| ПартииТоваровНаСкладахОбороты.Регистратор КАК Регистратор,
| СУММА(ПартииТоваровНаСкладахОбороты.КоличествоПриход) КАК Количество
|ИЗ
| РегистрНакопления.ПартииТоваровНаСкладах.Обороты(&Начало, &Конец, Регистратор, ) КАК ПартииТоваровНаСкладахОбороты
|
|СГРУППИРОВАТЬ ПО
| ПартииТоваровНаСкладахОбороты.Регистратор"
69. hrip 214 14.10.11 16:37 Сейчас в теме
(67)

И тем не менее Microsoft уверены что производительность вырастет...

Ну я надеюсь что Microsoft знает о чем пишет.

Ну а для меня результатом деления таблиц базы на файловые группы и их секционирования стало то что больше практически не слышу жалоб пользователей о том что они не могут проводить документы из-за конфликтов блокировок.
31. Yashazz 3582 12.10.11 12:26 Сейчас в теме
Свёртки свёртками, но запросы "тупят" гораздо чаще по другим причинам - написаны криво или в расчёте на малые объёмы. Когда дописыванием четырёх букв в текст запроса он ускоряется с 1.5 часов до 7 минут - это не требует комментариев. Притом, что исходный запрос принадлежит авторству АОЗТ "1С". :)
32. Medvedik 12.10.11 13:00 Сейчас в теме
(31)Пример приведите пожалуйста. Не то что бы я вам не доверял, но правила хорошего тона...
35. comol 4384 12.10.11 14:07 Сейчас в теме
(31) Yashazz, ну это да... просто это уже "избитая" тема :)
47. WellMaster 104 12.10.11 21:00 Сейчас в теме
48. comol 4384 13.10.11 00:38 Сейчас в теме
(47) WellMaster,

Да даже в книжке А.Габец "Профессиональная разработка..." В последней главе это всё расписано.

+

Вот здесь собрание только официальных материалов от 1С http://v8.1c.ru/expert/methodics.htm

+ в КБ

http://kb.1c.ru/articleView.jsp?id=44
http://kb.1c.ru/articleView.jsp?id=47

+ презентации с партнёрских мероприятий

http://partners.v8.1c.ru/index.jsp?parentID=74

И это только официальная информация... так что "оптимизировать запросы" и "подбирать индексы" не умеет только ленивый
50. hogik 435 13.10.11 00:58 Сейчас в теме
(48)
Олег.
Вопрос не в тему. А как получить доступ к содержанию этих ссылок?
51. comol 4384 13.10.11 01:04 Сейчас в теме
(50) hogik, Это с франчайзи договориться... :) ну или в открытых источниках можно Книжку "Профессиональная разработка" А.Габец-а скачать. Там в 7 главе почти всё это есть.
52. hogik 435 13.10.11 01:24 Сейчас в теме
(51)
Спасибо за информацию.
(49)
Олег.
Да, не пытаюсь я Вам говорит "плохое"(с) !!!
У меня просто стиль общения такой - задавать вопросы собеседнику цитируя его информацию для, как мне кажется, заострения (конкретизации) своего вопроса.
По сути:
Про SAN в статье ничего не сказано. Зато есть слова про NAS и "стабильный и надежный файловый сервер"(с). Т.е. обмен с применением сетевых адаптеров? Вот и мой вопрос (мнение) про скорость. И к 7.7 это никакого отношения не имеет... Т.е. общий вопрос (разговор) по железу. Вродей это в теме Ваше публикации.
57. WellMaster 104 13.10.11 10:52 Сейчас в теме
(48)(51) Книга Габеца у меня есть, читал. Доступа в партнерку нет.
Вопрос: о каких 4 буквах в запросе речь в комментарии (31):
"Когда дописыванием четырёх букв в текст запроса он ускоряется с 1.5 часов до 7 минут - это не требует комментариев."?
58. comol 4384 13.10.11 11:54 Сейчас в теме
(57) WellMaster, Это конфигурация, по-моему даже не типовая.
33. Maks_Payn 12.10.11 13:51 Сейчас в теме
Еще можно было бы добавить про "Создание недостающих индексов" для повышения скорости выполнения запросов ))
Gandalf Белый; +1 Ответить
36. comol 4384 12.10.11 14:09 Сейчас в теме
(33) Maks_Payn, Я старался уложиться в рамки лицензионного соглашения 1с... а индексы это уже операции с данными - это уже точно нарушение...
41. artbear 1202 12.10.11 16:20 Сейчас в теме
(33) Уже есть такая обработка.
Посмотри публикации автора desty
PS сейчас он готовит уже сделал намного более мощную версию, которая, например, позволяет показать сам запрос, про который MS SQL говорит о недостающих или неверных индексах, и план выполнения этого запроса.
Удобно разруливать косяки запросов :) я уже пользуюсь
37. zhleonid8 12.10.11 14:14 Сейчас в теме
38. владимирп 25 12.10.11 15:51 Сейчас в теме
Действительно очень дельное предложение. Учитывая приведенную статистику следует взять на вооружение. Попробую начать эти работы в ближайшее время. База растет, блокировки лезут. Посмотрим, что получится
39. artbear 1202 12.10.11 16:16 Сейчас в теме
(38) Блокировки слабо зависят от размера базы.
Автор как раз и говорит о том, что размер базы на самом деле на производительность работы почти не влияет :)
42. comol 4384 12.10.11 16:34 Сейчас в теме
(38) владимирп, Про блокировки я другие статьи писал... не от размера базы они...
40. artbear 1202 12.10.11 16:17 Сейчас в теме
Я также противник свертки всю свою сознательную жизнь на 1С.
Поэтому статью считаю полезной. Плюсанул.
ЗЫ ни разу не сворачивал базу, даже не пытался это пробовать :)
44. dkprim 5 12.10.11 17:17 Сейчас в теме
отличная статья. возьму себе на заметку обязательно приведенные в публикации методики :)
53. CheBurator 3429 13.10.11 02:46 Сейчас в теме
за инфу по скулю спсб.
базы у меня совсем небольшие, но ятакже против сворачивания...
на трех фирмах где поддерживал - на одном база с 2003 г, на других с 2006...
обрезать не надо хотя бы из-за необходимости посчитать иногда статистику...
54. ValeriTim 20 13.10.11 09:55 Сейчас в теме
(0) Очень интересно. Побольше бы таких статей. Оставил закладку - потом поковыряюсь
55. vec435 15 13.10.11 10:05 Сейчас в теме
у нас база больше 100 Гб,просто добавили дискового пространства.информация в статье очень полезная
56. Zoomby 13.10.11 10:12 Сейчас в теме
статья полезная, так что закладочка.
59. den_vladimir 97 14.10.11 07:17 Сейчас в теме
Про файловые группы очень понравилось! Надо будет что-нить порыскать на PostgresSQL.
Спасибо автору за труд!
61. comol 4384 14.10.11 10:27 Сейчас в теме
(59) den_vladimir, Где-то в комментариях вроде приводилась статья по PostgresSQL с тем же самым...
60. den_vladimir 97 14.10.11 07:44 Сейчас в теме
Я так понимаю, файловые группы в экспресс версии не поддерживается?
62. comol 4384 14.10.11 10:28 Сейчас в теме
(60) den_vladimir, Так и 1С вроде с Express Версией не работает... если просто протестить хотите там вроде Developer версия есть, в которой всё поддерживается...
63. Medvedik 14.10.11 11:11 Сейчас в теме
(62) В экспрессе ограничение на объем базы и количество процов, а так-то 1С работает с ней
73. speshuric 1189 15.10.11 12:47 Сейчас в теме
Двойственное впечатление от статьи. С одной стороны хорошо, что упомянуты возможности SQL Server 2008, которые могут помочь в решении проблем крупных баз данных, с другой всё как-то сумбурно и зачастую используются ложные предпосылки и предположения. Попробую аккуратно указать спорные моменты.
Я сам был и остаюсь противником свертки баз данных 1С. С точки зрения производительности работы пользователей это одна из последних мер, но она обладает неоспоримымми достоинствами:
  • Относительно гарантированнный результат.
  • Относительно прогнозируемое время выполнения.
  • Достижение других целей (кроме повышения производительнсти): упрощение обслуживания, возможность отказаться от некоторых "костылей" в программном коде (если они заточены на некорректные или устаревшие данные), возможность запланировать дополнительные процедуры обслуживания на тот же период, что и свертка
Конечно, безусловно и однозначно, речь не идёт об "игрушечных" базах данных в 50-60 ГБ. О свертке имееет смысл говорить, когда объём данных (чистый просуммированнный объём таблиц) уходит за 0,5-1,5 ТБ (оценка на текущий момент, НЕ подходит для зарплатных баз 1С, а подходит для доработанных типовых или относительно близких к типовым по идеологии). Дело в том, что начиная с примерно этого объёма резко вырастают затраты по обслуживанию базы данных:
  • Если версия сервера ниже, чем 2008R2, то на стандартной редакции бэкап длится 30 минут и более. Хранение за разумный срок и манипуляции с бэкапом становятся просто неподъёмными. Дифференциальные бэкапы лишь частично спасают положение, но они же добавляют время при планировании восстановления.
  • Кстати, восстановление на этих объёмах по времени становится нередко неприемлемым для бизнеса и приходится держать "тёплый" сервер через доставку журналов или аналоги.
  • Перестроение и дефрагментация больших индексов становится неприлично тяжёлой. А если есть тёплый сервер из предыдущего пункта, то еще и прибавляются затраты на передачу журналов транзакций.
  • Становятся дольше CHECKDB, обновление статистики (которая как раз и используется в планах запросов). С частотной статистикой, кстати, на больших таблицах есть еще беда, что хранится не более 200 значений для каждой статистики, и для больших таблиц ошибки в планах запросов из-за этого происходят гораздо чаще
  • Учитывая всё предыдущее - возрастание на 1 ГБ базы данных в такой системе потребует 5-15 ГБ всего в ИТ-инфраструктуре (1 за базу, 1 за тёплый сервер, 3-5-7 на полные бэкапы, плюс что-то на журналы транзакций и дифф. бэкапы, но это уже мелочи, как и всякие журналы сбоытий 1С и прочая ботва). А диски для СХД зачастую можно приобрести только у вендора и за космические деньги. Осталось вспомнить, что для производительной базы данных в дисковое хранилище диски покупаются не "на объём", а "на производительность", т. е. даже для 100 ГБ базы может потребоваться 8-10 дисков. И тут ваша оценка "Серверный жесткий диск на 500 ГБ стоит около 10 т.р." кажется неимоверно упрощённой
Дальше. У вас используется в примерах какая-то "дикая" свертка, которая выполняется сразу на боевой базе и не остаётся старой версии. Ну по крайней мере я об этом сужу по фразам:
И даже после этого найдутся пользователи которым "вдруг неожиданно понадобились" стертые данные...
Кроме того, если база уже размером не 60 а, к примеру, 120 ГБ... малейшая ошибка в коде 1С при свертке и всё... процедура заканчивается не удачно.
Обычно свертка выполняется всё ж таки на копии и только после оценки (получилось/не получилось) ей подменяется боевая база. А та база, которая была, становится доступной (на чтение), но архивной. И остаётся в боевой по возможности не меньше, чем полный прошлый год и хвост текущего.
Плюс вы почему-то посчитали риск от безвозвратной потери данных (при выносе на сетевой диск) менее страшным, чем программная ошибка в свертке. Хм. Ну если со второй проблемой можно бороться известными способами (например, банально нанять второго программиста, который напишет тесты), то что делать, когда я могу просто так, ни за что, непредсказуемо потерять данные - я не знаю как бороться.
Следующее замечание.
Сворачиваем мы обычно таблицы остатков
Вот с ними-то на текущий момент у 1С всё относительно хорошо. Есть промежуточные итоги и планы SQL строит достаточно эффективно практически на любых объёмах. А вот регистры сведений и документы - это беда. Другая беда с регистрами бухгалтерии , но там есть хоть какие-то итоги (хотя именно структура этих итогов - одна из проблем). В чем именнно проблемы:
  • Документы - да, вы упрощенно, но правильно описали работу индекса. Но скорее для кластерного индекса. Беда только в том, что даже для достаточно селективного индекса (например по контрагенту) постепенно накапливается много документов с одним и тем же контрагентом. Причем из-за хорошей селективности каждый документ зачастую лежит на отдельной от других документов этого контрагента странице данных. Хорошо, еще, если индекс с доп. упорядочиванием (тогда для документов добавляется дата в индекс) и идёт отбор по контрагенту и периоду (тогда эффективность очень высокая и почти не уступает кластерному). А если нет отбора по периоду (даже если есть по другому полю) или индекс не "с доп. упорядочиванием"? Тогда может сложиться ситуация, что с диска SQL будет поднимать все эти разрозненные страницы только чтобы убедиться, что они ему не нужны. Кстати, тут же нам передают привет излишние блокировки всего диапазона ключа или всех записей с данным отбором.
  • Регистры сведений - ключевая проблема в срезе последних. Проблема в том, что комбинация измерений однажды попавшая в срез - оттуда не исчезнет. В итоге у небольшой оптовой торгующей организации в срезе последних может быть 90% неактуальных видов цен (27 из 30), 90% товаров которых уже никогда не будет (45000 из 50000) и никакими индексами и хитрыми запросами особо ситуацию не исправить. Ну т.е. можно добиться улучшений, но по стоимости они дороже свертки.
  • У регистров бухгалтерии достаточно "специфичный" механизм хранения субконто и итогов по субконто. На больших базах он начинает вести себя слабо предсказуемо, да и сжирает место угрожающими темпами. Это если все остатковые субконто нормально закрываются, если они где-то не закрываются или долго не закрываются, то ситуация к концу года просто становится катастрофичной
  • Отдельно стоит упомянуть составные типы - эта достаточно удобная логическая абстракция имеет очень нехорошую тенденцию "запутывать" оптимизатор SQL Server на больших объёмах, что при активном использовании связок Таблица.СоставноеПоле.РеквизитСоставногоПоля нормальные планы можно увидеть только во сне (вспоминаем про ограничения статистик и про ограничение на глубину поиска оптимального решения оптимизатором)
Дальше: "В таблице остатков первым полем во всех индексах будет период.". Это не соответствует действительности. Откройте ИТС и прочитайте. Ну или SSMS, раз уж он вам ближе.

Теперь по самим предложениям. Главная претензия - 1С не поддерживает эти возможности. Файловые группы, секционирование или сжатие? Замечательно. Завтра вам придёт обновление, которое будет содержать реструктуризацию тех таблиц, которые вы поместили в SECONDARY или разбили на секции. И, кстати, лицензионному соглашению это как раз-таки противоречит, но не в этом суть. Главное, что стоимость поддержки резко вырастает: нужны специалисты более высокой квалификации (не на месяц, как для свертки, а навсегда), усложняется каждое применение типового релиза (каждого релиза!) как минимум на анализ "а не слетит ли".

Про размещение на сетевом диске. Я уже упомянул, но повторю: категорически не рекомендуется для рабочих OLTP баз. Это также безответственно, как садиться пьяным за руль. Дома или в разработке играйтесь этим как хотите. В промышленной среде вы рискуете всей базой данных или огромными простоями на время восстановления (ну и опять же потерями данных). Даже если причиной сбоя будет не этот фактор, то при привлечении к разбору стороннего квалифицированного специалиста вы аргументированно будете дисквалифицированы.

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

Так что если у вас процессор загружен всё время на 70% и выше - сжатие вам использовать нельзя. Если 20-30% загрузка процессора, и при этом очередь к диску вырастает до 3-4... то сжатие таблиц - как раз "лекарство" для вас.
Если мы говорим об обычной работе, а не о перестроении/дефрагментации индексов, не о ТиИ, не о checkdb и обновлении статистики и говорим о сервере, который не выполняет других серверных функций, кроме MS SQL для 1С, то средняя загрузка процессора сервера 20-30% со средней очередью в 3-4 - это ававрийная ситуация. Сервер не справляется. Надо срочно что-то менять: сервер, программиста, админа, информационную систему, директора - тут на выбор. Если у вас процессор загружен всё время на 70% и выше, то сжатие точно использовать нельзя. Потому что сервер использовать нельзя, тогда даже менять уже поздно. Если уж где-то применимо сжатие, так на архивных базах, где изменений нет совсем (в т.ч. структура таблиц не меняется), а сэкономить на месте хранения хочется.

Вы сами пишете
На рисунке вы видите что выбор не доступен - всё правильно, секционирование таблиц возможно только в версии Enterprise MS SQL Server
Но на разницу стоимостей Standard/Enterprise можно купить вполне достойное корпоративное хранилище данных начального уровня. Или раз 10 свернуть базу. Еще и детям на мороженное останется.
А вот на больших таблицах (на конкретных таблицах, а не базах данных), примерно от 100-200 ГБ, секционирование может сильно уменьшить время перестроения индексов, может позволить использовать сжатие страниц для старых данных и т.п. Но опять же - не бесплатно (Enterprise и усложнение обслуживания), но на больших объёмах выигрыш может быть значительным.

Непонятна ваша рекомендация про пометить на удаление неиспользуемые объекты. Что от этого быстрее станет работать? Тем более если настроить отборы по пометке удаления (которая никогда в индекс не входит). И уж для большинства пользователей будет неприемлемым "настроить автоматическую пометку на удаление неиспользуемых объектов". Гораздо проще для той же номенклатуры сделать группу неиспользуемых, и проработать перенос в эту группу. Но не для ускорения, а для удобства работы пользователей. И не автоматически, а с участием ответственных пользователей с продуманным регламентом.

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

В общем, статья действительно противоречивая: как будто автор знает или только что узнал много о текущих возможностях MS SQL, но не применял серьёзно их и видит в этих возможностях лишь плюсы, не раскрывая недостатки и ограничения (которые нередко сводят на нет все плюсы). Ну и, прямо скажу, очень неаккуратные, на грани технической безграмотности, формулировки, которые введут в заблуждение тех, кто не в теме.
Не удивлюсь, если следующие статьи окажутся про database snapshot (и опять не будет учтено, что они возможны только для enterprise, а значит стоимость использования, как минимум, +300-500 труб относительно стандартных), про доставку журналов и зеркалирование для баз 1С (не указав конкретные существенные ограничения по работе 1С с базами в stand by), репликацию транзакций (забыв что не везде есть первичный ключ) и т.п.
zoytsa; bohdan-k; vasiliy_b; sasha1200; mindcannon; purgin; aleksey.kubovtsov; zqzq; svetanik; ppeskov; zavss; SmartFox; simple; bird21; the1; Marik; rishat78; Terve!R; vkr; Serg0FFan; Atticus2; meuses; jk3; quNas; Taktic; адуырщдв; Sol; VSOP_juDGe; nikki_00; foka_1s; Silenser; cosmo2004; teflon; maxpiter; eeeio; Michale; KapasMordorov; CatMix; Циник; hogik; +40 Ответить
76. comol 4384 15.10.11 16:23 Сейчас в теме
(73) speshuric,
как будто автор знает или только что узнал много о текущих возможностях MS SQL
Эх... всё это уже давно работает на практике :)

А вот автор комментария похоже собрался 1С в газпроме использовать в качестве основной системы - вместо SAP, причём в режим 24/7, допустимое время простоя по SLA 1 час в год :).


т. е. даже для 100 ГБ базы может потребоваться 8-10 дисков

Вы не понимаете... для АРХИВНЫХ данных я рекоммендую не использовать 8-10 дисков. Не нужна там скорость... нужно просто чтобы они были доступны :).

Средняя загрузка процессора сервера 20-30% - это ававрийная ситуация

Хотел бы я работать в компании где это считали бы аварийной ситуацией :))))) Можно было бы вообще ничего не делать, а всё время кричать - 20% загрузка процессора, а что вы хотели - нужен новый сервер :).

Относительно гарантированнный результат.
Относительно прогнозируемое время выполнения.


Ага... запустите как-нибудь на базе в 1ТБ :))) Будет "Гарантированный результат" , я даже знаю какой :).

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

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

риск от безвозвратной потери данных (при выносе на сетевой диск)
Это же в каком состоянии нужно быть, чтобы умудриться при копировании на сетевой диск потерять файл :)))

Дальше: "В таблице остатков первым полем во всех индексах будет период.". Это не соответствует действительности. Откройте ИТС и прочитайте. Ну или SSMS, раз уж он вам ближе.
- посмотрел, период первый :)


Вообщем итог - замечание по поводу того что поле "пометка на удаление" не индексировано принимается. Я ручками индекс ставил - уже забыл..., всё остальное - "рассуждения на тему"
user1235208; zabaluev; +2 1 Ответить
78. speshuric 1189 15.10.11 18:33 Сейчас в теме
(76)
comol пишет:
А вот автор комментария похоже собрался 1С в газпроме использовать в качестве основной системы - вместо SAP, причём в режим 24/7, допустимое время простоя по SLA 1 час в год :)
Газпром тут ни при чем. Да, сейчас я работаю с достаточно критичной базой (но, кстати, ни разу не 24*7, технологические окна есть). Но до этого работал с относительно некритичной УПП на примерно сотню пользователей на предприятии с примерно 1000 сотрудников. По сути - нижняя граница среднего бизнеса. С этой системой реально работают люди. И реально не могут работать, когда УПП недоступна. Если сотрудники на сдельной ЗП не работали - они не получают денег. Это им не нравится, поэтому они пишут заявление о простое и оплате по среднему (это 2/3 от среднего заработка). В связи с этим вопрос простой: Вы лично, если Вы руководитель отдела, готовы оплатить из премиального фонда вашего отдела, например, 2 часа простоя 200 сотрудников производства с ЗП примерно 1/2 от ЗП программиста (для справки - это около 130 часов программиста, т.е. примерно 3/4 зарплаты одного программиста)? А простой вагонов, которые не смогли вовремя разгрузить?
Именно в огромных корпорациях типа газпрома как раз проще - всё-таки оперативная деятельность нередко разбита на разные информационные системы и простой одной из них наносит убытки, но не является катастрофой для компании. А вот для предприятий 200-10000 сотрудников (пусть даже пользователей 1С из них 10-30%) простой основной информационной системы наносит очень болезненные удары.
comol пишет:
Вы не понимаете... для АРХИВНЫХ данных я рекоммендую не использовать 8-10 дисков. Не нужна там скорость... нужно просто чтобы они были доступны :)

А я и не про архивные данные. Я про то, что если есть потребность увеличить базу на какой-то объём, то для более-менее крупных баз это выливается не просто в докупку 2 дисков. Даже если есть куда запихивать эти диски (а на самом деле это обычно не тривиально), то во-первых нужно резервировать больше не только под данные, но и под журналы транзакций (типичное значение 25% размера данных), нужно держать несколько последних актуальных копий, т.е. если не использовать сжатие (которое доступно только для 2008 enterprise и 2008R2 standard и enterprise) это столько же места, сколько копий хранится, нужно увеличить место на резервном сервере.
comol пишет:
Хотел бы я работать в компании где это считали бы аварийной ситуацией :))))) Можно было бы вообще ничего не делать, а всё время кричать - 20% загрузка процессора, а что вы хотели - нужен новый сервер :)

Еще раз. Средняя нагрузка. Не пиковая. Не во время переиндексации, а при обычной работе. На обычном двухпроцовом сервере с суммарно 12 ядрами и 24 потоками HT. 25% - это 6 потоков. Если без HT - 3, но это тоже не мало. Если средняя загрузка за час 25% - нужно бить тревогу, это высокие показатели. Возможно где-то в отчетах планы запросов кривые, возможно еще что-то. Надо разбираться. Если при этом еще и есть очередь к дискам постоянная, то это повод разбираться срочно.
comol пишет:
Ага... запустите как-нибудь на базе в 1ТБ :))) Будет "Гарантированный результат" , я даже знаю какой :)

Запускал.
comol пишет:
Но вот только резврные копии можно тоже делать по файловым группам, и соответственно ...

Нельзя рассматривать резервное копирование в отрыве от времени восстановления. Если восстановление БД займет больше суток, то оно нафиг не нужно. Если делать резервные копии по файловым группам, то надо будет прокачивать логи или накатывать разностные резервные копии этих файловых групп. Для баз размером меньше 1-2 ТБ на текущий момент обычно овчинка выделки не стоит.
comol пишет:
Ну всей БД вы конечно преувеличели
Целостность она знаете, либо есть, либо нет. Сеть (если это не специально собранная FC или iSCSI) очень ненадёжная среда. И, если вы потеряете из всей базы данных несколько страниц на одной файловой группе, то по сути вы имеете риск эту файловую группу потерять. Оценить стоимость восстановления в разумный срок я не возьмусь. Такие риски ИТ не может взять на себя. Владелец или топ-менеджмент могут, но они тоже не настолько идиоты обычно.
comol пишет:
посмотрел, период первый

У регистров может быть индексированное измерение. Еще раз советую читать документацию, особенно ИТС (см. размещение данных).
comol пишет:
Вообщем итог - замечание по поводу того что поле "пометка на удаление" не индексировано принимается. Я ручками индекс ставил - уже забыл..., всё остальное - "рассуждения на тему"

Что, правда? Посмеялся. И как работает индекс по полю с 2 значениями? Эффективно? И что, правда сам в план попадает без хинтов?
bohdan-k; Aleskey_K; ppeskov; sorb; Sol; foka_1s; cosmo2004; teflon; Michale; hogik; +10 Ответить
81. comol 4384 16.10.11 00:43 Сейчас в теме
(78) speshuric,

1) Что касается простоя либо SLA есть либо его нет. Если есть, то оценивается независыми экспертами ДОПУСТИМЫЙ простой. Если его поставить 5 часов в неделю - это одна стоимость обслуживания, если час в год - другая. В последнем случае и система уже будет другая и оборудование. Если SLA никто даже не оговаривал, тут что можно сказать - "извините", сложности у всех бывают, если хотите уменьшить вероятность - давайте обсудим SLA :). Это мировой цивилизованный подход.

2)По поводу процессоров: http://kb.1c.ru/articleView.jsp?id=10 70% это не с потолка - это официальная рекомендация 1С. Если Вы "Бьете тревогу" при 25% вам просто очень повезло с бюджетом :).

3)
накатывать разностные резервные копии этих файловых групп
Вообще-то я имел в виду что создавать резеврную копию нужно только одной (ну или нескольких) РАБОЧИХ файловых групп. Вы никак не можете понять основного смысла: даже если база в 1 ТБ, рабочая часть этой базы 20-50 ГБ, всё остальное - просто архивных хлам, к которому просто нужен удобный пользователям доступ. Ну не набирает 1С даже при интенсивной работе за год больше. Если соберёт больше то уже надо думать не об учетных системах, а о системах другого класса. Поэтому и про диски и про файловые группы и про сетевые диски все ваши вопросы. И потерять эту всю файловую группу не страшно, и без неё работать будет...

4)
И как работает индекс по полю с 2 значениями? Эффективно?
Кластерный индекс становится эффективным, и он практически всегда используется, да и в некластерные добавление поля повышает эффективность запросов. У меня просто конфа не типовая... во всех запросах стоит "ПометкаУдаления = ЛОЖЬ". Не знаю над чем вы смеялись, видимо так просто... иногда бывает. в DAX, к примеру, все индексы таблицы остатков содержат поле CLOSED с двумя значениями.
85. speshuric 1189 16.10.11 08:40 Сейчас в теме
(81)
Такое чувство, что мы на разном языке говорим.
1) Если SLA есть, то всё просто, действительно. Если его нет (в случае с описанным заводиком), но есть минимальное бюджетирование, то есть фонд ЗП общий по предприятию и простой надо оплатить. Либо оплатить как аварию, либо отнять из премиальных виновника. Если авария в 1С случайная или объективно не по вине отдела сопровождения, то в принципе на такие мелочи всегда найдётся копейка, но если будет явная вина отдела или регулярные повторения, то снимут именно с вас.
2) Статья 2007 года. Тогда еще 6-ядерных процов не было и HT c MS SQL хреново работал. Но и тогда я бы 50% считал недопустимой нагрузкой.
3) Ох ты ж блин. Гипотетическая ситуация. Есть 3 файла данных по 0,5 ТБ, каждый в отдельной файловой группе. 2 - архивные, 1 - активная. По вашей рекомендации мы делаем резервные копии архивных ФГ раз в 2 недели (по нечетным неделям первую архивную, по четным - вторую). Каждую ночь делается резервная копия активной ФГ. Время бэкапа одного файла - 1 час. Каждый час делаются РКЖТ (резервные копии журналов транзакций). Объём РКЖТ в рабочий день стабильный и около 10 ГБ (из них половина - дефрагментация индексов секций таблиц, остальное - действительно изменения данных). Скорость восстановления данных - 60 МБ/с, скороскть восстановления журналов 8 МБ/с, значения, кстати похожи на правду. Сбой произошёл в субботу вечером (это нам повезло, есть время для восстановления) до формирования копии архивной ФГ. Начинаем восстанавливать. Нам повезло и все резервные копии целы (на практике бывает и по-другому). Восстановили последнюю копию активных данных, восстановили 2 копии архивных. Это заняло около 7 часов (посчитал в экселе). Теперь накатим журналы транзакций. Оп. Тут кроется засада. Журналы транзакций нам надо поднимать за 2 недели, т.к. самый старый из восстановленных бэкапов - 2 недели назад. 2 недели - 10 рабочих дней - 200 ГБ РКЖТ, это еще 7 часов. Т.е. не делать рез. копии архивных файловых групп - опасно. Выход, конечно же в том, чтобы делать разностные резервные копии, но вы же пишете
Вообще-то я имел в виду что создавать резеврную копию нужно только одной (ну или нескольких) РАБОЧИХ файловых групп.
Кстати, 1С может и больше за год набрать, ничего ей не будет от этого.
И потерять эту всю файловую группу не страшно, и без неё работать будет...

Это как так? Вы пробовали остановить сервер (на разработческой копии, конечно), удалить ФГ и порпобовать в разумное время восстановиться?
4)
Кластерный индекс становится эффективным, и он практически всегда используется, да и в некластерные добавление поля повышает эффективность запросов. У меня просто конфа не типовая... во всех запросах стоит "ПометкаУдаления = ЛОЖЬ". Не знаю над чем вы смеялись, видимо так просто... иногда бывает. в DAX, к примеру, все индексы таблицы остатков содержат поле CLOSED с двумя значениями.

Кластерный индекс с первым полем пометки удаления или со вторым? Если со вторым, то не будет использоваться для отбора в принципе, если с первым, то это обрушит производительность 1С, потому что, например, "Таблица.Поле.ПолеПоля" будет создавать левое соединение без условия на пометку удаления.
В итоге варианты:
  • Кластерный индекс (Ссылка, Пометка) практически не ускорит отбор по пометке удаления
  • Кластерный индекс (Пометка, Ссылка) ускорит в лучшем случае отбор по значению пометки удаления, которого сильно меньше (и то только если статистика позволит). Обычно меньше помеченных на удаление всё-таки. Ну и плюс тот эффект, что разом начнут тупить запросы с неявными левыми соединениями.
  • Некластерный индекс по пометке удаления вообще не рассматриваем - ибо его селективность никакая.
comol пишет:
в DAX, к примеру, все индексы таблицы остатков содержат поле CLOSED с двумя значениями.

Не путайте теплое с мягким. Я не против добавления флагов в конец индекса. Это позволит реже доставать данные из кучи или из кластерного индекса. Но это не особо ускорит запрос с отбором только по этому полю, index seek не будет возникать (кроме вырожденных случаев).
bohdan-k; hogik; +2 Ответить
80. speshuric 1189 15.10.11 20:10 Сейчас в теме
(76)Кстати, если у вас на полный бэкап
30 минут это очень удачный расклад...
, то почему не используете сжатие бэкапов? Если затык на подсистеме ввода-вывода, то сжатие бэкапов очень ускоряет.
bohdan-k; zqzq; +2 Ответить
82. comol 4384 16.10.11 00:47 Сейчас в теме
(80) speshuric, Так вообщем-то не напрягает.. Backup на сетевой диск. Процессорное время пока самое узкое место.
79. hogik 435 15.10.11 19:31 Сейчас в теме
(73)(78)
Alexander (speshuric).
Браво!!!
Такие аргументы достойны отдельной Публикации.
Спасибо за Ваш труд...
83. comol 4384 16.10.11 00:49 Сейчас в теме
(79) hogik, Владимир, человек хотя бы со знанием дела и по сути даже кое-что пишет :)
84. hogik 435 16.10.11 01:09 Сейчас в теме
(83)
Олег.
Извините, не в тему напишу.
Если человек точно знает, что 2*2=4, и утверждает, что 2*2*х=4, только на основании того, что 2*2 используется в обеих формулах. То я сначала пытаюсь обратить его внимание на наличие "х", а потом разговаривать про 2*2.
А Alexander (speshuric) поступил иначе. И сделал это отлично!
74. speshuric 1189 15.10.11 13:19 Сейчас в теме
упс... не ожидал, что так дофига получится :)
75. anig99 2755 15.10.11 13:38 Сейчас в теме
(74) нормально. Действительно, для меня основная причина для свертки - увеличение времени бэкапа, реиндексации, обновления в структуре базы, тестирования и исправления и т.д.
77. Djonny 15.10.11 17:57 Сейчас в теме
Статья очень во время:) база 50Гб, хотел делать свертку! попробую сначала все оптимизировать! "+" однозначно
86. comol 4384 16.10.11 12:45 Сейчас в теме
Некластерный индекс по пометке удаления вообще не рассматриваем - ибо его селективность никакая.
Ну вам это кто сказал? Вы запустите как нибудь SQL Server Index tuneing - так для интереса, он с вами немного не согласится... вообще не понимаю почему 1С не добавят до сих пор штатного индекса...

Кластерный индекс (Пометка, Ссылка)
- преступление :).

3 - устал объяснять, вы опять ничего не поняли. Вы мыслите категориями администратора БД а не разработчика. Не нужна такая стратегия резервного копирования, и ситуация правда "гипотетическая"
2 - Ну конечно, только вас мы и будем слушать :)
1 - ну если у вас бывают "не случайные" аварии... то ИХМО надо весь отдел премий лишать :)
88. speshuric 1189 17.10.11 05:58 Сейчас в теме
(86)
Я вас не понимаю.

Вы предлагаете решение в рамках администрирования БД и жалуетесь, что вам отвечают в тех же понятиях и терминах. Я, кстати, вообще не администратор БД.

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

Вы путаетесь в показаниях про индекс по пометке удаления (даже без учета того, что 1С его не делает). Берём упомянутый вами справочник, в котором настроили "автоматическую пометку на удаление неиспользуемых объектов" и "отбор по умолчанию в программном коде для того чтобы не отображались по умолчанию не нужные пользователям объекты - помеченные на удаление". Какие индексы с участием пометки удаления будете создавать? Кластерные/некластерные, какие поля и в каком порядке входят, есть ли столбцы включаемые (INCLUDE) в индекс? Поможет ли этот индекс, когда непомеченных на удаление значительно больше, чем помеченных?

Кстати, к результатам DTA я отношусь крайне настороженно, потому что он нередко генерирует рекомендации на индексы, которые дублируют друг друга и плохо учитывает затраты на вставку/удаление записей и на хранение данных. Т.е. посмотреть "а не профукали ли где-нибудь индекс" можно, но генерить тупо индексы по рекомендациям стремно. Например, он может предложить 2 индекса с разным порядком колонок, которые сравниваются в запросах на равенство.
Yakov52; Sol; Michale; hogik; +4 Ответить
89. comol 4384 17.10.11 10:16 Сейчас в теме
(88) speshuric, Вы правы, вы меня не понимаете :). Вы сторонник стратегий "Из пушки по воробьям". Больше в дискуссии не вступаю. Сворачивайте базы в 0.5 ТБ могу только удачи вам пожелать :).
Вместо того чтобы писать "всё неправильно" могли бы лучше что-нибудь и правда полезное написать - про влияние секционирование на производительность (я так и не разобрался почему Microsoft пишут что в целом производительность запросов возрастет) и польза была бы, и знания свои показали бы.

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

P.S. Во все более-менее адекватные индексы пометку на удаление нужно вставлять, именно потому что помеченных на удаление намного больше чем не помеченных (справочники). Кластерный индекс в общем по полю с 2-мя значениями будет эффективен, а если там ID 1-м конечно уже не очень.
92. speshuric 1189 17.10.11 15:54 Сейчас в теме
(89)

Может всё-таки не затруднит ответить на 2 простых вопроса, которые я задаю третий раз, чтобы я наконец-то прозрел?

1.
speshuric пишет:
Вы так и не рассказали, как будете работать, если протеряете ФГ с архивными данными


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

Конкретику.
Кластерные/некластерные, какие поля и в каком порядке входят, есть ли столбцы включаемые (INCLUDE) в индекс? Поможет ли этот индекс, когда непомеченных на удаление значительно больше, чем помеченных?
Tbl4TblMBEK; VSOP_juDGe; hogik; +3 Ответить
93. comol 4384 17.10.11 17:01 Сейчас в теме
(92) speshuric,
1) Восстанавливать
2) Ищите индексы где присутствует _Folder и добавляете перед ним _Marked. В принципе то же самое помошник как правило советует.. ну на моих запросах...
94. hogik 435 17.10.11 17:18 Сейчас в теме
(89)
Олег.
А, и не надо вступать в дискуссии. ;-)
Еще раз, рекомендую Вам - потратить час своего времени и перечитать сообщения своих собеседников. Например вот это: "Я сам был и остаюсь противником свертки баз данных 1С."(с) из (73) сообщения.
Да. Вас трудно понять. Вы считаете, что: "Вы сторонник стратегий "Из пушки по воробьям"(с) и пытаетесь доказать, что "раздолбайство" - лучше... :-)
У мене такое впечатление, что Вашу фразу:
"В случае же если вы продаёте булочки или шариковые ручки, на вряд ли вам нужно..."(с)
http://infostart.ru/public/91880/
заменить на, примерно, такую фразу:
"Я продаю булочки или шариковые ручки, и мне ... не нужно...".
95. comol 4384 17.10.11 18:05 Сейчас в теме
(94) hogik, Владимир, надо признать что все кто продаёт не "булочки и ручки" работают не на 1С :). В 1С как speshuric писал у вас всё равно есть шанс получить противоречивые данные :).
96. hogik 435 17.10.11 19:23 Сейчас в теме
(95)
"надо признать что все кто продаёт не "булочки и ручки" работают не на 1С :)."(с)
Олег.
Вот - так? Запросто...
Взять и "нагадить в открытый рот" всем пользователям 1С-а и сообществу данного ресурса.
87. hogik 435 16.10.11 17:39 Сейчас в теме
В публикации ошибочный изначальный посыл, что:
1) Свертка БД делается, именно, из-за общего размера БД.
2) Основная цель (задачи) "Секционирования" решить проблему нехватки места на дисках.
3) Проблему (задачу) установки дополнительной дисковой памяти для сервера подменить размещением данных на "сетевом диске". В ущерб надежности и скорости.

Образно говоря, можно долго обсуждать нюансы и удобства использования фотоаппарата для забивки гвоздей, но... ;-)

Ставлю "минус" и под эту публикацию, для предостережения пользователей от безоглядного применения рекомендаций из данной "статьи". Надеюсь, что этот "минус" побудит читателя просмотреть комментарии к "статье". И насторожиться... ;-)
90. comol 4384 17.10.11 10:18 Сейчас в теме
(87) hogik, Владимир, я в вас не сомневался. Должен же кто-то "минус" ставить :).
91. ves_sergey 17.10.11 12:13 Сейчас в теме
В любом случае что-то в этом есть.
Evil Beaver; +1 1 Ответить
97. vovche 18.10.11 16:56 Сейчас в теме
хорошая статья, благодарю
98. Murom 18.10.11 18:31 Сейчас в теме
Очень полезная статья. Прочитал про секционирование БД, теперь надо бы протестировать как увеличится скорость если старые документы не обрезать, а по дате секционировать.
Можно ли как-то секционировать движения документов(У меня очень много документов установок цен) ?
99. comol 4384 18.10.11 21:42 Сейчас в теме
(98) Murom, Да, движения документов можно секционировать.... Но вот с установками цен это сложнее... вам там нужна по большому счету вся таблица... срез последних только индекс использовать будет.... Скорость опять же не увеличится ни в случае образения, ни в случае секционирования... Если только вы не планируете более быстрый дисковый массив (I/O Accelerator) поставить, и на него вынести только таблицу цен.
Оставьте свое сообщение

См. также

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    30102    MrWonder    42    

Анализ проблем производительности по динамике мониторинга RAS 1C

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

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

07.10.2020    3089    ivanov660    12    

Ускорение медленной работы строк в 1С на примере 1С:Документооборот КОРП

Производительность и оптимизация (HighLoad) v8 ДО Бесплатно (free)

Если у вас в 1С:Документооборот КОРП 2.1.11.5 (часть более старых и новых конфигураций): 1) Долго отправляется почта в формате HTML; 2) Медленно открывается документы внутренние / входящие / исходящие; 3) Тормозит область просмотра или открытие задач. Тогда вам сюда.

02.10.2020    3711    Nykyanen    16    

Тест скорости работы мобильной платформы 1С

Мобильная разработка Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

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

14.09.2020    1177    capitan    19    

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

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

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

22.04.2015    41273    Gilev.Vyacheslav    1    

Описание почти всех событий технологического журнала

Технологический журнал v8 Бесплатно (free)

Краткое описание событий технологического журнала с примерами. Все для быстрого старта.

19.08.2020    8378    YPermitin    30    

Адаптация автоматической классификации ошибок технологического журнала при появлении новых текстов и типов

Технологический журнал v8 1cv8.cf Бесплатно (free)

Корректируем классификацию ошибок ТЖ в процессе работы для конфигурации мониторинг производительности

17.08.2020    469    ivanov660    0    

SQL для 1С: пишем правильно, красиво, сложно

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Многие программисты боятся работать с Null, считая, что от этих данных в запросах нужно избавляться. О том, как с помощью Null-полей в запросе решать востребованные в учете задачи по выборке данных, на конференции Infostart Event 2019 Inception рассказал ведущий разработчик ГК WiseAdvice Дмитрий Дудин.

14.08.2020    10019    dmurk    30    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    67613    yuraos    112    

Нестандартные блокировки при работе с OLAP-нагрузкой

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Если выполнение отчета мешает работе других пользователей и провоцирует блокировки, даже с учетом «грязного чтения» – ситуация кажется парадоксальной. О том, как расследовать такие проблемы, на конференции Infostart Event 2019 Inception рассказали ведущий программист торгового дома «Петрович» Станислав Щербаков и специалист по производительности компании «СофтПоинт» Александр Денисов.

20.07.2020    2005    Филин    7    

Автоматическая классификация ошибок технологического журнала

Технологический журнал v8 1cv8.cf Бесплатно (free)

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

25.06.2020    2880    ivanov660    12    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

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

24.05.2020    7748    DataReducer    22    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

Производительность и оптимизация (HighLoad) v8 УТ10 УПП1 Бесплатно (free)

Не секрет, что многие пользователи, использующие партионный учет (а таких очень много, даже среди огромных холдингов, несмотря на пропаганду РАУЗ) при больших нагрузках сталкиваются с резким замедлением списания партий.

21.06.2013    55409    Антон Ширяев    117    

[SQL Server] Использование trace flag 9592 для сжатия траффика в кластере AlwaysOn

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

18.05.2020    2187    Aleksey.Bochkov    4    

Эти занимательные временные таблицы

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    12206    YPermitin    0    

Оптимизация запросов 1С посредством индексации временных таблиц. Миф? Тестируем, смотрим, считаем

Производительность и оптимизация (HighLoad) Практика программирования v8 Бесплатно (free)

Появилось свободное время, решил проверить на работе индексацию таблиц. Решил поделиться с Вами результатами исследования. Давайте порассуждаем на эту тему? Часто ли вы пользуетесь индексацией в запросах? Платформа 8.3.16.1224

03.04.2020    4720    feva    15    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    54914    Gilev.Vyacheslav    46    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    13447    informa1555    31    

Многострочный контекст событий

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

31.03.2020    3205    vasilev2015    9    

Анализ взаимоблокировок

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

20.03.2020    5341    vasilev2015    26    

Параллельные вычисления в 1С 8 Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    30175    gallam99    19    

Многопоточность

Практика программирования Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Увеличиваем скорость загрузки данных в 20 раз. Как следует использовать многопоточность и готовый модуль для внедрения.

18.03.2020    7416    kaliuzhnyi    43    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Производительность и оптимизация (HighLoad) v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    10179    Evil Beaver    13    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    42880    madmpro    32    

Оптимизатор запросов. Вторая часть

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

23.01.2020    6556    darkdan77    59    

Улучшаем производительность 1С. Рекомендации

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

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

23.01.2020    8138    Kaval88    26    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    12084    ivanov660    16    

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    7791    EugeneSemyonov    11    

Обслуживание баз данных. Не так просто, как кажется

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    18254    YPermitin    28    

Мониторинг высоконагруженной системы

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    9203    Repich    5    

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux

Администрирование данных 1С Zabbix v8 Бесплатно (free)

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    19001    Sloth    24    

Хранение файлов - как уменьшить размер базы данных

Чистка базы Производительность и оптимизация (HighLoad) Практика программирования Разработка v8 Россия Бесплатно (free)

Хранение файлов в базе 1С можно оптимизировать для уменьшения размера хранимых данных.

09.09.2019    8727    2tvad    17    

Неочевидные проблемы производительности: важность системного подхода при анализе

Производительность и оптимизация (HighLoad) v8 Россия Бесплатно (free)

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

19.07.2019    9086    Филин    12    

Ловля блокировок на связке "Microsoft SQL server - 1С"

Производительность и оптимизация (HighLoad) v8 v8::blocking Бесплатно (free)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    10260    fhqhelp    0    

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным

Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка v8 Бесплатно (free)

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

02.07.2019    11552    igordynets    119    

Ускорение чтения правил обмена в УПП 1.3 в 20 раз!

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Способ оптимизации чтения правил обмена конвертации данных. Может понадобиться при большом размере правил и высокой периодичности обмена.

27.06.2019    9963    YPermitin    17    

Хотите снизить нагрузку на процессор сервера в 2 раза?

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

27.06.2019    9962    Дмитрий74Чел    6    

Непридуманные истории по оптимизации. История 1

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

Первая статья из планируемого цикла об оптимизации приложений на базе 1С. Без теории. Одна практика.

13.06.2019    12843    Repich    117    

Оптимизация: неэффективные запросы

Производительность и оптимизация (HighLoad) Практика программирования Разработка v8 1cv8.cf Бесплатно (free)

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

13.06.2019    5983    slayer-ekb    10    

Многопоточное ускорение однопользовательских нагрузок в 1С + Microsoft SQL Server 2017

Практика программирования Производительность и оптимизация (HighLoad) v8 v8::Запросы Бесплатно (free)

Взаимодействие с Microsoft SQL Server нередко вызывает трудности у 1С-ников, а потому интересны любые моменты, связанные с его использованием. О своем опыте работы с новым SQL Server 2017 участникам конференции Infostart-2018 рассказал директор ООО «Аналитика софт» Дмитрий Дудин.

11.06.2019    25965    dmurk    146    

За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Мы расскажем и покажем, как добавить данные счетчиков производительности серверов 1С и MS SQL в нашу базу мониторинга за 15 минут. Приведем список наиболее важных из них, опишем основные особенности.

28.05.2019    20121    ivanov660    10    

Не думать о секундах свысока...

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Несколько примеров оптимизации типовой конфигурации УТ11. Описанные приемы подходят для многих других конфигураций.

21.05.2019    8081    vasilev2015    21    

Альтернативная стратегия управления блокировками

Производительность и оптимизация (HighLoad) v8 v8::blocking 1cv8.cf Россия Бесплатно (free)

Данная публикация освещает одну из альтернативных стратегий блокирования данных на уровне MS SQL Server, которая недоступна средствами 1С, но может быть весьма полезной. Разбирается практический пример.

20.05.2019    7271    zhichkin    15    

Как работают управляемые блокировки

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

29.04.2019    24018    comol    198    

Странное потребление места на диске С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Решение проблемы постоянного роста папки %AppData%/Local/Temp.

26.04.2019    14348    kuzyara    13