Реорганизация индекса sql 1с ошибка

Hi All,
  • Remove From My Forums

  • Question

  • Hi All,

    Index reorganize job is failing with below error stating — reorganize cannot be performed on indexes where page locks are disabled.

    What is the purpose of page locks?

    Can index reorganize be performed with page locks disabled?

    Do I need to seek permission from app team to enable the page locks?

    Thank You.

Answers

  • Hello Friend,

    This is a simple problem to solve.
    Following is a link to the problem and solution and explanation of the issue.

    Resolve
    SQL Server Database Index Reorganization Page Level Locking Problem

    complementing the friend’s message, after seeing the indices you can change the setting if you think it is best
    Here’s the example script to make the change: 

    USE MSSQLTipsDemo 
GO
ALTER INDEX [PK_Product] ON [Production].[Product] SET ( ALLOW_PAGE_LOCKS = ON )
ALTER INDEX [PK_Product] ON [Production].[Product] SET ( ALLOW_ROW_LOCKS = ON )

    Jefferson Clyton Pereira da Silva — [MCSA | MCP | MCTS | MTA | Analista de Banco de Dados — Sql Server e Oracle ]

    • Marked as answer by

      Tuesday, September 3, 2019 12:29 AM

  • Index reorganize job is failing with below error stating — reorganize cannot be performed on indexes where page locks are disabled.

    What is the purpose of page locks?

    A page lock locks an entire database page. For a normal operation, that is INSERT, SELECT etc, SQL Server can opt to start with page locks rather than row locks, if it estimates that using row locks will result in too many locks.

    Can index reorganize be performed with page locks disabled?

    No. What index reorganize does is to shuffle pages around to reduce fragmentation. That is, in difference to INSERT, SELECT etc, REORGNANIZE operates on the pages as units. The advantage of REORGANIZE over REBUILD is that since it works with small transaction
    the transaction log does not explode equally easily and there is no need for a lock on table level. (Although that can be avoided in Enterprise Edition with online rebuilds.)

    Do I need to seek permission from app team to enable the page locks?

    Whom you need to ask for permission is nothing we can answer, but something you will need to discuss with your boss if you don’t know how to talk to directly.

    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    • Marked as answer by
      SSG92
      Tuesday, September 3, 2019 12:29 AM

  • <<Can index reorganize be performed with page locks disabled?

    No

    By default, and in most cases, page level locking should be enabled for indexes.

    see

    SELECT ‘ALTER INDEX ‘ + I.Name + ‘ ON ‘ +  T.Name + ‘ SET (ALLOW_PAGE_LOCKS = ON)’ As Command
    FROM sys.indexes I
    LEFT OUTER JOIN sys.tables T ON I.object_id = t.object_id
    WHERE I.allow_page_locks = 0 AND T.Name IS NOT NULL

    This query creates the necessary ALTER INDEX statements to correct the indexes we identified above. Run the generated commands to correct all of the indexes found above.

    Best Regards,Uri Dimant SQL Server MVP,
    http://sqlblog.com/blogs/uri_dimant/

    MS SQL optimization: MS SQL Development and Optimization
    MS SQL Consulting:
    Large scale of database and data cleansing
    Remote DBA Services:
    Improves MS SQL Database Performance
    SQL Server Integration Services:
    Business Intelligence

    • Marked as answer by
      SSG92
      Tuesday, September 3, 2019 12:29 AM

Источник
  • Remove From My Forums

  • Question

  • Hi All,

    Index reorganize job is failing with below error stating — reorganize cannot be performed on indexes where page locks are disabled.

    What is the purpose of page locks?

    Can index reorganize be performed with page locks disabled?

    Do I need to seek permission from app team to enable the page locks?

    Thank You.

Answers

  • Hello Friend,

    This is a simple problem to solve.
    Following is a link to the problem and solution and explanation of the issue.

    Resolve
    SQL Server Database Index Reorganization Page Level Locking Problem

    complementing the friend’s message, after seeing the indices you can change the setting if you think it is best
    Here’s the example script to make the change: 

    USE MSSQLTipsDemo 
GO
ALTER INDEX [PK_Product] ON [Production].[Product] SET ( ALLOW_PAGE_LOCKS = ON )
ALTER INDEX [PK_Product] ON [Production].[Product] SET ( ALLOW_ROW_LOCKS = ON )

    Jefferson Clyton Pereira da Silva — [MCSA | MCP | MCTS | MTA | Analista de Banco de Dados — Sql Server e Oracle ]

    • Marked as answer by

      Tuesday, September 3, 2019 12:29 AM

  • Index reorganize job is failing with below error stating — reorganize cannot be performed on indexes where page locks are disabled.

    What is the purpose of page locks?

    A page lock locks an entire database page. For a normal operation, that is INSERT, SELECT etc, SQL Server can opt to start with page locks rather than row locks, if it estimates that using row locks will result in too many locks.

    Can index reorganize be performed with page locks disabled?

    No. What index reorganize does is to shuffle pages around to reduce fragmentation. That is, in difference to INSERT, SELECT etc, REORGNANIZE operates on the pages as units. The advantage of REORGANIZE over REBUILD is that since it works with small transaction
    the transaction log does not explode equally easily and there is no need for a lock on table level. (Although that can be avoided in Enterprise Edition with online rebuilds.)

    Do I need to seek permission from app team to enable the page locks?

    Whom you need to ask for permission is nothing we can answer, but something you will need to discuss with your boss if you don’t know how to talk to directly.

    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

    • Marked as answer by
      SSG92
      Tuesday, September 3, 2019 12:29 AM

  • <<Can index reorganize be performed with page locks disabled?

    No

    By default, and in most cases, page level locking should be enabled for indexes.

    see

    SELECT ‘ALTER INDEX ‘ + I.Name + ‘ ON ‘ +  T.Name + ‘ SET (ALLOW_PAGE_LOCKS = ON)’ As Command
    FROM sys.indexes I
    LEFT OUTER JOIN sys.tables T ON I.object_id = t.object_id
    WHERE I.allow_page_locks = 0 AND T.Name IS NOT NULL

    This query creates the necessary ALTER INDEX statements to correct the indexes we identified above. Run the generated commands to correct all of the indexes found above.

    Best Regards,Uri Dimant SQL Server MVP,
    http://sqlblog.com/blogs/uri_dimant/

    MS SQL optimization: MS SQL Development and Optimization
    MS SQL Consulting:
    Large scale of database and data cleansing
    Remote DBA Services:
    Improves MS SQL Database Performance
    SQL Server Integration Services:
    Business Intelligence

    • Marked as answer by
      SSG92
      Tuesday, September 3, 2019 12:29 AM

Источник
  1. Главная
  2. Полезная информация
  3. Как правильно настроить MS SQL Server для «1С»: планы обслуживания

12.03.2019

Часто неопытные системные администраторы подразумевают перевод базы «1С» в клиент-серверный режим работы как панацею, избавляющую от всех проблем и ускоряющую «1С» во много раз. Однако, без правильной настройки, мониторинга и регулярного обслуживания базы «1С» в клиент-серверном режиме начинают работать еще «медленнее», чем в файловом. В рамках этой статьи рассмотрим оптимальную настройку своевременных регламентных операций на уровне самой СУБД MS MSQL. Крайне важно выполнять регламентное обслуживание в системах под значительной нагрузкой, где работают больше 10-ти пользователей, ведь в подобных системах обычных действий (выполняемых СУБД MS SQL) становится недостаточно для эффективной работы.

Планы обслуживания/Maintenance Plan в MS SQL Server

Итак, «Сервер 1С:Предприятие» и SQL Server установлены и настроены, базы перенесены, пользователи работают. Ускорение «1С» и комфорт в работе получен. Но, с течением времени документы начинают открываться медленнее, подбор номенклатуры «зависает», а отчеты формируются «целую вечность». Чтобы этого избежать, следует настроить и автоматизировать регламентные процедуры по обслуживанию базы в SQL Server.

Вообще, планы обслуживания нужно подстраивать под конкретное оборудование и базы данных. Оставим это на усмотрение профессионалов администрирования баз данных. В общем случае, для базы данных не более 200 Гб в MS SQL Server рекомендуется выполнять следующие регламентные операции:

  • Проверка целостности базы данных
  • Реорганизация индекса/Восстановить индекс
  • Обновление статистики

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

Проверка целостности базы данных/DBCC CHECKDB

MS SQL Проверка целостности базы данных

Периодичность: 1 раз в неделю.

Время запуска: в технологическом окне — во время минимальной нагрузки.

Настройка расписания проверки целостности базы данных

Как настроить: Microsoft SQL Server Management Studio — «Управление» — «Планы обслуживания» — правой кнопкой мыши «Мастер планов обслуживания».

Имя — можно заполнить на свое усмотрение, например «Проверка целостности базы данных» или «CheckDB». Для настройки расписания запуска проверки — кнопка «Изменить». Выполняется — еженедельно; повторять — каждое воскресенье. Однократное задание, например, в 01:00.

При выборе задач по обслуживанию устанавливаем флаг «Проверка целостности базы данных».

Проверка целостности базы данных/DBCC CHECKDB

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

Если настройка прошла без ошибок, выйдет сообщение об успешной проверке.

Успешная проверка плана обслуживания SQL

Реорганизация индекса/Восстановить индекс

Что такое индексы? Индексы — это структурированные данные, которые ускоряют процесс запроса, предоставляя быстрый доступ к строкам данных в таблице, аналогично предметному указателю или оглавлению в книгах. Индексы составляют больше половины объема большинства баз «1С». Для каждого индекса обязательно хранится его статистика.

Подробнее об индексах в MS SQL Server

MS SQL Server самостоятельно создает и изменяет индексы при работе с базой. С течением времени данные в индексе становятся фрагментированными, т.е. разбросанными по базе данных. Существенно фрагментированные индексы могут серьезно снижать производительность запросов и служить причиной замедления работы базы. Если фрагментация составляет от 5 до 30%, то рекомендуется ее устранить с помощью реорганизации, при фрагментации свыше 30% необходимо полное перестроение индексов.

Подробнее о реорганизации и перестроении индексов

В простейшем случае получить информацию по фрагментации индексов можно с помощью кода:

DECLARE @db_id SMALLINT;

SET @db_id = DB_ID(N'MyBaseSQL');

IF @db_id IS NULL
BEGIN;
    PRINT N'Неправильное имя базы';
END;

ELSE
BEGIN;
	SELECT
		object_id AS [ID объекта],
		index_id AS [ID индекса],
		index_type_desc AS [Тип индекса],
		avg_fragmentation_in_percent AS [Фрагментация в %]
		
	FROM sys.dm_db_index_physical_stats(@db_id, NULL, NULL, NULL , 'LIMITED')
	 
	ORDER BY [avg_fragmentation_in_percent] DESC;
END;
GO

Для выполнения кода нажимаем «Создать запрос» — вставляем код. В строке «SET @db_id = DB_ID(N’MyBaseSQL’);» вместо «MyBaseSQL» нужно указать имя своей базы данных. Кнопка «Выполнить».

Фрагментация индексов базы SQL

Почему регулярно стоит использовать именно реорганизацию индекса?

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

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

Важно! При использовании модели восстановления «Полная» (правой кнопкой мыши по базе данных — «Свойства» — «Параметры»), чтобы файл журнала транзакций не вырастал до неприличных размеров, необходимо выполнять «Резервное копирование базы данных (полное)» после каждой процедуры реорганизации или перестроения индекса.

Вывод: Если фрагментация более 30%, нужно выполнить разовое полное перестроение индексов (восстановить индекс). После перестроения планово использовать только реорганизацию.

Периодичность: 1 раз в сутки.

Время запуска: в технологическом окне — во время минимальной нагрузки.

Как настроить: Microsoft SQL Server Management Studio — «Управление» — «Планы обслуживания» — правой кнопкой мыши «Мастер планов обслуживания».

Реорганизация индекса

Имя — можно заполнить на свое усмотрение, например «Реорганизация индекса» или «Index Reorganize». Для настройки расписания запуска проверки — кнопка «Изменить». Выполняется — ежедневно; повторять — каждый 1 день. Однократное задание, например, в 02:00.

При выборе задач по обслуживанию устанавливаем флаг «Реорганизация индекса».

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

Если настройка прошла без ошибок, выйдет сообщение об спешной проверке.

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

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

Подробнее о статистике в MS SQL Server

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

Частоту обновления статистики нужно определять экспериментальным путем в зависимости от нагрузки, но общая рекомендация для баз «1С» — один раз в сутки.

Периодичность: 1 раз в сутки.

Время запуска: в технологическом окне — во время минимальной нагрузки.

Как настроить: Microsoft SQL Server Management Studio — «Управление» — «Планы обслуживания» — правой кнопкой мыши «Мастер планов обслуживания».

Имя — можно заполнить на свое усмотрение, например «Обновление статистик» или «Update Statistics». Для настройки расписания запуска проверки — кнопка «Изменить». Выполняется — ежедневно; повторять — каждый 1 день. Однократное задание, например, в 03:00.

При выборе задач по обслуживанию устанавливаем флаг «Обновление статистик».

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

Если настройка прошла без ошибок, выйдет сообщение об спешной проверке.

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

Ежедневные планы обслуживания баз SQL

Фирма «1С» в нескольких источниках (Регламентные операции на уровне СУБД для MS SQL Server) советует после обновления статистики дополнительно проводить очистку процедурного кэша. Это имело смысл для старых версий SQL Server, например версии 2005. С версии 2008 при включенной настройке «асинхронное обновление статистики» очищать процедурный кэш необязательно. При асинхронном обновлении статистики запросы компилируются с существующей статистикой, даже если она устарела. Если на момент компиляции запроса статистика оказывается устаревшей, оптимизатор запросов может выбрать неоптимальный план запроса. Запросы, которые компилируются после выполнения асинхронного обновления, будут усовершенствованы благодаря использованию обновленной статистики.

Контроль выполнения планов обслуживания

Просматривать результаты выполнения обслуживания можно нажав правой кнопкой мыши на «Управление» — «Планы обслуживания» — «Просмотр журнала».

Журнал выполнения планов обслуживания

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

Почему не стоит использовать сжатие базы данных (шринк/shrink)?

Пожалуй, единственным случаем, когда есть смысл использовать сжатие базы данных — масштабные изменения в базе данных. Например: после восстановления из DT-дампа, свертки или реструктуризации информационной базы.

В остальных случаях:

  • сжатие файла базы данных (MDF) приводит к увеличению индексов;
  • сжатие файла журнала транзакций (LDF) не нужно при правильной настройке резервного копирования и обслуживании индексов. При использовании полной модели восстановления (Full Recovery Model) базы SQL важно делать регулярные резервные копии файла журнала транзакций и только перестроение индексов. Тогда, файл LDF будет соизмерим с размером файла базы данных и не будет бесконтрольно расти.

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

Что дальше?

В будущих статьях мы рассмотрим несколько тем:

  • тонкая настройка SQL Server;
  • поиск узких мест в производительности связки сервер «1С:Предприятие»/MS SQL Server;
  • настройка резервного копирования и возможность восстановить базу на любой момент времени.

Следите за обновлениями.

Источник

Понравилась статья? Поделить с друзьями:
  • Рентген аполло ошибка 158
  • Рено флюенс самодиагностика ошибок
  • Реф элинж ошибка ade
  • Рено меган ошибка 0010
  • Реф термокинг сл200е коды ошибок