Включение отладки на сервере 1С 8
Поможем в ✍️ написании учебной работы
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой

       По умолчанию, при использования клиент-серверного режима работы 1С-предприятия никакие серверные функции и процедуры не будут поддаваться пошаговой отладки. Система будет выполнять их «на сервере 1С 8.3″, такие процедуры не видны для клиентской машины. Для включения отладки 1С в режиме клиент-сервер достаточно последовать простым инструкциям:

Ø остановить службу

Ø перейти в реестр (regedit.exe) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent (x86-64). Открыть ключ «ImagePath» и дописать в конце строки –debug (перед –debug обязательно ставится пробел).

Ø еще возможно надо проставить галочки «Устанавливать режим разрешения отладки» и «Начинать отладку при запуске».

 

7. Что делать если разрастается журнал транзакций - файл _log.ldf для MS-SQL.

       Бывает такое что этот файл «имя базы_log.ldf» весит намного больше чем база (у меня было такое что база весит 4 Гб, log весит 20 Гб), значит были произведены неправильные настройки базы в MS-SQL. Сначала рассмотрим, как уменьшить размер log файла.

Шаг 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) -
указать приемлемый размер лога (можно поставить 0, тогда он выставит для себя автоматически минимальный размер).

После этих манипуляций размер log файла уменьшится до минимума и не будет так сильно расти.

Далее мы рассмотрим, как избежать роста log файла MS-SQL.

       Посмотрите, какой режим восстановления (Recovery) стоит на закладке Options в свойствах базы данных. Он бывает Simple (простой, который требует наименьшего администрирования) или Full (полный, который обеспечивает наилучшую возможность восстановления данных после сбоя). В режиме Full возможен рост журнала транзакций (LDF), поскольку изменения базы данных накапливаются в этом журнале.
Уменьшение журнала транзакций зависит от операции резервного копирования (backup): если не делать резервное копирование, то лог транзакций в режиме Full будет расти.
Обратите внимание на пункт контекстного меню "Shrink Database" (shrink - англ. усадка, усушка, уменьшение). Эта операция уменьшает размер базы данных путем "удаления неиспользуемых страниц" ("remove unused pages"). В свойствах базы данных есть опция "Auto Shrink", которая активизирует автоматическое уменьшение базы, во время периодических проверок неиспользуемого места ("during periodic checks for unused space").
Режим восстановления базы данных:
Теперь рассмотри подробно  три режима восстановления базы данных:
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. Значительное повышение производительности при операциях массовой вставки и при работе с большими двоичными данными вполне оправдывает некоторое снижение возможностей резервного копирования и восстановления. Что важнее для вашей задачи — дополнительные возможности восстановления или максимальная производительность, решать вам.

 













Дата: 2019-05-28, просмотров: 205.