Проблема: После обновления на 1С:Бухгалтерию предприятия 3-й версии, при нажатии на закладку командного интерфейса 1С:предприятие, выскакивает ошибка:

Aboutsecurity_1cv8c.exe или Aboutsecurity_1cv8.exe

«Содержимое указанного ниже веб-узла в этом приложении блокировано конфигурацией усиленной безопасности Internet Explorer».

Ошибка исчезает после многократного нажатия на «Закрыть», что несколько мешает работать, мягко говоря. Похожая ошибка бывает и в конфигураторе, при обновлении конфигурации или сравнении/объединении конфигураций. Чаще всего, мне попадалась эта проблема в серверных ОС, в частности Windows 2008 r2.

Решение: нужно добавить исключение в настройках безопасности Internet Explorer (далее & IE).

Это делается просто, если у вас один или несколько компьютеров & просто открываете IE/Свойства обозревателя/Безопасность/Надёжные узлы/Сайты, добавляете Aboutsecurity_1cv8c.exe и Aboutsecurity_1cv8.exe, нажимаете Ок, и наслаждаетесь результатом.

Но вот если у вас терминал-сервер и 40/60 пользователей, или еще хуже & пользователей 150 и они ходят в SQL версию 1С с локальных рабочих станций, то бегать по всем корпусам и добавлять эту настройку весьма накладно по времени, да и отвлекать пользователей лишний раз от работы не порядочно.

В этом случае, нужно пользоваться групповыми политиками домена (который у вас должен быть настроен, если вы не офисный спортсмен-бегун).

Вариант №1. Неудавшийся.

Первое решение & прописать настройки через Group Polices (Административные шаблоны/Компоненты Windows/Internet explorer/Вкладка «Безопасность»/Список назначений зоны для веб-сайтов) & не увенчалось успехом. Настройки пользователей, как и обещалось в статьях по данному методу, перестали работать, а вот зоны, описанные в этих настройках, работать не начали. При этом, я пробовал добавлять настройки и в локальные политики, и в доменные и в политики контроллера домена. Скорее всего из-за этих экспериментов с разными зонами действия групповых политик и появилась проблема.

И так, после этих манипуляций, в настройках безопасности IE появилась надпись «Некоторыми параметрами управляет системный администратор» и добавлять/удалять сайты узлов безопасности стало невозможно. От этой надписи, почему-то, оказалось не так просто избавиться. Удаление проделанных настроек GPO не разблокировали вкладку «Безопасность», а манипуляции с реестром привели к появлению ошибок «В параметрах зоны есть ошибка. Не удалось добавить сайт.» (IE 10) или «При установке параметров безопасности зоны произошла ошибка. Добавить узел не удается.» (IE 9) & все дальнейшие действия сходили на нет.

Исправить косяк удалось следующим путём:

Обновил Internet Explorer до версии 10 (был 9-й).

Предварительно экспортировав разделы реестра в файл, на случай восстановления, удалил из следующие ключи:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\InternetSettings

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings]

Восстановил настройки Internet Explorer (Свойства обозревателя/Дополнительно/Сброс).

Проверить, что проблема не вернётся можно введя команду gpupdate /force в командной строке. После обновления политики запустите IE и проверьте, что настройки остались на месте. Если настройки опять слетели и добавление сайтов в узлы безопасности стало опять невозможно, то, скорее всего вы забыли отключить параметр «Список назначений зоны для веб-сайтов» в какой-то из зон групповой политики.

Чтобы определить в какой из зон групповых политик засела настройка (в локальных, доменных или контроллера домена), удобно пользоваться мастером отчётов «Результаты групповой политики», который находится в консоли «Диспетчер сервера», в разделе «Компоненты/Управление групповой политикой» (в Windows 2008 r2, по крайне мере он там).

Так что, здесь стоит быть осторожным, чтобы не создать себе дополнительной работы.

Вариант №2. Через GPO и реестр.

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

Что делать:

Удаляем узлы Aboutsecurity_1cv8 из настроек IE, если вы их туда уже добавили вручную & это нужно для чистоты эксперимента. Проверьте, что в 1С ошибка сохранилась.

Создаём файл 1csec.reg, с содержимым:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\security_1cv8c.exe]

«about»=dword:00000002

Небольшая ремарка: подраздел EscDomains используется в режиме расширенной настройки безопасности, если же этот режим отключен по какой-то причине, то нужно использовать раздел Domains вместо EscDomains (подробнее о записях реестра IE см. в базе знаний Microsoft).

И пробуем добавить его в реестр & если срабатывает, и в тонком клиенте 1С ошибка Aboutsecurity_1cv8c.exe исчезает, делаем дальше.

Снова открываем Default Domain Policy в диспетчере управления сервером, далее Конфигурация пользователя/Настройка/Конфигурация Windows/Реестр.

Добавляем туда две записи, где поле «Путь раздела»:

в первой записи это «Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\security_1cv8c.exe» (для тонкого клиента 1С),

во второй записи «Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\security_1cv8.exe» (для толстого клиента).

В остальном запись содержит те же данные, что и на картинке.

После этого, как положено, перелогиниваемся и проверяем результат. В толстом и тонком клиенте 1С:предприятие, ошибка должна исчезнуть.

В моём случае, для надёжности избавления от проделанных в Варианте №2 настроек, были добавлены ещё три записи в реестр:

Обновить: HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings; параметр: ListBox_Support_ZoneMapKey; значение 0 (тип DWORD десятичный)

Удалить: HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

Удалить: HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey

Вариант №3. Интерфейсный.

Есть ещё вариант, который переключит работу программы в режим интерфейса «Такси» : Администрирование/Настройки программы/Интерфейс & здесь включаем «Интерфейс «Такси»" & в этом режиме данная ошибка не появляется, но пользователям может не понравиться работать с этим вариантом интерфейса, т. к. он предназначен для мобильных устройств и планшетов (например, для работы через Web).

Источник

Обратился ко мне клиент с задачей: Нужно запретить изменение всех видов платежных документов (ПП, РКО, ПКО) спустя 8 часов с момента проведения соответствующего документа

Для реализации этого я использовал Подписку на событие: ПередЗаписьюДокументаДатаЗапретаРедактирования

В конце процедуры обработчика добавил вызов своей процедуры

Вот ее код:

 Процедура ПроверкаВремениСозданияИИзмененияДокумента(Источник, Отказ)

	Если РольДоступна("ПолныеПрава") Тогда

		//Все можно		

	ИначеЕсли Источник.Проведен Тогда //Обрабатывае только Проведенные

		ТекДата=ТекущаяДата(); ЧасовРазрешено=24;

		Если ТипЗнч(Источник) = Тип("ДокументОбъект.РасходныйКассовыйОрдер") Тогда

			ЧасовРазрешено=8;

			Если НЕ (ТекДата-Источник.Дата)/60 < ЧасовРазрешено*60 Тогда Отказ=Истина; Конецесли;

		ИначеЕсли ТипЗнч(Источник) = Тип("ДокументОбъект.ПриходныйКассовыйОрдер") Тогда

			ЧасовРазрешено=8;

			Если НЕ (ТекДата-Источник.Дата)/60 < ЧасовРазрешено*60 Тогда Отказ=Истина; Конецесли;

		ИначеЕсли ТипЗнч(Источник) = Тип("ДокументОбъект.ПлатежноеПоручениеВходящее") Тогда

			ЧасовРазрешено=8;

			Если НЕ (ТекДата-Источник.Дата)/60 < ЧасовРазрешено*60 Тогда Отказ=Истина; Конецесли;

	     ИначеЕсли ТипЗнч(Источник) = Тип("ДокументОбъект.ПлатежноеПоручениеИсходящее") Тогда

			ЧасовРазрешено=8;

			Если НЕ (ТекДата-Источник.Дата)/60 < ЧасовРазрешено*60 Тогда Отказ=Истина; Конецесли;

		КонецЕсли;

	КонецЕсли;	

	#Если Клиент Тогда

		Если Отказ Тогда

			Сообщить("Прошло более "+Строка(ЧасовРазрешено)+" часов с момента создания документа! Изменение запрещено и документ не может быть записан...", СтатусСообщения.Важное);

		КонецЕсли;

	#КонецЕсли

КонецПроцедуры   

Пока документ не проведен, его можно менять сколько угодно, но после первого проведения и истечения указанного количества часов, документ заблокируется, и при проведении будет выведено сообщение:

При попытке удалить запись из регистра сведений - получаю ошибку: она заблокирована, ошибка блокировок и т.д.

Отключил всех пользователей, перезапустил сервер, пробую удалить - опять ошибка блокировки

Путем тестов было вяснено, что проблема не в коде, а происходит это на этапе обращения платформы к SQL серверу... после долгих поисков решений, в интернете была найдена статья, которая помогла в решении данной проблемы:

Кто что блокирует, MS SQL + 1C

В повседневной работе достаточно задействовать только первый блок "/*кто кого*/". Открываем MS SQL Server Management Studio, правой на корень - "new query" - вставляем код запроса (только верхнюю часть до "Кто что блокирует", остальное - для детального анализа), выполняем запрос (вверху есть кнопочка выполнения запроса).

Выполнив запрос, запоминаем "ID виновника", быстренько идем в консоль сервера 1С, заходим в ветку "Сеансы" нашей базы. Видим все соединения с 1С-сервером, ищем там колонку "Соединение с СУБД", чтобы увидеть соединения 1С-сервера с MSSQL-сервером. В колонке будет всего несколько заполненных значений, среди них и будет "ID виновника".

Что делать если его там нет, тут 3 варианта:

1. Вернитесь в MSSQL и сделайте запрос еще несколько раз подряд, если значения меняются или таблица вообще пуста - постоянной блокировки нет, у вас (уже) все в порядке.

2. Сеанс который блокирует MSSQL находится в другой базе т.е. блокировка не в той базе (можно попробовать задействовать ветку всех сеансов в консоли 1С-сервера) - вернитесь в MSSQL и внимательно посмотрите в колонку DB в ней находится название базы.

3. Бывает что ID процесса в 1С-консоли вообще отсутствует, такое тоже бывает если у вас есть какие-то внешние программы подключенные напрямую в базу 1С, если пускаете кого-то в MSSQL напрямую, то вариант не исключен.

Код SQL-запроса:

 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED





DECLARE @dbid AS smallint;

use [ВАШАБАЗА];

SET @dbid=DB_ID();





/*кто кого*/

SELECT DB_NAME(pr1.dbid) AS 'DB'

      ,pr1.spid AS 'ID жертвы'

      ,RTRIM(pr1.loginame) AS 'Login жертвы'

      ,pr2.spid AS 'ID виновника'

      ,RTRIM(pr2.loginame) AS 'Login виновника'

      ,pr1.program_name AS 'программа жертвы'

      ,pr2.program_name AS 'программа виновника'

      ,txt.[text] AS 'Запрос виновника'

FROM   MASTER.dbo.sysprocesses pr1(NOLOCK)

       JOIN MASTER.dbo.sysprocesses pr2(NOLOCK)

            ON  (pr2.spid = pr1.blocked)

       OUTER APPLY sys.[dm_exec_sql_text](pr2.[sql_handle]) AS txt

WHERE  pr1.blocked <> 0





/* Кто что блокирует */

SELECT s.[nt_username]

      ,request_session_id

      ,tran_locks.[request_status]

      ,rd.[Description] + ' (' + tran_locks.resource_type + ' ' + tran_locks.request_mode + ')' [Object]

      ,txt_blocked.[text]

      ,COUNT(*) [COUNT]

FROM   sys.dm_tran_locks AS tran_locks WITH (NOLOCK)

       JOIN sys.sysprocesses AS s WITH (NOLOCK)

            ON  tran_locks.request_session_id = s.[spid]

       JOIN (

                SELECT 'KEY' AS sResource_type

                      ,p.[hobt_id] AS [id]

                      ,QUOTENAME(o.name) + '.' + QUOTENAME(i.name) AS [Description]

                FROM   sys.partitions p

                       JOIN sys.objects o

                            ON  p.object_id = o.object_id

                       JOIN sys.indexes i

                            ON  p.object_id = i.object_id

                            AND p.index_id = i.index_id

                UNION ALL

                SELECT 'RID' AS sResource_type

                      ,p.[hobt_id] AS [id]

                      ,QUOTENAME(o.name) + '.' + QUOTENAME(i.name) AS [Description]

                FROM   sys.partitions p

                       JOIN sys.objects o

                            ON  p.object_id = o.object_id

                       JOIN sys.indexes i

                            ON  p.object_id = i.object_id

                            AND p.index_id = i.index_id

                UNION ALL

                SELECT 'PAGE'

                      ,p.[hobt_id]

                      ,QUOTENAME(o.name) + '.' + QUOTENAME(i.name)

                FROM   sys.partitions p

                       JOIN sys.objects o

                            ON  p.object_id = o.object_id

                       JOIN sys.indexes i

                            ON  p.object_id = i.object_id

                            AND p.index_id = i.index_id

               

                UNION ALL

                SELECT 'OBJECT'

                      ,o.[object_id]

                      ,QUOTENAME(o.name)

                FROM   sys.objects o

            ) AS RD

            ON  RD.[sResource_type] = tran_locks.resource_type

            AND RD.[id] = tran_locks.resource_associated_entity_id

       OUTER APPLY sys.[dm_exec_sql_text](s.[sql_handle]) AS txt_Blocked

