Настройки tempdb для 1с
Установка SQL Server для работы с 1С:Предприятие 8.3
В этой заметке мы сделаем упор лишь на тех этапах процесса развёртывания нового экземпляра SQL Server, которые могут иметь значение для работы баз данных 1С:Предприятие 8.3.
На этапе установки Feature Selection достаточным минимумом будут компоненты Database Engine Services. Если вместе с сервером SQL Server на этом же сервере планируется развёртывание серверной части 1С:Предприятие, то потребуется установить ещё и компоненту Client Tools Connectivity. Для локального подключения и возможности локального администрирования SQL Server потребуется установить компоненты Management Tools.
Имейте ввиду, что компоненты Management Tools, включающие в себя такой инструмент, как SQL Server Management Studio, являются опциональными (не нужны для работы 1С) и они отсутствует в установщике начиная с SQL Server 2016. При необходимости эти компоненты могут быть установлены отдельно из отдельно загружаемого инсталлятора SQL Server Management Studio)
Обратите внимание на то, что входящие в состав Database Engine Services компоненты SQL Server Replication, Full-Text and Semantic Extractions, Data Quality Services не требуются для работы 1С:Предприятие и включены на представленном скриншоте только по той причине, что графический инсталлятор SQL Server 2016 не позволяет выключить данные компоненты в том случае, если включена родительская компонента Database Engine Services.
На этапе установки Server Configuration на закладке Server Accounts в качестве учётных записей, от имени которых будут работать службы SQL Server, в инфраструктурах с доменом Active Directory, с точки зрения усиления уровня безопасности, более правильным будет использование учётных записей типа Group Managed Service Account (gMSA), для которых управление паролями выполняется в автоматическом режиме службой Key Distribution Service на контроллерах домена.
Здесь обратите внимание на то, что в инсталляторе SQL Server 2016 есть опция Grant Perform Volume Maintenance Task, которую здесь мы оставили нетронутой, так как фактически мы уже выдали такое право ранее, когда говорили о предоставлении привилегии SE_MANAGE_VOLUME_NAME через политику безопасности Perform volume maintenance tasks. Замечено, что при включении данной опции, инсталлятор SQL Server 2016 вместо того, чтобы добавить в политику Perform volume maintenance tasks указанную нами сервисную учётную запись, от имени которой фактически будет запускаться экземпляр SQL Server, добавляет учётную запись службы (Virtual Account) вида NT Service\MSSQL$ . Объяснить природу такого поведения инсталлятора может обсуждение Раздача прав сервисным учётным записям при установке SQL Server 2016
Важно.
В перспективе желательно придерживаться того правила, чтобы порядок сортировки создаваемых в дальнейшем баз данных для 1С не отличался от порядка сортировки самого экземпляра SQL Server, который мы укажем на этапе его развёртывания. Если пренебречь этим правилом, то в дальнейшем мы можем столкнуться с проблемами, описанными, например, в ветке обсуждения Cannot resolve the collation conflict between "Latin1_General_CI_AS" and "SQL_Latin1_General_CP1_CI_AS"
На этапе установки Database Engine Configuration на закладке Server Configuration в соответствии с 1С:ИТС - Настройки Microsoft SQL Server для работы с 1С:Предприятием необходимо выбирать смешанный режим аутентификации – Mixed Mode.
Не стоит забывать про администраторов, которым в дальнейшем может потребоваться доступ к устанавливаемому экземпляру SQL Server. То есть, как минимум, в качестве администраторов устанавливаемого экземпляра SQL Server можно назначить встроенную группу администраторов сервера.
На этапе установки Database Engine Configuration на закладке Data Directories для расположения баз 1С укажем производительный дисковый массив или отдельные дисковые массивы. По возможности желательно определить для размещения файлов БД и логов транзакций отдельные дисковые массивы, учитывая то обстоятельство, что под транзакционные логи требуется более производительный по операциям записи массив.
На этапе установки Database Engine Configuration на закладке TempDB фалы системной базы tempdb также очень желательно размещать на отдельном быстром дисковом томе. В качестве достойного претендента на эту роль будет отдельный массив SSD-дисков или RAM-диск. Один из вариантов настройки RAM-диска, который можно будет использовать в кластерных развёртываниях SQL Server, мы рассмотрели ранее в статье Организуем RAM-диск для кластера Windows Server с помощью Linux-IO FC Target.
В нашем примере помимо основного размещения файлов tempdb на том же дисковом массиве, где предполагается размещение пользовательских БД, добавлен ещё один каталог, расположенный на быстром RAM-диске. Этот же каталог указан в качестве расположения для транзакционного лога tempdb.
Дополнительную реконфигурацию размещения файлов базы tempdb можно будет выполнить и после установки SQL Server. Этому вопросу будет посвящена последующая заметка Файлы системной базы данных tempdb.
Важно.
1С:Предприятие 8.3 в своей работе может очень активно использовать ресурсы системной базы данных tempdb, а недостаточная производительность дисковых томов, на которых расположены файлы tempdb, может привести к существенной деградации общего уровня производительности в конфигурациях 1С и ощутимо ухудшить комфорт пользователей, работающих с 1С. Поэтому очень важно подойти к вопросу планирования производительных дисковых ресурсов под эту системную БД.
Неотъемлемой частью правильного процесса установки SQL Server является то, что сразу после завершения развёртывания экземпляра SQL Server желательно выполнить развёртывание последнего Service Pack (SP), а затем и последнего Cumulative Update (CU) для установленной версии SQL Server. Информацию об актуальных SP и CU для разных версий SQL Server можно найти в документе Where to find information about the latest SQL Server builds. Помимо этого, ссылки на страницы загрузки последних CU можно найти на нашей Вики-странице Microsoft SQL Server
Проверено на следующих конфигурациях:
Версия ОС | Версия SQL Server |
---|---|
Microsoft Windows Server 2012 R2 Standard EN (6.3.9600) | Microsoft SQL Server 2016 SP2 CU4 (13.0.5233.0) |
Автор первичной редакции:
Алексей Максимов
Время публикации: 12.02.2019 14:23
Работа с базой данных TEMPDB
TEMPDB представляет собой системную базу данных Microsoft SQL Server, в которой хранятся временные таблицы созданные как самим сервером, так и пользователями. Эта база данных создается заново при каждом перезапуске Microsoft SQL Server. По умолчанию размер этой базы данных неограничен и увеличение его осуществляется при необходимости автоматически, порциями по 10% от текущего размера TEMPDB, однако эти параметры могут быть переопределены пользователем. По умолчанию, минимальный размер этой базы данных, который устанавливается при старте Microsoft SQL Server, определяется размером системной базы данных MODEL. Очистка журнала транзакций в этой базе данных производится автоматически, при этом удаляются только неактивные записи журнала транзакций.
При работе 1С:Предприятия 8 в режиме клиент-сервер широко используются временные таблицы . Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, UNION, DISTINCT и т.п.
Проблема
В процессе работы 1С:Предприятия 8 возможно значительное увеличение размера базы данных TEMPDB .
Причина
Причиной увеличения размера базы данных TEMPDB, как правило, является невозможность автоматической очистки журнала транзакций и повторного использования свободного пространства в базе данных TEMPDB из-за наличия активных транзакций, использующих объекты этой базы данных. Основные причины, вызывающие длительную блокировку работы этих механизмов базы данных TEMPDB, заключаются в следующем:
- "Большие" транзакции, использующие TEMPDB , выполнение которых занимает большой промежуток времени.
- Сетевые ошибки, из-за которых Microsoft SQL Server не получает уведомление о потере сетевого подключения. Если клиентская рабочая станция зависает, перезагружается, или будет выключена во время исполнения определяемой пользователем транзакции, то Microsoft SQL Server будет считать, что клиент продолжает работу, и выполняющаяся клиентская транзакция будет по-прежнему активна. Время обнаружения подобной ситуации зависит от настроек параметров сетевого протокола, используемого Windows . Например, при использовании протокола TCP/IP это время составляет 2 часа.
Если для завершения активных транзакций не хватает места в базе данных, Microsoft SQL Server автоматически увеличивает размер TEMPDB на величину, заданную в параметрах этой базы данных (по умолчанию - 10% от текущего размера).
Решение
Уменьшить размер базы данных TEMPDB до требуемой величины можно следующими способами:
В этом случае размер базы данных TEMPDB будет установлен по умолчанию или, если эта величина переопределена пользователем, размер будет установлен в соответствии с заданными параметрами.
С помощью команды DBCC SHRINKDATABASE можно уменьшить размер всей базы данных. Для этого нужно в Query Analyzer выполнить следующую команду:
С помощью команды DBCC SHRINKFILE можно уменьшить размер отдельных файлов базы данных. Для этого нужно в Query Analyzer выполнить следующую последовательность команд:
Копировать в буфер обменаDBCC SHRINKFILE ( Имя_Файла_Данных, Желаемый_Размер_Файла_Данных )
go
DBCC SHRINKFILE ( Имя_Файла_Журнала_Транзакций, Желаемый_Размер_Файла_Журнала_Транзакций )
go
Следует отметить, что эти команды рекомендуется выполнять в период наименьшей активности пользователей, и для их выполнения необходимо обладать правами администратора.
Более подробное описание и рекомендации по использованию этих команд можно найти в документации по Microsoft SQL Server.
При работе 1С:Предприятия 8 в режиме клиент-сервер широко используются временные таблицы. Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, UNION, DISTINCT и т.п. Эта служебная БД весьма нагружена и её ускорение сулит нам серьезный выигрыш в производительности. Давайте же поместим её в RAM.
Для начала посмотрим на метрики, какой же прирост производительности может быть получен от использования RAM-диска.
Безусловно, данный тест является синтетическим и не отражает реальный профит(который будет ниже), но разница в цифрах является весьма показательной.
При использовании RAM-диска у нас всегда будет возникать одна проблема - что будет, если размер tempDB выйдет за пределы RAM-диска?
Эта проблема решается весьма просто - MSSQL позволяет создавать дополнительные файлы данных и логов, в том числе для tempDB.
Таким образом общие рекомендации сводятся к следующему:
Первый файл данных tempDB - на RAM-диске, фиксированного размера (я ставлю 75%) от размера RAM-диске. Отключен autogrowth.
Первый файл логов tempDB - на RAM-диске, фиксированного размера (я ставлю 25%) от размера RAM-диске. Отключен autogrowth.
Второй файл данных tempDB - на обычном диске, начальный размер 8 Mb. Включен autogrowth.
Второй файл логов tempDB - на обычном диске, начальный размер 8 Mb. Включен autogrowth.
Таким образом, при росте размера tempDB и выходе его "из берегов" RAM-диска он просто расширится на медленные диски.
Чтобы сжать дополнительные файлы БД, если tempDB выросла в их размеры, настраивается простенький план обслуживания на ночь:
P.S. Лишь внедрением RAM TempDB мы смогли ускорить закрытие месяца в ERP в два раза.
Специальные предложения
Эх! А я-то думал, что в статье будет описано, как именно сделать на сервере RAM-диск.
Какой понадёжнее, какой подешевле и т.п.
(5) Да не. Разобраться с установкой там легко.
Просто пишу свой отзыв о статье.
Я рассчитывал на сравнительный анализ ПО для RAM-дисков, а статья оказалась о другом. :)
(8) а теперь 2 тыщи домашняя версия и чуть больше 3к - коммерческая. Для организации копейки, так-то.
(4) Интерес скорее вызывает не столько цена, сколько опыт эксплуатации.
У вас это на рабочей базе/базах?
И нормально работает?
Плюсанул за разнесение по файлам для решения проблемы переполнения.
Вроде банальная штука, но почему-то никогда в голову не приходила. Правда и вопрос этот всерьез не рассматривал.
(9) Хм. И за счет чего ожидается прирост, если файлики рядом лежат?
Да и выставлять степень параллелизма в единицу - тоже спорный совет. Это радикально замедляет формирование тяжелых отчетов.
ЗЫ. Почитал про разбиение tempdb - это скорее прикрытие возможного узкого места (при большом количестве конфликтов при мультипоточном доступе к файлу), чем кнопка "турбо". Т.е. может и не иметь никакого эффекта.
(15) Правильно ли я понял Ваш вопрос - за счёт чего возникает прирост производительности после перемещения tempDB в RAM. Верно?
(16) Нет. Вопрос касался разделения tempdb на несколько файлов на одном и том же диске. Вопрос был не к вам.
Но если знаете точный ответ - буду благодарен. И актуальна ли эта рекомендация для RAID 5 и выше.
(9) Конечно знаю. Но в данной ситуации рекомендация разбивать неприменима. Нужно ли объяснить, почему?
(9) Не правильно давать ссылку на "перепосты", а не на первоисточник.
Плохо, что для 1С-ников истина по SQL на сайте 1С, а не на MSDN ((((
MS SQL сам кэширует в памяти все что нужно без всяких RAM-дисков. Без тестов производительности статья ни о чем. Разбивать TempDB на несколько файлов - описано в настройках MS SQL от 1С, вероятно закрытие месяца от этого и ускорилось.
(12) Я не являюсь экспертом по SQL, но насколько мне известно есть куча настроек (хеширование, статистика), которые отвечают за скорость работы с данными, ХРАНЯЩИМИСЯ НЕПОСРЕДСТВЕННО в базе (файле MDF). Но эти настройки (ИМХО) не ускоряют работы с файлами TempDB, которые (источник этой информации указать не могу) не планировались в роли оперативного хранилище здоровенных массивов информации, как сейчас их использует платформа 1С.
MS SQL при построении плана запроса рассчитывает необходимое количество памяти и, если ошибается, то начинает задействовать tempdb. Это легко увидеть, если в профайлере получить планы запросов. Там, где стоит желтый восклицательный знак, там внутри как раз и пишет, что был задействован tempdb. Часто такое происходит на процедурах сортировки.
Было такое, как по изначальной статье, даже базы выносили, но потом все равно на ssd перешли.
Тем более в новых скулях есть настройки Buffer Pool Extension.
Как вы после перезагрузки сервера действуете или MSSQL в отложенном запуске?
Да, конечно от статьи ждал большего. Хотелось бы анализа причин, прироста производительности. Ну, простите меня, не ведующего, ну не могу я понять, почему если от SQL сервера откусить несколько десятков гигабайт памяти и сделать на них RAM-диск, то операции на этом сервере станут выполнять ЗАМЕТНО быстрее (и уж тем более в общем случае, а не как у автора - в частном случае закрытия месяца).
Ведь, насколько я знаю, все операции над temdb SQL сервер и так делает над таблицами (условно будем считать всё, что хранится в tembdb таблицами) с установленным внутренним приоритетом хранения в оперативной памяти (если её конечно достаточно)! То есть, временная таблица не будет выгружаться на диск, если для неё достаточно свободного места в оперативной памяти. Понятно, что если будут обрабатываться достаточно большие таблицы - они будут выгружаться на диск (при этом будет дублирование - часть данных наборов страниц будет в оперативном кеше и на диске). Но насколько же это будет в общем случае критично? Чтобы лишать SQL сервер гибко управлять всей своей свободной памятью, ради того, чтобы достаточно большая часть была всегда выделена под RAM диск с temdb - которая, скорее всего, в 90% не будет использована и на половину (а что будет использовано ещё и будет частично повторно кешировано в буфере SQL Server - неэффективно расходуя оперативную память на свои копии данных)! Так как SQL Server и всё-равно будет стараться держать временные таблицы в оставшейся у него оперативной памяти и выгружать их RMA-tempdb (причём выполняя объёмную пересылку данных между блоками памяти самым не производительным способом - через кучу посредников и между изолированными доменами приложений) в одну и в другую сторону только по мере необходимости (нехватки памяти, которая как раз и будет вызвана тем, что её попросту недодали SQL Server'у).
На мой взгляд RAM-диск для базы - это больше экстремальное экспериментирование, чем реальное предложение по ускорению! Вы вот так насоветуете админам - а они на своих серверах с 64Gb оперативной памяти, при базе(ах) объёмом боле 1Tb (с самой большой базой около 100Gb) и temdb, который у них при закрытии месяца пухнет свыше 100Gb возьму и выделять под RAM-tempdb минимум 16Gb (а кто-то и все 32Gb) и тем самым у них просядет обычная работа с данными рабочих баз на 25% (условно) в обычном режиме (а в пике ещё больше), а скорость работы с temdb (в часы макс нагрузки) увеличится ну максимум на 20% (и это в пике) - будет ли это реальной панацеей? Большой вопрос! Очень большой!
Тут в статье нужно было писать про исследования, которые должны были предварять такие вот серьёзные перераспределения ресурсов. Показывать где и как возникают узкие горлышки использования temdb. Обосновывать (с конкретными доводами тестов) когда и почему стоит отнимать буферную память от SQL сервера и отдавать её temdb.
И главное, в чём будет реальный экономический выигрыш - от того, что сервер будет требовать больше очень недешёвой серверной оперативной памяти, нежели - как альтернатива - просто разместить temdb на хорошем (тоже не дешёвом, но это пока с памятью не сравнить) серверном SSD диске - с высоким IOPS (лучше всего модели для PCI-ex, а не SAS/SATA; ну или хотя бы в слот M.2 - но это только на современных матерях) , и низким коэффициентом снижения производительности от числа полной перезаписи. Тут важна скорость - надёжность не так важна - это же не для хранения рабочей базы данных.
Вот тогда от статьи был бы толк.
Ну а если помещать в RAM tempdb - то я был начал только с лога temdb - который только пишется (и перезаписывается) в simple rec. mode, ему не требуется хранить большие объёмы дублирующихся данных. А данные временных таблиц - пусть SQL Server сам размещает в доступной ему буферной памяти, и выгружает на физ диск (лучше SSD), когда памяти уж совсем не хватает (а если это часто -то лучше 100 раз задуматься о том, чтобы её нарастить - ведь если её не хватает, от её перераспределения её больше не станет).
Вообще, прежде чем переходить на RAM - лучше сначала освоить перенос temdb на другой диск - если Ваш tempdb находится в том же RAID массиве что и диски рабочей базы - то задумайтесь сначала об этом, крайне негативном факторе - вынесите tempdb на отдельный RAID массив, да хотя бы просто на отдельный диск (два диска : данные и лог) и Вы сразу почувствуете прирост скорости, особенно в пиковой нагрузке! А уж если вы выберите для temdb PСI-ex SSD диски - то, наверняка, дальнейшее желание переносить их на RAM у Вас уже пропадёт!
akR00b; shaykhelov; Macter178; dabu-dabu; Tyler Durden; Brawler; szhukov; Starik; vvp117; GreenDragon; d4rkmesa; akim2040; Quantum777; alest; shtinalex; smallbuk; Dragonim; Rusmus; strrike; lohmatik; CSiER; mickey.1cx; nyam-nyam; mivari; kolya_tlt; MrWonder; AnderWonder; rintik; + 28 – 1 Ответить
Обсуждаемая в статье проблема актуальна для клиент-серверных баз, размещенных на СУБД MS SQL Server. Она связана с настройками размещения системной базы tempdb, которые получаются при установке SQL-сервера с параметрами «по умолчанию». Подобные проблемы вполне возможны при работе 1С с другими СУБД (у меня не было возможности это проверить).
Описание проблемы:
И так «задача» – положить SQL-сервер с помощью обычной консоли запросов 1С. И решается она достаточно просто и непринужденно. Достаточно выбрать в запросе декартовое произведение какой-нибудь большой таблицы саму на себя (так сказать взять «декартов квадрат») и уложить результат во временную таблицу.
Самый подходящий кандидат для этого – таблица регистра сведений «Адресный классификатор». Но подойдет и любая другая, достаточно большая таблица. Если размер таблицы будет недостаточным, можно вместо «квадрата» выбрать «куб» или более высокую «декартову степень» таблицы.
И так проведем эксперимент:
Для его проведения нужно выполнить следующие «системные» требования:
- Стандартно-установленный MS SQL Server (все равно, какой версии, на 2005-том сервере это проявляется);
- Сервер 1С:Предприятие (все равно какой, на той же машине или нет – не важно);
- Так же для «фокуса» нужно, что бы на системном разделе SQL-сервера было не слишком много свободного места (30-40 гигабайт, но не сотни). Как правило, так часто и бывает. Чем больше свободного места, тем труднее будет получить «результат». Причем труднее не в смысле, что этого трудно добиться, а в смысле, что этого придется дольше ждать;
Убедившись, что указанные выше требования удовлетворены, выполним следующую последовательность действий:
- Создадим клиент-серверную информационную базу;
- Загрузим туда выгрузку демонстрационной базы какой-нибудь типовой конфигурации (какой – сильно не важно);
- Заполним адресный классификатор с диска ИТС, выбрав все регионы (примерно 112000 записей);
- И наберем в обработке «Консоль запросов» следующий запрос
ВЫБРАТЬ
ДекартовКвадрат.КодРегионаВКоде КАК КодРегионаВКоде ,
ДекартовКвадрат.Код КАК Код ,
ДекартовКвадрат.ТипАдресногоЭлемента КАК ТипАдресногоЭлемента ,
ДекартовКвадрат.КодРайонаВКоде КАК КодРайонаВКоде ,
ДекартовКвадрат.КодГородаВКоде КАК КодГородаВКоде ,
ДекартовКвадрат.КодНаселенногоПунктаВКоде КАК КодНаселенногоПунктаВКоде ,
ДекартовКвадрат.КодУлицыВКоде КАК КодУлицыВКоде ,
ДекартовКвадрат.Наименование ,
ДекартовКвадрат.Сокращение ,
ДекартовКвадрат.Индекс ,
ДекартовКвадрат.АльтернативныеНазвания ,
ДекартовКвадрат.КодРегионаВКоде1 КАК КодРегионаВКоде1 ,
ДекартовКвадрат.Код1 КАК Код1 ,
ДекартовКвадрат.ТипАдресногоЭлемента1 КАК ТипАдресногоЭлемента1 ,
ДекартовКвадрат.КодРайонаВКоде1 КАК КодРайонаВКоде1 ,
ДекартовКвадрат.КодГородаВКоде1 КАК КодГородаВКоде1 ,
ДекартовКвадрат.КодНаселенногоПунктаВКоде1 КАК КодНаселенногоПунктаВКоде1 ,
ДекартовКвадрат.КодУлицыВКоде1 КАК КодУлицыВКоде1 ,
ДекартовКвадрат.Наименование1 ,
ДекартовКвадрат.Сокращение1 ,
ДекартовКвадрат.Индекс1 ,
ДекартовКвадрат.АльтернативныеНазвания1
ПОМЕСТИТЬ тзДекартовКвадрат
ИЗ
(ВЫБРАТЬ
АдресныйКлассификатор.КодРегионаВКоде КАК КодРегионаВКоде ,
АдресныйКлассификатор.Код КАК Код ,
АдресныйКлассификатор.ТипАдресногоЭлемента КАК ТипАдресногоЭлемента ,
АдресныйКлассификатор.КодРайонаВКоде КАК КодРайонаВКоде ,
АдресныйКлассификатор.КодГородаВКоде КАК КодГородаВКоде ,
АдресныйКлассификатор.КодНаселенногоПунктаВКоде КАК КодНаселенногоПунктаВКоде ,
АдресныйКлассификатор.КодУлицыВКоде КАК КодУлицыВКоде ,
АдресныйКлассификатор.Наименование КАК Наименование ,
АдресныйКлассификатор.Сокращение КАК Сокращение ,
АдресныйКлассификатор.Индекс КАК Индекс ,
АдресныйКлассификатор.АльтернативныеНазвания КАК АльтернативныеНазвания ,
АдресныйКлассификатор1.КодРегионаВКоде КАК КодРегионаВКоде1 ,
АдресныйКлассификатор1.Код КАК Код1 ,
АдресныйКлассификатор1.ТипАдресногоЭлемента КАК ТипАдресногоЭлемента1 ,
АдресныйКлассификатор1.КодРайонаВКоде КАК КодРайонаВКоде1 ,
АдресныйКлассификатор1.КодГородаВКоде КАК КодГородаВКоде1 ,
АдресныйКлассификатор1.КодНаселенногоПунктаВКоде КАК КодНаселенногоПунктаВКоде1 ,
АдресныйКлассификатор1.КодУлицыВКоде КАК КодУлицыВКоде1 ,
АдресныйКлассификатор1.Наименование КАК Наименование1 ,
АдресныйКлассификатор1.Сокращение КАК Сокращение1 ,
АдресныйКлассификатор1.Индекс КАК Индекс1 ,
АдресныйКлассификатор1.АльтернативныеНазвания КАК АльтернативныеНазвания1
ИЗ
РегистрСведений.АдресныйКлассификатор КАК АдресныйКлассификатор ,
РегистрСведений.АдресныйКлассификатор КАК АдресныйКлассификатор1 ) КАК ДекартовКвадрат
ИНДЕКСИРОВАТЬ ПО
КодРегионаВКоде ,
Код ,
ТипАдресногоЭлемента ,
КодРайонаВКоде ,
КодГородаВКоде ,
КодНаселенногоПунктаВКоде ,
КодУлицыВКоде ,
КодРегионаВКоде1 ,
Код1 ,
ТипАдресногоЭлемента1 ,
КодРайонаВКоде1 ,
КодГородаВКоде1 ,
КодНаселенногоПунктаВКоде1 ,
КодУлицыВКоде1
Результаты и "последствия" эксперимента:
После нажатия на кнопку «Выполнить» нам придется запастись терпением. Для файловой базы все закончится довольно быстро и не очень интересно – клиент 1С «подавится» памятью и «лопнет» без глобальных последствий.
Для клиент-серверной базы все будет несколько иначе. Через достаточно большое время операционная система на сервере начнет жаловаться, что «не достаточно места на диске», а возмущенные пользователи (если сервер вдруг окажется рабочим) – начнут звонить и спрашивать: «почему тормозит и вылетает 1С».
Еще более серьезными будут последствия, если сервер является «трехголовым Змеем-Горынычем», в одном лице – SQL сервер, сервер 1С и терминальный сервер. Тогда произойдет «полный коллапс».
В такой ситуации приходится срочно предпринимать чрезвычайные меры: срочно что-то освобождать на системном разделе, а также перезапускать SQL сервер (чтобы усечь базу tempdb) и сервер 1С:Предприятия (на всякий случай).
Причины проблемы:
Причиной описанных выше бед является то, что при установке MS SQL Server «по умолчанию» системная база tempdb целиком размещается на системном разделе и при этом не ограничивается рост ее размера. Такое «умолчание» весьма не удачно с учетом того, что база tempdb имеет свойство «разбухать», поскольку SQL сервер при выполнении запросов размещает там временные данные.
При показанных выше настройках, база tempdb может легко «съесть» все свободное дисковое пространство на системном разделе сервера и поставить тем самым операционную систему р… в неработоспособное состояние.
Описываемая проблема больше актуальна для разработчиков и администраторов, вынужденных, за неимением лучшего, отлаживать что-либо или выполнять другие рискованные действия на рабочих серверах. Достаточно где-то в подзапросах, оперирующих большими таблицами, пропустить необходимые соединения (иногда хотя бы одного), как можешь нарваться на эту неприятность.
Лично на моем опыте такой «фокус» удавался два-три раза. После чего мы решили что-то с этим сделать. Так какие можно предпринять меры, чтобы избежать описанных выше неприятностей?
Варианты решения проблемы:
Окончательного (раз и навсегда!) решения этой проблемы, конечно, нет. Но есть способы сделать такой сценарий развития событий менее вероятным:
А) Можно расширить системный раздел сервера. Не всегда это можно сделать (тем более «на горячую»). И это не панацея – у меня в ходе эксперимента на тестовом сервере (не самом хилом, но не самом крутом) свободное пространство размером 80 гигабайт съелось где-то за 40 минут. И к тому же сейчас много свободного места, а завтра его может стать не так много.
Б) Можно еще установить SQL сервер не на системный раздел. Но говорят, это не слишком оптимально по производительности. Есть и другой веский довод «против» - не переустанавливать же «боевой сервак»!
В) Можно переместить файлы базы tempdb с помощью команды ALTER DATABASE (способ указан AKV77 в комментарии (5) ):
-
Для этого нужно в Query Analyzer выполнить следующую команду:
Для того чтобы указанные выше изменения настроек базы tempdb вступили в силу потребуется перезапусть SQL сервер.
Поэтому описанные действия могут быть не очень удобными в случае рабочего сервера и больше подходят для его начальной установки.
Г) Еще один вариант решения проблемы (пожалуй, самый взвешенный, его можно сделать без перезапуска сервера) - это оптимизация размещения системной базы tempdb без ее физического перемещения с системного раздела на другие диски:
-
Сначала обязательно необходимо ограничить в росте ту часть базы, которая размещается на системном разделе. Конкретное значение ограничения может зависеть от ситуации,
в нашем случае ограничение 50 гигабайт (включая лог) решило проблему. Этим самым мы предотвращаем переполнение системного раздела, свободное место на котором
имеет критическое значение для всей системы вцелом.
После проведения такой оптимизации размещения базы tempdb мне уже ни разу не удавалось «завалить» сервер описанным образом. В худшем случае возникали не требующие чрезвычайных мер «тормоза», которые решались личным «харакири» через консоль кластеров серверов 1С.
Системная база данных tempdb активно используется базами данных 1С:Предприятие 8.3 для хранения временных таблиц, промежуточных расчетов, версий строк при использовании режима версионирования и прочих временных данных. То есть для задач 1С:Предприятие интенсивность обращений к базе tempdb находится на высоком уровне, поэтому нужно подумать о размещении этой базы на выделенном быстром дисковом устройстве.Подходящими кандидатами на роль диска под tempdb будут выделенные быстрые дисковые RAID-группы уровня RAID1, выделенные накопители SSD или вообще RAM-диск.
В большинстве сценариев рекомендуется разбивать базу tempdb на несколько файлов данных с одинаковом начальным размером (Initial size) от 1GB и больше и увеличенным показателем прироста, например, в 512MB.
При определении количества файлов можно руководствоваться принципом: количество процессорных ядер = количество файлов данных tempdb, но при этом стоит помнить о том, что использование более 8 файлов (даже при количестве ядер более 8) далеко не всегда может иметь положительный эффект. Возможно по этой причине в инсталляторе SQL Server 2016 даже при большом количестве процессорных ядер по умолчанию предлагается 8 файлов tempdb.
Относительно 1С:Предприятие 8.3 можно встретить рекомендацию о том, что общий размер Initial size для всех файлов БД tempdb должен быть от 25% до 40% от размера рабочей БД 1С:Предприятие.
Саму процедуру переноса файлов tempdb на другой диск мы рассматривали ранее в заметке SQL Server 2008 - Перенос файлов БД tempdb на отдельный диск. Эта процедура может использоваться и на новых версиях СУБД, вплоть до SQL Server 2016.
Рассмотрим частный пример распределения файлов tempdb по разным дисковым томам, имеющим разные показатели производительности. В нашем примере имеется два тома NTFS:
Часть файлов данных в файловой группе tempdb, а также файл лога размещены на быстром диске. Файлы данных, расположенные на быстром диске установлены фиксированного размера без возможности авторасширения (исключением здесь является только файл лога). Другая часть файлов данных размещена на менее производительном дисковом томе, но при этом для файлов включено авторасширение.
В результате такой конфигурации, файлы tempdb в нашем случае будут распределены по дисковым томам следующим образом: 4 файла данных и лог tempdb окажутся на быстром томе T:
Другие 4 файла данных tempdb окажутся на менее производительном дисковом томе R:
В случае если в ходе работы экземпляра SQL Server потребуется дополнительное расширение ёмкости tempdb, то файлы начнут прирастать на меньшем по производительности, но большем по объёму дисковом томе R.
К операциям, которые могут вызвать бурный рост tempdb при работе БД 1С:Предприятие 8.3 можно отнести, например, регламентные процедуры с конфигурацией 1С, выполняемые из конфигуратора (обновление конфигурации, перерасчёт итогов и т.п.). Кроме того, активный рост tempdb может вызвать построение в 1С каких-то тяжёлых отчётов с большим количеством данных и за длительные периоды при условии, что код отчётов неоптимален или вообще содержит ошибки. В практической среде при размере БД около 170GB во время построения подобного отчёта мы наблюдали рост tempdb до 350GB. Учитывая эти моменты стоит подумать о полной изоляции файлов tempdb на выделенных дисковых томах, чтобы их возможный бурный рост не смог нарушить функционирования других БД SQL Server.
Используемый в нашем примере дисковый том T: представляет собой RAM-диск, подключенный к серверу SQL Server по методике, описанной в отдельной статье нашего Блога : Организуем RAM-диск для кластера Windows Server с помощью Linux-IO FC Target
Читайте также: