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

12.10.11

Целью данной статьи является "отговорить" от выполнения свертки БД пользователей клиент-серверного варианта 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С при свертке и всё... процедура заканчивается не удачно. А ошибки точно будут. Как "недостаточно памяти" при работе с ТЗ, так и ошибки вроде

Итоговая цифра получается 30-40 т. минимум против 20-25 в случае покупки жесткого диска, и получения 500 ГБ дополнительного места

Поэтому появляются продукты вроде //infostart.ru/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) Проблема большого объёма "ненужных данных", которые мешают работе пользователей

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

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

+456 –2

См. также

Поиск и анализ длительных вызовов - CALL, SCALL

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

Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.

24.06.2024 5124 ivanov660 12

Что не так с методом ЗаполнитьЗначенияСвойств

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.

06.06.2024 9250 Evg-Lylyk 61

[Замер] Кто самый быстрый в конфигураторе?

HighLoad оптимизация Механизмы платформы 1С Системный администратор Программист Стажер Платформа 1С v8.3 Бесплатно (free)

Сравним «Регистры сведений» с «Сервисами интеграции» и узнаем, кто быстрее!

28.03.2024 4999 dsdred 23

Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024 5088 spyke 28

Быстродействие типовой 1С

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024 7565 vasilev2015 20

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих запросов на sql, ожиданий, конвертация запроса в 1С и рекомендации, где может тормозить.

2 стартмани

15.02.2024 12405 241 ZAOSTG 80

115

Переход на Clickhouse для анализа метрик

HighLoad оптимизация Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Принимать, хранить и анализировать показания счетчиков (метрики) в базе 1С? Почему бы нет? Но это решение быстро привело к проблемам с производительностью при попытках построить какую-то более-менее сложную аналитику. Переход на PostgresSQL только временно решил проблему, т.к. количество записей уже исчислялось десятками миллионов и что-то сложное вычислить на таких объемах за разумное время становилось все сложнее. Кое-что уже практически невозможно. А что будет с производительностью через пару лет - представить страшно. Надо что-то предпринимать! В этой статье поделюсь своим первым опытом применения СУБД Clickhouse от Яндекс. Как работает, что может, как на нее планирую (если планирую) переходить, сравнение скорости работы, оценка производительности через пару лет, пример работы из 1С. Все это приправлено текстами запросов, кодом, алгоритмами выполненных действий и преподнесено вам для ознакомления в этой статье.

1 стартмани

24.01.2024 5662 glassman 18

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024 13975 doom2good 49

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

0. comol 5107 01.01.70 03:00 Сейчас в теме

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

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

1. hogik 443 12.10.11 04:02 Сейчас в теме

(0)
"Для файловых версий история тянется ещё с версии 1С 7.7 с ограничением в 2ГБ на размер базы. Сейчас ограничение 2ГБ уже только на размер таблицы, размер файла уже может получиться очень и очень не маленьким."(с)
В файловой версии 1С 7.7 нет ограничения на размер базы данных.

Ответить

15. comol 5107 12.10.11 10:59 Сейчас в теме

(1) hogik, Я конечно не эксперт по 7.7.. но вроде у dbf формата есть такое ограничение. Ссылку на источник не приведу и проверять лень, но как бы "везде на слуху"

2. hogik 443 12.10.11 06:54 Сейчас в теме

(0)
Очередной дельный совет: "если мало дисковой памяти, то ее надо увеличить".
Далее, автор представил себе сервер (!!!), где нет места для установки дополнительных дисков. И рассказал, как можно разнести информацию, аж, на сетевые диски. Используя средство предназначенное для повышения производительности. Да, "Microsoft не зря закрыли эту возможность"(с)...
Пояснения про индексы, трудно обсуждать (критиковать), т.к. есть приписка (оправдание): "там всё несколько сложнее"(с). Но, объяснение на "на птичьем языке"(с) впечатляет. Это, типа для тех у кого куриные мозги... :-)
Олег.
Основная причина (аргумент) для НеСворачивания БД это: "данные ненужными не бывают"(с), если ИС АвтоМехАнизирует не только "бухгалтерский" учет. А у НАС основные мотивы "не нравится "видеть документы за прошлые периоды"(с). Вот и сворачиваем, даже SQL-ные базы данных, при наличии свободной и достаточной дисковой памяти...

3. anton.fly7 174 12.10.11 07:03 Сейчас в теме

(2) объяснение, что не надо сворачивать, у ТС выглядит более аргументировано. что-то из статьи даже применю на практике
напишите более развернуто чтоли, а не издевательские вырывания цитат из контекста.

4. hogik 443 12.10.11 07:25 Сейчас в теме

(3)
Антон (anton.fly7).
А какие еще могут быть слова?
Автор пояснил, что если проблема в размере базы и нехватке дисковой памяти, то она легко решается. Рассказы об использовании сетевого диск интересные и познавательные. Но снижать скорость и надежность, думаю, не следует.
Причины для свертки базы, чаще выдвигаются по скорости и отсутствии причин для работы со "старой" информацией. Не знаю какие аргументы против сворачивания базы данных "у ТС"(с), но у меня пользователи желают иметь всю историю взаимодействия с "клиентами" и "товарами". В прошлой системе за 7 лет, в текущей за 11 лет. Т.е. за всё время жизни компании...

5. anton.fly7 174 12.10.11 08:00 Сейчас в теме

(3) ну так если вам нужны данные за 11 лет, то вы тоже против сворачивания базы? И что вы будете делать, когда база не влезет на диски? Ии запросы тупить? Автор обозначил свой план де.ствий

6. alexk-is 6544 12.10.11 08:53 Сейчас в теме

(5) Запросы не тупят. Просто пишутся они в типовых конфигурациях для "типовых" баз. Если база большая и где-то возникают проблемы связанные с производительностью, то необходимо просто переписать некоторые запросы и всё.

У нас база УПП за 6 лет. Сворачивать не собираемся.

7. anton.fly7 174 12.10.11 08:55 Сейчас в теме

(6) я и не утверждал что у вас проблемы с ИС
>> что вы будете делать, когда база не влезет на диски ?

8. alexk-is 6544 12.10.11 09:04 Сейчас в теме

(7) Перенесу ежедневные архивы за прошлый год на другой ПК, но это понадобится только через 10 лет, а к тому времени уже можно будет менять сам сервер. :)

9. anton.fly7 174 12.10.11 09:11 Сейчас в теме

(8) ок ) ая хочу попробовать вынести некоторые таблицы на другой диск ) например SSD

10. alexk-is 6544 12.10.11 09:23 Сейчас в теме

(9) http://forum.infostart.ru/forum24/topic38601/message446717/#message446717

11. comol 5107 12.10.11 10:54 Сейчас в теме

(9) anton.fly7, Вот так и делали... очень помогает основные "товарные" регистры даже если только перекинуть... регистры бухгалтерии.. на порядок растёт производительность... особенно "неправильных" запросов

13. comol 5107 12.10.11 10:55 Сейчас в теме

(3) anton.fly7, он просто будет писать всегда "против", чтобы я не написал :)

14. anton.fly7 174 12.10.11 10:57 Сейчас в теме

(13) тролит? ) я еще твой жж читаю, откуда ты столько много знаешь???

22. comol 5107 12.10.11 11:31 Сейчас в теме

(14) anton.fly7, СПС. да знаете... когда что-то случается жизнь заставляет узнавать :). В ЖЖ там чуть больше.. здесь только то что 1с касается выкладываю..

16. comol 5107 12.10.11 11:03 Сейчас в теме

(2) hogik,

Улыбнуло

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

Господа, объясните ему пожалуйста :). Что внешние дисковые массивы, SAN, NAS не просто так для развлечения люди придумали :). Что нормальный RAID массив требует около 9 дисков, и что сервера давно уже не делают вместе с "коробкой для дисков".... как-то прошли те времена :)

46. hogik 443 12.10.11 18:43 Сейчас в теме

(16)
Олег.
Ну, давайте, пожалуйста читать друг-друга! ;-)
Это же Вы написали:
"Естественно могут быть проблемы отсутствия места под новые жесткие диски в самом сервере... "(с)
Или, я это написал?
Лично, мне представляются странным разговор о скорости и предложение:
"разместить файлы БД на сетевом диске"(с)
И еще раз повторю - нехватка места на жестком диске не являться основной причиной (поводом) для свертки базы данных.
Т.к. см. (6),(8) сообщения. Или Ваше, же утверждение:
"Увеличение доступного для БД дискового пространства обойдётся нам в 20 т.р. + 10 минут работы специалиста. "(с)
Т.е. суть Вашей публикации - рассказать о "Management Studio" с искусственной привязкой к "проблеме" свертки базы данных 1С.
Про "Management Studio" - спасибо за информацию...

49. comol 5107 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 443 14.10.11 17:14 Сейчас в теме

(49)
"hogik, Владимир ... Не пишите пожалуйста больше ваших комментариев, они смущают людей."(с)

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

Написал тут: http://infostart.ru/public/94437/

71. comol 5107 14.10.11 17:32 Сейчас в теме

Господа, у кого 7-ка статья (70) наверное будет интересна. У кого 8-ка про "СУБД-Строение" я бы не стал читать.
Все мои предложения проверялись только под 1С 8, для 1С 7.7 может и вправду свертка полезна...

72. hogik 443 14.10.11 18:52 Сейчас в теме

(71)
Олег.
В моей статейке нет призыва: "сверните БД". :-)
Я не пытаюсь противопоставить свертку БД средствам "Management Studio".
Иначе бы, и под эту публикацию поставил "минус"...

12. fomix 33 12.10.11 10:55 Сейчас в теме

Интересно и познавательно. Могёт быть и придется воспользоваться описанными в статье мерами. Автору за статью "+". Не у каждого найдется время так обстоятельно написать о проблеме разрастания и тормозах в 1С и способах ее решения...

17. пользователь 12.10.11 11:14

Сообщение было скрыто модератором.

...

18. cool.vlad4 2 12.10.11 11:18 Сейчас в теме

(17) программисту надо платить зарплату и он должен знать ms sql, причем в плане администрирования

20. comol 5107 12.10.11 11:29 Сейчас в теме

(18) cool.vlad4, Это перевод (17)?

23. cool.vlad4 2 12.10.11 11:35 Сейчас в теме

(20) Нет, конечно, - ответ.
Примерный перевод
В этом что-то есть, но в 50-60% случаях и свертка подойдет. А в организации где есть сервер и база больше 500Гб, работа сильно завязана на БД , поэтому в штате должен быть программист, которому не надо платить 30 -40 тыс.

25. comol 5107 12.10.11 11:38 Сейчас в теме

(23) cool.vlad4, А... ну тогда надо "+" поставить :)

27. cool.vlad4 2 12.10.11 11:40 Сейчас в теме

(25) ~~я уже как 15 минут назад это сделал)))~~ А это ты мне...не понял, спросонья)))

19. cool.vlad4 2 12.10.11 11:21 Сейчас в теме

(0) А есть какая-то статистика? Или это все на теоретическом уровне? (14) наверное книжки умные читает

PS В любом случае зачот.

24. comol 5107 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 2 12.10.11 11:40 Сейчас в теме

(24) собственно, читаешь мои мысли, - как раз на production как-то стремно это делать(именно для 1С).

29. comol 5107 12.10.11 11:58 Сейчас в теме

(26) cool.vlad4, Нуу... Гилёв вроде писал что делал на production. Я лично верю в технологии MS :). В плане что физический уровень на логический не повлияет.

21. anton.fly7 174 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 сервере(основная, итоги и регистрация изменений) и как применить секционирование к таблицам регистрации изменений, в какие файловые группы их помещать и как они могут влиять на производительность я так и не понял.

34. comol 5107 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 5107 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 5107 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 5107 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 4790 12.10.11 12:26 Сейчас в теме

Свёртки свёртками, но запросы "тупят" гораздо чаще по другим причинам - написаны криво или в расчёте на малые объёмы. Когда дописыванием четырёх букв в текст запроса он ускоряется с 1.5 часов до 7 минут - это не требует комментариев. Притом, что исходный запрос принадлежит авторству АОЗТ "1С". :)

32. Medvedik 12.10.11 13:00 Сейчас в теме

(31)Пример приведите пожалуйста. Не то что бы я вам не доверял, но правила хорошего тона...

35. comol 5107 12.10.11 14:07 Сейчас в теме

(31) Yashazz, ну это да... просто это уже "избитая" тема :)

47. WellMaster 104 12.10.11 21:00 Сейчас в теме

(31)(35), Поясните, плз.

48. comol 5107 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 443 13.10.11 00:58 Сейчас в теме

(48)
Олег.
Вопрос не в тему. А как получить доступ к содержанию этих ссылок?

51. comol 5107 13.10.11 01:04 Сейчас в теме

(50) hogik, Это с франчайзи договориться... :) ну или в открытых источниках можно Книжку "Профессиональная разработка" А.Габец-а скачать. Там в 7 главе почти всё это есть.

52. hogik 443 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 5107 13.10.11 11:54 Сейчас в теме

(57) WellMaster, Это конфигурация, по-моему даже не типовая.

33. Maks_Payn 12.10.11 13:51 Сейчас в теме

Еще можно было бы добавить про "Создание недостающих индексов" для повышения скорости выполнения запросов ))

36. comol 5107 12.10.11 14:09 Сейчас в теме

(33) Maks_Payn, Я старался уложиться в рамки лицензионного соглашения 1с... а индексы это уже операции с данными - это уже точно нарушение...

41. artbear 1563 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 1563 12.10.11 16:16 Сейчас в теме

(38) Блокировки слабо зависят от размера базы.
Автор как раз и говорит о том, что размер базы на самом деле на производительность работы почти не влияет :)

42. comol 5107 12.10.11 16:34 Сейчас в теме

(38) владимирп, Про блокировки я другие статьи писал... не от размера базы они...

40. artbear 1563 12.10.11 16:17 Сейчас в теме

Я также противник свертки всю свою сознательную жизнь на 1С.
Поэтому статью считаю полезной. Плюсанул.
ЗЫ ни разу не сворачивал базу, даже не пытался это пробовать :)

44. dkprim 5 12.10.11 17:17 Сейчас в теме

отличная статья. возьму себе на заметку обязательно приведенные в публикации методики :)

53. CheBurator 2712 13.10.11 02:46 Сейчас в теме

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

54. ValeriTim 21 13.10.11 09:55 Сейчас в теме

(0) Очень интересно. Побольше бы таких статей. Оставил закладку - потом поковыряюсь

55. vec435 17 13.10.11 10:05 Сейчас в теме

у нас база больше 100 Гб,просто добавили дискового пространства.информация в статье очень полезная

56. Zoomby 13.10.11 10:12 Сейчас в теме

статья полезная, так что закладочка.

59. Vladimir_D 122 14.10.11 07:17 Сейчас в теме

Про файловые группы очень понравилось! Надо будет что-нить порыскать на PostgresSQL.
Спасибо автору за труд!

61. comol 5107 14.10.11 10:27 Сейчас в теме

(59) den_vladimir, Где-то в комментариях вроде приводилась статья по PostgresSQL с тем же самым...

60. Vladimir_D 122 14.10.11 07:44 Сейчас в теме

Я так понимаю, файловые группы в экспресс версии не поддерживается?

62. comol 5107 14.10.11 10:28 Сейчас в теме

(60) den_vladimir, Так и 1С вроде с Express Версией не работает... если просто протестить хотите там вроде Developer версия есть, в которой всё поддерживается...

63. Medvedik 14.10.11 11:11 Сейчас в теме

(62) В экспрессе ограничение на объем базы и количество процов, а так-то 1С работает с ней

73. speshuric 1338 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), репликацию транзакций (забыв что не везде есть первичный ключ) и т.п.

Ответить

76. comol 5107 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, раз уж он вам ближе.

- посмотрел, период первый :)

Вообщем итог - замечание по поводу того что поле "пометка на удаление" не индексировано принимается. Я ручками индекс ставил - уже забыл..., всё остальное - "рассуждения на тему"

