Здравствуйте.
Есть рукоблудная конфигурация. В файловом варианте вешает 50Гб. Выгружаю dt он вешает 60 Мб.
При попытке загрузить в новую базу этот процесс длится уже более часа... Но так и не закончился.
База небольшая по сути и 50Гб весить в ней нечему. Там просто нет таких объёмов данных. И выгрузка всего 60 Мб. И делается буквально за пару минут.
Я так предполагаю что может быть проблема с индексами. Кто то включил много полей на ндексацию.
ТиИ делается в базе регулярно. Без него вообще всё медленно работает.
Или может ещё что то?
Пока что пытаюсь себе развернуть копию. Видимо проще скопировать каталог с базой. В общем коллеги кто сталкивался с подобным пните в нужную сторону?
Есть рукоблудная конфигурация. В файловом варианте вешает 50Гб. Выгружаю dt он вешает 60 Мб.
При попытке загрузить в новую базу этот процесс длится уже более часа... Но так и не закончился.
База небольшая по сути и 50Гб весить в ней нечему. Там просто нет таких объёмов данных. И выгрузка всего 60 Мб. И делается буквально за пару минут.
Я так предполагаю что может быть проблема с индексами. Кто то включил много полей на ндексацию.
ТиИ делается в базе регулярно. Без него вообще всё медленно работает.
Или может ещё что то?
Пока что пытаюсь себе развернуть копию. Видимо проще скопировать каталог с базой. В общем коллеги кто сталкивался с подобным пните в нужную сторону?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) TODD22, более часа нормально, для базы такого объема.
по поводу
а если, прикрепить бинарный файл забитый нулями, размером 50 гб, в хранилище, без сжатия ?
Тогда база будет весить 60 гб, но при формировании DT-шника, легко свернется в очень маленький размер.
Короче, просто дождись конца процесса. Раз ошибок при выгрузке не выдал, мнк кажется что все нормально с базой, просто там какие то хитрые данные.
Ну можно переиндексировать попробовать
по поводу
Там просто нет таких объёмов данных
а если, прикрепить бинарный файл забитый нулями, размером 50 гб, в хранилище, без сжатия ?
Тогда база будет весить 60 гб, но при формировании DT-шника, легко свернется в очень маленький размер.
Короче, просто дождись конца процесса. Раз ошибок при выгрузке не выдал, мнк кажется что все нормально с базой, просто там какие то хитрые данные.
Ну можно переиндексировать попробовать
(10) TODD22,
Тогда не только анализируй свойства и поиски полнотекстовые, а ещё и код а то в друг какой механизм подключен, который новый журнал регистрации пишет с подробностями редактирования строки и.т.д. У меня например подключен Но база SQL, зато лог 90 ГБ весит!!!
Тогда не только анализируй свойства и поиски полнотекстовые, а ещё и код а то в друг какой механизм подключен, который новый журнал регистрации пишет с подробностями редактирования строки и.т.д. У меня например подключен Но база SQL, зато лог 90 ГБ весит!!!
(11) kolya_tlt, "тормоза" это означает что есть несколько критичных по времени операций которые выполняются долго.
Дисковая подсистема уже давно апгрейдирована(ssd). И железо нормальное.
Для начала нужно разобраться с размером базы. Потому что в ней не хранят файлов и тд. Её выгрузка вешает 60Мб. После загрузки 6Гб. Что явно очень много. В базе ведётся учёт оказанных услуг.
Посмотрел что делают в этой. В ней работает 1 кассир! на внесение данных и 1-2 человека в базу иногда заходят отчёт за день глянуть ничего при этом не внося.
Да не откуда там таким объёмам данных взяться. За 2 года один кассир набил 6 Гб данных :) По оказанным услуга. Когда одному человеку оказывается за раз 1-6 услуг. Никакого склада, остатков, себестоимости и тд. База делает только то что показывает сколько услуг было оказано за период в количестве, деньгах ну и ещё несколько разрезов аналитики.
Проблема видимо в том что она самописная... и где то не грамотно что то спроектировали. Завтра буду смотреть....
Начну с составных типов в измерениях регистров. Да и посмотрю какие таблицы больше всего весят.
В целом база работает нормально. За исключением отражения оказания услуг. На нём померает.....
Критичные операции там нужно код переписать. Там явно в нём дело. Потому что кассир вводит документ оказанных услуг. А он проводится и печатается до нескольких минут. Это явно много для кассы. Ну и для такого простого документа.
Дисковая подсистема уже давно апгрейдирована(ssd). И железо нормальное.
Для начала нужно разобраться с размером базы. Потому что в ней не хранят файлов и тд. Её выгрузка вешает 60Мб. После загрузки 6Гб. Что явно очень много. В базе ведётся учёт оказанных услуг.
Посмотрел что делают в этой. В ней работает 1 кассир! на внесение данных и 1-2 человека в базу иногда заходят отчёт за день глянуть ничего при этом не внося.
Да не откуда там таким объёмам данных взяться. За 2 года один кассир набил 6 Гб данных :) По оказанным услуга. Когда одному человеку оказывается за раз 1-6 услуг. Никакого склада, остатков, себестоимости и тд. База делает только то что показывает сколько услуг было оказано за период в количестве, деньгах ну и ещё несколько разрезов аналитики.
Проблема видимо в том что она самописная... и где то не грамотно что то спроектировали. Завтра буду смотреть....
Начну с составных типов в измерениях регистров. Да и посмотрю какие таблицы больше всего весят.
В целом база работает нормально. За исключением отражения оказания услуг. На нём померает.....
Критичные операции там нужно код переписать. Там явно в нём дело. Потому что кассир вводит документ оказанных услуг. А он проводится и печатается до нескольких минут. Это явно много для кассы. Ну и для такого простого документа.
(19) TODD22,
Или ждите, когда накопится критическая масса и появятся решения.
Как уменьшить индекс у этой таблицы?
Это, видимо, очередное ноу-хау у 1С в 8.3, так что - обращайтесь к ним или на партнерку, почему это данная таблица такая гигантская, и как с этим жить.
Или ждите, когда накопится критическая масса и появятся решения.
(24) AlexO, Это не проблема 8.3 данная проблема тянется с 2005 года. И исправлять 1с её не будет о чём написано на партнёрском. Варианта два или СУБД или как посоветовали выше чистить все настройки.
На СУБД не могу загрузить вылетает ошибка. Пробую почистить настройки в файловой. Пока что безуспешно.....
На СУБД не могу загрузить вылетает ошибка. Пробую почистить настройки в файловой. Пока что безуспешно.....
(26) TODD22,
Только саму проблему это не решает никак. А также её последствия, из-за которых "1с исправлять не будет".
Это не проблема 8.3 данная проблема тянется с 2005 года
Если это "давняя" проблема с сохранением непонятно чего от форм - это проблема 8.2 и УФ.
И исправлять 1с её не будет
т.е. вас это не напрягает?
Варианта два или СУБД или как посоветовали выше чистить все настройки.
ну могу предложить еще вариант - выгрузить в SQL, очистить/удалить эту таблицу, загрузить обратно в файл.
Только саму проблему это не решает никак. А также её последствия, из-за которых "1с исправлять не будет".
(27) AlexO, Ещё раз.... проблема в формате хранения. 1С не будет менять этот механизм.
(28) AllexSoft,
Ну как бы не совсем в БСП и УФ. Просто они очень сильно усугубляют эту проблему.
Дело не в том что УФ и БСП пишут данные. Сами данные 200 метров в таблице занимают. А вот индексы растут как на дрожжах. И там проблема как я понял именно с самими индексами.
(28) AllexSoft,
это проблема в БСП и конкретных формах
Ну как бы не совсем в БСП и УФ. Просто они очень сильно усугубляют эту проблему.
Дело не в том что УФ и БСП пишут данные. Сами данные 200 метров в таблице занимают. А вот индексы растут как на дрожжах. И там проблема как я понял именно с самими индексами.
(35) AlexO, да откуда я знаю... :) Читал на партнёрском. Там типа при каких то условиях рост индексов начинается.
Собственно мне нужно решение, а не то почему так происходит. Одно из решений переход на СУБД. Есть вариант очистки этих данных. В принципе то же нормальный вариант в моём случае. Переодически чистить не проблема. Просто тут случай запущенный :)
Собственно мне нужно решение, а не то почему так происходит. Одно из решений переход на СУБД. Есть вариант очистки этих данных. В принципе то же нормальный вариант в моём случае. Переодически чистить не проблема. Просто тут случай запущенный :)
(42) AllexSoft, Где то читал что проблема именно в файловом варианте. На СУБД такой проблемы вроде как быть не должно потому что проблема не в самих сохраняемых данных по действиям. А именно в их индексации. Хотя может и ошибаюсь. У меня база файловая.
Но на СУБД даже и не знаю как переводить. Она в СУБД загружается с ошибкой.... :( То есть процесс загрузки вылетает с ошибкой. Но при этом база создаётся, открывается, работает... Но раз ошибка то нужно разбираться.
Но на СУБД даже и не знаю как переводить. Она в СУБД загружается с ошибкой.... :( То есть процесс загрузки вылетает с ошибкой. Но при этом база создаётся, открывается, работает... Но раз ошибка то нужно разбираться.
(46) TODD22, в файловом варианте усугубляется это да, но и в серверном вот вам статистика одной УТ 11.. база небольшая, но размер таблицы SYSTEMSETTINGS уже показательно 3тий по размеру! там BLOB-записи еще есть, кроме индексов ) собственно в BLOB-ах и хранятся те самые настройки которые не нужны
Прикрепленные файлы:
(49) AllexSoft, В этом и есть видимо наша проблема :) Как раз с проведением и печатью документов проблема :( На этом и начинаются проблемы. А так база работает резво.
Но как доходит дело до формирования документов и печати всё встаёт колом :( Надо что то придумать будет. Так как документы печататься будут дальше и индексы опять будут расти.
Но как доходит дело до формирования документов и печати всё встаёт колом :( Надо что то придумать будет. Так как документы печататься будут дальше и индексы опять будут расти.
(55) AlexO,
Спасибо :)
Надо теперь придумать что сделать :) Или запускать чистку переодически... или может есть ещё какое то решение. Но хотелось бы без переписки конфигурации.
Не тот случай так сказать что бы что то сильно переделывать :)
Так что - с ненужными BLOB'ами вас ))
Спасибо :)
Надо теперь придумать что сделать :) Или запускать чистку переодически... или может есть ещё какое то решение. Но хотелось бы без переписки конфигурации.
Не тот случай так сказать что бы что то сильно переделывать :)
(57) AllexSoft, Сегодня оператор попробовал работать. Всё отлично. Всё работает быстро. Проблема с производительностью решилась.
Но при первом запуске при выполнении одной из процедур платформа упала. Но упала при выводе на печать и с вроде как с виндовой ошибкой дело было не при мне. Но после перезапуска всё отработало нормально.
В понедельник будем рабочую пробовать.
Но при первом запуске при выполнении одной из процедур платформа упала. Но упала при выводе на печать и с вроде как с виндовой ошибкой дело было не при мне. Но после перезапуска всё отработало нормально.
В понедельник будем рабочую пробовать.
При попытке залить на СУБД ms sql вылетает ошибка:
Ошибка загрузки информационной базы. В информационную базу загружены не все данные
по причине:
Ошибка СУБД:
Microsoft SQL Server Native Client 10.0: Внимание! Максимальная длина ключа - 900 байт. Индекс "_SystemSett_ByKey_SSS" имеет максимальную длину 1152 байт. Для некоторых комбинаций больших значений операции вставки или обновления не смогут быть выполнены.
HRESULT=80040E2F, HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=10, native=1505, line=1
SQLSrvr: SQLSTATE=01000, state=1, Severity=0, native=1945, line=1
Ошибка загрузки информационной базы. В информационную базу загружены не все данные
по причине:
Ошибка СУБД:
Microsoft SQL Server Native Client 10.0: Внимание! Максимальная длина ключа - 900 байт. Индекс "_SystemSett_ByKey_SSS" имеет максимальную длину 1152 байт. Для некоторых комбинаций больших значений операции вставки или обновления не смогут быть выполнены.
HRESULT=80040E2F, HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=10, native=1505, line=1
SQLSrvr: SQLSTATE=01000, state=1, Severity=0, native=1945, line=1
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот