Как правильно развернуть связку MS SQL + 1С-сервер версии 8.х

[STALKER_SLX]

Добро времени суток, уважаемые форумчане!
Сразу скажу, что я только-только пытаюсь разбираться в администрировании 1С серверов, поэтому прошу Вас сильно меня не пинать...
В продолжении раннее начатой мной темы на данном форуме https://interface31.ru/forum/index.php?topic=286.0

Есть 2-е ВМ-ки на ESXi 6.7 со свежеустановленным «Windows Server 2019 Standart». На одной из них поднят сервер терминалов, а на второй нужно развернуть 1С сервер + MS SQL.

В связи с чем вопросы.
1. Какую версию MS SQL нужно развернуть, чтобы получить оптимальную производительность 1С-сервера версии 8.х (более точную версию узнаю и сразу же отпишусь)?!
2. Какие дополнительные настройки (тюнинг) нужно будет осуществить как для MS SQL, так и для самого 1С-сервера версии 8.х с базой более 130Гб ?!

P.S.: Ваши замечательные материалы видел, но насколько они актуальны сейчас?!
https://interface31.ru/tech_it/2014/01/ustanovka-i-nastroyka-ms-sql-server-dlya-1spredpriyatie.html

https://interface31.ru/tech_it/2012/01/server-1s-predpriyatie-chast-1---obshie-voprosy.html

https://interface31.ru/tech_it/2012/02/server-1s-predpriyatiya-chast-2-ustanovka-na-platforme-windows.html

https://interface31.ru/tech_it/2013/11/uskoryaem-1spredpriyatie-8-pri-pomoshhi-ssd.html

[Уваров А.С.]

Практически все изложенное в материалах актуально, ничего принципиально нового 1С не придумала. Разницы между актуальными версиями MS SQL мы также не замечали.

Какие дополнительные настройки (тюнинг) нужно будет осуществить как для MS SQL, так и для самого 1С-сервера версии 8.х с базой более 130Гб ?!

130 ГБ - это размер чего? В MS SQL львиную долю размера базы может составлять лог транзакций, который при полной модели и без грамотно настроенного резервного копирования будет постоянно и беспредельно расти.

Также следует еще ознакомиться с этим: https://interface31.ru/tech_it/2019/09/nastroyki-servera-1spredpriyatie-8-po-umolchaniyu-dlya-raboty-s-licenziyami-urovnya-prof.html

И еще вопрос - какую именно конфигурацию вы разворачиваете?

[ival]

Странно у меня сафари ужасно стал статьи открывать, не одна статья из ссылки у меня так полностью и не прогрузилась. Но я не думаю что Уваров что-то плохого там насоветовал=)) Настройки sql будут актуальны до тех пор пока не поменяют архитектуру либо sql либо 1с.
Вы так и не решились разделить сервер 1с и ms sql, что я все-таки настоятельно советую.

1. Выбирать нужно из того какой куплен или если не куплен то покупать последний. В данном контексте разницы между 2008 и вы вы не увидите.

2. И настроек для начала вам нужно ограничить памятью ms sql из расчета чтоб осталось на ось и на 1с. Из того что я видел на 40 человек 1с нужно 8 гигов, больше я не замечал чтобы rphost начинал поедать. Плюс системе для комфорта отдать гигов 6, все остальное отдать sql. По дискам (только для баз), размер блока 64к с выравниванием бы не заморачивался, т.к. уже в прошлой теме решили что 1с не особо славиться производительностью, хотя по науке выравнивание все-таки нужно. Ещё сразу решить вопрос с файлом mdf и ldf. Я лично считаю что его лучше сразу делать с запасом. Размер базы*на 1,5 и увеличение ставить на фиксированную величину чтобы sql не торобанил потом по дискам постоянно расширяя mdf. Опять же вы так и не сказали 130 гб это mdf или mdf + ldf? Если mdf 130 то изначально я бы создал новый mdf на 200 гб и увеличение сделал на 10 гб. По ldf посмотрел бы его размер и увиличывал бы его пропорционально, но также на фиксированный размер. В принципе для начала этого должно хватить и потом уже начать смотреть производительность уже на продакшене. Вопрос по РК тоже продумайте. Если как вы писали 30-40 человек то это 100% полная модель: что-то из серии ночной полный, 3 дифа в сутки и логи каждые 30 минут, как-то так. Так-же не забывайте про периодический shrink ldf файла, но автоматически не совету его делать, лучше запускать самостоятельно, чтобы не попасть на момент когда будет делаться бекап журнала и система решит запустить сжатие ldf. Ну и не забудь те про полноценное обслуживание базы, Уваров писал где-то статью здесь, поищите.

[Уваров А.С.]

Писал не я, а один из наших читателей: https://interface31.ru/tech_it/2012/02/obsluzhivanie-baz-1s-v-ms-sql-server-chast-1.html

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

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

А так, настраивать там особо нечего, в ПРОФ лицензиях недавно забрали все более-менее значащие настройки сервера, осталось одно баловство. В MS SQL тоже особо крутить нечего, так как 1С работает с базой по собственному алгоритму, очень часто совсем неоптимальному.

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

[ival]

Не доумение может вызывать только частое перестроение индекса. Опять же вопрос спорный. Зависит от размера блока и фрагментации самой базы. Опять же, я предполагаю что 1с базу сильно врагментирует, хотя могу ошибаться, в принципе можно попробовать на работе выключить перестроение индексов и посмотреть уровень месячной фрагментации, но опять надо понять какой процент не поддаётся перестроению. Вопрос наверное к Вам (Уваров), как к человеку который работает с 1с вы должны знать какая из табиц подвержена больше всего фрагментации, от неё можно и плясать. А в целом когда человек не знает про фрагментацию базы такой план(как в статье) идеален. Соединение в один план РК и обслуживание конечно не лучший вариант. Но в целом если ты не смотришь во внутренности и нюансы базы то такой план рабочий. А про ошибки цепочки плана, можно играться с условиями. Из опыта базу из-за перестроения я ни разу не терял. Ну а с растущим ldf из-за перестроения механизм борьбы всем известен. Хотя 130 гб перестраивать каждый день я бы не стал за неделю ldf улетит наверное в 500 гб при среднег фрагментации.

[Уваров А.С.]

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

Так самый обычный документ может делать движения сразу в массе регистров, чтобы удовлетворять требованиям управленческого, бухгалтерского и налогового учета. Плюс отдельно учитывается НДС, доходы и расходы на спецрежимах, движения ЕГАИС и прочих систем контроля и маркировки. В общем даже довольно простое с виду действие, такое как покупка пачки бумаги для собственных нужд породит в базе достаточно большое количество движений.

И снова про 130 ГБ, что-то я сомневаюсь, что это реальный размер базы 1С, скорее это общий размер базы SQL вместе с журналом. Потому что такой объем самой базы - это очень и очень крупное предприятие.