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

12.10.11

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



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

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

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

См. также

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

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

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

13.03.2024    2977    spyke    26    

42

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

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

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

13.03.2024    5108    vasilev2015    19    

37

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

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

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

1 стартмани

15.02.2024    7636    158    ZAOSTG    68    

96

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

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

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

09.01.2024    5977    doom2good    48    

63

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8868    ivanov660    6    

76

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    5105    a.doroshkevich    20    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    16184    skovpin_sa    14    

98
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
99. comol 5051 18.10.11 21:42 Сейчас в теме
(98) Murom, Да, движения документов можно секционировать.... Но вот с установками цен это сложнее... вам там нужна по большому счету вся таблица... срез последних только индекс использовать будет.... Скорость опять же не увеличится ни в случае образения, ни в случае секционирования... Если только вы не планируете более быстрый дисковый массив (I/O Accelerator) поставить, и на него вынести только таблицу цен.
100. Murom 19.10.11 10:23 Сейчас в теме
(99) Спасибо. Т.Е. как я понял документы лежат в одой таблице и её можно секционировать. А движения в другой таблице и (в нашем случае по ценам) "срез последних" это не отдельная таблица а обращение к индексу?
102. comol 5051 19.10.11 13:54 Сейчас в теме
(100) Murom, да. Только не забудьте секционирование - только в Enterprise Ms SQL
156. МихаилМ 12.04.18 15:50 Сейчас в теме
(98) перечитайте (73) внимиательно
101. dyh 4 19.10.11 11:25 Сейчас в теме
1С вообще веселая штука. Постоянные переходы с версии на версию и с частичной потерей данных - то с 77 на 80, потом на 81, потом 82, щас вот 82.14 аля 83. я уж не говорю о конфигурациях и переходах с различных редакций...
103. comol 5051 19.10.11 13:57 Сейчас в теме
(101) dyh, Самое главное переходить когда есть реальная потребность :) и думать сразу как бы "вернуться обратно"... они нас этому уже научили :)
104. Fr1eNd_Tver 20.10.11 10:52 Сейчас в теме
Прочитал всю статью, понял что мою базу 7 ГБ свертывать точно не надо, сейчас собираемся в 1С хранить всю первичку в pdf, в Хранилище значений, как сильно это повлияет на объем базы?
105. cool.vlad4 2 20.10.11 11:14 Сейчас в теме
(104) сложно сказать, вам просто стоит самим рассчитать, сделать pdf, прикинуть количество доков и т.д. посоветую лишь грамотно, если есть возможность(поскольку есть вариант что это невозможно), формировать или сжимать pdf...тексты довольно хранятся...стандартный документ в 2 страницы - 67 кб например.
107. comol 5051 20.10.11 11:54 Сейчас в теме
(104) Fr1eNd_Tver, думаю не сильно. Но если повлияет вы теперь знаете что делать ;)
119. svemne 44 16.11.11 23:25 Сейчас в теме
(104) Fr1eNd_Tver, хранили как-то сканы документов в базе. За несколько месяцев бэкап распух с 3 до 6 гигабайт.
Быстренько все прикрыли. В конце-концов было реализовано внешнее хранилище данных на FTP сервере.

Живет себе уже 9 месяцев, данные собирает.
121. comol 5051 30.11.11 10:21 Сейчас в теме
(119) svemne, (104) Fr1eNd_Tver Вот так обычно "1С - ники" и делают. И к примеру Аксаптеры над нами смеются. Просто табличку на отдельный диск перекладываете и всё.. и бэкап делаете файловых групп...
106. yuriyscr 18 20.10.11 11:24 Сейчас в теме
Интересно - автор статьи пробовал переписать конфигурацию в 1с 7.7 для использования прямых запросов (1срр)?
Это значительно ускоряет работу и объем баз 50-100Гиг становится незаметен.
Хотя при этом усложняются бэкапы, загрузки/выгрузки и вероятность дисковой ошибки.
108. comol 5051 20.10.11 11:55 Сейчас в теме
(106) yuriyscr, автор статьи 1С 7.7 видел пару раз и теперь вспоминает только как кошмарный сон :)
109. yuriyscr 18 20.10.11 13:22 Сейчас в теме
За деньги клиента мы регулярно смотрим такие кошмарные сны... :)
110. dandrontiy 25.10.11 10:30 Сейчас в теме
Вот бы автоматизировать процесс разнесения таблиц на разные дисковые массивы.
Ведь можно собрать автоматизированно статистику с сервера. И потом сделать разнесение.
Это было бы шедеврально!
111. yushmakovmv 25.10.11 10:40 Сейчас в теме
Да 8.2.14 тот еще релиз. Слышал, многие предпочитают откатываться назад на 13.
112. anig99 2843 25.10.11 19:17 Сейчас в теме
(111) устаревшая информация
113. Kom-off 25.10.11 19:44 Сейчас в теме
(112) Я бы не сказал, что устаревшая. И про "отказываются" из (111) тоже бы сказал бы мягче - выжидают и опасаются.
114. comol 5051 26.10.11 11:31 Сейчас в теме
(113) Kom-off, Ну знаете 14.537 вроде работает... в случае если 1 раб. процесс достаточно стабильно... а более 1-го я уже с 12-го или с 13-го релиза не решался добавлять..
120. svemne 44 16.11.11 23:28 Сейчас в теме
(111) yushmakovmv, конечно откатываются, если размер пакета при обмене в распределенке равен 1 гигабайту.
115. shamant 4 28.10.11 01:10 Сейчас в теме
Спасибо, очень полезная статейка ) хоть уже и не новость
+1
116. Murom 07.11.11 23:21 Сейчас в теме
Пытаюсь перенести 1 большую таблицу (12 ГБ) на другой раздел. получаю вот такую ошибку
\'_Document5866_VT5869' table
- Unable to modify table.
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

Что можно предпринять ?
118. German 413 16.11.11 12:11 Сейчас в теме
(116)
Timeout expired
Сервер не ответил вашему инструменту в течении таймаута (по умолчанию в 30 секунд для ADO) увеличьте таймаут
117. German 413 16.11.11 12:09 Сейчас в теме
Вот обещанный автору инструмент по управлению секциями http://blog.1c-ei.ru/2011/11/221.html
122. comol 5051 30.11.11 10:22 Сейчас в теме
(117) German, да... удобно, но страшно :)
123. popovalex 17 06.01.12 15:03 Сейчас в теме
Очень интересно. Завтра проверю на практике
124. Масянечка 07.01.12 13:42 Сейчас в теме
А для sql server 2000 что посоветуете? Спасибо.
126. comol 5051 27.01.12 00:53 Сейчас в теме
(124) Светялчок, Для SQL server 2000 переходить на 2005/8 :). Им пользоваться уже нельзя ИХМО
127. Масянечка 27.01.12 13:32 Сейчас в теме
(126) ))))) Почему нельзя-то? Лицензия-то куплена...
128. comol 5051 28.01.12 20:28 Сейчас в теме
(127) Светялчок, Потому что убогий механизм блокировок, убогая статистика, ужасное резервное копирование... неправильная работа с памятью. Если говорить про работу с 1С, то наверное последняя версия PostgreSQL в случае управляемых блокировок была бы более приемлемым выбором. Или, если всё-таки заботитесь о базе, покупать апгрейд лицензции на 2008. Это по-моему намного дешевле чем просто покупка 2008.
125. ybeleckii 24.01.12 18:48 Сейчас в теме
ошибка в описании команд надо кавычки поставить
у тя
create partition scheme YearScheme
as partition YearSection to (SECONDARY, PRIMARY);
надо
create partition scheme YearScheme
as partition YearSection to ('SECONDARY', 'PRIMARY');
а то пишет ошибку
а так всё гут
130. пользователь 01.03.12 20:19
Сообщение было скрыто модератором.
...
131. awk 741 26.03.12 19:23 Сейчас в теме
Страшна ли база в 80 Гб (1С 8.2)? Я думаю не страшна. А начальство боится и говорит бэкап по сетке долго копируется. Но я все равно не пойму логику хранения товаров по заказам и по реализациям в одной таблице. Может я не прав?
132. comol 5051 26.03.12 19:37 Сейчас в теме
(131) awk, Если косяков в индексах нет - не страшна.
133. awk 741 26.03.12 20:54 Сейчас в теме
(132) Я то же думаю не страшно. Как обосновать? До этого была база +25 терабайт прироста в год. И как-то с бэкапили. Правда база уже была не SQL, а файловая. SQL не справлялся с требованиями скорости обработки данных.
134. comol 5051 27.03.12 00:29 Сейчас в теме
+25 терабайт в год файловая база?!!!!!!!!!!!!!! Я хочу посмотреть на ЭТО!!!!!!!
135. awk 741 27.03.12 00:46 Сейчас в теме
(134) Устройся в гугл, яндекс, майл.ру и т.п. - у них статистика рунета примерно этот объем занимает. Ни о каких SQL речи там не идет - не справляются. Правда и кодят там на Си.
136. comol 5051 27.03.12 10:54 Сейчас в теме
(135) awk, Так там и задачи другие... там не транзакционная система, и СУБД по другому принципу совсем работает логично что у них свои. И индексы полнотекстовые это совсем не те индексы... Транзакционная СУБД конечно тоже справится с такими объемами но тут скорее уже oracle или terradata... А вот как 1С-ка на 25 ТБ файловой базе работала бы... Если бы вы не написали - не поверил бы что такое возможно...
137. awk 741 27.03.12 12:03 Сейчас в теме
(136) В том то и дело, что транзакционные. +1 млн. запросов в секунду. И свертка происходит ежегодно. Хотя база и не реляционная, а объектная.

1С некие пытаются туда прикрутить.
138. comol 5051 27.03.12 16:34 Сейчас в теме
(137) awk, Если бы поисковики были транзакционными системами в полном смысле этого слова мы бы с вами гугл пару суток ждали :))) (см. мою статью о блокировках). Поэтому 1С туда конечно жестко... да ещё в файловом варианте. А работает?
139. awk 741 27.03.12 17:33 Сейчас в теме
(138) Нет, 1С не работает.... :)
Если бы поисковики были транзакционными системами в полном смысле этого слова мы бы с вами гугл пару суток ждали :)))
Я не про поисковики. Я про показы баннеров. Там транзакционная система в полном смысле этого слова. Не фиксированный показ баннера - убыток. Регистрация не показанного баннера - убыток, и т.д.

Требования:
Рост базы - 25 Тб в год
Количество запросов в секунду - 1 млн.
140. Varies 29.05.12 14:09 Сейчас в теме
А странно что в статье не упоминается такой фактор как "Идёт налоговая проверка, не хотим чтобы они видели тот-то год". Делить базу по годам можно не примитивной "сверткой базы" с кучей ошибок, а вводом начальных остатков, без всяких там ошибок. Но конечно если бухгалтерия скажем согласна на то что прийдя проверять 2010 год налоговики видят всё что было раньше и позже, то конечно оптимизация таблиц SQL рулит :)
141. comol 5051 29.05.12 15:06 Сейчас в теме
(140) Varies,
1) Хотел бы я посмотреть на базу бухгалтерии в 40 ГБ :). Бухгалтерию ИХМО нужно вести в отдельной базе, и если движений много то в бухгалтерии ненужные сворачивать
2) если бухгалтер собирается показывать плановой налоговой проверке бухгалтерскую базу такого бухгалтера нужно увольнять ИХМО. Базу это только если "маски шоу" нагрянут...
3)
не примитивной "сверткой базы" с кучей ошибок, а вводом начальных остатков, без всяких там ошибок
улыбнуло :).
142. Levran123 5 18.06.12 14:20 Сейчас в теме
(141)
2) если бухгалтер собирается показывать плановой налоговой проверке бухгалтерскую базу такого бухгалтера нужно увольнять ИХМО. Базу это только если "маски шоу" нагрянут...

Как показывает, моя, практика базы именно на случай "масок" и сворачивают.

ИМХО если есть возможность базу не сворачивать - то и не надо её трогать. А свертку производить раз в несколько лет (у кого как) при переходе на новую учетную систему (хочешь не хочешь. но раз в 5-10 лет надо)
143. VallyD 13.03.13 13:29 Сейчас в теме
Замечательная статья. Спасибо за проделанную работу. Хотя аргументы автора очень убедительны, но мне к сожалению свертки никак не избежать. Вдвойне обидно, что надо будет несколько дней "извращаться" над базой, из-за того, что название отдельных позиций номенклатуры в прошлом году должны быть менее детализированы. Сложно объяснить бухгалтеру, что ошибок при свертке избежать очень трудно. Они привыкли еще с 7.7 каждый год сворачивать данные. Вот и сейчас пристали. ((((
144. mec 18.03.13 11:46 Сейчас в теме
Очень полезный совет про сжатие, в случаях когда база действительно велика, и в ней используются огромные таблицы. В таких случаях диски загибаются, на них создаются огромные очереди (далеко не 3-4). Воспользовался советом и сжал не всю базу, а только огромные по размерам таблицы. Итог, база в 2 раза меньше, диски теперь справляются с нагрузкой по чтению данных. Всю базу сжимать не стал, так как процессор итак прилично нагружен. А вот частичное сжатие мне сильно помогло. Автору спасибо за идею! Проверил на своей базе - эффективно работает.
145. ozaycev 146 02.04.13 23:04 Сейчас в теме
Не всегда это поможет. В моем случае веселее, база за год вырастает до 500 гиг. Суть не в том - что с ней делать, разделять, сжимать не вариант. Такое обслуживание базы наверное не реально. Остается свертка. Как свернуть такую базу если у тебя есть всего сутки.
Специально писал обработку под эту задачу. Свернул базу 560 гиг примерно за 18 часов. Мелкие базы сворачиваются буквально за 15-20 минут.
http://infostart.ru/public/166388/
unoDosTres; +1 Ответить
146. bzmax 09.04.13 12:49 Сейчас в теме
Хорошая статья. Минус только в том что как СУБД рассматривается только "скуль мелкомягких".
Неплохо подобное описание и для DB2, и Oracle, и Postgre
147. BalVlad 16.04.13 16:17 Сейчас в теме
Присоединяюсь. Хотелось бы увидеть описание на PostGre.
148. g26516 16.07.14 08:35 Сейчас в теме
Хорошо, когда у предприятия есть средства на все нововведения программистов
KapasMordorov; +1 Ответить
149. zoytsa 29.01.15 13:45 Сейчас в теме
1C при создании наборов записей регистров, подчиненных регистратору,
при записи документа делает SELECT с отбором по регистратору. Есть ли возможность осуществить "partition elimination" в данном случае - чтобы при чтении таблицы документов использовался только раздел, соответствующий, а не шло чтение всех секций? В противном случае, к примеру, пометка на удаление документа (с удалением всех связанных с ним записей в регистры) значительно затягивается (буквально на 3-4 минуты при объеме базы в 1 Тб и расположении секций по годам в сети на 100 Мбит). С отчетами, где есть запросы с отбором по периоду - вопросов нет, все четко.

Возможно ли секционирование по регистратору?

150. zoytsa 31.01.15 10:45 Сейчас в теме
Ауу, ребят, кто секционривал большие базы - сталкивались ли с зависаниями при проведении/отмене проведения? Как решали проблему partition elimination - т.к. отбор в запросах SQL идет в данных операциях по регистратору, а не по периоду?
151. nofx 01.04.16 12:06 Сейчас в теме
Не могу найти свойство таблицы sql, где меняется файловая группа Primary на Secondary..
Выбираю таблицу - > Проект -> Конструктор таблиц ...
Версия CУБД: 2008 R2

Прикрепленные файлы:
157. nicxxx 254 31.08.18 16:08 Сейчас в теме
(151) В кластерном индексе
152. Nx6600 20 07.06.16 14:17 Сейчас в теме
154. sokir 2 10.02.17 16:58 Сейчас в теме
(152) наверно уже неактуально, но все таки - на пустом месте ПКМ, свойства и справа появится окно свойств.
153. sokir 2 10.02.17 16:55 Сейчас в теме
Очень полезная и доходчивая статья.
Ворчунам вход запрещен!
155. Ski4life 12.04.18 13:35 Сейчас в теме
Народ, что за беда, секционирую таблицу как показано в статье, но в результате действий изменения размеров файлов не происходит, по сути данные на диске не перемещаются из файла в файл. Смущает вот такая оценка размеров дискового хранилища, получаемая по кнопке, что это означает?
Прикрепленные файлы:
158. nicxxx 254 31.08.18 16:11 Сейчас в теме
в тему секционирования - не все так радужно, как пишет автор в (0)
https://www.forum.mista.ru/topic.php?id=819374&page=1
159. handscenter 59 06.10.20 12:35 Сейчас в теме
Концепция "бесконечной" базы утопична и ущербна в своей сути, особенно с оглядкой на работу платформу 1С. Не дай бог что-нибудь поломается в данных и вы остановите бизнес в лучшем случае на часы, в худшем на недели.

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

Классическая свертка, предполагает следующие работы
- Создание копии базы
- Перевод старой базы в режим только на просмотр
- Создание документов ввода начальных остатков или операций и корректировки регистров, для формирования первичных остатков
- Чистка предшествующего документооборота
- Подчистка развернутых остатков от ошибок учета
- Удаление помеченных на удаление справочников с контролем целостности
160. comol 5051 06.10.20 19:41 Сейчас в теме
(159)
Концепция "бесконечной" базы утопична и ущербна в своей сути

Передам яндексу, фейсбуку, баду, ну и всем ребятам у которых "ущербные концепции". В 2020 ущербной является концепция свертки бд.

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

А ребят котрые боятся что "в базе что-то поломается" надо просто гнать в шею - модель резервного копирования + репликация средствами СУБД + репликация средствами 1С - не ломается ничего. Быстрое восстановление бэкапа, работа задним числом и удаление помеченных решаются текущими процессами.

Всё ввшеопискнное как и статья конечно про нормальные системы с 50+ пользователями и от 0.5 Тб объёмом. В базе где работает 1 бухгалтер вцелом можно выполнять сверку и это будет эффективнее чем покупать бухгалтеру новый компьютер :)
Fox-trot; user1464234; +2 Ответить
162. comol 5051 07.10.20 02:03 Сейчас в теме
(161) Я хз о какой группе речь. Даже спорить не хочу ни с кем о сути поста, могу только постебаться, так что если что не обижайтесь. Печально что в мире 1С есть люди с настолько далёкими от современности взглядами. Статью я писал уже лет пять назад. И тогда уже нафиг свертка не нужна была. Что уж теперь говорить....
Fox-trot; +1 Ответить
165. handscenter 59 07.10.20 10:23 Сейчас в теме
(162)
(161) Печально что в мире 1С есть люди с настолько далёкими от современности взглядами.

Сами технологии работы с данными из 1с весьма консервативны и практически всегда игнорируют современные продвинутые технологии. Даже сейчас работа с данными в 1С реализована на уровне близкой к sql 2000.

(161) Печально что в мире 1С есть люди с настолько далёкими от современности взглядами. Статью я писал уже лет пять назад. И тогда уже нафиг свертка не нужна была. Что уж теперь говорить....

давайте назовем это не свертка, а актуализация данных.
Невозможно бесконечно наращивать данные без потери производительности, как и не возможно бесконечно наращивать мощности. Поэтому абсолютно все информационные системы время от времени актуализируют данные. Поисковики обновляют результаты выдач по запросам и удаляют из них несуществующие страницы, соцсети удаляют профили, фото и старые переписки, торговые площадки подчищают старые предложения, почтовые сервера подчищают почтовые ящики.
И это нормальная работа современных информационных систем.
166. comol 5051 07.10.20 10:27 Сейчас в теме
(165)
Невозможно бесконечно наращивать данные без потери производительности
чего? Да неужели? :)

В 1С тут технологии не причём. СУБД развиваются
Fox-trot; +1 Ответить
168. handscenter 59 07.10.20 10:32 Сейчас в теме
(166) видимо у нас с вами разное понимание бесконечности.

Зако́н Амдала (англ. Amdahl's law, иногда также Закон Амдаля — Уэра) — иллюстрирует ограничение роста производительности вычислительной системы с увеличением количества вычислителей. Джин Амдал сформулировал закон в 1967 году, обнаружив простое по существу, но непреодолимое по содержанию ограничение на рост производительности при распараллеливании вычислений: «В случае, когда задача разделяется на несколько частей, суммарное время её выполнения на параллельной системе не может быть меньше времени выполнения самого медленного фрагмента»[1]. Согласно этому закону, ускорение выполнения программы за счёт распараллеливания её инструкций на множестве вычислителей ограничено временем, необходимым для выполнения её последовательных инструкций.
163. handscenter 59 07.10.20 09:58 Сейчас в теме
(160)
Передам яндексу, фейсбуку, баду, ну и всем ребятам у которых "ущербные концепции". В 2020 ущербной является концепция свертки бд.

вы правда верите что у "яндекса, фейсбука, баду" бесконечные базы? вы считаете что например яндекс хранит все варианты результатов поиска за все 20 лет их существования? )) они точно так же постояно актуализируют (те удаляют неактуальную информацию), что в общем то является аналогом в свертки в понимании 1с )

А ребят котрые боятся что "в базе что-то поломается" надо просто гнать в шею - модель резервного копирования + репликация средствами СУБД + репликация средствами 1С - не ломается ничего. Быстрое восстановление бэкапа, работа задним числом и удаление помеченных решаются текущими процессами.


Я вам как админ, программист и ИТ предприниматель с 25 летним стажем скажу, ломается все, и поглаживая седеющую бороду я посмеиваюсь над админам и программистами чрезмерно уверенным в надежности технологий и недооценивающих человеческий фактор :) Резервное копирование и реплики конечно же существенно повышают надежность систем, но не гарантируют 100% их безопасность.

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

-абсолютное большинство решений на 1с предполагают регулярное обновление ИБ с высокой вероятность изменения метаданных и последующей реструктуризацией. К моему сожалению при обновлениях существует не нулевой риск крашнуть базу и откатиться назад с базой более 100гб довольно длительный процесс.

-удаление помеченных объектов не возможно при наличии в ИБ ссылок на них. У 1с строгая политика ссылочной целостности. И свертка это одна из немногих возможностей почистить справочники после удаления неактуального документооборота.

-работа задним числом это величайшее зло всех информационных систем
167. comol 5051 07.10.20 10:31 Сейчас в теме
(163)
вы правда верите что у "яндекса, фейсбука, баду" бесконечные базы?
я не верю я знаю. Открыл свои сообщения в фейсбуке от 2010 года.... Ничего не удалили странно :)))). Ломается всё и всё рещервируется :)))) скажет любой студент без стажа :)
Fox-trot; +1 Ответить
171. handscenter 59 07.10.20 10:40 Сейчас в теме
(167)
и?
вы уверены что данные будут сохранены, если вы допустим не будет пользоваться фейсбуком в лет пяти?
заголовки новостей
"Сообщения в Facebook будут автоматически удаляться через какое-то время. Об этом говорится в посте Марка Цукерберга об обновлении политики приватности соцсети."
"Facebook упрощает удаление старых публикаций"
"За полгода Facebook удалил более 3 млрд фейковых аккаунтов"

я лет 10 назад был таким же романтиком, верящим в людей и технологии ) но с возрастом все проходит.
164. ZloyGenii 07.10.20 10:10 Сейчас в теме
(0)

По вашему цель свертки базы всегда только уменьшение объема самой базы ??? Возможно бывают иные цели когда дело доходит до свертки ?

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

К тому же небольшой объем не есть плохо, в экстренном случае случае (я не беру супер крутые организации где все зеркалируется по 100 раз и выход из строя 10 серваков вообще никто не почувствует), восстановление 50 гигабайт базы пройдет куда быстрее нежели восстановления 500 гигабайт базы (а если еще следом логи транзакций накатывать которые например раз в 5 минут делаются и обвал в пятницу произошел...)

Возможно на оракле и Дайнамиксе вообще все работает настолько божественно что никогда не сбоит и не зависит от железа, но в обычных компаниях ситуация немного иная...
170. comol 5051 07.10.20 10:37 Сейчас в теме
(164) я только про технические аспекты конечно. Бизнес в этой статье не рассматривал
172. handscenter 59 07.10.20 10:43 Сейчас в теме
173. ZloyGenii 07.10.20 10:44 Сейчас в теме
(170)
в этой статье не рассматривал


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

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

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

Речь о свертке зачастую заходит в достаточно "бедных" компаниях которые не могут себе позволить иметь миллион зеркал, гигантские объемы данных которые вообще никому ни зачем не нужны, а для налоговой вообще достаточно 3 лет, зачем хранить все остальное ? Вот и ужимаются как могут...

Газпром или приведенный ниже вами в примере фейсбук, докупят облако на трилиард террабай и забудут об этом вопросе, а в мелких конторах дохода иногда едва хватает на зп, аренду и все, от слова совсем, чтобы держаться на плаву...
174. ZloyGenii 07.10.20 11:03 Сейчас в теме
(170)

И даже если брать ТОЛЬКО технические аспекты.. Опять же мелкие фирмы работают на серверах которым по 10 и более лет (на свой страх и риск но они отдают себе отчет в том что происходит и что будут делать "в случае чего")...

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

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

Благо 1С интегрировалась с Postgre, а так во многих конторах до сих пор SQL 2000, который был куплен в светлые времена :) и возможности купить крутой и навороченный SQL последнего поколения как бы нету, про другие иностранные платные аналоги я вообще молчу, майкрасофту похрен кому продавать, газпрому или ИП пупкину, для них все зарабатывают одинаково дохрена...

Это что касается технической части вопроса.... :)
175. comol 5051 07.10.20 11:23 Сейчас в теме
(174) я выше написал - от 50+ пользователей и от 0.5 тб база. Как и "не покупать новый компьютер бухгалтеру". Это не про технологию это про бизнес. Мелким фирмам надо в облака съезжать.... ИМХО конечно
169. comol 5051 07.10.20 10:33 Сейчас в теме
(163)
вы правда верите что у "яндекса, фейсбука, баду" бесконечные базы?
я не верю я знаю. Открыл свои сообщения в фейсбуке от 2010 года.... Ничего не удалили странно :)))). Ломается всё и всё рещервируется :)))) скажет любой студент без стажа :)
176. Fox-trot 156 07.10.20 12:35 Сейчас в теме
если нет данных прошлых периодов как делать анализ или прогнозы? скакать по куче баз?
177. handscenter 59 07.10.20 12:56 Сейчас в теме
(176) Если опустить факт того что у пользователей остается архивная копия для просмотра,
Всегда можно использовать подобие olap кубов, куда выгружаются срезы итогов нужные для отчетов(именно срезу итогов по нужным измерения, а не полный набор данных).
Такое несложно реализовать как на 1с (например итоги через регистры сведений), так и на напрямую в СУБД (внешний источник).
Я такое делал в начале 00х даже в семерке через 1cpp :) и в 8рке давая возможность напрямую из 1с формировать отчеты как из оперативных данных, так и из кубов.
178. Fox-trot 156 07.10.20 13:02 Сейчас в теме
(177) так это тред про ограничение 2 гига, ну так и над было тогда с самого начала говорить, что в моем детстве все игрушки были деревяными психологические барьеры тяжело преодолевать в силу привычек и тд
179. handscenter 59 07.10.20 13:09 Сейчас в теме
(178)
ограничения есть всегда, но с развитием технологий меняются их пределы.

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


Зако́н Амдала (англ. Amdahl's law, иногда также Закон Амдаля — Уэра) — иллюстрирует ограничение роста производительности вычислительной системы с увеличением количества вычислителей. Джин Амдал сформулировал закон в 1967 году, обнаружив простое по существу, но непреодолимое по содержанию ограничение на рост производительности при распараллеливании вычислений: «В случае, когда задача разделяется на несколько частей, суммарное время её выполнения на параллельной системе не может быть меньше времени выполнения самого медленного фрагмента»[1]. Согласно этому закону, ускорение выполнения программы за счёт распараллеливания её инструкций на множестве вычислителей ограничено временем, необходимым для выполнения её последовательных инструкций.
180. Fox-trot 156 07.10.20 13:21 Сейчас в теме
(179) это все хорошо конечно, но сильно пахнет очевидностью, капитан
бесконечность она и есть бесконечность, но мы же говорим о более конкретных вещах
так что данная цитата для флейма только годна. проблема лежит в другой плоскости
181. handscenter 59 07.10.20 14:07 Сейчас в теме
(180) автор поста утверждает что свертка, а это один из многих способ оптимизации данных устарела и утверждает что все проблемы производительности можно решить технологиями и масштабируемостью.
Я не отрицаю что технологии здорово шагнули вперед, я утверждаю что идея бесконечно большой базы утопична и ущербна в свой сути и что нельзя решать проблему производительности без оптимизации данных, как и нельзя сделать оптимизацию данных без ее актуализации.
в общем то я как и все тут тоже ради флейма, вижу интересных собеседников - пишу )
182. comol 5051 07.10.20 14:35 Сейчас в теме
(181) Не готов рассуждать о бесконечности... Но как бы Data Lake, Hadoop, шардинг, Map-reduce... много чего ещё придумали...

Для особо страждущих я переформулирую свой посыл так: "свертка БД бесполезная операция если вы где то сохраните данные, которые были до свёртки". А вы скорее всего так и сделаете же :). Если вы собрались хранить бесконечную историю логов почтового сервера, то я буду первым кто скажет - "давайте обрежем"...

В остальных кейсах нет никаких проблем секцианировать данные и хранить их на низком уровне так как удобно а для приложения (сервера 1С) сделать доступ к ним прозрачным
Fox-trot; +1 Ответить
184. ZloyGenii 08.10.20 08:12 Сейчас в теме
(177)
), так и на напрямую в СУБД (внешний источник).


Хотел бы я посмотреть как вы на срезе будете встречную сверку взаиморасчетов в разрезе каждой сделки делать за 3 года...
185. handscenter 59 08.10.20 11:31 Сейчас в теме
(184) разве кто-то делает сверки сразу за 3 года? У бухгалтеров принято делать сверки кратно отчетным периодам, месяц\квартал\год. И для этих целей прекрасно подойдет архивная копия.
186. ZloyGenii 08.10.20 11:35 Сейчас в теме
(185)

Вы не сталкивались со встречной/перекрестной налоговой проверкой, когда сверка идет за максимально возможный промежуток времени по всем клиентам по которым прилетел запрос, или для всех клиентов кто это запрашивает ?

Если нет, то желаю вам чтобы и дальше не сталкивались НИКОГДА с запросами подобного рода :) иначе в вашем случае на свернутом регистре это будет сделать крайне сложно....

Еще скажите что у вас не бывает корректировочных СФ по документам двух-годичной давности ? Если нет вы идеально работаете, точнее ваши клиенты...
187. handscenter 59 08.10.20 11:43 Сейчас в теме
(182) хорошо зайду с другой стороны
что такое архив в понимании бизнеса? Это отработанные документы, которые необходимо хранить в течении определенного периода и после уничтожать. И раньше и сейчас у бухгалтеров есть потребность в хранении первичной документации в течении длительного срока и при этом документацию постепенно переносят в архив. Дабы она не занимала дорогую, полезную площадь и не мешала сотрудникам быстрее разбирать бумаги. Причем архивное помещение требуется меньше ресурсов на содержание, чем основные помещения.
Свертка по своей сути тоже самое, это периодический перенос отработанной информации в архив для удобства пользователей и быстродействия информационной системы. Причем архивные базы могут хранится на серверах с меньшими затратами, чем на серверах с оперативными данными.

(186) А что есть какие то требования от налоговой делать акт сверки единым документом? )
188. ZloyGenii 08.10.20 13:49 Сейчас в теме
(187)

(186) А что есть какие то требования от налоговой делать акт сверки единым документом? )


Требования по сверкам не от налоговой, а из за налоговой и от клиентов :)...
При вопросе единым/или разными, все зависит от того какие сверки присылают клиенты, ответ обычно всегда зеркальный дабы не было такого "мы вам такой прислали а вы нам другой", прислали одним документом за 2 года, ответ одним документом за 2 года, сверка детализирована "до безобразия", такую ще детализированную по максимуму из того что можем выжимать отправляем в ответ... Ни разу не обращались клиенты на предмет того что мы не такую им сверку отправили как хотели :)

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

В любом случае инциденты были и не раз, поэтому держать 3 года полных оборотов (без каких либо урезаний) это "табу". Думается мне так как проверки возможны разного характера, то требование хранить полный документооборот за 3 года рождается не из бухгалтерии совсем, и это не прихоть сумасбродной "старушки" которая в бухгалтерии ни одно поколение властей пережила :)...
183. Fox-trot 156 07.10.20 14:36 Сейчас в теме
(181) да никто тут не топит за бесконечность, в статье нет никакого упоминания про это, речь малость о другом, коллега
189. Velifer 18.11.21 09:54 Сейчас в теме
Свертка базы 1С объемом 4.5 Терабайт занимает всего лишь 3.5 часа
И никаких битых данных после этого.

Почему Вы меня отговариваете это делать? ))
Ведь многие из предложенных в статье подходов займут сильно больше, чем 3.5 часа на большой базе
190. shlegel 18.08.22 20:06 Сейчас в теме
Мысль хороша, можно экономить дорогие NV-ME, но это точно не для 1С. Платформа прям весь кайф портит от этой идеи. Я не совсем скульных дел мастер, больше по 1С, но минимальные опыты провел все таки, настроил секционирование по периоду регистра, перетащил пару справочников на другой диск. Работало огненно, пока дело не дошло до реструктуризации таблиц. Платформа создала копии таблиц с постфиксом NG по своим внутренним правилам, о секциях не слышала, о каких то файловых группах не знала. Предыдущие таблицы потерла. На этом можно закругляться и продолжать дальше сворачивать базы как и 10 лет назад. Возможно когда нить 1С шагнет на уровень выше, но думаю не при моей программерской жизни. Но как говорится надежда умирает последней. Возможно ОЛД скульщики знают как отловить события создания таблиц и заставить||подменить||научить 1С создавать таблы по моим правилам. Если есть у кого идеи дайте направление куда копать.
191. mikukrnet 181 19.06.23 13:12 Сейчас в теме
Если часть данных выделить в отдельную файловую группу - можно ли эту группу потом сжать?

Методом типа такого EXEC sp_MSforeachtable 'ALT ER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE)' GO
192. comol 5051 19.06.23 16:05 Сейчас в теме
(191) не, page это логическая сущность - по сути SQL сервер "ничего не знает" о ваших файловых группах на этом уровне. Но если "данные совсем исторические" - можно выделить в файловую группу и положить её, к примеру, на сжатый диск. Прироста в скорости и перекладывания дисковой нагрузки на процессор тут конечно ждать не стоит, но в объёме сэкономите.
mikukrnet; +1 Ответить
Оставьте свое сообщение