База УТ 10.3 сильно "разбухла". Помогите пожалуйста разобраться.
Имеется база УТ10.3, разумеется допиленная.
Учет ведется с 2010 года. Размер dt 2.8 Гб, размер базы SQL 80Гб.
Что то тут не ладно, так ведь?
Сделал анализ базы при помощи обработки скачанной с инфостарта. Скрин в приложении.
Сказать, что я ужаснулся увидел результаты это ничего не сказать.
Регистр накопления НДСРасчетыСПокупателями
11.5Гб занимает, РН НДСНачисленный - 9.5Гб ну и т.д.
Я так понимаю, что то где пошло не так, ну или ведем учет в корне не верно.
Ребят помогите хоть немного привести базу в порядок. Ясно дело свертка неизбежна. Обязательно будем ее делать.
Ну а пока, наверное можно ненужные данные почистить.
Тот же самый Регистр Сведений Списанные товары я так понимаю мне ни к чему.
В общем жду советов.
Всем спасибо.
Учет ведется с 2010 года. Размер dt 2.8 Гб, размер базы SQL 80Гб.
Что то тут не ладно, так ведь?
Сделал анализ базы при помощи обработки скачанной с инфостарта. Скрин в приложении.
Сказать, что я ужаснулся увидел результаты это ничего не сказать.
Регистр накопления НДСРасчетыСПокупателями
11.5Гб занимает, РН НДСНачисленный - 9.5Гб ну и т.д.
Я так понимаю, что то где пошло не так, ну или ведем учет в корне не верно.
Ребят помогите хоть немного привести базу в порядок. Ясно дело свертка неизбежна. Обязательно будем ее делать.
Ну а пока, наверное можно ненужные данные почистить.
Тот же самый Регистр Сведений Списанные товары я так понимаю мне ни к чему.
В общем жду советов.
Всем спасибо.
Прикрепленные файлы:
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Нет УТ под рукой
А этот регистр случайно не допиливали в плане измерений или проведения ?
Если регистр остатков не закрывается в разрезе измерений база пухнет катастрофически
НДСРасчетыСПокупателями
- регистр остатков ?
А этот регистр случайно не допиливали в плане измерений или проведения ?
Если регистр остатков не закрывается в разрезе измерений база пухнет катастрофически
(26) Решил вопрос ?
Тоже вот сижу пялюсь на размеры таблиц. Базу неимоверными усилиями свернули на начало 2016. Сейчас наиболее критичная ситуация с тормозами при подборе, пытаюсь облегчить всё что можно.. попался на глаза НДС..
Тоже вот сижу пялюсь на размеры таблиц. Базу неимоверными усилиями свернули на начало 2016. Сейчас наиболее критичная ситуация с тормозами при подборе, пытаюсь облегчить всё что можно.. попался на глаза НДС..
(26)Пересчет итогов делали?
Попробуйте провести тестирование и исправление со всеми галками. Но не забудьте перед этим делом сделать копию.
А несколько лет конечно куда столько.. Максимум два -три года надо и то на зарплатных конфигурациях с учетом, что там данные для пособий берутся за два года. А так конечно было бы лучше раз в три года урезать базу.
Попробуйте провести тестирование и исправление со всеми галками. Но не забудьте перед этим делом сделать копию.
А несколько лет конечно куда столько.. Максимум два -три года надо и то на зарплатных конфигурациях с учетом, что там данные для пособий берутся за два года. А так конечно было бы лучше раз в три года урезать базу.
(29)Если за день вносится бешеное число данных, а не с десяток документов, то есть при большом ежедневном вводе данных урезание периодически неизбежно. Или необходим хорошей мощности сервер, на что не у всех есть возможности. При регулярном подсчете итогов, закрытия месяца и регулярных обновлениях и бекапах с мощным железом больших проблем быть не должно. Если же обо всем этом забывать и вдобавок комп не мощнее как офисного варианта проблем может быть много. При большом размере базы за ней должен быть глаз да глаз.
НДС обычно пухнет, если формирование книг покупок/продаж регламентно не делают. Он тогда тупо не закрывается.
Делаете?
Делаете?
1. Типовая или доработанная конфигурация?
2. Если Бухгалтерия не нуждается в данных по НДС из УТ, то движения по регистрам НДС можно убрать.
3. РС "Списанные товары" нужен для проведения по партиям, поэтому без него не обойтись.
2. Если Бухгалтерия не нуждается в данных по НДС из УТ, то движения по регистрам НДС можно убрать.
3. РС "Списанные товары" нужен для проведения по партиям, поэтому без него не обойтись.
(14) Именно такая большая - ненормально. Но легко возможно при ошибках проектирования системы и ведения учета. В dt ведь не выгружаются "вторичные" данные, которые могут быть получены пересчетом из "первичных", в том числе индексы и итоги регистров. Плюс dt уже запакованный. Поэтому он всегда будет намного меньше даже файловой базы. А SQL всегда больше файловой, т.к. там место забирается с запасом всегда, чтобы уменьшить количество дорогих файловых операций.
ЗЫ. Хотя... Даже в нормальных базах разница элементарно может превышать 10 раз и более... Какие там 3-4. Тут сложно провести границу. Только анализ реального веса таблиц, индексов и сравнения результата с заложенной бизнес-логикой.
ЗЫ. Хотя... Даже в нормальных базах разница элементарно может превышать 10 раз и более... Какие там 3-4. Тут сложно провести границу. Только анализ реального веса таблиц, индексов и сравнения результата с заложенной бизнес-логикой.
У вас индексы в 3-4 раза больше чем сами данные.
Вот тут собака порылась.
Навскидку только настройкой правильного индексирования можно убрать 20 Гигов вообще без потери данных.
Вот тут собака порылась.
Навскидку только настройкой правильного индексирования можно убрать 20 Гигов вообще без потери данных.
Регистр "Продажи".
Данные 1,6, индексы - 7,7
Если поубираете свойство "индексировать" с некоторых реквизитов регистра, то получите нормальные индексы.
Данные 1,6, индексы - 7,7
Если поубираете свойство "индексировать" с некоторых реквизитов регистра, то получите нормальные индексы.
А попробовали средствами SQL реорганизация индекса, обновление статистики и тому подобное регламенты.
Кстати да. Очень похоже что из-за того что база допиливалась для ускорения ставились индексы вместо того что бы переписывать и нормализировать БД. Если снять индексы то просядет производительность запросов. Кстати 80Гб не критичный размер для БД. У нас БД и по 200-300 ГБ были. Кстати росли чаще всего из-за регистров с картинками и документами. Но тут другой случай.
На одном из моих проектов тоже был такой случай, когда таблица итогов регистра накоплений очень разрослась.
Как оказалось все случилось из-за того, что "криворукие" пользователи случайно изменили дату документа к примеру на 0054 год. И от этой даты начали строится итоги, хотя других записей к 2013 не было.
Посмотрите самую первую по дате запись в регистре и если год будет явно неправильным, то можете воспользоваться советами отсюда - .
Как оказалось все случилось из-за того, что "криворукие" пользователи случайно изменили дату документа к примеру на 0054 год. И от этой даты начали строится итоги, хотя других записей к 2013 не было.
Посмотрите самую первую по дате запись в регистре и если год будет явно неправильным, то можете воспользоваться советами отсюда - .
Если кому интересно. Обратился во один из франчей из близлежащего региона.
Они очень профессионально все сделали. Размер dt в итоге был уменьшен с 2.9 Гб до 1.2 Гб.
На выходных выгружу dt, грохну базу и залью dt в чистую базу, дабы уменьшить размер базы на сервере SQL.
Если кому нужны контакты то скину в личк. По деньгам обошлось что то около 40к.
Они очень профессионально все сделали. Размер dt в итоге был уменьшен с 2.9 Гб до 1.2 Гб.
На выходных выгружу dt, грохну базу и залью dt в чистую базу, дабы уменьшить размер базы на сервере SQL.
Если кому нужны контакты то скину в личк. По деньгам обошлось что то около 40к.
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот