Вдруг за выходные база с 300 гигов выросла до 700, за прошлые сутки еще на 150.
База Бухгалтерия предприятия КОРП, редакция 3.0 (3.0.91.36) платформа 1С:Предприятие 8.3 (8.3.18.1208) 64 бит
Серверная сервер SQL 2008 R2 64 бит
Файл транзакций в норме.
Во время роста работала обработка по загрузке данных из внешней базы ORAKL. Обработка проверенная работает не первый месяц.
Вечером попробую сжать базу средствами SQL.
Что еще можно сделать и куда посмотреть?
База Бухгалтерия предприятия КОРП, редакция 3.0 (3.0.91.36) платформа 1С:Предприятие 8.3 (8.3.18.1208) 64 бит
Серверная сервер SQL 2008 R2 64 бит
Файл транзакций в норме.
Во время роста работала обработка по загрузке данных из внешней базы ORAKL. Обработка проверенная работает не первый месяц.
Вечером попробую сжать базу средствами SQL.
Что еще можно сделать и куда посмотреть?
По теме из базы знаний
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(16)У человека случился инцидент. Разовый инцидент.
Размер базы вырос в два раза.
И вот ваше сообщение:
Можно поподробнее, пожалуйста?
Я хочу понять, что вы хотели донести.
Как исходя из (1) делать (7)?
Размер базы вырос в два раза.
И вот ваше сообщение:
С точки зрения производительности, базу не нужно шринковать, лучше наоборот определить размер файла большим и приращение значимым.
Можно поподробнее, пожалуйста?
Я хочу понять, что вы хотели донести.
Как исходя из (1) делать (7)?
(17)Мой ответ был на (6), в котором ТС сообщил о своих намерениях шринкать БД, я сделал замечание по поводу шринка БД.
(7) делается не исходя, а предварительно, чтобы СУБД как можно реже выполняла операцию увеличения файла БД.
Если бы у ТС было сделано (7), то при (1) он бы не заметил увеличения БД.
(7) делается не исходя, а предварительно, чтобы СУБД как можно реже выполняла операцию увеличения файла БД.
Если бы у ТС было сделано (7), то при (1) он бы не заметил увеличения БД.
(19)
(7) Выполняется в рамках обязанностей администратора БД при создании БД не зависимо от того, произошло (1) или нет.
То, что произошло в (1): произошло и произошло. Причину поняли, соответствующие выводы сделали, надеюсь.
Шринкать базу после проишествия (1) нет необходимости.
Так понимаю, задача "освобождения" занимаемого места решается созданием копии "пустой" таблицы и удалением таблицы-источника с последующим переименованием копии.
(7) Выполняется в рамках обязанностей администратора БД при создании БД не зависимо от того, произошло (1) или нет.
То, что произошло в (1): произошло и произошло. Причину поняли, соответствующие выводы сделали, надеюсь.
Шринкать базу после проишествия (1) нет необходимости.
Так понимаю, задача "освобождения" занимаемого места решается созданием копии "пустой" таблицы и удалением таблицы-источника с последующим переименованием копии.
Обработка скорее всего сначала грузит данные с ORAKCL'а в какой-то регистр сведений, из регистра сведений потом чем-то распихивает в документы или еще куда, потом регистр сведений удаляется. Возможно обработка валилась на чем-то, и поэтому запускалась тыщу раз, записывая данные в регистр, но не стирая их, а потом когда-то данные были стерты (но ведь при стирании данные остаются в таблице, просто помечаются, как удаленные). На выходе рост базы на тот объем, который был загружен с ORAKCL'а.
По поводу инструментов, то вроде как каждый ребенок 1С-нега уже такой написал. Даже я )))
- всего одна строка кода (3).
По поводу инструментов, то вроде как каждый ребенок 1С-нега уже такой написал. Даже я )))
- всего одна строка кода (3).
Как показал анализ причиной стала таблица регистра сведений, в которой было Ноль записей но которая занимала кучу места.
Регистр добавлен к типовой конфигурации. Там в ресурсах было строковое поле неограниченной длины. В него писались логи загрузки,
По результатам: Никакие ухищрения в SQLe не помогли сжать базу.
В конфигураторе ограничил длину поля, затем стандартным SQL сжатием базы вернул ее к правильному размеру.
Регистр добавлен к типовой конфигурации. Там в ресурсах было строковое поле неограниченной длины. В него писались логи загрузки,
По результатам: Никакие ухищрения в SQLe не помогли сжать базу.
В конфигураторе ограничил длину поля, затем стандартным SQL сжатием базы вернул ее к правильному размеру.
Стоп а разница во сколько? если 2-3 % понятно это не показателю. А если разница в сторону > 40% то это можно считсать за прогресс. dt сливаем в рабочую базу тем самым получаем свободное место.
(36)Вы хотя бы размеры озвучили для понятия в какую сторону изменилось? Тогда аналитика заработает.
(36)Вы хотя бы размеры озвучили для понятия в какую сторону изменилось? Тогда аналитика заработает.
(38)
(38) но с большими данными всегда так. Или на начало года Вы начинаете новую базу вести переносите НСИ, взаиморасчеты с контрагентами и остатки по счетам учета. Или вы продолжаете работать в старой базе но уже с аналитикой в одном месте. Есть еще угрюмый метод сворачиваете базочку. Но я даже этот метод врагу не посоветовал. Мы при размере базы в 100 гигов каждый год начинали вести все в новой базе данных. Гемор в переносе. Но за то реальный прирост скорости до определенного момента времени. На данный момент все уперается в оптимизацию кода. Если все хорошо написано можно работать и в одной базе по 5-10 лет. Риск если база загнется тогда с умное решение с бэк апами всегда выручает. На эту тему нужно смотреть окружение и железо. А то, что я предложил это быстрая пррверка работы. Поиск медленных решения и т.д. Желаю удачи в не трудном решение вопроса.
(38) но с большими данными всегда так. Или на начало года Вы начинаете новую базу вести переносите НСИ, взаиморасчеты с контрагентами и остатки по счетам учета. Или вы продолжаете работать в старой базе но уже с аналитикой в одном месте. Есть еще угрюмый метод сворачиваете базочку. Но я даже этот метод врагу не посоветовал. Мы при размере базы в 100 гигов каждый год начинали вести все в новой базе данных. Гемор в переносе. Но за то реальный прирост скорости до определенного момента времени. На данный момент все уперается в оптимизацию кода. Если все хорошо написано можно работать и в одной базе по 5-10 лет. Риск если база загнется тогда с умное решение с бэк апами всегда выручает. На эту тему нужно смотреть окружение и железо. А то, что я предложил это быстрая пррверка работы. Поиск медленных решения и т.д. Желаю удачи в не трудном решение вопроса.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот