Different ways to flush or clear sql server cache

Настройка сервера 1С

Вначале необходимо создать рабочую базу данных, это можно сделать двумя способами:

1. Через консоль управления серверами «1С:Предприятие». Выбрать Console Root -> Central 1C:Enterprise 8.3 servers -> (*)hq-1c-app02-hw -> Кластеры -> Локальный кластер -> Информационная база, правый щелчок мыши -> Создать -> Информационная база. Задать имя на латинице, Защищенное соединение = выключено, Задать имя компьютера с СУБД, Тип СУБД = MS SQL Server, Пользователь и пароль БД, Разрешить выдачу лицензий = да, установить галочку «Создать базу в случае ее отсутствия», нажать «ОК». База создана.

Создание БД при помощи менеджера 1С

1. Экспертный режим. Для создания базы 1С настройка SQL производится непосредственно через менеджер СУБД MSSQL, для этого необходимо создать копию существующей базы <model>. После этого проверить ее настройки в свойствах на вкладке Files, начальный размер файлов БД должен находиться в диапазоне от 1 до 10 Гб, файлов журналов от 1 до 2 Гб, инкрементирующее значение = 512 Мб.

Установка параметров скопированной базы

1. Определить модель восстановления в режим полного функционала (Full), а параметр Auto update statistics asynchronously перевести в режим включено (True).

Установка дополнительных параметров БД

Созданную БД tempdb в разделе Files разбить на 4 части (tempdev, tempdev01, tempdev02, tempdev03), размер зависит от того, где находятся сами файлы (50 % от дискового пространства, если на отдельном диске, от 1 Гб если на диске с рабочей СУБД). Рабочую базу создать аналогичным образом, размер задавать в соответствии с потребностью.

Выделение квот объема памяти для БД

Также необходимо выставить флаги трассировки в соответствии с инструкциями:

В настройках сетевых протоколов включить режим TCP/IP, отключить Named pipes, если сервера не разделены – включить Shared Memory

Настройка параметров для сети

Выполнить инструкции по настройке обратной связи с операторами БД:

На этом экспертная настройка базы данных завершена.

После того, как база создана, необходимо запустить технологическую платформу и нажать кнопку «Добавить» – «Создание новой информационной базы». Указать наименование базы и местоположение на сервере 1С Предприятия. В открывшемся окне заполнить параметры, соответствующие созданной на прошлом этапе БД. Нажать «ОК» и приступить к работе по настройке необходимой конфигурации.

Особенности настройки и установки сервера 1С

Для настройки и установки серверного программного обеспечения необходимо подобрать подходящую аппаратную часть. Делается это исходя из поставленных перед предприятием задач, которые определяют степень загруженности сервера 1С приложений. Иерархию таких потребностей можно построить следующим образом:

Далее необходимо рассмотреть варианты аппаратной части для предложенных трех случаев.

Обратите внимание! Следует заметить, что рекомендуется устанавливать именно серверное «железо» (процессоры семейства Xeon, отказоустойчивые и быстродействующие SSD, регистровая память и т.д.)

1. В первом случае ЦПУ должен обладать базовой частотой не менее 1,8 ГГц, объем ОЗУ должен составлять не менее 8 Гб, емкость твердотельного накопителя не менее 120 Гб и скоростью сетевого интерфейса не менее 1 Гбит/сек в случае, если базы SQL установлены на стороннем сервере. При смежной установке требуется подъем тактовой частоты ЦПУ до 2 ГГц, объема ОЗУ до 32 Гб и емкости жесткого диска до 500 Гб.
2. Второй вариант также предусматривает два вида организации сервера. Для первого случая (раздельная установка платформы и базы) тактовая частота начинается от 2 ГГц, объем ОЗУ от 32 Гб, SSD от 500 Гб, скорость сетевого интерфейса 1 Гбит/сек. В случае смежной установки используется процессор с частотой 3 ГГц, ОЗУ не менее 128 Гб, SSD емкостью не менее 1 Тб, скорость передачи данных по сети не менее 1 Гбит/сек.
3. В третьем случае использование раздельного хранения базы данных настоятельно не рекомендуется. Взаимодействие двух решений в рамках одного сервера обеспечивается сборкой на базе ЦПУ с тактовой частотой 3 ГГц и максимально доступным количеством потоков (зависящих от ядер), объемом ОЗУ не менее 128 Гб, SSD не менее 1 Тб и скоростным сетевым интерфейсом не менее 1 Гбит/сек.

Важно. Необходимо помнить, что конкретный выбор комплектующих сервера зависит от четко поставленной задачи

Чем выше потребности – тем выше требования к вычислительным мощностям и отказоустойчивости, которая хорошо проявляется у серверных операционных систем семейства Microsoft Windows Server.

Для конфигурации программной части под 1с сервер установка и настройка приложений производится в соответствии с нижеизложенными инструкциями.

Обновление статистик

MS SQL Server строит план запроса на основании статистической информации о распределении значений в индексах и таблицах. Статистическая информация собирается на основании части (образца) данных и автоматически обновляется при изменении этих данных. Иногда этого оказывается недостаточно для того, что MS SQL Server стабильно строил наиболее оптимальный план выполнения всех запросов.

В этом случае возможно проявление проблем с производительностью запросов. При этом в планах запросов наблюдаются характерные признаки неоптимальной работы (неоптимальные операции).

Для того, чтобы гарантировать максимально правильную работу оптимизатора MS SQL Server рекомендуется регулярно обновлять статистики базы данных MS SQL.

Для обновления статистик по всем таблицам базы данных необходимо выполнить следующий SQL запрос:

exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'

Обновление статистик не приводит к блокировке таблиц, и не будет мешать работе других пользователей. Статистика может обновляться настолько часто, насколько это необходимо. Следует учитывать, что нагрузка на сервер СУБД во время обновления статистик возрастет, что может негативно сказаться на общей производительности системы.

Оптимальная частота обновления статистик зависит от величины и характера нагрузки на систему и определяется экспериментальным путем. Рекомендуется обновлять статистики не реже одного раза в день.

Приведенный выше запрос обновляет статистики для всех таблиц базы данных. В реально работающей системе разные таблицы требуют различной частоты обновления статистик. Путем анализа планов запроса можно установить, какие таблицы больше других нуждаются в частом обновлении статистик, и настроить две (или более) различных регламентных процедуры: для часто обновляемых таблиц и для всех остальных таблиц. Такой подход позволит существенно снизить время обновления статистик и влияние процесса обновления статистики на работу системы в целом.

Настройка автоматического обновления статистик (MS SQL 2005)

Запустите MS SQL Server Management Studio и подключитесь к серверу СУБД. Откройте папку Management и создайте новый план обслуживания:

Создайте субплан (Add Subplan) и назовите его «Обновление статистик». Добавьте в него задачу Update Statistics Task из панели задач:

Настройте расписание обновления статистик. Рекомендуется обновлять статистики не реже одного раза в день. При необходимости частота обновления статистик может быть увеличена.

Настройте параметры задачи. Для этого следует два раза кликнуть на задачу в правом нижнем углу окна. В появившейся форме укажите имя базу данных (или несколько баз данных) для которых будет выполняться обновление статистик. Кроме этого вы можете указать для каких таблиц обновлять статистики (если точно неизвестно, какие таблицы требуется указать, то устанавливайте значение All).

Обновление статистик необходимо проводить с включенной опцией Full Scan.

Сохраните созданный план. При наступлении указанного в расписании срока обновление статистик будет запущено автоматически.

Общие сведения

Одной из часто встречающихся причин неоптимальной работы системы является неправильное или несвоевременное выполнение регламентных операций на уровне СУБД

Особенно важно выполнять эти регламентные процедуры в крупных информационных системах, которые работают под значительной нагрузкой и обслуживают одновременно большое количество пользователей. Специфика таких систем в том, что обычных действий, выполняемых СУБД автоматически (на основании настроек) оказывает недостаточно для эффективной работы

Если в работающей системе наблюдаются какие-либо симптомы проблем с производительностью, следует проверить, что в системе правильно настроены и регулярно выполняются все рекомендуемые регламентные операции на уровне СУБД.

Выполнение регламентных процедур должно быть автоматизировано. Для автоматизации этих операций рекомендуется использовать встроенное средства MS SQL Server: Maintenance Plan. Существуют так же другие способы автоматизации выполнения этих процедур. В настоящей статье для каждой регламентной процедуры дан пример ее настройки при помощи Maintenance Plan для MS SQL Server 2005.

Для MS SQL Server рекомендуется выполнять следующие регламентные операции:

• Обновление статистик
• Очистка процедурного КЭШа
• Дефрагментация индексов
• Реиндексация таблиц базы данных

Рекомендуется своевременность и правильность выполнения данных регламентных процедур.

Компонент PL/SQL Function Result Cache

Компонент SQL Query Result Cache (Кэш результатов SQL-запросов) разделяет инфраструктуру кэша результатов с компонентом PL/SQL Function Result Cache (Кэш результатов PL/SQL-функций), который кэширует результаты PL/SQL-функций. Кандидатами на помещение в кэш результатов PL/SQL-функций являются те функции, которые используются в базе данных часто и зависят от относительно статической информации. При желании можно указать, что база данных должна делать находящиеся в кэше результаты PL/SQL-функции недействительными в случае внесения изменений в любой из объектов, от которых эта функция зависит.

Создание кэшируемой функции

Заставить базу данных помещать результаты функции в кэш PL/SQL Function Result Cache можно, включив в определение PL/SQL-функции конструкцию RESULT_CACHE, например, так: 

SQL> CREATE OR REPLACE function
get_dept_info (dept_id number) RETURN dept_info_record
result_cache relies_on (employees)
IS
rec dept_info_record;
BEGIN
SELECT AVG(salary), COUNT(*) INTO rec
FROM employees
WHERE department_id = dept_id;
RETURN rec;
END get_dept_info;
/

Конструкция RELIES_ON является необязательной. Она указывает, что база данных должна делать результаты функции в кэше недействительными в случае подвергания любой из таблиц или других объектов, от которых эта функции зависит, какому-нибудь изменению. При первом выполнении функции GET_DEPT_INFO базой данных она будет выполняться обычным образом. При последующих же выполнениях этой функции база данных будет извлекать ее значения прямо из кэша PL/SQL Result Function Cache вместо того, чтобы выполнять ее заново. Выполнять функции заново база данных будет только в следующих случаях.

• В случае обхода кэша результатов за счет не указания подсказки RESULT_CACHE.
• В случае выполнения процедуры DBMS_RESULT_CACHE_BYPASS для вынуждения функций и запросов обходить кэш результатов, независимо от значения параметра RESULT_CACHE_MODE или указания подсказки RESULT_CACHE.
• В случае изменения любого из лежащих в основе функции объектов и указания конструкции RELIES_ON в ее определении.
• В случае удаления находящихся в кэше результатов базой данных из-за того, что система нуждается в дополнительной памяти.

Ограничения

Для того чтобы база данных помещала результаты PL/SQL-функции в кэш, эта функция должна удовлетворять следующим требованиям:

• не содержать никаких параметров IN/OUT;
• не представлять собой анонимный блок;
• не определяться в модуле, который обладает правами вызывающего (invoker rights);
• не содержать параметров типа коллекций, объектного типа, типа REF CURSOR или LOB;
• не представлять собой конвейерную табличную функцию.

Помимо соблюдения этих требований, функция еще не должна зависеть ни от каких специфических параметров сеансов или контекстов приложений, а также не иметь побочных эффектов.

Quick Summary of DBCC FREEPROCCACHE command

Below is the quick summary of what we learned about DBCC FREEPROCCACHE command in this article:

• It clears out the plan cache in SQL Server for a specific plan hash or all plan as per the parameters used
• SQL Server forces to generate a new execution plan of each stored procedure on the next execution
• It might increase the utilization of system processes such as CPU, memory
• It might be good for the development environment, but try to use caution in executing this command in the production environment
• You should clear the cache only when it is crucial to do so
• We can use an alternative method sp_recompile to generate a new plan for the stored procedure
• It is a better approach than restarting SQL Server instance to clear the cache however we should not do it frequently

Шаг 4. Настройка Планов обслуживания (Maintenance Plans, Регламентных заданий)

Для работы регламентных заданий необходимо создать план обслуживания:

Итак, приведу свой пример настроенного Maintenance Plans с комментариями. Мой план состоит из 5 подпланов:

Первый подплан (ежедневное еженочное обслуживание сервера и резервных копий):

 

Данный подплан состоит из нескольких шагов. Связи зеленого цвета задают переход к следующему заданию при удачном завершении (т.е. без ошибок), связи синего цвета задают переход к следующему заданию при любом результате выполнения текущего. Параметры шагов видны на размещенных в редакторе заданиях. Параметры некоторых заданий нужно описать отдельно. Первым шагом выполняется «Проверка целостности базы данных» (Check Database Integrity Task), которая выполняется для всех баз системы и следующие задания выполняются только при отсутствии ошибок при проверке баз. Следующим шагом выполняется «Перестроение индексов баз данных» (Rebuild Index Task) для всех баз данных сервера. Данная процедура довольно ресурсоемкая, но в последствии ускоряет работу базы, т.к. если фрагментированость индексов > 25%, это резко снижает производительность сервера. Если размер баз не позволяет выполнять данную задачу, т.к. она занимает много времени, то рекомендуется делать данное действие хотябы раз в неделю, при этом, на ночные задания заменить задачу Перестроение индексов баз данных (Rebuild Index Task) на Дефрагментацию индекса (Reorganize Index Task), которая менее  ресурсоемка. Далее происходит «Обновление статистики базы данных» (Update Statistics Task) для всех баз данных, опять же для оптимизации. После этого задания рекомендуется выполнить «Очистку процедурного кэша»:

При этом, запускается процедура

DBCC FREEPROCCACHE

После оптимизации работы желательно сделать резервную копию журналов транзакций. Этот шаг делать не обязательно, но желательно.  Во время выполнения предыдущих шагов (Перестроение индексов баз данных (Rebuild Index Task) и Обновление статистики базы данных (Update Statistics Task)) файлы журналов вырастают примерно до размера базы данных, а то и более. В результате, в следующих подпланах при выполнении первого резервного копирования журнала транзакций, размер копии имеет довольно большой объем. Это может сильно увеличить вермя восстановления базы. Таким образом, делая копию логов до полной копии, мы избавляемся от данной проблемы. (спасибо за идею комментатору Kyoshiro)

Далее можно выполнить полный бэкап заданием Создание резервной копии базы данных (Back Up Database Task):

При выполнении данного задания копии складываются в сетевую папку на файловом сервере с расширением bak, при этом, для каждой базы создается своя папка:

SAMBA ~ # ls -1 /backup/full/
database1
database2
...
SAMBA ~ # ls -1 /backup/full/satabase1/
database1_backup_201111210250.bak
database1_backup_201111220251.bak
...

После заверешения создания резервной копии параллельно запускается 3 задания: очистка резервных копий журналов транзакция (о создании таких копий — ниже) старее 5 дней, очистка полных бэкапов старее 1 недели и очистка истории старше 1 месяца (сюда входит в основном — очистка служебной информации MS SQL, такой как журналы):

Данный подплан у меня запускается каждую ночь в нерабочее время по будням:

Второй, третий, четвертый подплан (обновление статистики 3 раза в день):

Следующие 3 подплана одинаковы по содержимому и различаются лишь временем выполнения. Выполняются 3 раза в день — в 6, 13 и 19 часов:

Обновление статистики довольно ресурсоемкая задача, поэтому спланируйте ее выполнение в то время, когда база данных не сильно загружена.

Пятый подплан (резервное копирование журнала транзакций):

Данный план выполняет инкрементальное копирование транзакционного лога Microsoft SQL Server:

Копирование выполняется каждые пол часа в рабочее время и сохраняется в сеть с расширением trn:

После настройки данного плана мы имеем регулярное резервное копирование с необходимым регламентным обслуживанием, с хранением копий базы данных за последние 7 дней с возможностью восстановления базы интервалом до 30 минут.

Более подробно о выборе и планировании плана обслуживания можно посмотреть данный подкаст(временно убран по причине заражения сайта s.rpod.ru):

Управление кэшем результатов

Для управления кэшем результатов, например, для проверки его состояния или сбрасывания его содержимого, служит пакет DBMS_RESULT_CACHE. Ниже приведен пример проверки объема выделяемой кэшу памяти за счет выполнения такой функции из этого пакета, как MEMORY_REPORT:

SQL> set serveroutput on
SQL> exec dbms_result_cache.memory_report
R e s u l t C a c h e M e m o r y R e p o r t

Block Size = 1K bytes
Maximum Cache Size = 672K bytes (672 blocks)
Maximum Result Size = 33K bytes (33 blocks)

Total Memory = 5132 bytes 
... Fixed Memory = 5132 bytes 
... Dynamic Memory = 0 bytes 
PL/SQL procedure successfully completed.
SQL>

С помощью функции STATUS можно проверять текущее состояние кэша результатов, каковое может выглядеть как ENABLED или DISABLED. Очищается кэш результатов посредством процедуры или функции FLUSH. Необходимость в очистке кэша результатов может возникать в случае его полного заполнения базой данных, поскольку автоматически сброс его содержимого не происходит. При загрузке новой версии функции, например, может быть удобно избавиться от результатов старой функции в кэше, удалив их с помощью процедуры или функции FLUSH. Перед выполнением процедуры или функции FLUSH, однако, нужно обязательно перевести кэш результатов в обходной режим, запустив процедуру BYPASS со значением TRUE. После очистки кэша результатов нужно выполнить процедуру BYPASS снова, но на этот раз со значением FALSE, как показано ниже:

BEGIN
EXEC dbms_result_cache.bypass (FALSE);
END;
/
PL/SQL procedure successfully completed.
SQL>

Ниже перечислены представления, которые можно использовать для управления кэшем результатов.

• V$RESULT_CACHE_STATISTICS. Это представление отображает перечень настроек кэша и статистические данные по используемой им памяти.
• V$RESULT_CACHE_OBJECTS. Это представление отображает список всех находящихся в кэше объектов и их атрибутов.
• V$RESULT_CACHE_DEPENDENCY. Это представление отображает информацию о зависимостях между находящимися в кэше результатами и объектами, от которых они зависят.
• V$RESULT_CACHE_MEMORY. Это представление отображает список всех используемых кэшем блоков памяти и статистические данные по ним.
• V$RESULT_CACHE_OBJECTS. Это представление отображает список как всех находящихся в кэше результатов, так и их зависимостей.

Например, для выяснения того, какие результаты находятся в кэше результатов, можно воспользоваться следующим запросом к представлению V$RESULT_CACHE_OBJECTS:

SQL> select type,status,name from v$result_cache_objects;
TYPE           STATUS          NAME
------------   ----------- ------------------------------------
Dependency     Published       HR.COUNT_EMP
Result         Published       select /* + result_cache
                               query name(q1) */
                               last_name, salary from hr.employees
                               order by salary
SQL>

Вывод приведенного выше запроса показывает, что в текущий момент в кэше результатов находятся два результата.

Ограничения по использованию кэша результатов SQL-запросов

Ниже перечислены объекты, для которых нельзя помещать результаты в кэш результатов SQL-запросов (SQL Query Result Cache):

• временные таблицы;
• таблицы словаря данных;
• недетерминированные функции PL/SQL;
• псевдофункции curval и nextval;
• функции SYSDATE, SYS_TIMESTAMP, CURRENT_DATE, CURRENT_TIMESTAMP, LOCAL_TIMESTAMP, USERENV, SYS_CONTEXT и SYS_QUID.

Кроме того, в кэш нельзя помещать результаты подзапросов, но для них можно использовать подсказку RESULT_CACHE во вложенном представлении.

Database instant file initialization — частично миф, частично реальность

Рекомендуют включить возможность Database instant file initialization для пользователя, от которого запущена служба Microsoft SQL Server.

Что это за штука?

Во-первых, эта настройка влияет только на файл данных. Когда файл автоматически вырастает, то новый кусок заполняется нулями, в этот момент 1С может тормозить. Instant File Initialization (IFI) позволяет отключить это зануление.

Делается так.

1. Запускаем Local Group Policy Editor:
2. Слева выбираем Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assigment.
3. Тыкаем в Perform volume maintenance tasks.
4. Сюда добавляем юзера, от имени которого запускается SQL Server.

Однако, у меня там уже прописана группа Administrators, а пользователь, под которым работает служба SQL Server уже в этой группе.

Так что у меня ничего не пришлось настраивать. Но вы у себя проверьте.

Давайте проверим, что всё работает. Рекомендуют создать новую БД размером 5 Гб и логом 1 Мб. Вот тут тоже нужно быть внимательным, нужно создавать под тем же пользователем, от которого запускается сервис SQL. Я создам от имени другого пользователя, который тоже в группе Administrators.

База создалась мгновенно. На всякий случай попробую создать базу размером 50 Гб, место есть. Да, моментально на диске пропало 50 Гб и БД создалась быстро.

Вывод:

Эту настройку применяем только при необходимости.

1 ответы

Ваши вопросы повсюду, поэтому я постараюсь рассмотреть их все.
Кэш процедуры только настолько велик. Кэш вашей процедуры может
быть заполнен одноразовыми планами (это не влияет на статистику,
хотя статистика может влиять на кеш плана). Вы можете прочитать
много подробностей об одноразовых планах в блоге Kimberly Tripp, «
Планировать кеш
и оптимизировать для рабочих нагрузок adhoc » — включая запрос
от sys.dm_exec_cached_plans , который поможет
определить, когда кэш заполнен множеством одноразовых планов. Как
она предлагает, вы можете предотвратить это вздутие живота,
используя оптимизацию для специальных рабочих нагрузок. Если вам
нужно часто это делать, я бы сказал, что планирование freeproccache
в качестве задания — это групповая помощь, а не решение.

Чтобы очистить «плохой» план, сначала вам нужно определить
«плохой» план. Это может быть план, который превышает определенный
размер и/или не был выполнен за какое-то время, или что вы
идентифицировали по длительному запросу и т. Д. К сожалению, не
просто определить план, который является жертвой параметра нюхать,
если вы уже не знаете запрос или запросы, на которые влияет.
Предположим, вы хотите найти самые старые планы в кеше, которые не
были запущены за неделю:

Теперь вам нужно убедиться, что вы действительно хотите удалить
этот план. Например, если вы признаете этот запрос как что-то, над
чем может работать CEO завтра, возможно, лучше оставить его там.
Если вы хотите очистить план, вы можете очистить его, сказав:

Это звучит намного больше, чем работающий глобально, но если у вас много планов
good в кеше, это, безусловно, будет лучше для ваших
пользователей в общем и целом.

Тем не менее, это действительно звучит как бандаж. Если ваш кеш
заполняется нежелательным эффектом, и производительность идет в
туалет до тех пор, пока вы не освободите кеш, вам нужно посмотреть
на более высокий уровень в архитектуре, как будут отправляться
запросы и т. Д. Это поведение, которое я ожидаю от очень первая
итерация LINQ2SQL, где он будет кэшировать версию плана для запроса
для каждого строкового аргумента, который был другой длины.
Поэтому, если у вас есть параметр «Январь», у вас будет другой
план, чем с параметром «Февраль», потому что он будет определять
тип данных как vs. . Довольно уверен, что поведение исправлено, но я
недостаточно знаю о вашей среде/приложении, чтобы предлагать, где
именно искать «плохие идеи».

8

Возможные сложности, с которыми можно столкнутся при установке и настройке сервера 1С

Когда установка SQL для 1с и платформы Предприятие на сервер были выполнены в соответствии с вышеприведенными инструкциями, проблем возникнуть не должно в принципе. Если ошибки все же появляются, то они однозначно связаны с тремя основными причинами, соответственно решение будет заключаться в их устранении:

Низкая производительность аппаратной части. Будет проявляться в виде системных ошибок, медленной работы ПО и т.д.

Обратите внимание! В этом случае необходимо сконфигурировать свой сервер, чтобы обеспечить программному обеспечению оптимальный режим работы. Несвоевременное обслуживание дисковых пространств

Также может привести к значительному замедлению работы сервера. Если используется HDD, то необходимо хотя бы один раз в неделю производить его проверку с последующей дефрагментацией. В случае использования SSD (что гарантирует максимальный уровень производительности) дефрагментация категорически запрещена, необходимо настроить непрерывный мониторинг состояния диска

Несвоевременное обслуживание дисковых пространств. Также может привести к значительному замедлению работы сервера. Если используется HDD, то необходимо хотя бы один раз в неделю производить его проверку с последующей дефрагментацией. В случае использования SSD (что гарантирует максимальный уровень производительности) дефрагментация категорически запрещена, необходимо настроить непрерывный мониторинг состояния диска.

Ошибка «Не найдена лицензия. Не обнаружен ключ защиты программы или полученная программная лицензия». Возникает, когда сервер не может обнаружить HASP ключ. Если его нет, то необходимо приобрести, если же он уже вставлен в USB то дело может быть в системной службе. Для решения проблемы надо запустить командную строку от имени администратора и выполнить команду net start “HASP Loader”, в большинстве случаев такой шаг помогает.

Ошибки, возникающие при запуске службы агент сервера 1с предприятия 8.3. Обычно связаны с настройками прав пользователей или правилами локальной политики безопасности. Более конкретную информацию о возникшей проблеме необходимо изучать при помощи журналов системы (Приложения, События, Система).

Обратите внимание! После чего добавлять пользователя в нужные группы, обеспечивая ему достаточные права доступа. Как видно, установка 1с sql достаточно ответственное занятие, включающее в себя работу как с аппаратной частью, так и с программным обеспечением, что требует присутствия некоторых навыков в этой области

Однако представленная статья в полной мере рассматривает, как установить 1С сервер, предлагая конкретную пошаговую инструкцию. Если ей следовать, то как результат проделанной работы будет рабочая версия БД MS SQL для 1С, привязанная к технологической платформе

Как видно, установка 1с sql достаточно ответственное занятие, включающее в себя работу как с аппаратной частью, так и с программным обеспечением, что требует присутствия некоторых навыков в этой области. Однако представленная статья в полной мере рассматривает, как установить 1С сервер, предлагая конкретную пошаговую инструкцию. Если ей следовать, то как результат проделанной работы будет рабочая версия БД MS SQL для 1С, привязанная к технологической платформе.

Подготовка к деинсталляции

Перед тем как приступить к процессу уничтожения данных, нужно подготовиться:

1. Удостовериться в том, что у файла подкачки Windows достаточный размер. Оптимальным показателем является диапазон:
   • от 3548 до 3548 Мб для ПК с оперативкой 2048 Мб;
   • от 3024 до 3024 Мб для ПК с оперативкой 4096 Мб;
   • от 2016 до 2016 Мб для ПК с оперативкой 8 Гб. Нехватка виртуальной памяти может привести к тому, что SQL Server 2008 будет удален с компьютера не полностью.
2. Если на ПК установлено несколько версий SQL Server, то браузер будет уничтожен после деинсталляции последней версии. Для полного удаления SQL Server 2017 нужно будет в разделе «Программы и компоненты» вручную деинсталлировать браузер SQL Server из перечня софта.
3. После очистки приложения будут удалены все tempdb. Так, данные по шаблону «tempdb_mssql_*.ndf» уничтожатся. Требуется сохранить нужные файлы.

Перед деинсталляцией важно выполнить следующие операции:

1. Сохранить имеющиеся базы данных tempdb: создать резервную копию БД. Для этого скопировать данные и журналы из директории MSSQL в любую другую папку. Так, нужно сохранить файлы в формате «.mdf» под именами «Master», «Model», «Msdbdata», «Mssqlsystemresource», «Tempdb» и «.ldf» под именами «Mastlog», «Modellog», «Msdblog», «Mssqlsustemresource»и «Templog», а также БД Reporting Services ReportServer и ReportServerTempDB – временную БД Службы Reporting Services.
2. Уничтожить локальные группы безопасности.
3. Остановить службы через «Диспетчер задач».
4. Перейти в учетную запись с правами admin.

Maximum Degree of Parallelism and DBCC FREEPROCCACHE command

Usually, experienced DBA with performance troubleshooting skills, modify the SQL Server max degree of parallelism (MAXDOP) setting to control the number of processors in the parallel query execution plan. The default value of MAXDOP is 0, and it allows SQL Server to use all available CPU for the parallel execution plan.

This article does not cover the detailed information of MAXDOP; you can refer to the article Max Degree of Parallelism in SQL Server.

Let’s say we modify the max degree of parallelism value to 6 for our workload. We do it using the following SQL query.

1 2 3 4 5 6 7 8

EXECsp_configure’show advanced options’,1; GO RECONFIGUREWITHOVERRIDE; GO EXECsp_configure’max degree of parallelism’,6; GO RECONFIGUREWITHOVERRIDE; GO

Once we have modified the max degree of parallelism value, SQL Server invalidates all stored procedure plan cache. It behaves similar to a DBCC FREEPROCCACHE command.

Alternatively, we can use the following methods to resolve performance issues and clear the plan cache.

