При обновлении бухгалтерии, на этапе сохранения, получил следующую ошибку:
Каталог не обнаружен 'v8srvr://sql/acc_main/configsave/e0666db2-45d6-49b4-a200-061c6ba7d569.6b9d6525-ee94-4e13-b73d-82d3e8e8441d'
по причине: Каталог не обнаружен 'ConfigSave\e0666db2-45d6-49b4-a200-061c6ba7d569.6b9d6525-ee94-4e13-b73d-82d3e8e8441d'
по причине: Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Журнал транзакций для базы данных "acc_main" переполнен. Причина: "LOG_BACKUP". HRESULT=80040E14, SQLSrvr: SQLSTATE=42000, state=2, Severity=11, native=9002, line=1
Идем на сервер и первым делом проверяем место на дисках,
А оно закончилось нужно потом почистить хард или увеличивать объем, а пока порежем лог
Открываем SQL Server Management Studio
Это ошибка Microsoft SQL Server - переполняется лог транзакций и не очищается. Урезать его возможно различными способами, в том числе и с помощью стандартной оснастки, но не всегда данная операция получается, и размер файла лога остается прежним. Как вариант предлагаю следующее решение из двух строчек( где acc_main - название базы Бух)
Результат выполнения:
Тоже самое можно сделать вручную:
Шаг 1. Установить модель восстановления Простая (Simple). Правой кнопкой на базе - Свойства(Properties) - Параметры(Options) - 4-й сверху пункт Модель восстановления(Recovery model) - Простая(Simple) - OK.
Шаг 2. Выполнить шринк (сжатие) лога транзакций. Правой кнопкой на базе - Задачи(Tasks) - Сжать(Shrink) - Файлы(Files) - установить Тип файла(File type) - Журнал(Log) - в Операция сжатия(Shrink action) - выбрать Реорганизовать страницы, перед тем осводить неиспользуемое место(Reorganize pages before releseasing unused space) - Сжать файл (Shrink file to) - указать приемлемый размер лога.
Шаг 3. Установить модель восстановления Полная(Full). Правой кнопкой на базе - Свойства(Properties) - Параметры(Options) - 4-й сверху пункт Модель восстановления(Recovery model) - Полная(Full) - OK.
В дополнении скажу, что можно сохранить лог в файл и выполнить шринк так(BaseDB - имя базы данных):
Связка сервера 1С:Предприятие и PostgreSQL вторая по популярности среди установок 1С и самое используемое решение на платформе Linux. В отличии внедрений на базе Windows и MSSQL, где трудно сделать так, чтобы не заработало, внедрения на базе Linux таят множество подводных камней для неопытного администратора. Часто бывает так, что вроде бы все сделано правильно, но ошибка следует за ошибкой. Сегодня мы рассмотрим самые типовые из них.
Общая информация
Перед тем, как начинать искать ошибки установки и, вообще, приступать к внедрению серверной версии 1С:Предприятия было бы неплохо освежить представление как это работает:
Сервер 1С Предприятия. Часть 1 - Общие вопросы.
В небольших внедрениях сервер 1С и сервер СУБД обычно совмещают на одном физическом сервере, что немного сужает круг возможных ошибок. В нашем случае будет рассматриваться ситуация, когда сервера разнесены по разным машинам. В нашей тестовой лаборатории мы развернули следующую схему:
В нашем распоряжении имеются два сервера под управлением Ubuntu 12.04 x64, на одном из них установлен сервер 1С:Предприятие версии 8.3, на другом PostgreSQL 9.04 от Ethersoft, а также клиент под управлением Windows. Напоминаем, что клиент работает только с сервером 1С, который, в свою очередь, формирует необходимые запросы к серверу СУДБ. Никаких запросов от клиента к серверу управления базами данных не происходит.
Сервер баз данных не обнаруженВАЖНО: пользователь "postgres" не прошёл проверку подлинности (Ident)
Данная ошибка возникает при разнесении серверов по разным ПК из-за неправильно настроеной проверки подлинности в локальной сети. Для устранения откройте /var/lib/pgsql/data/pg_hba.conf, найдите строку:
host all all 192.168.31.0/24 ident[/pre]
и приведите ее к виду:
host all all 192.168.31.0/24 md5[/pre]
где 192.168.31.0/24 - диапазон вашей локальной сети. Если такой строки нет, ее следует создать в секции IPv4 local connections.
Сервер баз данных не обнаруженcould not translate host name "NAME" to address: Temporary failure in name resolution
На первый взгляд ошибка понятна: клиент не может разрешить имя сервера СУБД, типичная ошибка для небольших сетей, где отсутствует локальный DNS-сервер. В качестве решения добавляют запись в файлhosts на клиенте, что не дает никакого результата...
А теперь вспоминаем, о чем было сказано несколько раньше. Клиентом сервера СУБД является сервер 1С, но никак не клиентский ПК, следовательно запись нужно добавлять на сервере 1С:Предприятие в файл/etc/hosts на платформе Linux или в C:\Windows\System32\drivers\etc\hosts на платформе Windows.
Аналогичная ошибка будет возникать, если вы забыли добавить запись типа A для сервера СУБД на локальном DNS-сервере.
Ошибка при выполнении операции с информационной базойserver_addr=NAME descr=11001(0x00002AF9): Этот хост неизвестен.
Как и прошлая, эта ошибка связана с неправильным разрешением клиентом имени сервера. На этот раз именно клиентским ПК. В качестве решения добавляем в файл /etc/hosts на платформе Linux или в C:\Windows\System32\drivers\etc\hosts на платформе Windows запись вида:
192.168.31.83SRV-1C-1204[/pre]
где указываете адрес и имя вашего сервера 1С:Предприятия. В случае использования локального DNS следует добавить A-запись для сервера 1С.
Ошибка СУБД: DATABASE не пригоден для использования
Гораздо более серьезная ошибка, которая говорит о том, что вы установили несовместимую с 1С:Предприятие версию PostgreSQL или допустили грубые ошибки при установке, например не установили все необходимые зависимости, в частности библиотеку libICU.
Если вы имеете достаточный опыт администрирования Linux систем, то можете попробовать доустановить необходимые библиотеки и заново инициализировать кластер СУБД. В противном случае PostgreSQL лучше переустановить, не забыв удалить содержимое папки /var/lib/pgsql.
Также данная ошибка может возникать при использовании сборок 9.1.x и 9.2.x Postgre@Etersoft, подробности смотрите ниже.
Ошибка СУБД: ERROR: could not load library "/usr/lib/x86_64-linux-gnu/postgresql/fasttrun.so"
Довольно специфичная ошибка, характерная для сборок 9.1.x и 9.2.x Postgre@Etersoft, также может приводить предыдущей ошибке. Причина кроется в неисправленной ошибке в библиотеке fasttrun.so. Решение - откатиться на сборку 9.0.x Postgre@Etersoft.
Ошибка СУБДERROR: type "mvarchar" does not exist at character 31
Возникает если база данных была создана без помощи системы 1С:Предприятия. Помните, для работы с 1С базы данных следует создавать только с использованием инструментов платформы 1С: через консоль Администрирование серверов 1С Предприятия
или через средство запуска 1С.
Сервер баз данных не обнаруженВАЖНО: пользователь "postgres" не прошёл проверку подлинности (по паролю)
Очень простая ошибка. Неправильно указан пароль суперпользователя СУБД postgres. Вариантов решения два: вспомнить пароль или изменить его. Во втором случае вам нужно будет изменить пароль в свойствах всех существующих информационных баз через оснастку Администрирование серверов 1С Предприятия.
Сервер баз данных не обнаруженFATAL: database "NAME" does not exist
Еще одна очень простая ошибка. Смысл ее сводится к тому, что указанная БД не существует. Чаще всего возникает из-за ошибки в указании имени базы. Следует помнить, что информационная база 1С в кластере и база данных СУБД - две разные сущности и могут иметь различные имена. Также следует помнить, что Linux системы чувствительны к регистру и для них unf83 и UNF83 два разных имени.
Можно также сделать через интерактивное нажатие кнопки. На форму помещаем кнопку, в ее свойствах выставляем "ИсточникДействий" - нужное нам Табл. Поле, в событии "Нажатие" выбираем "Вывести список..."
Если такое происходит, обратите внимание на следующее:
Посмотрите, какой режим восстановления (Recovery) стоит на закладке Options в свойствах базы данных. Он бывает Simple (простой, который требует наименьшего администрирования) или Full (полный, который обеспечивает наилучшую возможность восстановления данных после сбоя). В режиме Full возможен рост журнала транзакций (LDF), поскольку изменения базы данных накапливаются в этом журнале.
Уменьшение журнала транзакций зависит от операции резервного копирования (backup): если не делать резервное копирование, то лог транзакций в режиме Full будет расти.
Обратите внимание на пункт контекстного меню "Shrink Database" (shrink - англ. усадка, усушка, уменьшение). Эта операция уменьшает размер базы данных путем "удаления неиспользуемых страниц" ("remove unused pages").
В свойствах базы данных есть опция "Auto Shrink", которая активизирует автоматическое уменьшение базы, во время периодических проверок неиспользуемого места ("during periodic checks for unused space").
Для базы данных предприятия в свойствах базы я установил опцию Full Recovery. На этой же закладке я установил флажок Auto Shrink. Базу надо периодически архивировать, для чего я настроил автоматическое архивирование базы данных (каждое утро) и журнала транзакций (каждые 10 минут).
Режим восстановления базы данных:
Режимы восстановления базы данных (recovery models) баз данных SQL Server 2005, полное протоколирование (full), неполное протоколирование (bulk-logged), простая модель восстановления (simple)
Одно из важных решений, которые нужно принять при создании базы данных — в каком режиме восстановления будет работать база. Этот параметр выбирается на вкладке Options свойств базы данных в строке Recovery Model (Режим восстановления) (над списком остальных параметров). Изменить режим восстановления базы данных можно также при помощи команды A_lter DATABASE.
Всего предусмотрено три режима восстановления базы данных: Full (режим полного протоколирования) — в этом режиме максимальное количество операций записывается в журнал транзакций. Журнал транзакций автоматически не обрезается. Этот режим обеспечивает максимальные возможности восстановления (за счет снижения производительности). Только в этом режиме вы можете использовать зеркальное отображение баз данных и автоматическую доставку журналов (log shipping). Именно этот режим выбирается по умолчанию для пользовательских баз данных, поскольку он настроен для базы данных model. Если изменить режим восстановления для базы данных model, то для создаваемых баз данных по умолчанию будет выбираться новый режим.
Bulk-logged (режим неполного протоколирования) — это компромисс между требованиями производительности и возможностями восстановления. При использовании этого режима запись в журнал практически отключается (в терминологии Microsoft — проводится минимальное протоколирование) для операций следующих типов:
- массовой вставки (команды BULK I_nsert, S_elect INTO, загрузка средствами bcp и т. п.);
- вставка/изменение больших двоичных данных (text, ntext, image);
- операции по созданию, перестроению и удалению индексов.
Автоматическая перезапись журналов транзакций при этом не производится, работа с транзакциями, не включающими в себя перечисленные операции, производится как обычно.
При работе в этом режиме вы лишаетесь возможности использовать журнал транзакций для восстановления (при утрате файлов данных, на момент времени или на метку транзакции), если в нем была хотя бы одна запись о перечисленных ранее операциях. Microsoft рекомендует не использовать этот режим восстановления на постоянной основе, а переключаться в него из режима Full на время выполнения больших операций массовой вставки, а потом возвращаться обратно.
Simple (простая модель восстановления) — максимальный выигрыш в производительности и удобстве работы за счет возможностей восстановления. Минимально протоколируются те же операции, что и в режиме восстановления Bulk-logged, а кроме этого, журнал транзакций автоматически очищается (блоками, размер которых изначально равен 256 Кбайт, но при необходимости он может быть автоматически увеличен). В результате вы получаете максимальную производительность и возможность не думать о потенциальной нехватке места в журнале транзакций. Но в этом режиме использовать журнал транзакций для восстановления уже не удасться. Вы не сможем даже выполнить резервное копирование журнала транзакций: команда BACKUP LOG в этом режиме сразу вернет ошибку.
Какой же режим восстановления выбрать?
Microsoft (в своих учебных курсах) рекомендует для рабочих баз данных выбирать только режим Full. Однако из опыта проведения автором этих самых учебных курсов и общения со слушателями можно сказать, что очень многие опытные администраторы сознательно настраивают для своих баз данных режим восстановления Simple. Значительное повышение производительности при операциях массовой вставки и при работе с большими двоичными данными вполне оправдывает некоторое снижение возможностей резервного копирования и восстановления. Что важнее для вашей задачи — дополнительные возможности восстановления или максимальная производительность, решать вам. Рост журнала транзакций в 1С MS SQL Server
Добавление записи в журнал расчетов: Метод Новая может быть вызван где угодно, в глобальном модуле, модуле обработок, документов и т.д.
Данный метод проверяет корректность заполненных реквизитов журнала расчетов. При вводе новых записей журнала расчетов методами Новая и Записать обязательно должны быть заполнены следующие реквизиты записи журнала: Объект, Документ, ВидРасч. Кроме того, проверяется корректность реквизитов ДатаНачала и ДатаОкончания. Если реквизиты ДатаНачала и ДатаОкончания не установлены явным образом, при записи они устанавливаются как начало и окончание текущего расчетного прериода, соответственно. Реквизит ПериодРегистрации заполняется текущим значением расчетного периода, установленным для журнала расчетов (см. метод УстановитьПериодРасчета). Если реквизит РодительскийДокумент не установлен явным образом, для него устанавливается то же значение, что и для реквизита Документ. Если реквизиты Рассчитана, Сторно, Перерасчет, Фиксирована не установлены, то запись вводится как простая нерассчитанная, нефиксированная запись.
Внимание! При вводе новых записей в журнал расчетов методами Новая и Записать записи вводятся «как есть». Система не выполняет правила перерасчетов, а также правила взаимного вытеснения видов расчета. Ввод произвольных записей журнала расчетов очень ответственная операция. При использовании этих методов следует внимательно следить за логической целостностью журнала расчетов
Добавить записи в журнал расчетов которые вводятся при проведении документов: Методы ВвестиРасчет и ЗаписатьРасчет могут быть вызваны только в модулях документов,
вводящих расчеты. Вызвать эти методы в модулях иных объектов, например
в модуле формы списка ЖЗ или в модуле отчета (обработки), нельзя.
или
Отличие метода ЗаписатьРасчет заключается в том, что ввод вытесняющих расчетов приводит к вытеснению только тех расчетов, которые имеют меньший приоритет, а не меньший либо равный, как в случае с методом ВвестиРасчет. Это приводит, в частности, к тому, что за счет применения этого метода расчет не вытесняет «сам себя».
При записи невытесняющего расчета ввод новых записей также происходит «осмотрительно» — новые записи вводятся только в том случае, если в журнале расчетов нет точно такой же записи. Под точно такой же записью здесь подразумевается запись с таким же видом расчета, для того же объекта и с тем же периодом действия.
Вывод: Для обновления самовытесняющего расчета при его повторном вводе другим документом
вместо метода ЗаписатьРасчет используется метод ВвестиРасчет.
Как получить количество рабочих дней в месяце по календарю? 
нужно потом почистить хард или увеличивать объем, а пока порежем лог
.gif)
