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