Доброго времени суток!
Стал часто сталкиваться с ситуацией когда обращаются за помощью из-за не работоспособности баз 1С с одной и той же проблемой. Размер файла лога базы переполнен. Первоначальный размер файлов базы и лога задаются людьми устанавливающими SQL большими, от 10 и выше Гб. Очень часто размер базы меньше размера лога в несколько раз. База может быть 10 Гб а лог 40 Гб. Есть ли какое то обоснование задания первоначального размера файлов больших объемов? Базы в основной массе своей не большие быть должны, от 1 до 4 Гб, но они и 10, и 15 и 20 Гб бывают, файлы логов в 3-4 раза больше. Пользователей больше 10 крайне редко бывает, но кто то упорно для чего то указывает огромные первоначальные размеры файлов.
Стал часто сталкиваться с ситуацией когда обращаются за помощью из-за не работоспособности баз 1С с одной и той же проблемой. Размер файла лога базы переполнен. Первоначальный размер файлов базы и лога задаются людьми устанавливающими SQL большими, от 10 и выше Гб. Очень часто размер базы меньше размера лога в несколько раз. База может быть 10 Гб а лог 40 Гб. Есть ли какое то обоснование задания первоначального размера файлов больших объемов? Базы в основной массе своей не большие быть должны, от 1 до 4 Гб, но они и 10, и 15 и 20 Гб бывают, файлы логов в 3-4 раза больше. Пользователей больше 10 крайне редко бывает, но кто то упорно для чего то указывает огромные первоначальные размеры файлов.
По теме из базы знаний
Найденные решения
(14) Полная модель восстановления- это значит, что транзакции из журнала не удаляются автоматически вообще. Поэтому не уменьшается журнал лога. Раз установить симпл не проблема- установите. После этого завершенные транзакции удалятся и вы сможете сжать файл журнала транзакций. Отвечая на ваш вопрос, чтобы сжать файл- поставьте симпл, после этого он сожмется. Сколько поставили при старте неважно, сжимать мешают транзакции внутри файла, а не стартовое значение.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
У вас два вопроса в одном. Первый- почему появляется ошибка переполнения лога транзакций. Ответ- потому что граждане работают с моделью восстановления "full", не понимая, зачем она. Если не понимаешь, поставь модель восстановления "simple"(режим удаления завершенных транзакций), и ничего не вырастет и не переполнится.
Второй вопрос, зачем люди ставят большой стартовый размер файлов. Ответ- большой размер файлов не проблема для mssql, он умеет с ним работать. Когда люди ставят маленький объем, а потом делают шринки эти- они просто дают компьютеру дополнительную работу. Сначала он тратит ресурсы на шринк, потом- на выделение места под базу. Зачем они это делают- от непонимания наверное)) Свободное место внутри файла базы данных- это нормально. Экономить дисковое пространство не нужно, диски копейки стоят, даже ссд, даже на рейд.
Второй вопрос, зачем люди ставят большой стартовый размер файлов. Ответ- большой размер файлов не проблема для mssql, он умеет с ним работать. Когда люди ставят маленький объем, а потом делают шринки эти- они просто дают компьютеру дополнительную работу. Сначала он тратит ресурсы на шринк, потом- на выделение места под базу. Зачем они это делают- от непонимания наверное)) Свободное место внутри файла базы данных- это нормально. Экономить дисковое пространство не нужно, диски копейки стоят, даже ссд, даже на рейд.
(14) Полная модель восстановления- это значит, что транзакции из журнала не удаляются автоматически вообще. Поэтому не уменьшается журнал лога. Раз установить симпл не проблема- установите. После этого завершенные транзакции удалятся и вы сможете сжать файл журнала транзакций. Отвечая на ваш вопрос, чтобы сжать файл- поставьте симпл, после этого он сожмется. Сколько поставили при старте неважно, сжимать мешают транзакции внутри файла, а не стартовое значение.
В журнале sql если я правильно понимаю не хватает одной или двух колонок. Имя пользователя там записывается всегда сервер 1с, поэтому анализ транзакт лога навроде смысла не имеет, и у 1с есть свой журнал регистрации, где все колонки, какие нужны 1сникам (но по которым базу данных не восстановить, как в полной модели).
Смысл делать какие-то другие варианты кроме симпла нет. Уж лучше РИБ один держать полный обмен (если он работает конечно).
Плюс если не рауз, то восстановление последовательности, как и любой Ок или любое записать() в 1с дописывает транзакт лог. Может и еще почему растет, итоги, фоновые задания и т.д.
Смысл делать какие-то другие варианты кроме симпла нет. Уж лучше РИБ один держать полный обмен (если он работает конечно).
Плюс если не рауз, то восстановление последовательности, как и любой Ок или любое записать() в 1с дописывает транзакт лог. Может и еще почему растет, итоги, фоновые задания и т.д.
(11)
(11)
В журнале sql если я правильно понимаю не хватает одной или двух колонок. Имя пользователя там записывается всегда сервер 1с, поэтому анализ транзакт лога навроде смысла не имеет, и у 1с есть свой журнал регистрации, где все колонки, какие нужны 1сникам (но по которым базу данных не восстановить).
В общем-то, в транзакт логе вообще нет колонок, и в нем нет никаких пользователей, и его не анализируют. В нем находятся последние измененные данные.
(11)
Смысл делать какие-то другие варианты кроме симпла нет.
Смысл есть, но он должен четко пониматься. А вот с этим как раз наибольшее количество проблем. Ставят большой размер в надежде, что не будет расти, но не делают бэкапы лога при Full модели. Что есть наглядная демонстрация некомпетентности того, кто это настроил таким образом.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот