Архив рубрики: MS SQL Server

Почему для NVMe дисков под 1С не нужны RAID-массивы

Опубликовано автором

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

 

Нужен ли RAID-массив

Яркий пример неудачного массива

В каких случаях RAID-массивы на сервере 1С/СУБД можно использовать:

В каких случаях RAID-массивы на сервере 1С/СУБД не нужны

Почему RAID не является панацеей для отказоустойчивости

Нужен ли RAID-массив

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

Затем появились SSD, или твердотельные накопители (сокращённо они до сих пор называются “диски”, хотя там уже круглого ничего не осталось 🙂), скорость которых поначалу той же была хоть и выше, чем у механики, но всё равно “не радующей”, а надёжность вызывала сомнения (до сих пор большое количество айтишников уверены, что “SSD ненадёжные”), и эти SSD тоже по привычке запихивались в RAID-массивы. Однако “внезапно” стало проявляться, что далеко не всегда скорость итогового массива из SSD так же хорошо масштабируется, как если бы это был массив механических дисков, и тому есть ряд причин. Наиболее важные для нас минусы:

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

— если в состав массива включены SSD, не предназначенные для использования в составе массива, или не обладающие достаточной производительностью на запись (подробней о расчёте “нужной” производительности SSD можно почитать здесь: http://www.gilev.ru/dwpdssd/).

Для NVMe SSD даже если вы захотите собрать RAID-массив, то вам нужны такой контроллер и такая версия массива, чтобы они учитывали особенности архитектуры NVMe дисков, и позволяли не потерять, а как минимум сохранить скорость на уровне отдельно подключенного диска. Например, таковым является intel VROC (ссылка на https://www.intel.ru/content/www/ru/ru/support/products/122484/memory-and-storage/ssd-software/intel-virtual-raid-on-cpu-intel-vroc.html), опирающийся в свою очередь на intel VMD инструкции процессоров. 

Яркий пример неудачного массива

На снимке ниже: пример такого массива, собранного “неправильно”, формата RAID50, в котором 10 (десять) SSD. Причём в этом массиве “хорошо” себя показывает только чтение, и только крупными порциями (верхняя строчка Seq в колонке Read каждого из двух результатов). Запись даже крупными порциями (верхняя строчка Seq в колонке Write) показывает нам всего 142 мегабайта в секунду, а многопоточная запись пакетами по 4 килобайта (нижняя строчка 4K QD32 в колонке Write) даёт нам всего около 16 мегабайт в секунду. 

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

В каких случаях RAID-массивы на сервере 1С/СУБД можно использовать:

Для загрузочного носителя как зеркало.
 Но не потому что вы получаете реальную отказоустойчивость, а потому что цена такой “игрушки” невысока. Предполагаем, что это будут два недорогих SATA SSD класса read intensive или даже boot (подробней о классах SSD и их предназначении можно почитать здесь: http://www.gilev.ru/dwpdssd/), объединённых в RAID1 (“зеркало”). Если исходить из рисков выхода из строя, то вы скорее износите диск, чем он сломается. Некоторые современные SSD также подвержены перегреву, но рядом расположенные два ssd в рейд маловероятно сработают как надо, так как будут нагреваться примерно одинаково и перегреются почти одновременно. Кроме того надо помнить, что ssd “изнашиваются примерно одинаково”. Поэтому RAID в данном случае будет “для успокоения любителей делать рейд” без тяжелых финансовых последствий. Если вы будете подключать LUN для старта ОС с внешнего хранилища, то с высокой вероятностью там будет RAID “потому что так исторически сложилось”, т.е. нарезают массивы заранее, когда еще точно не знают характер использования и требования к отказоустойчивости 🙂

 

Для локальных бэкапов для увеличения емкости массива “страйп”.
Для бэкапов часто бывает необходимость места больше, чем есть на одиночном диске и поэтому увеличить общую емкость через рейд может быть полезно. Но хранить бэкапы в одном экземпляре только на зеркале прямо на том же сервере, что и исходная база этих бэкапов — мероприятие малоосмысленное, только зазря себя успокаивать. Если с сервером что-то случится — такой бэкап будет недоступен точно так же, как и исходная база. Гораздо полезней для повышения отказоустойчивости хранения локальных бэкапов сохранять сначала локально, затем тут же копировать (только копировать, не переносить!) полученные файлы бэкапа куда-то наружу сервера на сетевой ресурс. Подробней про бэкапы можно почитать например здесь: http://www.gilev.ru/31march/). 

 

Для базы данных 1С или данных кластера 1С “страйп” в отдельных случаях когда очередей к диску больше порога возможностей. Тут есть одно очень важное уточнение. Порог определяется не чьим-то мнением, а фактическими числовыми показателями времени отклика диска и числа очередей к диску, записанными за длительный период, который можно считать показательным для оценки. Т.е. решение принимается не потому, что вы заранее думаете “надо сделать рейд потому, что это так кажется правильным”, а потому что обладаете собранными с тестового стенда или даже лучше с продуктива данными, подтверждающими что с текущей нагрузкой диск не справляется именно из-за слишком большого числа одновременных операций чтения/записи. Если вы видите, что ваш диск выдерживает условно 128 одновременных активных транзакций (ну или пропорциональное им количество очередей) без потерь по времени отклика, а далее начинает выходить за рамки (ну пусть условно для примера порог будет 30 мс), то при росте числа активных транзакций ну скажем до 180, можно говорить об обоснованности наращивания дисковой подсистемы (например, добавления в RAID 0 второго диска). Ну и так далее. Также надо помнить, что в случае MS SQL Server и наличия квалифицированного админа — есть смысл не RAID 0 собирать под базу данных, а подключить те же два диска из примера отдельно, поместив на каждый по файлу базы данных (поровну распределив размер базы данных на каждый файл). В этом случае MS SQL Server на отдельных операциях может выдавать большую производительность, чем RAID 0.
Большинству админов лень что-либо замерять, и оборудование заказывается “на глаз”. Разумней в этом случае брать минимум дисков, и только по фактической нехватки мощности докупать диски. Если админ “отмазывается” тем, что у него бюджет на год и надо покупать сразу всё, тогда гораздо полезней всё равно сначала закупить один “нужный” диск, замерить практическим экспериментом “сколько он выдержит”, и только после этого составлять калькуляцию на год.

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

В каких случаях RAID-массивы на сервере 1С/СУБД не нужны

Временные данные 1С или СУБД, а также вторичные данные, потеря которых не остановит работу компании.

Сюда могут включаются например:
— папка кластера 1С, где лежат логи журналов регистрации и файлы полнотекстового поиска 1С (если он используется);
— папка temp профиля пользователя, под которым запущена служба сервера 1С;
— файлы и логи служебной базы tempdb сервера MS SQL (а если у вас PostgreSQL — то это например папки логов pg_clog/pg_xlog/pg_wal/pg_xact, в зависимости от версии постгреса).

 

Для всех вышеперечисленных целей наиболее рациональным мы видим использование независимых NVMe SSD (не SATA!), подключаемых либо в слоты PCIe, либо по U.2 (если серверная платформа или контроллер предполагают такую возможность). Производительность лидирующих по производительности одиночных NVMe SSD на потоковую запись исчисляется несколькими гигабайтами в секунду, а на случайную запись — многими сотнями мегабайт в секунду, или многими сотнями тысяч так любимых админами и вендорами IOPS. Объём таких одиночных накопителей может достигать например для разных моделей от 6 до 16 терабайт, при этом их же можно подключать несколько (если ваш сервер позволяет, конечно). Ряд серверных платформ позволяет подключить до 8-24 NVMe SSD. 

При этом, например, если у вас база 1С почему-то достигла объёма в несколько терабайт, а вы не хотите или не можете предпринимать никаких мер по уменьшению её размера (например http://www.gilev.ru/basereduction/), но при этом знаете, что на дисках сервера СУБД хорошо бы держать про запас свободного места ещё хотя бы на 50% объёма продуктивной базы (например, на случай реструктуризации или вообще внезапного роста), то например для базы в 4 терабайта не обязательно искать SSD на 8 терабайт, можно “размазать” базу средствами СУБД на 2-3 SSD меньшей ёмкости. 

Как именно разносить нагрузку tempdb, базы и логов — лучше всего не гадать, не слушать “чужих советов”, а просто “сфотографировать” со своей работающей системы фактические объёмы записи в СУБД например за неделю (подробнее: http://www.gilev.ru/dwpdssd/), и на их основании уже принимать решение вида “нам нужно вот столько SSD такой ёмкости, распределять нагрузку между дисками будем вот таким образом” (конкретный пример разнесения приводить не будем из принципа, чтобы он случайно не отложился в памяти как рекомендация).

Вышедшие NVMe PCIe 4.0 диски типа intel D7-P5600 настолько быстры, что современные сервера на RAM-дисках не дадут сколько-то значимого преимущества, но при этом обладают недостатками надежности  при отключении питания. Для малого бизнеса есть бюджетные диски типа Samsung 980 Pro.

Основные данные и файлы лицензирования ключей 1С.
Надежность дисков серии intel p3700, p4800 проверена временем. На таких дисках можно смело размещать основные данные. Вероятность выхода из строя таких дисков меньше чем блока питания к примеру. На некоторых проектах такие диски успешно работают более 5 лет.

Усилия по повышению надежности надо предпринимать на программном уровне (СУБД и т.п.)  оперативно передавая  данные на резервный сервер. Так как риски словить вирус или испортить данные руками пользователей будут гораздо выше. Оперативно выполняемые бэкапы на отдельный физический локальный диск будут первым шагом, более эффективным чем зеркалирующий рейд. Для бэкапов на физических серверах можно использовать например https://acronis-infoprotect.ru/backup . Если у вас будет резервный сервер для поднятия бэкапа, а также удаленно лежащая копия, то это снимает вопрос по необходимости зеркалирования дисков рейдом.

Почему RAID не является панацеей для отказоустойчивости

Что же касается надёжности — тут наша позиция такая: массив RAID даёт шанс пережить выход из строя условно 1-2 носителей из его состава. Это конечно замечательно, но если мы начинаем изучать, что же на самом деле может “сломаться” (не в порядке параноидального бреда, а по наблюдениям нас и наших клиентов) — выясняется, что это лишь малая часть айсберга! Выходят из строя разные комплектующие внутри сервера, выходят из строя компоненты сети, может “приехать” неудачное обновление Windows или 1С, может “упасть” сервер 1С, может “сломаться” база 1С, может “прилететь шифровальщик”. Будет ли откровением то, что ни от какого из этих факторов риска RAID-массив нас не спасёт? Здесь уже надо говорить о сценариях резервирования, отказоустойчивости и катастрофоустойчивости (но об этом в другой раз).

 

Почему SSD не “настолько же ненадёжны, как механические диски”: в механическом диске были вращающиеся с бешеной скоростью пластины, были яростно летающие над ними на микронной высоте головки, всё это жужжало, вибрировало, грелось, сильно боялось тряски или сторонних вибраций, внезапных отключений электричества и вообще было нежным и хрупким даже в довольно крепком серверном исполнении. Современные серверные SSD — скучная плата без движущихся деталей, возможно (и даже крайне желательно) с увесистым радиатором (а кто-нибудь может и вентилятор сверху “приколхозить”), по сути там внутри есть флэш-память и контроллер. Внутри SSD есть расходуемый ресурс, а именно флэш-память, которая при записи неизбежно изнашивается, и этот параметр крайне желательно контролировать хотя бы раз в месяц, но если к подбору SSD подошли правильно и вдумчиво — SSD как минимум переживёт период продуктивной эксплуатации, а с очень большой вероятностью доживёт и до полного морального устаревания сервера. Вся остальная электроника внутри — условно такая же, в остальном сервере, и выход из строя хоть и может произойти, но примерно с такой же вероятностью, как у любой другой компоненты серверного оборудования.

 

В итоге: для сервера 1С/СУБД RAID-массив из NVMe SSD в большинстве случаев не является необходимым ни для ускорения, ни для повышения надёжности.

 

Смотрите также Зачем аппаратному RAID-контроллеру нужна батарейка?

Подключение дисков с разъемом U.2

Влияние HDD на быстродействие 1С:Предприятие 8

31 марта — Международный день резервного копирования
Про диски для 1С

Подбираем хороший сервер

FREEPROCCACHE

Опубликовано автором

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

http://technet.microsoft.com/ru-ru/library/ms174283.aspx

Удаляет все элементы из кэша планов, удаляет заданный план из кэша планов с помощью указания дескриптора плана или дескриптора SQL либо удаляет все записи кэша, связанные с указанным пулом ресурсов.

Инструкция DBCC FREEPROCCACHE используется для аккуратной очистки кэша планов. Освобождение кэша планов приводит, например, к тому, что хранимая процедура повторно компилируется, а не используется из кэша. Это может стать причиной внезапного временного снижения производительности обработки запросов. В SQL Server для каждого очищенного хранилища кэша в кэше планов журнал ошибок содержит следующее информационное сообщение: «SQL Server обнаружил %d экземпляров, записанных на диск хранилищ кэша для хранилища кэша %s (части кэша планов) в результате операций DBCC FREEPROCCACHE или DBCC FREESYSTEMCACHE». Это сообщение добавляется в журнал каждые пять минут при сбросе кэша в течение этого интервала времени.

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

Иногда возникает необходимость очистить кэш для определенной БД. Когда полностью очиненный кэш сделанный по необходимости для одной БД, может повлиять на производительность остальных работающий в одном экземпляре SQL. Есть недокументированная команда по очистки КЭШа БД. Насколько она безопасна, решать каждому ее использовавшему:

1. select name, database_id from sys.databases
// получаем идентификатор нужной БД.

2. DBCC FLUSHPROCINDB(<database_id>)
// очищаем кэш по id БД.

 

 

Особенности 8.3.17

Опубликовано автором

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

Реализована возможность заимствования подписок на события и создания собственных подписок в расширении.

Реализована возможность определения IP-адреса компьютера, который начал сеанс работы с информационной базой. IP-адрес может быть определен не всегда и не для всех режимов работы.
Реализовано свойство IPАдресКлиента для объектов АдминистрированиеСеанс и СеансИнформационнойБазы.Реализована возможность отображения IP-адреса клиентского приложения в консоли управления кластером и стандартной обработке управления серверами.

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

Реализовано индексирование файлов журнала регистрации. Индексация выполняется в фоновом режиме. Индексы хранятся в файлах с расширением .lgx в каталоге 1Cv8Log. Оптимизированы алгоритмы последовательного чтения файлов журнала регистрации.
Никаких дополнительных настроек для включения индексации не требуется. За счет индексации существенно ускорен отбор записей журнала регистрации по индексируемым полям.При открытии в конфигураторе файла журнала регистрации другой информационной базы, индексирование данного файла выполняется в фоновом режиме и индексный файл стирается после завершения работы с просматриваемого журнала регистрации.Для новой информационной базы значение параметра Разделять хранение журнала по периодам устанавливается в значение Неделя. Для существующих информационных баз рекомендуется установить разделение таким образом, чтобы размер одного файла журнала не превышал 100 Мбайт. Прекращена поддержка журналов регистрации, сформированных в системе «1С:Предприятие» версий 8.0 и 8.1.

При работе в клиент-серверном варианте ускорен запуск первого сеанса для доступа к информационной базе. Ускорение особенно заметно для конфигураций, содержащих большой объем метаданных.

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

Оптимизировано сравнение составных типов с не составными, если не составной тип может принимать значение NULL и в запросе используются временные таблицы.
Оптимизированы следующие операции:Сравнение вида A = B, где A – составной тип, а B – простой тип и может принимать значение NULL.
Сравнение вида ЕСТЬNULL(A, B) = C, где A – простой тип и может принимать значение NULL, а C – составной тип.
Сравнение вида Выражение1 В (ВЫБРАТЬ ….) и сравнение вида Выражение1 В (Список значений), где Выражение1 – поле ссылочного типа на несколько таблиц. При этом в списке выборки подзапроса или в списке значений должны находиться ссылки на разные таблицы и отсутствовать значение Неопределено.
Оптимизация применяется только в тех случаях, когда это не влияет на результат запроса. Оптимизация может привести к улучшению плана запроса и уменьшению времени компиляции запроса.

Если в запросе используется сравнение с пустой ссылкой, переданной в качестве параметра, то в СУБД передается запрос, в котором параметр заменен на константу. Оптимизация применяется в том случае, если кластер серверов использует СУБД IBM DB2, Microsoft SQL Server или Oracle Database.

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

При использовании файлового или клиент-серверного варианта (при использовании СУБД Microsoft SQL Server) оператор языка запросов В, который отвечает всем следующим критериям, всегда возвращает значение типа Булево:
Оператор В содержит подзапрос.
Подзапрос оператора В содержит операции ПЕРВЫЕ или УПОРЯДОЧИТЬ ПО.
В левой части оператора В и подзапросе содержатся значения разных типов или тип ЛюбаяСсылка.
Рекомендуется проанализировать подобные запросы и выполнить их рефакторинг, при необходимости. В режиме совместимости с версией 8.3.16 поведение не изменилось.

Библиотека OpenSSL обновлена до версии 1.1.0k.

Реализована возможность работы с СУБД Microsoft SQL Server 2019.

 

Подробнее:

https://dl03.1c.ru/content/Platform/8_3_17_1386/1cv8upd_8_3_17_1386.htm#19110485-11e0-11ea-8371-0050569f678a

 

Как восстановить базы данных без лога *.ldf

Опубликовано автором

1. Создаем новую базу с таким же именем и такими же по именам и расположению .mdf и .ldf файлами

2. Останавливаем сервер, подменяем файл .mdf

3. Стартуем сервер, не обращаем внимания на статус базы

4. Из «Query Analyzer» выполняем скрипт:

SQL
Use master
go
sp_configure ‘allow updates’, 1
reconfigure with override
go

4. Там же выполняем:

SQL
select status from sysdatabases where name = ‘<db_name>’

и запоминаем/записываем значение на случай неудачи ребилда лога.

5. Там же выполняем:

SQL
update sysdatabases set status= 32768 where name = ‘<db_name>’

6. Перезапускаем SQL Server.

7. В принципе база должна быть видна (в emergency mode). Можно, например, заскриптовать все объекты.

8. Из «Query Analyzer» выполняем:

SQL
DBCC REBUILD_LOG(‘<db_name>’, ‘<имя нового лога с указанием полного пути>’)

SQL Server скажет — Warning: The log for database ‘<db_name>’ has been rebuilt.

9. Если все нормально, то там же выполняем:

SQL
Use master
go
sp_dboption ‘<db_name>’, ‘single_user’, ‘true’
go
USE <db_name>
GO
DBCC CHECKDB(‘<db_name>’, REPAIR_ALLOW_DATA_LOSS)
go

9a.
Если Вам не удалось перевести базу в single user mode, то для проверки целостности данных можно попробовать dbo only mode
sp_dboption », ‘dbo use only’, ‘true’

10. Если все в порядке, то:

SQL
sp_dboption ‘<db_name>’, ‘single_user’, ‘false’
go
Use master
go
sp_configure ‘allow updates’, 0
go

 

Обновление статистики базы данных

Опубликовано автором

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

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

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

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

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

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

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

В Вашем случае, имеет смысл настроить хотя бы ежедневное обновление статистик.

Например, в период минимальной нагрузки на систему — в ночные часы.

Можно сделать, например, так: В MS SQL:

1) Создайте новый план обслуживания

2) Создайте субплан (Add Subplan) и назовите его «Обновление статистик».

3) Добавьте в него задачу Update Statistics Task из панели задач:

4) Настройте расписание обновления статистик (рекомендация не реже 1 раза в день).

5) Настройте саму задачу:

5.1) Базу данных для который выполняется обновление статистики

5.2) Список таблиц установите «All» — это означает что будет обновлена статистика по всем таблицам БД

5.3) Укажите опцию Full scan

(Примечание. Такой режим будет эквивалентен скрипту

exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'
DBCC UPDATEUSAGE (dbname)

где dname имя вашей базы)

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

Поэтому в субплан:

6) Добавьте задачу Execute T-SQL Statement Task.

7) Соедините задачу Update Statistics Task стрелочкой с новой задачей

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

9) если у вас значительная нагрузка на базу в пиковые моменты (сотни пользователей, роботы-фоновики и т.п.) то наряду с параметром «Автоматическое создание статистики (AUTO_CREATE_STATISTICS)» будет полезно также для базы данных включить параметр «Автоматическое асинхронное обновление статистики (AUTO_UPDATE_STATISTICS_ASYNC)»

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

Если используется версия до SQL Server 2014 (12.x), SQL Server применяет пороговое значение в зависимости от процента измененных строк. Это значение не зависит от числа строк в таблице. Пороговое значение:
Если на момент оценки статистических данных кратность в таблице не превышала 500, обновление выполняется для каждых 500 модификаций.
Если на момент оценки статистических данных кратность в таблице превышала 500, обновление выполняется для каждых 500 + 20 % модификаций

Начиная с версии SQL Server 2016 (13.x) и при уровне совместимости базы данных 130 SQL Server используется пороговое значение для динамического обновления статистических данных по убыванию. Значение изменяется в зависимости от числа строк в таблице. Оно вычисляется как квадратный корень из произведения текущего значения кратности в таблице и 1000. Например, если таблица содержит 2 миллиона строк, значение вычисляется как квадратный корень из (1000 * 2000000) = 44721,359. Благодаря этому изменению статистика для больших таблиц будет обновляться чаще. Но если уровень совместимости для базы данных ниже 130, применяется пороговое значение SQL Server 2014 (12.x).

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

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

Особенности 8.3.14

Опубликовано автором

Добавлен встроенный веб-сервер (только для одной базы, из командной строки управление).

Реализован упрощенный OLAP . Теперь можно работать на чтение с копией таблицы с ведомой СУБД.
Реализовано событие технологического журнала <DBCOPIES>.Механизм копий базы данных требует лицензию КОРП.

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

Добавлен альтернативный механизм управления сервером 1С программно и кроссплатформенно, реализован объект АдминистрированиеСервера . Дополнительно смотрите https://wonderland.v8.1c.ru/blog/razvitie-klastera-serverov/

Улучшен механизм счетчиков  потребления ресурсов — реализована возможность отбора по признаку использования безопасного режима работы и профиля безопасности (добавлены новые типы фильтров).Для выражений отбора счетчика потребления ресурсов реализована возможность сравнения на неравенство. Для выражений отбора счетчика потребления ресурсов реализована возможность объединять «по И» несколько условий на один тип фильтра.

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

Больше не поддерживается интерфейс 8.2

Уменьшено время полного пересчета итогов для регистров бухгалтерии и накопления в следующих случаях:

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

Ускорено выполнение реструктуризации информационной базы при использовании СУБД Microsoft SQL Server и IBM DB2.

Уменьшилась вероятность одновременного закрытия множества соединений с Microsoft SQL Server, что положительно влияет на производительность работы с TempDB.

Для регистра расчета реализован кластерный индекс по регистратору. Перестройка индекса будет выполнена при реструктуризации регистра расчета или при переиндексации во время выполнения операции тестирования и обновления.Если при удалении записей из таблицы фактического периода действия не установлен отбор по измерениям регистра, то для запроса удаления не формируется соединение с основной таблицей регистра. Снижена вероятность табличной блокировки при удалении записей фактического периода действия регистра расчета.

Для динамического списка реализована возможность указания полей, которые будут использоваться в качестве ключевых полей выборки. Повышена производительность при использовании динамических списков с отсутствующей основной таблицей. Например, для динамического списка без основной таблицы, стало возможно использование группировки. Дополнительно смотрите https://wonderland.v8.1c.ru/blog/razvitie-dinamicheskikh-spiskov-s-proizvolnymi-zaprosami/

 Больше не поддерживается IE. У поля, имеющего вид ПолеHTMLДокумента, изменится с COMОбъект на ВнешнийОбъект. Ухудшится Windows-совместимость. Дополнительно смотрите https://wonderland.v8.1c.ru/blog/perevod-klientskikh-prilozheniy-dlya-windows-na-ispolzovanie-webkit-optimizatsiya-otobrazheniya-html/

В тонком, толстом и веб-клиентах, форма снимает блокировку объекта через 1 минуту после снятия признака модифицированности.(раньше снималась при закрытии формы)При работе под управлением СУБД PostgreSQL, в технологический журнал (событие <plansql>) помещаются планы запросов для запросов UPDATE, DELETE и INSERT. (Раньше был только SELECT)

 Реализовано отображение критических ошибок оптимизированного механизма обновления конфигурации базы данных в конфигураторе и в событии <EXCP> технологического журнала.

В технологическом журнале реализованы свойства Dbms, Database, DBCopy для событий обращения к СУБД (DB2, DBMSSQL, DBPOSTGRS, DBORACLE), событий EXCP и SDBL.

 Добавлен Механизм решения систем линейных алгебраических уравнений

смотрите https://wonderland.v8.1c.ru/blog/mekhanizm-resheniya-sistem-lineynykh-algebraicheskikh-uravneniy/

Подробнее http://downloads.v8.1c.ru/content//Platform/8_3_14_1565/1cv8upd_8_3_14_1565.htm

Получить 3ю строку

Заметка

Declare @N int
set @N = 3;
WITH CTE AS
(
SELECT Name, Salary, EmpID, RN = ROW_NUMBER()
OVER (ORDER BY Salary DESC)
FROM Employee
)
SELECT Name, Salary, EmpID
FROM CTE
WHERE RN = @N

Как найти дубликат записи

Заметка

Дублирование записей с одним полем

SELECT name, COUNT(email)
FROM users
GROUP BY email
HAVING COUNT(email) > 1

 

Дублирование записей с несколькими полями

SELECT name, email, COUNT(*)
FROM users
GROUP BY name, email
HAVING COUNT(*) > 1

 

Ошибка СУБД: Размер (39), выделенный тип «numeric», превышает максимально допустимое значение (38)

Опубликовано автором

Это зарегистрированная ошибка платформы 8.3.12.1412. Возникает когда есть ИТОГИ в запросе .

Временные костыли:

1. пересчет итогов
2. смещение даты актуальности итогов
3.  итоговое поле в запросе через Выразить(МоеПоле Как Число(15,2))

Скрипт сжатие таблиц mssqlserver

Опубликовано автором

DECLARE @Table_catalog NVARCHAR(128)
DECLARE @Table_schema NVARCHAR(128)
DECLARE @Table_name NVARCHAR(128)
DECLARE @Index_Name NVARCHAR(128)

DECLARE @cmd VARCHAR(4000)

— включение сжатия для таблиц
DECLARE TableNameCursor CURSOR
FOR
SELECT Table_catalog, Table_schema, Table_name FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = ‘BASE TABLE’
ORDER BY Table_catalog, Table_schema, Table_name

OPEN TableNameCursor

FETCH NEXT FROM TableNameCursor INTO @Table_catalog, @Table_schema, @Table_name
WHILE @@fetch_status = 0
BEGIN

PRINT @Table_catalog + ‘.’ + @Table_schema + ‘.’ + @Table_name
SET @cmd = ‘ALTER TABLE [‘ + @Table_catalog + ‘].[‘ + @Table_schema + ‘].[‘ + @Table_name + ‘] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)’
EXEC (@cmd)

FETCH NEXT FROM TableNameCursor INTO @Table_catalog, @Table_schema, @Table_name
END
CLOSE TableNameCursor
DEALLOCATE TableNameCursor

— включение сжатия для индексов
DECLARE IndexCursor CURSOR
FOR
SELECT DB_NAME(), schemas.name, tables.name, indexes.name
FROM sys.schemas as schemas inner join sys.tables as tables inner join sys.indexes as indexes on tables.object_id = indexes.object_id on schemas.schema_id = tables.schema_id
ORDER BY schemas.name, tables.name, indexes.name;

OPEN IndexCursor

FETCH NEXT FROM IndexCursor INTO @Table_catalog, @Table_schema, @Table_name, @Index_Name
WHILE @@fetch_status = 0
BEGIN

PRINT @Table_catalog + ‘.’ + @Table_schema + ‘.’ + @Table_name + ‘: ‘ + @Index_Name

SET @cmd = ‘ALTER INDEX [‘ + @Index_Name + ‘] ON [‘ + @Table_catalog + ‘].[‘ + @Table_schema + ‘].[‘ + @Table_name + ‘] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)’
EXEC (@cmd)

FETCH NEXT FROM IndexCursor INTO @Table_catalog, @Table_schema, @Table_name, @Index_Name
END
CLOSE IndexCursor
DEALLOCATE IndexCursor

— делаем шринк базы — возвращаем свободное место на диск
SELECT @cmd=(
SELECT ‘DBCC SHRINKDATABASE(»’+ DB_NAME() + »’)’
)
EXEC (@cmd)

Особенности 8.3.11

Опубликовано автором

Переработан механизм реструкторизации, актуально для баз с большими размерами

Реализован новый механизм реструктуризации информационной базы. Основные отличия этого механизма:

  • При выполнении реструктуризации обрабатываются только те физические таблицы базы данных, в которых есть реальные изменения.
  • Максимальное количество изменений выполняется без создания копии таблицы и копирования информации между копиями.
  • Если копирование информации между версиями таблиц все-таки требуется, это копирование будет выполняться средствами СУБД во всех возможных случаях.

Данная возможность включена в статусе бета-версии. Новый механизм реструктуризации используется только в клиент-серверном варианте, при работе с СУБД Microsoft SQL Server и PostgreSQL.

Для работы нового механизма реструктуризации требуется наличие Java 1.8 на компьютере, где установлен сервер «1С:Предприятия».

Для файла conf.cfg реализованы параметры JavaHome, JavaOpts, UpdateDBCfg.
Смотрите дополнительно https://wonderland.v8.1c.ru/blog/optimizatsiya-restrukturizatsii-bazy-dannykh/

Новый функционал «Система взаимодействия»

Стало возможно информировать клиентское приложение о событиях на стороне сервера «1С:Предприятия», в том числе асинхронно.
Реализована возможность развертывания собственного сервера системы взаимодействия. Сервер поставляется в виде отдельного дистрибутива и требует отдельной установки.

Реализовано событие технологического журнала <WINCERT>.

Событие предназначено для расследования событий, связанных с ошибками проверки действительности сертификатов средствами Windows API.Событие формируется только при работе под управлением ОС Windows.

 Стало возможно запускать более одного сеанса работы с веб-клиентом из одного веб-браузера.

Повышена скорость работы поиска по началу строки в языке запросов при работе с СУБД PostgreSQL.

При работе с СУБД PostgreSQL реализовано преобразование операции языка запросов ПОДОБНО `ТЕКСТ%` в более оптимальную операцию SQL-запроса.В режиме совместимости с версией 8.3.10 поведение не изменилось.

 Улучшена производительность и масштабируемость при использовании на стороне сервера «1С:Предприятия» объектов HTTPСоединение и FTPСоединение в том случае, если используется несколько соединений из различных сеансов.

 

Ускорена работа с временными таблицами, при использовании СУБД Microsoft SQL Server

следующих версий:

  • 2012, версия 11.0.5548.0 и старше.
  • 2014, версия 12.0.2430.0 и старше.
  • 2016.

Повышена скорость работы сервера «1С:Предприятия» в том случае, когда одновременно проводятся документы, содержащие большое количество (десятки тысяч) строк.

 

Оптимизирована работа с большими временными таблицами под управлением СУБД PostgreSQL.

Оптимизированы операции удаления записей из временных таблиц при выполнении некоторых операций в СУБД PostgreSQL и IBM DB2.

Уточнение отображения в линуксе

При работе под управлением ОС Linux, параметр рабочего процесса Занято памяти, вычисляется на основании значения VmRSS (resident set size). Значение параметра Занято памяти стало меньше в абсолютном выражении и более точно соответствует реальности.Рекомендуется провести переоценку параметров перезапуска рабочих процессов в свойствах рабочего сервера.

Добавлен платформенный вариант версионирования данных (для аудита) https://wonderland.v8.1c.ru/blog/istoriya-dannykh/

подробнее http://downloads.v8.1c.ru/content//Platform/8_3_11_2867/1cv8upd.htm

Недопустимое преобразование типов данных в записи

Опубликовано автором

Ошибка СУБД:
Microsoft SQL Native Client: Conversion failed when converting date and/or time from character string.
HRESULT=80004005, SQLSrvr: SQLSTATE=22007, state=1, Severity=10, native=241, line=1

ошибка может возникать например в момент обновления БД при изменении режима совместимости на «Не использовать»

Вариант решения: Установить native client на все рабочие сервера 1С кластера 1С.

Особенности 8.3.10

Опубликовано автором

Реализована поддержка СУБД PostgreSQL версии 9.6.

 Смотрите также http://1c.ru/news/pressrelise.jsp?id=1847

Повышена масштабируемость кластера серверов в том случае, если:

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

Снижено количество оперативной памяти, используемой сервером «1С:Предприятия», если в прикладном решении используются пакетные запросы.

Упрощена диагностика использования циклических ссылок при работе встроенного языка.

Реализована возможность дополнительно обработать данные, которые получил динамический список для отображения. Реализовано событие ПриПолученииДанныхНаСервере. Дополнительно смотрите https://wonderland.v8.1c.ru/blog/obrabotka-i-oformlenie-dannykh-dinamicheskogo-spiska/

В технологическом журнале реализовано отражение событий, связанных с:

  • получением и освобождением лицензий (как программных, так и ключей HASP);
  • получением лицензий на базовые версии;
  • регулярным мониторингом соответствия реального оборудования и списка оборудования, зафиксированного в лицензии.

Реализовано событие технологического журнала <LIC>.

Событие технологического журнала <HASP> предоставляет возможность анализа только технологических аспектов работы с ключами HASP (вызовы интерфейса работы с HASP), не предоставляя возможности отслеживать получение и освобождение лицензий, получаемых с ключей HASP.

Реализовано журналирование событий, возникающих при первом соединении сервера «1С:Предприятия» с СУБД Microsoft SQL Server, в технологическом журнале. Журналирование выполняется с помощью события <DBMSSQLCONN>.

В документации данное изменение описано здесь и здесь.

Изменен подход к хранению истории исполнения фоновых и регламентных заданий. В клиент-серверном варианте история хранится в разрезе информационных баз. Для каждой информационной базы хранится история:

  • до 1 000 фоновых заданий, созданных из встроенного языка;
  • до 1 000 регламентных заданий;
  • до 1 000 системных фоновых заданий (формируемых самой системой).

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

Реализовано в версии 8.3.10.2168 в новое событие SCRIPTCIRCREFS  режим автоматического поиска циклических ссылок

Недопустимое имя объекта «#tt

Опубликовано автором

Ошибка вроде как у платформу версии 8.3.9.1818 (Сервер 1С Предприятия x86-64) при работе базы начала вываливаться ошибка у пользователей:

Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
по причине:
Ошибка СУБД:
Microsoft SQL Server Native Client 10.0: Недопустимое имя объекта «#tt1».
HRESULT=80040E37, SQLSrvr: SQLSTATE=42S02, state=1, Severity=10, native=208, line=1

имеет регистрацию на сайте 1С
Код ошибки: 50010160
Код(ы) обращения: CSR-12050 CSR-12078
Зарегистрирована: 19.10.2016

Замечено что в том числе  8.3.9  «не любит» конструкцию «В (&Массив…)»
например ЗКГУ (ОбщийМодуль.ЗарплатаКадрыРасширенный.Модуль : 5948 : Запрос.Выполнить();)

Также проблема проявляется при интенсивном использовании поиска по строке в динамических списках

1. Исправлена и проверена на практике в релизе  8.3.9.2170. Не возникает на 8.3.8.2167.

2. Проверьте также наличие сервиспаков MS SQL Server.

3. Выключите Shared Memory

Флаг трассировки 2335

Опубликовано автором

Флаг трассировки 2335 заставит SQL Server 2005 и 2008 генерировать более консервативный с точки зрения потребления памяти план исполняя запроса, не ограничивая при этом объём используемой SQL Server памяти для  кэша данных, запросов и т.п. Необходимость в этом флаге может возникнуть, если после увеличения значения «max server memory» наблюдается замедление исполнения запросов. Подробности в статье KB2413549.

Флаги трассировки

Опубликовано автором

В SQL Server существуют два типа флагов трассировки: для сеанса и глобальные. Флаги трассировки сеанса действуют во время данного соединения и доступны только для этого соединения. Глобальные флаги трассировки устанавливаются на уровне сервера и доступны для каждого соединения с этим сервером. Некоторые флаги могут быть включены только как глобальные, а некоторые и как глобальные, и как для сеанса.

Применяются следующие правила.

  • Глобальный флаг трассировки должен быть включен глобально. В противном случае, флаг трассировки не повлияет на работу сервера. Рекомендуется включать глобальные флаги трассировки при запуске с помощью параметра командной строки -T.
  • Если флаг трассировки может иметь или глобальную область, или область сеанса, он может быть включен с соответствующей областью. Флаг трассировки, включенный на уровне сеанса, никогда не влияет на другой сеанс, и действие флага трассировки прекращается, если SPID, открывший сеанс, выполняет выход.

Флаги трассировки устанавливаются и снимаются с помощью любого из следующих методов:

  • Использование команд DBCC TRACEON и DBCC TRACEOFF.Например, DBCC TRACEON 2371: Чтобы включить флаг трассировки глобально, используйте DBCC TRACEON с аргументом -1: DBCC TRACEON (2371, -1). Чтобы отключить глобальный флаг трассировки, используйте команду DBCC TRACEOFF с аргументом -1.
  • Использование параметра запуска -T для задания установки флага трассировки при запуске.Параметр запуска -T включает флаг трассировки глобально. Невозможно включить флаг трассировки уровня сеанса с помощью параметра запуска. Дополнительные сведения о параметрах запуска см. в разделе 

Использование команды DBCC TRACESTATUS для определения активных в данный момент флагов трассировки.

Перечень флагов вы сможете посмотреть на msdb.

Флаг трассировки 1117

Опубликовано автором
Флаг трассировки 1117

При наличии типа ожидания pagelatch рекомендуется вспомнить про логическую конкуренцию ресурсов файлов.

select   session_id, wait_duration_ms,   resource_description      from    sys.dm_os_waiting_tasks where   wait_type like ‘PAGE%LATCH_%’ and              resource_description like ‘2:%’
В рамках одной файловой группы может быть создано несколько файлов. Например, для базы tempdb рекомендуется создавать несколько файлов, что может в некоторых сценариях увеличить производительность системы.

Идея такая:
Если логических ядер <=8 то файлов tempdb должно быть равно количеству ядер (при том что диск достаточный для увеличения нагрузки)

Если логических ядер >8 то добавить еще 4 файла и посмотреть по факту. Надо, еще добавить, но при этом важно не переборщить, можно вместо логических ожиданий наплодить очередей к диску например.

Теперь предположим ситуацию: все файлы, входящие в файловую группу, имеют одинаковый размер. Создается большая временная таблица. Места в файле #1 не достаточно и разумеется происходит AutoGrow. Через время такая же таблица пересоздается, но вставка происходит в файл #2, потому что #1 временно заблокирован. Что в таком случае будет?AutoGrow для #2… и повторная задержка при выполнении запросов. Для таких случаев, был предусмотрен TF 1117. Работал он глобально и при нехватке места в одном файле вызывал AutoGrow для всех файлов в рамках одной файловой группы.

В MS SQL Server 2016 данный трейс-флаг включен по умолчанию для tempdb и может избирательно настраиваться для пользовательских баз:
ALTER DATABASE test
MODIFY FILEGROUP [PRIMARY] AUTOGROW_ALL_FILES
GO
ALTER DATABASE test
MODIFY FILEGROUP [PRIMARY] AUTOGROW_SINGLE_FILE
GO

Посмотрим на размер файлов:
USE tempdb
GO

SELECT
name
, physical_name
, current_size_mb = ROUND(size * 8. / 1024, 0)
, auto_grow =
CASE WHEN is_percent_growth = 1
THEN CAST(growth AS VARCHAR(10)) + ‘%’
ELSE CAST(CAST(ROUND(growth * 8. / 1024, 0) AS INT) AS VARCHAR(10)) + ‘MB’
END
FROM sys.database_files
WHERE [type] = 0

name physical_name size_mb auto_grow
---------- --------------------------------------------------- -------- ------------
tempdev D:\DATABASES\SQL_2016RC0\TEMP\tempdb.mdf 8.000000 64MB
temp2 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_2.ndf 8.000000 64MB
temp3 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_3.ndf 8.000000 64MB
temp4 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_4.ndf 8.000000 64MB

Создаем временную таблицу:
IF OBJECT_ID('#t') IS NOT NULL
DROP TABLE #t
GO

CREATE TABLE #t (
ID INT DEFAULT 1,
Value CHAR(8000) DEFAULT ‘X’
)
GO

INSERT INTO #t
SELECT TOP(10000) 1, ‘X’
FROM [master].dbo.spt_values c1
CROSS APPLY [master].dbo.spt_values c2

Места чтобы вставить данные не хватит и произойдет AutoGrow.

AUTOGROW_SINGLE_FILE:
name physical_name size_mb auto_grow
---------- --------------------------------------------------- ----------- ------------
tempdev D:\DATABASES\SQL_2016RC0\TEMP\tempdb.mdf 72.000000 64MB
temp2 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_2.ndf 8.000000 64MB
temp3 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_3.ndf 8.000000 64MB
temp4 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_4.ndf 8.000000 64MB

AUTOGROW_ALL_FILES:
name physical_name size_mb auto_grow
---------- --------------------------------------------------- ----------- ------------
tempdev D:\DATABASES\SQL_2016RC0\TEMP\tempdb.mdf 72.000000 64MB
temp2 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_2.ndf 72.000000 64MB
temp3 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_3.ndf 72.000000 64MB
temp4 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_4.ndf 72.000000 64MB

Флаг трассировки 8048

Опубликовано автором

В случае, если в вашей системе более 8 логических процессоров и наблюдается большое число ожиданий CMEMTHREAD и кратковременных блокировок:
SELECT waiting_tasks_count
FROM sys.dm_os_wait_stats
WHERE wait_type = 'CMEMTHREAD'
AND waiting_tasks_count > 0

SELECT spins
FROM sys.dm_os_spinlock_stats
WHERE name = ‘SOS_SUSPEND_QUEUE’
AND spins > 0

то использование TF 8048 помогает избавиться от проблем с производительностью.

В SQL Server 2016 данный трейс флаг включен по умолчанию.

флаг трассировки -T1118

Опубликовано автором
-T1118

SQL Server вычитывает данные с диска кусками по 64Кб (так называемыми экстентами). Экстент – это группа из восьми физически последовательных страниц (по 8Кб каждая) файлов базы данных.

Имеются два типа экстентов: смешанные и однородные. На смешанном экстенте могут храниться страницы с разных объектов. Такое поведение позволяет очень маленьким таблицам занимать минимальное количество места. Но чаще всего таблицы не ограничиваются размером в 64Кб и когда требуется более 8 страниц для хранения данных по одному объекту, то происходит переключение на выделение однородных экстентов.

Чтобы изначально выделять для объекта однородные экстенты  предусмотрен флаг трассировки 1118, который рекомендуется включать:

DBCC TRACEON (1118, -1);
GO

В 2016 версии такого уже не будет. Но для каждой пользовательской базы можно задать опцию MIXED_PAGE_ALLOCATION

смотрите также http://www.gilev.ru/trace2371/

Возможности 8.3.4

Опубликовано автором

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

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

Общие реквизиты, которые являются разделителями в режиме Независимо и совместно, не могут быть выбраны в список реквизитов ПоляБлокировкиДанных. Реализована возможность указывать такие реквизиты в качестве имени пространства блокировок объекта БлокировкаДанных. Система вызовет исключение в том случае, если в объекте БлокировкаДанныхиспользуется значение разделителя, отличное от значения, используемого в сеансе.

Изменения реализованы для следующих объектов:

  • Справочники;
  • Документы;
  • Планы видов характеристик;
  • Планы счетов;
  • Планы видов расчета;
  • Планы обмена;
  • Бизнес-процессы;
  • Задачи;
  • Константы.

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

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

Для сервера «1С:Предприятия» реализованы лицензии с ограниченным количеством одновременно обслуживаемых сеансов клиентских приложений —  МИНИ-СЕРВЕР на 5 подключений.

Подробнее здесь

Особенности 8.3.1

Опубликовано автором

При работе с Microsoft SQL Server версии 2005 и выше, используется режим управления версиями строк, если конфигурация использует режим управляемых блокировок. Используется уровень изоляции транзакций READ_COMMITED_SNAPSHOT. При чтении данных вне транзакций используется согласованное чтение.

Возможность помещения в технологический журнал информации о работе с внешними источниками данных. Для этого в конфигурационный файл технологического журнала добавлено событие <EDS>

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

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

Табличные пространства не создаются автоматически и должны быть созданы администратором базы данных. Если дополнительных табличных пространств не создано — используется табличное пространство по умолчанию (pg_default).

Расширен состав свойств для события технологического журнала <call> в том случае, если событие генерируется для процесса rphost (свойство process равноrphost), а также в том случае, если процесс rphost выполняет обращение к виртуальным ресурсам системы.

Добавлены свойства, отображающие:

  • Report — имя объекта метаданных выполняемого отчета;
  • Method — имя вызванного метода;
  • SessionID — номер сеанса;
  • Memory — объем памяти в байтах, занятой, но не освобожденной за вызов;
  • MemoryPeak — объем памяти в байтах, занятой, но не освобожденной за вызов. Пиковое значение;
  • InBytes — количество прочитанных за вызов данных с диска, в байтах;
  • OutBytes — количество записанных за вызов данных с диска, в байтах;
  • Context — контекст события.

 

Возможность помещения в технологический журнал информации о работе с внешними источниками данных. Для этого в конфигурационный файл технологического журнала добавлено событие <EDS>.

 

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

Подробнее здесь

Особенности 8.3.8

Опубликовано автором

Файловая версия 8.3.8 работает существенно быстрее чем версии 8.3.6, 8.3.7

Реализована поддержка веб-сервера Apache 2.4 для ОС Windows и Linux.

Для динамического списка реализована поддержка работы с пакетным запросом.

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

В языке запросов реализовано упрощение некоторых выражений вида <ВЫРАЖЕНИЕ> ИЛИ ИСТИНА.

Оптимизированы операции удаления записей из временных таблиц при выполнении некоторых операций в СУБД PostgreSQL и IBM DB2.

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

 

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

Если блокировка устанавливается для дальнейшей работы с остатками, то не рекомендуется указывать значения оборотных субконто при наложении блокировки (возможно использование как свойства БлокироватьДляИзменения, так и явное использование управляемой блокировки). Если блокировка устанавливается для дальнейшей работы с оборотами — следует указывать все необходимые значения субконто, в том числе и значения оборотных субконто (возможно использование только явного вызова управляемой блокировки).

В режиме совместимости с версией 8.3.7 поведение не изменилось.

 

Реализовано событие технологического журнала <FTEXTSKIP>.

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

Для выполнения реструктуризации таблиц базы данных с изменением типов полей необходимо установить нужный режим режим совместимости и выполнить операцию реструктуризации информационной базы в конфигураторе (Главное меню — Администрирование — Тестирование и исправление).

В режиме совместимости с версией 8.3.7 поведение не изменилось.

При работе со всеми СУБД изменена структура индексов по полям составного типа. В результате уменьшено количество индексов. Такое построение индексов осуществляется при отключенном режиме совместимости и после выполнения реструктуризации соответствующего объекта конфигурации.
Для выполнения реструктуризации таблиц базы данных с изменением индексов необходимо установить нужный режим режим совместимости и выполнить операцию реструктуризации информационной базы в конфигураторе (Главное меню — Администрирование — Тестирование и исправление).
В режиме совместимости с версией 8.3.7 поведение не изменилось.

Ошибка 10161406 исправлена в 8.3.8.1747

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

 

Более подробно тут

Особенности 8.3.5

Опубликовано автором

Реализована официальная возможность работы с СУБД Microsoft SQL Server 2014.

Реализована официальная поддержка работы «1С:Предприятия» под управлением ОС Microsoft Windows Server 2012 R2 (x86-64)

Реализован новый «спорный» формат хранения журнала регистрации .Файл ЖР в новом формате (sqlite) после сокращения средствами платформы не уменьшается и все так же занимает много места на диске.
Рекомендуют останавливать сервер 1С периодически и использовать утилиту и команду
sqlite3 1Cv8.lgd «VACUUM;»
Добавлен новый способ управления спящими сеансами

Более подробно тут

Обнаружение повышения области блокировки таблицы

Опубликовано автором

Определяем ID объекта — исследуемой таблицы в базе данных

USE [trade_debug] Select * from Sys.objects WHERE Sys.objects.name = ‘_Reference82’

где _Reference82 имя таблицы

ObjectID

Далее настраиваем трассировку SQL server profiler:
PRprop

Устанавливаем фильтр:

PRfilter

Отключение эскалации чревато дополнительной нагрузкой на сервер, это надо учитывать:

USE [trade_debug] ALTER TABLE _Reference82 SET (LOCK_ESCALATION = DISABLE)

Проверить режим эскалации блокировок можно с помощью скрипта:

USE [trade_debug] SELECT lock_escalation, lock_escalation_desc, name FROM sys.tables WHERE lock_escalation_desc=’DISABLE’

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

Настройка и изменение параметров сортировки сервера

Опубликовано автором

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

Чтобы изменить параметры сортировки по умолчанию для экземпляра SQL Server (эта операция может оказаться сложной), выполните следующие шаги:

  • Проверьте наличие данных и сценариев, необходимых для повторного создания пользовательской базы данных и всех ее объектов.
  • Экспортируйте все данные с помощью такого средства, как Программа bcp. Дополнительные сведения см. в разделе Массовый импорт и экспорт данных.
  • Удалите все пользовательские базы данных.
  • Перестройте базу данных master, при этом в свойстве SQLCOLLATION команды setup задайте новые параметры сортировки. Например: 
    Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=InstanceName 
/SQLSYSADMINACCOUNTS=accounts /[ SAPWD= StrongPassword ] 
/SQLCOLLATION=CollationName

    Дополнительные сведения см. в  Перестроение системных баз данных.

  • Создайте все базы данных и все их объекты.
  • Импортируйте все данные.

 

ЕСТЬ ВАРИАНТ недокументированного решения:

Остановите сервис и запустите команду (из папки с екзешником).

sqlservr -m -T4022 -T3659 -q»Cyrillic_General_CI_AS»

 

MSSQL: как просмотреть информацию о бэкапах, хранящихся в файле .bak и .trn

Опубликовано автором 
restore headeronly from disk = ‘c:\base.bak’

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

Если не уменьшается раз файла лога базы данных MS SQL Server

Опубликовано автором

Выполинте скрипт

DECLARE @subscriptionDB AS sysname
SET @subscriptionDB = N’ИмяВашейБазы’

USE master
EXEC sp_removedbreplication @subscriptionDB
GO

Если вдруг это не поможет, то выполните диагностику с помощью

DBCC OPENTRAN

найдите «открытую» транзакцию и удалите ее

если она «системная», то проверьте наличие включенных механизмов типа «лог-шиппинг» и т.п.

Could not continue scan with NOLOCK due to data movement

Опубликовано автором

Что говорит производитель MS SQL Server:

http://msdn.microsoft.com/ru-ru/library/bb326281.aspx
SQL Server Database Engine не удается продолжить выполнение запроса, поскольку приложение пытается считать данные, обновленные или удаленные другой транзакцией. Очередь использует подсказку блокировки NOLOCK или
уровень изоляции транзакции READ UNCOMMITTED.
Как правило, доступ к данным, которые изменяются другой операцией, запрещен из-за наложенной на них блокировки.
Однако подсказка блокировки NOLOCK и уровень изоляции транзакции READ UNCOMMITTED позволили запросу считать данные, заблокированные другой транзакцией. Это называется «грязным» чтением, поскольку таким образом можно считать значения, которые еще не были зафиксированы и могут быть изменены.
Эта ошибка отменяет запрос. Отправьте запрос повторно или удалите подсказку блокировки NOLOCK.

Есть небольшая вероятность того, что дело в конфигурации.

Пример на скриншоте.

Could not continue scan with NOLOCK due to data movement

Но здесь есть ключевое НО: Обратите внимание, что речь идет о конфликте блокировок и запрос на чтение вне тразнакции.

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

В ОСТАЛЬНЫХ СЛУЧАЯХ, применительно к 1С:Предприятие скорее дело не в этом.

Проблемы с диском!!! Ошибка появляется при разрушении данных.

Проверьте БД  с помощью DBCC CHECKDB. Обязательно сделайте резервную копию!

Попытайтесь с помощью все той же DBCC CHECKDB восстановить данные (если жесткий диск «не умирает»).

ALTER DATABASE [Ваша база] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO

DBCC CHECKDB ([Ваша база],REPAIR_ALLOW_DATA_LOSS)
GO

ALTER DATABASE [Ваша база]SET MULTI_USER WITH ROLLBACK IMMEDIATE
GO

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

 

Или это ошибка платформы

Такое уже было раньше

http://downloads.v8.1c.ru/content/Comm/Platform/Err_8_2_9_356.htm

10036291  Ошибка СУБД: Microsoft OLE DB Provider for SQL Server: Could not continue scan with NOLOCK due to data movement.

Проблема:
В клиент-серверном варианте информационной базы с использованием MS SQL Server при возникновении ошибки

Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: Could not continue scan with NOLOCK due to data movement.
HRESULT=80040E14, SQLSrvr: Error state=3, Severity=C, native=601, line=1

происходит аварийное завершение работы программы.
Дата публикации: 2009-11-16

На момент написания статьи такой ошибки не было зарегистрировано, но это не 100% гарантия.

Есть смысл при возникновении проблемы обратиться на v8@1c.ru

Улучшения по производительности при отключении режима совместимости 8.2.13

Опубликовано автором

Почему мы рекомендуем отключать режим совместимости с 8.2.13

Улучшения в версии 8.2.14

  • Оптимизировано выполнение запроса вида «ТипЗначения(Поле1) = ТипЗначения(Поле2)», если «Поле1» и «Поле2» содержат значения ссылочного типа.
  • Оптимизированы выборки, выполняемые порциями (используемые в методах «Выбрать()», а также при реструктуризации), для всех СУБД.
  • Оптимизирован ряд механизмов сервера 1С:Предприятия для повышения масштабируемости и производительности при большом количестве работающих пользователей.
  • Оптимизирована работа с файлами на диске (включая временные файлы) для следующих механизмов: полнотекстовый поиск, справка, объект «ИнтернетПочта».
  • Оптимизирована работа кластера серверов с данными сеанса.
  • Ускорена работа функций «ПолучитьСоединенияИнформационнойБазы()» и «ПолучитьСеансыИнформационнойБазы()» при большом количестве зарегистрированных пользователей.
  • Повышена производительность и масштабируемость модуля расширения веб-сервера.
  • В веб-клиенте оптимизировано обновление табличного документа после выполнения интерактивного редактирования, а также после программного изменения отдельных ячеек табличного документа.
  • Уменьшено количество серверных вызовов в части функциональности в веб-клиенте.
  • Ускорена работа механизма управляемых блокировок.
  • При отключенном режиме совместимости изменен режим хранения констант и настроек регистров накопления. Для каждого объекта используется своя таблица базы данных. Это означает улучшенную параллельность работы пользователей. При включении режима совместимости (в значение «Версия 8.2.13» или «Версия 8.1») выполняется обратная конвертация для обеспечения возможности запуска прикладного решения с помощью версии 8.2.13. Требуется реструктуризация!

Улучшения в версии 8.2.15

  • Для полей управляемой формы, отображающих реквизит составного типа, ускорено открытие списка быстрого выбора в тех случаях, когда в составной тип входят ссылочные типы с разными настройками быстрого выбора.
  • Уменьшено влияние режима отладки на скорость работы в режиме «1С:Предприятие» для тонкого клиента, толстого клиента, сервера и внешнего соединения.
  • Увеличена производительность работы системы в случае использования двух и более разделителей или одного разделителя с типом «Строка».
  • Оптимизирован запуск клиентского приложения.
  • Оптимизировано открытие формы веб-клиента при использовании большого количества элементов в условном оформлении формы.
  • Оптимизировано открытие формы отчета в веб-клиенте, который содержит большое количество элементов условного оформления.
  • Для блокировочных СУБД (Microsoft SQL Server, IBM DB2) изменение пользователя информационной базы в транзакции более не конфликтует с процессом аутентификации, кроме случая, когда аутентификацию пытается выполнить пользователь, данные которого изменены, и транзакция, в рамках которой были выполнены изменения, не завершена.
  • Для нового независимого и непериодического регистра сведений, индекс по измерениям является кластерным. При создании первого регламентного задания, индекс по идентификатору задания также является кластерным. Требуется реструктуризация! Для создания необходимых индексов в существующей информационной базе можно выполнить одно из следующих действий:
    • Выполнить реструктуризацию базы данных.
    • Выполнить загрузку информационной базы из файла «.dt».

Улучшения в версии 8.2.17

  • Реализована поддержка СУБД Microsoft SQL Server 2012.
  • Для работы с Microsoft SQL Server 2008 R2 возможно использование Native Client. При использовании Native Client возможно использование протокола SHARED MEMORY, если оба сервера находятся на одном компьютере. Использование протокола SHARED MEMORY (при использовании Native Client) возможно, начиная с версии Microsoft SQL Server 2005. Можно получить значительное ускорении при использовании SHARED MEMORY.

Улучшения в версии 8.2.18

  • Реализована поддержка Native Client для СУБД Microsoft SQL Server 2005 и Microsoft SQL Server 2012.
  • Оптимизирован сервис нумерации кластера серверов «1С:Предприятия», в результате чего исключено снижение производительности сервера при длительной работе.
  • Оптимизирована работа тонкого и толстого клиентов, работающих с файловой информационной базой, расположенной на сетевом ресурсе, при многопользовательском доступе. Ускорены различные операции с информационной базой, включая открытие и редактирование форм объектов, просмотр форм списков, запись объектов, проведение документов и т.д.
  • Повышена масштабируемость сервера «1С:Предприятия» при работе с высокой нагрузкой и большим количеством одновременно работающих пользователей.
  • Ускорена работа функций СтрЧислоСтрок() и СтрПолучитьСтроку() при работе в тонком клиенте, толстом клиенте и на стороне сервера.
  • Оптимизировано получение писем с помощью объекта ИнтернетПочта.
  • Ускорена работа функции ЗначениеЗаполнено() в том случае, если параметром функции выступает выражение, состоящее из получения свойства какой-либо переменной (как «через точку» так и с помощью операторного способа ([])) любого уровня вложенности.
  • В таблицу журнала документов добавлен индекс по полю Ссылка. В результате повышается скорость работы динамического списка журнала документов, а также поиск по ссылке в журнале документов.
  • Оптимизирована генерация запросов для СУБД Microsoft SQL Server:
    • Сокращено количество повторяющихся планов запросов;
    • Сокращено количество компиляций запросов в Microsoft SQL Server;
    • Уменьшен размер кеша планов запросов Microsoft SQL Server;
    • Уменьшено время работы некоторых запросов;
    • Улучшились создаваемые планы запросов в некоторых случаях.

     

  • Оптимизирована работа динамического списка и динамической выборки из базы данных в случае наличия упорядочивания выборки по убыванию.Для Microsoft SQL Server эти операции оптимизированы дополнительно, а также оптимизирована операция реструктуризации.
  • При работе в клиент-серверном варианте в режиме управляемых блокировок, изменен механизм генерации новых ссылок для объектов информационной базы. Ссылки генерируются строго последовательно для всех соединений сервера «1С:Предприятие» с сервером СУБД. В результате сокращена фрагментация таблиц и индексов в базе данных, а также повышена скорость вставки и чтения записей таблиц базы данных.
  • Оптимизирован механизм балансировки нагрузки в кластере серверов.
  • Оптимизировано получение из базы данных прикладных объектов без табличных частей при вызове метода ПолучитьОбъект() и при обращении к свойствам «через точку» от ссылки.
  • Оптимизирована работа сервера «1С:Предприятия» при выполнении запросов к объектам, на которые наложены ограничения доступа к данным.
  • При работе с СУБД Microsoft SQL Server оптимизированы операции, использующие конструкцию IN (…) с одним значением в списке.
  • Оптимизирован запуск клиентских приложений, фоновых и регламентных заданий.
  • Ускорена работа системы при частом выполнении фоновых заданий и вызовов web-сервисов.
  • Ускорено открытие управляемых форм.Оптимизация наиболее заметна в случае многопользовательского доступа (с помощью тонкого клиента) в файловом варианте информационной базы, расположенной на сетевом ресурсе.
  • Ускорена работа некоторых видов запросов в файловом варианте информационной базы, например:
    • Запросы вида ВЫБРАТЬ ПЕРВЫЕ 1 …;
    • Сравнение двух списков с помощью оператора языка запросов В: … (Объект, СчетФактура) В (&СписокОбъектовИПартий) ….

     

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

Улучшения в версии 8.2.19

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

ВАЖНО. ДЛЯ ПОЛУЧЕНИЯ ЭФФЕКТА ОТ ВЫКЛЮЧЕНИЯ СОВМЕСТИМОСТИ НАДО СДЕЛАТЬ «РЕСТРУКТУРИЗАЦИЮ» В «ТЕСТИРОВАНИИ И ИСПРАВЛЕНИИ»!

 

Не стартует TempDB (MS SQL Server)

Опубликовано автором

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

Если разобраться по логам скуля с этой проблемой вы не смогли то надо вернуть назад или в другое место файлы.

Для этого запустите службу в ограниченном режиме (в командной строке)

NET START MSSQLSERVER /f /T3608

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

NET START MSSQL$instancename /f /T3608

Вызовите через командную строку подключение под учетной записью Windows, имеющей права SYSADM (в моем случае это будет administrator)

SQLCMD -s COMPUTERNAME\administrator

Теперь снова измените путь

USE master
GO
ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = ‘C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\tempdb.mdf’)
GO
ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = ‘C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\tempdblog.ldf’)
GO

У Вас путь может отличаться. Ну вот собственно и все, теперь рестартуйте службу и все заработает.

Посмотрите обязательно также

SHOWPLAN permission denied in database ‘tempdb’

Перемещение системной базы tempdb в MS SQL Server

Перемещение системной базы tempdb в MS SQL Server

Опубликовано автором

 

TEMPDB представляет собой системную базу данных Microsoft SQL Server, в которой хранятся временные таблицы, созданные как самим сервером, так и пользователями. Эта база данных создается заново при каждом перезапуске Microsoft SQL Server. По умолчанию размер этой базы данных неограничен и увеличение его осуществляется при необходимости автоматически, порциями по 10% от текущего размера TEMPDB. Однако эти параметры могут быть переопределены пользователем. По умолчанию, минимальный размер этой базы данных, который устанавливается при старте Microsoft SQL Server, определяется размером системной базы данных MODEL. Очистка журнала транзакций в этой базе данных производится автоматически, при этом удаляются только неактивные записи журнала транзакций.
При работе 1С:Предприятия 8 в режиме клиент-сервер используются временные таблицы и переменные table. Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, UNION, DISTINCT и т.п.
Проблема:
В процессе работы 1С:Предприятия 8.1 возможно значительное увеличение размера базы данных TEMPDB. Если размер диска, на котором расположена база данных TEMPDB, окажется недостаточным, работа 1С:Предприятия 8.1 может завершиться аварийно.
Решение:
Если эта проблема проявляется регулярно, то рекомендуется переместить TEMPDB на другой диск большего размера.
Эту операцию можно выполнить следующим способом:
определить логические имена файлов базы данных TEMPDB (колонка «NAME» результата выполнения процедуры). Для этого нужно в Query Analyzer выполнить следующую команду:

USE tempdb
GO
EXEC sp_helpfile
GO

изменить месторасположение файлов базы данных TEMPDB с помощью команды ALTER DATABASE. Для этого нужно в Query Analyzer выполнить следующую последовательность команд: USE master
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = ‘Новый_Диск:\Новый_Каталог\tempdb.mdf’)
GO
ALTER DATABASE  tempdb
MODIFY FILE (NAME = templog, FILENAME = ‘Новый_Диск:\Новый_Каталог\templog.ldf’)
GO

Если в результате перемещения у Вас перестал запускаться MS SQL Server, то смотрите http://www.gilev.ru/repeartempdb/

 

Расшифровка ошибок MS SQL

Опубликовано автором

 

Пример текста сообщения об ошибке

HRESULT=80004005, SQLSrvr: Error state=3, Severity=C, native=601, line=1

Как расшифровывается

HRESULT=80004005 — номер ошибки, именно номер «80004005» обозначает ошибку СУБД, а в данном контексте это Microsoft OLE DB Provider. Кроме этого, описание большей части номеров здесь

Error state=3 — номер состояния сообщения об ошибке, имеет значение от 0 до 127

Severity=C — уровень серьезности ошибки. Имеет значение от 0 до 25

Уровень серьезности от 0 до 18 может указать любой пользователь. Уровни серьезности от 19 до 25 могут быть указаны только членами фиксированной серверной роли sysadmin и пользователями с разрешениями ALTER TRACE. Для уровней серьезности от 19 до 25 требуется параметр WITH LOG.Если ошибка возникла в компоненте SQL Server Database Engine, серьезность ошибки указывает на тип проблемы, с которой столкнулся сервер SQL Server.

native=601 — номер ошибки, список номеров

Ошибки 1505, 1508 случаются когда предпринимается попытка создания индекса (уникального или кластерного)

2601 — при попытке вставки записи (либо изменении поля существующей записи) и при этом нарушается уникальность уже существующего индекса

line=1 — номер строки, в которой произошла ошибка

Скрипт обновления индексов на ms sql server

Опубликовано автором

— реиндексация ms sql 2008——————-
declare @minRows int
set @minRows = 100

declare @reindexQuery nvarchar(max)

set @reindexQuery =
REPLACE(REPLACE(
cast(
(
select
‘ALTER INDEX ‘+idx.name+’ ON ‘+ sc.name+’.’+ t.name+
CASE
WHEN st.avg_fragmentation_in_percent > 30 THEN ‘ REBUILD WITH (ONLINE=ON)’
ELSE ‘ REORGANIZE’
END as query

from sys.dm_db_index_physical_stats( DB_ID(),NULL,NULL,NULL,NULL) st
join sys.tables t on (st.object_id=t.object_id)
join sys.schemas sc on (sc.schema_id=t.schema_id)
join sys.indexes idx on (t.object_id=idx.object_id and st.index_id=idx.index_id)
join sys.partitions p on (p.index_id=idx.index_id and p.object_id=idx.object_id)
where p.rows > @minRows and st.avg_fragmentation_in_percent > 5
order by st.avg_fragmentation_in_percent desc
FOR XML PATH(»), TYPE
) as nvarchar(max))
,'</query>’,’;
‘),'<query>’,»)

print @reindexQuery

exec (@reindexQuery)

Влияние HDD на быстродействие 1С:Предприятие 8

Опубликовано автором

О чем пойдет речь

Только вариант клиент-серверной версии 1C:Предприятие 8 под MS SQL Server.

Только кластеры NTFS и блоки RAID-массива (пусть даже это RAID0 из одного диска) в операционных системах Windows Server 2003 (и Windows XP).

Внимание! Действие статьи не распространяется на RAW-партиции и простые диски HDD, не входящие ни в какой RAID-массив с собственным контроллером.

Также маловероятна проблема в в Windows Server 2008 и Windows Vista.

Предмет оптимизации

«Размер блока и размер кластера желательно устанавливать одинаковыми, например, для баз данных SQL Server очень часто слышны рекомендации выбирать и там и там 64Кб. Однако, операционная система создает самый первый кластер (блок начальной загрузки MBR) размером в 63Кб. Эта особенность NTFS означает, что каждый последующий кластер будет сдвинут на 1Кб на предыдущий блок. Т.е. кластеры окажутся смещёнными относительно границ блоков массива. Такая ситуация приводит к тому, что одна операция чтения или записи кластера будет затрагивать два сектора и будет приводить к удвоению числа запросов ввода-вывода.»(цитата Александра Гладченко).

Источник Disk Partition Alignment for SQL Server (eng) и http://sqlblog.com/blogs/linchi_shea/archive/2007/02/01/performance-impact-of-disk-misalignment.aspx

Официальное подтверждение проблемы Microsoft и тут.

Средняя степень влияния

Практически все основные типы нагрузки ввода-вывода SQL Server получат выигрыш от этой оптимизации от 9 до 23%.

Способы определить наличие проблемы

1. С помощью DiskPart (Описание программы http://technet.microsoft.com/ru-ru/library/cc773140.aspx и http://support.microsoft.com/kb/300415/ru).

diskpart -i

Наличие цифры 32256 (потому что смещение offset 32256 / 512 байт на сектор = 63).

2. С помощью утилиты DiskExt.

3. С помощью обработки для 1С:Предприятие 8.1 NTFS.epf

Необходимо исправить геометрию RAID массива

1. Скопировать ВСЮ информацию с диска (предположим, что имя диска D:) на другой локальный диск (например диск E:) используя команду xcopy с параметрами копирования файлов и каталогов включая ownership и ACL.

xcopy D:\*.* E:\DiskD /E /K /O /X

Запустить Disk Management и посмотреть какой физический диск соответствует логическому диску D; допустим это диск 1.

Запустить Disk Management и удалить логический раздел D на физическом диске 1. (Т.е. чтобы выровнять раздел, нужно удалить смещённый раздел).

2) Внимание! Утилита DISKPART уничтожит данные на диске.

В командной строке запустить утилиту DISKPART и выполнить следующие команды:

DISKPART> select disk 1

Disk 1 is now the selected disk.

DISKPART> create partition primary align=64

DiskPart succeeded in creating the specified partition.

DISKPART> exit

Примечание. Команда «create partition primary align=64» создает новый раздел со смещением первого кластера на 64Кб, что позволяет выровнять границы кластеров и блоков и тем самым оптимизировать работу дисковой подсистемы.

3) В Disk Management создать диск (отформатировать)

4) Скопировать файлы обратно (если есть такая необходимость)

xcopy E:\DiskD\*.* D:\ /E /K /O /X

Примечание. Описание xcopy.

Флаги трассировки MS SQL server 2008, влияющие на производительность

Опубликовано автором

661: Disable the ghost record removal process

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

834: Use Microsoft Windows large-page allocations for the buffer pool

Флаг трассировки 834 применяется в SQL Server 2008 для включения механизма распределения буферному пулу больших страницы памяти, которыми умеют оперировать последние версии Microsoft Windows. У разных аппаратных платформ может быть разный размер страниц, он может изменяться от 2 до 16 Мбайт. Большие страницы распределяются при запуске и сохраняются на протяжении всей жизни процесса. Флаг трассировки 834 повышает производительность, увеличивая эффективность TLB буфера процессоров.
Флаг трассировки 834 применим только к 64-битным версиям SQL Server 2008. Включить флаг трассировки 834 может только та учётная запись, для которой разрешена локальная политика «Lock pages in memory». Включать флаг трассировки 834 можно только при запуске SQL Server.
Флаг трассировки 834 может препятствовать запуску сервера, если память сильно фрагментирована и это мешает распределению больших страниц. Поэтому, флаг трассировки 834 безопаснее использовать на серверах, которые обслуживают только SQL Server 2008.
Для получения более подробной информации о поддержке больших страниц Windows, перейдите на следующую страницу сайта Microsoft Developer Network (MSDN): Large-Page Support.

3502: Log Database Checkpoint Start and End times in the SQL Server ErrorLog

Флаг трассировки 3502 не влияет на производительность, но он нужен для контроля выполнения эталонных тестов TPC. Этот флаг трассировки заставляет SQL Server регистрировать в SQL Server ErrorLog время начала и окончания работы системного процесса контрольной точки.

8744: Disable pre-fetching for ranges

Флаг трассировки 8744 отключает предварительную выборку для таких операторов, как «Nested Loops». Неуместное использование этого флага может спровоцировать дополнительные физические чтения, при реализации плана с оператором «Nested Loops«.
Когда флаг трассировки 8744 включён при запуске сервер, он получает глобальный контекст. Когда он включен в сеансе пользователя, контекст ограничивается сеансом.

смотрите также http://www.gilev.ru/escalation/