• In SQL Server 2016 onwards, we can use database scoped configuration option to clear the procedural cache in a specific database. Execute the following query under database context to clear the database-specific procedural cache

  1	ALTERSCOPEDCONFIGURATIONCLEARPROCEDURE_CACHE

Установка значения для параметра RESULT_CACHE_MODE

То, будет база данных кэшировать результат запроса или нет, зависит от значения параметра инициализации RESULT_CACHE_MODE, который может принимать два значения: MANUAL или FORCE. Ниже приведено краткое описание того, как эти два значения воздействует на связанное с кэшированием результатов поведение в базе данных.

• В случае установки для этого параметра значения FORCE база данных будет пытаться использовать кэш для всех результатов везде, где может. Этап помещения результатов в кэш, однако, в таком случае может пропускаться за счет включения в запрос подсказки NO_RESULT_CACHE.
• В случае установки для этого параметра значения MANUAL база данных будет помещать результаты запроса в кэш только при условии наличия в запросе подсказки RESULT_CACHE.

По умолчанию для параметра RESULT_CACHE_MODE принимается значение MANUAL, и изменять его динамически можно так, как показано ниже:

SQL> alter session set result_cache_mode=force scope=spfile;

Использование подсказок RESULT_CACHE и NO_RESULT_CACHE

Использование подсказки RESULT_CACHE в виде части запроса приводит к добавлению в план выполнения этого запроса операции ResultCache. Эта операция ResultCache будет просматривать кэш результатов для выяснения того, не хранится ли в нем результат для данного запроса. Если таковой в кэше имеется, она будет извлекать его, а если нет, тогда будет выполнять запрос и сохранять его результаты в кэше результатов. Подсказка no_result_cache работает противоположным образом. При добавлении ее в запрос она будет заставлять операцию ResultCache обходить кэш результатов и выполнять запрос заново.

Ниже приведен пример включения в SQL-запрос подсказки RESULT_CACHE:

SQL> select /*+ result_cache +*/
2 department_id, avg(salary)
3 from hr.employees
4* group by department_id;
SQL>

В этом примере подсказка RESULT_CACHE в первой строке запроса указывает, что должна использоваться операция ResultCache, проверяющая кэш результатов на предмет наличия в нем готовых результатов данного запроса и, если таковых там нет, выполняющая запрос и сохраняющая его результаты в кэше. Вывод EXPLAIN PLAN для этого запроса показывает, что для него используется кэш результатов:

SQL> EXPLAIN PLAN FOR select /*+ result_cache +*/
2 department_id,avg(salary)
3 from hr.employees
4* group by department_id
SQL> /
Explained.
SQL>
SQL> SELECT plan_table_output FROM table(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
----------------------------------------------------------------
Plan hash value: 1192169904
----------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost
(%CPU)| Time |
----------------------------------------------------------------
PLAN_TABLE_OUTPUT
----------------------------------------------------------------
| 0 | SELECT STATEMENT || 11 | 77 | 4
(25) | 00:00:01 |
| 1 | RESULT CACHE | 8nk7a7rfhymzy0s0b89ksn9bfz | ||
| 2 | HASH GROUP BY | | 11 | 77 | 4
(25) | 00:00:01 |
| 3 | TABLE ACCESS FULL| EMPLOYEES | 107 | 749 | 3
(0) | 00:00:01 |
PLAN_TABLE_OUTPUT
----------------------------------------------------------------
----------------------------------------------------------------
Result Cache Information (identified by operation id):
------------------------------------------------------
1 - column-count=2; dependencies=(HR.EMPLOYEES);
name="select /*+ result_cache +*/
department_id,avg(salary)
from hr.employees
group by department_id"
15 rows selected.
SQL>

Совет

Подсказки RESULT_CACHE и NO_RESULT_CACHE всегда превосходят по важности значение, установленное для параметра инициализации RESULT_CACHE_MODE

Вывод EXPLAIN PLAN выявляет использование кэша результатов для запроса в данном примере. Раз для использования кэша результатов пришлось применять подсказку RESULT_CACHE, значит, для параметра RESULT_CACHE_MODE установлено значение MANUAL. В случае установки для него значения FORCE добавлять подсказку RESULT_CACHE в запросы не понадобится. База данных будет просто кэшировать результаты всех повторяющихся SQL- операторов, если только в них не будет присутствовать подсказка NO_RESULT_CACHE.