В нете не нашел инфы об ожидаемом времени обновления.
Понятно, что зависит от много чего.
Но ведь можно попытаться определить некоторый "средний" удельный юнит типа K[минут / Кб]
Зачем это надо: получить оценку ожидаемого простоя во время обновления рабочей базы.
Примерно так:
1. количество реструктуризуемых таблиц, их общий вес.
2. Оцениваем производительность машины клиента ()
3. Умножаем на K, получаем оценку, планируем технологический перерыв.
Как получить K?
Ничего кроме простой статистики в голову не приходит.
Прошу поделиться опытом. Требуется: общий вес затронутых таблиц (общий вес базы), параметры (память, частота) клиентской машины и сервера, вариант базы (серверный/файловый), время обновления (без технологических потерь на изгнание юзеров и архивирование), платформу.
Понятно, что зависит от много чего.
Но ведь можно попытаться определить некоторый "средний" удельный юнит типа K[минут / Кб]
Зачем это надо: получить оценку ожидаемого простоя во время обновления рабочей базы.
Примерно так:
1. количество реструктуризуемых таблиц, их общий вес.
2. Оцениваем производительность машины клиента ()
3. Умножаем на K, получаем оценку, планируем технологический перерыв.
Как получить K?
Ничего кроме простой статистики в голову не приходит.
Прошу поделиться опытом. Требуется: общий вес затронутых таблиц (общий вес базы), параметры (память, частота) клиентской машины и сервера, вариант базы (серверный/файловый), время обновления (без технологических потерь на изгнание юзеров и архивирование), платформу.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) tango, примерно год назад мы обсуждали время реструктуризации здесь: .
С тех пор мало что изменилось, ИМХО. Например, сейчас перевод базы БП КОРП 2.0 на 3.0 у меня занимает 20-24 часа. В базе 2.5 миллиона документов. Размер SQL-базы 18Гб. Основные затраты на регистр бухгалтерии и регистр ДанныеПервичныхДокументов. Грубым расчетом получаю, что за секунду обрабатывается 25-30 документов. Опять же, на моем железе и софте.
С тех пор мало что изменилось, ИМХО. Например, сейчас перевод базы БП КОРП 2.0 на 3.0 у меня занимает 20-24 часа. В базе 2.5 миллиона документов. Размер SQL-базы 18Гб. Основные затраты на регистр бухгалтерии и регистр ДанныеПервичныхДокументов. Грубым расчетом получаю, что за секунду обрабатывается 25-30 документов. Опять же, на моем железе и софте.
из каментов по ссыле (16)
о пользе вин-дефрагментации файловой базы
27. JohnySC 19.12.2012 19:19
Я еще не раз замечал, что файл БД (при файловом конечно же режиме) может быть сильно фрагментирован (актуально для старых и забитых дисков в WinXP) и если его до обновления, или еще каких работ, дефрагментировать (может помочь например WinContig), то скорость обработки может увеличиться не то что в разы - а на порядки! :-)
о пользе вин-дефрагментации файловой базы
27. JohnySC 19.12.2012 19:19
Я еще не раз замечал, что файл БД (при файловом конечно же режиме) может быть сильно фрагментирован (актуально для старых и забитых дисков в WinXP) и если его до обновления, или еще каких работ, дефрагментировать (может помочь например WinContig), то скорость обработки может увеличиться не то что в разы - а на порядки! :-)
(21) kuzev,
своя конфигурация
- не аргумент. таблички сравнить можно
софт
- здесь разница в релизе платформы, варианте развертки базы, версии скуля и винды. все вполне учитывается. конкуренцию за ресурсы с другими программами можно не учитывать. если кто-то все службы запихонил на один сервак - это, как сказал один товарищ "его проблемы"
железо
- объем памяти и частота, вполне учитывается (+ скорость дисковых операций, конечно. гиговые базы без свопа не обновишь)
платформа 8.3.1:
Реструктуризация производится в режиме полного доступа, то есть в это время работа всех других операторов с программой не возможна. На тяжелых, прикладных программных средах и на больших базах реструктуризация может выполняться значительное время.
Раньше режим полного доступа на всё время создания реструктуризации , и этот процесс не мог быть остановлен. Если он останавливался, то в следующий раз требовалось начинать все заново.
Теперь же основные корректировки при реструктуризации вносятся в фоновом режиме, без необходимого прекращения работы операторов. Монопольный режим доступа по-прежнему необходим только в финальной, короткой по продолжительности фазе реструктуризации.
Фоновая реструктуризация доступна только в клиент-серверном варианте исполнения системы. Она может быть выполнена интерактивно, из режима Конфигуратор или с помощью командной консоли. Выполнение фоновой реструктуризации можно временно прервать, а затем продолжать с той ступени, на которой остановились.
Раньше режим полного доступа на всё время создания реструктуризации , и этот процесс не мог быть остановлен. Если он останавливался, то в следующий раз требовалось начинать все заново.
Теперь же основные корректировки при реструктуризации вносятся в фоновом режиме, без необходимого прекращения работы операторов. Монопольный режим доступа по-прежнему необходим только в финальной, короткой по продолжительности фазе реструктуризации.
Фоновая реструктуризация доступна только в клиент-серверном варианте исполнения системы. Она может быть выполнена интерактивно, из режима Конфигуратор или с помощью командной консоли. Выполнение фоновой реструктуризации можно временно прервать, а затем продолжать с той ступени, на которой остановились.
Для периодических регистров сведений, подчиненных регистратору, поле Активность включено в состав следующих индексов:
По периоду;
По измерениям;
По измерению.
Для указанных индексов поле Активность добавляется последним полем.
После переключения режима совместимости необходимо выполнить полную реструктуризацию информационной базы для перестроения индексов. В режиме совместимости с версией 8.3.2 поведение не изменилось.
По периоду;
По измерениям;
По измерению.
Для указанных индексов поле Активность добавляется последним полем.
После переключения режима совместимости необходимо выполнить полную реструктуризацию информационной базы для перестроения индексов. В режиме совместимости с версией 8.3.2 поведение не изменилось.
не в тему, но тоже интересно
кому как, а я "понятие 1с" плановый перезапуск вижу в первый раз
Уменьшено использование памяти во время работы сервера «1С:Предприятия», а также уменьшена фрагментация памяти. Это позволяет уменьшить количество плановых перезапусков сервера «1С:Предприятия» и повысить стабильность работы системы.
кому как, а я "понятие 1с" плановый перезапуск вижу в первый раз
Проверка наличия реквизита Ссылка (Ref) в табличных частях справочников, планов видов характеристик, планов счетов, планов видов расчета, планов обмена, бизнес-процессов и задач выполняется перед обновлением конфигурации базы данных. Наличие такого реквизита ведет к невозможности реструктуризации.
В режиме совместимости с версией 8.3.2 поведение не изменилось.
В режиме совместимости с версией 8.3.2 поведение не изменилось.
(8) tango, не знаю возможно, если хочешь могу проверить в принципе, есть база с большим регистром сведений, непереодическим... есть база с большим регистром накопления оборотным с порядка 30 измерениями аналитики, реструктурируется часто (идет допиливание), вроде очень быстро, порядка 20 секунд на 100 000 записей ориентировочно, комп сравнимый с тем что писал выше..
на тестовом серевере реквизит в регистре, где 8млн записей, база на тестовом сервере (которые является обычным компом с обычными дисками - реиндексация прошла за 4 минуты
пс: невнятно
какой регистр? какой реквизит? что за машина - клиент?
(однако, коллеги удостоили месседж плюсиком :))
(10) tango, а причем тут клиент? вроде давно уже есть специальный флаг выполнять реструктуризацию на сервере... Зачем анализировать еще и клиент? Или имеется ввиду открыть конфигуратор на клиенте и запустить реструктуризацию? Тогда статистики очень много надо, что бы понять как влияет и что влияет на клиенте.
Тоже проходил: на виртуалке работает с 2009г. проц Xenon 4 ядра, ОЗУ 4 Гб, винты древние 2006г. база около 200 Гб, УПП, в РБ Хозрасчетный порядка 23000000 записей, реструктуризация заняла около 10ч. Была добавлена доп. аналитика.
Предположим вам необходимо добавить реквизит в табличную часть _document39_vt415, узнать какая именно табличная часть можно либо специальными обработками, либо просто посмотрев несколько записей из таблицы в самой СУБД. Что произойдет далее, точнее что сделает платформа 1С, она создаст копии всех 6 (!) таблиц документа и начнет копирование в них данных из старых таблиц - начнется реструктуризация. Процесс этот, мягко говоря, не быстрый. Почему я вообще пишу эту статью, потому что в моем случаи: количество документов (записей в _document39 было 1М) и записей в табличных частях 25М, процесс реструктуризации документа средствами 1С занял 48 часов.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот