Настройка сервера 1с

Подробности
Категория: Другие статьи
Опубликовано 05.04.2013 15:27
Просмотров: 34823

Настройка работы сервера 1С с сервером SQL 2012 через shared memory (общую память) 

Исходные данные:

1. Windows Server 2012 Standart x64

2. Microsoft SQL Server 2012 x64

3. Сервер 1С 8.2.18.61 x64

Необходимо сделать работу сервера 1С с SQL сервером через общую память (shared memory) для достижения наилучших показателей работы 1С Предприятия.

Для работы через «общую память», необходима установка сервера 1С и SQL сервера на одном физическом сервере иначе ничего работать не будет!

Приступим…

1. Устанавливаем и настраиваем: Windows Server 2012, SQL Server 2012 и сервер 1С (как это сделать описывать не буду, в интернете полно информации).

2. Заходим в настройки SQL Server Configuration Manager и проверяем чтобы во всех вкладках был включен протокол «Общая память».

Также рекомендую отключить протокол «Именованные каналы». (Рис. 1)

Рисунок 1.

3. Перезапустите службу SQL или перезагрузите сервер.

4. Сделайте необходимые настройки сервера 1С (создайте необходимые базы, установите значение допустимого объема памяти и т.п.)

ВАЖНО! При создание базы данный указывайте в поле «Сервер базы данных: localhost» иначе будет использоваться протокол TCP/IP вместо shared memory (Рис. 2.)

Рисунок 2.

5. Для проверки работы сервера 1С и SQL сервера сделайте запрос:

SELECT net_transport, client_net_address, client_tcp_port, auth_scheme
FROM sys.dm_exec_connections

и Вы увидите какие протоколы используются. (Рис. 3.)

Рисунок 3.

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

Отличия файловой версии 1с от SQL

Я
   Uragan_a

 

27.01.12 — 05:19

Сложно ли устанавливать SQL, много ли подводных камней?

 
 
   Cube

 

1 — 27.01.12 — 05:23

(27) Первый «подводный камень» тебе обойдется в 32000 рублей. Это ключ на сервер.

   vladimir-boy

 

2 — 27.01.12 — 05:28

(0) В первый раз всё не так уж просто.

   asyr83

 

3 — 27.01.12 — 05:28

http://lmgtfy.com/?q=1с+отличия+файловой+версии+от+sql

   Андрюха

 

4 — 27.01.12 — 05:29

(0) Камней практически нет. Выгрузку в файловой, загрузку в SQL. Побалуйся на копии с начала.

   Uragan_a

 

5 — 27.01.12 — 05:34

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

   Uragan_a

 

6 — 27.01.12 — 05:35

я чет так и путаюсь с этими базами. Файловая она оперируеть данными на компьютере клиента? SQL все делает на сервере?

А как же тонкий и толстый клиент или это уже 8.2, а бухии 8.2 нет?

   Uragan_a

 

7 — 27.01.12 — 05:35

(4) то есть из семерки в файловую а из файловой в sql можно?)

   Андрюха

 

8 — 27.01.12 — 05:38

(7) В файловой версии в конфигураторе Администрирование -> Выгрузить данные. Потом создаешь базу в SQL и в ней Администрирование -> Загрузить данные.

   vladimir-boy

 

9 — 27.01.12 — 05:39

(7) из семёрки в 8 НЕ получится

   Cube

 

10 — 27.01.12 — 05:40

(6) Нет. И файловая и SQL делают всё там, где это определил разработчик. Для обычных форм, это и на клиенте и на сервере, плюс большая нагрузка на сеть. Для управляемых форм это в основном на сервере, плюс маленькая нагрузка на сеть.
SQL отличается от файловой только скоростью чтения/записи данных и то только при количестве пользователей больше 10-20…

 
 

   vladimir-boy

 

11 — 27.01.12 — 05:42

(0) Если есть файловая база на семёрке, то можно повесить эту же семёрку на sql2005

   Uragan_a

 

12 — 27.01.12 — 08:38

(11) хотят на восьмерку перейти, должны же быть какие то обработки)

   Uragan_a

 

13 — 27.01.12 — 08:45

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

   Uragan_a

 

14 — 27.01.12 — 08:54

ребят а если использовать бесплатный сервер скуль? чем отличия от платного?

описывается бесплатный http://www.softmaker.kz/articles.php?cat=5&id=87

   Reaper_1c

 

15 — 27.01.12 — 08:54

Точно специалистов на мисте нет, одни тролли -Блокировки? Не, не слышали…
   vladimir-boy

 