78. speshuric 1338 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 значениями? Эффективно? И что, правда сам в план попадает без хинтов?

Ответить

81. comol 5107 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 1338 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)

Кластерный индекс с первым полем пометки удаления или со вторым? Если со вторым, то не будет использоваться для отбора в принципе, если с первым, то это обрушит производительность 1С, потому что, например, "Таблица.Поле.ПолеПоля" будет создавать левое соединение без условия на пометку удаления.
В итоге варианты:

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

comol пишет:
в DAX, к примеру, все индексы таблицы остатков содержат поле CLOSED с двумя значениями.

Не путайте теплое с мягким. Я не против добавления флагов в конец индекса. Это позволит реже доставать данные из кучи или из кластерного индекса. Но это не особо ускорит запрос с отбором только по этому полю, index seek не будет возникать (кроме вырожденных случаев).

80. speshuric 1338 15.10.11 20:10 Сейчас в теме

(76)Кстати, если у вас на полный бэкап

30 минут это очень удачный расклад...

, то почему не используете сжатие бэкапов? Если затык на подсистеме ввода-вывода, то сжатие бэкапов очень ускоряет.

82. comol 5107 16.10.11 00:47 Сейчас в теме

(80) speshuric, Так вообщем-то не напрягает.. Backup на сетевой диск. Процессорное время пока самое узкое место.

79. hogik 443 15.10.11 19:31 Сейчас в теме

(73)(78)
Alexander (speshuric).
Браво!!!
Такие аргументы достойны отдельной Публикации.
Спасибо за Ваш труд...

83. comol 5107 16.10.11 00:49 Сейчас в теме

(79) hogik, Владимир, человек хотя бы со знанием дела и по сути даже кое-что пишет :)

84. hogik 443 16.10.11 01:09 Сейчас в теме

(83)
Олег.
Извините, не в тему напишу.
Если человек точно знает, что 2*2=4, и утверждает, что 2*2*х=4, только на основании того, что 2*2 используется в обеих формулах. То я сначала пытаюсь обратить его внимание на наличие "х", а потом разговаривать про 2*2.
А Alexander (speshuric) поступил иначе. И сделал это отлично!

74. speshuric 1338 15.10.11 13:19 Сейчас в теме

упс... не ожидал, что так дофига получится :)

75. anig99 2852 15.10.11 13:38 Сейчас в теме

(74) нормально. Действительно, для меня основная причина для свертки - увеличение времени бэкапа, реиндексации, обновления в структуре базы, тестирования и исправления и т.д.

77. Djonny 15.10.11 17:57 Сейчас в теме

Статья очень во время:) база 50Гб, хотел делать свертку! попробую сначала все оптимизировать! "+" однозначно

86. comol 5107 16.10.11 12:45 Сейчас в теме

Некластерный индекс по пометке удаления вообще не рассматриваем - ибо его селективность никакая.

Ну вам это кто сказал? Вы запустите как нибудь SQL Server Index tuneing - так для интереса, он с вами немного не согласится... вообще не понимаю почему 1С не добавят до сих пор штатного индекса...

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

- преступление :).

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

88. speshuric 1338 17.10.11 05:58 Сейчас в теме

(86)
Я вас не понимаю.

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

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

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

Кстати, к результатам DTA я отношусь крайне настороженно, потому что он нередко генерирует рекомендации на индексы, которые дублируют друг друга и плохо учитывает затраты на вставку/удаление записей и на хранение данных. Т.е. посмотреть "а не профукали ли где-нибудь индекс" можно, но генерить тупо индексы по рекомендациям стремно. Например, он может предложить 2 индекса с разным порядком колонок, которые сравниваются в запросах на равенство.

89. comol 5107 17.10.11 10:16 Сейчас в теме

(88) speshuric, Вы правы, вы меня не понимаете :). Вы сторонник стратегий "Из пушки по воробьям". Больше в дискуссии не вступаю. Сворачивайте базы в 0.5 ТБ могу только удачи вам пожелать :).
Вместо того чтобы писать "всё неправильно" могли бы лучше что-нибудь и правда полезное написать - про влияние секционирование на производительность (я так и не разобрался почему Microsoft пишут что в целом производительность запросов возрастет) и польза была бы, и знания свои показали бы.

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

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

