База за много лет, пишем историю множества реквизитов - ИНН, наименование контрагентов и прочая.
Сегодня в ЦБД (есть и периферийки) пошёл поток таких ошибок.
Если я правильно понимаю SQL, то выполнив в EM
"SEL ECT Count(1) FR OM _1sConst", можно получить примерно то же число, что "Число строк" в свойствах таблицы на SQL-сервере.
В моём случае это 3.4 млн строк и 512 МБ на копии. Это близко к критичному размеру?
Сегодня в ЦБД (есть и периферийки) пошёл поток таких ошибок.
Если я правильно понимаю SQL, то выполнив в EM
"SEL ECT Count(1) FR OM _1sConst", можно получить примерно то же число, что "Число строк" в свойствах таблицы на SQL-сервере.
В моём случае это 3.4 млн строк и 512 МБ на копии. Это близко к критичному размеру?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
«512 МБ на копии» — цифирь шибко красива: 64, 128, 256, 512, 1024.. лирическое вступление ;)
пробуй по типу
для 1SJOURN, 1SCRDOC; документов DT* с богатой табличной частью; 1SOPER ежли бухгалтерия – убедись, что числа не многократно меньше «3.4 млн строк».
гм.. так это при ответе пробелы добавляются.. в
пробуй по типу
SEL ECT Count(1) FROM _1sConst
для 1SJOURN, 1SCRDOC; документов DT* с богатой табличной частью; 1SOPER ежли бухгалтерия – убедись, что числа не многократно меньше «3.4 млн строк».
гм.. так это при ответе пробелы добавляются.. в
SELECT Count(1) FR OM _1sConst
А каких именно "пошел поток таких ошибок"?
В качестве информации к размышлению почитайтеhttp://1c.mazzy.ru/articles/howmany/
В качестве информации к размышлению почитайте
(5) vcv, В ЖР именно такая строка была, профайлером я не умею пользоваться, сейчас ошибка ушла так же сама, поэтому и исследовать не буду. Основная проблема сейчас - блокировка общего журнала и крупных регистров. Исправляю апгрейдом памяти самых слабых машин (караван идёт со скоростью самого медленного верблюда). До проверки sql-сервера руки вот-вот дойдут.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот