Развернуть базу 1с на mysql

Обновлено: 07.07.2024

Похожих статей достаточно много, но эту я в первую очередь писал для себя, останавливаясь на примечаниях, в которых описаны возможные проблемы. Надеюсь статья будет полезна и другим.
1. Устанавливаем 1С платформу
2. Устанавливаем MS SQL server 2008. При установке задаем пользователя баз данных. (Который SA).

После установки открываем панель администрирования серверов 1С предприятия и видим что она пуста.
Нужно создать сервер: Открываем console root->Central 1C: Enterprise 8.2 servers. Кликаем по нему правой кнопкой мыши и выбираем пункт new. В выпадающем меню выбираем Центральный сервер 1С Предприятия 8.2. Перед нами откроется окошко с 4-мя полями:
Протокол — протокол по которомы будут передаваться данные
Имя — имя компьютера в сети на котором располагается сервер
IP порт- порт по которому доступен сервер
Описание-описание. не обязательно.

Примечание:
Если платформа 1С была установлена на компьютер, и потом компьютер был переименован, то достучаться до него вы не сможете, потому что платформа 1С шибко умная платфома и записывает в определенные файлики при установке имя компьютера, но потом, когда имя компьютера менятся платформа их уже не перепишет. Эти файлики нужны для работы сервиса RAGENT 1С (его можно найти в запущеных службах, через панель администрирования сервера windows). Это все говорит о том, что чтобы переименовать эти файлы-необходимо остановить службу RAGENT. Сами файлы находятся в следующих местах:
C:\Program Files (x86)\1cv82\srvinfo\srvribrg
C:\Program Files (x86)\1cv82\srvinfo\reg_1541\1CV8Reg
Открываем эти файлии блокнотом и правим прошлое имя машины на настоящее ручками. Сохраняем и запускаем RAGENT.

Возвращаемся к настройке:
После того как заполнено окно с полями нажимаем кнопку OK и если все сделано верно то у нас появляется сервер по имени машины, на которй он стоит.

И так. Сервер запущен и теперь нам нужно создать базу на MYSQL server и связать ее с севером 1C. Есть несколько способов-здесь я опишу самый простой:
На сервере 1С предприятия открываем наш новый созданный сервер кликом по + рядом с названием сервера и на пункте «ИНФОРМАЦИОННЫЕ БАЗЫ» кликаем правой кнопочкой мыши, выбираем New->Информационная база
Перед нами откроется окно в котором будут следующие поля:

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

Нажимаем ОК и видим что серверы настроены и у нас в закладке «Информационные базы» появилась информационная база под именем которое мы ей дали.

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

Чтобы нстроить Backup нам нужно открыть Microsoft SQL MANAGEMENT STUDIO.
Вводим логин и подключаемся к серверу.
Перед нами административная консоль. В Object explorer открываем вкладку Management и в ней видим Maintance plans. Здесь будем создавать нужный нам BackUP. Как обычно правый клик по Maintance plans->new maintance plan. В главном окне появится вкладка subplan, а под Object Explorer появится еще одно окошечко ToolBox в котором вложен Maintance Plans Tasks. В ней мы выберем Back Up DataBase Task кликнув по нему 2 раза. Он перенесется на главное окно. На нем кликаем 2 раза и перед нами появляется окно опять же с полями, где мы можем выбрать какой Back Up делать, какую базу BackUp-ить, и куда это сохранять. По окончании настроек нужно нажать Ok.

Примечание:
Сохраняя Back Up в какую либо сетевую папку (путь кстати придется прописать ручками, потому, что оконко выбора директории видит только локальные рессурсы) проследите за правами доступа, и заодно проследите какая у вас аутентификация на сервере MySql потому что если аутентификация выставлена не по учетным записям Windows, а по внутреннему пользователю СУБД и если при этом у вас поднят сервер AD то BackUp будет выдавать ошибку при попытке исполнения, поскольку будет это делать от имени внутреннего пользователя СУБД и AD его не пропустит никуда кроме локального компьютера.

После того как вы настроили путь, базу и тип BackUp нужно настроить расписание. Для этого в главном окошке над созданным вами Task есть табличка SubPlan. В конце таблички (справа) есть иконка календаря. Кликнув на нее вы попадете в настройку расписания. Отмечая чекбоксы дней и выставляя время вы настроите расписание. Кликнув 2 раза на поле под названием SubPlan вы сможете изменить название Task-a. Настроив все пройдите в File->Save All. После сохранения в Maintance plans появится Task c вашим названием который вы дали BackUp-у.

По окончании настройки нужно обязательно проверить Работу. Для этого Правой клавишей мыши кликните на созданном Task и выполние Exicute.

Примечание:
Если Exicute выполняется с ошибкой читайте ошибки которые вам выдаст Studio, и первым делом проверьте запуще ли у вас SQL server agent. Это он занимается выполнением заданий и функция Exicute обращается именно к нему за выполнением заданий. Если он не запущен попытка выполнения потерпит неудачу. Дял того чтобы посмотреть работатет ди агент или нет в Studio в Object Explorer пройдите во вкладку SQL Server Agent . Если на иконке булет красный кружок с крестиком- значит агент остановлен. ЗАпустить его можно кликнув на нем правой кнопкой мыши и выбрав к контекстном меню опцию START.

DB2 и PostgreSQL бесплатные, но маленькое уточнение.
DB2 бесплатный - это "кастрированная" версия аналог MS SQL express.
и работает только с одной БД.
Т.е. на каждую БД нужно ставить отдельную инстанцию DB2.

Лучший выбор PostgreSQL. Использую уже более 5 лет доволен как "Слон" :)
Не зря наверное логотип PostgreSQL - Слон.

(8) bzmax,
Вы не совсем правы. у DB2 Express ограничений только 2:
1) один инстанс использует не более 4 Гб памяти;
2) один инстанс использует не более 2 ядер.
При этом в системе может быть несколько инстансов.
В каждом инстансе может быть несколько баз.

По сравнению с ПГ ДБ2 транзакционник. Поэтому для решения проблем блокировок на ПГ придется переписывать конфигурацию на управляемые блокировки.
обе СУБД требуют тонкой настройки параметров и понимания принципов работы в отличии от МС где все работает "из коробки".
Вообщем есть нюансы, что умеете, то и ставьте. На небольших базах бесплатный ДБ2 не уступает ПГ.

(31) GreyJoJo,
И Да и Нет.
То что вы описали - это действительно касается DB2 Express.
Но 4 Гига может использовать только 10-ый Express.

1C на момент написания одобрен пока что только 9.7 релиз. (2Г оперативки)
Да и само 1С категорически рекомендует на один инстанс только одну(!) БД запускать.

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

(33) bzmax,
Насчет рекомендаций 1С одна база один инстанс - не слышал такого, буду благодарен если поделитесь ссылкой.

Согласен, в плане бесплатности и отсутствия ограничений ПГ лидер. Но он требует даже для автоматизации на 3 р.м. тонкой настройки конфигов. МС такого не требует.

При небольшом внедрении на 10-15 р.м. вполне достаточно ограничений ДБ2. При этом УТ 10.3 не на управляемых блокировках. ДБ2 не требует их внедрения. ПГ - обязательно.

на внедрениях до 50 р.м. (50 р.м. неплохой такой ларек :) ) МС СКЛ работает прекрасно и из коробки (требуется только настройка регламенов через мастер за 15 минут).

Так что не все так однозначно. В каждом случае надо смотреть и выбирать оптимальное решение.

Для тех кто мучается выбором могу дать 3 простых совета:
1) Если есть возможность купить МС (хотя бы воркгруп) - берите.
2) Если надо дешево/бесплатно в первую очередь смотрите на то с чем умеете работать или есть человек который сможет помочь.
3) Считайте не просто стоимость лицензии а совокупную стоимость владения. Она далеко не всегда сама низкая у бесплатных продуктов.

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

Сами отчеты бывают разные. От простых оборотно-сальдовых ведомостей по счету, до замудренных отчетов с анализом данных за предыдущие года, при этом с применением различных формул и параметров расчета.

Не удивительно, что в периоды отчетности или закрытия месяца многие компании сталкиваются с замедлением работы своих систем на базе 1С или НЕ 1С. Ведь один тяжелый отчет при формировании может "съесть" больше ресурсов, чем работа всей системы за неделю и даже больше.

В мире энтерпрайза за пределами экосистемы 1С принято разделять базы на две категории:

Операционные (OLTP), где ведется основная работа бизнеса. Работа этих систем критична для бизнеса, а остановка в случае нештатных ситуаций может стоить компании значительных средств.
Отчетные (OLAP), предназначены для сбора различных видов отчетов. За счет изолирования от операционной базы, формирование тяжелой аналитической отчетности не повлияет на производительность и стабильность ее работы. Обычно остановка этих баз не так сильно отзывается на работе компании.

Создать отдельную базу для отчетов можно несколькими путями:

Сделать копию операционной базы данных.
Организовать хранилище данных.

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

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

Внимание!!

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

Ах да, все примеры для клиент-серверных баз в контексте работы со SQL Server. Что-то будет актуально и для PostgreSQL.

Классический подход

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

Формирование и последующее разворачивание бэкапа делается через SQL Server Managment Studio в несколько простых шагов.

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

Сделать бэкап можно через удобный интерфейс с помощью SQL Managment Studio (SSMS), который также поставляется с некоторыми дистрибутивами SQL Server в комплекте, но можно использовать и последнюю версию с сайта Microsoft.

Для этого нужно иметь соответствующие права доступа на инстансе SQL Server, зайти в SSMS и перейти к настройкам резервного копирования.

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

Далее запускам и ждем завершения операции создания резервной копии.

Когда увидим заветное окно о завершении, то можно говорить о грандиозном успехе! Все получилось!

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

С помощью SQL Managment Studio (SSMS) также развернем копию базы. Для этого перейдем к разделу "Базы данных" в SQL Managment Studio (SSMS).

Далее укажем основные параметры: путь к файлу резервной копии и имя базы данных. Если база данных уже существует и ее нужно полностью обновить, то на вкладке "Параметры" установите "Перезаписать существующую базу данных (WITH REPLACE)".

Ожидаем процесс восстановления базы.

Отлично, копия базы готова!

Вот и все! У нас есть актуальная (пока что!) база, для которой можно создать новую информационную базу на сервере 1С и использовать изолированно от рабочего окружения.

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

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

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

Просто, эффективно, но медленно!

Скриптуем все!

Но что, если нужно обновлять отчетную базу чаще? Например, раз в сутки?

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

Например, так мы сформируем бэкап.

А потом обновим отчетную базу.

Чтобы этот процесс выполнялся автоматически раз в сутки создадим задание на SQL Server.

Просто добавим задание, которое автоматически будет создавать резервную копию и разворачивать вне рабочее время.

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

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

Не подходит для формирования оперативных отчетов.
Не подходит для формирования отчетности по прошлым периодам, если там интенсивно выполняется корректировка данных. Ну никто же так не делает! :)

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

Реплицируем через репликацию

Другой способ - это репликация стандартными средствами SQL Server. На самом деле, это не самый подходящий вариант передачи изменений баз 1С в их копию, потому что для его эффективной работы необходимо было бы добавить первичные ключи во все таблицы. Платформа 1С этого не делает. Конечно, можно было бы добавить ключи самостоятельно и, о боже, поддерживать при реструктуризации. Но, даже это бы не помогло, потому что для некоторых таблиц ключ просто невозможно добавить. Например, для таблицы "DBSchema", в которой только одно поле с типом "varbinary(max)".

Вообще, есть несколько основных видов репликации:

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

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

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

Добавляем первичные ключи во все таблицы где есть кластерный индекс.
После добавляем ключи в таблицы "кучи", если это возможно.
Для таблиц, где первичный ключ добавить нельзя (например, та же таблица "DBSchema") добавляем свое числовое поле "ID" с автоинкрементом, которое и будет первичным ключом. Платформа 1С ничего об этом поле знать не будет.

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

И так, что имеем.

Быстрая синхронизация при использовании репликации транзакций.
Отлаженные механизмы обмена как для хороших каналов связи, так и с низким качеством соединения.

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

Таким образом, это для лютых извращенцев, которые не ищут легких путей! :)

Копия в реальном времени

И последний способ создания копии базы для отчетов - это использование групп высокой доступности AlwaysOn. Это очень мощная технология, которая позволяет создавать копию базы данных практически в реальном времени. С ее помощью можно настроить репликацию данных базы на другой инстанс SQL Server, при этом вторая база данных будет только для чтения.

Репликация при AlwaysOn может быть двух типов:

Синхронная - когда транзакция фиксируется сразу же на двух узлах базы данных.
Асинхронная - когда транзакции фиксируются на основной реплике и изменения асинхронно передаются на второй узел с некоторой задержкой.

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

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

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

SQL Server 2012 и выше редакции Enterprise Edition. Также функционал доступен для Standard Edition, но с ограничениями:
- Максимум 2 реплики (первичная и вторичная)
- Нет доступа на чтение для второй реплики
- Только одна база в каждой группе доступности.
Таким образом, нужен квалифицированный администратор, лицензии на Windows Server и SQL Server редакции Enterprise. Цена может подходить не для всех. Процесс настройки рассматривать в статье не будем, но ознакомиться с самой простой конфигурацией по шагам Вы можете по следующим ссылкам:

Сейчас же остановимся на некоторых особенностях работы баз 1С с репликами AlwaysOn. Допустим, у нас сделана настройка асинхронной реплики. База данных на втором узле практически всегда находится в актуальном состоянии. Но находится она в режиме только для чтения! Мы развернули отдельный сервер 1С, добавили эту базу и попытались зайти в нее в режиме 1С:Предприятие. Первое, что мы увидим будет.

Платформа 1С не поддерживает работу с базой в режиме "Только для чтения", т.к. пытается сохранять различные настройки форм, отчетов, историю работы в служебные таблицы. В этом случае есть несколько решений:

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

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

Мысли напоследок

Вы дочитали до конца и задались вопросом: "Почему не использовать стандартные возможности платформы?". Например, создать базу и наполнять ее через обмены или вообще сделать узел УРБД. Справедливый вопрос! Но и ответ простой - скорость и производительность!

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

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

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

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

Хорошим и дешевым был бы способ репликации транзакций, но из-за особенностей баз 1С его сложно применять.

Самым доступным и распространенным остается способ через бэкапирование и разворачивание резервных копий со всеми вытекающими недостатками и ограничениями.

У вас могут быть другие входящие, это не важно (сейчас).
Мы взяли Комплексную поставку УТП (в нее входит 10 клиентских лицензий, сервер (только 32 бит), и конфигурации ЗУП, УТ, Бухгалтерии, и сама УТП. Примечательно что франзайзи во всю хотели включить отдельные поставки, и лучше сразу КОРП. Анализ показал что это лишнее, и дешевле брать комплексную конфигурацию.
При подборе железа вам важно помнить, что в клиент-серверном варианте работе 1С нужно, чтобы частота работы процессора была максимальна, как и частота работы памяти (помните об этом, выбирая железо). (то есть Hyper трейдинг и всякие С1-2-3 state лучше отключить в BIOS).
Так же надо «физически» разносить файл базы (MDF) и лога (LDF) на отдельные жесткие, а не логические диски.
И если для файловой версии оптимально будет рекомендовать SSD, то тут, не все так очевидно.
Зайдите на форум Гилева, чтобы ознакомиться с «загадками», возникающими в попытке улучшить производительность 1С. Много интересного.
В моем случае коллеги админы выдели мне лезвие на блейд сервере, с 2мя физ.процессорами AMD Quad-Core Opteron(tm) Processor 2354, с 16 Гб (667 МГц). Система на 2 дисках в зеркале. Диски под базу выделялись по Fiber chanel, на HP EVA.
Сейчас ищу другую конфигурацию, но пока надо и на этом пожить.
И вот на этапе внедрения, пока ведется анализ как переносить данные из другой ERP системы, 1С программист обратил мое внимание на медленную работу, и долгое проведение документов. То есть систему еще не эксплуатируют, а она уже тормозит и помирает, а перепроведение раза в 3 медленнее, чем у человека на ноутбуке, а с этим еще и люди работать должны будут (3-4 основных, и 25-40 табельщиков).
Не порядок.
Он порекомендовал использовать тест Гилева (легко гуглится его сайт), у которого полного сервисов поддержки, и информации. Чем и воспользовался.
Тест показал что все плохо, и рекомендованное число пользователей отсутствует.
Посмотрев повнимательнее я понял что база и лог хоть на разных дисках — но логических.
И вот для исправления этого и сделал скриншоты и эту памятку на будущее себе и другим:

Создание базы данных в SQL server management studio. Базу и лог разносим на разные физические диски.

Методе восстановления выбираем Simple

Создаем новую базу через клиента 1С на компьютере

Выбираем добавление информационной базы. В нашем случае без конфигурации.

Задаем называние. Здесь любое. Лучше как на сервере.

Заполняем данные. Когда указывал на сервере, имя сервера указывал 127.0.0.1 — иное не работало.

здесь ничего не меняем

Делаем загрузку нашей информационной базы (предварительно имеющейся или новой, например теста)

Собственно выбор базы. Я загружаю тест Гилева для платформы 8.3

Подтверждаем

Подтверждаем
Имейте ввиду:
Запуская тест Гилева в тестовой базе, которая расположена в тех же местах хранения что и любая боевая — имейте ввиду, что как минимум Лог файл стремиться занять все свободное место, что чревато остановкой боевой базы и не прохождением теста.

Итог теста. Еще все плохо, но рекомендованное число пользователей больше требуемого, что хорошо.

Так же тестировал, используя логический раздел на зеркале основного диска в лезвие и раздела на СХД EVA.

Здесь Лог на логическом диске в зеркале на SAS 10K, а база на СХД EVA с SAS дисками 15K

А здесь База на логическом диске в зеркале на SAS 10K, а лог на СХД EVA с SAS дисками 15K

Промежуточный итог:
Разнесение Базы данных SQL по разным дискам очень важно!
В самом минимальном варианте Базу можно базировать на логическом диске основного физического диска с системой, а лог выносить на отдельный диск (в комментариях дали информацию, что лучше на SSD)
Лучшем вариантом разнесения базы и лога на отдельные физические диски.
Так же, как подметили в комментариях, имеет смысл вынести и TEMP базу самого SQL, так как 1С ее активно использует во время работы.

P.S. В процессе поиска правды система полностью клонировалась на один отдельный SSD (то есть диски с базой и логом были логические).
Не смотря на i7-4790 с 32 GB DDR3, производительность от обычного диска и работы на сервере лучше не становится.
Создание дисков на RAM диске так же показывало низкие результаты, не отличимые от работы на простых дисках.

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

Из дополнительного.
Если Вам захочется дать пользователям домена безнаказанно создавать любые БД средствами 1С, то учетной записи службы сервера 1С сделать доменную учетку, имеющую право создавать базы без всяких сисадминов вполне достаточно,
при этом логин и пароль в свойствах информационной базы писать не надо…

Читайте также:

Развернуть базу 1с на mysql

Классический подход

Скриптуем все!

Реплицируем через репликацию

Копия в реальном времени

Мысли напоследок