16 — 27.01.12 — 08:57

(12) О_о ! Обработка есть только, которая в 8 из 7 содержимое справочников вытянет. Всю кофигурацию при переходе на 8 придётся переписывать!

   Uragan_a

 

17 — 27.01.12 — 08:58

(16) ребят а если использовать бесплатный сервер скуль? чем отличия от платного?

возможно ли будет на этом работать

   Дядя Васька

 

18 — 27.01.12 — 09:00

(10) «SQL отличается от файловой только скоростью чтения/записи данных» — в мемориз 🙂

   Дядя Васька

 

19 — 27.01.12 — 09:01

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

   ptiz

 

20 — 27.01.12 — 09:02

(14) Ограничение в 10гб на размер базы. Только сервер 1С за 42 тыс. купиь.

   vladimir-boy

 

21 — 27.01.12 — 09:03

(17) если не ошибаюсь, то урезанным функционалом и количеством одновременных подключений

   Маратыч

 

22 — 27.01.12 — 09:05

бесплатные без ограничений — PostgreSQL и Oracle. Правда, в последнем случае есть формальные нюансы насчет коммерческого использования.

   Uragan_a

 

23 — 27.01.12 — 09:06

(20) я так понял что сервер уже есть

   Живой Ископаемый

24 — 27.01.12 — 09:08

2(22) разве у Оракл Експресс нет ограничений на память/процессор и размер базы в 4 Гига…

   Живой Ископаемый

25 — 27.01.12 — 09:08

2(21) ошибаешся.

   vladimir-boy

 

26 — 27.01.12 — 09:09

(23) Сервер 1С(это отдельный программный компонент) работает в связке с ms sql server

   Uragan_a

 

27 — 27.01.12 — 09:11

то есть на количество пользователей ограничений нет?

   Живой Ископаемый

28 — 27.01.12 — 09:13

   Живой Ископаемый

29 — 27.01.12 — 09:20

автору про клиент-серверный вариант работы:
http://v8.1c.ru/overview/Term_000000033.htm#1

   dva1c

 

30 — 27.01.12 — 09:27

(27) И еще. Подтяни знание в 1С8: что такое «трехзвенка»?
Поймешь это, тогда поймешь чем клиент-серверный отличается от файловой.

 

TurboConf 5 — расширение возможностей Конфигуратора 1С

ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку «Обновить» в браузере.

Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.

Клиент-серверный вариант работы

Клиент-серверный вариант работы системы 1С:Предприятие 8 – один из двух вариантов работы, поддерживаемых системой.

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

Архитектура клиент-серверного варианта работы является, логически, трёхуровневой и представлена на рисунке ниже.

Клиентские приложения расположены на компьютерах пользователей системы 1С – у бухгалтеров, работников кадровой службы, заведующих складами, продавцов, и т.д.

Кластер серверов 1С:Предприятие 8 – основной логический компонент системы 1С, является совокупностью процессов, обеспечивающих работу системы. Физически кластер располагается на одном или нескольких выделенных серверах.

Сервер базы данных – хранилище информации системы, физически может располагаться и на сервере кластеров, и на отдельном сервере. Он может быть реализован с помощью таких программных продуктах, как Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database.

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

Количество дополнительных компьютеров повышенного качества, на которых будут располагаться кластер серверов 1С:Предприятие 8 и сервер базы данных, определяются количеством рабочих мест, которые вам необходимы.

В клиент-серверном варианте работы системы 1С:Предприятие 8 клиентские приложения, установленные на компьютерах конечных пользователей, могут подключаться к кластеру серверов с помощью клиентов одного из трёх типов – Толстый клиент, Тонкий клиент и Веб-клиент.

  • Толстый клиент способен работать только по протоколу TCP/IP.
  • Тонкий клиент может обеспечить подключение клиентского приложения к кластеру и по протоколу TCP/IP, и по протоколу HTTPS.
  • Веб-клиент обеспечивает подключение только по протоколу HTTPS.

Вышеизложенное иллюстрируется на рисунке ниже:

Выводы

Достоинства:

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

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

В заключение

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

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

23.06.2017

Оптимизация реструктуризации базы данных

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

Реализовано в версии 8.3.11.2867.

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

Ускорение достигается за счёт минимизации манипуляций над данными и максимального их переноса на уровень системы управления базой данных (СУБД). 

Что такое реструктуризация? 

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

