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

  • Remove From My Forums
  • Question

  • Any assistance with this issue would be greatly appreciated. TIA!

    Server:                 DBServer-1

    Task Detail:        Reorganize index on Local server connection

    Databases:         dbA,dbB,dbC,dbD,dbE,master,model,msdb

    Object: Tables and views

    Compact large objects

    Error No:             -1073548784               

    Error Message:  Executing the query «ALTER INDEX [PK_Residential] ON [dbo].[Residential] REORGANIZE WITH ( LOB_COMPACTION = ON )» failed with the following error: «A severe error occurred on the current command.  The results, if any, should be discarded.». Possible failure reasons: Problems with the query, «ResultSet» property not set correctly, parameters not set correctly, or connection not established correctly.

    Windows Server 2003 Standard Edition w/ SP2

    SQL Server 2005 Standard Edition (9.0.3054)

Answers

    • Proposed as answer by

      Wednesday, April 24, 2013 12:50 PM

    • Marked as answer by
      Ed Price — MSFTMicrosoft employee
      Tuesday, April 30, 2013 3:51 AM
  • Remove From My Forums

 none

План обслуживания — ошибка — страничная блокировка отключена?

  • Вопрос

  • Добрый день!

    Произвожу обслуживание баз данных с помощью стандартного плана обслуживания предлагаемого мастером в MS SQL Server 2008R2.

    На одну из баз ругается на шаге Реорганизация индекса, выдает вот такую ошибку:

    Индекс «IX_Time» (секция 1) для таблицы «KeyData» невозможно реорганизовать, так как страничная блокировка отключена.

    Что делать? Как с этим бороться или может не надо бороться?

Ответы

  • ALTER INDEX < Index name > ON  < Table Name >
    SET (
      ALLOW_PAGE_LOCKS = ON
    )
    GO 
    

    http://www.t-sql.ru

    • Помечено в качестве ответа

      11 апреля 2011 г. 16:02

Не работает реорганизация индексов, если есть отключенные.

Модератор: Дмитрий Юхтимовский

Не работает реорганизация индексов, если есть отключенные.

Добрый день!
С помощью клиента IndexesClient82.dt создаю предлагаемые новые индексы и отключаю редко используемые.
Но при наличии отключенных индексов перестает работать реорганизация индексов:
[img]

http://screencast.com/t/dc1SUbgOHH

[/img]
Генерируется ошибка:

Сбой выполнения запроса «ALTER INDEX [_Accum19257_ByDims19274_RTRN] ON [dbo…» со следующей ошибкой: «Невозможно выполнить указанную операцию с отключенным индексом «_Accum19257_ByDims19274_RTRN» для таблица «dbo._AccumRg19257″.». Возможные причины сбоя: проблемы с этим запросом, свойство «ResultSet» установлено неправильно, параметры установлены неправильно или соединение было установлено неправильно.

Можно ли сделать чтобы задача «Реорганизация индекса» пропускала отключенные индексы?

simol
 
Сообщений: 101
Зарегистрирован: 18 фев 2013, 11:17

Re: Не работает реорганизация индексов, если есть отключенны

Сообщение Гилёв Вячеслав » 10 дек 2013, 22:39

simol писал(а):Добрый день!
С помощью клиента IndexesClient82.dt создаю предлагаемые новые индексы и отключаю редко используемые.
Но при наличии отключенных индексов перестает работать реорганизация индексов:
[img]

http://screencast.com/t/dc1SUbgOHH

[/img]
Генерируется ошибка:

Сбой выполнения запроса «ALTER INDEX [_Accum19257_ByDims19274_RTRN] ON [dbo…» со следующей ошибкой: «Невозможно выполнить указанную операцию с отключенным индексом «_Accum19257_ByDims19274_RTRN» для таблица «dbo._AccumRg19257″.». Возможные причины сбоя: проблемы с этим запросом, свойство «ResultSet» установлено неправильно, параметры установлены неправильно или соединение было установлено неправильно.

Можно ли сделать чтобы задача «Реорганизация индекса» пропускала отключенные индексы?

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

Гилёв Вячеслав
 
Сообщений: 2719
Зарегистрирован: 11 фев 2013, 15:40
Откуда: Россия, Москва

Re: Не работает реорганизация индексов, если есть отключенны

Сообщение simol » 10 дек 2013, 22:44

Гилёв Вячеслав писал(а):Для этого надо в регламенте указать список тех таблиц, которые надо обслуживать , а не всю базу целиком.

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

simol
 
Сообщений: 101
Зарегистрирован: 18 фев 2013, 11:17

Re: Не работает реорганизация индексов, если есть отключенны

Сообщение Гилёв Вячеслав » 10 дек 2013, 22:49

simol писал(а):

Гилёв Вячеслав писал(а):Для этого надо в регламенте указать список тех таблиц, которые надо обслуживать , а не всю базу целиком.

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

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

Гилёв Вячеслав
 
Сообщений: 2719
Зарегистрирован: 11 фев 2013, 15:40
Откуда: Россия, Москва




Re: Не работает реорганизация индексов, если есть отключенны

Сообщение simol » 23 янв 2014, 11:25

Гилёв Вячеслав писал(а):расскажите что получилось

Допроведем с вами аудит и продолжу по этому вопросу.

simol
 
Сообщений: 101
Зарегистрирован: 18 фев 2013, 11:17

Re: Не работает реорганизация индексов, если есть отключенны

Сообщение simol » 03 фев 2014, 17:18

Аудит завершился, спасибо!
Теперь продолжаю исследование.
Сначала хотел сделать алгоритм:

Исполняйте инструкцию ALTER INDEX … REORGANIZE, чтобы выполнить дефрагментацию индекса, при соблюдении следующих пороговых значений: значение avg_page_space_used_in_percent в диапазоне от 60 до 75 или значение avg_fragmentation_in_percent в диапазоне от 10 до 15. Исполняйте инструкцию ALTER INDEX … REBUILD, чтобы выполнить дефрагментацию индекса, при соблюдении следующих пороговых значений: значение avg_page_space_used_in_percent меньше 60 или значение avg_fragmentation_in_percent больше 15.

Столкнулся с тем, что есть таблица, записи в которой на столько большие, что при дефрагментации 0 получается avg_page_space_used_in_percen = 68% и эта таблица каждую итерацию требует REORGANIZE.
Потом решил сделать основываясь на алгоритме как для кластеризованных так и для некластеризованных:

> 5 % и <= 30 % REORGANIZE. > 30% ALTER INDEX REBUILD WITH (ONLINE = ON)

Затем заинтересовался вопросом обновления статистики и хотел добавить обновление статики по индексам, по которым перестроил индекс. Затем встал вопрос с очисткой процедурного кеша.
В результате лазя по просторам интернета нашел такой ресурс http://ola.hallengren.com/
Осознаваясь на который настроил регламенты:
1) каждый час по правилу >5%<=30% REORGANIZE, >30% REBUILD
2) каждые 6 часов обновление статистики, которая изменялась и очистка процедурного кеша
3) каждое воскресенье тестирование баз

simol
 
Сообщений: 101
Зарегистрирован: 18 фев 2013, 11:17


Вернуться в MS SQL Server для целей 1С:Предприятие

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

  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;
  • настройка резервного копирования и возможность восстановить базу на любой момент времени.

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

SQL Server 2017 on Windows SQL Server 2019 on Windows Еще…Меньше

Проблемы

Предположим, что в таблице за SQL Server 2017 или 2019 г. имеется индекс г. При запуске сканов с версиями (например, «Изоляция моментального снимка» (SI) или Чтение зафиксированной изоляции моментального снимка (RCSI)), а если в той же таблице также запущен процесс слияния с «многояровой многоязак» или «alter index reorganize», вы получаете неправильные результаты.

Статус

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

Решение

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

  • Накопительный итог обновления 12 SQL Server 2019 г.

  • Накопительный итог обновления 25 SQL Server 2017 г.

Ссылки

Узнайте о терминологии,используемой корпорацией Майкрософт для описания обновлений программного обеспечения.

Нужна дополнительная помощь?

Нужны дополнительные параметры?

Изучите преимущества подписки, просмотрите учебные курсы, узнайте, как защитить свое устройство и т. д.

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

  • Рентгеноанатомический атлас скелета норма варианты ошибки интерпретации
  • Рентген xgenus коды ошибок
  • Рено эспейс 4 ошибка ручника
  • Рено эспейс 3 ошибки на панели приборов
  • Рено флюенс проверьте систему впрыска ошибка