WHERE  (

           tran_locks.request_mode = 'X'

           AND tran_locks.resource_type = 'OBJECT'

       )

       OR  tran_locks.[request_status] = 'WAIT'

GROUP BY

       s.[nt_username]

      ,request_session_id

      ,tran_locks.[request_status]

      ,rd.[Description] + ' (' + tran_locks.resource_type + ' ' + tran_locks.request_mode + ')'

      ,txt_blocked.[text]

ORDER BY

       6 DESC

       





IF EXISTS ( SELECT  Name





            FROM    tempdb..sysobjects





            WHERE   name LIKE '#LOCK_01_01%' )

    DROP TABLE #LOCK_01_01









CREATE TABLE #LOCK_01_01





    (





      spid INT,





      dbid INT,





      ObjId INT,





      IndId SMALLINT,





      Type VARCHAR(20),





      Resource VARCHAR(50),





      Mode VARCHAR(20),





      Status VARCHAR(20)





    )





INSERT  INTO #LOCK_01_01





EXEC sp_lock









select OBJECT_NAME(ObjId) as [Имя объекта], Mode [Тип блокировки (код)],





CASE

     WHEN Mode='Sch-S' THEN 'Блокировка стабильности схемы. Гарантирует, что элемент схемы, такой как таблица или индекс, не будет удален до тех пор, пока сеанс связи удерживает блокировку стабильности схемы на данный элемент схемы;'





 WHEN Mode='Sch-М' THEN '= Блокировка изменения схемы. Должен поддерживаться любым сеансом связи, во время которого предполагается изменить схему данного ресурса. Гарантирует, что другие сеансы не имеют ссылок на обозначенный объект;'





 WHEN Mode='S' THEN 'S = Коллективная блокировка. Удерживающему сеансу предоставлен коллективный доступ к ресурсу;'





 WHEN Mode='U' THEN 'U = Блокировка обновления. Указывает блокировку обновления, полученную на ресурсы, которые со временем могут быть обновлены. Используется для предотвращения общей формы взаимоблокировки, которая возникает, когда множество сеансов блокируют ресурсы для потенциального обновления в последующее время;'





 WHEN Mode='X' THEN 'X = Монопольная блокировка. Удерживающему сеансу предоставлен исключительный доступ к ресурсу;'





 WHEN Mode='IS' THEN 'IS = Блокировка с намерением коллективного доступа. Указывает намерение поместить S блокировки на некоторые подчиненные ресурсы в иерархии блокировок;'





 WHEN Mode='IU' THEN 'IU = Блокировка с намерением обновления. Указывает намерение поместить U блокировки на некоторые подчиненные ресурсы в иерархии блокировок;'





 WHEN Mode='IX' THEN 'IX = Блокировка с намерением монопольного доступа. Указывает намерение поместить X блокировки на некоторые подчиненные ресурсы в иерархии блокировок;'





 WHEN Mode='SIU' THEN 'SIU = Коллективная блокировка с намерением обновления. Указывает коллективный доступ к ресурсу с намерением получения блокировок обновления на подчиненные ресурсы в иерархии блокировок;'





 WHEN Mode='SIX' THEN 'SIX = Коллективная блокировка с намерением монопольного доступа. Указывает коллективный доступ к ресурсу с намерением получения монопольных блокировок на подчиненные ресурсы в иерархии блокировок;'





 WHEN Mode='UIX' THEN 'UIX = Блокировка обновления с намерением монопольного доступа. Указывает блокировку обновления ресурса с намерением получения монопольных блокировок на подчиненные ресурсы в иерархии блокировок;'





 WHEN Mode='BU' THEN 'BU = Блокировка массового обновления. Используется для массовых операций;'

     --[ ELSE else_result_expression ]

END as [Тип блокировки]





,syspr.spid, syspr.dbid, syspr.open_tran, syspr.status, syspr.hostprocess, syspr.loginame, syspr.hostname





 From

#LOCK_01_01





inner join master.dbo.sysprocesses as syspr

on syspr.spid = #LOCK_01_01.spid and syspr.dbid = #LOCK_01_01.dbid





where

#LOCK_01_01.Type = 'TAB'

and

#LOCK_01_01.dbid = @dbid     





/* Чем занят сервер*/

SELECT s.[spid]

      ,s.[loginame]

      ,s.[open_tran]

      ,s.[blocked]

      ,s.[waittime]

      ,s.[cpu]

      ,s.[physical_io]

      ,s.[memusage]

       INTO #sysprocesses

FROM   sys.[sysprocesses] s





WAITFOR DELAY '00:00:01'





SELECT txt.[text]

      ,s.[spid]

      ,s.[loginame]

      ,s.[hostname]

      ,DB_NAME(s.[dbid]) [db_name]

      ,SUM(s.[waittime] -ts.[waittime]) [waittime]

      ,SUM(s.[cpu] -ts.[cpu]) [cpu]

      ,SUM(s.[physical_io] -ts.[physical_io]) [physical_io]

      ,s.[program_name]

FROM   sys.[sysprocesses] s

       JOIN #sysprocesses ts

            ON  s.[spid] = ts.[spid]

            AND s.[loginame] = ts.[loginame]

       OUTER APPLY sys.[dm_exec_sql_text](s.[sql_handle]) AS txt

WHERE  s.[cpu] -ts.[cpu]

       + s.[physical_io] -ts.[physical_io]

       > 500

       OR  (s.[waittime] -ts.[waittime]) > 3000

GROUP BY

       txt.[text]

      ,s.[spid]

      ,s.[loginame]

      ,s.[hostname]

      ,DB_NAME(s.[dbid])

      ,s.[program_name]

ORDER BY

       [physical_io] DESC

       

DROP TABLE #sysprocesses

   

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

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

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

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

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

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

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 Sublan) и назовите его «Обновление статистик». Добавьте в него задачу Update Statistics Task из панели задач:

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

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

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

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

Очистка процедурного КЭШа

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

Возможна ситуация, при которой MS SQL Server, ориентируясь на устаревшую статистическую информацию, построит неоптимальный план запроса. Этот план будет сохранен в процедурном КЭШе и использован при повторном вызове такого же запроса. Если Вы обновили статистику, но не очистили процедурный кэш, то SQL Server может выбрать старый (неоптимальный) план запроса из КЭШа вместо того, чтобы построить новый (более оптимальный) план.

Таким образом, рекомендуется всегда после обновления статистик очищать содержимое процедурного КЭШа.

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

 DBCC FREEPROCCACHE   

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

 Настройка очистки процедурного КЭШа

для (MS SQL 2005)

Поскольку процедурный КЭШ необходимо очищать при каждом обновлении статистики, данную операцию рекомендуется добавить в уже созданный субплан «Обновление статистик». Для этого следует открыть субплан и добавить в его схему задачу Execute T-SQL Statement Task. Затем следует соединить задачу Update Statistics Task стрелочкой с новой задачей.

В тексте созданной задачи Execute T-SQL Statement Task следует указать запрос «DBCC FREEPROCCACHE»:

Дефрагментация индексов

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

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

 sp_msforeachtable N'DBCC INDEXDEFRAG (<имя базы данных>, ''?'')'   

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

Возможно выполнение дефрагментации для одной или нескольких таблиц, а не для всех таблиц базы данных.

Настройка дефрагментации индексов (MS SQL 2005)

В ранее созданном плане обслуживания создайте новый субплан с именем «Дефрагментация индексов». Добавьте в него задачу Reorganize Index Task:

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

Настройте задачу, указав базу данных (или несколько баз данных) и выбрав необходимые таблицы. Если точно неизвестно, какие таблицы следует указать, то устанавливайте значение All.

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

 sp_msforeachtable N'DBCC DBREINDEX (''?'')'   

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

После выполнения реиндексации нет необходимости делать дефрагментацию индексов.

В ранее созданном плане обслуживания создайте новый субплан с именем «Дефрагментация индексов». Добавьте в него задачу Rebuild Index Task:

Задайте расписание выполнения для задачи реиндексирования таблиц. Рекомендуется выполнять задачу во время минимальной нагрузки на систему, не реже одного раза в неделю.

Настройте задачу, указав базу данных (или несколько баз данных) и выбрав необходимые таблицы. Если точно неизвестно, какие таблицы следует указать, то устанавливайте значение All.

Реиндексация таблиц базы данных

Необходимо осуществлять регулярный контроль выполнения регламентных процедур на уровне СУБД. Ниже приведен пример контроля выполнения плана обслуживания для MS SQL Server 2005.

Откройте созданный вами план обслуживания и выберите из контекстного меню пункт «View History»:

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

Успешно выполненные задачи и задачи, выполненные с ошибками, будут помечены соответствующими иконками. Для задач, выполненных с ошибками, доступна подробная информация об ошибке.

Источник: Регламентные операции MS SQL Server. Оптимизация работы