Реструктуризация выполняется тогда, когда изменения конфигурации требуют появления новых колонок или таблиц в базе, или когда меняется тип существующей колонки. Например, вы добавили реквизит к справочнику, добавили документ, или изменили тип имеющегося реквизита с Число на Строка. В этих случаях потребуется реструктуризация. 

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

«Традиционная» реструктуризация 

В процессе реструктуризации последовательно анализируются все объекты конфигурации. Не углубляясь в подробности можно сказать, что для каждого объекта выполняется: 

  • Анализ его изменений; 
  • Создание новых таблиц в базе данных, которые соответствуют новой структуре объекта; 
  • Перенос данных. 

Из этих трёх шагов перенос данных занимает наибольшее количество времени. При этом сами операции переноса данных могут быть простыми и сложными. 

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

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

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

Новый механизм реструктуризации 

Главное изменение заключается в том, что оптимизация реструктуризации достигнута не за счёт локальных изменений «традиционного» механизма, а за счёт создания полностью нового механизма реструктуризации. 

Это непростая и трудоёмкая задача, потому что механизм реструктуризации должен обеспечивать транзакционность изменений, то есть надежность и целостность базы данных во всех случаях. Механизм должен быть готов к тому, что процесс реструктуризации может прерваться в любой момент (в результате сбоя, например), и при этом система должна остаться в консистентном состоянии. То есть либо в виде старой версии, либо в виде новой версии. Старый механизм для этого создавал новые версии изменённых таблиц, и заполнял их. А потом подменял все старые версии на новые. 

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

Кроме этого новый механизм основан на ряде идей, которые позволили получить значительное ускорение: 

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

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

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

На основе этих идей мы достигли максимальной оптимизации на тех изменениях конфигурации, которые приводят к следующим операциям с данными: 

  • Добавление или удаление столбцов таблиц. Эти операции проводятся теперь на текущих таблицах (раньше создавались новые таблицы и в них переносились данные). Необходимость добавления или удаления столбцов возникает, например, при добавлении или удалении реквизитов, при изменении некоторых свойств объекта конфигурации (иерархия справочника и столбец _ParentID) и др. 
  • Добавление или удаление индексов. Просто создаётся новый индекс, без создания новых таблиц и переноса данных. Эти операции выполняются, если вы установили индексирование у реквизита, например. 
  • Изменение существующих индексов. Также выполняется без создания таблиц и переноса данных. Например, кластерный индекс регистра сведений меняется тогда, когда вы добавляете измерение. 

В других операциях перенос данных требуется как и раньше, но практически всегда (в большей части операций) он осуществляется на уровне СУБД. Данные переносятся единым запросом. Это может быть INSERT для новых таблиц, или UPDATE существующих таблиц. 

Конечно, существуют такие изменения, которые всё равно проходят обработку на сервере с выгрузкой данных построчно. Например, преобразование строки в число, или в дату. Такие операции нецелесообразно делать на уровне СУБД, к тому же они довольно редко встречаются. Но наиболее частые изменения проводятся всё же на уровне СУБД, одним запросом на одну таблицу. 

Результаты 

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

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

Мы провели несколько сравнительных экспериментов на реальных информационных базах, и получили следующие результаты: 

  • Добавление реквизитов к документам и измерений к регистрам сведений. База 400 Гб. Новый механизм позволяет ускорить реструктуризацию с 2 часов до 15 минут. 
  • Изменение режима совместимости с 8.2.19 на 8.3.6. База 6 Тб. Ускорение с 5 дней до 12 часов. 

Особенности текущей реализации 

Новый механизм реструктуризации мы планируем включить в версию 8.3.11 в статусе бета. Он реализован только на сервере, причём на сервере должна быть установлена Java 8. 

Чтобы использовать новый механизм реструктуризации, вы можете запустить Конфигуратор в пакетном режиме. Кроме этого в файле conf.cfg вы также можете указать необходимость использования нового механизма. Тогда новая реструктуризация будет выполняться при нажатии КонфигурацияКонфигурация базы данныхОбновить конфигурацию базы данных на сервере. Если никаких специальных действий не предпринимать (просто установить новую платформу), то стандартно будет использоваться старый механизм. 

Пока поддерживаются только две СУБД: MS SQL Server и PostgreSQL. 

На текущий момент мы оптимизировали реструктуризацию не всех объектов конфигурации, а только основных: 

  • Планов обмена, 
  • Справочников, 
  • Документов, 
  • Журналов документов, 
  • Планов видов характеристик, 
  • Планов счетов, 
  • Регистров сведений, 
  • Регистров накопления,
  • Регистров бухгалтерии. 

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

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

Добавить комментарий

Закрыть меню