92. speshuric 1338 17.10.11 15:54 Сейчас в теме

(89)

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

1.

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

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

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

93. comol 5107 17.10.11 17:01 Сейчас в теме

(92) speshuric,
1) Восстанавливать
2) Ищите индексы где присутствует _Folder и добавляете перед ним _Marked. В принципе то же самое помошник как правило советует.. ну на моих запросах...

94. hogik 443 17.10.11 17:18 Сейчас в теме

(89)
Олег.
А, и не надо вступать в дискуссии. ;-)
Еще раз, рекомендую Вам - потратить час своего времени и перечитать сообщения своих собеседников. Например вот это: "Я сам был и остаюсь противником свертки баз данных 1С."(с) из (73) сообщения.
Да. Вас трудно понять. Вы считаете, что: "Вы сторонник стратегий "Из пушки по воробьям"(с) и пытаетесь доказать, что "раздолбайство" - лучше... :-)
У мене такое впечатление, что Вашу фразу:
"В случае же если вы продаёте булочки или шариковые ручки, на вряд ли вам нужно..."(с)
http://infostart.ru/public/91880/
заменить на, примерно, такую фразу:
"Я продаю булочки или шариковые ручки, и мне ... не нужно...".

95. comol 5107 17.10.11 18:05 Сейчас в теме

(94) hogik, Владимир, надо признать что все кто продаёт не "булочки и ручки" работают не на 1С :). В 1С как speshuric писал у вас всё равно есть шанс получить противоречивые данные :).

96. hogik 443 17.10.11 19:23 Сейчас в теме

(95)
"надо признать что все кто продаёт не "булочки и ручки" работают не на 1С :)."(с)
Олег.
Вот - так? Запросто...
Взять и "нагадить в открытый рот" всем пользователям 1С-а и сообществу данного ресурса.

87. hogik 443 16.10.11 17:39 Сейчас в теме

В публикации ошибочный изначальный посыл, что:
1) Свертка БД делается, именно, из-за общего размера БД.
2) Основная цель (задачи) "Секционирования" решить проблему нехватки места на дисках.
3) Проблему (задачу) установки дополнительной дисковой памяти для сервера подменить размещением данных на "сетевом диске". В ущерб надежности и скорости.

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

Ставлю "минус" и под эту публикацию, для предостережения пользователей от безоглядного применения рекомендаций из данной "статьи". Надеюсь, что этот "минус" побудит читателя просмотреть комментарии к "статье". И насторожиться... ;-)

90. comol 5107 17.10.11 10:18 Сейчас в теме

(87) hogik, Владимир, я в вас не сомневался. Должен же кто-то "минус" ставить :).

91. ves_sergey 17.10.11 12:13 Сейчас в теме

В любом случае что-то в этом есть.

97. vovche 18.10.11 16:56 Сейчас в теме

хорошая статья, благодарю

98. Murom 18.10.11 18:31 Сейчас в теме

Очень полезная статья. Прочитал про секционирование БД, теперь надо бы протестировать как увеличится скорость если старые документы не обрезать, а по дате секционировать.
Можно ли как-то секционировать движения документов(У меня очень много документов установок цен) ?

Оставьте свое сообщение

E-mail:

Автор:

Олег Филиппов (comol)

Рейтинг: 5107

Для получения уведомлений о новых публикациях автора подключите телеграм бот: Инфостарт бот

Публикация:

№ 94040

Создание 12.10.11 00:08

Обновление 12.10.11 00:16

Статистика:

Просмотры 85214

Загрузки 0

Рейтинг 454

Комментарии 189

Характеристики:

Код открыт Не указано

Рубрики HighLoad оптимизация

Кому Системный администратор ,
Программист

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

Платформа Платформа 1С v8.3

Конфигурация Конфигурации 1cv8

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

Страна Россия

Отрасль Не имеет значения

Налоги Не имеет значения

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

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